* Re: [RFC net-next 2/2] udp: No longer use SLAB_DESTROY_BY_RCU
From: Rick Jones @ 2016-03-28 16:15 UTC (permalink / raw)
To: Eric Dumazet, David S . Miller; +Cc: netdev, Eric Dumazet, Tom Herbert
In-Reply-To: <1458944964-12890-3-git-send-email-edumazet@google.com>
On 03/25/2016 03:29 PM, Eric Dumazet wrote:
> UDP sockets are not short lived in the high usage case, so the added
> cost of call_rcu() should not be a concern.
Even a busy DNS resolver?
rick jones
^ permalink raw reply
* Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem
From: Andrew Lunn @ 2016-03-28 16:10 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: Vishal Thanki, f.fainelli, ujhelyi.m, netdev
In-Reply-To: <20160328084335.2b631e99@xeon-e3>
Hi Stephen
> There already is LED control via ethtool.
> It is more important that the existing API (ethtool) still work.
I'm having trouble finding this. The man page for ethtool only
mentions -p --identify with respect to LEDs.
I also don't see anything in include/uapi/linux/ethtool.h
Please could you give more specific pointers.
Thanks
Andrew
^ permalink raw reply
* [PATCH] mwifiex: ie_list is an array, so no need to check if NULL
From: Colin King @ 2016-03-28 15:53 UTC (permalink / raw)
To: Amitkumar Karwar, Nishant Sarmukadam, Kalle Valo, linux-wireless,
netdev
Cc: linux-kernel
From: Colin Ian King <colin.king@canonical.com>
ap_ie->ie_list is an array of struct mwifiex_ie and can never
be null, so the null check on this array is redundant and can
be removed.
Signed-off-by: Colin Ian King <colin.king@canonical.com>
---
drivers/net/wireless/marvell/mwifiex/uap_cmd.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
index 16d95b2..92ce32f 100644
--- a/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
+++ b/drivers/net/wireless/marvell/mwifiex/uap_cmd.c
@@ -694,7 +694,7 @@ static int mwifiex_uap_custom_ie_prepare(u8 *tlv, void *cmd_buf, u16 *ie_size)
struct mwifiex_ie_list *ap_ie = cmd_buf;
struct mwifiex_ie_types_header *tlv_ie = (void *)tlv;
- if (!ap_ie || !ap_ie->len || !ap_ie->ie_list)
+ if (!ap_ie || !ap_ie->len)
return -1;
*ie_size += le16_to_cpu(ap_ie->len) +
--
2.7.4
^ permalink raw reply related
* Re: [PATCH 0/3] Control ethernet PHY LEDs via LED subsystem
From: Stephen Hemminger @ 2016-03-28 15:43 UTC (permalink / raw)
To: Vishal Thanki; +Cc: andrew, f.fainelli, ujhelyi.m, netdev
In-Reply-To: <1458755500-15571-1-git-send-email-vishalthanki@gmail.com>
On Wed, 23 Mar 2016 18:51:37 +0100
Vishal Thanki <vishalthanki@gmail.com> wrote:
> Hi all,
>
> Based on suggestions from Andrew and Florian, I have made some changes
> to expose the ethernet PHY LEDs using kernel LED subsystem. The following
> ALPHA patchset introduces two new LED triggers:
>
> 1) <phydev>-eth-phy-link:
> To monitor the PHY Link status
>
> 2) <phydev>-eth-phy-activity:
> To monitor the PHY activity status. This trigger may still some more work
> because as of now it just takes decision to set the trigger based on
> PHY state machine and triggers the blink_set with delay_on and delay_off
> parameters set to 0.
>
> Please provide the review comments so that I can work on this patchset to
> make it complete.
>
> Thanks,
> Vishal
>
> Vishal Thanki (3):
> net: phy: Add ethernet PHY LED triggers
> net: phy: at8030: Expose the Link and Activity LEDs
> led: at8030: Add LED driver for AT8030 ethernet PHY
>
> drivers/leds/Kconfig | 7 ++
> drivers/leds/Makefile | 1 +
> drivers/leds/leds-at803x.c | 158 +++++++++++++++++++++++++++++++++++++++++++
> drivers/net/phy/Kconfig | 7 ++
> drivers/net/phy/Makefile | 1 +
> drivers/net/phy/at803x.c | 55 ++++++++++++++-
> drivers/net/phy/phy.c | 20 +++++-
> drivers/net/phy/phy_device.c | 4 ++
> drivers/net/phy/phy_led.c | 70 +++++++++++++++++++
> drivers/net/phy/phy_led.h | 37 ++++++++++
> include/linux/leds.h | 1 +
> include/linux/phy.h | 6 ++
> include/linux/phy/at803x.h | 45 ++++++++++++
> 13 files changed, 409 insertions(+), 3 deletions(-)
> create mode 100644 drivers/leds/leds-at803x.c
> create mode 100644 drivers/net/phy/phy_led.c
> create mode 100644 drivers/net/phy/phy_led.h
> create mode 100644 include/linux/phy/at803x.h
>
There already is LED control via ethtool.
It is more important that the existing API (ethtool) still work.
^ permalink raw reply
* Re: [PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()
From: David Miller @ 2016-03-28 15:41 UTC (permalink / raw)
To: paul; +Cc: netdev, selinux, Janak.Desai, pmoore
In-Reply-To: <CAHC9VhTV_0tdRgFEcRoF1qjBunjwK6rSp8wpB4Jqjow2ENToCg@mail.gmail.com>
From: Paul Moore <paul@paul-moore.com>
Date: Mon, 28 Mar 2016 11:17:28 -0400
> On Mon, Mar 28, 2016 at 11:10 AM, Paul Moore <pmoore@redhat.com> wrote:
>> From: Janak Desai <Janak.Desai@gtri.gatech.edu>
>>
>> We try to be clever and set large chunks of the bitmap at once, when
>> possible; unfortunately we weren't very clever when we wrote the code
>> and messed up the if-conditional. Fix this bug and restore proper
>> operation.
>>
>> Signed-off-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
>> Signed-off-by: Paul Moore <paul@paul-moore.com>
>> ---
>> net/netlabel/netlabel_kapi.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> DaveM, I'm planning on carrying this in selinux#next unless you really
> want to this to go to Linus via the netdev tree.
I'm fine with it going via your tree, thanks.
^ permalink raw reply
* Re: [PATCH] net: macb: Only call GPIO functions if there is a valid GPIO
From: David Miller @ 2016-03-28 15:40 UTC (permalink / raw)
To: ckeepax; +Cc: nicolas.ferre, netdev, linux-kernel, patches
In-Reply-To: <1459169262-3941-1-git-send-email-ckeepax@opensource.wolfsonmicro.com>
From: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Date: Mon, 28 Mar 2016 13:47:42 +0100
> GPIOlib will print warning messages if we call GPIO functions without a
> valid GPIO. Change the code to avoid doing so.
>
> Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 2/2] net: hns: set-coalesce-usecs returns errno by dsaf.ko
From: David Miller @ 2016-03-28 15:39 UTC (permalink / raw)
To: Yisen.Zhuang
Cc: salil.mehta, liguozhu, huangdaode, arnd, andriy.shevchenko,
andrew, geliangtang, ivecera, lisheng011, fengguang.wu,
charles.chenxin, haifeng.wei, netdev, linux-kernel,
linux-arm-kernel, linuxarm
In-Reply-To: <1459161657-151406-3-git-send-email-Yisen.Zhuang@huawei.com>
From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
Date: Mon, 28 Mar 2016 18:40:57 +0800
> From: Lisheng <lisheng011@huawei.com>
>
> It may fail to set coalesce usecs to HW, and Ethtool needs to know if it
> is successful to cfg the parameter or not. So it needs return the errno by
> dsaf.ko.
>
> Signed-off-by: Lisheng <lisheng011@huawei.com>
> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] net: hns: fixed the setting and getting overtime bug
From: David Miller @ 2016-03-28 15:39 UTC (permalink / raw)
To: Yisen.Zhuang
Cc: salil.mehta, liguozhu, huangdaode, arnd, andriy.shevchenko,
andrew, geliangtang, ivecera, lisheng011, fengguang.wu,
charles.chenxin, haifeng.wei, netdev, linux-kernel,
linux-arm-kernel, linuxarm
In-Reply-To: <1459161657-151406-2-git-send-email-Yisen.Zhuang@huawei.com>
From: Yisen Zhuang <Yisen.Zhuang@huawei.com>
Date: Mon, 28 Mar 2016 18:40:56 +0800
> From: Lisheng <lisheng011@huawei.com>
>
> The overtime setting and getting REGs in HNS V2 is defferent from HNS V1.
> It needs to be distinguished between them if getting or setting the REGs.
>
> Signed-off-by: Lisheng <lisheng011@huawei.com>
> Signed-off-by: Yisen Zhuang <Yisen.Zhuang@huawei.com>
Applied.
^ permalink raw reply
* Re: [PATCH] openvswitch: Use proper buffer size in nla_memcpy
From: David Miller @ 2016-03-28 15:39 UTC (permalink / raw)
To: yanhaishuang; +Cc: pshelar, netdev, linux-kernel, dev
In-Reply-To: <1459159739-51541-1-git-send-email-yanhaishuang@cmss.chinamobile.com>
From: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Date: Mon, 28 Mar 2016 18:08:59 +0800
> For the input parameter count, it's better to use the size
> of destination buffer size, as nla_memcpy would take into
> account the length of the source netlink attribute when
> a data is copied from an attribute.
>
> Signed-off-by: Haishuang Yan <yanhaishuang@cmss.chinamobile.com>
Applied, thanks.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 07/14] batman-adv: use list_for_each_entry_safe
From: Marek Lindner @ 2016-03-28 15:02 UTC (permalink / raw)
To: b.a.t.m.a.n
Cc: Geliang Tang, Simon Wunderlich, Antonio Quartulli,
David S. Miller, linux-kernel, netdev
In-Reply-To: <b01d3ee936833e94fffa53f7a82fc46e20d877c1.1450451516.git.geliangtang@163.com>
[-- Attachment #1: Type: text/plain, Size: 383 bytes --]
On Friday, December 18, 2015 23:33:31 Geliang Tang wrote:
> Use list_for_each_entry_safe() instead of list_for_each_safe() to
> simplify the code.
>
> Signed-off-by: Geliang Tang <geliangtang@163.com>
> ---
> net/batman-adv/icmp_socket.c | 22 +++++++++-------------
> 1 file changed, 9 insertions(+), 13 deletions(-)
Applied in the batman tree (revision 1557404).
Thanks,
Marek
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 1/3] batman-adv: use to_delayed_work
From: Marek Lindner @ 2016-03-28 15:05 UTC (permalink / raw)
To: b.a.t.m.a.n
Cc: Geliang Tang, Simon Wunderlich, Antonio Quartulli,
David S. Miller, linux-kernel, netdev
In-Reply-To: <2c0e66fe07809e4069df34cbeba51583ad943c7a.1451317025.git.geliangtang@163.com>
[-- Attachment #1: Type: text/plain, Size: 581 bytes --]
On Monday, December 28, 2015 23:43:37 Geliang Tang wrote:
> Use to_delayed_work() instead of open-coding it.
>
> Signed-off-by: Geliang Tang <geliangtang@163.com>
> ---
> net/batman-adv/bridge_loop_avoidance.c | 2 +-
> net/batman-adv/distributed-arp-table.c | 2 +-
> net/batman-adv/network-coding.c | 2 +-
> net/batman-adv/originator.c | 2 +-
> net/batman-adv/send.c | 4 ++--
> net/batman-adv/translation-table.c | 2 +-
> 6 files changed, 7 insertions(+), 7 deletions(-)
Applied in the batman tree (revision ecc6f9a).
Thanks,
Marek
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
^ permalink raw reply
* Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()
From: David Miller @ 2016-03-28 15:27 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, lorenzo
In-Reply-To: <1459175035.6473.92.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 28 Mar 2016 07:23:55 -0700
> On Mon, 2016-03-28 at 07:10 -0700, Eric Dumazet wrote:
>> On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote:
>>
>> > Sure, but the caller changed quite a lot in all stable versions.
>> >
>> > I took the easiest path for stable maintainers, and was planing to
>> > implement a better way in net-next.
>>
>> I misread your suggestion David, I send a V2 shortly.
>>
>
> Actually, I'll wait for net-next opening.
>
> My brain farted while working on the 'non refcounted TCP listener'
> because __inet_lookup_listener() will really need to be called from
> enclosed rcu_read_lock(), and for a reason I though net tree had a bug.
>
> The local_bh_disable()/local_bh_enable() removal can certainly wait
> net-next.
>
> Sorry for the confusion.
Ok, I'll mark this patch as deferred then.
Thanks Eric.
^ permalink raw reply
* Re: [PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()
From: Paul Moore @ 2016-03-28 15:17 UTC (permalink / raw)
To: netdev; +Cc: selinux, Janak Desai, Paul Moore
In-Reply-To: <145917783800.9565.7759086668991534988.stgit@localhost>
On Mon, Mar 28, 2016 at 11:10 AM, Paul Moore <pmoore@redhat.com> wrote:
> From: Janak Desai <Janak.Desai@gtri.gatech.edu>
>
> We try to be clever and set large chunks of the bitmap at once, when
> possible; unfortunately we weren't very clever when we wrote the code
> and messed up the if-conditional. Fix this bug and restore proper
> operation.
>
> Signed-off-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
> Signed-off-by: Paul Moore <paul@paul-moore.com>
> ---
> net/netlabel/netlabel_kapi.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
DaveM, I'm planning on carrying this in selinux#next unless you really
want to this to go to Linus via the netdev tree.
> diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
> index 28cddc8..1325776 100644
> --- a/net/netlabel/netlabel_kapi.c
> +++ b/net/netlabel/netlabel_kapi.c
> @@ -677,7 +677,7 @@ int netlbl_catmap_setrng(struct netlbl_lsm_catmap **catmap,
> u32 spot = start;
>
> while (rc == 0 && spot <= end) {
> - if (((spot & (BITS_PER_LONG - 1)) != 0) &&
> + if (((spot & (BITS_PER_LONG - 1)) == 0) &&
> ((end - spot) > BITS_PER_LONG)) {
> rc = netlbl_catmap_setlong(catmap,
> spot,
>
--
paul moore
www.paul-moore.com
^ permalink raw reply
* [PATCH] netlabel: fix a problem with netlbl_secattr_catmap_setrng()
From: Paul Moore @ 2016-03-28 15:10 UTC (permalink / raw)
To: netdev, selinux; +Cc: Janak Desai
From: Janak Desai <Janak.Desai@gtri.gatech.edu>
We try to be clever and set large chunks of the bitmap at once, when
possible; unfortunately we weren't very clever when we wrote the code
and messed up the if-conditional. Fix this bug and restore proper
operation.
Signed-off-by: Janak Desai <Janak.Desai@gtri.gatech.edu>
Signed-off-by: Paul Moore <paul@paul-moore.com>
---
net/netlabel/netlabel_kapi.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/netlabel/netlabel_kapi.c b/net/netlabel/netlabel_kapi.c
index 28cddc8..1325776 100644
--- a/net/netlabel/netlabel_kapi.c
+++ b/net/netlabel/netlabel_kapi.c
@@ -677,7 +677,7 @@ int netlbl_catmap_setrng(struct netlbl_lsm_catmap **catmap,
u32 spot = start;
while (rc == 0 && spot <= end) {
- if (((spot & (BITS_PER_LONG - 1)) != 0) &&
+ if (((spot & (BITS_PER_LONG - 1)) == 0) &&
((end - spot) > BITS_PER_LONG)) {
rc = netlbl_catmap_setlong(catmap,
spot,
^ permalink raw reply related
* Re: [PATCH 25/31] ethernet: use parity8 in sun/niu.c
From: Michal Nazarewicz @ 2016-03-28 14:33 UTC (permalink / raw)
To: zhaoxiu.zeng, Jiri Pirko, Andrew Morton, David S. Miller,
Vlastimil Babka, Joonsoo Kim
Cc: linux-kernel, netdev
In-Reply-To: <56F78D76.1060305@gmail.com>
On Sun, Mar 27 2016, zhaoxiu zeng wrote:
> From: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
>
> Signed-off-by: Zeng Zhaoxiu <zhaoxiu.zeng@gmail.com>
No idea why I’ve been CC’d, but code looks good to me so:
Acked-by: Michal Nazarewicz <mina86@mina86.com>
> ---
> drivers/net/ethernet/sun/niu.c | 10 ++--------
> 1 file changed, 2 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/sun/niu.c b/drivers/net/ethernet/sun/niu.c
> index 9cc4564..8c344ef 100644
> --- a/drivers/net/ethernet/sun/niu.c
> +++ b/drivers/net/ethernet/sun/niu.c
> @@ -2742,18 +2742,12 @@ static int niu_set_alt_mac_rdc_table(struct niu *np, int idx,
>
> static u64 vlan_entry_set_parity(u64 reg_val)
> {
> - u64 port01_mask;
> - u64 port23_mask;
> -
> - port01_mask = 0x00ff;
> - port23_mask = 0xff00;
> -
> - if (hweight64(reg_val & port01_mask) & 1)
> + if (parity8(reg_val))
> reg_val |= ENET_VLAN_TBL_PARITY0;
> else
> reg_val &= ~ENET_VLAN_TBL_PARITY0;
>
> - if (hweight64(reg_val & port23_mask) & 1)
> + if (parity8((unsigned int)reg_val >> 8))
> reg_val |= ENET_VLAN_TBL_PARITY1;
> else
> reg_val &= ~ENET_VLAN_TBL_PARITY1;
> --
> 2.5.5
>
--
Best regards
ミハウ “𝓶𝓲𝓷𝓪86” ナザレヴイツ
«If at first you don’t succeed, give up skydiving»
^ permalink raw reply
* Re: [PATCH v8 net-next] ravb: Add dma queue interrupt support
From: Yoshihiro Kaneko @ 2016-03-28 14:32 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: netdev, David S. Miller, Simon Horman, Magnus Damm,
linux-renesas-soc
In-Reply-To: <56F7D9E6.6080605@cogentembedded.com>
Hello.
2016-03-27 22:02 GMT+09:00 Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>:
> Hello.
>
>
> On 03/22/2016 06:22 PM, Yoshihiro Kaneko wrote:
>
>> From: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>>
>> This patch supports the following interrupts.
>>
>> - One interrupt for multiple (timestamp, error, gPTP)
>> - One interrupt for emac
>> - Four interrupts for dma queue (best effort rx/tx, network control rx/tx)
>>
>> This patch improve efficiency of the interrupt handler by adding the
>> interrupt handler corresponding to each interrupt source described
>> above. Additionally, it reduces the number of times of the access to
>> EthernetAVB IF.
>> Also this patch prevent this driver depends on the whim of a boot loader.
>>
>> [ykaneko0929@gmail.com: define bit names of registers]
>> [ykaneko0929@gmail.com: add comment for gen3 only registers]
>> [ykaneko0929@gmail.com: fix coding style]
>> [ykaneko0929@gmail.com: update changelog]
>> [ykaneko0929@gmail.com: gen3: fix initialization of interrupts]
>> [ykaneko0929@gmail.com: gen3: fix clearing interrupts]
>> [ykaneko0929@gmail.com: gen3: add helper function for request_irq()]
>> [ykaneko0929@gmail.com: gen3: remove IRQF_SHARED flag for request_irq()]
>> [ykaneko0929@gmail.com: revert ravb_close() and ravb_ptp_stop()]
>> [ykaneko0929@gmail.com: avoid calling free_irq() to non-hooked interrupts]
>> [ykaneko0929@gmail.com: make NC/BE interrupt handler a function]
>> [ykaneko0929@gmail.com: make timestamp interrupt handler a function]
>> [ykaneko0929@gmail.com: timestamp interrupt is handled in multiple
>> interrupt handler instead of dma queue interrupt handler]
>> Signed-off-by: Kazuya Mizuguchi <kazuya.mizuguchi.ks@renesas.com>
>> Signed-off-by: Yoshihiro Kaneko <ykaneko0929@gmail.com>
>
> [...]
>
> Acked-by: Sergei Shtylyov <sergei.shtylyov@cogentembedded.com>
Many thanks for your review and much help!
>
> MBR, Sergei
>
Thanks,
kaneko
^ permalink raw reply
* Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()
From: Eric Dumazet @ 2016-03-28 14:23 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lorenzo
In-Reply-To: <1459174213.6473.87.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-03-28 at 07:10 -0700, Eric Dumazet wrote:
> On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote:
>
> > Sure, but the caller changed quite a lot in all stable versions.
> >
> > I took the easiest path for stable maintainers, and was planing to
> > implement a better way in net-next.
>
> I misread your suggestion David, I send a V2 shortly.
>
Actually, I'll wait for net-next opening.
My brain farted while working on the 'non refcounted TCP listener'
because __inet_lookup_listener() will really need to be called from
enclosed rcu_read_lock(), and for a reason I though net tree had a bug.
The local_bh_disable()/local_bh_enable() removal can certainly wait
net-next.
Sorry for the confusion.
^ permalink raw reply
* Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()
From: Eric Dumazet @ 2016-03-28 14:10 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lorenzo
In-Reply-To: <1459171772.6473.86.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2016-03-28 at 06:29 -0700, Eric Dumazet wrote:
> Sure, but the caller changed quite a lot in all stable versions.
>
> I took the easiest path for stable maintainers, and was planing to
> implement a better way in net-next.
I misread your suggestion David, I send a V2 shortly.
^ permalink raw reply
* RE: [PATCH net-next 1/1] qlge: Update version to 1.00.00.35
From: Manish Chopra @ 2016-03-28 12:09 UTC (permalink / raw)
To: David Miller; +Cc: netdev, Dept-GE Linux NIC Dev, Harish Patil
In-Reply-To: <20160325.114131.1189108232537972107.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Friday, March 25, 2016 9:12 PM
> To: Manish Chopra <manish.chopra@qlogic.com>
> Cc: netdev <netdev@vger.kernel.org>; Dept-GE Linux NIC Dev <Dept-
> GELinuxNICDev@qlogic.com>; Harish Patil <harish.patil@qlogic.com>
> Subject: Re: [PATCH net-next 1/1] qlge: Update version to 1.00.00.35
>
> From: Manish Chopra <manish.chopra@qlogic.com>
> Date: Fri, 25 Mar 2016 07:14:09 -0400
>
> > Just updating version as many fixes got accumulated over 1.00.00.34
> >
> > Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
>
> Applied, but it is the 'net' tree that fixes et al. like this should be targetting as
> 'net-next' is closed.
Thanks Dave. By the way I used to see an announcement regarding "net-next is CLOSED" on netdev which I don't see these days.
I know that there are other ways to know this but I think it's much easier and straight to know this from announcement email so that
everybody be more aware of NOT sending patches for net-next over this period at first place.
^ permalink raw reply
* Re: [PATCH net] inet: add proper locking in __inet{6}_lookup()
From: Eric Dumazet @ 2016-03-28 13:29 UTC (permalink / raw)
To: David Miller; +Cc: netdev, lorenzo
In-Reply-To: <20160327.223222.486104825905902179.davem@davemloft.net>
On Sun, 2016-03-27 at 22:32 -0400, David Miller wrote:
> From: Eric Dumazet <eric.dumazet@gmail.com>
> Date: Fri, 25 Mar 2016 15:15:15 -0700
>
> > From: Eric Dumazet <edumazet@google.com>
> >
> > Blocking BH in __inet{6}_lookup() is not correct, as the lookups
> > are done using RCU protection.
> >
> > It matters only starting from Lorenzo Colitti patches to destroy
> > a TCP socket, since rcu_read_lock() is already held by other users
> > of these functions.
> >
> > This can be backported to all known stable versions, since TCP got RCU
> > lookups back in 2.6.29 : Even if iproute2 contained no code to trigger
> > the bug, some user programs could have used the API.
> >
> > Signed-off-by: Eric Dumazet <edumazet@google.com>
> > Cc: Lorenzo Colitti <lorenzo@google.com>
>
> This is quite the maze of RCU locking here. With this change,
> inet_lookup is now:
>
> rcu_read_lock();
> sk = x(); {
> rcu_read_lock();
> ...
> rcu_read_unlock();
> }
> if (!sk) {
> sk = y(); {
> rcu_read_lock();
> ...
> rcu_read_unlock();
> }
> }
> rcu_read_unlock();
>
> It would seem to me that we should bubble up the rcu locking calls.
>
> If, as you say, the other users do RCU locking already, then it should
> be safe to do what your patch is doing and also remove the RCU locking
> done by __inet_lookup_established() and __inet_lookup_listener().
>
Sure, but the caller changed quite a lot in all stable versions.
I took the easiest path for stable maintainers, and was planing to
implement a better way in net-next.
I certainly can take the final form and let you do the backports ?
Thanks.
^ permalink raw reply
* Re: [PATCH v2] netpoll: Fix extra refcount release in netpoll_cleanup()
From: Neil Horman @ 2016-03-28 13:18 UTC (permalink / raw)
To: David Miller; +Cc: helgaas, bhelgaas, nikolay, netdev, aduyck, linux-kernel
In-Reply-To: <20160325.151636.590435237623997861.davem@davemloft.net>
On Fri, Mar 25, 2016 at 03:16:36PM -0400, David Miller wrote:
> From: Bjorn Helgaas <helgaas@kernel.org>
> Date: Fri, 25 Mar 2016 11:46:39 -0500
>
> > You're right, there is an issue here. I reproduced a problem with a
> > bond device. bond_netpoll_setup() calls __netpoll_setup() directly
> > (not netpoll_setup()). I'll debug it more; just wanted to let you
> > know there *is* a problem with this patch.
>
> I bet that's why the assignment to np->dev and the reference counting
> were separated in the first place :-/
>
> Indeed, commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb:
>
> commit 30fdd8a082a00126a6feec994e43e8dc12f5bccb
> Author: Jiri Pirko <jiri@resnulli.us>
> Date: Tue Jul 17 05:22:35 2012 +0000
>
> netpoll: move np->dev and np->dev_name init into __netpoll_setup()
>
> Signed-off-by: Jiri Pirko <jiri@resnulli.us>
> Signed-off-by: David S. Miller <davem@davemloft.net>
We probably just want to balance the setting/clearing of np->dev in
__netpoll_setup, so that any error return (that would result in a drop of the
refcount in netpoll_setup) correlates to a setting of np->dev to NULL in
__netpoll_setup. That leaves us with the problem of having to watch for future
imbalances as you mentioned previously Dave, but it seems a potential problem
tomorrow is preferable to an actual problem today.
Another option would be to move the dev_hold/put into __netpoll_setup, but doing
so would I think require some additional refactoring in netpoll_setup. Namely
that we would still need a dev_hold/put in netpoll_setup to prevent the device
from being removed during the period where we release the rtnl lock in the if
(!netif_running(ndev)) clause. We would have to hold the device, unlock rtnl,
then put the device after re-aquiring rtnl at the end of that if block.
Neil
^ permalink raw reply
* Re: BUG: net/netfilter: KASAN: stack-out-of-bounds in tcp_packet
From: Baozeng Ding @ 2016-03-28 13:14 UTC (permalink / raw)
To: Jozsef Kadlecsik
Cc: Pablo Neira Ayuso, Patrick McHardy, David Miller, netfilter-devel,
netdev
In-Reply-To: <56F8987B.5030501@gmail.com>
On 2016/3/28 10:35, Baozeng Ding wrote:
>
>
> On 2016/3/28 6:25, Jozsef Kadlecsik wrote:
>> On Mon, 28 Mar 2016, Jozsef Kadlecsik wrote:
>>
>>> On Sun, 27 Mar 2016, Baozeng Ding wrote:
>>>
>>>> The following program triggers stack-out-of-bounds in tcp_packet. The
>>>> kernel version is 4.5 (on Mar 16 commit
>>>> 09fd671ccb2475436bd5f597f751ca4a7d177aea).
>>>> Uncovered with syzkaller. Thanks.
>>>>
>>>> ==================================================================
>>>> BUG: KASAN: stack-out-of-bounds in tcp_packet+0x4b77/0x51c0 at addr
>>>> ffff8800a45df3c8
>>>> Read of size 1 by task 0327/11132
>>>> page:ffffea00029177c0 count:0 mapcount:0 mapping: (null) index:0x0
>>>> flags: 0x1fffc0000000000()
>>>> page dumped because: kasan: bad access detected
>>>> CPU: 1 PID: 11132 Comm: 0327 Tainted: G B 4.5.0+ #12
>>>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS
>>>> rel-1.8.2-0-g33fbe13 by qemu-project.org 04/01/2014
>>>> 0000000000000001 ffff8800a45df148 ffffffff82945051 ffff8800a45df1d8
>>>> ffff8800a45df3c8 0000000000000027 0000000000000001 ffff8800a45df1c8
>>>> ffffffff81709f88 ffff8800b4f7e3d0 0000000000000028 0000000000000286
>>>> Call Trace:
>>>> [< inline >] __dump_stack /kernel/lib/dump_stack.c:15
>>>> [<ffffffff82945051>] dump_stack+0xb3/0x112 /kernel/lib/dump_stack.c:51
>>>> [< inline >] print_address_description
>>>> /kernel/mm/kasan/report.c:150
>>>> [<ffffffff81709f88>] kasan_report_error+0x4f8/0x530
>>>> /kernel/mm/kasan/report.c:236
>>>> [<ffffffff84c54b8d>] ? skb_copy_bits+0x49d/0x6d0
>>>> /kernel/net/core/skbuff.c:1675
>>>> [< inline >] ? spin_lock_bh
>>>> /kernel/include/linux/spinlock.h:307
>>>> [<ffffffff84e0e9b9>] ? tcp_packet+0x1c9/0x51c0
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:833
>>>> [< inline >] kasan_report /kernel/mm/kasan/report.c:259
>>>> [<ffffffff81709ffe>] __asan_report_load1_noabort+0x3e/0x40
>>>> /kernel/mm/kasan/report.c:277
>>>> [< inline >] ? tcp_sack
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
>>>> [< inline >] ? tcp_in_window
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
>>>> [<ffffffff84e13367>] ? tcp_packet+0x4b77/0x51c0
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
>>>> [< inline >] tcp_sack
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:473
>>>> [< inline >] tcp_in_window
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:527
>>>> [<ffffffff84e13367>] tcp_packet+0x4b77/0x51c0
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1036
>>>> [<ffffffff817094b8>] ? memset+0x28/0x30 /kernel/mm/kasan/kasan.c:302
>>>> [<ffffffff84e0dd74>] ? tcp_new+0x1a4/0xc20
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1122
>>>> [< inline >] ? build_report /kernel/include/net/netlink.h:499
>>>> [<ffffffff8518c4d6>] ? xfrm_send_report+0x426/0x450
>>>> /kernel/net/xfrm/xfrm_user.c:3039
>>>> [<ffffffff84e0e7f0>] ? tcp_new+0xc20/0xc20
>>>> /kernel/net/netfilter/nf_conntrack_proto_tcp.c:1169
>>>> [<ffffffff84dfb03a>] ? init_conntrack+0xca/0x9e0
>>>> /kernel/net/netfilter/nf_conntrack_core.c:972
>>>> [<ffffffff84dfaf70>] ? nf_conntrack_alloc+0x40/0x40
>>>> /kernel/net/netfilter/nf_conntrack_core.c:903
>>>> [<ffffffff84e0cdf0>] ? tcp_init_net+0x6e0/0x6e0
>>>> /kernel/include/net/netfilter/nf_conntrack_l4proto.h:137
>>>> [<ffffffff85121732>] ? ipv4_get_l4proto+0x262/0x390
>>>> /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:89
>>>> [<ffffffff84df372f>] ? nf_ct_get_tuple+0xaf/0x190
>>>> /kernel/net/netfilter/nf_conntrack_core.c:197
>>>> [<ffffffff84dfc23e>] nf_conntrack_in+0x8ee/0x1170
>>>> /kernel/net/netfilter/nf_conntrack_core.c:1177
>>>> [<ffffffff84dfb950>] ? init_conntrack+0x9e0/0x9e0
>>>> /kernel/net/netfilter/nf_conntrack_core.c:287
>>>> [<ffffffff8512ab06>] ? ipt_do_table+0xa16/0x1260
>>>> /kernel/net/ipv4/netfilter/ip_tables.c:423
>>>> [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
>>>> /kernel/kernel/locking/lockdep.c:2635
>>>> [<ffffffff81311fcb>] ? __local_bh_enable_ip+0x6b/0xc0
>>>> /kernel/kernel/softirq.c:175
>>>> [<ffffffff8512a0f0>] ? check_entry.isra.4+0x190/0x190
>>>> /kernel/net/ipv6/netfilter/ip6_tables.c:594
>>>> [<ffffffff84f9d4e0>] ? ip_reply_glue_bits+0xc0/0xc0
>>>> /kernel/net/ipv4/ip_output.c:1530
>>>> [<ffffffff851219ae>] ipv4_conntrack_local+0x14e/0x1a0
>>>> /kernel/net/ipv4/netfilter/nf_conntrack_l3proto_ipv4.c:161
>>>> [<ffffffff85131b3d>] ? iptable_raw_hook+0x9d/0x1e0
>>>> /kernel/net/ipv4/netfilter/iptable_raw.c:32
>>>> [<ffffffff84de5b7d>] nf_iterate+0x15d/0x230
>>>> /kernel/net/netfilter/core.c:274
>>>> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230
>>>> /kernel/net/netfilter/core.c:268
>>>> [<ffffffff84de5dfd>] nf_hook_slow+0x1ad/0x310
>>>> /kernel/net/netfilter/core.c:306
>>>> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230
>>>> /kernel/net/netfilter/core.c:268
>>>> [<ffffffff84de5c50>] ? nf_iterate+0x230/0x230
>>>> /kernel/net/netfilter/core.c:268
>>>> [<ffffffff82979274>] ? prandom_u32+0x24/0x30 /kernel/lib/random32.c:83
>>>> [<ffffffff84f747ff>] ? ip_idents_reserve+0x9f/0xf0
>>>> /kernel/net/ipv4/route.c:484
>>>> [< inline >] nf_hook_thresh
>>>> /kernel/include/linux/netfilter.h:187
>>>> [< inline >] nf_hook /kernel/include/linux/netfilter.h:197
>>>> [<ffffffff84fa4f53>] __ip_local_out+0x263/0x3c0
>>>> /kernel/net/ipv4/ip_output.c:104
>>>> [<ffffffff84fa4cf0>] ? ip_finish_output+0xd00/0xd00
>>>> /kernel/include/net/ip.h:322
>>>> [<ffffffff84fa0230>] ? __ip_flush_pending_frames.isra.45+0x2e0/0x2e0
>>>> /kernel/net/ipv4/ip_output.c:1337
>>>> [<ffffffff84faa336>] ? __ip_make_skb+0xfe6/0x1610
>>>> /kernel/net/ipv4/ip_output.c:1436
>>>> [<ffffffff84fa50dd>] ip_local_out+0x2d/0x1c0
>>>> /kernel/net/ipv4/ip_output.c:113
>>>> [<ffffffff84faa99c>] ip_send_skb+0x3c/0xc0
>>>> /kernel/net/ipv4/ip_output.c:1443
>>>> [<ffffffff84faaa84>] ip_push_pending_frames+0x64/0x80
>>>> /kernel/net/ipv4/ip_output.c:1463
>>>> [< inline >] rcu_read_unlock
>>>> /kernel/include/linux/rcupdate.h:922
>>>> [<ffffffff8504e10b>] raw_sendmsg+0x17bb/0x25c0
>>>> /kernel/net/ieee802154/socket.c:53
>>>> [<ffffffff8504c950>] ? dst_output+0x190/0x190
>>>> /kernel/include/net/dst.h:492
>>>> [< inline >] ? trace_mm_page_alloc
>>>> /kernel/include/trace/events/kmem.h:217
>>>> [<ffffffff81621609>] ? __alloc_pages_nodemask+0x559/0x16b0
>>>> /kernel/mm/page_alloc.c:3368
>>>> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
>>>> /kernel/kernel/locking/lockdep.c:4104
>>>> [<ffffffff814c0e30>] ? is_module_text_address+0x10/0x20
>>>> /kernel/kernel/module.c:4057
>>>> [<ffffffff81360533>] ? __kernel_text_address+0x73/0xa0
>>>> /kernel/kernel/extable.c:103
>>>> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
>>>> /kernel/kernel/locking/lockdep.c:4104
>>>> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
>>>> /kernel/kernel/locking/lockdep.c:4104
>>>> [<ffffffff81405ced>] ? trace_hardirqs_on+0xd/0x10
>>>> /kernel/kernel/locking/lockdep.c:2635
>>>> [<ffffffff81406260>] ? debug_check_no_locks_freed+0x290/0x290
>>>> /kernel/kernel/locking/lockdep.c:4104
>>>> [< inline >] ? sock_rps_record_flow
>>>> /kernel/include/net/sock.h:874
>>>> [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0
>>>> /kernel/net/ipv4/af_inet.c:729
>>>> [< inline >] ? rcu_read_unlock
>>>> /kernel/include/linux/rcupdate.h:922
>>>> [< inline >] ? sock_rps_record_flow_hash
>>>> /kernel/include/net/sock.h:867
>>>> [< inline >] ? sock_rps_record_flow
>>>> /kernel/include/net/sock.h:874
>>>> [<ffffffff8508929a>] ? inet_sendmsg+0x1fa/0x4c0
>>>> /kernel/net/ipv4/af_inet.c:729
>>>> [<ffffffff85089395>] inet_sendmsg+0x2f5/0x4c0
>>>> /kernel/net/ipv4/af_inet.c:736
>>>> [< inline >] ? sock_rps_record_flow
>>>> /kernel/include/net/sock.h:874
>>>> [<ffffffff85089113>] ? inet_sendmsg+0x73/0x4c0
>>>> /kernel/net/ipv4/af_inet.c:729
>>>> [<ffffffff850890a0>] ? inet_recvmsg+0x4a0/0x4a0
>>>> /kernel/include/linux/compiler.h:222
>>>> [< inline >] sock_sendmsg_nosec /kernel/net/socket.c:611
>>>> [<ffffffff84c3434a>] sock_sendmsg+0xca/0x110 /kernel/net/socket.c:621
>>>> [<ffffffff84c35448>] SYSC_sendto+0x208/0x350 /kernel/net/socket.c:1651
>>>> [<ffffffff84c35240>] ? SYSC_connect+0x2e0/0x2e0
>>>> /kernel/net/socket.c:1543
>>>> [<ffffffff81698650>] ? __pmd_alloc+0x350/0x350
>>>> /kernel/mm/memory.c:3928
>>>> [<ffffffff81230b3b>] ? __do_page_fault+0x2ab/0x8e0
>>>> /kernel/arch/x86/mm/fault.c:1184
>>>> [<ffffffff81230c30>] ? __do_page_fault+0x3a0/0x8e0
>>>> /kernel/arch/x86/mm/fault.c:1271
>>>> [<ffffffff813fb5da>] ? up_read+0x1a/0x40
>>>> /kernel/kernel/locking/rwsem.c:79
>>>> [<ffffffff81230a29>] ? __do_page_fault+0x199/0x8e0
>>>> /kernel/arch/x86/mm/fault.c:1187
>>>> [<ffffffff84c379b0>] SyS_sendto+0x40/0x50 /kernel/net/socket.c:1619
>>>> [<ffffffff85dab940>] entry_SYSCALL_64_fastpath+0x23/0xc1
>>>> /kernel/arch/x86/entry/entry_64.S:207
>>>> Memory state around the buggy address:
>>>> ffff8800a45df280: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ffff8800a45df300: f1 f1 f1 f1 00 00 04 f4 f2 f2 f2 f2 00 00 04 f4
>>>>> ffff8800a45df380: f2 f2 f2 f2 00 00 00 00 00 f4 f4 f4 f3 f3 f3 f3
>>>> ^
>>>> ffff8800a45df400: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>>>> ffff8800a45df480: 00 00 00 00 00 00 00 00 f1 f1 f1 f1 01 f4 f4 f4
>>>> ==================================================================
>>>>
>>>> #include <unistd.h>
>>>> #include <sys/syscall.h>
>>>> #include <string.h>
>>>> #include <stdint.h>
>>>> #include <pthread.h>
>>>> #include <sys/socket.h>
>>>> #include <sys/mman.h>
>>>> #include <netinet/in.h>
>>>> int main()
>>>> {
>>>> mmap((void *)0x20000000ul, 0x19000ul, PROT_READ|PROT_WRITE,
>>>> MAP_PRIVATE|MAP_FIXED|MAP_ANONYMOUS, -1, 0);
>>>> int sock = socket(AF_INET, SOCK_RAW, IPPROTO_TCP);
>>>> int sock_dup = dup(sock);
>>>> memcpy((void*)0x2000b000,
>>>> "\x11\xaf\x7d\x99\x91\x3c\x87\x34\x85\x18\xc4\xd6\xf2\x30\x0a", 15);
>>>> *(uint16_t*)0x20002fec = (uint16_t)0x2;
>>>> *(uint16_t*)0x20002fee = (uint16_t)0x11ab;
>>>> *(uint32_t*)0x20002ff0 = (uint32_t)0x100007f;
>>>> sendto(sock_dup, (void *)0x2000b000ul, 0xful, 0x8800ul,
>>>> (struct
>>>> sockaddr *)0x20002fe4ul, 0x1cul);
>>>> memcpy((void*)0x2001504f,
>>>> "\x7e\xb1\x52\x5b\x78\x85\x27\xe7\xcc\x3d\xf5\x18\x1b\xba\xda\x97\x6c\x18\x72\x0c\xd2\x0a\xa6\x77\xb7\x8b\xa2\xd2\x1d\xf0\x6b\xf6\x1a\x27\x6b\x98\x3e\x0b\x49\x8d\x54\x6e\x9e\xbb\x21\x4a\x72\x79\x1f\x82\xaf\x89\x2c\xf6\xd3\xc9\xd7\xed\x18\x29\x4d\x2e\x03\x15\xe2\x03\x14\xd0\xac\xa5\x81\x37\x73\x88\xa9\xf5\x08\xe5\xef\x5b\x56\xb7\x18\x8f\xe6\x19\xea\x91\x82\x23\xdd\x2c\x5c\xa5\xf0\xfc\xd8\xe2\x8b\x91\x48\x70\x24\xed\xae\xf9\x06\xac\xc4\x53\x01\xc3\xf5\xa3\x10\xef\xf1\xa6\x2b\xae\x72\xc7\x1a\x02\xee\x78\xcd\xd1\x7e\x8c\x9c\x1a\x36\xc7\xd4\x7c\x82\x64\xf7\x8b\x5a\xb0\x72\xa8\x87\x3c\xdc\xd0\xba\xfe\x70\x7d\x8c\x23\x78\xad\x7c\x31\x04\xec\xab\x1e\x4c\xee\xae\x84\xd8\x1a\x1d\x85\xa5\x57\xa8\x24\x53\x08\x1c\x4f\xda\x49\xe5\x3a\x99\x8c\x29\xa1\xed\x4b\x42\x7a\x15\x48\x2a\x22\x3b\x81\xfe\x47\x
74\xc1\x2f\x64\xcf\x10\xd4\x71\x72\x50\x71\xd7\xf6\xb0\xca\x41\x9a\x5e\x3e\xe4\x31\x19\xd1\x19\x46\x20\x66\x4c\x2f\xea\x76\x17\x2d\x94",
>>>>
>>>> 232);
>>>> *(uint16_t*)0x2001501c = (uint16_t)0xa;
>>>> *(uint16_t*)0x2001501e = (uint16_t)0x11ab;
>>>> *(uint32_t*)0x20015020 = (uint32_t)0xbdc;
>>>> *(uint32_t*)0x20015024 = (uint32_t)0x0;
>>>> *(uint32_t*)0x20015028 = (uint32_t)0x0;
>>>> *(uint32_t*)0x2001502c = (uint32_t)0x0;
>>>> *(uint32_t*)0x20015030 = (uint32_t)0x1000000;
>>>> *(uint32_t*)0x20015034 = (uint32_t)0x3;
>>>> sendto(sock_dup, (void *)0x2001504ful, 0xe8ul, 0x880ul,
>>>> (struct
>>>> sockaddr *)0x20015000ul, 0x1cul);
>>>> return 0;
>>>> }
>> Actually, in order to fix the non-conntrack case too, I believe the next
>> patch is required:
>>
>> diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
>> index d4c5115..365f4fb 100644
>> --- a/net/ipv4/tcp_input.c
>> +++ b/net/ipv4/tcp_input.c
>> @@ -3716,6 +3716,8 @@ void tcp_parse_options(const struct sk_buff *skb,
>> length--;
>> continue;
>> default:
>> + if (length < 2)
>> + return;
>> opsize = *ptr++;
>> if (opsize < 2) /* "silly options" */
>> return;
>> @@ -3873,6 +3875,8 @@ const u8 *tcp_parse_md5sig_option(const struct
>> tcphdr *th)
>> length--;
>> continue;
>> default:
>> + if (length < 2)
>> + return;
>> opsize = *ptr++;
>> if (opsize < 2 || opsize > length)
>> return NULL;
>> diff --git a/net/netfilter/nf_conntrack_proto_tcp.c
>> b/net/netfilter/nf_conntrack_proto_tcp.c
>> index 278f3b9..7cc1d9c 100644
>> --- a/net/netfilter/nf_conntrack_proto_tcp.c
>> +++ b/net/netfilter/nf_conntrack_proto_tcp.c
>> @@ -410,6 +410,8 @@ static void tcp_options(const struct sk_buff *skb,
>> length--;
>> continue;
>> default:
>> + if (length < 2)
>> + return;
>> opsize=*ptr++;
>> if (opsize < 2) /* "silly options" */
>> return;
>> @@ -470,6 +472,8 @@ static void tcp_sack(const struct sk_buff *skb,
>> unsigned int dataoff,
>> length--;
>> continue;
>> default:
>> + if (length < 2)
>> + return;
>> opsize = *ptr++;
>> if (opsize < 2) /* "silly options" */
>> return;
I tested with the patch and it fixed the bug. Thanks.
>> Best regards,
>> Jozsef
>> -
>> E-mail : kadlec@blackhole.kfki.hu, kadlecsik.jozsef@wigner.mta.hu
>> PGP key : http://www.kfki.hu/~kadlec/pgp_public_key.txt
>> Address : Wigner Research Centre for Physics, Hungarian Academy of
>> Sciences
>> H-1525 Budapest 114, POB. 49, Hungary
>
>
^ permalink raw reply
* [PATCH] net: macb: Only call GPIO functions if there is a valid GPIO
From: Charles Keepax @ 2016-03-28 12:47 UTC (permalink / raw)
To: nicolas.ferre, davem; +Cc: netdev, linux-kernel, patches
GPIOlib will print warning messages if we call GPIO functions without a
valid GPIO. Change the code to avoid doing so.
Signed-off-by: Charles Keepax <ckeepax@opensource.wolfsonmicro.com>
---
drivers/net/ethernet/cadence/macb.c | 8 +++++---
1 file changed, 5 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/cadence/macb.c b/drivers/net/ethernet/cadence/macb.c
index 6619178..71bb42e 100644
--- a/drivers/net/ethernet/cadence/macb.c
+++ b/drivers/net/ethernet/cadence/macb.c
@@ -2957,9 +2957,10 @@ static int macb_probe(struct platform_device *pdev)
phy_node = of_get_next_available_child(np, NULL);
if (phy_node) {
int gpio = of_get_named_gpio(phy_node, "reset-gpios", 0);
- if (gpio_is_valid(gpio))
+ if (gpio_is_valid(gpio)) {
bp->reset_gpio = gpio_to_desc(gpio);
- gpiod_direction_output(bp->reset_gpio, 1);
+ gpiod_direction_output(bp->reset_gpio, 1);
+ }
}
of_node_put(phy_node);
@@ -3029,7 +3030,8 @@ static int macb_remove(struct platform_device *pdev)
mdiobus_free(bp->mii_bus);
/* Shutdown the PHY if there is a GPIO reset */
- gpiod_set_value(bp->reset_gpio, 0);
+ if (bp->reset_gpio)
+ gpiod_set_value(bp->reset_gpio, 0);
unregister_netdev(dev);
clk_disable_unprepare(bp->tx_clk);
--
2.1.4
^ permalink raw reply related
* Re: [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats
From: Grumbach, Emmanuel @ 2016-03-28 11:39 UTC (permalink / raw)
To: linuxwifi, colin.king@canonical.com, kvalo@codeaurora.org,
Sharon, Sara, netdev@vger.kernel.org, Berg, Johannes,
linux-wireless@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
In-Reply-To: <1459164824-6994-1-git-send-email-colin.king@canonical.com>
On Mon, 2016-03-28 at 12:33 +0100, Colin King wrote:
> From: Colin Ian King <colin.king@canonical.com>
>
> isr_stats is written twice with the same value, remove one of the
> redundant assignments to isr_stats.
>
> Signed-off-by: Colin Ian King <colin.king@canonical.com>
> ---
Applied - thanks.
> drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> index 4be3c35..253e4f0 100644
> --- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> +++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
> @@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq,
> void *dev_id)
> struct msix_entry *entry = dev_id;
> struct iwl_trans_pcie *trans_pcie =
> iwl_pcie_get_trans_pcie(entry);
> struct iwl_trans *trans = trans_pcie->trans;
> - struct isr_statistics *isr_stats = isr_stats = &trans_pcie
> ->isr_stats;
> + struct isr_statistics *isr_stats = &trans_pcie->isr_stats;
> u32 inta_fh, inta_hw;
>
> lock_map_acquire(&trans->sync_cmd_lockdep_map);
^ permalink raw reply
* [PATCH] iwlwifi: pcie: remove duplicate assignment of variable isr_stats
From: Colin King @ 2016-03-28 11:33 UTC (permalink / raw)
To: Johannes Berg, Emmanuel Grumbach, Intel Linux Wireless,
Kalle Valo, Sara Sharon, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Cc: linux-kernel-u79uwXL29TY76Z2rM5mHXA
From: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
isr_stats is written twice with the same value, remove one of the
redundant assignments to isr_stats.
Signed-off-by: Colin Ian King <colin.king-Z7WLFzj8eWMS+FvcfC7Uqw@public.gmane.org>
---
drivers/net/wireless/intel/iwlwifi/pcie/rx.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
index 4be3c35..253e4f0 100644
--- a/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
+++ b/drivers/net/wireless/intel/iwlwifi/pcie/rx.c
@@ -1805,7 +1805,7 @@ irqreturn_t iwl_pcie_irq_msix_handler(int irq, void *dev_id)
struct msix_entry *entry = dev_id;
struct iwl_trans_pcie *trans_pcie = iwl_pcie_get_trans_pcie(entry);
struct iwl_trans *trans = trans_pcie->trans;
- struct isr_statistics *isr_stats = isr_stats = &trans_pcie->isr_stats;
+ struct isr_statistics *isr_stats = &trans_pcie->isr_stats;
u32 inta_fh, inta_hw;
lock_map_acquire(&trans->sync_cmd_lockdep_map);
--
2.7.4
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
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