From: Tom Yan <tom.ty89@gmail.com>
To: "Martin K. Petersen" <martin.petersen@oracle.com>
Cc: Tejun Heo <tj@kernel.org>,
linux-ide@vger.kernel.org, linux-scsi@vger.kernel.org,
linux-block@vger.kernel.org
Subject: Re: [PATCH v2 2/2] sd: check BLK_DEF_MAX_SECTORS against max_dev_sectors
Date: Sun, 14 Aug 2016 17:00:52 +0800 [thread overview]
Message-ID: <CAGnHSE=yBrBCbyKMNKBpZHRX7YKR-TV-s5YybvTKW18_gcrAbw@mail.gmail.com> (raw)
In-Reply-To: <yq11t1tmzxb.fsf@sermon.lab.mkp.net>
On 13 August 2016 at 05:37, Martin K. Petersen
<martin.petersen@oracle.com> wrote:
>
> It would be pretty unusual for a device that is smart enough to report a
> transfer length limit to be constrained to 1 MB and change.
>
Well, it is done pretty much for libata's SATL. Also since
opt_xfer_blocks is checked against dev_max, I think it makes sense in
logic that we do the equivalence for BLK_DEF_MAX_SECTORS. Not to
mention that since we check rw_max against the controller limit, no
reason not to make sure we check it against the device limit in both
cases.
>
> If you want to fix this please drop the braces and do:
>
> rw_max = min(BLK_DEF_MAX_SECTORS, q->limits.max_dev_sectors);
That won't really work. min_t() would, though the line is gonna be a
bit long; not sure if I can/should simply cast the type (unsigned int)
to BLK_DEF_MAX_SECTORS. And which braces are you referring to?
>
> --
> Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2016-08-14 9:00 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-12 14:27 [PATCH v2 1/2] libata-scsi: use dev->max_sectors from libata-core appropriately tom.ty89
2016-08-12 14:27 ` [PATCH v2 2/2] sd: check BLK_DEF_MAX_SECTORS against max_dev_sectors tom.ty89
2016-08-12 21:37 ` Martin K. Petersen
2016-08-14 9:00 ` Tom Yan [this message]
2016-08-14 9:40 ` Tom Yan
2016-08-16 4:10 ` Martin K. Petersen
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='CAGnHSE=yBrBCbyKMNKBpZHRX7YKR-TV-s5YybvTKW18_gcrAbw@mail.gmail.com' \
--to=tom.ty89@gmail.com \
--cc=linux-block@vger.kernel.org \
--cc=linux-ide@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=martin.petersen@oracle.com \
--cc=tj@kernel.org \
/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.