[dm-devel] [PATCH v2] dm-io: deal with wandering queue limits when handling REQ_DISCARD and REQ_WRITE_SAME
Mike Snitzer
snitzer at redhat.com
Fri Feb 27 19:58:26 UTC 2015
On Fri, Feb 27 2015 at 2:09pm -0500,
Mikulas Patocka <mpatocka at redhat.com> wrote:
>
>
> On Fri, 27 Feb 2015, Darrick J. Wong wrote:
>
> > Since it's apparently possible that the queue limits for discard and
> > write same can change while the upper level command is being sliced
> > and diced, fix up both of them (a) to reject IO if the special command
> > is unsupported at the start of the function and (b) read the limits
> > once and let the commands error out on their own if the status happens
> > to change.
> >
> > Signed-off-by: Darrick J. Wong <darrick.wong at oracle.com>
>
> > + unsigned int special_cmd_max_sectors;
> > +
> > + /* Reject unsupported discard and write same requests */
> > + if (rw & REQ_DISCARD)
> > + special_cmd_max_sectors = q->limits.max_discard_sectors;
> > + else if (rw & REQ_WRITE_SAME)
> > + special_cmd_max_sectors = q->limits.max_write_same_sectors;
> > + if ((rw & (REQ_DISCARD | REQ_WRITE_SAME)) &&
> > + special_cmd_max_sectors == 0) {
>
> That results in uninitialized variable warning (although the warning is
> false positive). We need the macro uninitialized_var to suppress the
> warning.
>
> It's better to use ACCESS_ONCE on variables that may be changing so that
> the compiler doesn't load them multiple times.
I dropped the use of ACCESS_ONCE. We access queue_limits all over block
related code. If the performance is quantifiable then all accesses
should be updated. Until then, I'm maintaining status-quo.
Slightly tweaked commit is staged for 4.0 here:
https://git.kernel.org/cgit/linux/kernel/git/device-mapper/linux-dm.git/commit/?h=dm-for-4.0&id=e5db29806b99ce2b2640d2e4d4fcb983cea115c5
More information about the dm-devel
mailing list