On 9/26/19 2:14 PM, Rasmus Villemoes wrote: > On 26/09/2019 13.42, Jens Axboe wrote: >> On 9/26/19 1:33 PM, Dan Carpenter wrote: >>> On Thu, Sep 26, 2019 at 11:56:30AM +0200, Jens Axboe wrote: >>>> On 9/26/19 11:50 AM, Colin King wrote: >>>>> From: Colin Ian King <colin.king@xxxxxxxxxxxxx> >>>>> >>>>> In the case where sig is NULL the error variable ret is not initialized >>>>> and may contain a garbage value on the final checks to see if ret is >>>>> -ERESTARTSYS. Best to initialize ret to zero before the do loop to >>>>> ensure the ret does not accidentially contain -ERESTARTSYS before the >>>>> loop. >>>> >>>> Oops, weird it didn't complain. I've folded in this fix, as that commit >>>> isn't upstream yet. Thanks! >>> >>> There is a bug in GCC where at certain optimization levels, instead of >>> complaining, it initializes it to zero. >> >> That's awfully nice of it ;-) >> >> Tried with -O0 and still didn't complain for me. >> >> $ gcc --version >> gcc (Ubuntu 9.1.0-2ubuntu2~18.04) 9.1.0 >> >> Tried gcc 5/6/7/8 as well. Might have to go look at what code it's >> generating. >> > > I think it's essentially the same as > https://lore.kernel.org/lkml/CAHk-=whP-9yPAWuJDwA6+rQ-9owuYZgmrMA9AqO3EGJVefe8vg@xxxxxxxxxxxxxx/ > (thread "tmpfs: fix uninitialized return value in shmem_link"). I think you're right, it's the same pattern. If I kill the: if (ret) return ret; inside the if (sig) branch, then gcc does show the warning as it should. -- Jens Axboe
