On Sat, Apr 19, 2014 at 9:21 AM, Paul Gortmaker
wrote:
> On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming wrote:
>> On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra wrote:
>
> [...]
>
>>>>
>>>> Look at that, its calling yield() from a non-preemptible context
On Sat, Apr 19, 2014 at 9:21 AM, Paul Gortmaker
paul.gortma...@windriver.com wrote:
On Wed, Apr 9, 2014 at 5:39 PM, Lin Ming min...@gmail.com wrote:
On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra pet...@infradead.org wrote:
[...]
Look at that, its calling yield() from a non-preemptible
On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra wrote:
> On Wed, Apr 09, 2014 at 09:47:42PM +0200, Peter Zijlstra wrote:
>> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>> > [12890.586996] [] (sys_sched_yield+0x0/0x90) from []
>> > (yield+0x2c/0x30)
>&
On Wed, Apr 9, 2014 at 11:32 AM, Lin Ming wrote:
> On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra wrote:
>> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>>> Hi Peter,
>>>
>>> I hit a panic in sys_sched_yield() because(for some unknown reason)
On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra wrote:
> On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
>> Hi Peter,
>>
>> I hit a panic in sys_sched_yield() because(for some unknown reason)
>> current->sched_class->yield_task is NULL.
>> It's a
Hi Peter,
I hit a panic in sys_sched_yield() because(for some unknown reason)
current->sched_class->yield_task is NULL.
It's an ARM embedded board with 3.4-rt kernel.
Could you share any hint for the possible causes?
Panic log attached.
Line 4551 "yield_task" is NULL.
4546
Hi Peter,
I hit a panic in sys_sched_yield() because(for some unknown reason)
current-sched_class-yield_task is NULL.
It's an ARM embedded board with 3.4-rt kernel.
Could you share any hint for the possible causes?
Panic log attached.
Line 4551 yield_task is NULL.
4546
On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
Hi Peter,
I hit a panic in sys_sched_yield() because(for some unknown reason)
current-sched_class-yield_task is NULL.
It's an ARM embedded board with 3.4-rt
On Wed, Apr 9, 2014 at 11:32 AM, Lin Ming min...@gmail.com wrote:
On Wed, Apr 9, 2014 at 11:25 AM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
Hi Peter,
I hit a panic in sys_sched_yield() because(for some unknown reason)
current
On Wed, Apr 9, 2014 at 1:08 PM, Peter Zijlstra pet...@infradead.org wrote:
On Wed, Apr 09, 2014 at 09:47:42PM +0200, Peter Zijlstra wrote:
On Wed, Apr 09, 2014 at 10:43:32AM -0700, Lin Ming wrote:
[12890.586996] [c007a364] (sys_sched_yield+0x0/0x90) from [c03cbf90]
(yield+0x2c/0x30
On Wed, 2013-09-25 at 07:30 -0400, Peter Hurley wrote:
> On 09/25/2013 05:04 AM, Lin Ming wrote:
> > On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley
> > wrote:
> > [snip]
> >>
> >> Looking over vmalloc.c, the critical section footprint of the
> >>
On Wed, Sep 25, 2013 at 7:30 PM, Peter Hurley wrote:
> On 09/25/2013 05:04 AM, Lin Ming wrote:
>>
>> On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley
>> wrote:
>> [snip]
>>>
>>>
>>> Looking over vmalloc.c, the critical section footprint of
but didn't find obvious way to reduce the
critical section footprint.
Could you share some hints how to do this?
Thanks,
Lin Ming
>
> Regards,
> Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@v
vmallo.c, but didn't find obvious way to reduce the
critical section footprint.
Could you share some hints how to do this?
Thanks,
Lin Ming
Regards,
Peter Hurley
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More
On Wed, Sep 25, 2013 at 7:30 PM, Peter Hurley pe...@hurleysoftware.com wrote:
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com
wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the
vmap_area_lock
could
On Wed, 2013-09-25 at 07:30 -0400, Peter Hurley wrote:
On 09/25/2013 05:04 AM, Lin Ming wrote:
On Wed, Sep 18, 2013 at 8:22 AM, Peter Hurley pe...@hurleysoftware.com
wrote:
[snip]
Looking over vmalloc.c, the critical section footprint of the
vmap_area_lock
could definitely
On Wed, 2013-09-18 at 11:15 +0200, Peter Zijlstra wrote:
> On Wed, Sep 18, 2013 at 02:57:13PM +0800, Lin Ming wrote:
> > Hi,
> >
> > lockdep support for seqlock was discussed at:
> > http://marc.info/?l=linux-kernel=137875860600648=2
> >
> > This is
Hi,
lockdep support for seqlock was discussed at:
http://marc.info/?l=linux-kernel=137875860600648=2
This is very draft patch to add lockdep support for seqlock.
Actually, it doesn't work yet. I throw it out to get comments and help.
TODO:
- fix seqlock usage in vdso code
I got below with this
Hi,
lockdep support for seqlock was discussed at:
http://marc.info/?l=linux-kernelm=137875860600648w=2
This is very draft patch to add lockdep support for seqlock.
Actually, it doesn't work yet. I throw it out to get comments and help.
TODO:
- fix seqlock usage in vdso code
I got below with
On Wed, 2013-09-18 at 11:15 +0200, Peter Zijlstra wrote:
On Wed, Sep 18, 2013 at 02:57:13PM +0800, Lin Ming wrote:
Hi,
lockdep support for seqlock was discussed at:
http://marc.info/?l=linux-kernelm=137875860600648w=2
This is very draft patch to add lockdep support for seqlock
On Wed, Sep 11, 2013 at 12:38 AM, John Stultz wrote:
> On 09/10/2013 01:59 AM, Lin Ming wrote:
>> On Tue, Sep 10, 2013 at 4:29 AM, John Stultz wrote:
>>
>> [snip]
>>
>>> So I think I've managed to finally reproduce this and hunt it down.
>>>
>>
_get_update_offsets().
> in ktime_get() and ktime_get_update_offsets(), which suggested a
> seqcount deadlock (basically calling something that reads the seqlock
> while we hold the write on it).
HRTICK enabled, then I can reproduce this simply with,
while [ 1 ] ;
adjtimex -t 9999
done
And your patch
() and ktime_get_update_offsets(), which suggested a
seqcount deadlock (basically calling something that reads the seqlock
while we hold the write on it).
HRTICK enabled, then I can reproduce this simply with,
while [ 1 ] ;
adjtimex -t
done
And your patch fixed it.
Thanks,
Lin Ming
On Wed, Sep 11, 2013 at 12:38 AM, John Stultz john.stu...@linaro.org wrote:
On 09/10/2013 01:59 AM, Lin Ming wrote:
On Tue, Sep 10, 2013 at 4:29 AM, John Stultz john.stu...@linaro.org wrote:
[snip]
So I think I've managed to finally reproduce this and hunt it down.
With Peter's sched: Fix
ode stuck at
somewhere with preemption disabled.
Look at the code, preemption disabled at:
sysvipc_proc_next -> sysvipc_find_ipc -> ipc_lock_by_ptr
enabled at:
sysvipc_proc_next -> ipc_unlock
or
sysvipc_proc_stop -> ipc_unlock
And I didn't find code may stuck in the path.
I may miss s
at
somewhere with preemption disabled.
Look at the code, preemption disabled at:
sysvipc_proc_next - sysvipc_find_ipc - ipc_lock_by_ptr
enabled at:
sysvipc_proc_next - ipc_unlock
or
sysvipc_proc_stop - ipc_unlock
And I didn't find code may stuck in the path.
I may miss something ..
Regards,
Lin Ming
>> should also be double checked whether the high words are really not
>> reserved and can be written to ...]
>
> Hi Ingo! Ufortunately I don't have access to real p4 hardware,
> thus I'm CC'ing Ming who has been helping a lot in testing
> this code pieces.
Hi,
Sorry, but I
hardware,
thus I'm CC'ing Ming who has been helping a lot in testing
this code pieces.
Hi,
Sorry, but I don't have access to p4 hardware either.
Lin Ming
Still the patch itself is perfectly fine to me
Reviewed-by: Cyrill Gorcunov gorcu...@openvz.org
--
To unsubscribe from this list: send
present everywhere.
How about moving the garbage collection to a kernel thread?
Then the write_lock(tb6_lock) in this kernel thread won't cause such
kind of dead lock with other threads.
Lin Ming
>
> Stack trace below.
>
> Thanks,
> Debabrata
>
> [46476.055009] Pid: 7963, comm:
everywhere.
How about moving the garbage collection to a kernel thread?
Then the write_lock(tb6_lock) in this kernel thread won't cause such
kind of dead lock with other threads.
Lin Ming
Stack trace below.
Thanks,
Debabrata
[46476.055009] Pid: 7963, comm: Not tainted 2.6.38-amd64
On Sun, Aug 19, 2012 at 10:45 PM, Eric Dumazet wrote:
> On Sun, 2012-08-19 at 22:15 +0800, Lin Ming wrote:
>
>> Will it still has problem if code goes here without sock_hold(sk)?
>
> Not sure of what you mean.
See my comments in the function.
Is that a potential pro
On Sun, Aug 19, 2012 at 8:51 PM, Eric Dumazet wrote:
> Hi Fengguang, thanks for this report.
>
> Hmm, this looks like sk_reset_timer() is called on a socket, and timer
> triggers _before_ the sock_hold()
>
> So the timer handler decrements sk_refcnt to 0 and calls sk_free()
>
> Its probably a
On Sun, Aug 19, 2012 at 8:51 PM, Eric Dumazet eric.duma...@gmail.com wrote:
snip...
Hi Fengguang, thanks for this report.
Hmm, this looks like sk_reset_timer() is called on a socket, and timer
triggers _before_ the sock_hold()
So the timer handler decrements sk_refcnt to 0 and calls
On Sun, Aug 19, 2012 at 10:45 PM, Eric Dumazet eric.duma...@gmail.com wrote:
On Sun, 2012-08-19 at 22:15 +0800, Lin Ming wrote:
Will it still has problem if code goes here without sock_hold(sk)?
Not sure of what you mean.
See my comments in the function.
Is that a potential problem?
static
34 matches
Mail list logo
