linux-kernel - Re: [PATCH v2.6.36-rc7] init: don't call flush_scheduled_work() from do

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-Id: <20101103054804.c88601d5.akpm@linux-foundation.org>
Date:	Wed, 3 Nov 2010 05:48:04 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Tejun Heo <tj@...nel.org>
Cc:	lkml <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Rusty Russell <rusty@...tcorp.com.au>
Subject: Re: [PATCH v2.6.36-rc7] init: don't call flush_scheduled_work()
 from do_initcalls()

On Wed, 03 Nov 2010 11:59:21 +0100 Tejun Heo <tj@...nel.org> wrote:

> Hello, Andrew.
> 
> On 10/22/2010 08:09 PM, Andrew Morton wrote:
> > mm..  I think we'd be OK to merge it.  Any such code is pretty badly
> > buggy and is probably also crashable with a well-timed rmmod.
> > 
> > It'll also be code which few people ever use, so any runtime checks
> > won't get us very good coverage.
> > 
> > Still, if it's not too hard to implement an "are there any scheduled
> > works which live in initmem" check then I guess that would be the
> > prudent approach.  A quite gross way of implementing that might be
> > something like
> 
> I've been trying to implement proper check code but there is a
> problem.  It's possible to check all pending works to see whether the
> work struct itself or the work function is in initmem and warn about
> them.
> 
> The problem is with currently running works.  As work_struct isn't
> accessible once it starts executing, struct worker would need to cache
> it for later reference.  Worker already remembers the work_struct
> pointer itself and its cwq and adding one more field to remember the
> currently running work function is easy.  However, it's only useful
> during the unlikely buggy case during init.  Given that if anything is
> still depending on initmem, it will blow up pretty reliably, I don't
> think it's worthwhile to add additional tracking just for this.

yes, if it goes bang, we'll hear it.  And we'll be able to work out why
it went bang pretty easily.  Although I assume that a backtrace which
leads into a just-unloaded module won't be able to display that
module's symbols.

>  So, I
> think I'll just go ahead and drop the flush call and deal with the
> unlikely fallouts if there's any.

OK by me.
--
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/