This repository has been archived by the owner on Apr 13, 2019. It is now read-only.
Any plan for upstreaming DMA32? #151
Assignees
Comments
|
Hi! I'm not the risc-v linux port maintainer. @palmer-dabbelt @nvpw What do you think? |
|
You can submit the patch to [email protected], based on Linus' latest master. There aren't any concrete plans for anyone at SiFive to do this, but it is necessary to enable a large set of devices so it'll have to get done at some point. If you're happy doing it that would be great, our development is all upstream now so that's the best way to get involved. |
atishp04
pushed a commit
to atishp04/riscv-linux
that referenced
this issue
Feb 6, 2019
bd_set_size() updates also block device's block size. This is somewhat unexpected from its name and at this point, only blkdev_open() uses this functionality. Furthermore, this can result in changing block size under a filesystem mounted on a loop device which leads to livelocks inside __getblk_gfp() like: Sending NMI from CPU 0 to CPUs 1: NMI backtrace for cpu 1 CPU: 1 PID: 10863 Comm: syz-executor0 Not tainted 4.18.0-rc5+ riscvarchive#151 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 RIP: 0010:__sanitizer_cov_trace_pc+0x3f/0x50 kernel/kcov.c:106 ... Call Trace: init_page_buffers+0x3e2/0x530 fs/buffer.c:904 grow_dev_page fs/buffer.c:947 [inline] grow_buffers fs/buffer.c:1009 [inline] __getblk_slow fs/buffer.c:1036 [inline] __getblk_gfp+0x906/0xb10 fs/buffer.c:1313 __bread_gfp+0x2d/0x310 fs/buffer.c:1347 sb_bread include/linux/buffer_head.h:307 [inline] fat12_ent_bread+0x14e/0x3d0 fs/fat/fatent.c:75 fat_ent_read_block fs/fat/fatent.c:441 [inline] fat_alloc_clusters+0x8ce/0x16e0 fs/fat/fatent.c:489 fat_add_cluster+0x7a/0x150 fs/fat/inode.c:101 __fat_get_block fs/fat/inode.c:148 [inline] ... Trivial reproducer for the problem looks like: truncate -s 1G /tmp/image losetup /dev/loop0 /tmp/image mkfs.ext4 -b 1024 /dev/loop0 mount -t ext4 /dev/loop0 /mnt losetup -c /dev/loop0 l /mnt Fix the problem by moving initialization of a block device block size into a separate function and call it when needed. Thanks to Tetsuo Handa <[email protected]> for help with debugging the problem. Reported-by: [email protected] Signed-off-by: Jan Kara <[email protected]> Signed-off-by: Jens Axboe <[email protected]>
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Hi, @terpstra
I'm currently trying to submit a patch for adding contiguous memory allocator (CMA) to RISC-V linux. I've already wrote some bit of code and tested it:
dayeol@16941d1
I believe this should be implemented in
arch/riscv/mm/dma.cin order to be migrated with architecture's dma allocators such asdma_alloc_coherent.But I found that the file only exists in
riscv-linux-4.15branch, and has not been upstreamed yet.Do you have any plans to upstream
dma.c?Can you let me know how and where can I submit this patch, or if I'm missing something?
Thank you in advance!
The text was updated successfully, but these errors were encountered: