* Re: [PATCH net v2 2/3] tunnels: Don't apply GRO to multiple layers of encapsulation.
From: Tom Herbert @ 2016-03-28 16:31 UTC (permalink / raw)
To: Jesse Gross; +Cc: David Miller, Linux Kernel Network Developers
In-Reply-To: <CAEh+42hbYUMK4WMZYDtzfynd1XFb7OxKkmdPOdT1Z7=n-kw4sA@mail.gmail.com>
On Sun, Mar 27, 2016 at 9:38 PM, Jesse Gross <jesse@kernel.org> wrote:
> On Sat, Mar 26, 2016 at 12:41 PM, Tom Herbert <tom@herbertland.com> wrote:
>> On Sat, Mar 19, 2016 at 9:32 AM, Jesse Gross <jesse@kernel.org> wrote:
>>> When drivers express support for TSO of encapsulated packets, they
>>> only mean that they can do it for one layer of encapsulation.
>>> Supporting additional levels would mean updating, at a minimum,
>>> more IP length fields and they are unaware of this.
>>>
>> This patch completely breaks GRO for FOU and GUE.
>>
>>> No encapsulation device expresses support for handling offloaded
>>> encapsulated packets, so we won't generate these types of frames
>>> in the transmit path. However, GRO doesn't have a check for
>>> multiple levels of encapsulation and will attempt to build them.
>>>
>>> UDP tunnel GRO actually does prevent this situation but it only
>>> handles multiple UDP tunnels stacked on top of each other. This
>>> generalizes that solution to prevent any kind of tunnel stacking
>>> that would cause problems.
>>>
>> GUE and FOU regularly create packets that will be both GSO UDP tunnels
>> and IPIP, SIT, GRE, etc. This is by design. There should be no
>> ambiguity in the drivers as to what this means. For instance, if
>> SKB_GSO_UDP_TUNNEL and SKB_GSO_GRE are set that is GRE/UDP packet, a
>> driver can use ndo_features_check to validate.
>>
>> So multiple levels of encapsulation with GRO is perfectly valid and I
>> would suggest to simply revert this patch. The one potential issue we
>> could have is the potential for GRO to construct a packet which is a
>> UDP-encapsulation inside another encapsulation, like UDP-encap in GRE.
>> In this case the GSO flags don't provide enough information to
>> distinguish say between GRE/UDP (common case) and UDP/GRE (uncommon
>> case). To make this clear we can set udp_mark in GRE, ipip, and sit
>> but *not* check for it.
>
> Generally speaking, multiple levels of encapsulation offload are not
> valid. I think this is pretty clear from the fact that none of the
> encapsulation drivers expose support for encapsulation offloads on
> transmit and the drivers supporting NETIF_F_GSO_GRE and
> NETIF_F_GSO_UDP_TUNNEL do not mean they can handle GRE in VXLAN.
>
Kernel software offload does support this combination just fine.
Seriously, I've tested that more than a thousand times. This is a few
HW implementations you're referring to. The limitations of these
drivers should not dictate how we build the software-- it needs to
work the other way around.
> Asking drivers to assume that this combination of flags means FOU
> doesn't seem right to me. To the best of my knowledge, no driver uses
> ndo_feature_check to do validation of multiple tunnel offload flags
> since the assumption is that the stack will never try to do this.
> Since FOU is being treated as only a single level of encapsulation, I
> think it would be better to just advertise it that way on transmit
> (i.e. only set SKB_GSO_UDP_TUNNEL).
>
If it's not FOU it will be something else. Arbitrarily declaring
multi-levels of encapsulation invalid is simply the wrong direction,
we should be increasing generality and capabilities of the kernel not
holding it down with artificial limits. This is why the generic TSO
work that Alexander and Edward are looking at is so important-- if
this flies then we can offload any combination of encapsulations with
out protocol specific information.
> The change that you are suggesting would result in packets generated
> by GRO that cannot be handled properly on transmit in some cases and
> would likely end up being dropped or malformed. GRO is just an
> optimization and correctness must come first so we cannot use it if it
> might corrupt traffic.
That's (a few) drivers problem. It's no different than if they had
decided that SKB_GSO_UDP_TUNNEL means vxlan, or they can support GRE
in IPv4 offload but not GRE in IPv6, or they can only handle headers
of a certain size, can't handle IPv6 ext. hdrs., etc. As I mentioned,
the long term solution is to eliminate the GSO_ flags and use a
generic segmentation offload interface. But in the interim, it is
*incumbent* on drivers to determine if they can handle a GSO packet
and the interfaces to do that exist. Restricting the capabilities of
GRO just to appease those drivers is not right. Breaking existing GRO
for their benefit is definitely not right.
Tom
^ permalink raw reply
* Re: [RFC PATCH 7/9] GSO: Support partial segmentation offload
From: Alexander Duyck @ 2016-03-28 16:25 UTC (permalink / raw)
To: Jesse Gross
Cc: Alexander Duyck, Edward Cree, Linux Kernel Network Developers,
David Miller, Tom Herbert
In-Reply-To: <CAEh+42iqaSg5WNCsc_iJbpxtwi+mjVtH+Wg5WY5HdWF7-5eM1Q@mail.gmail.com>
On Sun, Mar 27, 2016 at 10:36 PM, Jesse Gross <jesse@kernel.org> wrote:
> On Fri, Mar 18, 2016 at 4:25 PM, Alexander Duyck <aduyck@mirantis.com> wrote:
>> diff --git a/net/core/dev.c b/net/core/dev.c
>> index edb7179bc051..666cf427898b 100644
>> --- a/net/core/dev.c
>> +++ b/net/core/dev.c
>> @@ -2711,6 +2711,19 @@ struct sk_buff *__skb_gso_segment(struct sk_buff *skb,
> [...]
>> + /* Only report GSO partial support if it will enable us to
>> + * support segmentation on this frame without needing additional
>> + * work.
>> + */
>> + if (features & NETIF_F_GSO_PARTIAL) {
>> + netdev_features_t partial_features;
>> + struct net_device *dev = skb->dev;
>> +
>> + partial_features = dev->features & dev->gso_partial_features;
>> + if (!skb_gso_ok(skb, features | partial_features))
>> + features &= ~NETIF_F_GSO_PARTIAL;
>
> I think we need to add NETIF_F_GSO_ROBUST into the skb_gso_ok() check
> - otherwise packets coming from VMs fail this test and we lose GSO
> partial. It's totally safe to expose this feature, since we'll compute
> gso_segs anyways.
Good point. I will update that before submitting for net-next.
>> diff --git a/net/core/skbuff.c b/net/core/skbuff.c
>> index f044f970f1a6..bdcba77e164c 100644
>> --- a/net/core/skbuff.c
>> +++ b/net/core/skbuff.c
>> @@ -3281,6 +3291,15 @@ perform_csum_check:
>> */
>> segs->prev = tail;
>>
>> + /* Update GSO info on first skb in partial sequence. */
>> + if (partial_segs) {
>> + skb_shinfo(segs)->gso_size = mss / partial_segs;
>
> One small thing: this gso_size is the same as the original MSS, right?
> It seems like we could trivially stick it in a local variable and
> avoid the extra division.
Nice catch. I was a bit too in the mindset of having to use the same
variable throughout.
>> + skb_shinfo(segs)->gso_segs = partial_segs;
>> + skb_shinfo(segs)->gso_type = skb_shinfo(head_skb)->gso_type |
>> + SKB_GSO_PARTIAL;
>
> Since we're computing the gso_segs ourselves, it might be nice to
> strip out SKB_GSO_DODGY when we set the type.
I will have that fixed for the version I submit for net-next.
> I just wanted to say that this is really nice work - I was expecting
> it to turn out to be really messy and unmaintainable but this is very
> clean. Thanks!
Thanks.
- Alex
^ permalink raw reply
* 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
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