From: Hamish Martin hamish.martin@alliedtelesis.co.nz

commit c4005a8f65edc55fb1700dfc5c1c3dc58be80209 upstream.

The 'distrust_firmware' module parameter dates from 2004 and the USB subsystem is a lot more mature and reliable now than it was then. Alter the default to false now.

Suggested-by: Alan Stern stern@rowland.harvard.edu Acked-by: Alan Stern stern@rowland.harvard.edu Signed-off-by: Hamish Martin hamish.martin@alliedtelesis.co.nz Link: https://lore.kernel.org/r/20200910212512.16670-2-hamish.martin@alliedtelesis... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- drivers/usb/host/ohci-hcd.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/usb/host/ohci-hcd.c +++ b/drivers/usb/host/ohci-hcd.c @@ -102,7 +102,7 @@ static void io_watchdog_func(struct time

/* Some boards misreport power switching/overcurrent */ -static bool distrust_firmware = true; +static bool distrust_firmware; module_param (distrust_firmware, bool, 0); MODULE_PARM_DESC (distrust_firmware, "true to distrust firmware power/overcurrent setup");

From: Roger Pau Monne roger.pau@citrix.com

commit ef3a575baf53571dc405ee4028e26f50856898e7 upstream.

Allow issuing an IOCTL_PRIVCMD_MMAP_RESOURCE ioctl with num = 0 and addr = 0 in order to fetch the size of a specific resource.

Add a shortcut to the default map resource path, since fetching the size requires no address to be passed in, and thus no VMA to setup.

This is missing from the initial implementation, and causes issues when mapping resources that don't have fixed or known sizes.

Signed-off-by: Roger Pau Monné roger.pau@citrix.com Reviewed-by: Juergen Gross jgross@suse.com Tested-by: Andrew Cooper andrew.cooper3@citrix.com Cc: stable@vger.kernel.org # >= 4.18 Link: https://lore.kernel.org/r/20210112115358.23346-1-roger.pau@citrix.com Signed-off-by: Juergen Gross jgross@suse.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/xen/privcmd.c | 25 +++++++++++++++++++------ 1 file changed, 19 insertions(+), 6 deletions(-)

--- a/drivers/xen/privcmd.c +++ b/drivers/xen/privcmd.c @@ -724,14 +724,15 @@ static long privcmd_ioctl_restrict(struc return 0; }

