----- Ursprüngliche Mail ----- > Von: "Miquel Raynal" <miquel.raynal@xxxxxxxxxxx> > All being well, it was reported that JFFS2 was showing a splat when > interrupting a transfer. After some more debate about whether JFFS2 > should be fixed and how, it was also pointed out that the whole > consistency of the filesystem in case of parallel I/O would be > compromised. Changing JFFS2 behavior would in theory be possible but > nobody has the energy and time and knowledge to do this now, so better > prevent spi transfers to be interrupted by the user. Well, it's not really an JFFS2 issue. The real problem is, that with the said change anyone can abort an IO. Usually file systems assume that an IO can only fail in fatal situations. That's why UBIFS, for example, switches immediately to read-only mode. So, an unprivileged user can force UBIFS into read-only mode, which is a local DoS attack vector. JFFS2, on the other hand, dies a different death. If you abort one IO, another IO path can still be active and will violate the order of written data. Long story short, aborting pure user inflicted IO is fine. This is the "dd" use case. But as soon a filesystem is on top, things get complicated. Maybe it is possible to teach the SPI subsystem whether an IO comes from spidev or the kernel itself? Thanks, //richard
