From: Xianting TIan <xianting.tian@linux.alibaba.com>
To: Daniel Axtens <dja@axtens.net>,
gregkh@linuxfoundation.org, jirislaby@kernel.org,
amit@kernel.org, arnd@arndb.de, osandov@fb.com
Cc: shile.zhang@linux.alibaba.com, linuxppc-dev@lists.ozlabs.org,
linux-kernel@vger.kernel.org,
virtualization@lists.linux-foundation.org
Subject: Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars()
Date: Fri, 20 Aug 2021 16:43:33 +0800 [thread overview]
Message-ID: <6e36640d-b55f-ece4-4cab-437ecec0964a@linux.alibaba.com> (raw)
In-Reply-To: <87pmu8ehkk.fsf@linkitivity.dja.id.au>
在 2021/8/20 下午2:49, Daniel Axtens 写道:
> Xianting Tian <xianting.tian@linux.alibaba.com> writes:
>
>> As well known, hvc backend driver(eg, virtio-console) can register its
>> operations to hvc framework. The operations can contain put_chars(),
>> get_chars() and so on.
>>
>> Some hvc backend may do dma in its operations. eg, put_chars() of
>> virtio-console. But in the code of hvc framework, it may pass DMA
>> incapable memory to put_chars() under a specific configuration, which
>> is explained in commit c4baad5029(virtio-console: avoid DMA from stack):
> We could also run into issues on powerpc where Andrew is working on
> adding vmap-stack but the opal hvc driver assumes that it is passed a
> buffer which is not in vmalloc space but in the linear mapping. So it
> would be good to fix this (or more clearly document what drivers can
> expect).
>
>> 1, c[] is on stack,
>> hvc_console_print():
>> char c[N_OUTBUF] __ALIGNED__;
>> cons_ops[index]->put_chars(vtermnos[index], c, i);
>> 2, ch is on stack,
>> static void hvc_poll_put_char(,,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);
>> }
>>
>> Commit c4baad5029 is just the fix to avoid DMA from stack memory, which
>> is passed to virtio-console by hvc framework in above code. But I think
>> the fix is aggressive, it directly uses kmemdup() to alloc new buffer
>> from kmalloc area and do memcpy no matter the memory is in kmalloc area
>> or not. But most importantly, it should better be fixed in the hvc
>> framework, by changing it to never pass stack memory to the put_chars()
>> function in the first place. Otherwise, we still face the same issue if
>> a new hvc backend using dma added in the future.
>>
>> In this patch, we make 'char out_buf[N_OUTBUF]' and 'chat out_ch' part
>> of 'struct hvc_struct', so both two buf are no longer the stack memory.
>> we can use it in above two cases separately.
>>
>> Introduce another array(cons_outbufs[]) for buffer pointers next to
>> the cons_ops[] and vtermnos[] arrays. With the array, we can easily find
>> the buffer, instead of traversing hp list.
>>
>> With the patch, we can remove the fix c4baad5029.
>>
>> Signed-off-by: Xianting Tian <xianting.tian@linux.alibaba.com>
>> Reviewed-by: Shile Zhang <shile.zhang@linux.alibaba.com>
>> struct hvc_struct {
>> struct tty_port port;
>> spinlock_t lock;
>> int index;
>> int do_wakeup;
>> - char *outbuf;
>> - int outbuf_size;
>> int n_outbuf;
>> uint32_t vtermno;
>> const struct hv_ops *ops;
>> @@ -48,6 +56,10 @@ struct hvc_struct {
>> struct work_struct tty_resize;
>> struct list_head next;
>> unsigned long flags;
>> + char out_ch;
>> + char out_buf[N_OUTBUF] __ALIGNED__;
>> + int outbuf_size;
>> + char outbuf[0] __ALIGNED__;
> I'm trying to understand this patch but I am finding it very difficult
> to understand what the difference between `out_buf` and `outbuf`
> (without the underscore) is supposed to be. `out_buf` is statically
> sized and the size of `outbuf` is supposed to depend on the arguments to
> hvc_alloc(), but I can't quite figure out what the roles of each one are
> and their names are confusingly similiar!
>
> I looked briefly at the older revisions of the series but it didn't make
> things much clearer.
>
> Could you give them clearer names?
thanks for the comments,
It is indeed not easy to understand by the name. I will change it to a
proper name if we have next version patch.
Jiri Slaby is worring about the performance, because we need add two
locks to protect 'out_ch' and 'out_buf' separately, the origin on-stack
buffer is lockless.
I don't know whether this solution can be accepted, just waiting for
Jiri's further commtents.
>
> Also, looking at Documentation/process/deprecated.rst, it looks like
> maybe we want to use a 'flexible array member' instead:
>
> .. note:: If you are using struct_size() on a structure containing a zero-length
> or a one-element array as a trailing array member, please refactor such
> array usage and switch to a `flexible array member
> <#zero-length-and-one-element-arrays>`_ instead.
>
> I think we want:
thanks, we should use [], not [0].
>
>> + char outbuf[] __ALIGNED__;
> Kind regards,
> Daniel
next prev parent reply other threads:[~2021-08-20 8:43 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-18 8:21 [PATCH v8 0/3] make hvc pass dma capable memory to its backend Xianting Tian
2021-08-18 8:21 ` [PATCH v8 1/3] tty: hvc: use correct dma alignment size Xianting Tian
2021-08-18 8:21 ` [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars() Xianting Tian
2021-08-18 11:03 ` kernel test robot
2021-08-18 17:41 ` kernel test robot
2021-08-20 6:49 ` Daniel Axtens
2021-08-20 8:43 ` Xianting TIan [this message]
2021-09-18 12:32 ` Xianting Tian
2021-09-18 12:40 ` Greg KH
2021-09-18 12:47 ` Xianting Tian
2021-08-20 12:34 ` Michael Ellerman
2021-08-18 8:21 ` [PATCH v8 3/3] virtio-console: remove unnecessary kmemdup() Xianting Tian
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=6e36640d-b55f-ece4-4cab-437ecec0964a@linux.alibaba.com \
--to=xianting.tian@linux.alibaba.com \
--cc=amit@kernel.org \
--cc=arnd@arndb.de \
--cc=dja@axtens.net \
--cc=gregkh@linuxfoundation.org \
--cc=jirislaby@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=osandov@fb.com \
--cc=shile.zhang@linux.alibaba.com \
--cc=virtualization@lists.linux-foundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).