On Mon, 25 Feb 2019, Linus Torvalds wrote: > On Fri, Feb 22, 2019 at 10:35 PM Hugh Dickins <hughd@xxxxxxxxxx> wrote: > > > > When we made the shmem_reserve_inode call in shmem_link conditional, we > > forgot to update the declaration for ret so that it always has a known > > value. Dan Carpenter pointed out this deficiency in the original patch. > > Applied. Thanks. And I apologize for letting that slip through: Darrick sent the patch fragment, I dressed it up, and more or less tricked him into taking ownership of the bug, when it's I who should have been more careful. But I'm glad it confirmed your rc8 instinct, rather than messing final :) > > Side note: how come gcc didn't warn about this? Yes, we disable that > warning for some cases because of lots of false positives, but I > thought the *default* setup still had it. I thought so too, and have been puzzled by it. If I try removing the initialization of inode from the next function, shmem_unlink(), I do get the expected warning for that. > > Is it just that the goto ends up confusing gcc enough that it never notices? Since the goto route did have ret properly initialized, I don't see why it might have been confusing, but what do I know... I thought it might be because outside the goto route, ret was used for nothing but the return value. But that's disproved: I tried a very silly "inode->i_flags = ret;" just after d_instantiate(), and still no warning when ret is uninitialized. Seems like a gcc bug? But I don't have a decent recent gcc to hand to submit a proper report, hope someone else can shed light on it. Hugh
