* Re: [PATCH net-next] samples/bpf: Add support for SKB_MODE to xdp1 and xdp_tx_iptunnel
From: Alexei Starovoitov @ 2017-04-27 16:38 UTC (permalink / raw)
To: David Ahern, netdev; +Cc: daniel
In-Reply-To: <1493309473-27384-1-git-send-email-dsa@cumulusnetworks.com>
On 4/27/17 9:11 AM, David Ahern wrote:
> Add option to xdp1 and xdp_tx_iptunnel to insert xdp program in
> SKB_MODE:
> - update set_link_xdp_fd to take a flags argument that is added to the
> RTM_SETLINK message
>
> - Add -S option to xdp1 and xdp_tx_iptunnel user code. When passed in
> XDP_FLAGS_SKB_MODE is set in the flags arg passed to set_link_xdp_fd
>
> Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
awesome. thanks!
Acked-by: Alexei Starovoitov <ast@kernel.org>
^ permalink raw reply
* [PATCH] net: ath: tx99: fixed a spelling issue
From: ammly @ 2017-04-27 16:31 UTC (permalink / raw)
To: ath9k-devel; +Cc: kvalo, linux-wireless, netdev, linux-kernel, Ammly Fredrick
Fixed a spelling issue.
Signed-off-by: Ammly Fredrick <ammlyf@gmail.com>
---
drivers/net/wireless/ath/ath9k/tx99.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/wireless/ath/ath9k/tx99.c b/drivers/net/wireless/ath/ath9k/tx99.c
index 16aca9e28b77..a866cbda0799 100644
--- a/drivers/net/wireless/ath/ath9k/tx99.c
+++ b/drivers/net/wireless/ath/ath9k/tx99.c
@@ -153,7 +153,7 @@ static int ath9k_tx99_init(struct ath_softc *sc)
sc->tx99_power,
sc->tx99_power / 2);
- /* We leave the harware awake as it will be chugging on */
+ /* We leave the hardware awake as it will be chugging on */
return 0;
}
--
2.11.0
^ permalink raw reply related
* Re: [PATCH net-next 6/6] bpf: show bpf programs
From: Hannes Frederic Sowa @ 2017-04-27 16:28 UTC (permalink / raw)
To: David Miller; +Cc: daniel, netdev, ast, daniel, jbenc, aconole
In-Reply-To: <20170427.120019.1559603500876505216.davem@davemloft.net>
On 27.04.2017 18:00, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Thu, 27 Apr 2017 15:22:49 +0200
>
>> Sure, that sounds super. But so far Linux and most (maybe I should write
>> all) subsystems always provided some easy way to get the insights of the
>> kernel without having to code or rely on special tools so far.
>
> Not true.
Yes, I should not have written it that generally. ;)
> You cannot fully dump socket TCP internal state without netlink based
> tools. It is just one of many examples.
>
> Can you dump all nftables rules without a special tool?
You got me here, I agree that not all state is discoverable via procfs.
But to some degree even netfilter and tcp do expose some considerable
amount of data via procfs. In the case of netfilter it might be less
valuable, though, I have to agree.
> I don't think this is a legitimate line of argument, and I want
> this to be done via the bpf() system call which is what people
> are working on.
I hope you saw that I was absolutely not against dumping or enumeration
with the bpf syscall. It will be the primary interface to debug ebpf and
I completely agree.
Merely I tried to establish the procfs interface as quick look interface
if some type of bpf program is loaded which could start any further
diagnosis. This interface should not have any dependencies and should
even work on embedded devices, where sometimes it might be difficult to
get a binary for the correct architecture installed ad-hoc (I am
thinking about openwrt). But this is definitely also solvable.
I do think if a common utility in util-linux, like lsbpf, is available I
will be fine.
Anyway, I will take this argument back.
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH net-next 9/9] ipvlan: introduce individual MAC addresses
From: Dan Williams @ 2017-04-27 16:23 UTC (permalink / raw)
To: Marco Chiappero, netdev
Cc: David S . Miller, Jeff Kirsher, Alexander Duyck, Sainath Grandhi,
Mahesh Bandewar
In-Reply-To: <1493310033.27948.3.camel@redhat.com>
On Thu, 2017-04-27 at 11:20 -0500, Dan Williams wrote:
> On Thu, 2017-04-27 at 15:51 +0100, Marco Chiappero wrote:
> > Currently all the slave devices belonging to the same port inherit
> > their
> > MAC address from its master device. This patch removes this
> > limitation
> > and allows every slave device to obtain a unique MAC address, by
> > default
> > randomly generated at creation time.
> >
> > Moreover it is now possible to correctly modify the MAC address at
> > any
> > time, fixing an existing bug as MAC address changes on the master
> > were
> > not reflected on the slaves. It also avoids multiple interfaces
> > sharing
> > the same IPv6 link-local address.
>
> How is this different than macvlan now? Why would you use unique
> addressed ipvlan instances instead of macvlan? Wouldn't the same
> problems around external switches not expecting multiple MACs from
> the
> same switch port apply now to ipvlan?
>
> The whole point of ipvlan AIUI was to get around macvlan problems
> related to multiple MACs on the same port.
Another issue is the unicast MAC limits on cards. ipvlan is now much
more likely to hit the unicast MAC limit of the NIC and thus trigger
promiscuous mode and the resulting performance drop, where before it
would not.
Dan
> Also, I think the IPv6 thing you mention is incorrect and has long
> since been solved. Originally, ipvlan did not include a "dev_id"
> property that differened between child interfaces, and thus the IID
> of
> the each interface was the same. That has now been fixed, and each
> ipvlan slave should now have a different IID and thus a different
> link-
> local address.
>
> Dan
>
> > Since ipvlan is designed to expose a single MAC address for
> > external
> > communications, the driver now behaves as follow:
> > - L2 mode:
> > * Any reference to the internal MAC address of the originating
> > slave
> > is replaced with the MAC address of the master for outbound
> > frames.
> > * Likewise, the destination MAC address is overwritten with the
> > internal one (once the correct slave is determined) for any
> > incoming external frame.
> > * For any internal slave-to-slave communication, the original
> > MAC
> > addresses are preserved (although not used for
> > routing/switching).
> > - L3/L3s mode:
> > * The destination MAC address for incoming external packets is
> > replaced with the one belonging to the destination slave
> > device
> > (as for L2 mode)
> > * Every other path behaves as before.
> >
> > Being a significant behavioral change, version number has been
> > increased.
> >
> > Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
> > Tested-by: Marco Chiappero <marco.chiappero@intel.com>
> > ---
> > drivers/net/ipvlan/ipvlan.h | 2 +-
> > drivers/net/ipvlan/ipvlan_core.c | 113
> > ++++++++++++++++++++++++++++++++++-----
> > drivers/net/ipvlan/ipvlan_main.c | 18 +++----
> > 3 files changed, 111 insertions(+), 22 deletions(-)
> >
> > diff --git a/drivers/net/ipvlan/ipvlan.h
> > b/drivers/net/ipvlan/ipvlan.h
> > index 800a46c..efe4fd1 100644
> > --- a/drivers/net/ipvlan/ipvlan.h
> > +++ b/drivers/net/ipvlan/ipvlan.h
> > @@ -32,7 +32,7 @@
> > #include <net/l3mdev.h>
> >
> > #define IPVLAN_DRV "ipvlan"
> > -#define IPV_DRV_VER "0.1"
> > +#define IPV_DRV_VER "0.2"
> >
> > #define IPVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
> > #define IPVLAN_HASH_MASK (IPVLAN_HASH_SIZE - 1)
> > diff --git a/drivers/net/ipvlan/ipvlan_core.c
> > b/drivers/net/ipvlan/ipvlan_core.c
> > index 67e342d..a30bc11 100644
> > --- a/drivers/net/ipvlan/ipvlan_core.c
> > +++ b/drivers/net/ipvlan/ipvlan_core.c
> > @@ -215,6 +215,89 @@ static void ipvlan_skb_crossing_ns(struct
> > sk_buff *skb, struct net_device *dev)
> > skb->dev = dev;
> > }
> >
> > +static inline struct nd_opt_hdr *ipvlan_icmp6_nd_opts(struct
> > icmp6hdr *icmph)
> > +{
> > + return (struct nd_opt_hdr *)((struct nd_msg *)icmph)->opt;
> > +}
> > +
> > +static inline struct nd_opt_hdr *ipvlan_icmp6_rs_opts(struct
> > icmp6hdr *icmph)
> > +{
> > + return (struct nd_opt_hdr *)((struct rs_msg *)icmph)->opt;
> > +}
> > +
> > +static void ipvlan_proxy_l2_update_icmp6(const struct net_device
> > *master,
> > + struct sk_buff *skb,
> > + struct nd_opt_hdr
> > *nd_opt,
> > + u8 opt_type)
> > +{
> > + u32 opts_len = skb_tail_pointer(skb) - (u8 *)nd_opt;
> > +
> > + while (opts_len) {
> > + u32 opt_len = nd_opt->nd_opt_len << 3;
> > +
> > + if (nd_opt->nd_opt_type == opt_type) {
> > + struct ipv6hdr *ip6h = ipv6_hdr(skb);
> > + struct icmp6hdr *icmph = icmp6_hdr(skb);
> > + u32 len = ntohs(ip6h->payload_len);
> > +
> > + memcpy(nd_opt + 1, master->dev_addr,
> > master-
> > > addr_len);
> >
> > + icmph->icmp6_cksum = 0;
> > + icmph->icmp6_cksum =
> > + csum_ipv6_magic(&ip6h->saddr,
> > + &ip6h->daddr, len,
> > + IPPROTO_ICMPV6,
> > + csum_partial(icmph
> > ,
> > len, 0));
> > + return;
> > + }
> > +
> > + opts_len -= opt_len;
> > + nd_opt = ((void *)nd_opt) + opt_len;
> > + }
> > +}
> > +
> > +static void ipvlan_proxy_l2_outbound(struct sk_buff *skb,
> > + const struct net_device
> > *master)
> > +{
> > + /* masquerade the source MAC address for every outgoing
> > frame */
> > + memcpy(eth_hdr(skb)->h_source, master->dev_addr, master-
> > > addr_len);
> >
> > +
> > + /* ARP and some NDISC packets need additional treatment */
> > + if (skb->protocol == htons(ETH_P_IPV6)) {
> > + struct ipv6hdr *ip6h = ipv6_hdr(skb);
> > + struct icmp6hdr *icmph = icmp6_hdr(skb);
> > + struct nd_opt_hdr *nd_opt;
> > + u8 opt_type;
> > +
> > + if (likely(ip6h->nexthdr != NEXTHDR_ICMP))
> > + return;
> > +
> > + switch (icmph->icmp6_type) {
> > + case NDISC_NEIGHBOUR_SOLICITATION: {
> > + nd_opt = ipvlan_icmp6_nd_opts(icmph);
> > + opt_type = ND_OPT_SOURCE_LL_ADDR;
> > + break;
> > + }
> > + case NDISC_NEIGHBOUR_ADVERTISEMENT: {
> > + nd_opt = ipvlan_icmp6_nd_opts(icmph);
> > + opt_type = ND_OPT_TARGET_LL_ADDR;
> > + break;
> > + }
> > + case NDISC_ROUTER_SOLICITATION: {
> > + nd_opt = ipvlan_icmp6_rs_opts(icmph);
> > + opt_type = ND_OPT_SOURCE_LL_ADDR;
> > + break;
> > + }
> > + default:
> > + return;
> > + }
> > +
> > + ipvlan_proxy_l2_update_icmp6(master, skb, nd_opt,
> > opt_type);
> > +
> > + } else if (unlikely(skb->protocol == htons(ETH_P_ARP))) {
> > + memcpy(arp_hdr(skb) + 1, master->dev_addr, master-
> > > addr_len);
> >
> > + }
> > +}
> > +
> > static void ipvlan_dispatch_multicast(struct ipvl_port *port,
> > struct sk_buff *skb, u8
> > pkt_type,
> > unsigned int mac_hash)
> > @@ -258,6 +341,7 @@ static void ipvlan_dispatch_multicast(struct
> > ipvl_port *port,
> > /* If the packet originated here, send it out. */
> > skb->dev = port->dev;
> > skb->pkt_type = pkt_type;
> > + ipvlan_proxy_l2_outbound(skb, port->dev);
> > dev_queue_xmit(skb);
> > } else {
> > if (consumed)
> > @@ -489,6 +573,7 @@ static int ipvlan_xmit_mode_l3(struct sk_buff
> > *skb, struct net_device *dev)
> > static inline int ipvlan_process_l2_outbound(struct sk_buff *skb,
> > struct net_device
> > *dev)
> > {
> > + ipvlan_proxy_l2_outbound(skb, dev);
> > ipvlan_skb_crossing_ns(skb, dev);
> > return dev_queue_xmit(skb);
> > }
> > @@ -499,27 +584,27 @@ static int ipvlan_xmit_mode_l2(struct sk_buff
> > *skb, struct net_device *dev)
> > struct ethhdr *ethh = eth_hdr(skb);
> > struct ipvl_addr *addr;
> >
> > - if (ether_addr_equal(ethh->h_dest, ethh->h_source)) {
> > - addr = ipvlan_get_slave_addr_dst(skb, ipvlan-
> > >port);
> > - if (addr)
> > - return ipvlan_rcv_int_frame(addr, &skb);
> > + if (is_multicast_ether_addr(ethh->h_dest)) {
> > + ipvlan_multicast_enqueue(ipvlan->port, skb, true);
> > + return NET_XMIT_SUCCESS;
> > + }
> >
> > + if (ether_addr_equal(ethh->h_dest, ipvlan->phy_dev-
> > > dev_addr)) {
> >
> > skb = skb_share_check(skb, GFP_ATOMIC);
> > if (unlikely(!skb))
> > return NET_XMIT_DROP;
> >
> > - /* Packet definitely does not belong to any of the
> > - * virtual devices, but the dest is local. So
> > forward
> > - * the skb for the main-dev. At the RX side we
> > just
> > return
> > - * RX_PASS for it to be processed further on the
> > stack.
> > + /* Forward the skb for the master device. At the
> > RX
> > side we
> > + * just return RX_HANDLER_PASS for it to be
> > processed further
> > + * on the stack.
> > */
> > return dev_forward_skb(ipvlan->phy_dev, skb);
> > -
> > - } else if (is_multicast_ether_addr(ethh->h_dest)) {
> > - ipvlan_multicast_enqueue(ipvlan->port, skb, true);
> > - return NET_XMIT_SUCCESS;
> > }
> >
> > + addr = ipvlan_get_slave_addr_dst(skb, ipvlan->port);
> > + if (addr)
> > + return ipvlan_rcv_int_frame(addr, &skb);
> > +
> > return ipvlan_process_l2_outbound(skb, ipvlan->phy_dev);
> > }
> >
> > @@ -562,6 +647,10 @@ static int ipvlan_rcv_ext_frame(struct
> > ipvl_addr
> > *addr, struct sk_buff *skb)
> > struct net_device *dev = ipvlan->dev;
> > unsigned int len = skb->len + ETH_HLEN;
> >
> > + /* NOTE: although not necessary restore the actual
> > destination
> > + * address; this is also what traffic sniffers will
> > display.
> > + */
> > + memcpy(eth_hdr(skb)->h_dest, dev->dev_addr, dev-
> > >addr_len);
> > ipvlan_skb_crossing_ns(skb, dev);
> > ipvlan_count_rx(ipvlan, len, true, false);
> >
> > diff --git a/drivers/net/ipvlan/ipvlan_main.c
> > b/drivers/net/ipvlan/ipvlan_main.c
> > index b837807..709f27d 100644
> > --- a/drivers/net/ipvlan/ipvlan_main.c
> > +++ b/drivers/net/ipvlan/ipvlan_main.c
> > @@ -378,6 +378,7 @@ static const struct net_device_ops
> > ipvlan_netdev_ops = {
> > .ndo_start_xmit = ipvlan_start_xmit,
> > .ndo_fix_features = ipvlan_fix_features,
> > .ndo_change_rx_flags = ipvlan_change_rx_flags,
> > + .ndo_set_mac_address = eth_mac_addr,
> > .ndo_set_rx_mode = ipvlan_set_multicast_mac_filter,
> > .ndo_get_stats64 = ipvlan_get_stats64,
> > .ndo_vlan_rx_add_vid = ipvlan_vlan_rx_add_vid,
> > @@ -392,9 +393,10 @@ static int ipvlan_hard_header(struct sk_buff
> > *skb, struct net_device *dev,
> > const struct ipvl_dev *ipvlan = netdev_priv(dev);
> > struct net_device *phy_dev = ipvlan->phy_dev;
> >
> > - /* TODO Probably use a different field than dev_addr so
> > that
> > the
> > - * mac-address on the virtual device is portable and can
> > be
> > carried
> > - * while the packets use the mac-addr on the physical
> > device.
> > + /* This driver uses (almost exclusively) L3 addresses for
> > + * routing/switching. Use the actual slave's MAC address,
> > + * but overwrite it later during the packet processing for
> > + * frames leaving from master
> > */
> > return dev_hard_header(skb, phy_dev, type, daddr,
> > saddr ? : dev->dev_addr, len);
> > @@ -559,11 +561,8 @@ int ipvlan_link_new(struct net *src_net,
> > struct
> > net_device *dev,
> > /* Increment id-base to the next slot for the future
> > assignment */
> > port->dev_id_start = err + 1;
> >
> > - /* TODO Probably put random address here to be presented
> > to
> > the
> > - * world but keep using the physical-dev address for the
> > outgoing
> > - * packets.
> > - */
> > - memcpy(dev->dev_addr, phy_dev->dev_addr, ETH_ALEN);
> > + /* TODO: consider storing the original MAC address in dev-
> > > perm_addr */
> >
> > + eth_hw_addr_random(dev);
> >
> > dev->priv_flags |= IFF_IPVLAN_SLAVE;
> >
> > @@ -619,7 +618,8 @@ void ipvlan_link_setup(struct net_device *dev)
> > ether_setup(dev);
> >
> > dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> > IFF_TX_SKB_SHARING);
> > - dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> > + dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE
> > + | IFF_LIVE_ADDR_CHANGE;
> > dev->netdev_ops = &ipvlan_netdev_ops;
> > dev->destructor = free_netdev;
> > dev->header_ops = &ipvlan_header_ops;
^ permalink raw reply
* Re: [PATCH v1 net-next 5/6] net: allow simultaneous SW and HW transmit timestamping
From: Willem de Bruijn @ 2017-04-27 16:21 UTC (permalink / raw)
To: Miroslav Lichvar
Cc: Network Development, Richard Cochran, Willem de Bruijn,
Soheil Hassas Yeganeh, Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <20170427161700.GB3401@localhost>
>> > @@ -720,6 +720,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
>> > empty = 0;
>> > if (shhwtstamps &&
>> > (sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
>> > + (empty || !skb_is_err_queue(skb)) &&
>> > ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2)) {
>>
>> I find skb->tstamp == 0 easier to understand than the condition on empty.
>>
>> Indeed, this is so non-obvious that I would suggest another helper function
>> skb_is_hwtx_tstamp with a concise comment about the race condition
>> between tx software and hardware timestamps (as in the last sentence of
>> the commit message).
>
> Should it include also the skb_is_err_queue() check? If it returned
> true for both TX and RX HW timestamps, maybe it could be called
> skb_has_hw_tstamp?
For the purpose of documenting why this complex condition exists,
I would call the skb_is_err_queue in that helper function and make
it tx + hw specific.
^ permalink raw reply
* Re: [PATCH net-next 9/9] ipvlan: introduce individual MAC addresses
From: Dan Williams @ 2017-04-27 16:20 UTC (permalink / raw)
To: Marco Chiappero, netdev
Cc: David S . Miller, Jeff Kirsher, Alexander Duyck, Sainath Grandhi,
Mahesh Bandewar
In-Reply-To: <20170427145142.15830-10-marco.chiappero@intel.com>
On Thu, 2017-04-27 at 15:51 +0100, Marco Chiappero wrote:
> Currently all the slave devices belonging to the same port inherit
> their
> MAC address from its master device. This patch removes this
> limitation
> and allows every slave device to obtain a unique MAC address, by
> default
> randomly generated at creation time.
>
> Moreover it is now possible to correctly modify the MAC address at
> any
> time, fixing an existing bug as MAC address changes on the master
> were
> not reflected on the slaves. It also avoids multiple interfaces
> sharing
> the same IPv6 link-local address.
How is this different than macvlan now? Why would you use unique
addressed ipvlan instances instead of macvlan? Wouldn't the same
problems around external switches not expecting multiple MACs from the
same switch port apply now to ipvlan?
The whole point of ipvlan AIUI was to get around macvlan problems
related to multiple MACs on the same port.
Also, I think the IPv6 thing you mention is incorrect and has long
since been solved. Originally, ipvlan did not include a "dev_id"
property that differened between child interfaces, and thus the IID of
the each interface was the same. That has now been fixed, and each
ipvlan slave should now have a different IID and thus a different link-
local address.
Dan
> Since ipvlan is designed to expose a single MAC address for external
> communications, the driver now behaves as follow:
> - L2 mode:
> * Any reference to the internal MAC address of the originating
> slave
> is replaced with the MAC address of the master for outbound
> frames.
> * Likewise, the destination MAC address is overwritten with the
> internal one (once the correct slave is determined) for any
> incoming external frame.
> * For any internal slave-to-slave communication, the original MAC
> addresses are preserved (although not used for
> routing/switching).
> - L3/L3s mode:
> * The destination MAC address for incoming external packets is
> replaced with the one belonging to the destination slave device
> (as for L2 mode)
> * Every other path behaves as before.
>
> Being a significant behavioral change, version number has been
> increased.
>
> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
> Tested-by: Marco Chiappero <marco.chiappero@intel.com>
> ---
> drivers/net/ipvlan/ipvlan.h | 2 +-
> drivers/net/ipvlan/ipvlan_core.c | 113
> ++++++++++++++++++++++++++++++++++-----
> drivers/net/ipvlan/ipvlan_main.c | 18 +++----
> 3 files changed, 111 insertions(+), 22 deletions(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan.h
> b/drivers/net/ipvlan/ipvlan.h
> index 800a46c..efe4fd1 100644
> --- a/drivers/net/ipvlan/ipvlan.h
> +++ b/drivers/net/ipvlan/ipvlan.h
> @@ -32,7 +32,7 @@
> #include <net/l3mdev.h>
>
> #define IPVLAN_DRV "ipvlan"
> -#define IPV_DRV_VER "0.1"
> +#define IPV_DRV_VER "0.2"
>
> #define IPVLAN_HASH_SIZE (1 << BITS_PER_BYTE)
> #define IPVLAN_HASH_MASK (IPVLAN_HASH_SIZE - 1)
> diff --git a/drivers/net/ipvlan/ipvlan_core.c
> b/drivers/net/ipvlan/ipvlan_core.c
> index 67e342d..a30bc11 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -215,6 +215,89 @@ static void ipvlan_skb_crossing_ns(struct
> sk_buff *skb, struct net_device *dev)
> skb->dev = dev;
> }
>
> +static inline struct nd_opt_hdr *ipvlan_icmp6_nd_opts(struct
> icmp6hdr *icmph)
> +{
> + return (struct nd_opt_hdr *)((struct nd_msg *)icmph)->opt;
> +}
> +
> +static inline struct nd_opt_hdr *ipvlan_icmp6_rs_opts(struct
> icmp6hdr *icmph)
> +{
> + return (struct nd_opt_hdr *)((struct rs_msg *)icmph)->opt;
> +}
> +
> +static void ipvlan_proxy_l2_update_icmp6(const struct net_device
> *master,
> + struct sk_buff *skb,
> + struct nd_opt_hdr *nd_opt,
> + u8 opt_type)
> +{
> + u32 opts_len = skb_tail_pointer(skb) - (u8 *)nd_opt;
> +
> + while (opts_len) {
> + u32 opt_len = nd_opt->nd_opt_len << 3;
> +
> + if (nd_opt->nd_opt_type == opt_type) {
> + struct ipv6hdr *ip6h = ipv6_hdr(skb);
> + struct icmp6hdr *icmph = icmp6_hdr(skb);
> + u32 len = ntohs(ip6h->payload_len);
> +
> + memcpy(nd_opt + 1, master->dev_addr, master-
> >addr_len);
> + icmph->icmp6_cksum = 0;
> + icmph->icmp6_cksum =
> + csum_ipv6_magic(&ip6h->saddr,
> + &ip6h->daddr, len,
> + IPPROTO_ICMPV6,
> + csum_partial(icmph,
> len, 0));
> + return;
> + }
> +
> + opts_len -= opt_len;
> + nd_opt = ((void *)nd_opt) + opt_len;
> + }
> +}
> +
> +static void ipvlan_proxy_l2_outbound(struct sk_buff *skb,
> + const struct net_device
> *master)
> +{
> + /* masquerade the source MAC address for every outgoing
> frame */
> + memcpy(eth_hdr(skb)->h_source, master->dev_addr, master-
> >addr_len);
> +
> + /* ARP and some NDISC packets need additional treatment */
> + if (skb->protocol == htons(ETH_P_IPV6)) {
> + struct ipv6hdr *ip6h = ipv6_hdr(skb);
> + struct icmp6hdr *icmph = icmp6_hdr(skb);
> + struct nd_opt_hdr *nd_opt;
> + u8 opt_type;
> +
> + if (likely(ip6h->nexthdr != NEXTHDR_ICMP))
> + return;
> +
> + switch (icmph->icmp6_type) {
> + case NDISC_NEIGHBOUR_SOLICITATION: {
> + nd_opt = ipvlan_icmp6_nd_opts(icmph);
> + opt_type = ND_OPT_SOURCE_LL_ADDR;
> + break;
> + }
> + case NDISC_NEIGHBOUR_ADVERTISEMENT: {
> + nd_opt = ipvlan_icmp6_nd_opts(icmph);
> + opt_type = ND_OPT_TARGET_LL_ADDR;
> + break;
> + }
> + case NDISC_ROUTER_SOLICITATION: {
> + nd_opt = ipvlan_icmp6_rs_opts(icmph);
> + opt_type = ND_OPT_SOURCE_LL_ADDR;
> + break;
> + }
> + default:
> + return;
> + }
> +
> + ipvlan_proxy_l2_update_icmp6(master, skb, nd_opt,
> opt_type);
> +
> + } else if (unlikely(skb->protocol == htons(ETH_P_ARP))) {
> + memcpy(arp_hdr(skb) + 1, master->dev_addr, master-
> >addr_len);
> + }
> +}
> +
> static void ipvlan_dispatch_multicast(struct ipvl_port *port,
> struct sk_buff *skb, u8
> pkt_type,
> unsigned int mac_hash)
> @@ -258,6 +341,7 @@ static void ipvlan_dispatch_multicast(struct
> ipvl_port *port,
> /* If the packet originated here, send it out. */
> skb->dev = port->dev;
> skb->pkt_type = pkt_type;
> + ipvlan_proxy_l2_outbound(skb, port->dev);
> dev_queue_xmit(skb);
> } else {
> if (consumed)
> @@ -489,6 +573,7 @@ static int ipvlan_xmit_mode_l3(struct sk_buff
> *skb, struct net_device *dev)
> static inline int ipvlan_process_l2_outbound(struct sk_buff *skb,
> struct net_device *dev)
> {
> + ipvlan_proxy_l2_outbound(skb, dev);
> ipvlan_skb_crossing_ns(skb, dev);
> return dev_queue_xmit(skb);
> }
> @@ -499,27 +584,27 @@ static int ipvlan_xmit_mode_l2(struct sk_buff
> *skb, struct net_device *dev)
> struct ethhdr *ethh = eth_hdr(skb);
> struct ipvl_addr *addr;
>
> - if (ether_addr_equal(ethh->h_dest, ethh->h_source)) {
> - addr = ipvlan_get_slave_addr_dst(skb, ipvlan->port);
> - if (addr)
> - return ipvlan_rcv_int_frame(addr, &skb);
> + if (is_multicast_ether_addr(ethh->h_dest)) {
> + ipvlan_multicast_enqueue(ipvlan->port, skb, true);
> + return NET_XMIT_SUCCESS;
> + }
>
> + if (ether_addr_equal(ethh->h_dest, ipvlan->phy_dev-
> >dev_addr)) {
> skb = skb_share_check(skb, GFP_ATOMIC);
> if (unlikely(!skb))
> return NET_XMIT_DROP;
>
> - /* Packet definitely does not belong to any of the
> - * virtual devices, but the dest is local. So
> forward
> - * the skb for the main-dev. At the RX side we just
> return
> - * RX_PASS for it to be processed further on the
> stack.
> + /* Forward the skb for the master device. At the RX
> side we
> + * just return RX_HANDLER_PASS for it to be
> processed further
> + * on the stack.
> */
> return dev_forward_skb(ipvlan->phy_dev, skb);
> -
> - } else if (is_multicast_ether_addr(ethh->h_dest)) {
> - ipvlan_multicast_enqueue(ipvlan->port, skb, true);
> - return NET_XMIT_SUCCESS;
> }
>
> + addr = ipvlan_get_slave_addr_dst(skb, ipvlan->port);
> + if (addr)
> + return ipvlan_rcv_int_frame(addr, &skb);
> +
> return ipvlan_process_l2_outbound(skb, ipvlan->phy_dev);
> }
>
> @@ -562,6 +647,10 @@ static int ipvlan_rcv_ext_frame(struct ipvl_addr
> *addr, struct sk_buff *skb)
> struct net_device *dev = ipvlan->dev;
> unsigned int len = skb->len + ETH_HLEN;
>
> + /* NOTE: although not necessary restore the actual
> destination
> + * address; this is also what traffic sniffers will display.
> + */
> + memcpy(eth_hdr(skb)->h_dest, dev->dev_addr, dev->addr_len);
> ipvlan_skb_crossing_ns(skb, dev);
> ipvlan_count_rx(ipvlan, len, true, false);
>
> diff --git a/drivers/net/ipvlan/ipvlan_main.c
> b/drivers/net/ipvlan/ipvlan_main.c
> index b837807..709f27d 100644
> --- a/drivers/net/ipvlan/ipvlan_main.c
> +++ b/drivers/net/ipvlan/ipvlan_main.c
> @@ -378,6 +378,7 @@ static const struct net_device_ops
> ipvlan_netdev_ops = {
> .ndo_start_xmit = ipvlan_start_xmit,
> .ndo_fix_features = ipvlan_fix_features,
> .ndo_change_rx_flags = ipvlan_change_rx_flags,
> + .ndo_set_mac_address = eth_mac_addr,
> .ndo_set_rx_mode = ipvlan_set_multicast_mac_filter,
> .ndo_get_stats64 = ipvlan_get_stats64,
> .ndo_vlan_rx_add_vid = ipvlan_vlan_rx_add_vid,
> @@ -392,9 +393,10 @@ static int ipvlan_hard_header(struct sk_buff
> *skb, struct net_device *dev,
> const struct ipvl_dev *ipvlan = netdev_priv(dev);
> struct net_device *phy_dev = ipvlan->phy_dev;
>
> - /* TODO Probably use a different field than dev_addr so that
> the
> - * mac-address on the virtual device is portable and can be
> carried
> - * while the packets use the mac-addr on the physical
> device.
> + /* This driver uses (almost exclusively) L3 addresses for
> + * routing/switching. Use the actual slave's MAC address,
> + * but overwrite it later during the packet processing for
> + * frames leaving from master
> */
> return dev_hard_header(skb, phy_dev, type, daddr,
> saddr ? : dev->dev_addr, len);
> @@ -559,11 +561,8 @@ int ipvlan_link_new(struct net *src_net, struct
> net_device *dev,
> /* Increment id-base to the next slot for the future
> assignment */
> port->dev_id_start = err + 1;
>
> - /* TODO Probably put random address here to be presented to
> the
> - * world but keep using the physical-dev address for the
> outgoing
> - * packets.
> - */
> - memcpy(dev->dev_addr, phy_dev->dev_addr, ETH_ALEN);
> + /* TODO: consider storing the original MAC address in dev-
> >perm_addr */
> + eth_hw_addr_random(dev);
>
> dev->priv_flags |= IFF_IPVLAN_SLAVE;
>
> @@ -619,7 +618,8 @@ void ipvlan_link_setup(struct net_device *dev)
> ether_setup(dev);
>
> dev->priv_flags &= ~(IFF_XMIT_DST_RELEASE |
> IFF_TX_SKB_SHARING);
> - dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE;
> + dev->priv_flags |= IFF_UNICAST_FLT | IFF_NO_QUEUE
> + | IFF_LIVE_ADDR_CHANGE;
> dev->netdev_ops = &ipvlan_netdev_ops;
> dev->destructor = free_netdev;
> dev->header_ops = &ipvlan_header_ops;
^ permalink raw reply
* Re: [PATCH v1 net-next 5/6] net: allow simultaneous SW and HW transmit timestamping
From: Miroslav Lichvar @ 2017-04-27 16:17 UTC (permalink / raw)
To: Willem de Bruijn
Cc: Network Development, Richard Cochran, Willem de Bruijn,
Soheil Hassas Yeganeh, Keller, Jacob E, Denny Page, Jiri Benc
In-Reply-To: <CAF=yD-+GSK491AWQx8=6yd3=-HHwxdWq677ubwdjbV5AXzRbog@mail.gmail.com>
On Wed, Apr 26, 2017 at 08:00:02PM -0400, Willem de Bruijn wrote:
> > + if (!hwtstamps && !(sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TX_SWHW) &&
> > + skb_shinfo(orig_skb)->tx_flags & SKBTX_IN_PROGRESS)
> > + return;
> > +
>
> This check should only happen for software transmit timestamps, so simpler to
> revise the check in sw_tx_timestamp above to
>
> if (skb_shinfo(skb)->tx_flags & SKBTX_SW_TSTAMP &&
> - !(skb_shinfo(skb)->tx_flags & SKBTX_IN_PROGRESS))
> + (!(skb_shinfo(orig_skb)->tx_flags & SKBTX_IN_PROGRESS)) ||
> + (skb->sk && skb->sk->sk_tsflags & SOF_TIMESTAMPING_OPT_TX_SWHW)
Good point. This will avoid unnecessary calls of skb_tstamp_tx() in
the common case when SOF_TIMESTAMPING_OPT_TX_SWHW will not be enabled.
> > @@ -720,6 +720,7 @@ void __sock_recv_timestamp(struct msghdr *msg, struct sock *sk,
> > empty = 0;
> > if (shhwtstamps &&
> > (sk->sk_tsflags & SOF_TIMESTAMPING_RAW_HARDWARE) &&
> > + (empty || !skb_is_err_queue(skb)) &&
> > ktime_to_timespec_cond(shhwtstamps->hwtstamp, tss.ts + 2)) {
>
> I find skb->tstamp == 0 easier to understand than the condition on empty.
>
> Indeed, this is so non-obvious that I would suggest another helper function
> skb_is_hwtx_tstamp with a concise comment about the race condition
> between tx software and hardware timestamps (as in the last sentence of
> the commit message).
Should it include also the skb_is_err_queue() check? If it returned
true for both TX and RX HW timestamps, maybe it could be called
skb_has_hw_tstamp?
--
Miroslav Lichvar
^ permalink raw reply
* [PATCH net-next] samples/bpf: Add support for SKB_MODE to xdp1 and xdp_tx_iptunnel
From: David Ahern @ 2017-04-27 16:11 UTC (permalink / raw)
To: netdev; +Cc: ast, daniel, David Ahern
Add option to xdp1 and xdp_tx_iptunnel to insert xdp program in
SKB_MODE:
- update set_link_xdp_fd to take a flags argument that is added to the
RTM_SETLINK message
- Add -S option to xdp1 and xdp_tx_iptunnel user code. When passed in
XDP_FLAGS_SKB_MODE is set in the flags arg passed to set_link_xdp_fd
Signed-off-by: David Ahern <dsa@cumulusnetworks.com>
---
samples/bpf/bpf_load.c | 19 +++++++++++++++---
samples/bpf/bpf_load.h | 2 +-
samples/bpf/xdp1_user.c | 40 ++++++++++++++++++++++++++++++--------
samples/bpf/xdp_tx_iptunnel_user.c | 13 +++++++++----
4 files changed, 58 insertions(+), 16 deletions(-)
diff --git a/samples/bpf/bpf_load.c b/samples/bpf/bpf_load.c
index 0d449d8032d1..d4433a47e6c3 100644
--- a/samples/bpf/bpf_load.c
+++ b/samples/bpf/bpf_load.c
@@ -563,7 +563,7 @@ struct ksym *ksym_search(long key)
return &syms[0];
}
-int set_link_xdp_fd(int ifindex, int fd)
+int set_link_xdp_fd(int ifindex, int fd, int flags)
{
struct sockaddr_nl sa;
int sock, seq = 0, len, ret = -1;
@@ -599,15 +599,28 @@ int set_link_xdp_fd(int ifindex, int fd)
req.nh.nlmsg_seq = ++seq;
req.ifinfo.ifi_family = AF_UNSPEC;
req.ifinfo.ifi_index = ifindex;
+
+ /* started nested attribute for XDP */
nla = (struct nlattr *)(((char *)&req)
+ NLMSG_ALIGN(req.nh.nlmsg_len));
nla->nla_type = NLA_F_NESTED | 43/*IFLA_XDP*/;
+ nla->nla_len = NLA_HDRLEN;
- nla_xdp = (struct nlattr *)((char *)nla + NLA_HDRLEN);
+ /* add XDP fd */
+ nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
nla_xdp->nla_type = 1/*IFLA_XDP_FD*/;
nla_xdp->nla_len = NLA_HDRLEN + sizeof(int);
memcpy((char *)nla_xdp + NLA_HDRLEN, &fd, sizeof(fd));
- nla->nla_len = NLA_HDRLEN + nla_xdp->nla_len;
+ nla->nla_len += nla_xdp->nla_len;
+
+ /* if user passed in any flags, add those too */
+ if (flags) {
+ nla_xdp = (struct nlattr *)((char *)nla + nla->nla_len);
+ nla_xdp->nla_type = 3/*IFLA_XDP_FLAGS*/;
+ nla_xdp->nla_len = NLA_HDRLEN + sizeof(flags);
+ memcpy((char *)nla_xdp + NLA_HDRLEN, &flags, sizeof(flags));
+ nla->nla_len += nla_xdp->nla_len;
+ }
req.nh.nlmsg_len += NLA_ALIGN(nla->nla_len);
diff --git a/samples/bpf/bpf_load.h b/samples/bpf/bpf_load.h
index 68f6b2d22507..6bfd75ec6a16 100644
--- a/samples/bpf/bpf_load.h
+++ b/samples/bpf/bpf_load.h
@@ -47,5 +47,5 @@ struct ksym {
int load_kallsyms(void);
struct ksym *ksym_search(long key);
-int set_link_xdp_fd(int ifindex, int fd);
+int set_link_xdp_fd(int ifindex, int fd, int flags);
#endif
diff --git a/samples/bpf/xdp1_user.c b/samples/bpf/xdp1_user.c
index d2be65d1fd86..deb05e630d84 100644
--- a/samples/bpf/xdp1_user.c
+++ b/samples/bpf/xdp1_user.c
@@ -5,6 +5,7 @@
* License as published by the Free Software Foundation.
*/
#include <linux/bpf.h>
+#include <linux/if_link.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
@@ -12,16 +13,18 @@
#include <stdlib.h>
#include <string.h>
#include <unistd.h>
+#include <libgen.h>
#include "bpf_load.h"
#include "bpf_util.h"
#include "libbpf.h"
static int ifindex;
+static int flags;
static void int_exit(int sig)
{
- set_link_xdp_fd(ifindex, -1);
+ set_link_xdp_fd(ifindex, -1, flags);
exit(0);
}
@@ -54,18 +57,39 @@ static void poll_stats(int interval)
}
}
-int main(int ac, char **argv)
+static void usage(const char *prog)
{
- char filename[256];
+ fprintf(stderr,
+ "usage: %s [OPTS] IFINDEX\n\n"
+ "OPTS:\n"
+ " -S use skb-mode\n",
+ prog);
+}
- snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
+int main(int argc, char **argv)
+{
+ const char *optstr = "S";
+ char filename[256];
+ int opt;
+
+ while ((opt = getopt(argc, argv, optstr)) != -1) {
+ switch (opt) {
+ case 'S':
+ flags |= XDP_FLAGS_SKB_MODE;
+ break;
+ default:
+ usage(basename(argv[0]));
+ return 1;
+ }
+ }
- if (ac != 2) {
- printf("usage: %s IFINDEX\n", argv[0]);
+ if (optind == argc) {
+ usage(basename(argv[0]));
return 1;
}
+ ifindex = strtoul(argv[optind], NULL, 0);
- ifindex = strtoul(argv[1], NULL, 0);
+ snprintf(filename, sizeof(filename), "%s_kern.o", argv[0]);
if (load_bpf_file(filename)) {
printf("%s", bpf_log_buf);
@@ -79,7 +103,7 @@ int main(int ac, char **argv)
signal(SIGINT, int_exit);
- if (set_link_xdp_fd(ifindex, prog_fd[0]) < 0) {
+ if (set_link_xdp_fd(ifindex, prog_fd[0], flags) < 0) {
printf("link set xdp fd failed\n");
return 1;
}
diff --git a/samples/bpf/xdp_tx_iptunnel_user.c b/samples/bpf/xdp_tx_iptunnel_user.c
index 70e192fc61aa..cb2bda7b5346 100644
--- a/samples/bpf/xdp_tx_iptunnel_user.c
+++ b/samples/bpf/xdp_tx_iptunnel_user.c
@@ -5,6 +5,7 @@
* License as published by the Free Software Foundation.
*/
#include <linux/bpf.h>
+#include <linux/if_link.h>
#include <assert.h>
#include <errno.h>
#include <signal.h>
@@ -28,7 +29,7 @@ static int ifindex = -1;
static void int_exit(int sig)
{
if (ifindex > -1)
- set_link_xdp_fd(ifindex, -1);
+ set_link_xdp_fd(ifindex, -1, 0);
exit(0);
}
@@ -136,12 +137,13 @@ int main(int argc, char **argv)
{
unsigned char opt_flags[256] = {};
unsigned int kill_after_s = 0;
- const char *optstr = "i:a:p:s:d:m:T:P:h";
+ const char *optstr = "i:a:p:s:d:m:T:P:Sh";
int min_port = 0, max_port = 0;
struct iptnl_info tnl = {};
struct rlimit r = {RLIM_INFINITY, RLIM_INFINITY};
struct vip vip = {};
char filename[256];
+ int flags = 0;
int opt;
int i;
@@ -201,6 +203,9 @@ int main(int argc, char **argv)
case 'T':
kill_after_s = atoi(optarg);
break;
+ case 'S':
+ flags |= XDP_FLAGS_SKB_MODE;
+ break;
default:
usage(argv[0]);
return 1;
@@ -243,14 +248,14 @@ int main(int argc, char **argv)
}
}
- if (set_link_xdp_fd(ifindex, prog_fd[0]) < 0) {
+ if (set_link_xdp_fd(ifindex, prog_fd[0], flags) < 0) {
printf("link set xdp fd failed\n");
return 1;
}
poll_stats(kill_after_s);
- set_link_xdp_fd(ifindex, -1);
+ set_link_xdp_fd(ifindex, -1, flags);
return 0;
}
--
2.1.4
^ permalink raw reply related
* Re: [PATCH net-next] can: fix build error without CONFIG_PROC_FS
From: Oliver Hartkopp @ 2017-04-27 16:11 UTC (permalink / raw)
To: Marc Kleine-Budde, Arnd Bergmann, David S. Miller
Cc: Thomas Gleixner, Cong Wang, Mario Kicherer, Eric Dumazet,
linux-can, netdev, linux-kernel
In-Reply-To: <937e9144-c06c-d265-29eb-a1c6f96b6f89@pengutronix.de>
Hello Arnd,
many thanks for your patch.
Btw
> static void canbcm_pernet_exit(struct net *net)
> {
> +#ifdef CONFIG_PROC_FS
> /* remove /proc/net/can-bcm directory */
> if (IS_ENABLED(CONFIG_PROC_FS)) {
> if (net->can.bcmproc_dir)
> remove_proc_entry("can-bcm", net->proc_net);
> }
> +#endif
> }
"if (IS_ENABLED(CONFIG_PROC_FS))"
becomes obsolete too then ...
So I would suggest to take my patch to fix my fault ;-)
Best regards,
Oliver
On 04/27/2017 04:29 PM, Marc Kleine-Budde wrote:
> Hello Arnd,
>
> On 04/27/2017 04:21 PM, Arnd Bergmann wrote:
>> The procfs dir entry was added inside of an #ifdef, causing a build error
>> when we try to access it without CONFIG_PROC_FS set:
>>
>> net/can/bcm.c:1541:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
>> net/can/bcm.c: In function 'bcm_connect':
>> net/can/bcm.c:1601:14: error: 'struct netns_can' has no member named 'bcmproc_dir'
>> net/can/bcm.c: In function 'canbcm_pernet_init':
>> net/can/bcm.c:1696:11: error: 'struct netns_can' has no member named 'bcmproc_dir'
>> net/can/bcm.c: In function 'canbcm_pernet_exit':
>> net/can/bcm.c:1707:15: error: 'struct netns_can' has no member named 'bcmproc_dir'
>>
>> This adds the same #ifdef around all users of the pointer. Alternatively
>> we could move the pointer outside of the #ifdef.
>>
>> Fixes: 384317ef4187 ("can: network namespace support for CAN_BCM protocol")
>> Signed-off-by: Arnd Bergmann <arnd@arndb.de>
>
> A fix for this problem is part of the pull request I send to David
> earlier today:
>
> https://www.mail-archive.com/netdev@vger.kernel.org/msg165764.html
>
> regards,
> Marc
>
^ permalink raw reply
* Re: [PATCH net-next 8/9] ipvlan: improve compiler hints
From: David Miller @ 2017-04-27 16:05 UTC (permalink / raw)
To: alexander.h.duyck
Cc: marco.chiappero, netdev, jeffrey.t.kirsher, sainath.grandhi,
maheshb
In-Reply-To: <B1C1DF2ACD01FD4881736AA51731BAB2B2EFB2@ORSMSX107.amr.corp.intel.com>
From: "Duyck, Alexander H" <alexander.h.duyck@intel.com>
Date: Thu, 27 Apr 2017 15:21:16 +0000
>> -----Original Message-----
>> From: Chiappero, Marco
>> Sent: Thursday, April 27, 2017 7:52 AM
>> To: netdev@vger.kernel.org
>> Cc: David S . Miller <davem@davemloft.net>; Kirsher, Jeffrey T
>> <jeffrey.t.kirsher@intel.com>; Duyck, Alexander H
>> <alexander.h.duyck@intel.com>; Grandhi, Sainath
>> <sainath.grandhi@intel.com>; Mahesh Bandewar <maheshb@google.com>;
>> Chiappero, Marco <marco.chiappero@intel.com>
>> Subject: [PATCH net-next 8/9] ipvlan: improve compiler hints
>>
>> Extend inlining and branch prediction hints.
>>
>> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
>> ---
>> drivers/net/ipvlan/ipvlan_core.c | 6 +++---
>> 1 file changed, 3 insertions(+), 3 deletions(-)
>>
>> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
>> index a9fc1b5..67e342d 100644
>> --- a/drivers/net/ipvlan/ipvlan_core.c
>> +++ b/drivers/net/ipvlan/ipvlan_core.c
>> @@ -88,7 +88,7 @@ void ipvlan_ht_addr_del(struct ipvl_addr *addr)
>> hlist_del_init_rcu(&addr->hlnode);
>> }
>>
>> -unsigned int ipvlan_mac_hash(const unsigned char *addr)
>> +inline unsigned int ipvlan_mac_hash(const unsigned char *addr)
>> {
>> u32 hash = jhash_1word(__get_unaligned_cpu32(addr + 2),
>> ipvlan_jhash_secret);
>
> I'm kind of surprised this isn't causing a problem with differing
> declarations between the declaration here and the declaration in
> ipvlan.h. Normally for inlining something like this you would change
> it to a "static inline" and move the entire declaration into the
> header file.
No inlines in foo.c files please, seriously let the compiler decide
it knows better than you.
^ permalink raw reply
* Re: [PATCH net-next 6/6] bpf: show bpf programs
From: David Miller @ 2017-04-27 16:00 UTC (permalink / raw)
To: hannes; +Cc: daniel, netdev, ast, daniel, jbenc, aconole
In-Reply-To: <5b1f23e3-86a7-69aa-91e2-1dc72125f22b@stressinduktion.org>
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
Date: Thu, 27 Apr 2017 15:22:49 +0200
> Sure, that sounds super. But so far Linux and most (maybe I should write
> all) subsystems always provided some easy way to get the insights of the
> kernel without having to code or rely on special tools so far.
Not true.
You cannot fully dump socket TCP internal state without netlink based
tools. It is just one of many examples.
Can you dump all nftables rules without a special tool?
I don't think this is a legitimate line of argument, and I want
this to be done via the bpf() system call which is what people
are working on.
Thanks.
^ permalink raw reply
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Logan Gunthorpe @ 2017-04-27 15:57 UTC (permalink / raw)
To: Jason Gunthorpe, Christoph Hellwig
Cc: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, James E.J. Bottomley,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
Martin K. Petersen, Greg Kroah-Hartman,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427152720.GA7662-ePGOBjL8dl3ta4EC/59zMFaTQe2KTcn/@public.gmane.org>
On 27/04/17 09:27 AM, Jason Gunthorpe wrote:
> On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> How about first switching as many call sites as possible to use
> sg_copy_X_buffer instead of kmap?
Yeah, I could look at doing that first.
One problem is we might get more Naks of the form of Herbert Xu's who
might be concerned with the performance implications.
These are definitely a bit more invasive changes than thin wrappers
around kmap calls.
> A random audit of Logan's series suggests this is actually a fairly
> common thing.
It's not _that_ common but there are a significant fraction. One of my
patches actually did this to two places that seemed to be reimplementing
the sg_copy_X_buffer logic.
Thanks,
Logan
^ permalink raw reply
* Re: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: David Miller @ 2017-04-27 15:54 UTC (permalink / raw)
To: Jason; +Cc: netdev, linux-kernel, David.Laight, kernel-hardening
In-Reply-To: <CAHmME9qDmcvzF_xeaxegC2RpBOs8PziJOaKEqv6Z_X1pUFbR0w@mail.gmail.com>
From: "Jason A. Donenfeld" <Jason@zx2c4.com>
Date: Thu, 27 Apr 2017 11:21:51 +0200
> Hey Dave,
>
> David Laight and I have been discussing offlist. It occurred to both
> of us that this could just be turned into a loop because perhaps this
> is actually just tail-recursive. Upon further inspection, however, the
> way the current algorithm works, it's possible that each of the
> fraglist skbs has its own fraglist, which would make this into tree
> recursion, which is why in the first place I wanted to place that
> limit on it. If that's the case, then the patch I proposed above is
> the best way forward. However, perhaps there's the chance that
> fraglist skbs having separate fraglists are actually forbidden? Is
> this the case? Are there other parts of the API that enforce this
> contract? Is it something we could safely rely on here? If you say
> yes, I'll send a v7 that makes this into a non-recursive loop.
As Sabrina showed, it can happen. There are no such restrictions on
the geometry of an SKB.
^ permalink raw reply
* Re: rhashtable - Cap total number of entries to 2^31
From: David Miller @ 2017-04-27 15:48 UTC (permalink / raw)
To: herbert; +Cc: fw, netdev, tgraf
In-Reply-To: <20170427054451.GA529@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Thu, 27 Apr 2017 13:44:51 +0800
> When max_size is not set or if it set to a sufficiently large
> value, the nelems counter can overflow. This would cause havoc
> with the automatic shrinking as it would then attempt to fit a
> huge number of entries into a tiny hash table.
>
> This patch fixes this by adding max_elems to struct rhashtable
> to cap the number of elements. This is set to 2^31 as nelems is
> not a precise count. This is sufficiently smaller than UINT_MAX
> that it should be safe.
>
> When max_size is set max_elems will be lowered to at most twice
> max_size as is the status quo.
>
> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied to net-next, thanks Herbert.
^ permalink raw reply
* Re: [PATCH net-next] tcp: tcp_rack_reo_timeout() must update tp->tcp_mstamp
From: David Miller @ 2017-04-27 15:46 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, soheil, ncardwell, ycheng
In-Reply-To: <1493266255.6453.103.camel@edumazet-glaptop3.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 26 Apr 2017 21:10:55 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> I wrongly assumed tp->tcp_mstamp was up to date at the time
> tcp_rack_reo_timeout() was called.
>
> It is not true, since we only update tcp->tcp_mstamp when receiving
> a packet (as initially done in commit 69e996c58a35 ("tcp: add
> tp->tcp_mstamp field")
>
> tcp_rack_reo_timeout() being called by a timer and not an incoming
> packet, we need to refresh tp->tcp_mstamp
>
> Fixes: 7c1c7308592f ("tcp: do not pass timestamp to tcp_rack_detect_loss()")
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH v2 07/21] crypto: shash, caam: Make use of the new sg_map helper function
From: Logan Gunthorpe @ 2017-04-27 15:45 UTC (permalink / raw)
To: Herbert Xu
Cc: dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA, Christoph Hellwig,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, James E.J. Bottomley,
linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-nvdimm-hn68Rpc1hR1g9hUCZPvPmw,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
Martin K. Petersen, netdev-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman,
David S. Miller
In-Reply-To: <20170427035603.GA32212-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
On 26/04/17 09:56 PM, Herbert Xu wrote:
> On Tue, Apr 25, 2017 at 12:20:54PM -0600, Logan Gunthorpe wrote:
>> Very straightforward conversion to the new function in the caam driver
>> and shash library.
>>
>> Signed-off-by: Logan Gunthorpe <logang-OTvnGxWRz7hWk0Htik3J/w@public.gmane.org>
>> Cc: Herbert Xu <herbert-lOAM2aK0SrRLBo1qDEOMRrpzq4S04n8Q@public.gmane.org>
>> Cc: "David S. Miller" <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
>> ---
>> crypto/shash.c | 9 ++++++---
>> drivers/crypto/caam/caamalg.c | 8 +++-----
>> 2 files changed, 9 insertions(+), 8 deletions(-)
>>
>> diff --git a/crypto/shash.c b/crypto/shash.c
>> index 5e31c8d..5914881 100644
>> --- a/crypto/shash.c
>> +++ b/crypto/shash.c
>> @@ -283,10 +283,13 @@ int shash_ahash_digest(struct ahash_request *req, struct shash_desc *desc)
>> if (nbytes < min(sg->length, ((unsigned int)(PAGE_SIZE)) - offset)) {
>> void *data;
>>
>> - data = kmap_atomic(sg_page(sg));
>> - err = crypto_shash_digest(desc, data + offset, nbytes,
>> + data = sg_map(sg, 0, SG_KMAP_ATOMIC);
>> + if (IS_ERR(data))
>> + return PTR_ERR(data);
>> +
>> + err = crypto_shash_digest(desc, data, nbytes,
>> req->result);
>> - kunmap_atomic(data);
>> + sg_unmap(sg, data, 0, SG_KMAP_ATOMIC);
>> crypto_yield(desc->flags);
>> } else
>> err = crypto_shash_init(desc) ?:
>
> Nack. This is an optimisation for the special case of a single
> SG list entry. In fact in the common case the kmap_atomic should
> disappear altogether in the no-highmem case. So replacing it
> with sg_map is not acceptable.
What you seem to have missed is that sg_map is just a thin wrapper
around kmap_atomic. Perhaps with a future check for a mappable page.
This change should have zero impact on performance.
Logan
^ permalink raw reply
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Logan Gunthorpe @ 2017-04-27 15:44 UTC (permalink / raw)
To: Christoph Hellwig
Cc: dri-devel, Stephen Bates, dm-devel, target-devel, Sumit Semwal,
devel, James E.J. Bottomley, linux-scsi, linux-nvdimm, linux-rdma,
Ross Zwisler, open-iscsi, linux-media, intel-gfx, sparmaintainer,
linux-raid, Dan Williams, megaraidlinux.pdl, Jens Axboe,
Martin K. Petersen, netdev, Matthew Wilcox, linux-mmc,
linux-kernel, linux-crypto, Greg Kroah-Hartman
In-Reply-To: <20170427065338.GA20677@lst.de>
On 27/04/17 12:53 AM, Christoph Hellwig wrote:
> I think you'll need to follow the existing kmap semantics and never
> fail the iomem version either. Otherwise you'll have a special case
> that's almost never used that has a different error path.
>
> Again, wrong way. Suddenly making things fail for your special case
> that normally don't fail is a receipe for bugs.
I don't disagree but these restrictions make the problem impossible to
solve? If there is iomem behind a page in an SGL and someone tries to
map it, we either have to fail or we break iomem safety which was your
original concern.
Logan
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: Realtek RTL8101E PCI-E ethernet controller does not work with the r8169 driver
From: Piotr Gabriel Kosinski @ 2017-04-27 15:33 UTC (permalink / raw)
To: netdev
In-Reply-To: <CAFMLSdOBwO4zWZo48EymSGw=4i5DSDfc4VjrxBjWaM5h5DBknw@mail.gmail.com>
00:00.0 Host bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx
Series SoC Transaction Register (rev 0a)
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx Series SoC Transaction Register
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Kernel driver in use: iosf_mbi_pci
00:02.0 VGA compatible controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Graphics & Display (rev 0a) (prog-if 00 [VGA
controller])
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx Series Graphics & Display
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 90
Region 0: Memory at c0000000 (32-bit, non-prefetchable) [size=4M]
Region 2: Memory at d0000000 (32-bit, prefetchable) [size=256M]
Region 4: I/O ports at f080 [size=8]
[virtual] Expansion ROM at 000c0000 [disabled] [size=128K]
Capabilities: [d0] Power Management version 2
Flags: PMEClk- DSI+ D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [90] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0200c Data: 41d1
Capabilities: [b0] Vendor Specific Information: Len=07 <?>
Kernel driver in use: i915
Kernel modules: i915
00:13.0 SATA controller: Intel Corporation Atom Processor E3800 Series
SATA AHCI Controller (rev 0a) (prog-if 01 [AHCI 1.0])
Subsystem: Toshiba America Info Systems Atom Processor E3800
Series SATA AHCI Controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 88
Region 0: I/O ports at f070 [size=8]
Region 1: I/O ports at f060 [size=4]
Region 2: I/O ports at f050 [size=8]
Region 3: I/O ports at f040 [size=4]
Region 4: I/O ports at f020 [size=32]
Region 5: Memory at c0815000 (32-bit, non-prefetchable) [size=2K]
Capabilities: [80] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0200c Data: 41b1
Capabilities: [70] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a8] SATA HBA v1.0 BAR4 Offset=00000004
Kernel driver in use: ahci
Kernel modules: ahci
00:14.0 USB controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI (rev 0a) (prog-if 30
[XHCI])
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx, Celeron N2000 Series USB xHCI
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 87
Region 0: Memory at c0800000 (64-bit, non-prefetchable) [size=64K]
Capabilities: [70] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=375mA
PME(D0-,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [80] MSI: Enable+ Count=1/8 Maskable- 64bit+
Address: 00000000fee0200c Data: 4191
Kernel driver in use: xhci_hcd
00:1a.0 Encryption controller: Intel Corporation Atom Processor
Z36xxx/Z37xxx Series Trusted Execution Engine (rev 0a)
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx Series Trusted Execution Engine
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 91
Region 0: Memory at c0500000 (32-bit, non-prefetchable) [size=1M]
Region 1: Memory at c0400000 (32-bit, non-prefetchable) [size=1M]
Capabilities: [80] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [a0] MSI: Enable+ Count=1/1 Maskable- 64bit-
Address: fee0300c Data: 41e1
Kernel driver in use: mei_txe
Kernel modules: mei_txe
00:1b.0 Audio device: Intel Corporation Atom Processor Z36xxx/Z37xxx
Series High Definition Audio Controller (rev 0a)
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx Series High Definition Audio Controller
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 92
Region 0: Memory at c0810000 (64-bit, non-prefetchable) [size=16K]
Capabilities: [50] Power Management version 2
Flags: PMEClk- DSI- D1- D2- AuxCurrent=55mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 4142
Kernel driver in use: snd_hda_intel
Kernel modules: snd_hda_intel
00:1c.0 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 1 (rev 0a) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 16
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: 00001000-00001fff
Memory behind bridge: c0900000-c0afffff
Prefetchable memory behind bridge: 00000000c0b00000-00000000c0cfffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #1, Speed 5GT/s, Width x1, ASPM L0s L1, Exit
Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x0, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #0, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet- Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis-, LTR-,
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Toshiba America Info Systems Atom
Processor E3800 Series PCI Express Root Port 1
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.1 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 2 (rev 0a) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin B routed to IRQ 17
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: 00002000-00002fff
Memory behind bridge: c0700000-c07fffff
Prefetchable memory behind bridge: 00000000c0d00000-00000000c0efffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #2, Speed 5GT/s, Width x1, ASPM L0s L1, Exit
Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #1, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR-,
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Toshiba America Info Systems Atom
Processor E3800 Series PCI Express Root Port 2
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1c.2 PCI bridge: Intel Corporation Atom Processor E3800 Series PCI
Express Root Port 3 (rev 0a) (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin C routed to IRQ 18
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: 0000e000-0000efff
Memory behind bridge: c0600000-c06fffff
Prefetchable memory behind bridge: 00000000e0000000-00000000e00fffff
Secondary status: 66MHz- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort+ <SERR- <PERR-
BridgeCtl: Parity- SERR- NoISA- VGA- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [40] Express (v2) Root Port (Slot+), MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0
ExtTag- RBE+
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 128 bytes
DevSta: CorrErr- UncorrErr- FatalErr- UnsuppReq- AuxPwr+ TransPend-
LnkCap: Port #3, Speed 5GT/s, Width x1, ASPM L0s L1, Exit
Latency L0s <512ns, L1 <4us
ClockPM- Surprise- LLActRep+ BwNot+ ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive+ BWMgmt+ ABWMgmt-
SltCap: AttnBtn- PwrCtrl- MRL- AttnInd- PwrInd- HotPlug+ Surprise+
Slot #2, PowerLimit 10.000W; Interlock- NoCompl+
SltCtl: Enable: AttnBtn- PwrFlt- MRL- PresDet- CmdCplt-
HPIrq- LinkChg-
Control: AttnInd Unknown, PwrInd Unknown, Power- Interlock-
SltSta: Status: AttnBtn- PowerFlt- MRL- CmdCplt- PresDet+ Interlock-
Changed: MRL- PresDet- LinkState-
RootCtl: ErrCorrectable- ErrNon-Fatal- ErrFatal- PMEIntEna- CRSVisible-
RootCap: CRSVisible-
RootSta: PME ReqID 0000, PMEStatus- PMEPending-
DevCap2: Completion Timeout: Range BC, TimeoutDis+, LTR-, OBFF
Not Supported ARIFwd-
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR-,
OBFF Disabled ARIFwd-
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -3.5dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [80] MSI: Enable- Count=1/1 Maskable- 64bit-
Address: 00000000 Data: 0000
Capabilities: [90] Subsystem: Toshiba America Info Systems Atom
Processor E3800 Series PCI Express Root Port 3
Capabilities: [a0] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0+,D1-,D2-,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Kernel driver in use: pcieport
Kernel modules: shpchp
00:1f.0 ISA bridge: Intel Corporation Atom Processor Z36xxx/Z37xxx
Series Power Control Unit (rev 0a)
Subsystem: Toshiba America Info Systems Atom Processor
Z36xxx/Z37xxx Series Power Control Unit
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Capabilities: [e0] Vendor Specific Information: Len=0c <?>
Kernel driver in use: lpc_ich
Kernel modules: lpc_ich
00:1f.3 SMBus: Intel Corporation Atom Processor E3800 Series SMBus
Controller (rev 0a)
Subsystem: Toshiba America Info Systems Atom Processor E3800
Series SMBus Controller
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin B routed to IRQ 255
Region 0: Memory at c0814000 (32-bit, non-prefetchable) [size=32]
Region 4: I/O ports at f000 [size=32]
Capabilities: [50] Power Management version 3
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Kernel modules: i2c_i801
02:00.0 Network controller: Qualcomm Atheros QCA9565 / AR9565 Wireless
Network Adapter (rev 01)
Subsystem: XAVi Technologies Corp. QCA9565 / AR9565 Wireless Network Adapter
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 17
Region 0: Memory at c0700000 (64-bit, non-prefetchable) [size=512K]
Expansion ROM at c0780000 [disabled] [size=64K]
Capabilities: [40] Power Management version 2
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable- Count=1/4 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [70] Express (v2) Endpoint, MSI 00
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
Latency L0s <4us, L1 <64us
ClockPM- Surprise- LLActRep- BwNot- ASPMOptComp-
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Not Supported, TimeoutDis+, LTR-,
OBFF Not Supported
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR-,
OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap- CGenEn- ChkCap- ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
Kernel driver in use: ath9k
Kernel modules: ath9k
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd.
RTL8101/2/6E PCI Express Fast/Gigabit Ethernet controller (rev 07)
Subsystem: Toshiba America Info Systems RTL8101/2/6E PCI Express
Fast/Gigabit Ethernet controller
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
ParErr- Stepping- SERR- FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort-
<TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0, Cache Line Size: 64 bytes
Interrupt: pin A routed to IRQ 89
Region 0: I/O ports at e000 [size=256]
Region 2: Memory at e0004000 (64-bit, prefetchable) [size=4K]
Region 4: Memory at e0000000 (64-bit, prefetchable) [size=16K]
Expansion ROM at c0600000 [disabled] [size=64K]
Capabilities: [40] Power Management version 3
Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=375mA
PME(D0+,D1+,D2+,D3hot+,D3cold+)
Status: D0 NoSoftRst+ PME-Enable- DSel=0 DScale=0 PME-
Capabilities: [50] MSI: Enable+ Count=1/1 Maskable- 64bit+
Address: 00000000fee0300c Data: 41c1
Capabilities: [70] Express (v2) Endpoint, MSI 01
DevCap: MaxPayload 128 bytes, PhantFunc 0, Latency L0s
unlimited, L1 <64us
ExtTag- AttnBtn- AttnInd- PwrInd- RBE+ FLReset-
DevCtl: Report errors: Correctable- Non-Fatal- Fatal- Unsupported-
RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop-
MaxPayload 128 bytes, MaxReadReq 512 bytes
DevSta: CorrErr+ UncorrErr- FatalErr- UnsuppReq+ AuxPwr+ TransPend-
LnkCap: Port #0, Speed 2.5GT/s, Width x1, ASPM L0s L1, Exit
Latency L0s unlimited, L1 <64us
ClockPM+ Surprise- LLActRep- BwNot- ASPMOptComp+
LnkCtl: ASPM Disabled; RCB 64 bytes Disabled- CommClk+
ExtSynch- ClockPM- AutWidDis- BWInt- AutBWInt-
LnkSta: Speed 2.5GT/s, Width x1, TrErr- Train- SlotClk+
DLActive- BWMgmt- ABWMgmt-
DevCap2: Completion Timeout: Range ABCD, TimeoutDis+, LTR+,
OBFF Via message/WAKE#
DevCtl2: Completion Timeout: 50us to 50ms, TimeoutDis+, LTR+,
OBFF Disabled
LnkCtl2: Target Link Speed: 2.5GT/s, EnterCompliance- SpeedDis-
Transmit Margin: Normal Operating Range,
EnterModifiedCompliance- ComplianceSOS-
Compliance De-emphasis: -6dB
LnkSta2: Current De-emphasis Level: -6dB,
EqualizationComplete-, EqualizationPhase1-
EqualizationPhase2-, EqualizationPhase3-, LinkEqualizationRequest-
Capabilities: [b0] MSI-X: Enable- Count=4 Masked-
Vector table: BAR=4 offset=00000000
PBA: BAR=4 offset=00000800
Capabilities: [d0] Vital Product Data
Not readable
Capabilities: [100 v1] Advanced Error Reporting
UESta: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UEMsk: DLP- SDES- TLP- FCP- CmpltTO- CmpltAbrt- UnxCmplt-
RxOF- MalfTLP- ECRC- UnsupReq- ACSViol-
UESvrt: DLP+ SDES+ TLP- FCP+ CmpltTO- CmpltAbrt- UnxCmplt-
RxOF+ MalfTLP+ ECRC- UnsupReq- ACSViol-
CESta: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr-
CEMsk: RxErr- BadTLP- BadDLLP- Rollover- Timeout- NonFatalErr+
AERCap: First Error Pointer: 00, GenCap+ CGenEn- ChkCap+ ChkEn-
Capabilities: [140 v1] Virtual Channel
Caps: LPEVC=0 RefClk=100ns PATEntryBits=1
Arb: Fixed- WRR32- WRR64- WRR128-
Ctrl: ArbSelect=Fixed
Status: InProgress-
VC0: Caps: PATOffset=00 MaxTimeSlots=1 RejSnoopTrans-
Arb: Fixed- WRR32- WRR64- WRR128- TWRR128- WRR256-
Ctrl: Enable+ ID=0 ArbSelect=Fixed TC/VC=01
Status: NegoPending- InProgress-
Capabilities: [160 v1] Device Serial Number 00-00-00-00-00-00-00-00
Capabilities: [170 v1] Latency Tolerance Reporting
Max snoop latency: 71680ns
Max no snoop latency: 71680ns
Kernel driver in use: r8169
Kernel modules: r8169
2017-04-27 17:31 GMT+02:00 Piotr Gabriel Kosinski <pg.kosinski@gmail.com>:
> The Realtek RTL8101E PCI Express ethernet controller does not work
> with the r8169 driver, on kernel 4.10 (it also did not work on earlier
> kernels). These are the messages from the kernel log:
>
> [ 11.359593] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
> [ 11.359611] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have
> ASPM control
> [ 11.359803] r8169 0000:03:00.0 (unnamed net_device)
> (uninitialized): unknown MAC, using family default
> [ 11.369802] r8169 0000:03:00.0 (unnamed net_device)
> (uninitialized): rtl_chipcmd_cond == 1 (loop: 100, delay: 100).
> [ 11.406668] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop:
> 1000, delay: 10).
> [ 11.406815] r8169 0000:03:00.0 eth0: RTL8101e at
> 0xffffb3140068d000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 89
> [ 11.482740] r8169 0000:03:00.0 enp3s0: renamed from eth0
> [ 11.501187] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 33.348246] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 34.273602] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 35.195420] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 35.678908] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
> [ 36.401291] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
> [ 36.411989] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
> (loop: 1000, delay: 10).
>
> the rtl_counters_cond message is then regularly repeated.
>
> ifconfig's ether address shows ff:ff:ff:ff:ff:ff
>
>
> If that is of any help - the controller works on FreeBSD's re driver,
> but only when the following two loader options are set:
> hw.re.msix_disable=1
> hw.re.prefer_iomap=1
>
> Both of these options must be set to 1. If prefer_iomap is not set,
> there are messages like:
> re0: reset never completed!
> re0: PHY write failed
> re0: attaching PHYs failed
> device_attach: re0 attach returned 6
>
> If msix_disable is not set (msix is enabled), there are no error
> messages and mac address is read correctly, but the controller does
> not work (no connection can be established, e.g. DHCP).
>
> If both of the above options are set to 1, the controller works fine,
> with the following messages:
> re0: <RealTek 810xE PCIe 10/100baseTX> port 0xe000-0xe0ff mem
> 0xe0004000-0xe0004fff,0xe0000000-0xe0003fff at device 0.0 on pci2
> re0: Using 1 MSI message
> re0: Chip rev. 0x44800000
> re0: MAC rev. 0x00100000
> miibus0: <MII bus> on re0
> rlphy0: <RTL8201E 10/100 media interface> PHY 1 on miibus0
> rlphy0: 10baseT, 100baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
> re0: Using defaults for TSO: 65518/35/2048
> re0: netmap queues/slots: TX 1/256, RX 1/256
> re0: link state changed to DOWN
> re0: link state changed to UP
>
> The problem occurs e.g. on Intel Atom-based Toshiba NB10-A-104 Netbook.
> In the next mail I will attach lspci -vvv output.
>
> Thank you,
> Piotr.
^ permalink raw reply
* Realtek RTL8101E PCI-E ethernet controller does not work with the r8169 driver
From: Piotr Gabriel Kosinski @ 2017-04-27 15:31 UTC (permalink / raw)
To: netdev
The Realtek RTL8101E PCI Express ethernet controller does not work
with the r8169 driver, on kernel 4.10 (it also did not work on earlier
kernels). These are the messages from the kernel log:
[ 11.359593] r8169 Gigabit Ethernet driver 2.3LK-NAPI loaded
[ 11.359611] r8169 0000:03:00.0: can't disable ASPM; OS doesn't have
ASPM control
[ 11.359803] r8169 0000:03:00.0 (unnamed net_device)
(uninitialized): unknown MAC, using family default
[ 11.369802] r8169 0000:03:00.0 (unnamed net_device)
(uninitialized): rtl_chipcmd_cond == 1 (loop: 100, delay: 100).
[ 11.406668] r8169 0000:03:00.0 eth0: rtl_counters_cond == 1 (loop:
1000, delay: 10).
[ 11.406815] r8169 0000:03:00.0 eth0: RTL8101e at
0xffffb3140068d000, ff:ff:ff:ff:ff:ff, XID 9cf0f8ff IRQ 89
[ 11.482740] r8169 0000:03:00.0 enp3s0: renamed from eth0
[ 11.501187] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
[ 33.348246] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
[ 34.273602] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
[ 35.195420] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
[ 35.678908] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
[ 36.401291] IPv6: ADDRCONF(NETDEV_UP): enp3s0: link is not ready
[ 36.411989] r8169 0000:03:00.0 enp3s0: rtl_counters_cond == 1
(loop: 1000, delay: 10).
the rtl_counters_cond message is then regularly repeated.
ifconfig's ether address shows ff:ff:ff:ff:ff:ff
If that is of any help - the controller works on FreeBSD's re driver,
but only when the following two loader options are set:
hw.re.msix_disable=1
hw.re.prefer_iomap=1
Both of these options must be set to 1. If prefer_iomap is not set,
there are messages like:
re0: reset never completed!
re0: PHY write failed
re0: attaching PHYs failed
device_attach: re0 attach returned 6
If msix_disable is not set (msix is enabled), there are no error
messages and mac address is read correctly, but the controller does
not work (no connection can be established, e.g. DHCP).
If both of the above options are set to 1, the controller works fine,
with the following messages:
re0: <RealTek 810xE PCIe 10/100baseTX> port 0xe000-0xe0ff mem
0xe0004000-0xe0004fff,0xe0000000-0xe0003fff at device 0.0 on pci2
re0: Using 1 MSI message
re0: Chip rev. 0x44800000
re0: MAC rev. 0x00100000
miibus0: <MII bus> on re0
rlphy0: <RTL8201E 10/100 media interface> PHY 1 on miibus0
rlphy0: 10baseT, 100baseT-FDX, 100baseTX, 100baseTX-FDX, auto, auto-flow
re0: Using defaults for TSO: 65518/35/2048
re0: netmap queues/slots: TX 1/256, RX 1/256
re0: link state changed to DOWN
re0: link state changed to UP
The problem occurs e.g. on Intel Atom-based Toshiba NB10-A-104 Netbook.
In the next mail I will attach lspci -vvv output.
Thank you,
Piotr.
^ permalink raw reply
* [PATCH net-next] rhashtable: compact struct rhashtable_params
From: Florian Westphal @ 2017-04-27 15:28 UTC (permalink / raw)
To: netdev; +Cc: Florian Westphal
By using smaller datatypes this struct shrinks considerably
(80 -> 48 bytes on x86_64).
As this is embedded in other structs, this also reduces size of several
others, e.g. cls_fl_head and nft_hash.
Signed-off-by: Florian Westphal <fw@strlen.de>
---
include/linux/rhashtable.h | 18 +++++++++---------
lib/rhashtable.c | 2 +-
2 files changed, 10 insertions(+), 10 deletions(-)
diff --git a/include/linux/rhashtable.h b/include/linux/rhashtable.h
index 8e628feb8708..77cf43166383 100644
--- a/include/linux/rhashtable.h
+++ b/include/linux/rhashtable.h
@@ -127,23 +127,23 @@ struct rhashtable;
* @head_offset: Offset of rhash_head in struct to be hashed
* @max_size: Maximum size while expanding
* @min_size: Minimum size while shrinking
- * @nulls_base: Base value to generate nulls marker
- * @automatic_shrinking: Enable automatic shrinking of tables
* @locks_mul: Number of bucket locks to allocate per cpu (default: 128)
+ * @automatic_shrinking: Enable automatic shrinking of tables
+ * @nulls_base: Base value to generate nulls marker
* @hashfn: Hash function (default: jhash2 if !(key_len % 4), or jhash)
* @obj_hashfn: Function to hash object
* @obj_cmpfn: Function to compare key with object
*/
struct rhashtable_params {
- size_t nelem_hint;
- size_t key_len;
- size_t key_offset;
- size_t head_offset;
+ u16 nelem_hint;
+ u16 key_len;
+ u16 key_offset;
+ u16 head_offset;
unsigned int max_size;
- unsigned int min_size;
- u32 nulls_base;
+ u16 min_size;
bool automatic_shrinking;
- size_t locks_mul;
+ u8 locks_mul;
+ u32 nulls_base;
rht_hashfn_t hashfn;
rht_obj_hashfn_t obj_hashfn;
rht_obj_cmpfn_t obj_cmpfn;
diff --git a/lib/rhashtable.c b/lib/rhashtable.c
index 1fd7986aa9b4..4462676a26f2 100644
--- a/lib/rhashtable.c
+++ b/lib/rhashtable.c
@@ -961,7 +961,7 @@ int rhashtable_init(struct rhashtable *ht,
if (params->max_size)
ht->p.max_size = rounddown_pow_of_two(params->max_size);
- ht->p.min_size = max(ht->p.min_size, HASH_MIN_SIZE);
+ ht->p.min_size = max_t(u16, ht->p.min_size, HASH_MIN_SIZE);
if (params->nelem_hint)
size = rounded_hashtable_size(&ht->p);
--
2.10.2
^ permalink raw reply related
* RE: [PATCH net-next 8/9] ipvlan: improve compiler hints
From: David Laight @ 2017-04-27 15:27 UTC (permalink / raw)
To: 'Duyck, Alexander H', Chiappero, Marco,
netdev@vger.kernel.org
Cc: David S . Miller, Kirsher, Jeffrey T, Grandhi, Sainath,
Mahesh Bandewar
In-Reply-To: <B1C1DF2ACD01FD4881736AA51731BAB2B2EFB2@ORSMSX107.amr.corp.intel.com>
From: Duyck, Alexander H
> Sent: 27 April 2017 16:21
...
> > -unsigned int ipvlan_mac_hash(const unsigned char *addr)
> > +inline unsigned int ipvlan_mac_hash(const unsigned char *addr)
> > {
> > u32 hash = jhash_1word(__get_unaligned_cpu32(addr + 2),
> > ipvlan_jhash_secret);
>
> I'm kind of surprised this isn't causing a problem with differing declarations between the declaration
> here and the declaration in ipvlan.h. Normally for inlining something like this you would change it to
> a "static inline" and move the entire declaration into the header file.
You get a callable copy for external callers and local calls inlined.
Not usually what you want.
David
^ permalink raw reply
* Re: [PATCH v2 01/21] scatterlist: Introduce sg_map helper functions
From: Jason Gunthorpe @ 2017-04-27 15:27 UTC (permalink / raw)
To: Christoph Hellwig
Cc: linux-nvdimm-y27Ovi1pjclAfugRpC6u6w,
dri-devel-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
dm-devel-H+wXaHxf7aLQT0dZR+AlfA,
target-devel-u79uwXL29TY76Z2rM5mHXA, Sumit Semwal,
devel-gWbeCf7V1WCQmaza687I9mD2FQJk+8+b, James E.J. Bottomley,
linux-scsi-u79uwXL29TY76Z2rM5mHXA, Matthew Wilcox,
linux-rdma-u79uwXL29TY76Z2rM5mHXA,
open-iscsi-/JYPxA39Uh5TLH3MbocFFw,
linux-media-u79uwXL29TY76Z2rM5mHXA,
intel-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW,
sparmaintainer-GLv8BlqOqDDQT0dZR+AlfA,
linux-raid-u79uwXL29TY76Z2rM5mHXA,
megaraidlinux.pdl-dY08KVG/lbpWk0Htik3J/w, Jens Axboe,
Martin K. Petersen, Greg Kroah-Hartman,
linux-mmc-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-crypto-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20170427065338.GA20677-jcswGhMUV9g@public.gmane.org>
On Thu, Apr 27, 2017 at 08:53:38AM +0200, Christoph Hellwig wrote:
> > The main difficulty we
> > have now is that neither of those functions are expected to fail and we
> > need them to be able to in cases where the page doesn't map to system
> > RAM. This patch series is trying to address it for users of scatterlist.
> > I'm certainly open to other suggestions.
>
> I think you'll need to follow the existing kmap semantics and never
> fail the iomem version either. Otherwise you'll have a special case
> that's almost never used that has a different error path.
How about first switching as many call sites as possible to use
sg_copy_X_buffer instead of kmap?
A random audit of Logan's series suggests this is actually a fairly
common thing.
eg drivers/mmc/host/sdhci.c is only doing this:
buffer = sdhci_kmap_atomic(sg, &flags);
memcpy(buffer, align, size);
sdhci_kunmap_atomic(buffer, &flags);
drivers/scsi/mvsas/mv_sas.c is this:
+ to = sg_map(sg_resp, 0, SG_KMAP_ATOMIC);
+ memcpy(to,
+ slot->response + sizeof(struct mvs_err_info),
+ sg_dma_len(sg_resp));
+ sg_unmap(sg_resp, to, 0, SG_KMAP_ATOMIC);
etc.
Lots of other places seem similar, if not sometimes a little bit more
convoluted..
Switching all the trivial cases to use copy might bring more clarity
as to what is actually required for the remaining few users? If there
are only a few then it may no longer matter if the API is not idyllic.
Jason
^ permalink raw reply
* RE: [PATCH net-next 8/9] ipvlan: improve compiler hints
From: Duyck, Alexander H @ 2017-04-27 15:21 UTC (permalink / raw)
To: Chiappero, Marco, netdev@vger.kernel.org
Cc: David S . Miller, Kirsher, Jeffrey T, Grandhi, Sainath,
Mahesh Bandewar
In-Reply-To: <20170427145142.15830-9-marco.chiappero@intel.com>
> -----Original Message-----
> From: Chiappero, Marco
> Sent: Thursday, April 27, 2017 7:52 AM
> To: netdev@vger.kernel.org
> Cc: David S . Miller <davem@davemloft.net>; Kirsher, Jeffrey T
> <jeffrey.t.kirsher@intel.com>; Duyck, Alexander H
> <alexander.h.duyck@intel.com>; Grandhi, Sainath
> <sainath.grandhi@intel.com>; Mahesh Bandewar <maheshb@google.com>;
> Chiappero, Marco <marco.chiappero@intel.com>
> Subject: [PATCH net-next 8/9] ipvlan: improve compiler hints
>
> Extend inlining and branch prediction hints.
>
> Signed-off-by: Marco Chiappero <marco.chiappero@intel.com>
> ---
> drivers/net/ipvlan/ipvlan_core.c | 6 +++---
> 1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/drivers/net/ipvlan/ipvlan_core.c b/drivers/net/ipvlan/ipvlan_core.c
> index a9fc1b5..67e342d 100644
> --- a/drivers/net/ipvlan/ipvlan_core.c
> +++ b/drivers/net/ipvlan/ipvlan_core.c
> @@ -88,7 +88,7 @@ void ipvlan_ht_addr_del(struct ipvl_addr *addr)
> hlist_del_init_rcu(&addr->hlnode);
> }
>
> -unsigned int ipvlan_mac_hash(const unsigned char *addr)
> +inline unsigned int ipvlan_mac_hash(const unsigned char *addr)
> {
> u32 hash = jhash_1word(__get_unaligned_cpu32(addr + 2),
> ipvlan_jhash_secret);
I'm kind of surprised this isn't causing a problem with differing declarations between the declaration here and the declaration in ipvlan.h. Normally for inlining something like this you would change it to a "static inline" and move the entire declaration into the header file.
> @@ -505,7 +505,7 @@ static int ipvlan_xmit_mode_l2(struct sk_buff *skb,
> struct net_device *dev)
> return ipvlan_rcv_int_frame(addr, &skb);
>
> skb = skb_share_check(skb, GFP_ATOMIC);
> - if (!skb)
> + if (unlikely(!skb))
> return NET_XMIT_DROP;
>
> /* Packet definitely does not belong to any of the @@ -596,7
> +596,7 @@ static rx_handler_result_t ipvlan_handle_mode_l2(struct sk_buff
> **pskb,
> * when work-queue processes this frame. This is
> * achieved by returning RX_HANDLER_PASS.
> */
> - if (nskb)
> + if (likely(nskb))
> ipvlan_multicast_enqueue(port, nskb, false);
> }
> } else {
> --
> 2.9.3
^ permalink raw reply
* Re: [PATCH net-next 4/6] bpf: track if the bpf program was loaded with SYS_ADMIN capabilities
From: Jiri Benc @ 2017-04-27 14:56 UTC (permalink / raw)
To: Alexei Starovoitov
Cc: Hannes Frederic Sowa, netdev@vger.kernel.org, Alexei Starovoitov,
Aaron Conole, Daniel Borkmann
In-Reply-To: <CAADnVQ+GL6sYCff4eU4WXZYeZSi5BJ5amy6NQjuZk2=OjuM5+g@mail.gmail.com>
On Thu, 27 Apr 2017 07:49:29 -0700, Alexei Starovoitov wrote:
> there are bunch of other things that influence verifier.
> should we add all of them ?
Sure, why not? It's always good to be able to see the complete input
conditions while debugging.
Jiri
^ permalink raw reply
* RE: [PATCH v6 1/5] skbuff: return -EMSGSIZE in skb_to_sgvec to prevent overflow
From: David Laight @ 2017-04-27 14:54 UTC (permalink / raw)
To: 'Jason A. Donenfeld', Sabrina Dubroca
Cc: Netdev, LKML, kernel-hardening@lists.openwall.com, David Miller
In-Reply-To: <CAHmME9oa3LYsnBgguxFqbJwps1ai=cuHHEgSpfY36AQHAN5r1Q@mail.gmail.com>
From: Jason A. Donenfeld
> On Thu, Apr 27, 2017 at 1:30 PM, Sabrina Dubroca <sd@queasysnail.net> wrote:
> > Hmm, I think this can actually happen:
>
> Alright, perhaps better to err on the side of caution, then.
You only need to recurse if both pointers are set.
David
^ 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