- Linux-stable-mirror - lists.linaro.org

Patch "mt7601u: check return value of alloc_skb" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mt7601u: check return value of alloc_skb to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mt7601u-check-return-value-of-alloc_skb.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 23 Apr 2017 15:00:23 +0800 Subject: mt7601u: check return value of alloc_skb From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit 5fb01e91daf84ad1e50edfcf63116ecbe31e7ba7 ] Function alloc_skb() will return a NULL pointer if there is no enough memory. However, in function mt7601u_mcu_msg_alloc(), its return value is not validated before it is used. This patch fixes it. Signed-off-by: Pan Bian <bianpan2016(a)163.com> Acked-by: Jakub Kicinski <kubakici(a)wp.pl> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/mediatek/mt7601u/mcu.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) --- a/drivers/net/wireless/mediatek/mt7601u/mcu.c +++ b/drivers/net/wireless/mediatek/mt7601u/mcu.c @@ -66,8 +66,10 @@ mt7601u_mcu_msg_alloc(struct mt7601u_dev WARN_ON(len % 4); /* if length is not divisible by 4 we need to pad */ skb = alloc_skb(len + MT_DMA_HDR_LEN + 4, GFP_KERNEL); - skb_reserve(skb, MT_DMA_HDR_LEN); - memcpy(skb_put(skb, len), data, len); + if (skb) { + skb_reserve(skb, MT_DMA_HDR_LEN); + memcpy(skb_put(skb, len), data, len); + } return skb; } @@ -170,6 +172,8 @@ static int mt7601u_mcu_function_select(s }; skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg)); + if (!skb) + return -ENOMEM; return mt7601u_mcu_msg_send(dev, skb, CMD_FUN_SET_OP, func == 5); } @@ -205,6 +209,8 @@ mt7601u_mcu_calibrate(struct mt7601u_dev }; skb = mt7601u_mcu_msg_alloc(dev, &msg, sizeof(msg)); + if (!skb) + return -ENOMEM; return mt7601u_mcu_msg_send(dev, skb, CMD_CALIBRATION_OP, true); } Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.9/tipc-check-return-value-of-nlmsg_new.patch queue-4.9/mt7601u-check-return-value-of-alloc_skb.patch queue-4.9/rndis_wlan-add-return-value-validation.patch queue-4.9/libertas-check-return-value-of-alloc_workqueue.patch queue-4.9/staging-wilc1000-fix-unchecked-return-value.patch queue-4.9/qlcnic-fix-unchecked-return-value.patch queue-4.9/wan-pc300too-abort-path-on-failure.patch queue-4.9/power-supply-isp1704-fix-unchecked-return-value-of-devm_kzalloc.patch

7 years, 3 months

1
0
0 0

Patch "mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-sdhci-of-esdhc-limit-sd-clock-for-ls1012a-ls1046a.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: yangbo lu <yangbo.lu(a)nxp.com> Date: Thu, 20 Apr 2017 14:58:29 +0800 Subject: mmc: sdhci-of-esdhc: limit SD clock for ls1012a/ls1046a From: yangbo lu <yangbo.lu(a)nxp.com> [ Upstream commit a627f025eb0534052ff451427c16750b3530634c ] The ls1046a datasheet specified that the max SD clock frequency for eSDHC SDR104/HS200 was 167MHz, and the ls1012a datasheet specified it's 125MHz for ls1012a. So this patch is to add the limitation. Signed-off-by: Yangbo Lu <yangbo.lu(a)nxp.com> Acked-by: Adrian Hunter <adrian.hunter(a)intel.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/sdhci-of-esdhc.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/mmc/host/sdhci-of-esdhc.c +++ b/drivers/mmc/host/sdhci-of-esdhc.c @@ -432,6 +432,20 @@ static void esdhc_of_set_clock(struct sd if (esdhc->vendor_ver < VENDOR_V_23) pre_div = 2; + /* + * Limit SD clock to 167MHz for ls1046a according to its datasheet + */ + if (clock > 167000000 && + of_find_compatible_node(NULL, NULL, "fsl,ls1046a-esdhc")) + clock = 167000000; + + /* + * Limit SD clock to 125MHz for ls1012a according to its datasheet + */ + if (clock > 125000000 && + of_find_compatible_node(NULL, NULL, "fsl,ls1012a-esdhc")) + clock = 125000000; + /* Workaround to reduce the clock frequency for p1010 esdhc */ if (of_find_compatible_node(NULL, NULL, "fsl,p1010-esdhc")) { if (clock > 20000000) Patches currently in stable-queue which might be from yangbo.lu(a)nxp.com are queue-4.9/mmc-sdhci-of-esdhc-limit-sd-clock-for-ls1012a-ls1046a.patch

7 years, 3 months

1
0
0 0

