* [PATCH] net: phy: phy_led_triggers: Fix a possible null-pointer dereference in phy_led_trigger_change_speed()
From: Jia-Ju Bai @ 2019-07-29 9:24 UTC (permalink / raw)
To: andrew, f.fainelli, hkallweit1, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In phy_led_trigger_change_speed(), there is an if statement on line 48
to check whether phy->last_triggered is NULL:
if (!phy->last_triggered)
When phy->last_triggered is NULL, it is used on line 52:
led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
Thus, a possible null-pointer dereference may occur.
To fix this bug, led_trigger_event(&phy->last_triggered->trigger,
LED_OFF) is called when phy->last_triggered is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/phy/phy_led_triggers.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/net/phy/phy_led_triggers.c b/drivers/net/phy/phy_led_triggers.c
index b86a4b2116f8..59a94e07e7c5 100644
--- a/drivers/net/phy/phy_led_triggers.c
+++ b/drivers/net/phy/phy_led_triggers.c
@@ -48,8 +48,9 @@ void phy_led_trigger_change_speed(struct phy_device *phy)
if (!phy->last_triggered)
led_trigger_event(&phy->led_link_trigger->trigger,
LED_FULL);
+ else
+ led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
- led_trigger_event(&phy->last_triggered->trigger, LED_OFF);
led_trigger_event(&plt->trigger, LED_FULL);
phy->last_triggered = plt;
}
--
2.17.0
^ permalink raw reply related
* RE: [PATCH net-next 08/11] net: hns3: add interrupt affinity support for misc interrupt
From: Salil Mehta @ 2019-07-29 9:18 UTC (permalink / raw)
To: tanhuazhong, davem@davemloft.net
Cc: netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
Zhuangyuzeng (Yisen), Linuxarm, linyunsheng, lipeng (Y)
In-Reply-To: <1563938327-9865-9-git-send-email-tanhuazhong@huawei.com>
> From: tanhuazhong
> Sent: Wednesday, July 24, 2019 4:19 AM
> To: davem@davemloft.net
> Cc: netdev@vger.kernel.org; linux-kernel@vger.kernel.org; Salil Mehta
> <salil.mehta@huawei.com>; Zhuangyuzeng (Yisen) <yisen.zhuang@huawei.com>;
> Linuxarm <linuxarm@huawei.com>; linyunsheng <linyunsheng@huawei.com>; lipeng
> (Y) <lipeng321@huawei.com>; tanhuazhong <tanhuazhong@huawei.com>
> Subject: [PATCH net-next 08/11] net: hns3: add interrupt affinity support for
> misc interrupt
>
> From: Yunsheng Lin <linyunsheng@huawei.com>
>
> The misc interrupt is used to schedule the reset and mailbox
> subtask, and a 1 sec timer is used to schedule the service
> subtask, which does periodic work.
>
> This patch sets the above three subtask's affinity using the
> misc interrupt' affinity.
>
> Also this patch setups a affinity notify for misc interrupt to
> allow user to change the above three subtask's affinity.
>
> Signed-off-by: Yunsheng Lin <linyunsheng@huawei.com>
> Signed-off-by: Peng Li <lipeng321@huawei.com>
> Signed-off-by: Huazhong Tan <tanhuazhong@huawei.com>
> ---
> .../ethernet/hisilicon/hns3/hns3pf/hclge_main.c | 59
> ++++++++++++++++++++--
> .../ethernet/hisilicon/hns3/hns3pf/hclge_main.h | 4 ++
> 2 files changed, 59 insertions(+), 4 deletions(-)
>
> diff --git a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> index f345095..fe45986 100644
> --- a/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> +++ b/drivers/net/ethernet/hisilicon/hns3/hns3pf/hclge_main.c
> @@ -1270,6 +1270,12 @@ static int hclge_configure(struct hclge_dev *hdev)
>
> hclge_init_kdump_kernel_config(hdev);
>
> + /* Set the init affinity based on pci func number */
> + i = cpumask_weight(cpumask_of_node(dev_to_node(&hdev->pdev->dev)));
> + i = i ? PCI_FUNC(hdev->pdev->devfn) % i : 0;
> + cpumask_set_cpu(cpumask_local_spread(i, dev_to_node(&hdev->pdev->dev)),
> + &hdev->affinity_mask);
> +
> return ret;
> }
>
> @@ -2502,14 +2508,16 @@ static void hclge_mbx_task_schedule(struct hclge_dev
> *hdev)
> {
> if (!test_bit(HCLGE_STATE_CMD_DISABLE, &hdev->state) &&
> !test_and_set_bit(HCLGE_STATE_MBX_SERVICE_SCHED, &hdev->state))
> - schedule_work(&hdev->mbx_service_task);
> + queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
Why we have to use system Work Queue here? This could adversely affect
other work scheduled not related to the HNS3 driver. Mailbox is internal
to the driver and depending upon utilization of the mbx channel(which could
be heavy if many VMs are running), this might stress other system tasks
as well. Have we thought of this?
> + &hdev->mbx_service_task);
> }
>
> static void hclge_reset_task_schedule(struct hclge_dev *hdev)
> {
> if (!test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
> !test_and_set_bit(HCLGE_STATE_RST_SERVICE_SCHED, &hdev->state))
> - schedule_work(&hdev->rst_service_task);
> + queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
> + &hdev->rst_service_task);
> }
>
> static void hclge_task_schedule(struct hclge_dev *hdev)
> @@ -2517,7 +2525,8 @@ static void hclge_task_schedule(struct hclge_dev *hdev)
> if (!test_bit(HCLGE_STATE_DOWN, &hdev->state) &&
> !test_bit(HCLGE_STATE_REMOVING, &hdev->state) &&
> !test_and_set_bit(HCLGE_STATE_SERVICE_SCHED, &hdev->state))
> - (void)schedule_work(&hdev->service_task);
> + queue_work_on(cpumask_first(&hdev->affinity_mask), system_wq,
Same here.
Salil.
^ permalink raw reply
* [PATCH] net: ag71xx: use resource_size for the ioremap size
From: Ding Xiang @ 2019-07-29 9:01 UTC (permalink / raw)
To: jcliburn, chris.snook, davem; +Cc: netdev, linux-kernel
use resource_size to calcuate ioremap size and make
the code simpler.
Signed-off-by: Ding Xiang <dingxiang@cmss.chinamobile.com>
---
drivers/net/ethernet/atheros/ag71xx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/ethernet/atheros/ag71xx.c b/drivers/net/ethernet/atheros/ag71xx.c
index 8b69d0d..77542bd 100644
--- a/drivers/net/ethernet/atheros/ag71xx.c
+++ b/drivers/net/ethernet/atheros/ag71xx.c
@@ -1686,7 +1686,7 @@ static int ag71xx_probe(struct platform_device *pdev)
}
ag->mac_base = devm_ioremap_nocache(&pdev->dev, res->start,
- res->end - res->start + 1);
+ resource_size(res));
if (!ag->mac_base) {
err = -ENOMEM;
goto err_free;
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v3] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 8:42 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729082433.28981-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 10:24:33AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM")
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
^ permalink raw reply
* [PATCH] isdn: hfcsusb: Fix mISDN driver crash caused by transfer buffer on the stack
From: Juliana Rodrigueiro @ 2019-07-29 8:20 UTC (permalink / raw)
To: isdn, netdev
Since linux 4.9 it is not possible to use buffers on the stack for DMA transfers.
During usb probe the driver crashes with "transfer buffer is on stack" message.
This fix k-allocates a buffer to be used on "read_reg_atomic", which is a macro
that calls "usb_control_msg" under the hood.
Kernel 4.19 backtrace:
usb_hcd_submit_urb+0x3e5/0x900
? sched_clock+0x9/0x10
? log_store+0x203/0x270
? get_random_u32+0x6f/0x90
? cache_alloc_refill+0x784/0x8a0
usb_submit_urb+0x3b4/0x550
usb_start_wait_urb+0x4e/0xd0
usb_control_msg+0xb8/0x120
hfcsusb_probe+0x6bc/0xb40 [hfcsusb]
usb_probe_interface+0xc2/0x260
really_probe+0x176/0x280
driver_probe_device+0x49/0x130
__driver_attach+0xa9/0xb0
? driver_probe_device+0x130/0x130
bus_for_each_dev+0x5a/0x90
driver_attach+0x14/0x20
? driver_probe_device+0x130/0x130
bus_add_driver+0x157/0x1e0
driver_register+0x51/0xe0
usb_register_driver+0x5d/0x120
? 0xf81ed000
hfcsusb_drv_init+0x17/0x1000 [hfcsusb]
do_one_initcall+0x44/0x190
? free_unref_page_commit+0x6a/0xd0
do_init_module+0x46/0x1c0
load_module+0x1dc1/0x2400
sys_init_module+0xed/0x120
do_fast_syscall_32+0x7a/0x200
entry_SYSENTER_32+0x6b/0xbe
Signed-off-by: Juliana Rodrigueiro <juliana.rodrigueiro@intra2net.com>
---
drivers/isdn/hardware/mISDN/hfcsusb.c | 12 +++++++++++-
1 file changed, 11 insertions(+), 1 deletion(-)
diff --git a/drivers/isdn/hardware/mISDN/hfcsusb.c b/drivers/isdn/hardware/mISDN/hfcsusb.c
index 6d05946b445e..02006fdce67f 100644
--- a/drivers/isdn/hardware/mISDN/hfcsusb.c
+++ b/drivers/isdn/hardware/mISDN/hfcsusb.c
@@ -1705,12 +1705,22 @@ static int
setup_hfcsusb(struct hfcsusb *hw)
{
u_char b;
+ int ret;
+ void *dmabuf = kmalloc(sizeof(u_char), GFP_KERNEL);
if (debug & DBG_HFC_CALL_TRACE)
printk(KERN_DEBUG "%s: %s\n", hw->name, __func__);
+ if (!dmabuf)
+ return -ENOMEM;
+
+ ret = read_reg_atomic(hw, HFCUSB_CHIP_ID, dmabuf);
+
+ memcpy(&b, dmabuf, sizeof(u_char));
+ kfree(dmabuf);
+
/* check the chip id */
- if (read_reg_atomic(hw, HFCUSB_CHIP_ID, &b) != 1) {
+ if (ret != 1) {
printk(KERN_DEBUG "%s: %s: cannot read chip id\n",
hw->name, __func__);
return 1;
--
2.20.1
^ permalink raw reply related
* Re: [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 8:25 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729081854.GC2211@nanopsycho>
On 2019/7/29 16:18, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 10:00:18AM CEST, baijiaju1990@gmail.com wrote:
>> In dequeue_func(), there is an if statement on line 74 to check whether
>> skb is NULL:
>> if (skb)
>>
>> When skb is NULL, it is used on line 77:
>> prefetch(&skb->end);
>>
>> Thus, a possible null-pointer dereference may occur.
>>
>> To fix this bug, skb->end is used when skb is not NULL.
>>
>> This bug is found by a static analysis tool STCheck written by us.
>>
>> Fixes: 79bdc4c862af ("codel: generalize the implementation")
> Looks like this is something being there since the beginning:
> commit 76e3cc126bb223013a6b9a0e2a51238d1ef2e409
> Author: Eric Dumazet <edumazet@google.com>
> Date: Thu May 10 07:51:25 2012 +0000
>
> codel: Controlled Delay AQM
>
>
> Please adjust "Fixes:".
Thanks for the advice :)
I have sent a v3 patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [PATCH v3] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 8:24 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In dequeue_func(), there is an if statement on line 74 to check whether
skb is NULL:
if (skb)
When skb is NULL, it is used on line 77:
prefetch(&skb->end);
Thus, a possible null-pointer dereference may occur.
To fix this bug, skb->end is used when skb is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Fixes: 76e3cc126bb2 ("codel: Controlled Delay AQM")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
v2:
* Add a fix tag.
Thank Jiri Pirko for helpful advice.
v3:
* Use a correct fix tag.
Thank Jiri Pirko for helpful advice.
---
net/sched/sch_codel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
index 25ef172c23df..30169b3adbbb 100644
--- a/net/sched/sch_codel.c
+++ b/net/sched/sch_codel.c
@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
struct Qdisc *sch = ctx;
struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
- if (skb)
+ if (skb) {
sch->qstats.backlog -= qdisc_pkt_len(skb);
-
- prefetch(&skb->end); /* we'll need skb_shinfo() */
+ prefetch(&skb->end); /* we'll need skb_shinfo() */
+ }
return skb;
}
--
2.17.0
^ permalink raw reply related
* [PATCH] mac80211_hwsim: Fix possible null-pointer dereferences in hwsim_dump_radio_nl()
From: Jia-Ju Bai @ 2019-07-29 8:23 UTC (permalink / raw)
To: johannes, kvalo, davem; +Cc: linux-wireless, netdev, linux-kernel, Jia-Ju Bai
In hwsim_dump_radio_nl(), when genlmsg_put() on line 3617 fails, hdr is
assigned to NULL. Then hdr is used on lines 3622 and 3623:
genl_dump_check_consistent(cb, hdr);
genlmsg_end(skb, hdr);
Thus, possible null-pointer dereferences may occur.
To fix these bugs, hdr is used here when it is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
drivers/net/wireless/mac80211_hwsim.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/wireless/mac80211_hwsim.c b/drivers/net/wireless/mac80211_hwsim.c
index 519b4ee88c5c..61a8b6429e09 100644
--- a/drivers/net/wireless/mac80211_hwsim.c
+++ b/drivers/net/wireless/mac80211_hwsim.c
@@ -3617,10 +3617,11 @@ static int hwsim_dump_radio_nl(struct sk_buff *skb,
hdr = genlmsg_put(skb, NETLINK_CB(cb->skb).portid,
cb->nlh->nlmsg_seq, &hwsim_genl_family,
NLM_F_MULTI, HWSIM_CMD_GET_RADIO);
- if (!hdr)
+ if (hdr) {
+ genl_dump_check_consistent(cb, hdr);
+ genlmsg_end(skb, hdr);
+ } else
res = -EMSGSIZE;
- genl_dump_check_consistent(cb, hdr);
- genlmsg_end(skb, hdr);
}
done:
--
2.17.0
^ permalink raw reply related
* Re: [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 8:18 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729080018.28678-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 10:00:18AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Fixes: 79bdc4c862af ("codel: generalize the implementation")
Looks like this is something being there since the beginning:
commit 76e3cc126bb223013a6b9a0e2a51238d1ef2e409
Author: Eric Dumazet <edumazet@google.com>
Date: Thu May 10 07:51:25 2012 +0000
codel: Controlled Delay AQM
Please adjust "Fixes:".
The fix itself looks fine to me.
Reviewed-by: Jiri Pirko <jiri@mellanox.com>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>---
>v2:
>* Add a fix tag.
> Thank Jiri Pirko for helpful advice.
>
>---
> net/sched/sch_codel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
>index 25ef172c23df..30169b3adbbb 100644
>--- a/net/sched/sch_codel.c
>+++ b/net/sched/sch_codel.c
>@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
> struct Qdisc *sch = ctx;
> struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
>
>- if (skb)
>+ if (skb) {
> sch->qstats.backlog -= qdisc_pkt_len(skb);
>-
>- prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ }
> return skb;
> }
>
>--
>2.17.0
>
^ permalink raw reply
* RE: [PATCH net-next 3/3] net: stmmac: Introducing support for Page Pool
From: Jose Abreu @ 2019-07-29 8:16 UTC (permalink / raw)
To: Jon Hunter, Jose Abreu, linux-kernel@vger.kernel.org,
netdev@vger.kernel.org, linux-stm32@st-md-mailman.stormreply.com,
linux-arm-kernel@lists.infradead.org
Cc: Joao Pinto, Alexandre Torgue, Maxime Ripard, Chen-Yu Tsai,
Maxime Coquelin, linux-tegra, Giuseppe Cavallaro, Robin Murphy,
David S . Miller
In-Reply-To: <BYAPR12MB326922CDCB1D4B3D4A780CFDD3C30@BYAPR12MB3269.namprd12.prod.outlook.com>
[-- Attachment #1: Type: text/plain, Size: 1700 bytes --]
From: Jose Abreu <joabreu@synopsys.com>
Date: Jul/27/2019, 16:56:37 (UTC+00:00)
> From: Jon Hunter <jonathanh@nvidia.com>
> Date: Jul/26/2019, 15:11:00 (UTC+00:00)
>
> >
> > On 25/07/2019 16:12, Jose Abreu wrote:
> > > From: Jon Hunter <jonathanh@nvidia.com>
> > > Date: Jul/25/2019, 15:25:59 (UTC+00:00)
> > >
> > >>
> > >> On 25/07/2019 14:26, Jose Abreu wrote:
> > >>
> > >> ...
> > >>
> > >>> Well, I wasn't expecting that :/
> > >>>
> > >>> Per documentation of barriers I think we should set descriptor fields
> > >>> and then barrier and finally ownership to HW so that remaining fields
> > >>> are coherent before owner is set.
> > >>>
> > >>> Anyway, can you also add a dma_rmb() after the call to
> > >>> stmmac_rx_status() ?
> > >>
> > >> Yes. I removed the debug print added the barrier, but that did not help.
> > >
> > > So, I was finally able to setup NFS using your replicated setup and I
> > > can't see the issue :(
> > >
> > > The only difference I have from yours is that I'm using TCP in NFS
> > > whilst you (I believe from the logs), use UDP.
> >
> > So I tried TCP by setting the kernel boot params to 'nfsvers=3' and
> > 'proto=tcp' and this does appear to be more stable, but not 100% stable.
> > It still appears to fail in the same place about 50% of the time.
> >
> > > You do have flow control active right ? And your HW FIFO size is >= 4k ?
> >
> > How can I verify if flow control is active?
>
> You can check it by dumping register MTL_RxQ_Operation_Mode (0xd30).
>
> Can you also add IOMMU debug in file "drivers/iommu/iommu.c" ?
And, please try attached debug patch.
---
Thanks,
Jose Miguel Abreu
[-- Attachment #2: 0001-net-page_pool-Do-not-skip-CPU-sync.patch --]
[-- Type: application/octet-stream, Size: 1532 bytes --]
From d203a4f055a36ae20efbcee7cdf70ce13fff12c9 Mon Sep 17 00:00:00 2001
Message-Id: <d203a4f055a36ae20efbcee7cdf70ce13fff12c9.1564388075.git.joabreu@synopsys.com>
From: Jose Abreu <joabreu@synopsys.com>
Date: Mon, 29 Jul 2019 10:14:21 +0200
Subject: [PATCH net] net: page_pool: Do not skip CPU sync
Signed-off-by: Jose Abreu <joabreu@synopsys.com>
---
Cc: Jesper Dangaard Brouer <hawk@kernel.org>
Cc: Ilias Apalodimas <ilias.apalodimas@linaro.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
net/core/page_pool.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/core/page_pool.c b/net/core/page_pool.c
index 3272dc7a8c81..0262fcdf217e 100644
--- a/net/core/page_pool.c
+++ b/net/core/page_pool.c
@@ -156,7 +156,7 @@ static struct page *__page_pool_alloc_pages_slow(struct page_pool *pool,
*/
dma = dma_map_page_attrs(pool->p.dev, page, 0,
(PAGE_SIZE << pool->p.order),
- pool->p.dma_dir, DMA_ATTR_SKIP_CPU_SYNC);
+ pool->p.dma_dir, 0);
if (dma_mapping_error(pool->p.dev, dma)) {
put_page(page);
return NULL;
@@ -230,8 +230,7 @@ static void __page_pool_clean_page(struct page_pool *pool,
dma = page->dma_addr;
/* DMA unmap */
dma_unmap_page_attrs(pool->p.dev, dma,
- PAGE_SIZE << pool->p.order, pool->p.dma_dir,
- DMA_ATTR_SKIP_CPU_SYNC);
+ PAGE_SIZE << pool->p.order, pool->p.dma_dir, 0);
page->dma_addr = 0;
skip_dma_unmap:
atomic_inc(&pool->pages_state_release_cnt);
--
2.7.4
^ permalink raw reply related
* Re: memory leak in __nf_hook_entries_try_shrink
From: syzbot @ 2019-07-29 8:16 UTC (permalink / raw)
To: catalin.marinas, coreteam, davem, deller, fw, jejb, kadlec,
linux-kernel, linux-mm, linux-parisc, mingo, netdev,
netfilter-devel, pablo, rostedt, syzkaller-bugs
In-Reply-To: <0000000000005718ef058b3a0fcf@google.com>
syzbot has bisected this bug to:
commit fc79168a7c75423047d60a033dc4844955ccae0b
Author: Helge Deller <deller@gmx.de>
Date: Wed Apr 13 20:44:54 2016 +0000
parisc: Add syscall tracepoint support
bisection log: https://syzkaller.appspot.com/x/bisect.txt?x=16ad2cd8600000
start commit: b076173a Merge tag 'selinux-pr-20190612' of git://git.kern..
git tree: upstream
final crash: https://syzkaller.appspot.com/x/report.txt?x=15ad2cd8600000
console output: https://syzkaller.appspot.com/x/log.txt?x=11ad2cd8600000
kernel config: https://syzkaller.appspot.com/x/.config?x=cb38d33cd06d8d48
dashboard link: https://syzkaller.appspot.com/bug?extid=c51f73e78e7e2ce3a31e
syz repro: https://syzkaller.appspot.com/x/repro.syz?x=105a958ea00000
C reproducer: https://syzkaller.appspot.com/x/repro.c?x=103c758ea00000
Reported-by: syzbot+c51f73e78e7e2ce3a31e@syzkaller.appspotmail.com
Fixes: fc79168a7c75 ("parisc: Add syscall tracepoint support")
For information about bisection process see: https://goo.gl/tpsmEJ#bisection
^ permalink raw reply
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Jia-Ju Bai @ 2019-07-29 8:06 UTC (permalink / raw)
To: Steffen Klassert; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <20190729080341.GJ2879@gauss3.secunet.de>
On 2019/7/29 16:03, Steffen Klassert wrote:
> On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
>> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
>> NULL.
> We don't have a xfrm_policy() function, and as said already the
> line numbers does not help much as long as you don't say which
> tree/branch this is and which commit is the head commit.
>
>> Then, dst->xfrm is used on line 3840:
>> xfrm_state_mtu(dst->xfrm, mtu);
>> if (x->km.state != XFRM_STATE_VALID...)
>> aead = x->data;
>>
>> Thus, possible null-pointer dereferences may occur.
> I guess you refer to xfrm_bundle_ok(). The dst pointer
> is reoaded after the loop, so the dereferenced pointer
> is not the one that had NULL at dst->xfrm.
>
>> These bugs are found by a static analysis tool STCheck written by us.
>>
>> I do not know how to correctly fix these bugs, so I only report them.
> I'd suggest you to manually review the reports of your
> tool and to fix the tool accordingly.
Oh, sorry for my mistakes.
I have found that dst is updated:
dst = &xdst->u.dst;
I will fix my tool, thanks.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [BUG] net: xfrm: possible null-pointer dereferences in xfrm_policy()
From: Steffen Klassert @ 2019-07-29 8:03 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: herbert, davem, netdev, linux-kernel
In-Reply-To: <464bb93d-75b2-c21b-ee32-25a10ff61622@gmail.com>
On Mon, Jul 29, 2019 at 11:43:49AM +0800, Jia-Ju Bai wrote:
> In xfrm_policy(), the while loop on lines 3802-3830 ends when dst->xfrm is
> NULL.
We don't have a xfrm_policy() function, and as said already the
line numbers does not help much as long as you don't say which
tree/branch this is and which commit is the head commit.
> Then, dst->xfrm is used on line 3840:
> xfrm_state_mtu(dst->xfrm, mtu);
> if (x->km.state != XFRM_STATE_VALID...)
> aead = x->data;
>
> Thus, possible null-pointer dereferences may occur.
I guess you refer to xfrm_bundle_ok(). The dst pointer
is reoaded after the loop, so the dereferenced pointer
is not the one that had NULL at dst->xfrm.
>
> These bugs are found by a static analysis tool STCheck written by us.
>
> I do not know how to correctly fix these bugs, so I only report them.
I'd suggest you to manually review the reports of your
tool and to fix the tool accordingly.
^ permalink raw reply
* [PATCH v2] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 8:00 UTC (permalink / raw)
To: jhs, xiyou.wangcong, jiri, davem; +Cc: netdev, linux-kernel, Jia-Ju Bai
In dequeue_func(), there is an if statement on line 74 to check whether
skb is NULL:
if (skb)
When skb is NULL, it is used on line 77:
prefetch(&skb->end);
Thus, a possible null-pointer dereference may occur.
To fix this bug, skb->end is used when skb is not NULL.
This bug is found by a static analysis tool STCheck written by us.
Fixes: 79bdc4c862af ("codel: generalize the implementation")
Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
---
v2:
* Add a fix tag.
Thank Jiri Pirko for helpful advice.
---
net/sched/sch_codel.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
index 25ef172c23df..30169b3adbbb 100644
--- a/net/sched/sch_codel.c
+++ b/net/sched/sch_codel.c
@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
struct Qdisc *sch = ctx;
struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
- if (skb)
+ if (skb) {
sch->qstats.backlog -= qdisc_pkt_len(skb);
-
- prefetch(&skb->end); /* we'll need skb_shinfo() */
+ prefetch(&skb->end); /* we'll need skb_shinfo() */
+ }
return skb;
}
--
2.17.0
^ permalink raw reply related
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:59 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729074125.GB2211@nanopsycho>
On 2019/7/29 15:41, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 09:32:00AM CEST, baijiaju1990@gmail.com wrote:
>>
>> On 2019/7/29 14:56, Jiri Pirko wrote:
>>> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>>>> In dequeue_func(), there is an if statement on line 74 to check whether
>>>> skb is NULL:
>>>> if (skb)
>>>>
>>>> When skb is NULL, it is used on line 77:
>>>> prefetch(&skb->end);
>>>>
>>>> Thus, a possible null-pointer dereference may occur.
>>>>
>>>> To fix this bug, skb->end is used when skb is not NULL.
>>>>
>>>> This bug is found by a static analysis tool STCheck written by us.
>>>>
>>>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>>> Fixes tag, please?
>> Sorry, I do not know what "fixes tag" means...
>> I just find a possible bug and fix it in this patch.
> git log |grep Fixes:
>
> If A fix goes to -net tree, it most probably fixes some bug introduced
> by some commit in the past. So this tag is to put a reference.
Thanks for the explanation.
I will add it and submit a v2 patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* [PATCH net-next 1/1] qed[net-next] Add new ethtool supported port types based on media.
From: Rahul Verma @ 2019-07-29 7:49 UTC (permalink / raw)
To: davem; +Cc: netdev, aelior, mkalderon
Supported ports in ethtool <eth1> are displayed based on media type.
For media type fibre and twinaxial, port type is "FIBRE". Media type
Base-T is "TP" and media KR is "Backplane".
Signed-off-by: Rahul Verma <rahulv@marvell.com>
Signed-off-by: Michal Kalderon <michal.kalderon@marvell.com>
---
drivers/net/ethernet/qlogic/qed/qed_main.c | 6 +++++-
drivers/net/ethernet/qlogic/qede/qede_ethtool.c | 3 ++-
include/linux/qed/qed_if.h | 2 +-
3 files changed, 8 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_main.c b/drivers/net/ethernet/qlogic/qed/qed_main.c
index 829dd60..e5ac8bd 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_main.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_main.c
@@ -1688,6 +1688,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
switch (media_type) {
case MEDIA_DA_TWINAX:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
/* For DAC media multiple speed capabilities are supported*/
@@ -1707,6 +1708,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
*if_capability |= QED_LM_100000baseCR4_Full_BIT;
break;
case MEDIA_BASE_T:
+ *if_capability |= QED_LM_TP_BIT;
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_EXT_PHY) {
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
@@ -1718,6 +1720,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
}
}
if (board_cfg & NVM_CFG1_PORT_PORT_TYPE_MODULE) {
+ *if_capability |= QED_LM_FIBRE_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_1000BASET)
*if_capability |= QED_LM_1000baseT_Full_BIT;
if (tcvr_type == ETH_TRANSCEIVER_TYPE_10G_BASET)
@@ -1728,6 +1731,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
case MEDIA_SFPP_10G_FIBER:
case MEDIA_XFP_FIBER:
case MEDIA_MODULE_FIBER:
+ *if_capability |= QED_LM_FIBRE_BIT;
if (capability &
NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_1G) {
if ((tcvr_type == ETH_TRANSCEIVER_TYPE_1G_LX) ||
@@ -1770,6 +1774,7 @@ static void qed_fill_link_capability(struct qed_hwfn *hwfn,
break;
case MEDIA_KR:
+ *if_capability |= QED_LM_Backplane_BIT;
if (capability & NVM_CFG1_PORT_DRV_SPEED_CAPABILITY_MASK_20G)
*if_capability |= QED_LM_20000baseKR2_Full_BIT;
if (capability &
@@ -1821,7 +1826,6 @@ static void qed_fill_link(struct qed_hwfn *hwfn,
if_link->link_up = true;
/* TODO - at the moment assume supported and advertised speed equal */
- if_link->supported_caps = QED_LM_FIBRE_BIT;
if (link_caps.default_speed_autoneg)
if_link->supported_caps |= QED_LM_Autoneg_BIT;
if (params.pause.autoneg ||
diff --git a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
index e85f9fe..abcee47 100644
--- a/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
+++ b/drivers/net/ethernet/qlogic/qede/qede_ethtool.c
@@ -424,12 +424,13 @@ struct qede_link_mode_mapping {
};
static const struct qede_link_mode_mapping qed_lm_map[] = {
+ {QED_LM_FIBRE_BIT, ETHTOOL_LINK_MODE_FIBRE_BIT},
{QED_LM_Autoneg_BIT, ETHTOOL_LINK_MODE_Autoneg_BIT},
{QED_LM_Asym_Pause_BIT, ETHTOOL_LINK_MODE_Asym_Pause_BIT},
{QED_LM_Pause_BIT, ETHTOOL_LINK_MODE_Pause_BIT},
{QED_LM_1000baseT_Full_BIT, ETHTOOL_LINK_MODE_1000baseT_Full_BIT},
{QED_LM_10000baseT_Full_BIT, ETHTOOL_LINK_MODE_10000baseT_Full_BIT},
- {QED_LM_2500baseX_Full_BIT, ETHTOOL_LINK_MODE_2500baseX_Full_BIT},
+ {QED_LM_TP_BIT, ETHTOOL_LINK_MODE_TP_BIT},
{QED_LM_Backplane_BIT, ETHTOOL_LINK_MODE_Backplane_BIT},
{QED_LM_1000baseKX_Full_BIT, ETHTOOL_LINK_MODE_1000baseKX_Full_BIT},
{QED_LM_10000baseKX4_Full_BIT, ETHTOOL_LINK_MODE_10000baseKX4_Full_BIT},
diff --git a/include/linux/qed/qed_if.h b/include/linux/qed/qed_if.h
index eef02e6..2302136 100644
--- a/include/linux/qed/qed_if.h
+++ b/include/linux/qed/qed_if.h
@@ -689,7 +689,7 @@ enum qed_link_mode_bits {
QED_LM_40000baseLR4_Full_BIT = BIT(9),
QED_LM_50000baseKR2_Full_BIT = BIT(10),
QED_LM_100000baseKR4_Full_BIT = BIT(11),
- QED_LM_2500baseX_Full_BIT = BIT(12),
+ QED_LM_TP_BIT = BIT(12),
QED_LM_Backplane_BIT = BIT(13),
QED_LM_1000baseKX_Full_BIT = BIT(14),
QED_LM_10000baseKX4_Full_BIT = BIT(15),
--
1.8.3.1
^ permalink raw reply related
* [PATCH iproute2-rc 2/2] rdma: Document adaptive-moderation
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
Add document of setting the adaptive-moderation for the ib device.
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
man/man8/rdma-dev.8 | 16 +++++++++++++++-
1 file changed, 15 insertions(+), 1 deletion(-)
diff --git a/man/man8/rdma-dev.8 b/man/man8/rdma-dev.8
index e77e7cd0..368cdc7c 100644
--- a/man/man8/rdma-dev.8
+++ b/man/man8/rdma-dev.8
@@ -34,11 +34,17 @@ rdma-dev \- RDMA device configuration
.BR netns
.BR NSNAME
+.ti -8
+.B rdma dev set
+.RI "[ " DEV " ]"
+.BR adaptive-moderation
+.BR [on/off]
+
.ti -8
.B rdma dev help
.SH "DESCRIPTION"
-.SS rdma dev set - rename RDMA device or set network namespace
+.SS rdma dev set - rename RDMA device or set network namespace or set RDMA device adaptive-moderation
.SS rdma dev show - display RDMA device attributes
@@ -70,6 +76,14 @@ Changes the network namespace of RDMA device to foo where foo is
previously created using iproute2 ip command.
.RE
.PP
+rdma dev set mlx5_3 adaptive-moderation [on/off]
+.RS 4
+Sets the state of adaptive interrupt moderation for the RDMA device.
+.RE
+.RS 4
+This is a global setting for the RDMA device but the value is printed for each CQ individually because the state is constant from CQ allocation.
+.RE
+.PP
.SH SEE ALSO
.BR ip (8),
--
2.20.1
^ permalink raw reply related
* [PATCH iproute2-rc 1/2] rdma: Control CQ adaptive moderation (DIM)
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
In-Reply-To: <20190729074226.4335-1-leon@kernel.org>
From: Yamin Friedman <yaminf@mellanox.com>
In order to set adaptive-moderation for an ib device the command is:
rdma dev set [DEV] adaptive-moderation [on|off]
rdma dev show -d
0: mlx5_0: node_type ca fw 16.25.0319 node_guid 248a:0703:00a5:29d0
sys_image_guid 248a:0703:00a5:29d0 adaptive-moderation on
caps: <BAD_PKEY_CNTR, BAD_QKEY_CNTR, AUTO_PATH_MIG, CHANGE_PHY_PORT,
PORT_ACTIVE_EVENT, SYS_IMAGE_GUID, RC_RNR_NAK_GEN, MEM_WINDOW, XRC,
MEM_MGT_EXTENSIONS, BLOCK_MULTICAST_LOOPBACK, MEM_WINDOW_TYPE_2B,
RAW_IP_CSUM, CROSS_CHANNEL, MANAGED_FLOW_STEERING, SIGNATURE_HANDOVER,
ON_DEMAND_PAGING, SG_GAPS_REG, RAW_SCATTER_FCS, PCI_WRITE_END_PADDING>
rdma resource show cq
dev mlx5_0 cqn 0 cqe 1023 users 4 poll-ctx UNBOUND_WORKQUEUE
adaptive-moderation off comm [ib_core]
Signed-off-by: Yamin Friedman <yaminf@mellanox.com>
Signed-off-by: Leon Romanovsky <leonro@mellanox.com>
---
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 ++++++++++++++
rdma/utils.c | 6 ++++++
4 files changed, 76 insertions(+), 1 deletion(-)
diff --git a/rdma/dev.c b/rdma/dev.c
index d28bf6b3..c597cba5 100644
--- a/rdma/dev.c
+++ b/rdma/dev.c
@@ -12,6 +12,7 @@ static int dev_help(struct rd *rd)
pr_out("Usage: %s dev show [DEV]\n", rd->filename);
pr_out(" %s dev set [DEV] name DEVNAME\n", rd->filename);
pr_out(" %s dev set [DEV] netns NSNAME\n", rd->filename);
+ pr_out(" %s dev set [DEV] adaptive-moderation [on|off]\n", rd->filename);
return 0;
}
@@ -167,6 +168,21 @@ static void dev_print_sys_image_guid(struct rd *rd, struct nlattr **tb)
pr_out("sys_image_guid %s ", str);
}
+static void dev_print_dim_setting(struct rd *rd, struct nlattr **tb)
+{
+ uint8_t dim_setting;
+
+ if (!tb[RDMA_NLDEV_ATTR_DEV_DIM])
+ return;
+
+ dim_setting = mnl_attr_get_u8(tb[RDMA_NLDEV_ATTR_DEV_DIM]);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+
+}
+
static const char *node_type_to_str(uint8_t node_type)
{
static const char * const node_type_str[] = { "unknown", "ca",
@@ -219,8 +235,10 @@ static int dev_parse_cb(const struct nlmsghdr *nlh, void *data)
dev_print_fw(rd, tb);
dev_print_node_guid(rd, tb);
dev_print_sys_image_guid(rd, tb);
- if (rd->show_details)
+ if (rd->show_details) {
+ dev_print_dim_setting(rd, tb);
dev_print_caps(rd, tb);
+ }
if (!rd->json_output)
pr_out("\n");
@@ -308,12 +326,47 @@ done:
return ret;
}
+static int dev_set_dim_sendmsg(struct rd *rd, uint8_t dim_setting)
+{
+ uint32_t seq;
+
+ rd_prepare_msg(rd, RDMA_NLDEV_CMD_SET, &seq,
+ (NLM_F_REQUEST | NLM_F_ACK));
+ mnl_attr_put_u32(rd->nlh, RDMA_NLDEV_ATTR_DEV_INDEX, rd->dev_idx);
+ mnl_attr_put_u8(rd->nlh, RDMA_NLDEV_ATTR_DEV_DIM, dim_setting);
+
+ return rd_sendrecv_msg(rd, seq);
+}
+
+static int dev_set_dim_off(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 0);
+}
+
+static int dev_set_dim_on(struct rd *rd)
+{
+ return dev_set_dim_sendmsg(rd, 1);
+}
+
+static int dev_set_dim(struct rd *rd)
+{
+ const struct rd_cmd cmds[] = {
+ { NULL, dev_help},
+ { "on", dev_set_dim_on},
+ { "off", dev_set_dim_off},
+ { 0 }
+ };
+
+ return rd_exec_cmd(rd, cmds, "parameter");
+}
+
static int dev_one_set(struct rd *rd)
{
const struct rd_cmd cmds[] = {
{ NULL, dev_help},
{ "name", dev_set_name},
{ "netns", dev_set_netns},
+ { "adaptive-moderation", dev_set_dim},
{ 0 }
};
diff --git a/rdma/rdma.h b/rdma/rdma.h
index 23157743..dfd1b70b 100644
--- a/rdma/rdma.h
+++ b/rdma/rdma.h
@@ -136,6 +136,7 @@ int rd_attr_check(const struct nlattr *attr, int *typep);
void print_driver_table(struct rd *rd, struct nlattr *tb);
void newline(struct rd *rd);
void newline_indent(struct rd *rd);
+void print_on_off(struct rd *rd, const char *key_str, bool on);
#define MAX_LINE_LENGTH 80
#endif /* _RDMA_TOOL_H_ */
diff --git a/rdma/res-cq.c b/rdma/res-cq.c
index 5afb97c5..d2591fbe 100644
--- a/rdma/res-cq.c
+++ b/rdma/res-cq.c
@@ -30,6 +30,20 @@ static void print_poll_ctx(struct rd *rd, uint8_t poll_ctx, struct nlattr *attr)
pr_out("poll-ctx %s ", poll_ctx_to_str(poll_ctx));
}
+static void print_cq_dim_setting(struct rd *rd, struct nlattr *attr)
+{
+ uint8_t dim_setting;
+
+ if (!attr)
+ return;
+
+ dim_setting = mnl_attr_get_u8(attr);
+ if (dim_setting > 1)
+ return;
+
+ print_on_off(rd, "adaptive-moderation", dim_setting);
+}
+
static int res_cq_line(struct rd *rd, const char *name, int idx,
struct nlattr **nla_line)
{
@@ -97,6 +111,7 @@ static int res_cq_line(struct rd *rd, const char *name, int idx,
res_print_uint(rd, "users", users,
nla_line[RDMA_NLDEV_ATTR_RES_USECNT]);
print_poll_ctx(rd, poll_ctx, nla_line[RDMA_NLDEV_ATTR_RES_POLL_CTX]);
+ print_cq_dim_setting(rd, nla_line[RDMA_NLDEV_ATTR_DEV_DIM]);
res_print_uint(rd, "ctxn", ctxn, nla_line[RDMA_NLDEV_ATTR_RES_CTXN]);
res_print_uint(rd, "pid", pid, nla_line[RDMA_NLDEV_ATTR_RES_PID]);
print_comm(rd, comm, nla_line);
diff --git a/rdma/utils.c b/rdma/utils.c
index 95b669f3..37659011 100644
--- a/rdma/utils.c
+++ b/rdma/utils.c
@@ -449,6 +449,7 @@ static const enum mnl_attr_data_type nldev_policy[RDMA_NLDEV_ATTR_MAX] = {
[RDMA_NLDEV_ATTR_STAT_MODE] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_RES] = MNL_TYPE_U32,
[RDMA_NLDEV_ATTR_STAT_AUTO_MODE_MASK] = MNL_TYPE_U32,
+ [RDMA_NLDEV_ATTR_DEV_DIM] = MNL_TYPE_U8,
};
int rd_attr_check(const struct nlattr *attr, int *typep)
@@ -789,6 +790,11 @@ static int print_driver_string(struct rd *rd, const char *key_str,
}
}
+void print_on_off(struct rd *rd, const char *key_str, bool on)
+{
+ print_driver_string(rd, key_str, (on) ? "on":"off");
+}
+
static int print_driver_s32(struct rd *rd, const char *key_str, int32_t val,
enum rdma_nldev_print_type print_type)
{
--
2.20.1
^ permalink raw reply related
* [PATCH iproute2-rc 0/2] Control CQ adaptive moderation (RDMA DIM)
From: Leon Romanovsky @ 2019-07-29 7:42 UTC (permalink / raw)
To: Stephen Hemminger
Cc: Leon Romanovsky, netdev, David Ahern, RDMA mailing list,
Yamin Friedman
From: Leon Romanovsky <leonro@mellanox.com>
Hi,
This is supplementary part of RDMA DIM feature [1] accepted
for the kernel v5.3. In this patch set Yamin extends rdmatool
to get/set as a default this adaptive-moderation setting on
IB device level and provides an information about DIM on/off
status per-CQ.
Thanks
[1] https://lore.kernel.org/linux-rdma/20190708105905.27468-1-leon@kernel.org/
Yamin Friedman (2):
rdma: Control CQ adaptive moderation (DIM)
rdma: Document adaptive-moderation
man/man8/rdma-dev.8 | 16 ++++++++++++-
rdma/dev.c | 55 ++++++++++++++++++++++++++++++++++++++++++++-
rdma/rdma.h | 1 +
rdma/res-cq.c | 15 +++++++++++++
rdma/utils.c | 6 +++++
5 files changed, 91 insertions(+), 2 deletions(-)
--
2.20.1
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 7:41 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <4752bf67-7a0c-7bc9-3d54-f18361085ba2@gmail.com>
Mon, Jul 29, 2019 at 09:32:00AM CEST, baijiaju1990@gmail.com wrote:
>
>
>On 2019/7/29 14:56, Jiri Pirko wrote:
>> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> > In dequeue_func(), there is an if statement on line 74 to check whether
>> > skb is NULL:
>> > if (skb)
>> >
>> > When skb is NULL, it is used on line 77:
>> > prefetch(&skb->end);
>> >
>> > Thus, a possible null-pointer dereference may occur.
>> >
>> > To fix this bug, skb->end is used when skb is not NULL.
>> >
>> > This bug is found by a static analysis tool STCheck written by us.
>> >
>> > Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
>> Fixes tag, please?
>
>Sorry, I do not know what "fixes tag" means...
>I just find a possible bug and fix it in this patch.
git log |grep Fixes:
If A fix goes to -net tree, it most probably fixes some bug introduced
by some commit in the past. So this tag is to put a reference.
>
>
>Best wishes,
>Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jia-Ju Bai @ 2019-07-29 7:32 UTC (permalink / raw)
To: Jiri Pirko; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729065653.GA2211@nanopsycho>
On 2019/7/29 14:56, Jiri Pirko wrote:
> Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>> In dequeue_func(), there is an if statement on line 74 to check whether
>> skb is NULL:
>> if (skb)
>>
>> When skb is NULL, it is used on line 77:
>> prefetch(&skb->end);
>>
>> Thus, a possible null-pointer dereference may occur.
>>
>> To fix this bug, skb->end is used when skb is not NULL.
>>
>> This bug is found by a static analysis tool STCheck written by us.
>>
>> Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
> Fixes tag, please?
Sorry, I do not know what "fixes tag" means...
I just find a possible bug and fix it in this patch.
Best wishes,
Jia-Ju Bai
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:18 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
I think the nft is different with tc.
In tc case we can create vxlan device add a ingress qdisc with a block success
Then the ASIC driver loaded, then register the vxlan indr-dev and get the block
adn replay it to hardware
But in the nft case, The base chain flags with offload. Create an offload netdev
base chain on vxlan device will fail if there is no indr-device to offload.
^ permalink raw reply
* RE: [PATCH net-next v3 0/2] qed*: Support for NVM config attributes.
From: Sudarsana Reddy Kalluru @ 2019-07-29 7:16 UTC (permalink / raw)
To: David Miller; +Cc: netdev@vger.kernel.org, Michal Kalderon, Ariel Elior
In-Reply-To: <20190727.191328.1351271863559760336.davem@davemloft.net>
> -----Original Message-----
> From: David Miller <davem@davemloft.net>
> Sent: Sunday, July 28, 2019 7:43 AM
> To: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Cc: netdev@vger.kernel.org; Michal Kalderon <mkalderon@marvell.com>;
> Ariel Elior <aelior@marvell.com>
> Subject: Re: [PATCH net-next v3 0/2] qed*: Support for NVM config
> attributes.
>
> From: Sudarsana Reddy Kalluru <skalluru@marvell.com>
> Date: Sat, 27 Jul 2019 18:55:47 -0700
>
> > The patch series adds support for managing the NVM config attributes.
> > Patch (1) adds functionality to update config attributes via MFW.
> > Patch (2) adds driver interface for updating the config attributes.
> >
> > Changes from previous versions:
> > -------------------------------
> > v3: Removed unused variable.
> > v2: Removed unused API.
> >
> > Please consider applying this series to "net-next".
>
> I don't see where an existing ethtool method hooks into and calls this new
> NVM code.
Dave,
The new API/functionality is invoked as part of ethtool flash (ethtool -f) implementation.
Example code path:
ethtool_ops-->flash_device--> qede_flash_device() --> qed_nvm_flash() --> qed_nvm_flash_cfg_write() --> qed_mcp_nvm_set_cfg()
Thanks,
Sudarsana
^ permalink raw reply
* Re: [PATCH net-next v4 2/3] flow_offload: Support get default block from tc immediately
From: wenxu @ 2019-07-29 7:05 UTC (permalink / raw)
To: Jakub Kicinski; +Cc: pablo, fw, netfilter-devel, netdev
In-Reply-To: <20190728214237.2c0687db@cakuba.netronome.com>
On 7/29/2019 12:42 PM, Jakub Kicinski wrote:
> On Mon, 29 Jul 2019 10:43:56 +0800, wenxu wrote:
>> On 7/29/2019 4:16 AM, Jakub Kicinski wrote:
>>> I don't know the nft code, but it seems unlikely it wouldn't have the
>>> same problem/need..
>> nft don't have the same problem. The offload rule can only attached
>> to offload base chain.
>>
>> Th offload base chain is created after the device driver loaded (the
>> device exist).
> For indirect blocks the block is on the tunnel device and the offload
> target is another device. E.g. you offload rules from a VXLAN device
> onto the ASIC. The ASICs driver does not have to be loaded when VXLAN
> device is created.
>
> So I feel like either the chain somehow directly references the offload
> target (in which case the indirect infrastructure with hash lookup etc
> is not needed for nft), or indirect infra is needed, and we need to take
> care of replays.
So you mean the case is there are two card A and B both can offload vxlan.
First vxlan device offload with A. And then the B driver loaded, So the rules
should replay to B device?
^ permalink raw reply
* Re: [PATCH] net: sched: Fix a possible null-pointer dereference in dequeue_func()
From: Jiri Pirko @ 2019-07-29 6:56 UTC (permalink / raw)
To: Jia-Ju Bai; +Cc: jhs, xiyou.wangcong, davem, netdev, linux-kernel
In-Reply-To: <20190729022157.18090-1-baijiaju1990@gmail.com>
Mon, Jul 29, 2019 at 04:21:57AM CEST, baijiaju1990@gmail.com wrote:
>In dequeue_func(), there is an if statement on line 74 to check whether
>skb is NULL:
> if (skb)
>
>When skb is NULL, it is used on line 77:
> prefetch(&skb->end);
>
>Thus, a possible null-pointer dereference may occur.
>
>To fix this bug, skb->end is used when skb is not NULL.
>
>This bug is found by a static analysis tool STCheck written by us.
>
>Signed-off-by: Jia-Ju Bai <baijiaju1990@gmail.com>
Fixes tag, please?
>---
> net/sched/sch_codel.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
>diff --git a/net/sched/sch_codel.c b/net/sched/sch_codel.c
>index 25ef172c23df..30169b3adbbb 100644
>--- a/net/sched/sch_codel.c
>+++ b/net/sched/sch_codel.c
>@@ -71,10 +71,10 @@ static struct sk_buff *dequeue_func(struct codel_vars *vars, void *ctx)
> struct Qdisc *sch = ctx;
> struct sk_buff *skb = __qdisc_dequeue_head(&sch->q);
>
>- if (skb)
>+ if (skb) {
> sch->qstats.backlog -= qdisc_pkt_len(skb);
>-
>- prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ prefetch(&skb->end); /* we'll need skb_shinfo() */
>+ }
> return skb;
> }
>
>--
>2.17.0
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox