mm,vmscan: Allow preallocating memory for register_shrinker().
authorTetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Wed, 4 Apr 2018 10:53:07 +0000 (19:53 +0900)
committerAl Viro <viro@zeniv.linux.org.uk>
Mon, 16 Apr 2018 06:06:47 +0000 (02:06 -0400)
commit8e04944f0ea8b838399049bdcda920ab36ae3b04
tree830ce2c35100627212caaf732396cafd7bfc1dc8
parent4a3877c4cedd95543f8726b0a98743ed8db0c0fb
mm,vmscan: Allow preallocating memory for register_shrinker().

syzbot is catching so many bugs triggered by commit 9ee332d99e4d5a97
("sget(): handle failures of register_shrinker()"). That commit expected
that calling kill_sb() from deactivate_locked_super() without successful
fill_super() is safe, but the reality was different; some callers assign
attributes which are needed for kill_sb() after sget() succeeds.

For example, [1] is a report where sb->s_mode (which seems to be either
FMODE_READ | FMODE_EXCL | FMODE_WRITE or FMODE_READ | FMODE_EXCL) is not
assigned unless sget() succeeds. But it does not worth complicate sget()
so that register_shrinker() failure path can safely call
kill_block_super() via kill_sb(). Making alloc_super() fail if memory
allocation for register_shrinker() failed is much simpler. Let's avoid
calling deactivate_locked_super() from sget_userns() by preallocating
memory for the shrinker and making register_shrinker() in sget_userns()
never fail.

[1] https://syzkaller.appspot.com/bug?id=588996a25a2587be2e3a54e8646728fb9cae44e7

Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Reported-by: syzbot <syzbot+5a170e19c963a2e0df79@syzkaller.appspotmail.com>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: Michal Hocko <mhocko@suse.com>
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
fs/super.c
include/linux/shrinker.h
mm/vmscan.c