Message ID | 20231220074725.23211-1-lulie@linux.alibaba.com |
---|---|
State | New |
Headers |
Return-Path: <linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org> Delivered-To: ouuuleilei@gmail.com Received: by 2002:a05:7300:24d3:b0:fb:cd0c:d3e with SMTP id r19csp2478313dyi; Tue, 19 Dec 2023 23:47:48 -0800 (PST) X-Google-Smtp-Source: AGHT+IEWzd2kCBzRM6L90rESK7nVOVCw+LXak7dXVED3Wz9+kH4X4rijfDPR6uLcyj6rg3CENISs X-Received: by 2002:a17:90b:480b:b0:28b:684e:9dfa with SMTP id kn11-20020a17090b480b00b0028b684e9dfamr2267677pjb.61.1703058468249; Tue, 19 Dec 2023 23:47:48 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1703058468; cv=none; d=google.com; s=arc-20160816; b=z4J3YJJz26KU/lP3A93h7wuX6oHw7BhoFiU0Mcv3U+N+I4W38QlVJY7FR4T2/BjqeK o5GkA6+q8PTPvOnDfIKoQlV6aXnT5Vs8zyMlXLnw74FNpnj0nrcLefmIe73lSS0EGEhG Z/7CVdKL+JMLeHuc1wQg66MxmvxqqZZ6Ds/TL2qUsff6kQqNFuSy04bvt8lduKYbff9D ZlhJj7+Zhflt51NboQIF5whY8tEUCcdIlhsDtrcP61IJm3cSl+bLsVS7V8MilR+kuVTY Ux+s+KIXRHUQ6a/6BtPCiAuS2Y5GdU+FtBxAVWxGhxMnCqIIHfgJzgBjUDsUY+0k84Qa jHEQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=content-transfer-encoding:mime-version:list-unsubscribe :list-subscribe:list-id:precedence:message-id:date:subject:cc:to :from; bh=uu1JyQeL6akU0MSsZ9zlniLZtoGKjikh/Cn6JJpcdH8=; fh=5C9bkn7PACVFjOZ4+V8q/03N48OSjlZB21NTpNF6TFo=; b=juk5EmU51vzRtc9pFYcxCRK8GhaS4qkLEAvdqf3gQXPT8zYQenZ4ajdUacQCITM0/Z reuDQRFxmJcRW0aI4l+p/y0hXp7ZzY7a8BqQsv5LS6f9zTijhfColISdBcI+wRFjuOWa c1juqR5UlBadVxhTqg54aY4lYGq4aUlt4hIcEMp4aMrOePpCnI9rx+8A7YJA45ZUzjbo ZwlvyNIhEMODWZ4AlYNGbvpvv3ltdaBi6EKnD4/espxDzQvemkXzuqkYW65+xClJfP3G 9eANj5tKkDVo6BEQc6QrR+4SR7fjDNx4mhUm8N1379dg4tzxPGD7MUe5cgMbslRKRk0S BVUQ== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from sv.mirrors.kernel.org (sv.mirrors.kernel.org. [139.178.88.99]) by mx.google.com with ESMTPS id mu17-20020a17090b389100b0028bbbabf538si2731604pjb.16.2023.12.19.23.47.48 for <ouuuleilei@gmail.com> (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 19 Dec 2023 23:47:48 -0800 (PST) Received-SPF: pass (google.com: domain of linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) client-ip=139.178.88.99; Authentication-Results: mx.google.com; spf=pass (google.com: domain of linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org designates 139.178.88.99 as permitted sender) smtp.mailfrom="linux-kernel+bounces-6512-ouuuleilei=gmail.com@vger.kernel.org"; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=alibaba.com Received: from smtp.subspace.kernel.org (wormhole.subspace.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by sv.mirrors.kernel.org (Postfix) with ESMTPS id 085D4285DC2 for <ouuuleilei@gmail.com>; Wed, 20 Dec 2023 07:47:48 +0000 (UTC) Received: from localhost.localdomain (localhost.localdomain [127.0.0.1]) by smtp.subspace.kernel.org (Postfix) with ESMTP id 23FDB17988; Wed, 20 Dec 2023 07:47:34 +0000 (UTC) X-Original-To: linux-kernel@vger.kernel.org Received: from out30-118.freemail.mail.aliyun.com (out30-118.freemail.mail.aliyun.com [115.124.30.118]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 5BB86168A5 for <linux-kernel@vger.kernel.org>; Wed, 20 Dec 2023 07:47:28 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=linux.alibaba.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=linux.alibaba.com 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=ay29a033018046051;MF=lulie@linux.alibaba.com;NM=1;PH=DS;RN=14;SR=0;TI=SMTPD_---0VytbEip_1703058445; Received: from localhost(mailfrom:lulie@linux.alibaba.com fp:SMTPD_---0VytbEip_1703058445) by smtp.aliyun-inc.com; Wed, 20 Dec 2023 15:47:26 +0800 From: Philo Lu <lulie@linux.alibaba.com> To: linux-kernel@vger.kernel.org Cc: akpm@linux-foudation.org, surenb@google.com, rppt@kernel.org, zhou.kete@h3c.com, zhao_lei1@hoperun.com, kunyu@nfschina.com, zhang.zhengming@h3c.com, gregkh@linuxfoundation.org, xuanzhuo@linux.alibaba.com, dust.li@linux.alibaba.com, alibuda@linux.alibaba.com, guwen@linux.alibaba.com, hengqi@linux.alibaba.com Subject: [RFC PATCH] relay: avoid relay_open_buf inproperly fails in buffer-only mode Date: Wed, 20 Dec 2023 15:47:25 +0800 Message-Id: <20231220074725.23211-1-lulie@linux.alibaba.com> X-Mailer: git-send-email 2.32.0.3.g01195cf9f Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: <linux-kernel.vger.kernel.org> List-Subscribe: <mailto:linux-kernel+subscribe@vger.kernel.org> List-Unsubscribe: <mailto:linux-kernel+unsubscribe@vger.kernel.org> MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-getmail-retrieved-from-mailbox: INBOX X-GMAIL-THRID: 1785786236429111207 X-GMAIL-MSGID: 1785786236429111207 |
Series |
[RFC] relay: avoid relay_open_buf inproperly fails in buffer-only mode
|
|
Commit Message
Philo Lu
Dec. 20, 2023, 7:47 a.m. UTC
In buffer-only mode, relay_open(NULL, NULL, ...) is used to create the
buffer first, where chan->has_base_filename is not set. Though we still
need to call chan->cb->create_buf_file in relay_open_buf() to retrieve
global info for global buffer, the create_buf_file callback should
return NULL. With IS_ERR_OR_NULL() check, relay_open fails because of
the returned NULL dentry, so this patch reverts back to the WARN_ON()
version and add a comment for this behavior.
Here is an example after fix:
```
struct dentry *my_create_buf_file(const char *filename,
struct dentry *parent, umode_t mode,
struct rchan_buf *buf, int *is_global)
{
if (!filename)
return NULL;
return debugfs_create_file(filename, mode, parent, buf,
&relay_file_operations);
}
relay_cb.create_buf_file = my_create_buf_file
relay_chan = relay_open(NULL, NULL,
subbuf_size, subbuf_num,
&relay_cb, NULL);
relay_late_setup_files(relay_chan, filename, parent);
```
But before fix, the create_buf_file callback must be something like:
```
struct dentry *my_create_buf_file(const char *filename,
struct dentry *parent, umode_t mode,
struct rchan_buf *buf, int *is_global)
{
if (!filename)
return ERR_PTR(1); // a valid ptr is necessary for relay_open
return debugfs_create_file(filename, mode, parent, buf,
&relay_file_operations);
}
```
I'm not sure if this revertion proper because it may break existing use
cases. I think we can also remove the WARN_ON check instead.
Fixes: 2c1cf00eeacb ("relay: check return of create_buf_file() properly")
Signed-off-by: Philo Lu <lulie@linux.alibaba.com>
---
kernel/relay.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
--
2.32.0.3.g01195cf9f
Comments
Sorry, the email address of Andrew was wrongly spelled, so CC again. On 2023/12/20 15:47, Philo Lu wrote: > In buffer-only mode, relay_open(NULL, NULL, ...) is used to create the > buffer first, where chan->has_base_filename is not set. Though we still > need to call chan->cb->create_buf_file in relay_open_buf() to retrieve > global info for global buffer, the create_buf_file callback should > return NULL. With IS_ERR_OR_NULL() check, relay_open fails because of > the returned NULL dentry, so this patch reverts back to the WARN_ON() > version and add a comment for this behavior. > > Here is an example after fix: > ``` > struct dentry *my_create_buf_file(const char *filename, > struct dentry *parent, umode_t mode, > struct rchan_buf *buf, int *is_global) > { > if (!filename) > return NULL; > > return debugfs_create_file(filename, mode, parent, buf, > &relay_file_operations); > } > > relay_cb.create_buf_file = my_create_buf_file > relay_chan = relay_open(NULL, NULL, > subbuf_size, subbuf_num, > &relay_cb, NULL); > relay_late_setup_files(relay_chan, filename, parent); > ``` > > But before fix, the create_buf_file callback must be something like: > ``` > struct dentry *my_create_buf_file(const char *filename, > struct dentry *parent, umode_t mode, > struct rchan_buf *buf, int *is_global) > { > if (!filename) > return ERR_PTR(1); // a valid ptr is necessary for relay_open > > return debugfs_create_file(filename, mode, parent, buf, > &relay_file_operations); > } > ``` > > I'm not sure if this revertion proper because it may break existing use > cases. I think we can also remove the WARN_ON check instead. > > Fixes: 2c1cf00eeacb ("relay: check return of create_buf_file() properly") > Signed-off-by: Philo Lu <lulie@linux.alibaba.com> > --- > kernel/relay.c | 3 ++- > 1 file changed, 2 insertions(+), 1 deletion(-) > > diff --git a/kernel/relay.c b/kernel/relay.c > index 83fe0325cde1..0700745447c1 100644 > --- a/kernel/relay.c > +++ b/kernel/relay.c > @@ -395,7 +395,8 @@ static struct rchan_buf *relay_open_buf(struct rchan *chan, unsigned int cpu) > dentry = chan->cb->create_buf_file(NULL, NULL, > S_IRUSR, buf, > &chan->is_global); > - if (IS_ERR_OR_NULL(dentry)) > + /* has_base_filename not set, so dentry should be NULL */ > + if (WARN_ON(dentry)) > goto free_buf; > } > > -- > 2.32.0.3.g01195cf9f
Hi all, Is there any feedback about this patch? Many thanks for your time.
diff --git a/kernel/relay.c b/kernel/relay.c index 83fe0325cde1..0700745447c1 100644 --- a/kernel/relay.c +++ b/kernel/relay.c @@ -395,7 +395,8 @@ static struct rchan_buf *relay_open_buf(struct rchan *chan, unsigned int cpu) dentry = chan->cb->create_buf_file(NULL, NULL, S_IRUSR, buf, &chan->is_global); - if (IS_ERR_OR_NULL(dentry)) + /* has_base_filename not set, so dentry should be NULL */ + if (WARN_ON(dentry)) goto free_buf; }