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:	Fri, 26 Jan 2007 09:00:12 +0100
From:	Peter Zijlstra <a.p.zijlstra@...llo.nl>
To:	Andrew Morton <akpm@...l.org>
Cc:	Trond Myklebust <trond.myklebust@....uio.no>,
	Christoph Lameter <clameter@....com>,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, pj@....com
Subject: Re: [PATCH] nfs: fix congestion control -v4

On Thu, 2007-01-25 at 21:02 -0800, Andrew Morton wrote:
> On Thu, 25 Jan 2007 16:32:28 +0100
> Peter Zijlstra <a.p.zijlstra@...llo.nl> wrote:
> 
> > +long congestion_wait_interruptible(int rw, long timeout)
> > +{
> > +	long ret;
> > +	DEFINE_WAIT(wait);
> > +	wait_queue_head_t *wqh = &congestion_wqh[rw];
> > +
> > +	prepare_to_wait(wqh, &wait, TASK_INTERRUPTIBLE);
> > +	if (signal_pending(current))
> > +		ret = -ERESTARTSYS;
> > +	else
> > +		ret = io_schedule_timeout(timeout);
> > +	finish_wait(wqh, &wait);
> > +	return ret;
> > +}
> > +EXPORT_SYMBOL(congestion_wait_interruptible);
> 
> I think this can share code with congestion_wait()?
> 
> static long __congestion_wait(int rw, long timeout, int state)
> {
> 	long ret;
> 	DEFINE_WAIT(wait);
> 	wait_queue_head_t *wqh = &congestion_wqh[rw];
> 
> 	prepare_to_wait(wqh, &wait, state);
> 	ret = io_schedule_timeout(timeout);
> 	finish_wait(wqh, &wait);
> 	return ret;
> }
> 
> long congestion_wait_interruptible(int rw, long timeout)
> {
> 	long ret = __congestion_wait(rw, timeout);
> 
> 	if (signal_pending(current))
> 		ret = -ERESTARTSYS;
> 	return ret;
> }
> 
> it's only infinitesimally less efficient..

All the other _interruptible functions check signal_pending before
calling schedule. Which seems to make sense since its called in a loop
anyway, and if the loop condition turns false when interrupted you might
as well just finish up instead of bailing out.

However if you'd rather see your version, who am I to object ;-)

-
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