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

Message-ID: <20120126190114.GG1891@redhat.com>
Date:	Thu, 26 Jan 2012 14:01:14 -0500
From:	Vivek Goyal <vgoyal@...hat.com>
To:	Phillip Susi <psusi@....rr.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, Dec 29, 2011 at 07:09:17PM -0500, Phillip Susi wrote:

[..]
> > Btw, do we really need both part_nr_sects_write_begin and
> > part_nr_sects_write_end? What about:
> 
> Good points.  I also noticed that the read/write functions were only being called when not holding the mutex.  If anyone is touching nr_sects without the mutex, then everyone must use the read/write functions, whether they hold the mutex or not.  Otherwise, a mutex holder that touches it directly will race with a non mutex holder using the seqcounter.

Sorry for a very late reply. I was on vacation.

I thought update will always happen with mutex lock held. That's what
sequence counter expects so that two updaters don't race. Just that while
updating under mutex lock, we still need to use sequence counter mecahinsm
to update values so that any readers out there not holding mutex don't
get confused.

Did I miss some code where nr_sects is being read without mutex and I
have not use sequence counter version to read it?

> Vivek, rather than fix the rest of the references to nr_sects to use the read/write functions, why not just fix the few sites that were accessing it without the mutex to take the mutex fist instead of using a seqcounter?

Right now readers can afford not to take lock. Introducing mutex on read
side with just add to the cost. Especially IO submission path where we
map IO to a partitiona and we wouldn't want to take mutexes there?

Are you still pursuing this pathset? Sounds like a useful functionality
to have.

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/