Re: [PATCH v8 1/2 RESEND] Add bio/request flags to issue ZBC/ZAC commands

2016-08-25 Thread Shaun Tancheff 
On Thu, Aug 25, 2016 at 9:31 PM, Damien Le Moal  wrote:
>
> Shaun,
>
> On 8/25/16 05:24, Shaun Tancheff wrote:
>>
>> (RESENDING to include f2fs, fs-devel and dm-devel)
>>
>> Add op flags to access to zone information as well as open, close
>> and reset zones:
>>   - REQ_OP_ZONE_REPORT - Query zone information (Report zones)
>>   - REQ_OP_ZONE_OPEN - Explicitly open a zone for writing
>>   - REQ_OP_ZONE_CLOSE - Explicitly close a zone
>>   - REQ_OP_ZONE_FINISH - Explicitly finish a zone
>>   - REQ_OP_ZONE_RESET - Reset Write Pointer to start of zone
>>
>> These op flags can be used to create bio's to control zoned devices
>> through the block layer.
>
>
> I still have a hard time seeing the need for the REQ_OP_ZONE_REPORT
> operation assuming that the device queue will hold a zone information cache,
> Hannes RB-tree or your array type, whichever.
>
> Let's try to think simply here: if the disk user (and FS, a device mapper or
> an application doing raw disk accesses) wants to access the disk zone
> information, why would it need to issue a BIO when calling
> blkdev_lookup_zone would exactly give that information straight out of
> memory (so much faster) ? I thought hard about this, but cannot think of any
> value for the BIO-to-disk option. It seems to me to be equivalent to
> systematically doing a page cache read even if the page cache tells us that
> the page is up-to-date...

Firstly the BIO abstraction here gives a common interface to
getting the zone information and works even for embedded
systems that are not willing / convinced to enable
SCSI_ZBC + BLK_ZONED.

Secondly when SCSI_ZBC + BLK_ZONED are enabled it just
returns from the zone cache [as you can hopefully find
in the second half of this series]. I did add a 'force' option
but it's not intended to be used lightly.

Thirdly it is my belief that BIO abstraction is more easily
adapted to working with [and through] the device mapper
layer (s).

Today we both have the issue where if a file system
supports working with a ZBC device there can be no
device mapper stacked between the file system and
the actual zoned device. This is also true of our respective
device mapper targets.

It is my current belief that teaching the device mapper
layer to include REQ_OP_ZONE* operations is relatively
straight forward and can be done w/o affecting existing
targets that don't specifically need to operate on zones.
Something similar to the way flush is handled currently.
If the target doesn't ask to see zone operations the default
mapping rules apply.

Examples of why I would like to add REQ_OP_ZONE*
support to the device mapper:

I think it would be really neat if I could just to a quick
dm-linear and put big chunk of SSD in front of dm-zoned
or dm-zdm as it would be a nice way to boost performance.

Similarly it enable using dm-linear to stitch together enough
conventional space with a ZBC drive to see if Dave Chinner's
XFS proposal from a couple of years ago could work.

> Moreover, issuing a report zone to the disk may return information that is
> in fact incorrect, as that would not take into account the eventual set of
> write requests that was dispatched but not yet processed by the disk (some
> zone write pointer may be reported with a value lower than what the zone
> cache maintains).

Yes but issuing a zone report to media is not the expected path
when the zone cache is available. It is there to 'force' a re-sync
and it is intended that the user of the call knows that the force
is being applied and wants it to happen. Perhaps I should make
it two flags? One to force a reply form the device and second
flag to re-sync the zone cache with the result? There is one
piece of information that can only be retrieved by going to the
device and that is the 'non-seq resources' flag and it is only
used by Host Aware devices ... as far as I understand.

> Dealing (and fixing) these inconsistencies would force an update of the
> report zone result using the information of the zone cache, which in itself
> sounds like a good justification of not doing a report zones in the first
> place.

When report zones is just pulling from the zone cache it should
not be a problem. So the normal activity [when SCSI_ZBC +
BLK_ZONED are enabled] should not be introducing any
inconsistencies.

> I am fine with the other operations, and in fact having a BIO interface for
> them to send down to the SCSI layer is better than any other method. It will
> causes them to be seen in sd_init_command, which is the path taken for read
> and write commands too. So all zone cache information checking and updating
> can be done in that single place and serialized with a spinlock. Maintenance
> of the zone cache information becomes very easy.
>
> Any divergence of the zone cache information with the actual state of the
> disk will likely cause an error (unaligned write or other). Having a
> specific report zone BIO option will not help the disk user recover from
> those. Hannes current implementatio

