Messages in this thread Patch in this message | | | Subject | Re: [PATCH] virtio-console: avoid DMA from vmalloc area | From | Xianting Tian <> | Date | Wed, 28 Jul 2021 10:58:26 +0800 |
| |
Arnd, thanks for your quick reply,
As we know put_chars() of virtio-console is registered to hvc framework. I go throughed the code, actually there are totally three places that put_chars() is called in hvc driver, but only 1 has issue which is fixed by commit c4baad5029. So I think the scenario that the buf is from "ioremap(), kmap_atomic() , fixmap, loadable module" doesn't exist for virtio-console. If there is something wrong about above description, please correct me, thanks.
Three places that put_chars() is called in hvc driver: 1, it is on stack buf, it is not ok for dma hvc_console_print(): char c[N_OUTBUF] __ALIGNED__; cons_ops[index]->put_chars(vtermnos[index], c, i);
2, just one byte, no issue for dma static void hvc_poll_put_char(struct tty_driver *driver, int line, char ch) { struct tty_struct *tty = driver->ttys[0]; struct hvc_struct *hp = tty->driver_data; int n;
do { n = hp->ops->put_chars(hp->vtermno, &ch, 1); } while (n <= 0); } 3, hp->outbuf is allocated in hvc_alloc() via kzalloc(), no issue for dma static int hvc_push(struct hvc_struct *hp) { int n;
n = hp->ops->put_chars(hp->vtermno, hp->outbuf, hp->n_outbuf); … }
在 2021/7/27 下午9:18, Arnd Bergmann 写道: > On Tue, Jul 27, 2021 at 3:13 PM Xianting Tian > <xianting.tian@linux.alibaba.com> wrote: >> @@ -1127,13 +1128,18 @@ static int put_chars(u32 vtermno, const char *buf, int count) >> if (!port) >> return -EPIPE; >> >> - data = kmemdup(buf, count, GFP_ATOMIC); >> - if (!data) >> - return -ENOMEM; >> + if (is_vmalloc_addr(buf)) { >> + data = kmemdup(buf, count, GFP_ATOMIC); > What about buffers in .data? If those are in a loadable module, I guess you have > the same problem as with vmalloc() and vmap(). > > is_vmalloc_or_module_addr() would take care of both, not sure if there are > other examples that don't work. In theory it could be ioremap(), kmap_atomic() > or fixmap as well, but those seem less likely to matter here. > > Arnd
| |