On Mon, Sep 28, 2015 at 8:50 AM, Sedat Dilek wrote:
> [ CC only relevant people plus Paul as he took care in another thread ]
>
> First of all, sorry for flooding anybody or any mailing-list.
>
> Of course, using LLVM/Clang for the Linux-kernel is still WIP, but
> this does not mean using a
[ CC only relevant people plus Paul as he took care in another thread ]
First of all, sorry for flooding anybody or any mailing-list.
Of course, using LLVM/Clang for the Linux-kernel is still WIP, but
this does not mean using a different compiler does not find any
bugs...
Fascinated somehow of
On Mon, Sep 28, 2015 at 8:50 AM, Sedat Dilek wrote:
> [ CC only relevant people plus Paul as he took care in another thread ]
>
> First of all, sorry for flooding anybody or any mailing-list.
>
> Of course, using LLVM/Clang for the Linux-kernel is still WIP, but
> this does
[ CC only relevant people plus Paul as he took care in another thread ]
First of all, sorry for flooding anybody or any mailing-list.
Of course, using LLVM/Clang for the Linux-kernel is still WIP, but
this does not mean using a different compiler does not find any
bugs...
Fascinated somehow of
On Sun, Sep 27, 2015 at 10:10 AM, Sedat Dilek wrote:
> On Fri, Sep 25, 2015 at 3:13 PM, Jiri Kosina wrote:
>> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>>
>>> > The sequence looks correct. So I don't really see what call sequence could
>>> > lead to calling flush_work() from __cancel_work_timer()
On Sun, Sep 27, 2015 at 10:10 AM, Sedat Dilek wrote:
> On Fri, Sep 25, 2015 at 3:13 PM, Jiri Kosina wrote:
>> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>>
>>> > The sequence looks correct. So I don't really see what call sequence could
>>> > lead to calling
On Fri, Sep 25, 2015 at 3:13 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> > The sequence looks correct. So I don't really see what call sequence could
>> > lead to calling flush_work() from __cancel_work_timer() with IRQs
>> > disabled (which is what your stacktrace is
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> > The sequence looks correct. So I don't really see what call sequence could
> > lead to calling flush_work() from __cancel_work_timer() with IRQs
> > disabled (which is what your stacktrace is suggesting).
> >
> > The fact that this doesn't happen with
On Fri, Sep 25, 2015 at 2:40 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> >> $ egrep -nr 'save|restore|acquire|release'
>> >> objdump-Dr_kernel-workqueue_o_CLANG-3-7.txt | egrep 'irq|map'
>> >> 5718: 4601: R_X86_64_PC32
>> >>
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> >> $ egrep -nr 'save|restore|acquire|release'
> >> objdump-Dr_kernel-workqueue_o_CLANG-3-7.txt | egrep 'irq|map'
> >> 5718: 4601: R_X86_64_PC32
> >> _raw_spin_unlock_irqrestore-0x4
> >> 5766: 4699: R_X86_64_PC32
On Fri, Sep 25, 2015 at 2:00 PM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> >> > >> [ 24.705784]
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> > This however:
> >
> > [ 24.824639] hardirqs last enabled at (7913): []
> > _raw_spin_unlock_irq+0x32/0x60
> > [ 24.824646] hardirqs last disabled at (7914): []
> > del_timer_sync+0x37/0x110
> >
> > combined with the stacktrace above, doesn't
On Fri, Sep 25, 2015 at 2:00 PM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> >> > >> [ 24.705784]
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> >> >> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> >> >> > >> [ 24.705789]
On Thu, Sep 24, 2015 at 10:21 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> > >> [ 24.705784] []
On Thu, Sep 24, 2015 at 10:21 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> > >> [
On Fri, Sep 25, 2015 at 2:00 PM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> >> >
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> >> >> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> >> >> > >> [ 24.705789]
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> > This however:
> >
> > [ 24.824639] hardirqs last enabled at (7913): []
> > _raw_spin_unlock_irq+0x32/0x60
> > [ 24.824646] hardirqs last disabled at (7914): []
> > del_timer_sync+0x37/0x110
> >
> > combined with the stacktrace above, doesn't
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> >> $ egrep -nr 'save|restore|acquire|release'
> >> objdump-Dr_kernel-workqueue_o_CLANG-3-7.txt | egrep 'irq|map'
> >> 5718: 4601: R_X86_64_PC32
> >> _raw_spin_unlock_irqrestore-0x4
> >> 5766: 4699: R_X86_64_PC32
On Fri, Sep 25, 2015 at 2:00 PM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> >> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> >> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> >> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> >> >> >
On Fri, Sep 25, 2015 at 2:40 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> >> $ egrep -nr 'save|restore|acquire|release'
>> >> objdump-Dr_kernel-workqueue_o_CLANG-3-7.txt | egrep 'irq|map'
>> >> 5718: 4601: R_X86_64_PC32
>> >>
On Fri, 25 Sep 2015, Sedat Dilek wrote:
> > The sequence looks correct. So I don't really see what call sequence could
> > lead to calling flush_work() from __cancel_work_timer() with IRQs
> > disabled (which is what your stacktrace is suggesting).
> >
> > The fact that this doesn't happen with
On Fri, Sep 25, 2015 at 3:13 PM, Jiri Kosina wrote:
> On Fri, 25 Sep 2015, Sedat Dilek wrote:
>
>> > The sequence looks correct. So I don't really see what call sequence could
>> > lead to calling flush_work() from __cancel_work_timer() with IRQs
>> > disabled (which is what
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> >> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> >> > >> [ 24.705789] []
On Thu, Sep 24, 2015 at 10:03 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Jiri Kosina wrote:
>
>> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> > >> [ 24.705784] []
On Thu, Sep 24, 2015 at 9:57 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> I am seeing this call-trace when compiling a Linux v4.2.y or Linux
>> v4.3-rcN kernel with my llvm-toolchain and llvmlinux-amd64 patchset.
>> CLANG sometimes catches things which GCC does not.
>>
>>
On Thu, 24 Sep 2015, Jiri Kosina wrote:
> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> > >> [ 24.705789] [] flush_work+0x5c/0x80
> > >>
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> I am seeing this call-trace when compiling a Linux v4.2.y or Linux
> v4.3-rcN kernel with my llvm-toolchain and llvmlinux-amd64 patchset.
> CLANG sometimes catches things which GCC does not.
>
> Not sure if this is a workqueue or hid issue...
>
> [
On Thu, 24 Sep 2015, Jiri Kosina wrote:
> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> > >> [ 24.705789] [] flush_work+0x5c/0x80
> > >>
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> I am seeing this call-trace when compiling a Linux v4.2.y or Linux
> v4.3-rcN kernel with my llvm-toolchain and llvmlinux-amd64 patchset.
> CLANG sometimes catches things which GCC does not.
>
> Not sure if this is a workqueue or hid issue...
>
> [
On Thu, 24 Sep 2015, Sedat Dilek wrote:
> >> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
> >> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
> >> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
> >> > >> [ 24.705784] [] start_flush_work+0x2f/0x290
> >> > >> [ 24.705789] []
On Thu, Sep 24, 2015 at 10:03 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Jiri Kosina wrote:
>
>> > >> [ 24.705767] [] dump_stack+0x7d/0xa0
>> > >> [ 24.705774] [] ___might_sleep+0x28a/0x2a0
>> > >> [ 24.705779] [] __might_sleep+0x4f/0xc0
>> > >> [ 24.705784] []
On Thu, Sep 24, 2015 at 9:57 AM, Jiri Kosina wrote:
> On Thu, 24 Sep 2015, Sedat Dilek wrote:
>
>> I am seeing this call-trace when compiling a Linux v4.2.y or Linux
>> v4.3-rcN kernel with my llvm-toolchain and llvmlinux-amd64 patchset.
>> CLANG sometimes catches things which
On Thu, Sep 10, 2015 at 3:04 AM, Lai Jiangshan wrote:
> Hi, TJ
>
> I think we need to add might_sleep() on the top of __cancel_work_timer().
> The might_sleep() on the start_flush_work() doesn't cover all the
> paths of __cancel_work_timer().
> And it can help to narrow the area of this bug.
>
I
On Thu, Sep 10, 2015 at 3:04 AM, Lai Jiangshan wrote:
> Hi, TJ
>
> I think we need to add might_sleep() on the top of __cancel_work_timer().
> The might_sleep() on the start_flush_work() doesn't cover all the
> paths of __cancel_work_timer().
> And it can help to narrow
On Mon, Sep 14, 2015 at 4:00 PM, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 3:04 AM, Lai Jiangshan wrote:
>> Hi, TJ
>>
>> I think we need to add might_sleep() on the top of __cancel_work_timer().
>> The might_sleep() on the start_flush_work() doesn't cover all the
>> paths of
On Fri, Sep 11, 2015 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
>> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>>> Hey,
>>>
>>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>>> > I think we need to add might_sleep() on the
On Fri, Sep 11, 2015 at 6:12 PM, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
>> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>>> Hey,
>>>
>>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>>> > I
On Mon, Sep 14, 2015 at 4:00 PM, Sedat Dilek wrote:
> On Thu, Sep 10, 2015 at 3:04 AM, Lai Jiangshan wrote:
>> Hi, TJ
>>
>> I think we need to add might_sleep() on the top of __cancel_work_timer().
>> The might_sleep() on the start_flush_work()
On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>> Hey,
>>
>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>> > I think we need to add might_sleep() on the top of __cancel_work_timer().
>> > The might_sleep() on the
On Thu, Sep 10, 2015 at 4:53 PM, Tejun Heo wrote:
> On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
>> Hey,
>>
>> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
>> > I think we need to add might_sleep() on the top of __cancel_work_timer().
>> > The
On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
> Hey,
>
> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
> > I think we need to add might_sleep() on the top of __cancel_work_timer().
> > The might_sleep() on the start_flush_work() doesn't cover all the
> > paths of
Hey,
On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
> I think we need to add might_sleep() on the top of __cancel_work_timer().
> The might_sleep() on the start_flush_work() doesn't cover all the
> paths of __cancel_work_timer().
> And it can help to narrow the area of this bug.
On Thu, Sep 10, 2015 at 10:52:27AM -0400, Tejun Heo wrote:
> Hey,
>
> On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
> > I think we need to add might_sleep() on the top of __cancel_work_timer().
> > The might_sleep() on the start_flush_work() doesn't cover all the
> > paths of
Hey,
On Thu, Sep 10, 2015 at 09:04:27AM +0800, Lai Jiangshan wrote:
> I think we need to add might_sleep() on the top of __cancel_work_timer().
> The might_sleep() on the start_flush_work() doesn't cover all the
> paths of __cancel_work_timer().
> And it can help to narrow the area of this bug.
Hi, TJ
I think we need to add might_sleep() on the top of __cancel_work_timer().
The might_sleep() on the start_flush_work() doesn't cover all the
paths of __cancel_work_timer().
And it can help to narrow the area of this bug.
Hi Sedat Dilek
[ 24.705704] irq event stamp: 19968
[ 24.705706]
Hi, TJ
I think we need to add might_sleep() on the top of __cancel_work_timer().
The might_sleep() on the start_flush_work() doesn't cover all the
paths of __cancel_work_timer().
And it can help to narrow the area of this bug.
Hi Sedat Dilek
[ 24.705704] irq event stamp: 19968
[ 24.705706]
48 matches
Mail list logo