Bug 190071 - The patch "reiserfs: switch to generic_{get,set,remove}xattr()" introduced with 4.4.27 causes kernel panic on root mount
Summary: The patch "reiserfs: switch to generic_{get,set,remove}xattr()" introduced wi...
Status: NEW
Alias: None
Product: File System
Classification: Unclassified
Component: ReiserFS (show other bugs)
Hardware: i386 Linux
: P1 blocking
Assignee: ReiseFS developers team
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2016-12-11 17:21 UTC by Huemi
Modified: 2017-01-06 19:01 UTC (History)
1 user (show)

See Also:
Kernel Version: 4.4.37
Subsystem:
Regression: No
Bisected commit-id:

Attachments
Add an attachment (proposed patch, testcase, etc.)

Description Huemi 2016-12-11 17:21:28 UTC 
The patch "reiserfs: switch to generic_{get,set,remove}xattr()"
commit be90a09bd915e417feae76d9a72c2a37dc5cf1b7 in 4.4.x-series (introduced there with 4.4.27) causes a x86 server (tested there with vanilla kernel 4.4.37) to panic when it tries to mount the reiserfs root device (fsck didn't find any errors and --clean-attributes didn't help either).

Reverting the patch causes the kernel to boot without any errors, but probably there is something wrong with the generic_getxattr or xattr_resolve_name.

According to the commit it is "commit 79a628d14ec7ee9adfdc3ce04343d5ff7ec20c18 upstream".

This is the message from display when the kernel panic happened.


c158b940 f69a6744 f6030a40 f641eb8c f60da558 f683df2c c11775ef 00000000 

Call Trace 

c10cecb5 generic_getxattr+0x1c/0x3f 

c10cec99 ? xattr_resolve_name+0x46/0x46 

c11773ee get_vfs_caps_from_disk + 0x41/0xbd 

c11775ef cap_bprm_set_creds + 0x185/0x4a4 

c10bb593 prepare_binprm+0xbe/0xf1 

c10bb5e3 ? count.constprop.41 + 0x1d/0x6f 

c10bbbff do_execvat_common+0x31b/0x4f0 

c10bbde8 do_execve+0x14/0x16 

c100033c run_init_process+0x1c/0x1e 

c100034a try_to_run_init_process+0xc/0x2e 

c13d0984 kernel_init+0x74/0xb0 

c13d47c9 ret_from_kernel_thread + 0x21/0x38 

c13d0910 ? reset_init+0x64/0x64 

Code 

e5 53 8b 58 20 8b 5b 18 8b 5b 4c 85 db 74 04 ff d3 eb 02 31 c0 5b 5d c3 55 89 e5 57 56 53 51 8b 3a 89 55 b0 85 ff 74 23 8d 58 04 <8b> 00 85 c0 74 27 8b 30 89 f9 8a 16 84 d2 74 14 38 11 75 04 41 

EIP: [<c10cec66>] xattr_resolve_name+0x13/0x46 

SS:ESP 0068:f683de90 

CR2: 0000 0000 0000 0000
Comment 1 dflogeras2 2016-12-30 21:25:15 UTC 
I think I am seeing the same thing in ARM.  I updated from 4.4.26 to 4.4.39 and when I tried to access a partition (rsync) using reiserfs I got the following:


