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]
Message-ID: <20100527210808.GB8865@srcf.ucam.org>
Date:	Thu, 27 May 2010 22:08:08 +0100
From:	Matthew Garrett <mjg59@...f.ucam.org>
To:	Alan Cox <alan@...rguk.ukuu.org.uk>
Cc:	Arve Hjønnevåg <arve@...roid.com>,
	Florian Mickler <florian@...kler.org>,
	Vitaly Wool <vitalywool@...il.com>,
	Peter Zijlstra <peterz@...radead.org>,
	LKML <linux-kernel@...r.kernel.org>,
	Paul@...p1.linux-foundation.org, felipe.balbi@...ia.com,
	Linux OMAP Mailing List <linux-omap@...r.kernel.org>,
	Linux PM <linux-pm@...ts.linux-foundation.org>
Subject: Re: [linux-pm] [PATCH 0/8] Suspend block api (version 8)

On Thu, May 27, 2010 at 09:53:47PM +0100, Alan Cox wrote:
> > Not lost, but not delivered. So you need your policy agent to send 
> 
> it will be delivered next time the process wakes. It's not lost.
> 
> > SIGCONT when you receive any wakeup event, which either means proxying 
> > all your network traffic through your policy agent or having some 
> > mechanism for alerting the policy agent whenever you leave the deep idle 
> > state.
> 
> You didn't mention that requirement last time.

I thought it was pretty obvious that wakeup events had to actually be 
delivered to the applications that are listening for them.

> > > > also the race of an application being in the middle of handling a wakeup 
> > > > event when you send it the signal.
> > > 
> > > sigmask()
> > 
> > Doesn't help - I may be hit by the signal between the poll() unblocking 
> > and me having the opportunity to call sigmask().
> 
> ppoll(). This is all existing solved stuff.

Isn't that the inverse of what we want? The application should default 
to being SIGSTOPpable except in the case of it being in the process of 
having a specific event delivered.

-- 
Matthew Garrett | mjg59@...f.ucam.org
--
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

Powered by Openwall GNU/*/Linux Powered by OpenVZ