linux-kernel - RE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel threads

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <B85A65D85D7EB246BE421B3FB0FBB59301DE31FD10@dbde02.ent.ti.com>
Date:	Sun, 8 Nov 2009 16:40:07 +0530
From:	"Dasgupta, Romit" <romit@...com>
To:	Pavel Machek <pavel@....cz>
CC:	"Rafael J. Wysocki" <rjw@...k.pl>,
	"linux-omap@...r.kernel.org" <linux-omap@...r.kernel.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	"linux-pm@...ts.linux-foundation.org" 
	<linux-pm@...ts.linux-foundation.org>
Subject: RE: [PATCH 1/1] PM: Thaws refrigerated and to be exited kernel
 threads

(Resending with 80 column restriction) 

> -----Original Message-----
> From: Pavel Machek [mailto:pavel@....cz] 
> Sent: Sunday, November 08, 2009 1:57 PM
> To: Dasgupta, Romit
> Cc: Rafael J. Wysocki; linux-omap@...r.kernel.org; 
> linux-kernel@...r.kernel.org; linux-pm@...ts.linux-foundation.org
> Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be 
> exited kernel threads
> 
> On Sun 2009-11-08 09:52:52, Dasgupta, Romit wrote:
> > > Subject: Re: [PATCH 1/1] PM: Thaws refrigerated and to be 
> exited kernel
> > > threads
> > > 
> > > Hi!
> > > 
> > > > Kicks out a frozen thread from the refrigerator when an 
> active thread has
> > > > invoked kthread_stop on the frozen thread.
> ...
> > > > @@ -49,7 +50,7 @@ void refrigerator(void)
> > > >
> > > >  	for (;;) {
> > > >  		set_current_state(TASK_UNINTERRUPTIBLE);
> > > > -		if (!frozen(current))
> > > > +		if (!frozen(current) || (!current->mm 
> && kthread_should_stop()))
> > > >  			break;
> > > >  		schedule();
> > > 
> > > Well, what if the thread does some processing before 
> stopping? That
> > > would break refrigerator assumptions...
> > 
> > The suspend thread will block until the 'to be stopped' 
> thread clears up. That is what any call to kthread_stop would 
> boil down to. The target thread would anyway be out of the 
> refrigerator so I am not sure what assumption you mean here. 
> Eventually, the target thread would clear up and wake up the 
> suspend thread and then things would go on as usual.
> 
> (Please format to 80 columns).
> 
> No, I do not get it.
> 
> Lets say we have
> 
> evil_data_writer thread that needs to be stopped becuase it writes to
> filesystem
> 
> nofreeze random_stopper thread
> 
> now we create the suspend image, and start writing it out. But that's
> okay, evil_data_writer is stopped so it can't do no harm. But now
> random_stopper decides to thread_stop() the evil_data_writer, and this
> new code allows it to exit the refrigerator, *do some writing*, and
> then stop.
> 
> That's bad, right?
evil_data_writer will enter refrigerator after invoking 'try_to_freeze'. This 
should be followed by a call to kthread_should_stop. There it decides if it 
needs to exit the thread (after cleanups if necessary) or not. I have seen that
the bdi_writeback_task function is like that. It does not care if there is 
pending data to be written if it detects that someone have invoked a 
'kthread_stop' on it. It simply exits. I have seen some other kernel threads 
that do not follow this and I think that probably is not right. 
--
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/