Looking at the conditional lock acquire functions in the kernel due to
the new sparse support (see commit 4a557a5d1a "sparse: introduce
conditional lock acquire function attribute"), it became obvious that
the lockref code has a couple of them, but they don't match the usual
naming convention for the other ones, and their return value logic is
also reversed.
In the other very similar places, the naming pattern is '*_and_lock()'
(eg 'atomic_put_and_lock()' and 'refcount_dec_and_lock()'), and the
function returns true when the lock is taken.
The lockref code is superficially very similar to the refcount code,
only with the special "atomic wrt the embedded lock" semantics. But
instead of the '*_and_lock()' naming it uses '*_or_lock()'.
And instead of returning true in case it took the lock, it returns true
if it *didn't* take the lock.
Now, arguably the reflock code is quite logical: it really is a "either
decrement _or_ lock" kind of situation - and the return value is about
whether the operation succeeded without any special care needed.
So despite the similarities, the differences do make some sense, and
maybe it's not worth trying to unify the different conditional locking
primitives in this area.
But while looking at this all, it did become obvious that the
'lockref_get_or_lock()' function hasn't actually had any users for
almost a decade.
The only user it ever had was the shortlived 'd_rcu_to_refcount()'
function, and it got removed and replaced with 'lockref_get_not_dead()'
back in 2013 in commits 0d98439ea3 ("vfs: use lockred 'dead' flag to
mark unrecoverably dead dentries") and e5c832d555 ("vfs: fix dentry
RCU to refcounting possibly sleeping dput()")
In fact, that single use was removed less than a week after the whole
function was introduced in commit b3abd80250 ("lockref: add
'lockref_get_or_lock() helper") so this function has been around for a
decade, but only had a user for six days.
Let's just put this mis-designed and unused function out of its misery.
We can think about the naming and semantic oddities of the remaining
'lockref_put_or_lock()' later, but at least that function has users.
And while the naming is different and the return value doesn't match,
that function matches the whole '{atomic,refcount}_dec_and_test()'
pattern much better (ie the magic happens when the count goes down to
zero, not when it is incremented from zero).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Qualcomm ARM64 DT fixes for v5.19
This removes duplicate includes in the sc7180-trogdor files, which
accidentally ended up disabling nodes intended to be enabled.
It corrects identifiers for CPU6/7 on MSM8994. On SM8450 the UFS node's
interconnects property is updated to match the #interconnect-cells,
avoiding sync_state issues and the GIC ITS is defined, to correct the
references from the PCIe nodes. On SDM845 the display subsystem's AHB
clock is corrected and on msm8992 devices, the supplies for lvs 1 and 2
are correctly specified.
Lastly, a welcome addition of Konrad as reviewer for the Qualcomm SoC.
* tag 'qcom-arm64-fixes-for-5.19' of git://git.kernel.org/pub/scm/linux/kernel/git/qcom/linux:
arm64: dts: qcom: msm8992-*: Fix vdd_lvs1_2-supply typo
MAINTAINERS: Add myself as a reviewer for Qualcomm ARM/64 support
arm64: dts: qcom: sdm845: use dispcc AHB clock for mdss node
arm64: dts: qcom: sm8450 add ITS device tree node
arm64: dts: qcom: msm8994: Fix CPU6/7 reg values
arm64: dts: qcom: sm8450: fix interconnects property of UFS node
arm64: dts: qcom: Remove duplicate sc7180-trogdor include on lazor/homestar
Link: https://lore.kernel.org/r/20220703030208.408109-1-bjorn.andersson@linaro.org
Signed-off-by: Arnd Bergmann <arnd@arndb.de>
The kernel tends to try to avoid conditional locking semantics because
it makes it harder to think about and statically check locking rules,
but we do have a few fundamental locking primitives that take locks
conditionally - most obviously the 'trylock' functions.
That has always been a problem for 'sparse' checking for locking
imbalance, and we've had a special '__cond_lock()' macro that we've used
to let sparse know how the locking works:
# define __cond_lock(x,c) ((c) ? ({ __acquire(x); 1; }) : 0)
so that you can then use this to tell sparse that (for example) the
spinlock trylock macro ends up acquiring the lock when it succeeds, but
not when it fails:
#define raw_spin_trylock(lock) __cond_lock(lock, _raw_spin_trylock(lock))
and then sparse can follow along the locking rules when you have code like
if (!spin_trylock(&dentry->d_lock))
return LRU_SKIP;
.. sparse sees that the lock is held here..
spin_unlock(&dentry->d_lock);
and sparse ends up happy about the lock contexts.
However, this '__cond_lock()' use does result in very ugly header files,
and requires you to basically wrap the real function with that macro
that uses '__cond_lock'. Which has made PeterZ NAK things that try to
fix sparse warnings over the years [1].
To solve this, there is now a very experimental patch to sparse that
basically does the exact same thing as '__cond_lock()' did, but using a
function attribute instead. That seems to make PeterZ happy [2].
Note that this does not replace existing use of '__cond_lock()', but
only exposes the new proposed attribute and uses it for the previously
unannotated 'refcount_dec_and_lock()' family of functions.
For existing sparse installations, this will make no difference (a
negative output context was ignored), but if you have the experimental
sparse patch it will make sparse now understand code that uses those
functions, the same way '__cond_lock()' makes sparse understand the very
similar 'atomic_dec_and_lock()' uses that have the old '__cond_lock()'
annotations.
Note that in some cases this will silence existing context imbalance
warnings. But in other cases it may end up exposing new sparse warnings
for code that sparse just didn't see the locking for at all before.
This is a trial, in other words. I'd expect that if it ends up being
successful, and new sparse releases end up having this new attribute,
we'll migrate the old-style '__cond_lock()' users to use the new-style
'__cond_acquires' function attribute.
The actual experimental sparse patch was posted in [3].
Link: https://lore.kernel.org/all/20130930134434.GC12926@twins.programming.kicks-ass.net/ [1]
Link: https://lore.kernel.org/all/Yr60tWxN4P568x3W@worktop.programming.kicks-ass.net/ [2]
Link: https://lore.kernel.org/all/CAHk-=wjZfO9hGqJ2_hGQG3U_XzSh9_XaXze=HgPdvJbgrvASfA@mail.gmail.com/ [3]
Acked-by: Peter Zijlstra <peterz@infradead.org>
Cc: Alexander Aring <aahringo@redhat.com>
Cc: Luc Van Oostenryck <luc.vanoostenryck@gmail.com>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Pull xfs fixes from Darrick Wong:
"This fixes some stalling problems and corrects the last of the
problems (I hope) observed during testing of the new atomic xattr
update feature.
- Fix statfs blocking on background inode gc workers
- Fix some broken inode lock assertion code
- Fix xattr leaf buffer leaks when cancelling a deferred xattr update
operation
- Clean up xattr recovery to make it easier to understand.
- Fix xattr leaf block verifiers tripping over empty blocks.
- Remove complicated and error prone xattr leaf block bholding mess.
- Fix a bug where an rt extent crossing EOF was treated as "posteof"
blocks and cleaned unnecessarily.
- Fix a UAF when log shutdown races with unmount"
* tag 'xfs-5.19-fixes-4' of git://git.kernel.org/pub/scm/fs/xfs/xfs-linux:
xfs: prevent a UAF when log IO errors race with unmount
xfs: dont treat rt extents beyond EOF as eofblocks to be cleared
xfs: don't hold xattr leaf buffers across transaction rolls
xfs: empty xattr leaf header blocks are not corruption
xfs: clean up the end of xfs_attri_item_recover
xfs: always free xattri_leaf_bp when cancelling a deferred op
xfs: use invalidate_lock to check the state of mmap_lock
xfs: factor out the common lock flags assert
xfs: introduce xfs_inodegc_push()
xfs: bound maximum wait time for inodegc work
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Insufficient validation of element datatype and length in
nft_setelem_parse_data(). At least commit 7d7402642e updates
maximum element data area up to 64 bytes when only 16 bytes
where supported at the time. Support for larger element size
came later in fdb9c405e3 though. Picking this older commit
as Fixes: tag to be safe than sorry.
2) Memleak in pipapo destroy path, reproducible when transaction
in aborted. This is already triggering in the existing netfilter
test infrastructure since more recent new tests are covering this
path.
====================
Signed-off-by: David S. Miller <davem@davemloft.net>
Trogdor devices that have a detachable keyboard still have a
non-detachable keyboard input device present because we include the
cros-ec-keyboard.dtsi snippet in the top-level sc7180-trogdor.dtsi file
that every variant board includes. We do this because the
keyboard-controller node also provides some buttons like the power
button and volume buttons. Unfortunately, this means we register a
keyboard input device that doesn't do anything on boards with a
detachable keyboard.
Change the node's compatible on detachables to the newly introduced
"google,cros-ec-keyb-switches" compatible to indicate that there are
only switches and no keyboard to register. Similarly, move the keyboard
include that defines the keyboard-controller node out of
sc7180-trogdor.dtsi to boards that actually have a keyboard so that the
matrix properties are not defined on boards with the switches
compatible. Future boards can either use the include approach or the
node definition approach to describe a keyboard with possible switches
or just some switches.
Cc: Benson Leung <bleung@chromium.org>
Cc: Guenter Roeck <groeck@chromium.org>
Cc: Douglas Anderson <dianders@chromium.org>
Cc: Hsin-Yi Wang <hsinyi@chromium.org>
Cc: "Joseph S. Barrera III" <joebar@chromium.org>
Signed-off-by: Stephen Boyd <swboyd@chromium.org>
Reviewed-by: Douglas Anderson <dianders@chromium.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220627212802.3593012-1-swboyd@chromium.org
The soc node expects all the nodes to have unit addresses. The
qup-opp-table does not have that which causes warnings:
arch/arm64/boot/dts/qcom/sm8250.dtsi:916.32-933.5:
Warning (simple_bus_reg): /soc@0/qup-opp-table:
missing or empty reg/ranges property
Move the qup-opp-table out of soc node to fix these warnings
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[bjorn: Rebased ontop of Krzysztof's node name update]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220606065035.553533-4-vkoul@kernel.org
The soc node expects all the nodes to have unit addresses. The
qup-opp-tables do not have that which causes warnings:
arch/arm64/boot/dts/qcom/sm8350.dtsi:640.46-657.5:
Warning (simple_bus_reg): /soc@0/qup-100mhz-opp-table:
missing or empty reg/ranges property
arch/arm64/boot/dts/qcom/sm8350.dtsi:659.46-676.5:
Warning (simple_bus_reg): /soc@0/qup-120mhz-opp-table:
missing or empty reg/ranges property
Move the qup-opp-tables out of soc node to fix these warnings
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
[bjorn: Rebased ontop of Krzysztof's node name update]
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220606065035.553533-3-vkoul@kernel.org
clk-virt and mc-virt interconnect nodes were named interconnect@0 and
interconnect@1. That is incorrect as we don't have unit addresses 0/1
for these node.
This causes warning:
arch/arm64/boot/dts/qcom/sm8450.dtsi:255.27-259.4:
Warning (unit_address_vs_reg): /interconnect@0:
node has a unit name, but no reg or ranges property
arch/arm64/boot/dts/qcom/sm8450.dtsi:261.26-265.4:
Warning (unit_address_vs_reg): /interconnect@1:
node has a unit name, but no reg or ranges property
arch/arm64/boot/dts/qcom/sm8450.dtsi:255.27-259.4:
Warning (unique_unit_address_if_enabled): /interconnect@0:
duplicate unit-address (also used in node /soc@0)
Rename the nodes to interconnect-0 and interconnect-1 to fix the
warning.
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Reviewed-by: Krzysztof Kozlowski <krzysztof.kozlowski@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220606065035.553533-2-vkoul@kernel.org
Current QUP peripheral labels like spi_0 and i2c_0 dont really tell what is
the exact QUP HW being used as there are actually 6 identical QUP HW blocks
for UART, SPI and I2C.
For example current i2c_0 label actually points to the QUP2 I2C HW.
This style of labeling does not follow what the rest of Qualcomm SoC-s use,
for example IPQ8074 which has the identical QUP blocks.
It also makes it really hard to add the missing QUP DT nodes as there are
multiple missing.
So utilize the same style as other Qualcomm SoC-s are using and update the
CP01 DTS as its the current sole user of them.
Signed-off-by: Robert Marko <robimarko@gmail.com>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220604153003.55172-1-robimarko@gmail.com
Since the Qualcomm sdhci-msm device-tree binding has been converted
to yaml format, 'make dtbs_check' reports a number of issues with
ordering of 'clocks' & 'clock-names' for sdhci nodes:
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:0: 'iface' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:1: 'core' was expected
arch/arm64/boot/dts/qcom/ipq8074-hk10-c2.dtb: sdhci@7824900:
clock-names:2: 'xo' was expected
Fix the same by updating the offending 'dts' files.
Cc: Bjorn Andersson <bjorn.andersson@linaro.org>
Cc: Rob Herring <robh@kernel.org>
Signed-off-by: Bhupesh Sharma <bhupesh.sharma@linaro.org>
Signed-off-by: Bjorn Andersson <bjorn.andersson@linaro.org>
Link: https://lore.kernel.org/r/20220514215424.1007718-5-bhupesh.sharma@linaro.org
