Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1406203 > unrolled thread

can't boot with reiserfs on linux-4.6.0+

Started byJeff Chua <jeff.chua.linux@gmail.com>
First post2016-05-24 16:20 +0200
Last post2016-05-25 18:00 +0200
Articles 9 — 3 participants

Back to article view | Back to linux.kernel

Contents

  can't boot with reiserfs on linux-4.6.0+ Jeff Chua <jeff.chua.linux@gmail.com> - 2016-05-24 16:20 +0200
    Re: can't boot with reiserfs on linux-4.6.0+ Al Viro <viro@ZenIV.linux.org.uk> - 2016-05-24 18:00 +0200
      Re: can't boot with reiserfs on linux-4.6.0+ Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-24 18:20 +0200
        Re: can't boot with reiserfs on linux-4.6.0+ Jeff Chua <jeff.chua.linux@gmail.com> - 2016-05-25 10:40 +0200
      Re: can't boot with reiserfs on linux-4.6.0+ Al Viro <viro@ZenIV.linux.org.uk> - 2016-05-24 20:40 +0200
        Re: can't boot with reiserfs on linux-4.6.0+ Jeff Chua <jeff.chua.linux@gmail.com> - 2016-05-25 11:40 +0200
          Re: can't boot with reiserfs on linux-4.6.0+ Al Viro <viro@ZenIV.linux.org.uk> - 2016-05-25 18:00 +0200
            Re: can't boot with reiserfs on linux-4.6.0+ Jeff Chua <jeff.chua.linux@gmail.com> - 2016-05-26 09:30 +0200
          Re: can't boot with reiserfs on linux-4.6.0+ Linus Torvalds <torvalds@linux-foundation.org> - 2016-05-25 18:00 +0200

#1406203 — can't boot with reiserfs on linux-4.6.0+

FromJeff Chua <jeff.chua.linux@gmail.com>
Date2016-05-24 16:20 +0200
Subjectcan't boot with reiserfs on linux-4.6.0+
Message-ID<rCllE-4jI-11@gated-at.bofh.it>
Seems to break after index 348619f..d55dc5a 100644

Boot up with ext4 works, but try anything to access anything on the
reiser partition such as "/mnt/bin/passwd" resulted in the following
...

[   93.380353] BUG: unable to handle kernel NULL pointer dereference
at           (null)
[   93.380924] IP: [<ffffffff81101ad7>] 0xffffffff81101ad7
[   93.381476] PGD 40520a067 PUD 4052f0067 PMD 0
[   93.381974] Oops: 0000 [#6] SMP
[   93.382480] Modules linked in: usbhid
[   93.382972] CPU: 0 PID: 1888 Comm: bash Tainted: G      D         4.6.0 #3
[   93.383468] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   93.383986] task: ffff88040c313200 ti: ffff88040526c000 task.ti:
ffff88040526c000
[   93.384486] RIP: 0010:[<ffffffff81101ad7>]  [<ffffffff81101ad7>]
0xffffffff81101ad7
[   93.384985] RSP: 0018:ffff88040526fdd0  EFLAGS: 00010282
[   93.385475] RAX: 0000000000000000 RBX: ffff880410784b40 RCX: ffff88040526fe0c
[   93.385988] RDX: ffffffff81951fc2 RSI: ffff88040526fde0 RDI: 0000000000000000
[   93.386478] RBP: ffff88041065d538 R08: 0000000000000014 R09: ffffffff81951fc2
[   93.386970] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88040526fe0c
[   93.387475] R13: ffff88040c364540 R14: 0000000000000022 R15: 0000000000000000
[   93.387963] FS:  00007f56f4879700(0000) GS:ffff880421400000(0000)
knlGS:0000000000000000
[   93.388458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   93.388964] CR2: 0000000000000000 CR3: 0000000404c3c000 CR4: 00000000003406f0
[   93.389454] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   93.389937] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   93.390437] Stack:
[   93.390956]  ffffffff81101e5c 0000000000000014 ffffffff81951fc2
ffff88040526fe3c
[   93.391496]  0000000000000000 ffff8800d2441800 ffffffff81298232
ffffffff810c60c4
[   93.391996]  0000000000000000 0000000000000000 ffff8800d254f000
ffffffff81298460
[   93.392528] Call Trace:
[   93.393011]  [<ffffffff81101e5c>] ? 0xffffffff81101e5c
[   93.393495]  [<ffffffff81298232>] ? 0xffffffff81298232
[   93.394006]  [<ffffffff810c60c4>] ? 0xffffffff810c60c4
[   93.394481]  [<ffffffff81298460>] ? 0xffffffff81298460
[   93.394955]  [<ffffffff810eb8fd>] ? 0xffffffff810eb8fd
[   93.395447]  [<ffffffff810ec20f>] ? 0xffffffff810ec20f
[   93.395919]  [<ffffffff810ec40d>] ? 0xffffffff810ec40d
[   93.396422]  [<ffffffff810ec605>] ? 0xffffffff810ec605
[   93.396892]  [<ffffffff81000fe6>] ? 0xffffffff81000fe6
[   93.397361]  [<ffffffff816c04c0>] ? 0xffffffff816c04c0
[   93.397829] Code: 48 c7 c0 a1 ff ff ff c3 48 8b 47 30 48 8b 40 20
48 8b 80 90 00 00 00 48 85 c0 74 02 ff e0 31 c0 c3 4c 8b 0e 31 c0 4d
85 c9 74 6e <48> 8b 07 4c 8d 47 08 48 85 c0 74 36 48 8b 78 08 48 85 ff
48 89
[   93.398970] RIP  [<ffffffff81101ad7>] 0xffffffff81101ad7
[   93.399449]  RSP <ffff88040526fdd0>
[   93.399919] CR2: 0000000000000000
[   93.400419] ---[ end trace 78efe26e2c832ba1 ]---


Thanks,
Jeff

[toc] | [next] | [standalone]

#1406256

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-05-24 18:00 +0200
Message-ID<rCmUp-5cU-13@gated-at.bofh.it>
In reply to#1406203
On Tue, May 24, 2016 at 10:10:18PM +0800, Jeff Chua wrote:
> Seems to break after index 348619f..d55dc5a 100644
>
> Boot up with ext4 works, but try anything to access anything on the
> reiser partition such as "/mnt/bin/passwd" resulted in the following
> ...
> 
> [   93.380353] BUG: unable to handle kernel NULL pointer dereference
> at           (null)
> [   93.380924] IP: [<ffffffff81101ad7>] 0xffffffff81101ad7
> [   93.381476] PGD 40520a067 PUD 4052f0067 PMD 0
> [   93.381974] Oops: 0000 [#6] SMP
> [   93.382480] Modules linked in: usbhid
> [   93.382972] CPU: 0 PID: 1888 Comm: bash Tainted: G      D         4.6.0 #3
> [   93.383468] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
> R02ET44W (1.17 ) 01/25/2016
> [   93.383986] task: ffff88040c313200 ti: ffff88040526c000 task.ti:
> ffff88040526c000
> [   93.384486] RIP: 0010:[<ffffffff81101ad7>]  [<ffffffff81101ad7>]
> 0xffffffff81101ad7
> [   93.384985] RSP: 0018:ffff88040526fdd0  EFLAGS: 00010282
> [   93.385475] RAX: 0000000000000000 RBX: ffff880410784b40 RCX: ffff88040526fe0c
> [   93.385988] RDX: ffffffff81951fc2 RSI: ffff88040526fde0 RDI: 0000000000000000
> [   93.386478] RBP: ffff88041065d538 R08: 0000000000000014 R09: ffffffff81951fc2
> [   93.386970] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88040526fe0c
> [   93.387475] R13: ffff88040c364540 R14: 0000000000000022 R15: 0000000000000000
> [   93.387963] FS:  00007f56f4879700(0000) GS:ffff880421400000(0000)
> knlGS:0000000000000000
> [   93.388458] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [   93.388964] CR2: 0000000000000000 CR3: 0000000404c3c000 CR4: 00000000003406f0
> [   93.389454] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
> [   93.389937] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
> [   93.390437] Stack:
> [   93.390956]  ffffffff81101e5c 0000000000000014 ffffffff81951fc2
> ffff88040526fe3c
> [   93.391496]  0000000000000000 ffff8800d2441800 ffffffff81298232
> ffffffff810c60c4
> [   93.391996]  0000000000000000 0000000000000000 ffff8800d254f000
> ffffffff81298460
> [   93.392528] Call Trace:
> [   93.393011]  [<ffffffff81101e5c>] ? 0xffffffff81101e5c
> [   93.393495]  [<ffffffff81298232>] ? 0xffffffff81298232
> [   93.394006]  [<ffffffff810c60c4>] ? 0xffffffff810c60c4
> [   93.394481]  [<ffffffff81298460>] ? 0xffffffff81298460
> [   93.394955]  [<ffffffff810eb8fd>] ? 0xffffffff810eb8fd
> [   93.395447]  [<ffffffff810ec20f>] ? 0xffffffff810ec20f
> [   93.395919]  [<ffffffff810ec40d>] ? 0xffffffff810ec40d
> [   93.396422]  [<ffffffff810ec605>] ? 0xffffffff810ec605
> [   93.396892]  [<ffffffff81000fe6>] ? 0xffffffff81000fe6
> [   93.397361]  [<ffffffff816c04c0>] ? 0xffffffff816c04c0
> [   93.397829] Code: 48 c7 c0 a1 ff ff ff c3 48 8b 47 30 48 8b 40 20
> 48 8b 80 90 00 00 00 48 85 c0 74 02 ff e0 31 c0 c3 4c 8b 0e 31 c0 4d
> 85 c9 74 6e <48> 8b 07 4c 8d 47 08 48 85 c0 74 36 48 8b 78 08 48 85 ff
> 48 89
> [   93.398970] RIP  [<ffffffff81101ad7>] 0xffffffff81101ad7
> [   93.399449]  RSP <ffff88040526fdd0>
> [   93.399919] CR2: 0000000000000000
> [   93.400419] ---[ end trace 78efe26e2c832ba1 ]---

Umm...  Any chance of getting the function names to go with the addresses?
I'll try to reproduce it here, but the things would be easier with that
information...

[toc] | [prev] | [next] | [standalone]

#1406262

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-05-24 18:20 +0200
Message-ID<rCndL-5Ak-5@gated-at.bofh.it>
In reply to#1406256
On Tue, May 24, 2016 at 8:59 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>
> Umm...  Any chance of getting the function names to go with the addresses?
> I'll try to reproduce it here, but the things would be easier with that
> information...

Yeah, we shouldn't even allow non-KALLSYMS builds. In fact, unless you
pick EXPERT (which you shouldn't, unless you're doing some embedded
development) you can't even disable it.

Jeff, please don't use non-KALLSYMS builds. They are completely undebuggable.

                 Linus

[toc] | [prev] | [next] | [standalone]

#1406743

FromJeff Chua <jeff.chua.linux@gmail.com>
Date2016-05-25 10:40 +0200
Message-ID<rCCwa-7cx-11@gated-at.bofh.it>
In reply to#1406262
On Wed, May 25, 2016 at 12:10 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> On Tue, May 24, 2016 at 8:59 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> Yeah, we shouldn't even allow non-KALLSYMS builds. In fact, unless you
> pick EXPERT (which you shouldn't, unless you're doing some embedded
> development) you can't even disable it.
>
> Jeff, please don't use non-KALLSYMS builds. They are completely undebuggable.
>
>                  Linus

Got it. Will compile with CONFIG_KALLSYMS=y :)

Thanks,
Jeff

[toc] | [prev] | [next] | [standalone]

#1406382

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-05-24 20:40 +0200
Message-ID<rCppf-6R7-5@gated-at.bofh.it>
In reply to#1406256
On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:

> Umm...  Any chance of getting the function names to go with the addresses?
> I'll try to reproduce it here, but the things would be easier with that
> information...

See if this fixes your reproducer.

diff --git a/fs/xattr.c b/fs/xattr.c
index b11945e..49b8eab 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
 {
 	const struct xattr_handler *handler;
 
+	if (!handlers)
+		return NULL;
+
 	if (!*name)
 		return NULL;

[toc] | [prev] | [next] | [standalone]

#1406774

FromJeff Chua <jeff.chua.linux@gmail.com>
Date2016-05-25 11:40 +0200
Message-ID<rCDsd-7KY-17@gated-at.bofh.it>
In reply to#1406382
On Wed, May 25, 2016 at 2:37 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>
>> Umm...  Any chance of getting the function names to go with the addresses?
>> I'll try to reproduce it here, but the things would be easier with that
>> information...
>
> See if this fixes your reproducer.
>
> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..49b8eab 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
>  {
>         const struct xattr_handler *handler;
>
> +       if (!handlers)
> +               return NULL;
> +
>         if (!*name)
>                 return NULL;
>

Tried, but doesn't work.

Here's dmesg with symbols ...


[   35.565534] BUG: unable to handle kernel NULL pointer dereference
at 0000000000000020
[   35.566200] IP: [<ffffffff811033a1>] generic_getxattr+0x4f/0x5d
[   35.566828] PGD 409992067 PUD 409993067 PMD 0
[   35.567469] Oops: 0000 [#1] SMP
[   35.568082] Modules linked in: usbhid
[   35.568731] CPU: 1 PID: 1873 Comm: bash Not tainted 4.6.0 #5
[   35.569339] Hardware name: LENOVO 20F5000RSG/20F5000RSG, BIOS
R02ET44W (1.17 ) 01/25/2016
[   35.569981] task: ffff88040c3f2580 ti: ffff88040990c000 task.ti:
ffff88040990c000
[   35.570603] RIP: 0010:[<ffffffff811033a1>]  [<ffffffff811033a1>]
generic_getxattr+0x4f/0x5d
[   35.571246] RSP: 0018:ffff88040990fdd8  EFLAGS: 00010207
[   35.571843] RAX: 0000000000000000 RBX: ffff88041043d6c0 RCX: ffffffff819e2917
[   35.572436] RDX: ffff8804104b4310 RSI: ffff88041043d6c0 RDI: 0000000000000000
[   35.573085] RBP: ffff8804104b4310 R08: ffff88040990fe0c R09: 0000000000000014
[   35.573673] R10: 0000000000000000 R11: 0000000000000000 R12: ffff88040990fe0c
[   35.574257] R13: ffff88040e60a6c0 R14: 0000000000000022 R15: 0000000000000000
[   35.574868] FS:  00007f092f53e700(0000) GS:ffff880421440000(0000)
knlGS:0000000000000000
[   35.575446] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[   35.576013] CR2: 0000000000000020 CR3: 0000000409991000 CR4: 00000000003406e0
[   35.576621] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[   35.577186] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[   35.577748] Stack:
[   35.578342]  0000000000000014 ffffffff819e2917 ffff88040990fe3c
0000000000000000
[   35.578960]  ffff8800d25ce600 ffffffff81299993 ffffffff810c75a2
0000000000000000
[   35.579583]  0000000000000000 ffff88040e607000 ffffffff81299bc1
0000000000000000
[   35.580172] Call Trace:
[   35.580749]  [<ffffffff81299993>] ? get_vfs_caps_from_disk+0x51/0xcf
[   35.581365]  [<ffffffff810c75a2>] ? __vma_link_rb+0x58/0x73
[   35.581933]  [<ffffffff81299bc1>] ? cap_bprm_set_creds+0x1b0/0x420
[   35.582504]  [<ffffffff810ecddb>] ? prepare_binprm+0xce/0x107
[   35.583095]  [<ffffffff810ed6ed>] ? do_execveat_common.isra.49+0x3d0/0x5b4
[   35.583657]  [<ffffffff810ed8eb>] ? do_execve+0x1a/0x1c
[   35.584248]  [<ffffffff810edae3>] ? SyS_execve+0x23/0x2a
[   35.584801]  [<ffffffff81001066>] ? do_syscall_64+0x51/0x89
[   35.585345]  [<ffffffff816c1c80>] ? entry_SYSCALL64_slow_path+0x25/0x25
[   35.585882] Code: 8b b8 a0 00 00 00 e8 6c fc ff ff 4c 8b 04 24 48
3d 00 f0 ff ff 77 19 4d 89 c1 48 8b 4c 24 08 4d 89 e0 48 89 ea 48 89
de 48 89 c7 <ff> 50 20 48 98 48 83 c4 10 5b 5d 41 5c c3 41 54 48 c7 c0
18 4e
[   35.587155] RIP  [<ffffffff811033a1>] generic_getxattr+0x4f/0x5d
[   35.587776]  RSP <ffff88040990fdd8>
[   35.588351] CR2: 0000000000000020
[   35.588974] ---[ end trace 1ac6eb2a9a9b2964 ]---

Thanks,
Jeff

[toc] | [prev] | [next] | [standalone]

#1407018

FromAl Viro <viro@ZenIV.linux.org.uk>
Date2016-05-25 18:00 +0200
Message-ID<rCJnY-2Kq-19@gated-at.bofh.it>
In reply to#1406774
On Wed, May 25, 2016 at 05:30:22PM +0800, Jeff Chua wrote:
> On Wed, May 25, 2016 at 2:37 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> > On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
> >
> >> Umm...  Any chance of getting the function names to go with the addresses?
> >> I'll try to reproduce it here, but the things would be easier with that
> >> information...
> >
> > See if this fixes your reproducer.
> >
> > diff --git a/fs/xattr.c b/fs/xattr.c
> > index b11945e..49b8eab 100644
> > --- a/fs/xattr.c
> > +++ b/fs/xattr.c
> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
> >  {
> >         const struct xattr_handler *handler;
> >
> > +       if (!handlers)
> > +               return NULL;
> > +
> >         if (!*name)
> >                 return NULL;
> >
> 
> Tried, but doesn't work.

D'oh...  Since "vfs: Distinguish between full xattr names and proper prefixes"
we really need to return ERR_PTR() there (and I even have a patch from Andreas
fixing that if (!*name) return NULL; in my queue).  Combined delta to test
(that'll go as two commits, one mine, one his):

diff --git a/fs/xattr.c b/fs/xattr.c
index b11945e..fc81e77 100644
--- a/fs/xattr.c
+++ b/fs/xattr.c
@@ -655,6 +655,7 @@ strcmp_prefix(const char *a, const char *a_prefix)
  * operations to the correct xattr_handler.
  */
 #define for_each_xattr_handler(handlers, handler)		\
+	if (handlers)						\
 		for ((handler) = *(handlers)++;			\
 			(handler) != NULL;			\
 			(handler) = *(handlers)++)
@@ -668,7 +669,7 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
 	const struct xattr_handler *handler;
 
 	if (!*name)
-		return NULL;
+		return ERR_PTR(-EINVAL);
 
 	for_each_xattr_handler(handlers, handler) {
 		const char *n;

[toc] | [prev] | [next] | [standalone]

#1407420

FromJeff Chua <jeff.chua.linux@gmail.com>
Date2016-05-26 09:30 +0200
Message-ID<rCXTY-3sg-17@gated-at.bofh.it>
In reply to#1407018
On Wed, May 25, 2016 at 11:51 PM, Al Viro <viro@zeniv.linux.org.uk> wrote:
> On Wed, May 25, 2016 at 05:30:22PM +0800, Jeff Chua wrote:
>> On Wed, May 25, 2016 at 2:37 AM, Al Viro <viro@zeniv.linux.org.uk> wrote:
>> > On Tue, May 24, 2016 at 04:59:02PM +0100, Al Viro wrote:
>> >
>> >> Umm...  Any chance of getting the function names to go with the addresses?
>> >> I'll try to reproduce it here, but the things would be easier with that
>> >> information...
>> >
>> > See if this fixes your reproducer.
>> >
>> > diff --git a/fs/xattr.c b/fs/xattr.c
>> > index b11945e..49b8eab 100644
>> > --- a/fs/xattr.c
>> > +++ b/fs/xattr.c
>> > @@ -667,6 +667,9 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
>> >  {
>> >         const struct xattr_handler *handler;
>> >
>> > +       if (!handlers)
>> > +               return NULL;
>> > +
>> >         if (!*name)
>> >                 return NULL;
>> >
>>
>> Tried, but doesn't work.
>
> D'oh...  Since "vfs: Distinguish between full xattr names and proper prefixes"
> we really need to return ERR_PTR() there (and I even have a patch from Andreas
> fixing that if (!*name) return NULL; in my queue).  Combined delta to test
> (that'll go as two commits, one mine, one his):
>

Al, Linus,

Great that worked! And I see the patch is already in Linus's tree.

Thanks for the quick response and fixes.

Jeff.


> diff --git a/fs/xattr.c b/fs/xattr.c
> index b11945e..fc81e77 100644
> --- a/fs/xattr.c
> +++ b/fs/xattr.c
> @@ -655,6 +655,7 @@ strcmp_prefix(const char *a, const char *a_prefix)
>   * operations to the correct xattr_handler.
>   */
>  #define for_each_xattr_handler(handlers, handler)              \
> +       if (handlers)                                           \
>                 for ((handler) = *(handlers)++;                 \
>                         (handler) != NULL;                      \
>                         (handler) = *(handlers)++)
> @@ -668,7 +669,7 @@ xattr_resolve_name(const struct xattr_handler **handlers, const char **name)
>         const struct xattr_handler *handler;
>
>         if (!*name)
> -               return NULL;
> +               return ERR_PTR(-EINVAL);
>
>         for_each_xattr_handler(handlers, handler) {
>                 const char *n;

[toc] | [prev] | [next] | [standalone]

#1407020

FromLinus Torvalds <torvalds@linux-foundation.org>
Date2016-05-25 18:00 +0200
Message-ID<rCJnY-2Kq-21@gated-at.bofh.it>
In reply to#1406774
On Wed, May 25, 2016 at 2:30 AM, Jeff Chua <jeff.chua.linux@gmail.com> wrote:
>
> Here's dmesg with symbols ...

Ok, so "handler" in generic_getxattr() is NULL, the code decodes to

   0: 4d 89 c1             mov    %r8,%r9
   3: 48 8b 4c 24 08       mov    0x8(%rsp),%rcx
   8: 4d 89 e0             mov    %r12,%r8
   b: 48 89 ea             mov    %rbp,%rdx
   e: 48 89 de             mov    %rbx,%rsi
  11: 48 89 c7             mov    %rax,%rdi
  14:* ff 50 20             callq  *0x20(%rax) <-- trapping instruction
  17: 48 98                 cltq

which is

        return handler->get(handler, dentry, inode,
                            name, buffer, size);

so it's that "handler->get" access that fails ("handler" is in %rax
and %rdi, and the register state agrees).

I'm not seeing what changed for btrfs here - we had a calling
convention change, but nothing that should make handler be NULL.

I see nothing particularly odd in the call trace either:

> Call Trace:
>   get_vfs_caps_from_disk+0x51/0xcf
>   __vma_link_rb+0x58/0x73
>   cap_bprm_set_creds+0x1b0/0x420
>   prepare_binprm+0xce/0x107
>   do_execveat_common.isra.49+0x3d0/0x5b4
>   do_execve+0x1a/0x1c
>   SyS_execve+0x23/0x2a

that's the normal ->getxattr() call in security/commoncap.c, and I
don't see any changes there either apart from the calling convention.

Al, you'll probably go "Duh, I changed xyz" that I'm just missing.

               Linus

[toc] | [prev] | [standalone]

Back to top | Article view | linux.kernel

csiph-web