On Thu, Jun 07, 2018 at 06:52:13PM +0200, David Sterba wrote: > On Thu, Jun 07, 2018 at 06:28:02PM +0200, Dmitry Vyukov wrote: > > > Normally the GFP_NOFS allocations do not fail so I think the fuzzer > > > environment is tuned to allow that, which is fine for coverage but does > > > not happen in practice. This will be fixed eventually. > > > > Isn't GFP_NOFS more restricted than normal allocations? Are these > > allocations accounted against memcg? It's easy to fail any allocation > > within a memory container. > > https://lwn.net/Articles/723317/ The 'too small to fail' and some > unwritten semantics of GFP_NOFS but I think you're right about the > memory controler that can fail any allocation though. > > Error handling is being improved over time, the memory allocation > failures are in some cases hard and this one would need to update some > logic so it's not a oneliner. > This bug is still there. In btrfs_close_one_device(): if (device->name) { name = rcu_string_strdup(device->name->str, GFP_NOFS); BUG_ON(!name); /* -ENOMEM */ rcu_assign_pointer(new_device->name, name); } It assumes that the memory allocation succeeded. See syzbot report from v5.2-rc3 here: https://syzkaller.appspot.com/text?tag=CrashReport&x=16c839c1a00000 Is there any plan to fix this? - Eric