Patch "mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR()" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR() to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Dan Carpenter <dan.carpenter(a)oracle.com> Date: Mon, 10 Apr 2017 16:54:17 +0300 Subject: mmc: host: omap_hsmmc: checking for NULL instead of IS_ERR() From: Dan Carpenter <dan.carpenter(a)oracle.com> [ Upstream commit ec5ab8933772c87f24ad62a4a602fe8949f423c2 ] devm_pinctrl_get() returns error pointers, it never returns NULL. Fixes: 455e5cd6f736 ("mmc: omap_hsmmc: Pin remux workaround to support SDIO interrupt on AM335x") Signed-off-by: Dan Carpenter <dan.carpenter(a)oracle.com> Reviewed-by: Kishon Vijay Abraham I <kishon(a)ti.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/host/omap_hsmmc.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) --- a/drivers/mmc/host/omap_hsmmc.c +++ b/drivers/mmc/host/omap_hsmmc.c @@ -1762,8 +1762,8 @@ static int omap_hsmmc_configure_wake_irq */ if (host->pdata->controller_flags & OMAP_HSMMC_SWAKEUP_MISSING) { struct pinctrl *p = devm_pinctrl_get(host->dev); - if (!p) { - ret = -ENODEV; + if (IS_ERR(p)) { + ret = PTR_ERR(p); goto err_free_irq; } if (IS_ERR(pinctrl_lookup_state(p, PINCTRL_STATE_DEFAULT))) { Patches currently in stable-queue which might be from dan.carpenter(a)oracle.com are queue-4.9/netfilter-x_tables-unlock-on-error-in-xt_find_table_lock.patch queue-4.9/asoc-intel-skylake-uninitialized-variable-in-probe_codec.patch queue-4.9/mmc-host-omap_hsmmc-checking-for-null-instead-of-is_err.patch queue-4.9/qed-unlock-on-error-in-qed_vf_pf_acquire.patch queue-4.9/hsi-ssi_protocol-double-free-in-ssip_pn_xmit.patch queue-4.9/cifs-small-underflow-in-cnvrtdosunixtm.patch queue-4.9/ib-rdmavt-restore-irqs-on-error-path-in-rvt_create_ah.patch

7 years, 3 months

1
0
0 0

Patch "mmc: avoid removing non-removable hosts during suspend" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mmc: avoid removing non-removable hosts during suspend to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mmc-avoid-removing-non-removable-hosts-during-suspend.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Daniel Drake <drake(a)endlessm.com> Date: Tue, 12 Dec 2017 10:49:02 +0000 Subject: mmc: avoid removing non-removable hosts during suspend From: Daniel Drake <drake(a)endlessm.com> [ Upstream commit de8dcc3d2c0e08e5068ee1e26fc46415c15e3637 ] The Weibu F3C MiniPC has an onboard AP6255 module, presenting two SDIO functions on a single MMC host (Bluetooth/btsdio and WiFi/brcmfmac), and the mmc layer correctly detects this as non-removable. After suspend/resume, the wifi and bluetooth interfaces disappear and do not get probed again. The conditions here are: 1. During suspend, we reach mmc_pm_notify() 2. mmc_pm_notify() calls mmc_sdio_pre_suspend() to see if we can suspend the SDIO host. However, mmc_sdio_pre_suspend() returns -ENOSYS because btsdio_driver does not have a suspend method. 3. mmc_pm_notify() proceeds to remove the card 4. Upon resume, mmc_rescan() does nothing with this host, because of the rescan_entered check which aims to only scan a non-removable device a single time (i.e. during boot). Fix the loss of functionality by detecting that we are unable to suspend a non-removable host, so avoid the forced removal in that case. The comment above this function already indicates that this code was only intended for removable devices. Signed-off-by: Daniel Drake <drake(a)endlessm.com> Signed-off-by: Ulf Hansson <ulf.hansson(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mmc/core/core.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/drivers/mmc/core/core.c +++ b/drivers/mmc/core/core.c @@ -2974,6 +2974,14 @@ static int mmc_pm_notify(struct notifier if (!err) break; + if (!mmc_card_is_removable(host)) { + dev_warn(mmc_dev(host), + "pre_suspend failed for non-removable host: " + "%d\n", err); + /* Avoid removing non-removable hosts */ + break; + } + /* Calling bus_ops->remove() with a claimed host can deadlock */ host->bus_ops->remove(host); mmc_claim_host(host); Patches currently in stable-queue which might be from drake(a)endlessm.com are queue-4.9/mmc-avoid-removing-non-removable-hosts-during-suspend.patch

7 years, 3 months

1
0
0 0

Patch "mm, vmstat: suppress pcp stats for unpopulated zones in zoneinfo" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm, vmstat: suppress pcp stats for unpopulated zones in zoneinfo to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-vmstat-suppress-pcp-stats-for-unpopulated-zones-in-zoneinfo.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: David Rientjes <rientjes(a)google.com> Date: Wed, 3 May 2017 14:53:02 -0700 Subject: mm, vmstat: suppress pcp stats for unpopulated zones in zoneinfo From: David Rientjes <rientjes(a)google.com> [ Upstream commit 7dfb8bf3b9caef4049bee51d2c22e1c3a311d483 ] After "mm, vmstat: print non-populated zones in zoneinfo", /proc/zoneinfo will show unpopulated zones. The per-cpu pageset statistics are not relevant for unpopulated zones and can be potentially lengthy, so supress them when they are not interesting. Also moves lowmem reserve protection information above pcp stats since it is relevant for all zones per vm.lowmem_reserve_ratio. Link: http://lkml.kernel.org/r/alpine.DEB.2.10.1703061400500.46428@chino.kir.corp… Signed-off-by: David Rientjes <rientjes(a)google.com> Cc: Anshuman Khandual <khandual(a)linux.vnet.ibm.com> Cc: Vlastimil Babka <vbabka(a)suse.cz> Cc: Mel Gorman <mgorman(a)techsingularity.net> Cc: Johannes Weiner <hannes(a)cmpxchg.org> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/vmstat.c | 20 +++++++++++++------- 1 file changed, 13 insertions(+), 7 deletions(-) --- a/mm/vmstat.c +++ b/mm/vmstat.c @@ -1387,18 +1387,24 @@ static void zoneinfo_show_print(struct s zone->present_pages, zone->managed_pages); - for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++) - seq_printf(m, "\n %-12s %lu", vmstat_text[i], - zone_page_state(zone, i)); - seq_printf(m, "\n protection: (%ld", zone->lowmem_reserve[0]); for (i = 1; i < ARRAY_SIZE(zone->lowmem_reserve); i++) seq_printf(m, ", %ld", zone->lowmem_reserve[i]); - seq_printf(m, - ")" - "\n pagesets"); + seq_putc(m, ')'); + + /* If unpopulated, no other information is useful */ + if (!populated_zone(zone)) { + seq_putc(m, '\n'); + return; + } + + for (i = 0; i < NR_VM_ZONE_STAT_ITEMS; i++) + seq_printf(m, "\n %-12s %lu", vmstat_text[i], + zone_page_state(zone, i)); + + seq_printf(m, "\n pagesets"); for_each_online_cpu(i) { struct per_cpu_pageset *pageset; Patches currently in stable-queue which might be from rientjes(a)google.com are queue-4.9/mm-vmstat-suppress-pcp-stats-for-unpopulated-zones-in-zoneinfo.patch

7 years, 3 months

1
0
0 0

Patch "mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-hwpoison-call-shake_page-after-try_to_unmap-for-mlocked-page.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Date: Wed, 3 May 2017 14:56:22 -0700 Subject: mm: hwpoison: call shake_page() after try_to_unmap() for mlocked page From: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> [ Upstream commit 286c469a988fbaf68e3a97ddf1e6c245c1446968 ] Memory error handler calls try_to_unmap() for error pages in various states. If the error page is a mlocked page, error handling could fail with "still referenced by 1 users" message. This is because the page is linked to and stays in lru cache after the following call chain. try_to_unmap_one page_remove_rmap clear_page_mlock putback_lru_page lru_cache_add memory_failure() calls shake_page() to hanlde the similar issue, but current code doesn't cover because shake_page() is called only before try_to_unmap(). So this patches adds shake_page(). Fixes: 23a003bfd23ea9ea0b7756b920e51f64b284b468 ("mm/madvise: pass return code of memory_failure() to userspace") Link: http://lkml.kernel.org/r/20170417055948.GM31394@yexl-desktop Link: http://lkml.kernel.org/r/1493197841-23986-3-git-send-email-n-horiguchi@ah.j… Signed-off-by: Naoya Horiguchi <n-horiguchi(a)ah.jp.nec.com> Reported-by: kernel test robot <lkp(a)intel.com> Cc: Xiaolong Ye <xiaolong.ye(a)intel.com> Cc: Chen Gong <gong.chen(a)linux.intel.com> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/memory-failure.c | 8 ++++++++ 1 file changed, 8 insertions(+) --- a/mm/memory-failure.c +++ b/mm/memory-failure.c @@ -921,6 +921,7 @@ static int hwpoison_user_mappings(struct int ret; int kill = 1, forcekill; struct page *hpage = *hpagep; + bool mlocked = PageMlocked(hpage); /* * Here we are interested only in user-mapped pages, so skip any @@ -985,6 +986,13 @@ static int hwpoison_user_mappings(struct pfn, page_mapcount(hpage)); /* + * try_to_unmap() might put mlocked page in lru cache, so call + * shake_page() again to ensure that it's flushed. + */ + if (mlocked) + shake_page(hpage, 0); + + /* * Now that the dirty bit has been propagated to the * struct page and all unmaps done we can decide if * killing is needed or not. Only kill when the page Patches currently in stable-queue which might be from n-horiguchi(a)ah.jp.nec.com are queue-4.9/mm-hwpoison-call-shake_page-after-try_to_unmap-for-mlocked-page.patch

7 years, 3 months

1
0
0 0

Patch "mm: fix check for reclaimable pages in PF_MEMALLOC reclaim throttling" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mm: fix check for reclaimable pages in PF_MEMALLOC reclaim throttling to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mm-fix-check-for-reclaimable-pages-in-pf_memalloc-reclaim-throttling.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Johannes Weiner <hannes(a)cmpxchg.org> Date: Wed, 3 May 2017 14:51:54 -0700 Subject: mm: fix check for reclaimable pages in PF_MEMALLOC reclaim throttling From: Johannes Weiner <hannes(a)cmpxchg.org> [ Upstream commit d450abd81b081d45adb12f303a07dd44b15eb1bc ] PF_MEMALLOC direct reclaimers get throttled on a node when the sum of all free pages in each zone fall below half the min watermark. During the summation, we want to exclude zones that don't have reclaimables. Checking the same pgdat over and over again doesn't make sense. Fixes: 599d0c954f91 ("mm, vmscan: move LRU lists to node") Link: http://lkml.kernel.org/r/20170228214007.5621-3-hannes@cmpxchg.org Signed-off-by: Johannes Weiner <hannes(a)cmpxchg.org> Acked-by: Hillf Danton <hillf.zj(a)alibaba-inc.com> Acked-by: Michal Hocko <mhocko(a)suse.com> Cc: Jia He <hejianet(a)gmail.com> Cc: Mel Gorman <mgorman(a)suse.de> Signed-off-by: Andrew Morton <akpm(a)linux-foundation.org> Signed-off-by: Linus Torvalds <torvalds(a)linux-foundation.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- mm/vmscan.c | 6 ++++-- 1 file changed, 4 insertions(+), 2 deletions(-) --- a/mm/vmscan.c +++ b/mm/vmscan.c @@ -2841,8 +2841,10 @@ static bool allow_direct_reclaim(pg_data for (i = 0; i <= ZONE_NORMAL; i++) { zone = &pgdat->node_zones[i]; - if (!managed_zone(zone) || - pgdat_reclaimable_pages(pgdat) == 0) + if (!managed_zone(zone)) + continue; + + if (!zone_reclaimable_pages(zone)) continue; pfmemalloc_reserve += min_wmark_pages(zone); Patches currently in stable-queue which might be from hannes(a)cmpxchg.org are queue-4.9/mm-fix-check-for-reclaimable-pages-in-pf_memalloc-reclaim-throttling.patch queue-4.9/mm-vmstat-suppress-pcp-stats-for-unpopulated-zones-in-zoneinfo.patch

7 years, 3 months

1
0
0 0

Patch "mfd: palmas: Reset the POWERHOLD mux during power off" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mfd: palmas: Reset the POWERHOLD mux during power off to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mfd-palmas-reset-the-powerhold-mux-during-power-off.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Keerthy <j-keerthy(a)ti.com> Date: Thu, 10 Nov 2016 10:39:18 +0530 Subject: mfd: palmas: Reset the POWERHOLD mux during power off From: Keerthy <j-keerthy(a)ti.com> [ Upstream commit 85fdaf8eb9bbec1f0f8a52fd5d85659d60738816 ] POWERHOLD signal has higher priority over the DEV_ON bit. So power off will not happen if the POWERHOLD is held high. Hence reset the MUX to GPIO_7 mode to release the POWERHOLD and the DEV_ON bit to take effect to power off the PMIC. PMIC Power off happens in dire situations like thermal shutdown so irrespective of the POWERHOLD setting go ahead and turn off the powerhold. Currently poweroff is broken on boards that have powerhold enabled. This fixes poweroff on those boards. Signed-off-by: Keerthy <j-keerthy(a)ti.com> Signed-off-by: Lee Jones <lee.jones(a)linaro.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/mfd/palmas.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+) --- a/drivers/mfd/palmas.c +++ b/drivers/mfd/palmas.c @@ -430,6 +430,20 @@ static void palmas_power_off(void) { unsigned int addr; int ret, slave; + struct device_node *np = palmas_dev->dev->of_node; + + if (of_property_read_bool(np, "ti,palmas-override-powerhold")) { + addr = PALMAS_BASE_TO_REG(PALMAS_PU_PD_OD_BASE, + PALMAS_PRIMARY_SECONDARY_PAD2); + slave = PALMAS_BASE_TO_SLAVE(PALMAS_PU_PD_OD_BASE); + + ret = regmap_update_bits(palmas_dev->regmap[slave], addr, + PALMAS_PRIMARY_SECONDARY_PAD2_GPIO_7_MASK, 0); + if (ret) + dev_err(palmas_dev->dev, + "Unable to write PRIMARY_SECONDARY_PAD2 %d\n", + ret); + } if (!palmas_dev) return; Patches currently in stable-queue which might be from j-keerthy(a)ti.com are queue-4.9/mfd-palmas-reset-the-powerhold-mux-during-power-off.patch

7 years, 3 months

1
0
0 0

Patch "media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-media-dvb-frontends-add-delay-to-si2168-restart.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Ron Economos <w6rz(a)comcast.net> Date: Mon, 11 Dec 2017 19:51:53 -0500 Subject: media: [RESEND] media: dvb-frontends: Add delay to Si2168 restart From: Ron Economos <w6rz(a)comcast.net> [ Upstream commit 380a6c86457573aa42d27ae11e025eb25941a0b7 ] On faster CPUs a delay is required after the resume command and the restart command. Without the delay, the restart command often returns -EREMOTEIO and the Si2168 does not restart. Note that this patch fixes the same issue as https://patchwork.linuxtv.org/patch/44304/, but I believe my udelay() fix addresses the actual problem. Signed-off-by: Ron Economos <w6rz(a)comcast.net> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-frontends/si2168.c | 3 +++ 1 file changed, 3 insertions(+) --- a/drivers/media/dvb-frontends/si2168.c +++ b/drivers/media/dvb-frontends/si2168.c @@ -14,6 +14,8 @@ * GNU General Public License for more details. */ +#include <linux/delay.h> + #include "si2168_priv.h" static const struct dvb_frontend_ops si2168_ops; @@ -378,6 +380,7 @@ static int si2168_init(struct dvb_fronte if (ret) goto err; + udelay(100); memcpy(cmd.args, "\x85", 1); cmd.wlen = 1; cmd.rlen = 1; Patches currently in stable-queue which might be from w6rz(a)comcast.net are queue-4.9/media-media-dvb-frontends-add-delay-to-si2168-restart.patch

7 years, 3 months

1
0
0 0

Patch "[media] media/dvb-core: Race condition when writing to CAM" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled [media] media/dvb-core: Race condition when writing to CAM to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-dvb-core-race-condition-when-writing-to-cam.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Jasmin J <jasmin(a)anw.at> Date: Fri, 17 Mar 2017 23:04:20 -0300 Subject: [media] media/dvb-core: Race condition when writing to CAM From: Jasmin J <jasmin(a)anw.at> [ Upstream commit e7080d4471d805d921a9ea21b32f911a91e248cb ] It started with a sporadic message in syslog: "CAM tried to send a buffer larger than the ecount size" This message is not the fault itself, but a consecutive fault, after a read error from the CAM. This happens only on several CAMs, several hardware, and of course sporadic. It is a consecutive fault, if the last read from the CAM did fail. I guess this will not happen on all CAMs, but at least it did on mine. There was a write error to the CAM and during the re-initialization procedure, the CAM finished the last read, although it got a RS. The write error to the CAM happened because a race condition between HC write, checking DA and FR. This patch added an additional check for DA(RE), just after checking FR. It is important to read the CAMs status register again, to give the CAM the necessary time for a proper reaction to HC. Please note the description within the source code (patch below). [mchehab(a)s-opensource.com: make checkpatch happy] Signed-off-by: Jasmin jessich <jasmin(a)anw.at> Tested-by: Ralph Metzler <rjkm(a)metzlerbros.de> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/dvb-core/dvb_ca_en50221.c | 23 +++++++++++++++++++++++ 1 file changed, 23 insertions(+) --- a/drivers/media/dvb-core/dvb_ca_en50221.c +++ b/drivers/media/dvb-core/dvb_ca_en50221.c @@ -779,6 +779,29 @@ static int dvb_ca_en50221_write_data(str goto exit; } + /* + * It may need some time for the CAM to settle down, or there might + * be a race condition between the CAM, writing HC and our last + * check for DA. This happens, if the CAM asserts DA, just after + * checking DA before we are setting HC. In this case it might be + * a bug in the CAM to keep the FR bit, the lower layer/HW + * communication requires a longer timeout or the CAM needs more + * time internally. But this happens in reality! + * We need to read the status from the HW again and do the same + * we did for the previous check for DA + */ + status = ca->pub->read_cam_control(ca->pub, slot, CTRLIF_STATUS); + if (status < 0) + goto exit; + + if (status & (STATUSREG_DA | STATUSREG_RE)) { + if (status & STATUSREG_DA) + dvb_ca_en50221_thread_wakeup(ca); + + status = -EAGAIN; + goto exit; + } + /* send the amount of data */ if ((status = ca->pub->write_cam_control(ca->pub, slot, CTRLIF_SIZE_HIGH, bytes_write >> 8)) != 0) goto exit; Patches currently in stable-queue which might be from jasmin(a)anw.at are queue-4.9/media-dvb-core-race-condition-when-writing-to-cam.patch

7 years, 3 months

1
0
0 0

Patch "media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> Date: Mon, 20 Nov 2017 09:00:55 -0500 Subject: media: c8sectpfe: fix potential NULL pointer dereference in c8sectpfe_timer_interrupt From: "Gustavo A. R. Silva" <garsilva(a)embeddedor.com> [ Upstream commit baed3c4bc4c13de93e0dba0a26d601411ebcb389 ] _channel_ is being dereferenced before it is null checked, hence there is a potential null pointer dereference. Fix this by moving the pointer dereference after _channel_ has been null checked. This issue was detected with the help of Coccinelle. Fixes: c5f5d0f99794 ("[media] c8sectpfe: STiH407/10 Linux DVB demux support") Signed-off-by: Gustavo A. R. Silva <garsilva(a)embeddedor.com> Acked-by: Patrice Chotard <patrice.chotard(a)st.com> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) --- a/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c +++ b/drivers/media/platform/sti/c8sectpfe/c8sectpfe-core.c @@ -83,7 +83,7 @@ static void c8sectpfe_timer_interrupt(un static void channel_swdemux_tsklet(unsigned long data) { struct channel_info *channel = (struct channel_info *)data; - struct c8sectpfei *fei = channel->fei; + struct c8sectpfei *fei; unsigned long wp, rp; int pos, num_packets, n, size; u8 *buf; @@ -91,6 +91,8 @@ static void channel_swdemux_tsklet(unsig if (unlikely(!channel || !channel->irec)) return; + fei = channel->fei; + wp = readl(channel->irec + DMA_PRDS_BUSWP_TP(0)); rp = readl(channel->irec + DMA_PRDS_BUSRP_TP(0)); Patches currently in stable-queue which might be from garsilva(a)embeddedor.com are queue-4.9/media-c8sectpfe-fix-potential-null-pointer-dereference-in-c8sectpfe_timer_interrupt.patch

7 years, 3 months

1
0
0 0

Patch "media: bt8xx: Fix err 'bt878_probe()'" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled media: bt8xx: Fix err 'bt878_probe()' to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: media-bt8xx-fix-err-bt878_probe.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Date: Thu, 21 Sep 2017 19:23:56 -0400 Subject: media: bt8xx: Fix err 'bt878_probe()' From: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> [ Upstream commit 45392ff6881dbe56d41ef0b17c2e576065f8ffa1 ] This is odd to call 'pci_disable_device()' in an error path before a coresponding successful 'pci_enable_device()'. Return directly instead. Fixes: 77e0be12100a ("V4L/DVB (4176): Bug-fix: Fix memory overflow") Signed-off-by: Christophe JAILLET <christophe.jaillet(a)wanadoo.fr> Signed-off-by: Mauro Carvalho Chehab <mchehab(a)s-opensource.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/media/pci/bt8xx/bt878.c | 3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) --- a/drivers/media/pci/bt8xx/bt878.c +++ b/drivers/media/pci/bt8xx/bt878.c @@ -422,8 +422,7 @@ static int bt878_probe(struct pci_dev *d bt878_num); if (bt878_num >= BT878_MAX) { printk(KERN_ERR "bt878: Too many devices inserted\n"); - result = -ENOMEM; - goto fail0; + return -ENOMEM; } if (pci_enable_device(dev)) return -EIO; Patches currently in stable-queue which might be from christophe.jaillet(a)wanadoo.fr are queue-4.9/media-bt8xx-fix-err-bt878_probe.patch

7 years, 3 months

1
0
0 0

Patch "md/raid10: wait up frozen array in handle_write_completed" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md/raid10: wait up frozen array in handle_write_completed to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: md-raid10-wait-up-frozen-array-in-handle_write_completed.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Guoqing Jiang <gqjiang(a)suse.com> Date: Mon, 17 Apr 2017 17:11:05 +0800 Subject: md/raid10: wait up frozen array in handle_write_completed From: Guoqing Jiang <gqjiang(a)suse.com> [ Upstream commit cf25ae78fc50010f66b9be945017796da34c434d ] Since nr_queued is changed, we need to call wake_up here if the array is already frozen and waiting for condition "nr_pending == nr_queued + extra" to be true. And commit 824e47daddbf ("RAID1: avoid unnecessary spin locks in I/O barrier code") which has already added the wake_up for raid1. Signed-off-by: Guoqing Jiang <gqjiang(a)suse.com> Reviewed-by: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid10.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -2704,6 +2704,11 @@ static void handle_write_completed(struc list_add(&r10_bio->retry_list, &conf->bio_end_io_list); conf->nr_queued++; spin_unlock_irq(&conf->device_lock); + /* + * In case freeze_array() is waiting for condition + * nr_pending == nr_queued + extra to be true. + */ + wake_up(&conf->wait_barrier); md_wakeup_thread(conf->mddev->thread); } else { if (test_bit(R10BIO_WriteError, Patches currently in stable-queue which might be from gqjiang(a)suse.com are queue-4.9/md-raid10-wait-up-frozen-array-in-handle_write_completed.patch queue-4.9/md-raid10-skip-spare-disk-as-first-disk.patch

7 years, 3 months

1
0
0 0

Patch "md/raid10: skip spare disk as 'first' disk" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled md/raid10: skip spare disk as 'first' disk to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: md-raid10-skip-spare-disk-as-first-disk.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Shaohua Li <shli(a)fb.com> Date: Mon, 1 May 2017 12:15:07 -0700 Subject: md/raid10: skip spare disk as 'first' disk From: Shaohua Li <shli(a)fb.com> [ Upstream commit b506335e5d2b4ec687dde392a3bdbf7601778f1d ] Commit 6f287ca(md/raid10: reset the 'first' at the end of loop) ignores a case in reshape, the first rdev could be a spare disk, which shouldn't be accounted as the first disk since it doesn't include the offset info. Fix: 6f287ca(md/raid10: reset the 'first' at the end of loop) Cc: Guoqing Jiang <gqjiang(a)suse.com> Cc: NeilBrown <neilb(a)suse.com> Signed-off-by: Shaohua Li <shli(a)fb.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/md/raid10.c | 1 + 1 file changed, 1 insertion(+) --- a/drivers/md/raid10.c +++ b/drivers/md/raid10.c @@ -4089,6 +4089,7 @@ static int raid10_start_reshape(struct m diff = 0; if (first || diff < min_offset_diff) min_offset_diff = diff; + first = 0; } } Patches currently in stable-queue which might be from shli(a)fb.com are queue-4.9/md-raid10-wait-up-frozen-array-in-handle_write_completed.patch queue-4.9/md-raid10-skip-spare-disk-as-first-disk.patch

7 years, 3 months

1
0
0 0

Patch "mac80211: Fix possible sband related NULL pointer de-reference" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: Fix possible sband related NULL pointer de-reference to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-fix-possible-sband-related-null-pointer-de-reference.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Date: Thu, 27 Apr 2017 12:45:38 +0530 Subject: mac80211: Fix possible sband related NULL pointer de-reference From: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> [ Upstream commit 21a8e9dd52b64f0170bad208293ef8c30c3c1403 ] Existing API 'ieee80211_get_sdata_band' returns default 2 GHz band even if the channel context configuration is NULL. This crashes for chipsets which support 5 Ghz alone when it tries to access members of 'sband'. Channel context configuration can be NULL in multivif case and when channel switch is in progress (or) when it fails. Fix this by replacing the API 'ieee80211_get_sdata_band' with 'ieee80211_get_sband' which returns a NULL pointer for sband when the channel configuration is NULL. An example scenario is as below: In multivif mode (AP + STA) with drivers like ath10k, when we do a channel switch in the AP vif (which has a number of clients connected) and a STA vif which is connected to some other AP, when the channel switch in AP vif fails, while the STA vifs tries to connect to the other AP, there is a window where the channel context is NULL/invalid and this results in a crash while the clients connected to the AP vif tries to reconnect and this race is very similar to the one investigated by Michal in https://patchwork.kernel.org/patch/3788161/ and this does happens with hardware that supports 5Ghz alone after long hours of testing with continuous channel switch on the AP vif ieee80211 phy0: channel context reservation cannot be finalized because some interfaces aren't switching wlan0: failed to finalize CSA, disconnecting wlan0-1: deauthenticating from 8c:fd:f0:01:54:9c by local choice (Reason: 3=DEAUTH_LEAVING) WARNING: CPU: 1 PID: 19032 at net/mac80211/ieee80211_i.h:1013 sta_info_alloc+0x374/0x3fc [mac80211] [<bf77272c>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211])) [<bf73cc50>] (nl80211_new_station [cfg80211]) Unable to handle kernel NULL pointer dereference at virtual address 00000014 pgd = d5f4c000 Internal error: Oops: 17 [#1] PREEMPT SMP ARM PC is at sta_info_alloc+0x380/0x3fc [mac80211] LR is at sta_info_alloc+0x37c/0x3fc [mac80211] [<bf772738>] (sta_info_alloc [mac80211]) [<bf78776c>] (ieee80211_add_station [mac80211]) [<bf73cc50>] (nl80211_new_station [cfg80211])) Cc: Michal Kazior <michal.kazior(a)tieto.com> Signed-off-by: Mohammed Shafi Shajakhan <mohammed(a)qti.qualcomm.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/cfg.c | 30 +++++++++++++++++------------- net/mac80211/ibss.c | 6 +++++- net/mac80211/ieee80211_i.h | 36 +++++++++++++++++++++--------------- net/mac80211/mesh.c | 29 ++++++++++++++++++++--------- net/mac80211/mesh_plink.c | 37 ++++++++++++++++++++++++++----------- net/mac80211/mlme.c | 14 ++++++++++++-- net/mac80211/rate.c | 4 +++- net/mac80211/sta_info.c | 13 +++++++++---- net/mac80211/tdls.c | 29 +++++++++++++++++++---------- net/mac80211/tx.c | 5 ++++- net/mac80211/util.c | 6 +++--- 11 files changed, 139 insertions(+), 70 deletions(-) --- a/net/mac80211/cfg.c +++ b/net/mac80211/cfg.c @@ -620,10 +620,11 @@ void sta_set_rate_info_tx(struct sta_inf int shift = ieee80211_vif_get_shift(&sta->sdata->vif); u16 brate; - sband = sta->local->hw.wiphy->bands[ - ieee80211_get_sdata_band(sta->sdata)]; - brate = sband->bitrates[rate->idx].bitrate; - rinfo->legacy = DIV_ROUND_UP(brate, 1 << shift); + sband = ieee80211_get_sband(sta->sdata); + if (sband) { + brate = sband->bitrates[rate->idx].bitrate; + rinfo->legacy = DIV_ROUND_UP(brate, 1 << shift); + } } if (rate->flags & IEEE80211_TX_RC_40_MHZ_WIDTH) rinfo->bw = RATE_INFO_BW_40; @@ -1218,10 +1219,11 @@ static int sta_apply_parameters(struct i int ret = 0; struct ieee80211_supported_band *sband; struct ieee80211_sub_if_data *sdata = sta->sdata; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); u32 mask, set; - sband = local->hw.wiphy->bands[band]; + sband = ieee80211_get_sband(sdata); + if (!sband) + return -EINVAL; mask = params->sta_flags_mask; set = params->sta_flags_set; @@ -1354,7 +1356,7 @@ static int sta_apply_parameters(struct i ieee80211_parse_bitrates(&sdata->vif.bss_conf.chandef, sband, params->supported_rates, params->supported_rates_len, - &sta->sta.supp_rates[band]); + &sta->sta.supp_rates[sband->band]); } if (params->ht_capa) @@ -1370,8 +1372,8 @@ static int sta_apply_parameters(struct i /* returned value is only needed for rc update, but the * rc isn't initialized here yet, so ignore it */ - __ieee80211_vht_handle_opmode(sdata, sta, - params->opmode_notif, band); + __ieee80211_vht_handle_opmode(sdata, sta, params->opmode_notif, + sband->band); } if (params->support_p2p_ps >= 0) @@ -2017,13 +2019,15 @@ static int ieee80211_change_bss(struct w struct bss_parameters *params) { struct ieee80211_sub_if_data *sdata = IEEE80211_DEV_TO_SUB_IF(dev); - enum nl80211_band band; + struct ieee80211_supported_band *sband; u32 changed = 0; if (!sdata_dereference(sdata->u.ap.beacon, sdata)) return -ENOENT; - band = ieee80211_get_sdata_band(sdata); + sband = ieee80211_get_sband(sdata); + if (!sband) + return -EINVAL; if (params->use_cts_prot >= 0) { sdata->vif.bss_conf.use_cts_prot = params->use_cts_prot; @@ -2036,7 +2040,7 @@ static int ieee80211_change_bss(struct w } if (!sdata->vif.bss_conf.use_short_slot && - band == NL80211_BAND_5GHZ) { + sband->band == NL80211_BAND_5GHZ) { sdata->vif.bss_conf.use_short_slot = true; changed |= BSS_CHANGED_ERP_SLOT; } @@ -2049,7 +2053,7 @@ static int ieee80211_change_bss(struct w if (params->basic_rates) { ieee80211_parse_bitrates(&sdata->vif.bss_conf.chandef, - wiphy->bands[band], + wiphy->bands[sband->band], params->basic_rates, params->basic_rates_len, &sdata->vif.bss_conf.basic_rates); --- a/net/mac80211/ibss.c +++ b/net/mac80211/ibss.c @@ -994,7 +994,7 @@ static void ieee80211_update_sta_info(st enum nl80211_band band = rx_status->band; enum nl80211_bss_scan_width scan_width; struct ieee80211_local *local = sdata->local; - struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; + struct ieee80211_supported_band *sband; bool rates_updated = false; u32 supp_rates = 0; @@ -1004,6 +1004,10 @@ static void ieee80211_update_sta_info(st if (!ether_addr_equal(mgmt->bssid, sdata->u.ibss.bssid)) return; + sband = local->hw.wiphy->bands[band]; + if (WARN_ON(!sband)) + return; + rcu_read_lock(); sta = sta_info_get(sdata, mgmt->sa); --- a/net/mac80211/ieee80211_i.h +++ b/net/mac80211/ieee80211_i.h @@ -991,21 +991,6 @@ sdata_assert_lock(struct ieee80211_sub_i lockdep_assert_held(&sdata->wdev.mtx); } -static inline enum nl80211_band -ieee80211_get_sdata_band(struct ieee80211_sub_if_data *sdata) -{ - enum nl80211_band band = NL80211_BAND_2GHZ; - struct ieee80211_chanctx_conf *chanctx_conf; - - rcu_read_lock(); - chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); - if (!WARN_ON(!chanctx_conf)) - band = chanctx_conf->def.chan->band; - rcu_read_unlock(); - - return band; -} - static inline int ieee80211_chandef_get_shift(struct cfg80211_chan_def *chandef) { @@ -1410,6 +1395,27 @@ IEEE80211_WDEV_TO_SUB_IF(struct wireless return container_of(wdev, struct ieee80211_sub_if_data, wdev); } +static inline struct ieee80211_supported_band * +ieee80211_get_sband(struct ieee80211_sub_if_data *sdata) +{ + struct ieee80211_local *local = sdata->local; + struct ieee80211_chanctx_conf *chanctx_conf; + enum nl80211_band band; + + rcu_read_lock(); + chanctx_conf = rcu_dereference(sdata->vif.chanctx_conf); + + if (WARN_ON(!chanctx_conf)) { + rcu_read_unlock(); + return NULL; + } + + band = chanctx_conf->def.chan->band; + rcu_read_unlock(); + + return local->hw.wiphy->bands[band]; +} + /* this struct represents 802.11n's RA/TID combination */ struct ieee80211_ra_tid { u8 ra[ETH_ALEN]; --- a/net/mac80211/mesh.c +++ b/net/mac80211/mesh.c @@ -63,6 +63,7 @@ bool mesh_matches_local(struct ieee80211 struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; u32 basic_rates = 0; struct cfg80211_chan_def sta_chan_def; + struct ieee80211_supported_band *sband; /* * As support for each feature is added, check for matching @@ -83,7 +84,11 @@ bool mesh_matches_local(struct ieee80211 (ifmsh->mesh_auth_id == ie->mesh_config->meshconf_auth))) return false; - ieee80211_sta_get_rates(sdata, ie, ieee80211_get_sdata_band(sdata), + sband = ieee80211_get_sband(sdata); + if (!sband) + return false; + + ieee80211_sta_get_rates(sdata, ie, sband->band, &basic_rates); if (sdata->vif.bss_conf.basic_rates != basic_rates) @@ -399,12 +404,13 @@ static int mesh_add_ds_params_ie(struct int mesh_add_ht_cap_ie(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb) { - struct ieee80211_local *local = sdata->local; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); struct ieee80211_supported_band *sband; u8 *pos; - sband = local->hw.wiphy->bands[band]; + sband = ieee80211_get_sband(sdata); + if (!sband) + return -EINVAL; + if (!sband->ht_cap.ht_supported || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 || @@ -462,12 +468,13 @@ int mesh_add_ht_oper_ie(struct ieee80211 int mesh_add_vht_cap_ie(struct ieee80211_sub_if_data *sdata, struct sk_buff *skb) { - struct ieee80211_local *local = sdata->local; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); struct ieee80211_supported_band *sband; u8 *pos; - sband = local->hw.wiphy->bands[band]; + sband = ieee80211_get_sband(sdata); + if (!sband) + return -EINVAL; + if (!sband->vht_cap.vht_supported || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_20_NOHT || sdata->vif.bss_conf.chandef.width == NL80211_CHAN_WIDTH_5 || @@ -916,12 +923,16 @@ ieee80211_mesh_process_chnswitch(struct struct cfg80211_csa_settings params; struct ieee80211_csa_ie csa_ie; struct ieee80211_if_mesh *ifmsh = &sdata->u.mesh; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); + struct ieee80211_supported_band *sband; int err; u32 sta_flags; sdata_assert_lock(sdata); + sband = ieee80211_get_sband(sdata); + if (!sband) + return false; + sta_flags = IEEE80211_STA_DISABLE_VHT; switch (sdata->vif.bss_conf.chandef.width) { case NL80211_CHAN_WIDTH_20_NOHT: @@ -935,7 +946,7 @@ ieee80211_mesh_process_chnswitch(struct memset(&params, 0, sizeof(params)); memset(&csa_ie, 0, sizeof(csa_ie)); - err = ieee80211_parse_ch_switch_ie(sdata, elems, band, + err = ieee80211_parse_ch_switch_ie(sdata, elems, sband->band, sta_flags, sdata->vif.addr, &csa_ie); if (err < 0) --- a/net/mac80211/mesh_plink.c +++ b/net/mac80211/mesh_plink.c @@ -93,19 +93,23 @@ static inline void mesh_plink_fsm_restar static u32 mesh_set_short_slot_time(struct ieee80211_sub_if_data *sdata) { struct ieee80211_local *local = sdata->local; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); - struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; + struct ieee80211_supported_band *sband; struct sta_info *sta; u32 erp_rates = 0, changed = 0; int i; bool short_slot = false; - if (band == NL80211_BAND_5GHZ) { + sband = ieee80211_get_sband(sdata); + if (!sband) + return changed; + + if (sband->band == NL80211_BAND_5GHZ) { /* (IEEE 802.11-2012 19.4.5) */ short_slot = true; goto out; - } else if (band != NL80211_BAND_2GHZ) + } else if (sband->band != NL80211_BAND_2GHZ) { goto out; + } for (i = 0; i < sband->n_bitrates; i++) if (sband->bitrates[i].flags & IEEE80211_RATE_ERP_G) @@ -121,7 +125,7 @@ static u32 mesh_set_short_slot_time(stru continue; short_slot = false; - if (erp_rates & sta->sta.supp_rates[band]) + if (erp_rates & sta->sta.supp_rates[sband->band]) short_slot = true; else break; @@ -247,7 +251,15 @@ static int mesh_plink_frame_tx(struct ie mgmt->u.action.u.self_prot.action_code = action; if (action != WLAN_SP_MESH_PEERING_CLOSE) { - enum nl80211_band band = ieee80211_get_sdata_band(sdata); + struct ieee80211_supported_band *sband; + enum nl80211_band band; + + sband = ieee80211_get_sband(sdata); + if (!sband) { + err = -EINVAL; + goto free; + } + band = sband->band; /* capability info */ pos = skb_put(skb, 2); @@ -393,13 +405,16 @@ static void mesh_sta_info_init(struct ie struct ieee802_11_elems *elems, bool insert) { struct ieee80211_local *local = sdata->local; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); struct ieee80211_supported_band *sband; u32 rates, basic_rates = 0, changed = 0; enum ieee80211_sta_rx_bandwidth bw = sta->sta.bandwidth; - sband = local->hw.wiphy->bands[band]; - rates = ieee80211_sta_get_rates(sdata, elems, band, &basic_rates); + sband = ieee80211_get_sband(sdata); + if (!sband) + return; + + rates = ieee80211_sta_get_rates(sdata, elems, sband->band, + &basic_rates); spin_lock_bh(&sta->mesh->plink_lock); sta->rx_stats.last_rx = jiffies; @@ -410,9 +425,9 @@ static void mesh_sta_info_init(struct ie goto out; sta->mesh->processed_beacon = true; - if (sta->sta.supp_rates[band] != rates) + if (sta->sta.supp_rates[sband->band] != rates) changed |= IEEE80211_RC_SUPP_RATES_CHANGED; - sta->sta.supp_rates[band] = rates; + sta->sta.supp_rates[sband->band] = rates; if (ieee80211_ht_cap_ie_to_sta_ht_cap(sdata, sband, elems->ht_cap_elem, sta)) --- a/net/mac80211/mlme.c +++ b/net/mac80211/mlme.c @@ -1851,11 +1851,16 @@ static u32 ieee80211_handle_bss_capabili u16 capab, bool erp_valid, u8 erp) { struct ieee80211_bss_conf *bss_conf = &sdata->vif.bss_conf; + struct ieee80211_supported_band *sband; u32 changed = 0; bool use_protection; bool use_short_preamble; bool use_short_slot; + sband = ieee80211_get_sband(sdata); + if (!sband) + return changed; + if (erp_valid) { use_protection = (erp & WLAN_ERP_USE_PROTECTION) != 0; use_short_preamble = (erp & WLAN_ERP_BARKER_PREAMBLE) == 0; @@ -1865,7 +1870,7 @@ static u32 ieee80211_handle_bss_capabili } use_short_slot = !!(capab & WLAN_CAPABILITY_SHORT_SLOT_TIME); - if (ieee80211_get_sdata_band(sdata) == NL80211_BAND_5GHZ) + if (sband->band == NL80211_BAND_5GHZ) use_short_slot = true; if (use_protection != bss_conf->use_cts_prot) { @@ -2994,7 +2999,12 @@ static bool ieee80211_assoc_success(stru goto out; } - sband = local->hw.wiphy->bands[ieee80211_get_sdata_band(sdata)]; + sband = ieee80211_get_sband(sdata); + if (!sband) { + mutex_unlock(&sdata->local->sta_mtx); + ret = false; + goto out; + } /* Set up internal HT/VHT capabilities */ if (elems.ht_cap_elem && !(ifmgd->flags & IEEE80211_STA_DISABLE_HT)) --- a/net/mac80211/rate.c +++ b/net/mac80211/rate.c @@ -875,7 +875,9 @@ int rate_control_set_rates(struct ieee80 struct ieee80211_sta_rates *old; struct ieee80211_supported_band *sband; - sband = hw->wiphy->bands[ieee80211_get_sdata_band(sta->sdata)]; + sband = ieee80211_get_sband(sta->sdata); + if (!sband) + return -EINVAL; rate_control_apply_mask_ratetbl(sta, sband, rates); /* * mac80211 guarantees that this function will not be called --- a/net/mac80211/sta_info.c +++ b/net/mac80211/sta_info.c @@ -395,10 +395,15 @@ struct sta_info *sta_info_alloc(struct i sta->sta.smps_mode = IEEE80211_SMPS_OFF; if (sdata->vif.type == NL80211_IFTYPE_AP || sdata->vif.type == NL80211_IFTYPE_AP_VLAN) { - struct ieee80211_supported_band *sband = - hw->wiphy->bands[ieee80211_get_sdata_band(sdata)]; - u8 smps = (sband->ht_cap.cap & IEEE80211_HT_CAP_SM_PS) >> - IEEE80211_HT_CAP_SM_PS_SHIFT; + struct ieee80211_supported_band *sband; + u8 smps; + + sband = ieee80211_get_sband(sdata); + if (!sband) + goto free_txq; + + smps = (sband->ht_cap.cap & IEEE80211_HT_CAP_SM_PS) >> + IEEE80211_HT_CAP_SM_PS_SHIFT; /* * Assume that hostapd advertises our caps in the beacon and * this is the known_smps_mode for a station that just assciated --- a/net/mac80211/tdls.c +++ b/net/mac80211/tdls.c @@ -47,8 +47,7 @@ static void ieee80211_tdls_add_ext_capab NL80211_FEATURE_TDLS_CHANNEL_SWITCH; bool wider_band = ieee80211_hw_check(&local->hw, TDLS_WIDER_BW) && !ifmgd->tdls_wider_bw_prohibited; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); - struct ieee80211_supported_band *sband = local->hw.wiphy->bands[band]; + struct ieee80211_supported_band *sband = ieee80211_get_sband(sdata); bool vht = sband && sband->vht_cap.vht_supported; u8 *pos = (void *)skb_put(skb, 10); @@ -180,11 +179,14 @@ static void ieee80211_tdls_add_bss_coex_ static u16 ieee80211_get_tdls_sta_capab(struct ieee80211_sub_if_data *sdata, u16 status_code) { + struct ieee80211_supported_band *sband; + /* The capability will be 0 when sending a failure code */ if (status_code != 0) return 0; - if (ieee80211_get_sdata_band(sdata) == NL80211_BAND_2GHZ) { + sband = ieee80211_get_sband(sdata); + if (sband && sband->band == NL80211_BAND_2GHZ) { return WLAN_CAPABILITY_SHORT_SLOT_TIME | WLAN_CAPABILITY_SHORT_PREAMBLE; } @@ -358,17 +360,20 @@ ieee80211_tdls_add_setup_start_ies(struc u8 action_code, bool initiator, const u8 *extra_ies, size_t extra_ies_len) { - enum nl80211_band band = ieee80211_get_sdata_band(sdata); - struct ieee80211_local *local = sdata->local; struct ieee80211_supported_band *sband; + struct ieee80211_local *local = sdata->local; struct ieee80211_sta_ht_cap ht_cap; struct ieee80211_sta_vht_cap vht_cap; struct sta_info *sta = NULL; size_t offset = 0, noffset; u8 *pos; - ieee80211_add_srates_ie(sdata, skb, false, band); - ieee80211_add_ext_srates_ie(sdata, skb, false, band); + sband = ieee80211_get_sband(sdata); + if (!sband) + return; + + ieee80211_add_srates_ie(sdata, skb, false, sband->band); + ieee80211_add_ext_srates_ie(sdata, skb, false, sband->band); ieee80211_tdls_add_supp_channels(sdata, skb); /* add any custom IEs that go before Extended Capabilities */ @@ -439,7 +444,6 @@ ieee80211_tdls_add_setup_start_ies(struc * the same on all bands. The specification limits the setup to a * single HT-cap, so use the current band for now. */ - sband = local->hw.wiphy->bands[band]; memcpy(&ht_cap, &sband->ht_cap, sizeof(ht_cap)); if ((action_code == WLAN_TDLS_SETUP_REQUEST || @@ -545,9 +549,13 @@ ieee80211_tdls_add_setup_cfm_ies(struct struct ieee80211_if_managed *ifmgd = &sdata->u.mgd; size_t offset = 0, noffset; struct sta_info *sta, *ap_sta; - enum nl80211_band band = ieee80211_get_sdata_band(sdata); + struct ieee80211_supported_band *sband; u8 *pos; + sband = ieee80211_get_sband(sdata); + if (!sband) + return; + mutex_lock(&local->sta_mtx); sta = sta_info_get(sdata, peer); @@ -612,7 +620,8 @@ ieee80211_tdls_add_setup_cfm_ies(struct ieee80211_tdls_add_link_ie(sdata, skb, peer, initiator); /* only include VHT-operation if not on the 2.4GHz band */ - if (band != NL80211_BAND_2GHZ && sta->sta.vht_cap.vht_supported) { + if (sband->band != NL80211_BAND_2GHZ && + sta->sta.vht_cap.vht_supported) { /* * if both peers support WIDER_BW, we can expand the chandef to * a wider compatible one, up to 80MHz --- a/net/mac80211/tx.c +++ b/net/mac80211/tx.c @@ -4182,7 +4182,10 @@ struct sk_buff *ieee80211_beacon_get_tim return bcn; shift = ieee80211_vif_get_shift(vif); - sband = hw->wiphy->bands[ieee80211_get_sdata_band(vif_to_sdata(vif))]; + sband = ieee80211_get_sband(vif_to_sdata(vif)); + if (!sband) + return bcn; + ieee80211_tx_monitor(hw_to_local(hw), copy, sband, 1, shift, false); return bcn; --- a/net/mac80211/util.c +++ b/net/mac80211/util.c @@ -1590,14 +1590,14 @@ u32 ieee80211_sta_get_rates(struct ieee8 size_t num_rates; u32 supp_rates, rate_flags; int i, j, shift; + sband = sdata->local->hw.wiphy->bands[band]; + if (WARN_ON(!sband)) + return 1; rate_flags = ieee80211_chandef_rate_flags(&sdata->vif.bss_conf.chandef); shift = ieee80211_vif_get_shift(&sdata->vif); - if (WARN_ON(!sband)) - return 1; - num_rates = sband->n_bitrates; supp_rates = 0; for (i = 0; i < elems->supp_rates_len + Patches currently in stable-queue which might be from mohammed(a)qti.qualcomm.com are queue-4.9/mac80211-fix-possible-sband-related-null-pointer-de-reference.patch queue-4.9/ath-fix-updating-radar-flags-for-coutry-code-india.patch

7 years, 3 months

1
0
0 0

Patch "mac80211: don't parse encrypted management frames in ieee80211_frame_acked" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled mac80211: don't parse encrypted management frames in ieee80211_frame_acked to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: mac80211-don-t-parse-encrypted-management-frames-in-ieee80211_frame_acked.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Date: Wed, 26 Apr 2017 10:58:51 +0300 Subject: mac80211: don't parse encrypted management frames in ieee80211_frame_acked From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> [ Upstream commit cf147085fdda044622973a12e4e06f1c753ab677 ] ieee80211_frame_acked is called when a frame is acked by the peer. In case this is a management frame, we check if this an SMPS frame, in which case we can update our antenna configuration. When we parse the management frame we look at the category in case it is an action frame. That byte sits after the IV in case the frame was encrypted. This means that if the frame was encrypted, we basically look at the IV instead of looking at the category. It is then theorically possible that we think that an SMPS action frame was acked where really we had another frame that was encrypted. Since the only management frame whose ack needs to be tracked is the SMPS action frame, and that frame is not a robust management frame, it will never be encrypted. The easiest way to fix this problem is then to not look at frames that were encrypted. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Johannes Berg <johannes.berg(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/mac80211/status.c | 1 + 1 file changed, 1 insertion(+) --- a/net/mac80211/status.c +++ b/net/mac80211/status.c @@ -200,6 +200,7 @@ static void ieee80211_frame_acked(struct } if (ieee80211_is_action(mgmt->frame_control) && + !ieee80211_has_protected(mgmt->frame_control) && mgmt->u.action.category == WLAN_CATEGORY_HT && mgmt->u.action.u.ht_smps.action == WLAN_HT_ACTION_SMPS && ieee80211_sdata_running(sdata)) { Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are queue-4.9/iwlwifi-split-the-handler-and-the-wake-parts-of-the-notification-infra.patch queue-4.9/mac80211-don-t-parse-encrypted-management-frames-in-ieee80211_frame_acked.patch

7 years, 3 months

1
0
0 0

Patch "libertas: check return value of alloc_workqueue" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled libertas: check return value of alloc_workqueue to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: libertas-check-return-value-of-alloc_workqueue.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Pan Bian <bianpan2016(a)163.com> Date: Sun, 23 Apr 2017 21:19:38 +0800 Subject: libertas: check return value of alloc_workqueue From: Pan Bian <bianpan2016(a)163.com> [ Upstream commit dc3f89c38a8406554ffeffa370aad086a9c5e9de ] Function alloc_workqueue() will return a NULL pointer if there is no enough memory, and its return value should be validated before using. However, in function if_spi_probe(), its return value is not checked. This may result in a NULL dereference bug. This patch fixes the bug. Signed-off-by: Pan Bian <bianpan2016(a)163.com> Signed-off-by: Kalle Valo <kvalo(a)codeaurora.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/marvell/libertas/if_spi.c | 5 +++++ 1 file changed, 5 insertions(+) --- a/drivers/net/wireless/marvell/libertas/if_spi.c +++ b/drivers/net/wireless/marvell/libertas/if_spi.c @@ -1181,6 +1181,10 @@ static int if_spi_probe(struct spi_devic /* Initialize interrupt handling stuff. */ card->workqueue = alloc_workqueue("libertas_spi", WQ_MEM_RECLAIM, 0); + if (!card->workqueue) { + err = -ENOMEM; + goto remove_card; + } INIT_WORK(&card->packet_work, if_spi_host_to_card_worker); INIT_WORK(&card->resume_work, if_spi_resume_worker); @@ -1209,6 +1213,7 @@ release_irq: free_irq(spi->irq, card); terminate_workqueue: destroy_workqueue(card->workqueue); +remove_card: lbs_remove_card(priv); /* will call free_netdev */ free_card: free_if_spi_card(card); Patches currently in stable-queue which might be from bianpan2016(a)163.com are queue-4.9/tipc-check-return-value-of-nlmsg_new.patch queue-4.9/mt7601u-check-return-value-of-alloc_skb.patch queue-4.9/rndis_wlan-add-return-value-validation.patch queue-4.9/libertas-check-return-value-of-alloc_workqueue.patch queue-4.9/staging-wilc1000-fix-unchecked-return-value.patch queue-4.9/qlcnic-fix-unchecked-return-value.patch queue-4.9/wan-pc300too-abort-path-on-failure.patch queue-4.9/power-supply-isp1704-fix-unchecked-return-value-of-devm_kzalloc.patch

7 years, 3 months

1
0
0 0

Patch "KVM: PPC: Book3S PR: Exit KVM on failed mapping" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled KVM: PPC: Book3S PR: Exit KVM on failed mapping to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: kvm-ppc-book3s-pr-exit-kvm-on-failed-mapping.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Alexey Kardashevskiy <aik(a)ozlabs.ru> Date: Fri, 24 Mar 2017 17:48:10 +1100 Subject: KVM: PPC: Book3S PR: Exit KVM on failed mapping From: Alexey Kardashevskiy <aik(a)ozlabs.ru> [ Upstream commit bd9166ffe624000140fc6b606b256df01fc0d060 ] At the moment kvmppc_mmu_map_page() returns -1 if mmu_hash_ops.hpte_insert() fails for any reason so the page fault handler resumes the guest and it faults on the same address again. This adds distinction to kvmppc_mmu_map_page() to return -EIO if mmu_hash_ops.hpte_insert() failed for a reason other than full pteg. At the moment only pSeries_lpar_hpte_insert() returns -2 if plpar_pte_enter() failed with a code other than H_PTEG_FULL. Other mmu_hash_ops.hpte_insert() instances can only fail with -1 "full pteg". With this change, if PR KVM fails to update HPT, it can signal the userspace about this instead of returning to guest and having the very same page fault over and over again. Signed-off-by: Alexey Kardashevskiy <aik(a)ozlabs.ru> Reviewed-by: David Gibson <david(a)gibson.dropbear.id.au> Signed-off-by: Paul Mackerras <paulus(a)ozlabs.org> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- arch/powerpc/kvm/book3s_64_mmu_host.c | 5 ++++- arch/powerpc/kvm/book3s_pr.c | 6 +++++- 2 files changed, 9 insertions(+), 2 deletions(-) --- a/arch/powerpc/kvm/book3s_64_mmu_host.c +++ b/arch/powerpc/kvm/book3s_64_mmu_host.c @@ -177,12 +177,15 @@ map_again: ret = mmu_hash_ops.hpte_insert(hpteg, vpn, hpaddr, rflags, vflags, hpsize, hpsize, MMU_SEGSIZE_256M); - if (ret < 0) { + if (ret == -1) { /* If we couldn't map a primary PTE, try a secondary */ hash = ~hash; vflags ^= HPTE_V_SECONDARY; attempt++; goto map_again; + } else if (ret < 0) { + r = -EIO; + goto out_unlock; } else { trace_kvm_book3s_64_mmu_map(rflags, hpteg, vpn, hpaddr, orig_pte); --- a/arch/powerpc/kvm/book3s_pr.c +++ b/arch/powerpc/kvm/book3s_pr.c @@ -627,7 +627,11 @@ int kvmppc_handle_pagefault(struct kvm_r kvmppc_mmu_unmap_page(vcpu, &pte); } /* The guest's PTE is not mapped yet. Map on the host */ - kvmppc_mmu_map_page(vcpu, &pte, iswrite); + if (kvmppc_mmu_map_page(vcpu, &pte, iswrite) == -EIO) { + /* Exit KVM if mapping failed */ + run->exit_reason = KVM_EXIT_INTERNAL_ERROR; + return RESUME_HOST; + } if (data) vcpu->stat.sp_storage++; else if (vcpu->arch.mmu.is_dcbz32(vcpu) && Patches currently in stable-queue which might be from aik(a)ozlabs.ru are queue-4.9/kvm-ppc-book3s-pr-exit-kvm-on-failed-mapping.patch

7 years, 3 months

1
0
0 0

Patch "jbd2: Fix lockdep splat with generic/270 test" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled jbd2: Fix lockdep splat with generic/270 test to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: jbd2-fix-lockdep-splat-with-generic-270-test.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Jan Kara <jack(a)suse.cz> Date: Sat, 29 Apr 2017 20:12:16 -0400 Subject: jbd2: Fix lockdep splat with generic/270 test From: Jan Kara <jack(a)suse.cz> [ Upstream commit c52c47e4b4fbe4284602fc2ccbfc4a4d8dc05b49 ] I've hit a lockdep splat with generic/270 test complaining that: 3216.fsstress.b/3533 is trying to acquire lock: (jbd2_handle){++++..}, at: [<ffffffff813152e0>] jbd2_log_wait_commit+0x0/0x150 but task is already holding lock: (jbd2_handle){++++..}, at: [<ffffffff8130bd3b>] start_this_handle+0x35b/0x850 The underlying problem is that jbd2_journal_force_commit_nested() (called from ext4_should_retry_alloc()) may get called while a transaction handle is started. In such case it takes care to not wait for commit of the running transaction (which would deadlock) but only for a commit of a transaction that is already committing (which is safe as that doesn't wait for any filesystem locks). In fact there are also other callers of jbd2_log_wait_commit() that take care to pass tid of a transaction that is already committing and for those cases, the lockdep instrumentation is too restrictive and leading to false positive reports. Fix the problem by calling jbd2_might_wait_for_commit() from jbd2_log_wait_commit() only if the transaction isn't already committing. Fixes: 1eaa566d368b214d99cbb973647c1b0b8102a9ae Signed-off-by: Jan Kara <jack(a)suse.cz> Signed-off-by: Theodore Ts'o <tytso(a)mit.edu> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- fs/jbd2/journal.c | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) --- a/fs/jbd2/journal.c +++ b/fs/jbd2/journal.c @@ -691,8 +691,21 @@ int jbd2_log_wait_commit(journal_t *jour { int err = 0; - jbd2_might_wait_for_commit(journal); read_lock(&journal->j_state_lock); +#ifdef CONFIG_PROVE_LOCKING + /* + * Some callers make sure transaction is already committing and in that + * case we cannot block on open handles anymore. So don't warn in that + * case. + */ + if (tid_gt(tid, journal->j_commit_sequence) && + (!journal->j_committing_transaction || + journal->j_committing_transaction->t_tid != tid)) { + read_unlock(&journal->j_state_lock); + jbd2_might_wait_for_commit(journal); + read_lock(&journal->j_state_lock); + } +#endif #ifdef CONFIG_JBD2_DEBUG if (!tid_geq(journal->j_commit_request, tid)) { printk(KERN_ERR Patches currently in stable-queue which might be from jack(a)suse.cz are queue-4.9/jbd2-fix-lockdep-splat-with-generic-270-test.patch

7 years, 3 months

1
0
0 0

Patch "ixgbevf: fix size of queue stats length" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ixgbevf: fix size of queue stats length to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ixgbevf-fix-size-of-queue-stats-length.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Emil Tantilov <emil.s.tantilov(a)intel.com> Date: Thu, 30 Mar 2017 20:49:02 -0700 Subject: ixgbevf: fix size of queue stats length From: Emil Tantilov <emil.s.tantilov(a)intel.com> [ Upstream commit f87fc44770f54ff1b54d44ae9cec11f10efeca02 ] IXGBEVF_QUEUE_STATS_LEN is based on ixgebvf_stats, not ixgbe_stats. This change fixes a bug where ethtool -S displayed some empty fields. Signed-off-by: Emil Tantilov <emil.s.tantilov(a)intel.com> Tested-by: Andrew Bowers <andrewx.bowers(a)intel.com> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/ethernet/intel/ixgbevf/ethtool.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- a/drivers/net/ethernet/intel/ixgbevf/ethtool.c +++ b/drivers/net/ethernet/intel/ixgbevf/ethtool.c @@ -80,7 +80,7 @@ static struct ixgbe_stats ixgbevf_gstrin #define IXGBEVF_QUEUE_STATS_LEN ( \ (((struct ixgbevf_adapter *)netdev_priv(netdev))->num_tx_queues + \ ((struct ixgbevf_adapter *)netdev_priv(netdev))->num_rx_queues) * \ - (sizeof(struct ixgbe_stats) / sizeof(u64))) + (sizeof(struct ixgbevf_stats) / sizeof(u64))) #define IXGBEVF_GLOBAL_STATS_LEN ARRAY_SIZE(ixgbevf_gstrings_stats) #define IXGBEVF_STATS_LEN (IXGBEVF_GLOBAL_STATS_LEN + IXGBEVF_QUEUE_STATS_LEN) Patches currently in stable-queue which might be from emil.s.tantilov(a)intel.com are queue-4.9/ixgbevf-fix-size-of-queue-stats-length.patch

7 years, 3 months

1
0
0 0

Patch "iwlwifi: split the handler and the wake parts of the notification infra" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iwlwifi: split the handler and the wake parts of the notification infra to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iwlwifi-split-the-handler-and-the-wake-parts-of-the-notification-infra.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Date: Mon, 13 Feb 2017 11:29:16 +0200 Subject: iwlwifi: split the handler and the wake parts of the notification infra From: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> [ Upstream commit 2220fb2960b72915e7fd9da640a4695dceff238c ] The notification infrastructure (iwl_notification_wait_* functions) allows to wait until a list of notifications will come up from the firmware and to run a special handler (notif_wait handler) when those are received. The operation mode notifies the notification infrastructure about any Rx being received by the mean of iwl_notification_wait_notify() which will do two things: 1) call the notif_wait handler 2) wakeup the thread that was waiting for the notification Typically, only after those two steps happened, the operation mode will run its own handler for the notification that was received from the firmware. This means that the thread that was waiting for that notification can be running before the operation mode's handler was called. When the operation mode's handler is ASYNC, things get even worse since the thread that was waiting for the notification isn't even guaranteed that the ASYNC callback was added to async_handlers_list before it starts to run. This means that even calling iwl_mvm_wait_for_async_handlers() can't guarantee that absolutely everything related to that notification has run. The following can happen: Thread sending the command Operation mode's Rx path -------------------------- ------------------------ iwl_init_notification_wait() iwl_mvm_send_cmd() iwl_mvm_rx_common() iwl_notification_wait_notify() iwl_mvm_wait_for_async_handlers() // Possibly free some data // structure list_add_tail(async_handlers_list); schedule_work(async_handlers_wk); // Access the freed structure Split the 'run notif_wait's handler' and the 'wake up the thread' parts to fix this. This allows the operation mode to do the following: Thread sending the command Operation mode's Rx path -------------------------- ------------------------ iwl_init_notification_wait() iwl_mvm_send_cmd() iwl_mvm_rx_common() iwl_notification_wait() // Will run the notif_wait's handler list_add_tail(async_handlers_list); schedule_work(async_handlers_wk); iwl_notification_notify() iwl_mvm_wait_for_async_handlers() This way, the waiter is guaranteed that all the handlers have been run (if SYNC), or at least enqueued (if ASYNC) by the time it wakes up. Signed-off-by: Emmanuel Grumbach <emmanuel.grumbach(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c | 10 +++----- drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h | 25 ++++++++++++++++---- 2 files changed, 24 insertions(+), 11 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.c @@ -76,8 +76,8 @@ void iwl_notification_wait_init(struct i } IWL_EXPORT_SYMBOL(iwl_notification_wait_init); -void iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_wait, - struct iwl_rx_packet *pkt) +bool iwl_notification_wait(struct iwl_notif_wait_data *notif_wait, + struct iwl_rx_packet *pkt) { bool triggered = false; @@ -118,13 +118,11 @@ void iwl_notification_wait_notify(struct } } spin_unlock(&notif_wait->notif_wait_lock); - } - if (triggered) - wake_up_all(&notif_wait->notif_waitq); + return triggered; } -IWL_EXPORT_SYMBOL(iwl_notification_wait_notify); +IWL_EXPORT_SYMBOL(iwl_notification_wait); void iwl_abort_notification_waits(struct iwl_notif_wait_data *notif_wait) { --- a/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h +++ b/drivers/net/wireless/intel/iwlwifi/iwl-notif-wait.h @@ -6,7 +6,7 @@ * GPL LICENSE SUMMARY * * Copyright(c) 2007 - 2014 Intel Corporation. All rights reserved. - * Copyright(c) 2015 Intel Deutschland GmbH + * Copyright(c) 2015 - 2017 Intel Deutschland GmbH * * This program is free software; you can redistribute it and/or modify * it under the terms of version 2 of the GNU General Public License as @@ -32,6 +32,7 @@ * BSD LICENSE * * Copyright(c) 2005 - 2014 Intel Corporation. All rights reserved. + * Copyright(c) 2015 - 2017 Intel Deutschland GmbH * All rights reserved. * * Redistribution and use in source and binary forms, with or without @@ -89,10 +90,10 @@ struct iwl_notif_wait_data { * * This structure is not used directly, to wait for a * notification declare it on the stack, and call - * iwlagn_init_notification_wait() with appropriate + * iwl_init_notification_wait() with appropriate * parameters. Then do whatever will cause the ucode * to notify the driver, and to wait for that then - * call iwlagn_wait_notification(). + * call iwl_wait_notification(). * * Each notification is one-shot. If at some point we * need to support multi-shot notifications (which @@ -114,10 +115,24 @@ struct iwl_notification_wait { /* caller functions */ void iwl_notification_wait_init(struct iwl_notif_wait_data *notif_data); -void iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_data, - struct iwl_rx_packet *pkt); +bool iwl_notification_wait(struct iwl_notif_wait_data *notif_data, + struct iwl_rx_packet *pkt); void iwl_abort_notification_waits(struct iwl_notif_wait_data *notif_data); +static inline void +iwl_notification_notify(struct iwl_notif_wait_data *notif_data) +{ + wake_up_all(&notif_data->notif_waitq); +} + +static inline void +iwl_notification_wait_notify(struct iwl_notif_wait_data *notif_data, + struct iwl_rx_packet *pkt) +{ + if (iwl_notification_wait(notif_data, pkt)) + iwl_notification_notify(notif_data); +} + /* user functions */ void __acquires(wait_entry) iwl_init_notification_wait(struct iwl_notif_wait_data *notif_data, Patches currently in stable-queue which might be from emmanuel.grumbach(a)intel.com are queue-4.9/iwlwifi-split-the-handler-and-the-wake-parts-of-the-notification-infra.patch queue-4.9/mac80211-don-t-parse-encrypted-management-frames-in-ieee80211_frame_acked.patch

7 years, 3 months

1
0
0 0

Patch "iwlwifi: a000: fix memory offsets and lengths" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iwlwifi: a000: fix memory offsets and lengths to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iwlwifi-a000-fix-memory-offsets-and-lengths.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Liad Kaufman <liad.kaufman(a)intel.com> Date: Sun, 19 Feb 2017 10:42:40 +0200 Subject: iwlwifi: a000: fix memory offsets and lengths From: Liad Kaufman <liad.kaufman(a)intel.com> [ Upstream commit f4d1047914ea05e0f8393944da18f6ee5dad24c4 ] Memory offsets and lengths for A000 HW is different than currently specified. Fixes: e34d975e40ff ("iwlwifi: Add a000 HW family support") Signed-off-by: Liad Kaufman <liad.kaufman(a)intel.com> Signed-off-by: Luca Coelho <luciano.coelho(a)intel.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/net/wireless/intel/iwlwifi/iwl-a000.c | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) --- a/drivers/net/wireless/intel/iwlwifi/iwl-a000.c +++ b/drivers/net/wireless/intel/iwlwifi/iwl-a000.c @@ -65,12 +65,12 @@ #define IWL_A000_TX_POWER_VERSION 0xffff /* meaningless */ /* Memory offsets and lengths */ -#define IWL_A000_DCCM_OFFSET 0x800000 -#define IWL_A000_DCCM_LEN 0x18000 +#define IWL_A000_DCCM_OFFSET 0x800000 /* LMAC1 */ +#define IWL_A000_DCCM_LEN 0x10000 /* LMAC1 */ #define IWL_A000_DCCM2_OFFSET 0x880000 #define IWL_A000_DCCM2_LEN 0x8000 #define IWL_A000_SMEM_OFFSET 0x400000 -#define IWL_A000_SMEM_LEN 0x68000 +#define IWL_A000_SMEM_LEN 0xD0000 #define IWL_A000_FW_PRE "iwlwifi-Qu-a0-jf-b0-" #define IWL_A000_MODULE_FIRMWARE(api) \ Patches currently in stable-queue which might be from liad.kaufman(a)intel.com are queue-4.9/iwlwifi-a000-fix-memory-offsets-and-lengths.patch

7 years, 3 months

1
0
0 0

Patch "iser-target: avoid reinitializing rdma contexts for isert commands" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled iser-target: avoid reinitializing rdma contexts for isert commands to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: iser-target-avoid-reinitializing-rdma-contexts-for-isert-commands.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:24 CET 2018 From: Bharat Potnuri <bharat(a)chelsio.com> Date: Tue, 28 Nov 2017 23:58:07 +0530 Subject: iser-target: avoid reinitializing rdma contexts for isert commands From: Bharat Potnuri <bharat(a)chelsio.com> [ Upstream commit 66f53e6f5400578bae58db0c06d85a8820831f40 ] isert commands that failed during isert_rdma_rw_ctx_post() are queued to Queue-Full(QF) queue and are scheduled to be reposted during queue-full queue processing. During this reposting, the rdma contexts are initialised again in isert_rdma_rw_ctx_post(), which is leaking significant memory. unreferenced object 0xffff8830201d9640 (size 64): comm "kworker/0:2", pid 195, jiffies 4295374851 (age 4528.436s) hex dump (first 32 bytes): 00 60 8b cb 2e 00 00 00 00 10 00 00 00 00 00 00 .`.............. 00 90 e3 cb 2e 00 00 00 00 10 00 00 00 00 00 00 ................ backtrace: [<ffffffff8170711e>] kmemleak_alloc+0x4e/0xb0 [<ffffffff811f8ba5>] __kmalloc+0x125/0x2b0 [<ffffffffa046b24f>] rdma_rw_ctx_init+0x15f/0x6f0 [ib_core] [<ffffffffa07ab644>] isert_rdma_rw_ctx_post+0xc4/0x3c0 [ib_isert] [<ffffffffa07ad972>] isert_put_datain+0x112/0x1c0 [ib_isert] [<ffffffffa07dddce>] lio_queue_data_in+0x2e/0x30 [iscsi_target_mod] [<ffffffffa076c322>] target_qf_do_work+0x2b2/0x4b0 [target_core_mod] [<ffffffff81080c3b>] process_one_work+0x1db/0x5d0 [<ffffffff8108107d>] worker_thread+0x4d/0x3e0 [<ffffffff81088667>] kthread+0x117/0x150 [<ffffffff81713fa7>] ret_from_fork+0x27/0x40 [<ffffffffffffffff>] 0xffffffffffffffff Here is patch to use the older rdma contexts while reposting the isert commands intead of reinitialising them. Signed-off-by: Potnuri Bharat Teja <bharat(a)chelsio.com> Reviewed-by: Sagi Grimberg <sagi(a)grimberg.me> Signed-off-by: Jason Gunthorpe <jgg(a)mellanox.com> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/infiniband/ulp/isert/ib_isert.c | 7 +++++++ drivers/infiniband/ulp/isert/ib_isert.h | 1 + 2 files changed, 8 insertions(+) --- a/drivers/infiniband/ulp/isert/ib_isert.c +++ b/drivers/infiniband/ulp/isert/ib_isert.c @@ -2098,6 +2098,9 @@ isert_rdma_rw_ctx_post(struct isert_cmd u32 rkey, offset; int ret; + if (cmd->ctx_init_done) + goto rdma_ctx_post; + if (dir == DMA_FROM_DEVICE) { addr = cmd->write_va; rkey = cmd->write_stag; @@ -2125,11 +2128,15 @@ isert_rdma_rw_ctx_post(struct isert_cmd se_cmd->t_data_sg, se_cmd->t_data_nents, offset, addr, rkey, dir); } + if (ret < 0) { isert_err("Cmd: %p failed to prepare RDMA res\n", cmd); return ret; } + cmd->ctx_init_done = true; + +rdma_ctx_post: ret = rdma_rw_ctx_post(&cmd->rw, conn->qp, port_num, cqe, chain_wr); if (ret < 0) isert_err("Cmd: %p failed to post RDMA res\n", cmd); --- a/drivers/infiniband/ulp/isert/ib_isert.h +++ b/drivers/infiniband/ulp/isert/ib_isert.h @@ -124,6 +124,7 @@ struct isert_cmd { struct rdma_rw_ctx rw; struct work_struct comp_work; struct scatterlist sg; + bool ctx_init_done; }; static inline struct isert_cmd *tx_desc_to_cmd(struct iser_tx_desc *desc) Patches currently in stable-queue which might be from bharat(a)chelsio.com are queue-4.9/iser-target-avoid-reinitializing-rdma-contexts-for-isert-commands.patch

7 years, 3 months

1
0
0 0

Patch "irqchip/mips-gic: Separate IPI reservation & usage tracking" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled irqchip/mips-gic: Separate IPI reservation & usage tracking to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Paul Burton <paul.burton(a)imgtec.com> Date: Thu, 20 Apr 2017 10:07:34 +0100 Subject: irqchip/mips-gic: Separate IPI reservation & usage tracking From: Paul Burton <paul.burton(a)imgtec.com> [ Upstream commit f8dcd9e81797ae24acc44c84f0eb3b9e6cee9791 ] Since commit 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") introduced the GIC IPI IRQ domain we have tracked both reservation of interrupts & their use with a single bitmap - ipi_resrv. If an interrupt is reserved for use as an IPI but not actually in use then the appropriate bit is set in ipi_resrv. If an interrupt is either not reserved for use as an IPI or has been allocated as one then the appropriate bit is clear in ipi_resrv. Unfortunately this means that checking whether a bit is set in ipi_resrv to prevent IPI interrupts being allocated for use with a device is broken, because if the interrupt has been allocated as an IPI first then its bit will be clear. Fix this by separating the tracking of IPI reservation & usage, introducing a separate ipi_available bitmap for the latter. This means that ipi_resrv will now always have bits set corresponding to all interrupts reserved for use as IPIs, whether or not they have been allocated yet, and therefore that checking it when allocating device interrupts works as expected. Fixes: 2af70a962070 ("irqchip/mips-gic: Add a IPI hierarchy domain") Signed-off-by: Paul Burton <paul.burton(a)imgtec.com> Signed-off-by: Matt Redfearn <matt.redfearn(a)imgtec.com> Cc: linux-mips(a)linux-mips.org Cc: Jason Cooper <jason(a)lakedaemon.net> Cc: Marc Zyngier <marc.zyngier(a)arm.com> Cc: Ralf Baechle <ralf(a)linux-mips.org> Link: http://lkml.kernel.org/r/1492679256-14513-2-git-send-email-matt.redfearn@im… Signed-off-by: Thomas Gleixner <tglx(a)linutronix.de> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- drivers/irqchip/irq-mips-gic.c | 12 +++++++----- 1 file changed, 7 insertions(+), 5 deletions(-) --- a/drivers/irqchip/irq-mips-gic.c +++ b/drivers/irqchip/irq-mips-gic.c @@ -55,6 +55,7 @@ static unsigned int gic_cpu_pin; static unsigned int timer_cpu_pin; static struct irq_chip gic_level_irq_controller, gic_edge_irq_controller; DECLARE_BITMAP(ipi_resrv, GIC_MAX_INTRS); +DECLARE_BITMAP(ipi_available, GIC_MAX_INTRS); static void __gic_irq_dispatch(void); @@ -746,17 +747,17 @@ static int gic_irq_domain_alloc(struct i return gic_setup_dev_chip(d, virq, spec->hwirq); } else { - base_hwirq = find_first_bit(ipi_resrv, gic_shared_intrs); + base_hwirq = find_first_bit(ipi_available, gic_shared_intrs); if (base_hwirq == gic_shared_intrs) { return -ENOMEM; } /* check that we have enough space */ for (i = base_hwirq; i < nr_irqs; i++) { - if (!test_bit(i, ipi_resrv)) + if (!test_bit(i, ipi_available)) return -EBUSY; } - bitmap_clear(ipi_resrv, base_hwirq, nr_irqs); + bitmap_clear(ipi_available, base_hwirq, nr_irqs); /* map the hwirq for each cpu consecutively */ i = 0; @@ -787,7 +788,7 @@ static int gic_irq_domain_alloc(struct i return 0; error: - bitmap_set(ipi_resrv, base_hwirq, nr_irqs); + bitmap_set(ipi_available, base_hwirq, nr_irqs); return ret; } @@ -802,7 +803,7 @@ void gic_irq_domain_free(struct irq_doma return; base_hwirq = GIC_HWIRQ_TO_SHARED(irqd_to_hwirq(data)); - bitmap_set(ipi_resrv, base_hwirq, nr_irqs); + bitmap_set(ipi_available, base_hwirq, nr_irqs); } int gic_irq_domain_match(struct irq_domain *d, struct device_node *node, @@ -1066,6 +1067,7 @@ static void __init __gic_init(unsigned l 2 * gic_vpes); } + bitmap_copy(ipi_available, ipi_resrv, GIC_MAX_INTRS); gic_basic_init(); } Patches currently in stable-queue which might be from paul.burton(a)imgtec.com are queue-4.9/irqchip-mips-gic-separate-ipi-reservation-usage-tracking.patch

7 years, 3 months

1
0
0 0

Patch "ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled" has been added to the 4.9-stable tree

by gregkh＠linuxfoundation.org

This is a note to let you know that I've just added the patch titled ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled to the 4.9-stable tree which can be found at: http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=sum… The filename of the patch is: ipvs-explicitly-forbid-ipv6-service-dest-creation-if-ipv6-mod-is-disabled.patch and it can be found in the queue-4.9 subdirectory. If you, or anyone else, feels it should not be added to the stable tree, please let <stable(a)vger.kernel.org> know about it. >From foo@baz Thu Mar 22 14:40:23 CET 2018 From: Paolo Abeni <pabeni(a)redhat.com> Date: Thu, 20 Apr 2017 11:44:16 +0200 Subject: ipvs: explicitly forbid ipv6 service/dest creation if ipv6 mod is disabled From: Paolo Abeni <pabeni(a)redhat.com> [ Upstream commit 1442f6f7c1b77de1c508318164a527e240c24a4d ] When creating a new ipvs service, ipv6 addresses are always accepted if CONFIG_IP_VS_IPV6 is enabled. On dest creation the address family is not explicitly checked. This allows the user-space to configure ipvs services even if the system is booted with ipv6.disable=1. On specific configuration, ipvs can try to call ipv6 routing code at setup time, causing the kernel to oops due to fib6_rules_ops being NULL. This change addresses the issue adding a check for the ipv6 module being enabled while validating ipv6 service operations and adding the same validation for dest operations. According to git history, this issue is apparently present since the introduction of ipv6 support, and the oops can be triggered since commit 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local") Fixes: 09571c7ae30865ad ("IPVS: Add function to determine if IPv6 address is local") Signed-off-by: Paolo Abeni <pabeni(a)redhat.com> Acked-by: Julian Anastasov <ja(a)ssi.bg> Signed-off-by: Simon Horman <horms(a)verge.net.au> Signed-off-by: Sasha Levin <alexander.levin(a)microsoft.com> Signed-off-by: Greg Kroah-Hartman <gregkh(a)linuxfoundation.org> --- net/netfilter/ipvs/ip_vs_ctl.c | 22 +++++++++++++++++----- 1 file changed, 17 insertions(+), 5 deletions(-) --- a/net/netfilter/ipvs/ip_vs_ctl.c +++ b/net/netfilter/ipvs/ip_vs_ctl.c @@ -3092,6 +3092,17 @@ nla_put_failure: return skb->len; } +static bool ip_vs_is_af_valid(int af) +{ + if (af == AF_INET) + return true; +#ifdef CONFIG_IP_VS_IPV6 + if (af == AF_INET6 && ipv6_mod_enabled()) + return true; +#endif + return false; +} + static int ip_vs_genl_parse_service(struct netns_ipvs *ipvs, struct ip_vs_service_user_kern *usvc, struct nlattr *nla, int full_entry, @@ -3118,11 +3129,7 @@ static int ip_vs_genl_parse_service(stru memset(usvc, 0, sizeof(*usvc)); usvc->af = nla_get_u16(nla_af); -#ifdef CONFIG_IP_VS_IPV6 - if (usvc->af != AF_INET && usvc->af != AF_INET6) -#else - if (usvc->af != AF_INET) -#endif + if (!ip_vs_is_af_valid(usvc->af)) return -EAFNOSUPPORT; if (nla_fwmark) { @@ -3624,6 +3631,11 @@ static int ip_vs_genl_set_cmd(struct sk_ if (udest.af == 0) udest.af = svc->af; + if (!ip_vs_is_af_valid(udest.af)) { + ret = -EAFNOSUPPORT; + goto out; + } + if (udest.af != svc->af && cmd != IPVS_CMD_DEL_DEST) { /* The synchronization protocol is incompatible * with mixed family services Patches currently in stable-queue which might be from pabeni(a)redhat.com are queue-4.9/ipvs-explicitly-forbid-ipv6-service-dest-creation-if-ipv6-mod-is-disabled.patch

7 years, 3 months

1
0
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

Linux-stable-mirror