On Tue, 16 Jul 2024 22:19:05 +0300
Nikita Kiryushin wrote:
> On 7/16/24 12:45, Alexey Khoroshilov wrote:
> > Yes, but there is another possible modification: replacement of call to
> > nonseekable_open() by a call to some other function that returns error.
> > Current code is already ready for su
On 7/16/24 12:45, Alexey Khoroshilov wrote:
Yes, but there is another possible modification: replacement of call to
nonseekable_open() by a call to some other function that returns error.
Current code is already ready for such modification.
The change of which function is called would change
On 15.07.2024 16:47, Nikita Kiryushin wrote:
> As nonseekable_open() documentation states:
> "The function is not supposed to ever fail, the only
> reason it returns an 'int' and not 'void' is so that it can be plugged
> directly into file_operations structure."
>
> So it seems, that it will not f
As nonseekable_open() documentation states:
"The function is not supposed to ever fail, the only
reason it returns an 'int' and not 'void' is so that it can be plugged
directly into file_operations structure."
So it seems, that it will not fail anytime as it is not meant to? Otherwise,
there will
On Fri, 12 Jul 2024 23:12:58 +0300
Nikita Kiryushin wrote:
> There is a trace_array_put() in check result for
> nonseekable_open() in tracing_buffers_open(). However,
> it would be never executed as nonseekable_open never fails
> (by design).
>
> Remove the check and associated unreachable code.
There is a trace_array_put() in check result for
nonseekable_open() in tracing_buffers_open(). However,
it would be never executed as nonseekable_open never fails
(by design).
Remove the check and associated unreachable code.
Found by Linux Verification Center (linuxtesting.org) with SVACE.
Fixe
6 matches
Mail list logo
