public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
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
>>
>

  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