Exceeding data transfer limit sometimes makes server block indefinitely.

[Jiří Zárevúcky]

Encountered when asking EXT4 for a big data read (> DATA_XFER_LIMIT). The client side receives error properly, but server side blocks even after the exchange was closed.

At a glance, I don't see any problem in EXT4 code, which makes me suspect problem in the kernel.

[Jakub Jermář]

Can you apply the ipc <task_id> kconsole command on the hung task and take a screenshot?

[Jiří Zárevúcky]

I was mistaken. The call actually never reaches EXT4 server. In the screenshot, there are debug printouts at the beginning of libfs handler, which isn't called at all. It just hangs on async_data_read_forward().

[Jakub Jermář]

I think this is because the kernel refused to make the IPC_M_DATA_READ call with transfer size greater than DATA_XFER_LIMIT and returned an error.

The app detected the error and is now waiting in libc's read() for the reply to the initial VFS_IN_READ.

VFS, on the other hand, is waiting in async_data_read_forward() (called from vfs_rdwr()) for the IPC_M_DATA_READ call.

Neither can continue.

[Jakub Jermář]

I am closing this as vfs_read_short() will now no longer wait for the answer to the first message, but will rather forget it. Also the transfer size is checked by vfs_read_short().

Also note that now there is a mechanism (answer→flags & IPC_CALL_AUTO_REPLY) that allows the client to learn about an IPC error which was auto-replied by the kernel (and so the server never saw it).