Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
MIME-Version: 1.0
References: <7f57199f45df7212fdbba0bd1e78142a@agner.ch>
In-Reply-To: <7f57199f45df7212fdbba0bd1e78142a@agner.ch>
From:   Ilya Dryomov <idryomov@gmail.com>
Date:   Tue, 14 Aug 2018 17:24:03 +0200
Message-ID: <CAOi1vP9Y5Nrr7kVo5GAKnS4casbXPa+LSgY=si=mAW6OHs7-BA@mail.gmail.com>
Subject: Re: Warning when using eMMC and partprobe: generic_make_request:
 Trying to write to read-only block-device
To:     stefan@agner.ch
Cc:     Jens Axboe <axboe@kernel.dk>, Sagi Grimberg <sagi@grimberg.me>,
        Linus Torvalds <torvalds@linux-foundation.org>,
        linux-arm-kernel@lists.infradead.org, linux-kernel@vger.kernel.org
Content-Type: text/plain; charset="UTF-8"
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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