----- Original Message -----
> From: "Nathan Lynch" <[email protected]>
> To: [email protected]
> Sent: Thursday, November 14, 2013 1:16:53 PM
> Subject: Re: [lttng-dev] might_sleep warnings in overwrite mode
>
> On 11/10/2013 08:18 PM, Nathan Lynch wrote:
> > At this point I cannot trigger the issue without overwrite mode on
> > 3.11.6, but on a 3.8-based vendor kernel I can recreate it regardless of
> > the mode.
>
> Some updates on this:
> - It's not specific to overwrite mode; I was able to provoke it on
> 3.11.6 without --overwrite. Overwrite mode does seem to recreate the
> issue more readily.
> - It seems to be GCC version-dependent. 4.8.1 and 4.8.2 produce code
> which warns/bugs; 4.7.3 does not.
Allright! This info is really useful. Sorry for taking time to look into this,
I was busy with preparation for 2.4-rc1.
Looking at:
fs/ext3/incode.c:
__ext3_get_inode_loc()
we can see that a use of the inlined sb_getblk() appears close to a tracepoint.
The tracepoint includes preempt disable/enable, exactly those:
include/linux/preempt.h:
#define preempt_disable_notrace() \
do { \
inc_preempt_count_notrace(); \
barrier(); \
} while (0)
#define preempt_enable_notrace() \
do { \
preempt_enable_no_resched_notrace(); \
barrier(); \
preempt_check_resched_context(); \
} while (0)
Can you try wrapping the _outside_ of those macros with barrier(), e.g.
#define preempt_disable_notrace() \
do { \
barrier(); \
inc_preempt_count_notrace(); \
barrier(); \
} while (0)
#define preempt_enable_notrace() \
do { \
preempt_enable_no_resched_notrace(); \
barrier(); \
preempt_check_resched_context(); \
barrier(); \
} while (0)
and try it out with the apparently buggy compiler to see if it helps ? It does
look like the preempt inc or dec is slipping out and somehow triggers the
might_sleep() warning. I don't see clearly how this could happen yet, since
each of the inc/dec and the test are touching preempt_count(), but it's worth a
try.
Maybe on ARM the current_thread_info() macro somehow hides important info from
the compiler and it mistakenly reorders inc/dec vs the test. Another thing to
try out (in addition to the first one) would be to try changing
current_thread_info(), e.g., by turning asm ("sp") into a volatile inline
assembly, and by adding "memory" clobbers to it.
Thoughts ?
Thanks,
Mathieu
>
>
>
> _______________________________________________
> lttng-dev mailing list
> [email protected]
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
>
--
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
_______________________________________________
lttng-dev mailing list
[email protected]
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
