| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
Commit 49b3cf035edc ("kasan: arm64: set TCR_EL1.TBID1 when enabled") set
the TBID1 bit for the KASAN_SW_TAGS configuration, freeing up 8 bits to
be used by PAC. With in-kernel MTE now in mainline, also set this bit
for the KASAN_HW_TAGS configuration.
Signed-off-by: Catalin Marinas <[email protected]>
Cc: Peter Collingbourne <[email protected]>
Acked-by: Vincenzo Frascino <[email protected]>
Acked-by: Andrey Konovalov <[email protected]>
|
|
Currently with ld.lld we emit an empty .eh_frame_hdr section (and a
corresponding program header) into the vDSO. With ld.bfd the section
is not emitted but the program header is, with p_vaddr set to 0. This
can lead to unwinders attempting to interpret the data at whichever
location the program header happens to point to as an unwind info
header. This happens to be mostly harmless as long as the byte at
that location (interpreted as a version number) has a value other
than 1, causing both libgcc and LLVM libunwind to ignore the section
(in libunwind's case, after printing an error message to stderr),
but it could lead to worse problems if the byte happened to be 1 or
the program header points to non-readable memory (e.g. if the empty
section was placed at a page boundary).
Instead of disabling .eh_frame_hdr via --no-eh-frame-hdr (which
also has the downside of being unsupported by older versions of GNU
binutils), disable it by discarding the section, and stop emitting
the program header that points to it.
I understand that we intend to emit valid unwind info for the vDSO
at some point. Once that happens this patch can be reverted.
Signed-off-by: Peter Collingbourne <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Acked-by: Vincenzo Frascino <[email protected]>
Link: https://linux-review.googlesource.com/id/If745fd9cadcb31b4010acbf5693727fe111b0863
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
asm/exception.h is included more than once. Remove the one that isn't
necessary.
Signed-off-by: Tian Tao <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
This code will leak "map->debugfs_name" because the if statement is
reversed so it only frees NULL pointers instead of non-NULL. In
fact the if statement is not required and should just be removed
because kfree() accepts NULL pointers.
Fixes: cffa4b2122f5 ("regmap: debugfs: Fix a memory leak when calling regmap_attach_dev")
Signed-off-by: Dan Carpenter <[email protected]>
Link: https://lore.kernel.org/r/X/RQpfAwRdLg0GqQ@mwanda
Signed-off-by: Mark Brown <[email protected]>
|
|
We have set up a repository for users to try newer releases more easily, and
keep records of known bugs.
Signed-off-by: Samuel Thibault <[email protected]>
Link: https://lore.kernel.org/r/20201222014756.ov5vi6fywylbp5n6@function
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Commit d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST") deletes
CONFIG_KVM_ARM_HOST option, it should use CONFIG_KVM instead.
Just remove CONFIG_KVM_ARM_HOST here.
Fixes: d82755b2e781 ("KVM: arm64: Kill off CONFIG_KVM_ARM_HOST")
Signed-off-by: Shannon Zhao <[email protected]>
Acked-by: Catalin Marinas <[email protected]>
Signed-off-by: Marc Zyngier <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
|
|
Here's another variant PNY Pro Elite USB 3.1 Gen 2 portable SSD that
hangs and doesn't respond to ATA_1x pass-through commands. If it doesn't
support these commands, it should respond properly to the host. Add it
to the unusual uas list to be able to move forward with other
operations.
Cc: [email protected]
Reviewed-by: Hans de Goede <[email protected]>
Acked-by: Oliver Neukum <[email protected]>
Signed-off-by: Thinh Nguyen <[email protected]>
Link: https://lore.kernel.org/r/2edc7af892d0913bf06f5b35e49ec463f03d5ed8.1609819418.git.Thinh.Nguyen@synopsys.com
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
With GNU binutils 2.35+, linking with BFD produces warnings for vmlinux:
aarch64-linux-gnu-ld: warning: -z norelro ignored
BFD can produce this warning when the target emulation mode does not
support RELRO program headers, and -z relro or -z norelro is passed.
Alan Modra clarifies:
The default linker emulation for an aarch64-linux ld.bfd is
-maarch64linux, the default for an aarch64-elf linker is
-maarch64elf. They are not equivalent. If you choose -maarch64elf
you get an emulation that doesn't support -z relro.
The ARCH=arm64 kernel prefers -maarch64elf, but may fall back to
-maarch64linux based on the toolchain configuration.
LLD will always create RELRO program header regardless of target
emulation.
To avoid the above warning when linking with BFD, pass -z norelro only
when linking with LLD or with -maarch64linux.
Fixes: 3b92fa7485eb ("arm64: link with -z norelro regardless of CONFIG_RELOCATABLE")
Fixes: 3bbd3db86470 ("arm64: relocatable: fix inconsistencies in linker script and options")
Cc: <[email protected]> # 5.0.x-
Reported-by: kernelci.org bot <[email protected]>
Reported-by: Quentin Perret <[email protected]>
Signed-off-by: Nick Desaulniers <[email protected]>
Reviewed-by: Nathan Chancellor <[email protected]>
Acked-by: Ard Biesheuvel <[email protected]>
Cc: Alan Modra <[email protected]>
Cc: Fāng-ruì Sòng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Catalin Marinas <[email protected]>
|
|
Commit
28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
introduced a new location where a pmd was released, but neglected to
run the pmd page destructor. In fact, this happened previously for a
different pmd release path and was fixed by commit:
c283610e44ec ("x86, mm: do not leak page->ptl for pmd page tables").
This issue was hidden until recently because the failure mode is silent,
but commit:
b2b29d6d0119 ("mm: account PMD tables like PTE tables")
turns the failure mode into this signature:
BUG: Bad page state in process lt-pmem-ns pfn:15943d
page:000000007262ed7b refcount:0 mapcount:-1024 mapping:0000000000000000 index:0x0 pfn:0x15943d
flags: 0xaffff800000000()
raw: 00affff800000000 dead000000000100 0000000000000000 0000000000000000
raw: 0000000000000000 ffff913a029bcc08 00000000fffffbff 0000000000000000
page dumped because: nonzero mapcount
[..]
dump_stack+0x8b/0xb0
bad_page.cold+0x63/0x94
free_pcp_prepare+0x224/0x270
free_unref_page+0x18/0xd0
pud_free_pmd_page+0x146/0x160
ioremap_pud_range+0xe3/0x350
ioremap_page_range+0x108/0x160
__ioremap_caller.constprop.0+0x174/0x2b0
? memremap+0x7a/0x110
memremap+0x7a/0x110
devm_memremap+0x53/0xa0
pmem_attach_disk+0x4ed/0x530 [nd_pmem]
? __devm_release_region+0x52/0x80
nvdimm_bus_probe+0x85/0x210 [libnvdimm]
Given this is a repeat occurrence it seemed prudent to look for other
places where this destructor might be missing and whether a better
helper is needed. try_to_free_pmd_page() looks like a candidate, but
testing with setting up and tearing down pmd mappings via the dax unit
tests is thus far not triggering the failure.
As for a better helper pmd_free() is close, but it is a messy fit
due to requiring an @mm arg. Also, ___pmd_free_tlb() wants to call
paravirt_tlb_remove_table() instead of free_page(), so open-coded
pgtable_pmd_page_dtor() seems the best way forward for now.
Debugged together with Matthew Wilcox <[email protected]>.
Fixes: 28ee90fe6048 ("x86/mm: implement free pmd/pte page interfaces")
Signed-off-by: Dan Williams <[email protected]>
Signed-off-by: Borislav Petkov <[email protected]>
Tested-by: Yi Zhang <[email protected]>
Acked-by: Peter Zijlstra (Intel) <[email protected]>
Cc: <[email protected]>
Link: https://lkml.kernel.org/r/160697689204.605323.17629854984697045602.stgit@dwillia2-desk3.amr.corp.intel.com
|
|
With the apdma remove hand-shake signal, it requirs special
operation timing to reset i2c manually, otherwise the interrupt
will not be triggered, i2c transmission will be timeout.
Fixes: 8426fe70cfa4("i2c: mediatek: Add apdma sync in i2c driver")
Signed-off-by: Qii Wang <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
Since multiple connectors may run intel_dp_aux_xfer conncurrently, a
single global pm_qos does not suffice. (One connector may disable the
dma-latency boost prematurely while the second is still depending on
it.) Instead of a single global pm_qos, track the pm_qos request for
each intel_dp.
v2: Move the pm_qos setup/teardown to intel_dp_aux_init/fini
Fixes: 9ee32fea5fe8 ("drm/i915: irq-drive the dp aux communication")
Signed-off-by: Chris Wilson <[email protected]>
Cc: Ville Syrjälä <[email protected]>
Cc: Imre Deak <[email protected]>
Reviewed-by: Imre Deak <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit b3304591f14b437b6bccd8dbff06006c11837031)
Signed-off-by: Jani Nikula <[email protected]>
|
|
When splitting the Coffeelake define to also identify Cometlakes, I
missed the double fw_def for Coffeelake. That is only newer Cometlakes
use the cml specific guc firmware, older Cometlakes should use kbl
firmware.
Closes: https://gitlab.freedesktop.org/drm/intel/-/issues/2859
Fixes: 5f4ae2704d59 ("drm/i915: Identify Cometlake platform")
Signed-off-by: Chris Wilson <[email protected]>
Cc: <[email protected]> # v5.9+
Reviewed-by: Mika Kuoppala <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
(cherry picked from commit 70960ab27542d8dc322f909f516391f331fbd3f1)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The reloc batch is short lived but can exist in the user visible ppGTT,
and since it's backed by an internal object, which lacks page clearing,
we should take care to clear it upfront.
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Cc: [email protected]
(cherry picked from commit 26ebc511e799f621357982ccc37a7987a56a00f4)
Signed-off-by: Jani Nikula <[email protected]>
|
|
The shadow batch is an internal object, which doesn't have any page
clearing, and since the batch_len can be smaller than the object, we
should take care to clear it.
Testcase: igt/gen9_exec_parse/shadow-peek
Fixes: 4f7af1948abc ("drm/i915: Support ro ppgtt mapped cmdparser shadow buffers")
Signed-off-by: Matthew Auld <[email protected]>
Reviewed-by: Chris Wilson <[email protected]>
Signed-off-by: Chris Wilson <[email protected]>
Link: https://patchwork.freedesktop.org/patch/msgid/[email protected]
Cc: [email protected]
(cherry picked from commit eeb52ee6c4a429ec301faf1dc48988744960786e)
Signed-off-by: Jani Nikula <[email protected]>
|
|
While io_ring_exit_work() is running new requests of all sorts may be
issued, so it should do a bit more to cancel them, otherwise they may
just get stuck. e.g. in io-wq, in poll lists, etc.
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
io_uring fds marked O_CLOEXEC and we explicitly cancel all requests
before going through exec, so we don't want to leave task's file
references to not our anymore io_uring instances.
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
IOPOLL skips completion locking but keeps it under uring_lock, thus
io_cqring_overflow_flush() and so io_cqring_events() need additional
locking with uring_lock in some cases for IOPOLL.
Remove __io_cqring_overflow_flush() from io_cqring_events(), introduce a
wrapper around flush doing needed synchronisation and call it by hand.
Cc: [email protected] # 5.5+
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
io_req_task_submit() might be called for IOPOLL, do the fail path under
uring_lock to comply with IOPOLL synchronisation based solely on it.
Cc: [email protected] # 5.5+
Signed-off-by: Pavel Begunkov <[email protected]>
Signed-off-by: Jens Axboe <[email protected]>
|
|
Pablo Neira Ayuso says:
====================
Netfilter fixes for net
The following patchset contains Netfilter fixes for net:
1) Missing sanitization of rateest userspace string, bug has been
triggered by syzbot, patch from Florian Westphal.
2) Report EOPNOTSUPP on missing set features in nft_dynset, otherwise
error reporting to userspace via EINVAL is misleading since this is
reserved for malformed netlink requests.
3) New binaries with old kernels might silently accept several set
element expressions. New binaries set on the NFT_SET_EXPR and
NFT_DYNSET_F_EXPR flags to request for several expressions per
element, hence old kernels which do not support for this bail out
with EOPNOTSUPP.
* git://git.kernel.org/pub/scm/linux/kernel/git/pablo/nf:
netfilter: nftables: add set expression flags
netfilter: nft_dynset: report EOPNOTSUPP on missing set feature
netfilter: xt_RATEEST: reject non-null terminated string from userspace
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Martin Blumenstingl says:
====================
net: dsa: lantiq_gswip: two fixes for -net/-stable
While testing the lantiq_gswip driver in OpenWrt at least one board had
a non-working Ethernet port connected to an internal 100Mbit/s PHY22F
GPHY. The problem which could be observed:
- the PHY would detect the link just fine
- ethtool stats would see the TX counter rise
- the RX counter in ethtool was stuck at zero
It turns out that two independent patches are needed to fix this:
- first we need to enable the MII data lines also for internal PHYs
- second we need to program the GSWIP_MII_CFG registers for all ports
except the CPU port
These two patches have also been tested by back-porting them on top of
Linux 5.4.86 in OpenWrt.
Special thanks to Hauke for debugging and brainstorming this on IRC
with me!
====================
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
There is one GSWIP_MII_CFG register for each switch-port except the CPU
port. The register offset for the first port is 0x0, 0x02 for the
second, 0x04 for the third and so on.
Update the driver to not only restrict the GSWIP_MII_CFG registers to
ports 0, 1 and 5. Handle ports 0..5 instead but skip the CPU port. This
means we are not overwriting the configuration for the third port (port
two since we start counting from zero) with the settings for the sixth
port (with number five) anymore.
The GSWIP_MII_PCDU(p) registers are not updated because there's really
only three (one for each of the following ports: 0, 1, 5).
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Martin Blumenstingl <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Enable GSWIP_MII_CFG_EN also for internal PHYs to make traffic flow.
Without this the PHY link is detected properly and ethtool statistics
for TX are increasing but there's no RX traffic coming in.
Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Suggested-by: Hauke Mehrtens <[email protected]>
Signed-off-by: Martin Blumenstingl <[email protected]>
Acked-by: Hauke Mehrtens <[email protected]>
Reviewed-by: Florian Fainelli <[email protected]>
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
In lapb_device_event, lapb_devtostruct is called to get a reference to
an object of "struct lapb_cb". lapb_devtostruct increases the refcount
of the object and returns a pointer to it. However, we didn't decrease
the refcount after we finished using the pointer. This patch fixes this
problem.
Fixes: a4989fa91110 ("net/lapb: support netdev events")
Cc: Martin Schiller <[email protected]>
Signed-off-by: Xie He <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
A user reported failing network with RTL8168dp (a quite rare chip
version). Realtek confirmed that few chip versions suffer from a PLL
power-down hw bug.
Fixes: 07df5bd874f0 ("r8169: power down chip in probe")
Signed-off-by: Heiner Kallweit <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
New modem using ff/ff/30 for QCDM, ff/00/00 for AT and NMEA,
and ff/ff/ff for RMNET/QMI.
T: Bus=02 Lev=01 Prnt=01 Port=00 Cnt=01 Dev#= 2 Spd=5000 MxCh= 0
D: Ver= 3.20 Cls=ef(misc ) Sub=02 Prot=01 MxPS= 9 #Cfgs= 1
P: Vendor=2c7c ProdID=0620 Rev= 4.09
S: Manufacturer=Quectel
S: Product=EM160R-GL
S: SerialNumber=e31cedc1
C:* #Ifs= 5 Cfg#= 1 Atr=a0 MxPwr=896mA
I:* If#= 0 Alt= 0 #EPs= 2 Cls=ff(vend.) Sub=ff Prot=30 Driver=(none)
E: Ad=81(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=01(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 1 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=83(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=82(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=02(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 2 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=85(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=84(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=03(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 3 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=00 Prot=00 Driver=(none)
E: Ad=87(I) Atr=03(Int.) MxPS= 10 Ivl=32ms
E: Ad=86(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=04(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
I:* If#= 4 Alt= 0 #EPs= 3 Cls=ff(vend.) Sub=ff Prot=ff Driver=(none)
E: Ad=88(I) Atr=03(Int.) MxPS= 8 Ivl=32ms
E: Ad=8e(I) Atr=02(Bulk) MxPS=1024 Ivl=0ms
E: Ad=0f(O) Atr=02(Bulk) MxPS=1024 Ivl=0ms
Signed-off-by: Bjørn Mork <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The test was setting the headroom size of the wrong port. This was not
visible because of a firmware bug that canceled this bug.
Set the headroom size of the correct port, so that the test will pass
with both old and new firmware versions.
Fixes: bfa804784e32 ("selftests: mlxsw: Add a PFC test")
Signed-off-by: Ido Schimmel <[email protected]>
Reviewed-by: Petr Machata <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
A new flag MACB_CAPS_CLK_HW_CHG was added and all callers of
macb_set_tx_clk were gated on the presence of this flag.
- if (!clk)
+ if (!bp->tx_clk || !(bp->caps & MACB_CAPS_CLK_HW_CHG))
However the flag was not added to anything other than the new
sama7g5_gem, turning that function call into a no op for all other
systems. This breaks the networking on Zynq.
The commit message adding this states: a new capability so that
macb_set_tx_clock() to not be called for IPs having this
capability
This strongly implies that present of the flag was intended to skip
the function not absence of the flag. Update the if statement to
this effect, which repairs the existing users.
Fixes: daafa1d33cc9 ("net: macb: add capability to not set the clock rate")
Suggested-by: Andrew Lunn <[email protected]>
Signed-off-by: Charles Keepax <[email protected]>
Reviewed-by: Claudiu Beznea <[email protected]>
Reviewed-by: Andrew Lunn <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The error is due to dereference a null pointer in function
reset_one_sub_crq_queue():
if (!scrq) {
netdev_dbg(adapter->netdev,
"Invalid scrq reset. irq (%d) or msgs(%p).\n",
scrq->irq, scrq->msgs);
return -EINVAL;
}
If the expression is true, scrq must be a null pointer and cannot
dereference.
Fixes: 9281cf2d5840 ("ibmvnic: avoid memset null scrq msgs")
Signed-off-by: YANG LI <[email protected]>
Reported-by: Abaci <[email protected]>
Acked-by: Lijun Pan <[email protected]>
Link: https://lore.kernel.org/r/1609312994-121032-1-git-send-email-abaci-bugfix@linux.alibaba.com
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Before commit 889b8f964f2f ("packet: Kill CONFIG_PACKET_MMAP.") there
used to be a CONFIG_PACKET_MMAP config symbol that depended on
CONFIG_PACKET. The text still implies that PACKET_MMAP can be disabled.
Remove that from the text, as well as reference to old kernel versions.
Also, drop reference to broken link to information for pre 2.6.5
kernels.
Make a slight working improvement (s/In/On/) while at it.
Signed-off-by: Baruch Siach <[email protected]>
Link: https://lore.kernel.org/r/80089f3783372c8fd7833f28ce774a171b2ef252.1609232919.git.baruch@tkos.co.il
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
The citation of macro definitions should appear in a code block.
Signed-off-by: Baruch Siach <[email protected]>
Link: https://lore.kernel.org/r/5cb47005e7a59b64299e038827e295822193384c.1609232919.git.baruch@tkos.co.il
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Currently the vhost_zerocopy_callback() maybe be called to decrease
the refcount when sendmsg fails in tun. The error handling in vhost
handle_tx_zerocopy() will try to decrease the same refcount again.
This is wrong. To fix this issue, we only call vhost_net_ubuf_put()
when vq->heads[nvq->desc].len == VHOST_DMA_IN_PROGRESS.
Fixes: bab632d69ee4 ("vhost: vhost TX zero-copy support")
Signed-off-by: Yunjian Wang <[email protected]>
Acked-by: Willem de Bruijn <[email protected]>
Acked-by: Michael S. Tsirkin <[email protected]>
Acked-by: Jason Wang <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
In the bareudp6_xmit_skb(), it calculates min_headroom.
At that point, it uses struct iphdr, but it's not correct.
So panic could occur.
The struct ipv6hdr should be used.
Test commands:
ip netns add A
ip netns add B
ip link add veth0 netns A type veth peer name veth1 netns B
ip netns exec A ip link set veth0 up
ip netns exec A ip a a 2001:db8:0::1/64 dev veth0
ip netns exec B ip link set veth1 up
ip netns exec B ip a a 2001:db8:0::2/64 dev veth1
for i in {10..1}
do
let A=$i-1
ip netns exec A ip link add bareudp$i type bareudp dstport $i \
ethertype 0x86dd
ip netns exec A ip link set bareudp$i up
ip netns exec A ip -6 a a 2001:db8:$i::1/64 dev bareudp$i
ip netns exec A ip -6 r a 2001:db8:$i::2 encap ip6 src \
2001:db8:$A::1 dst 2001:db8:$A::2 via 2001:db8:$i::2 \
dev bareudp$i
ip netns exec B ip link add bareudp$i type bareudp dstport $i \
ethertype 0x86dd
ip netns exec B ip link set bareudp$i up
ip netns exec B ip -6 a a 2001:db8:$i::2/64 dev bareudp$i
ip netns exec B ip -6 r a 2001:db8:$i::1 encap ip6 src \
2001:db8:$A::2 dst 2001:db8:$A::1 via 2001:db8:$i::1 \
dev bareudp$i
done
ip netns exec A ping 2001:db8:7::2
Splat looks like:
[ 66.436679][ C2] skbuff: skb_under_panic: text:ffffffff928614c8 len:454 put:14 head:ffff88810abb4000 data:ffff88810abb3ffa tail:0x1c0 end:0x3ec0 dev:veth0
[ 66.441626][ C2] ------------[ cut here ]------------
[ 66.443458][ C2] kernel BUG at net/core/skbuff.c:109!
[ 66.445313][ C2] invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC KASAN PTI
[ 66.447606][ C2] CPU: 2 PID: 913 Comm: ping Not tainted 5.10.0+ #819
[ 66.450251][ C2] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 66.453713][ C2] RIP: 0010:skb_panic+0x15d/0x15f
[ 66.455345][ C2] Code: 98 fe 4c 8b 4c 24 10 53 8b 4d 70 45 89 e0 48 c7 c7 60 8b 78 93 41 57 41 56 41 55 48 8b 54 24 20 48 8b 74 24 28 e8 b5 40 f9 ff <0f> 0b 48 8b 6c 24 20 89 34 24 e8 08 c9 98 fe 8b 34 24 48 c7 c1 80
[ 66.462314][ C2] RSP: 0018:ffff888119209648 EFLAGS: 00010286
[ 66.464281][ C2] RAX: 0000000000000089 RBX: ffff888003159000 RCX: 0000000000000000
[ 66.467216][ C2] RDX: 0000000000000089 RSI: 0000000000000008 RDI: ffffed10232412c0
[ 66.469768][ C2] RBP: ffff88810a53d440 R08: ffffed102328018d R09: ffffed102328018d
[ 66.472297][ C2] R10: ffff888119400c67 R11: ffffed102328018c R12: 000000000000000e
[ 66.474833][ C2] R13: ffff88810abb3ffa R14: 00000000000001c0 R15: 0000000000003ec0
[ 66.477361][ C2] FS: 00007f37c0c72f00(0000) GS:ffff888119200000(0000) knlGS:0000000000000000
[ 66.480214][ C2] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 66.482296][ C2] CR2: 000055a058808570 CR3: 000000011039e002 CR4: 00000000003706e0
[ 66.484811][ C2] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 66.487793][ C2] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400
[ 66.490424][ C2] Call Trace:
[ 66.491469][ C2] <IRQ>
[ 66.492374][ C2] ? eth_header+0x28/0x190
[ 66.494054][ C2] ? eth_header+0x28/0x190
[ 66.495401][ C2] skb_push.cold.99+0x22/0x22
[ 66.496700][ C2] eth_header+0x28/0x190
[ 66.497867][ C2] neigh_resolve_output+0x3de/0x720
[ 66.499615][ C2] ? __neigh_update+0x7e8/0x20a0
[ 66.501176][ C2] __neigh_update+0x8bd/0x20a0
[ 66.502749][ C2] ndisc_update+0x34/0xc0
[ 66.504010][ C2] ndisc_recv_na+0x8da/0xb80
[ 66.505041][ C2] ? pndisc_redo+0x20/0x20
[ 66.505888][ C2] ? rcu_read_lock_sched_held+0xc0/0xc0
[ 66.506965][ C2] ndisc_rcv+0x3a0/0x470
[ 66.507797][ C2] icmpv6_rcv+0xad9/0x1b00
[ 66.508645][ C2] ip6_protocol_deliver_rcu+0xcd6/0x1560
[ 66.509719][ C2] ip6_input_finish+0x5b/0xf0
[ 66.510615][ C2] ip6_input+0xcd/0x2d0
[ 66.511406][ C2] ? ip6_input_finish+0xf0/0xf0
[ 66.512327][ C2] ? rcu_read_lock_held+0x91/0xa0
[ 66.513279][ C2] ? ip6_protocol_deliver_rcu+0x1560/0x1560
[ 66.514414][ C2] ipv6_rcv+0xe8/0x300
[ ... ]
Acked-by: Guillaume Nault <[email protected]>
Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
Signed-off-by: Taehee Yoo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
Like other tunneling interfaces, the bareudp doesn't need TXLOCK.
So, It is good to set the NETIF_F_LLTX flag to improve performance and
to avoid lockdep's false-positive warning.
Test commands:
ip netns add A
ip netns add B
ip link add veth0 netns A type veth peer name veth1 netns B
ip netns exec A ip link set veth0 up
ip netns exec A ip a a 10.0.0.1/24 dev veth0
ip netns exec B ip link set veth1 up
ip netns exec B ip a a 10.0.0.2/24 dev veth1
for i in {2..1}
do
let A=$i-1
ip netns exec A ip link add bareudp$i type bareudp \
dstport $i ethertype ip
ip netns exec A ip link set bareudp$i up
ip netns exec A ip a a 10.0.$i.1/24 dev bareudp$i
ip netns exec A ip r a 10.0.$i.2 encap ip src 10.0.$A.1 \
dst 10.0.$A.2 via 10.0.$i.2 dev bareudp$i
ip netns exec B ip link add bareudp$i type bareudp \
dstport $i ethertype ip
ip netns exec B ip link set bareudp$i up
ip netns exec B ip a a 10.0.$i.2/24 dev bareudp$i
ip netns exec B ip r a 10.0.$i.1 encap ip src 10.0.$A.2 \
dst 10.0.$A.1 via 10.0.$i.1 dev bareudp$i
done
ip netns exec A ping 10.0.2.2
Splat looks like:
[ 96.992803][ T822] ============================================
[ 96.993954][ T822] WARNING: possible recursive locking detected
[ 96.995102][ T822] 5.10.0+ #819 Not tainted
[ 96.995927][ T822] --------------------------------------------
[ 96.997091][ T822] ping/822 is trying to acquire lock:
[ 96.998083][ T822] ffff88810f753898 (_xmit_NONE#2){+.-.}-{2:2}, at: __dev_queue_xmit+0x1f52/0x2960
[ 96.999813][ T822]
[ 96.999813][ T822] but task is already holding lock:
[ 97.001192][ T822] ffff88810c385498 (_xmit_NONE#2){+.-.}-{2:2}, at: __dev_queue_xmit+0x1f52/0x2960
[ 97.002908][ T822]
[ 97.002908][ T822] other info that might help us debug this:
[ 97.004401][ T822] Possible unsafe locking scenario:
[ 97.004401][ T822]
[ 97.005784][ T822] CPU0
[ 97.006407][ T822] ----
[ 97.007010][ T822] lock(_xmit_NONE#2);
[ 97.007779][ T822] lock(_xmit_NONE#2);
[ 97.008550][ T822]
[ 97.008550][ T822] *** DEADLOCK ***
[ 97.008550][ T822]
[ 97.010057][ T822] May be due to missing lock nesting notation
[ 97.010057][ T822]
[ 97.011594][ T822] 7 locks held by ping/822:
[ 97.012426][ T822] #0: ffff888109a144f0 (sk_lock-AF_INET){+.+.}-{0:0}, at: raw_sendmsg+0x12f7/0x2b00
[ 97.014191][ T822] #1: ffffffffbce2f5a0 (rcu_read_lock_bh){....}-{1:2}, at: ip_finish_output2+0x249/0x2020
[ 97.016045][ T822] #2: ffffffffbce2f5a0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1fd/0x2960
[ 97.017897][ T822] #3: ffff88810c385498 (_xmit_NONE#2){+.-.}-{2:2}, at: __dev_queue_xmit+0x1f52/0x2960
[ 97.019684][ T822] #4: ffffffffbce2f600 (rcu_read_lock){....}-{1:2}, at: bareudp_xmit+0x31b/0x3690 [bareudp]
[ 97.021573][ T822] #5: ffffffffbce2f5a0 (rcu_read_lock_bh){....}-{1:2}, at: ip_finish_output2+0x249/0x2020
[ 97.023424][ T822] #6: ffffffffbce2f5a0 (rcu_read_lock_bh){....}-{1:2}, at: __dev_queue_xmit+0x1fd/0x2960
[ 97.025259][ T822]
[ 97.025259][ T822] stack backtrace:
[ 97.026349][ T822] CPU: 3 PID: 822 Comm: ping Not tainted 5.10.0+ #819
[ 97.027609][ T822] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 1.10.2-1ubuntu1 04/01/2014
[ 97.029407][ T822] Call Trace:
[ 97.030015][ T822] dump_stack+0x99/0xcb
[ 97.030783][ T822] __lock_acquire.cold.77+0x149/0x3a9
[ 97.031773][ T822] ? stack_trace_save+0x81/0xa0
[ 97.032661][ T822] ? register_lock_class+0x1910/0x1910
[ 97.033673][ T822] ? register_lock_class+0x1910/0x1910
[ 97.034679][ T822] ? rcu_read_lock_sched_held+0x91/0xc0
[ 97.035697][ T822] ? rcu_read_lock_bh_held+0xa0/0xa0
[ 97.036690][ T822] lock_acquire+0x1b2/0x730
[ 97.037515][ T822] ? __dev_queue_xmit+0x1f52/0x2960
[ 97.038466][ T822] ? check_flags+0x50/0x50
[ 97.039277][ T822] ? netif_skb_features+0x296/0x9c0
[ 97.040226][ T822] ? validate_xmit_skb+0x29/0xb10
[ 97.041151][ T822] _raw_spin_lock+0x30/0x70
[ 97.041977][ T822] ? __dev_queue_xmit+0x1f52/0x2960
[ 97.042927][ T822] __dev_queue_xmit+0x1f52/0x2960
[ 97.043852][ T822] ? netdev_core_pick_tx+0x290/0x290
[ 97.044824][ T822] ? mark_held_locks+0xb7/0x120
[ 97.045712][ T822] ? lockdep_hardirqs_on_prepare+0x12c/0x3e0
[ 97.046824][ T822] ? __local_bh_enable_ip+0xa5/0xf0
[ 97.047771][ T822] ? ___neigh_create+0x12a8/0x1eb0
[ 97.048710][ T822] ? trace_hardirqs_on+0x41/0x120
[ 97.049626][ T822] ? ___neigh_create+0x12a8/0x1eb0
[ 97.050556][ T822] ? __local_bh_enable_ip+0xa5/0xf0
[ 97.051509][ T822] ? ___neigh_create+0x12a8/0x1eb0
[ 97.052443][ T822] ? check_chain_key+0x244/0x5f0
[ 97.053352][ T822] ? rcu_read_lock_bh_held+0x56/0xa0
[ 97.054317][ T822] ? ip_finish_output2+0x6ea/0x2020
[ 97.055263][ T822] ? pneigh_lookup+0x410/0x410
[ 97.056135][ T822] ip_finish_output2+0x6ea/0x2020
[ ... ]
Acked-by: Guillaume Nault <[email protected]>
Fixes: 571912c69f0e ("net: UDP tunnel encapsulation module for tunnelling different protocols like MPLS, IP, NSH etc.")
Signed-off-by: Taehee Yoo <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Jakub Kicinski <[email protected]>
|
|
git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu
Pull RCU fix from Paul McKenney:
"This is a fix for a regression in the v5.10 merge window, but it was
reported quite late in the v5.10 process, plus generating and testing
the fix took some time.
The regression is due to commit 36dadef23fcc ("kprobes: Init kprobes
in early_initcall") which on powerpc can use RCU Tasks before
initialization, resulting in boot failures.
The fix is straightforward, simply moving initialization of RCU Tasks
before the early_initcall()s. The fix has been exposed to -next and
kbuild test robot testing, and has been tested by the PowerPC guys"
* 'rcu/urgent' of git://git.kernel.org/pub/scm/linux/kernel/git/paulmck/linux-rcu:
rcu-tasks: Move RCU-tasks initialization to before early_initcall()
|
|
Pull ENABLE_MUST_CHECK removal from Miguel Ojeda:
"Remove CONFIG_ENABLE_MUST_CHECK (Masahiro Yamada)"
Note that this removes the config option by making the must-check
unconditional, not by removing must check itself.
* tag 'compiler-attributes-for-linus-v5.11' of git://github.com/ojeda/linux:
Compiler Attributes: remove CONFIG_ENABLE_MUST_CHECK
|
|
Merge two commits that had dependencies on other 5.11 trees (the block
and the irq trees respectively).
- We reverted a megaraid_sas change in 5.10 due to missing block
layer plumbing. Now that this is in place, reinstate the change.
- The hisi_sas driver had a dependency on a driver core irq change
that went in through Thomas' tree.
Signed-off-by: Martin K. Petersen <[email protected]>
|
|
gpiod_add_lookup_table() expects the gpiod_lookup_table->table passed to
it to be terminated with a zero-ed out entry.
So we need to allocate one more entry then we will use.
Fixes: d308dfbf62ef ("i2c: mux/i801: Switch to use descriptor passing")
Signed-off-by: Hans de Goede <[email protected]>
Reviewed-by: Mika Westerberg <[email protected]>
Acked-by: Jean Delvare <[email protected]>
Reviewed-by: Linus Walleij <[email protected]>
Signed-off-by: Wolfram Sang <[email protected]>
|
|
If the i2c device SCL bus being pulled up due to some exception before
message transfer done, the system cannot receive the completing interrupt
signal any more, it would not exit waiting loop until MAX_SCHEDULE_TIMEOUT
jiffies eclipse, that would make the system seemed hang up. To avoid that
happen, this patch adds a specific timeout for message transfer.
Fixes: 8b9ec0719834 ("i2c: Add Spreadtrum I2C controller driver")
Signed-off-by: Linhua Xu <[email protected]>
Signed-off-by: Chunyan Zhang <[email protected]>
[wsa: changed errno to ETIMEDOUT]
Signed-off-by: Wolfram Sang <[email protected]>
|
|
KVM_ARM_PMU only existed for the benefit of 32bit ARM hosts,
and makes no sense now that we are 64bit only. Get rid of it.
Signed-off-by: Marc Zyngier <[email protected]>
|
|
Fix the following -Wformat warnings in vdso_test_correctness.c:
vdso_test_correctness.c: In function ‘test_one_clock_gettime64’:
vdso_test_correctness.c:352:21: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 3 has type ‘long long int’ [-Wformat=]
352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n",
| ~~~~^
| |
| long int
| %09lld
353 | (unsigned long long)start.tv_sec, start.tv_nsec,
| ~~~~~~~~~~~~~
| |
| long long int
vdso_test_correctness.c:352:32: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 5 has type ‘long long int’ [-Wformat=]
352 | printf("\t%llu.%09ld %llu.%09ld %llu.%09ld\n",
| ~~~~^
| |
| long int
| %09lld
353 | (unsigned long long)start.tv_sec, start.tv_nsec,
354 | (unsigned long long)vdso.tv_sec, vdso.tv_nsec,
| ~~~~~~~~~~~~
| |
| long long int
vdso_test_correctness.c:352:43: warning: format ‘%ld’ expects argument of type ‘long int’, but argument 7 has type ‘long long int’ [-Wformat=]
The tv_sec member of __kernel_timespec is long long, both in
uapi/linux/time_types.h and locally in vdso_test_correctness.c.
Signed-off-by: Tobias Klauser <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
Add the test binaries introduced by commit 693f5ca08ca0 ("kselftest:
Extend vDSO selftest"), commit 03f55c7952c9 ("kselftest: Extend vDSO
selftest to clock_getres") and commit c7e5789b24d3 ("kselftest: Move
test_vdso to the vDSO test suite") to .gitignore.
Signed-off-by: Tobias Klauser <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
|
|
kunit_tool relies on the UML console outputting printk() output to the
tty in order to get results. Since the default console driver could
change, pass 'console=tty' to the kernel.
This is triggered by a change[1] to use ttynull as a fallback console
driver which -- by chance or by design -- seems to have changed the
default console output on UML, breaking kunit_tool. While this may be
fixed, we should be less fragile to such changes in the default.
[1]:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=757055ae8dedf5333af17b3b5b4b70ba9bc9da4e
Signed-off-by: David Gow <[email protected]>
Fixes: 757055ae8ded ("init/console: Use ttynull as a fallback when there is no console")
Reported-by: Andy Shevchenko <[email protected]>
Tested-by: Andy Shevchenko <[email protected]>
Acked-by: Brendan Higgins <[email protected]>
Signed-off-by: Shuah Khan <[email protected]>
|
|
STM32_MDMA_VERY_HIGH_PRIORITY is b11 not 0x11, so fix it with 0x3.
Signed-off-by: Amelie Delaunay <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Vinod Koul <[email protected]>
|
|
When binding the ConfigFS gadget to a UDC, the functions in each
configuration are added in list order. However, if usb_add_function()
fails, the failed function is put back on its configuration's
func_list and purge_configs_funcs() is called to further clean up.
purge_configs_funcs() iterates over the configurations and functions
in forward order, calling unbind() on each of the previously added
functions. But after doing so, each function gets moved to the
tail of the configuration's func_list. This results in reshuffling
the original order of the functions within a configuration such
that the failed function now appears first even though it may have
originally appeared in the middle or even end of the list. At this
point if the ConfigFS gadget is attempted to re-bind to the UDC,
the functions will be added in a different order than intended,
with the only recourse being to remove and relink the functions all
over again.
An example of this as follows:
ln -s functions/mass_storage.0 configs/c.1
ln -s functions/ncm.0 configs/c.1
ln -s functions/ffs.adb configs/c.1 # oops, forgot to start adbd
echo "<udc device>" > UDC # fails
start adbd
echo "<udc device>" > UDC # now succeeds, but...
# bind order is
# "ADB", mass_storage, ncm
[30133.118289] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
[30133.119875] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
[30133.119974] using random self ethernet address
[30133.120002] using random host ethernet address
[30133.139604] usb0: HOST MAC 3e:27:46:ba:3e:26
[30133.140015] usb0: MAC 6e:28:7e:42:66:6a
[30133.140062] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
[30133.140081] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 --> -19
[30133.140098] configfs-gadget gadget: unbind function 'Mass Storage Function'/ffffff810af87200
[30133.140119] configfs-gadget gadget: unbind function 'cdc_network'/ffffff80f48d1a00
[30133.173201] configfs-gadget a600000.dwc3: failed to start g1: -19
[30136.661933] init: starting service 'adbd'...
[30136.700126] read descriptors
[30136.700413] read strings
[30138.574484] configfs-gadget gadget: adding 'Function FS Gadget'/ffffff80f3868438 to config 'c'/ffffff817d6a2520
[30138.575497] configfs-gadget gadget: adding 'Mass Storage Function'/ffffff810af87200 to config 'c'/ffffff817d6a2520
[30138.575554] configfs-gadget gadget: adding 'cdc_network'/ffffff80f48d1a00 to config 'c'/ffffff817d6a2520
[30138.575631] using random self ethernet address
[30138.575660] using random host ethernet address
[30138.595338] usb0: HOST MAC 2e:cf:43:cd:ca:c8
[30138.597160] usb0: MAC 6a:f0:9f:ee:82:a0
[30138.791490] configfs-gadget gadget: super-speed config #1: c
Fix this by reversing the iteration order of the functions in
purge_config_funcs() when unbinding them, and adding them back to
the config's func_list at the head instead of the tail. This
ensures that we unbind and unwind back to the original list order.
Fixes: 88af8bbe4ef7 ("usb: gadget: the start of the configfs interface")
Signed-off-by: Chandana Kishori Chiluveru <[email protected]>
Signed-off-by: Jack Pham <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Cc: stable <[email protected]>
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Without crc32 support, this driver fails to link:
arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_eem.o: in function `eem_unwrap':
f_eem.c:(.text+0x11cc): undefined reference to `crc32_le'
arm-linux-gnueabi-ld: drivers/usb/gadget/function/f_ncm.o:f_ncm.c:(.text+0x1e40):
more undefined references to `crc32_le' follow
Fixes: 6d3865f9d41f ("usb: gadget: NCM: Add transmit multi-frame.")
Signed-off-by: Arnd Bergmann <[email protected]>
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
The pullup does not need to be enabled at below situations:
- For platforms which the hardware pullup starts after setting
register even they do not see the VBUS. If the pullup is always
enabled for these platforms, it will consume more power and
break the USB IF compliance tests [1].
- For platforms which need to do BC 1.2 charger detection after
seeing the VBUS. Pullup D+ will break the charger detection
flow.
- For platforms which the system suspend is allowed when the
connection with host is there but the bus is not at suspend.
For these platforms, it is better to disable pullup when
entering the system suspend otherwise the host may confuse
the device behavior after controller is in low power mode.
Disable pullup is considered as a disconnection event from
host side.
[1] USB-IF Full and Low Speed Compliance Test Procedure
F Back-voltage Testing
Section 7.2.1 of the USB specification requires that no device
shall supply (source) current on VBUS at its upstream facing
port at any time. From VBUS on its upstream facing port,
a device may only draw (sink) current. They may not provide power
to the pull-up resistor on D+/D- unless VBUS is present (see
Section 7.1.5).
Signed-off-by: Peter Chen <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
There is a use-after-free issue, if access udc_name
in function gadget_dev_desc_UDC_store after another context
free udc_name in function unregister_gadget.
Context 1:
gadget_dev_desc_UDC_store()->unregister_gadget()->
free udc_name->set udc_name to NULL
Context 2:
gadget_dev_desc_UDC_show()-> access udc_name
Call trace:
dump_backtrace+0x0/0x340
show_stack+0x14/0x1c
dump_stack+0xe4/0x134
print_address_description+0x78/0x478
__kasan_report+0x270/0x2ec
kasan_report+0x10/0x18
__asan_report_load1_noabort+0x18/0x20
string+0xf4/0x138
vsnprintf+0x428/0x14d0
sprintf+0xe4/0x12c
gadget_dev_desc_UDC_show+0x54/0x64
configfs_read_file+0x210/0x3a0
__vfs_read+0xf0/0x49c
vfs_read+0x130/0x2b4
SyS_read+0x114/0x208
el0_svc_naked+0x34/0x38
Add mutex_lock to protect this kind of scenario.
Signed-off-by: Eddie Hung <[email protected]>
Signed-off-by: Macpaul Lin <[email protected]>
Reviewed-by: Peter Chen <[email protected]>
Cc: [email protected]
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
usb_gadget_deactivate/usb_gadget_activate does not execute the UDC start
operation, which may leave EP0 disabled and event IRQs disabled when
re-activating the function. Move the enabling/disabling of USB EP0 and
device event IRQs to be performed in the pullup routine.
Fixes: ae7e86108b12 ("usb: dwc3: Stop active transfers before halting the controller")
Tested-by: Michael Tretter <[email protected]>
Cc: stable <[email protected]>
Reported-by: Michael Tretter <[email protected]>
Signed-off-by: Wesley Cheng <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|
|
Fix shift out-of-bounds in vhci_hcd.c:
UBSAN: shift-out-of-bounds in ../drivers/usb/usbip/vhci_hcd.c:399:41
shift exponent 768 is too large for 32-bit type 'int'
Fixes: 03cd00d538a6 ("usbip: vhci-hcd: Set the vhci structure up to work")
Signed-off-by: Randy Dunlap <[email protected]>
Reported-by: [email protected]
Cc: Yuyang Du <[email protected]>
Cc: Shuah Khan <[email protected]>
Cc: Greg Kroah-Hartman <[email protected]>
Cc: [email protected]
Cc: stable <[email protected]>
Link: https://lore.kernel.org/r/[email protected]
Signed-off-by: Greg Kroah-Hartman <[email protected]>
|