* Re: RFC(v2): Audit Kernel Container IDs
From: Richard Guy Briggs @ 2017-12-11 15:10 UTC (permalink / raw)
To: Mickaël Salaün
Cc: Casey Schaufler, cgroups-u79uwXL29TY76Z2rM5mHXA, Linux Containers,
Linux API, Linux Audit, Linux FS Devel, Linux Kernel,
Linux Network Development, mszeredi-H+wXaHxf7aLQT0dZR+AlfA,
Eric W. Biederman, Simo Sorce, jlayton-H+wXaHxf7aLQT0dZR+AlfA,
Carlos O'Donell, David Howells, Al Viro, Andy Lutomirski,
Eric Paris, trondmy-7I+n7zu2hftEKMMhf/gKZA, Michael Kerrisk
In-Reply-To: <7ebca85a-425c-2b95-9a5f-59d81707339e-WFhQfpSGs3bR7s880joybQ@public.gmane.org>
On 2017-12-09 11:20, Mickaël Salaün wrote:
>
> On 12/10/2017 18:33, Casey Schaufler wrote:
> > On 10/12/2017 7:14 AM, Richard Guy Briggs wrote:
> >> Containers are a userspace concept. The kernel knows nothing of them.
> >>
> >> The Linux audit system needs a way to be able to track the container
> >> provenance of events and actions. Audit needs the kernel's help to do
> >> this.
> >>
> >> Since the concept of a container is entirely a userspace concept, a
> >> registration from the userspace container orchestration system initiates
> >> this. This will define a point in time and a set of resources
> >> associated with a particular container with an audit container ID.
> >>
> >> The registration is a pseudo filesystem (proc, since PID tree already
> >> exists) write of a u8[16] UUID representing the container ID to a file
> >> representing a process that will become the first process in a new
> >> container. This write might place restrictions on mount namespaces
> >> required to define a container, or at least careful checking of
> >> namespaces in the kernel to verify permissions of the orchestrator so it
> >> can't change its own container ID. A bind mount of nsfs may be
> >> necessary in the container orchestrator's mntNS.
> >> Note: Use a 128-bit scalar rather than a string to make compares faster
> >> and simpler.
> >>
> >> Require a new CAP_CONTAINER_ADMIN to be able to carry out the
> >> registration.
> >
> > Hang on. If containers are a user space concept, how can
> > you want CAP_CONTAINER_ANYTHING? If there's not such thing as
> > a container, how can you be asking for a capability to manage
> > them?
> >
> >> At that time, record the target container's user-supplied
> >> container identifier along with the target container's first process
> >> (which may become the target container's "init" process) process ID
> >> (referenced from the initial PID namespace), all namespace IDs (in the
> >> form of a nsfs device number and inode number tuple) in a new auxilliary
> >> record AUDIT_CONTAINER with a qualifying op=$action field.
>
> Here is an idea to avoid privilege problems or the need for a new
> capability: make it automatic. What makes a container a container seems
> to be the use of at least a namespace. What about automatically create
> and assign an ID to a process when it enters a namespace different than
> one of its parent process? This delegates the (permission)
> responsibility to the use of namespaces (e.g. /proc/sys/user/max_* limit).
A container doesn't imply a namespace and vice versa.
> One interesting side effect of this approach would be to be able to
> identify which processes are in the same set of namespaces, even if not
> spawn from the container but entered after its creation (i.e. using
> setns), by creating container IDs as a (deterministic) checksum from the
> /proc/self/ns/* IDs.
This would be really helpful, but it isn't the case.
> Since the concern is to identify a container, I think the ability to
> audit the switch from one container ID to another is enough. I don't
> think we need nested IDs.
Since container namespace membership is arbitrary between container
orchestrators, this needs a registration process and a way for the
container orchestrator to know the ID.
I completely agree with Casey here.
> As a side note, you may want to take a look at the Linux-VServer's XID.
>
> Regards,
> Mickaël
- RGB
--
Richard Guy Briggs <rgb-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
Sr. S/W Engineer, Kernel Security, Base Operating Systems
Remote, Ottawa, Red Hat Canada
IRC: rgb, SunRaycer
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* [PATCH net] ipv4: igmp: guard against silly MTU values
From: Eric Dumazet @ 2017-12-11 15:17 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
IPv4 stack reacts to changes to small MTU, by disabling itself under
RTNL.
But there is a window where threads not using RTNL can see a wrong
device mtu. This can lead to surprises, in igmp code where it is
assumed the mtu is suitable.
Fix this by reading device mtu once and checking IPv4 minimal MTU.
This patch adds missing IPV4_MIN_MTU define, to not abuse
ETH_MIN_MTU anymore.
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
include/net/ip.h | 1 +
net/ipv4/devinet.c | 2 +-
net/ipv4/igmp.c | 24 +++++++++++++++---------
net/ipv4/ip_tunnel.c | 4 ++--
4 files changed, 19 insertions(+), 12 deletions(-)
diff --git a/include/net/ip.h b/include/net/ip.h
index 9896f46cbbf11235395d75a5ec18a14736ee099d..af8addbaa3c188a896b74ff9646b6fdd692d1c8e 100644
--- a/include/net/ip.h
+++ b/include/net/ip.h
@@ -34,6 +34,7 @@
#include <net/flow_dissector.h>
#define IPV4_MAX_PMTU 65535U /* RFC 2675, Section 5.1 */
+#define IPV4_MIN_MTU 68 /* RFC 791 */
struct sock;
diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
index a4573bccd6da7b6763016d4f07d3032d44483d99..7a93359fbc7229389fc7bec67889ca1115f47a69 100644
--- a/net/ipv4/devinet.c
+++ b/net/ipv4/devinet.c
@@ -1428,7 +1428,7 @@ static void inetdev_changename(struct net_device *dev, struct in_device *in_dev)
static bool inetdev_valid_mtu(unsigned int mtu)
{
- return mtu >= 68;
+ return mtu >= IPV4_MIN_MTU;
}
static void inetdev_send_gratuitous_arp(struct net_device *dev,
diff --git a/net/ipv4/igmp.c b/net/ipv4/igmp.c
index d1f8f302dbf3ed5a079f27efa6eeaf802de40243..50448a220a1f26e29715bffc1b86f1f749e5a61d 100644
--- a/net/ipv4/igmp.c
+++ b/net/ipv4/igmp.c
@@ -404,16 +404,17 @@ static int grec_size(struct ip_mc_list *pmc, int type, int gdel, int sdel)
}
static struct sk_buff *add_grhead(struct sk_buff *skb, struct ip_mc_list *pmc,
- int type, struct igmpv3_grec **ppgr)
+ int type, struct igmpv3_grec **ppgr, unsigned int mtu)
{
struct net_device *dev = pmc->interface->dev;
struct igmpv3_report *pih;
struct igmpv3_grec *pgr;
- if (!skb)
- skb = igmpv3_newpack(dev, dev->mtu);
- if (!skb)
- return NULL;
+ if (!skb) {
+ skb = igmpv3_newpack(dev, mtu);
+ if (!skb)
+ return NULL;
+ }
pgr = skb_put(skb, sizeof(struct igmpv3_grec));
pgr->grec_type = type;
pgr->grec_auxwords = 0;
@@ -436,12 +437,17 @@ static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
struct igmpv3_grec *pgr = NULL;
struct ip_sf_list *psf, *psf_next, *psf_prev, **psf_list;
int scount, stotal, first, isquery, truncate;
+ unsigned int mtu;
if (pmc->multiaddr == IGMP_ALL_HOSTS)
return skb;
if (ipv4_is_local_multicast(pmc->multiaddr) && !net->ipv4.sysctl_igmp_llm_reports)
return skb;
+ mtu = READ_ONCE(dev->mtu);
+ if (mtu < IPV4_MIN_MTU)
+ return skb;
+
isquery = type == IGMPV3_MODE_IS_INCLUDE ||
type == IGMPV3_MODE_IS_EXCLUDE;
truncate = type == IGMPV3_MODE_IS_EXCLUDE ||
@@ -462,7 +468,7 @@ static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
AVAILABLE(skb) < grec_size(pmc, type, gdeleted, sdeleted)) {
if (skb)
igmpv3_sendpack(skb);
- skb = igmpv3_newpack(dev, dev->mtu);
+ skb = igmpv3_newpack(dev, mtu);
}
}
first = 1;
@@ -498,12 +504,12 @@ static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
pgr->grec_nsrcs = htons(scount);
if (skb)
igmpv3_sendpack(skb);
- skb = igmpv3_newpack(dev, dev->mtu);
+ skb = igmpv3_newpack(dev, mtu);
first = 1;
scount = 0;
}
if (first) {
- skb = add_grhead(skb, pmc, type, &pgr);
+ skb = add_grhead(skb, pmc, type, &pgr, mtu);
first = 0;
}
if (!skb)
@@ -538,7 +544,7 @@ static struct sk_buff *add_grec(struct sk_buff *skb, struct ip_mc_list *pmc,
igmpv3_sendpack(skb);
skb = NULL; /* add_grhead will get a new one */
}
- skb = add_grhead(skb, pmc, type, &pgr);
+ skb = add_grhead(skb, pmc, type, &pgr, mtu);
}
}
if (pgr)
diff --git a/net/ipv4/ip_tunnel.c b/net/ipv4/ip_tunnel.c
index fe6fee728ce49d01b55aa478698e1a3bcf9a3bdb..5ddb1cb52bd405ed10cce43195a25607d136efbf 100644
--- a/net/ipv4/ip_tunnel.c
+++ b/net/ipv4/ip_tunnel.c
@@ -349,8 +349,8 @@ static int ip_tunnel_bind_dev(struct net_device *dev)
dev->needed_headroom = t_hlen + hlen;
mtu -= (dev->hard_header_len + t_hlen);
- if (mtu < 68)
- mtu = 68;
+ if (mtu < IPV4_MIN_MTU)
+ mtu = IPV4_MIN_MTU;
return mtu;
}
^ permalink raw reply related
* [PATCH] iptables: ip6t_MASQUERADE: add dependency on conntrack module
From: Konstantin Khlebnikov @ 2017-12-11 15:19 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Eric Dumazet, Florian Westphal, Pablo Neira Ayuso
After commit 4d3a57f23dec ("netfilter: conntrack: do not enable connection
tracking unless needed") conntrack is disabled by default unless some
module explicitly declares dependency in particular network namespace.
Signed-off-by: Konstantin Khlebnikov <khlebnikov@yandex-team.ru>
Fixes: a357b3f80bc8 ("netfilter: nat: add dependencies on conntrack module")
---
net/ipv6/netfilter/ip6t_MASQUERADE.c | 8 +++++++-
1 file changed, 7 insertions(+), 1 deletion(-)
diff --git a/net/ipv6/netfilter/ip6t_MASQUERADE.c b/net/ipv6/netfilter/ip6t_MASQUERADE.c
index 2b1a15846f9a..92c0047e7e33 100644
--- a/net/ipv6/netfilter/ip6t_MASQUERADE.c
+++ b/net/ipv6/netfilter/ip6t_MASQUERADE.c
@@ -33,13 +33,19 @@ static int masquerade_tg6_checkentry(const struct xt_tgchk_param *par)
if (range->flags & NF_NAT_RANGE_MAP_IPS)
return -EINVAL;
- return 0;
+ return nf_ct_netns_get(par->net, par->family);
+}
+
+static void masquerade_tg6_destroy(const struct xt_tgdtor_param *par)
+{
+ nf_ct_netns_put(par->net, par->family);
}
static struct xt_target masquerade_tg6_reg __read_mostly = {
.name = "MASQUERADE",
.family = NFPROTO_IPV6,
.checkentry = masquerade_tg6_checkentry,
+ .destroy = masquerade_tg6_destroy,
.target = masquerade_tg6,
.targetsize = sizeof(struct nf_nat_range),
.table = "nat",
^ permalink raw reply related
* Re: [PATCH net] sctp: make sure stream nums can match optlen in sctp_setsockopt_reset_streams
From: Marcelo Ricardo Leitner @ 2017-12-11 15:36 UTC (permalink / raw)
To: Neil Horman; +Cc: Xin Long, network dev, linux-sctp, davem, syzkaller
In-Reply-To: <20171211145434.GB18284@hmswarspite.think-freely.org>
Hi,
On Mon, Dec 11, 2017 at 09:54:34AM -0500, Neil Horman wrote:
> On Sun, Dec 10, 2017 at 03:40:51PM +0800, Xin Long wrote:
> > Now in sctp_setsockopt_reset_streams, it only does the check
> > optlen < sizeof(*params) for optlen. But it's not enough, as
> > params->srs_number_streams should also match optlen.
> >
> > If the streams in params->srs_stream_list are less than stream
> > nums in params->srs_number_streams, later when dereferencing
> > the stream list, it could cause a slab-out-of-bounds crash, as
> > reported by syzbot.
> >
> > This patch is to fix it by also checking the stream numbers in
> > sctp_setsockopt_reset_streams to make sure at least it's not
> > greater than the streams in the list.
> >
> > Fixes: 7f9d68ac944e ("sctp: implement sender-side procedures for SSN Reset Request Parameter")
> > Reported-by: Dmitry Vyukov <dvyukov@google.com>
> > Signed-off-by: Xin Long <lucien.xin@gmail.com>
> > ---
> > net/sctp/socket.c | 6 +++++-
> > 1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/net/sctp/socket.c b/net/sctp/socket.c
> > index 014847e..dbf140d 100644
> > --- a/net/sctp/socket.c
> > +++ b/net/sctp/socket.c
> > @@ -3891,13 +3891,17 @@ static int sctp_setsockopt_reset_streams(struct sock *sk,
> > struct sctp_association *asoc;
> > int retval = -EINVAL;
> >
> > - if (optlen < sizeof(struct sctp_reset_streams))
> > + if (optlen < sizeof(*params))
> > return -EINVAL;
> >
> Is this going to work in all corner cases? IIRC struct
> sctp_reset_stream has variable length array at the end of it, and so
> sizeof(struct sctp_reset_streams) returns just the size of the
> struct, while sizeof(*params) returns the size of the entire object
> (including the array elements). If a user space task allocates a
I don't think it can include the array elements as such information
can't be passed from the application to the kernel other than via
optlen parameter. There is no metadata around the struct that could
allow that, and sizeof() is a constant, it can't be assuming different
values in runtime.
Cheers,
Marcelo
> static memory block to hold this struct and the array, and passes it
> in with a shorter optlen (if for example, they do not intend to use
> all the array elements), this will cause a failure, where no failure
> is truly warranted. It seems the correct check to me should be the
> origional sizeof(struct sctp_reset_streams) check, and the below
> check to ensure that there are at least the same number of array
> elements available as indicated in srs_nuber_streams.
>
> Regards
> Neil
>
> > params = memdup_user(optval, optlen);
> > if (IS_ERR(params))
> > return PTR_ERR(params);
> >
> > + if (params->srs_number_streams * sizeof(__u16) >
> > + optlen - sizeof(*params))
> > + goto out;
> > +
> > asoc = sctp_id2assoc(sk, params->srs_assoc_id);
> > if (!asoc)
> > goto out;
> > --
> > 2.1.0
> >
> > --
> > To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> > the body of a message to majordomo@vger.kernel.org
> > More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: [PATCH net v2 8/9] net: aquantia: Fix typo in ethtool statistics names
From: Andrew Lunn @ 2017-12-11 15:45 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, netdev, David Arcari, Pavel Belous,
Nadezhda Krupnina, Simon Edelhaus
In-Reply-To: <77ee1884039b2c73fb7542144931e30bdcb2de7f.1512994559.git.igor.russkikh@aquantia.com>
On Mon, Dec 11, 2017 at 03:16:25PM +0300, Igor Russkikh wrote:
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
> ---
> drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c | 16 ++++++++--------
> 1 file changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> index 70efb74..f2d8063 100644
> --- a/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/aq_ethtool.c
> @@ -66,14 +66,14 @@ static const char aq_ethtool_stat_names[][ETH_GSTRING_LEN] = {
> "OutUCast",
> "OutMCast",
> "OutBCast",
> - "InUCastOctects",
> - "OutUCastOctects",
> - "InMCastOctects",
> - "OutMCastOctects",
> - "InBCastOctects",
> - "OutBCastOctects",
> - "InOctects",
> - "OutOctects",
> + "InUCastOctets",
> + "OutUCastOctets",
> + "InMCastOctets",
> + "OutMCastOctets",
> + "InBCastOctets",
> + "OutBCastOctets",
> + "InOctets",
> + "OutOctets",
> "InPacketsDma",
> "OutPacketsDma",
> "InOctetsDma",
Hi Igor
I know it is not nice, but maybe we need to consider this is part of
the kernel ABI? You could be breaking applications by making this
change.
What do others think?
Andrew
^ permalink raw reply
* Re: [PATCH net v2 0/9] net: aquantia: Atlantic driver 12/2017 updates
From: Andrew Lunn @ 2017-12-11 15:45 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, netdev, David Arcari, Pavel Belous,
Nadezhda Krupnina, Simon Edelhaus
In-Reply-To: <cover.1512994559.git.igor.russkikh@aquantia.com>
On Mon, Dec 11, 2017 at 03:16:17PM +0300, Igor Russkikh wrote:
> The patchset contains important hardware fix for machines with large MRRS
> and couple of improvement in stats and capabilities reporting
>
> patch v2:
> - split into more detailed commits
Hi Igor
Thanks for breaking up the patches. They are much easier to review.
Andrew
^ permalink raw reply
* Re: [PATCH net v2 5/9] net: aquantia: Fill in multicast counter in ndev stats from hardware
From: Andrew Lunn @ 2017-12-11 15:46 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, netdev, David Arcari, Pavel Belous,
Nadezhda Krupnina, Simon Edelhaus
In-Reply-To: <6386236d1b55525e9f25de48070f96818f4f7a67.1512994559.git.igor.russkikh@aquantia.com>
On Mon, Dec 11, 2017 at 03:16:22PM +0300, Igor Russkikh wrote:
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
A one link comment for the change log would be good.
Otherwise,
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH] iptables: ip6t_MASQUERADE: add dependency on conntrack module
From: Pablo Neira Ayuso @ 2017-12-11 15:47 UTC (permalink / raw)
To: Konstantin Khlebnikov
Cc: netdev, David S. Miller, Eric Dumazet, Florian Westphal
In-Reply-To: <151300557384.454702.4055341451761100641.stgit@buzz>
On Mon, Dec 11, 2017 at 06:19:33PM +0300, Konstantin Khlebnikov wrote:
> After commit 4d3a57f23dec ("netfilter: conntrack: do not enable connection
> tracking unless needed") conntrack is disabled by default unless some
> module explicitly declares dependency in particular network namespace.
Applied, thanks.
^ permalink raw reply
* Re: [PATCH net v2 4/9] net: aquantia: Fill ndev stat couters from hardware
From: Andrew Lunn @ 2017-12-11 15:47 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, netdev, David Arcari, Pavel Belous,
Nadezhda Krupnina, Simon Edelhaus
In-Reply-To: <2a99c143ef60ccd48c2720c1a9ad57222f37952e.1512994559.git.igor.russkikh@aquantia.com>
On Mon, Dec 11, 2017 at 03:16:21PM +0300, Igor Russkikh wrote:
> Originally they were filled from ring sw counters.
> These sometimes incorrectly calculate byte and packet amounts
> when using LRO/LSO and jumboframes. Filling ndev counters from
> hardware makes them precise.
>
> Signed-off-by: Igor Russkikh <igor.russkikh@aquantia.com>
Reviewed-by: Andrew Lunn <andrew@lunn.ch>
Andrew
^ permalink raw reply
* Re: [PATCH net v2 8/9] net: aquantia: Fix typo in ethtool statistics names
From: David Miller @ 2017-12-11 15:51 UTC (permalink / raw)
To: andrew
Cc: igor.russkikh, netdev, darcari, pavel.belous, Nadezhda.Krupnina,
simon.edelhaus
In-Reply-To: <20171211154506.GG28672@lunn.ch>
From: Andrew Lunn <andrew@lunn.ch>
Date: Mon, 11 Dec 2017 16:45:06 +0100
> I know it is not nice, but maybe we need to consider this is part of
> the kernel ABI? You could be breaking applications by making this
> change.
>
> What do others think?
Not really.
The whole reason we have a string array exposed to userspace is so that
tools absolutely cannot hard code the driver specific ethtool stats
in any way shape or form, and must always query the number, order,
and names every single time.
^ permalink raw reply
* Re: [PATCH net v2 7/9] net: aquantia: Reset driver level statistics to zero on initialization
From: Andrew Lunn @ 2017-12-11 15:51 UTC (permalink / raw)
To: Igor Russkikh
Cc: David S . Miller, netdev, David Arcari, Pavel Belous,
Nadezhda Krupnina, Simon Edelhaus
In-Reply-To: <99425adad58a8ed133edc1a2b5ec8fec70e56e36.1512994559.git.igor.russkikh@aquantia.com>
> --- a/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c
> +++ b/drivers/net/ethernet/aquantia/atlantic/hw_atl/hw_atl_a0.c
> @@ -344,6 +344,13 @@ static int hw_atl_a0_hw_init(struct aq_hw_s *self,
> hw_atl_a0_hw_rss_set(self, &aq_nic_cfg->aq_rss);
> hw_atl_a0_hw_rss_hash_set(self, &aq_nic_cfg->aq_rss);
>
> + /* Read initial hardware counters
> + * and reset current in-driver statistics
> + */
> + hw_atl_utils_update_stats(self);
> + memset(&PHAL_ATLANTIC_A0->curr_stats, 0,
> + sizeof(PHAL_ATLANTIC_A0->curr_stats));
> +
> err = aq_hw_err_from_flags(self);
> if (err < 0)
> goto err_exit;
Hi Igor
It looks like this is called on pm state change? Does this mean that
resume will zero the statistics? That is probably not what you want.
You should probably only clear the statics in the probe function.
Andrew
^ permalink raw reply
* Re: [PATCH] ptr_ring: add barriers
From: David Miller @ 2017-12-11 15:53 UTC (permalink / raw)
To: mst
Cc: linux-kernel, george.cherian, jasowang, edumazet, netdev,
virtualization
In-Reply-To: <1512501990-30029-1-git-send-email-mst@redhat.com>
From: "Michael S. Tsirkin" <mst@redhat.com>
Date: Tue, 5 Dec 2017 21:29:37 +0200
> Users of ptr_ring expect that it's safe to give the
> data structure a pointer and have it be available
> to consumers, but that actually requires an smb_wmb
> or a stronger barrier.
>
> In absence of such barriers and on architectures that reorder writes,
> consumer might read an un=initialized value from an skb pointer stored
> in the skb array. This was observed causing crashes.
>
> To fix, add memory barriers. The barrier we use is a wmb, the
> assumption being that producers do not need to read the value so we do
> not need to order these reads.
>
> Reported-by: George Cherian <george.cherian@cavium.com>
> Suggested-by: Jason Wang <jasowang@redhat.com>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
I'm asked for asking for testing feedback and did not get it in a
reasonable amount of time.
So I'm applying this as-is, and queueing it up for -stable.
Thank you.
^ permalink raw reply
* [RFC][PATCH] new byteorder primitives - ..._{replace,get}_bits()
From: Al Viro @ 2017-12-11 15:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: netdev, linux-kernel
In-Reply-To: <20171211053803.GW21978@ZenIV.linux.org.uk>
A lot of drivers are open-coding the "replace these bits in __be32 with
the following value" kind of primitives. Let's add them to byteorder.h.
Primitives:
{be,le}{16,32,64}_replace_bits(old, v, bit, nbits)
{be,le}{16,32,64}_get_bits(val, bit, nbits)
Essentially, it gives helpers for work with bitfields in fixed-endian.
Suppose we have e.g. a little-endian 32bit value with fixed layout;
expressing that as a bitfield would go like
struct foo {
unsigned foo:4; /* bits 0..3 */
unsigned :2;
unsigned bar:12; /* bits 6..17 */
unsigned baz:14; /* bits 18..31 */
}
Even for host-endian it doesn't work all that well - you end up with
ifdefs in structure definition and generated code stinks. For fixed-endian
it gets really painful, and people tend to use explicit shift-and-mask
kind of macros for accessing the fields (and often enough get the
endianness conversions wrong, at that). With these primitives
struct foo v <=> __le32 v
v.foo = i ? 1 : 2 <=> v = le32_replace_bits(v, i ? 1 : 2, 0, 4)
f(4 + v.baz) <=> f(4 + le32_get_bits(v, 18, 14))
Signed-off-by: Al Viro <viro@zeniv.linux.org.uk>
---
diff --git a/include/linux/byteorder/generic.h b/include/linux/byteorder/generic.h
index 451aaa0786ae..d8f169a7104a 100644
--- a/include/linux/byteorder/generic.h
+++ b/include/linux/byteorder/generic.h
@@ -187,4 +187,26 @@ static inline void be32_to_cpu_array(u32 *dst, const __be32 *src, size_t len)
dst[i] = be32_to_cpu(src[i]);
}
+#define ____MASK(bit, nbits) ((((1ULL << ((nbits) - 1)) << 1) - 1) << (bit))
+#define ____MAKE_OP(type,base) \
+static inline __##type type##_replace_bits(__##type old, \
+ base val, int bit, int nbits) \
+{ \
+ __##type mask = cpu_to_##type(____MASK(bit, nbits)); \
+ return (old & ~mask) | (cpu_to_##type(val << bit) & mask); \
+} \
+static inline base type##_get_bits(__##type val, int bit, int nbits) \
+{ \
+ return (type##_to_cpu(val) >> bit) & ____MASK(0, nbits); \
+}
+
+____MAKE_OP(le16,u16)
+____MAKE_OP(le32,u32)
+____MAKE_OP(le64,u64)
+____MAKE_OP(be16,u16)
+____MAKE_OP(be32,u32)
+____MAKE_OP(be64,u64)
+#undef ____MAKE_OP
+#undef ____MASK
+
#endif /* _LINUX_BYTEORDER_GENERIC_H */
^ permalink raw reply related
* Re: Linux 4.14 - regression: broken tun/tap / bridge network with virtio - bisected
From: Andreas Hartmann @ 2017-12-11 15:54 UTC (permalink / raw)
To: Willem de Bruijn, Michal Kubecek
Cc: Jason Wang, David Miller, Network Development
In-Reply-To: <bc075f2c-85d0-cf97-60cd-ee6d6efca12e@01019freenet.de>
[-- Attachment #1: Type: text/plain, Size: 4176 bytes --]
On 12/08/2017 at 09:44 PM Andreas Hartmann wrote:
> On 12/08/2017 at 09:11 PM Andreas Hartmann wrote:
>> On 12/08/2017 at 05:04 PM Willem de Bruijn wrote:
>>> On Fri, Dec 8, 2017 at 6:40 AM, Michal Kubecek <mkubecek@suse.cz> wrote:
>>>> On Fri, Dec 08, 2017 at 11:31:50AM +0100, Andreas Hartmann wrote:
>>>>> On 12/08/2017 at 09:47 AM Michal Kubecek wrote:
>>>>>> On Fri, Dec 08, 2017 at 08:21:16AM +0100, Andreas Hartmann wrote:
>>>>>>>
>>>>>>> All my VMs are using virtio_net. BTW: I couldn't see the problems
>>>>>>> (sometimes, the VM couldn't be stopped at all) if all my VMs are using
>>>>>>> e1000 as interface instead.
>>>>>>>
>>>>>>> This finding now matches pretty much the responsible UDP-package which
>>>>>>> caused the stall. I already mentioned it here [2].
>>>>>>>
>>>>>>> To prove it, I reverted from the patch series "[PATCH v2 RFC 0/13]
>>>>>>> Remove UDP Fragmentation Offload support" [3]
>>>>>>>
>>>>>>> 11/13 [v2,RFC,11/13] net: Remove all references to SKB_GSO_UDP. [4]
>>>>>>> 12/13 [v2,RFC,12/13] inet: Remove software UFO fragmenting code. [5]
>>>>>>> 13/13 [v2,RFC,13/13] net: Kill NETIF_F_UFO and SKB_GSO_UDP. [6]
>>>>>>>
>>>>>>> and applied it to Linux 4.14.4. It compiled fine and is running fine.
>>>>>>> The vnet doesn't die anymore. Yet, I can't say if the qemu stop hangs
>>>>>>> are gone, too.
>>>>>>>
>>>>>>> Obviously, there is something broken with the new UDP handling. Could
>>>>>>> you please analyze this problem? I could test some more patches ... .
>>>>>>
>>>>>> Any chance your VMs were live migrated from pre-4.14 host kernel?
>>>>>
>>>>> No - the VMs are not live migrated. They are always running on the same
>>>>> host - either with kernel < 4.14 or with kernel 4.14.x.
>>>>
>>>> This is disturbing... unless I'm mistaken, it shouldn't be possible to
>>>> have UFO enabled on a virtio device in a VM booted on a host with 4.14
>>>> kernel.
>>>
>>> Indeed. When working on that revert patch I verified that UFO in
>>> the guest virtio_net was off before the revert patch, on after.
>>>
>>> Qemu should check host support with tap_probe_has_ufo
>>> before advertising support to the guest. Indeed, this is exactly
>>> what broke live migration in virtio_net_load_device at
>>>
>>> if (qemu_get_byte(f) && !peer_has_ufo(n)) {
>>> error_report("virtio-net: saved image requires TUN_F_UFO support");
>>> return -1;
>>> }
>>>
>>> Which follows
>>>
>>> peer_has_ufo
>>> qemu_has_ufo
>>> tap_has_ufo
>>> s->has_ufo
>>>
>>> where s->has_ufo was set by tap_probe_has_ufo in net_tap_fd_init.
>>>
>>> Now, checking my qemu git branch, I ran pretty old 2.7.0-rc3. But this
>>> codepath does not seem to have changed between then and 2.10.1.
>>>
>>> I cherry-picked the revert onto 4.14.3. It did not apply cleanly, but the
>>> fix-up wasn't too hard. Compiled and booted, but untested otherwise. At
>>>
>>> https://github.com/wdebruij/linux/commits/v4.14.3-aargh-ufo
>>
>> I'm just running it at the moment. I didn't face any network hang until
>> now - although the critical UDP packages have been gone through.
>> Therefore: looks nice.
>
> Well, the patch does not fix hanging VMs, which have been shutdown and
> can't be killed any more.
> Because of the stack trace
>
> [<ffffffffc0d0e3c5>] vhost_net_ubuf_put_and_wait+0x35/0x60 [vhost_net]
> [<ffffffffc0d0f264>] vhost_net_ioctl+0x304/0x870 [vhost_net]
> [<ffffffff9b25460f>] do_vfs_ioctl+0x8f/0x5c0
> [<ffffffff9b254bb4>] SyS_ioctl+0x74/0x80
> [<ffffffff9b00365b>] do_syscall_64+0x5b/0x100
> [<ffffffff9b78e7ab>] entry_SYSCALL64_slow_path+0x25/0x25
> [<ffffffffffffffff>] 0xffffffffffffffff
>
> I was hoping, that the problems could be related - but that seems not to
> be true.
However, it turned out, that reverting the complete patchset "Remove UDP
Fragmentation Offload support" prevent hanging qemu processes. I tested
today and the whole weekend - I didn't face any problem. Before that, I
could see nearly immediately hanging qemu processes after shutdown w/
libvirt.
Tested w/ 4.14.4, qemu 2.6.2 and libvirt 2.0.0 and 4 VMs.
I'll be back if the problem comes up again while the patchset is reverted.
Thanks,
Andreas
[-- Attachment #2: Revert - Remove UDP Fragmentation Offload support.tar.xz --]
[-- Type: application/x-xz, Size: 9152 bytes --]
^ permalink raw reply
* Re: [Patch net-next 0/2] netlink: improve netlink tap code
From: David Miller @ 2017-12-11 15:57 UTC (permalink / raw)
To: xiyou.wangcong; +Cc: netdev
In-Reply-To: <20171206230320.22191-1-xiyou.wangcong@gmail.com>
From: Cong Wang <xiyou.wangcong@gmail.com>
Date: Wed, 6 Dec 2017 15:03:18 -0800
> Cong Wang (2):
> netlink: make netlink tap per netns
> netlink: convert netlink tap spinlock to mutex
Both applied, thanks Cong.
^ permalink raw reply
* Re: [RFC PATCH 2/9] ethtool: introduce ethtool netlink interface
From: Jiri Pirko @ 2017-12-11 16:02 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, linux-kernel
In-Reply-To: <37174026f818dd1a61ca1b37bef2f1b114198de2.1513000306.git.mkubecek@suse.cz>
Mon, Dec 11, 2017 at 02:53:31PM CET, mkubecek@suse.cz wrote:
>No function implemented yet, only genetlink and module infrastructure.
>Register/unregister genetlink family "ethtool" and allow the module to be
>autoloaded by genetlink code (if built as a module, distributions would
>probably prefer "y").
>
>Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
[...]
>+
>+/* identifies the device to query/set
>+ * - use either ifindex or ifname, not both
>+ * - for dumps and messages not related to a particular devices, fill neither
>+ * - info_mask is a bitfield, interpretation depends on the command
>+ */
>+struct ethnlmsghdr {
>+ __u32 ifindex; /* device ifindex */
>+ __u16 flags; /* request/response flags */
>+ __u16 info_mask; /* request/response info mask */
>+ char ifname[IFNAMSIZ]; /* device name */
Why do you need this header? You can have 2 attrs:
ETHTOOL_ATTR_IFINDEX and
ETHTOOL_ATTR_IFNAME
Why do you need per-command flags and info_mask? Could be bitfield
attr if needed by specific command.
>+};
>+
>+#define ETHNL_HDRLEN NLMSG_ALIGN(sizeof(struct ethnlmsghdr))
>+
>+enum {
>+ ETHTOOL_CMD_NOOP,
>+
>+ __ETHTOOL_CMD_MAX,
>+ ETHTOOL_CMD_MAX = (__ETHTOOL_CMD_MAX - 1),
>+};
>+
>+/* generic netlink info */
>+#define ETHTOOL_GENL_NAME "ethtool"
>+#define ETHTOOL_GENL_VERSION 1
>+
>+#endif /* _UAPI_LINUX_ETHTOOL_NETLINK_H_ */
>diff --git a/net/Kconfig b/net/Kconfig
>index 9dba2715919d..a5e3c89a2495 100644
>--- a/net/Kconfig
>+++ b/net/Kconfig
>@@ -440,6 +440,13 @@ config MAY_USE_DEVLINK
> on MAY_USE_DEVLINK to ensure they do not cause link errors when
> devlink is a loadable module and the driver using it is built-in.
>
>+config ETHTOOL_NETLINK
>+ tristate "Netlink interface for ethtool"
>+ default m
>+ help
>+ New netlink based interface for ethtool which is going to obsolete
>+ the old ioctl based one once it provides all features.
>+
> endif # if NET
>
> # Used by archs to tell that they support BPF JIT compiler plus which flavour.
>diff --git a/net/core/Makefile b/net/core/Makefile
>index 1fd0a9c88b1b..617ab2abecdf 100644
>--- a/net/core/Makefile
>+++ b/net/core/Makefile
>@@ -30,3 +30,4 @@ obj-$(CONFIG_DST_CACHE) += dst_cache.o
> obj-$(CONFIG_HWBM) += hwbm.o
> obj-$(CONFIG_NET_DEVLINK) += devlink.o
> obj-$(CONFIG_GRO_CELLS) += gro_cells.o
>+obj-$(CONFIG_ETHTOOL_NETLINK) += ethtool_netlink.o
>diff --git a/net/core/ethtool_netlink.c b/net/core/ethtool_netlink.c
>new file mode 100644
>index 000000000000..46a226bb9a2c
>--- /dev/null
>+++ b/net/core/ethtool_netlink.c
>@@ -0,0 +1,46 @@
>+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
>+
>+#include <linux/module.h>
>+#include <linux/ethtool_netlink.h>
>+#include <linux/netdevice.h>
>+#include <net/genetlink.h>
>+#include "ethtool_common.h"
>+
>+static struct genl_family ethtool_genl_family;
>+
>+/* genetlink paperwork */
What "paperwork"? :)
>+
>+static const struct genl_ops ethtool_genl_ops[] = {
>+};
>+
>+static struct genl_family ethtool_genl_family = {
>+ .hdrsize = ETHNL_HDRLEN,
>+ .name = ETHTOOL_GENL_NAME,
>+ .version = ETHTOOL_GENL_VERSION,
>+ .netnsok = true,
>+ .ops = ethtool_genl_ops,
>+ .n_ops = ARRAY_SIZE(ethtool_genl_ops),
>+};
>+
>+/* module paperwork */
>+
>+static int __init ethtool_nl_init(void)
>+{
>+ return genl_register_family(ðtool_genl_family);
>+}
>+
>+static void __exit ethtool_nl_exit(void)
>+{
>+ genl_unregister_family(ðtool_genl_family);
>+}
>+
>+module_init(ethtool_nl_init);
>+module_exit(ethtool_nl_exit);
>+
>+/* this alias is for autoload */
>+MODULE_ALIAS("net-pf-" __stringify(PF_NETLINK)
>+ "-proto-" __stringify(NETLINK_GENERIC)
>+ "-family-" ETHTOOL_GENL_NAME);
You can use MODULE_ALIAS_GENL_FAMILY instead.
>+MODULE_AUTHOR("Michal Kubecek <mkubecek@suse.cz>");
>+MODULE_DESCRIPTION("Netlink interface for ethtool");
>+MODULE_LICENSE("GPL");
"GPL v2"?
>--
>2.15.1
>
^ permalink raw reply
* RE: [PATCH V2 net-next 2/8] net: hns3: Add mailbox support to VF driver
From: Salil Mehta @ 2017-12-11 16:04 UTC (permalink / raw)
To: Philippe Ombredanne
Cc: David S. Miller, Zhuangyuzeng (Yisen), lipeng (Y),
mehta.salil.lnk@gmail.com, netdev@vger.kernel.org, LKML,
linux-rdma@vger.kernel.org, Linuxarm
In-Reply-To: <CAOFm3uH0G7hA0kpiH+SivdLQ6hH_Prq7_gHg6O-hoaO94dPoTQ@mail.gmail.com>
Hi Philippe,
> -----Original Message-----
> From: Philippe Ombredanne [mailto:pombredanne@nexb.com]
> Sent: Saturday, December 09, 2017 12:17 AM
> To: Salil Mehta <salil.mehta@huawei.com>
> Cc: David S. Miller <davem@davemloft.net>; Zhuangyuzeng (Yisen)
> <yisen.zhuang@huawei.com>; lipeng (Y) <lipeng321@huawei.com>;
> mehta.salil.lnk@gmail.com; netdev@vger.kernel.org; LKML <linux-
> kernel@vger.kernel.org>; linux-rdma@vger.kernel.org; Linuxarm
> <linuxarm@huawei.com>
> Subject: Re: [PATCH V2 net-next 2/8] net: hns3: Add mailbox support to
> VF driver
>
> Sali,
Sali ---> Salil
Thanks
>
> On Fri, Dec 8, 2017 at 10:16 PM, Salil Mehta <salil.mehta@huawei.com>
> wrote:
> > This patch adds the support of the mailbox to the VF driver. The
> > mailbox shall be used as an interface to communicate with the
> > PF driver for various purposes like {set|get} MAC related
> > operations, reset, link status etc. The mailbox supports both
> > synchronous and asynchronous command send to PF driver.
> >
> > Signed-off-by: Salil Mehta <salil.mehta@huawei.com>
> > Signed-off-by: lipeng <lipeng321@huawei.com>
> [...]
> > --- /dev/null
> > +++ b/drivers/net/ethernet/hisilicon/hns3/hclge_mbx.h
> > @@ -0,0 +1,94 @@
> > +/*
> > + * Copyright (c) 2016-2017 Hisilicon Limited.
> > + *
> > + * This program is free software; you can redistribute it and/or
> modify
> > + * it under the terms of the GNU General Public License as published
> by
> > + * the Free Software Foundation; either version 2 of the License, or
> > + * (at your option) any later version.
> > + */
>
> Why not use the new SPDX ids?
We can. I will change the headers for files [.c .h Makefile] part of HNS3
VF driver change in next V3 patch submit.
> e.g.
> > +/* SPDX-License-Identifier: GPL-2.0+ */
> > +/* Copyright (c) 2016-2017 Hisilicon Limited. */
>
> See Linus posts and Thomas doc patches for details.
Sure.
Thanks!
>
> --
> Cordially
> Philippe Ombredanne
^ permalink raw reply
* Re: [PATCH V2] netlink: Add netns check on taps
From: Michal Kubecek @ 2017-12-11 16:13 UTC (permalink / raw)
To: David Miller
Cc: cernekee, johannes.berg, netdev, linux-kernel, daniel, dsahern
In-Reply-To: <20171206.155714.908446002721815545.davem@davemloft.net>
On Wed, Dec 06, 2017 at 03:57:14PM -0500, David Miller wrote:
> From: Kevin Cernekee <cernekee@chromium.org>
> Date: Wed, 6 Dec 2017 12:12:27 -0800
>
> > Currently, a nlmon link inside a child namespace can observe systemwide
> > netlink activity. Filter the traffic so that nlmon can only sniff
> > netlink messages from its own netns.
> >
> > Test case:
> >
> > vpnns -- bash -c "ip link add nlmon0 type nlmon; \
> > ip link set nlmon0 up; \
> > tcpdump -i nlmon0 -q -w /tmp/nlmon.pcap -U" &
> > sudo ip xfrm state add src 10.1.1.1 dst 10.1.1.2 proto esp \
> > spi 0x1 mode transport \
> > auth sha1 0x6162633132330000000000000000000000000000 \
> > enc aes 0x00000000000000000000000000000000
> > grep --binary abc123 /tmp/nlmon.pcap
> >
> > Signed-off-by: Kevin Cernekee <cernekee@chromium.org>
>
> Applied and queued up for -stable, thanks Kevin.
David,
this patch is marked as accepted in patchworks and listed in
http://patchwork.ozlabs.org/bundle/davem/stable/?state=*
but it's not in the net tree. Is there a problem with it?
Michal Kubecek
^ permalink raw reply
* Re: [PATCH next] ipvlan: add L2 check for packets arriving via virtual devices
From: David Miller @ 2017-12-11 16:15 UTC (permalink / raw)
To: mahesh; +Cc: netdev, edumazet, amit.sikka, maheshb
In-Reply-To: <20171207231543.7637-1-mahesh@bandewar.net>
From: Mahesh Bandewar <mahesh@bandewar.net>
Date: Thu, 7 Dec 2017 15:15:43 -0800
> From: Mahesh Bandewar <maheshb@google.com>
>
> Packets that don't have dest mac as the mac of the master device should
> not be entertained by the IPvlan rx-handler. This is mostly true as the
> packet path mostly takes care of that, except when the master device is
> a virtual device. As demonstrated in the following case -
...
> This patch adds that missing check in the IPvlan rx-handler.
>
> Reported-by: Amit Sikka <amit.sikka@ericsson.com>
> Signed-off-by: Mahesh Bandewar <maheshb@google.com>
Applied, but it's a shame that the data plane takes on this new MAC
compare operation.
^ permalink raw reply
* Re: [RFC PATCH 5/9] ethtool: implement GET_DRVINFO message
From: Jiri Pirko @ 2017-12-11 16:16 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, linux-kernel
In-Reply-To: <219f457821c4cbca64ead6a8f8a92246ed7f32a3.1513000306.git.mkubecek@suse.cz>
Mon, Dec 11, 2017 at 02:54:01PM CET, mkubecek@suse.cz wrote:
>Request the same information as ETHTOOL_GDRVINFO. This is read-only so that
>corresponding SET_DRVINFO exists but is only used in kernel replies. Rip
>the code to query the driver out of the legacy interface and move it to
>a new file ethtool_common.c so that both interfaces can use it.
>
>Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
>---
> Documentation/networking/ethtool-netlink.txt | 30 ++++++++++-
> include/uapi/linux/ethtool_netlink.h | 21 ++++++++
> net/core/Makefile | 2 +-
> net/core/ethtool.c | 42 +++-------------
> net/core/ethtool_common.c | 46 +++++++++++++++++
> net/core/ethtool_common.h | 11 ++++
> net/core/ethtool_netlink.c | 75 ++++++++++++++++++++++++++++
> 7 files changed, 189 insertions(+), 38 deletions(-)
> create mode 100644 net/core/ethtool_common.c
> create mode 100644 net/core/ethtool_common.h
>
>diff --git a/Documentation/networking/ethtool-netlink.txt b/Documentation/networking/ethtool-netlink.txt
>index 893e5156f6a7..cb992180b211 100644
>--- a/Documentation/networking/ethtool-netlink.txt
>+++ b/Documentation/networking/ethtool-netlink.txt
>@@ -107,6 +107,9 @@ which the request applies.
> List of message types
> ---------------------
>
>+ ETHTOOL_CMD_GET_DRVINFO
>+ ETHTOOL_CMD_SET_DRVINFO response only
>+
> All constants use ETHTOOL_CMD_ prefix followed by "GET", "SET" or "ACT" to
> indicate the type.
>
>@@ -119,6 +122,31 @@ messages marked as "response only" in the table above.
> Later sections describe the format and semantics of these request messages.
>
>
>+GET_DRVINFO
>+-----------
>+
>+GET_DRVINFO request corresponds to ETHTOOL_GDRVINFO ioctl command and provides
>+basic driver information. The request doesn't use any attributes and flags,
>+info_mask and index field in request header are ignored. Kernel response
>+contents:
>+
>+ ETHA_DRVINFO_DRIVER (string) driver name
>+ ETHA_DRVINFO_VERSION (string) driver version
You use 3 prefixes:
ETHTOOL_ for cmd
ETHA_ for attrs
ethnl_ for function
I suggest to sync this, perhaps to:
ETHNL_CMD_*
ETHNL_ATTR_*
ethnl_*
?
>+ ETHA_DRVINFO_FWVERSION (string) firmware version
>+ ETHA_DRVINFO_BUSINFO (string) device bus address
>+ ETHA_DRVINFO_EROM_VER (string) expansion ROM version
>+ ETHA_DRVINFO_N_PRIV_FLAGS (u32) number of private flags
>+ ETHA_DRVINFO_N_STATS (u32) number of device stats
>+ ETHA_DRVINFO_TESTINFO_LEN (u32) number of test results
>+ ETHA_DRVINFO_EEDUMP_LEN (u32) EEPROM dump size
>+ ETHA_DRVINFO_REGDUMP_LEN (u32) register dump size
We are now working on providing various fw memory regions dump in
devlink. It makes sense to have it in devlink for couple of reasons:
1) per-asic, not netdev specific, therefore does not really make sense
to have netdev as handle, but rather devlink handle.
2) snapshot support - we need to provide support for getting snapshot
(for example on failure), transferring to user and deleting it
(remove from driver memory).
Also, driver name, version, fwversion, etc is per-asic. Would make sense
to have it in devlink as well.
I think this is great opprotunity to move things where they should be to
be alligned with the current world and kernel infrastructure.
^ permalink raw reply
* Re: [PATCH net v3] net: phy: meson-gxl: detect LPA corruption
From: David Miller @ 2017-12-11 16:19 UTC (permalink / raw)
To: jbrunet
Cc: andrew, f.fainelli, khilman, netdev, linux-arm-kernel,
linux-amlogic, linux-kernel
In-Reply-To: <20171208110811.30789-1-jbrunet@baylibre.com>
From: Jerome Brunet <jbrunet@baylibre.com>
Date: Fri, 8 Dec 2017 12:08:11 +0100
> I suppose this patch probably seems a bit hacky, especially the part
> about the link partner acknowledge. I'm trying to figure out if the
> value in MII_LPA makes sense but I don't have such a deep knowledge
> of the ethernet spec.
Yeah it's not the prettiest thing in the world, but if this is what you
need to check to detect this situation then there isn't much else you
can do.
Applied, thanks.
^ permalink raw reply
* Re: [PATCHv2 net-next 00/12] sctp: Implement Stream Interleave: The I-DATA Chunk Supporting User Message Interleaving
From: David Miller @ 2017-12-11 16:23 UTC (permalink / raw)
To: lucien.xin; +Cc: netdev, linux-sctp, marcelo.leitner, nhorman
In-Reply-To: <cover.1512738021.git.lucien.xin@gmail.com>
From: Xin Long <lucien.xin@gmail.com>
Date: Fri, 8 Dec 2017 21:03:57 +0800
> Stream Interleave would be Implemented in two Parts:
>
> 1. The I-DATA Chunk Supporting User Message Interleaving
> 2. Interaction with Other SCTP Extensions
...
> As the 1st part of Stream Interleave Implementation, this patchset adds
> an ops framework named sctp_stream_interleave with a bunch of stuff that
> does lots of things needed somewhere.
>
> Then it defines sctp_stream_interleave_0 to work for normal DATA chunks
> and sctp_stream_interleave_1 for I-DATA chunks.
>
> With these functions, hundreds of if-else checks for the different process
> on I-DATA chunks would be avoided. Besides, very few codes could be shared
> in these two function sets.
>
> In this patchset, it adds some basic variables, structures and socket
> options firstly, then implement these functions one by one to add the
> procedures for ordered idata gradually, at last adjusts some codes to
> make them work for unordered idata.
>
> To make it safe to be implemented and also not break the normal data
> chunk process, this feature can't be enabled to use until all stream
> interleave codes are completely accomplished.
>
> v1 -> v2:
> - fixed a checkpatch warning that a blank line was missed.
> - avoided a kbuild warning reported from gcc-4.9.
Series applied, thanks Xin.
^ permalink raw reply
* Re: [PATCH] dt-bindings: fec: Make the phy-reset-gpio polarity explicit
From: David Miller @ 2017-12-11 16:27 UTC (permalink / raw)
To: festevam; +Cc: fugang.duan, robh+dt, netdev, fabio.estevam
In-Reply-To: <1512742293-14572-1-git-send-email-festevam@gmail.com>
From: Fabio Estevam <festevam@gmail.com>
Date: Fri, 8 Dec 2017 12:11:33 -0200
> From: Fabio Estevam <fabio.estevam@nxp.com>
>
> The GPIO polarity passed to phy-reset-gpio is ignored by the FEC
> driver and it is assumed to be active low.
>
> It can be active high only when the 'phy-reset-active-high' property
> is present.
>
> The current examples pass active high polarity and work fine, but
> in order to improve the documentation make it explicit what the real
> polarity is.
>
> Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
Applied to net-next.
^ permalink raw reply
* Re: RFC(v2): Audit Kernel Container IDs
From: Eric Paris @ 2017-12-11 16:30 UTC (permalink / raw)
To: Casey Schaufler, Mickaël Salaün, Richard Guy Briggs,
cgroups, Linux Containers, Linux API, Linux Audit, Linux FS Devel,
Linux Kernel, Linux Network Development
Cc: mszeredi, Eric W. Biederman, Simo Sorce, jlayton,
Carlos O'Donell, David Howells, Al Viro, Andy Lutomirski,
Eric Paris, trondmy, Michael Kerrisk
In-Reply-To: <f8ea78be-9bbf-2967-7b12-ac93bb85b0bc@schaufler-ca.com>
On Sat, 2017-12-09 at 10:28 -0800, Casey Schaufler wrote:
> On 12/9/2017 2:20 AM, Micka�l Sala�n wrote:
> > What about automatically create
> > and assign an ID to a process when it enters a namespace different
> > than
> > one of its parent process? This delegates the (permission)
> > responsibility to the use of namespaces (e.g. /proc/sys/user/max_*
> > limit).
>
> That gets ugly when you have a container that uses user, filesystem,
> network and whatever else namespaces. If all containers used the same
> set of namespaces I think this would be a fine idea, but they don't.
>
> > One interesting side effect of this approach would be to be able to
> > identify which processes are in the same set of namespaces, even if
> > not
> > spawn from the container but entered after its creation (i.e. using
> > setns), by creating container IDs as a (deterministic) checksum
> > from the
> > /proc/self/ns/* IDs.
> >
> > Since the concern is to identify a container, I think the ability
> > to
> > audit the switch from one container ID to another is enough. I
> > don't
> > think we need nested IDs.
>
> Because a container doesn't have to use namespaces to be a container
> you still need a mechanism for a process to declare that it is in
> fact
> in a container, and to identify the container.
I like the idea but I'm still tossing it around in my head (and
thinking about Casey's statement too). Lets say we have a 'docker-like'
container with pid=100 netns=X,userns=Y,mountns=Z. If I'm on the host
in all init namespaces and I run
nsenter -t 100 -n ip link set eth0 promisc on
How should this be logged? Did this command run in it's own 'container'
unrelated to the 'docker-like' container?
-Eric
^ permalink raw reply
* Re: [RFC PATCH 0/9] ethtool netlink interface (WiP)
From: Jiri Pirko @ 2017-12-11 16:32 UTC (permalink / raw)
To: Michal Kubecek; +Cc: netdev, linux-kernel
In-Reply-To: <cover.1513000306.git.mkubecek@suse.cz>
Mon, Dec 11, 2017 at 02:53:11PM CET, mkubecek@suse.cz wrote:
>This is still work in progress and only a very small part of the ioctl
>interface is reimplemented but I would like to get some comments before
>the patchset becomes too big and changing things becomes too tedious.
>
>The interface used for communication between ethtool and kernel is based on
>ioctl() and suffers from many problems. The most pressing seems the be the
>lack of extensibility. While some of the newer commands use structures
>designed to allow future extensions (e.g. GFEATURES or TEST), most either
>allow no extension at all (GPAUSEPARAM, GCOALESCE) or only limited set of
>reserved fields (GDRVINFO, GEEE). Even most of those which support future
>extensions limit the data types that can be used.
>
>This series aims to provide an alternative interface based on netlink which
>is what other network configuration utilities use. In particular, it uses
>generic netlink (family "ethtool"). The goal is to provide an interface
>which would be extensible, flexible and practical both for ethtool and for
>other network configuration tools (e.g. wicked or systemd-networkd).
>
>The interface is documented in Documentation/networking/ethtool-netlink.txt
>
>I'll post RFC patch series for ethtool in a few days, it still needs some
>more polishing.
First of all, thank you Michale for taking a stab at this!
I think that it does not make sense to convert ethtool->netlink_ethtool
1:1 feature wise. Now we have devlink, ritch switch representation
model, tc offload and many others. Lot of things that are in
ethtool, should be done in devlink. Also, there are couple of things
that should just die - nice example is ethtool --config-ntuple - we
should use tc for that.
So I believe that it would be better to introduce new iterface called
differently, to avoid confusion, like "ethlink" and start to migrate
things there, without existing baggage. In kernel the existing ethtool
would just call compat layer inside ethlink code. Similarly with devlink.
ethtool api would freeze. Similar scenario to rtnetlink and legacy ioctl.
Also, this new netlink iface should have userspace notification
support from day 1.
^ 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