On Fri, 2020-10-16 at 21:15 +0200, Heiner Kallweit wrote:
>
> But we should spend at least a few thoughts on whether and how the
> irqoff version could be improved. This would have two benefits:
I disagree, using the irqoff version in a place that irqoff is not
always true is a bug.
*Maybe* it wo
On 16.10.2020 19:11, Mike Galbraith wrote:
> On Fri, 2020-10-16 at 17:26 +0300, Vladimir Oltean wrote:
>> On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
>>> I'm aware of the topic, but missing the benefits of the irqoff version
>>> unconditionally doesn't seem to be the best optio
On Fri, Oct 16, 2020 at 07:11:22PM +0200, Mike Galbraith wrote:
> Yeah, it's a straight up correctness issue as it sits.
Yeah, tell me about it, you don't even want to know what it looks like
when the local_softirq_pending_ref percpu mask gets corrupted. The
symptom will be that random syscalls, l
On Fri, 2020-10-16 at 17:26 +0300, Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
> > I'm aware of the topic, but missing the benefits of the irqoff version
> > unconditionally doesn't seem to be the best option.
>
> What are the benefits of the irqoff ver
On Fri, Oct 16, 2020 at 04:41:50PM +0200, Heiner Kallweit wrote:
> On 16.10.2020 16:26, Vladimir Oltean wrote:
> > On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
> >> I'm aware of the topic, but missing the benefits of the irqoff version
> >> unconditionally doesn't seem to be the
On 16.10.2020 16:26, Vladimir Oltean wrote:
> On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
>> I'm aware of the topic, but missing the benefits of the irqoff version
>> unconditionally doesn't seem to be the best option.
>
> What are the benefits of the irqoff version? As far as
On Fri, Oct 16, 2020 at 01:34:55PM +0200, Heiner Kallweit wrote:
> I'm aware of the topic, but missing the benefits of the irqoff version
> unconditionally doesn't seem to be the best option.
What are the benefits of the irqoff version? As far as I see it, the
only use case for that function is wh
On Fri, 2020-10-16 at 13:34 +0200, Heiner Kallweit wrote:
> On 16.10.2020 13:26, Mike Galbraith wrote:
> >
> > When the kernel is built with PREEMPT_RT or booted with threadirqs,
> > irqs are not disabled when rtl8169_interrupt() is called, inspiring
> > __raise_softirq_irqoff() to gripe. Use plai
On 16.10.2020 13:26, Mike Galbraith wrote:
>
> When the kernel is built with PREEMPT_RT or booted with threadirqs,
> irqs are not disabled when rtl8169_interrupt() is called, inspiring
> __raise_softirq_irqoff() to gripe. Use plain napi_schedule().
>
I'm aware of the topic, but missing the bene
When the kernel is built with PREEMPT_RT or booted with threadirqs,
irqs are not disabled when rtl8169_interrupt() is called, inspiring
__raise_softirq_irqoff() to gripe. Use plain napi_schedule().
Signed-off-by: Mike Galbraith
---
drivers/net/ethernet/realtek/r8169_main.c |2 +-
1 file c
10 matches
Mail list logo
