- 03 Sep, 2022 17 commits
-
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type() actually calls acpi_video_unregister_backlight() since that is often probed earlier, leading to userspace seeing the acpi_video0 class device being briefly available, leading to races in userspace where udev probe-rules try to access the device and it is already gone. All callers have been fixed to no longer call it, so remove acpi_video_set_dmi_backlight_type() now. This means we now also no longer need acpi_video_unregister_backlight() for the remove acpi_video backlight after it was wrongly registered hack, so remove that too. Acked-by:
Rafael J. Wysocki <rafael.j.wysocki@intel.com> Signed-off-by:
Hans de Goede <hdegoede@redhat.com>
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Move all the acpi_backlight=[vendor|native] quirks from samsung-laptop to drivers/acpi/video_detect.c . Note the X360 -> acpi_backlight=native quirk is not moved because that already was present in drivers/acpi/video_detect.c . Acked-by:
-
Hans de Goede authored
Remove the asus-wmi quirk_entry.wmi_backlight_native quirk-flag, which called acpi_video_set_dmi_backlight_type(acpi_backlight_native) and replace it with acpi/video_detect.c video_detect_dmi_table[] entries using the video_detect_force_native callback. acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Acked-by:
-
Hans de Goede authored
Remove the asus-wmi quirk_entry.wmi_backlight_power quirk-flag, which called acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) and replace it with acpi/video_detect.c video_detect_dmi_table[] entries using the video_detect_force_vendor callback. acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Note no entries are dropped from the dmi_system_id table in asus-nb-wmi.c. This is because the entries using the removed wmi_backlight_power flag also use other model specific quirks from the asus-wmi quirk_entry struct. So the quirk_asus_x55u struct and the entries pointing to it cannot be dropped. Acked-by:
-
Hans de Goede authored
Remove this check from the asus-wmi backlight handling: /* Some Asus desktop boards export an acpi-video backlight interface, stop this from showing up */ chassis_type = dmi_get_system_info(DMI_CHASSIS_TYPE); if (chassis_type && !strcmp(chassis_type, "3")) acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); This acpi_video_set_dmi_backlight_type(acpi_backlight_vendor) call must be removed because other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ So leaving this in place can break things on laptops with a broken DMI chassis-type, which would have GPU native brightness control before the addition of the acpi_video_get_backlight_type() != native check. Removing this should be ok now, since the ACPI video code has improved heuristics for this itself now (which includes a chassis-type check). Signed-off-by: -
Hans de Goede authored
Move the backlight DMI quirks to acpi/video_detect.c, so that the driver no longer needs to call acpi_video_set_dmi_backlight_type(). acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. Note that even though the DMI quirk table name was video_vendor_dmi_table, 5/6 quirks were actually quirks to use the GPU native backlight. These 5 quirks also had a callback in their dmi_system_id entry which disabled the acer-wmi vendor driver; and any DMI match resulted in: acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); which disabled the acpi_video driver, so only the native driver was left. The new entries for these 5/6 devices correctly marks these as needing the native backlight driver. Also note that other changes in this series change the native backlight drivers to no longer unconditionally register their backlight. Instead these drivers now do this check: if (acpi_video_get_backlight_type(false) != acpi_backlight_native) return 0; /* bail */ which without this patch would have broken these 5/6 "special" quirks. Since I had to look at all the commits adding the quirks anyways, to make sure that I understood the code correctly, I've also added links to the various original bugzillas for these quirks to the new entries. Acked-by:
-
Hans de Goede authored
acpi_video_set_dmi_backlight_type() is troublesome because it may end up getting called after other backlight drivers have already called acpi_video_get_backlight_type() resulting in the other drivers already being registered even though they should not. In case of the acpi_video backlight, acpi_video_set_dmi_backlight_type() actually calls acpi_video_unregister_backlight() since that is often probed earlier, leading to userspace seeing the acpi_video0 class device being briefly available, leading to races in userspace where udev probe-rules try to access the device and it is already gone. In case of toshiba_acpi there are no DMI quirks to move to acpi/video_detect.c, but it also (ab)uses it for transflective displays. Adding transflective display support to video_detect.c would be quite involved. But luckily there are only 2 known models with a transflective display, so we can just add DMI quirks for those. Acked-by:
-
Hans de Goede authored
Now that acpi_video_get_backlight_type() has apple-gmux detection (using apple_gmux_present()), it is no longer necessary for the apple-gmux code to manually remove possibly conflicting drivers. So remove the handling for this from the apple-gmux driver. Signed-off-by: -
Hans de Goede authored
Add an acpi_video_get_backlight_type() == acpi_backlight_nvidia_wmi_ec check. This will make nvidia-wmi-ec-backlight properly honor the user selecting a different backlight driver through the acpi_backlight=... kernel commandline option. Since the auto-detect code check for nvidia-wmi-ec-backlight in drivers/acpi/video_detect.c already checks that the WMI advertised brightness-source is the embedded controller, this new check makes it unnecessary for nvidia_wmi_ec_backlight_probe() to check this itself. Suggested-by:
Daniel Dadap <ddadap@nvidia.com> Reviewed-by:
-
Hans de Goede authored
On Apple laptops with an Apple GMUX using this for brightness control, should take precedence of any other brightness control methods. Add apple-gmux detection to acpi_video_get_backlight_type() using the already existing apple_gmux_present() helper function. This will allow removig the (ab)use of: acpi_video_set_dmi_backlight_type(acpi_backlight_vendor); Inside the apple-gmux driver. Acked-by:
-
Hans de Goede authored
On some new laptop designs a new Nvidia specific WMI interface is present which gives info about panel brightness control and may allow controlling the brightness through this interface when the embedded controller is used for brightness control. When this WMI interface is present and indicates that the EC is used, then this interface should be used for brightness control. Changes in v2: - Use the new shared nvidia-wmi-ec-backlight.h header for the WMI firmware API definitions - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Changes in v3: - Use WMI_BRIGHTNESS_GUID define Acked-by:
-
Hans de Goede authored
Refactor acpi_video_get_backlight_type() so that the heuristics / detection steps are stricly in order of descending precedence. Also move the comments describing the steps to when the various steps are actually done, to avoid the comments getting out of sync with the code. Acked-by:
-
Hans de Goede authored
Move the WMI interface definitions to a header, so that the definitions can be shared with drivers/acpi/video_detect.c . Changes in v2: - Add missing Nvidia copyright header - Move WMI_BRIGHTNESS_GUID to nvidia-wmi-ec-backlight.h as well Suggested-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before radeon, which used to cause /sys/class/backlight/acpi_video0 to get registered and then radeon would register its own radeon_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when radeon skips registering its own backlight device because of e.g. the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the radeon drm_device gets registered with userspace. Acked-by:
Alex Deucher <alexander.deucher@amd.com> Signed-off-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before amdgpu, which used to cause /sys/class/backlight/acpi_video0 to get registered and then amdgpu would register its own amdgpu_bl# device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when amdgpu skips registering its own backlight device because of either the firmware_flags or the acpi_video_get_backlight_type() return value. This ensures that if the acpi_video backlight device should be used, it will be available before the amdgpu drm_device gets registered with userspace. Acked-by:
-
Hans de Goede authored
Typically the acpi_video driver will initialize before nouveau, which used to cause /sys/class/backlight/acpi_video0 to get registered and then nouveau would register its own nv_backlight device later. After which the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices. This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() when native backlight device registration has failed / was skipped to ensure that there is a backlight device available before the drm_device gets registered with userspace. Changes in v2: - Add nouveau_acpi_video_register_backlight() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by:
Lyude Paul <lyude@redhat.com> Signed-off-by:
-
Hans de Goede authored
On machins without an i915 opregion the acpi_video driver immediately probes the ACPI video bus and used to also immediately register acpi_video# backlight devices when supported. Once the drm/kms driver then loaded later and possibly registered a native backlight device then the drivers/acpi/video_detect.c code unregistered the acpi_video0 device to avoid there being 2 backlight devices (when acpi_video_get_backlight_type()==native). This means that userspace used to briefly see 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this the ACPI video code has been modified to make backlight class device registration a separate step, relying on the drm/kms driver to ask for the acpi_video backlight registration after it is done setting up its native backlight device. Add a call to the new acpi_video_register_backlight() after the i915 calls acpi_video_register() (after setting up the i915 opregion) so that the acpi_video backlight devices get registered on systems where the i915 native backlight device is not registered. Changes in v2: -Only call acpi_video_register_backlight() when a panel is detected Changes in v3: -Add a new intel_acpi_video_register() helper which checks if a panel is present and then calls acpi_video_register_backlight() Reviewed-by:
Jani Nikula <jani.nikula@intel.com> Signed-off-by:
-
- 02 Sep, 2022 6 commits
-
-
Hans de Goede authored
Remove the code to unregister acpi_video backlight devices when a native backlight device gets registered later. Now that the acpi_video backlight device registration is a separate step which runs later, after the drm/kms driver is done setting up its own native backlight device, it is no longer necessary to monitor for a native (BACKLIGHT_RAW) device showing up later and to then unregister the acpi_video backlight device(s). Acked-by:
-
Hans de Goede authored
On x86/ACPI boards the acpi_video driver will usually initialize before the kms driver (except i915). This causes /sys/class/backlight/acpi_video0 to show up and then the kms driver registers its own native backlight device after which the drivers/acpi/video_detect.c code unregisters the acpi_video0 device (when acpi_video_get_backlight_type()==native). This means that userspace briefly sees 2 devices and the disappearing of acpi_video0 after a brief time confuses the systemd backlight level save/restore code, see e.g.: https://bbs.archlinux.org/viewtopic.php?id=269920 To fix this make backlight class device registration a separate step done by a new acpi_video_register_backlight() function. The intend is for this to be called by the drm/kms driver *after* it is done setting up its own native backlight device. So that acpi_video_get_backlight_type() knows if a native backlight will be available or not at acpi_video backlight registration time, avoiding the add + remove dance. Note the new acpi_video_register_backlight() function is also called from a delayed work to ensure that the acpi_video backlight devices does get registered if necessary even if there is no drm/kms driver or when it is disabled. Changes in v2: - Make register_backlight_delay a module parameter, mainly so that it can be disabled by Nvidia binary driver users Acked-by:
-
Hans de Goede authored
When acpi_video_register() has not run yet the video_bus_head will be empty, so there is no need to check the register_count flag first. Acked-by:
-
Hans de Goede authored
Move the list_del removing an acpi_video_bus from video_bus_head on teardown to before the teardown is done, to avoid code iterating over the video_bus_head list seeing acpi_video_bus objects on there which are (partly) torn down already. Acked-by:
-
Hans de Goede authored
All x86/ACPI kms drivers which register native/BACKLIGHT_RAW type backlight devices call acpi_video_backlight_use_native() now. This sets __acpi_video_get_backlight_type()'s internal static native_available flag. This makes the backlight_device_get_by_type(BACKLIGHT_RAW) check unnecessary. Relying on the cached native_available value not only is simpler, it will also work correctly in cases where then native backlight registration was skipped because of acpi_video_backlight_use_native() returning false. Acked-by:
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Add nouveau_acpi_video_backlight_use_native() wrapper to avoid unresolved symbol errors on non X86 Reviewed-by:
-
- 25 Aug, 2022 3 commits
-
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - To avoid linker errors when amdgpu is builtin and video_detect.c is in a module, select ACPI_VIDEO and its deps if ACPI is enabled. When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring the stubs from acpi/video.h will be used. Changes in v3: - Use drm_info(drm_dev, "...") to log messages - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Acked-by:
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - To avoid linker errors when amdgpu is builtin and video_detect.c is in a module, select ACPI_VIDEO and its deps if ACPI is enabled. When ACPI is disabled, ACPI_VIDEO is also always disabled, ensuring the stubs from acpi/video.h will be used. Changes in v3: - Use drm_info(drm_dev, "...") to log messages - ACPI_VIDEO can now be enabled on non X86 too, adjust the Kconfig changes to match this. Acked-by:
-
Hans de Goede authored
Before this commit when we want userspace to use the acpi_video backlight device we register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones. Registering 2 backlight devices for a single display really is undesirable, don't register the GPU's native backlight device when another backlight device should be used. Changes in v2: - Use drm_info(drm_dev, ...) for log messages Reviewed-by:
-
- 17 Aug, 2022 1 commit
-
-
Hans de Goede authored
ATM on x86 laptops where we want userspace to use the acpi_video backlight device we often register both the GPU's native backlight device and acpi_video's firmware acpi_video# backlight device. This relies on userspace preferring firmware type backlight devices over native ones, but registering 2 backlight devices for a single display really is undesirable. On x86 laptops where the native GPU backlight device should be used, the registering of other backlight devices is avoided by their drivers using acpi_video_get_backlight_type() and only registering their backlight if the return value matches their type. acpi_video_get_backlight_type() uses backlight_device_get_by_type(BACKLIGHT_RAW) to determine if a native driver is available and will never return native if this returns false. This means that the GPU's native backlight registering code cannot just call acpi_video_get_backlight_type() to determine if it should register its backlight, since acpi_video_get_backlight_type() will never return native until the native backlight has already registered. To fix this add a new internal native function parameter to acpi_video_get_backlight_type(), which when set to true will make acpi_video_get_backlight_type() behave as if a native backlight has already been registered. And add a new acpi_video_backlight_use_native() helper, which sets this to true, for use in native GPU backlight code. Changes in v2: - Replace adding a native parameter to acpi_video_get_backlight_type() with adding a new acpi_video_backlight_use_native() helper. Acked-by:
-
- 14 Aug, 2022 10 commits
-
-
Linus Torvalds authored
-
Yury Norov authored
Radix tree header includes gfp.h for __GFP_BITS_SHIFT only. Now we have gfp_types.h for this. Fixes powerpc allmodconfig build: In file included from include/linux/nodemask.h:97, from include/linux/mmzone.h:17, from include/linux/gfp.h:7, from include/linux/radix-tree.h:12, from include/linux/idr.h:15, from include/linux/kernfs.h:12, from include/linux/sysfs.h:16, from include/linux/kobject.h:20, from include/linux/pci.h:35, from arch/powerpc/kernel/prom_init.c:24: include/linux/random.h: In function 'add_latent_entropy': >> include/linux/random.h:25:46: error: 'latent_entropy' undeclared (first use in this function); did you mean 'add_latent_entropy'? 25 | add_device_randomness((const void *)&latent_entropy, sizeof(latent_entropy)); | ^~~~~~~~~~~~~~ | add_latent_entropy include/linux/random.h:25:46: note: each undeclared identifier is reported only once for each function it appears in Reported-by:kernel test robot <lkp@intel.com> CC: Andy Shevchenko <andriy.shevchenko@linux.intel.com> CC: Andrew Morton <akpm@linux-foundation.org> CC: Jason A. Donenfeld <Jason@zx2c4.com> Signed-off-by:
Yury Norov <yury.norov@gmail.com> Signed-off-by:
Linus Torvalds <torvalds@linux-foundation.org>
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull vfs lseek fix from Al Viro: "Fix proc_reg_llseek() breakage. Always had been possible if somebody left NULL ->proc_lseek, became a practical issue now" * tag 'pull-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: take care to handle NULL ->proc_lseek()
-
Al Viro authored
Easily done now, just by clearing FMODE_LSEEK in ->f_mode during proc_reg_open() for such entries. Fixes: 868941b1 "fs: remove no_llseek" Signed-off-by:
Al Viro <viro@zeniv.linux.org.uk>
-
git://git.kernel.org/pub/scm/linux/kernel/git/xen/tipLinus Torvalds authored
Pull more xen updates from Juergen Gross: - fix the handling of the "persistent grants" feature negotiation between Xen blkfront and Xen blkback drivers - a cleanup of xen.config and adding xen.config to Xen section in MAINTAINERS - support HVMOP_set_evtchn_upcall_vector, which is more compliant to "normal" interrupt handling than the global callback used up to now - further small cleanups * tag 'for-linus-6.0-rc1b-tag' of git://git.kernel.org/pub/scm/linux/kernel/git/xen/tip: MAINTAINERS: add xen config fragments to XEN HYPERVISOR sections xen: remove XEN_SCRUB_PAGES in xen.config xen/pciback: Fix comment typo xen/xenbus: fix return type in xenbus_file_read() xen-blkfront: Apply 'feature_persistent' parameter when connect xen-blkback: Apply 'feature_persistent' parameter when connect xen-blkback: fix persistent grants negotiation x86/xen: Add support for HVMOP_set_evtchn_upcall_vector
-
Linus Torvalds authored
Merge tag 'perf-tools-fixes-for-v6.0-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux Pull more perf tool updates from Arnaldo Carvalho de Melo: - 'perf c2c' now supports ARM64, adjust its output to cope with differences with what is in x86_64. Now go find false sharing on ARM64 (at least Neoverse) as well! - Refactor the JSON processing, making the output more compact and thus reducing the size of the resulting perf binary - Improvements for 'perf offcpu' profiling, including tracking child processes - Update Intel JSON metrics and events files for broadwellde, broadwellx, cascadelakex, haswellx, icelakex, ivytown, jaketown, knightslanding, sapphirerapids, skylakex and snowridgex - Add 'perf stat' JSON output and a 'perf test' entry for it - Ignore memfd and anonymous mmap events if jitdump present - Refactor 'perf test' shell tests allowing subdirs - Fix an error handling path in 'parse_perf_probe_command()' - Fixes for the guest Intel PT tracing patchkit in the 1st batch of this merge window - Print debuginfod queries if -v option is used, to explain delays in processing when debuginfo servers are enabled to fetch DSOs with richer symbol tables - Improve error message for 'perf record -p not_existing_pid' - Fix openssl and libbpf feature detection - Add PMU pai_crypto event description for IBM z16 on 'perf list' - Fix typos and duplicated words on comments in various places * tag 'perf-tools-fixes-for-v6.0-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux: (81 commits) perf test: Refactor shell tests allowing subdirs perf vendor events: Update events for snowridgex perf vendor events: Update events and metrics for skylakex perf vendor events: Update metrics for sapphirerapids perf vendor events: Update events for knightslanding perf vendor events: Update metrics for jaketown perf vendor events: Update metrics for ivytown perf vendor events: Update events and metrics for icelakex perf vendor events: Update events and metrics for haswellx perf vendor events: Update events and metrics for cascadelakex perf vendor events: Update events and metrics for broadwellx perf vendor events: Update metrics for broadwellde perf jevents: Fold strings optimization perf jevents: Compress the pmu_events_table perf metrics: Copy entire pmu_event in find metric perf pmu-events: Hide the pmu_events perf pmu-events: Don't assume pmu_event is an array perf pmu-events: Move test events/metrics to JSON perf test: Use full metric resolution perf pmu-events: Hide pmu_events_map ...
-
git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linuxLinus Torvalds authored
Pull powerpc fixes from Michael Ellerman: - Ensure we never emit lwarx with EH=1 on 32-bit, because some 32-bit CPUs trap on it rather than ignoring it as they should. - Fix ftrace when building with clang, which was broken by some refactoring. - A couple of other minor fixes. Thanks to Christophe Leroy, Naveen N. Rao, Nick Desaulniers, Ondrej Mosnacek, Pali Rohár, Russell Currey, and Segher Boessenkool. * tag 'powerpc-6.0-2' of git://git.kernel.org/pub/scm/linux/kernel/git/powerpc/linux: powerpc/kexec: Fix build failure from uninitialised variable powerpc/ppc-opcode: Fix PPC_RAW_TW() powerpc64/ftrace: Fix ftrace for clang builds powerpc: Make eh value more explicit when using lwarx powerpc: Don't hide eh field of lwarx behind a macro powerpc: Fix eh field when calling lwarx on PPC32
-
git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfsLinus Torvalds authored
Pull /proc/mounts fix from Al Viro: "Fix for /proc/mounts escaping - escape the '#' character too" * tag 'pull-work.misc' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs: vfs: escape hash as well
-
git://git.samba.org/sfrench/cifs-2.6Linus Torvalds authored
Pull more cifs updates from Steve French: - two fixes for stable, one for a lock length miscalculation, and another fixes a lease break timeout bug - improvement to handle leases, allows the close timeout to be configured more safely - five restructuring/cleanup patches * tag '5.20-rc-smb3-client-fixes-part2' of git://git.samba.org/sfrench/cifs-2.6: cifs: Do not access tcon->cfids->cfid directly from is_path_accessible cifs: Add constructor/destructors for tcon->cfid SMB3: fix lease break timeout when multiple deferred close handles for the same file. smb3: allow deferred close timeout to be configurable cifs: Do not use tcon->cfid directly, use the cfid we get from open_cached_dir cifs: Move cached-dir functions into a separate file cifs: Remove {cifs,nfs}_fscache_release_page() cifs: fix lock length calculation
-
David Howells authored
Enable multipage folio support for the afs filesystem. Support has already been implemented in netfslib, fscache and cachefiles and in most of afs, but I've waited for Matthew Wilcox's latest folio changes. Note that it does require a change to afs_write_begin() to return the correct subpage. This is a "temporary" change as we're working on getting rid of the need for ->write_begin() and ->write_end() completely, at least as far as network filesystems are concerned - but it doesn't prevent afs from making use of the capability. Signed-off-by:
David Howells <dhowells@redhat.com> Acked-by:
Matthew Wilcox (Oracle) <willy@infradead.org> Tested-by: kafs-testing@auristor.com Cc: Marc Dionne <marc.dionne@auristor.com> Cc: linux-afs@lists.infradead.org Link: https://lore.kernel.org/lkml/2274528.1645833226@warthog.procyon.org.uk/Signed-off-by:
-
- 13 Aug, 2022 3 commits
-
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull timer fixes from Ingo Molnar: "Misc timer fixes: - fix a potential use-after-free bug in posix timers - correct a prototype - address a build warning" * tag 'timers-urgent-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: posix-cpu-timers: Cleanup CPU timers before freeing them during exec time: Correct the prototype of ns_to_kernel_old_timeval and ns_to_timespec64 posix-timers: Make do_clock_gettime() static
-
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tipLinus Torvalds authored
Pull x86 fix from Ingo Molnar: "Fix the 'IBPB mitigated RETBleed' mode of operation on AMD CPUs (not turned on by default), which also need STIBP enabled (if available) to be '100% safe' on even the shortest speculation windows" * tag 'x86-urgent-2022-08-13' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip: x86/bugs: Enable STIBP for IBPB mitigated RETBleed
-
git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linuxLinus Torvalds authored
Pull more i2c updates from Wolfram Sang: - two driver fixes for issues introduced this cycle - one trivial driver improvement regarding ACPI - more DTS conversion and additions - documentation updates - subsystem-wide move from strlcpy to strscpy * tag 'i2c-for-5.20-part2' of git://git.kernel.org/pub/scm/linux/kernel/git/wsa/linux: docs: i2c: i2c-sysfs: fix hyperlinks docs: i2c: i2c-sysfs: improve wording docs: i2c: instantiating-devices: add syntax coloring to dts and C blocks docs: i2c: smbus-protocol: improve DataLow/DataHigh definition docs: i2c: i2c-protocol: remove unused legend items docs: i2c: i2c-protocol,smbus-protocol: remove nonsense words docs: i2c: i2c-protocol: update introductory paragraph i2c: move core from strlcpy to strscpy i2c: move drivers from strlcpy to strscpy i2c: kempld: Support ACPI I2C device declaration i2c: mediatek: add i2c compatible for MT8188 dt-bindings: i2c: update bindings for mt8188 soc i2c: microchip-corei2c: fix erroneous late ack send dt-bindings: i2c: qcom,i2c-cci: convert to dtschema i2c: qcom-geni: Fix GPI DMA buffer sync-back
-
