Emmanuel Nicolet
720bc31669
ps3disk: use the default segment boundary
Since commit dcebd75592 ("block: use bio_for_each_bvec() to compute
multi-page bvec count"), the kernel will bug_on on the PS3 because
bio_split() is called with sectors == 0:
kernel BUG at block/bio.c:1853!
Oops: Exception in kernel mode, sig: 5 [#1]
BE PAGE_SIZE=4K MMU=Hash PREEMPT SMP NR_CPUS=8 NUMA PS3
Modules linked in: firewire_sbp2 rtc_ps3(+) soundcore ps3_gelic(+) \
ps3rom(+) firewire_core ps3vram(+) usb_common crc_itu_t
CPU: 0 PID: 97 Comm: blkid Not tainted 5.3.0-rc4 #1
NIP: c00000000027d0d0 LR: c00000000027d0b0 CTR: 0000000000000000
REGS: c00000000135ae90 TRAP: 0700 Not tainted (5.3.0-rc4)
MSR: 8000000000028032 <SF,EE,IR,DR,RI> CR: 44008240 XER: 20000000
IRQMASK: 0
GPR00: c000000000289368 c00000000135b120 c00000000084a500 c000000004ff8300
GPR04: 0000000000000c00 c000000004c905e0 c000000004c905e0 000000000000ffff
GPR08: 0000000000000000 0000000000000001 0000000000000000 000000000000ffff
GPR12: 0000000000000000 c0000000008ef000 000000000000003e 0000000000080001
GPR16: 0000000000000100 000000000000ffff 0000000000000000 0000000000000004
GPR20: c00000000062fd7e 0000000000000001 000000000000ffff 0000000000000080
GPR24: c000000000781788 c00000000135b350 0000000000000080 c000000004c905e0
GPR28: c00000000135b348 c000000004ff8300 0000000000000000 c000000004c90000
NIP [c00000000027d0d0] .bio_split+0x28/0xac
LR [c00000000027d0b0] .bio_split+0x8/0xac
Call Trace:
[c00000000135b120] [c00000000027d130] .bio_split+0x88/0xac (unreliable)
[c00000000135b1b0] [c000000000289368] .__blk_queue_split+0x11c/0x53c
[c00000000135b2d0] [c00000000028f614] .blk_mq_make_request+0x80/0x7d4
[c00000000135b3d0] [c000000000283a8c] .generic_make_request+0x118/0x294
[c00000000135b4b0] [c000000000283d34] .submit_bio+0x12c/0x174
[c00000000135b580] [c000000000205a44] .mpage_bio_submit+0x3c/0x4c
[c00000000135b600] [c000000000206184] .mpage_readpages+0xa4/0x184
[c00000000135b750] [c0000000001ff8fc] .blkdev_readpages+0x24/0x38
[c00000000135b7c0] [c0000000001589f0] .read_pages+0x6c/0x1a8
[c00000000135b8b0] [c000000000158c74] .__do_page_cache_readahead+0x118/0x184
[c00000000135b9b0] [c0000000001591a8] .force_page_cache_readahead+0xe4/0xe8
[c00000000135ba50] [c00000000014fc24] .generic_file_read_iter+0x1d8/0x830
[c00000000135bb50] [c0000000001ffadc] .blkdev_read_iter+0x40/0x5c
[c00000000135bbc0] [c0000000001b9e00] .new_sync_read+0x144/0x1a0
[c00000000135bcd0] [c0000000001bc454] .vfs_read+0xa0/0x124
[c00000000135bd70] [c0000000001bc7a4] .ksys_read+0x70/0xd8
[c00000000135be20] [c00000000000a524] system_call+0x5c/0x70
Instruction dump:
7fe3fb78 482e30dc 7c0802a6 482e3085 7c9e2378 f821ff71 7ca42b78 7d3e00d0
7c7d1b78 79290fe0 7cc53378 69290001 <0b090000> 81230028 7bca0020 7929ba62
[ end trace 313fec760f30aa1f ]---
The problem originates from setting the segment boundary of the
request queue to -1UL. This makes get_max_segment_size() return zero
when offset is zero, whatever the max segment size. The test with
BLK_SEG_BOUNDARY_MASK fails and 'mask - (mask & offset) + 1' overflows
to zero in the return statement.
Not setting the segment boundary and using the default
value (BLK_SEG_BOUNDARY_MASK) fixes the problem.
Signed-off-by: Emmanuel Nicolet <emmanuel.nicolet@gmail.com>
Signed-off-by: Geoff Levand <geoff@infradead.org>
Signed-off-by: Michael Ellerman <mpe@ellerman.id.au>
Link: https://lore.kernel.org/r/060a416c43138f45105c0540eff1a45539f7e2fc.1589049250.git.geoff@infradead.org
2020-05-19 00:10:35 +10:00
..
2020-04-10 09:52:15 -07:00
2020-04-01 08:03:28 +02:00
2020-04-16 10:26:52 -06:00
2020-03-25 11:50:48 +01:00
2020-04-07 10:43:41 -07:00
2020-05-19 00:10:35 +10:00
2020-04-03 15:05:35 -07:00
2020-04-10 17:57:48 -07:00
2020-04-13 12:20:07 -07:00
2020-04-05 09:24:58 +02:00
2020-04-06 10:14:39 -07:00
2020-04-30 12:35:26 +10:00
2020-04-20 16:53:14 +10:00
2020-04-02 19:15:03 -07:00
2020-03-25 08:35:03 +09:00
2020-04-10 15:36:22 -07:00
2020-04-08 09:14:34 +10:00
2020-03-30 16:40:08 -07:00
2020-03-25 11:50:48 +01:00
2020-04-03 13:22:40 -07:00
2020-04-14 08:32:15 +02:00
2020-04-04 10:27:00 -07:00
2020-04-16 15:40:02 +10:00
2020-04-01 15:18:42 -07:00
2020-04-14 11:58:04 -07:00
2020-04-18 10:13:07 -07:00
2020-03-25 22:30:46 -07:00
2020-03-24 13:45:24 +01:00
2020-04-15 18:27:31 +02:00
2020-03-29 10:35:50 +02:00
2020-04-04 18:07:59 -07:00
2020-03-30 16:40:08 -07:00
2020-04-08 21:25:49 -07:00
2020-04-01 18:18:18 -07:00
2020-04-07 20:20:12 -07:00
2020-03-27 11:33:27 +01:00
2020-04-17 08:59:55 +01:00
2020-04-16 13:52:31 -07:00
2020-04-06 23:12:08 +02:00
2020-03-30 11:43:51 -07:00
2020-05-15 11:58:56 +10:00
2020-04-08 21:03:40 -07:00
2020-03-30 15:05:01 -07:00
2020-04-03 15:05:35 -07:00
2020-03-26 22:40:47 -04:00
2020-03-30 07:35:28 +01:00
2020-04-08 10:51:53 -07:00
2020-03-31 16:13:09 -07:00
2020-03-24 13:42:44 +01:00
2020-04-09 22:00:13 +02:00
2020-05-19 00:10:35 +10:00
2020-03-25 18:58:11 -07:00
2020-04-03 14:25:02 -07:00
2020-04-08 21:03:40 -07:00
2020-04-10 10:06:54 -07:00
2020-03-25 19:23:49 +01:00
2020-04-17 08:31:34 -05:00
2020-04-13 16:14:55 +05:30
2020-04-05 22:05:23 +02:00
2020-04-08 11:00:00 -07:00
2020-03-31 18:48:22 +02:00
2020-03-31 10:05:01 -07:00
2020-04-03 14:25:02 -07:00
2020-04-04 10:27:00 -07:00
2020-04-16 15:00:57 -07:00
2020-04-10 15:36:22 -07:00
2020-03-30 16:40:08 -07:00
2020-05-19 00:10:35 +10:00
2020-03-30 11:16:38 -07:00
2020-04-03 21:41:42 +02:00
2020-03-30 14:58:26 -07:00
2020-04-03 10:47:21 -07:00
2020-04-07 19:48:52 -07:00
2020-04-17 08:05:27 -06:00
2020-04-13 21:58:48 -04:00
2020-04-09 10:51:30 -07:00
2020-04-03 13:22:40 -07:00
2020-04-02 15:50:04 -07:00
2020-04-10 15:36:21 -07:00
2020-04-13 14:03:20 -04:00
2020-04-03 15:05:35 -07:00
2020-04-07 20:00:16 -07:00
2020-04-05 11:12:59 -07:00
2020-04-02 17:03:53 -07:00
2020-04-02 10:41:40 -04:00
2020-05-11 23:15:15 +10:00
2020-04-02 10:41:40 -04:00
2020-05-11 23:15:15 +10:00
2020-04-08 10:51:53 -07:00
2020-04-08 11:18:38 +02:00
2020-04-17 10:35:17 -07:00
2020-04-03 13:12:26 -07:00
2020-04-08 10:51:53 -07:00
2020-04-08 10:51:53 -07:00