This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
------------- Pseudo-Shortlog of commits:
Greg Kroah-Hartman gregkh@linuxfoundation.org Linux 4.9.265-rc1
Paul Moore paul@paul-moore.com audit: fix a net reference leak in audit_list_rules_send()
Paul Moore paul@paul-moore.com audit: fix a net reference leak in audit_send_reply()
Atul Gopinathan atulgopinathan@gmail.com staging: rtl8192e: Change state information from u16 to u8
Atul Gopinathan atulgopinathan@gmail.com staging: rtl8192e: Fix incorrect source in memcpy()
Johan Hovold johan@kernel.org USB: cdc-acm: fix use-after-free after probe failure
Oliver Neukum oneukum@suse.com USB: cdc-acm: downgrade message to debug
Oliver Neukum oneukum@suse.com cdc-acm: fix BREAK rx code path adding necessary calls
Chunfeng Yun chunfeng.yun@mediatek.com usb: xhci-mtk: fix broken streams issue on 0.96 xHCI
Vincent Palatin vpalatin@chromium.org USB: quirks: ignore remote wake-up on Fibocom L850-GL LTE modem
Zheyu Ma zheyuma97@gmail.com firewire: nosy: Fix a use-after-free bug in nosy_ioctl()
Dinghao Liu dinghao.liu@zju.edu.cn extcon: Fix error handling in extcon_dev_register
Wang Panzhenzhuan randy.wang@rock-chips.com pinctrl: rockchip: fix restore error in resume
Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp reiserfs: update reiserfs_xattrs_initialized() condition
Ilya Lipnitskiy ilya.lipnitskiy@gmail.com mm: fix race by making init_zero_pfn() early_initcall
Steven Rostedt (VMware) rostedt@goodmis.org tracing: Fix stack trace event size
Hui Wang hui.wang@canonical.com ALSA: hda/realtek: call alc_update_headset_mode() in hp_automute_hook
Ikjoon Jang ikjn@chromium.org ALSA: usb-audio: Apply sample rate quirk to Logitech Connect
Jesper Dangaard Brouer brouer@redhat.com bpf: Remove MTU check in __bpf_skb_max_len
Tong Zhang ztong0001@gmail.com net: wan/lmc: unregister device when no matching device is found
Doug Brown doug@schmorgal.com appletalk: Fix skb allocation size in loopback case
zhangyi (F) yi.zhang@huawei.com ext4: do not iput inode under running transaction in ext4_rename()
Sameer Pujar spujar@nvidia.com ASoC: rt5659: Update MCLK rate in set_sysclk()
Tong Zhang ztong0001@gmail.com staging: comedi: cb_pcidas64: fix request_irq() warn
Tong Zhang ztong0001@gmail.com staging: comedi: cb_pcidas: fix request_irq() warn
Alexey Dobriyan adobriyan@gmail.com scsi: qla2xxx: Fix broken #endif placement
Lv Yunlong lyl2019@mail.ustc.edu.cn scsi: st: Fix a use after free in st_open()
Laurent Vivier lvivier@redhat.com vhost: Fix vhost_vq_reset()
Christophe Leroy christophe.leroy@csgroup.eu powerpc: Force inlining of cpu_has_feature() to avoid build failure
Benjamin Rood benjaminjrood@gmail.com ASoC: sgtl5000: set DAP_AVC_CTRL register to correct default value on probe
Hans de Goede hdegoede@redhat.com ASoC: rt5651: Fix dac- and adc- vol-tlv values being off by a factor of 10
Hans de Goede hdegoede@redhat.com ASoC: rt5640: Fix dac- and adc- vol-tlv values being off by a factor of 10
J. Bruce Fields bfields@redhat.com rpc: fix NULL dereference on kmalloc failure
Zhaolong Zhang zhangzl2013@126.com ext4: fix bh ref count on error paths
Jakub Kicinski kuba@kernel.org ipv6: weaken the v4mapped source check
David Brazdil dbrazdil@google.com selinux: vsock: Set SID for socket returned by accept()
-------------
Diffstat:
Makefile | 4 +-- arch/powerpc/include/asm/cpu_has_feature.h | 4 +-- drivers/extcon/extcon.c | 1 + drivers/firewire/nosy.c | 9 ++++-- drivers/net/wan/lmc/lmc_main.c | 2 ++ drivers/pinctrl/pinctrl-rockchip.c | 13 +++++--- drivers/scsi/qla2xxx/qla_target.h | 2 +- drivers/scsi/st.c | 2 +- drivers/staging/comedi/drivers/cb_pcidas.c | 2 +- drivers/staging/comedi/drivers/cb_pcidas64.c | 2 +- drivers/staging/rtl8192e/rtllib.h | 2 +- drivers/staging/rtl8192e/rtllib_rx.c | 2 +- drivers/usb/class/cdc-acm.c | 12 +++++-- drivers/usb/core/quirks.c | 4 +++ drivers/usb/host/xhci-mtk.c | 10 +++++- drivers/vhost/vhost.c | 2 +- fs/ext4/inode.c | 6 ++-- fs/ext4/namei.c | 18 +++++------ fs/reiserfs/xattr.h | 2 +- kernel/audit.c | 48 +++++++++++++++++----------- kernel/audit.h | 2 +- kernel/auditfilter.c | 13 ++++---- kernel/trace/trace.c | 3 +- mm/memory.c | 2 +- net/appletalk/ddp.c | 33 ++++++++++++------- net/core/filter.c | 7 ++-- net/dccp/ipv6.c | 5 +++ net/ipv6/ip6_input.c | 10 ------ net/ipv6/tcp_ipv6.c | 5 +++ net/sunrpc/auth_gss/svcauth_gss.c | 11 ++++--- net/vmw_vsock/af_vsock.c | 1 + sound/pci/hda/patch_realtek.c | 1 + sound/soc/codecs/rt5640.c | 4 +-- sound/soc/codecs/rt5651.c | 4 +-- sound/soc/codecs/rt5659.c | 5 +++ sound/soc/codecs/sgtl5000.c | 2 +- sound/usb/quirks.c | 1 + 37 files changed, 157 insertions(+), 99 deletions(-)
From: David Brazdil dbrazdil@google.com
[ Upstream commit 1f935e8e72ec28dddb2dc0650b3b6626a293d94b ]
For AF_VSOCK, accept() currently returns sockets that are unlabelled. Other socket families derive the child's SID from the SID of the parent and the SID of the incoming packet. This is typically done as the connected socket is placed in the queue that accept() removes from.
Reuse the existing 'security_sk_clone' hook to copy the SID from the parent (server) socket to the child. There is no packet SID in this case.
Fixes: d021c344051a ("VSOCK: Introduce VM Sockets") Signed-off-by: David Brazdil dbrazdil@google.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- net/vmw_vsock/af_vsock.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/net/vmw_vsock/af_vsock.c b/net/vmw_vsock/af_vsock.c index bd3a5ef8e59b..2fecdfe49bae 100644 --- a/net/vmw_vsock/af_vsock.c +++ b/net/vmw_vsock/af_vsock.c @@ -650,6 +650,7 @@ struct sock *__vsock_create(struct net *net, vsk->trusted = psk->trusted; vsk->owner = get_cred(psk->owner); vsk->connect_timeout = psk->connect_timeout; + security_sk_clone(parent, sk); } else { vsk->trusted = ns_capable_noaudit(&init_user_ns, CAP_NET_ADMIN); vsk->owner = get_current_cred();
From: Jakub Kicinski kuba@kernel.org
[ Upstream commit dcc32f4f183ab8479041b23a1525d48233df1d43 ]
This reverts commit 6af1799aaf3f1bc8defedddfa00df3192445bbf3.
Commit 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") introduced an input check against v4mapped addresses. Use of such addresses on the wire is indeed questionable and not allowed on public Internet. As the commit pointed out
https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02
lists potential issues.
Unfortunately there are applications which use v4mapped addresses, and breaking them is a clear regression. For example v4mapped addresses (or any semi-valid addresses, really) may be used for uni-direction event streams or packet export.
Since the issue which sparked the addition of the check was with TCP and request_socks in particular push the check down to TCPv6 and DCCP. This restores the ability to receive UDPv6 packets with v4mapped address as the source.
Keep using the IPSTATS_MIB_INHDRERRORS statistic to minimize the user-visible changes.
Fixes: 6af1799aaf3f ("ipv6: drop incoming packets having a v4mapped source address") Reported-by: Sunyi Shao sunyishao@fb.com Signed-off-by: Jakub Kicinski kuba@kernel.org Acked-by: Mat Martineau mathew.j.martineau@linux.intel.com Reviewed-by: Eric Dumazet edumazet@google.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- net/dccp/ipv6.c | 5 +++++ net/ipv6/ip6_input.c | 10 ---------- net/ipv6/tcp_ipv6.c | 5 +++++ 3 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/net/dccp/ipv6.c b/net/dccp/ipv6.c index 9438873fc3c8..ae62c2947278 100644 --- a/net/dccp/ipv6.c +++ b/net/dccp/ipv6.c @@ -317,6 +317,11 @@ static int dccp_v6_conn_request(struct sock *sk, struct sk_buff *skb) if (!ipv6_unicast_destination(skb)) return 0; /* discard, don't send a reset here */
+ if (ipv6_addr_v4mapped(&ipv6_hdr(skb)->saddr)) { + __IP6_INC_STATS(sock_net(sk), NULL, IPSTATS_MIB_INHDRERRORS); + return 0; + } + if (dccp_bad_service_code(sk, service)) { dcb->dccpd_reset_code = DCCP_RESET_CODE_BAD_SERVICE_CODE; goto drop; diff --git a/net/ipv6/ip6_input.c b/net/ipv6/ip6_input.c index e726a61ae6dc..aacfb4bce153 100644 --- a/net/ipv6/ip6_input.c +++ b/net/ipv6/ip6_input.c @@ -168,16 +168,6 @@ int ipv6_rcv(struct sk_buff *skb, struct net_device *dev, struct packet_type *pt if (ipv6_addr_is_multicast(&hdr->saddr)) goto err;
- /* While RFC4291 is not explicit about v4mapped addresses - * in IPv6 headers, it seems clear linux dual-stack - * model can not deal properly with these. - * Security models could be fooled by ::ffff:127.0.0.1 for example. - * - * https://tools.ietf.org/html/draft-itojun-v6ops-v4mapped-harmful-02 - */ - if (ipv6_addr_v4mapped(&hdr->saddr)) - goto err; - skb->transport_header = skb->network_header + sizeof(*hdr); IP6CB(skb)->nhoff = offsetof(struct ipv6hdr, nexthdr);
diff --git a/net/ipv6/tcp_ipv6.c b/net/ipv6/tcp_ipv6.c index 7b336b7803ff..dfddf2bfa7e1 100644 --- a/net/ipv6/tcp_ipv6.c +++ b/net/ipv6/tcp_ipv6.c @@ -986,6 +986,11 @@ static int tcp_v6_conn_request(struct sock *sk, struct sk_buff *skb) if (!ipv6_unicast_destination(skb)) goto drop;
+ if (ipv6_addr_v4mapped(&ipv6_hdr(skb)->saddr)) { + __IP6_INC_STATS(sock_net(sk), NULL, IPSTATS_MIB_INHDRERRORS); + return 0; + } + return tcp_conn_request(&tcp6_request_sock_ops, &tcp_request_sock_ipv6_ops, sk, skb);
From: Zhaolong Zhang zhangzl2013@126.com
[ Upstream commit c915fb80eaa6194fa9bd0a4487705cd5b0dda2f1 ]
__ext4_journalled_writepage should drop bhs' ref count on error paths
Signed-off-by: Zhaolong Zhang zhangzl2013@126.com Link: https://lore.kernel.org/r/1614678151-70481-1-git-send-email-zhangzl2013@126.... Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin sashal@kernel.org --- fs/ext4/inode.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/fs/ext4/inode.c b/fs/ext4/inode.c index aa97a3ed3d8f..79c067f74253 100644 --- a/fs/ext4/inode.c +++ b/fs/ext4/inode.c @@ -1978,13 +1978,13 @@ static int __ext4_journalled_writepage(struct page *page, if (!ret) ret = err;
- if (!ext4_has_inline_data(inode)) - ext4_walk_page_buffers(NULL, page_bufs, 0, len, - NULL, bput_one); ext4_set_inode_state(inode, EXT4_STATE_JDATA); out: unlock_page(page); out_no_pagelock: + if (!inline_data && page_bufs) + ext4_walk_page_buffers(NULL, page_bufs, 0, len, + NULL, bput_one); brelse(inode_bh); return ret; }
From: J. Bruce Fields bfields@redhat.com
[ Upstream commit 0ddc942394013f08992fc379ca04cffacbbe3dae ]
I think this is unlikely but possible:
svc_authenticate sets rq_authop and calls svcauth_gss_accept. The kmalloc(sizeof(*svcdata), GFP_KERNEL) fails, leaving rq_auth_data NULL, and returning SVC_DENIED.
This causes svc_process_common to go to err_bad_auth, and eventually call svc_authorise. That calls ->release == svcauth_gss_release, which tries to dereference rq_auth_data.
Signed-off-by: J. Bruce Fields bfields@redhat.com Link: https://lore.kernel.org/linux-nfs/3F1B347F-B809-478F-A1E9-0BE98E22B0F0@oracl... Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org --- net/sunrpc/auth_gss/svcauth_gss.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)
diff --git a/net/sunrpc/auth_gss/svcauth_gss.c b/net/sunrpc/auth_gss/svcauth_gss.c index fd897d900d12..85ad23d9a8a9 100644 --- a/net/sunrpc/auth_gss/svcauth_gss.c +++ b/net/sunrpc/auth_gss/svcauth_gss.c @@ -1705,11 +1705,14 @@ static int svcauth_gss_release(struct svc_rqst *rqstp) { struct gss_svc_data *gsd = (struct gss_svc_data *)rqstp->rq_auth_data; - struct rpc_gss_wire_cred *gc = &gsd->clcred; + struct rpc_gss_wire_cred *gc; struct xdr_buf *resbuf = &rqstp->rq_res; int stat = -EINVAL; struct sunrpc_net *sn = net_generic(SVC_NET(rqstp), sunrpc_net_id);
+ if (!gsd) + goto out; + gc = &gsd->clcred; if (gc->gc_proc != RPC_GSS_PROC_DATA) goto out; /* Release can be called twice, but we only wrap once. */ @@ -1750,10 +1753,10 @@ out_err: if (rqstp->rq_cred.cr_group_info) put_group_info(rqstp->rq_cred.cr_group_info); rqstp->rq_cred.cr_group_info = NULL; - if (gsd->rsci) + if (gsd && gsd->rsci) { cache_put(&gsd->rsci->h, sn->rsc_cache); - gsd->rsci = NULL; - + gsd->rsci = NULL; + } return stat; }
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit cfa26ed1f9f885c2fd8f53ca492989d1e16d0199 ]
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale.
E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer.
Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize.
Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver.
Signed-off-by: Hans de Goede hdegoede@redhat.com Link: https://lore.kernel.org/r/20210226143817.84287-2-hdegoede@redhat.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/rt5640.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5640.c b/sound/soc/codecs/rt5640.c index 3cc1135fc2cd..81fbbcaf8121 100644 --- a/sound/soc/codecs/rt5640.c +++ b/sound/soc/codecs/rt5640.c @@ -341,9 +341,9 @@ static bool rt5640_readable_register(struct device *dev, unsigned int reg) }
static const DECLARE_TLV_DB_SCALE(out_vol_tlv, -4650, 150, 0); -static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -65625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(dac_vol_tlv, -6562, 0); static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0); -static const DECLARE_TLV_DB_SCALE(adc_vol_tlv, -17625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(adc_vol_tlv, -1762, 3000); static const DECLARE_TLV_DB_SCALE(adc_bst_tlv, 0, 1200, 0);
/* {0, +20, +24, +30, +35, +40, +44, +50, +52} dB */
From: Hans de Goede hdegoede@redhat.com
[ Upstream commit eee51df776bd6cac10a76b2779a9fdee3f622b2b ]
The adc_vol_tlv volume-control has a range from -17.625 dB to +30 dB, not -176.25 dB to + 300 dB. This wrong scale is esp. a problem in userspace apps which translate the dB scale to a linear scale. With the logarithmic dB scale being of by a factor of 10 we loose all precision in the lower area of the range when apps translate things to a linear scale.
E.g. the 0 dB default, which corresponds with a value of 47 of the 0 - 127 range for the control, would be shown as 0/100 in alsa-mixer.
Since the centi-dB values used in the TLV struct cannot represent the 0.375 dB step size used by these controls, change the TLV definition for them to specify a min and max value instead of min + stepsize.
Note this mirrors commit 3f31f7d9b540 ("ASoC: rt5670: Fix dac- and adc- vol-tlv values being off by a factor of 10") which made the exact same change to the rt5670 codec driver.
Signed-off-by: Hans de Goede hdegoede@redhat.com Link: https://lore.kernel.org/r/20210226143817.84287-3-hdegoede@redhat.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/rt5651.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/sound/soc/codecs/rt5651.c b/sound/soc/codecs/rt5651.c index f0c9e2562474..acd5c30694e8 100644 --- a/sound/soc/codecs/rt5651.c +++ b/sound/soc/codecs/rt5651.c @@ -287,9 +287,9 @@ static bool rt5651_readable_register(struct device *dev, unsigned int reg) }
static const DECLARE_TLV_DB_SCALE(out_vol_tlv, -4650, 150, 0); -static const DECLARE_TLV_DB_SCALE(dac_vol_tlv, -65625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(dac_vol_tlv, -6562, 0); static const DECLARE_TLV_DB_SCALE(in_vol_tlv, -3450, 150, 0); -static const DECLARE_TLV_DB_SCALE(adc_vol_tlv, -17625, 375, 0); +static const DECLARE_TLV_DB_MINMAX(adc_vol_tlv, -1762, 3000); static const DECLARE_TLV_DB_SCALE(adc_bst_tlv, 0, 1200, 0);
/* {0, +20, +24, +30, +35, +40, +44, +50, +52} dB */
From: Benjamin Rood benjaminjrood@gmail.com
[ Upstream commit f86f58e3594fb0ab1993d833d3b9a2496f3c928c ]
According to the SGTL5000 datasheet [1], the DAP_AVC_CTRL register has the following bit field definitions:
| BITS | FIELD | RW | RESET | DEFINITION | | 15 | RSVD | RO | 0x0 | Reserved | | 14 | RSVD | RW | 0x1 | Reserved | | 13:12 | MAX_GAIN | RW | 0x1 | Max Gain of AVC in expander mode | | 11:10 | RSVD | RO | 0x0 | Reserved | | 9:8 | LBI_RESP | RW | 0x1 | Integrator Response | | 7:6 | RSVD | RO | 0x0 | Reserved | | 5 | HARD_LMT_EN | RW | 0x0 | Enable hard limiter mode | | 4:1 | RSVD | RO | 0x0 | Reserved | | 0 | EN | RW | 0x0 | Enable/Disable AVC |
The original default value written to the DAP_AVC_CTRL register during sgtl5000_i2c_probe() was 0x0510. This would incorrectly write values to bits 4 and 10, which are defined as RESERVED. It would also not set bits 12 and 14 to their correct RESET values of 0x1, and instead set them to 0x0. While the DAP_AVC module is effectively disabled because the EN bit is 0, this default value is still writing invalid values to registers that are marked as read-only and RESERVED as well as not setting bits 12 and 14 to their correct default values as defined by the datasheet.
The correct value that should be written to the DAP_AVC_CTRL register is 0x5100, which configures the register bits to the default values defined by the datasheet, and prevents any writes to bits defined as 'read-only'. Generally speaking, it is best practice to NOT attempt to write values to registers/bits defined as RESERVED, as it generally produces unwanted/undefined behavior, or errors.
Also, all credit for this patch should go to my colleague Dan MacDonald dmacdonald@curbellmedical.com for finding this error in the first place.
[1] https://www.nxp.com/docs/en/data-sheet/SGTL5000.pdf
Signed-off-by: Benjamin Rood benjaminjrood@gmail.com Reviewed-by: Fabio Estevam festevam@gmail.com Link: https://lore.kernel.org/r/20210219183308.GA2117@ubuntu-dev Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/sgtl5000.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/sound/soc/codecs/sgtl5000.c b/sound/soc/codecs/sgtl5000.c index 0c2a1413a8f5..14e564e38f3c 100644 --- a/sound/soc/codecs/sgtl5000.c +++ b/sound/soc/codecs/sgtl5000.c @@ -75,7 +75,7 @@ static const struct reg_default sgtl5000_reg_defaults[] = { { SGTL5000_DAP_EQ_BASS_BAND4, 0x002f }, { SGTL5000_DAP_MAIN_CHAN, 0x8000 }, { SGTL5000_DAP_MIX_CHAN, 0x0000 }, - { SGTL5000_DAP_AVC_CTRL, 0x0510 }, + { SGTL5000_DAP_AVC_CTRL, 0x5100 }, { SGTL5000_DAP_AVC_THRESHOLD, 0x1473 }, { SGTL5000_DAP_AVC_ATTACK, 0x0028 }, { SGTL5000_DAP_AVC_DECAY, 0x0050 },
From: Christophe Leroy christophe.leroy@csgroup.eu
[ Upstream commit eed5fae00593ab9d261a0c1ffc1bdb786a87a55a ]
The code relies on constant folding of cpu_has_feature() based on possible and always true values as defined per CPU_FTRS_ALWAYS and CPU_FTRS_POSSIBLE.
Build failure is encountered with for instance book3e_all_defconfig on kisskb in the AMDGPU driver which uses cpu_has_feature(CPU_FTR_VSX_COMP) to decide whether calling kernel_enable_vsx() or not.
The failure is due to cpu_has_feature() not being inlined with that configuration with gcc 4.9.
In the same way as commit acdad8fb4a15 ("powerpc: Force inlining of mmu_has_feature to fix build failure"), for inlining of cpu_has_feature().
Signed-off-by: Christophe Leroy christophe.leroy@csgroup.eu Signed-off-by: Michael Ellerman mpe@ellerman.id.au Link: https://lore.kernel.org/r/b231dfa040ce4cc37f702f5c3a595fdeabfe0462.161537820... Signed-off-by: Sasha Levin sashal@kernel.org --- arch/powerpc/include/asm/cpu_has_feature.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cpu_has_feature.h b/arch/powerpc/include/asm/cpu_has_feature.h index 6e834caa3720..7b10b3ef7739 100644 --- a/arch/powerpc/include/asm/cpu_has_feature.h +++ b/arch/powerpc/include/asm/cpu_has_feature.h @@ -6,7 +6,7 @@ #include <linux/bug.h> #include <asm/cputable.h>
-static inline bool early_cpu_has_feature(unsigned long feature) +static __always_inline bool early_cpu_has_feature(unsigned long feature) { return !!((CPU_FTRS_ALWAYS & feature) || (CPU_FTRS_POSSIBLE & cur_cpu_spec->cpu_features & feature)); @@ -45,7 +45,7 @@ static __always_inline bool cpu_has_feature(unsigned long feature) return static_branch_likely(&cpu_feature_keys[i]); } #else -static inline bool cpu_has_feature(unsigned long feature) +static __always_inline bool cpu_has_feature(unsigned long feature) { return early_cpu_has_feature(feature); }
From: Laurent Vivier lvivier@redhat.com
[ Upstream commit beb691e69f4dec7bfe8b81b509848acfd1f0dbf9 ]
vhost_reset_is_le() is vhost_init_is_le(), and in the case of cross-endian legacy, vhost_init_is_le() depends on vq->user_be.
vq->user_be is set by vhost_disable_cross_endian().
But in vhost_vq_reset(), we have:
vhost_reset_is_le(vq); vhost_disable_cross_endian(vq);
And so user_be is used before being set.
To fix that, reverse the lines order as there is no other dependency between them.
Signed-off-by: Laurent Vivier lvivier@redhat.com Link: https://lore.kernel.org/r/20210312140913.788592-1-lvivier@redhat.com Signed-off-by: Michael S. Tsirkin mst@redhat.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/vhost/vhost.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/vhost/vhost.c b/drivers/vhost/vhost.c index b14e62f11075..d2431afeda84 100644 --- a/drivers/vhost/vhost.c +++ b/drivers/vhost/vhost.c @@ -306,8 +306,8 @@ static void vhost_vq_reset(struct vhost_dev *dev, vq->call_ctx = NULL; vq->call = NULL; vq->log_ctx = NULL; - vhost_reset_is_le(vq); vhost_disable_cross_endian(vq); + vhost_reset_is_le(vq); vq->busyloop_timeout = 0; vq->umem = NULL; vq->iotlb = NULL;
From: Lv Yunlong lyl2019@mail.ustc.edu.cn
[ Upstream commit c8c165dea4c8f5ad67b1240861e4f6c5395fa4ac ]
In st_open(), if STp->in_use is true, STp will be freed by scsi_tape_put(). However, STp is still used by DEBC_printk() after. It is better to DEBC_printk() before scsi_tape_put().
Link: https://lore.kernel.org/r/20210311064636.10522-1-lyl2019@mail.ustc.edu.cn Acked-by: Kai Mäkisara kai.makisara@kolumbus.fi Signed-off-by: Lv Yunlong lyl2019@mail.ustc.edu.cn Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/scsi/st.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/st.c b/drivers/scsi/st.c index 618422ea3a41..0d58227431e4 100644 --- a/drivers/scsi/st.c +++ b/drivers/scsi/st.c @@ -1267,8 +1267,8 @@ static int st_open(struct inode *inode, struct file *filp) spin_lock(&st_use_lock); if (STp->in_use) { spin_unlock(&st_use_lock); - scsi_tape_put(STp); DEBC_printk(STp, "Device already in use.\n"); + scsi_tape_put(STp); return (-EBUSY); }
From: Alexey Dobriyan adobriyan@gmail.com
[ Upstream commit 5999b9e5b1f8a2f5417b755130919b3ac96f5550 ]
Only half of the file is under include guard because terminating #endif is placed too early.
Link: https://lore.kernel.org/r/YE4snvoW1SuwcXAn@localhost.localdomain Reviewed-by: Himanshu Madhani himanshu.madhani@oracle.com Signed-off-by: Alexey Dobriyan adobriyan@gmail.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/scsi/qla2xxx/qla_target.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/qla2xxx/qla_target.h b/drivers/scsi/qla2xxx/qla_target.h index 07ea4fcf4f88..983ec09da650 100644 --- a/drivers/scsi/qla2xxx/qla_target.h +++ b/drivers/scsi/qla2xxx/qla_target.h @@ -112,7 +112,6 @@ (min(1270, ((ql) > 0) ? (QLA_TGT_DATASEGS_PER_CMD_24XX + \ QLA_TGT_DATASEGS_PER_CONT_24XX*((ql) - 1)) : 0)) #endif -#endif
#define GET_TARGET_ID(ha, iocb) ((HAS_EXTENDED_IDS(ha)) \ ? le16_to_cpu((iocb)->u.isp2x.target.extended) \ @@ -323,6 +322,7 @@ struct ctio_to_2xxx { #ifndef CTIO_RET_TYPE #define CTIO_RET_TYPE 0x17 /* CTIO return entry */ #define ATIO_TYPE7 0x06 /* Accept target I/O entry for 24xx */ +#endif
struct fcp_hdr { uint8_t r_ctl;
From: Tong Zhang ztong0001@gmail.com
[ Upstream commit 2e5848a3d86f03024ae096478bdb892ab3d79131 ]
request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq()
[ 1.630764] name 'pci-das1602/16' [ 1.630950] WARNING: CPU: 0 PID: 181 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.634009] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.639441] Call Trace: [ 1.639976] proc_mkdir+0x18/0x20 [ 1.641946] request_threaded_irq+0xfe/0x160 [ 1.642186] cb_pcidas_auto_attach+0xf4/0x610 [cb_pcidas]
Suggested-by: Ian Abbott abbotti@mev.co.uk Reviewed-by: Ian Abbott abbotti@mev.co.uk Signed-off-by: Tong Zhang ztong0001@gmail.com Link: https://lore.kernel.org/r/20210315195914.4801-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/staging/comedi/drivers/cb_pcidas.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas.c b/drivers/staging/comedi/drivers/cb_pcidas.c index 3ea15bb0e56e..15b9cc8531f0 100644 --- a/drivers/staging/comedi/drivers/cb_pcidas.c +++ b/drivers/staging/comedi/drivers/cb_pcidas.c @@ -1290,7 +1290,7 @@ static int cb_pcidas_auto_attach(struct comedi_device *dev, devpriv->amcc + AMCC_OP_REG_INTCSR);
ret = request_irq(pcidev->irq, cb_pcidas_interrupt, IRQF_SHARED, - dev->board_name, dev); + "cb_pcidas", dev); if (ret) { dev_dbg(dev->class_dev, "unable to allocate irq %d\n", pcidev->irq);
From: Tong Zhang ztong0001@gmail.com
[ Upstream commit d2d106fe3badfc3bf0dd3899d1c3f210c7203eab ]
request_irq() wont accept a name which contains slash so we need to repalce it with something else -- otherwise it will trigger a warning and the entry in /proc/irq/ will not be created since the .name might be used by userspace and we don't want to break userspace, so we are changing the parameters passed to request_irq()
[ 1.565966] name 'pci-das6402/16' [ 1.566149] WARNING: CPU: 0 PID: 184 at fs/proc/generic.c:180 __xlate_proc_name+0x93/0xb0 [ 1.568923] RIP: 0010:__xlate_proc_name+0x93/0xb0 [ 1.574200] Call Trace: [ 1.574722] proc_mkdir+0x18/0x20 [ 1.576629] request_threaded_irq+0xfe/0x160 [ 1.576859] auto_attach+0x60a/0xc40 [cb_pcidas64]
Suggested-by: Ian Abbott abbotti@mev.co.uk Reviewed-by: Ian Abbott abbotti@mev.co.uk Signed-off-by: Tong Zhang ztong0001@gmail.com Link: https://lore.kernel.org/r/20210315195814.4692-1-ztong0001@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/staging/comedi/drivers/cb_pcidas64.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/comedi/drivers/cb_pcidas64.c b/drivers/staging/comedi/drivers/cb_pcidas64.c index cb9c2699277e..b202df1dcba0 100644 --- a/drivers/staging/comedi/drivers/cb_pcidas64.c +++ b/drivers/staging/comedi/drivers/cb_pcidas64.c @@ -4034,7 +4034,7 @@ static int auto_attach(struct comedi_device *dev, init_stc_registers(dev);
retval = request_irq(pcidev->irq, handle_interrupt, IRQF_SHARED, - dev->board_name, dev); + "cb_pcidas64", dev); if (retval) { dev_dbg(dev->class_dev, "unable to allocate irq %u\n", pcidev->irq);
From: Sameer Pujar spujar@nvidia.com
[ Upstream commit dbf54a9534350d6aebbb34f5c1c606b81a4f35dd ]
Simple-card/audio-graph-card drivers do not handle MCLK clock when it is specified in the codec device node. The expectation here is that, the codec should actually own up the MCLK clock and do necessary setup in the driver.
Suggested-by: Mark Brown broonie@kernel.org Suggested-by: Michael Walle michael@walle.cc Signed-off-by: Sameer Pujar spujar@nvidia.com Link: https://lore.kernel.org/r/1615829492-8972-3-git-send-email-spujar@nvidia.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sasha Levin sashal@kernel.org --- sound/soc/codecs/rt5659.c | 5 +++++ 1 file changed, 5 insertions(+)
diff --git a/sound/soc/codecs/rt5659.c b/sound/soc/codecs/rt5659.c index 635818fcda00..21a007c26407 100644 --- a/sound/soc/codecs/rt5659.c +++ b/sound/soc/codecs/rt5659.c @@ -3389,12 +3389,17 @@ static int rt5659_set_dai_sysclk(struct snd_soc_dai *dai, struct snd_soc_codec *codec = dai->codec; struct rt5659_priv *rt5659 = snd_soc_codec_get_drvdata(codec); unsigned int reg_val = 0; + int ret;
if (freq == rt5659->sysclk && clk_id == rt5659->sysclk_src) return 0;
switch (clk_id) { case RT5659_SCLK_S_MCLK: + ret = clk_set_rate(rt5659->mclk, freq); + if (ret) + return ret; + reg_val |= RT5659_SCLK_SRC_MCLK; break; case RT5659_SCLK_S_PLL1:
From: zhangyi (F) yi.zhang@huawei.com
[ Upstream commit 5dccdc5a1916d4266edd251f20bbbb113a5c495f ]
In ext4_rename(), when RENAME_WHITEOUT failed to add new entry into directory, it ends up dropping new created whiteout inode under the running transaction. After commit <9b88f9fb0d2> ("ext4: Do not iput inode under running transaction"), we follow the assumptions that evict() does not get called from a transaction context but in ext4_rename() it breaks this suggestion. Although it's not a real problem, better to obey it, so this patch add inode to orphan list and stop transaction before final iput().
Signed-off-by: zhangyi (F) yi.zhang@huawei.com Link: https://lore.kernel.org/r/20210303131703.330415-2-yi.zhang@huawei.com Signed-off-by: Theodore Ts'o tytso@mit.edu Signed-off-by: Sasha Levin sashal@kernel.org --- fs/ext4/namei.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/fs/ext4/namei.c b/fs/ext4/namei.c index e6e3eb8dd4d6..bbda3ea7039f 100644 --- a/fs/ext4/namei.c +++ b/fs/ext4/namei.c @@ -3615,7 +3615,7 @@ static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry, */ retval = -ENOENT; if (!old.bh || le32_to_cpu(old.de->inode) != old.inode->i_ino) - goto end_rename; + goto release_bh;
if ((old.dir != new.dir) && ext4_encrypted_inode(new.dir) && @@ -3629,7 +3629,7 @@ static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry, if (IS_ERR(new.bh)) { retval = PTR_ERR(new.bh); new.bh = NULL; - goto end_rename; + goto release_bh; } if (new.bh) { if (!new.inode) { @@ -3646,15 +3646,13 @@ static int ext4_rename(struct inode *old_dir, struct dentry *old_dentry, handle = ext4_journal_start(old.dir, EXT4_HT_DIR, credits); if (IS_ERR(handle)) { retval = PTR_ERR(handle); - handle = NULL; - goto end_rename; + goto release_bh; } } else { whiteout = ext4_whiteout_for_rename(&old, credits, &handle); if (IS_ERR(whiteout)) { retval = PTR_ERR(whiteout); - whiteout = NULL; - goto end_rename; + goto release_bh; } }
@@ -3762,16 +3760,18 @@ end_rename: ext4_resetent(handle, &old, old.inode->i_ino, old_file_type); drop_nlink(whiteout); + ext4_orphan_add(handle, whiteout); } unlock_new_inode(whiteout); + ext4_journal_stop(handle); iput(whiteout); - + } else { + ext4_journal_stop(handle); } +release_bh: brelse(old.dir_bh); brelse(old.bh); brelse(new.bh); - if (handle) - ext4_journal_stop(handle); return retval; }
From: Doug Brown doug@schmorgal.com
[ Upstream commit 39935dccb21c60f9bbf1bb72d22ab6fd14ae7705 ]
If a DDP broadcast packet is sent out to a non-gateway target, it is also looped back. There is a potential for the loopback device to have a longer hardware header length than the original target route's device, which can result in the skb not being created with enough room for the loopback device's hardware header. This patch fixes the issue by determining that a loopback will be necessary prior to allocating the skb, and if so, ensuring the skb has enough room.
This was discovered while testing a new driver that creates a LocalTalk network interface (LTALK_HLEN = 1). It caused an skb_under_panic.
Signed-off-by: Doug Brown doug@schmorgal.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- net/appletalk/ddp.c | 33 +++++++++++++++++++++------------ 1 file changed, 21 insertions(+), 12 deletions(-)
diff --git a/net/appletalk/ddp.c b/net/appletalk/ddp.c index 93209c009df5..a66de21671ac 100644 --- a/net/appletalk/ddp.c +++ b/net/appletalk/ddp.c @@ -1575,8 +1575,8 @@ static int atalk_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) struct sk_buff *skb; struct net_device *dev; struct ddpehdr *ddp; - int size; - struct atalk_route *rt; + int size, hard_header_len; + struct atalk_route *rt, *rt_lo = NULL; int err;
if (flags & ~(MSG_DONTWAIT|MSG_CMSG_COMPAT)) @@ -1639,7 +1639,22 @@ static int atalk_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) SOCK_DEBUG(sk, "SK %p: Size needed %d, device %s\n", sk, size, dev->name);
- size += dev->hard_header_len; + hard_header_len = dev->hard_header_len; + /* Leave room for loopback hardware header if necessary */ + if (usat->sat_addr.s_node == ATADDR_BCAST && + (dev->flags & IFF_LOOPBACK || !(rt->flags & RTF_GATEWAY))) { + struct atalk_addr at_lo; + + at_lo.s_node = 0; + at_lo.s_net = 0; + + rt_lo = atrtr_find(&at_lo); + + if (rt_lo && rt_lo->dev->hard_header_len > hard_header_len) + hard_header_len = rt_lo->dev->hard_header_len; + } + + size += hard_header_len; release_sock(sk); skb = sock_alloc_send_skb(sk, size, (flags & MSG_DONTWAIT), &err); lock_sock(sk); @@ -1647,7 +1662,7 @@ static int atalk_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) goto out;
skb_reserve(skb, ddp_dl->header_length); - skb_reserve(skb, dev->hard_header_len); + skb_reserve(skb, hard_header_len); skb->dev = dev;
SOCK_DEBUG(sk, "SK %p: Begin build.\n", sk); @@ -1698,18 +1713,12 @@ static int atalk_sendmsg(struct socket *sock, struct msghdr *msg, size_t len) /* loop back */ skb_orphan(skb); if (ddp->deh_dnode == ATADDR_BCAST) { - struct atalk_addr at_lo; - - at_lo.s_node = 0; - at_lo.s_net = 0; - - rt = atrtr_find(&at_lo); - if (!rt) { + if (!rt_lo) { kfree_skb(skb); err = -ENETUNREACH; goto out; } - dev = rt->dev; + dev = rt_lo->dev; skb->dev = dev; } ddp_dl->request(ddp_dl, skb, dev->dev_addr);
From: Tong Zhang ztong0001@gmail.com
[ Upstream commit 62e69bc419772638369eff8ff81340bde8aceb61 ]
lmc set sc->lmc_media pointer when there is a matching device. However, when no matching device is found, this pointer is NULL and the following dereference will result in a null-ptr-deref.
To fix this issue, unregister the hdlc device and return an error.
[ 4.569359] BUG: KASAN: null-ptr-deref in lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.569748] Read of size 8 at addr 0000000000000008 by task modprobe/95 [ 4.570102] [ 4.570187] CPU: 0 PID: 95 Comm: modprobe Not tainted 5.11.0-rc7 #94 [ 4.570527] Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.13.0-48-gd9c812dda519-preb4 [ 4.571125] Call Trace: [ 4.571261] dump_stack+0x7d/0xa3 [ 4.571445] kasan_report.cold+0x10c/0x10e [ 4.571667] ? lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.571932] lmc_init_one.cold+0x2b6/0x55d [lmc] [ 4.572186] ? lmc_mii_readreg+0xa0/0xa0 [lmc] [ 4.572432] local_pci_probe+0x6f/0xb0 [ 4.572639] pci_device_probe+0x171/0x240 [ 4.572857] ? pci_device_remove+0xe0/0xe0 [ 4.573080] ? kernfs_create_link+0xb6/0x110 [ 4.573315] ? sysfs_do_create_link_sd.isra.0+0x76/0xe0 [ 4.573598] really_probe+0x161/0x420 [ 4.573799] driver_probe_device+0x6d/0xd0 [ 4.574022] device_driver_attach+0x82/0x90 [ 4.574249] ? device_driver_attach+0x90/0x90 [ 4.574485] __driver_attach+0x60/0x100 [ 4.574694] ? device_driver_attach+0x90/0x90 [ 4.574931] bus_for_each_dev+0xe1/0x140 [ 4.575146] ? subsys_dev_iter_exit+0x10/0x10 [ 4.575387] ? klist_node_init+0x61/0x80 [ 4.575602] bus_add_driver+0x254/0x2a0 [ 4.575812] driver_register+0xd3/0x150 [ 4.576021] ? 0xffffffffc0018000 [ 4.576202] do_one_initcall+0x84/0x250 [ 4.576411] ? trace_event_raw_event_initcall_finish+0x150/0x150 [ 4.576733] ? unpoison_range+0xf/0x30 [ 4.576938] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.577219] ? unpoison_range+0xf/0x30 [ 4.577423] ? unpoison_range+0xf/0x30 [ 4.577628] do_init_module+0xf8/0x350 [ 4.577833] load_module+0x3fe6/0x4340 [ 4.578038] ? vm_unmap_ram+0x1d0/0x1d0 [ 4.578247] ? ____kasan_kmalloc.constprop.0+0x84/0xa0 [ 4.578526] ? module_frob_arch_sections+0x20/0x20 [ 4.578787] ? __do_sys_finit_module+0x108/0x170 [ 4.579037] __do_sys_finit_module+0x108/0x170 [ 4.579278] ? __ia32_sys_init_module+0x40/0x40 [ 4.579523] ? file_open_root+0x200/0x200 [ 4.579742] ? do_sys_open+0x85/0xe0 [ 4.579938] ? filp_open+0x50/0x50 [ 4.580125] ? exit_to_user_mode_prepare+0xfc/0x130 [ 4.580390] do_syscall_64+0x33/0x40 [ 4.580586] entry_SYSCALL_64_after_hwframe+0x44/0xa9 [ 4.580859] RIP: 0033:0x7f1a724c3cf7 [ 4.581054] Code: 48 89 57 30 48 8b 04 24 48 89 47 38 e9 1d a0 02 00 48 89 f8 48 89 f7 48 89 d6 48 891 [ 4.582043] RSP: 002b:00007fff44941c68 EFLAGS: 00000246 ORIG_RAX: 0000000000000139 [ 4.582447] RAX: ffffffffffffffda RBX: 00000000012ada70 RCX: 00007f1a724c3cf7 [ 4.582827] RDX: 0000000000000000 RSI: 00000000012ac9e0 RDI: 0000000000000003 [ 4.583207] RBP: 0000000000000003 R08: 0000000000000000 R09: 0000000000000001 [ 4.583587] R10: 00007f1a72527300 R11: 0000000000000246 R12: 00000000012ac9e0 [ 4.583968] R13: 0000000000000000 R14: 00000000012acc90 R15: 0000000000000001 [ 4.584349] ==================================================================
Signed-off-by: Tong Zhang ztong0001@gmail.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/net/wan/lmc/lmc_main.c | 2 ++ 1 file changed, 2 insertions(+)
diff --git a/drivers/net/wan/lmc/lmc_main.c b/drivers/net/wan/lmc/lmc_main.c index 04b60ed59ea0..4253ccb79975 100644 --- a/drivers/net/wan/lmc/lmc_main.c +++ b/drivers/net/wan/lmc/lmc_main.c @@ -923,6 +923,8 @@ static int lmc_init_one(struct pci_dev *pdev, const struct pci_device_id *ent) break; default: printk(KERN_WARNING "%s: LMC UNKNOWN CARD!\n", dev->name); + unregister_hdlc_device(dev); + return -EIO; break; }
From: Jesper Dangaard Brouer brouer@redhat.com
commit 6306c1189e77a513bf02720450bb43bd4ba5d8ae upstream.
Multiple BPF-helpers that can manipulate/increase the size of the SKB uses __bpf_skb_max_len() as the max-length. This function limit size against the current net_device MTU (skb->dev->mtu).
When a BPF-prog grow the packet size, then it should not be limited to the MTU. The MTU is a transmit limitation, and software receiving this packet should be allowed to increase the size. Further more, current MTU check in __bpf_skb_max_len uses the MTU from ingress/current net_device, which in case of redirects uses the wrong net_device.
This patch keeps a sanity max limit of SKB_MAX_ALLOC (16KiB). The real limit is elsewhere in the system. Jesper's testing[1] showed it was not possible to exceed 8KiB when expanding the SKB size via BPF-helper. The limiting factor is the define KMALLOC_MAX_CACHE_SIZE which is 8192 for SLUB-allocator (CONFIG_SLUB) in-case PAGE_SIZE is 4096. This define is in-effect due to this being called from softirq context see code __gfp_pfmemalloc_flags() and __do_kmalloc_node(). Jakub's testing showed that frames above 16KiB can cause NICs to reset (but not crash). Keep this sanity limit at this level as memory layer can differ based on kernel config.
[1] https://github.com/xdp-project/bpf-examples/tree/master/MTU-tests
Signed-off-by: Jesper Dangaard Brouer brouer@redhat.com Signed-off-by: Daniel Borkmann daniel@iogearbox.net Acked-by: John Fastabend john.fastabend@gmail.com Link: https://lore.kernel.org/bpf/161287788936.790810.2937823995775097177.stgit@fi... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/core/filter.c | 7 ++----- 1 file changed, 2 insertions(+), 5 deletions(-)
--- a/net/core/filter.c +++ b/net/core/filter.c @@ -2120,10 +2120,7 @@ static u32 __bpf_skb_min_len(const struc return min_len; }
-static u32 __bpf_skb_max_len(const struct sk_buff *skb) -{ - return skb->dev->mtu + skb->dev->hard_header_len; -} +#define BPF_SKB_MAX_LEN SKB_MAX_ALLOC
static int bpf_skb_grow_rcsum(struct sk_buff *skb, unsigned int new_len) { @@ -2144,7 +2141,7 @@ static int bpf_skb_trim_rcsum(struct sk_ BPF_CALL_3(bpf_skb_change_tail, struct sk_buff *, skb, u32, new_len, u64, flags) { - u32 max_len = __bpf_skb_max_len(skb); + u32 max_len = BPF_SKB_MAX_LEN; u32 min_len = __bpf_skb_min_len(skb); int ret;
From: Ikjoon Jang ikjn@chromium.org
commit 625bd5a616ceda4840cd28f82e957c8ced394b6a upstream.
Logitech ConferenceCam Connect is a compound USB device with UVC and UAC. Not 100% reproducible but sometimes it keeps responding STALL to every control transfer once it receives get_freq request.
This patch adds 046d:0x084c to a snd_usb_get_sample_rate_quirk list.
Bugzilla: https://bugzilla.kernel.org/show_bug.cgi?id=203419 Signed-off-by: Ikjoon Jang ikjn@chromium.org Cc: stable@vger.kernel.org Link: https://lore.kernel.org/r/20210324105153.2322881-1-ikjn@chromium.org Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- sound/usb/quirks.c | 1 + 1 file changed, 1 insertion(+)
--- a/sound/usb/quirks.c +++ b/sound/usb/quirks.c @@ -1154,6 +1154,7 @@ bool snd_usb_get_sample_rate_quirk(struc case USB_ID(0x21B4, 0x0081): /* AudioQuest DragonFly */ case USB_ID(0x2912, 0x30c8): /* Audioengine D1 */ case USB_ID(0x413c, 0xa506): /* Dell AE515 sound bar */ + case USB_ID(0x046d, 0x084c): /* Logitech ConferenceCam Connect */ return true; } return false;
From: Hui Wang hui.wang@canonical.com
commit e54f30befa7990b897189b44a56c1138c6bfdbb5 upstream.
We found the alc_update_headset_mode() is not called on some machines when unplugging the headset, as a result, the mode of the ALC_HEADSET_MODE_UNPLUGGED can't be set, then the current_headset_type is not cleared, if users plug a differnt type of headset next time, the determine_headset_type() will not be called and the audio jack is set to the headset type of previous time.
On the Dell machines which connect the dmic to the PCH, if we open the gnome-sound-setting and unplug the headset, this issue will happen. Those machines disable the auto-mute by ucm and has no internal mic in the input source, so the update_headset_mode() will not be called by cap_sync_hook or automute_hook when unplugging, and because the gnome-sound-setting is opened, the codec will not enter the runtime_suspend state, so the update_headset_mode() will not be called by alc_resume when unplugging. In this case the hp_automute_hook is called when unplugging, so add update_headset_mode() calling to this function.
Cc: stable@vger.kernel.org Signed-off-by: Hui Wang hui.wang@canonical.com Link: https://lore.kernel.org/r/20210320091542.6748-2-hui.wang@canonical.com Signed-off-by: Takashi Iwai tiwai@suse.de Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- sound/pci/hda/patch_realtek.c | 1 + 1 file changed, 1 insertion(+)
--- a/sound/pci/hda/patch_realtek.c +++ b/sound/pci/hda/patch_realtek.c @@ -4304,6 +4304,7 @@ static void alc_update_headset_jack_cb(s struct alc_spec *spec = codec->spec; spec->current_headset_type = ALC_HEADSET_TYPE_UNKNOWN; snd_hda_gen_hp_automute(codec, jack); + alc_update_headset_mode(codec); }
static void alc_probe_headset_mode(struct hda_codec *codec)
From: Steven Rostedt (VMware) rostedt@goodmis.org
commit 9deb193af69d3fd6dd8e47f292b67c805a787010 upstream.
Commit cbc3b92ce037 fixed an issue to modify the macros of the stack trace event so that user space could parse it properly. Originally the stack trace format to user space showed that the called stack was a dynamic array. But it is not actually a dynamic array, in the way that other dynamic event arrays worked, and this broke user space parsing for it. The update was to make the array look to have 8 entries in it. Helper functions were added to make it parse it correctly, as the stack was dynamic, but was determined by the size of the event stored.
Although this fixed user space on how it read the event, it changed the internal structure used for the stack trace event. It changed the array size from [0] to [8] (added 8 entries). This increased the size of the stack trace event by 8 words. The size reserved on the ring buffer was the size of the stack trace event plus the number of stack entries found in the stack trace. That commit caused the amount to be 8 more than what was needed because it did not expect the caller field to have any size. This produced 8 entries of garbage (and reading random data) from the stack trace event:
<idle>-0 [002] d... 1976396.837549: <stack trace> => trace_event_raw_event_sched_switch => __traceiter_sched_switch => __schedule => schedule_idle => do_idle => cpu_startup_entry => secondary_startup_64_no_verify => 0xc8c5e150ffff93de => 0xffff93de => 0 => 0 => 0xc8c5e17800000000 => 0x1f30affff93de => 0x00000004 => 0x200000000
Instead, subtract the size of the caller field from the size of the event to make sure that only the amount needed to store the stack trace is reserved.
Link: https://lore.kernel.org/lkml/your-ad-here.call-01617191565-ext-9692@work.hou...
Cc: stable@vger.kernel.org Fixes: cbc3b92ce037 ("tracing: Set kernel_stack's caller size properly") Reported-by: Vasily Gorbik gor@linux.ibm.com Tested-by: Vasily Gorbik gor@linux.ibm.com Acked-by: Vasily Gorbik gor@linux.ibm.com Signed-off-by: Steven Rostedt (VMware) rostedt@goodmis.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/trace/trace.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
--- a/kernel/trace/trace.c +++ b/kernel/trace/trace.c @@ -2225,7 +2225,8 @@ static void __ftrace_trace_stack(struct size *= sizeof(unsigned long);
event = trace_buffer_lock_reserve(buffer, TRACE_STACK, - sizeof(*entry) + size, flags, pc); + (sizeof(*entry) - sizeof(entry->caller)) + size, + flags, pc); if (!event) goto out; entry = ring_buffer_event_data(event);
From: Ilya Lipnitskiy ilya.lipnitskiy@gmail.com
commit e720e7d0e983bf05de80b231bccc39f1487f0f16 upstream.
There are code paths that rely on zero_pfn to be fully initialized before core_initcall. For example, wq_sysfs_init() is a core_initcall function that eventually results in a call to kernel_execve, which causes a page fault with a subsequent mmput. If zero_pfn is not initialized by then it may not get cleaned up properly and result in an error:
BUG: Bad rss-counter state mm:(ptrval) type:MM_ANONPAGES val:1
Here is an analysis of the race as seen on a MIPS device. On this particular MT7621 device (Ubiquiti ER-X), zero_pfn is PFN 0 until initialized, at which point it becomes PFN 5120:
1. wq_sysfs_init calls into kobject_uevent_env at core_initcall: kobject_uevent_env+0x7e4/0x7ec kset_register+0x68/0x88 bus_register+0xdc/0x34c subsys_virtual_register+0x34/0x78 wq_sysfs_init+0x1c/0x4c do_one_initcall+0x50/0x1a8 kernel_init_freeable+0x230/0x2c8 kernel_init+0x10/0x100 ret_from_kernel_thread+0x14/0x1c
2. kobject_uevent_env() calls call_usermodehelper_exec() which executes kernel_execve asynchronously.
3. Memory allocations in kernel_execve cause a page fault, bumping the MM reference counter: add_mm_counter_fast+0xb4/0xc0 handle_mm_fault+0x6e4/0xea0 __get_user_pages.part.78+0x190/0x37c __get_user_pages_remote+0x128/0x360 get_arg_page+0x34/0xa0 copy_string_kernel+0x194/0x2a4 kernel_execve+0x11c/0x298 call_usermodehelper_exec_async+0x114/0x194
4. In case zero_pfn has not been initialized yet, zap_pte_range does not decrement the MM_ANONPAGES RSS counter and the BUG message is triggered shortly afterwards when __mmdrop checks the ref counters: __mmdrop+0x98/0x1d0 free_bprm+0x44/0x118 kernel_execve+0x160/0x1d8 call_usermodehelper_exec_async+0x114/0x194 ret_from_kernel_thread+0x14/0x1c
To avoid races such as described above, initialize init_zero_pfn at early_initcall level. Depending on the architecture, ZERO_PAGE is either constant or gets initialized even earlier, at paging_init, so there is no issue with initializing zero_pfn earlier.
Link: https://lkml.kernel.org/r/CALCv0x2YqOXEAy2Q=hafjhHCtTHVodChv1qpM=niAXOpqEbt7... Signed-off-by: Ilya Lipnitskiy ilya.lipnitskiy@gmail.com Cc: Hugh Dickins hughd@google.com Cc: "Eric W. Biederman" ebiederm@xmission.com Cc: stable@vger.kernel.org Tested-by: 周琰杰 (Zhou Yanjie) zhouyanjie@wanyeetech.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- mm/memory.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/mm/memory.c +++ b/mm/memory.c @@ -132,7 +132,7 @@ static int __init init_zero_pfn(void) zero_pfn = page_to_pfn(ZERO_PAGE(0)); return 0; } -core_initcall(init_zero_pfn); +early_initcall(init_zero_pfn);
#if defined(SPLIT_RSS_COUNTING)
From: Tetsuo Handa penguin-kernel@i-love.sakura.ne.jp
commit 5e46d1b78a03d52306f21f77a4e4a144b6d31486 upstream.
syzbot is reporting NULL pointer dereference at reiserfs_security_init() [1], for commit ab17c4f02156c4f7 ("reiserfs: fixup xattr_root caching") is assuming that REISERFS_SB(s)->xattr_root != NULL in reiserfs_xattr_jcreate_nblocks() despite that commit made REISERFS_SB(sb)->priv_root != NULL && REISERFS_SB(s)->xattr_root == NULL case possible.
I guess that commit 6cb4aff0a77cc0e6 ("reiserfs: fix oops while creating privroot with selinux enabled") wanted to check xattr_root != NULL before reiserfs_xattr_jcreate_nblocks(), for the changelog is talking about the xattr root.
The issue is that while creating the privroot during mount reiserfs_security_init calls reiserfs_xattr_jcreate_nblocks which dereferences the xattr root. The xattr root doesn't exist, so we get an oops.
Therefore, update reiserfs_xattrs_initialized() to check both the privroot and the xattr root.
Link: https://syzkaller.appspot.com/bug?id=8abaedbdeb32c861dc5340544284167dd0e46cd... # [1] Reported-and-tested-by: syzbot syzbot+690cb1e51970435f9775@syzkaller.appspotmail.com Signed-off-by: Tetsuo Handa penguin-kernel@I-love.SAKURA.ne.jp Fixes: 6cb4aff0a77c ("reiserfs: fix oops while creating privroot with selinux enabled") Acked-by: Jeff Mahoney jeffm@suse.com Acked-by: Jan Kara jack@suse.com Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- fs/reiserfs/xattr.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/fs/reiserfs/xattr.h +++ b/fs/reiserfs/xattr.h @@ -42,7 +42,7 @@ void reiserfs_security_free(struct reise
static inline int reiserfs_xattrs_initialized(struct super_block *sb) { - return REISERFS_SB(sb)->priv_root != NULL; + return REISERFS_SB(sb)->priv_root && REISERFS_SB(sb)->xattr_root; }
#define xattr_size(size) ((size) + sizeof(struct reiserfs_xattr_header))
From: Wang Panzhenzhuan randy.wang@rock-chips.com
commit c971af25cda94afe71617790826a86253e88eab0 upstream.
The restore in resume should match to suspend which only set for RK3288 SoCs pinctrl.
Fixes: 8dca933127024 ("pinctrl: rockchip: save and restore gpio6_c6 pinmux in suspend/resume") Reviewed-by: Jianqun Xu jay.xu@rock-chips.com Reviewed-by: Heiko Stuebner heiko@sntech.de Signed-off-by: Wang Panzhenzhuan randy.wang@rock-chips.com Signed-off-by: Jianqun Xu jay.xu@rock-chips.com Link: https://lore.kernel.org/r/20210223100725.269240-1-jay.xu@rock-chips.com Signed-off-by: Linus Walleij linus.walleij@linaro.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/pinctrl/pinctrl-rockchip.c | 13 ++++++++----- 1 file changed, 8 insertions(+), 5 deletions(-)
--- a/drivers/pinctrl/pinctrl-rockchip.c +++ b/drivers/pinctrl/pinctrl-rockchip.c @@ -2367,12 +2367,15 @@ static int __maybe_unused rockchip_pinct static int __maybe_unused rockchip_pinctrl_resume(struct device *dev) { struct rockchip_pinctrl *info = dev_get_drvdata(dev); - int ret = regmap_write(info->regmap_base, RK3288_GRF_GPIO6C_IOMUX, - rk3288_grf_gpio6c_iomux | - GPIO6C6_SEL_WRITE_ENABLE); + int ret;
- if (ret) - return ret; + if (info->ctrl->type == RK3288) { + ret = regmap_write(info->regmap_base, RK3288_GRF_GPIO6C_IOMUX, + rk3288_grf_gpio6c_iomux | + GPIO6C6_SEL_WRITE_ENABLE); + if (ret) + return ret; + }
return pinctrl_force_default(info->pctl_dev); }
From: Dinghao Liu dinghao.liu@zju.edu.cn
[ Upstream commit d3bdd1c3140724967ca4136755538fa7c05c2b4e ]
When devm_kcalloc() fails, we should execute device_unregister() to unregister edev->dev from system.
Fixes: 046050f6e623e ("extcon: Update the prototype of extcon_register_notifier() with enum extcon") Signed-off-by: Dinghao Liu dinghao.liu@zju.edu.cn Signed-off-by: Chanwoo Choi cw00.choi@samsung.com Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/extcon/extcon.c | 1 + 1 file changed, 1 insertion(+)
diff --git a/drivers/extcon/extcon.c b/drivers/extcon/extcon.c index d0e367959c91..20e24d4b917a 100644 --- a/drivers/extcon/extcon.c +++ b/drivers/extcon/extcon.c @@ -1200,6 +1200,7 @@ int extcon_dev_register(struct extcon_dev *edev) sizeof(*edev->nh) * edev->max_supported, GFP_KERNEL); if (!edev->nh) { ret = -ENOMEM; + device_unregister(&edev->dev); goto err_dev; }
From: Zheyu Ma zheyuma97@gmail.com
[ Upstream commit 829933ef05a951c8ff140e814656d73e74915faf ]
For each device, the nosy driver allocates a pcilynx structure. A use-after-free might happen in the following scenario:
1. Open nosy device for the first time and call ioctl with command NOSY_IOC_START, then a new client A will be malloced and added to doubly linked list. 2. Open nosy device for the second time and call ioctl with command NOSY_IOC_START, then a new client B will be malloced and added to doubly linked list. 3. Call ioctl with command NOSY_IOC_START for client A, then client A will be readded to the doubly linked list. Now the doubly linked list is messed up. 4. Close the first nosy device and nosy_release will be called. In nosy_release, client A will be unlinked and freed. 5. Close the second nosy device, and client A will be referenced, resulting in UAF.
The root cause of this bug is that the element in the doubly linked list is reentered into the list.
Fix this bug by adding a check before inserting a client. If a client is already in the linked list, don't insert it.
The following KASAN report reveals it:
BUG: KASAN: use-after-free in nosy_release+0x1ea/0x210 Write of size 8 at addr ffff888102ad7360 by task poc CPU: 3 PID: 337 Comm: poc Not tainted 5.12.0-rc5+ #6 Hardware name: QEMU Standard PC (Q35 + ICH9, 2009), BIOS rel-1.12.0-59-gc9ba5276e321-prebuilt.qemu.org 04/01/2014 Call Trace: nosy_release+0x1ea/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae
Allocated by task 337: nosy_open+0x154/0x4d0 misc_open+0x2ec/0x410 chrdev_open+0x20d/0x5a0 do_dentry_open+0x40f/0xe80 path_openat+0x1cf9/0x37b0 do_filp_open+0x16d/0x390 do_sys_openat2+0x11d/0x360 __x64_sys_open+0xfd/0x1a0 do_syscall_64+0x33/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae
Freed by task 337: kfree+0x8f/0x210 nosy_release+0x158/0x210 __fput+0x1e2/0x840 task_work_run+0xe8/0x180 exit_to_user_mode_prepare+0x114/0x120 syscall_exit_to_user_mode+0x1d/0x40 entry_SYSCALL_64_after_hwframe+0x44/0xae
The buggy address belongs to the object at ffff888102ad7300 which belongs to the cache kmalloc-128 of size 128 The buggy address is located 96 bytes inside of 128-byte region [ffff888102ad7300, ffff888102ad7380)
[ Modified to use 'list_empty()' inside proper lock - Linus ]
Link: https://lore.kernel.org/lkml/1617433116-5930-1-git-send-email-zheyuma97@gmai... Reported-and-tested-by: 马哲宇 (Zheyu Ma) zheyuma97@gmail.com Signed-off-by: Zheyu Ma zheyuma97@gmail.com Cc: Greg Kroah-Hartman greg@kroah.com Cc: Stefan Richter stefanr@s5r6.in-berlin.de Signed-off-by: Linus Torvalds torvalds@linux-foundation.org Signed-off-by: Sasha Levin sashal@kernel.org --- drivers/firewire/nosy.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)
diff --git a/drivers/firewire/nosy.c b/drivers/firewire/nosy.c index 180f0a96528c..646dca0a8d73 100644 --- a/drivers/firewire/nosy.c +++ b/drivers/firewire/nosy.c @@ -359,6 +359,7 @@ nosy_ioctl(struct file *file, unsigned int cmd, unsigned long arg) struct client *client = file->private_data; spinlock_t *client_list_lock = &client->lynx->client_list_lock; struct nosy_stats stats; + int ret;
switch (cmd) { case NOSY_IOC_GET_STATS: @@ -373,11 +374,15 @@ nosy_ioctl(struct file *file, unsigned int cmd, unsigned long arg) return 0;
case NOSY_IOC_START: + ret = -EBUSY; spin_lock_irq(client_list_lock); - list_add_tail(&client->link, &client->lynx->client_list); + if (list_empty(&client->link)) { + list_add_tail(&client->link, &client->lynx->client_list); + ret = 0; + } spin_unlock_irq(client_list_lock);
- return 0; + return ret;
case NOSY_IOC_STOP: spin_lock_irq(client_list_lock);
From: Vincent Palatin vpalatin@chromium.org
commit 0bd860493f81eb2a46173f6f5e44cc38331c8dbd upstream.
This LTE modem (M.2 card) has a bug in its power management: there is some kind of race condition for U3 wake-up between the host and the device. The modem firmware sometimes crashes/locks when both events happen at the same time and the modem fully drops off the USB bus (and sometimes re-enumerates, sometimes just gets stuck until the next reboot).
Tested with the modem wired to the XHCI controller on an AMD 3015Ce platform. Without the patch, the modem dropped of the USB bus 5 times in 3 days. With the quirk, it stayed connected for a week while the 'runtime_suspended_time' counter incremented as excepted.
Signed-off-by: Vincent Palatin vpalatin@chromium.org Link: https://lore.kernel.org/r/20210319124802.2315195-1-vpalatin@chromium.org Cc: stable stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/core/quirks.c | 4 ++++ 1 file changed, 4 insertions(+)
--- a/drivers/usb/core/quirks.c +++ b/drivers/usb/core/quirks.c @@ -321,6 +321,10 @@ static const struct usb_device_id usb_qu /* DJI CineSSD */ { USB_DEVICE(0x2ca3, 0x0031), .driver_info = USB_QUIRK_NO_LPM },
+ /* Fibocom L850-GL LTE Modem */ + { USB_DEVICE(0x2cb7, 0x0007), .driver_info = + USB_QUIRK_IGNORE_REMOTE_WAKEUP }, + /* INTEL VALUE SSD */ { USB_DEVICE(0x8086, 0xf1a5), .driver_info = USB_QUIRK_RESET_RESUME },
From: Chunfeng Yun chunfeng.yun@mediatek.com
commit 6f978a30c9bb12dab1302d0f06951ee290f5e600 upstream.
The MediaTek 0.96 xHCI controller on some platforms does not support bulk stream even HCCPARAMS says supporting, due to MaxPSASize is set a default value 1 by mistake, here use XHCI_BROKEN_STREAMS quirk to fix it.
Fixes: 94a631d91ad3 ("usb: xhci-mtk: check hcc_params after adding primary hcd") Cc: stable stable@vger.kernel.org Signed-off-by: Chunfeng Yun chunfeng.yun@mediatek.com Link: https://lore.kernel.org/r/1616482975-17841-4-git-send-email-chunfeng.yun@med... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/host/xhci-mtk.c | 10 +++++++++- 1 file changed, 9 insertions(+), 1 deletion(-)
--- a/drivers/usb/host/xhci-mtk.c +++ b/drivers/usb/host/xhci-mtk.c @@ -470,6 +470,13 @@ static void xhci_mtk_quirks(struct devic xhci->quirks |= XHCI_SPURIOUS_SUCCESS; if (mtk->lpm_support) xhci->quirks |= XHCI_LPM_SUPPORT; + + /* + * MTK xHCI 0.96: PSA is 1 by default even if doesn't support stream, + * and it's 3 when support it. + */ + if (xhci->hci_version < 0x100 && HCC_MAX_PSA(xhci->hcc_params) == 4) + xhci->quirks |= XHCI_BROKEN_STREAMS; }
/* called during probe() after chip reset completes */ @@ -636,7 +643,8 @@ static int xhci_mtk_probe(struct platfor if (ret) goto put_usb3_hcd;
- if (HCC_MAX_PSA(xhci->hcc_params) >= 4) + if (HCC_MAX_PSA(xhci->hcc_params) >= 4 && + !(xhci->quirks & XHCI_BROKEN_STREAMS)) xhci->shared_hcd->can_do_streams = 1;
ret = usb_add_hcd(xhci->shared_hcd, irq, IRQF_SHARED);
From: Oliver Neukum oneukum@suse.com
commit 08dff274edda54310d6f1cf27b62fddf0f8d146e upstream.
Counting break events is nice but we should actually report them to the tty layer.
Fixes: 5a6a62bdb9257 ("cdc-acm: add TIOCMIWAIT") Signed-off-by: Oliver Neukum oneukum@suse.com Link: https://lore.kernel.org/r/20210311133714.31881-1-oneukum@suse.com Cc: stable stable@vger.kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/class/cdc-acm.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
--- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -335,8 +335,10 @@ static void acm_ctrl_irq(struct urb *urb acm->iocount.dsr++; if (difference & ACM_CTRL_DCD) acm->iocount.dcd++; - if (newctrl & ACM_CTRL_BRK) + if (newctrl & ACM_CTRL_BRK) { acm->iocount.brk++; + tty_insert_flip_char(&acm->port, 0, TTY_BREAK); + } if (newctrl & ACM_CTRL_RI) acm->iocount.rng++; if (newctrl & ACM_CTRL_FRAMING)
From: Oliver Neukum oneukum@suse.com
commit e4c77070ad45fc940af1d7fb1e637c349e848951 upstream.
This failure is so common that logging an error here amounts to spamming log files.
Reviewed-by: Bruno Thomsen bruno.thomsen@gmail.com Signed-off-by: Oliver Neukum oneukum@suse.com Cc: stable stable@vger.kernel.org Link: https://lore.kernel.org/r/20210311130126.15972-2-oneukum@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/class/cdc-acm.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)
--- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -543,7 +543,8 @@ static void acm_port_dtr_rts(struct tty_
res = acm_set_control(acm, val); if (res && (acm->ctrl_caps & USB_CDC_CAP_LINE)) - dev_err(&acm->control->dev, "failed to set dtr/rts\n"); + /* This is broken in too many devices to spam the logs */ + dev_dbg(&acm->control->dev, "failed to set dtr/rts\n"); }
static int acm_port_activate(struct tty_port *port, struct tty_struct *tty)
From: Johan Hovold johan@kernel.org
commit 4e49bf376c0451ad2eae2592e093659cde12be9a upstream.
If tty-device registration fails the driver would fail to release the data interface. When the device is later disconnected, the disconnect callback would still be called for the data interface and would go about releasing already freed resources.
Fixes: c93d81955005 ("usb: cdc-acm: fix error handling in acm_probe()") Cc: stable@vger.kernel.org # 3.9 Cc: Alexey Khoroshilov khoroshilov@ispras.ru Acked-by: Oliver Neukum oneukum@suse.com Signed-off-by: Johan Hovold johan@kernel.org Link: https://lore.kernel.org/r/20210322155318.9837-3-johan@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/usb/class/cdc-acm.c | 5 +++++ 1 file changed, 5 insertions(+)
--- a/drivers/usb/class/cdc-acm.c +++ b/drivers/usb/class/cdc-acm.c @@ -1460,6 +1460,11 @@ skip_countries:
return 0; alloc_fail8: + if (!acm->combined_interfaces) { + /* Clear driver data so that disconnect() returns early. */ + usb_set_intfdata(data_interface, NULL); + usb_driver_release_interface(&acm_driver, data_interface); + } if (acm->country_codes) { device_remove_file(&acm->control->dev, &dev_attr_wCountryCodes);
From: Atul Gopinathan atulgopinathan@gmail.com
commit 72ad25fbbb78930f892b191637359ab5b94b3190 upstream.
The variable "info_element" is of the following type:
struct rtllib_info_element *info_element
defined in drivers/staging/rtl8192e/rtllib.h:
struct rtllib_info_element { u8 id; u8 len; u8 data[]; } __packed;
The "len" field defines the size of the "data[]" array. The code is supposed to check if "info_element->len" is greater than 4 and later equal to 6. If this is satisfied then, the last two bytes (the 4th and 5th element of u8 "data[]" array) are copied into "network->CcxRmState".
Right now the code uses "memcpy()" with the source as "&info_element[4]" which would copy in wrong and unintended information. The struct "rtllib_info_element" has a size of 2 bytes for "id" and "len", therefore indexing will be done in interval of 2 bytes. So, "info_element[4]" would point to data which is beyond the memory allocated for this pointer (that is, at x+8, while "info_element" has been allocated only from x to x+7 (2 + 6 => 8 bytes)).
This patch rectifies this error by using "&info_element->data[4]" which correctly copies the last two bytes of "data[]".
NOTE: The faulty line of code came from the following commit:
commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created the file `rtl8192e/ieee80211/ieee80211_rx.c` which had the faulty line of code. This file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib_rx.c` along with additional code in the commit 94a799425eee (tagged in Fixes).
Fixes: 94a799425eee ("From: wlanfae wlanfae@realtek.com [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan atulgopinathan@gmail.com Link: https://lore.kernel.org/r/20210323113413.29179-1-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/staging/rtl8192e/rtllib_rx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtllib_rx.c +++ b/drivers/staging/rtl8192e/rtllib_rx.c @@ -1986,7 +1986,7 @@ static void rtllib_parse_mife_generic(st info_element->data[2] == 0x96 && info_element->data[3] == 0x01) { if (info_element->len == 6) { - memcpy(network->CcxRmState, &info_element[4], 2); + memcpy(network->CcxRmState, &info_element->data[4], 2); if (network->CcxRmState[0] != 0) network->bCcxRmEnable = true; else
From: Atul Gopinathan atulgopinathan@gmail.com
commit e78836ae76d20f38eed8c8c67f21db97529949da upstream.
The "u16 CcxRmState[2];" array field in struct "rtllib_network" has 4 bytes in total while the operations performed on this array through-out the code base are only 2 bytes.
The "CcxRmState" field is fed only 2 bytes of data using memcpy():
(In rtllib_rx.c:1972) memcpy(network->CcxRmState, &info_element->data[4], 2)
With "info_element->data[]" being a u8 array, if 2 bytes are written into "CcxRmState" (whose one element is u16 size), then the 2 u8 elements from "data[]" gets squashed and written into the first element ("CcxRmState[0]") while the second element ("CcxRmState[1]") is never fed with any data.
Same in file rtllib_rx.c:2522: memcpy(dst->CcxRmState, src->CcxRmState, 2);
The above line duplicates "src" data to "dst" but only writes 2 bytes (and not 4, which is the actual size). Again, only 1st element gets the value while the 2nd element remains uninitialized.
This later makes operations done with CcxRmState unpredictable in the following lines as the 1st element is having a squashed number while the 2nd element is having an uninitialized random number.
rtllib_rx.c:1973: if (network->CcxRmState[0] != 0) rtllib_rx.c:1977: network->MBssidMask = network->CcxRmState[1] & 0x07;
network->MBssidMask is also of type u8 and not u16.
Fix this by changing the type of "CcxRmState" from u16 to u8 so that the data written into this array and read from it make sense and are not random values.
NOTE: The wrong initialization of "CcxRmState" can be seen in the following commit:
commit ecdfa44610fa ("Staging: add Realtek 8192 PCI wireless driver")
The above commit created a file `rtl8192e/ieee80211.h` which used to have the faulty line. The file has been deleted (or possibly renamed) with the contents copied in to a new file `rtl8192e/rtllib.h` along with additional code in the commit 94a799425eee (tagged in Fixes).
Fixes: 94a799425eee ("From: wlanfae wlanfae@realtek.com [PATCH 1/8] rtl8192e: Import new version of driver from realtek") Cc: stable@vger.kernel.org Signed-off-by: Atul Gopinathan atulgopinathan@gmail.com Link: https://lore.kernel.org/r/20210323113413.29179-2-atulgopinathan@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/staging/rtl8192e/rtllib.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
--- a/drivers/staging/rtl8192e/rtllib.h +++ b/drivers/staging/rtl8192e/rtllib.h @@ -1160,7 +1160,7 @@ struct rtllib_network { bool bWithAironetIE; bool bCkipSupported; bool bCcxRmEnable; - u16 CcxRmState[2]; + u8 CcxRmState[2]; bool bMBssidValid; u8 MBssidMask; u8 MBssid[ETH_ALEN];
From: Paul Moore paul@paul-moore.com
commit a48b284b403a4a073d8beb72d2bb33e54df67fb6 upstream.
If audit_send_reply() fails when trying to create a new thread to send the reply it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error path and makes a handful of other cleanups that came up while fixing the code.
Reported-by: teroincn@gmail.com Reviewed-by: Richard Guy Briggs rgb@redhat.com Signed-off-by: Paul Moore paul@paul-moore.com Cc: stable@vger.kernel.org # 4.9.x Signed-off-by: Wen Yang wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/audit.c | 46 ++++++++++++++++++++++++++++------------------ 1 file changed, 28 insertions(+), 18 deletions(-)
--- a/kernel/audit.c +++ b/kernel/audit.c @@ -580,6 +580,18 @@ out_kfree_skb: return NULL; }
+static void audit_free_reply(struct audit_reply *reply) +{ + if (!reply) + return; + + if (reply->skb) + kfree_skb(reply->skb); + if (reply->net) + put_net(reply->net); + kfree(reply); +} + static int audit_send_reply_thread(void *arg) { struct audit_reply *reply = (struct audit_reply *)arg; @@ -592,8 +604,8 @@ static int audit_send_reply_thread(void /* Ignore failure. It'll only happen if the sender goes away, because our timeout is set to infinite. */ netlink_unicast(aunet->nlsk , reply->skb, reply->portid, 0); - put_net(net); - kfree(reply); + reply->skb = NULL; + audit_free_reply(reply); return 0; } /** @@ -606,36 +618,34 @@ static int audit_send_reply_thread(void * @payload: payload data * @size: payload size * - * Allocates an skb, builds the netlink message, and sends it to the port id. - * No failure notifications. + * Allocates a skb, builds the netlink message, and sends it to the port id. */ static void audit_send_reply(struct sk_buff *request_skb, int seq, int type, int done, int multi, const void *payload, int size) { u32 portid = NETLINK_CB(request_skb).portid; - struct net *net = sock_net(NETLINK_CB(request_skb).sk); - struct sk_buff *skb; struct task_struct *tsk; - struct audit_reply *reply = kmalloc(sizeof(struct audit_reply), - GFP_KERNEL); + struct audit_reply *reply;
+ reply = kzalloc(sizeof(*reply), GFP_KERNEL); if (!reply) return;
- skb = audit_make_reply(portid, seq, type, done, multi, payload, size); - if (!skb) - goto out; + reply->skb = audit_make_reply(portid, seq, type, done, multi, payload, size); + if (!reply->skb) + goto err;
- reply->net = get_net(net); + reply->net = get_net(sock_net(NETLINK_CB(request_skb).sk)); reply->portid = portid; - reply->skb = skb;
tsk = kthread_run(audit_send_reply_thread, reply, "audit_send_reply"); - if (!IS_ERR(tsk)) - return; - kfree_skb(skb); -out: - kfree(reply); + if (IS_ERR(tsk)) + goto err; + + return; + +err: + audit_free_reply(reply); }
/*
From: Paul Moore paul@paul-moore.com
commit 3054d06719079388a543de6adb812638675ad8f5 upstream.
If audit_list_rules_send() fails when trying to create a new thread to send the rules it also fails to cleanup properly, leaking a reference to a net structure. This patch fixes the error patch and renames audit_send_list() to audit_send_list_thread() to better match its cousin, audit_send_reply_thread().
Reported-by: teroincn@gmail.com Reviewed-by: Richard Guy Briggs rgb@redhat.com Signed-off-by: Paul Moore paul@paul-moore.com Cc: stable@vger.kernel.org # 4.9.x Signed-off-by: Wen Yang wenyang@linux.alibaba.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- kernel/audit.c | 2 +- kernel/audit.h | 2 +- kernel/auditfilter.c | 13 ++++++------- 3 files changed, 8 insertions(+), 9 deletions(-)
--- a/kernel/audit.c +++ b/kernel/audit.c @@ -535,7 +535,7 @@ static int kauditd_thread(void *dummy) return 0; }
-int audit_send_list(void *_dest) +int audit_send_list_thread(void *_dest) { struct audit_netlink_list *dest = _dest; struct sk_buff *skb; --- a/kernel/audit.h +++ b/kernel/audit.h @@ -245,7 +245,7 @@ struct audit_netlink_list { struct sk_buff_head q; };
-int audit_send_list(void *); +int audit_send_list_thread(void *);
struct audit_net { struct sock *nlsk; --- a/kernel/auditfilter.c +++ b/kernel/auditfilter.c @@ -1139,10 +1139,8 @@ int audit_rule_change(int type, __u32 po int audit_list_rules_send(struct sk_buff *request_skb, int seq) { u32 portid = NETLINK_CB(request_skb).portid; - struct net *net = sock_net(NETLINK_CB(request_skb).sk); struct task_struct *tsk; struct audit_netlink_list *dest; - int err = 0;
/* We can't just spew out the rules here because we might fill * the available socket buffer space and deadlock waiting for @@ -1150,10 +1148,10 @@ int audit_list_rules_send(struct sk_buff * happen if we're actually running in the context of auditctl * trying to _send_ the stuff */
- dest = kmalloc(sizeof(struct audit_netlink_list), GFP_KERNEL); + dest = kmalloc(sizeof(*dest), GFP_KERNEL); if (!dest) return -ENOMEM; - dest->net = get_net(net); + dest->net = get_net(sock_net(NETLINK_CB(request_skb).sk)); dest->portid = portid; skb_queue_head_init(&dest->q);
@@ -1161,14 +1159,15 @@ int audit_list_rules_send(struct sk_buff audit_list_rules(portid, seq, &dest->q); mutex_unlock(&audit_filter_mutex);
- tsk = kthread_run(audit_send_list, dest, "audit_send_list"); + tsk = kthread_run(audit_send_list_thread, dest, "audit_send_list"); if (IS_ERR(tsk)) { skb_queue_purge(&dest->q); + put_net(dest->net); kfree(dest); - err = PTR_ERR(tsk); + return PTR_ERR(tsk); }
- return err; + return 0; }
int audit_comparator(u32 left, u32 op, u32 right)
On 4/5/2021 1:53 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
On ARCH_BRCMSTB, using 32-bit and 64-bit kernels:
Tested-by: Florian Fainelli f.fainelli@gmail.com
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 383 pass: 382 fail: 1 Failed tests: parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get an IP address. This is not a new problem but a new test. For some reason it only happens with this specific network interface, this specific SCSI controller, and with v4.9.y. No reason for concern; I'll try to track down what is going on.
Tested-by: Guenter Roeck linux@roeck-us.net
Guenter
On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 383 pass: 382 fail: 1 Failed tests: parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get an IP address. This is not a new problem but a new test. For some reason it only happens with this specific network interface, this specific SCSI controller, and with v4.9.y. No reason for concern; I'll try to track down what is going on.
Interesting. The problem affects all kernels up to and including v4.19.y. Unlike I thought initially, the problem is not associated with the SCSI controller (that was coincidental) but with pcnet Ethernet interfaces. It has been fixed in the upstream kernel with commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*"). This patch does not apply cleanly to any of the affected kernels. I backported part of it to v4.19.y and v4.9.y and confirmed that it fixes the problem in those branches.
Question is what we should do: try to backport 518a2f1925c3 to v4.19.y and earlier, or stop testing against this specific problem.
Any thoughts ?
Thanks, Guenter
On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 383 pass: 382 fail: 1 Failed tests: parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get an IP address. This is not a new problem but a new test. For some reason it only happens with this specific network interface, this specific SCSI controller, and with v4.9.y. No reason for concern; I'll try to track down what is going on.
Interesting. The problem affects all kernels up to and including v4.19.y. Unlike I thought initially, the problem is not associated with the SCSI controller (that was coincidental) but with pcnet Ethernet interfaces. It has been fixed in the upstream kernel with commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*"). This patch does not apply cleanly to any of the affected kernels. I backported part of it to v4.19.y and v4.9.y and confirmed that it fixes the problem in those branches.
Question is what we should do: try to backport 518a2f1925c3 to v4.19.y and earlier, or stop testing against this specific problem.
Another update: The following code change fixes the problem as well. Commit 518a2f1925c3 fixes it only as side effect since it clears all DMA buffers.
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c index c22bf52d3320..7a25ec8390e4 100644 --- a/drivers/net/ethernet/amd/pcnet32.c +++ b/drivers/net/ethernet/amd/pcnet32.c @@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name) return -ENOMEM; }
- lp->rx_ring = pci_alloc_consistent(lp->pci_dev, + lp->rx_ring = pci_zalloc_consistent(lp->pci_dev, sizeof(struct pcnet32_rx_head) * lp->rx_ring_size, &lp->rx_ring_dma_addr);
I'll submit a patch implementing that; we'll see how it goes.
Thanks, Guenter
On Mon, Apr 05, 2021 at 07:22:00PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 383 pass: 382 fail: 1 Failed tests: parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get an IP address. This is not a new problem but a new test. For some reason it only happens with this specific network interface, this specific SCSI controller, and with v4.9.y. No reason for concern; I'll try to track down what is going on.
Interesting. The problem affects all kernels up to and including v4.19.y. Unlike I thought initially, the problem is not associated with the SCSI controller (that was coincidental) but with pcnet Ethernet interfaces. It has been fixed in the upstream kernel with commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*"). This patch does not apply cleanly to any of the affected kernels. I backported part of it to v4.19.y and v4.9.y and confirmed that it fixes the problem in those branches.
Question is what we should do: try to backport 518a2f1925c3 to v4.19.y and earlier, or stop testing against this specific problem.
Another update: The following code change fixes the problem as well. Commit 518a2f1925c3 fixes it only as side effect since it clears all DMA buffers.
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c index c22bf52d3320..7a25ec8390e4 100644 --- a/drivers/net/ethernet/amd/pcnet32.c +++ b/drivers/net/ethernet/amd/pcnet32.c @@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name) return -ENOMEM; }
lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
lp->rx_ring = pci_zalloc_consistent(lp->pci_dev, sizeof(struct pcnet32_rx_head) * lp->rx_ring_size, &lp->rx_ring_dma_addr);
I'll submit a patch implementing that; we'll see how it goes.
Sigh. That doesn't work; upstream uses dma_alloc_coherent(). We could apply the patch making the switch, but dma_alloc_coherent() doesn't clear memory in older kernels (we are back to commit 518a2f1925c3 which is introducing that). I'll just drop pcnet tests for kernels older than v5.4.
Guenter
On Mon, Apr 05, 2021 at 07:36:02PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 07:22:00PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 04:51:55PM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:56:29AM -0700, Guenter Roeck wrote:
On Mon, Apr 05, 2021 at 10:53:35AM +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
Build results: total: 163 pass: 163 fail: 0 Qemu test results: total: 383 pass: 382 fail: 1 Failed tests: parisc:generic-32bit_defconfig:smp:net,pcnet:scsi[53C895A]:rootfs
In the failing test, the network interfcace instantiates but fails to get an IP address. This is not a new problem but a new test. For some reason it only happens with this specific network interface, this specific SCSI controller, and with v4.9.y. No reason for concern; I'll try to track down what is going on.
Interesting. The problem affects all kernels up to and including v4.19.y. Unlike I thought initially, the problem is not associated with the SCSI controller (that was coincidental) but with pcnet Ethernet interfaces. It has been fixed in the upstream kernel with commit 518a2f1925c3 ("dma-mapping: zero memory returned from dma_alloc_*"). This patch does not apply cleanly to any of the affected kernels. I backported part of it to v4.19.y and v4.9.y and confirmed that it fixes the problem in those branches.
Question is what we should do: try to backport 518a2f1925c3 to v4.19.y and earlier, or stop testing against this specific problem.
Another update: The following code change fixes the problem as well. Commit 518a2f1925c3 fixes it only as side effect since it clears all DMA buffers.
diff --git a/drivers/net/ethernet/amd/pcnet32.c b/drivers/net/ethernet/amd/pcnet32.c index c22bf52d3320..7a25ec8390e4 100644 --- a/drivers/net/ethernet/amd/pcnet32.c +++ b/drivers/net/ethernet/amd/pcnet32.c @@ -1967,7 +1967,7 @@ static int pcnet32_alloc_ring(struct net_device *dev, const char *name) return -ENOMEM; }
lp->rx_ring = pci_alloc_consistent(lp->pci_dev,
lp->rx_ring = pci_zalloc_consistent(lp->pci_dev, sizeof(struct pcnet32_rx_head) * lp->rx_ring_size, &lp->rx_ring_dma_addr);
I'll submit a patch implementing that; we'll see how it goes.
Sigh. That doesn't work; upstream uses dma_alloc_coherent(). We could apply the patch making the switch, but dma_alloc_coherent() doesn't clear memory in older kernels (we are back to commit 518a2f1925c3 which is introducing that). I'll just drop pcnet tests for kernels older than v5.4.
If the patch above fixes this in the older kernel versions, I'm all for taking it if needed.
thanks,
greg k-h
On 4/5/21 2:53 AM, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Compiled and booted on my test system. No dmesg regressions.
Tested-by: Shuah Khan skhan@linuxfoundation.org
thanks, -- Shuah
On Mon, 5 Apr 2021 at 14:27, Greg Kroah-Hartman gregkh@linuxfoundation.org wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
Results from Linaro’s test farm. No regressions on arm64, arm, x86_64, and i386.
Tested-by: Linux Kernel Functional Testing lkft@linaro.org
## Build * kernel: 4.9.265-rc1 * git: ['https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git', 'https://gitlab.com/Linaro/lkft/mirrors/stable/linux-stable-rc'] * git branch: linux-4.9.y * git commit: 570fbad9f4ca61dfb49359b9c2627a97e41e2b4b * git describe: v4.9.264-36-g570fbad9f4ca * test details: https://qa-reports.linaro.org/lkft/linux-stable-rc-linux-4.9.y/build/v4.9.26...
## No regressions (compared to v4.9.264-25-gea8146018e96)
## No fixes (compared to v4.9.264-25-gea8146018e96)
## Test result summary total: 58777, pass: 48253, fail: 593, skip: 9676, xfail: 255,
## Build Summary * arm: 96 total, 96 passed, 0 failed * arm64: 23 total, 23 passed, 0 failed * dragonboard-410c: 1 total, 1 passed, 0 failed * hi6220-hikey: 1 total, 1 passed, 0 failed * i386: 13 total, 13 passed, 0 failed * juno-r2: 1 total, 1 passed, 0 failed * mips: 36 total, 36 passed, 0 failed * sparc: 9 total, 9 passed, 0 failed * x15: 1 total, 1 passed, 0 failed * x86: 1 total, 1 passed, 0 failed * x86_64: 13 total, 13 passed, 0 failed
## Test suites summary * fwts * igt-gpu-tools * install-android-platform-tools-r2600 * kselftest-android * kselftest-bpf * kselftest-capabilities * kselftest-cgroup * kselftest-clone3 * kselftest-core * kselftest-cpu-hotplug * kselftest-cpufreq * kselftest-efivarfs * kselftest-filesystems * kselftest-firmware * kselftest-fpu * kselftest-futex * kselftest-gpio * kselftest-intel_pstate * kselftest-ipc * kselftest-ir * kselftest-kcmp * kselftest-kexec * kselftest-kvm * kselftest-lib * kselftest-livepatch * kselftest-lkdtm * kselftest-membarrier * kselftest-ptrace * kselftest-rseq * kselftest-rtc * kselftest-seccomp * kselftest-sigaltstack * kselftest-size * kselftest-splice * kselftest-static_keys * kselftest-sync * kselftest-sysctl * kselftest-timens * kselftest-timers * kselftest-tmpfs * kselftest-tpm2 * kselftest-user * kselftest-vm * kselftest-x86 * kselftest-zram * kvm-unit-tests * libhugetlbfs * linux-log-parser * ltp-cap_bounds-tests * ltp-commands-tests * ltp-containers-tests * ltp-controllers-tests * ltp-cpuhotplug-tests * ltp-crypto-tests * ltp-cve-tests * ltp-dio-tests * ltp-fcntl-locktests-tests * ltp-filecaps-tests * ltp-fs-tests * ltp-fs_bind-tests * ltp-fs_perms_simple-tests * ltp-fsx-tests * ltp-hugetlb-tests * ltp-io-tests * ltp-ipc-tests * ltp-math-tests * ltp-mm-tests * ltp-nptl-tests * ltp-open-posix-tests * ltp-pty-tests * ltp-sched-tests * ltp-securebits-tests * ltp-syscalls-tests * ltp-tracing-tests * network-basic-tests * perf * ssuite * v4l2-compliance
-- Linaro LKFT https://lkft.linaro.org
On Mon, 05 Apr 2021 10:53:35 +0200, Greg Kroah-Hartman wrote:
This is the start of the stable review cycle for the 4.9.265 release. There are 35 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.
Responses should be made by Wed, 07 Apr 2021 08:50:09 +0000. Anything received after that time might be too late.
The whole patch series can be found in one patch at: https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.265-rc1... or in the git tree and branch at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git linux-4.9.y and the diffstat can be found below.
thanks,
greg k-h
All tests passing for Tegra ...
Test results for stable-v4.9: 8 builds: 8 pass, 0 fail 16 boots: 16 pass, 0 fail 32 tests: 32 pass, 0 fail
Linux version: 4.9.265-rc1-g570fbad9f4ca Boards tested: tegra124-jetson-tk1, tegra20-ventana, tegra210-p2371-2180, tegra30-cardhu-a04
Tested-by: Jon Hunter jonathanh@nvidia.com
Jon
linux-stable-mirror@lists.linaro.org