On Wed 11-04-12 15:10:24, Glauber Costa wrote: > While stressing the kernel with with failing allocations today, > I hit the following chain of events: > > alloc_page_buffers(): > > bh = alloc_buffer_head(GFP_NOFS); > if (!bh) > goto no_grow; <= path taken > > grow_dev_page(): > bh = alloc_page_buffers(page, size, 0); > if (!bh) > goto failed; <= taken, consequence of the above > > and then the failed path BUG()s the kernel. > > The failure is inserted a litte bit artificially, but even then, > I see no reason why it should be deemed impossible in a real box. > > Even though this is not a condition that we expect to see > around every time, failed allocations are expected to be handled, > and BUG() sounds just too much. As a matter of fact, grow_dev_page() > can return NULL just fine in other circumstances, so I propose we just > remove it, then. I am not familiar with the code much but a trivial call chain walk up to write_dev_supers (in btrfs) shows that we do not check for the return value from __getblk so we would nullptr and there might be more. I guess these need some treat before the BUG might be removed, right? > > Signed-off-by: Glauber Costa <glommer@xxxxxxxxxxxxx> > CC: Linus Torvalds <torvalds@xxxxxxxxxxxxxxxxxxxx> > CC: Andrew Morton <akpm@xxxxxxxxxxxxxxxxxxxx> > --- > fs/buffer.c | 1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > diff --git a/fs/buffer.c b/fs/buffer.c > index 36d6665..351e18e 100644 > --- a/fs/buffer.c > +++ b/fs/buffer.c > @@ -985,7 +985,6 @@ grow_dev_page(struct block_device *bdev, sector_t block, > return page; > > failed: > - BUG(); > unlock_page(page); > page_cache_release(page); > return NULL; > -- > 1.7.7.6 > > -- > To unsubscribe, send a message with 'unsubscribe linux-mm' in > the body to majordomo@xxxxxxxxx. For more info on Linux MM, > see: http://www.linux-mm.org/ . > Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/ > Don't email: <a href=mailto:"dont@xxxxxxxxx";> email@xxxxxxxxx </a> -- Michal Hocko SUSE Labs SUSE LINUX s.r.o. Lihovarska 1060/12 190 00 Praha 9 Czech Republic -- To unsubscribe from this list: send the line "unsubscribe cgroups" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