Re: [PATCH] scsi: not need to alloc zero buffer for local_atto_ioctl

2016-08-25 Thread Martin K. Petersen 
> "Shawn" == Shawn Lin  writes:

Shawn> We don't need to use kzalloc as we will always memset the
Shawn> local_atto_ioctl later.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: don't reinitialize adapter's req_table

2016-08-25 Thread Martin K. Petersen 
> "Shawn" == Shawn Lin  writes:

Shawn> req_table is allocate by kzalloc, so we don't need to zero it
Shawn> again anyway.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH] megaraid_sas: Fix the search of first memory bar

2016-08-25 Thread Sumit Saxena 
>-Original Message-
>From: Christophe JAILLET [mailto:christophe.jail...@wanadoo.fr]
>Sent: Sunday, August 21, 2016 1:58 PM
>To: kashyap.de...@avagotech.com; sumit.sax...@avagotech.com;
>uday.ling...@avagotech.com; j...@linux.vnet.ibm.com;
>martin.peter...@oracle.com
>Cc: megaraidlinux@avagotech.com; linux-scsi@vger.kernel.org; linux-
>ker...@vger.kernel.org; kernel-janit...@vger.kernel.org; Christophe JAILLET
>Subject: [PATCH] megaraid_sas: Fix the search of first memory bar
>
>The 2nd parameter of 'find_first_bit' is the number of bits to search.
>In this case, we are passing 'sizeof(unsigned long)' which is likely to be
>4.
>
>It is likely that the number of bits in a long was expected here, so use
>BITS_PER_LONG instead.
>
>Signed-off-by: Christophe JAILLET 
>---
>Other options are possible:
>  - 'bar_list' being a 'unsigned long', use __ffs to reduce code verbosity
>  - PCI_NUM_RESOURCES, which is the maximum number of bits that can be set
>by 'pci_select_bars()'
>---
> drivers/scsi/megaraid/megaraid_sas_base.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
>diff --git a/drivers/scsi/megaraid/megaraid_sas_base.c
>b/drivers/scsi/megaraid/megaraid_sas_base.c
>index c1ed25adb17e..7d3de811d33c 100644
>--- a/drivers/scsi/megaraid/megaraid_sas_base.c
>+++ b/drivers/scsi/megaraid/megaraid_sas_base.c
>@@ -5036,7 +5036,7 @@ static int megasas_init_fw(struct megasas_instance
>*instance)
>
>   /* Find first memory bar */
>   bar_list = pci_select_bars(instance->pdev, IORESOURCE_MEM);
>-  instance->bar = find_first_bit(&bar_list, sizeof(unsigned long));
>+  instance->bar = find_first_bit(&bar_list, BITS_PER_LONG);
>   if (pci_request_selected_regions(instance->pdev, 1"megasas: LSI")) {
>   dev_printk(KERN_DEBUG, &instance->pdev->dev, "IO memory
>region busy!\n");

Acked by: Sumit Saxena 

>--
>2.7.4
>
>
>---
>L'absence de virus dans ce courrier électronique a été vérifiée par le
>logiciel
>antivirus Avast.
>https://www.avast.com/antivirus
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 1/2] scsi: sg: Avoid overflow when USER_HZ > HZ

2016-08-25 Thread Martin K. Petersen 
> "Paul" == Paul Burton  writes:

Paul> Calculating the maximum timeout that a user can set via the
Paul> SG_SET_TIMEOUT ioctl involves multiplying INT_MAX by
Paul> USER_HZ/HZ. If USER_HZ is larger than HZ then this results in an
Paul> overflow when performed as a 32 bit integer calculation, resulting
Paul> in compiler warnings such as the following:

Doug: Please review.

Thanks!

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 0/2] ibmvfc: FC-TAPE Support

2016-08-25 Thread Martin K. Petersen 
> "Tyrel" == Tyrel Datwyler  writes:

Tyrel> This patchset introduces optional FC-TAPE/FC Class 3 Error
Tyrel> Recovery to the ibmvfc client driver.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] aic94xx: Add missing error code assignment before test

2016-08-25 Thread Martin K. Petersen 
> "Christophe" == Christophe JAILLET  writes:

Christophe> It is likely that checking the result of
Christophe> 'pci_write_config_dword' is expected here.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: core: configure runtime pm before calling device_add in scsi_add_host_with_dma

2016-08-25 Thread Martin K. Petersen 
> "Heiner" == Heiner Kallweit  writes:

