Re: [PATCH] staging: unisys: fix visorchipset sysfs attribute functions
On Fri, Jul 25, 2014 at 10:08:06PM +0400, Denis Kirjanov wrote: On 7/25/14, Benjamin Romer benjamin.ro...@unisys.com wrote: This patch cleans up the style, error handling, and string handling in the sysfs functions recently added to visorchipset: Split your changes and send one logical change per patch You can go mad with following rules. In staging we're trying to apply as many patches as we can so we're less picky. I think this patch is ok. In theory you could split this patch up with: 1) Fix the bug. 2) Other cleanups. But in reality the patch doesn't need to be backported so we can allow it. regards, dan carpenter ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] Staging: unisys: Fix code style
On Fri, Jul 25, 2014 at 03:37:41PM +0530, Arjun AK wrote: From 8e7748dd81cf63c62dbef8f102e97da1d4d5d90a Mon Sep 17 00:00:00 2001 From: Arjun AK arjunak...@gmail.com Date: Fri, 25 Jul 2014 15:09:11 +0530 Subject: [PATCH] Staging: unisys: Fix code style Why is all of this here in this message? Fixes code style in multiple files Please break this up into one logical change per patch, and be specific as to what you change. Signed-off-by: Arjun AK arjunak...@gmail.com I need a full name here, sorry. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: fix direct dereferencing of user pointer
Hi Malcolm, On Sat, Jul 26, 2014 at 12:09:49AM +0100, Malcolm Priestley wrote: Hi Guillaume On 25/07/14 13:47, Guillaume Clement wrote: Sparse reported that the data from tagSCmdRequest is given by userspace, so it should be tagged as such. extra is not in user space All right. This is still confusing to me because, taking the SIOCSIWGENIE ioctl as an example, in device_main.c, we have this code: rc = iwctl_siwgenie(dev, NULL, (wrq-u.data), wrq-u.data.pointer); Here the extra parameter is the last one, wrq-u.data.pointer. I was led to believe that wrq-u.data.pointer is in userspace (this was reported by sparse actually) because the pointer field in data is actually defined as __user. I can understand it's not though, if it was pre-processed by another function. Or if that pointer was never given by userspace in the first place (if so, why would it be inside a __user pointer) ? All Wireless Extensions ioctl extra calls originate from ioctl_standard_iw_point in wext-core. Either through ioctl or iw_handler After digging into the code a bit more, I think that there may still be an issue. Are we really going through ioctl_standard_iw_point in this specific case ? In the iwctl_handler definition, we have no handler because of: (iw_handler) NULL, // SIOCSIWGENIE In the wireless_process_ioctl function, the returned handler should be NULL if I understand correctly. I believe we're going through the old API part with ndo_do_ioctl being called, which is consistent with the fact that the code I showed earlier comes from that big switch in device_ioctl in device_main.c. This means we don't go to ioctl_standard_call, that would have called ioctl_standard_iw_point, the function that should have done the copy_from_user. I didn't see a copy_from_user of the pointer field in the paths that I think lead to device_ioctl in device_main.c. Maybe the proper fix should have been to copy the content of wrq-u.data.pointer to some buffer before calling iwctl_siwgenie, and let this function not taking __user data? This way, the driver is still ready to be converted to iw_handler because it keeps the proper signature. All these functions should have been converted to iw_handler. Yes certainly, but with no access to the real hardware for testing, I'd rather not make deep changes like this for now. ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: fix direct dereferencing of user pointer
On Sat, Jul 26, 2014 at 10:24:30AM +0200, Guillaume CLÉMENT wrote:
Hi Malcolm,
On Sat, Jul 26, 2014 at 12:09:49AM +0100, Malcolm Priestley wrote:
Hi Guillaume
On 25/07/14 13:47, Guillaume Clement wrote:
Sparse reported that the data from tagSCmdRequest is given by
userspace, so it should be tagged as such.
extra is not in user space
All right.
This is still confusing to me because, taking the SIOCSIWGENIE ioctl as
an example, in device_main.c, we have this code:
rc = iwctl_siwgenie(dev, NULL, (wrq-u.data), wrq-u.data.pointer);
Here the extra parameter is the last one, wrq-u.data.pointer.
I was led to believe that wrq-u.data.pointer is in userspace (this was
reported by sparse actually) because the pointer field in data is
actually defined as __user.
By the way, the original code (before my patch) reads:
if ((wrq-length 2) || (extra[1]+2 != wrq-length)) {
ret = -EINVAL;
goto out;
}
if (wrq-length MAX_WPA_IE_LEN) {
ret = -ENOMEM;
goto out;
}
memset(pMgmt-abyWPAIE, 0, MAX_WPA_IE_LEN);
if (copy_from_user(pMgmt-abyWPAIE, extra, wrq-length)) {
ret = -EFAULT;
goto out;
}
Note extra[1] and later copy_from_user(x, extra, y).
If extra is not in userspace, we should not call copy_from_user, and if
it is, we should not dereference it. There is definitely something fishy
here.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on sep?
On Fri, 2014-07-25 at 21:54 -0700, Greg KH wrote: On Fri, Jul 25, 2014 at 10:54:47PM +0100, Alan Cox wrote: On Fri, 2014-07-25 at 20:17 +0300, Kristina Martšenko wrote: On 23/06/14 23:32, Kristina Martšenko wrote: Hi Mark, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving sep out of staging in over a year. Are there any plans to clean it up and move it out soon? No response from Mark here. Alan, Jayant, either of you know what the status of the sep staging driver is? I believe works last time anyone checked. I don't think we have anyone officially working on the early Intel phone cpus for upstream any more. So can we just drop it then? If no one is working on moving it out of staging, it should go. Probably ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] staging: vt6655: fix direct dereferencing of user pointer
On 26/07/14 10:18, Guillaume CLÉMENT wrote:
On Sat, Jul 26, 2014 at 10:24:30AM +0200, Guillaume CLÉMENT wrote:
Hi Malcolm,
On Sat, Jul 26, 2014 at 12:09:49AM +0100, Malcolm Priestley wrote:
Hi Guillaume
On 25/07/14 13:47, Guillaume Clement wrote:
Sparse reported that the data from tagSCmdRequest is given by
userspace, so it should be tagged as such.
extra is not in user space
All right.
This is still confusing to me because, taking the SIOCSIWGENIE ioctl as
an example, in device_main.c, we have this code:
rc = iwctl_siwgenie(dev, NULL, (wrq-u.data), wrq-u.data.pointer);
Here the extra parameter is the last one, wrq-u.data.pointer.
I was led to believe that wrq-u.data.pointer is in userspace (this was
reported by sparse actually) because the pointer field in data is
actually defined as __user.
By the way, the original code (before my patch) reads:
if ((wrq-length 2) || (extra[1]+2 != wrq-length)) {
ret = -EINVAL;
goto out;
}
if (wrq-length MAX_WPA_IE_LEN) {
ret = -ENOMEM;
goto out;
}
memset(pMgmt-abyWPAIE, 0, MAX_WPA_IE_LEN);
if (copy_from_user(pMgmt-abyWPAIE, extra, wrq-length)) {
ret = -EFAULT;
goto out;
}
Note extra[1] and later copy_from_user(x, extra, y).
If extra is not in userspace, we should not call copy_from_user, and if
it is, we should not dereference it. There is definitely something fishy
here.
I got it wrong when the iw_handler is not present a standard ioctl is
called extra is in userspace.
Sorry for the noise.
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
-Original Message- From: James Bottomley [mailto:jbottom...@parallels.com] Sent: Friday, July 25, 2014 10:10 AM To: KY Srinivasan Cc: linux-ker...@vger.kernel.org; h...@infradead.org; sits...@gmail.com; de...@linuxdriverproject.org; a...@canonical.com; martin.peter...@oracle.com; linux-s...@vger.kernel.org; oher...@suse.com; gre...@linuxfoundation.org; jasow...@redhat.com Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests On Fri, 2014-07-25 at 16:47 +, KY Srinivasan wrote: -Original Message- From: Martin K. Petersen [mailto:martin.peter...@oracle.com] Sent: Thursday, July 24, 2014 8:54 AM To: Sitsofe Wheeler Cc: Martin K. Petersen; Christoph Hellwig; KY Srinivasan; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; a...@canonical.com; jasow...@redhat.com; jbottom...@parallels.com; linux- s...@vger.kernel.org Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests Sitsofe == Sitsofe Wheeler sits...@gmail.com writes: Sitsofe So we can see it is really a SATA device that announces Sitsofe discard correctly and supports discard through WRITE_SAME(16). No, that's the SATA device that announces support for DSM TRIM, and as a result the Linux SATL reports support for WRITE SAME(16) w. the UNMAP bit set and LBPME. Sitsofe It is the act of passing it through Hyper-V that turned it Sitsofe into a SCSI device that supports UNMAP (but not Sitsofe WRITE_SAME(16)), doesn't announce its SCSI conformance Sitsofe number and doesn't correctly announce which features it Sitsofe supports. Surely in this case it's reasonable to quirk our way around the problem? No. That's an issue in Hyper-V that'll you'll have to take up with Microsoft. I don't know what their passthrough limitations are for SCSI- ATA translation. Maybe K. Y. has some insight into this? For the pass through case, the host validates the request and passes the request to the device. However, not all scsi commands are passed through even though the device it is being passed through may support the command. WRITE_SAME is one such command. Consequently, in the EVPD page, we will set state indicating that WRITE_SAME is not supported (even if the device supports it). I think you haven't appreciated the problem: He's passing a SATA SSD via the SCSI hyper-v interface. That means that the windows host is doing SCSI- ATA translation. The problem is that the Windows translation layer (SATL) looks to be incomplete and it's not correctly translating the IDENTIFY bit that corresponds to TRIM to the correct VPD pages so consequently, Linux won't send UNMAP commands to the device (to be translated back to TRIM). We already know this is a bug in the Windows SATL which needs fixing (if you could report it and get a fix, that would be great) and that we're not going to be able to work around this automatically in Linux because the proposed patch would have us unconditionally try UNMAP for all Hyper-V devices. The current proposed fix is to enable UNMAP manually via sysfs in the guest boot scripts, but obviously that means that Hyper-V guests with direct pass through of SSDs need operator intervention to turn on TRIM. James, Thanks for the clarification. I am talking to the folks in MSFT that develop the native scsi stack on Windows. Hyper-V's back-end driver is not involved in SATL. I will keep you guys posted. Regards, K. Y James ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
-Original Message- From: Martin K. Petersen [mailto:martin.peter...@oracle.com] Sent: Friday, July 25, 2014 9:57 AM To: KY Srinivasan Cc: Martin K. Petersen; Sitsofe Wheeler; Christoph Hellwig; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; a...@canonical.com; jasow...@redhat.com; jbottom...@parallels.com; linux- s...@vger.kernel.org Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests KY == KY Srinivasan k...@microsoft.com writes: KY For the pass through case, the host validates the request and passes KY the request to the device. However, not all scsi commands are KY passed through even though the device it is being passed through may KY support the command. WRITE_SAME is one such command. Consequently, KY in the EVPD page, we will set state indicating that WRITE_SAME is KY not supported (even if the device supports it). The LBP VPD page flags UNMAP as being supported. Do you actually support UNMAP to DSM TRIM SCSI-ATA translation? Martin, I have been told by the Windows folks that this is done. I am trying to get additional details. K. Y One challenge in that department is that a single UNMAP command may turn into many, many, many DSM TRIM commands on the underlying SATA device. That's why we went with WRITE SAME for the internal Linux SATL, capping the maximum number of blocks to what we can fit in a single DSM TRIM command. -- Martin K. PetersenOracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: unisys: include: uisutils.h: Cleaning up missing null-terminate in conjunction with strncpy
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/staging/unisys/include/uisutils.h |8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/unisys/include/uisutils.h
b/drivers/staging/unisys/include/uisutils.h
index 70776c9..14d5cbd 100644
--- a/drivers/staging/unisys/include/uisutils.h
+++ b/drivers/staging/unisys/include/uisutils.h
@@ -307,20 +307,20 @@ Issue_VMCALL_CHANNEL_MISMATCH(const char *ChannelName,
U64 physaddr;
char *last_slash = NULL;
- strncpy(params.ChannelName, ChannelName,
+ strlcpy(params.ChannelName, ChannelName,
lengthof(VMCALL_CHANNEL_VERSION_MISMATCH_PARAMS, ChannelName));
- strncpy(params.ItemName, ItemName,
+ strlcpy(params.ItemName, ItemName,
lengthof(VMCALL_CHANNEL_VERSION_MISMATCH_PARAMS, ItemName));
params.SourceLineNumber = SourceLineNumber;
last_slash = strrchr(path_n_fn, '/');
if (last_slash != NULL) {
last_slash++;
- strncpy(params.SourceFileName, last_slash,
+ strlcpy(params.SourceFileName, last_slash,
lengthof(VMCALL_CHANNEL_VERSION_MISMATCH_PARAMS,
SourceFileName));
} else
- strncpy(params.SourceFileName,
+ strlcpy(params.SourceFileName,
Cannot determine source filename,
lengthof(VMCALL_CHANNEL_VERSION_MISMATCH_PARAMS,
SourceFileName));
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: usbip: stub_main.c: Cleaning up missing null-terminate in conjunction with strncpy
Replacing strncpy with strlcpy to avoid strings that lacks null terminate.
Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se
---
drivers/staging/usbip/stub_main.c | 10 +++---
1 file changed, 3 insertions(+), 7 deletions(-)
diff --git a/drivers/staging/usbip/stub_main.c
b/drivers/staging/usbip/stub_main.c
index 9c5832a..44ab43f 100644
--- a/drivers/staging/usbip/stub_main.c
+++ b/drivers/staging/usbip/stub_main.c
@@ -94,7 +94,7 @@ static int add_match_busid(char *busid)
for (i = 0; i MAX_BUSID; i++)
if (!busid_table[i].name[0]) {
- strncpy(busid_table[i].name, busid, BUSID_SIZE);
+ strlcpy(busid_table[i].name, busid, BUSID_SIZE);
if ((busid_table[i].status != STUB_BUSID_ALLOC)
(busid_table[i].status != STUB_BUSID_REMOV))
busid_table[i].status = STUB_BUSID_ADDED;
@@ -158,15 +158,11 @@ static ssize_t store_match_busid(struct device_driver
*dev, const char *buf,
if (count 5)
return -EINVAL;
- /* strnlen() does not include \0 */
- len = strnlen(buf + 4, BUSID_SIZE);
-
/* busid needs to include \0 termination */
- if (!(len BUSID_SIZE))
+ len = strlcpy(busid, buf + 4, BUSID_SIZE);
+ if (sizeof(busid) = len)
return -EINVAL;
- strncpy(busid, buf + 4, BUSID_SIZE);
-
if (!strncmp(buf, add , 4)) {
if (add_match_busid(busid) 0)
return -ENOMEM;
--
1.7.10.4
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: Anybody working on sep?
On Sat, Jul 26, 2014 at 10:55:11AM +0100, Alan Cox wrote: On Fri, 2014-07-25 at 21:54 -0700, Greg KH wrote: On Fri, Jul 25, 2014 at 10:54:47PM +0100, Alan Cox wrote: On Fri, 2014-07-25 at 20:17 +0300, Kristina Martšenko wrote: On 23/06/14 23:32, Kristina Martšenko wrote: Hi Mark, I'm helping Greg do a bit of cleanup in the staging tree. I noticed that nobody seems to have worked towards moving sep out of staging in over a year. Are there any plans to clean it up and move it out soon? No response from Mark here. Alan, Jayant, either of you know what the status of the sep staging driver is? I believe works last time anyone checked. I don't think we have anyone officially working on the early Intel phone cpus for upstream any more. So can we just drop it then? If no one is working on moving it out of staging, it should go. Probably Wonderful. Kristina, care to make up a patch that removes this? thanks, greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
KY == KY Srinivasan k...@microsoft.com writes: The LBP VPD page flags UNMAP as being supported. Do you actually support UNMAP to DSM TRIM SCSI-ATA translation? KY I have been told by the Windows folks that this is done. I am trying KY to get additional details. Great! I'd just like to have a reasonable level of confidence in what's happening down the stack before I entertain turning something on that's not being properly advertised. -- Martin K. Petersen Oracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
-Original Message- From: Martin K. Petersen [mailto:martin.peter...@oracle.com] Sent: Saturday, July 26, 2014 9:55 AM To: KY Srinivasan Cc: Martin K. Petersen; Sitsofe Wheeler; Christoph Hellwig; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; a...@canonical.com; jasow...@redhat.com; jbottom...@parallels.com; linux- s...@vger.kernel.org Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests KY == KY Srinivasan k...@microsoft.com writes: The LBP VPD page flags UNMAP as being supported. Do you actually support UNMAP to DSM TRIM SCSI-ATA translation? KY I have been told by the Windows folks that this is done. I am trying KY to get additional details. Great! I'd just like to have a reasonable level of confidence in what's happening down the stack before I entertain turning something on that's not being properly advertised. As I look at the output of inquiry between Linux on Hyper-V and native Linux, is not specifying conformance level the main issue? K. Y -- Martin K. PetersenOracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
KY == KY Srinivasan k...@microsoft.com writes: Great! I'd just like to have a reasonable level of confidence in what's happening down the stack before I entertain turning something on that's not being properly advertised. KY As I look at the output of inquiry between Linux on Hyper-V and KY native Linux, is not specifying conformance level the main issue? The main problem for this particular use case (aside from the issue we've already addressed) is that the passthrough device (SATA SSD) has LBPME=0 in the READ CAPACITY(16) response. The LBP VPD is correctly provided with LBPU flag set but because LBPME is reported as disabled we will not attempt to issue UNMAP commands to the device. -- Martin K. Petersen Oracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] wlan-ng:prism2sta: Changes reporting format to meet checkpatch.pl
From: Santiago Torres torresari...@gmail.com
[linux-next]: Make the format strings for netdev_err shorter so they can
fit under the 80 column width requirement.
To achieve this, the result= was stripped down to an implicit version
(i.e. result=%d to (%d)). This allows the whole string to fit inside the
80 column limit to pass some of the checkpatch.pl requirements.
While the error message is not as explicit as it used to be, it
shouldn't affect readability; specially since it is the only formatted
value printed to the log.
Signed-off by: Santiago Torres-Arias torresari...@gmail.com
---
drivers/staging/wlan-ng/prism2sta.c | 12
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/drivers/staging/wlan-ng/prism2sta.c
b/drivers/staging/wlan-ng/prism2sta.c
index 799ce8a..f05f142 100644
--- a/drivers/staging/wlan-ng/prism2sta.c
+++ b/drivers/staging/wlan-ng/prism2sta.c
@@ -453,7 +453,8 @@ u32 prism2sta_ifstate(wlandevice_t *wlandev, u32 ifstate)
result = hfa384x_drvr_start(hw);
if (result) {
netdev_err(wlandev-netdev,
- hfa384x_drvr_start()
failed,result=%d\n, (int)result);
+ hfa384x_drvr_start() failed (%d)\n,
+ (int)result);
result =
P80211ENUM_resultcode_implementation_failure;
wlandev-msdstate = WLAN_MSD_HWPRESENT;
@@ -496,7 +497,8 @@ u32 prism2sta_ifstate(wlandevice_t *wlandev, u32 ifstate)
result = hfa384x_drvr_start(hw);
if (result) {
netdev_err(wlandev-netdev,
- hfa384x_drvr_start()
failed,result=%d\n, (int)result);
+ hfa384x_drvr_start() failed (%d)\n,
+ (int)result);
result =
P80211ENUM_resultcode_implementation_failure;
wlandev-msdstate = WLAN_MSD_HWPRESENT;
@@ -506,7 +508,8 @@ u32 prism2sta_ifstate(wlandevice_t *wlandev, u32 ifstate)
result = prism2sta_getcardinfo(wlandev);
if (result) {
netdev_err(wlandev-netdev,
- prism2sta_getcardinfo()
failed,result=%d\n, (int)result);
+ prism2sta_getcardinfo() failed (%d)\n,
+ (int)result);
result =
P80211ENUM_resultcode_implementation_failure;
hfa384x_drvr_stop(hw);
@@ -516,7 +519,8 @@ u32 prism2sta_ifstate(wlandevice_t *wlandev, u32 ifstate)
result = prism2sta_globalsetup(wlandev);
if (result) {
netdev_err(wlandev-netdev,
- prism2sta_globalsetup()
failed,result=%d\n, (int)result);
+ prism2sta_globalsetup() failed (%d)\n,
+ (int)result);
result =
P80211ENUM_resultcode_implementation_failure;
hfa384x_drvr_stop(hw);
--
1.7.9.5
___
devel mailing list
de...@linuxdriverproject.org
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
Re: [PATCH] wlan-ng:prism2sta: Changes reporting format to meet checkpatch.pl
On Sat, Jul 26, 2014 at 04:09:24PM -0400, torresari...@gmail.com wrote: From: Santiago Torres torresari...@gmail.com [linux-next]: Make the format strings for netdev_err shorter so they can fit under the 80 column width requirement. We do not have that requirement for strings at all, so no need to make this change. greg k-h ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
[PATCH] staging: ced1401: userspace: use1401.c: Cleaning up missing null-terminate in conjunction with strncpy
Replacing strncpy with strlcpy to avoid strings that lacks null terminate. And replacing strncat with strlcat because of incorrect use. Signed-off-by: Rickard Strandqvist rickard_strandqv...@spectrumdigital.se --- drivers/staging/ced1401/userspace/use1401.c | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/drivers/staging/ced1401/userspace/use1401.c b/drivers/staging/ced1401/userspace/use1401.c index 7b8a222..2d15df8 100644 --- a/drivers/staging/ced1401/userspace/use1401.c +++ b/drivers/staging/ced1401/userspace/use1401.c @@ -693,7 +693,7 @@ U14API(short) U14DriverName(short hand, char* pBuf, unsigned short wMax) case 3: pName = HSS; break; default: pName = ???; break; } -strncpy(pBuf, pName, wMax);// Copy the correct name to return +strlcpy(pBuf, pName, wMax);/* Copy the correct name to return */ return U14ERR_NOERROR; } @@ -1079,7 +1079,7 @@ U14API(short) U14NameOf1401(short hand, char* pBuf, unsigned short wMax) case U14TYPEPOWER3:pName = Power1401-3; break; default: pName = Unknown; } -strncpy(pBuf, pName, wMax); +strlcpy(pBuf, pName, wMax); } return sErr; } @@ -2891,10 +2891,10 @@ U14API(unsigned int) U14Ld(short hand, const char* vl, const char* str) ++dwIndex; // Keep count of command number, first is 1 szFName[iLoop2]=(char)0;// null terminate name of command -strncpy(szLastName, szFName, sizeof(szLastName));// Save for error info -szLastName[sizeof(szLastName)-1] = 0; -strncat(szLastName, szFExt, sizeof(szLastName)); // with extension included -szLastName[sizeof(szLastName)-1] = 0; +/* Save for error info */ +strlcpy(szLastName, szFName, sizeof(szLastName)); +/* with extension included */ +strlcat(szLastName, szFExt, sizeof(szLastName)); U14SendString(hand, szFName); // ask if loaded U14SendString(hand, ;ERR;); // add err return -- 1.7.10.4 ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
RE: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests
-Original Message- From: Martin K. Petersen [mailto:martin.peter...@oracle.com] Sent: Saturday, July 26, 2014 12:25 PM To: KY Srinivasan Cc: Martin K. Petersen; Sitsofe Wheeler; Christoph Hellwig; gre...@linuxfoundation.org; linux-ker...@vger.kernel.org; de...@linuxdriverproject.org; oher...@suse.com; a...@canonical.com; jasow...@redhat.com; jbottom...@parallels.com; linux- s...@vger.kernel.org Subject: Re: [PATCH v2 3/3] [SCSI] Make LBP quirk skip lbpme checks tests KY == KY Srinivasan k...@microsoft.com writes: Great! I'd just like to have a reasonable level of confidence in what's happening down the stack before I entertain turning something on that's not being properly advertised. KY As I look at the output of inquiry between Linux on Hyper-V and KY native Linux, is not specifying conformance level the main issue? The main problem for this particular use case (aside from the issue we've already addressed) is that the passthrough device (SATA SSD) has LBPME=0 in the READ CAPACITY(16) response. The LBP VPD is correctly provided with LBPU flag set but because LBPME is reported as disabled we will not attempt to issue UNMAP commands to the device. Oh; ok. I missed the read_capacity response. Thanks, K. Y -- Martin K. PetersenOracle Linux Engineering ___ devel mailing list de...@linuxdriverproject.org http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
