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

Powered by blists - more mailing lists