linux-kernel - Re: [PATCH] [USB] UAS: Use kzalloc instead of kmalloc

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 8 Nov 2010 09:50:15 -0800 (PST)
From:	Luben Tuikov <ltuikov@...oo.com>
To:	Matthew Wilcox <willy@...ux.intel.com>
Cc:	Greg KH <greg@...ah.com>, linux-usb@...r.kernel.org,
	linux-kernel@...r.kernel.org, linux-scsi@...r.kernel.org
Subject: Re: [PATCH] [USB] UAS: Use kzalloc instead of kmalloc

--- On Mon, 11/8/10, Luben Tuikov <ltuikov@...oo.com> wrote:
> --- On Mon, 11/8/10, Matthew Wilcox
> <willy@...ux.intel.com>
> wrote:
> > On Wed, Oct 27, 2010 at 01:22:22PM
> > -0700, Luben Tuikov wrote:
> > > "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?

Matthew, could you reply-all here with your new, changed and
modified change log?

I'd like you to be accountable to what and how you've changed the changelog HERE and not in a git three somewhere and have an open comparison to what your new change log is and what is says.

Mine, quoted above:
  a) mentions an adage that's been around for 30 years at least,
     in the UNIX/net field to which we adhere.
  b) mentions (only!) the Command IU of making out on the wire
     with stale system data of the memory used for it.

Could you please reconsider your professional integrity and
submit the patch as is with the original log?

> > > @@ -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.
> 
> Lol, no of course it doesn't, silly!

And notice that /my/ change log doesn't claim that 
uas_dev_info makes it out the wire. It only mentions that
the Command IU makes it out the wire with stale data.

> 
> 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-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/