Heiner> Runtime PM should be configured already once we call
Heiner> device_add. See also the description in this mail thread
Heiner> 
https://lists.linuxfoundation.org/pipermail/linux-pm/2009-November/023198.html
Heiner> or the order of calls e.g. in usb_new_device.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ipr: Add asynchronous error notification

2016-08-25 Thread Martin K. Petersen 
> "Brian" == Brian King  writes:

Brian> Looks pretty good. I noticed one issue in an error path where you
Brian> weren't removing the new sysfs file. Here is a fixed version.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v2 0/8] hisi_sas internal abort support

2016-08-25 Thread Martin K. Petersen 
> "John" == John Garry  writes:

John> This patchset introduces support for the internal abort feature
John> for the HiSilicon SAS controller.

John> The internal abort feature allows commands which are active in the
John> controller to be aborted before being sent to the slave device.

John> Only support will be added for v2 HW since v1 HW has issues in
John> supporting internal abort feature.

Applied to 4.9/scsi-queue.

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] megaraid_sas: Fix the search of first memory bar

2016-08-25 Thread Martin K. Petersen 
> "Christophe" == Christophe JAILLET  writes:

Christophe> The 2nd parameter of 'find_first_bit' is the number of bits
Christophe> to search.  In this case, we are passing 'sizeof(unsigned
Christophe> long)' which is likely to be 4.

Kashyap? Sumit?

-- 
Martin K. Petersen  Oracle Linux Engineering
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH v8 1/2 RESEND] Add bio/request flags to issue ZBC/ZAC commands

2016-08-25 Thread Damien Le Moal 


Shaun,

On 8/25/16 05:24, Shaun Tancheff wrote:

(RESENDING to include f2fs, fs-devel and dm-devel)

Add op flags to access to zone information as well as open, close
and reset zones:
  - REQ_OP_ZONE_REPORT - Query zone information (Report zones)
  - REQ_OP_ZONE_OPEN - Explicitly open a zone for writing
  - REQ_OP_ZONE_CLOSE - Explicitly close a zone
  - REQ_OP_ZONE_FINISH - Explicitly finish a zone
  - REQ_OP_ZONE_RESET - Reset Write Pointer to start of zone

These op flags can be used to create bio's to control zoned devices
through the block layer.


I still have a hard time seeing the need for the REQ_OP_ZONE_REPORT 
operation assuming that the device queue will hold a zone information 
cache, Hannes RB-tree or your array type, whichever.


Let's try to think simply here: if the disk user (and FS, a device 
mapper or an application doing raw disk accesses) wants to access the 
disk zone information, why would it need to issue a BIO when calling 
blkdev_lookup_zone would exactly give that information straight out of 
memory (so much faster) ? I thought hard about this, but cannot think of 
any value for the BIO-to-disk option. It seems to me to be equivalent to 
systematically doing a page cache read even if the page cache tells us 
that the page is up-to-date...


Moreover, issuing a report zone to the disk may return information that 
is in fact incorrect, as that would not take into account the eventual 
set of write requests that was dispatched but not yet processed by the 
disk (some zone write pointer may be reported with a value lower than 
what the zone cache maintains).


Dealing (and fixing) these inconsistencies would force an update of the 
report zone result using the information of the zone cache, which in 
itself sounds like a good justification of not doing a report zones in 
the first place.


I am fine with the other operations, and in fact having a BIO interface 
for them to send down to the SCSI layer is better than any other method. 
It will causes them to be seen in sd_init_command, which is the path 
taken for read and write commands too. So all zone cache information 
checking and updating can be done in that single place and serialized 
with a spinlock. Maintenance of the zone cache information becomes very 
easy.


Any divergence of the zone cache information with the actual state of 
the disk will likely cause an error (unaligned write or other). Having a 
specific report zone BIO option will not help the disk user recover from 
those. Hannes current implementation make sure that the information of 
the zone for the failed request is automatically updated. That is enough 
to maintain the zone cache information uptodate, and a zone information 
can be marked as "in update" for the user to notice and wait for the 
refreshed information.


The ioctl code for reporting zones does not need the specific request op 
code either. Again, blkdev_lookup_zone can provide zone information, and 
an emulation of the reporting options filtering is also trivial to 
implement on top of that, if really required (I do not think that is 
strongly needed though).


Without the report zone operation, your patch set size would 
significantly shrink and merging with Hannes work becomes very easy too.


Please let me know what you think. If we drop this, we can get a clean 
and full ZBC support patch set ready in no time at all.


Best regards.

--
Damien Le Moal, Ph.D.
Sr. Manager, System Software Group, HGST Research,
HGST, a Western Digital brand
damien.lem...@hgst.com
(+81) 0466-98-3593 (ext. 513593)
1 kirihara-cho, Fujisawa,
Kanagawa, 252-0888 Japan
www.hgst.com
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: not need to alloc zero buffer for local_atto_ioctl

