linux-kernel - RE: [PATCH v15 10/10] usb:dummy_hcd: Force FS device connection according to module parameter

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>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <Pine.LNX.4.44L0.1106071436020.1972-100000@iolanthe.rowland.org>
Date:	Tue, 7 Jun 2011 14:41:43 -0400 (EDT)
From:	Alan Stern <stern@...land.harvard.edu>
To:	Tanya Brokhman <tlinder@...eaurora.org>
cc:	greg@...ah.com, <linux-usb@...r.kernel.org>,
	<linux-arm-msm@...r.kernel.org>, <balbi@...com>,
	<ablay@...eaurora.org>, 'open list' <linux-kernel@...r.kernel.org>
Subject: RE: [PATCH v15 10/10] usb:dummy_hcd: Force FS device connection
 according to module parameter

On Tue, 7 Jun 2011, Tanya Brokhman wrote:

> > > I thought about that as well. Even added it but removed at the last
> > minute
> > > :) I encountered quite a few places in the code where some error
> > message to
> > > the user is really needed but is missing
> > 
> > What other places?  There is very little the user has to do with
> > dummy-hcd -- really nothing more than setting the module parameters.
> 
> I'm not talking about dummy_hcd. It was a general comment about the gadget
> code. I can't give you an example from the top of my head...

Oh.  Well, if you're writing new code and you come across a place where 
an error message really is needed, you should add the error message.

> > IMO the driver should print an error message and fail to load if there
> > are contradictory module parameters.
> > 
> 
> Well, I can add the error message but I think that as far as dummy_hcd is
> concerned failing it's loading is a bit harsh, isn't it? I mean, this is a
> type of user error that can be fixed so why not fix it and just notify the
> user of what was done?

But if the parameters are contradictory, you don't know _how_ to fix 
it.  If is_super_speed is True and is_high_speed is False, did the user 
want to add SuperSpeed support or to remove high-speed support?

Besides, the best (i.e., easiest and most likely to be correct) way of
fixing the error is for the user to issue the modprobe command again,
with the correct parameters this time.  Therefore the driver should
fail to load, so that the modprobe can be reissued with no need to do
rmmod first.

Alan Stern

--
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/