Fork us on GitHub Follow us on Facebook Follow us on Twitter

Opened 10 years ago

Closed 10 years ago

#366 closed defect (fixed)

Cating a block device node renders the console unusable

Reported by: Jakub Jermář Owned by: Martin Decky
Priority: major Milestone: 0.5.0
Component: helenos/fs/locfs Version: mainline
Keywords: Cc:
Blocker for: Depends on:
See also:

Description (last modified by Jakub Jermář)

As of mainline,1184, the following will render the console unusable:

 # cat /loc/bd/initrd 

This is to some extent expected as the block devices do not implement the file protocol, so open() and read() don't make any sense with them. On the other hand, the system should react to this in a more sensible way and should survive any such attempt.

Change History (2)

comment:1 Changed 10 years ago by Jakub Jermář

Description: modified (diff)

comment:2 Changed 10 years ago by Jakub Jermář

Resolution: fixed
Status: newclosed

Fixed in mainline,1235.

The problem was that the block device responded quite aggressively (i.e. by EHANGUP) to the file system protocol communication attempt from locfs. locfs, btw, lost its only serialized session to the device (the sole underlying phone got slammed) and, which is worse, propagated the return code further to VFS. This resulted in locfs unintentionally slamming one of the VFS phones used for communication with locfs. Since we currently cannot recover from a slammed session / exchange phone, everyone who wanted to communicate with locfs, such as the shells, did not succeed.

I added sanitization of the EHANGUP return code to locfs_read() / locfs_write() because it makes a good sense to stop the aggresive response at that level. VFS should not be punished for someone else who attempts to talk to a device using wrong protocol. VFS and the client shall be returned mere ENOTSUP instead.

If the device can be only listed, but not read or written using locfs, it is debatable whether devices that don't support the file system protocol should be made exposed to it by locfs at all.

Once we have access rights, opening(), reading() and writing() shall be definitely prohibited on nodes like bd/initrd.

Note: See TracTickets for help on using tickets.