Hi,
I am having issues applying the aufs patch on top of the linux-stable
kernel. I'm targeting 4.4 (which I know isn't officially supported by
aufs anymore), 4.9 and 4.14 on their latest versions (currently
4.4.143, 4.9.114 and 4.14.57) and I use the tip of each corresponding
branch on aufs4-standalone.git. On all of these versions
aufs4-loopback.patch does not apply and is rejected with some hunks
failing.
1. linux-4.14.y:
# On v4.14.57
$ patch -d ../linux -p1 <aufs-loopback.patch
patching file drivers/block/loop.c
Hunk #2 succeeded at 668 (offset 30 lines).
Hunk #3 FAILED at 655.
Hunk #4 succeeded at 703 (offset 31 lines).
Hunk #5 succeeded at 711 (offset 31 lines).
Hunk #6 FAILED at 883.
Hunk #7 succeeded at 922 (offset 25 lines).
Hunk #8 succeeded at 960 (offset 9 lines).
Hunk #9 succeeded at 994 (offset 9 lines).
Hunk #10 succeeded at 1042 (offset 9 lines).
Hunk #11 succeeded at 1074 (offset 9 lines).
Hunk #12 succeeded at 1122 (offset 9 lines).
2 out of 12 hunks FAILED -- saving rejects to file drivers/block/loop.c.rej
patching file drivers/block/loop.h
patching file fs/aufs/f_op.c
Hunk #1 succeeded at 368 (offset 10 lines).
patching file fs/aufs/loop.c
Hunk #1 succeeded at 146 (offset 13 lines).
patching file fs/aufs/loop.h
Hunk #1 succeeded at 39 (offset 13 lines).
Hunk #2 succeeded at 51 (offset 13 lines).
patching file fs/aufs/super.c
Hunk #1 succeeded at 849 (offset 13 lines).
patching file include/linux/fs.h
Hunk #1 succeeded at 1840 (offset 1 line).
This happens from v4.14.56 onward. For reference:
$ git log v4.14.55..v4.14.56 drivers/block/loop.c
commit d2c18ad18cc7041b0591847d4c4ea4802bbd122e
Author: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Date: Fri May 4 10:58:09 2018 -0600
loop: remember whether sysfs_create_group() was done
commit d3349b6b3c373ac1fbfb040b810fcee5e2adc7e0 upstream.
syzbot is hitting WARN() triggered by memory allocation fault
injection [1] because loop module is calling sysfs_remove_group()
when sysfs_create_group() failed.
Fix this by remembering whether sysfs_create_group() succeeded.
[1]
https://syzkaller.appspot.com/bug?id=3f86c0edf75c86d2633aeb9dd69eccc70bc7e90b
Signed-off-by: Tetsuo Handa <penguin-ker...@i-love.sakura.ne.jp>
Reported-by: syzbot
<syzbot+9f03168400f56df89dbc6f1751f4458fe739f...@syzkaller.appspotmail.com>
Reviewed-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
Renamed sysfs_ready -> sysfs_inited.
Signed-off-by: Jens Axboe <ax...@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
commit 6f9f5797fc7de2e9f801b2f7af0726e1349d33a4
Author: Theodore Ts'o <ty...@mit.edu>
Date: Mon May 7 11:37:58 2018 -0400
loop: add recursion validation to LOOP_CHANGE_FD
commit d2ac838e4cd7e5e9891ecc094d626734b0245c99 upstream.
Refactor the validation code used in LOOP_SET_FD so it is also used in
LOOP_CHANGE_FD. Otherwise it is possible to construct a set of loop
devices that all refer to each other. This can lead to a infinite
loop in starting with "while (is_loop_device(f)) .." in loop_set_fd().
Fix this by refactoring out the validation code and using it for
LOOP_CHANGE_FD as well as LOOP_SET_FD.
Reported-by:
syzbot+4349872271ece473a7c91190b68b4bac7c5db...@syzkaller.appspotmail.com
Reported-by: syzbot+40bd32c4d9a3cc12a...@syzkaller.appspotmail.com
Reported-by: syzbot+769c54e66f994b041...@syzkaller.appspotmail.com
Reported-by: syzbot+0a89a9ce473936c57...@syzkaller.appspotmail.com
Signed-off-by: Theodore Ts'o <ty...@mit.edu>
Signed-off-by: Jens Axboe <ax...@kernel.dk>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
2. linux-4.9.y: this happens from v4.9.94 onward. For reference:
$ git log v4.9.93..v4.9.94 drivers/block/loop.c
commit 7f736f0e9ba38705eaf8e36a622a4b47218c14ae
Author: James Wang <jnw...@suse.com>
Date: Thu Jun 8 14:52:51 2017 +0800
Fix loop device flush before configure v3
[ Upstream commit 6460495709aeb651896bc8e5c134b2e4ca7d34a8 ]
While installing SLES-12 (based on v4.4), I found that the installer
will stall for 60+ seconds during LVM disk scan. The root cause was
determined to be the removal of a bound device check in loop_flush()
by commit b5dd2f6047ca ("block: loop: improve performance via blk-mq").
Restoring this check, examining ->lo_state as set by loop_set_fd()
eliminates the bad behavior.
Test method:
modprobe loop max_loop=64
dd if=/dev/zero of=disk bs=512 count=200K
for((i=0;i<4;i++))do losetup -f disk; done
mkfs.ext4 -F /dev/loop0
for((i=0;i<4;i++))do mkdir t$i; mount /dev/loop$i t$i;done
for f in `ls /dev/loop[0-9]*|sort`; do \
echo $f; dd if=$f of=/dev/null bs=512 count=1; \
done
Test output: stock patched
/dev/loop0 18.1217e-05 8.3842e-05
/dev/loop1 6.1114e-05 0.000147979
/dev/loop10 0.414701 0.000116564
/dev/loop11 0.7474 6.7942e-05
/dev/loop12 0.747986 8.9082e-05
/dev/loop13 0.746532 7.4799e-05
/dev/loop14 0.480041 9.3926e-05
/dev/loop15 1.26453 7.2522e-05
Note that from loop10 onward, the device is not mounted, yet the
stock kernel consumes several orders of magnitude more wall time
than it does for a mounted device.
(Thanks for Mike Galbraith <efa...@gmx.de>, give a changelog review.)
Reviewed-by: Hannes Reinecke <h...@suse.com>
Reviewed-by: Ming Lei <ming....@redhat.com>
Signed-off-by: James Wang <jnw...@suse.com>
Fixes: b5dd2f6047ca ("block: loop: improve performance via blk-mq")
Signed-off-by: Jens Axboe <ax...@fb.com>
Signed-off-by: Sasha Levin <alexander.le...@microsoft.com>
Signed-off-by: Greg Kroah-Hartman <gre...@linuxfoundation.org>
At this point, it fails with one rejected hunk. However, the same two
commits as linux-4.14.y have also been applied on this branch later.
The count of failed hunks then goes from 1 to 3.
3. For linux-4.4.y, but I suspect this might not be as important since
the support has been dropped: this happens from v4.4.127 onward with
one failed hunk and the same offending commit as above, then from
v4.4.141 (when the two commits mentioned in 1. are applied) with 3
failed hunks.
I hope this can help, I didn't dig in further. In the meantime, I am
building without the loopback patch.
Jérôme
------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
