From: Stefan Haberland <sth@linux.vnet.ibm.com>
To: hch@infradead.org, damien.lemoal@wdc.com, axboe@kernel.dk,
linux-block@vger.kernel.org, linux-kernel@vger.kernel.org
Cc: hoeppner@linux.vnet.ibm.com, sebott@linux.vnet.ibm.com
Subject: Re: [RFC] block: check partition alignment
Date: Mon, 19 Dec 2016 17:15:49 +0100 [thread overview]
Message-ID: <20161219161550.55414-1-sth@linux.vnet.ibm.com> (raw)
In-Reply-To: <88308b2d-de52-b97a-2001-96da7e9f5d1f@wdc.com>
Am 14.12.2016 um 18:07 schrieb Christoph Hellwig:
>> To prevent partitions that are not aligned to the physical blocksize
>> > of a device check for the alignment in the blkpg_ioctl.
> We'd also need to reject this when reading partitions from disk, right?
>
I am not sure if there is a problem. I was not able to recreate the error
with a partition read from disk. But simply because I was not able to
write a defective partition table to disk. All variants I tried where OK.
So I am at least not aware of a way to break it via the partition
detection code.
I just noticed that the ioctl which can be called by anyone is
able to establish defective partitions.
Am 15.12.2016 um 09:56 schrieb Damien Le Moal:
> On 12/15/16 17:45, Christoph Hellwig wrote:
>> On Thu, Dec 15, 2016 at 10:33:47AM +0900, Damien Le Moal wrote:
>>> For a regular block device, I agree. But in Stephan case, I think that
>>> the check really needs to be against the physical block size, with the
>>> added condition that the bdev is a DASD device (similarly to the zone
>>> alignment check for zoned block devices).
>>
>> Then they need to expose a chunk_size. physical block size is defined
>> as not having a meaning for the kernel.
>
> Or create the block device with the logical block size set to the
> physical sector size. Which would be even more simple and in fact
> correct in this case since only physically aligned accesses make sense
> for DASD.
>
We already do it this way. So the logical blocksize is fine for DASD.
I just was not aware of the fact that the physical blocksize is a
best_can_do field. So I changed it this way and also incorporated your
other feedback regarding the modulo. Here is the second suggestion for
the patch.
Stefan Haberland (1):
block: check partition alignment
block/ioctl.c | 3 +++
1 file changed, 3 insertions(+)
--
2.8.4
next prev parent reply other threads:[~2016-12-19 16:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-12-14 16:47 [RFC] block: check partition alignment Stefan Haberland
2016-12-14 17:07 ` Christoph Hellwig
2016-12-15 1:33 ` Damien Le Moal
2016-12-15 8:45 ` Christoph Hellwig
2016-12-15 8:56 ` Damien Le Moal
2016-12-19 16:15 ` Stefan Haberland [this message]
2016-12-19 16:15 ` [v2] " Stefan Haberland
2016-12-19 16:18 ` Christoph Hellwig
2016-12-15 0:29 ` [RFC] " Damien Le Moal
2016-12-15 0:55 ` Damien Le Moal
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20161219161550.55414-1-sth@linux.vnet.ibm.com \
--to=sth@linux.vnet.ibm.com \
--cc=axboe@kernel.dk \
--cc=damien.lemoal@wdc.com \
--cc=hch@infradead.org \
--cc=hoeppner@linux.vnet.ibm.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=sebott@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox