linux-kernel - Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

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:	Sun, 30 May 2010 11:43:50 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Arve Hjønnevåg <arve@...roid.com>
cc:	Peter Zijlstra <peterz@...radead.org>,
	Brian Swetland <swetland@...gle.com>,
	Ingo Molnar <mingo@...e.hu>,
	LKML <linux-kernel@...r.kernel.org>,
	Florian Mickler <florian@...kler.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Alan Cox <alan@...rguk.ukuu.org.uk>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Sat, 29 May 2010, Alan Stern wrote:

> On Sat, 29 May 2010, Arve Hjønnevåg wrote:

> > >        for (;;) {
> > >                while (any IPC requests remain)
> > >                        handle them;
> > >                if (any processes need to prevent suspend)
> > >                        sleep;
> > >                else
> > >                        write "qos" to /sys/power/state;
> > >        }
> > >
> > > The idea is that receipt of a new IPC request will cause a signal to be
> > > sent, interrupting the sleep or the "qos" write.
> > 
> > What happen if the signal is right before (or even right after)
> > calling write "qos". How does the signal handler stop the write?
> 
> You're right, this is a serious problem.  The process would have to
> give the kernel a signal mask to be used during the wait, as in ppoll
> or pselect.  There ought to be a way to do this or something
> equivalent.

Okay, here's a possible solution:

	char arg[20];

	signal_handler()
	{
		arg[0] = 0;
	}


	In the main loop:

	...
	mask signals;
	if (we decide to start a QoS-based suspend) {
		strcpy(arg, "qos");
		unmask signals;
		write arg to /sys/power/state;
	}

It's hacky but I think it will work.

A more straightforward approach is to give processes the ability to 
register their own QoS constraints.  This could be done via a custom 
driver as Brian suggested or by adding a new system call as Alan Cox 
suggested.  Then the power manager could be split into two threads, one 
of which handles IPC requests and manages QoS constraints, while the 
other repeatedly attempts to initiate QoS-based suspends.

Alan Stern

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