Dec 30 03:10:10 cubie kernel: Unable to handle kernel NULL pointer dereference at virtual address 00000000
Dec 30 03:10:10 cubie kernel: pgd = ea608000
Dec 30 03:10:10 cubie kernel: [00000000] *pgd=6a603831, *pte=00000000, *ppte=00000000
Dec 30 03:10:10 cubie kernel: Internal error: Oops: 17 [#1] SMP ARM
Dec 30 03:10:10 cubie kernel: Modules linked in: ipt_REJECT nf_reject_ipv4 xt_tcpudp iptable_filter ip_tables x_tables reiserfs dm_mod sun4i_codec snd_soc_core snd_pcm_dmaengine snd_pcm dwmac_sunxi stmmac_platform stmmac ptp of_mdio libphy snd_timer snd i2c_mv64xxx soundcore i2c_core sunxi_wdt leds_gpio
Dec 30 03:10:10 cubie kernel: CPU: 0 PID: 5174 Comm: rsync Not tainted 4.4.39-gentoo #1
Dec 30 03:10:10 cubie kernel: Hardware name: Allwinner sun7i (A20) Family
Dec 30 03:10:10 cubie kernel: task: e5977440 ti: e101e000 task.ti: e101e000
Dec 30 03:10:10 cubie kernel: PC is at xattr_resolve_name+0x10/0x98
Dec 30 03:10:10 cubie kernel: LR is at generic_getxattr+0x2c/0x5c
Dec 30 03:10:10 cubie kernel: pc : [<c0108cb8>]    lr : [<c0108d6c>]    psr: a00f0013\x0asp : e101fe00  ip : e101fe1c  fp : 00000006
Dec 30 03:10:10 cubie kernel: r10: d82a847c  r9 : e5aa5cc0  r8 : e101ff1c
Dec 30 03:10:10 cubie kernel: r7 : e101ff1c  r6 : c04b59e8  r5 : 00000000  r4 : d82857f8
Dec 30 03:10:10 cubie kernel: r3 : 00000000  r2 : 00000000  r1 : e101fe1c  r0 : 00000000
Dec 30 03:10:10 cubie kernel: Flags: NzCv  IRQs on  FIQs on  Mode SVC_32  ISA ARM  Segment none
Dec 30 03:10:10 cubie kernel: Control: 10c5387d  Table: 6a60806a  DAC: 00000051
Dec 30 03:10:10 cubie kernel: Process rsync (pid: 5174, stack limit = 0xe101e210)
Dec 30 03:10:10 cubie kernel: Stack: (0xe101fe00 to 0xe1020000)
Dec 30 03:10:10 cubie kernel: fe00: d82857f8 00000000 00000000 c0108d6c ef7c60e8 efa392c0 5209675f c04b59e8
Dec 30 03:10:10 cubie kernel: fe20: d82857f8 00000000 00000000 c01e442c d82a83a8 c00ff910 d82a83a8 d82857f8
Dec 30 03:10:10 cubie kernel: fe40: d82a83a8 c00ff9cc e5b07528 c00cd134 00000049 ea608000 00000055 0000004d
Dec 30 03:10:10 cubie kernel: fe60: ea60ad38 00000134 000b4e4c 00000000 00000001 00000000 00000000 e105b0b0
Dec 30 03:10:10 cubie kernel: fe80: e5977440 e101ff30 e5aa5cc0 c00a87a8 e105b108 00000041 b4e8d000 e101ffb0
Dec 30 03:10:10 cubie kernel: fea0: e5977440 edf93500 e105b108 e101ff30 d82a8418 e5aa5cc0 e101ff1c 00001ae9
Dec 30 03:10:10 cubie kernel: fec0: 000001ff 00000000 00000006 c00a8a78 e105b0c0 00000000 00000800 00000000
Dec 30 03:10:10 cubie kernel: fee0: 00000000 e5aa5cc0 00001ae9 00000000 00000000 e101ff88 e101e000 00000000
Dec 30 03:10:10 cubie kernel: ff00: 00000006 c00e6c28 00001ae9 c000929c 00000000 b4e4c008 00001ae9 00000001
Dec 30 03:10:10 cubie kernel: ff20: 00000000 00001ae9 e101ff14 00000001 e5aa5cc0 00000000 00000000 00000000
Dec 30 03:10:10 cubie kernel: ff40: 00000000 00000000 00000000 00000000 e5aa5cc0 00001ae9 b4e4c008 e101ff88
Dec 30 03:10:10 cubie kernel: ff60: c000f6c4 c00e73b0 b6ef0000 c00bd4e4 e5aa5cc0 e5aa5cc0 00001ae9 b4e4c008
Dec 30 03:10:10 cubie kernel: ff80: c000f6c4 c00e7bd8 00000000 00000000 00040008 00000000 b4e4c008 00091fb0
Dec 30 03:10:10 cubie kernel: ffa0: 00000004 c000f500 00000000 b4e4c008 00000006 b4e4c008 00001ae9 00001ae9
Dec 30 03:10:10 cubie kernel: ffc0: 00000000 b4e4c008 00091fb0 00000004 00001ae9 00000000 00091d78 00000006
Dec 30 03:10:10 cubie kernel: ffe0: 00000000 bec5bb74 000484a4 b6e7f260 600f0010 00000006 00000000 00000000
Dec 30 03:10:10 cubie kernel: [<c0108cb8>] (xattr_resolve_name) from [<c0108d6c>] (generic_getxattr+0x2c/0x5c)
Dec 30 03:10:11 cubie kernel: [<c0108d6c>] (generic_getxattr) from [<c01e442c>] (cap_inode_need_killpriv+0x2c/0x44)
Dec 30 03:10:11 cubie kernel: [<c01e442c>] (cap_inode_need_killpriv) from [<c00ff910>] (dentry_needs_remove_privs.part.6+0x18/0x2c)
Dec 30 03:10:11 cubie kernel: [<c00ff910>] (dentry_needs_remove_privs.part.6) from [<c00ff9cc>] (file_remove_privs+0x8c/0xe8)
Dec 30 03:10:11 cubie kernel: [<c00ff9cc>] (file_remove_privs) from [<c00a87a8>] (__generic_file_write_iter+0x5c/0x1ec)
Dec 30 03:10:11 cubie kernel: [<c00a87a8>] (__generic_file_write_iter) from [<c00a8a78>] (generic_file_write_iter+0x140/0x25c)
Dec 30 03:10:11 cubie kernel: [<c00a8a78>] (generic_file_write_iter) from [<c00e6c28>] (__vfs_write+0xa8/0xd8)
Dec 30 03:10:11 cubie kernel: [<c00e6c28>] (__vfs_write) from [<c00e73b0>] (vfs_write+0x90/0x164)
Dec 30 03:10:11 cubie kernel: [<c00e73b0>] (vfs_write) from [<c00e7bd8>] (SyS_write+0x44/0x9c)
Dec 30 03:10:11 cubie kernel: [<c00e7bd8>] (SyS_write) from [<c000f500>] (ret_fast_syscall+0x0/0x3c)
Dec 30 03:10:11 cubie kernel: Code: e92d4070 e5916000 e3560000 0a00001f (e5904000)
Dec 30 03:10:11 cubie kernel: ---[ end trace 325de232048f8448 ]---
Comment 2 dflogeras2 2017-01-06 19:01:48 UTC 
After reading

https://lkml.org/lkml/2016/5/25/416

I applied the two commits from Linus tree
0040773bff7b585fc948565a0558e5a6a4680e96
aaf431b4f92152d46ab54079692633aa422262b1

and my crash is gone. YMMV.
Note You need to log in before you can comment on or make changes to this bug.