From: Shiju Jose <shiju.jose@huawei.com>
To: Steven Rostedt <rostedt@goodmis.org>
Cc: "dave.jiang@intel.com" <dave.jiang@intel.com>,
"dan.j.williams@intel.com" <dan.j.williams@intel.com>,
Jonathan Cameron <jonathan.cameron@huawei.com>,
"alison.schofield@intel.com" <alison.schofield@intel.com>,
"nifan.cxl@gmail.com" <nifan.cxl@gmail.com>,
"vishal.l.verma@intel.com" <vishal.l.verma@intel.com>,
"ira.weiny@intel.com" <ira.weiny@intel.com>,
"dave@stgolabs.net" <dave@stgolabs.net>,
"linux-cxl@vger.kernel.org" <linux-cxl@vger.kernel.org>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
Linuxarm <linuxarm@huawei.com>,
tanxiaofei <tanxiaofei@huawei.com>,
"Zengtao (B)" <prime.zeng@hisilicon.com>
Subject: RE: [PATCH v4 3/6] cxl/events: Update General Media Event Record to CXL spec rev 3.1
Date: Tue, 3 Dec 2024 15:21:44 +0000 [thread overview]
Message-ID: <e4187844aed14d4897f0071dcfce7455@huawei.com> (raw)
In-Reply-To: <3c9808a694d242cab35bab67602edebf@huawei.com>
>-----Original Message-----
>From: Shiju Jose <shiju.jose@huawei.com>
>Sent: 29 November 2024 13:23
>To: Shiju Jose <shiju.jose@huawei.com>; Steven Rostedt <rostedt@goodmis.org>
>Cc: dave.jiang@intel.com; dan.j.williams@intel.com; Jonathan Cameron
><jonathan.cameron@huawei.com>; alison.schofield@intel.com;
>nifan.cxl@gmail.com; vishal.l.verma@intel.com; ira.weiny@intel.com;
>dave@stgolabs.net; linux-cxl@vger.kernel.org; linux-kernel@vger.kernel.org;
>Linuxarm <linuxarm@huawei.com>; tanxiaofei <tanxiaofei@huawei.com>;
>Zengtao (B) <prime.zeng@hisilicon.com>
>Subject: RE: [PATCH v4 3/6] cxl/events: Update General Media Event Record to
>CXL spec rev 3.1
>
>>-----Original Message-----
>>From: Shiju Jose <shiju.jose@huawei.com>
>>Sent: 28 November 2024 10:02
>>To: Steven Rostedt <rostedt@goodmis.org>
>>Cc: dave.jiang@intel.com; dan.j.williams@intel.com; Jonathan Cameron
>><jonathan.cameron@huawei.com>; alison.schofield@intel.com;
>>nifan.cxl@gmail.com; vishal.l.verma@intel.com; ira.weiny@intel.com;
>>dave@stgolabs.net; linux-cxl@vger.kernel.org;
>>linux-kernel@vger.kernel.org; Linuxarm <linuxarm@huawei.com>;
>>tanxiaofei <tanxiaofei@huawei.com>; Zengtao (B)
>><prime.zeng@hisilicon.com>
>>Subject: RE: [PATCH v4 3/6] cxl/events: Update General Media Event
>>Record to CXL spec rev 3.1
>>
[...]
>
>Hi Steve,
>
>I debug this case and please find the info, 1. rasdaemon : read() from format
>file return around 1/3rd of the
> actual data in the file only when the total size of the format's file
> is above 4K bytes (page size), For example, in this case, the total size was 4512
>bytes,
> but read only 1674 bytes.
> This partial data resulted tep_parse_event() in libtraceevent failed internally
>in the parse_format()
> and since __parse_event() does not return error when parse_format() fail,
> thus initialization of the event does not fail.
>
> The following solution in rasdaemon solved the issue,
> (provided if no other fix for the above issue with read()),
> 1. read() and accumulate content of format file until EOF reached.
> 2. Increased the buffer size from 4K bytes to 8K bytes.
> 3. May be __parse_event() in libtraceevent and thus tep_parse_event()
>return error
> when parse_format() fail so that the initialization would fail if the input
>data is
> corrupted or partial?
Hi Steve,
Identified the root cause of this issue in the kernel:
The read() function for the event's format file calls seq_read() and seq_read_iter() in the kernel,
which allocates a buffer of PAGE_SIZE (4 KB) for sequential reads. However, it
detects an overflow in the following marked call (seq_has_overflowed()) and
returns with partial data read.
=====================================
File : https://elixir.bootlin.com/linux/v6.13-rc1/source/fs/seq_file.c
ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
{
struct seq_file *m = iocb->ki_filp->private_data;
[...]
/* grab buffer if we didn't have one */
if (!m->buf) {
---------> m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
if (!m->buf)
goto Enomem;
}
// something left in the buffer - copy it out first
[...]
// get a non-empty record in the buffer
m->from = 0;
p = m->op->start(m, &m->index);
while (1) {
err = PTR_ERR(p);
if (!p || IS_ERR(p)) // EOF or an error
break;
[...]
}
// EOF or an error
m->op->stop(m, p);
m->count = 0;
goto Done;
Fill:
// one non-empty record is in the buffer; if they want more,
// try to fit more in, but in any case we need to advance
// the iterator once for every record shown.
while (1) {
size_t offs = m->count;
loff_t pos = m->index;
[...]
err = m->op->show(m, p);
if (err > 0) { // ->show() says "skip it"
m->count = offs;
----------> } else if (err || seq_has_overflowed(m)) {
m->count = offs;
break;
}
}
m->op->stop(m, p);
n = copy_to_iter(m->buf, m->count, iter);
copied += n;
m->count -= n;
m->from = n;
Done:
[...]
goto Done;
}
EXPORT_SYMBOL(seq_read_iter);
====================================
The following fix in the kernel's seq_read_iter() allows userspace to read the
content of the format file etc in one go if the requested size exceeds PAGE_SIZE,
and resolves the parsing error caused by the event's format file exceeding PAGE_SIZE.
====================================
diff --git a/fs/seq_file.c b/fs/seq_file.c index e676c8b0cf5d..f1f1af180562 100644
--- a/fs/seq_file.c
+++ b/fs/seq_file.c
@@ -207,7 +207,11 @@ ssize_t seq_read_iter(struct kiocb *iocb, struct iov_iter *iter)
/* grab buffer if we didn't have one */
if (!m->buf) {
- m->buf = seq_buf_alloc(m->size = PAGE_SIZE);
+ if (iter->count % PAGE_SIZE)
+ m->size = ((iter->count / PAGE_SIZE) + 1) * PAGE_SIZE;
+ else
+ m->size = (iter->count / PAGE_SIZE) * PAGE_SIZE;
+ m->buf = seq_buf_alloc(m->size);
if (!m->buf)
goto Enomem;
}
====================================
Can you suggest which fix is the right one, kernel based fix or rasdaemon based fix (which
mentioned in the previous email)?
Thanks,
Shiju
>>
>>>
>>>>
>>>> I've also attached another format file,
>>>> "format_cxl_general_media_v3.1_full",
>>>> which contains the complete TP_printk() intended.
>>>
[...]
>>>-- Steve
>>
>
next prev parent reply other threads:[~2024-12-03 15:41 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-11-20 9:37 [PATCH v4 0/6] Update Event Records to CXL spec rev 3.1 shiju.jose
2024-11-20 9:37 ` [PATCH v4 1/6] cxl/events: Update Common Event Record " shiju.jose
2024-11-26 17:27 ` Fan Ni
2024-11-27 10:15 ` Shiju Jose
2024-11-20 9:37 ` [PATCH v4 2/6] cxl/events: Add Component Identifier formatting for " shiju.jose
2024-11-20 9:37 ` [PATCH v4 3/6] cxl/events: Update General Media Event Record to " shiju.jose
2024-11-26 11:51 ` Shiju Jose
2024-11-26 17:02 ` Steven Rostedt
2024-11-27 10:12 ` Shiju Jose
2024-11-27 15:41 ` Steven Rostedt
2024-11-27 18:20 ` Shiju Jose
2024-11-27 18:34 ` Steven Rostedt
2024-11-28 10:01 ` Shiju Jose
2024-11-29 13:22 ` Shiju Jose
2024-12-03 15:21 ` Shiju Jose [this message]
2024-12-04 11:35 ` Shiju Jose
2024-11-20 9:37 ` [PATCH v4 4/6] cxl/events: Update DRAM " shiju.jose
2024-11-20 9:37 ` [PATCH v4 5/6] cxl/events: Update Memory Module " shiju.jose
2024-11-20 9:37 ` [PATCH v4 6/6] cxl/test: Update test code for event records " shiju.jose
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=e4187844aed14d4897f0071dcfce7455@huawei.com \
--to=shiju.jose@huawei.com \
--cc=alison.schofield@intel.com \
--cc=dan.j.williams@intel.com \
--cc=dave.jiang@intel.com \
--cc=dave@stgolabs.net \
--cc=ira.weiny@intel.com \
--cc=jonathan.cameron@huawei.com \
--cc=linux-cxl@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linuxarm@huawei.com \
--cc=nifan.cxl@gmail.com \
--cc=prime.zeng@hisilicon.com \
--cc=rostedt@goodmis.org \
--cc=tanxiaofei@huawei.com \
--cc=vishal.l.verma@intel.com \
/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