Xin Long says:
On udp rx path udp_rcv_segment() may do segment where the frag skbs
will get the header copied from the head skb in skb_segment_list()
by calling __copy_skb_header(), which could overwrite the frag skbs'
extensions by __skb_ext_copy() and cause a leak.
This issue was found after loading esp_offload where a sec path ext
is set in the skb.
Fix this by discarding head state of the fraglist skb before replacing
its contents.
Fixes: 3a1296a38d0cf62 ("net: Support GRO/GSO fraglist chaining.")
Cc: Steffen Klassert <steffen.klassert@secunet.com>
Reported-by: Xiumei Mu <xmu@redhat.com>
Tested-by: Xin Long <lucien.xin@gmail.com>
Signed-off-by: Florian Westphal <fw@strlen.de>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit cf673ed0e057a2dd68d930c6d7e30d53c70c5789)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iba886d897485ddddb2f1f67347b65fbba4d3e119
See:
https://www.rfc-editor.org/authors/rfc8781.txt
Cc: Erik Kline <ek@google.com>
Cc: Jen Linkova <furry@google.com>
Cc: Lorenzo Colitti <lorenzo@google.com>
Cc: Michael Haro <mharo@google.com>
Signed-off-by: Maciej Żenczykowski <maze@google.com>
Fixes: c24a77edc9a7 ("ipv6: ndisc: add support for 'PREF64' dns64 prefix identifier")
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 9175d3f38816835b0801bacbf4f6aff1a1672b71)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9ac8f0e2d500846e4a545434583bda3f671e00bb
Upon adding a new device from a DT node, we scan its properties and its
children's properties in order to create a consumer/supplier
relationship between the device and the property provider.
That said, it's possible for some of the node's children to be disabled,
which will create links that'll never be fulfilled.
To get around this, use the for_each_available_child_of_node() function
instead of for_each_available_node() when iterating over the node's
children.
Fixes: d4387cd11741 ("of: property: Create device links for all child-supplier depencencies")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit ed3655729182a59b9bef1b564c6fc2dcbbbe954e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I729c42bb3ddc8ecff1e5e097a439d672faea1f89
When creating a consumer/supplier relationship between two devices,
make sure the supplier node is actually active. Otherwise this will
create a link relationship that will never be fulfilled. This, in the
worst case scenario, will hang the system during boot.
Note that, in practice, the fact that a device-tree represented
consumer/supplier relationship isn't fulfilled will not prevent devices
from successfully probing.
Fixes: a3e1d1a7f5fc ("of: property: Add functional dependency link from DT bindings")
Signed-off-by: Nicolas Saenz Julienne <nsaenzjulienne@suse.de>
Reviewed-by: Saravana Kannan <saravanak@google.com>
Signed-off-by: Rob Herring <robh@kernel.org>
(cherry picked from commit 7456427af9def0fec5508dd8b861556038ee96a8)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I43d1405a81b00f360a514ff67487f0b375215ee3
Previous to commit 511ce378e16f07 ("mmc: Add MMC host software queue
support"), removing MMC_CAP2_CQE was enough to disable command queuing, but
now the cqe_ops must also be NULL otherwise ->cqe_enable() will be
called. Fix SDHCI_QUIRK_BROKEN_CQE to do that.
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Fixes: 511ce378e16f07 ("mmc: Add MMC host software queue support")
Link: https://lore.kernel.org/r/20200518120939.1399-1-adrian.hunter@intel.com
Signed-off-by: Ulf Hansson <ulf.hansson@linaro.org>
(cherry picked from commit 2b17b8d7cc65d333a48c6d32ee44fc489cecb7d9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ibadc2a45340e9c783f836401910b44123a49f02f
get_unaligned_le16() is defined in linux/unaligned/access_ok.h header
but it uses symbols which may not be available, leading to build
failures on ia64. Using asm/unaligned.h seem to be the right thing
and used in other drivers.
This fixes below error reported by kbuild test robot
In file included from drivers/usb/host/xhci-pci-renesas.c:9:
>> include/linux/unaligned/access_ok.h:8:28: error: redefinition of 'get_unaligned_le16'
8 | static __always_inline u16 get_unaligned_le16(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/unaligned.h:5,
from arch/ia64/include/asm/io.h:23,
from arch/ia64/include/asm/smp.h:21,
from include/linux/smp.h:67,
from include/linux/percpu.h:7,
from include/linux/arch_topology.h:9,
from include/linux/topology.h:30,
from include/linux/gfp.h:9,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:18,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/usb/host/xhci-pci-renesas.c:4:
include/linux/unaligned/le_struct.h:7:19: note: previous definition of 'get_unaligned_le16' was here
7 | static inline u16 get_unaligned_le16(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from drivers/usb/host/xhci-pci-renesas.c:9:
include/linux/unaligned/access_ok.h:13:28: error: redefinition of 'get_unaligned_le32'
13 | static __always_inline u32 get_unaligned_le32(const void *p)
| ^~~~~~~~~~~~~~~~~~
In file included from arch/ia64/include/asm/unaligned.h:5,
from arch/ia64/include/asm/io.h:23,
from arch/ia64/include/asm/smp.h:21,
from include/linux/smp.h:67,
from include/linux/percpu.h:7,
from include/linux/arch_topology.h:9,
from include/linux/topology.h:30,
from include/linux/gfp.h:9,
from include/linux/xarray.h:14,
from include/linux/radix-tree.h:18,
from include/linux/idr.h:15,
from include/linux/kernfs.h:13,
from include/linux/sysfs.h:16,
from include/linux/kobject.h:20,
from include/linux/of.h:17,
from include/linux/irqdomain.h:35,
from include/linux/acpi.h:13,
from drivers/usb/host/xhci-pci-renesas.c:4:
include/linux/unaligned/le_struct.h:12:19: note: previous definition of 'get_unaligned_le32' was here
Fixes: 8bd5741e3145 ("usb: renesas-xhci: Add the renesas xhci driver")
Reported-by: kbuild test robot <lkp@intel.com>
Signed-off-by: Vinod Koul <vkoul@kernel.org>
Link: https://lore.kernel.org/r/20200516162516.385149-1-vkoul@kernel.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 357abc1d6b832bdb6a7d27ed258f6d2be27d096d)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I30d9b8d71db8ca8143f22f461666f1deeef2a58b
The napi_gro_receive function no longer returns GRO_DROP ever, making
handling GRO_DROP dead code. This commit removes that dead code.
Further, it's not even clear that device drivers have any business in
taking action after passing off received packets; that's arguably out of
their hands. In this case, too, the non-gro path didn't bother checking
the return value. Plus, this had some clunky debugging functions that
duplicated code from elsewhere and was generally pretty messy. So, this
commit cleans that all up too.
Fixes: 6570bc79c0df ("net: core: use listified Rx for GRO_NORMAL in napi_gro_receive()")
Signed-off-by: Jason A. Donenfeld <Jason@zx2c4.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
(cherry picked from commit 045790b7bc66a75070c112a61558c639cef2263e)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6fa5a5c7a7b123e192e02e5dc671041454ad2df8
If there is an error when parsing the NL80211_ATTR_HE_BSS_COLOR
attribute, we return immediately without freeing param.acl. Fit it by
using goto out instead of returning immediately.
Fixes: 5c5e52d1bb96 ("nl80211: add handling for BSS color")
Signed-off-by: Luca Coelho <luciano.coelho@intel.com>
Link: https://lore.kernel.org/r/iwlwifi.20200626124931.7ad2a3eb894f.I60905fb70bd20389a3b170db515a07275e31845e@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 60a0121f8fa64b0f4297aa6fef8207500483a874)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I1b25c92cf781e73aba43e4b344358c6f458ae50e
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 554fdbaf19b1 ("thermal: sprd: Add Spreadtrum thermal driver support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Reviewed-by: Baolin Wang <baolin.wang7@gmail.com>
Signed-off-by: Daniel Lezcano <daniel.lezcano@linaro.org>
Link: https://lore.kernel.org/r/1590371941-25430-1-git-send-email-yangtiezhu@loongson.cn
(cherry picked from commit b4147917ad4ff2c755e01a7ca296b14030d2d507)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5ba1ea5bf4846edb0c0990557bbd00ce81bdc15f
IV_INO_LBLK_* exist only because of hardware limitations, and currently
the only known use case for them involves AES-256-XTS. Therefore, for
now only allow them in combination with AES-256-XTS. This way we don't
have to worry about them being combined with other encryption modes.
(To be clear, combining IV_INO_LBLK_* with other encryption modes
*should* work just fine. It's just not being tested, so we can't be
100% sure it works. So with no known use case, it's best to disallow it
for now, just like we don't allow other weird combinations like
AES-256-XTS contents encryption with Adiantum filenames encryption.)
This can be relaxed later if a use case for other combinations arises.
Fixes: b103fb7653ff ("fscrypt: add support for IV_INO_LBLK_64 policies")
Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
Link: https://lore.kernel.org/r/20200721181012.39308-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit f000223c981a7c75f6f3ab7288f0be7b571c3644)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I9b28a1d2394a8a70d020be3a4f8661ac5987a78d
Normally smp_store_release() or cmpxchg_release() is paired with
smp_load_acquire(). Sometimes smp_load_acquire() can be replaced with
the more lightweight READ_ONCE(). However, for this to be safe, all the
published memory must only be accessed in a way that involves the
pointer itself. This may not be the case if allocating the object also
involves initializing a static or global variable, for example.
fscrypt_prepared_key includes a pointer to a crypto_skcipher object,
which is internal to and is allocated by the crypto subsystem. By using
READ_ONCE() for it, we're relying on internal implementation details of
the crypto subsystem.
Remove this fragile assumption by using smp_load_acquire() instead.
(Note: I haven't seen any real-world problems here. This change is just
fixing the code to be guaranteed correct and less fragile.)
Fixes: 5fee36095cda ("fscrypt: add inline encryption support")
Cc: Satya Tangirala <satyat@google.com>
Link: https://lore.kernel.org/r/20200721225920.114347-3-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 97c6327f7192d7312eabc033b26a41ad6816496c)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I03b3e854e44734206112554dfc38cfe899127cfa
When call function devm_platform_ioremap_resource(), we should use IS_ERR()
to check the return value and return PTR_ERR() if failed.
Fixes: 096030e7f449 ("nvmem: sprd: Add Spreadtrum SoCs eFuse support")
Signed-off-by: Tiezhu Yang <yangtiezhu@loongson.cn>
Signed-off-by: Srinivas Kandagatla <srinivas.kandagatla@linaro.org>
Link: https://lore.kernel.org/r/20200722100705.7772-2-srinivas.kandagatla@linaro.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit bcd14bb7a68520bf88e45e91d354e43535624f82)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I6121d3ca4cb636bb4088a3baab6da554984a8dd0
The commit 24a2042cb22f ("mac80211: add HE 6 GHz Band Capability
element") failed to check device capability before adding HE 6 GHz
capability element. Below warning is reported in 11ac device in mesh.
Fix that by checking device capability at HE 6 GHz cap IE addition
in mesh beacon and association request.
WARNING: CPU: 1 PID: 1897 at net/mac80211/util.c:2878
ieee80211_ie_build_he_6ghz_cap+0x149/0x150 [mac80211]
[ 3138.720358] Call Trace:
[ 3138.720361] ieee80211_mesh_build_beacon+0x462/0x530 [mac80211]
[ 3138.720363] ieee80211_start_mesh+0xa8/0xf0 [mac80211]
[ 3138.720365] __cfg80211_join_mesh+0x122/0x3e0 [cfg80211]
[ 3138.720368] nl80211_join_mesh+0x3d3/0x510 [cfg80211]
Fixes: 24a2042cb22f ("mac80211: add HE 6 GHz Band Capability element")
Reported-by: Markus Theil <markus.theil@tu-ilmenau.de>
Signed-off-by: Rajkumar Manoharan <rmanohar@codeaurora.org>
Link: https://lore.kernel.org/r/1593656424-18240-1-git-send-email-rmanohar@codeaurora.org
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit 65ad3ef9fced4062dfd74e2f89443fb5ce184321)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I482ae69d99fcf58b3c08fef4561673b656d32995
The interrupt might be shared, in which case it is not an error for the
interrupt handler to be called when the interrupt status is zero, so don't
print the message unless there was enabled interrupt status.
Link: https://lore.kernel.org/r/20200811133936.19171-1-adrian.hunter@intel.com
Fixes: 9333d7757348 ("scsi: ufs: Fix irq return code")
Reviewed-by: Avri Altman <avri.altman@wdc.com>
Signed-off-by: Adrian Hunter <adrian.hunter@intel.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 6337f58cec030b34ced435b3d9d7d29d63c96e36)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I60f61f9453edae05b796afa7a37e59bf8ace32e1
In find_energy_efficient_cpu() 'cpu_cap' could be less that 'util'.
It might be because of RT, DL (so higher sched class than CFS), irq or
thermal pressure signal, which reduce the capacity value.
In such situation the result of 'cpu_cap - util' might be negative but
stored in the unsigned long. Then it might be compared with other unsigned
long when uclamp_rq_util_with() reduced the 'util' such that is passes the
fits_capacity() check.
Prevent this situation and make the arithmetic more safe.
Fixes: 1d42509e475cd ("sched/fair: Make EAS wakeup placement consider uclamp restrictions")
Signed-off-by: Lukasz Luba <lukasz.luba@arm.com>
Signed-off-by: Peter Zijlstra (Intel) <peterz@infradead.org>
Reviewed-by: Valentin Schneider <valentin.schneider@arm.com>
Link: https://lkml.kernel.org/r/20200810083004.26420-1-lukasz.luba@arm.com
(cherry picked from commit da0777d35f47892f359c3f73ea155870bb595700)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ib3e22c155eb031854cfb4428494c1c4da57692b1
This commit fixes two issues:
1. The lockdep warning reported by Dong Aisheng <dongas86@gmail.com> [1].
It is a warning about a cycle (dpm_list_mtx --> kn->active#3 --> fw_lock)
that was introduced when device-link devices were added to expose device
link information in sysfs.
The patch that "introduced" this cycle can't be reverted because it's fixes
a real SRCU issue and also ensures that the device-link device is deleted
as soon as the device-link is deleted. This is important to avoid sysfs
name collisions if the device-link is create again immediately (this can
happen a lot with deferred probing).
2. Inconsistency in grabbing device_pm_lock() during device link deletion
Some device link deletion code paths grab device_pm_lock(), while others
don't. The device_pm_lock() is grabbed during device_link_add() because it
checks if the supplier is in the dpm_list and also reorders the dpm_list.
However, when a device link is deleted, it does not do either of those and
therefore device_pm_lock() is not necessary. Dropping the device_pm_lock()
in all the device link deletion paths removes the inconsistency in locking.
Thanks to Stephen Boyd for helping me understand the lockdep splat.
Fixes: 843e600b8a2b ("driver core: Fix sleeping in invalid context during device link deletion")
[1] - https://lore.kernel.org/lkml/CAA+hA=S4eAreb7vo69LAXSk2t5=DEKNxHaiY1wSpk4xTp9urLg@mail.gmail.com/
Reported-by: Dong Aisheng <dongas86@gmail.com>
Signed-off-by: Saravana Kannan <saravanak@google.com>
Tested-by: Peng Fan <peng.fan@nxp.com>
Link: https://lore.kernel.org/r/20200901184445.1736658-1-saravanak@google.com
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
(cherry picked from commit 6b57b15abe11aa334ebf726e02c0deaf123ba040)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I714523d92bbfbad145df2794c481cd0b697d7d16
When an encryption policy has the IV_INO_LBLK_32 flag set, the IV
generation method involves hashing the inode number. This is different
from fscrypt's other IV generation methods, where the inode number is
either not used at all or is included directly in the IVs.
Therefore, in principle IV_INO_LBLK_32 can work with any length inode
number. However, currently fscrypt gets the inode number from
inode::i_ino, which is 'unsigned long'. So currently the implementation
limit is actually 32 bits (like IV_INO_LBLK_64), since longer inode
numbers will have been truncated by the VFS on 32-bit platforms.
Fix fscrypt_supported_v2_policy() to enforce the correct limit.
This doesn't actually matter currently, since only ext4 and f2fs support
IV_INO_LBLK_32, and they both only support 32-bit inode numbers. But we
might as well fix it in case it matters in the future.
Ideally inode::i_ino would instead be made 64-bit, but for now it's not
needed. (Note, this limit does *not* prevent filesystems with 64-bit
inode numbers from adding fscrypt support, since IV_INO_LBLK_* support
is optional and is useful only on certain hardware.)
Fixes: e3b1078bedd3 ("fscrypt: add support for IV_INO_LBLK_32 policies")
Reported-by: Jeff Layton <jlayton@kernel.org>
Link: https://lore.kernel.org/r/20200824203841.1707847-1-ebiggers@kernel.org
Signed-off-by: Eric Biggers <ebiggers@google.com>
(cherry picked from commit 5e895bd4d5233cb054447d0491d4e63c8496d419)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ie4abfef403dfacf790baa667a37febf591c7e3ca
Some MediaTek platforms does not have to bind MPHY so users shall not see
any unnecessary logs. Simply remove logs for this case.
Link: https://lore.kernel.org/r/20200908064507.30774-2-stanley.chu@mediatek.com
Fixes: fc4983018fea ("scsi: ufs-mediatek: Allow unbound mphy")
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit 30a90782c105fe498df74161392aa143796b6886)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I01f51f1532bf1826692b22b5650acd25a63f3698
Simply add HOST_PA_TACTIVATE quirk back since it was incorrectly removed
before.
Link: https://lore.kernel.org/r/20200908064507.30774-3-stanley.chu@mediatek.com
Fixes: 47d054580a75 ("scsi: ufs-mediatek: fix HOST_PA_TACTIVATE quirk for Samsung UFS Devices")
Signed-off-by: Stanley Chu <stanley.chu@mediatek.com>
Signed-off-by: Martin K. Petersen <martin.petersen@oracle.com>
(cherry picked from commit a3e40b80dc951057033dce86f0e675b2b822b513)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Id1f55fa74d0d393974b9f152d3289cd3ac4e3298
We shouldn't accept any channels bigger than 233, fix that.
Reported-by: Amar <asinghal@codeaurora.org>
Fixes: d1a1646c0de7 ("cfg80211: adapt to new channelization of the 6GHz band")
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
Link: https://lore.kernel.org/r/20200917115222.312ba6f1d461.I3a8c8fbcc3cc019814fd9cd0aced7eb591626136@changeid
Signed-off-by: Johannes Berg <johannes.berg@intel.com>
(cherry picked from commit c0de8776af6543e10d1a5c8969679fd9f6b66fa9)
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I83a88dce9a0c78f949abd792c824ed6f923ee809
Update Galaxy list of symbols with ones that are already in the .xml
file to manage symbols by used our modules
Bug: 173174399
Signed-off-by: Jeehong Kim <jhez.kim@samsung.com>
Change-Id: I0b26dff0c0075ba74fbbb3948f4e71c636f3a6cb
This patch adds to upload initial symbol list for Exynosauto SoC.
To find what has updated from GKI symbol easily, this list does not
include full list of symbol. So, nothing has added to GKI ABI symbols.
Bug: 172885440
Signed-off-by: Chanho Park <chanho61.park@samsung.com>
Change-Id: I41cc355687a5ba859ad601b8f1efdad13e52f20f
Add the following symbols to QCOM allowed-list:
-- __irq_set_handler
-- irq_set_handler_data
Bug: 172879351
Change-Id: I6869b60b4893a3f9447d0fb6e7977e0685477386
Signed-off-by: Maulik Shah <mkshah@codeaurora.org>
Before 5.10-rc1, the upstream kernel blocked any compat calls into XFRM
code with EOPNOTSUPP, however Android kernels had been patching this
check out and made userspace match the 64-bit kernel netlink format
instead.
When the new XFRM_USER_COMPAT feature landed, it added a similar check
in two places which returns EOPNOTSUPP only if the XFRM_USER_COMPAT
feature is disabled, however that is currently always the case for
Android kernels and we do not want to filter these callers.
While we work to remove the userspace compatibility mess, disable the
filtering of compat calls when XFRM_USER_COMPAT is disabled. If the
XFRM_USER_COMPAT feature is enabled, nothing changes.
Bug: 163141236
Bug: 172541864
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ifbea109070650dfcb4f93a3cc692c18a8d11ab44
Fix build-break for non GKI builds caused by using the
_rcuidle() variant of a vendor hook.
Fixes: bad091cc4b ("ANDROID: vendor_hooks: Add vendor hooks for
getting printk messages")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I0dffaf7e0df198a63578818f7c155671efe382b5
Fix this link error:
ERROR: modpost: "rcu_idle_enter" [drivers/acpi/processor.ko] undefined!
ERROR: modpost: "rcu_idle_exit" [drivers/acpi/processor.ko] undefined!
when CONFIG_ACPI_PROCESSOR is built as module. PeterZ says that in light
of ARM needing those soon too, they should simply be exported.
Link: https://lore.kernel.org/linux-pm/20200921103741.GC5901@zn.tnic/
Bug: 172034763
Change-Id: I26d516d11edbce673f52df6474f6695c5a1e2b07
(cherry picked from commit 3ad1c8ef083bef96ec922688966484be1039e6b5)
Fixes: 1fecfdbb7acc ("ACPI: processor: Take over RCU-idle for C3-BM idle")
Reported-by: Sven Joachim <svenjoac@gmx.de>
Suggested-by: Peter Zijlstra <peterz@infradead.org>
Signed-off-by: Borislav Petkov <bp@suse.de>
Reviewed-by: Paul E. McKenney <paulmckrcu@kernel.org>
Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
This problem will happened if handle_IPI is called from idle CPU.
Use trace_android_vh_ipi_stop_rcuidle() to fix this issue
Bug: 171683158
Change-Id: Ic49fc1ddc19a54415dec3f28b68f42fa258ffeea
Signed-off-by: Cheng Jui Wang <cheng-jui.wang@mediatek.com>
Signed-off-by: Chun-Hung Wu <chun-hung.wu@mediatek.com>
The new android_rvh_nf_conn_alloc hook was not declared properly
so kernelci builds break if !CONFIG_ANDROID_VENDOR_HOOKS.
Fixes: 01435b2e91 ("ANDROID: GKI: net: add vendor hooks
for 'struct nf_conn' lifecycle")
Signed-off-by: Todd Kjos <tkjos@google.com>
Change-Id: I1208dc440836687a9c5621323ff1cf5a5bec862b
This is useful for debuggers, and is already the default for clang
(incidentally). Make sure it is on for all users/compilers.
Bug: 160841764
Change-Id: Ibb9a0c6900728d4cce3eccb57fb4c38268a89f24
Signed-off-by: Alistair Delva <adelva@google.com>
Indirect calls can happen when RCU is not watching, so we need to wake
it up again for the CFI shadow and __module_address. As these calls can
happen anywhere, use rcu_nmi_enter() similarly to kernel_text_address(),
and switch to rcu_read_lock_sched() for shadow access.
Bug: 169017431
Change-Id: Iebb857df898e644b4952a62d86fa5ff9852b5711
Signed-off-by: Sami Tolvanen <samitolvanen@google.com>
slab does this already, and I want to use this in a memory allocation
tracker in drm for stuff that's tied to the lifetime of a drm_device,
not the underlying struct device. Kinda like devres, but for drm.
Acked-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Daniel Vetter <daniel.vetter@intel.com>
Cc: Christoph Lameter <cl@linux.com>
Cc: Pekka Enberg <penberg@kernel.org>
Cc: David Rientjes <rientjes@google.com>
Cc: Joonsoo Kim <iamjoonsoo.kim@lge.com>
Cc: Andrew Morton <akpm@linux-foundation.org>
Cc: linux-mm@kvack.org
Link: https://patchwork.freedesktop.org/patch/msgid/20200323144950.3018436-2-daniel.vetter@ffwll.ch
(cherry picked from commit fd7cb5753ef49964ea9db5121c3fc9a4ec21ed8e)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: I10790befc779311a5f2ee441e4d073e51a5a7a62
Provide the user-to-kernel translator under XFRM_USER_COMPAT, that
creates for 32-bit xfrm-user message a 64-bit translation.
The translation is afterwards reused by xfrm_user code just as if
userspace had sent 64-bit message.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5106f4a8acff480e244300bc5097c0ad7048c3a2)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: If15999b86e4704b75307fbcc3d7f0c8d8bc89e7a
Currently nlmsg_unicast() is used by functions that dump structures that
can be different in size for compat tasks, see dump_one_state() and
dump_one_policy().
The following nlmsg_unicast() users exist today in xfrm:
Function | Message can be different
| in size on compat
-------------------------------------------|------------------------------
xfrm_get_spdinfo() | N
xfrm_get_sadinfo() | N
xfrm_get_sa() | Y
xfrm_alloc_userspi() | Y
xfrm_get_policy() | Y
xfrm_get_ae() | N
Besides, dump_one_state() and dump_one_policy() can be used by filtered
netlink dump for XFRM_MSG_GETSA, XFRM_MSG_GETPOLICY.
Just as for xfrm multicast, allocate frag_list for compat skb journey
down to recvmsg() which will give user the desired skb according to
syscall bitness.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5f3eea6b7e8f58cf5c8a9d4b9679dc19e9e67ba3)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id1a606ddd9d7dfe73a448eeb252b1bfd8dbd2fcb
Provide the kernel-to-user translator under XFRM_USER_COMPAT, that
creates for 64-bit xfrm-user message a 32-bit translation and puts it
in skb's frag_list. net/compat.c layer provides MSG_CMSG_COMPAT to
decide if the message should be taken from skb or frag_list.
(used by wext-core which has also an ABI difference)
Kernel sends 64-bit xfrm messages to the userspace for:
- multicast (monitor events)
- netlink dumps
Wire up the translator to xfrm_nlmsg_multicast().
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit 5461fc0c8d9f23956b99f5907f69726a293ccb67)
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Id8b59587d60feb9b9f0ce96be9d140d694573fe3
Add a skeleton for xfrm_compat module and provide API to register it in
xfrm_state.ko. struct xfrm_translator will have function pointers to
translate messages received from 32-bit userspace or to be sent to it
from 64-bit kernel.
module_get()/module_put() are used instead of rcu_read_lock() as the
module will vmalloc() memory for translation.
The new API is registered with xfrm_state module, not with xfrm_user as
the former needs translator for user_policy set by setsockopt() and
xfrm_user already uses functions from xfrm_state.
Signed-off-by: Dmitry Safonov <dima@arista.com>
Signed-off-by: Steffen Klassert <steffen.klassert@secunet.com>
(cherry picked from commit c9e7c76d70fa50582ca96759829c93d0dd024662)
[adelva: Edited around some context changes]
Bug: 163141236
Signed-off-by: Alistair Delva <adelva@google.com>
Change-Id: Ic825c6a0367fa192cc3f7af6b7d2682ef8f9d58b
The KMI was changed by several patches on October 31. Update the
generation number to notify all tools of this.
Bug: 161946584
Cc: Todd Kjos <tkjos@google.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I5d96ec5e4fe3ead9aedf19bdedf731b3ee28746a
Bump the userspace-facing value of SW_MAX from 0x10 to 0x3f, allowing
out-of-tree input drivers to use the increased space to send input codes
to userspace safely.
Note, there are no new reserved input code values, so any out-of-tree
numbers are not guaranteed to ever remain stable over time, but this
allows those drivers to work properly before they get merged upstream to
claim a reserved number.
Be aware that if you use this increased numberspace, your values will
change going forward to new Android and kernel versions, you have been
warned.
This gives us the free-space for 0x2f new values, which should be enough
for a few years grace-period :)
This changes the CRC of a number of functions, but no variable sizes
have changed:
Leaf changes summary: 36 artifacts changed
Changed leaf types summary: 0 leaf type changed
Removed/Changed/Added functions summary: 0 Removed, 36 Changed, 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 0 Changed, 0 Added variable
36 functions with some sub-type change:
[C] 'function cec_adapter* cec_allocate_adapter(const cec_adap_ops*, void*, const char*, u32, u8)' at cec-core.c:253:1 has some sub-type changes:
[C] 'function void cec_delete_adapter(cec_adapter*)' at cec-core.c:431:1 has some sub-type changes:
[C] 'function void cec_received_msg_ts(cec_adapter*, cec_msg*, ktime_t)' at cec-adap.c:1036:1 has some sub-type changes:
[C] 'function int cec_register_adapter(cec_adapter*, device*)' at cec-core.c:342:1 has some sub-type changes:
[C] 'function void cec_s_phys_addr(cec_adapter*, unsigned short int, bool)' at cec.h:279:1 has some sub-type changes:
[C] 'function void cec_s_phys_addr_from_edid(cec_adapter*, const edid*)' at cec-adap.c:1616:1 has some sub-type changes:
[C] 'function void cec_transmit_attempt_done_ts(cec_adapter*, u8, ktime_t)' at cec-adap.c:688:1 has some sub-type changes:
[C] 'function void cec_transmit_done_ts(cec_adapter*, u8, u8, u8, u8, u8, ktime_t)' at cec-adap.c:591:1 has some sub-type changes:
[C] 'function void cec_unregister_adapter(cec_adapter*)' at cec-core.c:412:1 has some sub-type changes:
[C] 'function input_dev* devm_input_allocate_device(device*)' at input.h:352:1 has some sub-type changes:
[C] 'function void input_alloc_absinfo(input_dev*)' at input.h:466:1 has some sub-type changes:
[C] 'function input_dev* input_allocate_device()' at input.h:351:1 has some sub-type changes:
[C] 'function void input_close_device(input_handle*)' at input.h:404:1 has some sub-type changes:
[C] 'function void input_event(input_dev*, unsigned int, unsigned int, int)' at input.h:411:1 has some sub-type changes:
[C] 'function int input_ff_create(input_dev*, unsigned int)' at input.h:555:1 has some sub-type changes:
[C] 'function int input_ff_create_memless(input_dev*, void*, int (input_dev*, void*, ff_effect*)*)' at input.h:564:1 has some sub-type changes:
[C] 'function void input_ff_destroy(input_dev*)' at input.h:556:1 has some sub-type changes:
[C] 'function void input_free_device(input_dev*)' at input.h:353:1 has some sub-type changes:
[C] 'function void input_mt_destroy_slots(input_dev*)' at mt.h:78:1 has some sub-type changes:
[C] 'function int input_mt_get_slot_by_key(input_dev*, int)' at mt.h:122:1 has some sub-type changes:
[C] 'function int input_mt_init_slots(input_dev*, unsigned int, unsigned int)' at mt.h:76:1 has some sub-type changes:
[C] 'function void input_mt_report_pointer_emulation(input_dev*, bool)' at mt.h:104:1 has some sub-type changes:
[C] 'function bool input_mt_report_slot_state(input_dev*, unsigned int, bool)' at mt.h💯1 has some sub-type changes:
[C] 'function void input_mt_sync_frame(input_dev*)' at mt.h:107:1 has some sub-type changes:
[C] 'function int input_open_device(input_handle*)' at input.h:403:1 has some sub-type changes:
[C] 'function int input_register_device(input_dev*)' at input.h:376:1 has some sub-type changes:
[C] 'function int input_register_handle(input_handle*)' at input.h:397:1 has some sub-type changes:
[C] 'function int input_register_handler(input_handler*)' at input.h:387:1 has some sub-type changes:
[C] 'function void input_set_abs_params(input_dev*, unsigned int, int, int, int, int)' at input.h:467:1 has some sub-type changes:
[C] 'function void input_set_capability(input_dev*, unsigned int, unsigned int)' at input.h:449:1 has some sub-type changes:
[C] 'function void input_unregister_device(input_dev*)' at input.h:377:1 has some sub-type changes:
[C] 'function void input_unregister_handle(input_handle*)' at input.h:398:1 has some sub-type changes:
[C] 'function void input_unregister_handler(input_handler*)' at input.h:388:1 has some sub-type changes:
[C] 'function int snd_jack_new(snd_card*, const char*, int, snd_jack**, bool, bool)' at jack.c:198:1 has some sub-type changes:
[C] 'function void snd_jack_report(snd_jack*, int)' at jack.c:340:1 has some sub-type changes:
[C] 'function int snd_jack_set_key(snd_jack*, snd_jack_types, int)' at jack.c:317:1 has some sub-type changes:
Bug: 170534200
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I28c8b49ac37f42d3ff89554e18fe042a44f5704a
Leaf changes summary: 3380 artifacts changed (154 filtered out)
Changed leaf types summary: 282 (120 filtered out) leaf types changed
Removed/Changed/Added functions summary: 0 Removed, 3052 Changed (32 filtered out), 0 Added function
Removed/Changed/Added variables summary: 0 Removed, 46 Changed (2 filtered out), 0 Added variable
3052 functions with some sub-type change:
46 Changed variables:
'struct dentry_operations at dcache.h:139:1' changed:
type size hasn't changed
1 data member insertion:
'void (const path*, path*)* dentry_operations::d_canonical_path', at offset 832 (in bits) at dcache.h:154:1
there are data member changes:
'u64 dentry_operations::android_kabi_reserved1' offset changed from 832 to 896 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved2' offset changed from 896 to 960 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved3' offset changed from 960 to 1024 (in bits) (by +64 bits)
'u64 dentry_operations::android_kabi_reserved4' offset changed from 1024 to 1088 (in bits) (by +64 bits)
3330 impacted interfaces
'struct inet_connection_sock at inet_connection_sock.h:87:1' changed (indirectly):
type size changed from 11840 to 11904 (in bits)
there are data member changes:
type 'struct inet_sock' of 'inet_connection_sock::icsk_inet' changed:
type size changed from 8320 to 8384 (in bits)
there are data member changes:
type 'struct sock' of 'inet_sock::sk' changed:
type size changed from 6656 to 6720 (in bits)
1 data member insertion:
'u64 sock::android_vendor_data1', at offset 6656 (in bits) at sock.h:526:1
422 impacted interfaces
'ipv6_pinfo* inet_sock::pinet6' offset changed from 6656 to 6720 (in bits) (by +64 bits)
'__be32 inet_sock::inet_saddr' offset changed from 6720 to 6784 (in bits) (by +64 bits)
'__s16 inet_sock::uc_ttl' offset changed from 6752 to 6816 (in bits) (by +64 bits)
'__u16 inet_sock::cmsg_flags' offset changed from 6768 to 6832 (in bits) (by +64 bits)
'__be16 inet_sock::inet_sport' offset changed from 6784 to 6848 (in bits) (by +64 bits)
'__u16 inet_sock::inet_id' offset changed from 6800 to 6864 (in bits) (by +64 bits)
'ip_options_rcu* inet_sock::inet_opt' offset changed from 6848 to 6912 (in bits) (by +64 bits)
'int inet_sock::rx_dst_ifindex' offset changed from 6912 to 6976 (in bits) (by +64 bits)
'__u8 inet_sock::tos' offset changed from 6944 to 7008 (in bits) (by +64 bits)
'__u8 inet_sock::min_ttl' offset changed from 6952 to 7016 (in bits) (by +64 bits)
'__u8 inet_sock::mc_ttl' offset changed from 6960 to 7024 (in bits) (by +64 bits)
'__u8 inet_sock::pmtudisc' offset changed from 6968 to 7032 (in bits) (by +64 bits)
'__u8 inet_sock::nodefrag' offset changed from 6976 to 7040 (in bits) (by +64 bits)
'__u8 inet_sock::rcv_tos' offset changed from 6992 to 7056 (in bits) (by +64 bits)
'__u8 inet_sock::convert_csum' offset changed from 7000 to 7064 (in bits) (by +64 bits)
'int inet_sock::uc_index' offset changed from 7008 to 7072 (in bits) (by +64 bits)
'int inet_sock::mc_index' offset changed from 7040 to 7104 (in bits) (by +64 bits)
'__be32 inet_sock::mc_addr' offset changed from 7072 to 7136 (in bits) (by +64 bits)
'ip_mc_socklist* inet_sock::mc_list' offset changed from 7104 to 7168 (in bits) (by +64 bits)
'inet_cork_full inet_sock::cork' offset changed from 7168 to 7232 (in bits) (by +64 bits)
2 impacted interfaces
'request_sock_queue inet_connection_sock::icsk_accept_queue' offset changed from 8320 to 8384 (in bits) (by +64 bits)
'inet_bind_bucket* inet_connection_sock::icsk_bind_hash' offset changed from 8960 to 9024 (in bits) (by +64 bits)
'unsigned long int inet_connection_sock::icsk_timeout' offset changed from 9024 to 9088 (in bits) (by +64 bits)
'timer_list inet_connection_sock::icsk_retransmit_timer' offset changed from 9088 to 9152 (in bits) (by +64 bits)
'timer_list inet_connection_sock::icsk_delack_timer' offset changed from 9536 to 9600 (in bits) (by +64 bits)
'__u32 inet_connection_sock::icsk_rto' offset changed from 9984 to 10048 (in bits) (by +64 bits)
'__u32 inet_connection_sock::icsk_pmtu_cookie' offset changed from 10016 to 10080 (in bits) (by +64 bits)
'const tcp_congestion_ops* inet_connection_sock::icsk_ca_ops' offset changed from 10048 to 10112 (in bits) (by +64 bits)
'const inet_connection_sock_af_ops* inet_connection_sock::icsk_af_ops' offset changed from 10112 to 10176 (in bits) (by +64 bits)
'const tcp_ulp_ops* inet_connection_sock::icsk_ulp_ops' offset changed from 10176 to 10240 (in bits) (by +64 bits)
'void* inet_connection_sock::icsk_ulp_data' offset changed from 10240 to 10304 (in bits) (by +64 bits)
'void (sock*, typedef u32)* inet_connection_sock::icsk_clean_acked' offset changed from 10304 to 10368 (in bits) (by +64 bits)
'hlist_node inet_connection_sock::icsk_listen_portaddr_node' offset changed from 10368 to 10432 (in bits) (by +64 bits)
'unsigned int (sock*, typedef u32)* inet_connection_sock::icsk_sync_mss' offset changed from 10496 to 10560 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_ca_dst_locked' offset changed from 10560 to 10624 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_retransmits' offset changed from 10568 to 10632 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_pending' offset changed from 10576 to 10640 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_backoff' offset changed from 10584 to 10648 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_syn_retries' offset changed from 10592 to 10656 (in bits) (by +64 bits)
'__u8 inet_connection_sock::icsk_probes_out' offset changed from 10600 to 10664 (in bits) (by +64 bits)
'__u16 inet_connection_sock::icsk_ext_hdr_len' offset changed from 10608 to 10672 (in bits) (by +64 bits)
'struct {__u8 pending; __u8 quick; __u8 pingpong; __u8 blocked; __u32 ato; unsigned long int timeout; __u32 lrcvtime; __u16 last_seg_size; __u16 rcv_mss;} inet_connection_sock::icsk_ack' offset changed from 10624 to 10688 (in bits) (by +64 bits)
'struct {int enabled; int search_high; int search_low; int probe_size; u32 probe_timestamp;} inet_connection_sock::icsk_mtup' offset changed from 10816 to 10880 (in bits) (by +64 bits)
'u32 inet_connection_sock::icsk_user_timeout' offset changed from 10976 to 11040 (in bits) (by +64 bits)
'u64 inet_connection_sock::icsk_ca_priv[13]' offset changed from 11008 to 11072 (in bits) (by +64 bits)
2 impacted interfaces
'struct module at module.h:354:1' changed:
type size hasn't changed
1 data member insertion:
'bool module::using_gplonly_symbols', at offset 2688 (in bits) at module.h:385:1
there are data member changes:
anonymous data member union {module_kabi_preserve_1 m1; struct {u64 android_kabi_reserved1;} __UNIQUE_ID_android_kabi_hide201; union {};} at offset 6848 (in bits) became data member 'u64 module::android_kabi_reserved1'
'bool module::sig_ok' offset changed from 2688 to 2696 (in bits) (by +8 bits)
'bool module::async_probe_requested' offset changed from 2696 to 2704 (in bits) (by +8 bits)
3330 impacted interfaces
'struct nf_conn at nf_conntrack.h:58:1' changed:
type size changed from 2048 to 2240 (in bits)
3 data member insertions:
'u64 nf_conn::android_kabi_reserved1', at offset 2048 (in bits) at nf_conntrack.h:111:1
'u64 nf_conn::android_kabi_reserved2', at offset 2112 (in bits) at nf_conntrack.h:112:1
'u64 nf_conn::android_vendor_data1', at offset 2176 (in bits) at nf_conntrack.h:114:1
422 impacted interfaces
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Iec13bb17711b4337d6810b6eac45f755497c6ed8
Some vendors want to add things to 'struct skb_shared_info', so give
them an array to place their data.
Bug: 171013716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: Ifaa5942550794b747e9624124c785a0bc85dfe17
Some vendors want to add a field when a 'sruct nf_conn' is added so give a
hook to handle this. Any memory allocated when
trace_android_rvh_nf_conn_alloc() is called needs to be freed when
trace_android_rvh_nf_conn_free() is called.
Note, if trace_android_rvh_nf_conn_alloc() fails, be sure to be able to
handle this in trace_android_rvh_nf_conn_free(), but that should not be
an issue as that needs to be addressed in vendor code that runs for
'struct nf_conn' objects that have been created before the vendor code
is loaded no matter what.
Bug: 171013716
Signed-off-by: Greg Kroah-Hartman <gregkh@google.com>
Change-Id: I67a9be129150690f8c1961accf7d5cdf0d5d50cc
