Re: might_sleep warnings in overwrite mode

Re: might_sleep warnings in overwrite mode

[Nathan Lynch]

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.
> 
> Is it possible that the lttng module code is messing up the current
> task's preempt count somehow?

Here's another manifestation of the issue -- when flood-pinging the
board during tracing, I get this warning from __do_softirq:

huh, entered softirq 3 NET_RX 804ae528 preempt_count 00000101, exited
with 00000102?

Re: might_sleep warnings in overwrite mode

[Nathan Lynch]

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.

Re: might_sleep warnings in overwrite mode

[Mathieu Desnoyers]

----- Original Message -----
> From: "Nathan Lynch" <Nathan_Lynch@mentor.com>
> To: lttng-dev@lists.lttng.org
> 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
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: might_sleep warnings in overwrite mode

[Nathan Lynch]

On 11/14/2013 08:34 PM, Mathieu Desnoyers wrote:
> ----- Original Message -----
>> From: "Nathan Lynch" <Nathan_Lynch@mentor.com>
>> To: lttng-dev@lists.lttng.org
>> 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.
> 
> 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 ?

I did this, and I think I'm pretty satisfied that it works around the
issue.  I haven't been able to provoke might_sleep or preempt count
warnings with multiple runs.  Complicating matters is that I keep
hitting a null pointer dereference in the mmc code which I wasn't seeing
before (and sorry about the line wrapping, I cannot make Thunderbird
behave well here):

Unable to handle kernel NULL pointer dereference at virtual address 00000000
pgd = 80004000
[00000000] *pgd=00000000
Internal error: Oops: 17 [#1] PREEMPT SMP ARM
Modules linked in: lttng_probe_writeback(O) lttng_probe_workqueue(O)
lttng_probe_vmscan(O) lttng_probe_udp(O) lttng_probe_timer(O)
lttng_probe_sunrpc(O) lttng_probe_statedump(O) lttng_probe_sock(O)
lttng_probe_skb(O) lttng_probe_signal(O) lttng_probe_scsi(O)
lttng_probe_sched(O) lttng_probe_rpm(O) lttng_probe_regulator(O)
lttng_probe_regmap(O) lttng_probe_rcu(O) lttng_probe_random(O)
lttng_probe_printk(O) lttng_probe_power(O) lttng_probe_net(O)
lttng_probe_napi(O) lttng_probe_module(O) lttng_probe_kmem(O)
lttng_probe_jbd2(O) lttng_probe_jbd(O) lttng_probe_irq(O)
lttng_probe_gpio(O) lttng_probe_ext4(O) lttng_probe_ext3(O)
lttng_probe_compaction(O) lttng_probe_block(O) lttng_probe_asoc(O)
lttng_types(O) lttng_ring_buffer_metadata_mmap_client(O)
lttng_ring_buffer_client_mmap_overwrite(O)
lttng_ring_buffer_client_mmap_discard(O)
lttng_ring_buffer_metadata_client(O)
lttng_ring_buffer_client_overwrite(O)
lttng_ring_buffer_client_discard(O) lttng_tracer(O) lttng_statedump(O)
lttng_ftrace(O) lttng_kprobes(O) lttng_lib_ring_buffer(O)
lttng_kretprobes(O)
CPU: 0 PID: 143 Comm: mmcqd/0 Tainted: G           O 3.11.6 #1
task: bf0d0900 ti: bf0be000 task.ti: bf0be000
PC is at sdhci_send_command+0x3fc/0xc58
LR is at sdhci_send_command+0x424/0xc58
pc : [<804371d0>]    lr : [<804371f8>]    psr: 80000093
sp : bf0bfd50  ip : bf0bfd50  fp : bf0bfdac
r10: 60000013  r9 : bfb7c440  r8 : 0000000f
r7 : 808da22c  r6 : bb39c000  r5 : bb3ebe18  r4 : bb3ebe80
r3 : 87654321  r2 : bfa12c10  r1 : 81802b22  r0 : 00000000
Flags: Nzcv  IRQs off  FIQs on  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c53c7d  Table: 4ecb404a  DAC: 00000017
Process mmcqd/0 (pid: 143, stack limit = 0xbf0be238)
Stack: (0xbf0bfd50 to 0xbf0c0000)
fd40:                                     00000001 00000000 bf0bfd84
87654321
fd60: bfa12c10 7f0b700c bfb7c000 bb3ebda0 bfb7c440 00000001 bf0bfd94
bf0bfd88
fd80: 802d1af8 bfb7c000 bb3ebda0 bfb7c440 bfb7c518 40000013 00000001
bfb7c000
fda0: bf0bfdd4 bf0bfdb0 80438194 80436de0 bb3ebda0 bfb7c000 bb3ebd8c
00000000
fdc0: 00000001 00000001 bf0bfdec bf0bfdd8 804248d4 80437fd8 bb3ebec0
bf0bfe74
fde0: bf0bfe44 bf0bfdf0 804261b8 80424800 bf0be000 bf0be000 bf0be030
bb3ebc6c
fe00: bf0bfe44 00000000 bf0d0900 80047430 bf0bfe10 bf0bfe10 3aee2e82
bb368618
fe20: bb3ebc24 bb3c6000 bb317438 bb317438 bb3ebd9c bb3ebc00 bf0bfea4
bf0bfe48
fe40: 80433ba8 80425ef8 7f08d740 7f066a08 00000000 00000000 bf026000
00000000
fe60: bb3ebda0 00000000 bb3ebc00 00000000 00000038 cec07c38 cec07c00
bb317438
fe80: bb3c6000 bb3ebc24 bb368618 bfb7c000 bb3ebc00 bb3ebc00 bf0bfeec
bf0bfea8
fea0: 804342a4 80433800 bb3ebd9c bb3ebc00 bb317438 bb3ebc2c bb368618
5e565e55
fec0: bb3ebc00 bb3ebc24 bb317438 bb3ebc2c bb368618 bf0be030 bf0be000
00000001
fee0: bf0bff24 bf0bfef0 80434cb4 804341a4 00000000 122c8001 80434bec
bfa87bc4
ff00: 00000000 bb3ebc24 80434bec 00000000 00000000 00000000 bf0bffac
bf0bff28
ff20: 80046520 80434bf8 8182be80 00000000 8182be80 bb3ebc24 00000000
00000000
ff40: dead4ead ffffffff ffffffff 80942bfc 00000000 00000000 807877a5
bf0bff5c
ff60: bf0bff5c 00000000 00000000 dead4ead ffffffff ffffffff 80942bfc
00000000
ff80: 00000000 807877a5 bf0bff88 bf0bff88 bfa87bc4 80046464 00000000
00000000
ffa0: 00000000 bf0bffb0 8000e438 80046470 00000000 00000000 00000000
00000000
ffc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000
00000000
ffe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000
00000000
Backtrace:
[<80436dd4>] (sdhci_send_command+0x0/0xc58) from [<80438194>]
(sdhci_request+0x1c8/0x1e0)
[<80437fcc>] (sdhci_request+0x0/0x1e0) from [<804248d4>]
(mmc_start_request+0xe0/0xe8)
 r9:00000001 r8:00000001 r7:00000000 r6:bb3ebd8c r5:bfb7c000

[<804247f4>] (mmc_start_request+0x0/0xe8) from [<804261b8>]
(mmc_start_req+0x2cc/0x360)
 r5:bf0bfe74 r4:bb3ebec0
[<80425eec>] (mmc_start_req+0x0/0x360) from [<80433ba8>]
(mmc_blk_issue_rw_rq+0x3b4/0x9a4)
[<804337f4>] (mmc_blk_issue_rw_rq+0x0/0x9a4) from [<804342a4>]
(mmc_blk_issue_rq+0x10c/0x450)
[<80434198>] (mmc_blk_issue_rq+0x0/0x450) from [<80434cb4>]
(mmc_queue_thread+0xc8/0x164)
[<80434bec>] (mmc_queue_thread+0x0/0x164) from [<80046520>]
(kthread+0xbc/0xc8)
[<80046464>] (kthread+0x0/0xc8) from [<8000e438>] (ret_from_fork+0x14/0x20)
 r7:00000000 r6:00000000 r5:80046464 r4:bfa87bc4
Code: e1a00006 e3a08000 e158000a aa00000c (e5901000)

I've narrowed this down to sdhci_adma_table_pre() which is inlined, but
haven't gotten much further.  Anyway, I think it's probably unrelated --
surely it wouldn't be _caused_ by adding the barriers -- and I'll have
to figure out some way to work around it (perhaps it's fixed in 3.12).


> 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.

Haven't tried this yet.

current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

Hi,

I got a bug report on ARM which appears to be caused by an aggressive gcc optimisation starting from gcc 4.8.x due to lack of constraints on the current_thread_info() inline assembly. The only logical explanation for his issue I see so far is that read of the preempt_count within might_sleep() is reordered with preempt_enable() or preempt_disable(). AFAIU, this kind of issue also applies to other architectures.

First thing, preempt enable/disable only contains barrier() between the inc/dec and the inside of the critical section, not the outside. Therefore, we are relying on program order to ensure that the preempt_count() read in might_sleep() is not reordered with the preempt count inc/dec.

However, looking at ARM arch/arm/include/asm/thread_info.h:

static inline struct thread_info *current_thread_info(void)
{
        register unsigned long sp asm ("sp");
        return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
}

The inline assembly has no clobber and is not volatile. (this is also true for all other architectures I've looked at so far, which includes x86 and powerpc)

As long as someone does:

struct thread_info *myinfo = current_thread_info();

load from myinfo->preempt_count;
store to myinfo->preempt_count;

The program order should be preserved, because the read and the write are done wrt same base. However, what we have here in the case of might_sleep() followed by preempt_enable() is:

load from current_thread_info()->preempt_count;
store to current_thread_info()->preempt_count;

Since each current_thread_info() is a different asm ("sp") without clobber nor volatile, AFAIU, the compiler is within its right to reorder them.

One possible solution to this might be to add "memory" clobber and volatile to this inline asm, but I fear it would put way too much constraints on the compiler optimizations (too heavyweight).

Have any of you experienced this issue ? Any thoughts on the matter ?

I'm providing the original bug report email exchange below. I had confirmation that adding barrier() outside preempt_enable()/preempt_disable() does indeed work-around the issue, but I fear that this work-around would be leaving the current_thread_info() semantic gap in place: people expect program order to be respected.

Thanks,

Mathieu


----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "Nathan Lynch" <Nathan_Lynch@mentor.com>
> Cc: lttng-dev@lists.lttng.org
> Sent: Thursday, November 14, 2013 9:34:09 PM
> Subject: Re: [lttng-dev] might_sleep warnings in overwrite mode
> 
> ----- Original Message -----
> > From: "Nathan Lynch" <Nathan_Lynch@mentor.com>
> > To: lttng-dev@lists.lttng.org
> > 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
> > lttng-dev@lists.lttng.org
> > http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> > 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Peter Zijlstra]

On Tue, Nov 19, 2013 at 03:29:12PM +0000, Mathieu Desnoyers wrote:
> Hi,
> 
> I got a bug report on ARM which appears to be caused by an aggressive
> gcc optimisation starting from gcc 4.8.x due to lack of constraints on
> the current_thread_info() inline assembly. The only logical
> explanation for his issue I see so far is that read of the
> preempt_count within might_sleep() is reordered with preempt_enable()
> or preempt_disable(). AFAIU, this kind of issue also applies to other
> architectures.
> 
> First thing, preempt enable/disable only contains barrier() between
> the inc/dec and the inside of the critical section, not the outside.
> Therefore, we are relying on program order to ensure that the
> preempt_count() read in might_sleep() is not reordered with the
> preempt count inc/dec.
> 
> However, looking at ARM arch/arm/include/asm/thread_info.h:
> 
> static inline struct thread_info *current_thread_info(void) { register
> unsigned long sp asm ("sp"); return (struct thread_info *)(sp &
> ~(THREAD_SIZE - 1)); }
> 
> The inline assembly has no clobber and is not volatile. (this is also
> true for all other architectures I've looked at so far, which includes
> x86 and powerpc)
> 
> As long as someone does:
> 
> struct thread_info *myinfo = current_thread_info();
> 
> load from myinfo->preempt_count; store to myinfo->preempt_count;
> 
> The program order should be preserved, because the read and the write
> are done wrt same base. However, what we have here in the case of
> might_sleep() followed by preempt_enable() is:
> 
> load from current_thread_info()->preempt_count; store to
> current_thread_info()->preempt_count;
> 
> Since each current_thread_info() is a different asm ("sp") without
> clobber nor volatile, AFAIU, the compiler is within its right to
> reorder them.
> 
> One possible solution to this might be to add "memory" clobber and
> volatile to this inline asm, but I fear it would put way too much
> constraints on the compiler optimizations (too heavyweight).
> 
> Have any of you experienced this issue ? Any thoughts on the matter ?
> 
> I'm providing the original bug report email exchange below. I had
> confirmation that adding barrier() outside
> preempt_enable()/preempt_disable() does indeed work-around the issue,
> but I fear that this work-around would be leaving the
> current_thread_info() semantic gap in place: people expect program
> order to be respected.

This all brings to mind commit 509eb76ebf977 ("ARM: 7747/1: pcpu: ensure
__my_cpu_offset cannot be re-ordered across barrier()").

GCC seems overly happy with reordering asm() thingies.

Ideally we'd be able to tell gcc that:

  register unsigned long *sp asm ("sp")

not only acts like a variable but should be treated like a variable and
thus such reshuffeling should be limited to preserve program-order.

There doesn't seem to be any __attribute__() that can do this, and
currently out only recourse seems to add either volatile, which seems
overly strict as Mathieu said, or add fake input like Will did.

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Jakub Jelinek]

On Tue, Nov 19, 2013 at 04:57:49PM +0100, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 03:29:12PM +0000, Mathieu Desnoyers wrote:
> > However, looking at ARM arch/arm/include/asm/thread_info.h:
> > 
> > static inline struct thread_info *current_thread_info(void) { register
> > unsigned long sp asm ("sp"); return (struct thread_info *)(sp &
> > ~(THREAD_SIZE - 1)); }
> > 
> > The inline assembly has no clobber and is not volatile. (this is also
> > true for all other architectures I've looked at so far, which includes
> > x86 and powerpc)

The above is not inline assembly, it is a local register variable extension,
see
http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars

> > Since each current_thread_info() is a different asm ("sp") without
> > clobber nor volatile, AFAIU, the compiler is within its right to
> > reorder them.

Sure.

> > One possible solution to this might be to add "memory" clobber and
> > volatile to this inline asm, but I fear it would put way too much
> > constraints on the compiler optimizations (too heavyweight).

As it is not inline asm extension, you can't.
Of course you could add asm volatile ("" : "=r" (ret) : "0" (sp));
or similar and thus make it a barrier, but I think the current
definition of current_thread_info meant to avoid all that extra
overhead.  Why does it matter when sp is different between the
current_thread_info () calls?  As long as sp & ~(THREAD_SIZE - 1) is
the same, it shouldn't make a difference.  Or is the call in between those
changing sp to something else?

	Jakub

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Peter Zijlstra]

On Tue, Nov 19, 2013 at 05:13:22PM +0100, Jakub Jelinek wrote:
> On Tue, Nov 19, 2013 at 04:57:49PM +0100, Peter Zijlstra wrote:
> > On Tue, Nov 19, 2013 at 03:29:12PM +0000, Mathieu Desnoyers wrote:
> > > However, looking at ARM arch/arm/include/asm/thread_info.h:
> > > 
> > > static inline struct thread_info *current_thread_info(void) { register
> > > unsigned long sp asm ("sp"); return (struct thread_info *)(sp &
> > > ~(THREAD_SIZE - 1)); }
> > > 
> > > The inline assembly has no clobber and is not volatile. (this is also
> > > true for all other architectures I've looked at so far, which includes
> > > x86 and powerpc)
> 
> The above is not inline assembly, it is a local register variable extension,
> see
> http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars
> 
> > > Since each current_thread_info() is a different asm ("sp") without
> > > clobber nor volatile, AFAIU, the compiler is within its right to
> > > reorder them.
> 
> Sure.
> 
> > > One possible solution to this might be to add "memory" clobber and
> > > volatile to this inline asm, but I fear it would put way too much
> > > constraints on the compiler optimizations (too heavyweight).
> 
> As it is not inline asm extension, you can't.
> Of course you could add asm volatile ("" : "=r" (ret) : "0" (sp));
> or similar and thus make it a barrier, but I think the current
> definition of current_thread_info meant to avoid all that extra
> overhead.  Why does it matter when sp is different between the
> current_thread_info () calls?  As long as sp & ~(THREAD_SIZE - 1) is
> the same, it shouldn't make a difference.  Or is the call in between those
> changing sp to something else?

So what appears to be happening is that:

    preempt_enable()
 	barrier();
 	current_thread_info()->preempt_count--;

    (1)

    might_sleep()
 	if (current_thread_info()->preempt_count)
		/* raise all bloody hell */

Gets re-ordered like:

	barrier();
	if (current_thread_info()->preempt_count)
		/* raise hell */
	current_thread_info()->preempt_count--;


And by inserting a barrier() at (1) things revert to normal and work
again.

The "sp" reg value itself doesn't change here.

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Will Deacon]

On Tue, Nov 19, 2013 at 03:29:12PM +0000, Mathieu Desnoyers wrote:
> Hi,

Hi Mathieu,

> I got a bug report on ARM which appears to be caused by an aggressive gcc optimisation starting from gcc 4.8.x due to lack of constraints on the current_thread_info() inline assembly. The only logical explanation for his issue I see so far is that read of the preempt_count within might_sleep() is reordered with preempt_enable() or preempt_disable(). AFAIU, this kind of issue also applies to other architectures.
> 
> First thing, preempt enable/disable only contains barrier() between the inc/dec and the inside of the critical section, not the outside. Therefore, we are relying on program order to ensure that the preempt_count() read in might_sleep() is not reordered with the preempt count inc/dec.

This sounds almost identical to an issue I experienced with our optimised
per-cpu code (more below).

> However, looking at ARM arch/arm/include/asm/thread_info.h:
> 
> static inline struct thread_info *current_thread_info(void)
> {
>         register unsigned long sp asm ("sp");
>         return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
> }
> 
> The inline assembly has no clobber and is not volatile. (this is also true for all other architectures I've looked at so far, which includes x86 and powerpc)
> 
> As long as someone does:
> 
> struct thread_info *myinfo = current_thread_info();
> 
> load from myinfo->preempt_count;
> store to myinfo->preempt_count;
> 
> The program order should be preserved, because the read and the write are done wrt same base. However, what we have here in the case of might_sleep() followed by preempt_enable() is:
> 
> load from current_thread_info()->preempt_count;
> store to current_thread_info()->preempt_count;
> 
> Since each current_thread_info() is a different asm ("sp") without clobber nor volatile, AFAIU, the compiler is within its right to reorder them.
> 
> One possible solution to this might be to add "memory" clobber and volatile to this inline asm, but I fear it would put way too much constraints on the compiler optimizations (too heavyweight).

Yup, that sucks, because you end up unable to cache the value when you know
it hasn't changed.

> Have any of you experienced this issue ? Any thoughts on the matter ?

The way I got around this for the per-cpu code is to include a dummy memory
constraint for the stack. This has a couple of advantages:

	(1) It hazards against a "memory" clobber, so doesn't require use of
	    `volatile'

	(2) It doesn't require GCC to emit any address generation code,
	    since dereferencing the sp is valid in ARM assembly

so adding something like:

	asm("" :: "Q" (*sp));

immediately after the declaration of sp in current_therad_info might do the
trick. Do you have a way to test that?

Cheers,

Will

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

----- Original Message -----
> From: "Will Deacon" <will.deacon@arm.com>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: linux-kernel@vger.kernel.org, "Catalin Marinas" <Catalin.Marinas@arm.com>, "Peter Zijlstra"
> <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul E. McKenney"
> <paulmck@linux.vnet.ibm.com>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Andrew Morton"
> <akpm@linux-foundation.org>
> Sent: Tuesday, November 19, 2013 11:05:02 AM
> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> 
> On Tue, Nov 19, 2013 at 03:29:12PM +0000, Mathieu Desnoyers wrote:
> > Hi,
> 
> Hi Mathieu,

Hi Will,

> 
> > I got a bug report on ARM which appears to be caused by an aggressive gcc
> > optimisation starting from gcc 4.8.x due to lack of constraints on the
> > current_thread_info() inline assembly. The only logical explanation for
> > his issue I see so far is that read of the preempt_count within
> > might_sleep() is reordered with preempt_enable() or preempt_disable().
> > AFAIU, this kind of issue also applies to other architectures.
> > 
> > First thing, preempt enable/disable only contains barrier() between the
> > inc/dec and the inside of the critical section, not the outside.
> > Therefore, we are relying on program order to ensure that the
> > preempt_count() read in might_sleep() is not reordered with the preempt
> > count inc/dec.
> 
> This sounds almost identical to an issue I experienced with our optimised
> per-cpu code (more below).
> 
> > However, looking at ARM arch/arm/include/asm/thread_info.h:
> > 
> > static inline struct thread_info *current_thread_info(void)
> > {
> >         register unsigned long sp asm ("sp");
> >         return (struct thread_info *)(sp & ~(THREAD_SIZE - 1));
> > }
> > 
> > The inline assembly has no clobber and is not volatile. (this is also true
> > for all other architectures I've looked at so far, which includes x86 and
> > powerpc)
> > 
> > As long as someone does:
> > 
> > struct thread_info *myinfo = current_thread_info();
> > 
> > load from myinfo->preempt_count;
> > store to myinfo->preempt_count;
> > 
> > The program order should be preserved, because the read and the write are
> > done wrt same base. However, what we have here in the case of
> > might_sleep() followed by preempt_enable() is:
> > 
> > load from current_thread_info()->preempt_count;
> > store to current_thread_info()->preempt_count;
> > 
> > Since each current_thread_info() is a different asm ("sp") without clobber
> > nor volatile, AFAIU, the compiler is within its right to reorder them.
> > 
> > One possible solution to this might be to add "memory" clobber and volatile
> > to this inline asm, but I fear it would put way too much constraints on
> > the compiler optimizations (too heavyweight).
> 
> Yup, that sucks, because you end up unable to cache the value when you know
> it hasn't changed.
> 
> > Have any of you experienced this issue ? Any thoughts on the matter ?
> 
> The way I got around this for the per-cpu code is to include a dummy memory
> constraint for the stack. This has a couple of advantages:
> 
> 	(1) It hazards against a "memory" clobber, so doesn't require use of
> 	    `volatile'
> 
> 	(2) It doesn't require GCC to emit any address generation code,
> 	    since dereferencing the sp is valid in ARM assembly
> 
> so adding something like:
> 
> 	asm("" :: "Q" (*sp));
> 
> immediately after the declaration of sp in current_therad_info might do the
> trick. Do you have a way to test that?

Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could test
it for us though.

It might shuffle things around enough to work around the issue, but with the
approach you propose, I would be concerned about the compiler being within
its rights to reorder the code into the following sequence:

struct thread_info *ptra, *ptrb;

ptra = current_thread_info();
/*
 * each current_thread_info() would have a clobber on *sp, which orders
 * those two wrt each other.
  */
ptrb = current_thread_info();

load from ptra->preempt_count;
/*
 * however, the following accesses that depend on ptra and ptrb could be
 * reordered if the compiler has no way to know that ptra and ptrb are
 * aliased.
 */
store to ptrb->preempt_count;

One question that might be worth asking: with the local register variable
extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
(thanks to Jakub for the pointer), should the compiler consider two variables
bound to the same register as being aliased or not ? AFAIU, local reg vars appear
to be architecture-specific, so maybe there is something fishy on ARM ?

Thanks,

Mathieu


> 
> Cheers,
> 
> Will
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Peter Zijlstra]

On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could test
> it for us though.
> 
> It might shuffle things around enough to work around the issue, but with the
> approach you propose, I would be concerned about the compiler being within
> its rights to reorder the code into the following sequence:
> 
> struct thread_info *ptra, *ptrb;
> 
> ptra = current_thread_info();
> /*
>  * each current_thread_info() would have a clobber on *sp, which orders
>  * those two wrt each other.
>   */
> ptrb = current_thread_info();
> 
> load from ptra->preempt_count;
> /*
>  * however, the following accesses that depend on ptra and ptrb could be
>  * reordered if the compiler has no way to know that ptra and ptrb are
>  * aliased.
>  */
> store to ptrb->preempt_count;
> 
> One question that might be worth asking: with the local register variable
> extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> (thanks to Jakub for the pointer), should the compiler consider two variables
> bound to the same register as being aliased or not ? AFAIU, local reg vars appear
> to be architecture-specific, so maybe there is something fishy on ARM ?

Might help if you ask where the GCC people are on CC ;-)

Multiple local register variables w/ same register

[Richard Henderson]

On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could test
>> it for us though.
>>
>> It might shuffle things around enough to work around the issue, but with the
>> approach you propose, I would be concerned about the compiler being within
>> its rights to reorder the code into the following sequence:
>>
>> struct thread_info *ptra, *ptrb;
>>
>> ptra = current_thread_info();
>> /*
>>  * each current_thread_info() would have a clobber on *sp, which orders
>>  * those two wrt each other.
>>   */
>> ptrb = current_thread_info();
>>
>> load from ptra->preempt_count;
>> /*
>>  * however, the following accesses that depend on ptra and ptrb could be
>>  * reordered if the compiler has no way to know that ptra and ptrb are
>>  * aliased.
>>  */
>> store to ptrb->preempt_count;
>>
>> One question that might be worth asking: with the local register variable
>> extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
>> (thanks to Jakub for the pointer), should the compiler consider two variables
>> bound to the same register as being aliased or not ? AFAIU, local reg vars appear
>> to be architecture-specific, so maybe there is something fishy on ARM ?

It appears not:

int __attribute__((noinline)) f(void)
{
  {
    register int x __asm__("eax");
    x = 1;
  }
  {
    register int y __asm__("eax");
    return ++y;
  }
}

extern void abort(void);

int main(void)
{
  if (f() != 2)
    abort();
  return 0;
}

Anyone see anything wrong with the testcase?  Do we thing this sort of thing
ought to work, perhaps with scopes lengthened?


r~

Re: Multiple local register variables w/ same register

[Jakub Jelinek]

On Wed, Nov 20, 2013 at 07:56:57AM +1000, Richard Henderson wrote:
> It appears not:
> 
> int __attribute__((noinline)) f(void)
> {
>   {
>     register int x __asm__("eax");
>     x = 1;
>   }
>   {
>     register int y __asm__("eax");
>     return ++y;
>   }
> }
> 
> extern void abort(void);
> 
> int main(void)
> {
>   if (f() != 2)
>     abort();
>   return 0;
> }
> 
> Anyone see anything wrong with the testcase?  Do we thing this sort of thing
> ought to work, perhaps with scopes lengthened?

I'd say this is undefined, when a local register var goes out of scope,
it's value can change arbitrarily.  If you insert some call in between the
two scopes, it will surely have clobbered value, and even if there isn't
any call in between those, any insn could in theory clobber those.

	Jakub

Re: Multiple local register variables w/ same register

[Måns Rullgård]

Richard Henderson <rth@twiddle.net> writes:

> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
>> On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
>>> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
>>> could test it for us though.
>>>
>>> It might shuffle things around enough to work around the issue, but
>>> with the approach you propose, I would be concerned about the
>>> compiler being within its rights to reorder the code into the
>>> following sequence:
>>>
>>> struct thread_info *ptra, *ptrb;
>>>
>>> ptra = current_thread_info();
>>> /*
>>>  * each current_thread_info() would have a clobber on *sp, which orders
>>>  * those two wrt each other.
>>>   */
>>> ptrb = current_thread_info();
>>>
>>> load from ptra->preempt_count;
>>> /*
>>>  * however, the following accesses that depend on ptra and ptrb could be
>>>  * reordered if the compiler has no way to know that ptra and ptrb are
>>>  * aliased.
>>>  */
>>> store to ptrb->preempt_count;
>>>
>>> One question that might be worth asking: with the local register variable
>>> extension (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
>>> (thanks to Jakub for the pointer), should the compiler consider two
>>> variables bound to the same register as being aliased or not ?
>>> AFAIU, local reg vars appear to be architecture-specific, so maybe
>>> there is something fishy on ARM ?
>
> It appears not:
>
> int __attribute__((noinline)) f(void)
> {
>   {
>     register int x __asm__("eax");
>     x = 1;
>   }
>   {
>     register int y __asm__("eax");
>     return ++y;
>   }
> }
>
> extern void abort(void);
>
> int main(void)
> {
>   if (f() != 2)
>     abort();
>   return 0;
> }
>
> Anyone see anything wrong with the testcase?  Do we thing this sort of
> thing ought to work, perhaps with scopes lengthened?

In general, I see no reason why the compiler should be forced to
preserve a register between blocks like that.  Relying on a value
magically appearing in a general-purpose register seems to me fragile at
best.  Code like this adds inter-block dependencies that would not
normally be there, and I'd rather not gamble on how the various
optimisation passes deal with it, if it is even noticed at all.

What happens if you some code clobbering eax (e.g. a function call)
between those two blocks?  What do you think should happen?

-- 
Måns Rullgård
mans@mansr.com

Re: Multiple local register variables w/ same register

[Mathieu Desnoyers]

----- Original Message -----
> From: "Richard Henderson" <rth@twiddle.net>
> To: "Peter Zijlstra" <peterz@infradead.org>, "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: "Will Deacon" <will.deacon@arm.com>, linux-kernel@vger.kernel.org, "Catalin Marinas" <Catalin.Marinas@arm.com>,
> lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul E. McKenney"
> <paulmck@linux.vnet.ibm.com>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Andrew Morton"
> <akpm@linux-foundation.org>, "Jakub Jelinek" <jakub@redhat.com>, gcc@gcc.gnu.org
> Sent: Tuesday, November 19, 2013 4:56:57 PM
> Subject: Multiple local register variables w/ same register
> 
> On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> > On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
> >> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan could
> >> test
> >> it for us though.
> >>
> >> It might shuffle things around enough to work around the issue, but with
> >> the
> >> approach you propose, I would be concerned about the compiler being within
> >> its rights to reorder the code into the following sequence:
> >>
> >> struct thread_info *ptra, *ptrb;
> >>
> >> ptra = current_thread_info();
> >> /*
> >>  * each current_thread_info() would have a clobber on *sp, which orders
> >>  * those two wrt each other.
> >>   */
> >> ptrb = current_thread_info();
> >>
> >> load from ptra->preempt_count;
> >> /*
> >>  * however, the following accesses that depend on ptra and ptrb could be
> >>  * reordered if the compiler has no way to know that ptra and ptrb are
> >>  * aliased.
> >>  */
> >> store to ptrb->preempt_count;
> >>
> >> One question that might be worth asking: with the local register variable
> >> extension
> >> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> >> (thanks to Jakub for the pointer), should the compiler consider two
> >> variables
> >> bound to the same register as being aliased or not ? AFAIU, local reg vars
> >> appear
> >> to be architecture-specific, so maybe there is something fishy on ARM ?
> 
> It appears not:
> 
> int __attribute__((noinline)) f(void)
> {
>   {
>     register int x __asm__("eax");
>     x = 1;
>   }
>   {
>     register int y __asm__("eax");
>     return ++y;
>   }
> }
> 
> extern void abort(void);
> 
> int main(void)
> {
>   if (f() != 2)
>     abort();
>   return 0;
> }
> 
> Anyone see anything wrong with the testcase?

This testcase is targeting a general purpose register, whereas the issue I'm presenting gets the stack pointer as base address for many memory operations targeting the same offset from this base address. So strictly speaking, I think the two cases are slightly different.

Thanks,

Mathieu


> Do we thing this sort of thing
> ought to work, perhaps with scopes lengthened?
> 
> 
> r~
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [lttng-dev] Multiple local register variables w/ same register

[Mathieu Desnoyers]

----- Original Message -----
> From: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> To: "Richard Henderson" <rth@twiddle.net>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, gcc@gcc.gnu.org, "Peter Zijlstra" <peterz@infradead.org>, "Catalin Marinas"
> <Catalin.Marinas@arm.com>, "Nathan Lynch" <Nathan_Lynch@mentor.com>, linux-kernel@vger.kernel.org, "Will Deacon"
> <will.deacon@arm.com>, lttng-dev@lists.lttng.org, "Andrew Morton" <akpm@linux-foundation.org>, "Paul E. McKenney"
> <paulmck@linux.vnet.ibm.com>, "Linus Torvalds" <torvalds@linux-foundation.org>
> Sent: Tuesday, November 19, 2013 5:25:18 PM
> Subject: Re: [lttng-dev] Multiple local register variables w/ same register
> 
> ----- Original Message -----
> > From: "Richard Henderson" <rth@twiddle.net>
> > To: "Peter Zijlstra" <peterz@infradead.org>, "Mathieu Desnoyers"
> > <mathieu.desnoyers@efficios.com>
> > Cc: "Will Deacon" <will.deacon@arm.com>, linux-kernel@vger.kernel.org,
> > "Catalin Marinas" <Catalin.Marinas@arm.com>,
> > lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > E. McKenney"
> > <paulmck@linux.vnet.ibm.com>, "Linus Torvalds"
> > <torvalds@linux-foundation.org>, "Andrew Morton"
> > <akpm@linux-foundation.org>, "Jakub Jelinek" <jakub@redhat.com>,
> > gcc@gcc.gnu.org
> > Sent: Tuesday, November 19, 2013 4:56:57 PM
> > Subject: Multiple local register variables w/ same register
> > 
> > On 11/20/2013 03:33 AM, Peter Zijlstra wrote:
> > > On Tue, Nov 19, 2013 at 05:02:20PM +0000, Mathieu Desnoyers wrote:
> > >> Unfortunately I don't have a ARM cross-compiler setup ready. Nathan
> > >> could
> > >> test
> > >> it for us though.
> > >>
> > >> It might shuffle things around enough to work around the issue, but with
> > >> the
> > >> approach you propose, I would be concerned about the compiler being
> > >> within
> > >> its rights to reorder the code into the following sequence:
> > >>
> > >> struct thread_info *ptra, *ptrb;
> > >>
> > >> ptra = current_thread_info();
> > >> /*
> > >>  * each current_thread_info() would have a clobber on *sp, which orders
> > >>  * those two wrt each other.
> > >>   */
> > >> ptrb = current_thread_info();
> > >>
> > >> load from ptra->preempt_count;
> > >> /*
> > >>  * however, the following accesses that depend on ptra and ptrb could be
> > >>  * reordered if the compiler has no way to know that ptra and ptrb are
> > >>  * aliased.
> > >>  */
> > >> store to ptrb->preempt_count;
> > >>
> > >> One question that might be worth asking: with the local register
> > >> variable
> > >> extension
> > >> (http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Local-Reg-Vars.html#Local-Reg-Vars)
> > >> (thanks to Jakub for the pointer), should the compiler consider two
> > >> variables
> > >> bound to the same register as being aliased or not ? AFAIU, local reg
> > >> vars
> > >> appear
> > >> to be architecture-specific, so maybe there is something fishy on ARM ?
> > 
> > It appears not:
> > 
> > int __attribute__((noinline)) f(void)
> > {
> >   {
> >     register int x __asm__("eax");
> >     x = 1;
> >   }
> >   {
> >     register int y __asm__("eax");
> >     return ++y;
> >   }
> > }
> > 
> > extern void abort(void);
> > 
> > int main(void)
> > {
> >   if (f() != 2)
> >     abort();
> >   return 0;
> > }
> > 
> > Anyone see anything wrong with the testcase?
> 
> This testcase is targeting a general purpose register, whereas the issue I'm
> presenting gets the stack pointer as base address for many memory operations
> targeting the same offset from this base address. So strictly speaking, I
> think the two cases are slightly different.

By the way, I just had more info from Nathan, where a splat clearly shows a scheduling while atomic, which points rather to an unbalanced preempt enable/disable within LTTng. It's weird though, because so far it only triggers on ARM, and only with gcc 4.8.x. Don't waste your time on this one until we can figure out if the issue is within LTTng.

Thanks,

Mathieu

> 
> Thanks,
> 
> Mathieu
> 
> 
> > Do we thing this sort of thing
> > ought to work, perhaps with scopes lengthened?
> > 
> > 
> > r~
> > 
> 
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
> 
> _______________________________________________
> lttng-dev mailing list
> lttng-dev@lists.lttng.org
> http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Linus Torvalds]

On Tue, Nov 19, 2013 at 7:29 AM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> Since each current_thread_info() is a different asm ("sp") without clobber nor volatile, AFAIU, the compiler is within its right to reorder them.

I don't understand why you say that.

The ordering of the access to the asm("sp") register is totally
irrelevant. You are "correct" in saying that the compiler is within
its right to re-order them, but that is the worst kind of correct:
it's totally immaterial. In fact, we *want* the compiler to not just
re-order the accesses to %sp, but to notice that it can combine them,
and do CSE on that whole expression when it is used multiple times
within the same function (like it often is used).

So the compiler can very much decide to re-read %sp all it wants, and
re-order those reads all it wants, and that's not the bug at all.
Putting a clobber or a volatile on it would disable the optimization
we *want* to happen.

So don't bark up the wrong tree.

The bug seems to be that gcc re-orders the *memory* *accesses* through
that point, which is not correct in any way, shape, or form. If we
have a write to a memory location followed by a read of the same
memory location, the compiler ABSOLUTELY MUST NOT RE-ORDER THEM. The
write obviously changes the value of the read.

It seems that some gcc alias analysis completely incorrectly thinks
that they are not the same memory location, and do not alias. My guess
would be that gcc sees that that they are based on the stack pointer
with "different" offsets, and decides that the memory locations must
be different - without noticing that the "& ~(THREAD_SIZE - 1)" will
end up generating the same address for both of them.

There may be some insane "two different objects on the stack cannot
alias" logic, which is true for *objects* on the stack, but it sure as
hell isn't true for random accesses through asm("sp").

If I read this thread correctly, you're all talking about something
else than the actual bug, and are trying to say that there is
something wrong with re-ordering the access to %sp itself. Missing the
_real_ bug entirely. See above.

                  Linus

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

----- Original Message -----
> From: "Linus Torvalds" <torvalds@linux-foundation.org>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>, "Jakub Jelinek" <jakub@redhat.com>, "Richard Henderson"
> <rth@twiddle.net>
> Cc: "Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin
> Marinas" <catalin.marinas@arm.com>, "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan
> Lynch" <Nathan_Lynch@mentor.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> <akpm@linux-foundation.org>
> Sent: Tuesday, November 19, 2013 7:41:17 PM
> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> 
> On Tue, Nov 19, 2013 at 7:29 AM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> >
> > Since each current_thread_info() is a different asm ("sp") without clobber
> > nor volatile, AFAIU, the compiler is within its right to reorder them.
> 
> I don't understand why you say that.
> 
> The ordering of the access to the asm("sp") register is totally
> irrelevant. You are "correct" in saying that the compiler is within
> its right to re-order them, but that is the worst kind of correct:
> it's totally immaterial. In fact, we *want* the compiler to not just
> re-order the accesses to %sp, but to notice that it can combine them,
> and do CSE on that whole expression when it is used multiple times
> within the same function (like it often is used).
> 
> So the compiler can very much decide to re-read %sp all it wants, and
> re-order those reads all it wants, and that's not the bug at all.
> Putting a clobber or a volatile on it would disable the optimization
> we *want* to happen.
> 
> So don't bark up the wrong tree.
> 
> The bug seems to be that gcc re-orders the *memory* *accesses* through
> that point, which is not correct in any way, shape, or form. If we
> have a write to a memory location followed by a read of the same
> memory location, the compiler ABSOLUTELY MUST NOT RE-ORDER THEM. The
> write obviously changes the value of the read.
> 
> It seems that some gcc alias analysis completely incorrectly thinks
> that they are not the same memory location, and do not alias. My guess
> would be that gcc sees that that they are based on the stack pointer
> with "different" offsets, and decides that the memory locations must
> be different - without noticing that the "& ~(THREAD_SIZE - 1)" will
> end up generating the same address for both of them.
> 
> There may be some insane "two different objects on the stack cannot
> alias" logic, which is true for *objects* on the stack, but it sure as
> hell isn't true for random accesses through asm("sp").
> 
> If I read this thread correctly, you're all talking about something
> else than the actual bug, and are trying to say that there is
> something wrong with re-ordering the access to %sp itself. Missing the
> _real_ bug entirely. See above.

Yes, exactly, your explanation clarifies the underlying issue I'm trying to
point at.

Thank you !

Mathieu


> 
>                   Linus
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Alexander Holler]

Am 20.11.2013 01:41, schrieb Linus Torvalds:

> It seems that some gcc alias analysis completely incorrectly thinks
> that they are not the same memory location, and do not alias. My guess
> would be that gcc sees that that they are based on the stack pointer
> with "different" offsets, and decides that the memory locations must
> be different - without noticing that the "& ~(THREAD_SIZE - 1)" will
> end up generating the same address for both of them.

Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that 
current_thread_info() has the prototype

static inline struct thread_info *current_thread_info(void) 
__attribute_const__;

on arm (and arm64 and unicore32, something the paste from Mathieu missed 
so most people here might have missed that detail too). It's a very good 
finding from Luis.

I'm writing this message because his mail doesn't have an in-reply-to 
header, so it might be missed in this thread.

As Luis said, declaring current_thread_info() as a const function is 
wrong. The gcc manual says:

----
const

Many functions do not examine any values except their arguments, and 
have no effects except the return value. Basically this is just slightly 
more strict class than the pure attribute below, since function is not 
allowed to read global memory.

Note that a function that has pointer arguments and examines the data 
pointed to must not be declared const. Likewise, a function that calls a 
non-const function usually must not be const. It does not make sense for 
a const function to return void.
----

So current_thread_info() clearly violates the constrain to not read 
global memory. Or in other words, that __attribute_const__ tells gcc 
explicitly that the two reads are pointing to different locations 
because they are assumed to be local (through the const).

So This might be the reason why gcc misses that different calls to 
current_thread_info() might point to the same memory location.


As I've an arm gcc 4.8.1 ready too, I'm joining Luis question where the 
reordering can be found. If someone would point me to the source/object 
where this happens, I could have a look if removing the 
__attribute_const__ makes a difference.

Regards,

Alexander Holler

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

Thanks for putting my e-mail in the right thread Alexander.

I also wanted to point out that we recently were hit by the following bug:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854

which can mess up the handling of SP and cause strange failures in the kernel.

From the description of the bug in this thread, we don't think the
bugs are related but whoever is going to try removing the "const
attribute" please also make sure that the bug still reproduces after
applying the fix for the GCC bug above.

Luis

On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@ahsoftware.de> wrote:
> Am 20.11.2013 01:41, schrieb Linus Torvalds:
>
>> It seems that some gcc alias analysis completely incorrectly thinks
>> that they are not the same memory location, and do not alias. My guess
>> would be that gcc sees that that they are based on the stack pointer
>> with "different" offsets, and decides that the memory locations must
>> be different - without noticing that the "& ~(THREAD_SIZE - 1)" will
>> end up generating the same address for both of them.
>
>
> Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that
> current_thread_info() has the prototype
>
>
> static inline struct thread_info *current_thread_info(void)
> __attribute_const__;
>
> on arm (and arm64 and unicore32, something the paste from Mathieu missed so
> most people here might have missed that detail too). It's a very good
> finding from Luis.
>
> I'm writing this message because his mail doesn't have an in-reply-to
> header, so it might be missed in this thread.
>
> As Luis said, declaring current_thread_info() as a const function is wrong.
> The gcc manual says:
>
> ----
> const
>
> Many functions do not examine any values except their arguments, and have no
> effects except the return value. Basically this is just slightly more strict
> class than the pure attribute below, since function is not allowed to read
> global memory.
>
> Note that a function that has pointer arguments and examines the data
> pointed to must not be declared const. Likewise, a function that calls a
> non-const function usually must not be const. It does not make sense for a
> const function to return void.
> ----
>
> So current_thread_info() clearly violates the constrain to not read global
> memory. Or in other words, that __attribute_const__ tells gcc explicitly
> that the two reads are pointing to different locations because they are
> assumed to be local (through the const).
>
> So This might be the reason why gcc misses that different calls to
> current_thread_info() might point to the same memory location.
>
>
> As I've an arm gcc 4.8.1 ready too, I'm joining Luis question where the
> reordering can be found. If someone would point me to the source/object
> where this happens, I could have a look if removing the __attribute_const__
> makes a difference.
>
> Regards,
>
> Alexander Holler

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Linus Torvalds]

On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@ahsoftware.de> wrote:
>
> Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that
> current_thread_info() has the prototype
>
> static inline struct thread_info *current_thread_info(void)
> __attribute_const__;
>
> on arm (and arm64 and unicore32, something the paste from Mathieu missed so
> most people here might have missed that detail too). It's a very good
> finding from Luis.

No, because it is immaterial.

We *want* gcc to optimize away multiple accesses to "sp". Because it
doesn't *matter* whether "sp" changes or not, the *result* is always
the same. That's what the "const" means.

The "& ~(THREAD_SIZE - 1)" part will remove all the bits that can
change. Really. So the result *is* constant (within one thread).
Marking it constant and telling gcc that it can combine these things
is correct.

Guys, read my email again.

The bug is not that gcc can re-order or combine the accesses to "sp".
WE WANT THAT TO HAPPEN.

The bug is *outside* that "current_thread_info()" macro/inline
function. It's the *dereference* of the pointer that gcc re-orders.
AND THAT IS WRONG.

Gcc seems to mess up the alias analysis, and decide that the
deferences cannot alias. Which is wrong. They clearly *can* alias,
exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
the same value all the time.

                 Linus

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Bhaskar Janakiraman]