2016-08-25 Thread Bradley Grove 

Acked-by: Bradley Grove 

On 08/20/2016 10:33 PM, Shawn Lin wrote:

We don't need to use kzalloc as we will always memset the
local_atto_ioctl later.

Signed-off-by: Shawn Lin 
---

 drivers/scsi/esas2r/esas2r_main.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/scsi/esas2r/esas2r_main.c 
b/drivers/scsi/esas2r/esas2r_main.c
index 2aca4d1..5092c82 100644
--- a/drivers/scsi/esas2r/esas2r_main.c
+++ b/drivers/scsi/esas2r/esas2r_main.c
@@ -194,7 +194,7 @@ static ssize_t write_hw(struct file *file, struct kobject 
*kobj,
int length = min(sizeof(struct atto_ioctl), count);

if (!a->local_atto_ioctl) {
-   a->local_atto_ioctl = kzalloc(sizeof(struct atto_ioctl),
+   a->local_atto_ioctl = kmalloc(sizeof(struct atto_ioctl),
  GFP_KERNEL);
if (a->local_atto_ioctl == NULL) {
esas2r_log(ESAS2R_LOG_WARN,





This electronic transmission and any attachments hereto are intended only for the use of the individual or entity to which it is addressed and may contain confidential information belonging to ATTO Technology, Inc. If you have reason to believe that you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this electronic transmission is strictly prohibited. If you have reason to believe that you have received this transmission in error, please notify ATTO immediately by return e-mail and delete and destroy this communication.   
--

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] scsi: don't reinitialize adapter's req_table

2016-08-25 Thread Bradley Grove 

Acked-by: Bradley Grove 

On 08/20/2016 10:39 PM, Shawn Lin wrote:

req_table is allocate by kzalloc, so we don't need to
zero it again anyway.

Signed-off-by: Shawn Lin 
---

 drivers/scsi/esas2r/esas2r_init.c | 4 
 1 file changed, 4 deletions(-)

diff --git a/drivers/scsi/esas2r/esas2r_init.c 
b/drivers/scsi/esas2r/esas2r_init.c
index 78ce4d61..d6e53ae 100644
--- a/drivers/scsi/esas2r/esas2r_init.c
+++ b/drivers/scsi/esas2r/esas2r_init.c
@@ -963,10 +963,6 @@ bool esas2r_init_adapter_struct(struct esas2r_adapter *a,

/* initialize the allocated memory */
if (test_bit(AF_FIRST_INIT, &a->flags)) {
-   memset(a->req_table, 0,
-  (num_requests + num_ae_requests +
-   1) * sizeof(struct esas2r_request *));
-
esas2r_targ_db_initialize(a);

/* prime parts of the inbound list */






This electronic transmission and any attachments hereto are intended only for the use of the individual or entity to which it is addressed and may contain confidential information belonging to ATTO Technology, Inc. If you have reason to believe that you are not the intended recipient, you are hereby notified that any disclosure, copying, distribution or the taking of any action in reliance on the contents of this electronic transmission is strictly prohibited. If you have reason to believe that you have received this transmission in error, please notify ATTO immediately by return e-mail and delete and destroy this communication.   
--

To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCHv2] ipr: Add asynchronous error notification

2016-08-25 Thread Gabriel Krisman Bertazi 
Brian King  writes:

> Looks pretty good. I noticed one issue in an error path where you
> weren't removing the new sysfs file. Here is a fixed version.
>

The modifications look good to me.


-- 
Gabriel Krisman Bertazi

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH v2] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-08-25 Thread Zang Leigang 
Some device may cause a compatibility issue while receiving a Query UPIU
with Data Segment which does not expected.

Signed-off-by: Zang Leigang 
---
 drivers/scsi/ufs/ufshcd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a..9b21d88 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1266,9 +1266,12 @@ static void ufshcd_prepare_utp_query_req_upiu(struct 
ufs_hba *hba,
ucd_req_ptr->header.dword_1 = UPIU_HEADER_DWORD(
0, query->request.query_func, 0, 0);
 
-   /* Data segment length */
-   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
-   0, 0, len >> 8, (u8)len);
+   /* Data segment length only need for WRITE_DESC */
+   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE_DESC)
+   ucd_req_ptr->header.dword_2 =
+   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
+   else
+   ucd_req_ptr->header.dword_2 = 0;
 
/* Copy the Query Request buffer as is */
memcpy(&ucd_req_ptr->qr, &query->request.upiu_req,
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-08-25 Thread kbuild test robot 
Hi Zang,

[auto build test ERROR on scsi/for-next]
[also build test ERROR on v4.8-rc3 next-20160824]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]
[Suggest to use git(>=2.9.0) format-patch --base= (or --base=auto for 
convenience) to record what (public, well-known) commit your patch series was 
built on]
[Check https://git-scm.com/docs/git-format-patch for more information]

url:
https://github.com/0day-ci/linux/commits/Zang-Leigang/UFS-Date-Segment-only-need-for-WRITE-DESCRIPTOR/20160825-165332
base:   https://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi.git for-next
config: sparc64-allyesconfig (attached as .config)
compiler: sparc64-linux-gnu-gcc (Debian 5.4.0-6) 5.4.0 20160609
reproduce:
wget 
https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross
 -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=sparc64 

All errors (new ones prefixed by >>):

   drivers/scsi/ufs/ufshcd.c: In function 'ufshcd_prepare_utp_query_req_upiu':
>> drivers/scsi/ufs/ufshcd.c:1270:40: error: 'UPIU_QUERY_OPCODE_WRITE' 
>> undeclared (first use in this function)
 if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE)
   ^
   drivers/scsi/ufs/ufshcd.c:1270:40: note: each undeclared identifier is 
reported only once for each function it appears in

vim +/UPIU_QUERY_OPCODE_WRITE +1270 drivers/scsi/ufs/ufshcd.c

  1264  UPIU_TRANSACTION_QUERY_REQ, upiu_flags,
  1265  lrbp->lun, lrbp->task_tag);
  1266  ucd_req_ptr->header.dword_1 = UPIU_HEADER_DWORD(
  1267  0, query->request.query_func, 0, 0);
  1268  
  1269  /* Data segment length only need for WRITE_DESC */
> 1270  if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE)
  1271  ucd_req_ptr->header.dword_2 =
  1272  UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
  1273  else

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: Binary data

[PATCH] UFS: Date Segment only need for WRITE DESCRIPTOR

2016-08-25 Thread Zang Leigang 
Some device may cause a compatibility issue while receiving a Query UPIU
with Data Segment which does not expected.

Signed-off-by: Zang Leigang 
---
 drivers/scsi/ufs/ufshcd.c | 9 ++---
 1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/drivers/scsi/ufs/ufshcd.c b/drivers/scsi/ufs/ufshcd.c
index f08d41a..7292333 100644
--- a/drivers/scsi/ufs/ufshcd.c
+++ b/drivers/scsi/ufs/ufshcd.c
@@ -1266,9 +1266,12 @@ static void ufshcd_prepare_utp_query_req_upiu(struct 
ufs_hba *hba,
ucd_req_ptr->header.dword_1 = UPIU_HEADER_DWORD(
0, query->request.query_func, 0, 0);
 
-   /* Data segment length */
-   ucd_req_ptr->header.dword_2 = UPIU_HEADER_DWORD(
-   0, 0, len >> 8, (u8)len);
+   /* Data segment length only need for WRITE_DESC */
+   if (query->request.upiu_req.opcode == UPIU_QUERY_OPCODE_WRITE)
+   ucd_req_ptr->header.dword_2 =
+   UPIU_HEADER_DWORD(0, 0, (len >> 8), (u8)len);
+   else
+   ucd_req_ptr->header.dword_2 = 0;
 
/* Copy the Query Request buffer as is */
memcpy(&ucd_req_ptr->qr, &query->request.upiu_req,
-- 
2.9.3

--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH] ata: do not hard code limit in ata_set_lba_range_entries()

2016-08-25 Thread Shaun Tancheff 
Tom,

In my opinion this patch you submitted is simply making the code less
safe against a buffer overflow without a sufficiently good reason.

In future please comment on other patches as replies to those patches.
Mixing them together is just confusing.

--Shaun
--
To unsubscribe from this list: send the line "unsubscribe linux-scsi" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

RE: [PATCH 1/7] aacraid: Use memdup_user() rather than duplicating its implementation

2016-08-25 Thread David Carroll 
> >
> > Hi Markus,
> >
> > Patch 2/7 should precede Patch 1/7, as falling into kfree() would not look
> pretty.
> 
> Do you eventually prefer that this source code adjustment should be combined
> with the update suggestion "[2/7] aacraid: One function call less in
> aac_send_raw_srb() after error detection" in a single update step?
> 

Hi Markus,

My primary objective in this would be the ability to bisect ... The secondary 
would be one issue/patch. I think my preference would be to swap patches 1 and 
2.

Thanks, -Dave