[PATCH] char: xillybus: use stream_open for stream semantics

[PATCH] char: xillybus: use stream_open for stream semantics

[mdshahid03]

From: Mohammad Shahid <mdshahid03@gmail.com>

The Xillybus uses nonseekable_open() in xillybus_open()
for non-seekable channels. However,its read and write
callbacks maintain their own buffer positions and do not
use the file position passed by VFS.

Use stream_open() to mark these channels as streams and
disable unnecessary file position handling,allowing read
and write operations to run concurrently.

This issue is reported by stream_open.cocci script as a
potential deadlock between read and write operations.

Signed-off-by: Mohammad Shahid <mdshahid03@gmail.com>
---
 drivers/char/xillybus/xillybus_core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/char/xillybus/xillybus_core.c b/drivers/char/xillybus/xillybus_core.c
index 7189c6d97e7d..92c526e84572 100644
--- a/drivers/char/xillybus/xillybus_core.c
+++ b/drivers/char/xillybus/xillybus_core.c
@@ -1607,7 +1607,7 @@ static int xillybus_open(struct inode *inode, struct file *filp)
 		mutex_unlock(&channel->wr_mutex);
 
 	if (!rc && (!channel->seekable))
-		return nonseekable_open(inode, filp);
+		return stream_open(inode, filp);
 
 	return rc;
 }
-- 
2.43.0

Re: [PATCH] char: xillybus: use stream_open for stream semantics

[Eli Billauer]

Hello Mohammad,

On 31/10/2026 9:36, mdshahid03@gmail.com wrote:
> Use stream_open() to mark these channels as streams and
> disable unnecessary file position handling,

The difference between stream_open() and nonseekable_open() is that the 
former sets FMODE_STREAM and clears FMODE_ATOMIC_POS. I made a quick 
test run, and FMODE_ATOMIC_POS isn't set in either case. As 
FMODE_ATOMIC_POS is clear, no lock is taken while updating fpos either way.

So in effect, the only difference is that FMODE_STREAM is set. Frankly 
speaking, I'm not sure in what way this matters, if at all.

> allowing read
> and write operations to run concurrently.

I checked that with hardware. There's no problem running read() and 
write() concurrently even before this patch. And I don't see why there 
would be a problem.

It seems like FMODE_STREAM was supposed to replace FMODE_ATOMIC_POS 
somewhere back in 2019 with Linus' commit 0be0ee71816b ("vfs: properly 
and reliably lock f_pos in fdget_pos()"). That is where he urged the 
move towards stream_open(). But then he reverted it with commit 
2be7d348fe92 soon afterwards.

All in all, I don't know what to say about this. Calling stream_open() 
does sound more correct, and nothing broke with this patch. But I'm 
generally unhappy fiddling with code unless it fixes something.

Regards,
    Eli