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: <200712100413.38077.phillips@phunq.net>
Date:	Mon, 10 Dec 2007 04:13:37 -0800
From:	Daniel Phillips <phillips@...nq.net>
To:	Jens Axboe <jens.axboe@...cle.com>
Cc:	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Peter Zijlstra <peterz@...radead.org>
Subject: Re: [RFC] [PATCH] A clean aEvgeniy pproach to writeout throttling

On Monday 10 December 2007 03:41, Jens Axboe wrote:
> On Mon, Dec 10 2007, Daniel Phillips wrote:
> > +       if (q && q->metric && !bio->bi_queue) {
> >
> > This prevents any reference to bi_bdev after the intial call to
> > generic_make_request.  Thanks to Evgeniy for pointing out the need
> > for this measure on the last go round.
>
> Which saves the initial target, for ease of accounting at end io time
> - that's not the point. What happens when ->make_request_fn() changes
> bio->bi_bdev and returns 1, causing another iteration of the
> __generic_make_request() loop? 'q' is no longer the valid target,
> bdev_get_queue(bio->bi_bdev) is.

What happens on the second iteration of a recursive submission loop is 
exactly nothing, as is right and proper.  The throttling has already 
been done, and all the state necessary to perform the unthrottle was 
recorded in the bio.  Everything seems to be in order there, and the 
algorithm does indeed perform its function as designed, though to be 
sure we have not tested it on -mm branch, only on mainline.

Regards,

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