Re: [RFC PATCH 0/4] devres: warn about managed memory still held by open files at unbind

[Chad Aldreda <ca@modelmiser.com>]

> Are you really expecting anyone to read all that ?

Fair enough. The short version:

A struct cdev, miscdevice or video_device embedded in devm_kzalloc()'d
driver state outlives the unbind through any open file, and the next
operation on that file, usually close(), is a use-after-free. It keeps
getting fixed one driver at a time (44f3468a0aef, 7d6358ab0286), and
cx231xx in 7.4-rc1 still has the shape.

CONFIG_DEBUG_DEVRES_REFS, off by default: in device_unbind_cleanup(),
before devres_release_all(), walk every task's fd table once and WARN
when a file's private_data, i_private or i_cdev, or an object a
subsystem names (patch 3: V4L2's video_device), points into an
allocation about to be freed. A debugfs file still live during the walk
is judged after release, since drivers often remove those through a
devres action. Cost: one walk per unbind or failed probe.

Patch 4 is a test driver: unbind with its nodes open gives two WARNs,
and KASAN then reports the use-after-frees on close. vivid, as a
control, is silent.

The open problem (question 5 in the cover): the walk holds a reference
on each file it inspects, so a racing close can leave it the last
holder. It runs on a kthread so that release goes to delayed_fput
rather than task work queued behind the unbind, but the delayed-fput
worker is serialized, so a release there that needs a lock unbind
holds stalls the ones behind it.