All of lore.kernel.org
 help / color / mirror / Atom feed
From: Jens Axboe <jaxboe@fusionio.com>
To: Linus Torvalds <torvalds@linux-foundation.org>
Cc: "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>
Subject: Re: [GIT PULL] One important block fix for 2.6.36-rc
Date: Sun, 26 Sep 2010 12:21:52 +0900	[thread overview]
Message-ID: <4C9EBC50.3080201@fusionio.com> (raw)
In-Reply-To: <AANLkTikcR8fu11jyLcD3Fuvm4TPxU=46jLcpsYryHONP@mail.gmail.com>

On 2010-09-26 01:59, Linus Torvalds wrote:
> On Sat, Sep 25, 2010 at 3:45 AM, Jens Axboe <jaxboe@fusionio.com> wrote:
>>
>> Please pull asap, thanks.
> 
> Pulled, but I _really_ wish you started looking at cleanliness issues,
> even with bug-reports.
> 
> That's a singularly stupid and unreadable way of testing "do those
> flags match". It is quite possible that the compiler fixes up the
> stupidity, but that doesn't make it much better.
> 
> Here's how things like this _should_ be tested:
> 
>    #define REQ_FLAGS_MUST_MATCH (REQ_SECURE | REQ_DISCARD)
> 
>    ...
>    /* Check that flags match in the required bits */
>    if ((req->cmd_flags ^ next->cmd_flags) & REQ_FLAGS_MUST_MATCH)
>       return 0;
>    ...
> 
> which is (a) smaller (b) easier and clearer to add flags as needed and
> (c) actually more readable due to not having duplicated logic (not
> just one if-statement, but one mask too).

Completely agree, I will clean this up for the .37. Since we are very
late in the rc cycle, I prefer obvious patches greatly. Especially
for something like this, which could cause data corruption.

> And yes, I think you'd want to add a few flags there. Looking at the
> REQ_xyz flags, I suspect most o them should really really match for
> requests to be mergeable. Wouldn't it be better to think of it in
> terms of "do we really allow different cmd_flags requests to merge"
> than adding one bit ad-hoc at a time?

The above bits and the failfast bits at least should disallow merging,
and the direction bit as well. So yes, I think we should add an
explicit mask for this.

-- 
Jens Axboe


      reply	other threads:[~2010-09-26  3:21 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-09-25 10:45 [GIT PULL] One important block fix for 2.6.36-rc Jens Axboe
2010-09-25 16:59 ` Linus Torvalds
2010-09-26  3:21   ` Jens Axboe [this message]

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=4C9EBC50.3080201@fusionio.com \
    --to=jaxboe@fusionio.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=torvalds@linux-foundation.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.