Received: by 2002:a05:6a10:1d13:0:0:0:0 with SMTP id pp19csp1270966pxb; Fri, 20 Aug 2021 01:44:29 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxR6tgS82wX4L+Hy0duI76HDOJO5XuM6h9YLEM9v+yAYsm+qxnYQP33cueME7i1BHS/0So2 X-Received: by 2002:a05:6602:218d:: with SMTP id b13mr15141153iob.143.1629449069362; Fri, 20 Aug 2021 01:44:29 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1629449069; cv=none; d=google.com; s=arc-20160816; b=yrOlmtEoIOgDHHbMopCu5etTB5i6KGh4N9s1N3TWVORL1RU8DRzWr5gF4t5yl1DKfQ cRVs/lMiPou2xhy7LLzMwG/crg9HLvKYLAk8s3XkNIlPTy2/VKXUo/InyMQ/T+Y5pcAD xKoY7L7nNGd5aRAqO6eSRglCK99ny7oVB4F4vI0Qq43e2u5WMtgokmRKc6CbOIRnlczS 623PbL90Gpn7mwiTqXOW+4BNaQA38DYuwTAdrjJRemWy/Jhm5RffGaIhfMNXeeQ4+TUk n7h8pfB2Nsdmku1tF6BfIo7w1ApFaLc1j0vHs4ebGZfsragQC51e0TYdly4G5cG8gEgE qTsQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to :mime-version:user-agent:date:message-id:from:references:cc:to :subject; bh=1A3p4HVkvfHT++AzMJXJNtrUu0kqI9T3SMmOv90jQms=; b=d5ExIO6Cz3NvsbBpzwwlsYceMRnblkkH/Tqi1N49lSplxeX1mF7DQH0FWUJYk0F3+Q fYF5o076fTMBpfctFiFwSeryRkCaHjzrxjDkTOzoQ5P1jecR01gVS0XDakC9bpcqvxYh cjBPOBNO0xjI6DPntTemEPCKsYoIF7BfJW5bxK1Of8tnKbBuHelyLxJ7R4Jchv9KGqiX W08abwcIYHRzcD9OQQY24DU+06jLFRgepshY/ltWnJRz/j5f/gyO3u7O9OrJjWaahiCw dkaR+5I811QsYOhS8nWZ859tjRh7Jnp11s5PmGJqOtuSghgFg7mG6i1EIiiW4yXSPI/Q zetQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k14si5703263ilo.4.2021.08.20.01.44.17; Fri, 20 Aug 2021 01:44:29 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S230418AbhHTIoO (ORCPT + 99 others); Fri, 20 Aug 2021 04:44:14 -0400 Received: from out30-130.freemail.mail.aliyun.com ([115.124.30.130]:59451 "EHLO out30-130.freemail.mail.aliyun.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229586AbhHTIoN (ORCPT ); Fri, 20 Aug 2021 04:44:13 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R151e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=e01e04400;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=10;SR=0;TI=SMTPD_---0UkJj0o4_1629449013; Received: from B-LB6YLVDL-0141.local(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0UkJj0o4_1629449013) by smtp.aliyun-inc.com(127.0.0.1); Fri, 20 Aug 2021 16:43:33 +0800 Subject: Re: [PATCH v8 2/3] tty: hvc: pass DMA capable memory to put_chars() To: Daniel Axtens , 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 References: <20210818082122.166881-1-xianting.tian@linux.alibaba.com> <20210818082122.166881-3-xianting.tian@linux.alibaba.com> <87pmu8ehkk.fsf@linkitivity.dja.id.au> From: Xianting TIan Message-ID: <6e36640d-b55f-ece4-4cab-437ecec0964a@linux.alibaba.com> Date: Fri, 20 Aug 2021 16:43:33 +0800 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:78.0) Gecko/20100101 Thunderbird/78.10.1 MIME-Version: 1.0 In-Reply-To: <87pmu8ehkk.fsf@linkitivity.dja.id.au> Content-Type: text/plain; charset=gbk; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org ?? 2021/8/20 ????2:49, Daniel Axtens ะด??: > Xianting Tian 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 >> Reviewed-by: Shile Zhang >> 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