Messages in this thread | | | From | Ilya Dryomov <> | Date | Tue, 14 Aug 2018 17:24:03 +0200 | Subject | Re: Warning when using eMMC and partprobe: generic_make_request: Trying to write to read-only block-device |
| |
On Tue, Aug 14, 2018 at 4:41 PM Stefan Agner <stefan@agner.ch> wrote: > > Hi, > > Using Linux 4.18 on a i.MX 6Q I see the following warning during > boot-up: > > [ 23.928916] ------------[ cut here ]------------ > [ 23.933795] WARNING: CPU: 1 PID: 527 at block/blk-core.c:2161 > generic_make_request_checks+0x868/0xa18 > [ 23.943306] generic_make_request: Trying to write to read-only > block-device mmcblk2boot0 (partno 0) > [ 23.952569] Modules linked in: joydev flexcan can_dev coda imx_vdoa > v4l2_mem2mem videobuf2_vmalloc dw_hdmi_ahb_audio evbug nhc_mobility > nhc_hop nhc_routing nhc_ipv6 nhc_dest nhc_fragment nhc_udp fuse > bluetooth_6lowpan 6lowpan > [ 23.973115] CPU: 1 PID: 527 Comm: partprobe Not tainted 4.18.0 #1 > [ 23.979336] Hardware name: Freescale i.MX6 Quad/DualLite (Device > Tree) > [ 23.985984] Backtrace: > [ 23.988513] [<c010ecdc>] (dump_backtrace) from [<c010f064>] > (show_stack+0x18/0x1c) > [ 23.996231] r7:00000000 r6:60060013 r5:00000000 r4:c118ca44 > [ 24.002009] [<c010f04c>] (show_stack) from [<c0bc54e4>] > (dump_stack+0xb4/0xec) > [ 24.009377] [<c0bc5430>] (dump_stack) from [<c012d7dc>] > (__warn+0xc4/0x108) > [ 24.016471] r10:c1108908 r9:c04864f0 r8:00000871 r7:c0ea02dc > r6:00000009 r5:00000000 > [ 24.024447] r4:d73d1d1c r3:abf2ba7b > [ 24.028111] [<c012d718>] (__warn) from [<c012d424>] > (warn_slowpath_fmt+0x4c/0x6c) > [ 24.035741] r9:d73d0000 r8:c01011e4 r7:c04873cc r6:d6f27400 > r5:c0ea05b0 r4:c1108908 > [ 24.043641] [<c012d3dc>] (warn_slowpath_fmt) from [<c04864f0>] > (generic_make_request_checks+0x868/0xa18) > [ 24.053296] r3:d73d1d74 r2:c0ea05b0 > [ 24.058425] r5:d6d4d0a0 r4:d6f94240 > [ 24.063538] [<c0485c88>] (generic_make_request_checks) from > [<c04873cc>] (generic_make_request+0xc0/0x480) > [ 24.076301] r10:d6f94240 r9:d73d0000 r8:c01011e4 r7:c1108908 > r6:d73d1e98 r5:c1108908 > [ 24.087212] r4:d6d4d0a0 > [ 24.091251] [<c048730c>] (generic_make_request) from [<c04877c4>] > (submit_bio+0x38/0x19c) > [ 24.102438] r10:00000076 r9:d73d0000 r8:c01011e4 r7:7fffffff > r6:d73d1e98 r5:c1108908 > [ 24.113265] r4:d6f94240 > [ 24.117278] [<c048778c>] (submit_bio) from [<c047d8c4>] > (submit_bio_wait+0x5c/0x98) > [ 24.127914] r10:00000076 r9:d73d0000 r8:c01011e4 r7:7fffffff > r6:d73d1e98 r5:c1108908 > [ 24.138724] r4:d6f94240 > [ 24.142739] [<c047d868>] (submit_bio_wait) from [<c048bd20>] > (blkdev_issue_flush+0x80/0xb0) > [ 24.154038] r6:00000000 r5:d4164340 r4:d6f94240 > [ 24.160143] [<c048bca0>] (blkdev_issue_flush) from [<c02de510>] > (blkdev_fsync+0x3c/0x54) > [ 24.171143] r7:7fffffff r6:d4164428 r5:7fffffff r4:00000000 > [ 24.178322] [<c02de4d4>] (blkdev_fsync) from [<c02d434c>] > (vfs_fsync_range+0x44/0x84) > [ 24.189080] r6:ffffffff r5:00000000 r4:d66ce000 > [ 24.195173] [<c02d4308>] (vfs_fsync_range) from [<c02d4404>] > (do_fsync+0x44/0x78) > [ 24.205530] r7:00000076 r6:00000000 r5:d66ce000 r4:d66ce000 > [ 24.212672] [<c02d43c0>] (do_fsync) from [<c02d46f8>] > (sys_fsync+0x14/0x18) > [ 24.221140] r6:01320248 r5:00000001 r4:013201d0 > [ 24.227266] [<c02d46e4>] (sys_fsync) from [<c0101000>] > (ret_fast_syscall+0x0/0x28) > [ 24.237781] Exception stack(0xd73d1fa8 to 0xd73d1ff0) > [ 24.244320] 1fa0: 013201d0 00000001 00000004 > be863b1c 00000064 00000000 > [ 24.255437] 1fc0: 013201d0 00000001 01320248 00000076 b6ef8aec > b6ef4c04 b6f37fa4 00000000 > [ 24.266593] 1fe0: 00000076 be863a00 b6e61faf b6de8306 > [ 24.273302] irq event stamp: 13037 > [ 24.278202] hardirqs last enabled at (13045): [<c019a9e4>] > console_unlock+0x3e0/0x4e4 > [ 24.289163] hardirqs last disabled at (13054): [<c019a684>] > console_unlock+0x80/0x4e4 > [ 24.300085] softirqs last enabled at (12880): [<c010240c>] > __do_softirq+0x224/0x2d0 > [ 24.310934] softirqs last disabled at (12833): [<c01334e4>] > irq_exit+0xc8/0x1ac > [ 24.321438] ---[ end trace 05a4aba40df38a0c ]--- > > The system I am using calls partprobe for some reason, which causes the > stack > trace to appear. > > The mmcblkXbootY partitions are hardware partitions on eMMC devices > which are > by default set to read only. Partition probing should really not lead to > a > write as far as I can tell... > > strace shows what partprobe is actually doing: > > ... > openat(AT_FDCWD, "/dev/mmcblk2boot0", O_RDONLY|O_LARGEFILE) = 4 > ... > ioctl(4, BLKFLSBUF) = 0 > ... > ioctl(4, BLKSSZGET, [512]) = 0 > fadvise64_64(4, 0, 0, POSIX_FADV_RANDOM) = 0 > fstat64(4, {st_mode=S_IFBLK|0660, st_rdev=makedev(179, 64), ...}) = 0 > ioctl(4, BLKGETSIZE64, [2097152]) = 0 > ... > ioctl(4, CDROM_GET_CAPABILITY, 0) = -1 EINVAL (Invalid argument) > ioctl(4, BLKALIGNOFF, [0]) = 0 > ioctl(4, BLKIOMIN, [512]) = 0 > ioctl(4, BLKIOOPT, [0]) = 0 > ioctl(4, BLKPBSZGET, [512]) = 0 > ioctl(4, BLKSSZGET, [512]) = 0 > ioctl(4, BLKGETSIZE64, [2097152]) = 0 > ioctl(4, HDIO_GETGEO, {heads=4, sectors=16, cylinders=64, start=0}) = 0 > fsync(4) = 0 > close(4) = 0 > ... > > Any idea?
Looks like it's coming from that fsync():
sys_fsync do_fsync vfs_fsync_range blkdev_fsync blkdev_issue_flush
I think we need to teach blkdev_issue_flush() to bail out if the bdev is read-only, similar to blkdev_issue_discard(), _write_zeroes(), etc. The question is which error code to use. blkdev_fsync() already skips over EOPNOTSUPP, so it is a (no-so-good) option. Other blkdev_issue_ functions return EPERM.
Thanks,
Ilya
| |