aboutsummaryrefslogtreecommitdiffstats
path: root/net/bluetooth/hci_request.c
diff options
context:
space:
mode:
authorJann Horn <[email protected]>2022-10-31 17:52:56 +0000
committerAl Viro <[email protected]>2022-10-31 19:30:11 +0000
commit7ee47dcfff1835ff75a794d1075b6b5f5462cfed (patch)
tree42d8767ff75c33525b7bc0ba0a05e112b7958200 /net/bluetooth/hci_request.c
parentLinux 6.1-rc1 (diff)
downloadkernel-7ee47dcfff1835ff75a794d1075b6b5f5462cfed.tar.gz
kernel-7ee47dcfff1835ff75a794d1075b6b5f5462cfed.zip
fs: use acquire ordering in __fget_light()
We must prevent the CPU from reordering the files->count read with the FD table access like this, on architectures where read-read reordering is possible: files_lookup_fd_raw() close_fd() put_files_struct() atomic_read(&files->count) I would like to mark this for stable, but the stable rules explicitly say "no theoretical races", and given that the FD table pointer and files->count are explicitly stored in the same cacheline, this sort of reordering seems quite unlikely in practice... Signed-off-by: Jann Horn <[email protected]> Signed-off-by: Al Viro <[email protected]>
Diffstat (limited to 'net/bluetooth/hci_request.c')
0 files changed, 0 insertions, 0 deletions