On Mon, Dec 21, 2015 at 12:55 PM, Anton Ivanov
wrote:
> Patch in your queue, current code looks OK.
>
> I will try to assemble the full ubd acceleration sequence of patches
> this afternoon to submit that as well.
Applied. Let's see how much will explode. :-)
--
Thanks,
//richard
-
Patch in your queue, current code looks OK.
I will try to assemble the full ubd acceleration sequence of patches
this afternoon to submit that as well.
A.
On 11/12/15 18:38, Richard Weinberger wrote:
> Am 11.12.2015 um 12:24 schrieb Anton Ivanov:
>> On 11/12/15 08:16, Richard Weinberger wrote:
On 11/12/15 18:38, Richard Weinberger wrote:
> Am 11.12.2015 um 12:24 schrieb Anton Ivanov:
>> On 11/12/15 08:16, Richard Weinberger wrote:
>>> Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
>> 2. I cannot catch what is wrong with the current code in signal.c. When
>> I read it, it should not
Am 11.12.2015 um 12:24 schrieb Anton Ivanov:
> On 11/12/15 08:16, Richard Weinberger wrote:
>> Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
> 2. I cannot catch what is wrong with the current code in signal.c. When
> I read it, it should not produce re-entrancy. But it does.
Sorry for t
On 11/12/15 08:16, Richard Weinberger wrote:
> Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
2. I cannot catch what is wrong with the current code in signal.c. When
I read it, it should not produce re-entrancy. But it does.
>>> Sorry for the delay. Until now I did not find the time to dig
Am 11.12.2015 um 07:58 schrieb Anton Ivanov:
>>> 2. I cannot catch what is wrong with the current code in signal.c. When
>>> I read it, it should not produce re-entrancy. But it does.
>> Sorry for the delay. Until now I did not find the time to dig into that.
>> Did you find the offending code in s
On 10/12/15 22:40, Richard Weinberger wrote:
> On Fri, Nov 20, 2015 at 1:05 PM, Anton Ivanov
> wrote:
>> I have gotten to the bottom of this.
>>
>> 1. The IRQ handler re-entrancy issue predates the timer patch. Adding a
>> simple guard with a WARN_ON_ONCE around the device loop in the
>> sig_io_ha
On Fri, Nov 20, 2015 at 1:05 PM, Anton Ivanov
wrote:
> I have gotten to the bottom of this.
>
> 1. The IRQ handler re-entrancy issue predates the timer patch. Adding a
> simple guard with a WARN_ON_ONCE around the device loop in the
> sig_io_handler catches it in plain 4.3
>
> diff --git a/arch/um
I got to the bottom of this now:
1. This has been around for a long time.
2. It was not showing up because:
2.1. The deactivate_fd/reactivate_fd in the poll based IRQ
controller double up as per-fd reentrancy guard for SIGIO. So while
SIGIO handler was reentrant (potentially bad), the act
[snip]
I hope the change in arch/um/kernel/skas/MMU.c isn't the cause of all this
trouble!
No it is not, but it is one that needs refinement. Fix coming up in 10
minutes or so, I was just cleaning up the patches for submission.
The issue is reentrancy of the core interrupt logic which the cod
On 20/11/15 15:21, Thomas Meyer wrote:
> Am 20.11.2015 3:08 nachm. schrieb Anton Ivanov
> :
>> On 20/11/15 13:48, st...@nixia.no wrote:
>>> Den 2015-11-20 13:50, skrev Anton Ivanov:
On 20/11/15 12:26, st...@nixia.no wrote:
>>> 4. While I can propose a brutal patch for signal.c which sets
Am 20.11.2015 3:08 nachm. schrieb Anton Ivanov :
>
> On 20/11/15 13:48, st...@nixia.no wrote:
> > Den 2015-11-20 13:50, skrev Anton Ivanov:
> >> On 20/11/15 12:26, st...@nixia.no wrote:
> > 4. While I can propose a brutal patch for signal.c which sets
> > guards
> > against reentra
On 20/11/15 13:48, st...@nixia.no wrote:
> Den 2015-11-20 13:50, skrev Anton Ivanov:
>> On 20/11/15 12:26, st...@nixia.no wrote:
> 4. While I can propose a brutal patch for signal.c which sets
> guards
> against reentrancy which works fine, I suggest we actually get to
> the
> b
Den 2015-11-20 13:50, skrev Anton Ivanov:
> On 20/11/15 12:26, st...@nixia.no wrote:
4. While I can propose a brutal patch for signal.c which sets
guards
against reentrancy which works fine, I suggest we actually get to
the
bottom of this. Why the code in unblock_signals()
On 20/11/15 12:26, st...@nixia.no wrote:
>>> 4. While I can propose a brutal patch for signal.c which sets guards
>>> against reentrancy which works fine, I suggest we actually get to
>>> the
>>> bottom of this. Why the code in unblock_signals() does not guard
>>> correctly against that?
>> Thanks
It works correctly if I insert a guard around the interrupt handlers as
well as into unblock_signals which prevents re-entrancy.
I can clean that and send it in as well as the various irq/signal
erratas I have dug out while hunting this one.
A
On 20/11/15 12:16, Richard Weinberger wrote:
> On
>> 4. While I can propose a brutal patch for signal.c which sets guards
>> against reentrancy which works fine, I suggest we actually get to
>> the
>> bottom of this. Why the code in unblock_signals() does not guard
>> correctly against that?
>
> Thanks for hunting this issue.
> I fear I'll have t
On Fri, Nov 20, 2015 at 1:05 PM, Anton Ivanov
wrote:
> I have gotten to the bottom of this.
>
> 1. The IRQ handler re-entrancy issue predates the timer patch. Adding a
> simple guard with a WARN_ON_ONCE around the device loop in the
> sig_io_handler catches it in plain 4.3
>
> diff --git a/arch/um
18 matches
Mail list logo
