On Thu, 15 Apr 2010, Arnd Bergmann wrote: > On Thursday 15 April 2010, Douglas Gilbert wrote: > > At the level of SCSI commands, tape device state assumptions > > made by the st driver could be compromised by SCSI commands > > sent by the sg driver. However the BKL was never meant > > to address that concern. > > ... > > So I would not be concerned about any kernel locking > > interactions between the sg and st drivers. I have > > added Kai Makisara (st maintainer) to the cc list. > > Ok. I've also checked st.c again and noticed that it > doesn't use use the BKL in ioctl() but only in open(), > which is very unlikely to race against anything in sg.c > or the block subsystem. > Using sg with a tape opened by st may lead to incorrect state within st. However, to prevent this would be far too complicated and so the coordination responsibility is left to the user. (There are some cases where use of both sg and st can be justified but then the user should know what he/she is doing and properly serialize access in user space.) BKL does not have any "hidden duties" in open() in st.c. I don't know any reason why it would be needed, but, because I have not been absolutely sure, I have not removed it. (The tape devices are not opened often and so the overhead has been negligible. That is, while BKL has been available.) If you don't see any reason for BKL in open(), go ahead and remove it. Kai -- To unsubscribe from this list: send the line "unsubscribe linux-scsi" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
