Cating a block device node renders the console unusable

[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.

[Jakub Jermář]

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.