From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>
Cc: "jejb@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"steve.magnani@digidescorp.com" <steve.magnani@digidescorp.com>,
"martin.petersen@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"steve@digidescorp.com" <steve@digidescorp.com>
Subject: Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF
Date: Mon, 27 Feb 2017 22:18:28 -0500 [thread overview]
Message-ID: <yq1wpcbvw8r.fsf@oracle.com> (raw)
In-Reply-To: <1488221849.2656.8.camel@sandisk.com> (Bart Van Assche's message of "Mon, 27 Feb 2017 18:57:44 +0000")
>>>>> "Bart" == Bart Van Assche <Bart.VanAssche@sandisk.com> writes:
Bart,
Bart> Sorry but I still don't understand why the two checks are
Bart> different. How about the (untested) patch below? The approach
Bart> below avoids that the check is duplicated and - at least in my
Bart> opinion - results in code that is easier to read.
I'll take a closer look at your patch tomorrow. I am sympathetic to
having a sanity check helper function. That would also give us a single
place to filter out crackpot values reported by USB doodads.
--
Martin K. Petersen Oracle Linux Engineering
WARNING: multiple messages have this Message-ID (diff)
From: "Martin K. Petersen" <martin.petersen@oracle.com>
To: Bart Van Assche <Bart.VanAssche@sandisk.com>
Cc: "jejb\@linux.vnet.ibm.com" <jejb@linux.vnet.ibm.com>,
"steve.magnani\@digidescorp.com" <steve.magnani@digidescorp.com>,
"martin.petersen\@oracle.com" <martin.petersen@oracle.com>,
"linux-scsi\@vger.kernel.org" <linux-scsi@vger.kernel.org>,
"linux-kernel\@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"steve\@digidescorp.com" <steve@digidescorp.com>
Subject: Re: [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF
Date: Mon, 27 Feb 2017 22:18:28 -0500 [thread overview]
Message-ID: <yq1wpcbvw8r.fsf@oracle.com> (raw)
In-Reply-To: <1488221849.2656.8.camel@sandisk.com> (Bart Van Assche's message of "Mon, 27 Feb 2017 18:57:44 +0000")
>>>>> "Bart" == Bart Van Assche <Bart.VanAssche@sandisk.com> writes:
Bart,
Bart> Sorry but I still don't understand why the two checks are
Bart> different. How about the (untested) patch below? The approach
Bart> below avoids that the check is duplicated and - at least in my
Bart> opinion - results in code that is easier to read.
I'll take a closer look at your patch tomorrow. I am sympathetic to
having a sanity check helper function. That would also give us a single
place to filter out crackpot values reported by USB doodads.
--
Martin K. Petersen Oracle Linux Engineering
next prev parent reply other threads:[~2017-02-28 3:21 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-27 15:22 [PATCH] sd: close hole in > 2T device rejection when !CONFIG_LBDAF Steven J. Magnani
2017-02-27 16:13 ` Bart Van Assche
2017-02-27 17:13 ` Steve Magnani
2017-02-27 18:57 ` Bart Van Assche
2017-02-28 3:18 ` Martin K. Petersen [this message]
2017-02-28 3:18 ` Martin K. Petersen
2017-02-28 13:53 ` Steve Magnani
2017-04-04 23:35 ` Martin K. Petersen
2017-04-04 23:35 ` Martin K. Petersen
2017-04-04 23:54 ` Bart Van Assche
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=yq1wpcbvw8r.fsf@oracle.com \
--to=martin.petersen@oracle.com \
--cc=Bart.VanAssche@sandisk.com \
--cc=jejb@linux.vnet.ibm.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-scsi@vger.kernel.org \
--cc=steve.magnani@digidescorp.com \
--cc=steve@digidescorp.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.