[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241113163145.04c92662@kernel.org>
Date: Wed, 13 Nov 2024 16:31:45 -0800
From: Jakub Kicinski <kuba@...nel.org>
To: Jijie Shao <shaojijie@...wei.com>
Cc: <davem@...emloft.net>, <edumazet@...gle.com>, <pabeni@...hat.com>,
<andrew+netdev@...n.ch>, <horms@...nel.org>, <shenjian15@...wei.com>,
<salil.mehta@...wei.com>, <liuyonglong@...wei.com>,
<wangpeiyang1@...wei.com>, <chenhao418@...wei.com>,
<netdev@...r.kernel.org>, <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH RESEND net 3/7] net: hns3: Resolved the issue that the
debugfs query result is inconsistent.
On Wed, 13 Nov 2024 13:59:32 +0800 Jijie Shao wrote:
> inconsistent:
> Before this modification,
> if the previous read operation is stopped before complete, the buffer is not released.
> In the next read operation (perhaps after a long time), the driver does not read again.
> Instead, the driver returns the bufffer content, which causes outdated data to be obtained.
> As a result, the obtained data is inconsistent with the actual data.
I think the word "stale" would fit the situation better.
> In this patch, ppos is used to determine whether a new read operation is performed.
> If yes, the driver updates the data in the buffer to ensure that the queried data is fresh.
> But, if two processes read the same file at once, The read operation that ends first releases the buffer.
> As a result, the other read operation re-alloc buffer memory. However, because the value of ppos is not 0,
> the data is not updated again. As a result, the queried data is truncated.
>
> This is a bug and I will fix it in the next version.
Let's say two reads are necessary to read the data:
reader A reader B
read()
- alloc
- hns3_dbg_read_cmd()
read()
read()
read(EOF)
- free
read()
- alloc
- hns3_dbg_read_cmd()
read(EOF)
- free
The data for read A is half from one hns3_dbg_read_cmd() and half from
another. Does it not cause any actual inconsistency?
Also, just to be sure, it's not possible to lseek on these files, right?
Powered by blists - more mailing lists