summaryrefslogtreecommitdiffstats
path: root/mm
diff options
context:
space:
mode:
authorJohannes Berg <johannes.berg@intel.com>2021-03-19 23:25:11 +0100
committerJohannes Berg <johannes.berg@intel.com>2021-04-08 10:14:45 +0200
commit71826654ce40112f0651b6f4e94c422354f4adb6 (patch)
treed5ea7eea71c56e40c685f8754f1b9e74f66188c4 /mm
parentdd0b45538146cb6a54d6da7663b8c3afd16ebcfd (diff)
downloadlinux-stable-71826654ce40112f0651b6f4e94c422354f4adb6.tar.gz
linux-stable-71826654ce40112f0651b6f4e94c422354f4adb6.tar.bz2
linux-stable-71826654ce40112f0651b6f4e94c422354f4adb6.zip
rfkill: revert back to old userspace API by default
Recompiling with the new extended version of struct rfkill_event broke systemd in *two* ways: - It used "sizeof(struct rfkill_event)" to read the event, but then complained if it actually got something != 8, this broke it on new kernels (that include the updated API); - It used sizeof(struct rfkill_event) to write a command, but didn't implement the intended expansion protocol where the kernel returns only how many bytes it accepted, and errored out due to the unexpected smaller size on kernels that didn't include the updated API. Even though systemd has now been fixed, that fix may not be always deployed, and other applications could potentially have similar issues. As such, in the interest of avoiding regressions, revert the default API "struct rfkill_event" back to the original size. Instead, add a new "struct rfkill_event_ext" that extends it by the new field, and even more clearly document that applications should be prepared for extensions in two ways: * write might only accept fewer bytes on older kernels, and will return how many to let userspace know which data may have been ignored; * read might return anything between 8 (the original size) and whatever size the application sized its buffer at, indicating how much event data was supported by the kernel. Perhaps that will help avoid such issues in the future and we won't have to come up with another version of the struct if we ever need to extend it again. Applications that want to take advantage of the new field will have to be modified to use struct rfkill_event_ext instead now, which comes with the danger of them having already been updated to use it from 'struct rfkill_event', but I found no evidence of that, and it's still relatively new. Cc: stable@vger.kernel.org # 5.11 Reported-by: Takashi Iwai <tiwai@suse.de> Tested-by: Sedat Dilek <sedat.dilek@gmail.com> # LLVM/Clang v12.0.0-r4 (x86-64) Link: https://lore.kernel.org/r/20210319232510.f1a139cfdd9c.Ic5c7c9d1d28972059e132ea653a21a427c326678@changeid Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Diffstat (limited to 'mm')
0 files changed, 0 insertions, 0 deletions