On sam., 2016-02-27 at 18:10 -0800, Peter Hurley wrote:

On 02/27/2016 05:59 PM, Eric Dumazet wrote:

quoted

On sam., 2016-02-27 at 15:33 -0800, Peter Hurley wrote:

quoted

On 02/27/2016 03:04 PM, David Miller wrote:

quoted

From: Peter Hurley <redacted>
Date: Sat, 27 Feb 2016 12:29:39 -0800

quoted

Not really. softirq raised from interrupt context will always execute
on this cpu and not in ksoftirqd, unless load forces softirq loop abort.

That guarantee never was specified.

??

Neither is running network socket servers at normal priority as if they're
higher priority than softirq.

quoted

Or are you saying that by design, on a system under load, your UART
will not function properly?

Surely you don't mean that.

No, that's not what I mean.

What I mean is that bypassing the entire SOFTIRQ priority so that
sshd can process one network packet makes a mockery of the point of softirq.

This hack to workaround NET_RX looping over-and-over-and-over affects every
subsystem, not just one uart.

HI, TIMER, BLOCK; all of these are skipped: that's straight-up, a bug.

No idea what you talk about.

All pending softirq interrupts are processed. _Nothing_ is skipped.

An interrupt that schedules HI softirq while in NET_RX softirq should
still run the HI softirq. But with your patch that won't happen.

Stop saying this. This never had been the case. I am glad my patch
finally show you are wrong.

quoted

Really, your system stability seems to depend on a completely
undocumented behavior of linux kernels before linux-3.8

If I understood, you expect that a tasklet activated from a softirq
handler is run from the same  __do_softirq() loop. This never has been
the case.

No.

The *interrupt handler* for DMA goes off while NET_RX softirq is running.
That's what schedules the *DMA tasklet*.

That tasklet should run before any process.

But it doesn't because your patch bails out early from softirq.

Fine. Fix your driver.