linux-kernel - Re: [PATCH 1/2] Add partition resize function to BLKPG ioctl

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:	Mon, 30 Jan 2012 10:49:35 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Phillip Susi <psusi@...ntu.com>
Cc:	Maxim Patlasov <maxim.patlasov@...il.com>, joe@...ches.com,
	kzak@...hat.com, linux-kernel@...r.kernel.org, jaxboe@...ionio.com
Subject: Re: [PATCH 1/2] Add partition resize function to BLKPG ioctl

On Thu, Jan 26, 2012 at 04:48:06PM -0500, Phillip Susi wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On 1/26/2012 4:04 PM, Vivek Goyal wrote:
> >> Another idea that I had but have not yet checked to see if it is
> >>  actually feasible is to copy the struct genhd, change the size
> >> of the copy, and replace the existing one since updating the
> >> pointer will be atomic.
> > 
> > You will run into issues if somebody has a pointer stored to 
> > genhd.
> 
> They are already kept in an RCU list which has the same problem.

Yes, using rcu is one option.

> Doesn't that deal with it by using reference counters, so the reader
> can keep and use the pointer to the old structure just fine, and it
> will be cleaned up when they release the reference.

Then reader needs to take reference count before every read and that
makes it heavy weight solution for reader.

Sequence counter keeps it lightweight for reader in fast path.

> 
> > I think simpler thing would be to stick with sequence counter 
> > approach which keeps read side lockless. We can fix other writers 
> > of nr_sects over a period of time. If nobody has complained so
> > far, that means we don't run into issues frequently and it is not a
> > huge concern.
> 
> So you think the patch is fine the way it is?

If you can fix other use cases now, it would be good. Otherwise, I think
we can leave a big fat comment in the code and if somebody runs into
issues, we can go fix the individiual cases then.

As we are not introducing any new races, I will not be too concerned
about that.

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