-static long privcmd_ioctl_mmap_resource(struct file *file, void __user *udata) +static long privcmd_ioctl_mmap_resource(struct file *file, + struct privcmd_mmap_resource __user *udata) { struct privcmd_data *data = file->private_data; struct mm_struct *mm = current->mm; struct vm_area_struct *vma; struct privcmd_mmap_resource kdata; xen_pfn_t *pfns = NULL; - struct xen_mem_acquire_resource xdata; + struct xen_mem_acquire_resource xdata = { }; int rc;

if (copy_from_user(&kdata, udata, sizeof(kdata))) @@ -741,6 +742,22 @@ static long privcmd_ioctl_mmap_resource( if (data->domid != DOMID_INVALID && data->domid != kdata.dom) return -EPERM;

+ /* Both fields must be set or unset */ + if (!!kdata.addr != !!kdata.num) + return -EINVAL; + + xdata.domid = kdata.dom; + xdata.type = kdata.type; + xdata.id = kdata.id; + + if (!kdata.addr && !kdata.num) { + /* Query the size of the resource. */ + rc = HYPERVISOR_memory_op(XENMEM_acquire_resource, &xdata); + if (rc) + return rc; + return __put_user(xdata.nr_frames, &udata->num); + } + down_write(&mm->mmap_sem);

vma = find_vma(mm, kdata.addr); @@ -775,10 +792,6 @@ static long privcmd_ioctl_mmap_resource( } else vma->vm_private_data = PRIV_VMA_LOCKED;

- memset(&xdata, 0, sizeof(xdata)); - xdata.domid = kdata.dom; - xdata.type = kdata.type; - xdata.id = kdata.id; xdata.frame = kdata.idx; xdata.nr_frames = kdata.num; set_xen_guest_handle(xdata.frame_list, pfns);

From: zhengbin zhengbin13@huawei.com

commit f7cb0d0945ebc9879aff72cf7b3342fd1040ffaa upstream.

Fix sparse warnings:

drivers/scsi/lpfc/lpfc_nportdisc.c:290:1: warning: symbol 'lpfc_defer_pt2pt_acc' was not declared. Should it be static?

Link: https://lore.kernel.org/r/1570183477-137273-1-git-send-email-zhengbin13@huaw... Reported-by: Hulk Robot hulkci@huawei.com Signed-off-by: zhengbin zhengbin13@huawei.com Reviewed-by: Dick Kennedy dick.kennedy@broadcom.com Reviewed-by: James Smart james.smart@broadcom.com Signed-off-by: Martin K. Petersen martin.petersen@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- drivers/scsi/lpfc/lpfc_nportdisc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/drivers/scsi/lpfc/lpfc_nportdisc.c +++ b/drivers/scsi/lpfc/lpfc_nportdisc.c @@ -286,7 +286,7 @@ lpfc_els_abort(struct lpfc_hba *phba, st * This routine is only called if we are SLI3, direct connect pt2pt * mode and the remote NPort issues the PLOGI after link up. */ -void +static void lpfc_defer_pt2pt_acc(struct lpfc_hba *phba, LPFC_MBOXQ_t *link_mbox) { LPFC_MBOXQ_t *login_mbox;

From: Qinglang Miao miaoqinglang@huawei.com

commit 4c3a14fbc05a09fc369fb68a86cdbf6f441a29f2 upstream

Simplify the return expression.

Signed-off-by: Qinglang Miao miaoqinglang@huawei.com Link: https://lore.kernel.org/r/20200921131106.93228-1-miaoqinglang@huawei.com Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Sudip Mukherjee sudipm.mukherjee@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/spi/spi-npcm-fiu.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/spi/spi-npcm-fiu.c +++ b/drivers/spi/spi-npcm-fiu.c @@ -677,7 +677,6 @@ static int npcm_fiu_probe(struct platfor struct npcm_fiu_spi *fiu; void __iomem *regbase; struct resource *res; - int ret; int id;

ctrl = devm_spi_alloc_master(dev, sizeof(*fiu)); @@ -736,11 +735,7 @@ static int npcm_fiu_probe(struct platfor ctrl->num_chipselect = fiu->info->max_cs; ctrl->dev.of_node = dev->of_node;

- ret = devm_spi_register_master(dev, ctrl); - if (ret) - return ret; - - return 0; + return devm_spi_register_master(dev, ctrl); }

static int npcm_fiu_remove(struct platform_device *pdev)

From: J. Bruce Fields bfields@redhat.com

commit 51b2ee7d006a736a9126e8111d1f24e4fd0afaa6 upstream.

If you export a subdirectory of a filesystem, a READDIRPLUS on the root of that export will return the filehandle of the parent with the ".." entry.

The filehandle is optional, so let's just not return the filehandle for ".." if we're at the root of an export.

Note that once the client learns one filehandle outside of the export, they can trivially access the rest of the export using further lookups.

However, it is also not very difficult to guess filehandles outside of the export. So exporting a subdirectory of a filesystem should considered equivalent to providing access to the entire filesystem. To avoid confusion, we recommend only exporting entire filesystems.

Reported-by: Youjipeng wangzhibei1999@gmail.com Signed-off-by: J. Bruce Fields bfields@redhat.com Cc: stable@vger.kernel.org Signed-off-by: Chuck Lever chuck.lever@oracle.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- fs/nfsd/nfs3xdr.c | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-)

--- a/fs/nfsd/nfs3xdr.c +++ b/fs/nfsd/nfs3xdr.c @@ -857,9 +857,14 @@ compose_entry_fh(struct nfsd3_readdirres if (isdotent(name, namlen)) { if (namlen == 2) { dchild = dget_parent(dparent); - /* filesystem root - cannot return filehandle for ".." */ + /* + * Don't return filehandle for ".." if we're at + * the filesystem or export root: + */ if (dchild == dparent) goto out; + if (dparent == exp->ex_path.dentry) + goto out; } else dchild = dget(dparent); } else

From: Mircea Cirjaliu mcirjaliu@bitdefender.com

commit 301a33d51880619d0c5a581b5a48d3a5248fa84b upstream.

I assume this was obtained by copy/paste. Point it to bpf_map_peek_elem() instead of bpf_map_pop_elem(). In practice it may have been less likely hit when under JIT given shielded via 84430d4232c3 ("bpf, verifier: avoid retpoline for map push/pop/peek operation").

Fixes: f1a2e44a3aec ("bpf: add queue and stack maps") Signed-off-by: Mircea Cirjaliu mcirjaliu@bitdefender.com Signed-off-by: Daniel Borkmann daniel@iogearbox.net Cc: Mauricio Vasquez mauriciovasquezbernal@gmail.com Link: https://lore.kernel.org/bpf/AM7PR02MB6082663DFDCCE8DA7A6DD6B1BBA30@AM7PR02MB... Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- kernel/bpf/helpers.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/kernel/bpf/helpers.c +++ b/kernel/bpf/helpers.c @@ -105,7 +105,7 @@ BPF_CALL_2(bpf_map_peek_elem, struct bpf }

const struct bpf_func_proto bpf_map_peek_elem_proto = { - .func = bpf_map_pop_elem, + .func = bpf_map_peek_elem, .gpl_only = false, .ret_type = RET_INTEGER, .arg1_type = ARG_CONST_MAP_PTR,

From: Manish Chopra manishc@marvell.com

[ Upstream commit a2bc221b972db91e4be1970e776e98f16aa87904 ]

For all PCI functions on the netxen_nic adapter, interrupt mode (INTx or MSI) configuration is dependent on what has been configured by the PCI function zero in the shared interrupt register, as these adapters do not support mixed mode interrupts among the functions of a given adapter.

Logic for setting MSI/MSI-x interrupt mode in the shared interrupt register based on PCI function id zero check is not appropriate for all family of netxen adapters, as for some of the netxen family adapters PCI function zero is not really meant to be probed/loaded in the host but rather just act as a management function on the device, which caused all the other PCI functions on the adapter to always use legacy interrupt (INTx) mode instead of choosing MSI/MSI-x interrupt mode.

This patch replaces that check with port number so that for all type of adapters driver attempts for MSI/MSI-x interrupt modes.

Fixes: b37eb210c076 ("netxen_nic: Avoid mixed mode interrupts") Signed-off-by: Manish Chopra manishc@marvell.com Signed-off-by: Igor Russkikh irusskikh@marvell.com Link: https://lore.kernel.org/r/20210107101520.6735-1-manishc@marvell.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c | 7 +------ 1 file changed, 1 insertion(+), 6 deletions(-)

--- a/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c +++ b/drivers/net/ethernet/qlogic/netxen/netxen_nic_main.c @@ -564,11 +564,6 @@ static const struct net_device_ops netxe .ndo_set_features = netxen_set_features, };

-static inline bool netxen_function_zero(struct pci_dev *pdev) -{ - return (PCI_FUNC(pdev->devfn) == 0) ? true : false; -} - static inline void netxen_set_interrupt_mode(struct netxen_adapter *adapter, u32 mode) { @@ -664,7 +659,7 @@ static int netxen_setup_intr(struct netx netxen_initialize_interrupt_registers(adapter); netxen_set_msix_bit(pdev, 0);

- if (netxen_function_zero(pdev)) { + if (adapter->portnum == 0) { if (!netxen_setup_msi_interrupts(adapter, num_msix)) netxen_set_interrupt_mode(adapter, NETXEN_MSI_MODE); else

From: Jason A. Donenfeld Jason@zx2c4.com

commit 5eee7bd7e245914e4e050c413dfe864e31805207 upstream.

This worked before, because we made all callers name their next pointer "next". But in trying to be more "drop-in" ready, the silliness here is revealed. This commit fixes the problem by making the macro argument and the member use different names.

Signed-off-by: Jason A. Donenfeld Jason@zx2c4.com Signed-off-by: David S. Miller davem@davemloft.net Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- include/linux/skbuff.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-)

--- a/include/linux/skbuff.h +++ b/include/linux/skbuff.h @@ -1481,9 +1481,9 @@ static inline void skb_mark_not_on_list( }

/* Iterate through singly-linked GSO fragments of an skb. */ -#define skb_list_walk_safe(first, skb, next) \ - for ((skb) = (first), (next) = (skb) ? (skb)->next : NULL; (skb); \ - (skb) = (next), (next) = (skb) ? (skb)->next : NULL) +#define skb_list_walk_safe(first, skb, next_skb) \ + for ((skb) = (first), (next_skb) = (skb) ? (skb)->next : NULL; (skb); \ + (skb) = (next_skb), (next_skb) = (skb) ? (skb)->next : NULL)

static inline void skb_list_del_init(struct sk_buff *skb) {

From: Vadim Pasternak vadimp@nvidia.com

[ Upstream commit 57726ebe2733891c9f59105eff028735f73d05fb ]

Validate thresholds to avoid a single failure due to some transceiver unreliability. Ignore the last readouts in case warning temperature is above alarm temperature, since it can cause unexpected thermal shutdown. Stay with the previous values and refresh threshold within the next iteration.

This is a rare scenario, but it was observed at a customer site.

Fixes: 6a79507cfe94 ("mlxsw: core: Extend thermal module with per QSFP module thermal zones") Signed-off-by: Vadim Pasternak vadimp@nvidia.com Reviewed-by: Jiri Pirko jiri@nvidia.com Signed-off-by: Ido Schimmel idosch@nvidia.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/mellanox/mlxsw/core_thermal.c | 11 +++++++---- 1 file changed, 7 insertions(+), 4 deletions(-)

--- a/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c +++ b/drivers/net/ethernet/mellanox/mlxsw/core_thermal.c @@ -177,6 +177,12 @@ mlxsw_thermal_module_trips_update(struct if (err) return err;

+ if (crit_temp > emerg_temp) { + dev_warn(dev, "%s : Critical threshold %d is above emergency threshold %d\n", + tz->tzdev->type, crit_temp, emerg_temp); + return 0; + } + /* According to the system thermal requirements, the thermal zones are * defined with four trip points. The critical and emergency * temperature thresholds, provided by QSFP module are set as "active" @@ -191,11 +197,8 @@ mlxsw_thermal_module_trips_update(struct tz->trips[MLXSW_THERMAL_TEMP_TRIP_NORM].temp = crit_temp; tz->trips[MLXSW_THERMAL_TEMP_TRIP_HIGH].temp = crit_temp; tz->trips[MLXSW_THERMAL_TEMP_TRIP_HOT].temp = emerg_temp; - if (emerg_temp > crit_temp) - tz->trips[MLXSW_THERMAL_TEMP_TRIP_CRIT].temp = emerg_temp + + tz->trips[MLXSW_THERMAL_TEMP_TRIP_CRIT].temp = emerg_temp + MLXSW_THERMAL_MODULE_TEMP_SHIFT; - else - tz->trips[MLXSW_THERMAL_TEMP_TRIP_CRIT].temp = emerg_temp;

return 0; }

From: Stefan Chulski stefanc@marvell.com

[ Upstream commit 6f83802a1a06e74eafbdbc9b52c05516d3083d02 ]

Packet Processor hardware not connected to MAC flow control unit and cannot support TX flow control. This patch disable flow control support.

Fixes: 3f518509dedc ("ethernet: Add new driver for Marvell Armada 375 network unit") Signed-off-by: Stefan Chulski stefanc@marvell.com Acked-by: Marcin Wojtas mw@semihalf.com Link: https://lore.kernel.org/r/1610306582-16641-1-git-send-email-stefanc@marvell.... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c | 2 -- 1 file changed, 2 deletions(-)

--- a/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c +++ b/drivers/net/ethernet/marvell/mvpp2/mvpp2_main.c @@ -4790,8 +4790,6 @@ static void mvpp2_phylink_validate(struc

phylink_set(mask, Autoneg); phylink_set_port_modes(mask); - phylink_set(mask, Pause); - phylink_set(mask, Asym_Pause);

switch (state->interface) { case PHY_INTERFACE_MODE_10GKR:

From: Willem de Bruijn willemb@google.com

[ Upstream commit 9bd6b629c39e3fa9e14243a6d8820492be1a5b2e ]

esp(6)_output_head uses skb_page_frag_refill to allocate a buffer for the esp trailer.

It accesses the page with kmap_atomic to handle highmem. But skb_page_frag_refill can return compound pages, of which kmap_atomic only maps the first underlying page.

skb_page_frag_refill does not return highmem, because flag __GFP_HIGHMEM is not set. ESP uses it in the same manner as TCP. That also does not call kmap_atomic, but directly uses page_address, in skb_copy_to_page_nocache. Do the same for ESP.

This issue has become easier to trigger with recent kmap local debugging feature CONFIG_DEBUG_KMAP_LOCAL_FORCE_MAP.

Fixes: cac2661c53f3 ("esp4: Avoid skb_cow_data whenever possible") Fixes: 03e2a30f6a27 ("esp6: Avoid skb_cow_data whenever possible") Signed-off-by: Willem de Bruijn willemb@google.com Acked-by: Steffen Klassert steffen.klassert@secunet.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/ipv4/esp4.c | 7 +------ net/ipv6/esp6.c | 7 +------ 2 files changed, 2 insertions(+), 12 deletions(-)

--- a/net/ipv4/esp4.c +++ b/net/ipv4/esp4.c @@ -272,7 +272,6 @@ static int esp_output_udp_encap(struct x int esp_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *esp) { u8 *tail; - u8 *vaddr; int nfrags; int esph_offset; struct page *page; @@ -314,14 +313,10 @@ int esp_output_head(struct xfrm_state *x page = pfrag->page; get_page(page);

- vaddr = kmap_atomic(page); - - tail = vaddr + pfrag->offset; + tail = page_address(page) + pfrag->offset;

esp_output_fill_trailer(tail, esp->tfclen, esp->plen, esp->proto);

- kunmap_atomic(vaddr); - nfrags = skb_shinfo(skb)->nr_frags;

__skb_fill_page_desc(skb, nfrags, page, pfrag->offset, --- a/net/ipv6/esp6.c +++ b/net/ipv6/esp6.c @@ -226,7 +226,6 @@ static void esp_output_fill_trailer(u8 * int esp6_output_head(struct xfrm_state *x, struct sk_buff *skb, struct esp_info *esp) { u8 *tail; - u8 *vaddr; int nfrags; struct page *page; struct sk_buff *trailer; @@ -259,14 +258,10 @@ int esp6_output_head(struct xfrm_state * page = pfrag->page; get_page(page);

- vaddr = kmap_atomic(page); - - tail = vaddr + pfrag->offset; + tail = page_address(page) + pfrag->offset;

esp_output_fill_trailer(tail, esp->tfclen, esp->plen, esp->proto);

- kunmap_atomic(vaddr); - nfrags = skb_shinfo(skb)->nr_frags;

__skb_fill_page_desc(skb, nfrags, page, pfrag->offset,

From: Petr Machata petrm@nvidia.com

[ Upstream commit df85bc140a4d6cbaa78d8e9c35154e1a2f0622c7 ]

In commit 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler"), Linux started rejecting RTM_GETDCB netlink messages if they contained a set-like DCB_CMD_ command.

The reason was that privileges were only verified for RTM_SETDCB messages, but the value that determined the action to be taken is the command, not the message type. And validation of message type against the DCB command was the obvious missing piece.

Unfortunately it turns out that mlnx_qos, a somewhat widely deployed tool for configuration of DCB, accesses the DCB set-like APIs through RTM_GETDCB.

Therefore do not bounce the discrepancy between message type and command. Instead, in addition to validating privileges based on the actual message type, validate them also based on the expected message type. This closes the loophole of allowing DCB configuration on non-admin accounts, while maintaining backward compatibility.

Fixes: 2f90b8657ec9 ("ixgbe: this patch adds support for DCB to the kernel and ixgbe driver") Fixes: 826f328e2b7e ("net: dcb: Validate netlink message in DCB handler") Signed-off-by: Petr Machata petrm@nvidia.com Link: https://lore.kernel.org/r/a3edcfda0825f2aa2591801c5232f2bbf2d8a554.161038480... Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/dcb/dcbnl.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/dcb/dcbnl.c +++ b/net/dcb/dcbnl.c @@ -1765,7 +1765,7 @@ static int dcb_doit(struct sk_buff *skb, fn = &reply_funcs[dcb->cmd]; if (!fn->cb) return -EOPNOTSUPP; - if (fn->type != nlh->nlmsg_type) + if (fn->type == RTM_SETDCB && !netlink_capable(skb, CAP_NET_ADMIN)) return -EPERM;

if (!tb[DCB_ATTR_IFNAME])

From: David Wu david.wu@rock-chips.com

[ Upstream commit 5b55299eed78538cc4746e50ee97103a1643249c ]

Since the original mtu is not used when the mtu is updated, the mtu is aligned with cache, this will get an incorrect. For example, if you want to configure the mtu to be 1500, but mtu 1536 is configured in fact.

Fixed: eaf4fac478077 ("net: stmmac: Do not accept invalid MTU values") Signed-off-by: David Wu david.wu@rock-chips.com Link: https://lore.kernel.org/r/20210113034109.27865-1-david.wu@rock-chips.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-)

--- a/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c +++ b/drivers/net/ethernet/stmicro/stmmac/stmmac_main.c @@ -3739,6 +3739,7 @@ static int stmmac_change_mtu(struct net_ { struct stmmac_priv *priv = netdev_priv(dev); int txfifosz = priv->plat->tx_fifo_size; + const int mtu = new_mtu;

if (txfifosz == 0) txfifosz = priv->dma_cap.tx_fifo_size; @@ -3756,7 +3757,7 @@ static int stmmac_change_mtu(struct net_ if ((txfifosz < new_mtu) || (new_mtu > BUF_SIZE_16KiB)) return -EINVAL;

- dev->mtu = new_mtu; + dev->mtu = mtu;

netdev_update_features(dev);

From: Eric Dumazet edumazet@google.com

[ Upstream commit 3226b158e67cfaa677fd180152bfb28989cb2fac ]

Both virtio net and napi_get_frags() allocate skbs with a very small skb->head

While using page fragments instead of a kmalloc backed skb->head might give a small performance improvement in some cases, there is a huge risk of under estimating memory usage.

For both GOOD_COPY_LEN and GRO_MAX_HEAD, we can fit at least 32 allocations per page (order-3 page in x86), or even 64 on PowerPC

We have been tracking OOM issues on GKE hosts hitting tcp_mem limits but consuming far more memory for TCP buffers than instructed in tcp_mem[2]

Even if we force napi_alloc_skb() to only use order-0 pages, the issue would still be there on arches with PAGE_SIZE >= 32768

This patch makes sure that small skb head are kmalloc backed, so that other objects in the slab page can be reused instead of being held as long as skbs are sitting in socket queues.

Note that we might in the future use the sk_buff napi cache, instead of going through a more expensive __alloc_skb()

Another idea would be to use separate page sizes depending on the allocated length (to never have more than 4 frags per page)

I would like to thank Greg Thelen for his precious help on this matter, analysing crash dumps is always a time consuming task.

Fixes: fd11a83dd363 ("net: Pull out core bits of __netdev_alloc_skb and add __napi_alloc_skb") Signed-off-by: Eric Dumazet edumazet@google.com Cc: Paolo Abeni pabeni@redhat.com Cc: Greg Thelen gthelen@google.com Reviewed-by: Alexander Duyck alexanderduyck@fb.com Acked-by: Michael S. Tsirkin mst@redhat.com Link: https://lore.kernel.org/r/20210113161819.1155526-1-eric.dumazet@gmail.com Signed-off-by: Jakub Kicinski kuba@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/core/skbuff.c | 9 +++++++-- 1 file changed, 7 insertions(+), 2 deletions(-)

--- a/net/core/skbuff.c +++ b/net/core/skbuff.c @@ -496,13 +496,17 @@ EXPORT_SYMBOL(__netdev_alloc_skb); struct sk_buff *__napi_alloc_skb(struct napi_struct *napi, unsigned int len, gfp_t gfp_mask) { - struct napi_alloc_cache *nc = this_cpu_ptr(&napi_alloc_cache); + struct napi_alloc_cache *nc; struct sk_buff *skb; void *data;

len += NET_SKB_PAD + NET_IP_ALIGN;

- if ((len > SKB_WITH_OVERHEAD(PAGE_SIZE)) || + /* If requested length is either too small or too big, + * we use kmalloc() for skb->head allocation. + */ + if (len <= SKB_WITH_OVERHEAD(1024) || + len > SKB_WITH_OVERHEAD(PAGE_SIZE) || (gfp_mask & (__GFP_DIRECT_RECLAIM | GFP_DMA))) { skb = __alloc_skb(len, gfp_mask, SKB_ALLOC_RX, NUMA_NO_NODE); if (!skb) @@ -510,6 +514,7 @@ struct sk_buff *__napi_alloc_skb(struct goto skb_success; }

+ nc = this_cpu_ptr(&napi_alloc_cache); len += SKB_DATA_ALIGN(sizeof(struct skb_shared_info)); len = SKB_DATA_ALIGN(len);

From: Daniel Borkmann daniel@iogearbox.net

[ no upstream commit ]

Fix a potential kernel address leakage for the prerequisite where there is a BPF program attached to the cgroup/setsockopt hook. The latter can only be attached under root, however, if the attached program returns 1 to then run the related kernel handler, an unprivileged program could probe for kernel addresses that way. The reason this is possible is that we're under set_fs(KERNEL_DS) when running the kernel setsockopt handler. Aside from old cBPF there is also SCTP's struct sctp_getaddrs_old which contains pointers in the uapi struct that further need copy_from_user() inside the handler. In the normal case this would just return -EFAULT, but under a temporary KERNEL_DS setting the memory would be copied and we'd end up at a different error code, that is, -EINVAL, for both cases given subsequent validations fail, which then allows the app to distinguish and make use of this fact for probing the address space. In case of later kernel versions this issue won't work anymore thanks to Christoph Hellwig's work that got rid of the various temporary set_fs() address space overrides altogether. One potential option for 5.4 as the only affected stable kernel with the least complexity would be to remap those affected -EFAULT copy_from_user() error codes with -EINVAL such that they cannot be probed anymore. Risk of breakage should be rather low for this particular error case.

Fixes: 0d01da6afc54 ("bpf: implement getsockopt and setsockopt hooks") Reported-by: Ryota Shiga (Flatt Security) Signed-off-by: Daniel Borkmann daniel@iogearbox.net Cc: Stanislav Fomichev sdf@google.com Cc: Eric Dumazet edumazet@google.com Cc: Marcelo Ricardo Leitner marcelo.leitner@gmail.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org --- net/core/filter.c | 2 +- net/sctp/socket.c | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-)

--- a/net/core/filter.c +++ b/net/core/filter.c @@ -1475,7 +1475,7 @@ struct bpf_prog *__get_filter(struct soc

if (copy_from_user(prog->insns, fprog->filter, fsize)) { __bpf_prog_free(prog); - return ERR_PTR(-EFAULT); + return ERR_PTR(-EINVAL); }

prog->len = fprog->len; --- a/net/sctp/socket.c +++ b/net/sctp/socket.c @@ -1319,7 +1319,7 @@ static int __sctp_setsockopt_connectx(st

kaddrs = memdup_user(addrs, addrs_size); if (IS_ERR(kaddrs)) - return PTR_ERR(kaddrs); + return PTR_ERR(kaddrs) == -EFAULT ? -EINVAL : PTR_ERR(kaddrs);

/* Allow security module to validate connectx addresses. */ err = security_sctp_bind_connect(sk, SCTP_SOCKOPT_CONNECTX,

From: Felix Fietkau nbd@nbd.name

commit 2463ec86cd0338a2c2edbfb0b9d50c52ff76ff43 upstream.

ieee80211_tx_h_select_key drops any non-mgmt packets without a key when encryption is used. This is wrong for nulldata packets that can't be encrypted and are sent out for probing clients and indicating 4-address mode.

Reported-by: Sebastian Gottschall s.gottschall@dd-wrt.com Fixes: a0761a301746 ("mac80211: drop data frames without key on encrypted links") Signed-off-by: Felix Fietkau nbd@nbd.name Link: https://lore.kernel.org/r/20201218191525.1168-1-nbd@nbd.name Signed-off-by: Johannes Berg johannes.berg@intel.com Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- net/mac80211/tx.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

--- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -657,7 +657,7 @@ ieee80211_tx_h_select_key(struct ieee802 if (!skip_hw && tx->key && tx->key->flags & KEY_FLAG_UPLOADED_TO_HARDWARE) info->control.hw_key = &tx->key->conf; - } else if (!ieee80211_is_mgmt(hdr->frame_control) && tx->sta && + } else if (ieee80211_is_data_present(hdr->frame_control) && tx->sta && test_sta_flag(tx->sta, WLAN_STA_USES_ENCRYPTION)) { return TX_DROP; }

From: Michael Hennerich michael.hennerich@analog.com

commit 4d163ad79b155c71bf30366dc38f8d2502f78844 upstream.

The issue is that using SPI from a callback under the CCF lock will deadlock, since this code uses clk_get_rate().

Fixes: c474b38665463 ("spi: Add driver for Cadence SPI controller") Signed-off-by: Michael Hennerich michael.hennerich@analog.com Signed-off-by: Alexandru Ardelean alexandru.ardelean@analog.com Link: https://lore.kernel.org/r/20210114154217.51996-1-alexandru.ardelean@analog.c... Signed-off-by: Mark Brown broonie@kernel.org Signed-off-by: Greg Kroah-Hartman gregkh@linuxfoundation.org

--- drivers/spi/spi-cadence.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-)

--- a/drivers/spi/spi-cadence.c +++ b/drivers/spi/spi-cadence.c @@ -115,6 +115,7 @@ struct cdns_spi { void __iomem *regs; struct clk *ref_clk; struct clk *pclk; + unsigned int clk_rate; u32 speed_hz; const u8 *txbuf; u8 *rxbuf; @@ -250,7 +251,7 @@ static void cdns_spi_config_clock_freq(s u32 ctrl_reg, baud_rate_val; unsigned long frequency;

- frequency = clk_get_rate(xspi->ref_clk); + frequency = xspi->clk_rate;

ctrl_reg = cdns_spi_read(xspi, CDNS_SPI_CR);

@@ -558,8 +559,9 @@ static int cdns_spi_probe(struct platfor master->auto_runtime_pm = true; master->mode_bits = SPI_CPOL | SPI_CPHA;

+ xspi->clk_rate = clk_get_rate(xspi->ref_clk); /* Set to default valid value */ - master->max_speed_hz = clk_get_rate(xspi->ref_clk) / 4; + master->max_speed_hz = xspi->clk_rate / 4; xspi->speed_hz = master->max_speed_hz;

master->bits_per_word_mask = SPI_BPW_MASK(8);