[-- Attachment #1.1: Type: text/plain, Size: 2240 bytes --]

On Thu, Nov 21, 2013 at 2:32 PM, Linus Torvalds <
torvalds@linux-foundation.org> wrote:

> On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@ahsoftware.de>
> wrote:
> >
> > Luis Lozano just noted (see https://lkml.org/lkml/2013/11/20/625) that
> > current_thread_info() has the prototype
> >
> > static inline struct thread_info *current_thread_info(void)
> > __attribute_const__;
> >
> > on arm (and arm64 and unicore32, something the paste from Mathieu missed
> so
> > most people here might have missed that detail too). It's a very good
> > finding from Luis.
>

Can someone provide a test case? We are unable to reproduce the problem in
ChromeOS land.


>
> No, because it is immaterial.
>
> We *want* gcc to optimize away multiple accesses to "sp". Because it
> doesn't *matter* whether "sp" changes or not, the *result* is always
> the same. That's what the "const" means.
>
> The "& ~(THREAD_SIZE - 1)" part will remove all the bits that can
> change. Really. So the result *is* constant (within one thread).
> Marking it constant and telling gcc that it can combine these things
> is correct.
>

Its unfortunate that the attribute '__const__ ' is very misleading - the
semantic used by gcc is that this is an aliasing attribute that implies
that the function does not depend in any way on global state. Meaning, if
called with the same parameters, it expected to return the same value. It
should have been called 'pure', but gcc has a different 'pure' attribute
that imples something different :-(

That said, gcc should be smart enough to figure out that this function is
 not doing anything complicated. Again, a test case would be much
appreciated.

Bhaskar



> Guys, read my email again.
>
> The bug is not that gcc can re-order or combine the accesses to "sp".
> WE WANT THAT TO HAPPEN.
>
> The bug is *outside* that "current_thread_info()" macro/inline
> function. It's the *dereference* of the pointer that gcc re-orders.
> AND THAT IS WRONG.
>
> Gcc seems to mess up the alias analysis, and decide that the
> deferences cannot alias. Which is wrong. They clearly *can* alias,
> exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
> the same value all the time.
>
>






                 Linus
>

[-- Attachment #1.2: Type: text/html, Size: 3920 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Alexander Holler]

Am 21.11.2013 23:32, schrieb Linus Torvalds:
> On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@ahsoftware.de> wrote:

> The bug is not that gcc can re-order or combine the accesses to "sp".
> WE WANT THAT TO HAPPEN.

Sure, and I don't disagree on that.

>
> The bug is *outside* that "current_thread_info()" macro/inline
> function. It's the *dereference* of the pointer that gcc re-orders.
> AND THAT IS WRONG.
>
> Gcc seems to mess up the alias analysis, and decide that the
> deferences cannot alias. Which is wrong. They clearly *can* alias,
> exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
> the same value all the time.

Sorry, that I still disagree.

I try to describe it more clearly why I still think that the problem 
might be because of that const declaration.

(...)

foobar1 = current_thread_info() __attribute_const__ {
	return sp->somewhere_local;
}

(...)

foobar2 = current_thread_info() __attribute_const__ {
	return sp->somewhere_local;
}

So, even if sp is the same in both cases, that const states that 
wherever sp points to is local to current_thread_info(), so it can't be 
the same for both cases.

Regards,

Alexander Holler

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

I think we need a reproducer. Without this we may all be going on the
wrong path. This whole conversation started on an *assumption* that
some accesses were being reordered.

evidence of the reorder or reproducer please?

Luis


On Thu, Nov 21, 2013 at 3:18 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>
> Am 21.11.2013 23:32, schrieb Linus Torvalds:
>
>> On Thu, Nov 21, 2013 at 8:02 AM, Alexander Holler <holler@ahsoftware.de>
>> wrote:
>
>
>> The bug is not that gcc can re-order or combine the accesses to "sp".
>> WE WANT THAT TO HAPPEN.
>
>
> Sure, and I don't disagree on that.
>
>
>>
>> The bug is *outside* that "current_thread_info()" macro/inline
>> function. It's the *dereference* of the pointer that gcc re-orders.
>> AND THAT IS WRONG.
>>
>> Gcc seems to mess up the alias analysis, and decide that the
>> deferences cannot alias. Which is wrong. They clearly *can* alias,
>> exactly because the value of "sp & ~(THREAD_SIZE - 1)" ends up having
>> the same value all the time.
>
>
> Sorry, that I still disagree.
>
> I try to describe it more clearly why I still think that the problem might
> be because of that const declaration.
>
> (...)
>
> foobar1 = current_thread_info() __attribute_const__ {
>         return sp->somewhere_local;
> }
>
> (...)
>
> foobar2 = current_thread_info() __attribute_const__ {
>         return sp->somewhere_local;
> }
>
> So, even if sp is the same in both cases, that const states that wherever sp
> points to is local to current_thread_info(), so it can't be the same for
> both cases.
>
> Regards,
>
> Alexander Holler



-- 

Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Jakub Jelinek]

On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> I think we need a reproducer. Without this we may all be going on the
> wrong path. This whole conversation started on an *assumption* that
> some accesses were being reordered.
> 
> evidence of the reorder or reproducer please?

Yeah, if a compiler bug is suspected, can anybody please open
a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
compiler version, flags and how it was configured and some hint in which
function to look for what exactly?  We don't necessarily need a runtime
small reproducer, but if it can be shown in the assembly what has been
reordered and why you think it shouldn't, with the above mentioned input
that ought to be sufficient.  Thanks.

	Jakub

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

[-- Attachment #1: Type: text/plain, Size: 6839 bytes --]

----- Original Message -----
> From: "Jakub Jelinek" <jakub@redhat.com>
> To: "Luis Lozano" <llozano@google.com>
> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> Sent: Thursday, November 21, 2013 7:39:04 PM
> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> 
> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> > I think we need a reproducer. Without this we may all be going on the
> > wrong path. This whole conversation started on an *assumption* that
> > some accesses were being reordered.
> > 
> > evidence of the reorder or reproducer please?
> 
> Yeah, if a compiler bug is suspected, can anybody please open
> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
> compiler version, flags and how it was configured and some hint in which
> function to look for what exactly?  We don't necessarily need a runtime
> small reproducer, but if it can be shown in the assembly what has been
> reordered and why you think it shouldn't, with the above mentioned input
> that ought to be sufficient.  Thanks.

OK OK, let me reply on list first so I can share the result of a full day
of bug hunting. We're not there yet, but many options have been eliminated.

The issue shows up in stress test, when tracing with lttng-modules 2.4-rc1,
on ARM. It's been reproduced with a Linux kernel 3.12 so far, with lttng-modules
compiled against that kernel.

First, I asked Nathan to compile his kernel with gcc 4.7, and lttng-modules
with gcc 4.8.x (and vice-versa). The problem only appears when lttng-modules
are compiled with gcc 4.8.x. The compiler version used to compile the rest
of the kernel does not matter.

Then I looked at gcc 4.8 changelog for ARM, new feature: -fno-sched-pressure
(sched pressure is there by default). Nathan tried compiling lttng-modules with
-fno-sched-pressure. The problem still reproduces.

Knowing that adding barrier() outside of preempt_disable()/enable() was
fixing the issue, we tried identifying which code location was responsible
for working around the issue. Skipping a long investigation, here is the
executive summary:

http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD

Has the following function. We identified that adding a barrier() as shown below
works around the issue:

static
int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
                      uint32_t event_id)
{
        struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
        int ret, cpu;

        cpu = lib_ring_buffer_get_cpu(&client_config);
        if (cpu < 0)
                return -EPERM;
        ctx->cpu = cpu;

        switch (lttng_chan->header_type) {
        case 1: /* compact */
                if (event_id > 30)
                        ctx->rflags |= LTTNG_RFLAG_EXTENDED;
                break;
        case 2: /* large */
                if (event_id > 65534)
                        ctx->rflags |= LTTNG_RFLAG_EXTENDED;
                break;
        default:
                WARN_ON_ONCE(1);
        }

        ret = lib_ring_buffer_reserve(&client_config, ctx);
        if (ret)
                goto put;
        lttng_write_event_header(&client_config, ctx, event_id);
        return 0;
put:
        lib_ring_buffer_put_cpu(&client_config);
        ---------------> barrier() added here; <----------------------------
        return ret;
}

Where barrier() is the usual asm volatile with "memory" clobber, nothing else.

Nathan gave me the binary diff for the assembly generated for this function without
the barrier and with the barrier:

--- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079 -0600
+++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21 14:12:52.997355907 -0600
@@ -7,11 +7,11 @@
      f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
      f14:      e5903000        ldr     r3, [r0]
      f18:      e1a04000        mov     r4, r0
-     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
+     f1c:      e1a0000d        mov     r0, sp
      f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
-     f24:      e1a0000d        mov     r0, sp
-     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
-     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
+     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
+     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
+     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
      f30:      e5932004        ldr     r2, [r3, #4]
      f34:      e2822001        add     r2, r2, #1
      f38:      e5832004        str     r2, [r3, #4]
@@ -53,7 +53,7 @@
      fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
      fcc:      e5933000        ldr     r3, [r3]
      fd0:      e3130002        tst     r3, #2
-     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
+     fd4:      0a0002be        beq     1ad4 <lttng_event_reserve+0xbd8>
      fd8:      ebfffffe        bl      0 <preempt_schedule>
      fdc:      ea0002bc        b       1ad4 <lttng_event_reserve+0xbd8>
      fe0:      e3500000        cmp     r0, #0

We tried disabling the ftrace function tracing to get mcount out of the way,
and the problem still reproduces.

I'm stopping here in terms of details about the disassembly, because I
need to double check with Nathan that I get the right disassembly for the right
cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my machine.

I'm attaching Nathan's ARM configuration.

It does look behave a bit like this bug pointed out by Luis:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854

AFAIU (please correct me if I am wrong), ARM's interrupt handler run
on top of the thread stack (?). If it's the case, then anything stored
on the stack below "sp" could be overwritten by an interrupt handler.
This would fit well the reproduction scenario for this bug: Nathan runs
LTTng tracing of kmem_cache_free tracepoint with hackbench running.
A race between a short window of stack use below sp and interrupt handlers
would trigger with this kind of stress-test.

Thoughts ?

Thanks,

Mathieu


-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[-- Attachment #2: nathan-arm-config --]
[-- Type: application/octet-stream, Size: 72981 bytes --]

#
# Automatically generated file; DO NOT EDIT.
# Linux/arm 3.12.0 Kernel Configuration
#
CONFIG_ARM=y
CONFIG_SYS_SUPPORTS_APM_EMULATION=y
CONFIG_HAVE_PROC_CPU=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_RWSEM_GENERIC_SPINLOCK=y
CONFIG_ARCH_HAS_CPUFREQ=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_NEED_DMA_MAP_STATE=y
CONFIG_FIQ=y
CONFIG_VECTORS_BASE=0xffff0000
CONFIG_ARM_PATCH_PHYS_VIRT=y
CONFIG_GENERIC_BUG=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_EXTABLE_SORT=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_CROSS_COMPILE=""
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_LZMA is not set
# CONFIG_KERNEL_XZ is not set
CONFIG_KERNEL_LZO=y
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_HOSTNAME="(none)"
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_FHANDLE is not set
# CONFIG_AUDIT is not set

#
# IRQ subsystem
#
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_GENERIC_IRQ_SHOW=y
CONFIG_HARDIRQS_SW_RESEND=y
CONFIG_GENERIC_IRQ_CHIP=y
CONFIG_IRQ_DOMAIN=y
# CONFIG_IRQ_DOMAIN_DEBUG is not set
CONFIG_IRQ_FORCED_THREADING=y
CONFIG_SPARSE_IRQ=y
CONFIG_KTIME_SCALAR=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_ARCH_HAS_TICK_BROADCAST=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y

#
# Timers subsystem
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ_COMMON=y
# CONFIG_HZ_PERIODIC is not set
CONFIG_NO_HZ_IDLE=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y

#
# CPU/Task time and stats accounting
#
CONFIG_TICK_CPU_ACCOUNTING=y
# CONFIG_IRQ_TIME_ACCOUNTING is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set

#
# RCU Subsystem
#
CONFIG_TREE_PREEMPT_RCU=y
CONFIG_PREEMPT_RCU=y
CONFIG_RCU_STALL_COMMON=y
# CONFIG_RCU_USER_QS is not set
CONFIG_RCU_FANOUT=32
CONFIG_RCU_FANOUT_LEAF=16
# CONFIG_RCU_FANOUT_EXACT is not set
# CONFIG_RCU_FAST_NO_HZ is not set
# CONFIG_TREE_RCU_TRACE is not set
# CONFIG_RCU_BOOST is not set
# CONFIG_RCU_NOCB_CPU is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=18
CONFIG_GENERIC_SCHED_CLOCK=y
CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not set
# CONFIG_CGROUP_FREEZER is not set
# CONFIG_CGROUP_DEVICE is not set
# CONFIG_CPUSETS is not set
# CONFIG_CGROUP_CPUACCT is not set
# CONFIG_RESOURCE_COUNTERS is not set
# CONFIG_CGROUP_PERF is not set
# CONFIG_CGROUP_SCHED is not set
# CONFIG_BLK_CGROUP is not set
# CONFIG_CHECKPOINT_RESTORE is not set
# CONFIG_NAMESPACES is not set
# CONFIG_UIDGID_STRICT_TYPE_CHECKS is not set
# CONFIG_SCHED_AUTOGROUP is not set
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_RD_GZIP=y
# CONFIG_RD_BZIP2 is not set
# CONFIG_RD_LZMA is not set
# CONFIG_RD_XZ is not set
# CONFIG_RD_LZO is not set
# CONFIG_RD_LZ4 is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_ANON_INODES=y
CONFIG_HAVE_UID16=y
CONFIG_EXPERT=y
CONFIG_UID16=y
# CONFIG_SYSCTL_SYSCALL is not set
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_AIO=y
# CONFIG_EMBEDDED is not set
CONFIG_HAVE_PERF_EVENTS=y
CONFIG_PERF_USE_VMALLOC=y

#
# Kernel Performance Events And Counters
#
CONFIG_PERF_EVENTS=y
CONFIG_DEBUG_PERF_USE_VMALLOC=y
CONFIG_VM_EVENT_COUNTERS=y
# CONFIG_SLUB_DEBUG is not set
# CONFIG_COMPAT_BRK is not set
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_SLUB_CPU_PARTIAL=y
# CONFIG_PROFILING is not set
CONFIG_TRACEPOINTS=y
CONFIG_HAVE_OPROFILE=y
CONFIG_KPROBES=y
# CONFIG_JUMP_LABEL is not set
# CONFIG_HAVE_64BIT_ALIGNED_ACCESS is not set
CONFIG_KRETPROBES=y
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_HAVE_ARCH_TRACEHOOK=y
CONFIG_HAVE_DMA_ATTRS=y
CONFIG_HAVE_DMA_CONTIGUOUS=y
CONFIG_USE_GENERIC_SMP_HELPERS=y
CONFIG_GENERIC_SMP_IDLE_THREAD=y
CONFIG_GENERIC_IDLE_POLL_SETUP=y
CONFIG_HAVE_REGS_AND_STACK_ACCESS_API=y
CONFIG_HAVE_CLK=y
CONFIG_HAVE_DMA_API_DEBUG=y
CONFIG_HAVE_HW_BREAKPOINT=y
CONFIG_HAVE_ARCH_JUMP_LABEL=y
CONFIG_ARCH_WANT_IPC_PARSE_VERSION=y
CONFIG_HAVE_ARCH_SECCOMP_FILTER=y
CONFIG_HAVE_CONTEXT_TRACKING=y
CONFIG_HAVE_IRQ_TIME_ACCOUNTING=y
CONFIG_MODULES_USE_ELF_REL=y
CONFIG_CLONE_BACKWARDS=y
CONFIG_OLD_SIGSUSPEND3=y
CONFIG_OLD_SIGACTION=y

#
# GCOV-based kernel profiling
#
# CONFIG_GCOV_KERNEL is not set
CONFIG_HAVE_GENERIC_DMA_COHERENT=y
CONFIG_RT_MUTEXES=y
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_FORCE_LOAD is not set
CONFIG_MODULE_UNLOAD=y
# CONFIG_MODULE_FORCE_UNLOAD is not set
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
# CONFIG_MODULE_SIG is not set
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBDAF=y
# CONFIG_BLK_DEV_BSG is not set
# CONFIG_BLK_DEV_BSGLIB is not set
# CONFIG_BLK_DEV_INTEGRITY is not set
# CONFIG_BLK_CMDLINE_PARSER is not set

#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
CONFIG_EFI_PARTITION=y

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_UNINLINE_SPIN_UNLOCK=y
CONFIG_FREEZER=y

#
# System Type
#
CONFIG_MMU=y
CONFIG_ARCH_MULTIPLATFORM=y
# CONFIG_ARCH_INTEGRATOR is not set
# CONFIG_ARCH_REALVIEW is not set
# CONFIG_ARCH_VERSATILE is not set
# CONFIG_ARCH_AT91 is not set
# CONFIG_ARCH_CLPS711X is not set
# CONFIG_ARCH_GEMINI is not set
# CONFIG_ARCH_EBSA110 is not set
# CONFIG_ARCH_EP93XX is not set
# CONFIG_ARCH_FOOTBRIDGE is not set
# CONFIG_ARCH_NETX is not set
# CONFIG_ARCH_IOP13XX is not set
# CONFIG_ARCH_IOP32X is not set
# CONFIG_ARCH_IOP33X is not set
# CONFIG_ARCH_IXP4XX is not set
# CONFIG_ARCH_DOVE is not set
# CONFIG_ARCH_KIRKWOOD is not set
# CONFIG_ARCH_MV78XX0 is not set
# CONFIG_ARCH_ORION5X is not set
# CONFIG_ARCH_MMP is not set
# CONFIG_ARCH_KS8695 is not set
# CONFIG_ARCH_W90X900 is not set
# CONFIG_ARCH_LPC32XX is not set
# CONFIG_ARCH_PXA is not set
# CONFIG_ARCH_MSM is not set
# CONFIG_ARCH_SHMOBILE is not set
# CONFIG_ARCH_RPC is not set
# CONFIG_ARCH_SA1100 is not set
# CONFIG_ARCH_S3C24XX is not set
# CONFIG_ARCH_S3C64XX is not set
# CONFIG_ARCH_S5P64X0 is not set
# CONFIG_ARCH_S5PC100 is not set
# CONFIG_ARCH_S5PV210 is not set
# CONFIG_ARCH_EXYNOS is not set
# CONFIG_ARCH_SHARK is not set
# CONFIG_ARCH_DAVINCI is not set
# CONFIG_ARCH_OMAP1 is not set

#
# Multiple platform selection
#

#
# CPU Core family selection
#
CONFIG_ARCH_MULTI_V6=y
CONFIG_ARCH_MULTI_V7=y
CONFIG_ARCH_MULTI_V6_V7=y
# CONFIG_ARCH_MULTI_CPU_AUTO is not set
# CONFIG_ARCH_MVEBU is not set
# CONFIG_ARCH_BCM is not set
# CONFIG_ARCH_BCM2835 is not set
# CONFIG_ARCH_CNS3XXX is not set
# CONFIG_GPIO_PCA953X is not set
# CONFIG_KEYBOARD_GPIO_POLLED is not set
# CONFIG_ARCH_HIGHBANK is not set
# CONFIG_ARCH_KEYSTONE is not set
CONFIG_ARCH_MXC=y

#
# Freescale i.MX support
#
# CONFIG_MXC_IRQ_PRIOR is not set
CONFIG_MXC_TZIC=y
CONFIG_MXC_AVIC=y
CONFIG_MXC_DEBUG_BOARD=y
CONFIG_HAVE_EPIT=y
# CONFIG_MXC_USE_EPIT is not set
CONFIG_ARCH_HAS_RNGA=y
CONFIG_HAVE_IMX_ANATOP=y
CONFIG_HAVE_IMX_GPC=y
CONFIG_HAVE_IMX_MMDC=y
CONFIG_HAVE_IMX_SRC=y
CONFIG_ARCH_MXC_IOMUX_V3=y
CONFIG_SOC_IMX31=y
CONFIG_SOC_IMX35=y
CONFIG_SOC_IMX5=y
CONFIG_SOC_IMX51=y

#
# MX31 platforms:
#
CONFIG_MACH_MX31ADS=y
CONFIG_MACH_MX31LILLY=y
CONFIG_MACH_MX31LITE=y
CONFIG_MACH_PCM037=y
CONFIG_MACH_PCM037_EET=y
CONFIG_MACH_MX31_3DS=y
# CONFIG_MACH_MX31_3DS_MXC_NAND_USE_BBT is not set
CONFIG_MACH_MX31MOBOARD=y
CONFIG_MACH_QONG=y
CONFIG_MACH_ARMADILLO5X0=y
CONFIG_MACH_KZM_ARM11_01=y
CONFIG_MACH_BUG=y
CONFIG_MACH_IMX31_DT=y

#
# MX35 platforms:
#
CONFIG_MACH_PCM043=y
CONFIG_MACH_MX35_3DS=y
# CONFIG_MACH_EUKREA_CPUIMX35SD is not set
CONFIG_MACH_VPR200=y

#
# i.MX51 machines:
#
CONFIG_MACH_IMX51_DT=y
# CONFIG_MACH_MX51_BABBAGE is not set
CONFIG_MACH_EUKREA_CPUIMX51SD=y
CONFIG_MACH_EUKREA_MBIMXSD51_BASEBOARD=y

#
# Device tree only
#
CONFIG_SOC_IMX53=y
CONFIG_SOC_IMX6Q=y
CONFIG_SOC_IMX6SL=y
CONFIG_SOC_VF610=y
CONFIG_IMX_HAVE_PLATFORM_FEC=y
CONFIG_IMX_HAVE_PLATFORM_FLEXCAN=y
CONFIG_IMX_HAVE_PLATFORM_FSL_USB2_UDC=y
CONFIG_IMX_HAVE_PLATFORM_GPIO_KEYS=y
CONFIG_IMX_HAVE_PLATFORM_IMX2_WDT=y
CONFIG_IMX_HAVE_PLATFORM_IMX_FB=y
CONFIG_IMX_HAVE_PLATFORM_IMX_I2C=y
CONFIG_IMX_HAVE_PLATFORM_IMX_KEYPAD=y
CONFIG_IMX_HAVE_PLATFORM_IMX_SSI=y
CONFIG_IMX_HAVE_PLATFORM_IMX_UART=y
CONFIG_IMX_HAVE_PLATFORM_IPU_CORE=y
CONFIG_IMX_HAVE_PLATFORM_MXC_EHCI=y
CONFIG_IMX_HAVE_PLATFORM_MXC_MMC=y
CONFIG_IMX_HAVE_PLATFORM_MXC_NAND=y
CONFIG_IMX_HAVE_PLATFORM_MXC_RNGA=y
CONFIG_IMX_HAVE_PLATFORM_MXC_RTC=y
CONFIG_IMX_HAVE_PLATFORM_MXC_W1=y
CONFIG_IMX_HAVE_PLATFORM_SDHCI_ESDHC_IMX=y
CONFIG_IMX_HAVE_PLATFORM_SPI_IMX=y
# CONFIG_ARCH_OMAP2 is not set
# CONFIG_ARCH_OMAP3 is not set
# CONFIG_ARCH_OMAP4 is not set
# CONFIG_SOC_OMAP5 is not set
# CONFIG_SOC_AM33XX is not set
# CONFIG_SOC_AM43XX is not set
# CONFIG_ARCH_PICOXCELL is not set
# CONFIG_ARCH_ROCKCHIP is not set
# CONFIG_ARCH_SOCFPGA is not set
# CONFIG_PLAT_SPEAR is not set
# CONFIG_ARCH_STI is not set
# CONFIG_ARCH_SHMOBILE_MULTI is not set
# CONFIG_ARCH_SUNXI is not set
# CONFIG_ARCH_SIRF is not set
# CONFIG_ARCH_TEGRA is not set
# CONFIG_ARCH_U8500 is not set
# CONFIG_ARCH_VEXPRESS is not set
# CONFIG_ARCH_VIRT is not set
# CONFIG_ARCH_WM8750 is not set
# CONFIG_ARCH_WM8850 is not set
# CONFIG_ARCH_ZYNQ is not set

#
# Processor Type
#
CONFIG_CPU_V6=y
CONFIG_CPU_V6K=y
CONFIG_CPU_V7=y
CONFIG_CPU_32v6=y
CONFIG_CPU_32v6K=y
CONFIG_CPU_32v7=y
CONFIG_CPU_ABRT_EV6=y
CONFIG_CPU_ABRT_EV7=y
CONFIG_CPU_PABRT_V6=y
CONFIG_CPU_PABRT_V7=y
CONFIG_CPU_CACHE_V6=y
CONFIG_CPU_CACHE_V7=y
CONFIG_CPU_CACHE_VIPT=y
CONFIG_CPU_COPY_V6=y
CONFIG_CPU_TLB_V6=y
CONFIG_CPU_TLB_V7=y
CONFIG_CPU_HAS_ASID=y
CONFIG_CPU_CP15=y
CONFIG_CPU_CP15_MMU=y
CONFIG_CPU_USE_DOMAINS=y

#
# Processor Features
#
# CONFIG_ARCH_PHYS_ADDR_T_64BIT is not set
CONFIG_ARM_THUMB=y
# CONFIG_ARM_THUMBEE is not set
CONFIG_ARM_VIRT_EXT=y
# CONFIG_CPU_ICACHE_DISABLE is not set
# CONFIG_CPU_DCACHE_DISABLE is not set
# CONFIG_CPU_BPREDICT_DISABLE is not set
CONFIG_KUSER_HELPERS=y
CONFIG_DMA_CACHE_RWFO=y
CONFIG_OUTER_CACHE=y
CONFIG_OUTER_CACHE_SYNC=y
CONFIG_MIGHT_HAVE_CACHE_L2X0=y
CONFIG_CACHE_L2X0=y
CONFIG_ARM_L1_CACHE_SHIFT_6=y
CONFIG_ARM_L1_CACHE_SHIFT=6
CONFIG_ARM_DMA_MEM_BUFFERABLE=y
CONFIG_ARM_NR_BANKS=8
CONFIG_MULTI_IRQ_HANDLER=y
# CONFIG_ARM_ERRATA_326103 is not set
# CONFIG_ARM_ERRATA_411920 is not set
# CONFIG_ARM_ERRATA_430973 is not set
# CONFIG_PL310_ERRATA_588369 is not set
# CONFIG_ARM_ERRATA_643719 is not set
# CONFIG_ARM_ERRATA_720789 is not set
# CONFIG_PL310_ERRATA_727915 is not set
CONFIG_ARM_ERRATA_754322=y
# CONFIG_ARM_ERRATA_754327 is not set
# CONFIG_ARM_ERRATA_364296 is not set
CONFIG_ARM_ERRATA_764369=y
# CONFIG_PL310_ERRATA_769419 is not set
CONFIG_ARM_ERRATA_775420=y
# CONFIG_ARM_ERRATA_798181 is not set
# CONFIG_ARM_ERRATA_773022 is not set

#
# Bus support
#
# CONFIG_PCI_SYSCALL is not set
# CONFIG_PCCARD is not set

#
# Kernel Features
#
CONFIG_HAVE_SMP=y
CONFIG_SMP=y
CONFIG_SMP_ON_UP=y
CONFIG_ARM_CPU_TOPOLOGY=y
# CONFIG_SCHED_MC is not set
# CONFIG_SCHED_SMT is not set
CONFIG_HAVE_ARM_SCU=y
# CONFIG_HAVE_ARM_ARCH_TIMER is not set
CONFIG_HAVE_ARM_TWD=y
# CONFIG_MCPM is not set
# CONFIG_VMSPLIT_3G is not set
CONFIG_VMSPLIT_2G=y
# CONFIG_VMSPLIT_1G is not set
CONFIG_PAGE_OFFSET=0x80000000
CONFIG_NR_CPUS=4
CONFIG_HOTPLUG_CPU=y
# CONFIG_ARM_PSCI is not set
CONFIG_ARCH_NR_GPIO=0
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
CONFIG_PREEMPT_COUNT=y
CONFIG_HZ_FIXED=0
CONFIG_HZ_100=y
# CONFIG_HZ_200 is not set
# CONFIG_HZ_250 is not set
# CONFIG_HZ_300 is not set
# CONFIG_HZ_500 is not set
# CONFIG_HZ_1000 is not set
CONFIG_HZ=100
CONFIG_SCHED_HRTICK=y
CONFIG_AEABI=y
# CONFIG_OABI_COMPAT is not set
# CONFIG_ARCH_SPARSEMEM_DEFAULT is not set
# CONFIG_ARCH_SELECT_MEMORY_MODEL is not set
CONFIG_HAVE_ARCH_PFN_VALID=y
# CONFIG_HIGHMEM is not set
# CONFIG_HW_PERF_EVENTS is not set
CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_HAVE_MEMBLOCK=y
# CONFIG_HAVE_BOOTMEM_INFO_NODE is not set
CONFIG_PAGEFLAGS_EXTENDED=y
CONFIG_SPLIT_PTLOCK_CPUS=999999
CONFIG_COMPACTION=y
CONFIG_MIGRATION=y
# CONFIG_PHYS_ADDR_T_64BIT is not set
CONFIG_ZONE_DMA_FLAG=0
# CONFIG_KSM is not set
CONFIG_DEFAULT_MMAP_MIN_ADDR=4096
CONFIG_CROSS_MEMORY_ATTACH=y
# CONFIG_CLEANCACHE is not set
# CONFIG_FRONTSWAP is not set
# CONFIG_CMA is not set
# CONFIG_ZBUD is not set
CONFIG_FORCE_MAX_ZONEORDER=11
CONFIG_ALIGNMENT_TRAP=y
# CONFIG_UACCESS_WITH_MEMCPY is not set
# CONFIG_SECCOMP is not set
# CONFIG_CC_STACKPROTECTOR is not set

#
# Boot options
#
CONFIG_USE_OF=y
CONFIG_ATAGS=y
# CONFIG_DEPRECATED_PARAM_STRUCT is not set
CONFIG_ZBOOT_ROM_TEXT=0
CONFIG_ZBOOT_ROM_BSS=0
# CONFIG_ARM_APPENDED_DTB is not set
CONFIG_CMDLINE="noinitrd console=ttymxc0,115200"
CONFIG_CMDLINE_FROM_BOOTLOADER=y
# CONFIG_CMDLINE_EXTEND is not set
# CONFIG_CMDLINE_FORCE is not set
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_AUTO_ZRELADDR=y

#
# CPU Power Management
#

#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_GOV_POWERSAVE is not set
# CONFIG_CPU_FREQ_GOV_USERSPACE is not set
# CONFIG_CPU_FREQ_GOV_ONDEMAND is not set
# CONFIG_CPU_FREQ_GOV_CONSERVATIVE is not set
# CONFIG_GENERIC_CPUFREQ_CPU0 is not set

#
# ARM CPU frequency scaling drivers
#
# CONFIG_ARM_BIG_LITTLE_CPUFREQ is not set
CONFIG_ARM_IMX6Q_CPUFREQ=y
# CONFIG_ARM_KIRKWOOD_CPUFREQ is not set

#
# CPU Idle
#
# CONFIG_CPU_IDLE is not set
# CONFIG_ARCH_NEEDS_CPU_IDLE_COUPLED is not set

#
# Floating point emulation
#

#
# At least one emulation must be selected
#
CONFIG_VFP=y
CONFIG_VFPv3=y
CONFIG_NEON=y
# CONFIG_KERNEL_MODE_NEON is not set

#
# Userspace binary formats
#
CONFIG_BINFMT_ELF=y
CONFIG_ARCH_BINFMT_ELF_RANDOMIZE_PIE=y
CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS=y
CONFIG_BINFMT_SCRIPT=y
# CONFIG_HAVE_AOUT is not set
CONFIG_BINFMT_MISC=m
CONFIG_COREDUMP=y

#
# Power management options
#
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM_RUNTIME=y
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
CONFIG_PM_TEST_SUSPEND=y
CONFIG_PM_SLEEP_DEBUG=y
# CONFIG_APM_EMULATION is not set
CONFIG_ARCH_HAS_OPP=y
CONFIG_PM_OPP=y
CONFIG_PM_CLK=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
CONFIG_CPU_PM=y
CONFIG_ARCH_SUSPEND_POSSIBLE=y
CONFIG_ARM_CPU_SUSPEND=y
CONFIG_NET=y

#
# Networking options
#
CONFIG_PACKET=y
# CONFIG_PACKET_DIAG is not set
CONFIG_UNIX=y
# CONFIG_UNIX_DIAG is not set
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
# CONFIG_IP_MULTICAST is not set
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_PNP=y
CONFIG_IP_PNP_DHCP=y
# CONFIG_IP_PNP_BOOTP is not set
# CONFIG_IP_PNP_RARP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE_DEMUX is not set
CONFIG_NET_IP_TUNNEL=y
# CONFIG_SYN_COOKIES is not set
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
CONFIG_INET_TUNNEL=y
# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
# CONFIG_INET_XFRM_MODE_TUNNEL is not set
# CONFIG_INET_XFRM_MODE_BEET is not set
# CONFIG_INET_LRO is not set
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
# CONFIG_INET_UDP_DIAG is not set
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
# CONFIG_IPV6_ROUTER_PREF is not set
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
# CONFIG_IPV6_SIT_6RD is not set
CONFIG_IPV6_NDISC_NODETYPE=y
# CONFIG_IPV6_TUNNEL is not set
# CONFIG_IPV6_GRE is not set
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_IPV6_MROUTE is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETWORK_PHY_TIMESTAMPING is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_NETFILTER_ADVANCED=y

#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK_ACCT is not set
# CONFIG_NETFILTER_NETLINK_QUEUE is not set
# CONFIG_NETFILTER_NETLINK_LOG is not set
# CONFIG_NF_CONNTRACK is not set
# CONFIG_NETFILTER_XTABLES is not set
# CONFIG_IP_VS is not set

#
# IP: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV4 is not set
# CONFIG_IP_NF_IPTABLES is not set
# CONFIG_IP_NF_ARPTABLES is not set

#
# IPv6: Netfilter Configuration
#
# CONFIG_NF_DEFRAG_IPV6 is not set
# CONFIG_IP6_NF_IPTABLES is not set
# CONFIG_IP_DCCP is not set
# CONFIG_IP_SCTP is not set
# CONFIG_RDS is not set
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
# CONFIG_L2TP is not set
# CONFIG_BRIDGE is not set
CONFIG_HAVE_NET_DSA=y
# CONFIG_VLAN_8021Q is not set
# CONFIG_DECNET is not set
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_PHONET is not set
# CONFIG_IEEE802154 is not set
# CONFIG_NET_SCHED is not set
# CONFIG_DCB is not set
CONFIG_DNS_RESOLVER=y
# CONFIG_BATMAN_ADV is not set
# CONFIG_OPENVSWITCH is not set
# CONFIG_VSOCKETS is not set
# CONFIG_NETLINK_MMAP is not set
# CONFIG_NETLINK_DIAG is not set
# CONFIG_NET_MPLS_GSO is not set
CONFIG_RPS=y
CONFIG_RFS_ACCEL=y
CONFIG_XPS=y
# CONFIG_NETPRIO_CGROUP is not set
CONFIG_NET_RX_BUSY_POLL=y
CONFIG_BQL=y
# CONFIG_BPF_JIT is not set
CONFIG_NET_FLOW_LIMIT=y

#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_NET_TCPPROBE is not set
# CONFIG_NET_DROP_MONITOR is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not set
# CONFIG_BT is not set
# CONFIG_AF_RXRPC is not set
CONFIG_WIRELESS=y
CONFIG_CFG80211=y
# CONFIG_NL80211_TESTMODE is not set
# CONFIG_CFG80211_DEVELOPER_WARNINGS is not set
# CONFIG_CFG80211_REG_DEBUG is not set
# CONFIG_CFG80211_CERTIFICATION_ONUS is not set
CONFIG_CFG80211_DEFAULT_PS=y
# CONFIG_CFG80211_DEBUGFS is not set
# CONFIG_CFG80211_INTERNAL_REGDB is not set
# CONFIG_CFG80211_WEXT is not set
# CONFIG_LIB80211 is not set
CONFIG_MAC80211=y
CONFIG_MAC80211_HAS_RC=y
# CONFIG_MAC80211_RC_PID is not set
CONFIG_MAC80211_RC_MINSTREL=y
CONFIG_MAC80211_RC_MINSTREL_HT=y
CONFIG_MAC80211_RC_DEFAULT_MINSTREL=y
CONFIG_MAC80211_RC_DEFAULT="minstrel_ht"
# CONFIG_MAC80211_MESH is not set
# CONFIG_MAC80211_LEDS is not set
# CONFIG_MAC80211_DEBUGFS is not set
# CONFIG_MAC80211_MESSAGE_TRACING is not set
# CONFIG_MAC80211_DEBUG_MENU is not set
# CONFIG_WIMAX is not set
CONFIG_RFKILL=y
CONFIG_RFKILL_INPUT=y
# CONFIG_RFKILL_REGULATOR is not set
# CONFIG_RFKILL_GPIO is not set
# CONFIG_NET_9P is not set
# CONFIG_CAIF is not set
# CONFIG_CEPH_LIB is not set
# CONFIG_NFC is not set
CONFIG_HAVE_BPF_JIT=y

#
# Device Drivers
#

#
# Generic Driver Options
#
CONFIG_UEVENT_HELPER_PATH=""
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
# CONFIG_STANDALONE is not set
CONFIG_PREVENT_FIRMWARE_BUILD=y
CONFIG_FW_LOADER=y
CONFIG_FIRMWARE_IN_KERNEL=y
CONFIG_EXTRA_FIRMWARE=""
CONFIG_FW_LOADER_USER_HELPER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_GENERIC_CPU_DEVICES is not set
CONFIG_REGMAP=y
CONFIG_REGMAP_I2C=y
CONFIG_REGMAP_SPI=y
CONFIG_REGMAP_MMIO=y
CONFIG_REGMAP_IRQ=y
CONFIG_DMA_SHARED_BUFFER=y

#
# Bus devices
#
CONFIG_IMX_WEIM=y
# CONFIG_ARM_CCI is not set
CONFIG_CONNECTOR=y
CONFIG_PROC_EVENTS=y
CONFIG_MTD=y
# CONFIG_MTD_TESTS is not set
# CONFIG_MTD_REDBOOT_PARTS is not set
CONFIG_MTD_CMDLINE_PARTS=y
# CONFIG_MTD_AFS_PARTS is not set
CONFIG_MTD_OF_PARTS=y
# CONFIG_MTD_AR7_PARTS is not set

#
# User Modules And Translation Layers
#
CONFIG_MTD_BLKDEVS=y
CONFIG_MTD_BLOCK=y
# CONFIG_FTL is not set
# CONFIG_NFTL is not set
# CONFIG_INFTL is not set
# CONFIG_RFD_FTL is not set
# CONFIG_SSFDC is not set
# CONFIG_SM_FTL is not set
# CONFIG_MTD_OOPS is not set
# CONFIG_MTD_SWAP is not set

#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=y
CONFIG_MTD_JEDECPROBE=y
CONFIG_MTD_GEN_PROBE=y
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=y
CONFIG_MTD_CFI_AMDSTD=y
CONFIG_MTD_CFI_STAA=y
CONFIG_MTD_CFI_UTIL=y
# CONFIG_MTD_RAM is not set
# CONFIG_MTD_ROM is not set
# CONFIG_MTD_ABSENT is not set

#
# Mapping drivers for chip access
#
# CONFIG_MTD_COMPLEX_MAPPINGS is not set
# CONFIG_MTD_PHYSMAP is not set
CONFIG_MTD_PHYSMAP_OF=y
# CONFIG_MTD_IMPA7 is not set
# CONFIG_MTD_PLATRAM is not set

#
# Self-contained MTD device drivers
#
CONFIG_MTD_DATAFLASH=y
# CONFIG_MTD_DATAFLASH_WRITE_VERIFY is not set
# CONFIG_MTD_DATAFLASH_OTP is not set
CONFIG_MTD_M25P80=y
CONFIG_M25PXX_USE_FAST_READ=y
CONFIG_MTD_SST25L=y
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
# CONFIG_MTD_BLOCK2MTD is not set

#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOCG3 is not set
CONFIG_MTD_NAND_ECC=y
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND=y
# CONFIG_MTD_NAND_ECC_BCH is not set
# CONFIG_MTD_SM_COMMON is not set
# CONFIG_MTD_NAND_DENALI is not set
# CONFIG_MTD_NAND_GPIO is not set
CONFIG_MTD_NAND_IDS=y
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_DOCG4 is not set
# CONFIG_MTD_NAND_NANDSIM is not set
CONFIG_MTD_NAND_GPMI_NAND=y
# CONFIG_MTD_NAND_PLATFORM is not set
CONFIG_MTD_NAND_MXC=y
# CONFIG_MTD_ONENAND is not set

#
# LPDDR flash memory drivers
#
# CONFIG_MTD_LPDDR is not set
CONFIG_MTD_UBI=y
CONFIG_MTD_UBI_WL_THRESHOLD=4096
CONFIG_MTD_UBI_BEB_LIMIT=20
# CONFIG_MTD_UBI_FASTMAP is not set
# CONFIG_MTD_UBI_GLUEBI is not set
CONFIG_DTC=y
CONFIG_OF=y

#
# Device Tree and Open Firmware support
#
# CONFIG_PROC_DEVICETREE is not set
# CONFIG_OF_SELFTEST is not set
CONFIG_OF_FLATTREE=y
CONFIG_OF_EARLY_FLATTREE=y
CONFIG_OF_ADDRESS=y
CONFIG_OF_IRQ=y
CONFIG_OF_NET=y
CONFIG_OF_MDIO=y
CONFIG_OF_MTD=y
# CONFIG_PARPORT is not set
CONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
CONFIG_BLK_DEV_LOOP_MIN_COUNT=8
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
# CONFIG_BLK_DEV_DRBD is not set
# CONFIG_BLK_DEV_NBD is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=16
CONFIG_BLK_DEV_RAM_SIZE=65536
# CONFIG_BLK_DEV_XIP is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MG_DISK is not set
# CONFIG_BLK_DEV_RBD is not set

#
# Misc devices
#
# CONFIG_SENSORS_LIS3LV02D is not set
# CONFIG_AD525X_DPOT is not set
# CONFIG_ATMEL_PWM is not set
# CONFIG_DUMMY_IRQ is not set
# CONFIG_ICS932S401 is not set
# CONFIG_ATMEL_SSC is not set
# CONFIG_ENCLOSURE_SERVICES is not set
# CONFIG_APDS9802ALS is not set
# CONFIG_ISL29003 is not set
# CONFIG_ISL29020 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_SENSORS_BH1780 is not set
# CONFIG_SENSORS_BH1770 is not set
# CONFIG_SENSORS_APDS990X is not set
# CONFIG_HMC6352 is not set
# CONFIG_DS1682 is not set
# CONFIG_TI_DAC7512 is not set
# CONFIG_BMP085_I2C is not set
# CONFIG_BMP085_SPI is not set
# CONFIG_USB_SWITCH_FSA9480 is not set
# CONFIG_LATTICE_ECP3_CONFIG is not set
CONFIG_SRAM=y
# CONFIG_C2PORT is not set

#
# EEPROM support
#
CONFIG_EEPROM_AT24=y
CONFIG_EEPROM_AT25=y
# CONFIG_EEPROM_LEGACY is not set
# CONFIG_EEPROM_MAX6875 is not set
# CONFIG_EEPROM_93CX6 is not set
# CONFIG_EEPROM_93XX46 is not set

#
# Texas Instruments shared transport line discipline
#
# CONFIG_TI_ST is not set
# CONFIG_SENSORS_LIS3_SPI is not set
# CONFIG_SENSORS_LIS3_I2C is not set

#
# Altera FPGA firmware download module
#
# CONFIG_ALTERA_STAPL is not set

#
# SCSI device support
#
CONFIG_SCSI_MOD=y
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
# CONFIG_SCSI_PROC_FS is not set

#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not set
# CONFIG_CHR_DEV_SCH is not set
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
CONFIG_SCSI_LOGGING=y
CONFIG_SCSI_SCAN_ASYNC=y

#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not set
# CONFIG_SCSI_DH is not set
# CONFIG_SCSI_OSD_INITIATOR is not set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_VERBOSE_ERROR=y
CONFIG_SATA_PMP=y

#
# Controllers with non-SFF native interface
#
CONFIG_SATA_AHCI_PLATFORM=y
CONFIG_AHCI_IMX=y
CONFIG_ATA_SFF=y

#
# SFF controllers with custom DMA interface
#
CONFIG_ATA_BMDMA=y

#
# SATA SFF controllers with BMDMA
#
# CONFIG_SATA_HIGHBANK is not set
# CONFIG_SATA_MV is not set
# CONFIG_SATA_RCAR is not set

#
# PATA SFF controllers with BMDMA
#
# CONFIG_PATA_ARASAN_CF is not set
CONFIG_PATA_IMX=y

#
# PIO-only SFF controllers
#
# CONFIG_PATA_PLATFORM is not set

#
# Generic fallback / legacy drivers
#
# CONFIG_MD is not set
# CONFIG_TARGET_CORE is not set
CONFIG_NETDEVICES=y
CONFIG_MII=y
CONFIG_NET_CORE=y
# CONFIG_BONDING is not set
# CONFIG_DUMMY is not set
# CONFIG_EQUALIZER is not set
# CONFIG_NET_TEAM is not set
# CONFIG_MACVLAN is not set
# CONFIG_VXLAN is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not set
# CONFIG_TUN is not set
# CONFIG_VETH is not set
# CONFIG_NLMON is not set

#
# CAIF transport drivers
#

#
# Distributed Switch Architecture drivers
#
# CONFIG_NET_DSA_MV88E6XXX is not set
# CONFIG_NET_DSA_MV88E6060 is not set
# CONFIG_NET_DSA_MV88E6XXX_NEED_PPU is not set
# CONFIG_NET_DSA_MV88E6131 is not set
# CONFIG_NET_DSA_MV88E6123_61_65 is not set
CONFIG_ETHERNET=y
CONFIG_NET_VENDOR_ARC=y
# CONFIG_ARC_EMAC is not set
CONFIG_NET_CADENCE=y
# CONFIG_ARM_AT91_ETHER is not set
# CONFIG_MACB is not set
# CONFIG_NET_VENDOR_BROADCOM is not set
# CONFIG_NET_CALXEDA_XGMAC is not set
CONFIG_NET_VENDOR_CIRRUS=y
CONFIG_CS89x0=y
CONFIG_CS89x0_PLATFORM=y
# CONFIG_DM9000 is not set
# CONFIG_DNET is not set
# CONFIG_NET_VENDOR_FARADAY is not set
CONFIG_NET_VENDOR_FREESCALE=y
CONFIG_FEC=y
# CONFIG_NET_VENDOR_INTEL is not set
# CONFIG_NET_VENDOR_MARVELL is not set
# CONFIG_NET_VENDOR_MICREL is not set
# CONFIG_NET_VENDOR_MICROCHIP is not set
# CONFIG_NET_VENDOR_NATSEMI is not set
# CONFIG_ETHOC is not set
# CONFIG_SH_ETH is not set
# CONFIG_NET_VENDOR_SEEQ is not set
CONFIG_NET_VENDOR_SMSC=y
CONFIG_SMC91X=y
CONFIG_SMC911X=y
CONFIG_SMSC911X=y
# CONFIG_SMSC911X_ARCH_HOOKS is not set
# CONFIG_NET_VENDOR_STMICRO is not set
CONFIG_NET_VENDOR_VIA=y
# CONFIG_VIA_VELOCITY is not set
CONFIG_NET_VENDOR_WIZNET=y
# CONFIG_WIZNET_W5100 is not set
# CONFIG_WIZNET_W5300 is not set
CONFIG_PHYLIB=y

#
# MII PHY device drivers
#
# CONFIG_AT803X_PHY is not set
# CONFIG_AMD_PHY is not set
# CONFIG_MARVELL_PHY is not set
# CONFIG_DAVICOM_PHY is not set
# CONFIG_QSEMI_PHY is not set
# CONFIG_LXT_PHY is not set
# CONFIG_CICADA_PHY is not set
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_BCM87XX_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_REALTEK_PHY is not set
# CONFIG_NATIONAL_PHY is not set
# CONFIG_STE10XP is not set
# CONFIG_LSI_ET1011C_PHY is not set
# CONFIG_MICREL_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not set
# CONFIG_MDIO_BUS_MUX_GPIO is not set
# CONFIG_MDIO_BUS_MUX_MMIOREG is not set
# CONFIG_MICREL_KS8995MA is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
CONFIG_WLAN=y
# CONFIG_LIBERTAS_THINFIRM is not set
# CONFIG_MAC80211_HWSIM is not set
# CONFIG_ATH_CARDS is not set
# CONFIG_B43 is not set
# CONFIG_B43LEGACY is not set
CONFIG_BRCMUTIL=m
CONFIG_BRCMFMAC=m
CONFIG_BRCMFMAC_SDIO=y
# CONFIG_BRCM_TRACING is not set
# CONFIG_BRCMDBG is not set
# CONFIG_HOSTAP is not set
# CONFIG_LIBERTAS is not set
# CONFIG_P54_COMMON is not set
# CONFIG_RT2X00 is not set
# CONFIG_WL_TI is not set
# CONFIG_MWIFIEX is not set
# CONFIG_CW1200 is not set

#
# Enable WiMAX (Networking options) to see the WiMAX drivers
#
# CONFIG_WAN is not set
# CONFIG_ISDN is not set

#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
CONFIG_INPUT_POLLDEV=y
# CONFIG_INPUT_SPARSEKMAP is not set
CONFIG_INPUT_MATRIXKMAP=y

#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
# CONFIG_INPUT_MOUSEDEV_PSAUX is not set
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=m

#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
# CONFIG_KEYBOARD_ADP5588 is not set
# CONFIG_KEYBOARD_ADP5589 is not set
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_QT1070 is not set
# CONFIG_KEYBOARD_QT2160 is not set
# CONFIG_KEYBOARD_LKKBD is not set
CONFIG_KEYBOARD_GPIO=y
# CONFIG_KEYBOARD_TCA6416 is not set
# CONFIG_KEYBOARD_TCA8418 is not set
# CONFIG_KEYBOARD_MATRIX is not set
# CONFIG_KEYBOARD_LM8323 is not set
# CONFIG_KEYBOARD_LM8333 is not set
# CONFIG_KEYBOARD_MAX7359 is not set
# CONFIG_KEYBOARD_MCS is not set
# CONFIG_KEYBOARD_MPR121 is not set
CONFIG_KEYBOARD_IMX=y
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_OPENCORES is not set
# CONFIG_KEYBOARD_SAMSUNG is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=m
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
CONFIG_MOUSE_PS2_CYPRESS=y
CONFIG_MOUSE_PS2_TRACKPOINT=y
CONFIG_MOUSE_PS2_ELANTECH=y
# CONFIG_MOUSE_PS2_SENTELIC is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_CYAPA is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_MOUSE_GPIO is not set
# CONFIG_MOUSE_SYNAPTICS_I2C is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
CONFIG_INPUT_TOUCHSCREEN=y
# CONFIG_TOUCHSCREEN_ADS7846 is not set
# CONFIG_TOUCHSCREEN_AD7877 is not set
# CONFIG_TOUCHSCREEN_AD7879 is not set
# CONFIG_TOUCHSCREEN_ATMEL_MXT is not set
# CONFIG_TOUCHSCREEN_AUO_PIXCIR is not set
# CONFIG_TOUCHSCREEN_BU21013 is not set
# CONFIG_TOUCHSCREEN_CY8CTMG110 is not set
# CONFIG_TOUCHSCREEN_CYTTSP_CORE is not set
# CONFIG_TOUCHSCREEN_CYTTSP4_CORE is not set
# CONFIG_TOUCHSCREEN_DA9052 is not set
# CONFIG_TOUCHSCREEN_DYNAPRO is not set
# CONFIG_TOUCHSCREEN_HAMPSHIRE is not set
# CONFIG_TOUCHSCREEN_EETI is not set
CONFIG_TOUCHSCREEN_EGALAX=y
# CONFIG_TOUCHSCREEN_FUJITSU is not set
# CONFIG_TOUCHSCREEN_ILI210X is not set
# CONFIG_TOUCHSCREEN_GUNZE is not set
# CONFIG_TOUCHSCREEN_ELO is not set
# CONFIG_TOUCHSCREEN_WACOM_W8001 is not set
# CONFIG_TOUCHSCREEN_WACOM_I2C is not set
# CONFIG_TOUCHSCREEN_MAX11801 is not set
# CONFIG_TOUCHSCREEN_MCS5000 is not set
# CONFIG_TOUCHSCREEN_MMS114 is not set
# CONFIG_TOUCHSCREEN_MTOUCH is not set
# CONFIG_TOUCHSCREEN_INEXIO is not set
# CONFIG_TOUCHSCREEN_MK712 is not set
# CONFIG_TOUCHSCREEN_PENMOUNT is not set
# CONFIG_TOUCHSCREEN_EDT_FT5X06 is not set
# CONFIG_TOUCHSCREEN_TOUCHRIGHT is not set
# CONFIG_TOUCHSCREEN_TOUCHWIN is not set
# CONFIG_TOUCHSCREEN_PIXCIR is not set
# CONFIG_TOUCHSCREEN_WM97XX is not set
CONFIG_TOUCHSCREEN_MC13783=y
# CONFIG_TOUCHSCREEN_TOUCHIT213 is not set
# CONFIG_TOUCHSCREEN_TSC_SERIO is not set
# CONFIG_TOUCHSCREEN_TSC2005 is not set
# CONFIG_TOUCHSCREEN_TSC2007 is not set
# CONFIG_TOUCHSCREEN_W90X900 is not set
# CONFIG_TOUCHSCREEN_ST1232 is not set
# CONFIG_TOUCHSCREEN_TPS6507X is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_AD714X is not set
# CONFIG_INPUT_BMA150 is not set
# CONFIG_INPUT_MC13783_PWRBUTTON is not set
CONFIG_INPUT_MMA8450=y
# CONFIG_INPUT_MPU3050 is not set
# CONFIG_INPUT_GP2A is not set
# CONFIG_INPUT_GPIO_TILT_POLLED is not set
# CONFIG_INPUT_KXTJ9 is not set
# CONFIG_INPUT_UINPUT is not set
# CONFIG_INPUT_PCF8574 is not set
# CONFIG_INPUT_PWM_BEEPER is not set
# CONFIG_INPUT_GPIO_ROTARY_ENCODER is not set
# CONFIG_INPUT_DA9052_ONKEY is not set
# CONFIG_INPUT_ADXL34X is not set
# CONFIG_INPUT_CMA3000 is not set

#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_SERPORT=m
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_SERIO_ALTERA_PS2 is not set
# CONFIG_SERIO_PS2MULT is not set
# CONFIG_SERIO_ARC_PS2 is not set
# CONFIG_SERIO_APBPS2 is not set
# CONFIG_SERIO_OLPC_APSP is not set
# CONFIG_GAMEPORT is not set

#
# Character devices
#
CONFIG_TTY=y
CONFIG_VT=y
CONFIG_CONSOLE_TRANSLATIONS=y
CONFIG_VT_CONSOLE=y
CONFIG_VT_CONSOLE_SLEEP=y
CONFIG_HW_CONSOLE=y
CONFIG_VT_HW_CONSOLE_BINDING=y
CONFIG_UNIX98_PTYS=y
# CONFIG_DEVPTS_MULTIPLE_INSTANCES is not set
# CONFIG_LEGACY_PTYS is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_N_GSM is not set
# CONFIG_TRACE_SINK is not set
# CONFIG_DEVKMEM is not set

#
# Serial drivers
#
# CONFIG_SERIAL_8250 is not set

#
# Non-8250 serial port support
#
# CONFIG_SERIAL_MAX3100 is not set
# CONFIG_SERIAL_MAX310X is not set
CONFIG_SERIAL_IMX=y
CONFIG_SERIAL_IMX_CONSOLE=y
CONFIG_SERIAL_CORE=y
CONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_SCCNXP is not set
# CONFIG_SERIAL_TIMBERDALE is not set
# CONFIG_SERIAL_ALTERA_JTAGUART is not set
# CONFIG_SERIAL_ALTERA_UART is not set
# CONFIG_SERIAL_IFX6X60 is not set
# CONFIG_SERIAL_XILINX_PS_UART is not set
# CONFIG_SERIAL_ARC is not set
CONFIG_SERIAL_FSL_LPUART=y
CONFIG_SERIAL_FSL_LPUART_CONSOLE=y
# CONFIG_SERIAL_ST_ASC is not set
# CONFIG_TTY_PRINTK is not set
# CONFIG_HVC_DCC is not set
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_TIMERIOMEM is not set
# CONFIG_HW_RANDOM_ATMEL is not set
CONFIG_HW_RANDOM_MXC_RNGA=y
# CONFIG_HW_RANDOM_EXYNOS is not set
# CONFIG_R3964 is not set
# CONFIG_RAW_DRIVER is not set
# CONFIG_TCG_TPM is not set
CONFIG_I2C=y
CONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_COMPAT is not set
CONFIG_I2C_CHARDEV=y
# CONFIG_I2C_MUX is not set
# CONFIG_I2C_HELPER_AUTO is not set
# CONFIG_I2C_SMBUS is not set

#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
CONFIG_I2C_ALGOPCF=m
CONFIG_I2C_ALGOPCA=m

#
# I2C Hardware Bus support
#

#
# I2C system bus drivers (mostly embedded / system-on-chip)
#
# CONFIG_I2C_CBUS_GPIO is not set
# CONFIG_I2C_DESIGNWARE_PLATFORM is not set
# CONFIG_I2C_GPIO is not set
CONFIG_I2C_IMX=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PCA_PLATFORM is not set
# CONFIG_I2C_PXA_PCI is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_I2C_XILINX is not set

#
# External I2C/SMBus adapter drivers
#
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_TAOS_EVM is not set

#
# Other I2C/SMBus bus drivers
#
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
CONFIG_SPI=y
# CONFIG_SPI_DEBUG is not set
CONFIG_SPI_MASTER=y

#
# SPI Master Controller Drivers
#
# CONFIG_SPI_ALTERA is not set
CONFIG_SPI_BITBANG=y
# CONFIG_SPI_GPIO is not set
CONFIG_SPI_IMX=y
# CONFIG_SPI_FSL_SPI is not set
# CONFIG_SPI_FSL_DSPI is not set
# CONFIG_SPI_OC_TINY is not set
# CONFIG_SPI_PXA2XX_PCI is not set
# CONFIG_SPI_SC18IS602 is not set
# CONFIG_SPI_XCOMM is not set
# CONFIG_SPI_XILINX is not set
# CONFIG_SPI_DESIGNWARE is not set

#
# SPI Protocol Masters
#
# CONFIG_SPI_SPIDEV is not set
# CONFIG_SPI_TLE62X0 is not set
# CONFIG_HSI is not set

#
# PPS support
#
CONFIG_PPS=y
# CONFIG_PPS_DEBUG is not set

#
# PPS clients support
#
# CONFIG_PPS_CLIENT_KTIMER is not set
# CONFIG_PPS_CLIENT_LDISC is not set
# CONFIG_PPS_CLIENT_GPIO is not set

#
# PPS generators support
#

#
# PTP clock support
#
CONFIG_PTP_1588_CLOCK=y

#
# Enable PHYLIB and NETWORK_PHY_TIMESTAMPING to see the additional clocks.
#
CONFIG_PINCTRL=y

#
# Pin controllers
#
CONFIG_PINMUX=y
CONFIG_PINCONF=y
# CONFIG_DEBUG_PINCTRL is not set
CONFIG_PINCTRL_IMX=y
# CONFIG_PINCTRL_IMX35 is not set
CONFIG_PINCTRL_IMX51=y
CONFIG_PINCTRL_IMX53=y
CONFIG_PINCTRL_IMX6Q=y
CONFIG_PINCTRL_IMX6SL=y
CONFIG_PINCTRL_VF610=y
# CONFIG_PINCTRL_SINGLE is not set
CONFIG_ARCH_HAVE_CUSTOM_GPIO_H=y
CONFIG_ARCH_REQUIRE_GPIOLIB=y
CONFIG_GPIO_DEVRES=y
CONFIG_GPIOLIB=y
CONFIG_OF_GPIO=y
# CONFIG_DEBUG_GPIO is not set
CONFIG_GPIO_SYSFS=y
CONFIG_GPIO_GENERIC=y
# CONFIG_GPIO_DA9052 is not set

#
# Memory mapped GPIO drivers:
#
# CONFIG_GPIO_GENERIC_PLATFORM is not set
# CONFIG_GPIO_EM is not set
CONFIG_GPIO_MXC=y
# CONFIG_GPIO_RCAR is not set
# CONFIG_GPIO_TS5500 is not set
# CONFIG_GPIO_GRGPIO is not set

#
# I2C GPIO expanders:
#
# CONFIG_GPIO_MAX7300 is not set
# CONFIG_GPIO_MAX732X is not set
CONFIG_GPIO_MC9S08DZ60=y
# CONFIG_GPIO_PCF857X is not set
# CONFIG_GPIO_SX150X is not set
# CONFIG_GPIO_ADP5588 is not set
# CONFIG_GPIO_ADNP is not set

#
# PCI GPIO expanders:
#

#
# SPI GPIO expanders:
#
# CONFIG_GPIO_MAX7301 is not set
# CONFIG_GPIO_MCP23S08 is not set
# CONFIG_GPIO_MC33880 is not set
# CONFIG_GPIO_74X164 is not set

#
# AC97 GPIO expanders:
#

#
# LPC GPIO expanders:
#

#
# MODULbus GPIO expanders:
#

#
# USB GPIO expanders:
#
# CONFIG_W1 is not set
# CONFIG_POWER_SUPPLY is not set
# CONFIG_POWER_AVS is not set
# CONFIG_HWMON is not set
# CONFIG_THERMAL is not set
CONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_CORE is not set
# CONFIG_WATCHDOG_NOWAYOUT is not set

#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not set
# CONFIG_DA9052_WATCHDOG is not set
# CONFIG_DW_WATCHDOG is not set
# CONFIG_MAX63XX_WATCHDOG is not set
CONFIG_IMX2_WDT=y
# CONFIG_MEN_A21_WDT is not set
CONFIG_SSB_POSSIBLE=y

#
# Sonics Silicon Backplane
#
# CONFIG_SSB is not set
CONFIG_BCMA_POSSIBLE=y

#
# Broadcom specific AMBA
#
# CONFIG_BCMA is not set

#
# Multifunction device drivers
#
CONFIG_MFD_CORE=y
# CONFIG_MFD_AS3711 is not set
# CONFIG_PMIC_ADP5520 is not set
# CONFIG_MFD_AAT2870_CORE is not set
# CONFIG_MFD_CROS_EC is not set
# CONFIG_MFD_ASIC3 is not set
# CONFIG_PMIC_DA903X is not set
CONFIG_PMIC_DA9052=y
# CONFIG_MFD_DA9052_SPI is not set
CONFIG_MFD_DA9052_I2C=y
# CONFIG_MFD_DA9055 is not set
# CONFIG_MFD_DA9063 is not set
CONFIG_MFD_MC13783=y
CONFIG_MFD_MC13XXX=y
CONFIG_MFD_MC13XXX_SPI=y
CONFIG_MFD_MC13XXX_I2C=y
# CONFIG_HTC_EGPIO is not set
# CONFIG_HTC_PASIC3 is not set
# CONFIG_HTC_I2CPLD is not set
# CONFIG_MFD_KEMPLD is not set
# CONFIG_MFD_88PM800 is not set
# CONFIG_MFD_88PM805 is not set
# CONFIG_MFD_88PM860X is not set
# CONFIG_MFD_MAX77686 is not set
# CONFIG_MFD_MAX77693 is not set
# CONFIG_MFD_MAX8907 is not set
# CONFIG_MFD_MAX8925 is not set
# CONFIG_MFD_MAX8997 is not set
# CONFIG_MFD_MAX8998 is not set
# CONFIG_EZX_PCAP is not set
# CONFIG_MFD_RETU is not set
# CONFIG_MFD_PCF50633 is not set
# CONFIG_UCB1400_CORE is not set
# CONFIG_MFD_RC5T583 is not set
# CONFIG_MFD_SEC_CORE is not set
# CONFIG_MFD_SI476X_CORE is not set
# CONFIG_MFD_SM501 is not set
# CONFIG_MFD_SMSC is not set
# CONFIG_ABX500_CORE is not set
# CONFIG_MFD_STMPE is not set
CONFIG_MFD_SYSCON=y
# CONFIG_MFD_TI_AM335X_TSCADC is not set
# CONFIG_MFD_LP8788 is not set
# CONFIG_MFD_PALMAS is not set
# CONFIG_TPS6105X is not set
# CONFIG_TPS65010 is not set
# CONFIG_TPS6507X is not set
# CONFIG_MFD_TPS65090 is not set
# CONFIG_MFD_TPS65217 is not set
# CONFIG_MFD_TPS6586X is not set
# CONFIG_MFD_TPS65910 is not set
# CONFIG_MFD_TPS65912 is not set
# CONFIG_MFD_TPS65912_I2C is not set
# CONFIG_MFD_TPS65912_SPI is not set
# CONFIG_MFD_TPS80031 is not set
# CONFIG_TWL4030_CORE is not set
# CONFIG_TWL6040_CORE is not set
# CONFIG_MFD_WL1273_CORE is not set
# CONFIG_MFD_LM3533 is not set
# CONFIG_MFD_TC3589X is not set
# CONFIG_MFD_TMIO is not set
# CONFIG_MFD_T7L66XB is not set
# CONFIG_MFD_TC6387XB is not set
# CONFIG_MFD_TC6393XB is not set
# CONFIG_MFD_ARIZONA_I2C is not set
# CONFIG_MFD_ARIZONA_SPI is not set
# CONFIG_MFD_WM8400 is not set
# CONFIG_MFD_WM831X_I2C is not set
# CONFIG_MFD_WM831X_SPI is not set
# CONFIG_MFD_WM8350_I2C is not set
# CONFIG_MFD_WM8994 is not set
# CONFIG_VEXPRESS_CONFIG is not set
CONFIG_REGULATOR=y
# CONFIG_REGULATOR_DEBUG is not set
# CONFIG_REGULATOR_DUMMY is not set
CONFIG_REGULATOR_FIXED_VOLTAGE=y
# CONFIG_REGULATOR_VIRTUAL_CONSUMER is not set
# CONFIG_REGULATOR_USERSPACE_CONSUMER is not set
# CONFIG_REGULATOR_AD5398 is not set
CONFIG_REGULATOR_ANATOP=y
CONFIG_REGULATOR_DA9052=y
# CONFIG_REGULATOR_DA9210 is not set
# CONFIG_REGULATOR_FAN53555 is not set
# CONFIG_REGULATOR_GPIO is not set
# CONFIG_REGULATOR_ISL6271A is not set
# CONFIG_REGULATOR_LP3971 is not set
# CONFIG_REGULATOR_LP3972 is not set
# CONFIG_REGULATOR_LP872X is not set
# CONFIG_REGULATOR_LP8755 is not set
# CONFIG_REGULATOR_MAX1586 is not set
# CONFIG_REGULATOR_MAX8649 is not set
# CONFIG_REGULATOR_MAX8660 is not set
# CONFIG_REGULATOR_MAX8952 is not set
# CONFIG_REGULATOR_MAX8973 is not set
CONFIG_REGULATOR_MC13XXX_CORE=y
CONFIG_REGULATOR_MC13783=y
CONFIG_REGULATOR_MC13892=y
# CONFIG_REGULATOR_PFUZE100 is not set
# CONFIG_REGULATOR_TPS51632 is not set
# CONFIG_REGULATOR_TPS62360 is not set
# CONFIG_REGULATOR_TPS65023 is not set
# CONFIG_REGULATOR_TPS6507X is not set
# CONFIG_REGULATOR_TPS6524X is not set
CONFIG_MEDIA_SUPPORT=y

#
# Multimedia core support
#
CONFIG_MEDIA_CAMERA_SUPPORT=y
# CONFIG_MEDIA_ANALOG_TV_SUPPORT is not set
# CONFIG_MEDIA_DIGITAL_TV_SUPPORT is not set
# CONFIG_MEDIA_RADIO_SUPPORT is not set
# CONFIG_MEDIA_RC_SUPPORT is not set
# CONFIG_MEDIA_CONTROLLER is not set
CONFIG_VIDEO_DEV=y
CONFIG_VIDEO_V4L2=y
# CONFIG_VIDEO_ADV_DEBUG is not set
# CONFIG_VIDEO_FIXED_MINOR_RANGES is not set
CONFIG_V4L2_MEM2MEM_DEV=y
CONFIG_VIDEOBUF_GEN=y
CONFIG_VIDEOBUF2_CORE=y
CONFIG_VIDEOBUF2_MEMOPS=y
CONFIG_VIDEOBUF2_DMA_CONTIG=y
# CONFIG_VIDEO_V4L2_INT_DEVICE is not set
# CONFIG_TTPCI_EEPROM is not set

#
# Media drivers
#
CONFIG_V4L_PLATFORM_DRIVERS=y
# CONFIG_VIDEO_TIMBERDALE is not set
CONFIG_SOC_CAMERA=y
# CONFIG_SOC_CAMERA_PLATFORM is not set
CONFIG_VIDEO_MX3=y
# CONFIG_VIDEO_RCAR_VIN is not set
# CONFIG_VIDEO_SH_MOBILE_CSI2 is not set
# CONFIG_VIDEO_SH_MOBILE_CEU is not set
CONFIG_V4L_MEM2MEM_DRIVERS=y
CONFIG_VIDEO_CODA=y
# CONFIG_VIDEO_MEM2MEM_DEINTERLACE is not set
# CONFIG_VIDEO_SH_VEU is not set
# CONFIG_V4L_TEST_DRIVERS is not set

#
# Supported MMC/SDIO adapters
#

#
# Media ancillary drivers (tuners, sensors, i2c, frontends)
#
CONFIG_MEDIA_SUBDRV_AUTOSELECT=y

#
# Audio decoders, processors and mixers
#

#
# RDS decoders
#

#
# Video decoders
#

#
# Video and audio decoders
#

#
# Video encoders
#

#
# Camera sensor devices
#

#
# Flash devices
#

#
# Video improvement chips
#

#
# Miscelaneous helper chips
#

#
# Sensors used on soc_camera driver
#

#
# soc_camera sensor drivers
#
# CONFIG_SOC_CAMERA_IMX074 is not set
# CONFIG_SOC_CAMERA_MT9M001 is not set
# CONFIG_SOC_CAMERA_MT9M111 is not set
# CONFIG_SOC_CAMERA_MT9T031 is not set
# CONFIG_SOC_CAMERA_MT9T112 is not set
# CONFIG_SOC_CAMERA_MT9V022 is not set
CONFIG_SOC_CAMERA_OV2640=y
# CONFIG_SOC_CAMERA_OV5642 is not set
# CONFIG_SOC_CAMERA_OV6650 is not set
# CONFIG_SOC_CAMERA_OV772X is not set
# CONFIG_SOC_CAMERA_OV9640 is not set
# CONFIG_SOC_CAMERA_OV9740 is not set
# CONFIG_SOC_CAMERA_RJ54N1 is not set
# CONFIG_SOC_CAMERA_TW9910 is not set

#
# Tools to develop new frontends
#
# CONFIG_DVB_DUMMY_FE is not set

#
# Graphics support
#
CONFIG_DRM=y
CONFIG_DRM_KMS_HELPER=y
# CONFIG_DRM_LOAD_EDID_FIRMWARE is not set
CONFIG_DRM_GEM_CMA_HELPER=y
CONFIG_DRM_KMS_CMA_HELPER=y

#
# I2C encoder or helper chips
#
# CONFIG_DRM_I2C_CH7006 is not set
# CONFIG_DRM_I2C_SIL164 is not set
# CONFIG_DRM_I2C_NXP_TDA998X is not set
# CONFIG_DRM_EXYNOS is not set
# CONFIG_DRM_RCAR_DU is not set
# CONFIG_DRM_SHMOBILE is not set
# CONFIG_DRM_TILCDC is not set
# CONFIG_TEGRA_HOST1X is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
CONFIG_VIDEOMODE_HELPERS=y
CONFIG_HDMI=y
CONFIG_FB=y
# CONFIG_FIRMWARE_EDID is not set
# CONFIG_FB_DDC is not set
# CONFIG_FB_BOOT_VESA_SUPPORT is not set
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
CONFIG_FB_SYS_FILLRECT=y
CONFIG_FB_SYS_COPYAREA=y
CONFIG_FB_SYS_IMAGEBLIT=y
# CONFIG_FB_FOREIGN_ENDIAN is not set
# CONFIG_FB_SYS_FOPS is not set
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
# CONFIG_FB_MODE_HELPERS is not set
# CONFIG_FB_TILEBLITTING is not set

#
# Frame buffer hardware drivers
#
# CONFIG_FB_IMX is not set
# CONFIG_FB_UVESA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_TMIO is not set
# CONFIG_FB_GOLDFISH is not set
# CONFIG_FB_VIRTUAL is not set
# CONFIG_FB_METRONOME is not set
CONFIG_FB_MX3=y
# CONFIG_FB_BROADSHEET is not set
# CONFIG_FB_AUO_K190X is not set
# CONFIG_FB_SIMPLE is not set
# CONFIG_EXYNOS_VIDEO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_LCD_CLASS_DEVICE=y
CONFIG_LCD_L4F00242T03=y
# CONFIG_LCD_LMS283GF05 is not set
# CONFIG_LCD_LTV350QV is not set
# CONFIG_LCD_ILI922X is not set
# CONFIG_LCD_ILI9320 is not set
# CONFIG_LCD_TDO24M is not set
# CONFIG_LCD_VGG2432A4 is not set
CONFIG_LCD_PLATFORM=y
# CONFIG_LCD_S6E63M0 is not set
# CONFIG_LCD_LD9040 is not set
# CONFIG_LCD_AMS369FG06 is not set
# CONFIG_LCD_LMS501KF03 is not set
# CONFIG_LCD_HX8357 is not set
CONFIG_BACKLIGHT_CLASS_DEVICE=y
CONFIG_BACKLIGHT_GENERIC=y
CONFIG_BACKLIGHT_PWM=y
# CONFIG_BACKLIGHT_DA9052 is not set
# CONFIG_BACKLIGHT_ADP8860 is not set
# CONFIG_BACKLIGHT_ADP8870 is not set
# CONFIG_BACKLIGHT_LM3630 is not set
# CONFIG_BACKLIGHT_LM3639 is not set
# CONFIG_BACKLIGHT_LP855X is not set
# CONFIG_BACKLIGHT_GPIO is not set
# CONFIG_BACKLIGHT_LV5207LP is not set
# CONFIG_BACKLIGHT_BD6107 is not set

#
# Console display driver support
#
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY=y
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_LOGO=y
CONFIG_LOGO_LINUX_MONO=y
CONFIG_LOGO_LINUX_VGA16=y
CONFIG_LOGO_LINUX_CLUT224=y
# CONFIG_FB_SSD1307 is not set
CONFIG_SOUND=y
# CONFIG_SOUND_OSS_CORE is not set
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
CONFIG_SND_DMAENGINE_PCM=y
CONFIG_SND_COMPRESS_OFFLOAD=y
CONFIG_SND_JACK=y
# CONFIG_SND_SEQUENCER is not set
# CONFIG_SND_MIXER_OSS is not set
# CONFIG_SND_PCM_OSS is not set
# CONFIG_SND_HRTIMER is not set
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_SND_SUPPORT_OLD_API=y
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
# CONFIG_SND_RAWMIDI_SEQ is not set
# CONFIG_SND_OPL3_LIB_SEQ is not set
# CONFIG_SND_OPL4_LIB_SEQ is not set
# CONFIG_SND_SBAWE_SEQ is not set
# CONFIG_SND_EMU10K1_SEQ is not set
CONFIG_SND_DRIVERS=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_ALOOP is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
CONFIG_SND_ARM=y
CONFIG_SND_SPI=y
CONFIG_SND_SOC=y
CONFIG_SND_SOC_AC97_BUS=y
CONFIG_SND_SOC_GENERIC_DMAENGINE_PCM=y
# CONFIG_SND_ATMEL_SOC is not set
# CONFIG_SND_DESIGNWARE_I2S is not set
CONFIG_SND_SOC_FSL_SSI=y
CONFIG_SND_IMX_SOC=y
CONFIG_SND_SOC_IMX_SSI=y
CONFIG_SND_SOC_IMX_PCM_FIQ=y
CONFIG_SND_SOC_IMX_PCM_DMA=y
CONFIG_SND_SOC_IMX_AUDMUX=y
CONFIG_SND_SOC_PHYCORE_AC97=y
CONFIG_SND_SOC_EUKREA_TLV320=y
CONFIG_SND_SOC_IMX_WM8962=y
CONFIG_SND_SOC_IMX_SGTL5000=y
# CONFIG_SND_SOC_IMX_SPDIF is not set
CONFIG_SND_SOC_IMX_MC13783=y
CONFIG_SND_SOC_I2C_AND_SPI=y
CONFIG_SND_SOC_SGTL5000=y
CONFIG_SND_SOC_TLV320AIC23=y
CONFIG_SND_SOC_WM8962=y
CONFIG_SND_SOC_WM9712=y
CONFIG_SND_SOC_MC13783=y
# CONFIG_SND_SIMPLE_CARD is not set
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y

#
# HID support
#
CONFIG_HID=y
# CONFIG_HIDRAW is not set
# CONFIG_UHID is not set
CONFIG_HID_GENERIC=y

#
# Special HID drivers
#
# CONFIG_HID_A4TECH is not set
# CONFIG_HID_ACRUX is not set
# CONFIG_HID_APPLE is not set
# CONFIG_HID_AUREAL is not set
# CONFIG_HID_BELKIN is not set
# CONFIG_HID_CHERRY is not set
# CONFIG_HID_CHICONY is not set
# CONFIG_HID_PRODIKEYS is not set
# CONFIG_HID_CYPRESS is not set
# CONFIG_HID_DRAGONRISE is not set
# CONFIG_HID_EMS_FF is not set
# CONFIG_HID_ELECOM is not set
# CONFIG_HID_EZKEY is not set
# CONFIG_HID_KEYTOUCH is not set
# CONFIG_HID_KYE is not set
# CONFIG_HID_UCLOGIC is not set
# CONFIG_HID_WALTOP is not set
# CONFIG_HID_GYRATION is not set
# CONFIG_HID_ICADE is not set
# CONFIG_HID_TWINHAN is not set
# CONFIG_HID_KENSINGTON is not set
# CONFIG_HID_LCPOWER is not set
# CONFIG_HID_LOGITECH is not set
# CONFIG_HID_MAGICMOUSE is not set
# CONFIG_HID_MICROSOFT is not set
# CONFIG_HID_MONTEREY is not set
# CONFIG_HID_MULTITOUCH is not set
# CONFIG_HID_ORTEK is not set
# CONFIG_HID_PANTHERLORD is not set
# CONFIG_HID_PETALYNX is not set
# CONFIG_HID_PICOLCD is not set
# CONFIG_HID_PRIMAX is not set
# CONFIG_HID_SAITEK is not set
# CONFIG_HID_SAMSUNG is not set
# CONFIG_HID_SPEEDLINK is not set
# CONFIG_HID_STEELSERIES is not set
# CONFIG_HID_SUNPLUS is not set
# CONFIG_HID_GREENASIA is not set
# CONFIG_HID_SMARTJOYPLUS is not set
# CONFIG_HID_TIVO is not set
# CONFIG_HID_TOPSEED is not set
# CONFIG_HID_THINGM is not set
# CONFIG_HID_THRUSTMASTER is not set
# CONFIG_HID_WACOM is not set
# CONFIG_HID_WIIMOTE is not set
# CONFIG_HID_XINMO is not set
# CONFIG_HID_ZEROPLUS is not set
# CONFIG_HID_ZYDACRON is not set
# CONFIG_HID_SENSOR_HUB is not set

#
# I2C HID support
#
# CONFIG_I2C_HID is not set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
# CONFIG_USB_SUPPORT is not set
CONFIG_MMC=y
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
# CONFIG_MMC_CLKGATE is not set

#
# MMC/SD/SDIO Card Drivers
#
CONFIG_MMC_BLOCK=y
CONFIG_MMC_BLOCK_MINORS=8
CONFIG_MMC_BLOCK_BOUNCE=y
# CONFIG_SDIO_UART is not set
# CONFIG_MMC_TEST is not set

#
# MMC/SD/SDIO Host Controller Drivers
#
CONFIG_MMC_SDHCI=y
CONFIG_MMC_SDHCI_IO_ACCESSORS=y
CONFIG_MMC_SDHCI_PLTFM=y
CONFIG_MMC_SDHCI_ESDHC_IMX=y
# CONFIG_MMC_SDHCI_PXAV3 is not set
# CONFIG_MMC_SDHCI_PXAV2 is not set
# CONFIG_MMC_MXC is not set
# CONFIG_MMC_SPI is not set
# CONFIG_MMC_DW is not set
# CONFIG_MEMSTICK is not set
CONFIG_LEDS_GPIO_REGISTER=y
CONFIG_NEW_LEDS=y
CONFIG_LEDS_CLASS=y

#
# LED drivers
#
# CONFIG_LEDS_LM3530 is not set
# CONFIG_LEDS_LM3642 is not set
# CONFIG_LEDS_PCA9532 is not set
# CONFIG_LEDS_GPIO is not set
# CONFIG_LEDS_LP3944 is not set
# CONFIG_LEDS_LP5521 is not set
# CONFIG_LEDS_LP5523 is not set
# CONFIG_LEDS_LP5562 is not set
# CONFIG_LEDS_LP8501 is not set
# CONFIG_LEDS_PCA955X is not set
# CONFIG_LEDS_PCA963X is not set
# CONFIG_LEDS_DA9052 is not set
# CONFIG_LEDS_DAC124S085 is not set
# CONFIG_LEDS_PWM is not set
# CONFIG_LEDS_REGULATOR is not set
# CONFIG_LEDS_BD2802 is not set
# CONFIG_LEDS_LT3593 is not set
# CONFIG_LEDS_MC13783 is not set
# CONFIG_LEDS_TCA6507 is not set
# CONFIG_LEDS_LM355x is not set
# CONFIG_LEDS_OT200 is not set
# CONFIG_LEDS_BLINKM is not set

#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not set
# CONFIG_ACCESSIBILITY is not set
# CONFIG_EDAC is not set
CONFIG_RTC_LIB=y
CONFIG_RTC_CLASS=y
CONFIG_RTC_HCTOSYS=y
CONFIG_RTC_SYSTOHC=y
CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set

#
# RTC interfaces
#
CONFIG_RTC_INTF_SYSFS=y
CONFIG_RTC_INTF_PROC=y
CONFIG_RTC_INTF_DEV=y
CONFIG_RTC_INTF_DEV_UIE_EMUL=y
# CONFIG_RTC_DRV_TEST is not set

#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not set
# CONFIG_RTC_DRV_DS1672 is not set
# CONFIG_RTC_DRV_DS3232 is not set
# CONFIG_RTC_DRV_MAX6900 is not set
# CONFIG_RTC_DRV_RS5C372 is not set
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_ISL12022 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF2127 is not set
# CONFIG_RTC_DRV_PCF8523 is not set
# CONFIG_RTC_DRV_PCF8563 is not set
# CONFIG_RTC_DRV_PCF8583 is not set
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_BQ32K is not set
# CONFIG_RTC_DRV_S35390A is not set
# CONFIG_RTC_DRV_FM3130 is not set
# CONFIG_RTC_DRV_RX8581 is not set
# CONFIG_RTC_DRV_RX8025 is not set
# CONFIG_RTC_DRV_EM3027 is not set
# CONFIG_RTC_DRV_RV3029C2 is not set

#
# SPI RTC drivers
#
# CONFIG_RTC_DRV_M41T93 is not set
# CONFIG_RTC_DRV_M41T94 is not set
# CONFIG_RTC_DRV_DS1305 is not set
# CONFIG_RTC_DRV_DS1390 is not set
# CONFIG_RTC_DRV_MAX6902 is not set
# CONFIG_RTC_DRV_R9701 is not set
# CONFIG_RTC_DRV_RS5C348 is not set
# CONFIG_RTC_DRV_DS3234 is not set
# CONFIG_RTC_DRV_PCF2123 is not set
# CONFIG_RTC_DRV_RX4581 is not set

#
# Platform RTC drivers
#
# CONFIG_RTC_DRV_CMOS is not set
# CONFIG_RTC_DRV_DS1286 is not set
# CONFIG_RTC_DRV_DS1511 is not set
# CONFIG_RTC_DRV_DS1553 is not set
# CONFIG_RTC_DRV_DS1742 is not set
# CONFIG_RTC_DRV_DA9052 is not set
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_M48T86 is not set
# CONFIG_RTC_DRV_M48T35 is not set
# CONFIG_RTC_DRV_M48T59 is not set
# CONFIG_RTC_DRV_MSM6242 is not set
# CONFIG_RTC_DRV_BQ4802 is not set
# CONFIG_RTC_DRV_RP5C01 is not set
# CONFIG_RTC_DRV_V3020 is not set
# CONFIG_RTC_DRV_DS2404 is not set

#
# on-CPU RTC drivers
#
# CONFIG_RTC_DRV_IMXDI is not set
CONFIG_RTC_DRV_MC13XXX=y
CONFIG_RTC_DRV_MXC=y
CONFIG_RTC_DRV_SNVS=y
# CONFIG_RTC_DRV_MOXART is not set

#
# HID Sensor RTC drivers
#
CONFIG_DMADEVICES=y
# CONFIG_DMADEVICES_DEBUG is not set

#
# DMA Devices
#
# CONFIG_DW_DMAC_CORE is not set
# CONFIG_DW_DMAC is not set
CONFIG_MX3_IPU=y
CONFIG_MX3_IPU_IRQS=4
# CONFIG_TIMB_DMA is not set
CONFIG_IMX_SDMA=y
# CONFIG_IMX_DMA is not set
CONFIG_MXS_DMA=y
CONFIG_DMA_ENGINE=y
CONFIG_DMA_OF=y

#
# DMA Clients
#
# CONFIG_NET_DMA is not set
# CONFIG_ASYNC_TX_DMA is not set
# CONFIG_DMATEST is not set
# CONFIG_AUXDISPLAY is not set
# CONFIG_UIO is not set
# CONFIG_VIRT_DRIVERS is not set

#
# Virtio drivers
#
# CONFIG_VIRTIO_MMIO is not set

#
# Microsoft Hyper-V guest support
#
CONFIG_STAGING=y
# CONFIG_ECHO is not set
# CONFIG_COMEDI is not set
# CONFIG_RTLLIB is not set
# CONFIG_ZSMALLOC is not set
# CONFIG_FT1000 is not set

#
# Speakup console speech
#
# CONFIG_SPEAKUP is not set
# CONFIG_TOUCHSCREEN_CLEARPAD_TM1217 is not set
# CONFIG_TOUCHSCREEN_SYNAPTICS_I2C_RMI4 is not set
# CONFIG_STAGING_MEDIA is not set

#
# Android
#
# CONFIG_ANDROID is not set
# CONFIG_WIMAX_GDM72XX is not set
CONFIG_DRM_IMX=y
CONFIG_DRM_IMX_FB_HELPER=y
CONFIG_DRM_IMX_PARALLEL_DISPLAY=y
CONFIG_DRM_IMX_TVE=y
CONFIG_DRM_IMX_LDB=y
CONFIG_DRM_IMX_IPUV3_CORE=y
CONFIG_DRM_IMX_IPUV3=y
# CONFIG_DGRP is not set
# CONFIG_LUSTRE_FS is not set
# CONFIG_XILLYBUS is not set
# CONFIG_DGAP is not set
CONFIG_CLKDEV_LOOKUP=y
CONFIG_HAVE_CLK_PREPARE=y
CONFIG_COMMON_CLK=y

#
# Common Clock Framework
#
CONFIG_COMMON_CLK_DEBUG=y
# CONFIG_COMMON_CLK_SI5351 is not set

#
# Hardware Spinlock drivers
#
CONFIG_CLKSRC_OF=y
CONFIG_CLKSRC_MMIO=y
CONFIG_VF_PIT_TIMER=y
# CONFIG_MAILBOX is not set
# CONFIG_IOMMU_SUPPORT is not set

#
# Remoteproc drivers
#
# CONFIG_STE_MODEM_RPROC is not set

#
# Rpmsg drivers
#
# CONFIG_PM_DEVFREQ is not set
# CONFIG_EXTCON is not set
# CONFIG_MEMORY is not set
# CONFIG_IIO is not set
CONFIG_PWM=y
CONFIG_PWM_SYSFS=y
CONFIG_PWM_IMX=y
# CONFIG_PWM_PCA9685 is not set
CONFIG_IRQCHIP=y
CONFIG_ARM_GIC=y
# CONFIG_IPACK_BUS is not set
CONFIG_ARCH_HAS_RESET_CONTROLLER=y
CONFIG_RESET_CONTROLLER=y
# CONFIG_FMC is not set

#
# File systems
#
CONFIG_DCACHE_WORD_ACCESS=y
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_DEFAULTS_TO_ORDERED=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
CONFIG_EXT4_FS=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_JBD2=y
# CONFIG_JBD2_DEBUG is not set
CONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not set
CONFIG_XFS_POSIX_ACL=y
# CONFIG_XFS_RT is not set
# CONFIG_XFS_WARN is not set
# CONFIG_XFS_DEBUG is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
# CONFIG_BTRFS_FS is not set
# CONFIG_NILFS2_FS is not set
CONFIG_FS_POSIX_ACL=y
CONFIG_EXPORTFS=y
CONFIG_FILE_LOCKING=y
CONFIG_FSNOTIFY=y
CONFIG_DNOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_FANOTIFY is not set
CONFIG_QUOTA=y
CONFIG_QUOTA_NETLINK_INTERFACE=y
# CONFIG_PRINT_QUOTA_WARNING is not set
# CONFIG_QUOTA_DEBUG is not set
# CONFIG_QFMT_V1 is not set
# CONFIG_QFMT_V2 is not set
CONFIG_QUOTACTL=y
CONFIG_AUTOFS4_FS=y
CONFIG_FUSE_FS=y
# CONFIG_CUSE is not set

#
# Caches
#
# CONFIG_FSCACHE is not set

#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y

#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set

#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_SYSCTL=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_TMPFS_XATTR is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_CONFIGFS_FS=m
CONFIG_MISC_FILESYSTEMS=y
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_ECRYPT_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=y
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_FS_WBUF_VERIFY is not set
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
# CONFIG_JFFS2_COMPRESSION_OPTIONS is not set
CONFIG_JFFS2_ZLIB=y
# CONFIG_JFFS2_LZO is not set
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
CONFIG_UBIFS_FS=y
# CONFIG_UBIFS_FS_ADVANCED_COMPR is not set
CONFIG_UBIFS_FS_LZO=y
CONFIG_UBIFS_FS_ZLIB=y
# CONFIG_LOGFS is not set
# CONFIG_CRAMFS is not set
# CONFIG_SQUASHFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_OMFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_QNX6FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_PSTORE is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
# CONFIG_F2FS_FS is not set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=y
CONFIG_NFS_V2=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
# CONFIG_NFS_SWAP is not set
# CONFIG_NFS_V4_1 is not set
CONFIG_ROOT_NFS=y
# CONFIG_NFS_USE_LEGACY_DNS is not set
CONFIG_NFS_USE_KERNEL_DNS=y
# CONFIG_NFSD is not set
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
CONFIG_SUNRPC_GSS=y
# CONFIG_SUNRPC_DEBUG is not set
# CONFIG_CEPH_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
# CONFIG_NLS_CODEPAGE_850 is not set
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
CONFIG_NLS_ASCII=y
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=m
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
# CONFIG_NLS_MAC_ROMAN is not set
# CONFIG_NLS_MAC_CELTIC is not set
# CONFIG_NLS_MAC_CENTEURO is not set
# CONFIG_NLS_MAC_CROATIAN is not set
# CONFIG_NLS_MAC_CYRILLIC is not set
# CONFIG_NLS_MAC_GAELIC is not set
# CONFIG_NLS_MAC_GREEK is not set
# CONFIG_NLS_MAC_ICELAND is not set
# CONFIG_NLS_MAC_INUIT is not set
# CONFIG_NLS_MAC_ROMANIAN is not set
# CONFIG_NLS_MAC_TURKISH is not set
CONFIG_NLS_UTF8=y
# CONFIG_DLM is not set

#
# Kernel hacking
#

#
# printk and dmesg options
#
CONFIG_PRINTK_TIME=y
CONFIG_DEFAULT_MESSAGE_LOGLEVEL=7
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_DYNAMIC_DEBUG is not set

#
# Compile-time checks and compiler options
#
CONFIG_DEBUG_INFO=y
# CONFIG_DEBUG_INFO_REDUCED is not set
CONFIG_ENABLE_WARN_DEPRECATED=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_FRAME_WARN=1024
# CONFIG_STRIP_ASM_SYMS is not set
# CONFIG_READABLE_ASM is not set
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
# CONFIG_DEBUG_SECTION_MISMATCH is not set
CONFIG_FRAME_POINTER=y
# CONFIG_DEBUG_FORCE_WEAK_PER_CPU is not set
CONFIG_MAGIC_SYSRQ=y
CONFIG_DEBUG_KERNEL=y

#
# Memory Debugging
#
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_OBJECTS is not set
# CONFIG_SLUB_STATS is not set
CONFIG_HAVE_DEBUG_KMEMLEAK=y
# CONFIG_DEBUG_KMEMLEAK is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_MEMORY_INIT is not set
# CONFIG_DEBUG_PER_CPU_MAPS is not set
CONFIG_DEBUG_SHIRQ=y

#
# Debug Lockups and Hangs
#
CONFIG_LOCKUP_DETECTOR=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC=y
CONFIG_BOOTPARAM_SOFTLOCKUP_PANIC_VALUE=1
CONFIG_DETECT_HUNG_TASK=y
CONFIG_DEFAULT_HUNG_TASK_TIMEOUT=120
CONFIG_BOOTPARAM_HUNG_TASK_PANIC=y
CONFIG_BOOTPARAM_HUNG_TASK_PANIC_VALUE=1
CONFIG_PANIC_ON_OOPS=y
CONFIG_PANIC_ON_OOPS_VALUE=1
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
# CONFIG_TIMER_STATS is not set
CONFIG_DEBUG_PREEMPT=y

#
# Lock Debugging (spinlocks, mutexes, etc...)
#
CONFIG_DEBUG_RT_MUTEXES=y
CONFIG_DEBUG_PI_LIST=y
CONFIG_RT_MUTEX_TESTER=y
CONFIG_DEBUG_SPINLOCK=y
CONFIG_DEBUG_MUTEXES=y
CONFIG_DEBUG_WW_MUTEX_SLOWPATH=y
CONFIG_DEBUG_LOCK_ALLOC=y
CONFIG_PROVE_LOCKING=y
CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
CONFIG_DEBUG_ATOMIC_SLEEP=y
CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
CONFIG_TRACE_IRQFLAGS=y
CONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_WRITECOUNT is not set
CONFIG_DEBUG_LIST=y
CONFIG_DEBUG_SG=y
CONFIG_DEBUG_NOTIFIERS=y
# CONFIG_DEBUG_CREDENTIALS is not set

#
# RCU Debugging
#
# CONFIG_PROVE_RCU is not set
CONFIG_PROVE_RCU_DELAY=y
# CONFIG_SPARSE_RCU_POINTER is not set
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_RCU_CPU_STALL_TIMEOUT=21
CONFIG_RCU_CPU_STALL_VERBOSE=y
# CONFIG_RCU_CPU_STALL_INFO is not set
# CONFIG_RCU_TRACE is not set
# CONFIG_DEBUG_BLOCK_EXT_DEVT is not set
# CONFIG_NOTIFIER_ERROR_INJECTION is not set
# CONFIG_FAULT_INJECTION is not set
CONFIG_NOP_TRACER=y
CONFIG_HAVE_FUNCTION_TRACER=y
CONFIG_HAVE_FUNCTION_GRAPH_TRACER=y
CONFIG_HAVE_DYNAMIC_FTRACE=y
CONFIG_HAVE_FTRACE_MCOUNT_RECORD=y
CONFIG_HAVE_SYSCALL_TRACEPOINTS=y
CONFIG_HAVE_C_RECORDMCOUNT=y
CONFIG_TRACE_CLOCK=y
CONFIG_RING_BUFFER=y
CONFIG_EVENT_TRACING=y
CONFIG_CONTEXT_SWITCH_TRACER=y
CONFIG_TRACING=y
CONFIG_GENERIC_TRACER=y
CONFIG_TRACING_SUPPORT=y
CONFIG_FTRACE=y
CONFIG_FUNCTION_TRACER=y
CONFIG_FUNCTION_GRAPH_TRACER=y
# CONFIG_IRQSOFF_TRACER is not set
# CONFIG_PREEMPT_TRACER is not set
# CONFIG_SCHED_TRACER is not set
CONFIG_FTRACE_SYSCALLS=y
# CONFIG_TRACER_SNAPSHOT is not set
CONFIG_BRANCH_PROFILE_NONE=y
# CONFIG_PROFILE_ANNOTATED_BRANCHES is not set
# CONFIG_PROFILE_ALL_BRANCHES is not set
# CONFIG_STACK_TRACER is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
CONFIG_KPROBE_EVENT=y
CONFIG_PROBE_EVENTS=y
CONFIG_DYNAMIC_FTRACE=y
# CONFIG_FUNCTION_PROFILER is not set
CONFIG_FTRACE_MCOUNT_RECORD=y
# CONFIG_FTRACE_STARTUP_TEST is not set
# CONFIG_RING_BUFFER_BENCHMARK is not set
# CONFIG_RING_BUFFER_STARTUP_TEST is not set

#
# Runtime Testing
#
# CONFIG_LKDTM is not set
# CONFIG_TEST_LIST_SORT is not set
# CONFIG_KPROBES_SANITY_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_RBTREE_TEST is not set
# CONFIG_INTERVAL_TREE_TEST is not set
# CONFIG_ATOMIC64_SELFTEST is not set
# CONFIG_TEST_STRING_HELPERS is not set
# CONFIG_TEST_KSTRTOX is not set
# CONFIG_DMA_API_DEBUG is not set
# CONFIG_SAMPLES is not set
CONFIG_HAVE_ARCH_KGDB=y
# CONFIG_KGDB is not set
# CONFIG_STRICT_DEVMEM is not set
# CONFIG_ARM_UNWIND is not set
CONFIG_OLD_MCOUNT=y
# CONFIG_DEBUG_USER is not set
# CONFIG_DEBUG_LL is not set
CONFIG_DEBUG_IMX_UART_PORT=1
CONFIG_DEBUG_LL_INCLUDE="mach/debug-macro.S"
# CONFIG_DEBUG_UART_PL01X is not set
# CONFIG_DEBUG_UART_8250 is not set
CONFIG_UNCOMPRESS_INCLUDE="debug/uncompress.h"
# CONFIG_ARM_KPROBES_TEST is not set
# CONFIG_PID_IN_CONTEXTIDR is not set

#
# Security options
#
CONFIG_KEYS=y
# CONFIG_ENCRYPTED_KEYS is not set
# CONFIG_KEYS_DEBUG_PROC_KEYS is not set
# CONFIG_SECURITY_DMESG_RESTRICT is not set
# CONFIG_SECURITY is not set
CONFIG_SECURITYFS=y
CONFIG_DEFAULT_SECURITY_DAC=y
CONFIG_DEFAULT_SECURITY=""
CONFIG_CRYPTO=y

#
# Crypto core or helper
#
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_ALGAPI2=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_BLKCIPHER2=y
CONFIG_CRYPTO_HASH=y
CONFIG_CRYPTO_HASH2=y
CONFIG_CRYPTO_RNG2=y
# CONFIG_CRYPTO_MANAGER is not set
# CONFIG_CRYPTO_MANAGER2 is not set
# CONFIG_CRYPTO_USER is not set
# CONFIG_CRYPTO_GF128MUL is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_PCRYPT is not set
CONFIG_CRYPTO_WORKQUEUE=y
# CONFIG_CRYPTO_CRYPTD is not set
# CONFIG_CRYPTO_AUTHENC is not set
# CONFIG_CRYPTO_TEST is not set

#
# Authenticated Encryption with Associated Data
#
# CONFIG_CRYPTO_CCM is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_SEQIV is not set

#
# Block modes
#
# CONFIG_CRYPTO_CBC is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_CTS is not set
# CONFIG_CRYPTO_ECB is not set
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_PCBC is not set
# CONFIG_CRYPTO_XTS is not set

#
# Hash modes
#
# CONFIG_CRYPTO_CMAC is not set
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_VMAC is not set

#
# Digest
#
CONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CRC32 is not set
CONFIG_CRYPTO_CRCT10DIF=y
# CONFIG_CRYPTO_GHASH is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_MICHAEL_MIC is not set
# CONFIG_CRYPTO_RMD128 is not set
# CONFIG_CRYPTO_RMD160 is not set
# CONFIG_CRYPTO_RMD256 is not set
# CONFIG_CRYPTO_RMD320 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA1_ARM is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_WP512 is not set

#
# Ciphers
#
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_ARM is not set
# CONFIG_CRYPTO_ANUBIS is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_FCRYPT is not set
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SERPENT is not set
# CONFIG_CRYPTO_TEA is not set
# CONFIG_CRYPTO_TWOFISH is not set

#
# Compression
#
CONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_ZLIB is not set
CONFIG_CRYPTO_LZO=y
# CONFIG_CRYPTO_LZ4 is not set
# CONFIG_CRYPTO_LZ4HC is not set

#
# Random Number Generation
#
# CONFIG_CRYPTO_ANSI_CPRNG is not set
# CONFIG_CRYPTO_USER_API_HASH is not set
# CONFIG_CRYPTO_USER_API_SKCIPHER is not set
# CONFIG_CRYPTO_HW is not set
# CONFIG_ASYMMETRIC_KEY_TYPE is not set
CONFIG_BINARY_PRINTF=y

#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_RATIONAL=y
CONFIG_GENERIC_STRNCPY_FROM_USER=y
CONFIG_GENERIC_STRNLEN_USER=y
CONFIG_GENERIC_NET_UTILS=y
CONFIG_GENERIC_PCI_IOMAP=y
CONFIG_GENERIC_IO=y
CONFIG_STMP_DEVICE=y
CONFIG_CRC_CCITT=m
CONFIG_CRC16=y
CONFIG_CRC_T10DIF=y
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=y
# CONFIG_CRC32_SELFTEST is not set
CONFIG_CRC32_SLICEBY8=y
# CONFIG_CRC32_SLICEBY4 is not set
# CONFIG_CRC32_SARWATE is not set
# CONFIG_CRC32_BIT is not set
CONFIG_CRC7=m
CONFIG_LIBCRC32C=y
# CONFIG_CRC8 is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_LZO_COMPRESS=y
CONFIG_LZO_DECOMPRESS=y
# CONFIG_XZ_DEC is not set
# CONFIG_XZ_DEC_BCJ is not set
CONFIG_DECOMPRESS_GZIP=y
CONFIG_GENERIC_ALLOCATOR=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
CONFIG_CPU_RMAP=y
CONFIG_DQL=y
CONFIG_NLATTR=y
CONFIG_GENERIC_ATOMIC64=y
CONFIG_ARCH_HAS_ATOMIC64_DEC_IF_POSITIVE=y
CONFIG_AVERAGE=y
# CONFIG_CORDIC is not set
# CONFIG_DDR is not set
CONFIG_OID_REGISTRY=y
CONFIG_FONT_SUPPORT=y
CONFIG_FONTS=y
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
# CONFIG_FONT_SUN12x22 is not set
# CONFIG_FONT_10x18 is not set
# CONFIG_VIRTUALIZATION is not set

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

Hi Mathieu,

Yes the problem we were seeing with GCC bug 58854 is that an interrupt
handler was corrupting the stack of a routine which had an invalid
value of SP (not really on "top" of the stack) for part of the
routine.
But in the assembly code you sent, I don't see where sp is being
modified... or where the access to "below" sp is happening.
In GCC bug 58854 it was pretty clear that the restore of the sp
register in the epilogue is moved to somewhere close to the prologue
of the routine.
Are we missing some diffs from the assembly comparison?

Thanks

Luis




On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
> ----- Original Message -----
>> From: "Jakub Jelinek" <jakub@redhat.com>
>> To: "Luis Lozano" <llozano@google.com>
>> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds" <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
>> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
>> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
>> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
>> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
>> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
>> Sent: Thursday, November 21, 2013 7:39:04 PM
>> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
>>
>> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
>> > I think we need a reproducer. Without this we may all be going on the
>> > wrong path. This whole conversation started on an *assumption* that
>> > some accesses were being reordered.
>> >
>> > evidence of the reorder or reproducer please?
>>
>> Yeah, if a compiler bug is suspected, can anybody please open
>> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
>> compiler version, flags and how it was configured and some hint in which
>> function to look for what exactly?  We don't necessarily need a runtime
>> small reproducer, but if it can be shown in the assembly what has been
>> reordered and why you think it shouldn't, with the above mentioned input
>> that ought to be sufficient.  Thanks.
>
> OK OK, let me reply on list first so I can share the result of a full day
> of bug hunting. We're not there yet, but many options have been eliminated.
>
> The issue shows up in stress test, when tracing with lttng-modules 2.4-rc1,
> on ARM. It's been reproduced with a Linux kernel 3.12 so far, with lttng-modules
> compiled against that kernel.
>
> First, I asked Nathan to compile his kernel with gcc 4.7, and lttng-modules
> with gcc 4.8.x (and vice-versa). The problem only appears when lttng-modules
> are compiled with gcc 4.8.x. The compiler version used to compile the rest
> of the kernel does not matter.
>
> Then I looked at gcc 4.8 changelog for ARM, new feature: -fno-sched-pressure
> (sched pressure is there by default). Nathan tried compiling lttng-modules with
> -fno-sched-pressure. The problem still reproduces.
>
> Knowing that adding barrier() outside of preempt_disable()/enable() was
> fixing the issue, we tried identifying which code location was responsible
> for working around the issue. Skipping a long investigation, here is the
> executive summary:
>
> http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
>
> Has the following function. We identified that adding a barrier() as shown below
> works around the issue:
>
> static
> int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
>                       uint32_t event_id)
> {
>         struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
>         int ret, cpu;
>
>         cpu = lib_ring_buffer_get_cpu(&client_config);
>         if (cpu < 0)
>                 return -EPERM;
>         ctx->cpu = cpu;
>
>         switch (lttng_chan->header_type) {
>         case 1: /* compact */
>                 if (event_id > 30)
>                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
>                 break;
>         case 2: /* large */
>                 if (event_id > 65534)
>                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
>                 break;
>         default:
>                 WARN_ON_ONCE(1);
>         }
>
>         ret = lib_ring_buffer_reserve(&client_config, ctx);
>         if (ret)
>                 goto put;
>         lttng_write_event_header(&client_config, ctx, event_id);
>         return 0;
> put:
>         lib_ring_buffer_put_cpu(&client_config);
>         ---------------> barrier() added here; <----------------------------
>         return ret;
> }
>
> Where barrier() is the usual asm volatile with "memory" clobber, nothing else.
>
> Nathan gave me the binary diff for the assembly generated for this function without
> the barrier and with the barrier:
>
> --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079 -0600
> +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21 14:12:52.997355907 -0600
> @@ -7,11 +7,11 @@
>       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
>       f14:      e5903000        ldr     r3, [r0]
>       f18:      e1a04000        mov     r4, r0
> -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> +     f1c:      e1a0000d        mov     r0, sp
>       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
> -     f24:      e1a0000d        mov     r0, sp
> -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>       f30:      e5932004        ldr     r2, [r3, #4]
>       f34:      e2822001        add     r2, r2, #1
>       f38:      e5832004        str     r2, [r3, #4]
> @@ -53,7 +53,7 @@
>       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
>       fcc:      e5933000        ldr     r3, [r3]
>       fd0:      e3130002        tst     r3, #2
> -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
> +     fd4:      0a0002be        beq     1ad4 <lttng_event_reserve+0xbd8>
>       fd8:      ebfffffe        bl      0 <preempt_schedule>
>       fdc:      ea0002bc        b       1ad4 <lttng_event_reserve+0xbd8>
>       fe0:      e3500000        cmp     r0, #0
>
> We tried disabling the ftrace function tracing to get mcount out of the way,
> and the problem still reproduces.
>
> I'm stopping here in terms of details about the disassembly, because I
> need to double check with Nathan that I get the right disassembly for the right
> cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my machine.
>
> I'm attaching Nathan's ARM configuration.
>
> It does look behave a bit like this bug pointed out by Luis:
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
>
> AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> on top of the thread stack (?). If it's the case, then anything stored
> on the stack below "sp" could be overwritten by an interrupt handler.
> This would fit well the reproduction scenario for this bug: Nathan runs
> LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> A race between a short window of stack use below sp and interrupt handlers
> would trigger with this kind of stress-test.
>
> Thoughts ?
>
> Thanks,
>
> Mathieu
>
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com



-- 

Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

----- Original Message -----
> From: "Luis Lozano" <llozano@google.com>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> Sent: Thursday, November 21, 2013 9:36:27 PM
> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> 
> Hi Mathieu,
> 
> Yes the problem we were seeing with GCC bug 58854 is that an interrupt
> handler was corrupting the stack of a routine which had an invalid
> value of SP (not really on "top" of the stack) for part of the
> routine.
> But in the assembly code you sent, I don't see where sp is being
> modified... or where the access to "below" sp is happening.

The following instruction

  f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8

appears in the assembly generated by gcc 4.8.2, but not in the one
generated by 4.7.3, which makes me wonder if it's good or not. With
slightly different build output from the diff (probably a different config
from Nathan), the first function instructions look like:

00000efc <lttng_event_reserve>:
     efc:	e1a0c00d 	mov	ip, sp
     f00:	e92ddff0 	push	{r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
     f04:	e24cb004 	sub	fp, ip, #4
     f08:	e24dd03c 	sub	sp, sp, #60	; 0x3c
     f0c:	e52de004 	push	{lr}		; (str lr, [sp, #-4]!)
     f10:	ebfffffe 	bl	0 <__gnu_mcount_nc>
     f14:	e5903000 	ldr	r3, [r0]
     f18:	e1a04000 	mov	r4, r0
     f1c:	e1a0000d 	mov	r0, sp
     f20:	e5936030 	ldr	r6, [r3, #48]	; 0x30
     f24:	e3c03d7f 	bic	r3, r0, #8128	; 0x1fc0
     f28:	e3c3303f 	bic	r3, r3, #63	; 0x3f
     f2c:	e50b104c 	str	r1, [fp, #-76]	; 0xffffffb4
     f30:	e5932004 	ldr	r2, [r3, #4]
     f34:	e2822001 	add	r2, r2, #1
     f38:	e5832004 	str	r2, [r3, #4]
     f3c:	ebfffffe 	bl	0 <debug_smp_processor_id>
     f40:	e59f2e44 	ldr	r2, [pc, #3652]	; 1d8c <lttng_event_reserve+0xe90>
     f44:	e59f3e44 	ldr	r3, [pc, #3652]	; 1d90 <lttng_event_reserve+0xe94>
     f48:	e7921100 	ldr	r1, [r2, r0, lsl #2]
     f4c:	e1a05000 	mov	r5, r0
     f50:	e7932001 	ldr	r2, [r3, r1]

My rusty ARM assembler knowledge analyzes this like:

ip = sp            (ip being the scratch register)
push 11 registers * 4 bytes = 44 bytes onto the stack
fp = ip - 4
sp = sp - 60   (sp = ip - 104)
push {lr} bl
0 <__gnu_mcount_nc>  (dynamically patched to a pop {lr})
[...]
store r1 into mem location fp - 76

So yes, it does look like the -76 from fp is within the stack.


> In GCC bug 58854 it was pretty clear that the restore of the sp
> register in the epilogue is moved to somewhere close to the prologue
> of the routine.
> Are we missing some diffs from the assembly comparison?

My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this morning,
did not manage to get one working even after following 2 howtos, trying with Debian
packages, etc. Nathan told me this diff was the full comparison between the two
functions, but you'll understand that at this point I want to reproduce
everything myself, because this is a _weird_ issue.

But after a long day of debugging, it's time for some sleep. I will get back to this
tomorrow,

Thanks,

Mathieu

> 
> Thanks
> 
> Luis
> 
> 
> 
> 
> On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> > ----- Original Message -----
> >> From: "Jakub Jelinek" <jakub@redhat.com>
> >> To: "Luis Lozano" <llozano@google.com>
> >> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> >> <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
> >> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <rth@twiddle.net>,
> >> "Linux Kernel Mailing List"
> >> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> >> "Catalin Marinas" <catalin.marinas@arm.com>,
> >> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> >> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> >> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> >> <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> >> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> >> Sent: Thursday, November 21, 2013 7:39:04 PM
> >> Subject: Re: current_thread_info() not respecting program order with gcc
> >> 4.8.x
> >>
> >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> >> > I think we need a reproducer. Without this we may all be going on the
> >> > wrong path. This whole conversation started on an *assumption* that
> >> > some accesses were being reordered.
> >> >
> >> > evidence of the reorder or reproducer please?
> >>
> >> Yeah, if a compiler bug is suspected, can anybody please open
> >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
> >> compiler version, flags and how it was configured and some hint in which
> >> function to look for what exactly?  We don't necessarily need a runtime
> >> small reproducer, but if it can be shown in the assembly what has been
> >> reordered and why you think it shouldn't, with the above mentioned input
> >> that ought to be sufficient.  Thanks.
> >
> > OK OK, let me reply on list first so I can share the result of a full day
> > of bug hunting. We're not there yet, but many options have been eliminated.
> >
> > The issue shows up in stress test, when tracing with lttng-modules 2.4-rc1,
> > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
> > lttng-modules
> > compiled against that kernel.
> >
> > First, I asked Nathan to compile his kernel with gcc 4.7, and lttng-modules
> > with gcc 4.8.x (and vice-versa). The problem only appears when
> > lttng-modules
> > are compiled with gcc 4.8.x. The compiler version used to compile the rest
> > of the kernel does not matter.
> >
> > Then I looked at gcc 4.8 changelog for ARM, new feature:
> > -fno-sched-pressure
> > (sched pressure is there by default). Nathan tried compiling lttng-modules
> > with
> > -fno-sched-pressure. The problem still reproduces.
> >
> > Knowing that adding barrier() outside of preempt_disable()/enable() was
> > fixing the issue, we tried identifying which code location was responsible
> > for working around the issue. Skipping a long investigation, here is the
> > executive summary:
> >
> > http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
> >
> > Has the following function. We identified that adding a barrier() as shown
> > below
> > works around the issue:
> >
> > static
> > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
> >                       uint32_t event_id)
> > {
> >         struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
> >         int ret, cpu;
> >
> >         cpu = lib_ring_buffer_get_cpu(&client_config);
> >         if (cpu < 0)
> >                 return -EPERM;
> >         ctx->cpu = cpu;
> >
> >         switch (lttng_chan->header_type) {
> >         case 1: /* compact */
> >                 if (event_id > 30)
> >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> >                 break;
> >         case 2: /* large */
> >                 if (event_id > 65534)
> >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> >                 break;
> >         default:
> >                 WARN_ON_ONCE(1);
> >         }
> >
> >         ret = lib_ring_buffer_reserve(&client_config, ctx);
> >         if (ret)
> >                 goto put;
> >         lttng_write_event_header(&client_config, ctx, event_id);
> >         return 0;
> > put:
> >         lib_ring_buffer_put_cpu(&client_config);
> >         ---------------> barrier() added here;
> >         <----------------------------
> >         return ret;
> > }
> >
> > Where barrier() is the usual asm volatile with "memory" clobber, nothing
> > else.
> >
> > Nathan gave me the binary diff for the assembly generated for this function
> > without
> > the barrier and with the barrier:
> >
> > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079 -0600
> > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21
> > 14:12:52.997355907 -0600
> > @@ -7,11 +7,11 @@
> >       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
> >       f14:      e5903000        ldr     r3, [r0]
> >       f18:      e1a04000        mov     r4, r0
> > -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > +     f1c:      e1a0000d        mov     r0, sp
> >       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
> > -     f24:      e1a0000d        mov     r0, sp
> > -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> >       f30:      e5932004        ldr     r2, [r3, #4]
> >       f34:      e2822001        add     r2, r2, #1
> >       f38:      e5832004        str     r2, [r3, #4]
> > @@ -53,7 +53,7 @@
> >       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> >       fcc:      e5933000        ldr     r3, [r3]
> >       fd0:      e3130002        tst     r3, #2
> > -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
> > +     fd4:      0a0002be        beq     1ad4 <lttng_event_reserve+0xbd8>
> >       fd8:      ebfffffe        bl      0 <preempt_schedule>
> >       fdc:      ea0002bc        b       1ad4 <lttng_event_reserve+0xbd8>
> >       fe0:      e3500000        cmp     r0, #0
> >
> > We tried disabling the ftrace function tracing to get mcount out of the
> > way,
> > and the problem still reproduces.
> >
> > I'm stopping here in terms of details about the disassembly, because I
> > need to double check with Nathan that I get the right disassembly for the
> > right
> > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
> > machine.
> >
> > I'm attaching Nathan's ARM configuration.
> >
> > It does look behave a bit like this bug pointed out by Luis:
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> >
> > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> > on top of the thread stack (?). If it's the case, then anything stored
> > on the stack below "sp" could be overwritten by an interrupt handler.
> > This would fit well the reproduction scenario for this bug: Nathan runs
> > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> > A race between a short window of stack use below sp and interrupt handlers
> > would trigger with this kind of stress-test.
> >
> > Thoughts ?
> >
> > Thanks,
> >
> > Mathieu
> >
> >
> > --
> > Mathieu Desnoyers
> > EfficiOS Inc.
> > http://www.efficios.com
> 
> 
> 
> --
> 
> Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

[-- Attachment #1.1: Type: text/plain, Size: 12735 bytes --]

On Thu, Nov 21, 2013 at 7:38 PM, Mathieu Desnoyers <
mathieu.desnoyers@efficios.com> wrote:

> ----- Original Message -----
> > From: "Luis Lozano" <llozano@google.com>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> > Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler" <
> holler@ahsoftware.de>, "Linus Torvalds"
> > <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>,
> "Linux Kernel Mailing List"
> > <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> "Catalin Marinas" <catalin.marinas@arm.com>,
> > "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <
> akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > Sent: Thursday, November 21, 2013 9:36:27 PM
> > Subject: Re: current_thread_info() not respecting program order with gcc
> 4.8.x
> >
> > Hi Mathieu,
> >
> > Yes the problem we were seeing with GCC bug 58854 is that an interrupt
> > handler was corrupting the stack of a routine which had an invalid
> > value of SP (not really on "top" of the stack) for part of the
> > routine.
> > But in the assembly code you sent, I don't see where sp is being
> > modified... or where the access to "below" sp is happening.
>
> The following instruction
>
>   f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>
> appears in the assembly generated by gcc 4.8.2, but not in the one
> generated by 4.7.3, which makes me wonder if it's good or not.



It is there in 4.7.3 just a few lines difference.
I don't see any meaningful difference between the 2 assembly snippets...
Just instructions ordered a little different?

Luis


> With
> slightly different build output from the diff (probably a different config
> from Nathan), the first function instructions look like:
>
> 00000efc <lttng_event_reserve>:
>      efc:       e1a0c00d        mov     ip, sp
>      f00:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl, fp,
> ip, lr, pc}
>      f04:       e24cb004        sub     fp, ip, #4
>      f08:       e24dd03c        sub     sp, sp, #60     ; 0x3c
>      f0c:       e52de004        push    {lr}            ; (str lr, [sp,
> #-4]!)
>      f10:       ebfffffe        bl      0 <__gnu_mcount_nc>
>      f14:       e5903000        ldr     r3, [r0]
>      f18:       e1a04000        mov     r4, r0
>      f1c:       e1a0000d        mov     r0, sp
>      f20:       e5936030        ldr     r6, [r3, #48]   ; 0x30
>      f24:       e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
>      f28:       e3c3303f        bic     r3, r3, #63     ; 0x3f
>      f2c:       e50b104c        str     r1, [fp, #-76]  ; 0xffffffb4
>      f30:       e5932004        ldr     r2, [r3, #4]
>      f34:       e2822001        add     r2, r2, #1
>      f38:       e5832004        str     r2, [r3, #4]
>      f3c:       ebfffffe        bl      0 <debug_smp_processor_id>
>      f40:       e59f2e44        ldr     r2, [pc, #3652] ; 1d8c
> <lttng_event_reserve+0xe90>
>      f44:       e59f3e44        ldr     r3, [pc, #3652] ; 1d90
> <lttng_event_reserve+0xe94>
>      f48:       e7921100        ldr     r1, [r2, r0, lsl #2]
>      f4c:       e1a05000        mov     r5, r0
>      f50:       e7932001        ldr     r2, [r3, r1]
>
> My rusty ARM assembler knowledge analyzes this like:
>
> ip = sp            (ip being the scratch register)
> push 11 registers * 4 bytes = 44 bytes onto the stack
> fp = ip - 4
> sp = sp - 60   (sp = ip - 104)
> push {lr} bl
> 0 <__gnu_mcount_nc>  (dynamically patched to a pop {lr})
> [...]
> store r1 into mem location fp - 76
>
> So yes, it does look like the -76 from fp is within the stack.
>
>
> > In GCC bug 58854 it was pretty clear that the restore of the sp
> > register in the epilogue is moved to somewhere close to the prologue
> > of the routine.
> > Are we missing some diffs from the assembly comparison?
>
> My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this
> morning,
> did not manage to get one working even after following 2 howtos, trying
> with Debian
> packages, etc. Nathan told me this diff was the full comparison between
> the two
> functions, but you'll understand that at this point I want to reproduce
> everything myself, because this is a _weird_ issue.
>
> But after a long day of debugging, it's time for some sleep. I will get
> back to this
> tomorrow,
>
> Thanks,
>
> Mathieu
>
> >
> > Thanks
> >
> > Luis
> >
> >
> >
> >
> > On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com> wrote:
> > > ----- Original Message -----
> > >> From: "Jakub Jelinek" <jakub@redhat.com>
> > >> To: "Luis Lozano" <llozano@google.com>
> > >> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> > >> <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
> > >> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <
> rth@twiddle.net>,
> > >> "Linux Kernel Mailing List"
> > >> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> > >> "Catalin Marinas" <catalin.marinas@arm.com>,
> > >> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> > >> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > >> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> > >> <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > >> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > >> Sent: Thursday, November 21, 2013 7:39:04 PM
> > >> Subject: Re: current_thread_info() not respecting program order with
> gcc
> > >> 4.8.x
> > >>
> > >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> > >> > I think we need a reproducer. Without this we may all be going on
> the
> > >> > wrong path. This whole conversation started on an *assumption* that
> > >> > some accesses were being reordered.
> > >> >
> > >> > evidence of the reorder or reproducer please?
> > >>
> > >> Yeah, if a compiler bug is suspected, can anybody please open
> > >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed
> source,
> > >> compiler version, flags and how it was configured and some hint in
> which
> > >> function to look for what exactly?  We don't necessarily need a
> runtime
> > >> small reproducer, but if it can be shown in the assembly what has been
> > >> reordered and why you think it shouldn't, with the above mentioned
> input
> > >> that ought to be sufficient.  Thanks.
> > >
> > > OK OK, let me reply on list first so I can share the result of a full
> day
> > > of bug hunting. We're not there yet, but many options have been
> eliminated.
> > >
> > > The issue shows up in stress test, when tracing with lttng-modules
> 2.4-rc1,
> > > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
> > > lttng-modules
> > > compiled against that kernel.
> > >
> > > First, I asked Nathan to compile his kernel with gcc 4.7, and
> lttng-modules
> > > with gcc 4.8.x (and vice-versa). The problem only appears when
> > > lttng-modules
> > > are compiled with gcc 4.8.x. The compiler version used to compile the
> rest
> > > of the kernel does not matter.
> > >
> > > Then I looked at gcc 4.8 changelog for ARM, new feature:
> > > -fno-sched-pressure
> > > (sched pressure is there by default). Nathan tried compiling
> lttng-modules
> > > with
> > > -fno-sched-pressure. The problem still reproduces.
> > >
> > > Knowing that adding barrier() outside of preempt_disable()/enable() was
> > > fixing the issue, we tried identifying which code location was
> responsible
> > > for working around the issue. Skipping a long investigation, here is
> the
> > > executive summary:
> > >
> > >
> http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
> > >
> > > Has the following function. We identified that adding a barrier() as
> shown
> > > below
> > > works around the issue:
> > >
> > > static
> > > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
> > >                       uint32_t event_id)
> > > {
> > >         struct lttng_channel *lttng_chan =
> channel_get_private(ctx->chan);
> > >         int ret, cpu;
> > >
> > >         cpu = lib_ring_buffer_get_cpu(&client_config);
> > >         if (cpu < 0)
> > >                 return -EPERM;
> > >         ctx->cpu = cpu;
> > >
> > >         switch (lttng_chan->header_type) {
> > >         case 1: /* compact */
> > >                 if (event_id > 30)
> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > >                 break;
> > >         case 2: /* large */
> > >                 if (event_id > 65534)
> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > >                 break;
> > >         default:
> > >                 WARN_ON_ONCE(1);
> > >         }
> > >
> > >         ret = lib_ring_buffer_reserve(&client_config, ctx);
> > >         if (ret)
> > >                 goto put;
> > >         lttng_write_event_header(&client_config, ctx, event_id);
> > >         return 0;
> > > put:
> > >         lib_ring_buffer_put_cpu(&client_config);
> > >         ---------------> barrier() added here;
> > >         <----------------------------
> > >         return ret;
> > > }
> > >
> > > Where barrier() is the usual asm volatile with "memory" clobber,
> nothing
> > > else.
> > >
> > > Nathan gave me the binary diff for the assembly generated for this
> function
> > > without
> > > the barrier and with the barrier:
> > >
> > > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079
> -0600
> > > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21
> > > 14:12:52.997355907 -0600
> > > @@ -7,11 +7,11 @@
> > >       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
> > >       f14:      e5903000        ldr     r3, [r0]
> > >       f18:      e1a04000        mov     r4, r0
> > > -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > > +     f1c:      e1a0000d        mov     r0, sp
> > >       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
> > > -     f24:      e1a0000d        mov     r0, sp
> > > -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > >       f30:      e5932004        ldr     r2, [r3, #4]
> > >       f34:      e2822001        add     r2, r2, #1
> > >       f38:      e5832004        str     r2, [r3, #4]
> > > @@ -53,7 +53,7 @@
> > >       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > >       fcc:      e5933000        ldr     r3, [r3]
> > >       fd0:      e3130002        tst     r3, #2
> > > -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
> > > +     fd4:      0a0002be        beq     1ad4
> <lttng_event_reserve+0xbd8>
> > >       fd8:      ebfffffe        bl      0 <preempt_schedule>
> > >       fdc:      ea0002bc        b       1ad4
> <lttng_event_reserve+0xbd8>
> > >       fe0:      e3500000        cmp     r0, #0
> > >
> > > We tried disabling the ftrace function tracing to get mcount out of the
> > > way,
> > > and the problem still reproduces.
> > >
> > > I'm stopping here in terms of details about the disassembly, because I
> > > need to double check with Nathan that I get the right disassembly for
> the
> > > right
> > > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
> > > machine.
> > >
> > > I'm attaching Nathan's ARM configuration.
> > >
> > > It does look behave a bit like this bug pointed out by Luis:
> > >
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> > >
> > > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> > > on top of the thread stack (?). If it's the case, then anything stored
> > > on the stack below "sp" could be overwritten by an interrupt handler.
> > > This would fit well the reproduction scenario for this bug: Nathan runs
> > > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> > > A race between a short window of stack use below sp and interrupt
> handlers
> > > would trigger with this kind of stress-test.
> > >
> > > Thoughts ?
> > >
> > > Thanks,
> > >
> > > Mathieu
> > >
> > >
> > > --
> > > Mathieu Desnoyers
> > > EfficiOS Inc.
> > > http://www.efficios.com
> >
> >
> >
> > --
> >
> > Luis A. Lozano | Software Engineer | llozano@google.com | +1
> (408)431-5164
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com
>

[-- Attachment #1.2: Type: text/html, Size: 18258 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

On Thu, Nov 21, 2013 at 7:38 PM, Mathieu Desnoyers
<mathieu.desnoyers@efficios.com> wrote:
>
> ----- Original Message -----
> > From: "Luis Lozano" <llozano@google.com>
> > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> > Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> > <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
> > <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
> > "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > Sent: Thursday, November 21, 2013 9:36:27 PM
> > Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> >
> > Hi Mathieu,
> >
> > Yes the problem we were seeing with GCC bug 58854 is that an interrupt
> > handler was corrupting the stack of a routine which had an invalid
> > value of SP (not really on "top" of the stack) for part of the
> > routine.
> > But in the assembly code you sent, I don't see where sp is being
> > modified... or where the access to "below" sp is happening.
>
> The following instruction
>
>   f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>
> appears in the assembly generated by gcc 4.8.2, but not in the one
> generated by 4.7.3,



It is there in 4.7.3 just a few lines difference.
I don't see any meaningful difference between the 2 assembly snippets...
Just the instructions ordered a little different?

Luis

>
> which makes me wonder if it's good or not. With
> slightly different build output from the diff (probably a different config
> from Nathan), the first function instructions look like:
>
> 00000efc <lttng_event_reserve>:
>      efc:       e1a0c00d        mov     ip, sp
>      f00:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
>      f04:       e24cb004        sub     fp, ip, #4
>      f08:       e24dd03c        sub     sp, sp, #60     ; 0x3c
>      f0c:       e52de004        push    {lr}            ; (str lr, [sp, #-4]!)
>      f10:       ebfffffe        bl      0 <__gnu_mcount_nc>
>      f14:       e5903000        ldr     r3, [r0]
>      f18:       e1a04000        mov     r4, r0
>      f1c:       e1a0000d        mov     r0, sp
>      f20:       e5936030        ldr     r6, [r3, #48]   ; 0x30
>      f24:       e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
>      f28:       e3c3303f        bic     r3, r3, #63     ; 0x3f
>      f2c:       e50b104c        str     r1, [fp, #-76]  ; 0xffffffb4
>      f30:       e5932004        ldr     r2, [r3, #4]
>      f34:       e2822001        add     r2, r2, #1
>      f38:       e5832004        str     r2, [r3, #4]
>      f3c:       ebfffffe        bl      0 <debug_smp_processor_id>
>      f40:       e59f2e44        ldr     r2, [pc, #3652] ; 1d8c <lttng_event_reserve+0xe90>
>      f44:       e59f3e44        ldr     r3, [pc, #3652] ; 1d90 <lttng_event_reserve+0xe94>
>      f48:       e7921100        ldr     r1, [r2, r0, lsl #2]
>      f4c:       e1a05000        mov     r5, r0
>      f50:       e7932001        ldr     r2, [r3, r1]
>
> My rusty ARM assembler knowledge analyzes this like:
>
> ip = sp            (ip being the scratch register)
> push 11 registers * 4 bytes = 44 bytes onto the stack
> fp = ip - 4
> sp = sp - 60   (sp = ip - 104)
> push {lr} bl
> 0 <__gnu_mcount_nc>  (dynamically patched to a pop {lr})
> [...]
> store r1 into mem location fp - 76
>
> So yes, it does look like the -76 from fp is within the stack.
>
>
> > In GCC bug 58854 it was pretty clear that the restore of the sp
> > register in the epilogue is moved to somewhere close to the prologue
> > of the routine.
> > Are we missing some diffs from the assembly comparison?
>
> My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this morning,
> did not manage to get one working even after following 2 howtos, trying with Debian
> packages, etc. Nathan told me this diff was the full comparison between the two
> functions, but you'll understand that at this point I want to reproduce
> everything myself, because this is a _weird_ issue.
>
> But after a long day of debugging, it's time for some sleep. I will get back to this
> tomorrow,
>
> Thanks,
>
> Mathieu
>
> >
> > Thanks
> >
> > Luis
> >
> >
> >
> >
> > On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
> > <mathieu.desnoyers@efficios.com> wrote:
> > > ----- Original Message -----
> > >> From: "Jakub Jelinek" <jakub@redhat.com>
> > >> To: "Luis Lozano" <llozano@google.com>
> > >> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> > >> <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
> > >> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <rth@twiddle.net>,
> > >> "Linux Kernel Mailing List"
> > >> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> > >> "Catalin Marinas" <catalin.marinas@arm.com>,
> > >> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> > >> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > >> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> > >> <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > >> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > >> Sent: Thursday, November 21, 2013 7:39:04 PM
> > >> Subject: Re: current_thread_info() not respecting program order with gcc
> > >> 4.8.x
> > >>
> > >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> > >> > I think we need a reproducer. Without this we may all be going on the
> > >> > wrong path. This whole conversation started on an *assumption* that
> > >> > some accesses were being reordered.
> > >> >
> > >> > evidence of the reorder or reproducer please?
> > >>
> > >> Yeah, if a compiler bug is suspected, can anybody please open
> > >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
> > >> compiler version, flags and how it was configured and some hint in which
> > >> function to look for what exactly?  We don't necessarily need a runtime
> > >> small reproducer, but if it can be shown in the assembly what has been
> > >> reordered and why you think it shouldn't, with the above mentioned input
> > >> that ought to be sufficient.  Thanks.
> > >
> > > OK OK, let me reply on list first so I can share the result of a full day
> > > of bug hunting. We're not there yet, but many options have been eliminated.
> > >
> > > The issue shows up in stress test, when tracing with lttng-modules 2.4-rc1,
> > > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
> > > lttng-modules
> > > compiled against that kernel.
> > >
> > > First, I asked Nathan to compile his kernel with gcc 4.7, and lttng-modules
> > > with gcc 4.8.x (and vice-versa). The problem only appears when
> > > lttng-modules
> > > are compiled with gcc 4.8.x. The compiler version used to compile the rest
> > > of the kernel does not matter.
> > >
> > > Then I looked at gcc 4.8 changelog for ARM, new feature:
> > > -fno-sched-pressure
> > > (sched pressure is there by default). Nathan tried compiling lttng-modules
> > > with
> > > -fno-sched-pressure. The problem still reproduces.
> > >
> > > Knowing that adding barrier() outside of preempt_disable()/enable() was
> > > fixing the issue, we tried identifying which code location was responsible
> > > for working around the issue. Skipping a long investigation, here is the
> > > executive summary:
> > >
> > > http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
> > >
> > > Has the following function. We identified that adding a barrier() as shown
> > > below
> > > works around the issue:
> > >
> > > static
> > > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
> > >                       uint32_t event_id)
> > > {
> > >         struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
> > >         int ret, cpu;
> > >
> > >         cpu = lib_ring_buffer_get_cpu(&client_config);
> > >         if (cpu < 0)
> > >                 return -EPERM;
> > >         ctx->cpu = cpu;
> > >
> > >         switch (lttng_chan->header_type) {
> > >         case 1: /* compact */
> > >                 if (event_id > 30)
> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > >                 break;
> > >         case 2: /* large */
> > >                 if (event_id > 65534)
> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > >                 break;
> > >         default:
> > >                 WARN_ON_ONCE(1);
> > >         }
> > >
> > >         ret = lib_ring_buffer_reserve(&client_config, ctx);
> > >         if (ret)
> > >                 goto put;
> > >         lttng_write_event_header(&client_config, ctx, event_id);
> > >         return 0;
> > > put:
> > >         lib_ring_buffer_put_cpu(&client_config);
> > >         ---------------> barrier() added here;
> > >         <----------------------------
> > >         return ret;
> > > }
> > >
> > > Where barrier() is the usual asm volatile with "memory" clobber, nothing
> > > else.
> > >
> > > Nathan gave me the binary diff for the assembly generated for this function
> > > without
> > > the barrier and with the barrier:
> > >
> > > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079 -0600
> > > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21
> > > 14:12:52.997355907 -0600
> > > @@ -7,11 +7,11 @@
> > >       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
> > >       f14:      e5903000        ldr     r3, [r0]
> > >       f18:      e1a04000        mov     r4, r0
> > > -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > > +     f1c:      e1a0000d        mov     r0, sp
> > >       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
> > > -     f24:      e1a0000d        mov     r0, sp
> > > -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > >       f30:      e5932004        ldr     r2, [r3, #4]
> > >       f34:      e2822001        add     r2, r2, #1
> > >       f38:      e5832004        str     r2, [r3, #4]
> > > @@ -53,7 +53,7 @@
> > >       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > >       fcc:      e5933000        ldr     r3, [r3]
> > >       fd0:      e3130002        tst     r3, #2
> > > -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
> > > +     fd4:      0a0002be        beq     1ad4 <lttng_event_reserve+0xbd8>
> > >       fd8:      ebfffffe        bl      0 <preempt_schedule>
> > >       fdc:      ea0002bc        b       1ad4 <lttng_event_reserve+0xbd8>
> > >       fe0:      e3500000        cmp     r0, #0
> > >
> > > We tried disabling the ftrace function tracing to get mcount out of the
> > > way,
> > > and the problem still reproduces.
> > >
> > > I'm stopping here in terms of details about the disassembly, because I
> > > need to double check with Nathan that I get the right disassembly for the
> > > right
> > > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
> > > machine.
> > >
> > > I'm attaching Nathan's ARM configuration.
> > >
> > > It does look behave a bit like this bug pointed out by Luis:
> > >
> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> > >
> > > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> > > on top of the thread stack (?). If it's the case, then anything stored
> > > on the stack below "sp" could be overwritten by an interrupt handler.
> > > This would fit well the reproduction scenario for this bug: Nathan runs
> > > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> > > A race between a short window of stack use below sp and interrupt handlers
> > > would trigger with this kind of stress-test.
> > >
> > > Thoughts ?
> > >
> > > Thanks,
> > >
> > > Mathieu
> > >
> > >
> > > --
> > > Mathieu Desnoyers
> > > EfficiOS Inc.
> > > http://www.efficios.com
> >
> >
> >
> > --
> >
> > Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164
> >
>
> --
> Mathieu Desnoyers
> EfficiOS Inc.
> http://www.efficios.com

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Luis Lozano]

On Fri, Nov 22, 2013 at 12:18 AM, Luis Lozano <llozano@chromium.org> wrote:
> On Thu, Nov 21, 2013 at 7:38 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
>>
>> ----- Original Message -----
>> > From: "Luis Lozano" <llozano@google.com>
>> > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
>> > Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
>> > <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
>> > <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
>> > "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
>> > E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
>> > <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
>> > Sent: Thursday, November 21, 2013 9:36:27 PM
>> > Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
>> >
>> > Hi Mathieu,
>> >
>> > Yes the problem we were seeing with GCC bug 58854 is that an interrupt
>> > handler was corrupting the stack of a routine which had an invalid
>> > value of SP (not really on "top" of the stack) for part of the
>> > routine.
>> > But in the assembly code you sent, I don't see where sp is being
>> > modified... or where the access to "below" sp is happening.
>>
>> The following instruction
>>
>>   f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>>
>> appears in the assembly generated by gcc 4.8.2, but not in the one
>> generated by 4.7.3,
>
>
>
> It is there in 4.7.3 just a few lines difference.
> I don't see any meaningful difference between the 2 assembly snippets...
> Just the instructions ordered a little different?
>

unless there is a dependency between the following 2 instructions?
-     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
...
      f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30

and moving the str across the ldr makes a difference...


> Luis
>
>>
>> which makes me wonder if it's good or not. With
>> slightly different build output from the diff (probably a different config
>> from Nathan), the first function instructions look like:
>>
>> 00000efc <lttng_event_reserve>:
>>      efc:       e1a0c00d        mov     ip, sp
>>      f00:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
>>      f04:       e24cb004        sub     fp, ip, #4
>>      f08:       e24dd03c        sub     sp, sp, #60     ; 0x3c
>>      f0c:       e52de004        push    {lr}            ; (str lr, [sp, #-4]!)
>>      f10:       ebfffffe        bl      0 <__gnu_mcount_nc>
>>      f14:       e5903000        ldr     r3, [r0]
>>      f18:       e1a04000        mov     r4, r0
>>      f1c:       e1a0000d        mov     r0, sp
>>      f20:       e5936030        ldr     r6, [r3, #48]   ; 0x30
>>      f24:       e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
>>      f28:       e3c3303f        bic     r3, r3, #63     ; 0x3f
>>      f2c:       e50b104c        str     r1, [fp, #-76]  ; 0xffffffb4
>>      f30:       e5932004        ldr     r2, [r3, #4]
>>      f34:       e2822001        add     r2, r2, #1
>>      f38:       e5832004        str     r2, [r3, #4]
>>      f3c:       ebfffffe        bl      0 <debug_smp_processor_id>
>>      f40:       e59f2e44        ldr     r2, [pc, #3652] ; 1d8c <lttng_event_reserve+0xe90>
>>      f44:       e59f3e44        ldr     r3, [pc, #3652] ; 1d90 <lttng_event_reserve+0xe94>
>>      f48:       e7921100        ldr     r1, [r2, r0, lsl #2]
>>      f4c:       e1a05000        mov     r5, r0
>>      f50:       e7932001        ldr     r2, [r3, r1]
>>
>> My rusty ARM assembler knowledge analyzes this like:
>>
>> ip = sp            (ip being the scratch register)
>> push 11 registers * 4 bytes = 44 bytes onto the stack
>> fp = ip - 4
>> sp = sp - 60   (sp = ip - 104)
>> push {lr} bl
>> 0 <__gnu_mcount_nc>  (dynamically patched to a pop {lr})
>> [...]
>> store r1 into mem location fp - 76
>>
>> So yes, it does look like the -76 from fp is within the stack.
>>
>>
>> > In GCC bug 58854 it was pretty clear that the restore of the sp
>> > register in the epilogue is moved to somewhere close to the prologue
>> > of the routine.
>> > Are we missing some diffs from the assembly comparison?
>>
>> My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this morning,
>> did not manage to get one working even after following 2 howtos, trying with Debian
>> packages, etc. Nathan told me this diff was the full comparison between the two
>> functions, but you'll understand that at this point I want to reproduce
>> everything myself, because this is a _weird_ issue.
>>
>> But after a long day of debugging, it's time for some sleep. I will get back to this
>> tomorrow,
>>
>> Thanks,
>>
>> Mathieu
>>
>> >
>> > Thanks
>> >
>> > Luis
>> >
>> >
>> >
>> >
>> > On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
>> > <mathieu.desnoyers@efficios.com> wrote:
>> > > ----- Original Message -----
>> > >> From: "Jakub Jelinek" <jakub@redhat.com>
>> > >> To: "Luis Lozano" <llozano@google.com>
>> > >> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
>> > >> <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
>> > >> <mathieu.desnoyers@efficios.com>, "Richard Henderson" <rth@twiddle.net>,
>> > >> "Linux Kernel Mailing List"
>> > >> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
>> > >> "Catalin Marinas" <catalin.marinas@arm.com>,
>> > >> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
>> > >> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
>> > >> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
>> > >> <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
>> > >> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
>> > >> Sent: Thursday, November 21, 2013 7:39:04 PM
>> > >> Subject: Re: current_thread_info() not respecting program order with gcc
>> > >> 4.8.x
>> > >>
>> > >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
>> > >> > I think we need a reproducer. Without this we may all be going on the
>> > >> > wrong path. This whole conversation started on an *assumption* that
>> > >> > some accesses were being reordered.
>> > >> >
>> > >> > evidence of the reorder or reproducer please?
>> > >>
>> > >> Yeah, if a compiler bug is suspected, can anybody please open
>> > >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed source,
>> > >> compiler version, flags and how it was configured and some hint in which
>> > >> function to look for what exactly?  We don't necessarily need a runtime
>> > >> small reproducer, but if it can be shown in the assembly what has been
>> > >> reordered and why you think it shouldn't, with the above mentioned input
>> > >> that ought to be sufficient.  Thanks.
>> > >
>> > > OK OK, let me reply on list first so I can share the result of a full day
>> > > of bug hunting. We're not there yet, but many options have been eliminated.
>> > >
>> > > The issue shows up in stress test, when tracing with lttng-modules 2.4-rc1,
>> > > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
>> > > lttng-modules
>> > > compiled against that kernel.
>> > >
>> > > First, I asked Nathan to compile his kernel with gcc 4.7, and lttng-modules
>> > > with gcc 4.8.x (and vice-versa). The problem only appears when
>> > > lttng-modules
>> > > are compiled with gcc 4.8.x. The compiler version used to compile the rest
>> > > of the kernel does not matter.
>> > >
>> > > Then I looked at gcc 4.8 changelog for ARM, new feature:
>> > > -fno-sched-pressure
>> > > (sched pressure is there by default). Nathan tried compiling lttng-modules
>> > > with
>> > > -fno-sched-pressure. The problem still reproduces.
>> > >
>> > > Knowing that adding barrier() outside of preempt_disable()/enable() was
>> > > fixing the issue, we tried identifying which code location was responsible
>> > > for working around the issue. Skipping a long investigation, here is the
>> > > executive summary:
>> > >
>> > > http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
>> > >
>> > > Has the following function. We identified that adding a barrier() as shown
>> > > below
>> > > works around the issue:
>> > >
>> > > static
>> > > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
>> > >                       uint32_t event_id)
>> > > {
>> > >         struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
>> > >         int ret, cpu;
>> > >
>> > >         cpu = lib_ring_buffer_get_cpu(&client_config);
>> > >         if (cpu < 0)
>> > >                 return -EPERM;
>> > >         ctx->cpu = cpu;
>> > >
>> > >         switch (lttng_chan->header_type) {
>> > >         case 1: /* compact */
>> > >                 if (event_id > 30)
>> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
>> > >                 break;
>> > >         case 2: /* large */
>> > >                 if (event_id > 65534)
>> > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
>> > >                 break;
>> > >         default:
>> > >                 WARN_ON_ONCE(1);
>> > >         }
>> > >
>> > >         ret = lib_ring_buffer_reserve(&client_config, ctx);
>> > >         if (ret)
>> > >                 goto put;
>> > >         lttng_write_event_header(&client_config, ctx, event_id);
>> > >         return 0;
>> > > put:
>> > >         lib_ring_buffer_put_cpu(&client_config);
>> > >         ---------------> barrier() added here;
>> > >         <----------------------------
>> > >         return ret;
>> > > }
>> > >
>> > > Where barrier() is the usual asm volatile with "memory" clobber, nothing
>> > > else.
>> > >
>> > > Nathan gave me the binary diff for the assembly generated for this function
>> > > without
>> > > the barrier and with the barrier:
>> > >
>> > > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079 -0600
>> > > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21
>> > > 14:12:52.997355907 -0600
>> > > @@ -7,11 +7,11 @@
>> > >       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
>> > >       f14:      e5903000        ldr     r3, [r0]
>> > >       f18:      e1a04000        mov     r4, r0
>> > > -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>> > > +     f1c:      e1a0000d        mov     r0, sp
>> > >       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
>> > > -     f24:      e1a0000d        mov     r0, sp
>> > > -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
>> > > -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
>> > > +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
>> > > +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
>> > > +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
>> > >       f30:      e5932004        ldr     r2, [r3, #4]
>> > >       f34:      e2822001        add     r2, r2, #1
>> > >       f38:      e5832004        str     r2, [r3, #4]
>> > > @@ -53,7 +53,7 @@
>> > >       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
>> > >       fcc:      e5933000        ldr     r3, [r3]
>> > >       fd0:      e3130002        tst     r3, #2
>> > > -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
>> > > +     fd4:      0a0002be        beq     1ad4 <lttng_event_reserve+0xbd8>
>> > >       fd8:      ebfffffe        bl      0 <preempt_schedule>
>> > >       fdc:      ea0002bc        b       1ad4 <lttng_event_reserve+0xbd8>
>> > >       fe0:      e3500000        cmp     r0, #0
>> > >
>> > > We tried disabling the ftrace function tracing to get mcount out of the
>> > > way,
>> > > and the problem still reproduces.
>> > >
>> > > I'm stopping here in terms of details about the disassembly, because I
>> > > need to double check with Nathan that I get the right disassembly for the
>> > > right
>> > > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
>> > > machine.
>> > >
>> > > I'm attaching Nathan's ARM configuration.
>> > >
>> > > It does look behave a bit like this bug pointed out by Luis:
>> > >
>> > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
>> > >
>> > > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
>> > > on top of the thread stack (?). If it's the case, then anything stored
>> > > on the stack below "sp" could be overwritten by an interrupt handler.
>> > > This would fit well the reproduction scenario for this bug: Nathan runs
>> > > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
>> > > A race between a short window of stack use below sp and interrupt handlers
>> > > would trigger with this kind of stress-test.
>> > >
>> > > Thoughts ?
>> > >
>> > > Thanks,
>> > >
>> > > Mathieu
>> > >
>> > >
>> > > --
>> > > Mathieu Desnoyers
>> > > EfficiOS Inc.
>> > > http://www.efficios.com
>> >
>> >
>> >
>> > --
>> >
>> > Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164
>> >
>>
>> --
>> Mathieu Desnoyers
>> EfficiOS Inc.
>> http://www.efficios.com



-- 

Luis A. Lozano | Software Engineer | llozano@google.com | +1 (408)431-5164

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

----- Original Message -----
> From: "Luis Lozano" <llozano@chromium.org>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>, "Catalin Marinas" <catalin.marinas@arm.com>,
> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> Sent: Friday, November 22, 2013 3:18:14 AM
> Subject: Re: current_thread_info() not respecting program order with gcc 4.8.x
> 
> On Thu, Nov 21, 2013 at 7:38 PM, Mathieu Desnoyers
> <mathieu.desnoyers@efficios.com> wrote:
> >
> > ----- Original Message -----
> > > From: "Luis Lozano" <llozano@google.com>
> > > To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> > > Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler"
> > > <holler@ahsoftware.de>, "Linus Torvalds"
> > > <torvalds@linux-foundation.org>, "Richard Henderson" <rth@twiddle.net>,
> > > "Linux Kernel Mailing List"
> > > <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> > > "Catalin Marinas" <catalin.marinas@arm.com>,
> > > "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> > > "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > > E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> > > <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > > <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > > Sent: Thursday, November 21, 2013 9:36:27 PM
> > > Subject: Re: current_thread_info() not respecting program order with gcc
> > > 4.8.x
> > >
> > > Hi Mathieu,
> > >
> > > Yes the problem we were seeing with GCC bug 58854 is that an interrupt
> > > handler was corrupting the stack of a routine which had an invalid
> > > value of SP (not really on "top" of the stack) for part of the
> > > routine.
> > > But in the assembly code you sent, I don't see where sp is being
> > > modified... or where the access to "below" sp is happening.
> >
> > The following instruction
> >
> >   f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> >
> > appears in the assembly generated by gcc 4.8.2, but not in the one
> > generated by 4.7.3,
> 
> 
> 
> It is there in 4.7.3 just a few lines difference.
> I don't see any meaningful difference between the 2 assembly snippets...
> Just the instructions ordered a little different?
> 
> Luis

(resending reply in plain text)


Assembly generated by 4.7.3 vs 4.8.2 are much more different.

The diff I've presented yesterday is between 4.8.2 and 4.8.2+barrier() at the end of
the function error path. When I can get a cross compiler to work, I will send out more
the complete assembly listings of the function.

Thanks,

Mathieu


> 
> >
> > which makes me wonder if it's good or not. With
> > slightly different build output from the diff (probably a different config
> > from Nathan), the first function instructions look like:
> >
> > 00000efc <lttng_event_reserve>:
> >      efc:       e1a0c00d        mov     ip, sp
> >      f00:       e92ddff0        push    {r4, r5, r6, r7, r8, r9, sl, fp,
> >      ip, lr, pc}
> >      f04:       e24cb004        sub     fp, ip, #4
> >      f08:       e24dd03c        sub     sp, sp, #60     ; 0x3c
> >      f0c:       e52de004        push    {lr}            ; (str lr, [sp,
> >      #-4]!)
> >      f10:       ebfffffe        bl      0 <__gnu_mcount_nc>
> >      f14:       e5903000        ldr     r3, [r0]
> >      f18:       e1a04000        mov     r4, r0
> >      f1c:       e1a0000d        mov     r0, sp
> >      f20:       e5936030        ldr     r6, [r3, #48]   ; 0x30
> >      f24:       e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> >      f28:       e3c3303f        bic     r3, r3, #63     ; 0x3f
> >      f2c:       e50b104c        str     r1, [fp, #-76]  ; 0xffffffb4
> >      f30:       e5932004        ldr     r2, [r3, #4]
> >      f34:       e2822001        add     r2, r2, #1
> >      f38:       e5832004        str     r2, [r3, #4]
> >      f3c:       ebfffffe        bl      0 <debug_smp_processor_id>
> >      f40:       e59f2e44        ldr     r2, [pc, #3652] ; 1d8c
> >      <lttng_event_reserve+0xe90>
> >      f44:       e59f3e44        ldr     r3, [pc, #3652] ; 1d90
> >      <lttng_event_reserve+0xe94>
> >      f48:       e7921100        ldr     r1, [r2, r0, lsl #2]
> >      f4c:       e1a05000        mov     r5, r0
> >      f50:       e7932001        ldr     r2, [r3, r1]
> >
> > My rusty ARM assembler knowledge analyzes this like:
> >
> > ip = sp            (ip being the scratch register)
> > push 11 registers * 4 bytes = 44 bytes onto the stack
> > fp = ip - 4
> > sp = sp - 60   (sp = ip - 104)
> > push {lr} bl
> > 0 <__gnu_mcount_nc>  (dynamically patched to a pop {lr})
> > [...]
> > store r1 into mem location fp - 76
> >
> > So yes, it does look like the -76 from fp is within the stack.
> >
> >
> > > In GCC bug 58854 it was pretty clear that the restore of the sp
> > > register in the epilogue is moved to somewhere close to the prologue
> > > of the routine.
> > > Are we missing some diffs from the assembly comparison?
> >
> > My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this
> > morning,
> > did not manage to get one working even after following 2 howtos, trying
> > with Debian
> > packages, etc. Nathan told me this diff was the full comparison between the
> > two
> > functions, but you'll understand that at this point I want to reproduce
> > everything myself, because this is a _weird_ issue.
> >
> > But after a long day of debugging, it's time for some sleep. I will get
> > back to this
> > tomorrow,
> >
> > Thanks,
> >
> > Mathieu
> >
> > >
> > > Thanks
> > >
> > > Luis
> > >
> > >
> > >
> > >
> > > On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
> > > <mathieu.desnoyers@efficios.com> wrote:
> > > > ----- Original Message -----
> > > >> From: "Jakub Jelinek" <jakub@redhat.com>
> > > >> To: "Luis Lozano" <llozano@google.com>
> > > >> Cc: "Alexander Holler" <holler@ahsoftware.de>, "Linus Torvalds"
> > > >> <torvalds@linux-foundation.org>, "Mathieu Desnoyers"
> > > >> <mathieu.desnoyers@efficios.com>, "Richard Henderson"
> > > >> <rth@twiddle.net>,
> > > >> "Linux Kernel Mailing List"
> > > >> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> > > >> "Catalin Marinas" <catalin.marinas@arm.com>,
> > > >> "Peter Zijlstra" <peterz@infradead.org>, lttng-dev@lists.lttng.org,
> > > >> "Nathan Lynch" <Nathan_Lynch@mentor.com>, "Paul
> > > >> E. McKenney" <paulmck@linux.vnet.ibm.com>, "Andrew Morton"
> > > >> <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> > > >> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> > > >> Sent: Thursday, November 21, 2013 7:39:04 PM
> > > >> Subject: Re: current_thread_info() not respecting program order with
> > > >> gcc
> > > >> 4.8.x
> > > >>
> > > >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> > > >> > I think we need a reproducer. Without this we may all be going on
> > > >> > the
> > > >> > wrong path. This whole conversation started on an *assumption* that
> > > >> > some accesses were being reordered.
> > > >> >
> > > >> > evidence of the reorder or reproducer please?
> > > >>
> > > >> Yeah, if a compiler bug is suspected, can anybody please open
> > > >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed
> > > >> source,
> > > >> compiler version, flags and how it was configured and some hint in
> > > >> which
> > > >> function to look for what exactly?  We don't necessarily need a
> > > >> runtime
> > > >> small reproducer, but if it can be shown in the assembly what has been
> > > >> reordered and why you think it shouldn't, with the above mentioned
> > > >> input
> > > >> that ought to be sufficient.  Thanks.
> > > >
> > > > OK OK, let me reply on list first so I can share the result of a full
> > > > day
> > > > of bug hunting. We're not there yet, but many options have been
> > > > eliminated.
> > > >
> > > > The issue shows up in stress test, when tracing with lttng-modules
> > > > 2.4-rc1,
> > > > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
> > > > lttng-modules
> > > > compiled against that kernel.
> > > >
> > > > First, I asked Nathan to compile his kernel with gcc 4.7, and
> > > > lttng-modules
> > > > with gcc 4.8.x (and vice-versa). The problem only appears when
> > > > lttng-modules
> > > > are compiled with gcc 4.8.x. The compiler version used to compile the
> > > > rest
> > > > of the kernel does not matter.
> > > >
> > > > Then I looked at gcc 4.8 changelog for ARM, new feature:
> > > > -fno-sched-pressure
> > > > (sched pressure is there by default). Nathan tried compiling
> > > > lttng-modules
> > > > with
> > > > -fno-sched-pressure. The problem still reproduces.
> > > >
> > > > Knowing that adding barrier() outside of preempt_disable()/enable() was
> > > > fixing the issue, we tried identifying which code location was
> > > > responsible
> > > > for working around the issue. Skipping a long investigation, here is
> > > > the
> > > > executive summary:
> > > >
> > > > http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
> > > >
> > > > Has the following function. We identified that adding a barrier() as
> > > > shown
> > > > below
> > > > works around the issue:
> > > >
> > > > static
> > > > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
> > > >                       uint32_t event_id)
> > > > {
> > > >         struct lttng_channel *lttng_chan =
> > > >         channel_get_private(ctx->chan);
> > > >         int ret, cpu;
> > > >
> > > >         cpu = lib_ring_buffer_get_cpu(&client_config);
> > > >         if (cpu < 0)
> > > >                 return -EPERM;
> > > >         ctx->cpu = cpu;
> > > >
> > > >         switch (lttng_chan->header_type) {
> > > >         case 1: /* compact */
> > > >                 if (event_id > 30)
> > > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > > >                 break;
> > > >         case 2: /* large */
> > > >                 if (event_id > 65534)
> > > >                         ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> > > >                 break;
> > > >         default:
> > > >                 WARN_ON_ONCE(1);
> > > >         }
> > > >
> > > >         ret = lib_ring_buffer_reserve(&client_config, ctx);
> > > >         if (ret)
> > > >                 goto put;
> > > >         lttng_write_event_header(&client_config, ctx, event_id);
> > > >         return 0;
> > > > put:
> > > >         lib_ring_buffer_put_cpu(&client_config);
> > > >         ---------------> barrier() added here;
> > > >         <----------------------------
> > > >         return ret;
> > > > }
> > > >
> > > > Where barrier() is the usual asm volatile with "memory" clobber,
> > > > nothing
> > > > else.
> > > >
> > > > Nathan gave me the binary diff for the assembly generated for this
> > > > function
> > > > without
> > > > the barrier and with the barrier:
> > > >
> > > > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079
> > > > -0600
> > > > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump    2013-11-21
> > > > 14:12:52.997355907 -0600
> > > > @@ -7,11 +7,11 @@
> > > >       f10:      ebfffffe        bl      0 <__gnu_mcount_nc>
> > > >       f14:      e5903000        ldr     r3, [r0]
> > > >       f18:      e1a04000        mov     r4, r0
> > > > -     f1c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > > > +     f1c:      e1a0000d        mov     r0, sp
> > > >       f20:      e5936030        ldr     r6, [r3, #48]   ; 0x30
> > > > -     f24:      e1a0000d        mov     r0, sp
> > > > -     f28:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > > -     f2c:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > > +     f24:      e3c03d7f        bic     r3, r0, #8128   ; 0x1fc0
> > > > +     f28:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > > +     f2c:      e50b1048        str     r1, [fp, #-72]  ; 0xffffffb8
> > > >       f30:      e5932004        ldr     r2, [r3, #4]
> > > >       f34:      e2822001        add     r2, r2, #1
> > > >       f38:      e5832004        str     r2, [r3, #4]
> > > > @@ -53,7 +53,7 @@
> > > >       fc8:      e3c3303f        bic     r3, r3, #63     ; 0x3f
> > > >       fcc:      e5933000        ldr     r3, [r3]
> > > >       fd0:      e3130002        tst     r3, #2
> > > > -     fd4:      0a000000        beq     fdc <lttng_event_reserve+0xe0>
> > > > +     fd4:      0a0002be        beq     1ad4
> > > > <lttng_event_reserve+0xbd8>
> > > >       fd8:      ebfffffe        bl      0 <preempt_schedule>
> > > >       fdc:      ea0002bc        b       1ad4
> > > >       <lttng_event_reserve+0xbd8>
> > > >       fe0:      e3500000        cmp     r0, #0
> > > >
> > > > We tried disabling the ftrace function tracing to get mcount out of the
> > > > way,
> > > > and the problem still reproduces.
> > > >
> > > > I'm stopping here in terms of details about the disassembly, because I
> > > > need to double check with Nathan that I get the right disassembly for
> > > > the
> > > > right
> > > > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
> > > > machine.
> > > >
> > > > I'm attaching Nathan's ARM configuration.
> > > >
> > > > It does look behave a bit like this bug pointed out by Luis:
> > > >
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> > > >
> > > > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> > > > on top of the thread stack (?). If it's the case, then anything stored
> > > > on the stack below "sp" could be overwritten by an interrupt handler.
> > > > This would fit well the reproduction scenario for this bug: Nathan runs
> > > > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> > > > A race between a short window of stack use below sp and interrupt
> > > > handlers
> > > > would trigger with this kind of stress-test.
> > > >
> > > > Thoughts ?
> > > >
> > > > Thanks,
> > > >
> > > > Mathieu
> > > >
> > > >
> > > > --
> > > > Mathieu Desnoyers
> > > > EfficiOS Inc.
> > > > http://www.efficios.com
> > >
> > >
> > >
> > > --
> > >
> > > Luis A. Lozano | Software Engineer | llozano@google.com | +1
> > > (408)431-5164
> > >
> >
> > --
> > Mathieu Desnoyers
> > EfficiOS Inc.
> > http://www.efficios.com
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

Re: [lttng-dev] current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

[-- Attachment #1: Type: text/plain, Size: 2019 bytes --]

Very interesting result:

Here is the asm diff between the problematic function compiled with gcc 4.8.2
vs that same function compiled with gcc 4.8.2 with the "lightly tested patch"
in bug http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854

--- lttng-ring-buffer-client-overwrite.ko-4.8.2.objdump	2013-11-22 13:53:39.634901143 -0600
+++ lttng-ring-buffer-client-overwrite.ko-4.8.2-fix.objdump	2013-11-22 13:56:28.717746721 -0600
@@ -363,9 +363,9 @@ Disassembly of section .text:
      504:	e0647008 	rsb	r7, r4, r8
      508:	e0874004 	add	r4, r7, r4
      50c:	e0650004 	rsb	r0, r5, r4
-     510:	e24bd028 	sub	sp, fp, #40	; 0x28
+     510:	e58a6000 	str	r6, [sl]
      514:	e6ef0070 	uxtb	r0, r0
-     518:	e58a6000 	str	r6, [sl]
+     518:	e24bd028 	sub	sp, fp, #40	; 0x28
      51c:	e89daff0 	ldm	sp, {r4, r5, r6, r7, r8, r9, sl, fp, sp, pc}
 	...
 
@@ -1938,8 +1938,8 @@ Disassembly of section .text:
     1d74:	ebfffffe 	bl	0 <warn_slowpath_null>
     1d78:	e51b205c 	ldr	r2, [fp, #-92]	; 0x5c
     1d7c:	eafffef5 	b	1958 <lttng_event_reserve+0xa5c>
-    1d80:	e24bd028 	sub	sp, fp, #40	; 0x28
-    1d84:	e51b0048 	ldr	r0, [fp, #-72]	; 0x48
+    1d80:	e51b0048 	ldr	r0, [fp, #-72]	; 0x48
+    1d84:	e24bd028 	sub	sp, fp, #40	; 0x28
     1d88:	e89daff0 	ldm	sp, {r4, r5, r6, r7, r8, r9, sl, fp, sp, pc}
 	...
     1d98:	0000017e 	.word	0x0000017e

So far, Nathan has not reproduced the issue with the fixed gcc. He's running those
stress tests a couple more hours to get more confidence in the result.

Not sure about the first two stores (they use the stack limit pointer "sl", which
I'm clueless about), but the last snippet clearly fixes a one instruction stack
usage below sp race window. Before the fix:

-    1d80:	e24bd028 	sub	sp, fp, #40	; 0x28
-    1d84:	e51b0048 	ldr	r0, [fp, #-72]	; 0x48

sp = fp - 40
load from memory location fp - 72   .... wrong !

The full objdumps (before and after gcc fix) are attached.

Thoughts ?

Thanks,

Mathieu

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com

[-- Attachment #2: gcc bz 58854 fix objdumps.zip --]
[-- Type: application/zip, Size: 35107 bytes --]

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Mathieu Desnoyers]

[-- Attachment #1.1: Type: text/plain, Size: 14160 bytes --]

----- Original Message -----

> From: "Luis Lozano" <llozano@chromium.org>
> To: "Mathieu Desnoyers" <mathieu.desnoyers@efficios.com>
> Cc: "Jakub Jelinek" <jakub@redhat.com>, "Alexander Holler"
> <holler@ahsoftware.de>, "Linus Torvalds" <torvalds@linux-foundation.org>,
> "Richard Henderson" <rth@twiddle.net>, "Linux Kernel Mailing List"
> <linux-kernel@vger.kernel.org>, "Will Deacon" <will.deacon@arm.com>,
> "Catalin Marinas" <catalin.marinas@arm.com>, "Peter Zijlstra"
> <peterz@infradead.org>, lttng-dev@lists.lttng.org, "Nathan Lynch"
> <Nathan_Lynch@mentor.com>, "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>,
> "Andrew Morton" <akpm@linux-foundation.org>, "Bhaskar Janakiraman"
> <bjanakiraman@chromium.org>, "Han Shen" <shenhan@chromium.org>
> Sent: Friday, November 22, 2013 3:16:27 AM
> Subject: Re: current_thread_info() not respecting program order with gcc
> 4.8.x

> On Thu, Nov 21, 2013 at 7:38 PM, Mathieu Desnoyers <
> mathieu.desnoyers@efficios.com > wrote:

> > ----- Original Message -----
> 
> > > From: "Luis Lozano" < llozano@google.com >
> 
> > > To: "Mathieu Desnoyers" < mathieu.desnoyers@efficios.com >
> 
> > > Cc: "Jakub Jelinek" < jakub@redhat.com >, "Alexander Holler" <
> > > holler@ahsoftware.de >, "Linus Torvalds"
> 
> > > < torvalds@linux-foundation.org >, "Richard Henderson" < rth@twiddle.net
> > > >,
> > > "Linux Kernel Mailing List"
> 
> > > < linux-kernel@vger.kernel.org >, "Will Deacon" < will.deacon@arm.com >,
> > > "Catalin Marinas" < catalin.marinas@arm.com >,
> 
> > > "Peter Zijlstra" < peterz@infradead.org >, lttng-dev@lists.lttng.org ,
> > > "Nathan Lynch" < Nathan_Lynch@mentor.com >, "Paul
> 
> > > E. McKenney" < paulmck@linux.vnet.ibm.com >, "Andrew Morton" <
> > > akpm@linux-foundation.org >, "Bhaskar Janakiraman"
> 
> > > < bjanakiraman@chromium.org >, "Han Shen" < shenhan@chromium.org >
> 
> > > Sent: Thursday, November 21, 2013 9:36:27 PM
> 
> > > Subject: Re: current_thread_info() not respecting program order with gcc
> > > 4.8.x
> 
> > >
> 
> > > Hi Mathieu,
> 
> > >
> 
> > > Yes the problem we were seeing with GCC bug 58854 is that an interrupt
> 
> > > handler was corrupting the stack of a routine which had an invalid
> 
> > > value of SP (not really on "top" of the stack) for part of the
> 
> > > routine.
> 
> > > But in the assembly code you sent, I don't see where sp is being
> 
> > > modified... or where the access to "below" sp is happening.
> 

> > The following instruction
> 

> > f1c: e50b1048 str r1, [fp, #-72] ; 0xffffffb8
> 

> > appears in the assembly generated by gcc 4.8.2, but not in the one
> 
> > generated by 4.7.3, which makes me wonder if it's good or not.
> 
> It is there in 4.7.3 just a few lines difference.
> I don't see any meaningful difference between the 2 assembly snippets...
> Just instructions ordered a little different?

Assembly generated by 4.7.3 vs 4.8.2 are much more different. 

The diff I've presented yesterday is between 4.8.2 and 4.8.2+barrier() at the end of 
the function error path. When I can get a cross compiler to work, I will send out more 
the complete assembly listings of the function. 

Thanks, 

Mathieu 

> Luis

> > With
> 
> > slightly different build output from the diff (probably a different config
> 
> > from Nathan), the first function instructions look like:
> 

> > 00000efc <lttng_event_reserve>:
> 
> > efc: e1a0c00d mov ip, sp
> 
> > f00: e92ddff0 push {r4, r5, r6, r7, r8, r9, sl, fp, ip, lr, pc}
> 
> > f04: e24cb004 sub fp, ip, #4
> 
> > f08: e24dd03c sub sp, sp, #60 ; 0x3c
> 
> > f0c: e52de004 push {lr} ; (str lr, [sp, #-4]!)
> 
> > f10: ebfffffe bl 0 <__gnu_mcount_nc>
> 
> > f14: e5903000 ldr r3, [r0]
> 
> > f18: e1a04000 mov r4, r0
> 
> > f1c: e1a0000d mov r0, sp
> 
> > f20: e5936030 ldr r6, [r3, #48] ; 0x30
> 
> > f24: e3c03d7f bic r3, r0, #8128 ; 0x1fc0
> 
> > f28: e3c3303f bic r3, r3, #63 ; 0x3f
> 
> > f2c: e50b104c str r1, [fp, #-76] ; 0xffffffb4
> 
> > f30: e5932004 ldr r2, [r3, #4]
> 
> > f34: e2822001 add r2, r2, #1
> 
> > f38: e5832004 str r2, [r3, #4]
> 
> > f3c: ebfffffe bl 0 <debug_smp_processor_id>
> 
> > f40: e59f2e44 ldr r2, [pc, #3652] ; 1d8c <lttng_event_reserve+0xe90>
> 
> > f44: e59f3e44 ldr r3, [pc, #3652] ; 1d90 <lttng_event_reserve+0xe94>
> 
> > f48: e7921100 ldr r1, [r2, r0, lsl #2]
> 
> > f4c: e1a05000 mov r5, r0
> 
> > f50: e7932001 ldr r2, [r3, r1]
> 

> > My rusty ARM assembler knowledge analyzes this like:
> 

> > ip = sp (ip being the scratch register)
> 
> > push 11 registers * 4 bytes = 44 bytes onto the stack
> 
> > fp = ip - 4
> 
> > sp = sp - 60 (sp = ip - 104)
> 
> > push {lr} bl
> 
> > 0 <__gnu_mcount_nc> (dynamically patched to a pop {lr})
> 
> > [...]
> 
> > store r1 into mem location fp - 76
> 

> > So yes, it does look like the -76 from fp is within the stack.
> 

> > > In GCC bug 58854 it was pretty clear that the restore of the sp
> 
> > > register in the epilogue is moved to somewhere close to the prologue
> 
> > > of the routine.
> 
> > > Are we missing some diffs from the assembly comparison?
> 

> > My next step is to setup my own 4.8.2 ARM cross-compiler. I've tried this
> > morning,
> 
> > did not manage to get one working even after following 2 howtos, trying
> > with
> > Debian
> 
> > packages, etc. Nathan told me this diff was the full comparison between the
> > two
> 
> > functions, but you'll understand that at this point I want to reproduce
> 
> > everything myself, because this is a _weird_ issue.
> 

> > But after a long day of debugging, it's time for some sleep. I will get
> > back
> > to this
> 
> > tomorrow,
> 

> > Thanks,
> 

> > Mathieu
> 

> > >
> 
> > > Thanks
> 
> > >
> 
> > > Luis
> 
> > >
> 
> > >
> 
> > >
> 
> > >
> 
> > > On Thu, Nov 21, 2013 at 5:57 PM, Mathieu Desnoyers
> 
> > > < mathieu.desnoyers@efficios.com > wrote:
> 
> > > > ----- Original Message -----
> 
> > > >> From: "Jakub Jelinek" < jakub@redhat.com >
> 
> > > >> To: "Luis Lozano" < llozano@google.com >
> 
> > > >> Cc: "Alexander Holler" < holler@ahsoftware.de >, "Linus Torvalds"
> 
> > > >> < torvalds@linux-foundation.org >, "Mathieu Desnoyers"
> 
> > > >> < mathieu.desnoyers@efficios.com >, "Richard Henderson" <
> > > >> rth@twiddle.net >,
> 
> > > >> "Linux Kernel Mailing List"
> 
> > > >> < linux-kernel@vger.kernel.org >, "Will Deacon" < will.deacon@arm.com
> > > >> >,
> 
> > > >> "Catalin Marinas" < catalin.marinas@arm.com >,
> 
> > > >> "Peter Zijlstra" < peterz@infradead.org >, lttng-dev@lists.lttng.org ,
> 
> > > >> "Nathan Lynch" < Nathan_Lynch@mentor.com >, "Paul
> 
> > > >> E. McKenney" < paulmck@linux.vnet.ibm.com >, "Andrew Morton"
> 
> > > >> < akpm@linux-foundation.org >, "Bhaskar Janakiraman"
> 
> > > >> < bjanakiraman@chromium.org >, "Han Shen" < shenhan@chromium.org >
> 
> > > >> Sent: Thursday, November 21, 2013 7:39:04 PM
> 
> > > >> Subject: Re: current_thread_info() not respecting program order with
> > > >> gcc
> 
> > > >> 4.8.x
> 
> > > >>
> 
> > > >> On Thu, Nov 21, 2013 at 03:45:35PM -0800, Luis Lozano wrote:
> 
> > > >> > I think we need a reproducer. Without this we may all be going on
> > > >> > the
> 
> > > >> > wrong path. This whole conversation started on an *assumption* that
> 
> > > >> > some accesses were being reordered.
> 
> > > >> >
> 
> > > >> > evidence of the reorder or reproducer please?
> 
> > > >>
> 
> > > >> Yeah, if a compiler bug is suspected, can anybody please open
> 
> > > >> a bugreport in http://gcc.gnu.org/bugzilla/ with the preprocessed
> > > >> source,
> 
> > > >> compiler version, flags and how it was configured and some hint in
> > > >> which
> 
> > > >> function to look for what exactly? We don't necessarily need a runtime
> 
> > > >> small reproducer, but if it can be shown in the assembly what has been
> 
> > > >> reordered and why you think it shouldn't, with the above mentioned
> > > >> input
> 
> > > >> that ought to be sufficient. Thanks.
> 
> > > >
> 
> > > > OK OK, let me reply on list first so I can share the result of a full
> > > > day
> 
> > > > of bug hunting. We're not there yet, but many options have been
> > > > eliminated.
> 
> > > >
> 
> > > > The issue shows up in stress test, when tracing with lttng-modules
> > > > 2.4-rc1,
> 
> > > > on ARM. It's been reproduced with a Linux kernel 3.12 so far, with
> 
> > > > lttng-modules
> 
> > > > compiled against that kernel.
> 
> > > >
> 
> > > > First, I asked Nathan to compile his kernel with gcc 4.7, and
> > > > lttng-modules
> 
> > > > with gcc 4.8.x (and vice-versa). The problem only appears when
> 
> > > > lttng-modules
> 
> > > > are compiled with gcc 4.8.x. The compiler version used to compile the
> > > > rest
> 
> > > > of the kernel does not matter.
> 
> > > >
> 
> > > > Then I looked at gcc 4.8 changelog for ARM, new feature:
> 
> > > > -fno-sched-pressure
> 
> > > > (sched pressure is there by default). Nathan tried compiling
> > > > lttng-modules
> 
> > > > with
> 
> > > > -fno-sched-pressure. The problem still reproduces.
> 
> > > >
> 
> > > > Knowing that adding barrier() outside of preempt_disable()/enable() was
> 
> > > > fixing the issue, we tried identifying which code location was
> > > > responsible
> 
> > > > for working around the issue. Skipping a long investigation, here is
> > > > the
> 
> > > > executive summary:
> 
> > > >
> 
> > > > http://git.lttng.org/?p=lttng-modules.git;a=blob;f=lttng-ring-buffer-client.h;h=50c47b3bf49f6c2dd24e250cf1a9b97808cd8e27;hb=HEAD
> 
> > > >
> 
> > > > Has the following function. We identified that adding a barrier() as
> > > > shown
> 
> > > > below
> 
> > > > works around the issue:
> 
> > > >
> 
> > > > static
> 
> > > > int lttng_event_reserve(struct lib_ring_buffer_ctx *ctx,
> 
> > > > uint32_t event_id)
> 
> > > > {
> 
> > > > struct lttng_channel *lttng_chan = channel_get_private(ctx->chan);
> 
> > > > int ret, cpu;
> 
> > > >
> 
> > > > cpu = lib_ring_buffer_get_cpu(&client_config);
> 
> > > > if (cpu < 0)
> 
> > > > return -EPERM;
> 
> > > > ctx->cpu = cpu;
> 
> > > >
> 
> > > > switch (lttng_chan->header_type) {
> 
> > > > case 1: /* compact */
> 
> > > > if (event_id > 30)
> 
> > > > ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> 
> > > > break;
> 
> > > > case 2: /* large */
> 
> > > > if (event_id > 65534)
> 
> > > > ctx->rflags |= LTTNG_RFLAG_EXTENDED;
> 
> > > > break;
> 
> > > > default:
> 
> > > > WARN_ON_ONCE(1);
> 
> > > > }
> 
> > > >
> 
> > > > ret = lib_ring_buffer_reserve(&client_config, ctx);
> 
> > > > if (ret)
> 
> > > > goto put;
> 
> > > > lttng_write_event_header(&client_config, ctx, event_id);
> 
> > > > return 0;
> 
> > > > put:
> 
> > > > lib_ring_buffer_put_cpu(&client_config);
> 
> > > > ---------------> barrier() added here;
> 
> > > > <----------------------------
> 
> > > > return ret;
> 
> > > > }
> 
> > > >
> 
> > > > Where barrier() is the usual asm volatile with "memory" clobber,
> > > > nothing
> 
> > > > else.
> 
> > > >
> 
> > > > Nathan gave me the binary diff for the assembly generated for this
> > > > function
> 
> > > > without
> 
> > > > the barrier and with the barrier:
> 
> > > >
> 
> > > > --- /tmp/lttng_event_reserve-4.8.2.dump 2013-11-21 11:14:14.536495079
> > > > -0600
> 
> > > > +++ /tmp/lttng_event_reserve-with-barrier-4.8.2.dump 2013-11-21
> 
> > > > 14:12:52.997355907 -0600
> 
> > > > @@ -7,11 +7,11 @@
> 
> > > > f10: ebfffffe bl 0 <__gnu_mcount_nc>
> 
> > > > f14: e5903000 ldr r3, [r0]
> 
> > > > f18: e1a04000 mov r4, r0
> 
> > > > - f1c: e50b1048 str r1, [fp, #-72] ; 0xffffffb8
> 
> > > > + f1c: e1a0000d mov r0, sp
> 
> > > > f20: e5936030 ldr r6, [r3, #48] ; 0x30
> 
> > > > - f24: e1a0000d mov r0, sp
> 
> > > > - f28: e3c03d7f bic r3, r0, #8128 ; 0x1fc0
> 
> > > > - f2c: e3c3303f bic r3, r3, #63 ; 0x3f
> 
> > > > + f24: e3c03d7f bic r3, r0, #8128 ; 0x1fc0
> 
> > > > + f28: e3c3303f bic r3, r3, #63 ; 0x3f
> 
> > > > + f2c: e50b1048 str r1, [fp, #-72] ; 0xffffffb8
> 
> > > > f30: e5932004 ldr r2, [r3, #4]
> 
> > > > f34: e2822001 add r2, r2, #1
> 
> > > > f38: e5832004 str r2, [r3, #4]
> 
> > > > @@ -53,7 +53,7 @@
> 
> > > > fc8: e3c3303f bic r3, r3, #63 ; 0x3f
> 
> > > > fcc: e5933000 ldr r3, [r3]
> 
> > > > fd0: e3130002 tst r3, #2
> 
> > > > - fd4: 0a000000 beq fdc <lttng_event_reserve+0xe0>
> 
> > > > + fd4: 0a0002be beq 1ad4 <lttng_event_reserve+0xbd8>
> 
> > > > fd8: ebfffffe bl 0 <preempt_schedule>
> 
> > > > fdc: ea0002bc b 1ad4 <lttng_event_reserve+0xbd8>
> 
> > > > fe0: e3500000 cmp r0, #0
> 
> > > >
> 
> > > > We tried disabling the ftrace function tracing to get mcount out of the
> 
> > > > way,
> 
> > > > and the problem still reproduces.
> 
> > > >
> 
> > > > I'm stopping here in terms of details about the disassembly, because I
> 
> > > > need to double check with Nathan that I get the right disassembly for
> > > > the
> 
> > > > right
> 
> > > > cases. I also terribly need to setup a 4.8.2 ARM cross-compiler on my
> 
> > > > machine.
> 
> > > >
> 
> > > > I'm attaching Nathan's ARM configuration.
> 
> > > >
> 
> > > > It does look behave a bit like this bug pointed out by Luis:
> 
> > > >
> 
> > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58854
> 
> > > >
> 
> > > > AFAIU (please correct me if I am wrong), ARM's interrupt handler run
> 
> > > > on top of the thread stack (?). If it's the case, then anything stored
> 
> > > > on the stack below "sp" could be overwritten by an interrupt handler.
> 
> > > > This would fit well the reproduction scenario for this bug: Nathan runs
> 
> > > > LTTng tracing of kmem_cache_free tracepoint with hackbench running.
> 
> > > > A race between a short window of stack use below sp and interrupt
> > > > handlers
> 
> > > > would trigger with this kind of stress-test.
> 
> > > >
> 
> > > > Thoughts ?
> 
> > > >
> 
> > > > Thanks,
> 
> > > >
> 
> > > > Mathieu
> 
> > > >
> 
> > > >
> 
> > > > --
> 
> > > > Mathieu Desnoyers
> 
> > > > EfficiOS Inc.
> 
> > > > http://www.efficios.com
> 
> > >
> 
> > >
> 
> > >
> 
> > > --
> 
> > >
> 
> > > Luis A. Lozano | Software Engineer | llozano@google.com | +1
> > > (408)431-5164
> 
> > >
> 

> > --
> 
> > Mathieu Desnoyers
> 
> > EfficiOS Inc.
> 
> > http://www.efficios.com
> 

-- 
Mathieu Desnoyers 
EfficiOS Inc. 
http://www.efficios.com 

[-- Attachment #1.2: Type: text/html, Size: 24335 bytes --]

[-- Attachment #2: Type: text/plain, Size: 155 bytes --]

_______________________________________________
lttng-dev mailing list
lttng-dev@lists.lttng.org
http://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Linus Torvalds]

On Thu, Nov 21, 2013 at 3:18 PM, Alexander Holler <holler@ahsoftware.de> wrote:
>
> Sorry, that I still disagree.

Why? You're wrong.

I mean, anybody who disagrees with me is pretty much wrong just on
pure principles, but I actually mean a deeper kind of wrong than that.
I mean a very objective "you're clearly wrong".

> I try to describe it more clearly why I still think that the problem might
> be because of that const declaration.

.. and then you use a totally bogus example to try to "prove" your point.

The example you use has nothing to do with what the function in case
actually does.

The function we actually talk about RETURNS THE SAME VALUE EVERY TIME
IT IS CALLED, regardless of arguments (which it doesn't happen to
have). Ergo, it is "const".

Your example is pure and utter shit, since you still get confused
about what is actually const and what isn't.

The fact is, "current_thread_info()" returns a constant value (within
that execution context). Always has, always will. It fundamentally HAS
to, since that is - by definition - what that "thread info" is all
about.

The dereference (your "->somewhere_local") happens *outside* that
const function scope. And no, that dereference is not const. But
that's not what we tell gcc, and never has been.

So don't try to confuse things by trying to make
"current_thread_info()" something it isn't.

Basically, your whole argument boils down to "if the function did
something else than what it does, then it wouldn't be const, so we
shouldn't mark it const". But that argument is BULLSHIT, because the
fact is, the function *doesn't* do what you try to claim it does.

               Linus

Re: current_thread_info() not respecting program order with gcc 4.8.x

[Alexander Holler]

Am 22.11.2013 01:17, schrieb Linus Torvalds:
> On Thu, Nov 21, 2013 at 3:18 PM, Alexander Holler <holler@ahsoftware.de> wrote:

> Basically, your whole argument boils down to "if the function did
> something else than what it does, then it wouldn't be const, so we
> shouldn't mark it const". But that argument is BULLSHIT, because the
> fact is, the function *doesn't* do what you try to claim it does.

Maybe gcc just makes the same false conclusion as I did in my description.

I read it as current_thread_info() returns "a pointer to something 
local" instead of returns "a pointer". Might be BULLSHIT but would 
explain the bug which seems to exist.

Alexander Holler