Re: Best solution for shifting DAX_ZERO_PAGE to XA_ZERO_ENTRY

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



Sorry for the long reply time - personal issues came up.

On Sun, Nov 8, 2020 at 7:36 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
>
> On Sun, Nov 08, 2020 at 05:54:14PM -0800, Amy Parker wrote:
> > On Sun, Nov 8, 2020 at 5:50 PM Matthew Wilcox <willy@xxxxxxxxxxxxx> wrote:
> > >
> > > On Sun, Nov 08, 2020 at 05:33:22PM -0800, Darrick J. Wong wrote:
> > > > On Sun, Nov 08, 2020 at 05:15:55PM -0800, Amy Parker wrote:
> > > > > XA_ZERO_ENTRY
> > > > > is defined in include/linux/xarray.h, where it's defined using
> > > > > xa_mk_internal(257). This function returns a void pointer, which
> > > > > is incompatible with the bitwise arithmetic it is performed on with.
> > >
> > > We don't really perform bitwise arithmetic on it, outside of:
> > >
> > > static int dax_is_zero_entry(void *entry)
> > > {
> > >         return xa_to_value(entry) & DAX_ZERO_PAGE;
> > > }
> >
> > We also have:
> >
> > if (dax_is_zero_entry(entry) && !(flags & DAX_ZERO_PAGE)) {
> >        unsigned long index = xas->xa_index;
> >        /* we are replacing a zero page with block mapping */
> >        if (dax_is_pmd_entry(entry))
> >               unmap_mapping_pages(mapping, index & ~PG_PMD_COLOUR,
> >                             PG_PMD_NR, false);
> >        else /* pte entry */
> >               unmap_mapping_pages(mapping, index, 1, false);
> > }
> >
> > and:
> >
> > *entry = dax_insert_entry(xas, mapping, vmf, *entry, pfn,
> >               DAX_PMD | DAX_ZERO_PAGE, false);
>
> Right.  We need to be able to distinguish whether an entry represents
> a PMD size.  So maybe we need XA_ZERO_PMD_ENTRY ... ?  Or we could use
> the recently-added xa_get_order().

I could add an additional dependent patch for this. Where would we
want XA_ZERO_PMD_ENTRY declared? Considering we're dependent
on DAX_PMD, I'd say in fs/dax.c, but if there's a better solution I'm missing...

> >
> > That'd probably be a better idea - so what should we do about the type
> > issue? Not typecasting it causes it not to compile.
>
> I don't think you'll need to do any casting once the bit operations go
> away ...

True, but what're we going to do about dax_is_zero_entry? We haven't
figured out what to do about that yet... a typecast back to void* of
xa_to_value locally could work, as it itself is just shifting an entry right
by 1 bit and then typecasting it to unsigned long. Thoughts?

Best regards,
Amy Parker
(she/her)



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]

  Powered by Linux