linux-kernel - Re: [dm-devel] [PATCH] dm: noflush resizing (0/3)

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]

Date:	Thu, 25 Oct 2007 15:48:33 +0100
From:	Alasdair G Kergon <agk@...hat.com>
To:	device-mapper development <dm-devel@...hat.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: [dm-devel] [PATCH] dm: noflush resizing (0/3)

On Thu, Oct 25, 2007 at 10:18:02AM -0400, Jun'ichi Nomura wrote:
> There is no guarantee that the I/O flowing through the device again.
> The table might need be replaced again, but to do that, the resume
> should have been completed to let the userspace know it.

Then the first attempt to set the size could be made to fail
(because it could not get the lock immediately) and the
size could be set after the second resume instead.

- Setting the size would lag behind the actual size the dm table was
supporting, but (given the usage cases discussed) this would not matter.

> bdget() in noflush suspend has a possibility of stall.

So we cannot avoid fixing that: we require immediate return
with failure instead of waiting.

> OTOH, calling bdget() and i_size_write() outside of the lock
> can cause race with other table swapping and may result in setting
> wrong device size.

If the size setting is removed from the lock, then it becomes
"set the inode size to match the current size of the table" and
races would not matter - each "set size" attempt would set it
to the instantaneous live table size, not a cached value that
could be out-of-date.

Alasdair
-- 
agk@...hat.com
-
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/