Messages in this thread | | | Date | Fri, 3 Jun 2011 08:39:05 +0200 | From | Jens Axboe <> | Subject | Re: [026/146] block: dont block events on excl write for non-optical |
| |
On 2011-06-03 08:02, Greg KH wrote: > On Wed, Jun 01, 2011 at 11:15:56AM +0200, Jens Axboe wrote: >> On 2011-06-01 10:58, Greg KH wrote: >>> On Wed, Jun 01, 2011 at 05:15:14PM +0900, Tejun Heo wrote: >>>> Hello, Greg. >>>> >>>> On Wed, Jun 01, 2011 at 04:59:22PM +0900, Greg KH wrote: >>>>> 2.6.38-stable review patch. If anyone has any objections, please let us know. >>>>> >>>>> ------------------ >>>>> devices >>>>> >>>>> From: Tejun Heo <tj@kernel.org> >>>>> >>>>> commit d4dc210f69bcb0b4bef5a83b1c323817be89bad1 upstream. >>>>> >>>>> Disk event code automatically blocks events on excl write. This is >>>>> primarily to avoid issuing polling commands while burning is in >>>>> progress. This behavior doesn't fit other types of devices with >>>>> removeable media where polling commands don't have adverse side >>>>> effects and door locking usually doesn't exist. >>>>> >>>>> This patch introduces new genhd flag which controls the auto-blocking >>>>> behavior and uses it to enable auto-blocking only on optical devices. >>>>> >>>>> Note for stable: 2.6.38 and later only >>>> >>>> This one should be accompanied by the following commit which is >>>> currently in Jens' tree and will soon be pulled into Linus' tree. >>>> Sorry about the fuss. ->check_events() update turned out to be much >>>> more fragile than I originally expected. :( >>>> >>>> commit 4c49ff3fe128ca68dabd07537415c419ad7f82f9 >>>> Author: Tejun Heo <tj@kernel.org> >>>> Date: Wed Jun 1 08:27:41 2011 +0200 >>>> >>>> block: blkdev_get() should access ->bd_disk only after success >>> >>> As I can't take it into -stable until it hits Linus's tree, I'll have to >>> wait until then. Hopefully it hits there soon, I'll watch out for it. >>> >>> thanks for letting me know. >> >> It'll go out in the next few days. The above commit also references this >> patch, so you should have proper notification when it goes in. > > Did it go in? I see commit 0f48f2600911d5de6393829e4a9986d4075558b3 > which looks like it might have been it, right? Or do I need something > else for .39-stable?
No, I haven't pushed it out yet, will do today. The above commit is just a merge error fixup.
-- Jens Axboe
| |