Hi,
i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
[ 48.419401] Unable to handle kernel paging request at virtual address bf076f58
[ 48.426630] pgd = e4e54000
[ 48.429328] [bf076f58] *pgd=24d49811, *pte=249e94df, *ppte=249e965e
[ 48.435603] Internal error: Oops: 80f [#1] SMP ARM
[ 48.440383] Modules linked in: bridge(+) stp llc ipv6
[ 48.445442] CPU: 1 PID: 911 Comm: modprobe Not tainted 3.17.0 #37
[ 48.451525] task: e8da9b00 ti: e4a22000 task.ti: e4a22000
[ 48.456918] PC is at patch_text+0x4/0x10
[ 48.460833] LR is at __jump_label_update+0x64/0x6c
[ 48.465615] pc : [<c0215448>] lr : [<c02b6008>] psr: 80000013
[ 48.465615] sp : e4a23db8 ip : 000141b2 fp : bf07e7dc
[ 48.477079] r10: 00000000 r9 : e4a22030 r8 : 00000000
[ 48.482293] r7 : 00000001 r6 : c0d1c5a8 r5 : bf07e794 r4 : bf07e6f8
[ 48.488809] r3 : bf076f58 r2 : ea000000 r1 : ea000007 r0 : bf076f58
[ 48.495326] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
[ 48.502450] Control: 10c5387d Table: 24e5406a DAC: 00000015
[ 48.508185] Process modprobe (pid: 911, stack limit = 0xe4a22250)
[ 48.514267] Stack: (0xe4a23db8 to 0xe4a24000)
[ 48.518614] 3da0: 00000001 e4d6f740
[ 48.526780] 3dc0: c0d1c5a8 00000001 00000000 c02b605c c0d1c5a8 00000000 e4d3e580 00000007
[ 48.534947] 3de0: bf07e5fc c02b6158 bf07e5fc c07cef04 bf07e61c c07cefdc bf07e8fc c0bfd960
[ 48.543113] 3e00: e4d3e580 bf07e794 bf084000 bf084190 bf07e8fc c07a81e8 00000000 00000000
[ 48.551279] 3e20: c0bfd960 bf084050 c0bfd960 c0208c90 e8dee9c0 e4961f40 e8e93000 c0a3d75c
[ 48.559446] 3e40: c0bfd844 eb7ccf20 00000000 8040003f 80000000 e97e9000 00000001 e4d3ea40
[ 48.567612] 3e60: bf07e7dc c02bf0e4 c0d07448 8040003f bf07e7dc 0000001e 0000001e e4961f40
[ 48.575778] 3e80: f0a6d000 e4a23f58 00000001 bf07e7a0 bf07e794 e4d3ea00 00000001 e4d3ea40
[ 48.583944] 3ea0: bf07e7dc c02a5108 bf07e7a0 00007fff c02a213c c02fafc0 0001d23e 00000000
[ 48.592110] 3ec0: f0a6d000 00000000 bf07e7a0 e4d3ea08 e4a22028 e4a23ef4 e4a22030 000003b8
[ 48.600277] 3ee0: 00181414 00000000 00800002 000081a4 00000001 bf07c024 00000001 bf07c02c
[ 48.608443] 3f00: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
[ 48.616609] 3f20: 00000000 00000000 00000000 00000000 e8dee0c0 00000000 00000000 b6fc2398
[ 48.624776] 3f40: 0000017b c020e624 e4a22000 00000000 b6fd61a8 c02a56c4 f0a6d000 0001d23e
[ 48.632942] 3f60: f0a7df38 f0a7dce5 f0a87280 00011000 00012770 00000000 00000000 00000000
[ 48.641108] 3f80: 00000036 00000037 0000002d 00000000 0000001b 00000000 b6fc3608 b6fc3e18
[ 48.649274] 3fa0: b6fc3990 c020e4a0 b6fc3608 b6fc3e18 00000000 b6fc2398 00000000 b6fc3968
[ 48.657440] 3fc0: b6fc3608 b6fc3e18 b6fc3990 0000017b b6fd6278 00000000 00000000 b6fd61a8
[ 48.665607] 3fe0: bee78a38 bee78a28 b6fb9177 b6f2c2b2 40010030 00000000 2b7de821 2b7dec21
[ 48.673779] [<c0215448>] (patch_text) from [<c02b6008>] (__jump_label_update+0x64/0x6c)
[ 48.681775] [<c02b6008>] (__jump_label_update) from [<c02b605c>] (jump_label_update+0x4c/0x90)
[ 48.690378] [<c02b605c>] (jump_label_update) from [<c02b6158>] (static_key_slow_inc+0xb8/0xe0)
[ 48.698981] [<c02b6158>] (static_key_slow_inc) from [<c07cef04>] (nf_register_hook+0xb4/0xc0)
[ 48.707497] [<c07cef04>] (nf_register_hook) from [<c07cefdc>] (nf_register_hooks+0x34/0x74)
[ 48.715848] [<c07cefdc>] (nf_register_hooks) from [<bf084190>] (br_netfilter_init+0x38/0xea8 [bridge])
[ 48.725160] [<bf084190>] (br_netfilter_init [bridge]) from [<bf084050>] (br_init+0x50/0xbc [bridge])
[ 48.734292] [<bf084050>] (br_init [bridge]) from [<c0208c90>] (do_one_initcall+0x8c/0x1c4)
[ 48.742548] [<c0208c90>] (do_one_initcall) from [<c02a5108>] (load_module+0x1b24/0x1f88)
[ 48.750629] [<c02a5108>] (load_module) from [<c02a56c4>] (SyS_finit_module+0x68/0x78)
[ 48.758451] [<c02a56c4>] (SyS_finit_module) from [<c020e4a0>] (ret_fast_syscall+0x0/0x30)
[ 48.766618] Code: e4831004 e1a01003 ea0025d3 e1a03000 (e4831004)
[ 48.772720] ---[ end trace 5a993d4461f1ebf2 ]---
i found a conversion from April 2014 outlining the same problem, but the situation hasn't changed (the above oops
comes from a 3.17 kernel):
http://comments.gmane.org/gmane.linux.kernel/1675790
shouldn't JUMP_LABEL and DEBUG_SET_MODULE_RONX be mutually exclusive, at least on arm?
or was DEBUG_SET_MODULE_RONX superseded by something more fine grained that i
can use to circumvent this problem?
--
bye,
p.
On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
> Hi,
>
> i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
I think my RO/NX patch series solves this. I sent a pull request, but
I haven't seen any movement on it. :(
-Kees
>
> [ 48.419401] Unable to handle kernel paging request at virtual address bf076f58
> [ 48.426630] pgd = e4e54000
> [ 48.429328] [bf076f58] *pgd=24d49811, *pte=249e94df, *ppte=249e965e
> [ 48.435603] Internal error: Oops: 80f [#1] SMP ARM
> [ 48.440383] Modules linked in: bridge(+) stp llc ipv6
> [ 48.445442] CPU: 1 PID: 911 Comm: modprobe Not tainted 3.17.0 #37
> [ 48.451525] task: e8da9b00 ti: e4a22000 task.ti: e4a22000
> [ 48.456918] PC is at patch_text+0x4/0x10
> [ 48.460833] LR is at __jump_label_update+0x64/0x6c
> [ 48.465615] pc : [<c0215448>] lr : [<c02b6008>] psr: 80000013
> [ 48.465615] sp : e4a23db8 ip : 000141b2 fp : bf07e7dc
> [ 48.477079] r10: 00000000 r9 : e4a22030 r8 : 00000000
> [ 48.482293] r7 : 00000001 r6 : c0d1c5a8 r5 : bf07e794 r4 : bf07e6f8
> [ 48.488809] r3 : bf076f58 r2 : ea000000 r1 : ea000007 r0 : bf076f58
> [ 48.495326] Flags: Nzcv IRQs on FIQs on Mode SVC_32 ISA ARM Segment user
> [ 48.502450] Control: 10c5387d Table: 24e5406a DAC: 00000015
> [ 48.508185] Process modprobe (pid: 911, stack limit = 0xe4a22250)
> [ 48.514267] Stack: (0xe4a23db8 to 0xe4a24000)
> [ 48.518614] 3da0: 00000001 e4d6f740
> [ 48.526780] 3dc0: c0d1c5a8 00000001 00000000 c02b605c c0d1c5a8 00000000 e4d3e580 00000007
> [ 48.534947] 3de0: bf07e5fc c02b6158 bf07e5fc c07cef04 bf07e61c c07cefdc bf07e8fc c0bfd960
> [ 48.543113] 3e00: e4d3e580 bf07e794 bf084000 bf084190 bf07e8fc c07a81e8 00000000 00000000
> [ 48.551279] 3e20: c0bfd960 bf084050 c0bfd960 c0208c90 e8dee9c0 e4961f40 e8e93000 c0a3d75c
> [ 48.559446] 3e40: c0bfd844 eb7ccf20 00000000 8040003f 80000000 e97e9000 00000001 e4d3ea40
> [ 48.567612] 3e60: bf07e7dc c02bf0e4 c0d07448 8040003f bf07e7dc 0000001e 0000001e e4961f40
> [ 48.575778] 3e80: f0a6d000 e4a23f58 00000001 bf07e7a0 bf07e794 e4d3ea00 00000001 e4d3ea40
> [ 48.583944] 3ea0: bf07e7dc c02a5108 bf07e7a0 00007fff c02a213c c02fafc0 0001d23e 00000000
> [ 48.592110] 3ec0: f0a6d000 00000000 bf07e7a0 e4d3ea08 e4a22028 e4a23ef4 e4a22030 000003b8
> [ 48.600277] 3ee0: 00181414 00000000 00800002 000081a4 00000001 bf07c024 00000001 bf07c02c
> [ 48.608443] 3f00: 00000003 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> [ 48.616609] 3f20: 00000000 00000000 00000000 00000000 e8dee0c0 00000000 00000000 b6fc2398
> [ 48.624776] 3f40: 0000017b c020e624 e4a22000 00000000 b6fd61a8 c02a56c4 f0a6d000 0001d23e
> [ 48.632942] 3f60: f0a7df38 f0a7dce5 f0a87280 00011000 00012770 00000000 00000000 00000000
> [ 48.641108] 3f80: 00000036 00000037 0000002d 00000000 0000001b 00000000 b6fc3608 b6fc3e18
> [ 48.649274] 3fa0: b6fc3990 c020e4a0 b6fc3608 b6fc3e18 00000000 b6fc2398 00000000 b6fc3968
> [ 48.657440] 3fc0: b6fc3608 b6fc3e18 b6fc3990 0000017b b6fd6278 00000000 00000000 b6fd61a8
> [ 48.665607] 3fe0: bee78a38 bee78a28 b6fb9177 b6f2c2b2 40010030 00000000 2b7de821 2b7dec21
> [ 48.673779] [<c0215448>] (patch_text) from [<c02b6008>] (__jump_label_update+0x64/0x6c)
> [ 48.681775] [<c02b6008>] (__jump_label_update) from [<c02b605c>] (jump_label_update+0x4c/0x90)
> [ 48.690378] [<c02b605c>] (jump_label_update) from [<c02b6158>] (static_key_slow_inc+0xb8/0xe0)
> [ 48.698981] [<c02b6158>] (static_key_slow_inc) from [<c07cef04>] (nf_register_hook+0xb4/0xc0)
> [ 48.707497] [<c07cef04>] (nf_register_hook) from [<c07cefdc>] (nf_register_hooks+0x34/0x74)
> [ 48.715848] [<c07cefdc>] (nf_register_hooks) from [<bf084190>] (br_netfilter_init+0x38/0xea8 [bridge])
> [ 48.725160] [<bf084190>] (br_netfilter_init [bridge]) from [<bf084050>] (br_init+0x50/0xbc [bridge])
> [ 48.734292] [<bf084050>] (br_init [bridge]) from [<c0208c90>] (do_one_initcall+0x8c/0x1c4)
> [ 48.742548] [<c0208c90>] (do_one_initcall) from [<c02a5108>] (load_module+0x1b24/0x1f88)
> [ 48.750629] [<c02a5108>] (load_module) from [<c02a56c4>] (SyS_finit_module+0x68/0x78)
> [ 48.758451] [<c02a56c4>] (SyS_finit_module) from [<c020e4a0>] (ret_fast_syscall+0x0/0x30)
> [ 48.766618] Code: e4831004 e1a01003 ea0025d3 e1a03000 (e4831004)
> [ 48.772720] ---[ end trace 5a993d4461f1ebf2 ]---
>
> i found a conversion from April 2014 outlining the same problem, but the situation hasn't changed (the above oops
> comes from a 3.17 kernel):
>
> http://comments.gmane.org/gmane.linux.kernel/1675790
>
> shouldn't JUMP_LABEL and DEBUG_SET_MODULE_RONX be mutually exclusive, at least on arm?
> or was DEBUG_SET_MODULE_RONX superseded by something more fine grained that i
> can use to circumvent this problem?
> --
> bye,
> p.
--
Kees Cook
Chrome OS Security
On 10/15/2014 11:34 AM, Kees Cook wrote:
> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
>> Hi,
>>
>> i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
> I think my RO/NX patch series solves this. I sent a pull request, but
> I haven't seen any movement on it. :(
>
Please let me know if this doesn't fix it, I don't want to see JUMP_LABEL
disabled b/c DEBUG_SET_MODULE_RONX is set.
Thanks,
-Jason
On Wed, Oct 15, 2014 at 08:34:17AM -0700, Kees Cook wrote:
> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
> > Hi,
> >
> > i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
>
> I think my RO/NX patch series solves this. I sent a pull request, but
> I haven't seen any movement on it. :(
Sorry Kees.
However, even if I had looked at it, I would /not/ have been able to
pull it. It does the absolutely fatal thing for any pull request:
The following changes since commit cc31d8f887953e9824c4d9333b15c335ee7d1b65:
Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next (2014-09-2+6 14:40:19 +0100)
That commit is on my "for-next" branch. The clue is in the name. :)
Just like trying to base commits onto the linux-next tree, trying to
base commits on an aggregate branch intended for linux-next usage
doesn't work for all the same reasons.
The commit which ultimately ended up being merged was:
commit d5d16892243e7755da706d03b34da85ea6a74117
Merge: 3467e765a592 ad684dce87fa f3354ab67476 421520ba9829
Author: Russell King <[email protected]>
Date: Thu Oct 2 21:47:02 2014 +0100
Merge branches 'fiq' (early part), 'fixes', 'l2c' (early part) and 'misc' into for-next
compared to the one you based on:
commit cc31d8f887953e9824c4d9333b15c335ee7d1b65
Merge: 3467e765a592 5ca918e5e3f9 e16343c47e42
Author: Russell King <[email protected]>
Date: Fri Sep 26 14:40:19 2014 +0100
Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next
So, although "fiq" was the same, "fixes" had additional commits added,
an additional "l2c" branch was added, and two additional commits in "misc".
The reason why I publish a "for-next" branch is exactly so I don't have
to push out lots of individual branches, and then have to tell SFR which
branches he needs to pull on a regular basis. "for-next" is an aggregate
unstable branch solely intended to be pulled into linux-next (and thus
inspected by others.)
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Wed, Oct 15, 2014 at 5:09 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Wed, Oct 15, 2014 at 08:34:17AM -0700, Kees Cook wrote:
>> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
>> > Hi,
>> >
>> > i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
>>
>> I think my RO/NX patch series solves this. I sent a pull request, but
>> I haven't seen any movement on it. :(
>
> Sorry Kees.
>
> However, even if I had looked at it, I would /not/ have been able to
> pull it. It does the absolutely fatal thing for any pull request:
>
> The following changes since commit cc31d8f887953e9824c4d9333b15c335ee7d1b65:
>
> Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next (2014-09-2+6 14:40:19 +0100)
>
> That commit is on my "for-next" branch. The clue is in the name. :)
> Just like trying to base commits onto the linux-next tree, trying to
> base commits on an aggregate branch intended for linux-next usage
> doesn't work for all the same reasons.
Ah! My mistake; I was trying to figure out which branch would be best
for you to pull from. What do you prefer I use as the base for the
pull request?
Thanks!
-Kees
--
Kees Cook
Chrome OS Security
On Wed, Oct 15, 2014 at 05:21:29PM -0500, Kees Cook wrote:
> On Wed, Oct 15, 2014 at 5:09 PM, Russell King - ARM Linux
> <[email protected]> wrote:
> > On Wed, Oct 15, 2014 at 08:34:17AM -0700, Kees Cook wrote:
> >> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
> >> > Hi,
> >> >
> >> > i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
> >>
> >> I think my RO/NX patch series solves this. I sent a pull request, but
> >> I haven't seen any movement on it. :(
> >
> > Sorry Kees.
> >
> > However, even if I had looked at it, I would /not/ have been able to
> > pull it. It does the absolutely fatal thing for any pull request:
> >
> > The following changes since commit cc31d8f887953e9824c4d9333b15c335ee7d1b65:
> >
> > Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next (2014-09-2+6 14:40:19 +0100)
> >
> > That commit is on my "for-next" branch. The clue is in the name. :)
> > Just like trying to base commits onto the linux-next tree, trying to
> > base commits on an aggregate branch intended for linux-next usage
> > doesn't work for all the same reasons.
>
> Ah! My mistake; I was trying to figure out which branch would be best
> for you to pull from. What do you prefer I use as the base for the
> pull request?
I much prefer branches against one of Linus' release points than some
point in someone elses tree - unless, of course, there are dependencies
that need to be solved (which means there should be something in the
pull request explaining that.)
If it conflicts with something I have in my tree, then that's generally
not a problem unless the conflict is horrid, at which point it can be
discussed.
--
FTTC broadband for 0.8mile line: currently at 9.5Mbps down 400kbps up
according to speedtest.net.
On Wed, Oct 15, 2014 at 5:36 PM, Russell King - ARM Linux
<[email protected]> wrote:
> On Wed, Oct 15, 2014 at 05:21:29PM -0500, Kees Cook wrote:
>> On Wed, Oct 15, 2014 at 5:09 PM, Russell King - ARM Linux
>> <[email protected]> wrote:
>> > On Wed, Oct 15, 2014 at 08:34:17AM -0700, Kees Cook wrote:
>> >> On Wed, Oct 15, 2014 at 5:21 AM, Paolo Pisati <[email protected]> wrote:
>> >> > Hi,
>> >> >
>> >> > i keep hitting this with BRIDGE=m, JUMP_LABEL=y and DEBUG_SET_MODULE_RONX=y:
>> >>
>> >> I think my RO/NX patch series solves this. I sent a pull request, but
>> >> I haven't seen any movement on it. :(
>> >
>> > Sorry Kees.
>> >
>> > However, even if I had looked at it, I would /not/ have been able to
>> > pull it. It does the absolutely fatal thing for any pull request:
>> >
>> > The following changes since commit cc31d8f887953e9824c4d9333b15c335ee7d1b65:
>> >
>> > Merge branches 'fiq' (early part), 'fixes' and 'misc' into for-next (2014-09-2+6 14:40:19 +0100)
>> >
>> > That commit is on my "for-next" branch. The clue is in the name. :)
>> > Just like trying to base commits onto the linux-next tree, trying to
>> > base commits on an aggregate branch intended for linux-next usage
>> > doesn't work for all the same reasons.
>>
>> Ah! My mistake; I was trying to figure out which branch would be best
>> for you to pull from. What do you prefer I use as the base for the
>> pull request?
>
> I much prefer branches against one of Linus' release points than some
> point in someone elses tree - unless, of course, there are dependencies
> that need to be solved (which means there should be something in the
> pull request explaining that.)
>
> If it conflicts with something I have in my tree, then that's generally
> not a problem unless the conflict is horrid, at which point it can be
> discussed.
Okay, thanks. I've resent the pull request based off of the v3.17 tag.
Thanks!
-Kees
--
Kees Cook
Chrome OS Security