From: Ovidiu Panait <ovidiu.panait.oss@gmail.com>
To: Greg KH <gregkh@linuxfoundation.org>
Cc: gshahrouzi@gmail.com, linux-kernel@vger.kernel.org
Subject: Re: [PATCH] staging: axis-fifo: fix maximum TX packet length check
Date: Sun, 17 Aug 2025 19:08:59 +0300 [thread overview]
Message-ID: <2a7e9a24-38f8-4be5-a820-c19e4aeaac7f@gmail.com> (raw)
In-Reply-To: <2025081755-actress-flogging-4261@gregkh>
On 8/17/25 2:12 PM, Greg KH wrote:
> On Sat, Aug 02, 2025 at 11:59:43PM +0300, Ovidiu Panait wrote:
>> Since commit 2ca34b508774 ("staging: axis-fifo: Correct handling of
>> tx_fifo_depth for size validation"), write() operations with packets
>> larger than 'tx_fifo_depth - 4' words are no longer rejected with -EINVAL.
>>
>> Fortunately, the packets are not actually getting transmitted to hardware,
>> otherwise they would be raising a 'Transmit Packet Overrun Error'
>> interrupt, which requires a reset of the TX circuit to recover from.
>>
>> Instead, the request times out inside wait_event_interruptible_timeout()
>> and always returns -EAGAIN, since the wake up condition can never be true
>> for these packets. But still, they unnecessarily block other tasks from
>> writing to the FIFO and the EAGAIN return code signals userspace to retry
>> the write() call, even though it will always fail and time out.
>>
>> According to the AXI4-Stream FIFO reference manual (PG080), the maximum
>> valid packet length is 'tx_fifo_depth - 4' words, so attempting to send
>> larger packets is invalid and should not be happening in the first place:
>>
>>> The maximum packet that can be transmitted is limited by the size of
>>> the FIFO, which is (C_TX_FIFO_DEPTH–4)*(data interface width/8) bytes.
>>
>> Therefore, bring back the old behavior and outright reject packets larger
>> than 'tx_fifo_depth - 4' with -EINVAL. Add a comment to explain why the
>> check is necessary. The dev_err() message was removed to avoid cluttering
>> the dmesg log if an invalid packet is received from userspace.
>>
>> Fixes: 2ca34b508774 ("staging: axis-fifo: Correct handling of tx_fifo_depth for size validation")
>> Signed-off-by: Ovidiu Panait <ovidiu.panait.oss@gmail.com>
>
> Any specific reason you didn't cc: the staging list? Or add cc: stable
> to this commit?
>
It was a copy-paste error. I'll resend this with the cc: stable tag
included.
Thanks,
Ovidiu
> thanks,
>
> greg k-h
prev parent reply other threads:[~2025-08-17 16:09 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-08-02 20:59 Ovidiu Panait
2025-08-17 11:12 ` Greg KH
2025-08-17 16:08 ` Ovidiu Panait [this message]
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=2a7e9a24-38f8-4be5-a820-c19e4aeaac7f@gmail.com \
--to=ovidiu.panait.oss@gmail.com \
--cc=gregkh@linuxfoundation.org \
--cc=gshahrouzi@gmail.com \
--cc=linux-kernel@vger.kernel.org \
/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
all inboxes | Powered by JetHome®