All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bart Van Assche <bart.vanassche@sandisk.com>
To: Hannes Reinecke <hare@suse.com>,
	emilne@redhat.com, Hannes Reinecke <hare@suse.de>
Cc: "Martin K. Petersen" <martin.petersen@oracle.com>,
	James Bottomley <james.bottomley@hansenpartnership.com>,
	linux-scsi@vger.kernel.org, Christoph Hellwig <hch@lst.de>,
	Damien Le Moal <damien.lemoal@hgst.com>
Subject: Re: [PATCH 1/5] sd: configure ZBC devices
Date: Sat, 23 Jul 2016 15:04:15 -0700	[thread overview]
Message-ID: <71c26e2a-98d6-ce14-6147-4b7a29c2cbd5@sandisk.com> (raw)
In-Reply-To: <a3d658d8-ad55-2888-aca5-d30476767526@suse.com>

On 07/23/16 13:31, Hannes Reinecke wrote:
> On 07/22/2016 11:56 PM, Ewan D. Milne wrote:
>> On Tue, 2016-07-19 at 15:25 +0200, Hannes Reinecke wrote:
>>> For ZBC devices I/O must not cross zone boundaries, so setup
>>> the 'chunk_sectors' block queue setting to the zone size.
>>> This is only valid for REPORT ZONES SAME type 2 or 3;
>>> for other types the zone sizes might be different
>>> for individual zones. So issue a warning if the type is
>>> found to be different.
>>> Also the capacity might be different from the announced
>>> capacity, so adjust it as needed.
>>>
>>> Signed-off-by: Hannes Reinecke <hare@suse.com>
>>
>> ...
>>
>>> +static void sd_read_zones(struct scsi_disk *sdkp, unsigned char *buffer)
>>> +{
>>> +	int retval;
>>> +	unsigned char *desc;
>>> +	u32 rep_len;
>>> +	u8 same;
>>> +	u64 zone_len, lba;
>>> +
>>> +	if (sdkp->zoned != 1)
>>> +		/* Device managed, no special handling required */
>>> +		return;
>>> +
>>> +	retval = sd_zbc_report_zones(sdkp, buffer, SD_BUF_SIZE,
>>> +				     0, ZBC_ZONE_REPORTING_OPTION_ALL, false);
>>> +	if (retval < 0)
>>> +		return;
>>> +
>>> +	rep_len = get_unaligned_be32(&buffer[0]);
>>> +	if (rep_len < 64) {
>>> +		sd_printk(KERN_WARNING, sdkp,
>>> +			  "REPORT ZONES report invalid length %u\n",
>>> +			  rep_len);
>>> +		return;
>>> +	}
>>> +
>>> +	if (sdkp->rc_basis == 0) {
>>> +		/* The max_lba field is the capacity of a zoned device */
>>> +		lba = get_unaligned_be64(&buffer[8]);
>>> +		if (lba + 1 > sdkp->capacity) {
>>> +			sd_printk(KERN_WARNING, sdkp,
>>> +				  "Max LBA %zu (capacity %zu)\n",
>>> +				  (sector_t) lba + 1, sdkp->capacity);
>>> +			sdkp->capacity = lba + 1;
>>> +		}
>>> +	}
>>> +
>>> +	/*
>>> +	 * Adjust 'chunk_sectors' to the zone length if the device
>>> +	 * supports equal zone sizes.
>>> +	 */
>>> +	same = buffer[4] & 0xf;
>>> +	if (same == 0 || same > 3) {
>>> +		sd_printk(KERN_WARNING, sdkp,
>>> +			  "REPORT ZONES SAME type %d not supported\n", same);
>>> +		return;
>>> +	}
>>> +	/* Read the zone length from the first zone descriptor */
>>> +	desc = &buffer[64];
>>> +	zone_len = logical_to_sectors(sdkp->device,
>>> +				      get_unaligned_be64(&desc[8]));
>>> +	blk_queue_chunk_sectors(sdkp->disk->queue, zone_len);
>>> +}
>>> +
>>
>> So, blk_queue_chunk_sectors() has:
>>
>> void blk_queue_chunk_sectors(struct request_queue *q, unsigned int chunk_sectors)
>> {
>>         BUG_ON(!is_power_of_2(chunk_sectors));
>>         q->limits.chunk_sectors = chunk_sectors;
>> }
>>
>> and it seems like if some device reports a non-power-of-2 zone_len then we
>> will BUG_ON().  Probably would be better if we reported an error instead?
>>
> The ZBC spec mandates that the zone size must be a power of 2.
> So I don't have problems with triggering a BUG_ON for non-compliant
> drives.

Triggering BUG_ON() if zone_len is not a power of two is completely 
unacceptable. No matter what zone information a ZBC drive exports that 
shouldn't result in a kernel oops.

Bart.

  reply	other threads:[~2016-07-23 22:19 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-19 13:25 [PATCH 0/5] Add support for ZBC host-managed devices Hannes Reinecke
2016-07-19 13:25 ` [PATCH 1/5] sd: configure ZBC devices Hannes Reinecke
2016-07-20  0:46   ` Damien Le Moal
2016-07-22 21:56   ` Ewan D. Milne
2016-07-23 20:31     ` Hannes Reinecke
2016-07-23 22:04       ` Bart Van Assche [this message]
2016-07-24  7:07         ` Hannes Reinecke
2016-07-25  6:00         ` Hannes Reinecke
2016-07-25 13:24           ` Ewan D. Milne
2016-08-01 14:24   ` Shaun Tancheff
2016-08-01 14:29     ` Hannes Reinecke
2016-07-19 13:25 ` [PATCH 2/5] sd: Implement new RESET_WP provisioning mode Hannes Reinecke
2016-07-20  0:49   ` Damien Le Moal
2016-07-20 14:52     ` Hannes Reinecke
2016-07-19 13:25 ` [PATCH 3/5] sd: Implement support for ZBC devices Hannes Reinecke
2016-07-20  0:54   ` Damien Le Moal
2016-08-12  6:00   ` Shaun Tancheff
2016-07-19 13:25 ` [PATCH 4/5] sd: Limit messages for ZBC disks capacity change Hannes Reinecke
2016-07-19 13:25 ` [PATCH 5/5] sd_zbc: Fix handling of ZBC read after write pointer Hannes Reinecke

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=71c26e2a-98d6-ce14-6147-4b7a29c2cbd5@sandisk.com \
    --to=bart.vanassche@sandisk.com \
    --cc=damien.lemoal@hgst.com \
    --cc=emilne@redhat.com \
    --cc=hare@suse.com \
    --cc=hare@suse.de \
    --cc=hch@lst.de \
    --cc=james.bottomley@hansenpartnership.com \
    --cc=linux-scsi@vger.kernel.org \
    --cc=martin.petersen@oracle.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.