linux-kernel - Re: [PATCH v3 07/22] kthread: Detect when a kthread work is used by more workers

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:	Tue, 24 Nov 2015 17:28:23 +0100
From:	Petr Mladek <pmladek@...e.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Oleg Nesterov <oleg@...hat.com>,
	Ingo Molnar <mingo@...hat.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Steven Rostedt <rostedt@...dmis.org>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Josh Triplett <josh@...htriplett.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Jiri Kosina <jkosina@...e.cz>, Borislav Petkov <bp@...e.de>,
	Michal Hocko <mhocko@...e.cz>, linux-mm@...ck.org,
	Vlastimil Babka <vbabka@...e.cz>, linux-api@...r.kernel.org,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH v3 07/22] kthread: Detect when a kthread work is used by
 more workers

On Tue 2015-11-24 09:49:42, Tejun Heo wrote:
> Hello, Petr.
> 
> On Tue, Nov 24, 2015 at 11:06:50AM +0100, Petr Mladek wrote:
> > > > @@ -610,6 +625,12 @@ repeat:
> > > >  	if (work) {
> > > >  		__set_current_state(TASK_RUNNING);
> > > >  		work->func(work);
> > > > +
> > > > +		spin_lock_irq(&worker->lock);
> > > > +		/* Allow to queue the work into another worker */
> > > > +		if (!kthread_work_pending(work))
> > > > +			work->worker = NULL;
> > > > +		spin_unlock_irq(&worker->lock);
> > > 
> > > Doesn't this mean that the work item can't be freed from its callback?
> > > That pattern tends to happen regularly.
> > 
> > I am not sure if I understand your question. Do you mean switching
> > work->func during the life time of the struct kthread_work? This
> > should not be affected by the above code.
> 
>IOW, you can't expect the work
> item to remain accessible once the work function starts executing.

I see, I was not aware of this pattern.


> > The above code allows to queue an _unused_ kthread_work into any
> > kthread_worker. For example, it is needed for khugepaged,
> > see http://marc.info/?l=linux-kernel&m=144785344924871&w=2
> > The work is static but the worker can be started/stopped
> > (allocated/freed) repeatedly. It means that the work need
> > to be usable with many workers. But it is associated only
> > with one worker when being used.
>
> It can just re-init work items when it restarts workers, right?

Yes, this would work. It might be slightly inconvenient but
it looks like a good compromise. It helps to keep the API
implementation rather simple and rather secure.

Alternatively, we could allow to queue the work on another worker
if it is not pending. But then we would need to check the pending
status without the worker->lock because work->worker might point
to an already freed worker. We need to check the pending
status in many situations. It might open a can of worms that
I probably do not want to catch.

Thank you and PeterZ for explanation,
Petr
--
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/