netdev - Re: [PATCH] qmi_wwan/cdc_ether: add device IDs for Dell 5804 (Novatel E371) WWAN card

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

Message-ID: <CAO2Qn5kRZ+Cmnavw_8NKPw48NPw_9-bBAtOgWeopAB=EgzqNLw@mail.gmail.com>
Date:	Wed, 8 May 2013 14:27:37 -0500
From:	dag dg <dagofthedofg@...il.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	David Miller <davem@...emloft.net>,
	Bjørn Mork <bjorn@...k.no>,
	Network Development <netdev@...r.kernel.org>,
	stable@...r.kernel.org
Subject: Re: [PATCH] qmi_wwan/cdc_ether: add device IDs for Dell 5804 (Novatel
 E371) WWAN card

cool, just wanted to make sure. When I set up a startup script to load
up the option driver I freaked when my machine locked up. Good to know
you have this covered, looking forward to seeing it implemented down
the road. Thanks.

On Wed, May 8, 2013 at 2:25 PM, Dan Williams <dcbw@...hat.com> wrote:
> On Wed, 2013-05-08 at 12:19 -0700, David Miller wrote:
>> From: dag dg <dagofthedofg@...il.com>
>> Date: Wed, 8 May 2013 14:11:48 -0500
>>
>> > Just a side note on this. By default for this device, modprobe won't
>> > load and assign the option driver. However, if cdc_ether is
>> > blacklisted and you try to load option onto the device, it will try to
>> > load the option driver onto where cdc_ether was being used, which will
>> > cause the system to lock up. I'm not sure what needs to be done to
>> > force qmi_wwan to take over cdc_ether without option grabbing these
>> > IDs...
>
> This is a consequence of "new_id" not being flexible enough to handle
> class/subclass/protocol in addition to USB IDs.  Thus when you use it,
> the driver binds to *all* USB interfaces, even ones that the driver
> shouldn't ever control
>
> So the issue you refer to is actually user error, helped by a
> too-coarse-grained kernel API.  It's not an issue when things are all
> done correctly, which is to say when the USB IDs and interface
> class/subclass/protocol are properly added to the kernel drivers.
>
> The option patch I posted earlier will fix this issue correctly.
>
> Dan
>
>
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html