* gpmc-nand broken since v4.12 @ 2017-10-13 11:57 Roger Quadros 2017-10-13 12:50 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Roger Quadros @ 2017-10-13 11:57 UTC (permalink / raw) To: Boris Brezillon Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin Hi Boris, NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 Behaviour follows through in v4.13 and v4.14-rc as well. Do you have any idea about this? == unmounting volume [ 30.128584] Unable to handle kernel NULL pointer dereference at virtual address 00000000 [ 30.137234] pgd = ed3d0000 [ 30.140079] [00000000] *pgd=fd67a835 [ 30.143843] Internal error: Oops: 17 [#1] SMP ARM [ 30.148781] Modules linked in: snd_soc_davinci_mcasp xhci_plat_hcd snd_soc_edma xhci_hcd snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_omap snd_soc_simple_card_utils snd_soc_core usbcoe [ 30.193881] CPU: 1 PID: 2149 Comm: umount Not tainted 4.12.0-00001-g2c09531 #1440 [ 30.201734] Hardware name: Generic DRA74X (Flattened Device Tree) [ 30.208130] task: ec870140 task.stack: ed406000 [ 30.212889] PC is at memcpy+0xe8/0x330 [ 30.216833] LR is at mtd_ooblayout_set_bytes+0x7c/0xa4 [ 30.222231] pc : [<c04abe68>] lr : [<c05d7490>] psr: 60000013 [ 30.222231] sp : ed407b74 ip : 00000002 fp : 00000200 [ 30.234276] r10: ed082800 r9 : 00000000 r8 : ed079010 [ 30.239761] r7 : c05d76d8 r6 : 00000000 r5 : 00000038 r4 : 00000038 [ 30.246614] r3 : 00000038 r2 : 00000034 r1 : 00000000 r0 : ed082802 [ 30.253468] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none [ 30.260957] Control: 10c5387d Table: ad3d006a DAC: 00000051 [ 30.266986] Process umount (pid: 2149, stack limit = 0xed406218) [ 30.273296] Stack: (0xed407b74 to 0xed408000) [ 30.277868] 7b60: ed082802 00000038 c05d7490 [ 30.286458] 7b80: c05d76d8 ed082600 0000ffff 00000000 00000002 00000038 00000004 ed082800 [ 30.295047] 7ba0: ed079010 00000000 00000000 ed082800 ed079010 c05d74fc 00000038 c05d76d8 [ 30.303635] 7bc0: ed0e8f6a c05e8388 00000038 00000000 c0dc60f0 00000001 00000010 0000000e [ 30.312216] 7be0: 00000004 00000001 00000001 00000001 c05f2668 ed079010 00000200 00000200 [ 30.320806] 7c00: 000095c0 00000200 ed082000 ed312200 000095c0 c05e9658 ed082000 00000000 [ 30.329392] 7c20: 000095c0 00000002 00000200 00000000 ed082000 ed407c80 00000000 00000000 [ 30.337975] 7c40: 00000000 00000001 00000040 00000000 00000000 04ae0200 00000000 ed079010 [ 30.346563] 7c60: ed407c80 ed407d30 00000200 ed312200 ed312200 c05e9994 ed407c80 c0191f70 [ 30.355150] 7c80: 00000000 00000200 00000000 00000000 00000000 00000000 ed312200 00000000 [ 30.363738] 7ca0: 00a00000 00000000 00000200 00000000 0f600000 00000000 ed407d30 c05d9fbc [ 30.372328] 7cc0: 00000200 ed407d30 ed312200 00000000 9188fed8 c05d9f7c 00000000 c05d6c7c [ 30.380917] 7ce0: 00000200 ed407d30 ed312200 ed312200 040e0200 00000000 ed628000 00000200 [ 30.389509] 7d00: 00000200 00000207 00000000 c0604cd0 00000200 ed407d30 ed312200 60000013 [ 30.398097] 7d20: 00000200 00000000 ed208040 c019269c 00000000 00000004 ed628dd8 ed312200 [ 30.406676] 7d40: ed628000 00000207 ed312200 00000800 00000207 00000000 ffffffff c060536c [ 30.415267] 7d60: 00000200 c0607fb8 ed18c800 ed628000 ed2a0800 00000008 00000000 c0601178 [ 30.423851] 7d80: ed312200 ed628550 00000000 ed628000 ed312200 ed18c800 ed2a0800 ed628000 [ 30.432437] 7da0: ed312200 00000008 00000004 ed18c800 ed2a0800 00001014 ed208040 c0601cf0 [ 30.441020] 7dc0: 00000000 00000800 00000000 ec870140 00000003 60000013 c1568e2c c060154c [ 30.449605] 7de0: ed18c800 c019269c 00000000 00000002 ed628000 00000800 ed628000 00000000 [ 30.458191] 7e00: 00000008 ed18c800 00000000 00000088 ed18c800 c0600538 00000000 00000800 [ 30.466779] 7e20: ed18c800 ed770000 00000000 00000008 ed770000 c0426a90 00000800 00000000 [ 30.475366] 7e40: 00000088 00000000 00000800 000000a0 ed770000 c0430904 00000800 c08002e8 [ 30.483952] 7e60: 00000000 00000000 000000d8 00000000 00000000 00000000 00000000 00000000 [ 30.492545] 7e80: ed18c800 ed407eb4 00000001 ed770000 00000000 00000288 00000003 ed51b5d4 [ 30.501126] 7ea0: ed406000 00000000 00000000 c0431880 ed77014c 76ecb30e 5c265a59 ec870140 [ 30.509709] 7ec0: 00000003 60000013 c1568e2c c0431f38 00000000 c019269c ed77014c 00000002 [ 30.518301] 7ee0: ed51b5d4 ed77014c ed77014c ed770104 ed51b5d4 ed770000 ed406000 00000000 [ 30.526886] 7f00: ed77014c c08039c8 00000000 00000288 00000003 ed51b5d4 ed770000 c042201c [ 30.535471] 7f20: ed1cb000 00000000 c0dcbbe0 00000534 ec870140 c02e6324 edf88a10 ed1cb000 [ 30.544056] 7f40: c0926528 c02afaf4 c0421714 00000015 c0d823cc c02afc40 ed770000 c0421720 [ 30.552643] 7f60: ed1cb000 c02b0288 ec870140 ed61a600 00000000 c02d0950 ec870634 c0159b34 [ 30.561220] 7f80: ed61a61c 00000000 ed407fb0 c0107ae4 00000034 c0107ae4 00000000 c010b09c [ 30.569803] 7fa0: 00021cb8 0001e320 00021cb8 c0107968 00000000 00000000 00000000 00000000 [ 30.578392] 7fc0: 00021cb8 0001e320 00021cb8 00000034 00021ca8 00000000 00000000 00000000 [ 30.586973] 7fe0: 00021ce8 bec06600 b6e11dbc b6e11ddc 60000010 00021cb8 afffd861 afffdc61 [ 30.595558] [<c04abe68>] (memcpy) from [<c05d7490>] (mtd_ooblayout_set_bytes+0x7c/0xa4) [ 30.603968] [<c05d7490>] (mtd_ooblayout_set_bytes) from [<c05d74fc>] (mtd_ooblayout_set_eccbytes+0x1c/0x28) [ 30.614207] [<c05d74fc>] (mtd_ooblayout_set_eccbytes) from [<c05e8388>] (nand_write_subpage_hwecc+0x1a8/0x1d0) [ 30.624707] [<c05e8388>] (nand_write_subpage_hwecc) from [<c05e9658>] (nand_do_write_ops+0x22c/0x50c) [ 30.634397] [<c05e9658>] (nand_do_write_ops) from [<c05e9994>] (nand_write+0x5c/0x7c) [ 30.642621] [<c05e9994>] (nand_write) from [<c05d9fbc>] (part_write+0x40/0x48) [ 30.650211] [<c05d9fbc>] (part_write) from [<c05d6c7c>] (mtd_write+0x90/0xa8) [ 30.657718] [<c05d6c7c>] (mtd_write) from [<c0604cd0>] (ubi_io_write+0x114/0x6b8) [ 30.665573] [<c0604cd0>] (ubi_io_write) from [<c060536c>] (ubi_io_write_vid_hdr+0xf8/0x148) [ 30.674342] [<c060536c>] (ubi_io_write_vid_hdr) from [<c0601178>] (try_write_vid_and_data+0x54/0x1a4) [ 30.684030] [<c0601178>] (try_write_vid_and_data) from [<c0601cf0>] (ubi_eba_write_leb+0x1f8/0x7bc) [ 30.693525] [<c0601cf0>] (ubi_eba_write_leb) from [<c0600538>] (ubi_leb_write+0xbc/0xdc) [ 30.702021] [<c0600538>] (ubi_leb_write) from [<c0426a90>] (ubifs_leb_write+0x9c/0x11c) [ 30.710426] [<c0426a90>] (ubifs_leb_write) from [<c0430904>] (ubifs_log_start_commit+0x27c/0x444) [ 30.719743] [<c0430904>] (ubifs_log_start_commit) from [<c0431880>] (do_commit+0x1b8/0x7e8) [ 30.728521] [<c0431880>] (do_commit) from [<c042201c>] (ubifs_sync_fs+0x8c/0xa0) [ 30.736292] [<c042201c>] (ubifs_sync_fs) from [<c02e6324>] (sync_filesystem+0x88/0xac) [ 30.744616] [<c02e6324>] (sync_filesystem) from [<c02afaf4>] (generic_shutdown_super+0x24/0xf8) [ 30.753754] [<c02afaf4>] (generic_shutdown_super) from [<c02afc40>] (kill_anon_super+0xc/0x18) [ 30.762807] [<c02afc40>] (kill_anon_super) from [<c0421720>] (kill_ubifs_super+0xc/0x18) [ 30.771308] [<c0421720>] (kill_ubifs_super) from [<c02b0288>] (deactivate_locked_super+0x5c/0x80) [ 30.780627] [<c02b0288>] (deactivate_locked_super) from [<c02d0950>] (cleanup_mnt+0x38/0x78) [ 30.789492] [<c02d0950>] (cleanup_mnt) from [<c0159b34>] (task_work_run+0xc0/0xe8) [ 30.797444] [<c0159b34>] (task_work_run) from [<c010b09c>] (do_work_pending+0xd4/0xd8) [ 30.805759] [<c010b09c>] (do_work_pending) from [<c0107968>] (slow_work_pending+0xc/0x20) [ 30.814345] Code: e8bd8011 e26cc004 e35c0002 c4d13001 (a4d14001) [ 30.820843] ---[ end trace bc240a5a583e6e02 ]--- -- cheers, -roger Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-13 11:57 gpmc-nand broken since v4.12 Roger Quadros @ 2017-10-13 12:50 ` Boris Brezillon 2017-10-13 20:24 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Boris Brezillon @ 2017-10-13 12:50 UTC (permalink / raw) To: Roger Quadros Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin On Fri, 13 Oct 2017 14:57:29 +0300 Roger Quadros <rogerq@ti.com> wrote: > Hi Boris, > > NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > > Behaviour follows through in v4.13 and v4.14-rc as well. > > Do you have any idea about this? Can you try with this patch [1] applied and paste me the values printed just before the crash? [1]http://code.bulix.org/lc8xk0-209746 > > == unmounting volume > [ 30.128584] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > [ 30.137234] pgd = ed3d0000 > [ 30.140079] [00000000] *pgd=fd67a835 > [ 30.143843] Internal error: Oops: 17 [#1] SMP ARM > [ 30.148781] Modules linked in: snd_soc_davinci_mcasp xhci_plat_hcd snd_soc_edma xhci_hcd snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_omap snd_soc_simple_card_utils snd_soc_core usbcoe > [ 30.193881] CPU: 1 PID: 2149 Comm: umount Not tainted 4.12.0-00001-g2c09531 #1440 > [ 30.201734] Hardware name: Generic DRA74X (Flattened Device Tree) > [ 30.208130] task: ec870140 task.stack: ed406000 > [ 30.212889] PC is at memcpy+0xe8/0x330 > [ 30.216833] LR is at mtd_ooblayout_set_bytes+0x7c/0xa4 > [ 30.222231] pc : [<c04abe68>] lr : [<c05d7490>] psr: 60000013 > [ 30.222231] sp : ed407b74 ip : 00000002 fp : 00000200 > [ 30.234276] r10: ed082800 r9 : 00000000 r8 : ed079010 > [ 30.239761] r7 : c05d76d8 r6 : 00000000 r5 : 00000038 r4 : 00000038 > [ 30.246614] r3 : 00000038 r2 : 00000034 r1 : 00000000 r0 : ed082802 > [ 30.253468] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > [ 30.260957] Control: 10c5387d Table: ad3d006a DAC: 00000051 > [ 30.266986] Process umount (pid: 2149, stack limit = 0xed406218) > [ 30.273296] Stack: (0xed407b74 to 0xed408000) > [ 30.277868] 7b60: ed082802 00000038 c05d7490 > [ 30.286458] 7b80: c05d76d8 ed082600 0000ffff 00000000 00000002 00000038 00000004 ed082800 > [ 30.295047] 7ba0: ed079010 00000000 00000000 ed082800 ed079010 c05d74fc 00000038 c05d76d8 > [ 30.303635] 7bc0: ed0e8f6a c05e8388 00000038 00000000 c0dc60f0 00000001 00000010 0000000e > [ 30.312216] 7be0: 00000004 00000001 00000001 00000001 c05f2668 ed079010 00000200 00000200 > [ 30.320806] 7c00: 000095c0 00000200 ed082000 ed312200 000095c0 c05e9658 ed082000 00000000 > [ 30.329392] 7c20: 000095c0 00000002 00000200 00000000 ed082000 ed407c80 00000000 00000000 > [ 30.337975] 7c40: 00000000 00000001 00000040 00000000 00000000 04ae0200 00000000 ed079010 > [ 30.346563] 7c60: ed407c80 ed407d30 00000200 ed312200 ed312200 c05e9994 ed407c80 c0191f70 > [ 30.355150] 7c80: 00000000 00000200 00000000 00000000 00000000 00000000 ed312200 00000000 > [ 30.363738] 7ca0: 00a00000 00000000 00000200 00000000 0f600000 00000000 ed407d30 c05d9fbc > [ 30.372328] 7cc0: 00000200 ed407d30 ed312200 00000000 9188fed8 c05d9f7c 00000000 c05d6c7c > [ 30.380917] 7ce0: 00000200 ed407d30 ed312200 ed312200 040e0200 00000000 ed628000 00000200 > [ 30.389509] 7d00: 00000200 00000207 00000000 c0604cd0 00000200 ed407d30 ed312200 60000013 > [ 30.398097] 7d20: 00000200 00000000 ed208040 c019269c 00000000 00000004 ed628dd8 ed312200 > [ 30.406676] 7d40: ed628000 00000207 ed312200 00000800 00000207 00000000 ffffffff c060536c > [ 30.415267] 7d60: 00000200 c0607fb8 ed18c800 ed628000 ed2a0800 00000008 00000000 c0601178 > [ 30.423851] 7d80: ed312200 ed628550 00000000 ed628000 ed312200 ed18c800 ed2a0800 ed628000 > [ 30.432437] 7da0: ed312200 00000008 00000004 ed18c800 ed2a0800 00001014 ed208040 c0601cf0 > [ 30.441020] 7dc0: 00000000 00000800 00000000 ec870140 00000003 60000013 c1568e2c c060154c > [ 30.449605] 7de0: ed18c800 c019269c 00000000 00000002 ed628000 00000800 ed628000 00000000 > [ 30.458191] 7e00: 00000008 ed18c800 00000000 00000088 ed18c800 c0600538 00000000 00000800 > [ 30.466779] 7e20: ed18c800 ed770000 00000000 00000008 ed770000 c0426a90 00000800 00000000 > [ 30.475366] 7e40: 00000088 00000000 00000800 000000a0 ed770000 c0430904 00000800 c08002e8 > [ 30.483952] 7e60: 00000000 00000000 000000d8 00000000 00000000 00000000 00000000 00000000 > [ 30.492545] 7e80: ed18c800 ed407eb4 00000001 ed770000 00000000 00000288 00000003 ed51b5d4 > [ 30.501126] 7ea0: ed406000 00000000 00000000 c0431880 ed77014c 76ecb30e 5c265a59 ec870140 > [ 30.509709] 7ec0: 00000003 60000013 c1568e2c c0431f38 00000000 c019269c ed77014c 00000002 > [ 30.518301] 7ee0: ed51b5d4 ed77014c ed77014c ed770104 ed51b5d4 ed770000 ed406000 00000000 > [ 30.526886] 7f00: ed77014c c08039c8 00000000 00000288 00000003 ed51b5d4 ed770000 c042201c > [ 30.535471] 7f20: ed1cb000 00000000 c0dcbbe0 00000534 ec870140 c02e6324 edf88a10 ed1cb000 > [ 30.544056] 7f40: c0926528 c02afaf4 c0421714 00000015 c0d823cc c02afc40 ed770000 c0421720 > [ 30.552643] 7f60: ed1cb000 c02b0288 ec870140 ed61a600 00000000 c02d0950 ec870634 c0159b34 > [ 30.561220] 7f80: ed61a61c 00000000 ed407fb0 c0107ae4 00000034 c0107ae4 00000000 c010b09c > [ 30.569803] 7fa0: 00021cb8 0001e320 00021cb8 c0107968 00000000 00000000 00000000 00000000 > [ 30.578392] 7fc0: 00021cb8 0001e320 00021cb8 00000034 00021ca8 00000000 00000000 00000000 > [ 30.586973] 7fe0: 00021ce8 bec06600 b6e11dbc b6e11ddc 60000010 00021cb8 afffd861 afffdc61 > [ 30.595558] [<c04abe68>] (memcpy) from [<c05d7490>] (mtd_ooblayout_set_bytes+0x7c/0xa4) > [ 30.603968] [<c05d7490>] (mtd_ooblayout_set_bytes) from [<c05d74fc>] (mtd_ooblayout_set_eccbytes+0x1c/0x28) > [ 30.614207] [<c05d74fc>] (mtd_ooblayout_set_eccbytes) from [<c05e8388>] (nand_write_subpage_hwecc+0x1a8/0x1d0) > [ 30.624707] [<c05e8388>] (nand_write_subpage_hwecc) from [<c05e9658>] (nand_do_write_ops+0x22c/0x50c) > [ 30.634397] [<c05e9658>] (nand_do_write_ops) from [<c05e9994>] (nand_write+0x5c/0x7c) > [ 30.642621] [<c05e9994>] (nand_write) from [<c05d9fbc>] (part_write+0x40/0x48) > [ 30.650211] [<c05d9fbc>] (part_write) from [<c05d6c7c>] (mtd_write+0x90/0xa8) > [ 30.657718] [<c05d6c7c>] (mtd_write) from [<c0604cd0>] (ubi_io_write+0x114/0x6b8) > [ 30.665573] [<c0604cd0>] (ubi_io_write) from [<c060536c>] (ubi_io_write_vid_hdr+0xf8/0x148) > [ 30.674342] [<c060536c>] (ubi_io_write_vid_hdr) from [<c0601178>] (try_write_vid_and_data+0x54/0x1a4) > [ 30.684030] [<c0601178>] (try_write_vid_and_data) from [<c0601cf0>] (ubi_eba_write_leb+0x1f8/0x7bc) > [ 30.693525] [<c0601cf0>] (ubi_eba_write_leb) from [<c0600538>] (ubi_leb_write+0xbc/0xdc) > [ 30.702021] [<c0600538>] (ubi_leb_write) from [<c0426a90>] (ubifs_leb_write+0x9c/0x11c) > [ 30.710426] [<c0426a90>] (ubifs_leb_write) from [<c0430904>] (ubifs_log_start_commit+0x27c/0x444) > [ 30.719743] [<c0430904>] (ubifs_log_start_commit) from [<c0431880>] (do_commit+0x1b8/0x7e8) > [ 30.728521] [<c0431880>] (do_commit) from [<c042201c>] (ubifs_sync_fs+0x8c/0xa0) > [ 30.736292] [<c042201c>] (ubifs_sync_fs) from [<c02e6324>] (sync_filesystem+0x88/0xac) > [ 30.744616] [<c02e6324>] (sync_filesystem) from [<c02afaf4>] (generic_shutdown_super+0x24/0xf8) > [ 30.753754] [<c02afaf4>] (generic_shutdown_super) from [<c02afc40>] (kill_anon_super+0xc/0x18) > [ 30.762807] [<c02afc40>] (kill_anon_super) from [<c0421720>] (kill_ubifs_super+0xc/0x18) > [ 30.771308] [<c0421720>] (kill_ubifs_super) from [<c02b0288>] (deactivate_locked_super+0x5c/0x80) > [ 30.780627] [<c02b0288>] (deactivate_locked_super) from [<c02d0950>] (cleanup_mnt+0x38/0x78) > [ 30.789492] [<c02d0950>] (cleanup_mnt) from [<c0159b34>] (task_work_run+0xc0/0xe8) > [ 30.797444] [<c0159b34>] (task_work_run) from [<c010b09c>] (do_work_pending+0xd4/0xd8) > [ 30.805759] [<c010b09c>] (do_work_pending) from [<c0107968>] (slow_work_pending+0xc/0x20) > [ 30.814345] Code: e8bd8011 e26cc004 e35c0002 c4d13001 (a4d14001) > [ 30.820843] ---[ end trace bc240a5a583e6e02 ]--- > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-13 12:50 ` Boris Brezillon @ 2017-10-13 20:24 ` Boris Brezillon 2017-10-13 20:29 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Boris Brezillon @ 2017-10-13 20:24 UTC (permalink / raw) To: Roger Quadros Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin On Fri, 13 Oct 2017 14:50:33 +0200 Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > On Fri, 13 Oct 2017 14:57:29 +0300 > Roger Quadros <rogerq@ti.com> wrote: > > > Hi Boris, > > > > NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > > > > Behaviour follows through in v4.13 and v4.14-rc as well. > > > > Do you have any idea about this? More info on what has changed in 4.12: we no longer allocate the nand_buffer struct + its internal buffer using a single big kmalloc call, which means the nand_buffer struct is now likely to be allocated in a small object slab (sizeof(nand_buffers) = 12). If you have a use-after-free bug somewhere in the kernel, it might corrupt the nand_buffers object, which might explain the bug you see here. > > Can you try with this patch [1] applied and paste me the values printed > just before the crash? > > [1]http://code.bulix.org/lc8xk0-209746 > > > > > == unmounting volume > > [ 30.128584] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > [ 30.137234] pgd = ed3d0000 > > [ 30.140079] [00000000] *pgd=fd67a835 > > [ 30.143843] Internal error: Oops: 17 [#1] SMP ARM > > [ 30.148781] Modules linked in: snd_soc_davinci_mcasp xhci_plat_hcd snd_soc_edma xhci_hcd snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_omap snd_soc_simple_card_utils snd_soc_core usbcoe > > [ 30.193881] CPU: 1 PID: 2149 Comm: umount Not tainted 4.12.0-00001-g2c09531 #1440 > > [ 30.201734] Hardware name: Generic DRA74X (Flattened Device Tree) > > [ 30.208130] task: ec870140 task.stack: ed406000 > > [ 30.212889] PC is at memcpy+0xe8/0x330 > > [ 30.216833] LR is at mtd_ooblayout_set_bytes+0x7c/0xa4 > > [ 30.222231] pc : [<c04abe68>] lr : [<c05d7490>] psr: 60000013 > > [ 30.222231] sp : ed407b74 ip : 00000002 fp : 00000200 > > [ 30.234276] r10: ed082800 r9 : 00000000 r8 : ed079010 > > [ 30.239761] r7 : c05d76d8 r6 : 00000000 r5 : 00000038 r4 : 00000038 > > [ 30.246614] r3 : 00000038 r2 : 00000034 r1 : 00000000 r0 : ed082802 > > [ 30.253468] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > [ 30.260957] Control: 10c5387d Table: ad3d006a DAC: 00000051 > > [ 30.266986] Process umount (pid: 2149, stack limit = 0xed406218) > > [ 30.273296] Stack: (0xed407b74 to 0xed408000) > > [ 30.277868] 7b60: ed082802 00000038 c05d7490 > > [ 30.286458] 7b80: c05d76d8 ed082600 0000ffff 00000000 00000002 00000038 00000004 ed082800 > > [ 30.295047] 7ba0: ed079010 00000000 00000000 ed082800 ed079010 c05d74fc 00000038 c05d76d8 > > [ 30.303635] 7bc0: ed0e8f6a c05e8388 00000038 00000000 c0dc60f0 00000001 00000010 0000000e > > [ 30.312216] 7be0: 00000004 00000001 00000001 00000001 c05f2668 ed079010 00000200 00000200 > > [ 30.320806] 7c00: 000095c0 00000200 ed082000 ed312200 000095c0 c05e9658 ed082000 00000000 > > [ 30.329392] 7c20: 000095c0 00000002 00000200 00000000 ed082000 ed407c80 00000000 00000000 > > [ 30.337975] 7c40: 00000000 00000001 00000040 00000000 00000000 04ae0200 00000000 ed079010 > > [ 30.346563] 7c60: ed407c80 ed407d30 00000200 ed312200 ed312200 c05e9994 ed407c80 c0191f70 > > [ 30.355150] 7c80: 00000000 00000200 00000000 00000000 00000000 00000000 ed312200 00000000 > > [ 30.363738] 7ca0: 00a00000 00000000 00000200 00000000 0f600000 00000000 ed407d30 c05d9fbc > > [ 30.372328] 7cc0: 00000200 ed407d30 ed312200 00000000 9188fed8 c05d9f7c 00000000 c05d6c7c > > [ 30.380917] 7ce0: 00000200 ed407d30 ed312200 ed312200 040e0200 00000000 ed628000 00000200 > > [ 30.389509] 7d00: 00000200 00000207 00000000 c0604cd0 00000200 ed407d30 ed312200 60000013 > > [ 30.398097] 7d20: 00000200 00000000 ed208040 c019269c 00000000 00000004 ed628dd8 ed312200 > > [ 30.406676] 7d40: ed628000 00000207 ed312200 00000800 00000207 00000000 ffffffff c060536c > > [ 30.415267] 7d60: 00000200 c0607fb8 ed18c800 ed628000 ed2a0800 00000008 00000000 c0601178 > > [ 30.423851] 7d80: ed312200 ed628550 00000000 ed628000 ed312200 ed18c800 ed2a0800 ed628000 > > [ 30.432437] 7da0: ed312200 00000008 00000004 ed18c800 ed2a0800 00001014 ed208040 c0601cf0 > > [ 30.441020] 7dc0: 00000000 00000800 00000000 ec870140 00000003 60000013 c1568e2c c060154c > > [ 30.449605] 7de0: ed18c800 c019269c 00000000 00000002 ed628000 00000800 ed628000 00000000 > > [ 30.458191] 7e00: 00000008 ed18c800 00000000 00000088 ed18c800 c0600538 00000000 00000800 > > [ 30.466779] 7e20: ed18c800 ed770000 00000000 00000008 ed770000 c0426a90 00000800 00000000 > > [ 30.475366] 7e40: 00000088 00000000 00000800 000000a0 ed770000 c0430904 00000800 c08002e8 > > [ 30.483952] 7e60: 00000000 00000000 000000d8 00000000 00000000 00000000 00000000 00000000 > > [ 30.492545] 7e80: ed18c800 ed407eb4 00000001 ed770000 00000000 00000288 00000003 ed51b5d4 > > [ 30.501126] 7ea0: ed406000 00000000 00000000 c0431880 ed77014c 76ecb30e 5c265a59 ec870140 > > [ 30.509709] 7ec0: 00000003 60000013 c1568e2c c0431f38 00000000 c019269c ed77014c 00000002 > > [ 30.518301] 7ee0: ed51b5d4 ed77014c ed77014c ed770104 ed51b5d4 ed770000 ed406000 00000000 > > [ 30.526886] 7f00: ed77014c c08039c8 00000000 00000288 00000003 ed51b5d4 ed770000 c042201c > > [ 30.535471] 7f20: ed1cb000 00000000 c0dcbbe0 00000534 ec870140 c02e6324 edf88a10 ed1cb000 > > [ 30.544056] 7f40: c0926528 c02afaf4 c0421714 00000015 c0d823cc c02afc40 ed770000 c0421720 > > [ 30.552643] 7f60: ed1cb000 c02b0288 ec870140 ed61a600 00000000 c02d0950 ec870634 c0159b34 > > [ 30.561220] 7f80: ed61a61c 00000000 ed407fb0 c0107ae4 00000034 c0107ae4 00000000 c010b09c > > [ 30.569803] 7fa0: 00021cb8 0001e320 00021cb8 c0107968 00000000 00000000 00000000 00000000 > > [ 30.578392] 7fc0: 00021cb8 0001e320 00021cb8 00000034 00021ca8 00000000 00000000 00000000 > > [ 30.586973] 7fe0: 00021ce8 bec06600 b6e11dbc b6e11ddc 60000010 00021cb8 afffd861 afffdc61 > > [ 30.595558] [<c04abe68>] (memcpy) from [<c05d7490>] (mtd_ooblayout_set_bytes+0x7c/0xa4) > > [ 30.603968] [<c05d7490>] (mtd_ooblayout_set_bytes) from [<c05d74fc>] (mtd_ooblayout_set_eccbytes+0x1c/0x28) > > [ 30.614207] [<c05d74fc>] (mtd_ooblayout_set_eccbytes) from [<c05e8388>] (nand_write_subpage_hwecc+0x1a8/0x1d0) > > [ 30.624707] [<c05e8388>] (nand_write_subpage_hwecc) from [<c05e9658>] (nand_do_write_ops+0x22c/0x50c) > > [ 30.634397] [<c05e9658>] (nand_do_write_ops) from [<c05e9994>] (nand_write+0x5c/0x7c) > > [ 30.642621] [<c05e9994>] (nand_write) from [<c05d9fbc>] (part_write+0x40/0x48) > > [ 30.650211] [<c05d9fbc>] (part_write) from [<c05d6c7c>] (mtd_write+0x90/0xa8) > > [ 30.657718] [<c05d6c7c>] (mtd_write) from [<c0604cd0>] (ubi_io_write+0x114/0x6b8) > > [ 30.665573] [<c0604cd0>] (ubi_io_write) from [<c060536c>] (ubi_io_write_vid_hdr+0xf8/0x148) > > [ 30.674342] [<c060536c>] (ubi_io_write_vid_hdr) from [<c0601178>] (try_write_vid_and_data+0x54/0x1a4) > > [ 30.684030] [<c0601178>] (try_write_vid_and_data) from [<c0601cf0>] (ubi_eba_write_leb+0x1f8/0x7bc) > > [ 30.693525] [<c0601cf0>] (ubi_eba_write_leb) from [<c0600538>] (ubi_leb_write+0xbc/0xdc) > > [ 30.702021] [<c0600538>] (ubi_leb_write) from [<c0426a90>] (ubifs_leb_write+0x9c/0x11c) > > [ 30.710426] [<c0426a90>] (ubifs_leb_write) from [<c0430904>] (ubifs_log_start_commit+0x27c/0x444) > > [ 30.719743] [<c0430904>] (ubifs_log_start_commit) from [<c0431880>] (do_commit+0x1b8/0x7e8) > > [ 30.728521] [<c0431880>] (do_commit) from [<c042201c>] (ubifs_sync_fs+0x8c/0xa0) > > [ 30.736292] [<c042201c>] (ubifs_sync_fs) from [<c02e6324>] (sync_filesystem+0x88/0xac) > > [ 30.744616] [<c02e6324>] (sync_filesystem) from [<c02afaf4>] (generic_shutdown_super+0x24/0xf8) > > [ 30.753754] [<c02afaf4>] (generic_shutdown_super) from [<c02afc40>] (kill_anon_super+0xc/0x18) > > [ 30.762807] [<c02afc40>] (kill_anon_super) from [<c0421720>] (kill_ubifs_super+0xc/0x18) > > [ 30.771308] [<c0421720>] (kill_ubifs_super) from [<c02b0288>] (deactivate_locked_super+0x5c/0x80) > > [ 30.780627] [<c02b0288>] (deactivate_locked_super) from [<c02d0950>] (cleanup_mnt+0x38/0x78) > > [ 30.789492] [<c02d0950>] (cleanup_mnt) from [<c0159b34>] (task_work_run+0xc0/0xe8) > > [ 30.797444] [<c0159b34>] (task_work_run) from [<c010b09c>] (do_work_pending+0xd4/0xd8) > > [ 30.805759] [<c010b09c>] (do_work_pending) from [<c0107968>] (slow_work_pending+0xc/0x20) > > [ 30.814345] Code: e8bd8011 e26cc004 e35c0002 c4d13001 (a4d14001) > > [ 30.820843] ---[ end trace bc240a5a583e6e02 ]--- > > > > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-13 20:24 ` Boris Brezillon @ 2017-10-13 20:29 ` Boris Brezillon 2017-10-16 10:22 ` Roger Quadros 0 siblings, 1 reply; 9+ messages in thread From: Boris Brezillon @ 2017-10-13 20:29 UTC (permalink / raw) To: Roger Quadros Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin On Fri, 13 Oct 2017 22:24:58 +0200 Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > On Fri, 13 Oct 2017 14:50:33 +0200 > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > On Fri, 13 Oct 2017 14:57:29 +0300 > > Roger Quadros <rogerq@ti.com> wrote: > > > > > Hi Boris, > > > > > > NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > > > > > > Behaviour follows through in v4.13 and v4.14-rc as well. > > > > > > Do you have any idea about this? > > More info on what has changed in 4.12: we no longer allocate the > nand_buffer struct + its internal buffer using a single big kmalloc > call, which means the nand_buffer struct is now likely to be allocated > in a small object slab (sizeof(nand_buffers) = 12). If you have a > use-after-free bug somewhere in the kernel, it might corrupt the I meant buffer-overflow, not use-after-free. > nand_buffers object, which might explain the bug you see here. > > > > > Can you try with this patch [1] applied and paste me the values printed > > just before the crash? > > > > [1]http://code.bulix.org/lc8xk0-209746 > > > > > > > > == unmounting volume > > > [ 30.128584] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > > [ 30.137234] pgd = ed3d0000 > > > [ 30.140079] [00000000] *pgd=fd67a835 > > > [ 30.143843] Internal error: Oops: 17 [#1] SMP ARM > > > [ 30.148781] Modules linked in: snd_soc_davinci_mcasp xhci_plat_hcd snd_soc_edma xhci_hcd snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_omap snd_soc_simple_card_utils snd_soc_core usbcoe > > > [ 30.193881] CPU: 1 PID: 2149 Comm: umount Not tainted 4.12.0-00001-g2c09531 #1440 > > > [ 30.201734] Hardware name: Generic DRA74X (Flattened Device Tree) > > > [ 30.208130] task: ec870140 task.stack: ed406000 > > > [ 30.212889] PC is at memcpy+0xe8/0x330 > > > [ 30.216833] LR is at mtd_ooblayout_set_bytes+0x7c/0xa4 > > > [ 30.222231] pc : [<c04abe68>] lr : [<c05d7490>] psr: 60000013 > > > [ 30.222231] sp : ed407b74 ip : 00000002 fp : 00000200 > > > [ 30.234276] r10: ed082800 r9 : 00000000 r8 : ed079010 > > > [ 30.239761] r7 : c05d76d8 r6 : 00000000 r5 : 00000038 r4 : 00000038 > > > [ 30.246614] r3 : 00000038 r2 : 00000034 r1 : 00000000 r0 : ed082802 > > > [ 30.253468] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none > > > [ 30.260957] Control: 10c5387d Table: ad3d006a DAC: 00000051 > > > [ 30.266986] Process umount (pid: 2149, stack limit = 0xed406218) > > > [ 30.273296] Stack: (0xed407b74 to 0xed408000) > > > [ 30.277868] 7b60: ed082802 00000038 c05d7490 > > > [ 30.286458] 7b80: c05d76d8 ed082600 0000ffff 00000000 00000002 00000038 00000004 ed082800 > > > [ 30.295047] 7ba0: ed079010 00000000 00000000 ed082800 ed079010 c05d74fc 00000038 c05d76d8 > > > [ 30.303635] 7bc0: ed0e8f6a c05e8388 00000038 00000000 c0dc60f0 00000001 00000010 0000000e > > > [ 30.312216] 7be0: 00000004 00000001 00000001 00000001 c05f2668 ed079010 00000200 00000200 > > > [ 30.320806] 7c00: 000095c0 00000200 ed082000 ed312200 000095c0 c05e9658 ed082000 00000000 > > > [ 30.329392] 7c20: 000095c0 00000002 00000200 00000000 ed082000 ed407c80 00000000 00000000 > > > [ 30.337975] 7c40: 00000000 00000001 00000040 00000000 00000000 04ae0200 00000000 ed079010 > > > [ 30.346563] 7c60: ed407c80 ed407d30 00000200 ed312200 ed312200 c05e9994 ed407c80 c0191f70 > > > [ 30.355150] 7c80: 00000000 00000200 00000000 00000000 00000000 00000000 ed312200 00000000 > > > [ 30.363738] 7ca0: 00a00000 00000000 00000200 00000000 0f600000 00000000 ed407d30 c05d9fbc > > > [ 30.372328] 7cc0: 00000200 ed407d30 ed312200 00000000 9188fed8 c05d9f7c 00000000 c05d6c7c > > > [ 30.380917] 7ce0: 00000200 ed407d30 ed312200 ed312200 040e0200 00000000 ed628000 00000200 > > > [ 30.389509] 7d00: 00000200 00000207 00000000 c0604cd0 00000200 ed407d30 ed312200 60000013 > > > [ 30.398097] 7d20: 00000200 00000000 ed208040 c019269c 00000000 00000004 ed628dd8 ed312200 > > > [ 30.406676] 7d40: ed628000 00000207 ed312200 00000800 00000207 00000000 ffffffff c060536c > > > [ 30.415267] 7d60: 00000200 c0607fb8 ed18c800 ed628000 ed2a0800 00000008 00000000 c0601178 > > > [ 30.423851] 7d80: ed312200 ed628550 00000000 ed628000 ed312200 ed18c800 ed2a0800 ed628000 > > > [ 30.432437] 7da0: ed312200 00000008 00000004 ed18c800 ed2a0800 00001014 ed208040 c0601cf0 > > > [ 30.441020] 7dc0: 00000000 00000800 00000000 ec870140 00000003 60000013 c1568e2c c060154c > > > [ 30.449605] 7de0: ed18c800 c019269c 00000000 00000002 ed628000 00000800 ed628000 00000000 > > > [ 30.458191] 7e00: 00000008 ed18c800 00000000 00000088 ed18c800 c0600538 00000000 00000800 > > > [ 30.466779] 7e20: ed18c800 ed770000 00000000 00000008 ed770000 c0426a90 00000800 00000000 > > > [ 30.475366] 7e40: 00000088 00000000 00000800 000000a0 ed770000 c0430904 00000800 c08002e8 > > > [ 30.483952] 7e60: 00000000 00000000 000000d8 00000000 00000000 00000000 00000000 00000000 > > > [ 30.492545] 7e80: ed18c800 ed407eb4 00000001 ed770000 00000000 00000288 00000003 ed51b5d4 > > > [ 30.501126] 7ea0: ed406000 00000000 00000000 c0431880 ed77014c 76ecb30e 5c265a59 ec870140 > > > [ 30.509709] 7ec0: 00000003 60000013 c1568e2c c0431f38 00000000 c019269c ed77014c 00000002 > > > [ 30.518301] 7ee0: ed51b5d4 ed77014c ed77014c ed770104 ed51b5d4 ed770000 ed406000 00000000 > > > [ 30.526886] 7f00: ed77014c c08039c8 00000000 00000288 00000003 ed51b5d4 ed770000 c042201c > > > [ 30.535471] 7f20: ed1cb000 00000000 c0dcbbe0 00000534 ec870140 c02e6324 edf88a10 ed1cb000 > > > [ 30.544056] 7f40: c0926528 c02afaf4 c0421714 00000015 c0d823cc c02afc40 ed770000 c0421720 > > > [ 30.552643] 7f60: ed1cb000 c02b0288 ec870140 ed61a600 00000000 c02d0950 ec870634 c0159b34 > > > [ 30.561220] 7f80: ed61a61c 00000000 ed407fb0 c0107ae4 00000034 c0107ae4 00000000 c010b09c > > > [ 30.569803] 7fa0: 00021cb8 0001e320 00021cb8 c0107968 00000000 00000000 00000000 00000000 > > > [ 30.578392] 7fc0: 00021cb8 0001e320 00021cb8 00000034 00021ca8 00000000 00000000 00000000 > > > [ 30.586973] 7fe0: 00021ce8 bec06600 b6e11dbc b6e11ddc 60000010 00021cb8 afffd861 afffdc61 > > > [ 30.595558] [<c04abe68>] (memcpy) from [<c05d7490>] (mtd_ooblayout_set_bytes+0x7c/0xa4) > > > [ 30.603968] [<c05d7490>] (mtd_ooblayout_set_bytes) from [<c05d74fc>] (mtd_ooblayout_set_eccbytes+0x1c/0x28) > > > [ 30.614207] [<c05d74fc>] (mtd_ooblayout_set_eccbytes) from [<c05e8388>] (nand_write_subpage_hwecc+0x1a8/0x1d0) > > > [ 30.624707] [<c05e8388>] (nand_write_subpage_hwecc) from [<c05e9658>] (nand_do_write_ops+0x22c/0x50c) > > > [ 30.634397] [<c05e9658>] (nand_do_write_ops) from [<c05e9994>] (nand_write+0x5c/0x7c) > > > [ 30.642621] [<c05e9994>] (nand_write) from [<c05d9fbc>] (part_write+0x40/0x48) > > > [ 30.650211] [<c05d9fbc>] (part_write) from [<c05d6c7c>] (mtd_write+0x90/0xa8) > > > [ 30.657718] [<c05d6c7c>] (mtd_write) from [<c0604cd0>] (ubi_io_write+0x114/0x6b8) > > > [ 30.665573] [<c0604cd0>] (ubi_io_write) from [<c060536c>] (ubi_io_write_vid_hdr+0xf8/0x148) > > > [ 30.674342] [<c060536c>] (ubi_io_write_vid_hdr) from [<c0601178>] (try_write_vid_and_data+0x54/0x1a4) > > > [ 30.684030] [<c0601178>] (try_write_vid_and_data) from [<c0601cf0>] (ubi_eba_write_leb+0x1f8/0x7bc) > > > [ 30.693525] [<c0601cf0>] (ubi_eba_write_leb) from [<c0600538>] (ubi_leb_write+0xbc/0xdc) > > > [ 30.702021] [<c0600538>] (ubi_leb_write) from [<c0426a90>] (ubifs_leb_write+0x9c/0x11c) > > > [ 30.710426] [<c0426a90>] (ubifs_leb_write) from [<c0430904>] (ubifs_log_start_commit+0x27c/0x444) > > > [ 30.719743] [<c0430904>] (ubifs_log_start_commit) from [<c0431880>] (do_commit+0x1b8/0x7e8) > > > [ 30.728521] [<c0431880>] (do_commit) from [<c042201c>] (ubifs_sync_fs+0x8c/0xa0) > > > [ 30.736292] [<c042201c>] (ubifs_sync_fs) from [<c02e6324>] (sync_filesystem+0x88/0xac) > > > [ 30.744616] [<c02e6324>] (sync_filesystem) from [<c02afaf4>] (generic_shutdown_super+0x24/0xf8) > > > [ 30.753754] [<c02afaf4>] (generic_shutdown_super) from [<c02afc40>] (kill_anon_super+0xc/0x18) > > > [ 30.762807] [<c02afc40>] (kill_anon_super) from [<c0421720>] (kill_ubifs_super+0xc/0x18) > > > [ 30.771308] [<c0421720>] (kill_ubifs_super) from [<c02b0288>] (deactivate_locked_super+0x5c/0x80) > > > [ 30.780627] [<c02b0288>] (deactivate_locked_super) from [<c02d0950>] (cleanup_mnt+0x38/0x78) > > > [ 30.789492] [<c02d0950>] (cleanup_mnt) from [<c0159b34>] (task_work_run+0xc0/0xe8) > > > [ 30.797444] [<c0159b34>] (task_work_run) from [<c010b09c>] (do_work_pending+0xd4/0xd8) > > > [ 30.805759] [<c010b09c>] (do_work_pending) from [<c0107968>] (slow_work_pending+0xc/0x20) > > > [ 30.814345] Code: e8bd8011 e26cc004 e35c0002 c4d13001 (a4d14001) > > > [ 30.820843] ---[ end trace bc240a5a583e6e02 ]--- > > > > > > > > > ______________________________________________________ > > Linux MTD discussion mailing list > > http://lists.infradead.org/mailman/listinfo/linux-mtd/ > ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-13 20:29 ` Boris Brezillon @ 2017-10-16 10:22 ` Roger Quadros 2017-10-16 11:34 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Roger Quadros @ 2017-10-16 10:22 UTC (permalink / raw) To: Boris Brezillon Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 13/10/17 23:29, Boris Brezillon wrote: > On Fri, 13 Oct 2017 22:24:58 +0200 > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > >> On Fri, 13 Oct 2017 14:50:33 +0200 >> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: >> >>> On Fri, 13 Oct 2017 14:57:29 +0300 >>> Roger Quadros <rogerq@ti.com> wrote: >>> >>>> Hi Boris, >>>> >>>> NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 >>>> >>>> Behaviour follows through in v4.13 and v4.14-rc as well. >>>> >>>> Do you have any idea about this? >> >> More info on what has changed in 4.12: we no longer allocate the >> nand_buffer struct + its internal buffer using a single big kmalloc >> call, which means the nand_buffer struct is now likely to be allocated >> in a small object slab (sizeof(nand_buffers) = 12). If you have a >> use-after-free bug somewhere in the kernel, it might corrupt the Spot on. Problem starts from commit 4d5dea5725f3aa95b9b64e252540e435dd216dbc "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset" > > I meant buffer-overflow, not use-after-free. Your analysis seems correct. > >> nand_buffers object, which might explain the bug you see here. >> >>> >>> Can you try with this patch [1] applied and paste me the values printed >>> just before the crash? >>> >>> [1]http://code.bulix.org/lc8xk0-209746 == unmounting volume [ 36.308792] nand: nand_write_subpage_hwecc:2575 ecc_calc = (null) oob_poi = ed096800 [ 36.317319] mtd_ooblayout_set_bytes:1330 dst = ed096802 src = (null) [ 36.324162] Unable to handle kernel NULL pointer dereference at virtual address 00000000 Running the following patch https://hastebin.com/ulogurutuz.php shows [ 37.260689] nand: nand_write_subpage_hwecc:2547:A ecc_calc = ed116e40 oob_poi = ed117800 [ 37.260772] nand: nand_write_subpage_hwecc:2556:A1:step 0, ecc_calc = ed116e40 [ 37.260779] nand: nand_write_subpage_hwecc:2562:A2:step 0, ecc_calc = ed116e40 [ 37.260834] nand: nand_write_subpage_hwecc:2556:A1:step 1, ecc_calc = ed116e40 [ 37.260840] nand: nand_write_subpage_hwecc:2567:A3-pre:step 1, ecc_calc = ed116e40 [ 37.260846] omap_calculate_ecc_bch [ 37.260856] nand: nand_write_subpage_hwecc:2570:A3-post:step 1, ecc_calc = (null) [ 37.260912] nand: nand_write_subpage_hwecc:2556:A1:step 2, ecc_calc = (null) [ 37.260918] nand: nand_write_subpage_hwecc:2562:A2:step 2, ecc_calc = (null) [ 37.260972] nand: nand_write_subpage_hwecc:2556:A1:step 3, ecc_calc = (null) [ 37.260978] nand: nand_write_subpage_hwecc:2562:A2:step 3, ecc_calc = (null) [ 37.260984] nand: nand_write_subpage_hwecc:2587:B ecc_calc = (null) oob_poi = ed117800 [ 37.260991] mtd_ooblayout_set_bytes:1330 dst = ed117802 src = (null) which means omap_calculate_ecc_bch() it the culprit. Looks like the function calculates and stores ECC for all sectors even if we just want ECC for just one sector (sub-page). Is my understanding correct - We should not be hooking the multi-sector ECC calculator omap_calculate_ecc_bch() to ecc.calculate - provide a new one sector ECC calculator function (for BCH4/8/16) for omap and hook it to ecc.calculate OR - override nand_read_subpage() and nand_write_subpage() using omap specific implementation (for BCH4/8/16). >>> >>>> >>>> == unmounting volume >>>> [ 30.128584] Unable to handle kernel NULL pointer dereference at virtual address 00000000 >>>> [ 30.137234] pgd = ed3d0000 >>>> [ 30.140079] [00000000] *pgd=fd67a835 >>>> [ 30.143843] Internal error: Oops: 17 [#1] SMP ARM >>>> [ 30.148781] Modules linked in: snd_soc_davinci_mcasp xhci_plat_hcd snd_soc_edma xhci_hcd snd_soc_tlv320aic3x snd_soc_simple_card snd_soc_omap snd_soc_simple_card_utils snd_soc_core usbcoe >>>> [ 30.193881] CPU: 1 PID: 2149 Comm: umount Not tainted 4.12.0-00001-g2c09531 #1440 >>>> [ 30.201734] Hardware name: Generic DRA74X (Flattened Device Tree) >>>> [ 30.208130] task: ec870140 task.stack: ed406000 >>>> [ 30.212889] PC is at memcpy+0xe8/0x330 >>>> [ 30.216833] LR is at mtd_ooblayout_set_bytes+0x7c/0xa4 >>>> [ 30.222231] pc : [<c04abe68>] lr : [<c05d7490>] psr: 60000013 >>>> [ 30.222231] sp : ed407b74 ip : 00000002 fp : 00000200 >>>> [ 30.234276] r10: ed082800 r9 : 00000000 r8 : ed079010 >>>> [ 30.239761] r7 : c05d76d8 r6 : 00000000 r5 : 00000038 r4 : 00000038 >>>> [ 30.246614] r3 : 00000038 r2 : 00000034 r1 : 00000000 r0 : ed082802 >>>> [ 30.253468] Flags: nZCv IRQs on FIQs on Mode SVC_32 ISA ARM Segment none >>>> [ 30.260957] Control: 10c5387d Table: ad3d006a DAC: 00000051 >>>> [ 30.266986] Process umount (pid: 2149, stack limit = 0xed406218) >>>> [ 30.273296] Stack: (0xed407b74 to 0xed408000) >>>> [ 30.277868] 7b60: ed082802 00000038 c05d7490 >>>> [ 30.286458] 7b80: c05d76d8 ed082600 0000ffff 00000000 00000002 00000038 00000004 ed082800 >>>> [ 30.295047] 7ba0: ed079010 00000000 00000000 ed082800 ed079010 c05d74fc 00000038 c05d76d8 >>>> [ 30.303635] 7bc0: ed0e8f6a c05e8388 00000038 00000000 c0dc60f0 00000001 00000010 0000000e >>>> [ 30.312216] 7be0: 00000004 00000001 00000001 00000001 c05f2668 ed079010 00000200 00000200 >>>> [ 30.320806] 7c00: 000095c0 00000200 ed082000 ed312200 000095c0 c05e9658 ed082000 00000000 >>>> [ 30.329392] 7c20: 000095c0 00000002 00000200 00000000 ed082000 ed407c80 00000000 00000000 >>>> [ 30.337975] 7c40: 00000000 00000001 00000040 00000000 00000000 04ae0200 00000000 ed079010 >>>> [ 30.346563] 7c60: ed407c80 ed407d30 00000200 ed312200 ed312200 c05e9994 ed407c80 c0191f70 >>>> [ 30.355150] 7c80: 00000000 00000200 00000000 00000000 00000000 00000000 ed312200 00000000 >>>> [ 30.363738] 7ca0: 00a00000 00000000 00000200 00000000 0f600000 00000000 ed407d30 c05d9fbc >>>> [ 30.372328] 7cc0: 00000200 ed407d30 ed312200 00000000 9188fed8 c05d9f7c 00000000 c05d6c7c >>>> [ 30.380917] 7ce0: 00000200 ed407d30 ed312200 ed312200 040e0200 00000000 ed628000 00000200 >>>> [ 30.389509] 7d00: 00000200 00000207 00000000 c0604cd0 00000200 ed407d30 ed312200 60000013 >>>> [ 30.398097] 7d20: 00000200 00000000 ed208040 c019269c 00000000 00000004 ed628dd8 ed312200 >>>> [ 30.406676] 7d40: ed628000 00000207 ed312200 00000800 00000207 00000000 ffffffff c060536c >>>> [ 30.415267] 7d60: 00000200 c0607fb8 ed18c800 ed628000 ed2a0800 00000008 00000000 c0601178 >>>> [ 30.423851] 7d80: ed312200 ed628550 00000000 ed628000 ed312200 ed18c800 ed2a0800 ed628000 >>>> [ 30.432437] 7da0: ed312200 00000008 00000004 ed18c800 ed2a0800 00001014 ed208040 c0601cf0 >>>> [ 30.441020] 7dc0: 00000000 00000800 00000000 ec870140 00000003 60000013 c1568e2c c060154c >>>> [ 30.449605] 7de0: ed18c800 c019269c 00000000 00000002 ed628000 00000800 ed628000 00000000 >>>> [ 30.458191] 7e00: 00000008 ed18c800 00000000 00000088 ed18c800 c0600538 00000000 00000800 >>>> [ 30.466779] 7e20: ed18c800 ed770000 00000000 00000008 ed770000 c0426a90 00000800 00000000 >>>> [ 30.475366] 7e40: 00000088 00000000 00000800 000000a0 ed770000 c0430904 00000800 c08002e8 >>>> [ 30.483952] 7e60: 00000000 00000000 000000d8 00000000 00000000 00000000 00000000 00000000 >>>> [ 30.492545] 7e80: ed18c800 ed407eb4 00000001 ed770000 00000000 00000288 00000003 ed51b5d4 >>>> [ 30.501126] 7ea0: ed406000 00000000 00000000 c0431880 ed77014c 76ecb30e 5c265a59 ec870140 >>>> [ 30.509709] 7ec0: 00000003 60000013 c1568e2c c0431f38 00000000 c019269c ed77014c 00000002 >>>> [ 30.518301] 7ee0: ed51b5d4 ed77014c ed77014c ed770104 ed51b5d4 ed770000 ed406000 00000000 >>>> [ 30.526886] 7f00: ed77014c c08039c8 00000000 00000288 00000003 ed51b5d4 ed770000 c042201c >>>> [ 30.535471] 7f20: ed1cb000 00000000 c0dcbbe0 00000534 ec870140 c02e6324 edf88a10 ed1cb000 >>>> [ 30.544056] 7f40: c0926528 c02afaf4 c0421714 00000015 c0d823cc c02afc40 ed770000 c0421720 >>>> [ 30.552643] 7f60: ed1cb000 c02b0288 ec870140 ed61a600 00000000 c02d0950 ec870634 c0159b34 >>>> [ 30.561220] 7f80: ed61a61c 00000000 ed407fb0 c0107ae4 00000034 c0107ae4 00000000 c010b09c >>>> [ 30.569803] 7fa0: 00021cb8 0001e320 00021cb8 c0107968 00000000 00000000 00000000 00000000 >>>> [ 30.578392] 7fc0: 00021cb8 0001e320 00021cb8 00000034 00021ca8 00000000 00000000 00000000 >>>> [ 30.586973] 7fe0: 00021ce8 bec06600 b6e11dbc b6e11ddc 60000010 00021cb8 afffd861 afffdc61 >>>> [ 30.595558] [<c04abe68>] (memcpy) from [<c05d7490>] (mtd_ooblayout_set_bytes+0x7c/0xa4) >>>> [ 30.603968] [<c05d7490>] (mtd_ooblayout_set_bytes) from [<c05d74fc>] (mtd_ooblayout_set_eccbytes+0x1c/0x28) >>>> [ 30.614207] [<c05d74fc>] (mtd_ooblayout_set_eccbytes) from [<c05e8388>] (nand_write_subpage_hwecc+0x1a8/0x1d0) >>>> [ 30.624707] [<c05e8388>] (nand_write_subpage_hwecc) from [<c05e9658>] (nand_do_write_ops+0x22c/0x50c) >>>> [ 30.634397] [<c05e9658>] (nand_do_write_ops) from [<c05e9994>] (nand_write+0x5c/0x7c) >>>> [ 30.642621] [<c05e9994>] (nand_write) from [<c05d9fbc>] (part_write+0x40/0x48) >>>> [ 30.650211] [<c05d9fbc>] (part_write) from [<c05d6c7c>] (mtd_write+0x90/0xa8) >>>> [ 30.657718] [<c05d6c7c>] (mtd_write) from [<c0604cd0>] (ubi_io_write+0x114/0x6b8) >>>> [ 30.665573] [<c0604cd0>] (ubi_io_write) from [<c060536c>] (ubi_io_write_vid_hdr+0xf8/0x148) >>>> [ 30.674342] [<c060536c>] (ubi_io_write_vid_hdr) from [<c0601178>] (try_write_vid_and_data+0x54/0x1a4) >>>> [ 30.684030] [<c0601178>] (try_write_vid_and_data) from [<c0601cf0>] (ubi_eba_write_leb+0x1f8/0x7bc) >>>> [ 30.693525] [<c0601cf0>] (ubi_eba_write_leb) from [<c0600538>] (ubi_leb_write+0xbc/0xdc) >>>> [ 30.702021] [<c0600538>] (ubi_leb_write) from [<c0426a90>] (ubifs_leb_write+0x9c/0x11c) >>>> [ 30.710426] [<c0426a90>] (ubifs_leb_write) from [<c0430904>] (ubifs_log_start_commit+0x27c/0x444) >>>> [ 30.719743] [<c0430904>] (ubifs_log_start_commit) from [<c0431880>] (do_commit+0x1b8/0x7e8) >>>> [ 30.728521] [<c0431880>] (do_commit) from [<c042201c>] (ubifs_sync_fs+0x8c/0xa0) >>>> [ 30.736292] [<c042201c>] (ubifs_sync_fs) from [<c02e6324>] (sync_filesystem+0x88/0xac) >>>> [ 30.744616] [<c02e6324>] (sync_filesystem) from [<c02afaf4>] (generic_shutdown_super+0x24/0xf8) >>>> [ 30.753754] [<c02afaf4>] (generic_shutdown_super) from [<c02afc40>] (kill_anon_super+0xc/0x18) >>>> [ 30.762807] [<c02afc40>] (kill_anon_super) from [<c0421720>] (kill_ubifs_super+0xc/0x18) >>>> [ 30.771308] [<c0421720>] (kill_ubifs_super) from [<c02b0288>] (deactivate_locked_super+0x5c/0x80) >>>> [ 30.780627] [<c02b0288>] (deactivate_locked_super) from [<c02d0950>] (cleanup_mnt+0x38/0x78) >>>> [ 30.789492] [<c02d0950>] (cleanup_mnt) from [<c0159b34>] (task_work_run+0xc0/0xe8) >>>> [ 30.797444] [<c0159b34>] (task_work_run) from [<c010b09c>] (do_work_pending+0xd4/0xd8) >>>> [ 30.805759] [<c010b09c>] (do_work_pending) from [<c0107968>] (slow_work_pending+0xc/0x20) >>>> [ 30.814345] Code: e8bd8011 e26cc004 e35c0002 c4d13001 (a4d14001) >>>> [ 30.820843] ---[ end trace bc240a5a583e6e02 ]--- >>>> >>> >>> >>> ______________________________________________________ >>> Linux MTD discussion mailing list >>> http://lists.infradead.org/mailman/listinfo/linux-mtd/ >> > > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- cheers, -roger ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-16 10:22 ` Roger Quadros @ 2017-10-16 11:34 ` Boris Brezillon 2017-10-16 12:12 ` Roger Quadros 0 siblings, 1 reply; 9+ messages in thread From: Boris Brezillon @ 2017-10-16 11:34 UTC (permalink / raw) To: Roger Quadros Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin Hi Roger, On Mon, 16 Oct 2017 13:22:04 +0300 Roger Quadros <rogerq@ti.com> wrote: > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 13/10/17 23:29, Boris Brezillon wrote: > > On Fri, 13 Oct 2017 22:24:58 +0200 > > Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > > >> On Fri, 13 Oct 2017 14:50:33 +0200 > >> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > >> > >>> On Fri, 13 Oct 2017 14:57:29 +0300 > >>> Roger Quadros <rogerq@ti.com> wrote: > >>> > >>>> Hi Boris, > >>>> > >>>> NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > >>>> > >>>> Behaviour follows through in v4.13 and v4.14-rc as well. > >>>> > >>>> Do you have any idea about this? > >> > >> More info on what has changed in 4.12: we no longer allocate the > >> nand_buffer struct + its internal buffer using a single big kmalloc > >> call, which means the nand_buffer struct is now likely to be allocated > >> in a small object slab (sizeof(nand_buffers) = 12). If you have a > >> use-after-free bug somewhere in the kernel, it might corrupt the > > Spot on. Problem starts from commit 4d5dea5725f3aa95b9b64e252540e435dd216dbc > "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset" > > > > > I meant buffer-overflow, not use-after-free. > > Your analysis seems correct. > > > > >> nand_buffers object, which might explain the bug you see here. > >> > >>> > >>> Can you try with this patch [1] applied and paste me the values printed > >>> just before the crash? > >>> > >>> [1]http://code.bulix.org/lc8xk0-209746 > > == unmounting volume > [ 36.308792] nand: nand_write_subpage_hwecc:2575 ecc_calc = (null) oob_poi = ed096800 > [ 36.317319] mtd_ooblayout_set_bytes:1330 dst = ed096802 src = (null) > [ 36.324162] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > > Running the following patch > https://hastebin.com/ulogurutuz.php > shows > > [ 37.260689] nand: nand_write_subpage_hwecc:2547:A ecc_calc = ed116e40 oob_poi = ed117800 > [ 37.260772] nand: nand_write_subpage_hwecc:2556:A1:step 0, ecc_calc = ed116e40 > [ 37.260779] nand: nand_write_subpage_hwecc:2562:A2:step 0, ecc_calc = ed116e40 > [ 37.260834] nand: nand_write_subpage_hwecc:2556:A1:step 1, ecc_calc = ed116e40 > [ 37.260840] nand: nand_write_subpage_hwecc:2567:A3-pre:step 1, ecc_calc = ed116e40 > [ 37.260846] omap_calculate_ecc_bch > [ 37.260856] nand: nand_write_subpage_hwecc:2570:A3-post:step 1, ecc_calc = (null) > [ 37.260912] nand: nand_write_subpage_hwecc:2556:A1:step 2, ecc_calc = (null) > [ 37.260918] nand: nand_write_subpage_hwecc:2562:A2:step 2, ecc_calc = (null) > [ 37.260972] nand: nand_write_subpage_hwecc:2556:A1:step 3, ecc_calc = (null) > [ 37.260978] nand: nand_write_subpage_hwecc:2562:A2:step 3, ecc_calc = (null) > [ 37.260984] nand: nand_write_subpage_hwecc:2587:B ecc_calc = (null) oob_poi = ed117800 > [ 37.260991] mtd_ooblayout_set_bytes:1330 dst = ed117802 src = (null) > > which means omap_calculate_ecc_bch() it the culprit. > > Looks like the function calculates and stores ECC for all sectors even if we just want ECC > for just one sector (sub-page). Yes, looks like you find the root cause. > > Is my understanding correct > - We should not be hooking the multi-sector ECC calculator omap_calculate_ecc_bch() to ecc.calculate > - provide a new one sector ECC calculator function (for BCH4/8/16) for omap and hook it to ecc.calculate > OR > - override nand_read_subpage() and nand_write_subpage() using omap specific implementation (for BCH4/8/16). Second solution sounds simpler because the ECC sector information is not passed to ecc->calculate() hook, which means you'd have to extract it from the ecc_calc pointer: (uintptr_t)(ecc_calc - chip->buffers->ecccalc) / chip->ecc.size and doing arithmetic on pointers is usually not a good idea. Anyway, I'd be fine with both solutions, so pick the one you prefer. Regards, Boris ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-16 11:34 ` Boris Brezillon @ 2017-10-16 12:12 ` Roger Quadros 2017-10-16 12:39 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Roger Quadros @ 2017-10-16 12:12 UTC (permalink / raw) To: Boris Brezillon Cc: Tony Lindgren, linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin Hi Boris, Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki On 16/10/17 14:34, Boris Brezillon wrote: > Hi Roger, > > On Mon, 16 Oct 2017 13:22:04 +0300 > Roger Quadros <rogerq@ti.com> wrote: > >> >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki >> >> On 13/10/17 23:29, Boris Brezillon wrote: >>> On Fri, 13 Oct 2017 22:24:58 +0200 >>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: >>> >>>> On Fri, 13 Oct 2017 14:50:33 +0200 >>>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: >>>> >>>>> On Fri, 13 Oct 2017 14:57:29 +0300 >>>>> Roger Quadros <rogerq@ti.com> wrote: >>>>> >>>>>> Hi Boris, >>>>>> >>>>>> NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 >>>>>> >>>>>> Behaviour follows through in v4.13 and v4.14-rc as well. >>>>>> >>>>>> Do you have any idea about this? >>>> >>>> More info on what has changed in 4.12: we no longer allocate the >>>> nand_buffer struct + its internal buffer using a single big kmalloc >>>> call, which means the nand_buffer struct is now likely to be allocated >>>> in a small object slab (sizeof(nand_buffers) = 12). If you have a >>>> use-after-free bug somewhere in the kernel, it might corrupt the >> >> Spot on. Problem starts from commit 4d5dea5725f3aa95b9b64e252540e435dd216dbc >> "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset" >> >>> >>> I meant buffer-overflow, not use-after-free. >> >> Your analysis seems correct. >> >>> >>>> nand_buffers object, which might explain the bug you see here. >>>> >>>>> >>>>> Can you try with this patch [1] applied and paste me the values printed >>>>> just before the crash? >>>>> >>>>> [1]http://code.bulix.org/lc8xk0-209746 >> >> == unmounting volume >> [ 36.308792] nand: nand_write_subpage_hwecc:2575 ecc_calc = (null) oob_poi = ed096800 >> [ 36.317319] mtd_ooblayout_set_bytes:1330 dst = ed096802 src = (null) >> [ 36.324162] Unable to handle kernel NULL pointer dereference at virtual address 00000000 >> >> >> Running the following patch >> https://hastebin.com/ulogurutuz.php >> shows >> >> [ 37.260689] nand: nand_write_subpage_hwecc:2547:A ecc_calc = ed116e40 oob_poi = ed117800 >> [ 37.260772] nand: nand_write_subpage_hwecc:2556:A1:step 0, ecc_calc = ed116e40 >> [ 37.260779] nand: nand_write_subpage_hwecc:2562:A2:step 0, ecc_calc = ed116e40 >> [ 37.260834] nand: nand_write_subpage_hwecc:2556:A1:step 1, ecc_calc = ed116e40 >> [ 37.260840] nand: nand_write_subpage_hwecc:2567:A3-pre:step 1, ecc_calc = ed116e40 >> [ 37.260846] omap_calculate_ecc_bch >> [ 37.260856] nand: nand_write_subpage_hwecc:2570:A3-post:step 1, ecc_calc = (null) >> [ 37.260912] nand: nand_write_subpage_hwecc:2556:A1:step 2, ecc_calc = (null) >> [ 37.260918] nand: nand_write_subpage_hwecc:2562:A2:step 2, ecc_calc = (null) >> [ 37.260972] nand: nand_write_subpage_hwecc:2556:A1:step 3, ecc_calc = (null) >> [ 37.260978] nand: nand_write_subpage_hwecc:2562:A2:step 3, ecc_calc = (null) >> [ 37.260984] nand: nand_write_subpage_hwecc:2587:B ecc_calc = (null) oob_poi = ed117800 >> [ 37.260991] mtd_ooblayout_set_bytes:1330 dst = ed117802 src = (null) >> >> which means omap_calculate_ecc_bch() it the culprit. >> >> Looks like the function calculates and stores ECC for all sectors even if we just want ECC >> for just one sector (sub-page). > > Yes, looks like you find the root cause. > >> >> Is my understanding correct >> - We should not be hooking the multi-sector ECC calculator omap_calculate_ecc_bch() to ecc.calculate >> - provide a new one sector ECC calculator function (for BCH4/8/16) for omap and hook it to ecc.calculate >> OR >> - override nand_read_subpage() and nand_write_subpage() using omap specific implementation (for BCH4/8/16). > > Second solution sounds simpler because the ECC sector information is > not passed to ecc->calculate() hook, which means you'd have to extract > it from the ecc_calc pointer: > > (uintptr_t)(ecc_calc - chip->buffers->ecccalc) / chip->ecc.size I don't think we need ECC sector number at all if we're always going to do a transfer of one sector of data after calling ecc.hwctl(NAND_ECC_READ/WRITE) and before calling ecc.calculate. My understanding is that the ECC calculators sector 0 registers will always contain the right content irrespective of which sector we transfer as long as we do, ecc.hwctl(mtd, NAND_ECC_READ/WRITE); transfer one sector; ecc.calculate(); Why isn't there a nand_read_subpage_hwecc()? In the current form a subpage read won't work if if ecc->mode is NAND_ECC_HW and controllers expect a ecc.hwctl(NAND_ECC_READ) before calling ecc.calculate(). For the OMAP case I can override both subpage functions. Is there a good way to test if subpage read/writes are working as they should? > > and doing arithmetic on pointers is usually not a good idea. > > Anyway, I'd be fine with both solutions, so pick the one you prefer. > > Regards, > > Boris > -- > To unsubscribe from this list: send the line "unsubscribe linux-omap" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- cheers, -roger ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-16 12:12 ` Roger Quadros @ 2017-10-16 12:39 ` Boris Brezillon 2017-10-16 13:50 ` Boris Brezillon 0 siblings, 1 reply; 9+ messages in thread From: Boris Brezillon @ 2017-10-16 12:39 UTC (permalink / raw) To: Roger Quadros, Tony Lindgren Cc: linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin On Mon, 16 Oct 2017 15:12:38 +0300 Roger Quadros <rogerq@ti.com> wrote: > Hi Boris, > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > On 16/10/17 14:34, Boris Brezillon wrote: > > Hi Roger, > > > > On Mon, 16 Oct 2017 13:22:04 +0300 > > Roger Quadros <rogerq@ti.com> wrote: > > > >> > >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > >> > >> On 13/10/17 23:29, Boris Brezillon wrote: > >>> On Fri, 13 Oct 2017 22:24:58 +0200 > >>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > >>> > >>>> On Fri, 13 Oct 2017 14:50:33 +0200 > >>>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > >>>> > >>>>> On Fri, 13 Oct 2017 14:57:29 +0300 > >>>>> Roger Quadros <rogerq@ti.com> wrote: > >>>>> > >>>>>> Hi Boris, > >>>>>> > >>>>>> NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > >>>>>> > >>>>>> Behaviour follows through in v4.13 and v4.14-rc as well. > >>>>>> > >>>>>> Do you have any idea about this? > >>>> > >>>> More info on what has changed in 4.12: we no longer allocate the > >>>> nand_buffer struct + its internal buffer using a single big kmalloc > >>>> call, which means the nand_buffer struct is now likely to be allocated > >>>> in a small object slab (sizeof(nand_buffers) = 12). If you have a > >>>> use-after-free bug somewhere in the kernel, it might corrupt the > >> > >> Spot on. Problem starts from commit 4d5dea5725f3aa95b9b64e252540e435dd216dbc > >> "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset" > >> > >>> > >>> I meant buffer-overflow, not use-after-free. > >> > >> Your analysis seems correct. > >> > >>> > >>>> nand_buffers object, which might explain the bug you see here. > >>>> > >>>>> > >>>>> Can you try with this patch [1] applied and paste me the values printed > >>>>> just before the crash? > >>>>> > >>>>> [1]http://code.bulix.org/lc8xk0-209746 > >> > >> == unmounting volume > >> [ 36.308792] nand: nand_write_subpage_hwecc:2575 ecc_calc = (null) oob_poi = ed096800 > >> [ 36.317319] mtd_ooblayout_set_bytes:1330 dst = ed096802 src = (null) > >> [ 36.324162] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > >> > >> > >> Running the following patch > >> https://hastebin.com/ulogurutuz.php > >> shows > >> > >> [ 37.260689] nand: nand_write_subpage_hwecc:2547:A ecc_calc = ed116e40 oob_poi = ed117800 > >> [ 37.260772] nand: nand_write_subpage_hwecc:2556:A1:step 0, ecc_calc = ed116e40 > >> [ 37.260779] nand: nand_write_subpage_hwecc:2562:A2:step 0, ecc_calc = ed116e40 > >> [ 37.260834] nand: nand_write_subpage_hwecc:2556:A1:step 1, ecc_calc = ed116e40 > >> [ 37.260840] nand: nand_write_subpage_hwecc:2567:A3-pre:step 1, ecc_calc = ed116e40 > >> [ 37.260846] omap_calculate_ecc_bch > >> [ 37.260856] nand: nand_write_subpage_hwecc:2570:A3-post:step 1, ecc_calc = (null) > >> [ 37.260912] nand: nand_write_subpage_hwecc:2556:A1:step 2, ecc_calc = (null) > >> [ 37.260918] nand: nand_write_subpage_hwecc:2562:A2:step 2, ecc_calc = (null) > >> [ 37.260972] nand: nand_write_subpage_hwecc:2556:A1:step 3, ecc_calc = (null) > >> [ 37.260978] nand: nand_write_subpage_hwecc:2562:A2:step 3, ecc_calc = (null) > >> [ 37.260984] nand: nand_write_subpage_hwecc:2587:B ecc_calc = (null) oob_poi = ed117800 > >> [ 37.260991] mtd_ooblayout_set_bytes:1330 dst = ed117802 src = (null) > >> > >> which means omap_calculate_ecc_bch() it the culprit. > >> > >> Looks like the function calculates and stores ECC for all sectors even if we just want ECC > >> for just one sector (sub-page). > > > > Yes, looks like you find the root cause. > > > >> > >> Is my understanding correct > >> - We should not be hooking the multi-sector ECC calculator omap_calculate_ecc_bch() to ecc.calculate > >> - provide a new one sector ECC calculator function (for BCH4/8/16) for omap and hook it to ecc.calculate > >> OR > >> - override nand_read_subpage() and nand_write_subpage() using omap specific implementation (for BCH4/8/16). > > > > Second solution sounds simpler because the ECC sector information is > > not passed to ecc->calculate() hook, which means you'd have to extract > > it from the ecc_calc pointer: > > > > (uintptr_t)(ecc_calc - chip->buffers->ecccalc) / chip->ecc.size > > I don't think we need ECC sector number at all if we're always going to do a transfer > of one sector of data after calling ecc.hwctl(NAND_ECC_READ/WRITE) and before calling ecc.calculate. > > My understanding is that the ECC calculators sector 0 registers will always contain > the right content irrespective of which sector we transfer as long as we do, > ecc.hwctl(mtd, NAND_ECC_READ/WRITE); > transfer one sector; > ecc.calculate(); Ok, then the first solution sounds good too. > > Why isn't there a nand_read_subpage_hwecc()? Probably because nobody ever needed it. Feel free to add it if you think this is necessary. > In the current form a subpage read won't work if > if ecc->mode is NAND_ECC_HW and controllers expect a ecc.hwctl(NAND_ECC_READ) before > calling ecc.calculate(). > > For the OMAP case I can override both subpage functions. > Is there a good way to test if subpage read/writes are working as they should? There's a nandsubpage test [1] in mtd-utils. [1]http://git.infradead.org/mtd-utils.git/blob/HEAD:/tests/mtd-tests/nandpagetest.c ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: gpmc-nand broken since v4.12 2017-10-16 12:39 ` Boris Brezillon @ 2017-10-16 13:50 ` Boris Brezillon 0 siblings, 0 replies; 9+ messages in thread From: Boris Brezillon @ 2017-10-16 13:50 UTC (permalink / raw) To: Roger Quadros, Tony Lindgren Cc: linux-omap, linux-mtd@lists.infradead.org, Cooper Jr., Franklin On Mon, 16 Oct 2017 14:39:04 +0200 Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > On Mon, 16 Oct 2017 15:12:38 +0300 > Roger Quadros <rogerq@ti.com> wrote: > > > Hi Boris, > > > > > > Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > > > On 16/10/17 14:34, Boris Brezillon wrote: > > > Hi Roger, > > > > > > On Mon, 16 Oct 2017 13:22:04 +0300 > > > Roger Quadros <rogerq@ti.com> wrote: > > > > > >> > > >> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki. Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki > > >> > > >> On 13/10/17 23:29, Boris Brezillon wrote: > > >>> On Fri, 13 Oct 2017 22:24:58 +0200 > > >>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > >>> > > >>>> On Fri, 13 Oct 2017 14:50:33 +0200 > > >>>> Boris Brezillon <boris.brezillon@free-electrons.com> wrote: > > >>>> > > >>>>> On Fri, 13 Oct 2017 14:57:29 +0300 > > >>>>> Roger Quadros <rogerq@ti.com> wrote: > > >>>>> > > >>>>>> Hi Boris, > > >>>>>> > > >>>>>> NAND on gpmc-omap breaks for me while doing a unmount of a ubi volume since v4.12 > > >>>>>> > > >>>>>> Behaviour follows through in v4.13 and v4.14-rc as well. > > >>>>>> > > >>>>>> Do you have any idea about this? > > >>>> > > >>>> More info on what has changed in 4.12: we no longer allocate the > > >>>> nand_buffer struct + its internal buffer using a single big kmalloc > > >>>> call, which means the nand_buffer struct is now likely to be allocated > > >>>> in a small object slab (sizeof(nand_buffers) = 12). If you have a > > >>>> use-after-free bug somewhere in the kernel, it might corrupt the > > >> > > >> Spot on. Problem starts from commit 4d5dea5725f3aa95b9b64e252540e435dd216dbc > > >> "mtd: nand: allocate aligned buffers if NAND_OWN_BUFFERS is unset" > > >> > > >>> > > >>> I meant buffer-overflow, not use-after-free. > > >> > > >> Your analysis seems correct. > > >> > > >>> > > >>>> nand_buffers object, which might explain the bug you see here. > > >>>> > > >>>>> > > >>>>> Can you try with this patch [1] applied and paste me the values printed > > >>>>> just before the crash? > > >>>>> > > >>>>> [1]http://code.bulix.org/lc8xk0-209746 > > >> > > >> == unmounting volume > > >> [ 36.308792] nand: nand_write_subpage_hwecc:2575 ecc_calc = (null) oob_poi = ed096800 > > >> [ 36.317319] mtd_ooblayout_set_bytes:1330 dst = ed096802 src = (null) > > >> [ 36.324162] Unable to handle kernel NULL pointer dereference at virtual address 00000000 > > >> > > >> > > >> Running the following patch > > >> https://hastebin.com/ulogurutuz.php > > >> shows > > >> > > >> [ 37.260689] nand: nand_write_subpage_hwecc:2547:A ecc_calc = ed116e40 oob_poi = ed117800 > > >> [ 37.260772] nand: nand_write_subpage_hwecc:2556:A1:step 0, ecc_calc = ed116e40 > > >> [ 37.260779] nand: nand_write_subpage_hwecc:2562:A2:step 0, ecc_calc = ed116e40 > > >> [ 37.260834] nand: nand_write_subpage_hwecc:2556:A1:step 1, ecc_calc = ed116e40 > > >> [ 37.260840] nand: nand_write_subpage_hwecc:2567:A3-pre:step 1, ecc_calc = ed116e40 > > >> [ 37.260846] omap_calculate_ecc_bch > > >> [ 37.260856] nand: nand_write_subpage_hwecc:2570:A3-post:step 1, ecc_calc = (null) > > >> [ 37.260912] nand: nand_write_subpage_hwecc:2556:A1:step 2, ecc_calc = (null) > > >> [ 37.260918] nand: nand_write_subpage_hwecc:2562:A2:step 2, ecc_calc = (null) > > >> [ 37.260972] nand: nand_write_subpage_hwecc:2556:A1:step 3, ecc_calc = (null) > > >> [ 37.260978] nand: nand_write_subpage_hwecc:2562:A2:step 3, ecc_calc = (null) > > >> [ 37.260984] nand: nand_write_subpage_hwecc:2587:B ecc_calc = (null) oob_poi = ed117800 > > >> [ 37.260991] mtd_ooblayout_set_bytes:1330 dst = ed117802 src = (null) > > >> > > >> which means omap_calculate_ecc_bch() it the culprit. > > >> > > >> Looks like the function calculates and stores ECC for all sectors even if we just want ECC > > >> for just one sector (sub-page). > > > > > > Yes, looks like you find the root cause. > > > > > >> > > >> Is my understanding correct > > >> - We should not be hooking the multi-sector ECC calculator omap_calculate_ecc_bch() to ecc.calculate > > >> - provide a new one sector ECC calculator function (for BCH4/8/16) for omap and hook it to ecc.calculate > > >> OR > > >> - override nand_read_subpage() and nand_write_subpage() using omap specific implementation (for BCH4/8/16). > > > > > > Second solution sounds simpler because the ECC sector information is > > > not passed to ecc->calculate() hook, which means you'd have to extract > > > it from the ecc_calc pointer: > > > > > > (uintptr_t)(ecc_calc - chip->buffers->ecccalc) / chip->ecc.size > > > > I don't think we need ECC sector number at all if we're always going to do a transfer > > of one sector of data after calling ecc.hwctl(NAND_ECC_READ/WRITE) and before calling ecc.calculate. > > > > My understanding is that the ECC calculators sector 0 registers will always contain > > the right content irrespective of which sector we transfer as long as we do, > > ecc.hwctl(mtd, NAND_ECC_READ/WRITE); > > transfer one sector; > > ecc.calculate(); > > Ok, then the first solution sounds good too. > > > > > Why isn't there a nand_read_subpage_hwecc()? > > Probably because nobody ever needed it. Feel free to add it if you > think this is necessary. Actually, if you want to make your patch easily backport-able to stable releases, you'd better go for the omap_nand_write/read_subpage() approach. The generic solution can be done afterwards. > > > In the current form a subpage read won't work if > > if ecc->mode is NAND_ECC_HW and controllers expect a ecc.hwctl(NAND_ECC_READ) before > > calling ecc.calculate(). > > > > For the OMAP case I can override both subpage functions. > > Is there a good way to test if subpage read/writes are working as they should? > > There's a nandsubpage test [1] in mtd-utils. > > [1]http://git.infradead.org/mtd-utils.git/blob/HEAD:/tests/mtd-tests/nandpagetest.c > > ______________________________________________________ > Linux MTD discussion mailing list > http://lists.infradead.org/mailman/listinfo/linux-mtd/ ______________________________________________________ Linux MTD discussion mailing list http://lists.infradead.org/mailman/listinfo/linux-mtd/ ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2017-10-16 13:50 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2017-10-13 11:57 gpmc-nand broken since v4.12 Roger Quadros 2017-10-13 12:50 ` Boris Brezillon 2017-10-13 20:24 ` Boris Brezillon 2017-10-13 20:29 ` Boris Brezillon 2017-10-16 10:22 ` Roger Quadros 2017-10-16 11:34 ` Boris Brezillon 2017-10-16 12:12 ` Roger Quadros 2017-10-16 12:39 ` Boris Brezillon 2017-10-16 13:50 ` Boris Brezillon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).