* RE: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning off link autonegotiation via ethtool
From: Ariel Levkovich @ 2017-01-16 23:08 UTC (permalink / raw)
To: Or Gerlitz, Tariq Toukan
Cc: David S. Miller, Linux Netdev List, Eran Ben Elisha
In-Reply-To: <CAJ3xEMjEPQv=Agz5Wr-2UEL+iv7nz4NAcpCKY9=C4vs6SfKLLA@mail.gmail.com>
+ MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
It's there.
Best Regards,
Ariel Levkovich
Staff Engineer, SW
Mellanox Technologies
Beit Mellanox, Yokneam, P.O.Box 586, Israel 20692
Office: +972-74723-7652, Mobile: +972-52-3947-704
www.mellanox.com
Follow us on Facebook and Twitter
> -----Original Message-----
> From: Or Gerlitz [mailto:gerlitz.or@gmail.com]
> Sent: Monday, January 16, 2017 4:48 PM
> To: Tariq Toukan <tariqt@mellanox.com>; Ariel Levkovich
> <lariel@mellanox.com>
> Cc: David S. Miller <davem@davemloft.net>; Linux Netdev List
> <netdev@vger.kernel.org>; Eran Ben Elisha <eranbe@mellanox.com>
> Subject: Re: [PATCH net-next 6/9] net/mlx4_en: Adding support of turning
> off link autonegotiation via ethtool
>
> On Mon, Jan 16, 2017 at 7:30 PM, Tariq Toukan <tariqt@mellanox.com>
> wrote:
> 0644
> > --- a/include/linux/mlx4/device.h
> > +++ b/include/linux/mlx4/device.h
> > @@ -1539,8 +1539,13 @@ enum mlx4_ptys_proto {
> > MLX4_PTYS_EN = 1<<2,
> > };
> >
> > +enum mlx4_ptys_flags {
> > + MLX4_PTYS_AN_DISABLE_CAP = 1 << 5,
> > + MLX4_PTYS_AN_DISABLE_ADMIN = 1 << 6, };
> > +
> > struct mlx4_ptys_reg {
> > - u8 resrvd1;
> > + u8 flags;
> > u8 local_port;
> > u8 resrvd2;
> > u8 proto_mask;
>
> Hi Ariel,
>
> I didn't see any new dev cap bit, what happens with FW version which don't
> support this, is the result well defined? what is it?
>
> Or.
^ permalink raw reply
* [PATCH net-next] bridge: sparse fixes in br_ip6_multicast_alloc_query()
From: Lance Richardson @ 2017-01-16 23:11 UTC (permalink / raw)
To: netdev
Changed type of csum field in struct igmpv3_query from __be16 to
__sum16 to eliminate type warning, made same change in struct
igmpv3_report for consistency.
Fixed up an ntohs() where htons() should have been used instead.
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
include/uapi/linux/igmp.h | 4 ++--
net/bridge/br_multicast.c | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/include/uapi/linux/igmp.h b/include/uapi/linux/igmp.h
index ccbb32a..a97f9a7 100644
--- a/include/uapi/linux/igmp.h
+++ b/include/uapi/linux/igmp.h
@@ -53,7 +53,7 @@ struct igmpv3_grec {
struct igmpv3_report {
__u8 type;
__u8 resv1;
- __be16 csum;
+ __sum16 csum;
__be16 resv2;
__be16 ngrec;
struct igmpv3_grec grec[0];
@@ -62,7 +62,7 @@ struct igmpv3_report {
struct igmpv3_query {
__u8 type;
__u8 code;
- __be16 csum;
+ __sum16 csum;
__be32 group;
#if defined(__LITTLE_ENDIAN_BITFIELD)
__u8 qrv:3,
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index b30e77e..f6634612 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -540,7 +540,7 @@ static struct sk_buff *br_ip6_multicast_alloc_query(struct net_bridge *br,
break;
case 2:
mld2q = (struct mld2_query *)icmp6_hdr(skb);
- mld2q->mld2q_mrc = ntohs((u16)jiffies_to_msecs(interval));
+ mld2q->mld2q_mrc = htons((u16)jiffies_to_msecs(interval));
mld2q->mld2q_type = ICMPV6_MGM_QUERY;
mld2q->mld2q_code = 0;
mld2q->mld2q_cksum = 0;
--
2.5.5
^ permalink raw reply related
* Re: [pull request][for-next] Mellanox mlx5 Reorganize core driver directory layout
From: Saeed Mahameed @ 2017-01-16 23:36 UTC (permalink / raw)
To: Tom Herbert
Cc: David Miller, Saeed Mahameed, Doug Ledford, Linux Netdev List,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Leon Romanovsky
In-Reply-To: <CALx6S377hzH8_DbUSKafkbCzMEunr0H7vrfcb2WfEWFHFnfUpw-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Jan 16, 2017 at 11:06 PM, Tom Herbert <tom-BjP2VixgY4xUbtYUoyoikg@public.gmane.org> wrote:
> On Mon, Jan 16, 2017 at 12:30 PM, Saeed Mahameed
> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>> On Sat, Jan 14, 2017 at 12:07 AM, Saeed Mahameed
>> <saeedm-LDSdmyG8hGV8YrgS2mwiifqBs+8SCbDb@public.gmane.org> wrote:
>>> On Fri, Jan 13, 2017 at 7:14 PM, David Miller <davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org> wrote:
>>>> From: Saeed Mahameed <saeedm-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
>>>> Date: Thu, 12 Jan 2017 19:22:34 +0200
>>>>
>>>>> This pull request includes one patch from Leon, this patch as described
>>>>> below will change the driver directory structure and layout for better,
>>>>> logical and modular driver files separation.
>>>>>
>>>>> This change is important to both rdma and net maintainers in order to
>>>>> have smoother management of driver patches for different mlx5 sub modules
>>>>> and smoother rdma-next vs. net-next features submissions.
>>>>>
>>>>> Please find more info below -in the tag commit message-,
>>>>> review and let us know if there's any problem.
>>>>>
>>>>> This change doesn't introduce any conflicts with the current mlx5
>>>>> fixes and cleanups posted on 2017-01-10 to net branch, and merge tests
>>>>> worked flawlessly with no issues.
>>>>>
>>>>> This is the last pull request meant for both rdma-next and net-next.
>>>>> Once pulled, this will be the base shared code for both trees.
>>>>
>>>> This is pretty crazy, it will make all bug fix backporting to -stable
>>>> a complete nightmare for myself, Doug, various distribution maintainers
>>>> and many other people who quietly have to maintain their own trees and
>>>> do backporting.
>>>>
>>>
>>> I hear you,
>>> But please bear with me here, what if we queue this patch up to -stable ? and we
>>> (Mellanox) and specifically our dedicated inbox team, will make sure
>>> that this patch
>>> will land on the various distributions and for those maintaining their
>>> own trees.
>>> This patch is really straight forward (rename files) and I already
>>> tried to cherry-pick it
>>> on older kernels, I only got a couple of conflicts on some of the
>>> "#inlcude" lines we've
>>> changed, and they are pretty straightforward to fix, we can even avoid
>>> this if we decide to
>>> not move mlx5 header files in this phase.
>>>
>>> If this is possible then all trees will be aligned and it will be a
>>> win win situation.
>>>
>>
>> Hi Dave,
>>
>> Any chance you saw my -stable suggestion above ?
>> I think it would really close the backporting gap.
>>
>> Sorry i am bothering you with this topic, but we really desire the new
>> structure and
>> I never got your feedback on this suggestion, so i would like to hear
>> your thoughts.
>>
> Saeed,
>
> I've already you specific suggestions on your new structure, please
> consider your reviewers feedback more carefully. Again, the starting
I know, sorry i didn't respond on time, I though Leno's response was sufficient.
> point for your restructuring should be to separate out the minimum set
> of files required to build reasonable driver and then cleanly
> compartmentalize the rest of the features to make it easy for your
> users to include or not include those in their build. Unless you've
I see your point and i am 100% with you on this, we are all on the
same page here,
we all want to achieve the same goal -modular break down and features
logic separation-.
And in order to achieve this we need to do some big steps.
some of them will have real benefits and others are just moving code around.
One thing I need to point out (that Leon already mentioned) that the
current driver files sitting flat
in mlx5/core directory can be categorized to 4 categories
1. core related & init flows
2. common (infinband/ethernet resource management API)
3. infiniband related logic and FW commands
4. ethernet related logic and FW commands
so we figured that first we should split the bigger chunks (ethernet
vs. inifniband) into their own directories.
then i can follow up with ethernet features break down and kconfig separation.
> done this I'm not seeing much benefit for this restructuring. Also, I
> would rather see this done in one shot then expecting some sort of
> evolution over time to the right solution-- as Dave said the
> complexity of this driver is to far down the road to do that.
>
Well, I also prefer to do this in one shot, but I don't want to start
wasting time doing such a huge change
then get a NACK on submission.
Let's assume we did this in one shot i.e:
1. restructure files and directories
2. re-arrange code (separate logic)
3. Kconfig features control - to show the immediate benefit of this change
If this is acceptable by you and we get Dave's blessing on this then i
would be happy to provide (as this is our
long term plan), but if Dave doesn't approve, then ... I don't really know.
Also for 1. backporting is really easy since such patch can be applied
easily to any kernel release back to 4.4.
but 2. and 3. are really tricky ones.
> Tom
>
>> Thanks,
>> Saeed.
>>
>>>> I really don't think you can justify this rearrangement based upon the
>>>> consequences and how much activity happens in this driver.
>>>>
>>>
>>> Right, but this is not the only justification, I can sum it up to that
>>> we would like
>>> to lay out the foundation for many years to come for a well designed
>>> driver with a modular
>>> sub modules break down and scalable infrastructure. We already plan to
>>> submit more mlx5
>>> independent sub modules - just like mlx5e (en_*) files and mlx5_ib
>>> driver- so this was also
>>> a reason for us to consider this re-engagement at this stage.
>>>
>>>> You should have thought long and hard about the layout a long time ago
>>>> rather than after the driver has been in the tree for many years.
>>>>
>>>
>>> I had this Idea for the separation before the mlx5 Ethernet
>>> submission, but I wasn't the maintainer
>>> back then, and i have been itching to submit such patch for long as
>>> well, still i don't think
>>> it is too late, We (Me and Leon) will keep maintaining this driver for
>>> only god knows how many years to come,
>>> and the mlx5 drivers are meant to serve at least 3-4 more future HW generations.
>>>
>>> Long story short, We would like to re-arrange the driver in a way that
>>> would serve us (the maintainers) and serve those
>>> who are going do develop the future Stack features and the future HW
>>> generations over the well designed (Hopefully)
>>> mlx5 infrastructure.
>>> Keeping it as it is today, will only make the situation worst in the
>>> future and it will be really hard to avoid having a spaghetti code
>>> in the mlx5 driver. All i want to point out here is that maintaining
>>> such a flat subtree is also nightmare.
>>>
>>> So i am only asking you to reconsider this change and give my -stable
>>> suggestion a thought.
>>>
>>> Thank you.
>>> Saeed.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH net] vxlan: fix byte order of vxlan-gpe port number
From: Lance Richardson @ 2017-01-16 23:37 UTC (permalink / raw)
To: netdev, jbenc
vxlan->cfg.dst_port is in network byte order, so an htons()
is needed here. Also reduced comment length to stay closer
to 80 column width (still slightly over, however).
Fixes: e1e5314de08b ("vxlan: implement GPE")
Signed-off-by: Lance Richardson <lrichard@redhat.com>
---
drivers/net/vxlan.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/net/vxlan.c b/drivers/net/vxlan.c
index ca7196c..8a79cfc 100644
--- a/drivers/net/vxlan.c
+++ b/drivers/net/vxlan.c
@@ -2890,7 +2890,7 @@ static int vxlan_dev_configure(struct net *src_net, struct net_device *dev,
memcpy(&vxlan->cfg, conf, sizeof(*conf));
if (!vxlan->cfg.dst_port) {
if (conf->flags & VXLAN_F_GPE)
- vxlan->cfg.dst_port = 4790; /* IANA assigned VXLAN-GPE port */
+ vxlan->cfg.dst_port = htons(4790); /* IANA VXLAN-GPE port */
else
vxlan->cfg.dst_port = default_port;
}
--
2.5.5
^ permalink raw reply related
* [PATCH 1/1] ip: fix igmp parsing when iface is long
From: Petr Vorel @ 2017-01-16 23:25 UTC (permalink / raw)
To: netdev; +Cc: Petr Vorel
Entries with long vhost names in /proc/net/igmp have no whitespace
between name and colon, so sscanf() adds it to vhost and
'ip maddr show iface' doesn't include inet result.
Signed-off-by: Petr Vorel <pvorel@suse.cz>
---
ip/ipmaddr.c | 6 +++++-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/ip/ipmaddr.c b/ip/ipmaddr.c
index 22eb407..4f726fd 100644
--- a/ip/ipmaddr.c
+++ b/ip/ipmaddr.c
@@ -136,13 +136,17 @@ static void read_igmp(struct ma_info **result_p)
while (fgets(buf, sizeof(buf), fp)) {
struct ma_info *ma;
+ size_t len;
if (buf[0] != '\t') {
sscanf(buf, "%d%s", &m.index, m.name);
+ len = strlen(m.name);
+ if (m.name[len - 1] == ':')
+ len--;
continue;
}
- if (filter.dev && strcmp(filter.dev, m.name))
+ if (filter.dev && strncmp(filter.dev, m.name, len))
continue;
sscanf(buf, "%08x%d", (__u32 *)&m.addr.data, &m.users);
--
2.11.0
^ permalink raw reply related
* fq_codel and skb->hash
From: Andrew Collins @ 2017-01-17 0:04 UTC (permalink / raw)
To: netdev; +Cc: edumazet
The fq_codel packet scheduler always regenerates the skb flow hash. Is there any reason
to do this other than the recent hash perturbation additions?
I ask because I have a case where an incoming set of TCP flows is encapsulated in a
single ipsec tunnel, which is then classified on egress into a single flow by fq_codel
resulting in poor behavior.
Reusing the skb hash set in receive results in much better behavior, as the value is
determined pre-encapsulation and flows end up being distributed more naturally across
codel queues.
Is opportunistically using the pre-existing skb hash (if available) problematic? Is
there a better way to manage flow separation in routed+encapsulated traffic?
Thanks,
Andrew Collins
^ permalink raw reply
* RE: [PATCH] net: add regs attribute to phy device for user diagnose
From: YUAN Linyu @ 2017-01-17 0:11 UTC (permalink / raw)
To: David Miller, f.fainelli@gmail.com
Cc: cugyly@163.com, andrew@lunn.ch, netdev@vger.kernel.org
In-Reply-To: <20170116.165401.1642553705400599921.davem@davemloft.net>
> -----Original Message-----
> From: David Miller [mailto:davem@davemloft.net]
> Sent: Tuesday, January 17, 2017 5:54 AM
> To: f.fainelli@gmail.com
> Cc: cugyly@163.com; andrew@lunn.ch; netdev@vger.kernel.org; YUAN Linyu
> Subject: Re: [PATCH] net: add regs attribute to phy device for user diagnose
>
> From: Florian Fainelli <f.fainelli@gmail.com>
> Date: Mon, 16 Jan 2017 12:22:16 -0800
>
> >
> > So why not add support in ethtool for reading PHY registers if you need
> > it? There are handful of PHY "things" in ethtool, such as reading
> > counters, configuring downshift etc., adding support for dumping
> > registers does not sound out of space.
Thanks, I will try this direction.
>
> Agreed.
^ permalink raw reply
* Re: [PATCH net 1/1] net sched actions: fix refcnt when GETing of action after bind
From: David Miller @ 2017-01-17 0:46 UTC (permalink / raw)
To: jhs; +Cc: netdev, xiyou.wangcong
In-Reply-To: <1484493246-10911-1-git-send-email-jhs@emojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Sun, 15 Jan 2017 10:14:06 -0500
> From: Jamal Hadi Salim <jhs@mojatatu.com>
...
> Fixes: aecc5cefc389 ("net sched actions: fix GETing actions")
> Signed-off-by: Jamal Hadi Salim <jhs@mojatatu.com>
Applied and queued up for -stable, thanks Jamal.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Miller @ 2017-01-17 0:51 UTC (permalink / raw)
To: dsa; +Cc: netdev, ddutt
In-Reply-To: <1484510826-2723-2-git-send-email-dsa@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Sun, 15 Jan 2017 12:07:04 -0800
> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
> return __ip6_del_rt(rt, &info);
> }
>
> +/* called with table lock held */
...
> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
> continue;
> if (cfg->fc_protocol && cfg->fc_protocol != rt->rt6i_protocol)
> continue;
> - dst_hold(&rt->dst);
> - read_unlock_bh(&table->tb6_lock);
>
> - return __ip6_del_rt(rt, &cfg->fc_nlinfo);
> + err = __ip6_route_del(rt, cfg);
> + break;
> }
fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
table lock held a sa writer, but here you are only holding it as a
reader.
I also think some more thought has to be put into whether we can
change behavior like this without using a flag, as suggested by Roopa.
^ permalink raw reply
* Re: [PATCH v2 net-next 0/2] mvneta xmit_more and bql support
From: David Miller @ 2017-01-17 1:13 UTC (permalink / raw)
To: mw
Cc: thomas.petazzoni, andrew, linux, jason, netdev, linux-kernel, jaz,
gregory.clement, linux-arm-kernel, sebastian.hesselbarth
In-Reply-To: <1484586512-16412-1-git-send-email-mw@semihalf.com>
From: Marcin Wojtas <mw@semihalf.com>
Date: Mon, 16 Jan 2017 18:08:30 +0100
> This is a delayed v2 of short patchset, which introduces xmit_more and BQL
> to mvneta driver. The only one change was added in xmit_more support -
> condition check preventing excessive descriptors concatenation before
> flushing in HW.
>
> Any comments or feedback would be welcome.
...
> Changelog:
> v1 -> v2:
>
> * Add checking condition that ensures too much descriptors are not
> concatenated before flushing in HW.
Looks good, series applied, thanks.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Miller @ 2017-01-17 1:37 UTC (permalink / raw)
To: dsa; +Cc: netdev, ddutt
In-Reply-To: <06d4b3c0-0713-04b8-32d2-99b9b083b825@cumulusnetworks.com>
From: David Ahern <dsa@cumulusnetworks.com>
Date: Mon, 16 Jan 2017 18:27:36 -0700
> On 1/16/17 5:51 PM, David Miller wrote:
>> From: David Ahern <dsa@cumulusnetworks.com>
>> Date: Sun, 15 Jan 2017 12:07:04 -0800
>>
>>> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
>>> return __ip6_del_rt(rt, &info);
>>> }
>>>
>>> +/* called with table lock held */
>> ...
>>> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
>>> continue;
>>> if (cfg->fc_protocol && cfg->fc_protocol != rt->rt6i_protocol)
>>> continue;
>>> - dst_hold(&rt->dst);
>>> - read_unlock_bh(&table->tb6_lock);
>>>
>>> - return __ip6_del_rt(rt, &cfg->fc_nlinfo);
>>> + err = __ip6_route_del(rt, cfg);
>>> + break;
>>> }
>>
>> fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
>> table lock held a sa writer, but here you are only holding it as a
>> reader.
>
> That table lock is still held. If you look up 2 lines I remove the line that releases the lock.
It's held in this function as a reader, it needs to be held as a writer.
That's why the lock is dropped in the current code and the existing
wrapper around fib6_del() takes it as a writer.
Is it clear now?
read_lock_bh(&table->lock);
fib6_del();
is invalid.
write_lock_bh(&table->lock);
fib6_del();
is required.
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Ahern @ 2017-01-17 1:38 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ddutt
In-Reply-To: <20170116.203717.949572770050738032.davem@davemloft.net>
On 1/16/17 6:37 PM, David Miller wrote:
> Is it clear now?
yes. time for a trip to the eye doctor
^ permalink raw reply
* Re: fq_codel and skb->hash
From: Eric Dumazet @ 2017-01-17 1:44 UTC (permalink / raw)
To: Andrew Collins; +Cc: netdev, edumazet
In-Reply-To: <f9913fca-da16-8620-d237-d7d8d09cced2@cradlepoint.com>
On Mon, 2017-01-16 at 17:04 -0700, Andrew Collins wrote:
> The fq_codel packet scheduler always regenerates the skb flow hash. Is there any reason
> to do this other than the recent hash perturbation additions?
>
> I ask because I have a case where an incoming set of TCP flows is encapsulated in a
> single ipsec tunnel, which is then classified on egress into a single flow by fq_codel
> resulting in poor behavior.
>
> Reusing the skb hash set in receive results in much better behavior, as the value is
> determined pre-encapsulation and flows end up being distributed more naturally across
> codel queues.
>
> Is opportunistically using the pre-existing skb hash (if available) problematic?
I guess this would be fine.
We never exported the 'perturbation' or allowed to change/set it.
The only 'risk' would be having a buggy device setting a wrong L4
skb->hash, or buggy protocol messing with skb->hash for a given flow.
> Is there a better way to manage flow separation in routed+encapsulated traffic?
Encapsulated traffic is fine, since flow dissector skips encap header(s)
up to the L4 header.
Problem is about encrypted traffic, since presumably this L4 header is
opaque for flow dissector ;)
^ permalink raw reply
* Re: [PATCH net-next v2 1/3] net: ipv6: Allow shorthand delete of all nexthops in multipath route
From: David Ahern @ 2017-01-17 1:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, ddutt
In-Reply-To: <20170116.195139.2265183195514595519.davem@davemloft.net>
On 1/16/17 5:51 PM, David Miller wrote:
> From: David Ahern <dsa@cumulusnetworks.com>
> Date: Sun, 15 Jan 2017 12:07:04 -0800
>
>> @@ -2143,6 +2143,26 @@ int ip6_del_rt(struct rt6_info *rt)
>> return __ip6_del_rt(rt, &info);
>> }
>>
>> +/* called with table lock held */
> ...
>> @@ -2176,10 +2196,9 @@ static int ip6_route_del(struct fib6_config *cfg)
>> continue;
>> if (cfg->fc_protocol && cfg->fc_protocol != rt->rt6i_protocol)
>> continue;
>> - dst_hold(&rt->dst);
>> - read_unlock_bh(&table->tb6_lock);
>>
>> - return __ip6_del_rt(rt, &cfg->fc_nlinfo);
>> + err = __ip6_route_del(rt, cfg);
>> + break;
>> }
>
> fib6_del() (invoked by __ip6_route_del()) has to be invoked with the
> table lock held a sa writer, but here you are only holding it as a
> reader.
That table lock is still held. If you look up 2 lines I remove the line that releases the lock.
>
> I also think some more thought has to be put into whether we can
> change behavior like this without using a flag, as suggested by Roopa.
>
I'm all for changing the behavior by default, but AIUI that breaks the golden rule.
libnl as of libnl3_2_16-16-g29b71371e764 (a patch by Roopa) already handles both flavors -- if RTA_MULTIPATH is sent it handles it fine and if a series of routes are sent they are consolidated to 1 object with next hops.
iproute2 can handle it just fine as well. I made no changes to get the display format consistent. The problem here is scripts that rely on the old format.
quagga does *not* correctly handle the RTA_MULTIPATH attribute for IPv6 but then it does not properly handle IPv6 multipath routes it receives from the kernel at all. Same result with current kernel code or with this patch set - only the last nexthop is retained. (quagga routes pushed to kernel works, but kernel routes fed to quagga does not)
^ permalink raw reply
* [PATCH] qed: Replace memset with eth_zero_addr
From: Shyam Saini @ 2017-01-17 2:05 UTC (permalink / raw)
To: Yuval.Mintz; +Cc: Ariel.Elior, everest-linux-l2, netdev, Shyam Saini
Use eth_zero_addr to assign zero address to the given address array
instead of memset when the second argument in memset is address
of zero. Also, it makes the code clearer
Signed-off-by: Shyam Saini <mayhs11saini@gmail.com>
---
drivers/net/ethernet/qlogic/qed/qed_l2.c | 2 +-
drivers/net/ethernet/qlogic/qed/qed_sriov.c | 7 +++----
2 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/net/ethernet/qlogic/qed/qed_l2.c b/drivers/net/ethernet/qlogic/qed/qed_l2.c
index c92a850..7520eb3 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_l2.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_l2.c
@@ -1846,7 +1846,7 @@ static int qed_fill_eth_dev_info(struct qed_dev *cdev,
qed_fill_dev_info(cdev, &info->common);
if (IS_VF(cdev))
- memset(info->common.hw_mac, 0, ETH_ALEN);
+ eth_zero_addr(info->common.hw_mac);
return 0;
}
diff --git a/drivers/net/ethernet/qlogic/qed/qed_sriov.c b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
index b121364..3f4bf31 100644
--- a/drivers/net/ethernet/qlogic/qed/qed_sriov.c
+++ b/drivers/net/ethernet/qlogic/qed/qed_sriov.c
@@ -1224,7 +1224,7 @@ static void qed_iov_clean_vf(struct qed_hwfn *p_hwfn, u8 vfid)
return;
/* Clear the VF mac */
- memset(vf_info->mac, 0, ETH_ALEN);
+ eth_zero_addr(vf_info->mac);
vf_info->rx_accept_mode = 0;
vf_info->tx_accept_mode = 0;
@@ -2626,8 +2626,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn *p_hwfn,
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++) {
if (ether_addr_equal(p_vf->shadow_config.macs[i],
p_params->mac)) {
- memset(p_vf->shadow_config.macs[i], 0,
- ETH_ALEN);
+ eth_zero_addr(p_vf->shadow_config.macs[i]);
break;
}
}
@@ -2640,7 +2639,7 @@ static int qed_iov_vf_update_mac_shadow(struct qed_hwfn *p_hwfn,
} else if (p_params->opcode == QED_FILTER_REPLACE ||
p_params->opcode == QED_FILTER_FLUSH) {
for (i = 0; i < QED_ETH_VF_NUM_MAC_FILTERS; i++)
- memset(p_vf->shadow_config.macs[i], 0, ETH_ALEN);
+ eth_zero_addr(p_vf->shadow_config.macs[i]);
}
/* List the new MAC address */
--
2.7.4
^ permalink raw reply related
* [PATCH net-next 1/1] net: ping: Use right format specifier to avoid type casting
From: fgao @ 2017-01-17 2:21 UTC (permalink / raw)
To: davem, kuznet, jmorris, netdev, gfree.wind; +Cc: Gao Feng
From: Gao Feng <fgao@ikuai8.com>
The inet_num is u16, so use %hu instead of casting it to int. And
the sk_bound_dev_if is int actually, so it needn't cast to int.
Signed-off-by: Gao Feng <fgao@ikuai8.com>
---
net/ipv4/ping.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/net/ipv4/ping.c b/net/ipv4/ping.c
index 86cca61..592db6a 100644
--- a/net/ipv4/ping.c
+++ b/net/ipv4/ping.c
@@ -433,9 +433,9 @@ int ping_bind(struct sock *sk, struct sockaddr *uaddr, int addr_len)
goto out;
}
- pr_debug("after bind(): num = %d, dif = %d\n",
- (int)isk->inet_num,
- (int)sk->sk_bound_dev_if);
+ pr_debug("after bind(): num = %hu, dif = %d\n",
+ isk->inet_num,
+ sk->sk_bound_dev_if);
err = 0;
if (sk->sk_family == AF_INET && isk->inet_rcv_saddr)
--
1.9.1
^ permalink raw reply related
* Re: fq_codel and skb->hash
From: Eric Dumazet @ 2017-01-17 2:34 UTC (permalink / raw)
To: Andrew Collins; +Cc: netdev, edumazet
In-Reply-To: <1484617489.13165.63.camel@edumazet-glaptop3.roam.corp.google.com>
On Mon, 2017-01-16 at 17:44 -0800, Eric Dumazet wrote:
> On Mon, 2017-01-16 at 17:04 -0700, Andrew Collins wrote:
> > Is there a better way to manage flow separation in routed+encapsulated traffic?
>
> Encapsulated traffic is fine, since flow dissector skips encap header(s)
> up to the L4 header.
>
> Problem is about encrypted traffic, since presumably this L4 header is
> opaque for flow dissector ;)
BTW, how can we make sure skb->hash is populated before IPSEC ?
Relying on forwarding, and skb->hash set by a device might be not
enough.
^ permalink raw reply
* [GIT] Networking
From: David Miller @ 2017-01-17 2:52 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Handle multicast packets properly in fast-RX path of mac80211,
from Johannes Berg.
2) Because of a logic bug, the user can't actually force SW
checksumming on r8152 devices. This makes diagnosis of hw
checksumming bugs really annoying. Fix from Hayes Wang.
3) VXLAN route lookup does not take the source and destination ports
into account, which means IPSEC policies cannot be matched
properly. Fix from Martynas Pumputis.
4) Do proper RCU locking in netvsc callbacks, from Stephen Hemminger.
5) Fix SKB leaks in mlxsw driver, from Arkadi Sharshevsky.
6) If lwtunnel_fill_encap() fails, we do not abort the netlink message
construction properly in fib_dump_info(), from David Ahern.
7) Do not use kernel stack for DMA buffers in atusb driver, from
Stefan Schmidt.
8) Openvswitch conntack actions need to maintain a correct checksum,
fix from Lance Richardson.
9) ax25_disconnect() is missing a check for ax25->sk being NULL, in fact
it already checks this, but not in all of the necessary spots. Fix
from Basil Gunn.
10) Action GET operations in the packet scheduler can erroneously bump
the reference count of the entry, making it unreleasable. Fix
from Jamal Hadi Salim. Jamal gives a great set of example command
lines that trigger this in the commit message.
Please pull, thanks a lot!
The following changes since commit ba836a6f5ab1243ff5e08a941a2d1de8b31244e1:
Merge branch 'akpm' (patches from Andrew) (2017-01-11 11:15:15 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net
for you to fetch changes up to 0faa9cb5b3836a979864a6357e01d2046884ad52:
net sched actions: fix refcnt when GETing of action after bind (2017-01-16 19:43:19 -0500)
----------------------------------------------------------------
Andrey Smirnov (1):
at86rf230: Allow slow GPIO pins for "rstn"
Arkadi Sharshevsky (2):
mlxsw: spectrum: Fix memory leak at skb reallocation
mlxsw: switchx2: Fix memory leak at skb reallocation
Arnd Bergmann (2):
cpmac: remove hopeless #warning
net/mlx5e: Fix a -Wmaybe-uninitialized warning
Basil Gunn (1):
ax25: Fix segfault after sock connection timeout
Beni Lev (1):
cfg80211: consider VHT opmode on station update
Cedric Izoard (1):
mac80211: Fix headroom allocation when forwarding mesh pkt
Daniel Borkmann (1):
bpf: rework prog_digest into prog_tag
David Ahern (2):
net: lwtunnel: Handle lwtunnel_fill_encap failure
net: ipv4: fix table id in getroute response
David Lebrun (1):
ipv6: sr: fix several BUGs when preemption is enabled
David S. Miller (4):
Merge branch 'mlxsw-fixes'
Merge tag 'mac80211-for-davem-2017-01-13' of git://git.kernel.org/.../jberg/mac80211
Merge branch 'for-upstream' of git://git.kernel.org/.../bluetooth/bluetooth
Merge branch 'mlx4-core-fixes'
Elad Raz (1):
mlxsw: pci: Fix EQE structure definition
Emmanuel Grumbach (1):
mac80211: fix the TID on NDPs sent as EOSP carrier
Eric Dumazet (1):
mlx4: do not call napi_schedule() without care
Felix Fietkau (1):
mac80211: initialize SMPS field in HT capabilities
Florian Fainelli (1):
net: systemport: Decouple flow control from __bcm_sysport_tx_reclaim
Hangbin Liu (1):
mld: do not remove mld souce list info when set link down
Heiner Kallweit (1):
net: stmmac: don't use netdev_[dbg, info, ..] before net_device is registered
Ivan Vecera (3):
be2net: fix status check in be_cmd_pmac_add()
be2net: don't delete MAC on close on unprivileged BE3 VFs
be2net: fix MAC addr setting on privileged BE3 VFs
Jack Morgenstein (3):
net/mlx4_core: Fix racy CQ (Completion Queue) free
net/mlx4_core: Fix when to save some qp context flags for dynamic VST to VGT transitions
net/mlx4_core: Eliminate warning messages for SRQ_LIMIT under SRIOV
Jakub Sitnicki (1):
ip6_tunnel: Account for tunnel header in tunnel MTU
Jamal Hadi Salim (1):
net sched actions: fix refcnt when GETing of action after bind
Johannes Berg (3):
mac80211: implement multicast forwarding on fast-RX path
mac80211: calculate min channel width correctly
mac80211: recalculate min channel width on VHT opmode changes
Karicheri, Muralidharan (1):
net: phy: dp83867: allow RGMII_TXID/RGMII_RXID interface types
Kazuya Mizuguchi (1):
ravb: Remove Rx overflow log messages
Lance Richardson (1):
openvswitch: maintain correct checksum state in conntrack actions
Martynas Pumputis (1):
vxlan: Set ports in flow key when doing route lookups
Masaru Nagai (1):
ravb: do not use zero-length alignment DMA descriptor
Michal Kazior (1):
mac80211: prevent skb/txq mismatch
Parthasarathy Bhuvaragan (1):
tipc: allocate user memory with GFP_KERNEL flag
Shannon Nelson (1):
tcp: fix tcp_fastopen unaligned access complaints on sparc
Stefan Schmidt (4):
ieee802154: atusb: do not use the stack for buffers to make them DMA able
ieee802154: atusb: make sure we set a randaom extended address if fetching fails
ieee802154: atusb: do not use the stack for address fetching to make it DMA able
ieee802154: atusb: fix driver to work with older firmware versions
Timur Tabi (1):
net: qcom/emac: grab a reference to the phydev on ACPI systems
Vadim Lomovtsev (1):
net: thunderx: acpi: fix LMAC initialization
hayeswang (1):
r8152: fix the sw rx checksum is unavailable
stephen hemminger (1):
netvsc: add rcu_read locking to netvsc callback
Documentation/devicetree/bindings/net/ti,dp83867.txt | 6 ++++--
drivers/net/ethernet/broadcom/bcmsysport.c | 25 ++++++++++++++++++-------
drivers/net/ethernet/cavium/thunder/thunder_bgx.c | 11 ++++++-----
drivers/net/ethernet/emulex/benet/be_cmds.c | 2 +-
drivers/net/ethernet/emulex/benet/be_main.c | 18 +++++++++++++++---
drivers/net/ethernet/mellanox/mlx4/cq.c | 38 ++++++++++++++++++++------------------
drivers/net/ethernet/mellanox/mlx4/en_netdev.c | 5 ++++-
drivers/net/ethernet/mellanox/mlx4/eq.c | 23 ++++++++++++++---------
drivers/net/ethernet/mellanox/mlx4/resource_tracker.c | 5 +++--
drivers/net/ethernet/mellanox/mlx5/core/en_tc.c | 11 +++++++----
drivers/net/ethernet/mellanox/mlxsw/pci_hw.h | 8 ++++----
drivers/net/ethernet/mellanox/mlxsw/spectrum.c | 1 +
drivers/net/ethernet/mellanox/mlxsw/switchx2.c | 1 +
drivers/net/ethernet/qualcomm/emac/emac-phy.c | 7 +++++++
drivers/net/ethernet/qualcomm/emac/emac.c | 6 ++----
drivers/net/ethernet/renesas/ravb_main.c | 21 +++++++++++++++------
drivers/net/ethernet/stmicro/stmmac/stmmac_main.c | 19 ++++++++++---------
drivers/net/ethernet/ti/cpmac.c | 2 +-
drivers/net/hyperv/netvsc_drv.c | 3 +++
drivers/net/ieee802154/at86rf230.c | 4 ++--
drivers/net/ieee802154/atusb.c | 59 +++++++++++++++++++++++++++++++++++++++++++----------------
drivers/net/phy/dp83867.c | 8 ++++++--
drivers/net/usb/r8152.c | 7 ++++++-
drivers/net/vxlan.c | 13 ++++++++++---
include/linux/bpf.h | 2 +-
include/linux/filter.h | 6 ++++--
include/linux/tcp.h | 7 ++++++-
include/uapi/linux/nl80211.h | 4 +++-
include/uapi/linux/pkt_cls.h | 2 +-
include/uapi/linux/tc_act/tc_bpf.h | 2 +-
kernel/bpf/core.c | 14 ++++++++------
kernel/bpf/syscall.c | 8 ++++----
kernel/bpf/verifier.c | 2 +-
net/ax25/ax25_subr.c | 2 +-
net/ipv4/fib_semantics.c | 11 +++++++----
net/ipv4/route.c | 2 +-
net/ipv4/tcp_fastopen.c | 2 +-
net/ipv6/ip6_tunnel.c | 4 ++--
net/ipv6/mcast.c | 51 ++++++++++++++++++++++++++++++---------------------
net/ipv6/route.c | 3 ++-
net/ipv6/seg6_hmac.c | 2 +-
net/ipv6/seg6_iptunnel.c | 4 ++++
net/mac80211/chan.c | 3 ---
net/mac80211/iface.c | 21 +++++++++++++++++++++
net/mac80211/main.c | 13 +++++++++----
net/mac80211/rate.c | 2 ++
net/mac80211/rx.c | 38 +++++++++++++++++++++-----------------
net/mac80211/sta_info.c | 4 ++--
net/mac80211/tx.c | 17 +++++++----------
net/mac80211/vht.c | 4 +++-
net/openvswitch/conntrack.c | 6 ++++--
net/sched/act_api.c | 5 ++---
net/sched/act_bpf.c | 5 ++---
net/sched/cls_bpf.c | 4 ++--
net/tipc/discover.c | 4 ++--
net/tipc/link.c | 2 +-
net/tipc/msg.c | 16 ++++++++--------
net/tipc/msg.h | 2 +-
net/tipc/name_distr.c | 2 +-
net/wireless/nl80211.c | 15 +++++++++++++++
60 files changed, 384 insertions(+), 210 deletions(-)
^ permalink raw reply
* Re: [PATCH] stmicro: rename it to dwc to improve future development
From: kbuild test robot @ 2017-01-17 3:13 UTC (permalink / raw)
To: Joao Pinto
Cc: kbuild-all, davem, peppe.cavallaro, alexandre.torgue, netdev,
Joao Pinto
In-Reply-To: <0f5b325a9c8d9e5b6c95f90d833278cfb8f77606.1484571696.git.jpinto@synopsys.com>
[-- Attachment #1: Type: text/plain, Size: 22736 bytes --]
Hi Joao,
[auto build test WARNING on net-next/master]
[also build test WARNING on next-20170116]
[cannot apply to v4.10-rc4]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Joao-Pinto/stmicro-rename-it-to-dwc-to-improve-future-development/20170116-214440
config: m32r-allyesconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 6.2.0
reproduce:
wget https://git.kernel.org/cgit/linux/kernel/git/wfg/lkp-tests.git/plain/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/mmdebug.h:4,
from include/linux/gfp.h:4,
from include/linux/slab.h:14,
from drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c:30:
drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c: In function 'dwmac1000_dump_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c:107:3: note: in expansion of macro 'pr_info'
pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
^~~~~~~
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/dwc/stmmac/dwmac1000.h:25,
from drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c:30:
drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c: In function 'dwmac1000_dump_dma_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:10:18: note: in expansion of macro 'KERN_SOH'
#define KERN_ERR KERN_SOH "3" /* error conditions */
^~~~~~~~
include/linux/printk.h:292:9: note: in expansion of macro 'KERN_ERR'
printk(KERN_ERR pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac1000_dma.c:215:4: note: in expansion of macro 'pr_err'
pr_err("\t Reg No. %d (offset 0x%x): 0x%08x\n", i,
^~~~~~
--
In file included from include/linux/printk.h:6:0,
from include/linux/kernel.h:13,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/dwc/stmmac/dwmac100.h:28,
from drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:33:
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c: In function 'dwmac100_dump_mac_regs':
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:53:2: note: in expansion of macro 'pr_info'
pr_info("\tcontrol reg (offset 0x%x): 0x%08x\n", MAC_CONTROL,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:55:2: note: in expansion of macro 'pr_info'
pr_info("\taddr HI (offset 0x%x): 0x%08x\n ", MAC_ADDR_HIGH,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:57:2: note: in expansion of macro 'pr_info'
pr_info("\taddr LO (offset 0x%x): 0x%08x\n", MAC_ADDR_LOW,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:59:2: note: in expansion of macro 'pr_info'
pr_info("\tmulticast hash HI (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:61:2: note: in expansion of macro 'pr_info'
pr_info("\tmulticast hash LO (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:63:2: note: in expansion of macro 'pr_info'
pr_info("\tflow control (offset 0x%x): 0x%08x\n",
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:65:2: note: in expansion of macro 'pr_info'
pr_info("\tVLAN1 tag (offset 0x%x): 0x%08x\n", MAC_VLAN1,
^~~~~~~
include/linux/kern_levels.h:4:18: warning: format '%x' expects argument of type 'unsigned int', but argument 3 has type 'long unsigned int' [-Wformat=]
#define KERN_SOH "\001" /* ASCII Start Of Header */
^
include/linux/kern_levels.h:13:19: note: in expansion of macro 'KERN_SOH'
#define KERN_INFO KERN_SOH "6" /* informational */
^~~~~~~~
include/linux/printk.h:299:9: note: in expansion of macro 'KERN_INFO'
printk(KERN_INFO pr_fmt(fmt), ##__VA_ARGS__)
^~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_core.c:67:2: note: in expansion of macro 'pr_info'
pr_info("\tVLAN2 tag (offset 0x%x): 0x%08x\n", MAC_VLAN2,
^~~~~~~
--
In file included from include/linux/kernel.h:13:0,
from include/linux/list.h:8,
from include/linux/preempt.h:10,
from include/linux/spinlock.h:50,
from include/linux/phy.h:20,
from drivers/net/ethernet/dwc/stmmac/dwmac100.h:28,
from drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:32:
drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c: In function 'dwmac100_dump_dma_regs':
>> drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:79:12: warning: format '%x' expects argument of type 'unsigned int', but argument 5 has type 'long unsigned int' [-Wformat=]
pr_debug("\t CSR%d (offset 0x%x): 0x%08x\n", i,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:79:3: note: in expansion of macro 'pr_debug'
pr_debug("\t CSR%d (offset 0x%x): 0x%08x\n", i,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:83:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:83:2: note: in expansion of macro 'pr_debug'
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:83:11: warning: format '%x' expects argument of type 'unsigned int', but argument 6 has type 'long unsigned int' [-Wformat=]
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac100_dma.c:83:2: note: in expansion of macro 'pr_debug'
pr_debug("\tCSR20 (0x%x): 0x%08x, CSR21 (0x%x): 0x%08x\n",
^~~~~~~~
--
In file included from include/linux/kernel.h:13:0,
from include/asm-generic/bug.h:13,
from arch/m32r/include/asm/bug.h:3,
from include/linux/bug.h:4,
from include/linux/io.h:23,
from drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:16:
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c: In function '_dwmac4_dump_dma_regs':
>> drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:133:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_CONTROL, offset: 0x%x, val: 0x%x\n", 0,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
>> drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:133:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_CONTROL, offset: 0x%x, val: 0x%x\n", 0,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:135:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x4,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:135:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x4,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:137:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x8,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:137:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_CONTROL, offset: 0x%x, val: 0x%x\n", 0x8,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:139:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x14,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:139:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x14,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:141:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x1c,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:141:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_BASE_ADDR, offset: 0x%x, val: 0x%x\n", 0x1c,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:143:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x20,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:143:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x20,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:145:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x28,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:145:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_END_ADDR, offset: 0x%x, val: 0x%x\n", 0x28,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:147:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_TX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x2c,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:147:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_TX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x2c,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:149:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_RX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x30,
^
include/linux/printk.h:276:21: note: in definition of macro 'pr_fmt'
#define pr_fmt(fmt) fmt
^~~
include/linux/printk.h:324:2: note: in expansion of macro 'dynamic_pr_debug'
dynamic_pr_debug(fmt, ##__VA_ARGS__)
^~~~~~~~~~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:149:2: note: in expansion of macro 'pr_debug'
pr_debug("\tDMA_CHAN_RX_RING_LEN, offset: 0x%x, val: 0x%x\n", 0x30,
^~~~~~~~
drivers/net/ethernet/dwc/stmmac/dwmac4_dma.c:151:11: warning: format '%x' expects argument of type 'unsigned int', but argument 4 has type 'long unsigned int' [-Wformat=]
pr_debug("\tDMA_CHAN_INTR_ENA, offset: 0x%x, val: 0x%x\n", 0x34,
..
vim +/pr_info +107 drivers/net/ethernet/dwc/stmmac/dwmac1000_core.c
d2afb5bd drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2014-09-01 91
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 92 writel(value, ioaddr + GMAC_CONTROL);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 93
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 94 value = readl(ioaddr + GMAC_CONTROL);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 95
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 96 return !!(value & GMAC_CONTROL_IPC);
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 97 }
ebbb293f drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-09-17 98
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 99 static void dwmac1000_dump_regs(struct mac_device_info *hw)
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 100 {
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 101 void __iomem *ioaddr = hw->pcsr;
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 102 int i;
1f0f6388 drivers/net/stmmac/dwmac1000_core.c David S. Miller 2010-08-30 103 pr_info("\tDWMAC1000 regs (base addr = 0x%p)\n", ioaddr);
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 104
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 105 for (i = 0; i < 55; i++) {
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 106 int offset = i * 4;
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 @107 pr_info("\tReg No. %d (offset 0x%x): 0x%08x\n", i,
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 108 offset, readl(ioaddr + offset));
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 109 }
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 110 }
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 111
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 112 static void dwmac1000_set_umac_addr(struct mac_device_info *hw,
7ed24bbe drivers/net/ethernet/stmicro/stmmac/dwmac1000_core.c Vince Bridgers 2014-07-31 113 unsigned char *addr,
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 114 unsigned int reg_n)
21d437cc drivers/net/stmmac/dwmac1000_core.c Giuseppe CAVALLARO 2010-01-06 115 {
:::::: The code at line 107 was first introduced by commit
:::::: 21d437cc66dcfd0119a4905214fbbe19f3e276dc stmmac: rename the gmac as dwmac1000 and split core and dma parts
:::::: TO: Giuseppe CAVALLARO <peppe.cavallaro@st.com>
:::::: CC: David S. Miller <davem@davemloft.net>
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 40611 bytes --]
^ permalink raw reply
* Re: [PATCH] qed: Replace memset with eth_zero_addr
From: Shyam Saini @ 2017-01-17 3:33 UTC (permalink / raw)
To: David Miller; +Cc: Yuval.Mintz, Ariel.Elior, everest-linux-l2, netdev
In-Reply-To: <20170116.145819.115892553691222296.davem@davemloft.net>
On Mon, Jan 16, 2017 at 02:58:19PM -0500, David Miller wrote:
> From: Shyam Saini <mayhs11saini@gmail.com>
> Date: Tue, 17 Jan 2017 00:21:38 +0530
>
> > Use eth_zero_addr to assign zero address to the given address array
> > instead of memset when the second argument in memset is address
> > of zero. Also, it makes the code clearer
> >
> > Signed-off-by: Shyam Saini <mayhs11saini@gmail.com>
>
> This patch does not apply cleanly to the net-next tree.
I always send patches from linux-next tree and that caused this mistake
I apologize for this.
> Please state if you don't understand what that means instead of
> submitting this patch over and over again against the wrong source
> tree.
Now sent from net-next tree
Thanks a lot,
Shyam
^ permalink raw reply
* Re: [PATCHv3 net-next 1/7] sctp: add a common helper function to generate stream reconf chunk
From: Xin Long @ 2017-01-17 3:41 UTC (permalink / raw)
To: David Miller
Cc: network dev, linux-sctp, Marcelo Ricardo Leitner, Neil Horman,
Vlad Yasevich
In-Reply-To: <20170116.135033.773805315875747960.davem@davemloft.net>
On Tue, Jan 17, 2017 at 2:50 AM, David Miller <davem@davemloft.net> wrote:
> From: Xin Long <lucien.xin@gmail.com>
> Date: Sat, 14 Jan 2017 03:15:35 +0800
>
>> diff --git a/net/sctp/sm_make_chunk.c b/net/sctp/sm_make_chunk.c
>> index a15d824..fd58097 100644
>> --- a/net/sctp/sm_make_chunk.c
>> +++ b/net/sctp/sm_make_chunk.c
>> @@ -3526,3 +3526,36 @@ struct sctp_chunk *sctp_make_fwdtsn(const struct sctp_association *asoc,
>>
>> return retval;
>> }
>> +
>> +/* RE-CONFIG 3.1 (RE-CONFIG chunk)
>> + * 0 1 2 3
>> + * 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>> + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + * | Type = 130 | Chunk Flags | Chunk Length |
>> + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + * \ \
>> + * / Re-configuration Parameter /
>> + * \ \
>> + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + * \ \
>> + * / Re-configuration Parameter (optional) /
>> + * \ \
>> + * +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>> + */
>> +static struct sctp_chunk *sctp_make_reconf(
>> + const struct sctp_association *asoc,
>> + int length)
>> +{
>> + struct sctp_reconf_chunk *reconf;
>
> This patch will cause a warning because this new static function is unused.
>
> All patch series must be fully bisectable, that measn at each step of
> the patch series the tree must work properly and not introduce new
> build warnings or build failures.
sorry, will merge patch 1/7 and 2/7
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Richard Guy Briggs @ 2017-01-17 3:53 UTC (permalink / raw)
To: Paul Moore; +Cc: netdev, Steve, linux-audit, linux-kernel
In-Reply-To: <CAHC9VhQsL7c=dAd4ZyTbEugkcrNuaxGNnaOi8oMkn=NCwuVoHA@mail.gmail.com>
On 2017-01-16 15:04, Paul Moore wrote:
> On Fri, Jan 13, 2017 at 9:42 AM, Eric Paris <eparis@redhat.com> wrote:
> > On Fri, 2017-01-13 at 04:51 -0500, Richard Guy Briggs wrote:
> >> diff --git a/include/linux/audit.h b/include/linux/audit.h
> >> index 9d4443f..43d8003 100644
> >> --- a/include/linux/audit.h
> >> +++ b/include/linux/audit.h
> >> @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs,
> >> unsigned long *args)
> >> return __audit_socketcall(nargs, args);
> >> return 0;
> >> }
> >> +static inline int audit_socketcall_compat(int nargs, u32 *args)
> >> +{
> >> + if (unlikely(!audit_dummy_context())) {
> >
> > I've always hated these likely/unlikely. Mostly because I think they
> > are so often wrong. I believe this says that you compiled audit in but
> > you expect it to be explicitly disabled. While that is (recently) true
> > in Fedora I highly doubt that's true on the vast majority of systems
> > that have audit compiled in.
>
> Richard and I have talked about the likely/unlikely optimization
> before and I know Richard likes to use them, but I don't for the
> reasons Eric has already mentioned. Richard, since you're respinning
> the patch, go ahead and yank out the unlikely() call.
I don't "like to use them". I'm simply following the use and style of
existing code and the arguments of others in places of critical
performance. If I "fix" that one, then I would feel compelled to yank
out the one in the function immediately above, audit_socketcall() for
consistency to ease my conscience. Eric conceded that argument.
> paul moore
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCH V2] audit: log 32-bit socketcalls
From: Richard Guy Briggs @ 2017-01-17 4:03 UTC (permalink / raw)
To: David Miller
Cc: netdev, linux-kernel, linux-audit, aixer77, eparis, pmoore,
sgrubb
In-Reply-To: <20170116.132745.1831536278596554491.davem@davemloft.net>
On 2017-01-16 13:27, David Miller wrote:
> From: Richard Guy Briggs <rgb@redhat.com>
> Date: Fri, 13 Jan 2017 04:51:48 -0500
>
> > diff --git a/include/linux/audit.h b/include/linux/audit.h
> > index 9d4443f..43d8003 100644
> > --- a/include/linux/audit.h
> > +++ b/include/linux/audit.h
> > @@ -387,6 +387,18 @@ static inline int audit_socketcall(int nargs, unsigned long *args)
> > return __audit_socketcall(nargs, args);
> > return 0;
> > }
> > +static inline int audit_socketcall_compat(int nargs, u32 *args)
> > +{
>
> Please put an empty line between function definitions.
Ok, should I reformat the rest of the file while I'm at it?
> > + if (unlikely(!audit_dummy_context())) {
> > + int i;
> > + unsigned long a[AUDITSC_ARGS];
>
> Please order local variable declarations from longest to shortest line.
Ok. Is this a recent addition to a style guide or in checkpatch.pl?
> > +
> > + for (i=0; i<nargs; i++)
>
> Please put a space around operators such as "=" and "<".
Oops, my bad...
> > + a[i] = (unsigned long)args[i];
> > + return __audit_socketcall(nargs, a);
> > + }
> > + return 0;
> > +}
> > static inline int audit_sockaddr(int len, void *addr)
>
> Again, empty line between function definitions please.
>
> > @@ -781,14 +782,24 @@ COMPAT_SYSCALL_DEFINE5(recvmmsg, int, fd, struct compat_mmsghdr __user *, mmsg,
> >
> > COMPAT_SYSCALL_DEFINE2(socketcall, int, call, u32 __user *, args)
> > {
> > + unsigned int len;
> > int ret;
> > - u32 a[6];
> > + u32 a[AUDITSC_ARGS];
> > u32 a0, a1;
>
> Longest to shortest line for local variable declarations please.
- RGB
--
Richard Guy Briggs <rgb@redhat.com>
Kernel Security Engineering, Base Operating Systems, Red Hat
Remote, Ottawa, Canada
Voice: +1.647.777.2635, Internal: (81) 32635
^ permalink raw reply
* Re: [PATCHv3 net-next 2/7] sctp: add support for generating stream reconf ssn reset request chunk
From: Xin Long @ 2017-01-17 4:27 UTC (permalink / raw)
To: Marcelo Ricardo Leitner
Cc: network dev, linux-sctp, Neil Horman, Vlad Yasevich, davem
In-Reply-To: <CADvbK_cLGNyCWCHJ1pcMxxuqFvGABKBOS36_ekJhYsrd30nc3g@mail.gmail.com>
On Mon, Jan 16, 2017 at 11:56 AM, Xin Long <lucien.xin@gmail.com> wrote:
> On Sun, Jan 15, 2017 at 11:51 PM, Marcelo Ricardo Leitner
> <marcelo.leitner@gmail.com> wrote:
>> On Sat, Jan 14, 2017 at 03:15:36AM +0800, Xin Long wrote:
>>> This patch is to add asoc strreset_outseq and strreset_inseq for
>>> saving the reconf request sequence, initialize them when create
>>> assoc and process init, and also to define Incoming and Outgoing
>>> SSN Reset Request Parameter described in rfc6525 section 4.1 and
>>> 4.2, As they can be in one same chunk as section rfc6525 3.1-3
>>> describes, it makes them in one function.
>>>
>>> Signed-off-by: Xin Long <lucien.xin@gmail.com>
>>> ---
>>> include/linux/sctp.h | 26 ++++++++++++++
>>> include/net/sctp/sm.h | 5 ++-
>>> include/net/sctp/structs.h | 3 ++
>>> net/sctp/associola.c | 1 +
>>> net/sctp/sm_make_chunk.c | 88 ++++++++++++++++++++++++++++++++++++++++++++++
>>> 5 files changed, 122 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/include/linux/sctp.h b/include/linux/sctp.h
>>> index cdc3b05..d5da19c 100644
>>> --- a/include/linux/sctp.h
>>> +++ b/include/linux/sctp.h
>>> @@ -200,6 +200,13 @@ typedef enum {
>>> SCTP_PARAM_SUCCESS_REPORT = cpu_to_be16(0xc005),
>>> SCTP_PARAM_ADAPTATION_LAYER_IND = cpu_to_be16(0xc006),
>>>
>>> + /* RE-CONFIG. Section 4 */
>>> + SCTP_PARAM_RESET_OUT_REQUEST = cpu_to_be16(0x000d),
>>> + SCTP_PARAM_RESET_IN_REQUEST = cpu_to_be16(0x000e),
>>> + SCTP_PARAM_RESET_TSN_REQUEST = cpu_to_be16(0x000f),
>>> + SCTP_PARAM_RESET_RESPONSE = cpu_to_be16(0x0010),
>>> + SCTP_PARAM_RESET_ADD_OUT_STREAMS = cpu_to_be16(0x0011),
>>> + SCTP_PARAM_RESET_ADD_IN_STREAMS = cpu_to_be16(0x0012),
>>> } sctp_param_t; /* enum */
>>>
>>>
>>> @@ -716,4 +723,23 @@ struct sctp_reconf_chunk {
>>> __u8 params[0];
>>> } __packed;
>>>
>>> +struct sctp_strreset_req {
>>> + sctp_paramhdr_t param_hdr;
>>> + __u32 request_seq;
>>> +} __packed;
>>> +
>>> +struct sctp_strreset_outreq {
>>> + sctp_paramhdr_t param_hdr;
>>> + __u32 request_seq;
>>
>> This should be:
>> + struct sctp_strreset_req strreset_req;
>> Use the definition you created above for the encapsulation and make the
>> embedding evident.
>> Like it's done for sctp_chunkhdr_t.
> I'm not sure if it's good to do it like sctp_chunkhdr_t.
>
> As sctp_chunkhdr is a very common data:
> Chunk Type | Chunk Flags | Chunk Length
> and the next must be "Chunk Value"
>
> But here sctp_strreset_req is more used to access
> the request_seq of the params in asoc->strreset_chunk
> without knowing params' type. like in sctp_chunk_lookup_strreset_param()
> and sctp_process_strreset_resp() [see it from the big patchset].
>
> struct sctp_strreset_outreq {
> sctp_paramhdr_t param_hdr;
> __u32 request_seq;
> ------------------------------------[1]
> __u32 response_seq;
> __u32 send_reset_at_tsn;
> __u16 list_of_streams[0];
> } __packed;
>
> it seems not good to split it by [1].
> __u32 request_seq;
> __u32 response_seq;
> __u32 send_reset_at_tsn;
> __u16 list_of_streams[0];
> these should to together and equal.
>
> what do you think ?
>
Hi, Marcelo, I'm planning to drop "struct sctp_strreset_req" so
that it will not be confusing here, and only introduce it when
it's used somewhere. agreed ?
^ permalink raw reply
* (unknown),
From: Andy Lutomirski @ 2017-01-17 5:18 UTC (permalink / raw)
To: Tejun Heo
Cc: Michal Hocko, Peter Zijlstra, David Ahern, Alexei Starovoitov,
Andy Lutomirski, Daniel Mack, Mickaël Salaün, Kees Cook,
Jann Horn, David S. Miller, Thomas Graf, Michael Kerrisk,
Linux API, linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Network Development
;; This buffer is for text that is not saved, and for Lisp evaluation.
;; To create a file, visit it with C-x C-f and enter text in its buffer.
On Sun, Jan 15, 2017 at 5:19 PM, Tejun Heo <tj-DgEjT+Ai2ygdnm+yROfE0A@public.gmane.org> wrote:
> Hello,
>
> Sorry about the delay. Some fire fighthing followed the holidays.
>
> On Tue, Jan 03, 2017 at 11:25:59AM +0100, Michal Hocko wrote:
>> > So from what I understand the proposed cgroup is not in fact
>> > hierarchical at all.
>> >
>> > @TJ, I thought you were enforcing all new cgroups to be properly
>> > hierarchical, that would very much include this one.
>>
>> I would be interested in that as well. We have made that mistake in
>> memcg v1 where hierarchy could be disabled for performance reasons and
>> that turned out to be major PITA in the end. Why do we want to repeat
>> the same mistake here?
>
> Across the different threads on this subject, there have been multiple
> explanations but I'll try to sum it up more clearly.
>
> The big issue here is whether this is a cgroup thing or a bpf thing.
> I don't think there's anything inherently wrong with one approach or
> the other. Forget about the proposed cgroup bpf extentions but thinkg
> about how iptables does cgroups. Whether it's the netcls/netprio in
> v1 or direct membership matching in v2, it is the network side testing
> for cgroup membership one way or the other. The only part where
> cgroup is involved in is answering that test.
>
[...]
>
> None of the issues that people have been raising here is actually an
> issue if one thinks of it as a part of bpf. Its security model is
> exactly the same as any other bpf programs. Recursive behavior is
> exactly the same as how other external cgroup descendant membership
> testing work. There is no issue here whatsoever.
After sleeping on this, here are my thoughts:
First, there are three ways to think about this, not just two. It
could be a BPF feature, a net feature, or a cgroup feature.
I think that calling it a BPF feature is a cop-out. BPF is an
assembly language and a mechanism for importing little programs into
the kernel. BPF maps are a BPF feature. These new hooks are a
feature that actively changes the behavior of other parts of the
kernel. I don't see how calling this new feature a "BPF" feature
excuses it from playing by the expected rules of the subsystems it
affects or from generally working well with the rest of the kernel.
Perhaps this is a net feature, though, not a cgroup feature. This
would IMO make a certain amount of sense. Iptables cgroup matches,
for example, logically are an iptables (i.e., net) feature. The
problem here is that network configuration (and this explicitly
includes iptables) is done on a per-netns level, whereas these new
hooks entirely ignore network namespaces. I've pointed out that
trying to enable them in a namespaced world is problematic (e.g.
switching to ns_capable() will cause serious problems), and Alexei
seems to think that this will never happen. So I don't think we can
really call this a net feature that works the way that other net
features work.
(Suppose that this actually tried to be netns-enabled. Then you'd
have to map from (netns, cgroup) -> hook, and this would probably be
slow and messy.)
So I think that leaves it being a cgroup feature. And it definitely
does *not* play by the rules of cgroups right now.
> I'm sure we'll
> eventually get there but from what I hear it isn't something we can
> pull off in a restricted timeframe.
To me, this sounds like "the API isn't that great, we know how to do
better, but we really really want this feature ASAP so we want to ship
it with a sub-par API." I think that's a bad idea.
> This also holds true for the perf controller. While it is implemented
> as a controller, it isn't visible to cgroup users in any way and the
> only function it serves is providing the membership test to perf
> subsystem. perf is the one which decides whether and how it is to be
> used. cgroup providing membership test to other subsystems is
> completely acceptable and established.
Unless I'm mistaken, "perf_event" is an actual cgroup controller, and
it explicitly respects the cgroup hierarchy. It shows up in
/proc/cgroups, and I had no problem mounting a cgroupfs instance with
perf_event enabled. So I'm not sure what you mean.
^ 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