lists.openwall.net   lists  /  announce  owl-users  owl-dev  john-users  john-dev  passwdqc-users  yescrypt  popa3d-users  /  oss-security  kernel-hardening  musl  sabotage  tlsify  passwords  /  crypt-dev  xvendor  /  Bugtraq  Full-Disclosure  linux-kernel  linux-netdev  linux-ext4  linux-hardening  linux-cve-announce  PHC 
Open Source and information security mailing list archives
 
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Fri, 14 Jan 2011 08:48:11 -0600
From:	Shawn Bohrer <shawn.bohrer@...il.com>
To:	Jack Stone <jwjstone@...tmail.fm>,
	Andrew Morton <akpm@...ux-foundation.org>
Cc:	Viresh Kumar <viresh.kumar@...com>, linux-kernel@...r.kernel.org,
	linux-fsdevel@...r.kernel.org, viro@...iv.linux.org.uk
Subject: Re: [PATCH resend] fs/eventpoll.c: fix compilation warning

On Fri, Jan 14, 2011 at 7:07 AM, Jack Stone <jwjstone@...tmail.fm> wrote:
> [cc Al Viro and Shawn Bohrer]
> On 14/01/2011 11:52, Viresh Kumar wrote:
>> This patch fixes following compilation warning
>> fs/eventpoll.c:1119: warning: 'slack' may be used uninitialized in this function
>>
>> Signed-off-by: Viresh Kumar <viresh.kumar@...com>
>> ---
>>  fs/eventpoll.c |    2 +-
>>  1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/fs/eventpoll.c b/fs/eventpoll.c
>> index 8cf0724..89b5e98 100644
>> --- a/fs/eventpoll.c
>> +++ b/fs/eventpoll.c
>> @@ -1116,7 +1116,7 @@ static int ep_poll(struct eventpoll *ep, struct epoll_event __user *events,
>>  {
>>       int res, eavail, timed_out = 0;
>>       unsigned long flags;
>> -     long slack;
>> +     long uninitialized_var(slack);
>>       wait_queue_t wait;
>>       struct timespec end_time;
>>       ktime_t expires, *to = NULL;
>
> Hi Viresh,
>
> This is certainly the correct thing to do if timeout cannot be negative.
>
> Al, Shawn
>
> Can timeout be negative, and if so what does it mean?

Yes timeout can be negative.  When timeout is negative it signifies an
infinite timeout.  Therefore I think the correct fix is to initialize
slack to 0.  I actually sent a patch to fix this back in November, but
it looks like it was never applied.

https://lkml.org/lkml/2010/11/27/143

Andrew, can you apply this patch?  Let me know if I need to resend.

--
Shawn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