Skip to contentSkip to conversation

UAS: Use kzalloc instead of kmalloc

PATCH Applied Luben Tuikov 3 participants 4 messages Oct 27, 2010 – Nov 8, 2010

Subsystems (4)
lore
Share & tools
lore
#0 lore raw

PATCH 1/1 UAS: Use kzalloc instead of kmalloc

"Be conservative in what you send, liberal in what you accept." -- In the spirit of this adage, don't send Command IUs with randomly filled in data in the reserved fields. (Yes, this shows up on the wire.)

---
 drivers/usb/storage/uas.c |    6 +++---
 1 files changed, 3 insertions(+), 3 deletions(-)
drivers/usb/storage/uas.c +3 -3
index 2054b1e..17e1820 100644
@@ -294,7 +294,7 @@ static struct urb *uas_alloc_sense_urb(struct uas_dev_info *devinfo, gfp_t gfp,
 	if (!urb)
 		goto out;
 
-	iu = kmalloc(sizeof(*iu), gfp);
+	iu = kzalloc(sizeof(*iu), gfp);
 	if (!iu)
 		goto free;
 
@@ -325,7 +325,7 @@ static struct urb *uas_alloc_cmd_urb(struct uas_dev_info *devinfo, gfp_t gfp,
 	if (len < 0)
 		len = 0;
 	len = ALIGN(len, 4);
-	iu = kmalloc(sizeof(*iu) + len, gfp);
+	iu = kzalloc(sizeof(*iu) + len, gfp);
 	if (!iu)
 		goto free;
 
@@ -660,7 +660,7 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id)
 			return -ENODEV;
 	}
 
-	devinfo = kmalloc(sizeof(struct uas_dev_info), GFP_KERNEL);
+	devinfo = kzalloc(sizeof(struct uas_dev_info), GFP_KERNEL);
 	if (!devinfo)
 		return -ENOMEM;
 
Signature · 6 lines
1.7.0.1

--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
#1 lore raw
Quoted 5 lines · Luben Tuikov

"Be conservative in what you send, liberal in what you accept." -- In the spirit of this adage, don't send Command IUs with randomly filled in data in the reserved fields. (Yes, this shows up on the wire.)

Applied, with a better changelog entry ...

drivers/usb/storage/uas.c static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id) · line 666

Quoted 9 lines
drivers/usb/storage/uas.c +1 -1
@@ -660,7 +660,7 @@ static int uas_probe(struct usb_interface *intf, const struct usb_device_id *id)
 			return -ENODEV;
 	}
 
-	devinfo = kmalloc(sizeof(struct uas_dev_info), GFP_KERNEL);
+	devinfo = kzalloc(sizeof(struct uas_dev_info), GFP_KERNEL);
 	if (!devinfo)
 		return -ENOMEM;
 

Except for this hunk, which isn't an IU and doesn't go out on the wire.

Applied
#2 lore raw
Quoted 8 lines · Matthew Wilcox
Quoted 5 lines · Luben Tuikov

"Be conservative in what you send, liberal in what you accept." -- In the spirit of this adage, don't send Command IUs with randomly filled in data in the reserved fields. (Yes, this shows up on the wire.)

Applied, with a better changelog entry ...

Applied to where? Shouldn't these patches go into my tree that feeds into linux-next?

We really don't want driver-specific trees floating around anywhere, please push them to me if possible.

thanks,

greg k-h

#3 lore raw
In reply to Matthew Wilcox
Quoted 9 lines · Matthew Wilcox
Quoted 5 lines · Luben Tuikov

"Be conservative in what you send, liberal in what you accept." -- In the spirit of this adage, don't send Command IUs with randomly filled in data in the reserved fields. (Yes, this shows up on the wire.)

Applied, with a better changelog entry ...

"Better"? Where did you apply it? Your willy/uas.git doesn't show it (updated 3 months ago), neither do Greg's.

BTW, is it customary to change the change log? What did you change? Do you mind sharing?

Quoted 9 lines

Review static int uas_probe(struct

Quoted 1 line
(quoted diff) +0 -0
@@ -660,7 +660,7 @@ static int uas_probe(struct

usb_interface *intf, const struct usb_device_id *id)

Quoted 1 line

    return -ENODEV;

Quoted 3 lines

      }

-    devinfo = kmalloc(sizeof(struct

uas_dev_info), GFP_KERNEL);

Quoted 1 line

+    devinfo = kzalloc(sizeof(struct

Quoted 8 lines

uas_dev_info), GFP_KERNEL);

Quoted 2 lines

      if (!devinfo)
          return

-ENOMEM;

Quoted 1 line

Except for this hunk, which isn't an IU and doesn't go out on the wire.

Lol, no of course it doesn't, silly!

So help us understand: You've preserved all changes from kmalloc->kzalloc and left a single kmalloc alone. And your reason is that "*This* one doesn't go out on the wire?"

Wouldn't if have been more consistent (and harmless) to have changed all of them, just as the patch did?

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