netdev - Re: softirqs are invoked while bottom halves are masked

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: <CAAXf6LXddZUHEz738DDTi-XqENRYT7dTODw+1C4RTYsCdyro7g@mail.gmail.com>
Date:	Wed, 13 Jul 2011 09:20:47 +0200
From:	Thomas De Schampheleire <patrickdepinguin+linuxppc@...il.com>
To:	David Miller <davem@...emloft.net>
Cc:	ronny.meeus@...il.com, eric.dumazet@...il.com,
	linuxppc-dev@...abs.org, netdev@...r.kernel.org,
	afleming@...escale.com
Subject: Re: softirqs are invoked while bottom halves are masked

On Tue, Jul 12, 2011 at 2:13 PM, David Miller <davem@...emloft.net> wrote:
> From: David Miller <davem@...emloft.net>
> Date: Tue, 12 Jul 2011 05:08:17 -0700 (PDT)
>
>> From: Ronny Meeus <ronny.meeus@...il.com>
>> Date: Tue, 12 Jul 2011 14:03:04 +0200
>>
>>> but we still see the issue "BUG: sleeping function called from invalid context":
>>>
>>> [   91.015989] BUG: sleeping function called from invalid context at
>>> include/linux/skbuff.h:786
>>> [   91.117096] in_atomic(): 1, irqs_disabled(): 0, pid: 1865, name: NMTX_T1842
>>> [   91.200461] Call Trace:
>>> [   91.229672] [ec58bbd0] [c000789c] show_stack+0x78/0x18c (unreliable)
>>> [   91.305791] [ec58bc10] [c0022900] __might_sleep+0x100/0x118
>>> [   91.372524] [ec58bc20] [c029f8d8] dpa_tx+0x128/0x758
>>
>> Because this dpa driver's transmit method is doing something else that
>> is not allowed in software interrupt context.
>>
>> You must remove all things that might sleep in this driver's
>> ->ndo_start_xmit method, and I do mean everything.
>
> Also this whole HW QOS feature bit facility is beyond bogus.
>
> What if the user enables a qdisc that the hardware can't handle, or a
> configuration of a hw supported qdisc that the hardware can't support?
>
> What if I have packet classification and packet actions enabled in the
> packet scheduler?
>
> These changes are terrible, and we really need you guys to sort out
> your problems with these changes yoursleves because your wounds are
> entirely self-inflicted and totally not our problem.
>

Of course, you make very valid points.

I just want to mention that, although you seem to think that we
shouldn't have created this thread in the first place, your and Eric's
remarks have actually helped us in identifying the problem and
increasing our understanding.

So, thanks for that.

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