* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) [not found] <151652931598.757.4527606947579667082.reportbug@massive.lan> @ 2018-03-04 17:41 ` Martin Michlmayr 2018-03-04 18:42 ` Andrew Lunn 2018-03-04 20:41 ` Andrew Lunn 0 siblings, 2 replies; 17+ messages in thread From: Martin Michlmayr @ 2018-03-04 17:41 UTC (permalink / raw) To: linux-arm-kernel A Debian user reported the following issue on QNAP TS-119P II with 4.9.65: * Menno Finlay-Smits <inbox@menno.io> [2018-01-21 23:08]: > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install of > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel > memory overwrite attempt (full error below). > > This happens reliably for any large rsync attempt. I have about 1TB of data to > copy between these 2 HDDs and have not managed to copy more than ~2% of the > total amount. > > ** Kernel log: > > [ 2775.213733] usercopy: kernel memory overwrite attempt detected to c29454e0 (<wrapped address>) (4294802208 bytes) > [ 2775.224095] ------------[ cut here ]------------ > [ 2775.228728] kernel BUG at /build/linux-myVvPm/linux-4.9.65/mm/usercopy.c:75! > [ 2775.235800] Internal error: Oops - BUG: 0 [#1] ARM > [ 2775.240604] Modules linked in: marvell ehci_orion mvmdio mv643xx_eth ehci_hcd of_mdio fixed_phy xhci_pci xhci_hcd marvell_cesa des_generic sg usbcore libphy m25p80 spi_nor orion_wdt usb_common kirkwood_thermal evdev gpio_keys ip_tables x_tables ipv6 autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache sd_mod sata_mv libata scsi_mod > [ 2775.271023] CPU: 0 PID: 601 Comm: rsync Not tainted 4.9.0-5-marvell #1 Debian 4.9.65-3+deb9u2 > [ 2775.279582] Hardware name: Marvell Kirkwood (Flattened Device Tree) > [ 2775.285870] task: c0d496c0 task.stack: d5ffe000 > [ 2775.290418] PC is at __check_object_size+0x120/0x1d8 > [ 2775.295401] LR is at __check_object_size+0x120/0x1d8 > [ 2775.300382] pc : [<c0111908>] lr : [<c0111908>] psr: 60000013 > sp : d5fffdb8 ip : 00000000 fp : d5ffff08 > [ 2775.311908] r10: d5ffe000 r9 : fffd7b20 r8 : c29454e0 > [ 2775.317148] r7 : c291d000 r6 : 00000000 r5 : fffd7b20 r4 : c29454e0 > [ 2775.323697] r3 : c0554fa0 r2 : c055a20c r1 : c055094c r0 : 00000065 > [ 2775.330247] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > [ 2775.337405] Control: 0005397f Table: 14810000 DAC: 00000051 > [ 2775.343168] Process rsync (pid: 601, stack limit = 0xd5ffe190) > [ 2775.349020] Stack: (0xd5fffdb8 to 0xd6000000) > [ 2775.353390] fda0: c04623b8 fffd7b20 > [ 2775.361598] fdc0: 000294e8 fffd7b20 00001000 d5fffec0 c29454e0 c0202360 00000008 008eafe8 > [ 2775.369812] fde0: dfc4a380 c291c000 00000051 69000008 d5fffec0 00008000 00000008 00000008 > [ 2775.378026] fe00: 00001000 00000000 c0c26b40 00001008 c0495cf7 c02fc3d0 c0c26b40 d5fffec0 > [ 2775.386240] fe20: d5fffec0 00000000 00008008 c0c26b40 df782d80 d5fffeb8 00000001 00000000 > [ 2775.394445] fe40: df782b40 c03a21d0 d5fffe64 00000003 de65b2c0 00008000 00000008 00008008 > [ 2775.402651] fe60: 5a644f89 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000000 > [ 2775.410866] fe80: d2bebb80 d5fffeb8 de65b2c0 de65b2c0 df79caa0 008c1b00 d5ffe000 00000000 > [ 2775.419080] fea0: 00512e6c c02ee92c d5ffff10 d5ffff28 de65b2c0 c02ee9cc 00000000 00000000 > [ 2775.427294] fec0: 00000001 00000008 00008000 d5ffff08 00000001 3b9aa9ee 00000000 00000000 > [ 2775.435499] fee0: 00000040 d5ffff28 00000000 00000000 df79caa0 d5ffff88 00008008 c0114048 > [ 2775.443705] ff00: 00008008 00000000 008c1b00 00008008 00000001 00000000 00008008 d5ffff08 > [ 2775.451909] ff20: 00000001 3b9aa9ee df79caa0 00000000 00000000 00000000 00000000 00000000 > [ 2775.460116] ff40: 00000000 00000000 00000000 df79caa0 00008008 00000000 d5ffff88 c0114cb4 > [ 2775.468321] ff60: df79caa0 008c1b00 00008008 df79caa0 df79caa0 008c1b00 00008008 c000f704 > [ 2775.476527] ff80: d5ffe000 c0115b68 00000000 00000000 00008008 00512e6c bedfb878 bedfb7f8 > [ 2775.484733] ffa0: 00000004 c000f560 00512e6c bedfb878 00000004 008c1b00 00008008 008c1b00 > [ 2775.492947] ffc0: 00512e6c bedfb878 bedfb7f8 00000004 00520a80 00512e84 0051095c 00512e6c > [ 2775.501161] ffe0: 00000000 bedfb69c 004c6978 b6ea3d1c 40000010 00000004 0000624f 0000624f > [ 2775.509384] [<c0111908>] (__check_object_size) from [<c0202360>] (copy_page_from_iter+0x2e8/0x3d0) > [ 2775.518388] [<c0202360>] (copy_page_from_iter) from [<c02fc3d0>] (skb_copy_datagram_from_iter+0xfc/0x188) > [ 2775.527997] [<c02fc3d0>] (skb_copy_datagram_from_iter) from [<c03a21d0>] (unix_stream_sendmsg+0x208/0x2f8) > [ 2775.537691] [<c03a21d0>] (unix_stream_sendmsg) from [<c02ee92c>] (sock_sendmsg+0x3c/0x50) > [ 2775.545903] [<c02ee92c>] (sock_sendmsg) from [<c02ee9cc>] (sock_write_iter+0x8c/0xb4) > [ 2775.553771] [<c02ee9cc>] (sock_write_iter) from [<c0114048>] (new_sync_write+0xc0/0xe4) > [ 2775.561810] [<c0114048>] (new_sync_write) from [<c0114cb4>] (vfs_write+0xc0/0x194) > [ 2775.569414] [<c0114cb4>] (vfs_write) from [<c0115b68>] (SyS_write+0x44/0x7c) > [ 2775.576497] [<c0115b68>] (SyS_write) from [<c000f560>] (ret_fast_syscall+0x0/0x38) > [ 2775.584098] Code: e59f10a0 01a01000 e59f009c ebff04bf (e7f001f2) > [ 2775.590218] ---[ end trace 9c6c6370c712b384 ]--- > > ** Network status: > *** IP interfaces and addresses: > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > inet 127.0.0.1/8 scope host lo > valid_lft forever preferred_lft forever > inet6 ::1/128 scope host > valid_lft forever preferred_lft forever > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 > link/ether 00:08:9b:c8:50:26 brd ff:ff:ff:ff:ff:ff > inet 192.168.164.3/24 brd 192.168.164.255 scope global eth0 > valid_lft forever preferred_lft forever > inet6 fe80::208:9bff:fec8:5026/64 scope link > valid_lft forever preferred_lft forever > > *** Device statistics: > Inter-| Receive | Transmit > face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed > lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > eth0: 667374 2622 0 0 0 0 0 0 420218 1869 0 0 0 0 0 0 > -- Martin Michlmayr http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-04 17:41 ` Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) Martin Michlmayr @ 2018-03-04 18:42 ` Andrew Lunn 2018-03-04 20:41 ` Andrew Lunn 1 sibling, 0 replies; 17+ messages in thread From: Andrew Lunn @ 2018-03-04 18:42 UTC (permalink / raw) To: linux-arm-kernel On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > A Debian user reported the following issue on QNAP TS-119P II with > 4.9.65: > > * Menno Finlay-Smits <inbox@menno.io> [2018-01-21 23:08]: > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install of > > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel > > memory overwrite attempt (full error below). > > > > This happens reliably for any large rsync attempt. I have about 1TB of data to > > copy between these 2 HDDs and have not managed to copy more than ~2% of the > > total amount. > > > > ** Kernel log: > > > > [ 2775.213733] usercopy: kernel memory overwrite attempt detected to c29454e0 (<wrapped address>) (4294802208 bytes) Not seen this before. My first thought is that this actually looks like a userspace problem. Userspace is passing 4294802208 bytes to the kernel. But the kernel should of already sanity checked that before trying to copy it into kernel space. This is also a Unix domain socket, which sounds odd for rsync. And this is all generic code, nothing specific to kirkwood. Has there been any similar reports on other targets? Andrew > > [ 2775.224095] ------------[ cut here ]------------ > > [ 2775.228728] kernel BUG at /build/linux-myVvPm/linux-4.9.65/mm/usercopy.c:75! > > [ 2775.235800] Internal error: Oops - BUG: 0 [#1] ARM > > [ 2775.240604] Modules linked in: marvell ehci_orion mvmdio mv643xx_eth ehci_hcd of_mdio fixed_phy xhci_pci xhci_hcd marvell_cesa des_generic sg usbcore libphy m25p80 spi_nor orion_wdt usb_common kirkwood_thermal evdev gpio_keys ip_tables x_tables ipv6 autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache sd_mod sata_mv libata scsi_mod > > [ 2775.271023] CPU: 0 PID: 601 Comm: rsync Not tainted 4.9.0-5-marvell #1 Debian 4.9.65-3+deb9u2 > > [ 2775.279582] Hardware name: Marvell Kirkwood (Flattened Device Tree) > > [ 2775.285870] task: c0d496c0 task.stack: d5ffe000 > > [ 2775.290418] PC is at __check_object_size+0x120/0x1d8 > > [ 2775.295401] LR is at __check_object_size+0x120/0x1d8 > > [ 2775.300382] pc : [<c0111908>] lr : [<c0111908>] psr: 60000013 > > sp : d5fffdb8 ip : 00000000 fp : d5ffff08 > > [ 2775.311908] r10: d5ffe000 r9 : fffd7b20 r8 : c29454e0 > > [ 2775.317148] r7 : c291d000 r6 : 00000000 r5 : fffd7b20 r4 : c29454e0 > > [ 2775.323697] r3 : c0554fa0 r2 : c055a20c r1 : c055094c r0 : 00000065 > > [ 2775.330247] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > [ 2775.337405] Control: 0005397f Table: 14810000 DAC: 00000051 > > [ 2775.343168] Process rsync (pid: 601, stack limit = 0xd5ffe190) > > [ 2775.349020] Stack: (0xd5fffdb8 to 0xd6000000) > > [ 2775.353390] fda0: c04623b8 fffd7b20 > > [ 2775.361598] fdc0: 000294e8 fffd7b20 00001000 d5fffec0 c29454e0 c0202360 00000008 008eafe8 > > [ 2775.369812] fde0: dfc4a380 c291c000 00000051 69000008 d5fffec0 00008000 00000008 00000008 > > [ 2775.378026] fe00: 00001000 00000000 c0c26b40 00001008 c0495cf7 c02fc3d0 c0c26b40 d5fffec0 > > [ 2775.386240] fe20: d5fffec0 00000000 00008008 c0c26b40 df782d80 d5fffeb8 00000001 00000000 > > [ 2775.394445] fe40: df782b40 c03a21d0 d5fffe64 00000003 de65b2c0 00008000 00000008 00008008 > > [ 2775.402651] fe60: 5a644f89 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000000 > > [ 2775.410866] fe80: d2bebb80 d5fffeb8 de65b2c0 de65b2c0 df79caa0 008c1b00 d5ffe000 00000000 > > [ 2775.419080] fea0: 00512e6c c02ee92c d5ffff10 d5ffff28 de65b2c0 c02ee9cc 00000000 00000000 > > [ 2775.427294] fec0: 00000001 00000008 00008000 d5ffff08 00000001 3b9aa9ee 00000000 00000000 > > [ 2775.435499] fee0: 00000040 d5ffff28 00000000 00000000 df79caa0 d5ffff88 00008008 c0114048 > > [ 2775.443705] ff00: 00008008 00000000 008c1b00 00008008 00000001 00000000 00008008 d5ffff08 > > [ 2775.451909] ff20: 00000001 3b9aa9ee df79caa0 00000000 00000000 00000000 00000000 00000000 > > [ 2775.460116] ff40: 00000000 00000000 00000000 df79caa0 00008008 00000000 d5ffff88 c0114cb4 > > [ 2775.468321] ff60: df79caa0 008c1b00 00008008 df79caa0 df79caa0 008c1b00 00008008 c000f704 > > [ 2775.476527] ff80: d5ffe000 c0115b68 00000000 00000000 00008008 00512e6c bedfb878 bedfb7f8 > > [ 2775.484733] ffa0: 00000004 c000f560 00512e6c bedfb878 00000004 008c1b00 00008008 008c1b00 > > [ 2775.492947] ffc0: 00512e6c bedfb878 bedfb7f8 00000004 00520a80 00512e84 0051095c 00512e6c > > [ 2775.501161] ffe0: 00000000 bedfb69c 004c6978 b6ea3d1c 40000010 00000004 0000624f 0000624f > > [ 2775.509384] [<c0111908>] (__check_object_size) from [<c0202360>] (copy_page_from_iter+0x2e8/0x3d0) > > [ 2775.518388] [<c0202360>] (copy_page_from_iter) from [<c02fc3d0>] (skb_copy_datagram_from_iter+0xfc/0x188) > > [ 2775.527997] [<c02fc3d0>] (skb_copy_datagram_from_iter) from [<c03a21d0>] (unix_stream_sendmsg+0x208/0x2f8) > > [ 2775.537691] [<c03a21d0>] (unix_stream_sendmsg) from [<c02ee92c>] (sock_sendmsg+0x3c/0x50) > > [ 2775.545903] [<c02ee92c>] (sock_sendmsg) from [<c02ee9cc>] (sock_write_iter+0x8c/0xb4) > > [ 2775.553771] [<c02ee9cc>] (sock_write_iter) from [<c0114048>] (new_sync_write+0xc0/0xe4) > > [ 2775.561810] [<c0114048>] (new_sync_write) from [<c0114cb4>] (vfs_write+0xc0/0x194) > > [ 2775.569414] [<c0114cb4>] (vfs_write) from [<c0115b68>] (SyS_write+0x44/0x7c) > > [ 2775.576497] [<c0115b68>] (SyS_write) from [<c000f560>] (ret_fast_syscall+0x0/0x38) > > [ 2775.584098] Code: e59f10a0 01a01000 e59f009c ebff04bf (e7f001f2) > > [ 2775.590218] ---[ end trace 9c6c6370c712b384 ]--- > > > > > ** Network status: > > *** IP interfaces and addresses: > > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1 > > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 > > inet 127.0.0.1/8 scope host lo > > valid_lft forever preferred_lft forever > > inet6 ::1/128 scope host > > valid_lft forever preferred_lft forever > > 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000 > > link/ether 00:08:9b:c8:50:26 brd ff:ff:ff:ff:ff:ff > > inet 192.168.164.3/24 brd 192.168.164.255 scope global eth0 > > valid_lft forever preferred_lft forever > > inet6 fe80::208:9bff:fec8:5026/64 scope link > > valid_lft forever preferred_lft forever > > > > *** Device statistics: > > Inter-| Receive | Transmit > > face |bytes packets errs drop fifo frame compressed multicast|bytes packets errs drop fifo colls carrier compressed > > lo: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 > > eth0: 667374 2622 0 0 0 0 0 0 420218 1869 0 0 0 0 0 0 > > > > -- > Martin Michlmayr > http://www.cyrius.com/ ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-04 17:41 ` Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) Martin Michlmayr 2018-03-04 18:42 ` Andrew Lunn @ 2018-03-04 20:41 ` Andrew Lunn 2018-03-05 14:28 ` Andrew Lunn 1 sibling, 1 reply; 17+ messages in thread From: Andrew Lunn @ 2018-03-04 20:41 UTC (permalink / raw) To: linux-arm-kernel On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > A Debian user reported the following issue on QNAP TS-119P II with > 4.9.65: > > * Menno Finlay-Smits <inbox@menno.io> [2018-01-21 23:08]: > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install of > > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel > > memory overwrite attempt (full error below). Please can you give me the exact rsync command being used. Having a unix domain socket seems a bit odd for rsync'ing files on the same machine. Thanks Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-04 20:41 ` Andrew Lunn @ 2018-03-05 14:28 ` Andrew Lunn 2018-03-05 15:57 ` Yves-Alexis Perez 0 siblings, 1 reply; 17+ messages in thread From: Andrew Lunn @ 2018-03-05 14:28 UTC (permalink / raw) To: linux-arm-kernel On Sun, Mar 04, 2018 at 09:41:15PM +0100, Andrew Lunn wrote: > On Sun, Mar 04, 2018 at 06:41:57PM +0100, Martin Michlmayr wrote: > > A Debian user reported the following issue on QNAP TS-119P II with > > 4.9.65: > > > > * Menno Finlay-Smits <inbox@menno.io> [2018-01-21 23:08]: > > > Rsyncing files between 2 HDDs on a QNAP 119p with a fresh, minimal install of > > > stretch NAS (armel) causes the kernel to fail after ~20mins with a kernel > > > memory overwrite attempt (full error below). > > Please can you give me the exact rsync command being used. Having a > unix domain socket seems a bit odd for rsync'ing files on the same > machine. I played with this a bit. When you rsync with both source and target on the same machine, it appears to fork two processes, and connect them together via a unix domain socket. I tried reproducing this with 4.9.86. I used the command rsync -az /home /root/home which copied 12G of data. No problems seen. But this is one disk. I assume the machine giving the problem has one of the disks as USB, since the QNAP TS-119P II is a single bay NAS. So it could be the USB disk is slower than the internal disk, and there is a backlog building up. First a backlog for writing out to the disk, then a backlog forming on the Unix domain socket? So maybe that is why i cannot reproduce it. Or the problem has been fixed between 4.9.65 and 4.9.86. Would it be possible to try to reproduce this problem with 4.9.86 on the hardware reporting the issue? Thanks Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-05 14:28 ` Andrew Lunn @ 2018-03-05 15:57 ` Yves-Alexis Perez 2018-03-06 0:54 ` Menno Finlay-Smits 0 siblings, 1 reply; 17+ messages in thread From: Yves-Alexis Perez @ 2018-03-05 15:57 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2018-03-05 at 15:28 +0100, Andrew Lunn wrote: > Would it be possible to try to reproduce this problem with 4.9.86 on > the hardware reporting the issue? 4.9.82-1+deb9u3 is currently in the archive. Menno, could you give it a shot? Regards, -- Yves-Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180305/7c635e74/attachment.sig> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-05 15:57 ` Yves-Alexis Perez @ 2018-03-06 0:54 ` Menno Finlay-Smits 2018-03-07 3:58 ` Menno Finlay-Smits 0 siblings, 1 reply; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-06 0:54 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Mar 2018, at 04:57, Yves-Alexis Perez wrote: > On Mon, 2018-03-05 at 15:28 +0100, Andrew Lunn wrote: > > Would it be possible to try to reproduce this problem with 4.9.86 on > > the hardware reporting the issue? > > 4.9.82-1+deb9u3 is currently in the archive. Menno, could you give it a shot? Will do. I need to get the NAS back to running Scratch as I went back to Jessie for comparison (similar looking problems there too) but I'll get it done as soon as I can. Also, I can confirm that I was indeed copying from an external USB disk with just "rsync -av <source> <dest>". ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-06 0:54 ` Menno Finlay-Smits @ 2018-03-07 3:58 ` Menno Finlay-Smits 2018-03-07 13:02 ` Andrew Lunn 2018-03-07 13:36 ` Andrew Lunn 0 siblings, 2 replies; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-07 3:58 UTC (permalink / raw) To: linux-arm-kernel On Tue, 6 Mar 2018, at 13:54, Menno Finlay-Smits wrote: > On Tue, 6 Mar 2018, at 04:57, Yves-Alexis Perez wrote: > > On Mon, 2018-03-05 at 15:28 +0100, Andrew Lunn wrote: > > > Would it be possible to try to reproduce this problem with 4.9.86 on > > > the hardware reporting the issue? > > > > 4.9.82-1+deb9u3 is currently in the archive. Menno, could you give it a shot? > > Will do. I need to get the NAS back to running Scratch as I went back to > Jessie for comparison (similar looking problems there too) but I'll get > it done as soon as I can. > > Also, I can confirm that I was indeed copying from an external USB disk > with just "rsync -av <source> <dest>". The problem still happens with 4.9.82-1+deb9u3. Here's the dump: [ 675.800163] usercopy: kernel memory overwrite attempt detected to c08f83a0 (<wrapped address>) (4294933600 bytes) [ 675.810513] ------------[ cut here ]------------ [ 675.815144] kernel BUG at /build/linux-nLLkbA/linux-4.9.82/mm/usercopy.c:75! [ 675.822215] Internal error: Oops - BUG: 0 [#1] ARM [ 675.827020] Modules linked in: ses enclosure scsi_transport_sas uas usb_storage marvell ehci_orion mv643xx_eth mvmdio of_mdio ehci_hcd fixed_phy marvell_cesa libphy des_generic xhci_pci xhci_hcd sg usbcore orion_wdt usb_common m25p80 spi_nor kirkwood_thermal evdev gpio_keys sunrpc ip_tables x_tables ipv6 autofs4 ext4 crc16 jbd2 crc32c_generic fscrypto ecb mbcache sd_mod sata_mv libata scsi_mod [ 675.862376] CPU: 0 PID: 2050 Comm: rsync Not tainted 4.9.0-6-marvell #1 Debian 4.9.82-1+deb9u3 [ 675.871022] Hardware name: Marvell Kirkwood (Flattened Device Tree) [ 675.877310] task: c0af32c0 task.stack: c0a7e000 [ 675.881857] PC is at __check_object_size+0x120/0x1d8 [ 675.886840] LR is at __check_object_size+0x120/0x1d8 [ 675.891821] pc : [<c0111d84>] lr : [<c0111d84>] psr: 60000013 sp : c0a7fdb8 ip : 00000000 fp : c0a7ff08 [ 675.903339] r10: c0a7e000 r9 : ffff7c60 r8 : c08f83a0 [ 675.908579] r7 : c08f0000 r6 : 00000000 r5 : ffff7c60 r4 : c08f83a0 [ 675.915128] r3 : c0555080 r2 : c055a3a4 r1 : c05509f0 r0 : 00000065 [ 675.921677] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 675.928835] Control: 0005397f Table: 00b44000 DAC: 00000051 [ 675.934599] Process rsync (pid: 2050, stack limit = 0xc0a7e190) [ 675.940538] Stack: (0xc0a7fdb8 to 0xc0a80000) [ 675.944908] fda0: c04634c4 ffff7c60 [ 675.953116] fdc0: 000103a8 ffff7c60 00008000 c0a7fec0 c08f83a0 c0202dd0 00000008 00cfbff0 [ 675.961329] fde0: dfc09d00 c08e8000 00000051 00000008 c0a7fec0 00008000 00000008 00000008 [ 675.969535] fe00: 00008000 00000000 dead4e40 00008008 c0496ed1 c02fcf5c dead4e40 c0a7fec0 [ 675.977749] fe20: c0a7fec0 00000000 00008008 dead4e40 c08be920 c0a7feb8 00000001 00000000 [ 675.985964] fe40: c08beb60 c03a2f80 c0a7fe64 00000003 dec8e2e0 00008000 00000008 00008008 [ 675.994178] fe60: 5a9f1704 00000000 00000000 00000000 00000000 ffffffff ffffffff 00000000 [ 676.002392] fe80: c0ace700 c0a7feb8 dec8e2e0 dec8e2e0 c0a892a0 00cebc48 c0a7e000 00000000 [ 676.010607] fea0: 00511e6c c02ef4a8 c0a7ff10 c0a7ff28 dec8e2e0 c02ef548 00000000 00000000 [ 676.018821] fec0: 00000001 00000008 00008000 c0a7ff08 00000001 3b9a9904 00000000 00000000 [ 676.027035] fee0: 00000040 c0a7ff28 00000000 00000000 c0a892a0 c0a7ff88 00008008 c01144c0 [ 676.035249] ff00: 00008008 00000000 00cebc48 00008008 00000001 00000000 00008008 c0a7ff08 [ 676.043454] ff20: 00000001 3b9a9904 c0a892a0 00000000 00000000 00000000 00000000 00000000 [ 676.051660] ff40: 00000000 00000000 00000000 c0a892a0 00008008 00000000 c0a7ff88 c011512c [ 676.059865] ff60: c0a892a0 00cebc48 00008008 c0a892a0 c0a892a0 00cebc48 00008008 c000f724 [ 676.068071] ff80: c0a7e000 c0115fe0 00000000 00000000 00008008 00511e6c bef86848 bef867c8 [ 676.076277] ffa0: 00000004 c000f560 00511e6c bef86848 00000004 00cebc48 00008008 00cebc48 [ 676.084490] ffc0: 00511e6c bef86848 bef867c8 00000004 0051fa80 00511e84 0050f95c 00511e6c [ 676.092696] ffe0: 00000000 bef8666c 004c5978 b6ef7d1c 40000010 00000004 1fffd871 1fffdc71 [ 676.100910] [<c0111d84>] (__check_object_size) from [<c0202dd0>] (copy_page_from_iter+0x2e8/0x3d0) [ 676.109915] [<c0202dd0>] (copy_page_from_iter) from [<c02fcf5c>] (skb_copy_datagram_from_iter+0xfc/0x188) [ 676.119524] [<c02fcf5c>] (skb_copy_datagram_from_iter) from [<c03a2f80>] (unix_stream_sendmsg+0x208/0x2f8) [ 676.129218] [<c03a2f80>] (unix_stream_sendmsg) from [<c02ef4a8>] (sock_sendmsg+0x3c/0x50) [ 676.137430] [<c02ef4a8>] (sock_sendmsg) from [<c02ef548>] (sock_write_iter+0x8c/0xb4) [ 676.145297] [<c02ef548>] (sock_write_iter) from [<c01144c0>] (new_sync_write+0xc0/0xe4) [ 676.153337] [<c01144c0>] (new_sync_write) from [<c011512c>] (vfs_write+0xc0/0x194) [ 676.160941] [<c011512c>] (vfs_write) from [<c0115fe0>] (SyS_write+0x44/0x7c) [ 676.168023] [<c0115fe0>] (SyS_write) from [<c000f560>] (ret_fast_syscall+0x0/0x44) [ 676.175625] Code: e59f10a0 01a01000 e59f009c ebff0495 (e7f001f2) [ 676.181748] ---[ end trace 09357b62c70de3ea ]--- What else can I try? There doesn't appear to be a newer kernel in proposed right now. - Menno ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-07 3:58 ` Menno Finlay-Smits @ 2018-03-07 13:02 ` Andrew Lunn 2018-03-07 13:36 ` Andrew Lunn 1 sibling, 0 replies; 17+ messages in thread From: Andrew Lunn @ 2018-03-07 13:02 UTC (permalink / raw) To: linux-arm-kernel > What else can I try? There doesn't appear to be a newer kernel in > proposed right now. Are you happy to apply patches, build a kernel, and test it? Thanks Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-07 3:58 ` Menno Finlay-Smits 2018-03-07 13:02 ` Andrew Lunn @ 2018-03-07 13:36 ` Andrew Lunn 2018-03-07 20:49 ` Menno Finlay-Smits 1 sibling, 1 reply; 17+ messages in thread From: Andrew Lunn @ 2018-03-07 13:36 UTC (permalink / raw) To: linux-arm-kernel > What else can I try? Do you have transparent huge pages enabled? ~$ cat /sys/kernel/mm/transparent_hugepage/enabled [always] madvise never If so, could you disable it with: echo never > /sys/kernel/mm/transparent_hugepage/enabled and run your rsync command. Thanks Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-07 13:36 ` Andrew Lunn @ 2018-03-07 20:49 ` Menno Finlay-Smits 2018-03-07 22:27 ` Andrew Lunn 0 siblings, 1 reply; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-07 20:49 UTC (permalink / raw) To: linux-arm-kernel On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > What else can I try? > > Do you have transparent huge pages enabled? > > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled > [always] madvise never > > If so, could you disable it with: > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > and run your rsync command. I'll check this at the next opportunity. Also, I'm comfortable with patching and compiling kernels if necessary. ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-07 20:49 ` Menno Finlay-Smits @ 2018-03-07 22:27 ` Andrew Lunn 2018-03-09 9:53 ` Menno Finlay-Smits 0 siblings, 1 reply; 17+ messages in thread From: Andrew Lunn @ 2018-03-07 22:27 UTC (permalink / raw) To: linux-arm-kernel On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote: > On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > > What else can I try? > > > > Do you have transparent huge pages enabled? > > > > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled > > [always] madvise never > > > > If so, could you disable it with: > > > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > > > and run your rsync command. Hi Menno Could you also try linux-image-4.14.0-3-marvell from sid? There does not appear to be a 4.15 yet for marvell. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-07 22:27 ` Andrew Lunn @ 2018-03-09 9:53 ` Menno Finlay-Smits 2018-03-09 9:56 ` Yves-Alexis Perez 2018-03-09 14:27 ` Andrew Lunn 0 siblings, 2 replies; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-09 9:53 UTC (permalink / raw) To: linux-arm-kernel On Thu, 8 Mar 2018, at 11:27, Andrew Lunn wrote: > On Thu, Mar 08, 2018 at 09:49:29AM +1300, Menno Finlay-Smits wrote: > > On Thu, 8 Mar 2018, at 02:36, Andrew Lunn wrote: > > > > What else can I try? > > > > > > Do you have transparent huge pages enabled? > > > > > > ~$ cat /sys/kernel/mm/transparent_hugepage/enabled > > > [always] madvise never > > > > > > If so, could you disable it with: > > > > > > echo never > /sys/kernel/mm/transparent_hugepage/enabled > > > > > > and run your rsync command. > > Hi Menno > > Could you also try linux-image-4.14.0-3-marvell from sid? Can do. Should I just use the kernel packages from sid or update the whole system to sid? ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-09 9:53 ` Menno Finlay-Smits @ 2018-03-09 9:56 ` Yves-Alexis Perez 2018-03-09 14:27 ` Andrew Lunn 1 sibling, 0 replies; 17+ messages in thread From: Yves-Alexis Perez @ 2018-03-09 9:56 UTC (permalink / raw) To: linux-arm-kernel On Fri, Mar 09, 2018 at 10:53:07PM +1300, Menno Finlay-Smits wrote: > Can do. Should I just use the kernel packages from sid or update the whole system to sid? I think you should be able to just pick the kernel from sid. I'm starting to work on updating 4.9 to later kernels but it's not really a priority right now since we'll just have a point release this week-end. Regards, -- Yves-Alexis Perez -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: not available URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180309/850762ec/attachment.sig> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-09 9:53 ` Menno Finlay-Smits 2018-03-09 9:56 ` Yves-Alexis Perez @ 2018-03-09 14:27 ` Andrew Lunn 2018-03-11 11:02 ` Menno Finlay-Smits 1 sibling, 1 reply; 17+ messages in thread From: Andrew Lunn @ 2018-03-09 14:27 UTC (permalink / raw) To: linux-arm-kernel > > Hi Menno > > > > Could you also try linux-image-4.14.0-3-marvell from sid? > > Can do. Should I just use the kernel packages from sid or update the whole system to sid? Hi Menno The kernel packages should be sufficient. Andrew ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-09 14:27 ` Andrew Lunn @ 2018-03-11 11:02 ` Menno Finlay-Smits 2018-03-11 11:06 ` Yves-Alexis Perez 0 siblings, 1 reply; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-11 11:02 UTC (permalink / raw) To: linux-arm-kernel > > > Could you also try linux-image-4.14.0-3-marvell from sid? > > > > Can do. Should I just use the kernel packages from sid or update the whole system to sid? > > Hi Menno > > The kernel packages should be sufficient. Bingo. The problem doesn't seem to happen using linux-image-4.14.0-3-marvell_4.14.17-1 from sid. I've now successfully transferred 1.5TB from an external USB drive onto the internal hard disk. Previously the problem would show up within the first few 100MB of the transfer. Do you want me to help figure out which change to the kernel fixed the problem? - Menno ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-11 11:02 ` Menno Finlay-Smits @ 2018-03-11 11:06 ` Yves-Alexis Perez 2018-03-11 20:59 ` Menno Finlay-Smits 0 siblings, 1 reply; 17+ messages in thread From: Yves-Alexis Perez @ 2018-03-11 11:06 UTC (permalink / raw) To: linux-arm-kernel On Mon, 2018-03-12 at 00:02 +1300, Menno Finlay-Smits wrote: > Bingo. The problem doesn't seem to happen using linux-image-4.14.0-3- > marvell_4.14.17-1 from sid. I've now successfully transferred 1.5TB from an > external USB drive onto the internal hard disk. Previously the problem would > show up within the first few 100MB of the transfer. > > Do you want me to help figure out which change to the kernel fixed the > problem? As far as I can tell and if I'm not mistaken, the fix is already identified and is included in 4.9.86. I've started working on it for Stretch, and at one point it will be uploaded to -proposed-updates for inclusion in the next point release (9.5). When it's done I'll probably ask you to try a test kernel to make sure it's really fixed. Regards, -- Yves-Alexis -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 488 bytes Desc: This is a digitally signed message part URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180311/9575cd85/attachment.sig> ^ permalink raw reply [flat|nested] 17+ messages in thread
* Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) 2018-03-11 11:06 ` Yves-Alexis Perez @ 2018-03-11 20:59 ` Menno Finlay-Smits 0 siblings, 0 replies; 17+ messages in thread From: Menno Finlay-Smits @ 2018-03-11 20:59 UTC (permalink / raw) To: linux-arm-kernel On Mon, 12 Mar 2018, at 00:06, Yves-Alexis Perez wrote: > On Mon, 2018-03-12 at 00:02 +1300, Menno Finlay-Smits wrote: > > Do you want me to help figure out which change to the kernel fixed the > > problem? > > As far as I can tell and if I'm not mistaken, the fix is already identified > and is included in 4.9.86. > > I've started working on it for Stretch, and at one point it will be uploaded > to -proposed-updates for inclusion in the next point release (9.5). When it's > done I'll probably ask you to try a test kernel to make sure it's really > fixed. I'm happy to try it out when it's available. ^ permalink raw reply [flat|nested] 17+ messages in thread
end of thread, other threads:[~2018-03-11 20:59 UTC | newest]
Thread overview: 17+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
[not found] <151652931598.757.4527606947579667082.reportbug@massive.lan>
2018-03-04 17:41 ` Bug#887873: linux-image-4.9.0-5-marvell: frequent "usercopy: kernel memory overwrite attempt detected" on QNAP NAS (ARM) Martin Michlmayr
2018-03-04 18:42 ` Andrew Lunn
2018-03-04 20:41 ` Andrew Lunn
2018-03-05 14:28 ` Andrew Lunn
2018-03-05 15:57 ` Yves-Alexis Perez
2018-03-06 0:54 ` Menno Finlay-Smits
2018-03-07 3:58 ` Menno Finlay-Smits
2018-03-07 13:02 ` Andrew Lunn
2018-03-07 13:36 ` Andrew Lunn
2018-03-07 20:49 ` Menno Finlay-Smits
2018-03-07 22:27 ` Andrew Lunn
2018-03-09 9:53 ` Menno Finlay-Smits
2018-03-09 9:56 ` Yves-Alexis Perez
2018-03-09 14:27 ` Andrew Lunn
2018-03-11 11:02 ` Menno Finlay-Smits
2018-03-11 11:06 ` Yves-Alexis Perez
2018-03-11 20:59 ` Menno Finlay-Smits
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.