Re: [PATCH v2] xfs: preserve i_rdev when recycling a reclaimable inode

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

 



On Thu, Feb 1, 2018 at 2:35 AM, Darrick J. Wong <darrick.wong@xxxxxxxxxx> wrote:
> On Thu, Feb 01, 2018 at 02:27:23AM +0200, Amir Goldstein wrote:
>> On Mon, Jan 29, 2018 at 5:50 PM, Darrick J. Wong
>> <darrick.wong@xxxxxxxxxx> wrote:
>> > On Mon, Jan 29, 2018 at 01:07:36PM +0200, Amir Goldstein wrote:
>> >> On Fri, Jan 26, 2018 at 11:44 PM, Darrick J. Wong
>> >> <darrick.wong@xxxxxxxxxx> wrote:
>> >> > On Fri, Jan 26, 2018 at 09:44:29AM +0200, Amir Goldstein wrote:
>> >> >> Commit 66f364649d870 ("xfs: remove if_rdev") moved storing of rdev
>> >> >> value for special inodes to VFS inodes, but forgot to preserve the
>> >> >> value of i_rdev when recycling a reclaimable xfs_inode.
>> >> >>
>> >> >> This was detected by xfstest overlay/017 with inodex=on mount option
>> >> >> and xfs base fs. The test does a lookup of overlay chardev and blockdev
>> >> >> right after drop caches.
>> >> >>
>> >> >> Overlayfs inodes hold a reference on underlying xfs inodes when mount
>> >> >> option index=on is configured. If drop caches reclaim xfs inodes, before
>> >> >> it relclaims overlayfs inodes, that can sometimes leave a reclaimable xfs
>> >> >> inode and that test hits that case quite often.
>> >> >>
>> >> >> When that happens, the xfs inode cache remains broken (zere i_rdev)
>> >> >> until the next cycle mount or drop caches.
>> >> >>
>> >> >> Fixes: 66f364649d870 ("xfs: remove if_rdev")
>> >> >> Signed-off-by: Amir Goldstein <amir73il@xxxxxxxxx>
>> >> >
>> >> > Looks ok,
>> >> > Reviewed-by: Darrick J. Wong <darrick.wong@xxxxxxxxxx>
>> >> >
>> >>
>> >> I recon that now we should now also strap:
>> >> Cc: <stable@xxxxxxxxxxxxxxx> #v4.15
>> >>
>> >> Can I assume, you'll add it on apply?
>> >
>> > I'll do a proper backport of this and a couple other critical cow
>> > fixes after I get the 4.16 stuff merged.
>> >
>>
>> I am not sure what "proper backport" means in the context of
>> this patch.
>> This is a v4.15-rc1 regression fix that is based on v4.15-rc8.
>> It applied cleanly on v4.15.
>
> I meant the other things that went into 4.16, like the reflink quota
> fixes, the directio corruption problems, etc.  Make a branch, add the
> necessary fixes, run xfstests to make sure it all still works, etc.
>

Darrick,

I may be missing something in the process of stable kernel
maintenance, but this patch fixes a reproducible v4.15 regression
(xfstest overlay/017 fails on stable kernel v4.15).

Is Greg usually picking those stable patches himself or is he waiting
for xfs maintainers (or xfs stable maintainers) to stage the
stable patches?

As I wrote above, the reason this patch is missing the Cc: stable
tag is because it landed just after v4.15 was released, but I was
aiming for it to get merged to v4.15 and avoid the regression in
a release kernel.

Thanks,
Amir.
--
To unsubscribe from this list: send the line "unsubscribe linux-xfs" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html



[Index of Archives]     [XFS Filesystem Development (older mail)]     [Linux Filesystem Development]     [Linux Audio Users]     [Yosemite Trails]     [Linux Kernel]     [Linux RAID]     [Linux SCSI]


  Powered by Linux