On 01/05/18(Tue) 19:08, Theo Buehler wrote: > On Mon, Apr 30, 2018 at 02:55:21PM +0200, Martin Pieuchot wrote: > > On 30/04/18(Mon) 12:00, Theo Buehler wrote: > > > With mpi's encouragement and guidance, here's a diff that reduces the > > > scope of the NET_LOCK() a bit. > > > > > > in_control() is the only caller of mrt_ioctl() and the latter is a > > > simple function only requiring a read lock. > > > > > > There are only a handful callers of in_ioctl(). The two switches create > > > relatively tangled codepaths, so this will need some refactoring before > > > we can push the lock further down and split the read and write cases. > > > For now, establish a single exit point, grab the netlock at the > > > beginning and release it at the end. > > > > That makes sense, the same could be done for in6_ioctl(). > > Here's the corresponding diff for in6_control(). > > Push the diff down into mrt6_ioctl() and in6_ioctl(). Much like the IPv4 > version, mrt6_ioctl() only needs a read lock. > > in6_ioctl() is a bit messier. It starts off with a call to nd6_ioctl(), > which only needs a read lock. In the diff, I pushed the NET_RLOCK() down > into nd6_ioctl(), but perhaps it would be better to keep the locking > inside in6_ioctl()
No! It's much better to push it down. We must push it down everywhere until it dies. Diff is ok mpi@
