* Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Florian Fainelli @ 2016-11-22 5:35 UTC (permalink / raw)
To: Andrew Lunn, Jerome Brunet
Cc: netdev, devicetree, Alexandre TORGUE, Neil Armstrong,
Martin Blumenstingl, Kevin Hilman, linux-kernel, Andre Roth,
linux-amlogic, Carlo Caione, Giuseppe Cavallaro, linux-arm-kernel
In-Reply-To: <20161121164733.GG1922@lunn.ch>
Le 21/11/2016 à 08:47, Andrew Lunn a écrit :
>> What I did not realize when doing this patch for the realtek driver is
>> that there is already 6 valid modes defined in the kernel
>>
>> #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX /*
>> 100TX EEE cap */
>> #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T /*
>> 1000T EEE cap */
>> #define MDIO_EEE_10GT 0x0008 /* 10GT EEE cap */
>> #define MDIO_EEE_1000KX 0x0010 /* 1000KX EEE cap
>> */
>> #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4 EEE cap
>> */
>> #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE cap
>> */
>>
>> I took care of only 2 in the case of realtek.c since it only support
>> MDIO_EEE_100TX and MDIO_EEE_1000T.
>>
>> Defining a property for each is certainly doable but it does not look
>> very nice either. If it extends in the future, it will get even more
>> messier, especially if you want to disable everything.
>
> Yes, agreed.
One risk with the definition a group of advertisement capabilities
(under the form of a bitmask for instance) to enable/disable is that we
end up with Device Tree contain some kind of configuration policy as
opposed to just flagging particular hardware features as broken.
Fortunately, there does not seem to be a ton of PHYs out there which
require EEE to be disabled to function properly so having individual
properties vs. bitmasks/groups is kind of speculative here.
Another approach to solving this problem could be to register a PHY
fixup which disables EEE at the PHY level, and which is only called for
specific boards affected by this problem (of_machine_is_compatible()).
This code can leave in arch/*/* when that is possible, or it can just be
somewhere where it is relevant, e.g; in the PHY driver for instance
(similarly to how PCI fixups are done).
--
Florian
^ permalink raw reply
* [PATCH] mac80211: Remove unused 'struct ieee80211_rx_status' ptr
From: Kirtika Ruchandani @ 2016-11-22 5:44 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
Commit 554891e63a29 introduced 'struct ieee80211_rx_status' in
ieee80211_rx_h_defragment but did not use it. Compiling with W=1
gives the following warning, fix it.
net/mac80211/rx.c: In function ‘ieee80211_rx_h_defragment’:
net/mac80211/rx.c:1911:30: warning: variable ‘status’ set but not used [-Wunused-but-set-variable]
Fixes: 554891e63a29 ("mac80211: move packet flags into packet")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: John W. Linville <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/rx.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/rx.c b/net/mac80211/rx.c
index eeab725..d2a00f2 100644
--- a/net/mac80211/rx.c
+++ b/net/mac80211/rx.c
@@ -1908,7 +1908,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
unsigned int frag, seq;
struct ieee80211_fragment_entry *entry;
struct sk_buff *skb;
- struct ieee80211_rx_status *status;
hdr = (struct ieee80211_hdr *)rx->skb->data;
fc = hdr->frame_control;
@@ -2034,9 +2033,6 @@ ieee80211_rx_h_defragment(struct ieee80211_rx_data *rx)
dev_kfree_skb(skb);
}
- /* Complete frame has been reassembled - process it now */
- status = IEEE80211_SKB_RXCB(rx->skb);
^ permalink raw reply related
* [PATCH] mac80211: Remove unused 'rates_idx' variable
From: Kirtika Ruchandani @ 2016-11-22 6:04 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Felix Fietkau, Johannes Berg
Commit f027c2aca0cf introduced 'rates_idx' in
ieee80211_tx_status_noskb but did not use it. Compiling with W=1
gives the following warning, fix it.
mac80211/status.c: In function ‘ieee80211_tx_status_noskb’:
mac80211/status.c:636:6: warning: variable ‘rates_idx’ set but not used [-Wunused-but-set-variable]
This is a harmless warning, and is only being fixed to reduce the
noise generated with W=1.
Fixes: f027c2aca0cf ("mac80211: add ieee80211_tx_status_noskb")
Cc: Johannes Berg <johannes.berg-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: Felix Fietkau <nbd-p3rKhJxN3npAfugRpC6u6w@public.gmane.org>
Signed-off-by: Kirtika Ruchandani <kirtika-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
---
net/mac80211/status.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index ddf71c6..f7c5ae5 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -633,10 +633,9 @@ void ieee80211_tx_status_noskb(struct ieee80211_hw *hw,
struct ieee80211_local *local = hw_to_local(hw);
struct ieee80211_supported_band *sband;
int retry_count;
- int rates_idx;
bool acked, noack_success;
- rates_idx = ieee80211_tx_get_rates(hw, info, &retry_count);
+ ieee80211_tx_get_rates(hw, info, &retry_count);
sband = hw->wiphy->bands[info->band];
--
2.8.0.rc3.226.g39d4020
^ permalink raw reply related
* [net] rtnetlink: fix the wrong minimal dump size getting from rtnl_calcit()
From: Zhang Shengju @ 2016-11-22 6:14 UTC (permalink / raw)
To: netdev, davem; +Cc: roopa
For RT netlink, calcit() function should return the minimal size for
netlink dump message. This will make sure that dump message for every
network device can be stored.
Currently, rtnl_calcit() function doesn't account the size of header of
netlink message, this patch will fix it.
Signed-off-by: Zhang Shengju <zhangshengju@cmss.chinamobile.com>
---
net/core/rtnetlink.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/core/rtnetlink.c b/net/core/rtnetlink.c
index f4b9350..09e115b 100644
--- a/net/core/rtnetlink.c
+++ b/net/core/rtnetlink.c
@@ -2734,7 +2734,7 @@ static u16 rtnl_calcit(struct sk_buff *skb, struct nlmsghdr *nlh)
ext_filter_mask));
}
- return min_ifinfo_dump_size;
+ return nlmsg_total_size(min_ifinfo_dump_size);
}
static int rtnl_dump_all(struct sk_buff *skb, struct netlink_callback *cb)
--
1.8.3.1
^ permalink raw reply related
* [PATCH] ipv6:ipv6_pinfo dereferenced after NULL check
From: Manjeet Pawar @ 2016-11-22 6:27 UTC (permalink / raw)
To: davem, kuznet, jmorris, yoshfuji, kaber, netdev, linux-kernel
Cc: pankaj.m, ajeet.y, Rohit Thapliyal, Manjeet Pawar
From: Rohit Thapliyal <r.thapliyal@samsung.com>
np checked for NULL and then dereferenced. It should be modified
for NULL case.
Signed-off-by: Rohit Thapliyal <r.thapliyal@samsung.com>
Signed-off-by: Manjeet Pawar <manjeet.p@samsung.com>
---
net/ipv6/ip6_output.c | 9 +++++----
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 1dfc402..c2afa14 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -205,14 +205,15 @@ int ip6_xmit(const struct sock *sk, struct sk_buff *skb, struct flowi6 *fl6,
/*
* Fill in the IPv6 header
*/
- if (np)
+ if (np) {
hlimit = np->hop_limit;
+ ip6_flow_hdr(
+ hdr, tclass, ip6_make_flowlabel(
+ net, skb, fl6->flowlabel,
+ np->autoflowlabel, fl6));
+ }
if (hlimit < 0)
hlimit = ip6_dst_hoplimit(dst);
- ip6_flow_hdr(hdr, tclass, ip6_make_flowlabel(net, skb, fl6->flowlabel,
- np->autoflowlabel, fl6));
-
hdr->payload_len = htons(seg_len);
hdr->nexthdr = proto;
hdr->hop_limit = hlimit;
--
1.9.1
^ permalink raw reply related
* Re: [mm PATCH v3 21/23] mm: Add support for releasing multiple instances of a page
From: Andrew Morton @ 2016-11-22 6:28 UTC (permalink / raw)
To: Alexander Duyck
Cc: Alexander Duyck, linux-mm, Netdev, linux-kernel@vger.kernel.org
In-Reply-To: <CAKgT0UfoS-JC66hHV14E-hgmrhGdz4oYpmHve=01A1X8o8O=rw@mail.gmail.com>
On Mon, 21 Nov 2016 08:21:39 -0800 Alexander Duyck <alexander.duyck@gmail.com> wrote:
> >> + __free_pages_ok(page, order);
> >> + }
> >> +}
> >> +EXPORT_SYMBOL(__page_frag_drain);
> >
> > It's an exported-to-modules library function. It should be documented,
> > please? The page-frag API is only partially documented, but that's no
> > excuse.
>
> Okay. I assume you want the documentation as a follow-up patch since
> I received a notice that the patch was added to -mm?
Yes please. Or a replacement patch which I'll temporarily turn into a
delta, either is fine.
> If you would like I could look at doing a couple of renaming patches
> so that we make the API a bit more consistent. I could move the
> __alloc and __free to what you have suggested, and then take a look at
> trying to rename the refill/drain to be a bit more consistent in terms
> of what they are supposed to work on and how they are supposed to be
> used.
I think that would be better - it's hardly high-priority but a bit of
attention to the documentation and naming conventions would help tidy
things up. When you can't find anything else to do ;)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCH net 1/1] net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit
From: Gao Feng @ 2016-11-22 6:32 UTC (permalink / raw)
To: Cong Wang
Cc: Eric Dumazet, David Miller, javier,
Linux Kernel Network Developers
In-Reply-To: <CAM_iQpX-z8Eja4rPg5dzAXLXd6v3nwMMPev-gk+wM9XLBNYK1A@mail.gmail.com>
Hi Cong,
On Tue, Nov 22, 2016 at 1:29 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
> On Sun, Nov 20, 2016 at 4:56 PM, <fgao@ikuai8.com> wrote:
>> From: Gao Feng <gfree.wind@gmail.com>
>>
>> The tc could return NET_XMIT_CN as one congestion notification, but
>> it does not mean the packe is lost. Other modules like ipvlan,
>> macvlan, and others treat NET_XMIT_CN as success too.
>> So l2tp_eth_dev_xmit should add the NET_XMIT_CN check.
>>
>> Signed-off-by: Gao Feng <gfree.wind@gmail.com>
>> ---
>> net/l2tp/l2tp_eth.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
>> index 965f7e3..3dc97b4 100644
>> --- a/net/l2tp/l2tp_eth.c
>> +++ b/net/l2tp/l2tp_eth.c
>> @@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
>> unsigned int len = skb->len;
>> int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
>>
>> - if (likely(ret == NET_XMIT_SUCCESS)) {
>> + if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
>
> How could l2tp_xmit_skb() possibly return NET_XMIT_CN?
> Note It ignores the return value of l2tp_xmit_core().
You are right. I didn't think about it.
Regards
Feng
^ permalink raw reply
* [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Kirtika Ruchandani @ 2016-11-22 6:54 UTC (permalink / raw)
To: Johannes Berg
Cc: Arnd Bergmann, linux-wireless, netdev, Maxim Altshul,
Johannes Berg
Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
leaving variable 'struct rate_control_ref* ref' set but unused.
Compiling with W=1 gives the following warning, fix it.
net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not used [-Wunused-but-set-variable]
Fixes: 3b17fbf87d5d ("mac80211: mesh: Add support for HW RC implementation")
Cc: Johannes Berg <johannes.berg@intel.com>
Cc: Maxim Altshul <maxim.altshul@ti.com>
Signed-off-by: Kirtika Ruchandani <kirtika@google.com>
---
net/mac80211/sta_info.c | 4 ----
1 file changed, 4 deletions(-)
diff --git a/net/mac80211/sta_info.c b/net/mac80211/sta_info.c
index 1711bae..4ab75a9 100644
--- a/net/mac80211/sta_info.c
+++ b/net/mac80211/sta_info.c
@@ -2049,16 +2049,12 @@ void sta_set_sinfo(struct sta_info *sta, struct station_info *sinfo)
{
struct ieee80211_sub_if_data *sdata = sta->sdata;
struct ieee80211_local *local = sdata->local;
- struct rate_control_ref *ref = NULL;
u32 thr = 0;
int i, ac, cpu;
struct ieee80211_sta_rx_stats *last_rxstats;
last_rxstats = sta_get_last_rx_stats(sta);
- if (test_sta_flag(sta, WLAN_STA_RATE_CONTROL))
- ref = local->rate_ctrl;
-
sinfo->generation = sdata->local->sta_generation;
/* do before driver, so beacon filtering drivers have a
^ permalink raw reply related
* Re: [PATCH] bnxt_en: Fix a VXLAN vs GENEVE issue
From: Michael Chan @ 2016-11-22 7:15 UTC (permalink / raw)
To: Christophe JAILLET
Cc: David Miller, Prashant Sreedharan, Netdev, kernel-janitors
In-Reply-To: <20161122051440.9748-1-christophe.jaillet@wanadoo.fr>
On Mon, Nov 21, 2016 at 9:14 PM, Christophe JAILLET
<christophe.jaillet@wanadoo.fr> wrote:
> Knowing that:
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_VXLAN (0x1UL << 0)
> #define TUNNEL_DST_PORT_FREE_REQ_TUNNEL_TYPE_GENEVE (0x5UL << 0)
> and that 'bnxt_hwrm_tunnel_dst_port_alloc()' is only called with one of
> these 2 constants, the TUNNEL_DST_PORT_ALLOC_REQ_TUNNEL_TYPE_GENEVE can not
> trigger.
>
> Replace the bit test that overlap by an equality test, just as in
> 'bnxt_hwrm_tunnel_dst_port_free()' above.
>
> Signed-off-by: Christophe JAILLET <christophe.jaillet@wanadoo.fr>
Thanks.
Acked-by: Michael Chan <michael.chan@broadcom.com>
^ permalink raw reply
* [Patch net] net: revert "net: l2tp: Treat NET_XMIT_CN as success in l2tp_eth_dev_xmit"
From: Cong Wang @ 2016-11-22 7:24 UTC (permalink / raw)
To: netdev; +Cc: Cong Wang, Gao Feng
This reverts commit 7c6ae610a1f0, because l2tp_xmit_skb() never
returns NET_XMIT_CN, it ignores the return value of l2tp_xmit_core().
Cc: Gao Feng <gfree.wind@gmail.com>
Signed-off-by: Cong Wang <xiyou.wangcong@gmail.com>
---
net/l2tp/l2tp_eth.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/l2tp/l2tp_eth.c b/net/l2tp/l2tp_eth.c
index 3dc97b4..965f7e3 100644
--- a/net/l2tp/l2tp_eth.c
+++ b/net/l2tp/l2tp_eth.c
@@ -97,7 +97,7 @@ static int l2tp_eth_dev_xmit(struct sk_buff *skb, struct net_device *dev)
unsigned int len = skb->len;
int ret = l2tp_xmit_skb(session, skb, session->hdr_len);
- if (likely(ret == NET_XMIT_SUCCESS || ret == NET_XMIT_CN)) {
+ if (likely(ret == NET_XMIT_SUCCESS)) {
atomic_long_add(len, &priv->tx_bytes);
atomic_long_inc(&priv->tx_packets);
} else {
--
1.8.4.5
^ permalink raw reply related
* Re: [PATCH] mac80211: Remove unused 'struct rate_control_ref' variable
From: Johannes Berg @ 2016-11-22 7:30 UTC (permalink / raw)
To: Kirtika Ruchandani
Cc: Arnd Bergmann, linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Maxim Altshul
In-Reply-To: <20161122065416.GA3565-hpIqsD4AKlfQT0dZR+AlfA@public.gmane.org>
On Mon, 2016-11-21 at 22:54 -0800, Kirtika Ruchandani wrote:
> Commit 3b17fbf87d5d introduced sta_get_expected_throughput()
> leaving variable 'struct rate_control_ref* ref' set but unused.
> Compiling with W=1 gives the following warning, fix it.
>
> net/mac80211/sta_info.c: In function ‘sta_set_sinfo’:
> net/mac80211/sta_info.c:2052:27: warning: variable ‘ref’ set but not
> used [-Wunused-but-set-variable]
Applied all three of these, thanks Kirtika.
johannes
^ permalink raw reply
* Re: [PATCH] net: ioctl SIOCSIFADDR minor cleanup
From: Cong Wang @ 2016-11-22 7:32 UTC (permalink / raw)
To: YUAN Linyu; +Cc: David Miller, cugyly@163.com, netdev@vger.kernel.org
In-Reply-To: <8729016553E3654398EA69218DA29EEF0E431D3A@cnshjmbx02>
On Mon, Nov 21, 2016 at 8:30 PM, YUAN Linyu
<Linyu.Yuan@alcatel-sbell.com.cn> wrote:
> I think there are newbie include me still use ifconfig utility.
> So when I check this code, it can be optimized.
>
Working on Linux kernel is always welcome.
But I don't think this can convince DaveM to take your patch even
if it is really correct (I never check).
^ permalink raw reply
* Re: [PATCH iproute2 2/2] tc/act_tunnel: Introduce ip tunnel action
From: Amir Vadai @ 2016-11-22 7:50 UTC (permalink / raw)
To: Rosen, Rami
Cc: Stephen Hemminger, David S. Miller, netdev@vger.kernel.org,
Or Gerlitz, Hadar Har-Zion, Roi Dayan
In-Reply-To: <9B0331B6EBBD0E4684FBFAEDA55776F93D345ED8@HASMSX110.ger.corp.intel.com>
On Mon, Nov 21, 2016 at 11:50:03PM +0000, Rosen, Rami wrote:
> Hi, Amir,
>
> Following are three minor comments:
>
> Seems that TCA_TUNNEL_KEY_PAD used anywhere:
I assume you ment that it is _NOT_ used anywhere:
This attribute type is used in the kernel side only - for padding 64bit
attributes. The userspace enum should match the kernel include/uapi one.
>
> + TCA_TUNNEL_KEY_PAD,
> + __TCA_TUNNEL_KEY_MAX,
> +};
>
>
> Should be "and destination IP 11.11.0.2" instead of "and destination IP 11.11.0.1":
ack
>
> +Tunnel ID (for example VNI in VXLAN tunnel) .TP .B src_ip Outer header
> +source IP address (IPv4 or IPv6) .TP .B dst_ip Outer header destination
> +IP address (IPv4 or IPv6) .RE .SH EXAMPLES The following example
> +encapsulates incoming ICMP packets on eth0 into a vxlan tunnel by
> +setting metadata to VNI 11, source IP 11.11.0.1 and destination IP
> +11.11.0.1 by forwarding the skb with the metadata to device vxlan0,
> +which will prepare the VXLAN headers:
> +
> +.RS
> +.EX
> +#tc qdisc add dev eth0 handle ffff: ingress #tc filter add dev eth0
> +protocol ip parent ffff: \\
> + flower \\
> + ip_proto icmp \\
> + action tunnel_key set \\
> + src_ip 11.11.0.1 \\
> + dst_ip 11.11.0.2 \\
> + id 11 \\
>
>
> Typo: should be "ip tunnel" instead of "ip tunel":
ack
>
> + * m_tunnel_key.c ip tunel manipulation module
> + *
> + * This program is free software; you can redistribute it and/or
>
> Keep on the good work!
Thanks for reviewing,
Amir
>
> Regards,
> Rami Rosen
> Intel Corporation
^ permalink raw reply
* Re: [net-next PATCH v2 1/5] net: virtio dynamically disable/enable LRO
From: John Fastabend @ 2016-11-22 8:16 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <20161122012202-mutt-send-email-mst@kernel.org>
On 16-11-21 03:23 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 19, 2016 at 06:49:34PM -0800, John Fastabend wrote:
>> This adds support for dynamically setting the LRO feature flag. The
>> message to control guest features in the backend uses the
>> CTRL_GUEST_OFFLOADS msg type.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>> ---
>> drivers/net/virtio_net.c | 45 ++++++++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 44 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/net/virtio_net.c b/drivers/net/virtio_net.c
>> index ca5239a..8189e5b 100644
>> --- a/drivers/net/virtio_net.c
>> +++ b/drivers/net/virtio_net.c
>> @@ -1419,6 +1419,41 @@ static void virtnet_init_settings(struct net_device *dev)
>> .set_settings = virtnet_set_settings,
>> };
>>
>> +static int virtnet_set_features(struct net_device *netdev,
>> + netdev_features_t features)
>> +{
>> + struct virtnet_info *vi = netdev_priv(netdev);
>> + struct virtio_device *vdev = vi->vdev;
>> + struct scatterlist sg;
>> + u64 offloads = 0;
>> +
>> + if (features & NETIF_F_LRO)
>> + offloads |= (1 << VIRTIO_NET_F_GUEST_TSO4) |
>> + (1 << VIRTIO_NET_F_GUEST_TSO6);
>> +
>> + if (features & NETIF_F_RXCSUM)
>> + offloads |= (1 << VIRTIO_NET_F_GUEST_CSUM);
>> +
>> + if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS)) {
>> + sg_init_one(&sg, &offloads, sizeof(uint64_t));
>> + if (!virtnet_send_command(vi,
>> + VIRTIO_NET_CTRL_GUEST_OFFLOADS,
>> + VIRTIO_NET_CTRL_GUEST_OFFLOADS_SET,
>> + &sg)) {
>> + dev_warn(&netdev->dev,
>> + "Failed to set guest offloads by virtnet command.\n");
>> + return -EINVAL;
>> + }
>> + } else if (virtio_has_feature(vdev, VIRTIO_NET_F_CTRL_GUEST_OFFLOADS) &&
>> + !virtio_has_feature(vdev, VIRTIO_F_VERSION_1)) {
>> + dev_warn(&netdev->dev,
>> + "No support for setting offloads pre version_1.\n");
>> + return -EINVAL;
>> + }
>
> I don't get this last warning. VIRTIO_NET_F_CTRL_GUEST_OFFLOADS
> was exposes by legacy devices, I don't think it's related to
> VIRTIO_F_VERSION_1.
>
OK looks like I can just drop the else if branch here.
Thanks,
John
^ permalink raw reply
* Re: [net-next PATCH v2 4/5] virtio_net: add dedicated XDP transmit queues
From: John Fastabend @ 2016-11-22 8:17 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <20161121234008-mutt-send-email-mst@kernel.org>
On 16-11-21 03:13 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 19, 2016 at 06:51:04PM -0800, John Fastabend wrote:
>> XDP requires using isolated transmit queues to avoid interference
>> with normal networking stack (BQL, NETDEV_TX_BUSY, etc). This patch
>> adds a XDP queue per cpu when a XDP program is loaded and does not
>> expose the queues to the OS via the normal API call to
>> netif_set_real_num_tx_queues(). This way the stack will never push
>> an skb to these queues.
>>
>> However virtio/vhost/qemu implementation only allows for creating
>> TX/RX queue pairs at this time so creating only TX queues was not
>> possible. And because the associated RX queues are being created I
>> went ahead and exposed these to the stack and let the backend use
>> them. This creates more RX queues visible to the network stack than
>> TX queues which is worth mentioning but does not cause any issues as
>> far as I can tell.
>>
>> Signed-off-by: John Fastabend <john.r.fastabend@intel.com>
>
> FYI what's supposed to happen is packets from the same
> flow going in the reverse direction will go on the
> same queue.
>
> This might come in handy when implementing RX XDP.
>
Yeah but if its the first packet not part of a flow then presumably it
can pick any queue but its worth keeping in mind certainly.
.John
^ permalink raw reply
* Re: linux-next: build warnings after merge of the net-next tree
From: Thomas Petazzoni @ 2016-11-22 8:23 UTC (permalink / raw)
To: Florian Fainelli
Cc: Stephen Rothwell, David Miller, Networking, linux-next,
linux-kernel, Gregory Clement
In-Reply-To: <e5c5a4d7-355e-b8a6-9526-d6acbe4e54f8@gmail.com>
Hello,
On Mon, 21 Nov 2016 17:28:39 -0800, Florian Fainelli wrote:
> +Thomas, Gregory,
>
> On 11/21/2016 05:22 PM, Stephen Rothwell wrote:
> [snip]
> >
> > Introduced by commit
> >
> > a0627f776a45 ("net: marvell: Allow drivers to be built with COMPILE_TEST")
> >
> > "a few warnings" is a matter of perception. :-(
>
> Thomas, based on our IRC conversation, do you already have patches for
> mvneta and mvpp2 to build without warning on 64-bit or should I prepare
> patches for these?
Yes, we already have patches for making mvneta and mvpp2 build without
warning for 64-bit (Grégory for mvneta, and myself for mvpp2). I
intended to send the mvpp2 ones together with patches adding support
for a new variant of the IP, but I guess I can send just the few ones
that make it 64-bit "buildable".
Best regards,
Thomas
--
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
^ permalink raw reply
* Re: [net-next PATCH v2 3/5] virtio_net: Add XDP support
From: John Fastabend @ 2016-11-22 8:27 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: daniel, eric.dumazet, kubakici, shm, davem, alexei.starovoitov,
netdev, bblanco, john.r.fastabend, brouer, tgraf
In-Reply-To: <20161122011638-mutt-send-email-mst@kernel.org>
On 16-11-21 03:20 PM, Michael S. Tsirkin wrote:
> On Sat, Nov 19, 2016 at 06:50:33PM -0800, John Fastabend wrote:
>> From: Shrijeet Mukherjee <shrijeet@gmail.com>
>>
>> This adds XDP support to virtio_net. Some requirements must be
>> met for XDP to be enabled depending on the mode. First it will
>> only be supported with LRO disabled so that data is not pushed
>> across multiple buffers. The MTU must be less than a page size
>> to avoid having to handle XDP across multiple pages.
>>
>> If mergeable receive is enabled this first series only supports
>> the case where header and data are in the same buf which we can
>> check when a packet is received by looking at num_buf. If the
>> num_buf is greater than 1 and a XDP program is loaded the packet
>> is dropped and a warning is thrown. When any_header_sg is set this
>> does not happen and both header and data is put in a single buffer
>> as expected so we check this when XDP programs are loaded. Note I
>> have only tested this with Linux vhost backend.
>>
>> If big packets mode is enabled and MTU/LRO conditions above are
>> met then XDP is allowed.
>>
>> A follow on patch can be generated to solve the mergeable receive
>> case with num_bufs equal to 2. Buffers greater than two may not
>> be handled has easily.
>
>
> I would very much prefer support for other layouts without drops
> before merging this.
> header by itself can certainly be handled by skipping it.
> People wanted to use that e.g. for zero copy.
OK fair enough I'll do this now rather than push it out.
>
> Anything else can be handled by copying the packet.
This though I'm not so sure about. The copy is going to be slow and
I wonder if someone could craft a packet to cause this if it could
be used to slow down a system.
Also I can't see what would cause this to happen. With mergeable
buffers and LRO off the num_bufs is either 1 or 2 depending on where
the header is. Otherwise with LRO off it should be in a single page.
At least this is the Linux vhost implementation, I guess other
implementation might meet spec but use num_buf > 2 or multiple pages
even in the non LRO case.
I tend to think dropping the packet out right is better than copying
it around. At very least if we do this we need to put in warnings so
users can see something is mis-configured.
.John
^ permalink raw reply
* Re: Synopsys Ethernet QoS Driver
From: Ozgur Karatas @ 2016-11-22 8:38 UTC (permalink / raw)
To: Giuseppe CAVALLARO, Joao Pinto, Rayagond Kokatanur, Rabin Vincent
Cc: andreas.irestal@axis.com, alexandre.torgue@st.com,
saeedm@mellanox.com, netdev, linux-kernel@vger.kernel.org,
CARLOS.PALMINHA@synopsys.com, idosch@mellanox.com, mued dib,
jiri@mellanox.com, Jeff Kirsher, David Miller,
linux-arm-kernel@lists.infradead.org, lars.persson@axis.com
In-Reply-To: <937252db-9538-2cf6-c8fa-82b558531c51@st.com>
Hello all,
I think, ethtool and mdio don't work because the tool's not support to "QoS", right?
Maybe, need a new API. I'm looking for dwceqos code but "tc" tools is very idea.
I hope to be me always helpful.
Regards,
Ozgur
21.11.2016, 16:38, "Giuseppe CAVALLARO" <peppe.cavallaro@st.com>:
> Hello Joao
>
> On 11/21/2016 2:48 PM, Joao Pinto wrote:
>> Synopsys QoS IP is a separated hardware component, so it should be reusable by
>> all implementations using it and so have its own "core driver" and platform +
>> pci glue drivers. This is necessary for example in hardware validation, where
>> you prototype an IP and instantiate its drivers and test it.
>>
>> Was there a strong reason to integrate QoS features directly in stmmac and not
>> in synopsys/dwc_eth_qos.*?
>
> We decided to enhance the stmmac on supporting the QoS for several
> reasons; for example the common APIs that the driver already exposed and
> actually suitable for other SYNP chips. Then, PTP, EEE,
> S/RGMII, MMC could be shared among different chips with a minimal
> effort. This meant a lot of code already ready.
>
> For sure, the net-core, Ethtool, mdio parts were reused. Same for the
> glue logic files.
> For the latter, this helped to easily bring-up new platforms also
> because the stmmac uses the HW cap register to auto-configure many
> parts of the MAC core, DMA and modules. This helped many users, AFAIK.
>
> For validation purpose, this is my experience, the stmmac helped
> a lot because people used the same code to validate different HW
> and it was easy to switch to a platform to another one in order to
> verify / check if the support was ok or if a regression was introduced.
> This is important for complex supports like PTP or EEE.
>
> Hoping this can help.
>
> Do not hesitate to contact me for further details
>
> peppe
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* net/can: use-after-free in bcm_rx_thr_flush
From: Andrey Konovalov @ 2016-11-22 9:22 UTC (permalink / raw)
To: Oliver Hartkopp, Marc Kleine-Budde, David S. Miller, linux-can,
netdev, LKML
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
[-- Attachment #1: Type: text/plain, Size: 5259 bytes --]
Hi,
I've got the following error report while fuzzing the kernel with syzkaller.
A reproducer is attached.
You may need to run it a few times.
On commit 9c763584b7c8911106bb77af7e648bef09af9d80 (4.9-rc6, Nov 20).
==================================================================
BUG: KASAN: use-after-free in bcm_rx_thr_flush+0x284/0x2b0
Read of size 1 at addr ffff88006c1faae5 by task a.out/3874
page:ffffea0001b07e80 count:1 mapcount:0 mapping: (null) index:0x0
flags: 0x100000000000080(slab)
page dumped because: kasan: bad access detected
CPU: 1 PID: 3874 Comm: a.out Not tainted 4.9.0-rc6+ #427
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
ffff88006ab07900 ffffffff81b472e4 ffff88006ab07990 ffff88006c1faae5
00000000000000fa 00000000000000fb ffff88006ab07980 ffffffff8150ad42
ffff88006323ce58 0000000000000246 ffff880068ca8000 0000000000000282
Call Trace:
[< inline >] __dump_stack lib/dump_stack.c:15
[<ffffffff81b472e4>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
[< inline >] describe_address mm/kasan/report.c:259
[<ffffffff8150ad42>] kasan_report_error+0x122/0x560 mm/kasan/report.c:365
[< inline >] kasan_report mm/kasan/report.c:387
[<ffffffff8150b1be>] __asan_report_load1_noabort+0x3e/0x40
mm/kasan/report.c:405
[< inline >] bcm_rx_do_flush net/can/bcm.c:589
[<ffffffff83577e04>] bcm_rx_thr_flush+0x284/0x2b0 net/can/bcm.c:612
[< inline >] bcm_rx_setup net/can/bcm.c:1199
[<ffffffff83578b36>] bcm_sendmsg+0xbb6/0x30e0 net/can/bcm.c:1351
[< inline >] sock_sendmsg_nosec net/socket.c:621
[<ffffffff82b7176c>] sock_sendmsg+0xcc/0x110 net/socket.c:631
[<ffffffff82b73651>] ___sys_sendmsg+0x771/0x8b0 net/socket.c:1954
[<ffffffff82b7563e>] __sys_sendmsg+0xce/0x170 net/socket.c:1988
[< inline >] SYSC_sendmsg net/socket.c:1999
[<ffffffff82b7570d>] SyS_sendmsg+0x2d/0x50 net/socket.c:1995
[<ffffffff83fc4301>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
The buggy address belongs to the object at ffff88006c1faae0
which belongs to the cache kmalloc-32 of size 32
The buggy address ffff88006c1faae5 is located 5 bytes inside
of 32-byte region [ffff88006c1faae0, ffff88006c1fab00)
Freed by task 2013:
[<ffffffff8107e236>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff81509e56>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff8150a6b3>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
[< inline >] slab_free_hook mm/slub.c:1352
[< inline >] slab_free_freelist_hook mm/slub.c:1374
[< inline >] slab_free mm/slub.c:2951
[<ffffffff81506b98>] kfree+0xe8/0x2b0 mm/slub.c:3871
[<ffffffff819dd8c1>] selinux_cred_free+0x51/0x80 security/selinux/hooks.c:3725
[<ffffffff819ce358>] security_cred_free+0x48/0x80 security/security.c:907
[<ffffffff8117e27d>] put_cred_rcu+0xed/0x390 kernel/cred.c:116
[< inline >] __rcu_reclaim kernel/rcu/rcu.h:118
[< inline >] rcu_do_batch kernel/rcu/tree.c:2776
[< inline >] invoke_rcu_callbacks kernel/rcu/tree.c:3040
[< inline >] __rcu_process_callbacks kernel/rcu/tree.c:3007
[<ffffffff8125dfe0>] rcu_process_callbacks+0xa40/0x1190 kernel/rcu/tree.c:3024
[<ffffffff83fc70af>] __do_softirq+0x23f/0x8e5 kernel/softirq.c:284
Allocated by task 1826:
[<ffffffff8107e236>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
[<ffffffff81509e56>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
[< inline >] set_track mm/kasan/kasan.c:507
[<ffffffff8150a0cb>] kasan_kmalloc+0xab/0xe0 mm/kasan/kasan.c:598
[<ffffffff8150a632>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:537
[< inline >] slab_post_alloc_hook mm/slab.h:417
[< inline >] slab_alloc_node mm/slub.c:2708
[< inline >] slab_alloc mm/slub.c:2716
[<ffffffff815090ef>] __kmalloc_track_caller+0xcf/0x2a0 mm/slub.c:4240
[<ffffffff8146bf84>] kmemdup+0x24/0x50 mm/util.c:113
[<ffffffff819dcbe9>] selinux_cred_prepare+0x49/0xb0
security/selinux/hooks.c:3739
[<ffffffff819ce40d>] security_prepare_creds+0x7d/0xb0 security/security.c:912
[<ffffffff8117fab3>] prepare_creds+0x243/0x340 kernel/cred.c:277
[<ffffffff81181bab>] copy_creds+0x7b/0x5c0 kernel/cred.c:343
[<ffffffff81109c6e>] copy_process.part.45+0x86e/0x5b50 kernel/fork.c:1529
[< inline >] copy_process kernel/fork.c:1479
[<ffffffff8110f2fa>] _do_fork+0x1ba/0xcc0 kernel/fork.c:1933
[< inline >] SYSC_clone kernel/fork.c:2043
[<ffffffff8110fed7>] SyS_clone+0x37/0x50 kernel/fork.c:2037
[<ffffffff81006465>] do_syscall_64+0x195/0x490 arch/x86/entry/common.c:280
[<ffffffff83fc43c9>] return_from_SYSCALL_64+0x0/0x7a
arch/x86/entry/entry_64.S:251
Memory state around the buggy address:
ffff88006c1fa980: fc fc fb fb fb fb fc fc fb fb fb fb fc fc fb fb
ffff88006c1faa00: fb fb fc fc fb fb fb fb fc fc fb fb fb fb fc fc
>ffff88006c1faa80: fb fb fb fb fc fc fb fb fb fb fc fc fb fb fb fb
^
ffff88006c1fab00: fc fc fb fb fb fb fc fc 00 00 00 00 fc fc 00 00
ffff88006c1fab80: 00 00 fc fc fb fb fb fb fc fc fb fb fb fb fc fc
==================================================================
Thanks!
[-- Attachment #2: bcm-rx-uaf-poc.c --]
[-- Type: text/x-csrc, Size: 7860 bytes --]
// autogenerated by syzkaller (http://github.com/google/syzkaller)
#ifndef __NR_socket
#define __NR_socket 41
#endif
#ifndef __NR_syz_fuse_mount
#define __NR_syz_fuse_mount 1000004
#endif
#ifndef __NR_syz_fuseblk_mount
#define __NR_syz_fuseblk_mount 1000005
#endif
#ifndef __NR_syz_open_pts
#define __NR_syz_open_pts 1000003
#endif
#ifndef __NR_syz_test
#define __NR_syz_test 1000001
#endif
#ifndef __NR_mmap
#define __NR_mmap 9
#endif
#ifndef __NR_connect
#define __NR_connect 42
#endif
#ifndef __NR_sendmsg
#define __NR_sendmsg 46
#endif
#ifndef __NR_syz_open_dev
#define __NR_syz_open_dev 1000002
#endif
#include <sys/ioctl.h>
#include <sys/socket.h>
#include <sys/stat.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <net/if_arp.h>
#include <errno.h>
#include <error.h>
#include <fcntl.h>
#include <pthread.h>
#include <setjmp.h>
#include <signal.h>
#include <stddef.h>
#include <stdint.h>
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
__thread int skip_segv;
__thread jmp_buf segv_env;
static void segv_handler(int sig, siginfo_t* info, void* uctx)
{
if (__atomic_load_n(&skip_segv, __ATOMIC_RELAXED))
_longjmp(segv_env, 1);
exit(sig);
}
static void install_segv_handler()
{
struct sigaction sa;
memset(&sa, 0, sizeof(sa));
sa.sa_sigaction = segv_handler;
sa.sa_flags = SA_NODEFER | SA_SIGINFO;
sigaction(SIGSEGV, &sa, NULL);
sigaction(SIGBUS, &sa, NULL);
}
#define NONFAILING(...) \
{ \
__atomic_fetch_add(&skip_segv, 1, __ATOMIC_SEQ_CST); \
if (_setjmp(segv_env) == 0) { \
__VA_ARGS__; \
} \
__atomic_fetch_sub(&skip_segv, 1, __ATOMIC_SEQ_CST); \
}
static uintptr_t syz_open_dev(uintptr_t a0, uintptr_t a1, uintptr_t a2)
{
if (a0 == 0xc || a0 == 0xb) {
char buf[128];
sprintf(buf, "/dev/%s/%d:%d", a0 == 0xc ? "char" : "block",
(uint8_t)a1, (uint8_t)a2);
return open(buf, O_RDWR, 0);
} else {
char buf[1024];
char* hash;
strncpy(buf, (char*)a0, sizeof(buf));
buf[sizeof(buf) - 1] = 0;
while ((hash = strchr(buf, '#'))) {
*hash = '0' + (char)(a1 % 10);
a1 /= 10;
}
return open(buf, a2, 0);
}
}
static uintptr_t syz_open_pts(uintptr_t a0, uintptr_t a1)
{
int ptyno = 0;
if (ioctl(a0, TIOCGPTN, &ptyno))
return -1;
char buf[128];
sprintf(buf, "/dev/pts/%d", ptyno);
return open(buf, a1, 0);
}
static uintptr_t syz_fuse_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5)
{
uint64_t target = a0;
uint64_t mode = a1;
uint64_t uid = a2;
uint64_t gid = a3;
uint64_t maxread = a4;
uint64_t flags = a5;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
char buf[1024];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, "", target, "fuse", flags, buf);
return fd;
}
static uintptr_t syz_fuseblk_mount(uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7)
{
uint64_t target = a0;
uint64_t blkdev = a1;
uint64_t mode = a2;
uint64_t uid = a3;
uint64_t gid = a4;
uint64_t maxread = a5;
uint64_t blksize = a6;
uint64_t flags = a7;
int fd = open("/dev/fuse", O_RDWR);
if (fd == -1)
return fd;
if (syscall(SYS_mknodat, AT_FDCWD, blkdev, S_IFBLK, makedev(7, 199)))
return fd;
char buf[256];
sprintf(buf, "fd=%d,user_id=%ld,group_id=%ld,rootmode=0%o", fd,
(long)uid, (long)gid, (unsigned)mode & ~3u);
if (maxread != 0)
sprintf(buf + strlen(buf), ",max_read=%ld", (long)maxread);
if (blksize != 0)
sprintf(buf + strlen(buf), ",blksize=%ld", (long)blksize);
if (mode & 1)
strcat(buf, ",default_permissions");
if (mode & 2)
strcat(buf, ",allow_other");
syscall(SYS_mount, blkdev, target, "fuseblk", flags, buf);
return fd;
}
static uintptr_t execute_syscall(int nr, uintptr_t a0, uintptr_t a1,
uintptr_t a2, uintptr_t a3,
uintptr_t a4, uintptr_t a5,
uintptr_t a6, uintptr_t a7,
uintptr_t a8)
{
switch (nr) {
default:
return syscall(nr, a0, a1, a2, a3, a4, a5);
case __NR_syz_test:
return 0;
case __NR_syz_open_dev:
return syz_open_dev(a0, a1, a2);
case __NR_syz_open_pts:
return syz_open_pts(a0, a1);
case __NR_syz_fuse_mount:
return syz_fuse_mount(a0, a1, a2, a3, a4, a5);
case __NR_syz_fuseblk_mount:
return syz_fuseblk_mount(a0, a1, a2, a3, a4, a5, a6, a7);
}
}
long r[25];
int main()
{
install_segv_handler();
memset(r, -1, sizeof(r));
r[0] = execute_syscall(__NR_mmap, 0x20000000ul, 0xf60000ul, 0x3ul,
0x32ul, 0xfffffffffffffffful, 0x0ul, 0, 0, 0);
r[1] = execute_syscall(__NR_socket, 0x1dul, 0x80002ul, 0x2ul, 0, 0, 0,
0, 0, 0);
NONFAILING(*(uint16_t*)0x20f57000 = (uint16_t)0x27);
NONFAILING(*(uint32_t*)0x20f57004 = (uint32_t)0x0);
NONFAILING(*(uint32_t*)0x20f57008 = (uint32_t)0x0);
NONFAILING(*(uint32_t*)0x20f5700c = (uint32_t)0x0);
NONFAILING(*(uint8_t*)0x20f57010 = (uint8_t)0x0);
NONFAILING(*(uint8_t*)0x20f57011 = (uint8_t)0x0);
NONFAILING(memcpy(
(void*)0x20f57012,
"\x34\x1b\x3a\x01\xb2\x57\x84\x9c\xa1\xd7\xd1\xff\x9f\x99\x9d\x81"
"\x27\xb1\x85\xf8\x8d\x1d\x77\x5d\x59\xc8\x8a\x3a\xa6\xa8\xdd\xac"
"\xdf\x2b\xdc\x32\x4e\xa6\x57\x8a\x21\xb8\x51\x14\x61\x01\x86\xc3"
"\x81\x7c\x34\xb0\x5e\xaf\xfd\x2c\x3f\x54\xf5\x7f\xa8\x1b\xa0",
63));
NONFAILING(*(uint64_t*)0x20f57058 = (uint64_t)0x0);
r[10] = execute_syscall(__NR_connect, r[1], 0x20f57000ul, 0x60ul, 0,
0, 0, 0, 0, 0);
NONFAILING(*(uint64_t*)0x20b05000 = (uint64_t)0x20f55000);
NONFAILING(*(uint32_t*)0x20b05008 = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20b05010 = (uint64_t)0x20008fe0);
NONFAILING(*(uint64_t*)0x20b05018 = (uint64_t)0x2);
NONFAILING(*(uint64_t*)0x20b05020 = (uint64_t)0x20f54000);
NONFAILING(*(uint64_t*)0x20b05028 = (uint64_t)0x0);
NONFAILING(*(uint32_t*)0x20b05030 = (uint32_t)0x0);
NONFAILING(*(uint64_t*)0x20008fe0 = (uint64_t)0x20d5fff1);
NONFAILING(*(uint64_t*)0x20008fe8 = (uint64_t)0xf);
NONFAILING(*(uint64_t*)0x20008ff0 = (uint64_t)0x20f55000);
NONFAILING(*(uint64_t*)0x20008ff8 = (uint64_t)0x69);
NONFAILING(memcpy(
(void*)0x20d5fff1,
"\x05\x00\x00\x00\x8d\x13\x00\x00\x00\x00\x17\x14\xb7\x7e\xa6",
15));
NONFAILING(memcpy(
(void*)0x20f55000,
"\x12\x6f\x39\xb6\x5b\x4e\xed\x90\x77\xe0\x54\xbf\xb6\xb2\x41\xd7"
"\x36\x5d\x58\xfa\xa8\x32\x7a\x6d\x25\x89\x01\x00\xdd\x00\xc5\x89"
"\x07\xec\xc2\x76\x8d\x02\x00\x00\x00\x10\xb4\x27\xab\x6c\x2a\x41"
"\xe2\x54\x47\xcc\x08\xca\x75\x2a\x03\x89\xd3\x04\x71\x3f\x75\x90"
"\xf4\xda\xc6\xd9\xa7\x50\xff\xe8\x3e\xff\xcd\x31\x1b\xa2\x0a\xee"
"\x8a\x72\x6b\xda\x74\x75\x92\xbf\xad\xf0\x71\xb9\xb7\x70\x04\xbb"
"\x58\x40\x7d\x50\x14\x6b\xd7\xc2\x60",
105));
r[24] = execute_syscall(__NR_sendmsg, r[1], 0x20b05000ul, 0x0ul, 0, 0,
0, 0, 0, 0);
return 0;
}
^ permalink raw reply
* Re: net/l2tp: use-after-free write in l2tp_ip6_close
From: Andrey Konovalov @ 2016-11-22 9:23 UTC (permalink / raw)
To: Guillaume Nault
Cc: David S. Miller, Eric Dumazet, Willem de Bruijn,
Hannes Frederic Sowa, Soheil Hassas Yeganeh, Shmulik Ladkani,
Wei Wang, Haishuang Yan, netdev, LKML, Dmitry Vyukov,
Kostya Serebryany, Alexander Potapenko, syzkaller
In-Reply-To: <20161110174429.dmqgov4k6tgg2fsc@alphalink.fr>
Hi Guillaume,
Sorry, I was on vacation last week, couldn't reply.
As I can see a fix was already sent upstream.
Thanks!
On Thu, Nov 10, 2016 at 6:44 PM, Guillaume Nault <g.nault@alphalink.fr> wrote:
> On Mon, Nov 07, 2016 at 11:35:26PM +0100, Andrey Konovalov wrote:
>> Hi,
>>
>> I've got the following error report while running the syzkaller fuzzer:
>>
>> ==================================================================
>> BUG: KASAN: use-after-free in l2tp_ip6_close+0x239/0x2a0 at addr
>> ffff8800677276d8
>> Write of size 8 by task a.out/8668
>> CPU: 0 PID: 8668 Comm: a.out Not tainted 4.9.0-rc4+ #354
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff8800694d7b00 ffffffff81b46a64 ffff88006adb5780 ffff8800677276c0
>> ffff880067727c68 ffff8800677276c0 ffff8800694d7b28 ffffffff8150a86c
>> ffff8800694d7bb8 ffff88006adb5780 ffff8800e77276d8 ffff8800694d7ba8
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff81b46a64>] dump_stack+0xb3/0x10f lib/dump_stack.c:51
>> [<ffffffff8150a86c>] kasan_object_err+0x1c/0x70 mm/kasan/report.c:156
>> [< inline >] print_address_description mm/kasan/report.c:194
>> [<ffffffff8150ab07>] kasan_report_error+0x1f7/0x4d0 mm/kasan/report.c:283
>> [< inline >] kasan_report mm/kasan/report.c:303
>> [<ffffffff8150b01e>] __asan_report_store8_noabort+0x3e/0x40
>> mm/kasan/report.c:329
>> [< inline >] __write_once_size ./include/linux/compiler.h:272
>> [< inline >] __hlist_del ./include/linux/list.h:622
>> [< inline >] hlist_del_init ./include/linux/list.h:637
>> [<ffffffff83825f49>] l2tp_ip6_close+0x239/0x2a0 net/l2tp/l2tp_ip6.c:239
>> [<ffffffff8316b31f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
>> [<ffffffff832cd4d0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
>> [<ffffffff82b6d89e>] sock_release+0x8e/0x1d0 net/socket.c:570
>> [<ffffffff82b6d9f6>] sock_close+0x16/0x20 net/socket.c:1017
>> [<ffffffff81524bdd>] __fput+0x29d/0x720 fs/file_table.c:208
>> [<ffffffff815250e5>] ____fput+0x15/0x20 fs/file_table.c:244
>> [<ffffffff81172928>] task_work_run+0xf8/0x170 kernel/task_work.c:116
>> [< inline >] exit_task_work ./include/linux/task_work.h:21
>> [<ffffffff8111bda3>] do_exit+0x883/0x2ac0 kernel/exit.c:828
>> [<ffffffff8112234e>] do_group_exit+0x10e/0x340 kernel/exit.c:931
>> [< inline >] SYSC_exit_group kernel/exit.c:942
>> [<ffffffff8112259d>] SyS_exit_group+0x1d/0x20 kernel/exit.c:940
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Object at ffff8800677276c0, in cache L2TP/IPv6 size: 1448
>> Allocated:
>> PID = 8692
>> [<ffffffff8107e236>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>> [<ffffffff81509bd6>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
>> [< inline >] set_track mm/kasan/kasan.c:507
>> [<ffffffff81509e4b>] kasan_kmalloc+0xab/0xe0 mm/kasan/kasan.c:598
>> [<ffffffff8150a3b2>] kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:537
>> [< inline >] slab_post_alloc_hook mm/slab.h:417
>> [< inline >] slab_alloc_node mm/slub.c:2708
>> [< inline >] slab_alloc mm/slub.c:2716
>> [<ffffffff81505064>] kmem_cache_alloc+0xb4/0x270 mm/slub.c:2721
>> [<ffffffff82b77ca9>] sk_prot_alloc+0x69/0x2b0 net/core/sock.c:1327
>> [<ffffffff82b80898>] sk_alloc+0x38/0xaf0 net/core/sock.c:1389
>> [<ffffffff832cef05>] inet6_create+0x2e5/0xf60 net/ipv6/af_inet6.c:182
>> [<ffffffff82b7301f>] __sock_create+0x37f/0x640 net/socket.c:1153
>> [< inline >] sock_create net/socket.c:1193
>> [< inline >] SYSC_socket net/socket.c:1223
>> [<ffffffff82b73510>] SyS_socket+0xf0/0x1b0 net/socket.c:1203
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Freed:
>> PID = 8668
>> [<ffffffff8107e236>] save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:57
>> [<ffffffff81509bd6>] save_stack+0x46/0xd0 mm/kasan/kasan.c:495
>> [< inline >] set_track mm/kasan/kasan.c:507
>> [<ffffffff8150a433>] kasan_slab_free+0x73/0xc0 mm/kasan/kasan.c:571
>> [< inline >] slab_free_hook mm/slub.c:1352
>> [< inline >] slab_free_freelist_hook mm/slub.c:1374
>> [< inline >] slab_free mm/slub.c:2951
>> [<ffffffff81506263>] kmem_cache_free+0xb3/0x2c0 mm/slub.c:2973
>> [< inline >] sk_prot_free net/core/sock.c:1370
>> [<ffffffff82b7c669>] __sk_destruct+0x319/0x480 net/core/sock.c:1445
>> [<ffffffff82b82b94>] sk_destruct+0x44/0x80 net/core/sock.c:1453
>> [<ffffffff82b82c24>] __sk_free+0x54/0x230 net/core/sock.c:1461
>> [<ffffffff82b82e23>] sk_free+0x23/0x30 net/core/sock.c:1472
>> [< inline >] sock_put ./include/net/sock.h:1591
>> [<ffffffff82b84b04>] sk_common_release+0x294/0x3e0 net/core/sock.c:2745
>> [<ffffffff83825f19>] l2tp_ip6_close+0x209/0x2a0 net/l2tp/l2tp_ip6.c:243
>> [<ffffffff8316b31f>] inet_release+0xef/0x1c0 net/ipv4/af_inet.c:415
>> [<ffffffff832cd4d0>] inet6_release+0x50/0x70 net/ipv6/af_inet6.c:422
>> [<ffffffff82b6d89e>] sock_release+0x8e/0x1d0 net/socket.c:570
>> [<ffffffff82b6d9f6>] sock_close+0x16/0x20 net/socket.c:1017
>> [<ffffffff81524bdd>] __fput+0x29d/0x720 fs/file_table.c:208
>> [<ffffffff815250e5>] ____fput+0x15/0x20 fs/file_table.c:244
>> [<ffffffff81172928>] task_work_run+0xf8/0x170 kernel/task_work.c:116
>> [< inline >] exit_task_work ./include/linux/task_work.h:21
>> [<ffffffff8111bda3>] do_exit+0x883/0x2ac0 kernel/exit.c:828
>> [<ffffffff8112234e>] do_group_exit+0x10e/0x340 kernel/exit.c:931
>> [< inline >] SYSC_exit_group kernel/exit.c:942
>> [<ffffffff8112259d>] SyS_exit_group+0x1d/0x20 kernel/exit.c:940
>> [<ffffffff83fc1501>] entry_SYSCALL_64_fastpath+0x1f/0xc2
>> arch/x86/entry/entry_64.S:209
>> Memory state around the buggy address:
>> ffff880067727580: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff880067727600: fb fb fb fb fb fc fc fc fc fc fc fc fc fc fc fc
>> >ffff880067727680: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>> ^
>> ffff880067727700: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ffff880067727780: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>> ==================================================================
>>
>> To reproduce run the attached program in a tight parallel loop using
>> stress (https://godoc.org/golang.org/x/tools/cmd/stress):
>> $ gcc -lpthread tmp.c
>> $ ./stress ./a.out
>>
>> On commit bc33b0ca11e3df467777a4fa7639ba488c9d4911 (Nov 5).
>>
>
> Thanks for the report. It looks like l2tp_ip6_bind() is racy.
> Can you try the following patch?
>
> diff --git a/net/l2tp/l2tp_ip6.c b/net/l2tp/l2tp_ip6.c
> index ad3468c..9978d01 100644
> --- a/net/l2tp/l2tp_ip6.c
> +++ b/net/l2tp/l2tp_ip6.c
> @@ -269,8 +269,6 @@ static int l2tp_ip6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
> int addr_type;
> int err;
>
> - if (!sock_flag(sk, SOCK_ZAPPED))
> - return -EINVAL;
> if (addr->l2tp_family != AF_INET6)
> return -EINVAL;
> if (addr_len < sizeof(*addr))
> @@ -296,6 +294,9 @@ static int l2tp_ip6_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
> lock_sock(sk);
>
> err = -EINVAL;
> + if (!sock_flag(sk, SOCK_ZAPPED))
> + goto out_unlock;
> +
> if (sk->sk_state != TCP_CLOSE)
> goto out_unlock;
^ permalink raw reply
* Re: [PATCH net 1/1] net sched filters: pass netlink message flags in event notification
From: Daniel Borkmann @ 2016-11-22 9:28 UTC (permalink / raw)
To: Cong Wang, Roman Mashak
Cc: David Miller, Linux Kernel Network Developers, Jamal Hadi Salim
In-Reply-To: <CAM_iQpXPsDAfgGsKB7V_=+LnwnuqzgvY7amcPo7hs3VKGrviiA@mail.gmail.com>
On 11/22/2016 06:23 AM, Cong Wang wrote:
> On Thu, Nov 17, 2016 at 1:02 PM, Cong Wang <xiyou.wangcong@gmail.com> wrote:
>> On Wed, Nov 16, 2016 at 2:16 PM, Roman Mashak <mrv@mojatatu.com> wrote:
>>> Userland client should be able to read an event, and reflect it back to
>>> the kernel, therefore it needs to extract complete set of netlink flags.
>>>
>>> For example, this will allow "tc monitor" to distinguish Add and Replace
>>> operations.
>>>
>>> Signed-off-by: Roman Mashak <mrv@mojatatu.com>
>>> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
>>> ---
>>> net/sched/cls_api.c | 5 +++--
>>> 1 file changed, 3 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/net/sched/cls_api.c b/net/sched/cls_api.c
>>> index 2b2a797..8e93d4a 100644
>>> --- a/net/sched/cls_api.c
>>> +++ b/net/sched/cls_api.c
>>> @@ -112,7 +112,7 @@ static void tfilter_notify_chain(struct net *net, struct sk_buff *oskb,
>>>
>>> for (it_chain = chain; (tp = rtnl_dereference(*it_chain)) != NULL;
>>> it_chain = &tp->next)
>>> - tfilter_notify(net, oskb, n, tp, 0, event, false);
>>> + tfilter_notify(net, oskb, n, tp, n->nlmsg_flags, event, false);
>>
>>
>> I must miss something, why does it make sense to pass n->nlmsg_flags
>> as 'fh' to tfilter_notify()??
>
> Ping... Any response?
>
> It still doesn't look correct to me. I will send a fix unless someone could
> explain this.
Sigh, I missed that this was applied already to -net (it certainly doesn't look
like -net material, but rather -net-next stuff) ... This definitely looks buggy
to me, the 0 as it was before was correct here (as it means we delete the whole
chain in this case).
If you could send a patch would be great. Thanks Cong!
^ permalink raw reply
* mlx5 "syndrome" errors in kernel log
From: Jesper Dangaard Brouer @ 2016-11-22 9:59 UTC (permalink / raw)
To: Saeed Mahameed, Tariq Toukan; +Cc: netdev@vger.kernel.org
Hi Saeed,
I'm seeing below dmesg errors, after pulling net-next at commit
e796f49d826aad, before I was not seeing these errors, where my tree was
based on top of commit 319b0534b95.
mlx5_core 0000:02:00.1: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.1: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.0: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.0: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.1: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.1: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.0: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
mlx5_core 0000:02:00.0: mlx5_cmd_check:698:(pid 8788): ACCESS_REG(0x805) op_mod(0x1) failed, status bad parameter(0x3), syndrome (0x6c4d48)
Listing my firmware version:
$ ethtool -i mlx5p2
driver: mlx5_core
version: 3.0-1 (January 2015)
firmware-version: 12.12.1240
bus-info: 0000:02:00.1
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: yes
--
Best regards,
Jesper Dangaard Brouer
MSc.CS, Principal Kernel Engineer at Red Hat
Author of http://www.iptv-analyzer.org
LinkedIn: http://www.linkedin.com/in/brouer
git diff --stat 319b0534b95..e796f49d826aad drivers/net/ethernet/mellanox/mlx5/
drivers/net/ethernet/mellanox/mlx5/core/cmd.c | 145 ++++++++++++++++++++++++++++++++++++++++++----------------------------------------------
drivers/net/ethernet/mellanox/mlx5/core/en_ethtool.c | 40 ++++++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/en_main.c | 61 +++++++++++++++++++++++++++++--------
drivers/net/ethernet/mellanox/mlx5/core/en_stats.h | 49 +++++++++++++++++++++++++++++-
drivers/net/ethernet/mellanox/mlx5/core/eq.c | 12 ++++++++
drivers/net/ethernet/mellanox/mlx5/core/main.c | 37 +++++++++++++++++++++++
drivers/net/ethernet/mellanox/mlx5/core/mlx5_core.h | 1 +
drivers/net/ethernet/mellanox/mlx5/core/port.c | 57 +++++++++++++++++++++++++++++++++++
8 files changed, 312 insertions(+), 90 deletions(-)
$ git shortlog 319b0534b95..e796f49d826aad drivers/net/ethernet/mellanox/mlx5/
Daniel Borkmann (3):
bpf, mlx5: fix mlx5e_create_rq taking reference on prog
bpf, mlx5: fix various refcount issues in mlx5e_xdp_set
bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup
Eric Dumazet (1):
net/mlx5e: remove napi_hash_del() calls
Gal Pressman (1):
net/mlx5e: Expose PCIe statistics to ethtool
Huy Nguyen (3):
net/mlx5: Add handling for port module event
net/mlx5e: Add port module event counters to ethtool stats
net/mlx5: Set driver version into firmware
Mohamad Haj Yahia (1):
net/mlx5: Make the command interface cache more flexible
$ git log --pretty=oneline 319b0534b95..e796f49d826aad drivers/net/ethernet/mellanox/mlx5/
a055c19be98bc065a4478663ba7f6833693b8958 bpf, mlx5: drop priv->xdp_prog reference on netdev cleanup
c54c06290428554bc0e26d58f21a7865cbe995af bpf, mlx5: fix various refcount issues in mlx5e_xdp_set
97bc402db7821259f6a722cb38e060aa9b35b6e8 bpf, mlx5: fix mlx5e_create_rq taking reference on prog
9c7262399ba12825f3ca4b00a76d8d5e77c720f5 net/mlx5e: Expose PCIe statistics to ethtool
012e50e109fd27ff989492ad74c50ca7ab21e6a1 net/mlx5: Set driver version into firmware
bedb7c909c1911270fcb084230245df4a00bd881 net/mlx5e: Add port module event counters to ethtool stats
d4eb4cd78b0774c7061db56844ed2ea7790cc77c net/mlx5: Add handling for port module event
0ac3ea70897fb9f84b620aeda074ecccf481629d net/mlx5: Make the command interface cache more flexible
d30d9ccbfac7cf9a12a088d57aaf0891732e2bca net/mlx5e: remove napi_hash_del() calls
^ permalink raw reply
* [PATCH v2] net/phy: add trace events for mdio accesses
From: Uwe Kleine-König @ 2016-11-22 10:01 UTC (permalink / raw)
To: Florian Fainelli, Steven Rostedt, Ingo Molnar; +Cc: netdev
In-Reply-To: <20161114110335.27862-1-uwe@kleine-koenig.org>
Make it possible to generate trace events for mdio read and write accesses.
Signed-off-by: Uwe Kleine-König <uwe@kleine-koenig.org>
---
Changes since (implicit) v1:
- make use of TRACE_EVENT_CONDITION
Alternatively to this patch the condition could be
+ TP_CONDITION(err == 0),
but then we'd need in the read callbacks:
+ trace_mdio_access(bus, 1, addr, regnum, retval, retval < 0 ? retval : 0);
or at least
+ trace_mdio_access(bus, 1, addr, regnum, retval, retval < 0);
which both looks more ugly IMHO.
Best regards
Uwe
drivers/net/phy/mdio_bus.c | 11 +++++++++++
include/trace/events/mdio.h | 42 ++++++++++++++++++++++++++++++++++++++++++
2 files changed, 53 insertions(+)
create mode 100644 include/trace/events/mdio.h
diff --git a/drivers/net/phy/mdio_bus.c b/drivers/net/phy/mdio_bus.c
index 09deef4bed09..653d076eafe5 100644
--- a/drivers/net/phy/mdio_bus.c
+++ b/drivers/net/phy/mdio_bus.c
@@ -38,6 +38,9 @@
#include <asm/irq.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/mdio.h>
+
int mdiobus_register_device(struct mdio_device *mdiodev)
{
if (mdiodev->bus->mdio_map[mdiodev->addr])
@@ -461,6 +464,8 @@ int mdiobus_read_nested(struct mii_bus *bus, int addr, u32 regnum)
retval = bus->read(bus, addr, regnum);
mutex_unlock(&bus->mdio_lock);
+ trace_mdio_access(bus, 1, addr, regnum, retval, retval);
+
return retval;
}
EXPORT_SYMBOL(mdiobus_read_nested);
@@ -485,6 +490,8 @@ int mdiobus_read(struct mii_bus *bus, int addr, u32 regnum)
retval = bus->read(bus, addr, regnum);
mutex_unlock(&bus->mdio_lock);
+ trace_mdio_access(bus, 1, addr, regnum, retval, retval);
+
return retval;
}
EXPORT_SYMBOL(mdiobus_read);
@@ -513,6 +520,8 @@ int mdiobus_write_nested(struct mii_bus *bus, int addr, u32 regnum, u16 val)
err = bus->write(bus, addr, regnum, val);
mutex_unlock(&bus->mdio_lock);
+ trace_mdio_access(bus, 0, addr, regnum, val, err);
+
return err;
}
EXPORT_SYMBOL(mdiobus_write_nested);
@@ -538,6 +547,8 @@ int mdiobus_write(struct mii_bus *bus, int addr, u32 regnum, u16 val)
err = bus->write(bus, addr, regnum, val);
mutex_unlock(&bus->mdio_lock);
+ trace_mdio_access(bus, 0, addr, regnum, val, err);
+
return err;
}
EXPORT_SYMBOL(mdiobus_write);
diff --git a/include/trace/events/mdio.h b/include/trace/events/mdio.h
new file mode 100644
index 000000000000..468e2d095d19
--- /dev/null
+++ b/include/trace/events/mdio.h
@@ -0,0 +1,42 @@
+#undef TRACE_SYSTEM
+#define TRACE_SYSTEM mdio
+
+#if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ)
+#define _TRACE_MDIO_H
+
+#include <linux/tracepoint.h>
+
+TRACE_EVENT_CONDITION(mdio_access,
+
+ TP_PROTO(struct mii_bus *bus, int read,
+ unsigned addr, unsigned regnum, u16 val, int err),
+
+ TP_ARGS(bus, read, addr, regnum, val, err),
+
+ TP_CONDITION(err >= 0),
+
+ TP_STRUCT__entry(
+ __array(char, busid, MII_BUS_ID_SIZE)
+ __field(int, read)
+ __field(unsigned, addr)
+ __field(unsigned, regnum)
+ __field(u16, val)
+ ),
+
+ TP_fast_assign(
+ strncpy(__entry->busid, bus->id, MII_BUS_ID_SIZE);
+ __entry->read = read;
+ __entry->addr = addr;
+ __entry->regnum = regnum;
+ __entry->val = val;
+ ),
+
+ TP_printk("%s %-5s phy:0x%02x reg:0x%02x val:0x%04hx",
+ __entry->busid, __entry->read ? "read" : "write",
+ __entry->addr, __entry->regnum, __entry->val)
+);
+
+#endif /* if !defined(_TRACE_MDIO_H) || defined(TRACE_HEADER_MULTI_READ) */
+
+/* This part must be outside protection */
+#include <trace/define_trace.h>
--
2.10.2
^ permalink raw reply related
* Re: [RFC PATCH net v2 2/3] dt: bindings: add ethernet phy eee-disable-advert option documentation
From: Jerome Brunet @ 2016-11-22 10:13 UTC (permalink / raw)
To: Florian Fainelli, Andrew Lunn
Cc: netdev-u79uwXL29TY76Z2rM5mHXA, devicetree-u79uwXL29TY76Z2rM5mHXA,
Alexandre TORGUE, Neil Armstrong, Martin Blumenstingl,
Kevin Hilman, linux-kernel-u79uwXL29TY76Z2rM5mHXA, Andre Roth,
linux-amlogic-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r, Carlo Caione,
Giuseppe Cavallaro,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <e792c889-8725-3952-ca28-a08537d9f87a-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Mon, 2016-11-21 at 21:35 -0800, Florian Fainelli wrote:
> Le 21/11/2016 à 08:47, Andrew Lunn a écrit :
> >
> > >
> > > What I did not realize when doing this patch for the realtek
> > > driver is
> > > that there is already 6 valid modes defined in the kernel
> > >
> > > #define MDIO_EEE_100TX MDIO_AN_EEE_ADV_100TX
> > > /*
> > > 100TX EEE cap */
> > > #define MDIO_EEE_1000T MDIO_AN_EEE_ADV_1000T
> > > /*
> > > 1000T EEE cap */
> > > #define MDIO_EEE_10GT 0x0008 /* 10GT EEE
> > > cap */
> > > #define MDIO_EEE_1000KX 0x0010 /* 1000KX
> > > EEE cap
> > > */
> > > #define MDIO_EEE_10GKX4 0x0020 /* 10G KX4
> > > EEE cap
> > > */
> > > #define MDIO_EEE_10GKR 0x0040 /* 10G KR EEE
> > > cap
> > > */
> > >
> > > I took care of only 2 in the case of realtek.c since it only
> > > support
> > > MDIO_EEE_100TX and MDIO_EEE_1000T.
> > >
> > > Defining a property for each is certainly doable but it does not
> > > look
> > > very nice either. If it extends in the future, it will get even
> > > more
> > > messier, especially if you want to disable everything.
> >
> > Yes, agreed.
>
> One risk with the definition a group of advertisement capabilities
> (under the form of a bitmask for instance) to enable/disable is that
> we
> end up with Device Tree contain some kind of configuration policy as
> opposed to just flagging particular hardware features as broken.
The code proposed only allows to disable EEE advertisement (not
enable), so we should not see it used as a configuration policy in DT.
To make this more explicit, I could replace the property "eee-advert-
disable" by "eee-broken" ?
>
> Fortunately, there does not seem to be a ton of PHYs out there which
> require EEE
It is quite difficult to have the real picture here because some PHYs
have EEE disabled by default and you have to explicitly enable it.
I have no idea of the ratio between the 2 phy policies.
> to be disabled to function properly so having individual
> properties vs. bitmasks/groups is kind of speculative here.
In the particular instance of the OdroidC2, disabling EEE for GbE only
enough. However, If you have a PHY broken with, I think it is likely
that you might want to disable all (supported) EEE modes. That's reason
why I prefer bitmask. I agree both are functionally similar, this is
kind of a cosmetic debate.
>
> Another approach to solving this problem could be to register a PHY
> fixup which disables EEE at the PHY level, and which is only called
> for
> specific boards affected by this problem
> (of_machine_is_compatible()).
> This code can leave in arch/*/* when that is possible,
That something I was looking at, but we don't have these files anymore
on ARM64 (looking at your comment, you already know this)
> or it can just be
> somewhere where it is relevant, e.g; in the PHY driver for instance
> (similarly to how PCI fixups are done).
Do you prefer having board specific code inside generic driver than
having the setting living in DT? Peppe told me they also had a few
platform with similar issues. The point is that this could be useful to
other people, so it could spread a grow a bit.
I would prefer having this in the DT, but I can definitely do it the
PHY with of_machine_is_compatible() and register_fixup is this what you
prefer/want.
Cheers
Jerome
--
To unsubscribe from this list: send the line "unsubscribe devicetree" 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
* net/icmp: null-ptr-deref in icmp6_send
From: Andrey Konovalov @ 2016-11-22 10:23 UTC (permalink / raw)
To: David Ahern, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev, LKML
Cc: Dmitry Vyukov, Alexander Potapenko, Kostya Serebryany,
Eric Dumazet, syzkaller
Hi,
I've got the following error report while fuzzing the kernel with syzkaller.
It seems that skb_dst(skb) may end up being NULL.
As far as I can see the bug was introduced in commit 5d41ce29e ("net:
icmp6_send should use dst dev to determine L3 domain").
ICMP v4 probaly has similar issue due to 9d1a6c4ea ("net:
icmp_route_lookup should use rt dev to determine L3 domain").
On commit 9c763584b7c8911106bb77af7e648bef09af9d80 (4.9-rc6, Nov 20).
kasan: CONFIG_KASAN_INLINE enabled
kasan: GPF could be caused by NULL-ptr deref or user memory access
general protection fault: 0000 [#1] SMP KASAN
Modules linked in:
CPU: 0 PID: 3859 Comm: a.out Not tainted 4.9.0-rc6+ #429
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
task: ffff8800666d4200 task.stack: ffff880067348000
RIP: 0010:[<ffffffff833617ec>] [<ffffffff833617ec>]
icmp6_send+0x5fc/0x1e30 net/ipv6/icmp.c:451
RSP: 0018:ffff88006734f2c0 EFLAGS: 00010206
RAX: ffff8800666d4200 RBX: 0000000000000000 RCX: 0000000000000000
RDX: 0000000000000000 RSI: dffffc0000000000 RDI: 0000000000000018
RBP: ffff88006734f630 R08: ffff880064138418 R09: 0000000000000003
R10: dffffc0000000000 R11: 0000000000000005 R12: 0000000000000000
R13: ffffffff84e7e200 R14: ffff880064138484 R15: ffff8800641383c0
FS: 00007fb3887a07c0(0000) GS:ffff88006cc00000(0000) knlGS:0000000000000000
CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
CR2: 0000000020000000 CR3: 000000006b040000 CR4: 00000000000006f0
Stack:
ffff8800666d4200 ffff8800666d49f8 ffff8800666d4200 ffffffff84c02460
ffff8800666d4a1a 1ffff1000ccdaa2f ffff88006734f498 0000000000000046
ffff88006734f440 ffffffff832f4269 ffff880064ba7456 0000000000000000
Call Trace:
[<ffffffff83364ddc>] icmpv6_param_prob+0x2c/0x40 net/ipv6/icmp.c:557
[< inline >] ip6_tlvopt_unknown net/ipv6/exthdrs.c:88
[<ffffffff83394405>] ip6_parse_tlv+0x555/0x670 net/ipv6/exthdrs.c:157
[<ffffffff8339a759>] ipv6_parse_hopopts+0x199/0x460 net/ipv6/exthdrs.c:663
[<ffffffff832ee773>] ipv6_rcv+0xfa3/0x1dc0 net/ipv6/ip6_input.c:191
[<ffffffff82bdc01b>] __netif_receive_skb_core+0x187b/0x2a10 net/core/dev.c:4208
[<ffffffff82bdd1da>] __netif_receive_skb+0x2a/0x170 net/core/dev.c:4246
[<ffffffff82bdd4d3>] netif_receive_skb_internal+0x1b3/0x390 net/core/dev.c:4274
[<ffffffff82bdd6f8>] netif_receive_skb+0x48/0x250 net/core/dev.c:4298
[<ffffffff82420e7e>] tun_get_user+0xbde/0x2890 drivers/net/tun.c:1308
[<ffffffff82422d4a>] tun_chr_write_iter+0xda/0x190 drivers/net/tun.c:1332
[< inline >] new_sync_write fs/read_write.c:499
[<ffffffff8151c234>] __vfs_write+0x334/0x570 fs/read_write.c:512
[<ffffffff8151fd4b>] vfs_write+0x17b/0x500 fs/read_write.c:560
[< inline >] SYSC_write fs/read_write.c:607
[<ffffffff81523674>] SyS_write+0xd4/0x1a0 fs/read_write.c:599
[<ffffffff83fc4301>] entry_SYSCALL_64_fastpath+0x1f/0xc2
arch/x86/entry/entry_64.S:209
Code: 67 58 41 f6 c4 01 0f 85 d4 07 00 00 49 83 e4 fe e8 ea 5e fc fd
49 8d 7c 24 18 49 ba 00 00 00 00 00 fc ff df 49 89 f9 49 c1 e9 03 <43>
80 3c 11 00 0f 85 c5 17 00 00 4d 8b 64 24 18 65 ff 05 cd 3c
RIP [<ffffffff833617ec>] icmp6_send+0x5fc/0x1e30 net/ipv6/icmp.c:451
RSP <ffff88006734f2c0>
---[ end trace 12dd736536064d71 ]---
Kernel panic - not syncing: Fatal exception in interrupt
Kernel Offset: disabled
---[ end Kernel panic - not syncing: Fatal exception in interrupt
^ 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