Using the correct bit helps. The documentation specifies bit 0 in both
registers to be controlling polarity of dpi_vsync_input and
dpi_hsync_input polarity. Bit 1 is reserved, and should therefore not be
set.
Tested with panel that requires active high vsync and hsync.
Signed-off-by: Esben Haabendal <esben@geanix.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240814-nwl-dsi-sync-polarity-v1-1-ee198e369196@geanix.com
Add support for ArrowLake-U platform to the RAPL common driver.
Signed-off-by: Sumeet Pawnikar <sumeet.r.pawnikar@intel.com>
Acked-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240816113332.7408-1-sumeet.r.pawnikar@intel.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
After commit ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf"),
on AMD processors that support extended CPUID leaf 0x80000026, the
topology_logical_die_id() macros, no longer returns package id, instead it
returns the CCD (Core Complex Die) id. This leads to the energy-pkg
event scope to be modified to CCD instead of package.
For more historical context, please refer to commit 32fb480e0a
("powercap/intel_rapl: Support multi-die/package"), which initially changed
the RAPL scope from package to die for all systems, as Intel systems
with Die enumeration have RAPL scope as die, and those without die
enumeration are not affected. So, all systems(Intel, AMD, Hygon), worked
correctly with topology_logical_die_id() until recently, but this changed
after the "0x80000026 leaf" commit mentioned above.
Future multi-die Intel systems will have package scope RAPL counters,
but they will be using TPMI RAPL interface, which is not affected by
this change.
Replacing topology_logical_die_id() with topology_physical_package_id()
conditionally only for AMD and Hygon fixes the energy-pkg event.
On an AMD 2 socket 8 CCD Zen4 server:
Before:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:4 intel-rapl:8:0 intel-rapl:d
intel-rapl:0 intel-rapl:4:0 intel-rapl:9 intel-rapl:d:0
intel-rapl:0:0 intel-rapl:5 intel-rapl:9:0 intel-rapl:e
intel-rapl:1 intel-rapl:5:0 intel-rapl:a intel-rapl:e:0
intel-rapl:1:0 intel-rapl:6 intel-rapl🅰️0 intel-rapl:f
intel-rapl:2 intel-rapl:6:0 intel-rapl:b intel-rapl:f:0
intel-rapl:2:0 intel-rapl:7 intel-rapl🅱️0
intel-rapl:3 intel-rapl:7:0 intel-rapl:c
intel-rapl:3:0 intel-rapl:8 intel-rapl:c:0
After:
linux$ ls /sys/class/powercap/
intel-rapl intel-rapl:0 intel-rapl:0:0 intel-rapl:1 intel-rapl:1:0
Only one sysfs entry per-event per-package is created after this change.
Fixes: 63edbaa48a ("x86/cpu/topology: Add support for the AMD 0x80000026 leaf")
Reported-by: Michael Larabel <michael@michaellarabel.com>
Signed-off-by: Dhananjay Ugwekar <Dhananjay.Ugwekar@amd.com>
Reviewed-by: Zhang Rui <rui.zhang@intel.com>
Link: https://patch.msgid.link/20240730044917.4680-3-Dhananjay.Ugwekar@amd.com
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
There's no need to get the length of an DT array property before
parsing the array. of_property_read_variable_u8_array() takes a minimum
and maximum length and returns the actual length (or error code).
This is part of a larger effort to remove callers of of_get_property()
and similar functions. of_get_property() leaks the DT property data
pointer which is a problem for dynamically allocated nodes which may
be freed.
Signed-off-by: Rob Herring (Arm) <robh@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240731201407.1838385-4-robh@kernel.org
Make use of devm_clk_get_enabled() to replace devm_clk_get() and
clk_prepare_enable() for isfr and iahb clocks, and drop the now
unnecessary calls to clk_disable_unprepare().
Similarly, use devm_clk_get_optional_enabled() helper for cec clock,
which additionally allows to remove the -ENOENT test.
Moreover, the clock related members of struct dw_hdmi are not required
anymore, hence drop them.
Signed-off-by: Cristian Ciocaltea <cristian.ciocaltea@collabora.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240813-dw-hdmi-simple-clk-v1-1-78d45cef02a9@collabora.com
If the bridge is attached with the DRM_BRIDGE_ATTACH_NO_CONNECTOR flag set,
this driver won't initialize a connector and hence display mode won't be
validated in drm_connector_helper_funcs::mode_valid(). So, move the mode
validation from drm_connector_helper_funcs::mode_valid() to
drm_bridge_funcs::mode_valid(), because the mode validation is always done
for the bridge.
Fixes: 30e2ae943c ("drm/bridge: Introduce LT8912B DSI to HDMI bridge")
Signed-off-by: Liu Ying <victor.liu@nxp.com>
Reviewed-by: Robert Foss <rfoss@kernel.org>
Signed-off-by: Robert Foss <rfoss@kernel.org>
Link: https://patchwork.freedesktop.org/patch/msgid/20240813091637.1054586-1-victor.liu@nxp.com
We should unpin before evicting all memory, and repin after GT resume.
This way, we preserve the contents of the framebuffers, and won't hang
on resume due to migration engine not being restored yet.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Fixes: dd08ebf6c3 ("drm/xe: Introduce a new DRM driver for Intel GPUs")
Cc: stable@vger.kernel.org # v6.8+
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240806105044.596842-3-maarten.lankhorst@linux.intel.com
Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com>
Suspend fbdev sooner, and disable user access before suspending to
prevent some races. I've noticed this when comparing xe suspend to
i915's.
Matches the following commits from i915:
24b412b1bf ("drm/i915: Disable intel HPD poll after DRM poll init/enable")
1ef28d86be ("drm/i915: Suspend the framebuffer console earlier during system suspend")
bd738d859e ("drm/i915: Prevent modesets during driver init/shutdown")
Thanks to Imre for pointing me to those commits.
Driver shutdown is currently missing, but I have some idea how to
implement it next.
Signed-off-by: Maarten Lankhorst <maarten.lankhorst@linux.intel.com>
Cc: Imre Deak <imre.deak@intel.com>
Reviewed-by: Uma Shankar <uma.shankar@intel.com>
Link: https://patchwork.freedesktop.org/patch/msgid/20240806105044.596842-2-maarten.lankhorst@linux.intel.com
Signed-off-by: Maarten Lankhorst,,, <maarten.lankhorst@linux.intel.com>
Change the Kconfig dependency so that it doesn't require both I2C and SPI
subsystems to be built. Make a few small changes to the code so that the
code for a bus is only called if the bus is being built.
When SPI support was added to serial-multi-instantiate it created a
dependency that both CONFIG_I2C and CONFIG_SPI must be enabled.
Typically they are, but there's no reason why this should be a
requirement. A specific kernel build could have only I2C devices
or only SPI devices. It should be possible to use serial-multi-instantiate
if only I2C or only SPI is enabled.
The dependency formula used is:
depends on (I2C && !SPI) || (!I2C && SPI) || (I2C && SPI)
The advantage of this approach is that if I2C=m or SPI=m then
SERIAL_MULTI_INSTANTIATE is limited to n/m.
Signed-off-by: Richard Fitzgerald <rf@opensource.cirrus.com>
Link: https://lore.kernel.org/r/20240814132939.308696-1-rf@opensource.cirrus.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
The pm_runtime_disable() is missing in the remove function, fix it
by using devm_pm_runtime_enable(), so the pm_runtime_disable() in
the probe error path can also be removed.
Fixes: 2d13f2ff60 ("spi: bcm63xx-spi: fix pm_runtime")
Cc: stable@vger.kernel.org # v5.13+
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Suggested-by: Jonas Gorski <jonas.gorski@gmail.com>
Link: https://patch.msgid.link/20240819123349.4020472-3-ruanjinjie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from platform_device_id table.
Fixes: 44d8fb3094 ("spi/bcm63xx: move register definitions into the driver")
Cc: stable@vger.kernel.org
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Jonas Gorski <jonas.gorski@gmail.com>
Link: https://patch.msgid.link/20240819123349.4020472-2-ruanjinjie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The sparse tool complains as follows:
drivers/iommu/iommufd/selftest.c:277:30: warning:
symbol 'dirty_ops' was not declared. Should it be static?
This symbol is not used outside of selftest.c, so marks it static.
Fixes: 266ce58989 ("iommufd/selftest: Test IOMMU_HWPT_ALLOC_DIRTY_TRACKING")
Link: https://patch.msgid.link/r/20240819120007.3884868-1-ruanjinjie@huawei.com
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Yi Liu <yi.l.liu@intel.com>
Signed-off-by: Jason Gunthorpe <jgg@nvidia.com>
Add MODULE_DEVICE_TABLE(), so modules could be properly autoloaded
based on the alias from of_device_id table.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://patch.msgid.link/20240819040523.2801461-1-ruanjinjie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The sparse tool complains as follows:
drivers/spi/spi-cadence-xspi.c:334:11: warning:
symbol 'cdns_mrvl_xspi_clk_div_list' was not declared. Should it be static?
This symbol is not used outside spi-cadence-xspi.c, so marks it static.
Signed-off-by: Jinjie Ruan <ruanjinjie@huawei.com>
Link: https://patch.msgid.link/20240819120031.3884913-1-ruanjinjie@huawei.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The skylake-driver is deprecated in favour of the avs-driver. As the
latter supports all configurations of its predecessor and more, update
the existing selection mechanism to acknowledge the SST flag.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-15-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The avs-driver found in sound/soc/intel/avs is a direct replacement to
the existing skylake-driver. It covers all features supported by it and
more and aligns with the recommended flows and requirements based on
Windows driver equivalent.
For the official kernel tree the deprecation begun with v6.0. Most
skylake-drivers users moved to avs- or SOF-driver when AudioDSP
capabilities are available on the platform or to snd-hda-intel
(sound/pci/hda) when such capabilities are not.
For the supported trees the deprecation begun with v5.4 with v5.15 being
the first where the skylake-driver is disabled entirely.
All machine board drivers that consume the DSP driver have their
replacements present within sound/soc/intel/avs/boards/ directory.
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-14-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_nau8825 (./intel/avs/boards/nau8825.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-13-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_nau8825 (./intel/avs/boards/nau8825.c)
- avs_ssm4567 (./intel/avs/boards/ssm4567.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-12-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt286 (./intel/avs/boards/rt286.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-11-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-10-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-9-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5660 (./intel/avs/boards/rt5660.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-8-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5663 (./intel/avs/boards/rt5663.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-7-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt5514 (./intel/avs/boards/rt5514.c)
- avs_rt5663 (./intel/avs/boards/rt5663.c)
- avs_max98927 (./intel/avs/boards/max98927.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-6-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_da7219 (./intel/avs/boards/da7219.c)
- avs_max98357a (./intel/avs/boards/max98357a.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-5-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The driver has no users.
Succeeded by:
- avs_rt298 (./intel/avs/boards/rt298.c)
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-4-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
Preparation step in the skylake-driver removal process.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-3-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The avs-driver succeeds the skylake-driver. It suppots all
configurations of its predecessor and more. Reflect that in the existing
selection table.
Signed-off-by: Cezary Rojewski <cezary.rojewski@intel.com>
Reviewed-by: Takashi Iwai <tiwai@suse.de>
Acked-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://patch.msgid.link/20240814083929.1217319-2-cezary.rojewski@intel.com
Signed-off-by: Mark Brown <broonie@kernel.org>
The previous implementation lacked error checking (e.g. the bytes
returned by squashfs_fill_page() is not checked), and the use of
page->index could not be removed without substantially rewriting
the routine to use the page actor abstraction used elsewhere.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
Link: https://lore.kernel.org/r/20240818235847.170468-5-phillip@squashfs.org.uk
Signed-off-by: Christian Brauner <brauner@kernel.org>
This commit removes references to page->index in the pages returned
from __readahead_batch(), and instead uses the 'start' variable.
This does reveal a bug in the previous code in that 'start' was
not updated every time around the loop. This is fixed in this
commit.
Signed-off-by: Phillip Lougher <phillip@squashfs.org.uk>
Link: https://lore.kernel.org/r/20240818235847.170468-3-phillip@squashfs.org.uk
Signed-off-by: Christian Brauner <brauner@kernel.org>
Add basic support for registering the aggregator module on Device Tree-
based platforms. These include at least three generations of Qualcomm
Snapdragon-based Surface devices:
- SC8180X / SQ1 / SQ2: Pro X,
- SC8280XP / SQ3: Devkit 2023, Pro 9
- X Elite: Laptop 7 / Pro11
Thankfully, the aggregators on these seem to be configured in an
identical way, which allows for using these settings as defaults and
no DT properties need to be introduced (until that changes, anyway).
Based on the work done by Maximilian Luz, largely rewritten.
Signed-off-by: Konrad Dybcio <quic_kdybcio@quicinc.com>
Reviewed-by: Maximilian Luz <luzmaximilian@gmail.com>
Tested-by: Maximilian Luz <luzmaximilian@gmail.com>
Link: https://lore.kernel.org/r/20240814-topic-sam-v3-3-a84588aad233@quicinc.com
Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
Add bindings for the Surface System Aggregator Module (SAM/SSAM), the
Microsoft Surface-standard Embedded Controller, used on both x86- and
Qualcomm-based devices.
It provides a plethora of functions, depending on what's wired up to
it. That includes but is not limited to: fan control, keyboard/touchpad
support, thermal sensors, power control, special buttons, tablet mode.
Signed-off-by: Konrad Dybcio <quic_kdybcio@quicinc.com>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20240814-topic-sam-v3-2-a84588aad233@quicinc.com
Signed-off-by: Hans de Goede <hdegoede@redhat.com>
In the function percpu_rwsem_release, the parameter `read`
is unused, so remove it.
Signed-off-by: Wang Long <w@laoqinren.net>
Link: https://lore.kernel.org/r/20240802091901.2546797-1-w@laoqinren.net
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
If you pass an fd using FSCONFIG_SET_FD, autofs_parse_fd() "steals" the
param->file and so the fs_context infrastructure will not do fput() for
us.
Fixes: e6ec453bd0 ("autofs: convert autofs to use the new mount api")
Signed-off-by: Aleksa Sarai <cyphar@cyphar.com>
Link: https://lore.kernel.org/r/20240731-fsconfig-fsparam_fd-fixes-v2-1-e7c472224417@cyphar.com
Signed-off-by: Christian Brauner <brauner@kernel.org>
__percpu annotation of *cpu pointer in struct kioctx is put at
the wrong place, resulting in several sparse warnings:
aio.c:623:24: warning: incorrect type in argument 1 (different address spaces)
aio.c:623:24: expected void [noderef] __percpu *__pdata
aio.c:623:24: got struct kioctx_cpu *cpu
aio.c:788:18: warning: incorrect type in assignment (different address spaces)
aio.c:788:18: expected struct kioctx_cpu *cpu
aio.c:788:18: got struct kioctx_cpu [noderef] __percpu *
aio.c:835:24: warning: incorrect type in argument 1 (different address spaces)
aio.c:835:24: expected void [noderef] __percpu *__pdata
aio.c:835:24: got struct kioctx_cpu *cpu
aio.c:940:16: warning: incorrect type in initializer (different address spaces)
aio.c:940:16: expected void const [noderef] __percpu *__vpp_verify
aio.c:940:16: got struct kioctx_cpu *
aio.c:958:16: warning: incorrect type in initializer (different address spaces)
aio.c:958:16: expected void const [noderef] __percpu *__vpp_verify
aio.c:958:16: got struct kioctx_cpu *
Put __percpu annotation at the right place to fix these warnings.
Signed-off-by: Uros Bizjak <ubizjak@gmail.com>
Link: https://lore.kernel.org/r/20240730121915.4514-1-ubizjak@gmail.com
Reviewed-by: Jan Kara <jack@suse.cz>
Cc: Benjamin LaHaise <bcrl@kvack.org>
Cc: Alexander Viro <viro@zeniv.linux.org.uk>
Cc: Christian Brauner <brauner@kernel.org>
Cc: Jan Kara <jack@suse.cz>
Cc: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Christian Brauner <brauner@kernel.org>
If no page could be allocated, an error pointer was used as format
string in pr_warn.
Rearrange the code to return early in case of OOM. Also add a check
for the return value of d_path.
Fixes: f8b92ba67c ("mount: Add mount warning for impending timestamp expiry")
Signed-off-by: Olaf Hering <olaf@aepfle.de>
Link: https://lore.kernel.org/r/20240730085856.32385-1-olaf@aepfle.de
[brauner: rewrite commit and commit message]
Signed-off-by: Christian Brauner <brauner@kernel.org>
Fixed-
WARNING: Missing a blank line after declarations
WARNING: Missing a blank line after declarations
Declaration format: improved struct file declaration format
Signed-off-by: Mohit0404 <mohitpawar@mitaoe.ac.in>
Link: https://lore.kernel.org/r/20240727072134.130962-2-mohitpawar@mitaoe.ac.in
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
After commit c22198e78d ("direct-io: remove random prefetches"), Nothing
in this file needs anything from `linux/prefetch.h`.
Signed-off-by: Youling Tang <tangyouling@kylinos.cn>
Link: https://lore.kernel.org/r/20240603014834.45294-1-youling.tang@linux.dev
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
When deactivating any type of superblock, it had to wait for the in-flight
wb switches to be completed. wb switches are executed in inode_switch_wbs_work_fn()
which needs to acquire the wb_switch_rwsem and races against sync_inodes_sb().
If there are too much dirty data in the superblock, the waiting time may increase
significantly.
For superblocks without cgroup writeback such as tmpfs, they have nothing to
do with the wb swithes, so the flushing can be avoided.
Signed-off-by: Haifeng Xu <haifeng.xu@shopee.com>
Link: https://lore.kernel.org/r/20240726030525.180330-1-haifeng.xu@shopee.com
Reviewed-by: Jan Kara <jack@suse.cz>
Suggested-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Christian Brauner <brauner@kernel.org> says:
Systemd has a helper called openat_report_new() that returns whether a
file was created anew or it already existed before for cases where
O_CREAT has to be used without O_EXCL (cf. [1]). That apparently isn't
something that's specific to systemd but it's where I noticed it.
The current logic is that it first attempts to open the file without
O_CREAT | O_EXCL and if it gets ENOENT the helper tries again with both
flags. If that succeeds all is well. If it now reports EEXIST it
retries.
That works fairly well but some corner cases make this more involved. If
this operates on a dangling symlink the first openat() without O_CREAT |
O_EXCL will return ENOENT but the second openat() with O_CREAT | O_EXCL
will fail with EEXIST. The reason is that openat() without O_CREAT |
O_EXCL follows the symlink while O_CREAT | O_EXCL doesn't for security
reasons. So it's not something we can really change unless we add an
explicit opt-in via O_FOLLOW which seems really ugly.
The caller could try and use fanotify() to register to listen for
creation events in the directory before calling openat(). The caller
could then compare the returned tid to its own tid to ensure that even
in threaded environments it actually created the file. That might work
but is a lot of work for something that should be fairly simple and I'm
uncertain about it's reliability.
The caller could use a bpf lsm hook to hook into security_file_open() to
figure out whether they created the file. That also seems a bit wild.
So let's add F_CREATED_QUERY which allows the caller to check whether
they actually did create the file. That has caveats of course but I
don't
think they are problematic:
* In multi-threaded environments a thread can only be sure that it did
create the file if it calls openat() with O_CREAT. In other words,
it's obviously not enough to just go through it's fdtable and check
these fds because another thread could've created the file.
* If there's any codepaths where an openat() with O_CREAT would yield
the same struct file as that of another thread it would obviously
cause wrong results. I'm not aware of any such codepaths from openat()
itself. Imho, that would be a bug.
* Related to the previous point, calling the new fcntl() on files created
and opened via special-purpose system calls or ioctl()s would cause
wrong results only if the affected subsystem a) raises FMODE_CREATED
and b) may return the same struct file for two different calls. I'm
not seeing anything outside of regular VFS code that raises
FMODE_CREATED.
There is code for b) in e.g., the drm layer where the same struct file
is resurfaced but again FMODE_CREATED isn't used and it would be very
misleading if it did.
[1]: 11d5e2b5fb/src/basic/fs-util.c (L1078)
* patches from https://lore.kernel.org/r/20240724-work-fcntl-v1-0-e8153a2f1991@kernel.org:
selftests: add F_CREATED_QUERY tests
fcntl: add F_CREATED_QUERY
Signed-off-by: Christian Brauner <brauner@kernel.org>
Systemd has a helper called openat_report_new() that returns whether a
file was created anew or it already existed before for cases where
O_CREAT has to be used without O_EXCL (cf. [1]). That apparently isn't
something that's specific to systemd but it's where I noticed it.
The current logic is that it first attempts to open the file without
O_CREAT | O_EXCL and if it gets ENOENT the helper tries again with both
flags. If that succeeds all is well. If it now reports EEXIST it
retries.
That works fairly well but some corner cases make this more involved. If
this operates on a dangling symlink the first openat() without O_CREAT |
O_EXCL will return ENOENT but the second openat() with O_CREAT | O_EXCL
will fail with EEXIST. The reason is that openat() without O_CREAT |
O_EXCL follows the symlink while O_CREAT | O_EXCL doesn't for security
reasons. So it's not something we can really change unless we add an
explicit opt-in via O_FOLLOW which seems really ugly.
The caller could try and use fanotify() to register to listen for
creation events in the directory before calling openat(). The caller
could then compare the returned tid to its own tid to ensure that even
in threaded environments it actually created the file. That might work
but is a lot of work for something that should be fairly simple and I'm
uncertain about it's reliability.
The caller could use a bpf lsm hook to hook into security_file_open() to
figure out whether they created the file. That also seems a bit wild.
So let's add F_CREATED_QUERY which allows the caller to check whether
they actually did create the file. That has caveats of course but I
don't think they are problematic:
* In multi-threaded environments a thread can only be sure that it did
create the file if it calls openat() with O_CREAT. In other words,
it's obviously not enough to just go through it's fdtable and check
these fds because another thread could've created the file.
* If there's any codepaths where an openat() with O_CREAT would yield
the same struct file as that of another thread it would obviously
cause wrong results. I'm not aware of any such codepaths from openat()
itself. Imho, that would be a bug.
* Related to the previous point, calling the new fcntl() on files created
and opened via special-purpose system calls or ioctl()s would cause
wrong results only if the affected subsystem a) raises FMODE_CREATED
and b) may return the same struct file for two different calls. I'm
not seeing anything outside of regular VFS code that raises
FMODE_CREATED.
There is code for b) in e.g., the drm layer where the same struct file
is resurfaced but again FMODE_CREATED isn't used and it would be very
misleading if it did.
Link: 11d5e2b5fb/src/basic/fs-util.c (L1078) [1]
Link: https://lore.kernel.org/r/20240724-work-fcntl-v1-1-e8153a2f1991@kernel.org
Reviewed-by: Jeff Layton <jlayton@kernel.org>
Reviewed-by: Jan Kara <jack@suse.cz>
Signed-off-by: Christian Brauner <brauner@kernel.org>
Matthew Wilcox (Oracle) <willy@infradead.org> says:
This patch series applies on top of fs-next. After applying these two
patches, there are no more references to 'struct page' in jffs2. I
obviously haven't tested it at all beyond compilation.
* patches from https://lore.kernel.org/r/20240814195915.249871-1-willy@infradead.org:
jffs2: Use a folio in jffs2_garbage_collect_dnode()
jffs2: Convert jffs2_do_readpage_nolock to take a folio
Link: https://lore.kernel.org/r/20240814195915.249871-1-willy@infradead.org
Signed-off-by: Christian Brauner <brauner@kernel.org>
Call read_cache_folio() instead of read_cache_page() to get the folio
containing the page. No attempt is made here to support large folios
as I assume that will never be interesting for jffs2. Includes a switch
from kmap to kmap_local which looks safe.
Signed-off-by: Matthew Wilcox (Oracle) <willy@infradead.org>
Link: https://lore.kernel.org/r/20240814195915.249871-3-willy@infradead.org
Reviewed-by: Zhihao Cheng <chengzhihao1@huawei.com>
Signed-off-by: Christian Brauner <brauner@kernel.org>
