Greg KH wrote:
> bleah, a proliferation of a zillion little spinlocks all across the
> kernel is not my idea of fun :(
A zillion locks each with a single purpose is a lot more fun than 1
lock with a zillion different uses.
> I don't know if a simple spinlock can help us here. Look at
> driverfs_get_inode() and follow that into the vfs layer. Make sure all
> of that is race safe (and isn't currently relying on the BKL.) I'll
> defer to Al Viro's opinion about this, as I don't quite know all of the
> side effects going on at this moment in time.
OK, I agree a simple spinlock is not the way to go because I now see
the sleepable operations in there. But, I don't think
driverfs_get_inode() needs any more locking. The inode that it
references is freshly allocated and my only concern would be about
access from the inode_in_use list. Maybe down()ing i_sem will provide
a bit more protection, but unless the access through inode_in_use is
already a problem, i_sem isn't needed. Any thoughts, Al?
-- Dave Hansen haveblue@us.ibm.com- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/