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 as
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
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 SYSCALL_DEFINE0(sche
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
o.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 majo
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&m=137875860600648&w=2
> >
> >
Hi,
lockdep support for seqlock was discussed at:
http://marc.info/?l=linux-kernel&m=137875860600648&w=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 t
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.
>>>
>
et() and
ktime_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
hen code 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 pat
could test it - Cyrill? [It
>> 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 test
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, c
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 bug
17 matches
Mail list logo
