linux-kernel - Re: [PATCH] [RFC] make hd_struct->in_flight atomic to avoid diskstat corruption

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] [day] [month] [year] [list]

Date:	Tue, 21 Apr 2009 09:31:50 +0200
From:	Jens Axboe <jens.axboe@...cle.com>
To:	Tejun Heo <tj@...nel.org>
Cc:	Nikanth Karthikesan <knikanth@...e.de>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] [RFC] make hd_struct->in_flight atomic to avoid
	diskstat   corruption

On Sun, Apr 19 2009, Tejun Heo wrote:
> Hello,
> 
> Jens Axboe wrote:
> > On Thu, Apr 16 2009, Tejun Heo wrote:
> >> Hello, Nikanth, Jens.
> >>
> >> Nikanth Karthikesan wrote:
> >>>> Hmm. Did you observe this behaviour?
> >>> Sorry, not on current kernels. But on a very old 2.6.5 kernel.
> >>>
> >>> Reading Documentation/iostats.txt and the changelog of commit 
> >>> e71bf0d0ee89e51b92776391c5634938236977d5 made me assume that this could be a 
> >>> problem even today.
> >> The only problem we can run into there is if a request doesn't get
> >> attributed to a partition on issue but gets attributed to a partition
> >> on completion, which seems to be possible if a new partition is added
> >> while IO on the whole device which fell into the new partition area is
> >> already in progress, which, on the first glance, seems possible if the
> >> admin tries really hard.  I think we can get around the problem by
> >> doing part->in_flight = min(max(new_val, part0->in_flight), 0) in
> >> dec_in_flight().  This is pretty extreme corner case tho.
> > 
> > Heh, that is pretty extreme. I'd prefer just quiescing the queue,
> > perhaps we should do that for partition map swaps.
> 
> Yeah, I think that would be the better approach for swapping ptbl.
> RCU isn't really necessary there.

I think so, it definitely makes more sense to make the swap operation
heavier if we can make the read side free. Doesn't make much sense to
optimize for swapping partition tables ;)

-- 
Jens Axboe

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