summaryrefslogtreecommitdiff
path: root/include
diff options
context:
space:
mode:
authorTom Van Braeckel <tomvanbraeckel@gmail.com>2015-03-24 16:35:49 +0100
committerChris Mason <clm@fb.com>2015-03-26 18:10:24 -0700
commitd8620958296e4fa61afde421f1de16a5c2234b28 (patch)
tree23fdbb199dd476ae5acae908f87803d974dc648e /include
parent26e726afe01c1c82072cf23a5ed89ce25f39d9f2 (diff)
downloadlinux-next-d8620958296e4fa61afde421f1de16a5c2234b28.tar.gz
btrfs: explicitly set control file's private_data
The private_data member of the Btrfs control device file (/dev/btrfs-control) is used to hold the current transaction and needs to be initialized to NULL to signify that no transaction is in progress. We explicitly set the control file's private_data to NULL to be independent of whatever value the misc subsystem initializes it to. Backstory: ---------- The misc subsystem (which is used by /dev/btrfs-control) initializes a file's private_data to point to the misc device when a driver has registered a custom open file operation and initializes it to NULL when a custom open file operation has *not* been provided. This subtle quirk is confusing, to the point where kernel code registers *empty* file open operations to have private_data point to the misc device structure. And it leads to bugs, where the addition or removal of a custom open file operation surprisingly changes the initial contents of a file's private_data structure. To simplify things in the misc subsystem, a patch [1] has been proposed to *always* set private_data to point to the misc device instead of only doing this when a custom open file operation has been registered. But before we can fix this in the misc subsystem itself, we need to modify the (few) drivers that rely on this very subtle behavior. [1] https://lkml.org/lkml/2014/12/4/939 Signed-off-by: Martin Kepplinger <martink@posteo.de> Signed-off-by: Tom Van Braeckel <tomvanbraeckel@gmail.com> Signed-off-by: Chris Mason <clm@fb.com>
Diffstat (limited to 'include')
0 files changed, 0 insertions, 0 deletions