linux-kernel - Re: timer code oops when calling mod_delayed

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:	Sat, 31 Oct 2015 17:31:07 -0400
From:	Tejun Heo <tj@...nel.org>
To:	Jeff Layton <jlayton@...chiereds.net>
Cc:	linux-kernel@...r.kernel.org, bfields@...ldses.org,
	Michael Skralivetsky <michael.skralivetsky@...marydata.com>,
	Chris Worley <chris.worley@...marydata.com>,
	Trond Myklebust <trond.myklebust@...marydata.com>,
	Lai Jiangshan <laijs@...fujitsu.com>
Subject: Re: timer code oops when calling mod_delayed_work

Hello, Jeff.

On Sat, Oct 31, 2015 at 07:34:00AM -0400, Jeff Layton wrote:
> > Heh, this one is tricky.  Yeah, try_to_grab_pending() missing PENDING
> > would explain the failure but I can't see how it'd leak at the moment.
> 
> Thanks Tejun. Yeah, I realized that after sending the response above.
> 
> If you successfully delete the timer the timer then the PENDING bit
> should already be set. Might be worth throwing in something like this,
> just before the return 1:
> 
>     WARN_ON(!test_bit(WORK_STRUCT_PENDING_BIT, work_data_bits(work)))
>
> ...but I doubt it would fire. I think it's likely that the bug is
> elsewhere.

I doubt that'd trigger either but it'd still be a good idea to throw
that in just in case.

> The other thing is that we've had this code in place for a couple of
> years now, and this is the first time I've seen an oops like this. I
> suspect that this may be a recent regression, but I don't know that for
> sure.

I can't think of any recent changes which could affect this.  This
part of code has remained unchanged for years at least from the
workqueue side.

> I have asked Chris and Michael to see if they can bisect it down, but
> it may be a bit before they can get that done. Any insight you might
> have in the meantime would helpful.

Yeah, I'd love to find out how reproducible the issue is.  If the
problem is rarely reproducible, it might make sense to try
instrumentation before trying bisection as it *could* be a latent bug
which has been there all along and bisecting to the commit introducing
the code wouldn't help us too much.

Thanks.

-- 
tejun
--
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/