On Thu, Apr 14, 2022 at 12:43:31PM -0700, Dan Williams wrote: > On Thu, Apr 14, 2022 at 12:34 PM Peter Zijlstra <pet...@infradead.org> wrote: > > > > On Thu, Apr 14, 2022 at 10:17:13AM -0700, Dan Williams wrote: > > > > > One more sanity check... So in driver subsystems there are cases where > > > a device on busA hosts a topology on busB. When that happens there's a > > > need to set the lock class late in a driver since busA knows nothing > > > about the locking rules of busB. > > > > I'll pretend I konw what you're talking about ;-) > > > > > Since the device has a longer lifetime than a driver when the driver > > > exits it must set dev->mutex back to the novalidate class, otherwise > > > it sets up a use after free of the static lock_class_key. > > > > I'm not following, static storage has infinite lifetime. > > Not static storage in a driver module. > > modprobe -r fancy_lockdep_using_driver.ko > > Any use of device_lock() by the core on a device that a driver in this > module was driving will de-reference a now invalid pointer into > whatever memory was vmalloc'd for the module static data.
Ooh, modules (I always, conveniently, forget they exist). Yes, setting a lock instance from the core kernel to a key that's inside a module and then taking the module out will be 'interesting'. Most likely you'll get a splat from lockdep when doing this.
