Received: by 2002:a05:6a10:c7c6:0:0:0:0 with SMTP id h6csp1456999pxy; Mon, 2 Aug 2021 01:57:47 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxHSdLTWg/vqZHJmBpfw/hgOtpaPuDZ/jIhgpomTaxbifFQ0vLTFr6sit8iR6mT8fOk28Uc X-Received: by 2002:a17:907:6218:: with SMTP id ms24mr14664646ejc.367.1627894667239; Mon, 02 Aug 2021 01:57:47 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1627894667; cv=none; d=google.com; s=arc-20160816; b=vbKcZjYP3Spf+jYKzIR/4WyWE7p2pCGlL9uM+U8FRYRN+qFIFM117JskOpUZGg7GvP TaYUQdPXfxdZkB0b8mBmyyV396Dn/D9FkpX1GEIH256OpYBs2M3SwSJWh93C6f0zocuZ uRLtZ33HKJmBHuXZwLgQHPDKI9bHjnaQV15hdIvntDRNccIM3o2InbioFZtBnUfexOcQ hS9HS4WsTESiBuI4/hkq2myveTRTV4wM0tE/uYMJ/me++Eh8WKeSnSL3RjW/m1KiIgRz UtFgNt4gdJAMddCxl5PUgEmSZZb4CmaWt1i80mkA9iZoSDnJmsyqbOxehxFKg0M3/4Ll UCVQ== 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=f0Kyf6ecmT2NttZUWZTZE+To7gUUYE6e15LgjwFejPA=; b=fOiHOZCDdkNXpZBqenfRncmB1qBaYKLwGE6MvgF+rMY/NHqYgnYQlE8DtPvzODQdH1 SXqtW3ipE8MA7wV3Xa+ILOoN5y7HDG7RzNZoE9GsIad7A+8OMYbBSyiU7Qf/SAyiPEmL G/nv5m+4MzvIA62M3dEBs7N4MYVLGURTvMD+kQ+E81cLpnf4SnDquG5y0pkMin/Vz4Py DoNMC+fFBhyT8Isl75JVTNSgEulnqFK8KFFtkaK7AXZeYOi47Zr9GOCykdx9i1PhHF6h 7pfz2ZATqTT/Ooy4tw2H1mTJC6C4h35JZh5vbYjprg/KqAM5MuAax569LmViKmwuvtaT 7KKw== 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 f7si9207754edr.319.2021.08.02.01.57.24; Mon, 02 Aug 2021 01:57:47 -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 S232809AbhHBI4P (ORCPT + 99 others); Mon, 2 Aug 2021 04:56:15 -0400 Received: from out4436.biz.mail.alibaba.com ([47.88.44.36]:6470 "EHLO out4436.biz.mail.alibaba.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S232711AbhHBI4P (ORCPT ); Mon, 2 Aug 2021 04:56:15 -0400 X-Alimail-AntiSpam: AC=PASS;BC=-1|-1;BR=01201311R171e4;CH=green;DM=||false|;DS=||;FP=0|-1|-1|-1|0|-1|-1|-1;HT=alimailimapcm10staff010182156082;MF=xianting.tian@linux.alibaba.com;NM=1;PH=DS;RN=8;SR=0;TI=SMTPD_---0UhkYtRe_1627894553; Received: from B-LB6YLVDL-0141.local(mailfrom:xianting.tian@linux.alibaba.com fp:SMTPD_---0UhkYtRe_1627894553) by smtp.aliyun-inc.com(127.0.0.1); Mon, 02 Aug 2021 16:55:54 +0800 Subject: Re: [PATCH 2/2] virtio-console: remove unnecessary kmemdup() To: Jiri Slaby , gregkh@linuxfoundation.org, amit@kernel.org, arnd@arndb.de Cc: linuxppc-dev@lists.ozlabs.org, virtualization@lists.linux-foundation.org, linux-kernel@vger.kernel.org, osandov@fb.com References: <20210801051655.79048-1-xianting.tian@linux.alibaba.com> <5ad81a0e-fbb2-a849-6db7-f5718633d282@linux.alibaba.com> From: Xianting Tian Message-ID: <61a6d459-338b-7e77-c78e-3a069bbfd690@linux.alibaba.com> Date: Mon, 2 Aug 2021 16:55:53 +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: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 在 2021/8/2 下午4:40, Jiri Slaby 写道: > On 02. 08. 21, 10:32, Xianting Tian wrote: >> >> 在 2021/8/2 下午3:25, Jiri Slaby 写道: >>> Hi, >>> >>> why is this 2/2? I seem (Lore neither) to find 1/2. >> You didn't receive 1/2? >> [PATCH 1/2] tty: hvc: pass DMA capable memory to put_chars() >> https://lkml.org/lkml/2021/8/1/8 > > Oh, I did, but it's not properly threaded. PLease fix your setup. Ok, thanks > >>> On 01. 08. 21, 7:16, Xianting Tian wrote: >>>> hvc framework will never pass stack memory to the put_chars() >>>> function, >>> >>> Am I blind or missing something? >>> >>> hvc_console_print(...) >>> { >>>   char c[N_OUTBUF] >>> ... >>>   cons_ops[index]->put_chars(vtermnos[index], c, i); >>> >>> The same here: >>> >>> hvc_poll_put_char(..., char ch) >>> { >>> ... >>>    n = hp->ops->put_chars(hp->vtermno, &ch, 1); >>> >>> AFAICS both of them *pass* a pointer to stack variable. >> >> yes, I discussed the issue with Arnd before in below thread, you can >> get the history, thanks >> >> https://lkml.org/lkml/2021/7/27/494 >> > > So is this a v2? You should have noted that. And what changed from v1 > too. I think yes, I should mentioned it in this patch, sorry for that:( > >>>> So the calling of kmemdup() is unnecessary, remove it. >>>> >>>> Fixes: c4baad5029 ("virtio-console: avoid DMA from stack") >>> >>> This patch doesn't "Fix" -- it reverts the commit. You should've >>> CCed the author too. >> >> yes, we discussed ther issue in above thread, which we CCed the author. > > I don't see any input from the author? > > > Anyway, 1/2 does not even build, so you will send v3 with all the > above fixed, hopefully. yes, I will send v3 patch after I figured out a better solution based on Arnd's comments for the patch '1/2'. Do you have any other suggestion for the solution? thanks. > > thanks,