These are fixes from Lyude, and were meant to have been included in the
last round of drm-next patches.
- Fix some nasty memory issues that broke Lyude's display:
- 0 initialize both nvif args and parsed HDMI infoframe buffers
- Fixed missing memset(…, 0, …) for nvif args before sending VSI
infoframe
- Fixed incorrect data pointer and size in nvkm_uoutp_mthd_infoframe()
(was previously pointing at the start of the nvif_outp_infoframe_args
struct instead of at the start of the infoframe data
- Get rid of duplicated scdc assignments, since we only use it to write the
scdc registers
Signed-off-by: Ben Skeggs <bskeggs@redhat.com>
Signed-off-by: Dave Airlie <airlied@redhat.com>
This reverts commit bd88b965ae ("platform/chrome: cros_ec_lpc: Mark
PROBE_PREFER_ASYNCHRONOUS"), and then some.
It has been reported that there are issues with 'cros-ec-keyb' devices
that are children of this. As noted in the initial patch for its ACPI
support (commit ba0f32141b ("Input: cros_ec_keyb - handle x86
detachable/convertible Chromebooks")), it's possible to probe an ACPI
child device before its parent is probed -- hence the need for
EPROBE_DEFER. Unfortunately, poking your parent's dev_get_drvdata()
isn't safe with asynchronous probe, as there's no locking, and the
ordering is all wrong anyway (drvdata is set before the device is
*really* ready).
Because this parent/child relationship has known issues, let's go the
other direction and force synchronous probe, until we resolve the
issues.
Possible solutions involve adding device links, so we ensure the child
doesn't probe before the parent is done; or perhaps some other larger
refactoring (auxiliary bus?). But that might take a little more effort
and review, as there are many other potential sub-devices of
cros_ec_lpc that could need patching.
Note that we don't have the same problem for non-ACPI cros-ec hosts,
like cros-ec-spi (commit 015e4b05c3 ("platform/chrome: cros_ec_spi:
Set PROBE_PREFER_ASYNCHRONOUS")), because its sub-devices aren't created
until cros_ec_register(), or they don't exist at all (e.g., FPMCU uses).
Fixes: bd88b965ae ("platform/chrome: cros_ec_lpc: Mark PROBE_PREFER_ASYNCHRONOUS")
Signed-off-by: Brian Norris <briannorris@chromium.org>
Reviewed-by: Dmitry Torokhov <dmitry.torokhov@gmail.com>
Reviewed-by: Guenter Roeck <groeck@chromium.org>
Signed-off-by: Tzung-Bi Shih <tzungbi@kernel.org>
Link: https://lore.kernel.org/r/20221111231302.3458191-1-briannorris@chromium.org
With clang's kernel control flow integrity (kCFI, CONFIG_CFI_CLANG),
indirect call targets are validated against the expected function
pointer prototype to make sure the call target is valid to help mitigate
ROP attacks. If they are not identical, there is a failure at run time,
which manifests as either a kernel panic or thread getting killed. A
proposed warning in clang aims to catch these at compile time, which
reveals:
drivers/gpu/drm/mediatek/mtk_hdmi.c:1407:16: error: incompatible function pointer types initializing 'enum drm_mode_status (*)(struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' with an expression of type 'int (struct drm_bridge *, const struct drm_display_info *, const struct drm_display_mode *)' [-Werror,-Wincompatible-function-pointer-types-strict]
.mode_valid = mtk_hdmi_bridge_mode_valid,
^~~~~~~~~~~~~~~~~~~~~~~~~~
1 error generated.
->mode_valid() in 'struct drm_bridge_funcs' expects a return type of
'enum drm_mode_status', not 'int'. Adjust the return type of
mtk_hdmi_bridge_mode_valid() to match the prototype's to resolve the
warning and CFI failure.
Link: https://github.com/ClangBuiltLinux/linux/issues/1750
Reported-by: Sami Tolvanen <samitolvanen@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Reviewed-by: AngeloGioacchino Del Regno <angelogioacchino.delregno@collabora.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
[Why]
Some userspaces assume that the first connected connector is the "main"
display, which supposed to display, for example, the login screen.
For laptops, this should be the internal connector.
[How]
This patch calls drm_helper_move_panel_connectors_to_head() right before
crtc creation to ensure internal connectors are at the top of the
connector list.
Tested by ensuring the internal panels are at the top of the connector
list via modetest -c.
This patch does to mediatek what the following patch
https://www.spinics.net/lists/stable/msg590605.html
did for qualcomm.
Signed-off-by: Gil Dekel <gildekel@chromium.org>
Tested-by: Gil Dekel <gildekel@chromium.org>
Reviewed-by: Sean Paul <seanpaul@chromium.org>
Reviewed-by: Chen-Yu Tsai <wenst@chromium.org>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Nothing in this file needs anything from linux/msi.h
Signed-off-by: Thomas Gleixner <tglx@linutronix.de>
Cc: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Cc: linux-ide@vger.kernel.org
Signed-off-by: Damien Le Moal <damien.lemoal@opensource.wdc.com>
Modify dpi power on/off sequence so that the first gpio operation will
take effect.
Fixes: 6bd4763fd5 ("drm/mediatek: set dpi pin mode to gpio low to avoid leakage current")
Signed-off-by: Xinlei Lee <xinlei.lee@mediatek.com>
Signed-off-by: Chun-Kuang Hu <chunkuang.hu@kernel.org>
Add support for dma-channel-mask so that only the specified channels
are used. This helps to reserve some channels for the firmware.
This was initially achieved by limiting the channel number to 31 in
the driver and adjusting the register address to skip channel0 which
was reserved for a firmware. This is wrong and does not align with
the hardware.
Now, with this change, the driver can align more to the actual hardware
which has 32 channels. But this implies that there will be a break in the
ABI and the device tree need to be updated along with this change for the
driver to pickup the right interrupt corresponding to the channel
Reviewed-by: Jon Hunter <jonathanh@nvidia.com>
Link: https://lore.kernel.org/all/Y2EFoG1H9YpfxRjs@orome/
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Link: https://lore.kernel.org/r/20221110171748.40304-4-akhilrajeev@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Add dma-channel-mask property in Tegra GPCDMA document.
The property would help to specify the channels to be used in
kernel and reserve few for the firmware. This was previously
achieved by limiting the channel number to 31 in the driver.
This is wrong and does not align with the hardware. Correct
this and set the max interrupts to 32.
Signed-off-by: Akhil R <akhilrajeev@nvidia.com>
Acked-by: Thierry Reding <treding@nvidia.com>
Acked-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221110171748.40304-2-akhilrajeev@nvidia.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Document the compatible for GPI DMA controller on SM6375 SoC.
Signed-off-by: Konrad Dybcio <konrad.dybcio@linaro.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Link: https://lore.kernel.org/r/20221109111236.46003-3-konrad.dybcio@linaro.org
Signed-off-by: Vinod Koul <vkoul@kernel.org>
The crc_val in the completion record should be 64 bits and not 32 bits.
Fixes: 4ac823e9cd ("dmaengine: idxd: fix delta_rec and crc size field for completion record")
Reported-by: Nirav N Shah <nirav.n.shah@intel.com>
Signed-off-by: Fenghua Yu <fenghua.yu@intel.com>
Reviewed-by: Dave Jiang <dave.jiang@intel.com>
Link: https://lore.kernel.org/r/20221111012715.2031481-1-fenghua.yu@intel.com
Signed-off-by: Vinod Koul <vkoul@kernel.org>
- check kmalloc failures in Loongson64 kexec
- fix builds with clang-14
- fix char/int handling in pic32
-----BEGIN PGP SIGNATURE-----
iQJOBAABCAA4FiEEbt46xwy6kEcDOXoUeZbBVTGwZHAFAmNw8WkaHHRzYm9nZW5k
QGFscGhhLmZyYW5rZW4uZGUACgkQeZbBVTGwZHCdPQ//a3bRPpetxO3Feg4ETBxd
bsk4Zu9YEwwXzghBRAV09iAwuI/0sw79g8I49zAW1yOO5L0Y8UJGybpoxdhXEwhB
yX5yWrh+oM4ktwX5uJGD0r+q1GH4bqM245L08g0Ry3u19aux9LdhH3rMC4XZOb+Q
L6op6TALI+zv6O4+7RTY/kKxOds/So6D3ZuZUoy3DF0EYj8ij4eXQ8w/HNz/wYqo
tmgoYM6JT+E6jDRGFoMtj4bUnC1tt3aTBMYSiHw+fMTRFn7p/pWnMBMbsfN8WY4Q
qUTPTZj28s0azgWqar5yoGbVYqnDKEzTuSMxIScNlyf2jmOecC1WcEJIxqEOmRui
fPrBNffeR88bG1qofUeBE9ctoOqf20pcCUQrFYdCA51R6dDa1Pamn3gwql2Df6/Y
7AUSUSl/1mWQv4vt1+QQ87Jwi9nteJ7LomPspKBTRFE6okLa0XVVSViCDqrwS0lj
QgGdkgzSHn2wDd4+tc5NNDMhjW4df/u52+MH62J8S4CnextNtfMKacPuwidARABn
acT1oVkInUM5bBvEEuaK++tuFDixfse0eQSnUlq7FoIIjm0nKDUIYEWgClzFdJRT
i5ErRIFPTcJd2UUM1d8dQ9F8A/5q54UBHvDiTtD3Fet2+YqaFww+6FYid8qXWYkg
mW+DHzZaxyPrd8cV2v4Ka1M=
=OtmI
-----END PGP SIGNATURE-----
Merge tag 'mips-fixes_6.1_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux
Pull MIPS fixes from Thomas Bogendoerfer:
- fix jump label branch range check
- check kmalloc failures in Loongson64 kexec
- fix builds with clang-14
- fix char/int handling in pic32
* tag 'mips-fixes_6.1_1' of git://git.kernel.org/pub/scm/linux/kernel/git/mips/linux:
MIPS: pic32: treat port as signed integer
MIPS: jump_label: Fix compat branch range check
mips: alchemy: gpio: Include the right header
MIPS: Loongson64: Add WARN_ON on kexec related kmalloc failed
MIPS: fix duplicate definitions for exported symbols
mips: boot/compressed: use __NO_FORTIFY
- Force the use of SetVirtualAddressMap() on Ampera Altra arm64
machines, which crash in SetTime() if no virtual remapping is used
- Drop a spurious warning on misaligned runtime regions when using 16k
or 64k pages on arm64
-----BEGIN PGP SIGNATURE-----
iQGzBAABCgAdFiEE+9lifEBpyUIVN1cpw08iOZLZjyQFAmNvduwACgkQw08iOZLZ
jySmkgv9GTFJUWJY1JWsQZf2OB+Ui2JAVCPJVbLGzDxWEFY/z+mgAcC6rJ6+T0Ju
9fNNBnFXeSq5bOPqGFcBOsLxHcP1KpNQHNKHjFUv9RovQGiMD29Fl3kT8XiuqtsB
SJcilTJs+J6umBOX+yQ1oho0P5eq/LkvDW3AFxzxrHAl/k9U0eePLIBAgIXS8Iuf
wZP3b2Bqt0z9b6JBFBKmXlLTC1WGdoVPmcXc2n+6O3c4MxUrZnbDk9Ou8vA1sCy5
JO4GlU0qvHercsZwcRRcdsKeQPpXIeDDOklUkicxsuYVhi7ipIfLdYsMwFkxGp22
IhXfxfV8OyJm71uD4z7EJAIgZibG86UQlh3Lib5846xYAGbZiUx3CaiiPBgHXgeV
PUy4FtYPlf0u8epC2QWKC3FGRIpkcAVwmZPnNvXV+NFg1wzd2B1dGFJajvCKfW93
joBsdWLUZABj5bNtSyLlaswT6gHt58w6PkHaqwi3mQaZs0oNt01iLbZCMy33y4A+
+jhAY/FE
=sWO/
-----END PGP SIGNATURE-----
Merge tag 'efi-fixes-for-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi
Pull EFI fixes from Ard Biesheuvel:
- Force the use of SetVirtualAddressMap() on Ampera Altra arm64
machines, which crash in SetTime() if no virtual remapping is used
This is the first time we've added an SMBIOS based quirk on arm64,
but fortunately, we can just call a EFI protocol to grab the type #1
SMBIOS record when running in the stub, so we don't need all the
machinery we have in the kernel proper to parse SMBIOS data.
- Drop a spurious warning on misaligned runtime regions when using 16k
or 64k pages on arm64
* tag 'efi-fixes-for-v6.1-3' of git://git.kernel.org/pub/scm/linux/kernel/git/efi/efi:
arm64: efi: Fix handling of misaligned runtime regions and drop warning
arm64: efi: Force the use of SetVirtualAddressMap() on Altra machines
In 4053d2500b ("orangefs: rework posix acl handling when creating new
filesystem objects") we tried to precalculate the correct mode when
creating a new inode. However, this leads to regressions when creating new
filesystem objects.
Even if we precalculate the mode we still need to call __orangefs_setattr()
to perform additional checks and we also need to update the mode of
ACL_TYPE_ACCESS acls set on the inode. The patch referenced above regressed
that. Restore that part of the old behavior and remove the mode
precalculation as it doesn't get us anything anymore.
Fixes: 4053d2500b ("orangefs: rework posix acl handling when creating new filesystem objects")
Reported-by: Mike Marshall <hubcap@omnibond.com>
Signed-off-by: Christian Brauner (Microsoft) <brauner@kernel.org>
Ths PMIC's interrupt line is tied to GPIO0_A3. This is described
correctly for the pinmux setting, but incorrectly for the interrupt.
Correct the interrupt setting so that interrupts from the PMIC get
delivered.
Fixes: dcc8c66bef ("arm64: dts: rockchip: add Pine64 Quartz64-B device tree")
Signed-off-by: Chen-Yu Tsai <wens@csie.org>
Reviewed-by: Peter Geis <pgwipeout@gmail.com>
Link: https://lore.kernel.org/r/20221106161513.4140-1-wens@kernel.org
Signed-off-by: Heiko Stuebner <heiko@sntech.de>
Based on the test results of kallsyms_on_each_match_symbol() and
kallsyms_on_each_symbol(), the average performance can be improved by
more than 1500 times.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Function kallsyms_on_each_symbol() traverses all symbols and submits each
symbol to the hook 'fn' for judgment and processing. For some cases, the
hook actually only handles the matched symbol, such as livepatch.
Because all symbols are currently sorted by name, all the symbols with the
same name are clustered together. Function kallsyms_lookup_names() gets
the start and end positions of the set corresponding to the specified
name. So we can easily and quickly traverse all the matches.
The test results are as follows (twice): (x86)
kallsyms_on_each_match_symbol: 7454, 7984
kallsyms_on_each_symbol : 11733809, 11785803
kallsyms_on_each_match_symbol() consumes only 0.066% of
kallsyms_on_each_symbol()'s time. In other words, 1523x better
performance.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
kallsyms_seqs_of_names[] records the symbol index sorted by address, the
maximum value in kallsyms_seqs_of_names[] is the number of symbols. And
2^24 = 16777216, which means that three bytes are enough to store the
index. This can help us save (1 * kallsyms_num_syms) bytes of memory.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
LLVM appends various suffixes for local functions and variables, suffixes
observed:
- foo.llvm.[0-9a-f]+
- foo.[0-9a-f]+
Therefore, when CONFIG_LTO_CLANG=y, kallsyms_lookup_name() needs to
truncate the suffix of the symbol name before comparing the local function
or variable name.
Old implementation code:
- if (strcmp(namebuf, name) == 0)
- return kallsyms_sym_address(i);
- if (cleanup_symbol_name(namebuf) && strcmp(namebuf, name) == 0)
- return kallsyms_sym_address(i);
The preceding process is traversed by address from low to high. That is,
for those with the same name after the suffix is removed, the one with
the smallest address is returned first. Therefore, when sorting in the
tool, if the raw names are the same, they should be sorted by address in
ascending order.
ASCII[.] = 2e
ASCII[0-9] = 30,39
ASCII[A-Z] = 41,5a
ASCII[_] = 5f
ASCII[a-z] = 61,7a
According to the preceding ASCII code values, the following sorting result
is strictly followed.
---------------------------------
| main-key | sub-key |
|---------------------------------|
| | addr_lowest |
| <name> | ... |
| <name>.<suffix> | ... |
| | addr_highest |
|---------------------------------|
| <name>?<others> | | //? is [_A-Za-z0-9]
---------------------------------
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Currently, to search for a symbol, we need to expand the symbols in
'kallsyms_names' one by one, and then use the expanded string for
comparison. It's O(n).
If we sort names in ascending order like addresses, we can also use
binary search. It's O(log(n)).
In order not to change the implementation of "/proc/kallsyms", the table
kallsyms_names[] is still stored in a one-to-one correspondence with the
address in ascending order.
Add array kallsyms_seqs_of_names[], it's indexed by the sequence number
of the sorted names, and the corresponding content is the sequence number
of the sorted addresses. For example:
Assume that the index of NameX in array kallsyms_seqs_of_names[] is 'i',
the content of kallsyms_seqs_of_names[i] is 'k', then the corresponding
address of NameX is kallsyms_addresses[k]. The offset in kallsyms_names[]
is get_symbol_offset(k).
Note that the memory usage will increase by (4 * kallsyms_num_syms)
bytes, the next two patches will reduce (1 * kallsyms_num_syms) bytes
and properly handle the case CONFIG_LTO_CLANG=y.
Performance test results: (x86)
Before:
min=234, max=10364402, avg=5206926
min=267, max=11168517, avg=5207587
After:
min=1016, max=90894, avg=7272
min=1014, max=93470, avg=7293
The average lookup performance of kallsyms_lookup_name() improved 715x.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
Except for the function build_initial_tok_table(), no token abbreviation
is used elsewhere.
$ cat scripts/kallsyms.c | grep tok | wc -l
33
$ cat scripts/kallsyms.c | grep token | wc -l
31
Here, it would be clearer to use the full name.
Signed-off-by: Zhen Lei <thunder.leizhen@huawei.com>
Reviewed-by: Petr Mladek <pmladek@suse.com>
Signed-off-by: Luis Chamberlain <mcgrof@kernel.org>
This patch adds IRQ support to the PASemi I2C controller driver to
increase the performace of I2C transactions on platforms with PASemi I2C
controllers. While primarily intended for Apple silicon platforms, this
patch should also help in enabling IRQ support for older PASemi hardware
as well should the need arise.
This version of the patch has been tested on an M1 Ultra Mac Studio,
as well as an M1 MacBook Pro, and userspace launches successfully
while using the IRQ path for I2C transactions.
Signed-off-by: Arminder Singh <arminders208@outlook.com>
Reviewed-by: Sven Peter <sven@svenpeter.dev>
Reviewed-by: Hector Martin <marcan@marcan.st>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
A problem about i2c-npcm7xx create debugfs failed is triggered with the
following log given:
[ 173.827310] debugfs: Directory 'npcm_i2c' with parent '/' already present!
The reason is that npcm_i2c_init() returns platform_driver_register()
directly without checking its return value, if platform_driver_register()
failed, it returns without destroy the newly created debugfs, resulting
the debugfs of npcm_i2c can never be created later.
npcm_i2c_init()
debugfs_create_dir() # create debugfs directory
platform_driver_register()
driver_register()
bus_add_driver()
priv = kzalloc(...) # OOM happened
# return without destroy debugfs directory
Fix by removing debugfs when platform_driver_register() returns error.
Fixes: 56a1485b10 ("i2c: npcm7xx: Add Nuvoton NPCM I2C controller driver")
Signed-off-by: Yuan Can <yuancan@huawei.com>
Reviewed-by: Tali Perry <tali.perry@nuvoton.com>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
Convert platform_get_resource(), devm_ioremap_resource() to a single
call to devm_platform_get_and_ioremap_resource(), as this is exactly
what this function does.
Reported-by: Zeal Robot <zealci@zte.com.cn>
Signed-off-by: Minghao Chi <chi.minghao@zte.com.cn>
Reviewed-by: Mukesh Ojha <quic_mojha@quicinc.com>
Reviewed-by: Uwe Kleine-König <u.kleine-koenig@pengutronix.de>
Signed-off-by: Wolfram Sang <wsa@kernel.org>
There were two patches which addressed the same bug and added the same
condition:
commit 6db620863f ("fs/ntfs3: Validate data run offset")
commit 887bfc5460 ("fs/ntfs3: Fix slab-out-of-bounds read in run_unpack")
Delete one condition.
Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Add documentation for system.ntfs_attrib_be extended attribute.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
NTFS-3G provides the system.ntfs_attrib_be extended attribute, which
has the same value as system.ntfs_attrib but represented in big-endian.
Some utilities rely on the existence of this extended attribute.
Improves compatibility with NTFS-3G by adding the system.ntfs_attrib_be
extended attribute.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
The hidedotfiles mount option provides the same functionality as
the NTFS-3G hide_dot_files mount option. As such, it should be
named the same for compatibility with NTGS-3G.
Rename the hidedotfiles to hide_dot_files for compatbility with
NTFS-3G.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Add documentation for the hidedotfiles mount option.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Currently, the ntfs3 driver does return the hidedotfiles mount
option in the list of enabled mount options. This can confuse
users who may doubt they enabled the option when not seeing in
the list provided by the mount command.
Add hidedotfiles mount option to the list of enabled options
provided by the mount command when it is enabled.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Currently, the hidedotfiles mount option only has an effect when
creating new files. Removing or adding the starting dot when moving
or renaming files does not update the hidden attribute.
Make hidedotfiles also set or uset the hidden attribute when a file
gains or loses its starting dot by being moved or renamed.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Currently, the hidedotfiles mount option is behaving in the reverse
way of what would be expected: enabling it disables setting the
hidden attribute on files or directories with names starting with a
dot and disabling it enables the setting.
Reverse the behaviour of the hidedotfiles mount option so it matches
what is expected.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Add documentation for windows_names mount option.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
When enabled, the windows_names mount option prevents the creation
of files or directories with names not allowed by Windows. Use
the same option name as NTFS-3G for compatibility.
Signed-off-by: Daniel Pinto <danielpinto52@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
'a == b ? 0 : 1' is logically equivalent to 'a != b'.
Suggested-by: Nick Desaulniers <ndesaulniers@google.com>
Signed-off-by: Nathan Chancellor <nathan@kernel.org>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
The data_size and valid_size fields of non resident attributes should be
less than the its alloc_size field, but this is not checked in
ntfs_read_mft function.
Syzbot reports a allocation order warning due to a large unchecked value
of data_size getting assigned to inode->i_size which is then passed to
kcalloc.
Add sanity check for ensuring that the data_size and valid_size fields
are not larger than alloc_size field.
Link: https://syzkaller.appspot.com/bug?extid=fa4648a5446460b7b963
Reported-and-tested-by: syzbot+fa4648a5446460b7b963@syzkaller.appspotmail.com
Fixes: (82cae269cf) fs/ntfs3: Add initialization of super block
Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
syzbot is reporting too large allocation at ntfs_fill_super() [1], for a
crafted filesystem can contain bogus inode->i_size. Add __GFP_NOWARN in
order to avoid too large allocation warning, than exhausting memory by
using kvmalloc().
Link: https://syzkaller.appspot.com/bug?extid=33f3faaa0c08744f7d40 [1]
Reported-by: syzot <syzbot+33f3faaa0c08744f7d40@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
syzbot is reporting too large allocation at wnd_init() [1], for a crafted
filesystem can become wnd->nwnd close to UINT_MAX. Add __GFP_NOWARN in
order to avoid too large allocation warning, than exhausting memory by
using kvcalloc().
Link: https://syzkaller.appspot.com/bug?extid=fa4648a5446460b7b963 [1]
Reported-by: syzot <syzbot+fa4648a5446460b7b963@syzkaller.appspotmail.com>
Signed-off-by: Tetsuo Handa <penguin-kernel@I-love.SAKURA.ne.jp>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
Syzbot reports an out of bound access in ntfs_trim_fs.
The cause of this is using a loop termination condition that compares
window index (iw) with wnd->nbits instead of wnd->nwnd, due to which the
index used for wnd->free_bits exceeds the size of the array allocated.
Fix the loop condition.
Fixes: 3f3b442b5a ("fs/ntfs3: Add bitmap")
Link: https://syzkaller.appspot.com/bug?extid=b892240eac461e488d51
Reported-by: syzbot+b892240eac461e488d51@syzkaller.appspotmail.com
Signed-off-by: Abdun Nihaal <abdun.nihaal@gmail.com>
Signed-off-by: Konstantin Komarov <almaz.alexandrovich@paragon-software.com>
In iio_register_sw_trigger_type(), configfs_register_default_group() is
possible to fail, but the entry add to iio_trigger_types_list is not
deleted.
This leaves wild in iio_trigger_types_list, which can cause page fault
when module is loading again. So fix this by list_del(&t->list) in error
path.
BUG: unable to handle page fault for address: fffffbfff81d7400
Call Trace:
<TASK>
iio_register_sw_trigger_type
do_one_initcall
do_init_module
load_module
...
Fixes: b662f809d4 ("iio: core: Introduce IIO software triggers")
Signed-off-by: Chen Zhongjin <chenzhongjin@huawei.com>
Link: https://lore.kernel.org/r/20221108032802.168623-1-chenzhongjin@huawei.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
When regmap_bulk_read() fails, it does not free steps_raw,
which will cause a memory leak issue, this patch fixes it.
Fixes: d221de60ee ("iio: accel: bma400: Add separate channel for step counter")
Signed-off-by: Dong Chenchen <dongchenchen2@huawei.com>
Reviewed-by: Jagath Jog J <jagathjog1996@gmail.com>
Link: https://lore.kernel.org/r/20221110010726.235601-1-dongchenchen2@huawei.com
Cc: <Stable@vger.kernel.org>
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Fix an implicit declaration of function error for rpr0521 under some configs
When CONFIG_RPR0521 is enabled without CONFIG_IIO_TRIGGERED_BUFFER,
the build results in "implicit declaration of function" errors, e.g.,
drivers/iio/light/rpr0521.c:434:3: error: implicit declaration of function
'iio_trigger_poll_chained' [-Werror=implicit-function-declaration]
434 | iio_trigger_poll_chained(data->drdy_trigger0);
| ^~~~~~~~~~~~~~~~~~~~~~~~
This fix adds select dependencies to RPR0521's configuration declaration.
Fixes: e12ffd241c ("iio: light: rpr0521 triggered buffer")
Signed-off-by: Paul Gazzillo <paul@pgazz.com>
Link: https://bugzilla.kernel.org/show_bug.cgi?id=216678
Reviewed-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Link: https://lore.kernel.org/r/20221110214729.ls5ixav5kxpeftk7@device
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Three small fixes, all in drivers. The sas one is in an unlikely
error leg, the debug one is to make it more standards conformant and
the ibmvfc one is to fix a user visible bug where a failover could
lose all paths to the device.
Signed-off-by: James E.J. Bottomley <jejb@linux.ibm.com>
-----BEGIN PGP SIGNATURE-----
iJwEABMIAEQWIQTnYEDbdso9F2cI+arnQslM7pishQUCY2+0+iYcamFtZXMuYm90
dG9tbGV5QGhhbnNlbnBhcnRuZXJzaGlwLmNvbQAKCRDnQslM7pishXfTAQCxqdCV
jb6MSs0IqB/EtTWYhq6znt6Tz4f544+esrtn+wEAxD5G8+6p7hbKi9GzPz4vLke4
sTT3xTOd4I2iLaaM3p0=
=v1jf
-----END PGP SIGNATURE-----
Merge tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi
Pull SCSI fixes from James Bottomley:
"Three small fixes, all in drivers.
The sas one is in an unlikely error leg, the debug one is to make it
more standards conformant and the ibmvfc one is to fix a user visible
bug where a failover could lose all paths to the device"
* tag 'scsi-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/jejb/scsi:
scsi: scsi_debug: Make the READ CAPACITY response compliant with ZBC
scsi: scsi_transport_sas: Fix error handling in sas_phy_add()
scsi: ibmvfc: Avoid path failures during live migration
This contains a regression fix for the latest memalloc helper change.
-----BEGIN PGP SIGNATURE-----
iQJCBAABCAAsFiEEIXTw5fNLNI7mMiVaLtJE4w1nLE8FAmNvXmoOHHRpd2FpQHN1
c2UuZGUACgkQLtJE4w1nLE8xuw//fsXClcYR8PhY6TEMc1NvSJkVC0AsWNLQ3eMs
YpiEBgzHn99YPGZx5cIiTES1e3HI0OgibnWEvF60rizjPeDELL1mJLAuupxjwRsE
m1XsOuJ9AXDWdcwHZ/9Nh5A394El8fGo5au8IkOREMhHaMgwkWE7mVfl6h26qY8w
0F6//MLuFNEuyWXAeZk9QqtYUpfIBf8xBGFkL0fa5dtTQ0NsqwGmoQx/WArk7E6U
HrVL+x1mwZaK+8gSrbFdaAew8dxF1CAdk1XOVFiN8nvnN+Zvl7P1/WwU1u9FyAIC
tcV7zqklv4oKGH2iRZzT+3TGDT5HN0ylzMKc0EAuBGKgveuw1BUIJo9QZ7frturh
FCv/iOly1UP9lHFqoCrgBq4192gNwO2YNoLP3991iHVFliq9wS2Kk5QjGpVk49Z6
6ujZlq8lvGgf+9/dEwfAxQmd2GjGU1fcg86e8trrgFaE5ESphyLWposLEPAxVQ+6
EB1aeiLPrweS7IQ4qC6KHiS5tG6TZR3DUmKbjmwLB8+T/UALkcRY6wj8P0u9kUdH
XWLrKmUv2ExysR0Pd2Hu2dMm2XX3fs5WgAtfRYrcNT2zKUemhbwIYubBkd9F6deb
CMI8MomWOLC5KqEbNuOvMVOTavyPNFVh0LxVnwy2SK1rgxvwW1CfZaJFy1/noWqf
GK4AdhY=
=sSea
-----END PGP SIGNATURE-----
Merge tag 'sound-fix-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound
Pull additional sound fix from Takashi Iwai:
"A regression fix for the latest memalloc helper change"
* tag 'sound-fix-6.1-rc5' of git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound:
ALSA: memalloc: Try dma_alloc_noncontiguous() at first
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4404_read_raw+0x2ce/0x380
Read of size 4 at addr ffffffffc00e4658 by task cat/278
Call Trace:
afe4404_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4404_channel_leds+0x18/0xffffffffffffe9c0
This issue can be reproduce by singe command:
$ cat /sys/bus/i2c/devices/0-0058/iio\:device0/in_intensity6_raw
The array size of afe4404_channel_leds and afe4404_channel_offdacs
are less than channels, so access with chan->address cause OOB read
in afe4404_[read|write]_raw. Fix it by moving access before use them.
Fixes: b36e825764 ("iio: health/afe440x: Use regmap fields")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20221107152010.95937-1-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
KASAN report out-of-bounds read as follows:
BUG: KASAN: global-out-of-bounds in afe4403_read_raw+0x42e/0x4c0
Read of size 4 at addr ffffffffc02ac638 by task cat/279
Call Trace:
afe4403_read_raw
iio_read_channel_info
dev_attr_show
The buggy address belongs to the variable:
afe4403_channel_leds+0x18/0xffffffffffffe9e0
This issue can be reproduced by singe command:
$ cat /sys/bus/spi/devices/spi0.0/iio\:device0/in_intensity6_raw
The array size of afe4403_channel_leds is less than channels, so access
with chan->address cause OOB read in afe4403_read_raw. Fix it by moving
access before use it.
Fixes: b36e825764 ("iio: health/afe440x: Use regmap fields")
Signed-off-by: Wei Yongjun <weiyongjun1@huawei.com>
Acked-by: Andrew Davis <afd@ti.com>
Link: https://lore.kernel.org/r/20221107151946.89260-1-weiyongjun@huaweicloud.com
Signed-off-by: Jonathan Cameron <Jonathan.Cameron@huawei.com>
Jeffrey added Multi-MSI support to the pci-hyperv driver by the 4 patches:
08e61e861a ("PCI: hv: Fix multi-MSI to allow more than one MSI vector")
455880dfe2 ("PCI: hv: Fix hv_arch_irq_unmask() for multi-MSI")
b4b77778ec ("PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()")
a2bad844a6 ("PCI: hv: Fix interrupt mapping for multi-MSI")
It turns out that the third patch (b4b77778ec) causes a performance
regression because all the interrupts now happen on 1 physical CPU (or two
pCPUs, if one pCPU doesn't have enough vectors). When a guest has many PCI
devices, it may suffer from soft lockups if the workload is heavy, e.g.,
see https://lwn.net/ml/linux-kernel/20220804025104.15673-1-decui@microsoft.com/
Commit b4b77778ec itself is good. The real issue is that the hypercall in
hv_irq_unmask() -> hv_arch_irq_unmask() ->
hv_do_hypercall(HVCALL_RETARGET_INTERRUPT...) only changes the target
virtual CPU rather than physical CPU; with b4b77778ec, the pCPU is
determined only once in hv_compose_msi_msg() where only vCPU0 is specified;
consequently the hypervisor only uses 1 target pCPU for all the interrupts.
Note: before b4b77778ec, the pCPU is determined twice, and when the pCPU
is determined the second time, the vCPU in the effective affinity mask is
used (i.e., it isn't always vCPU0), so the hypervisor chooses different
pCPU for each interrupt.
The hypercall will be fixed in future to update the pCPU as well, but
that will take quite a while, so let's restore the old behavior in
hv_compose_msi_msg(), i.e., don't reuse the existing IRTE allocation for
single-MSI and MSI-X; for multi-MSI, we choose the vCPU in a round-robin
manner for each PCI device, so the interrupts of different devices can
happen on different pCPUs, though the interrupts of each device happen on
some single pCPU.
The hypercall fix may not be backported to all old versions of Hyper-V, so
we want to have this guest side change forever (or at least till we're sure
the old affected versions of Hyper-V are no longer supported).
Fixes: b4b77778ec ("PCI: hv: Reuse existing IRTE allocation in compose_msi_msg()")
Co-developed-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Signed-off-by: Jeffrey Hugo <quic_jhugo@quicinc.com>
Co-developed-by: Carl Vanderlip <quic_carlv@quicinc.com>
Signed-off-by: Carl Vanderlip <quic_carlv@quicinc.com>
Signed-off-by: Dexuan Cui <decui@microsoft.com>
Reviewed-by: Michael Kelley <mikelley@microsoft.com>
Link: https://lore.kernel.org/r/20221104222953.11356-1-decui@microsoft.com
Signed-off-by: Wei Liu <wei.liu@kernel.org>
