* Re: per-PID network stats files in /proc
From: Matthew Hall @ 2013-09-24 21:22 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <20130924140435.5881cf76@nehalam.linuxnetplumber.net>
On Tue, Sep 24, 2013 at 02:04:35PM -0700, Stephen Hemminger wrote:
> You could do what you want by putting each process in own network
> namespace, but that might be more work than you want to bother with.
Putting my one process or group of processes into one namespace, separate from
the one the rest of the system uses, could be perfectly OK actually.
So I'm going to look into this and see if it's possible. At least it would
give me a better route than where I am right now.
Thanks!
Matthew.
^ permalink raw reply
* Re: [PATCH 08/10] toshiba: Remove extern from function prototypes
From: Geoff Levand @ 2013-09-24 21:26 UTC (permalink / raw)
To: Joe Perches
Cc: netdev, David S. Miller, Ishizaki Kou, Jens Osterkamp,
cbe-oss-dev, linux-kernel
In-Reply-To: <3e0dd1f4722f8e0c10a47b9bbb26e891e79fef60.1380056108.git.joe@perches.com>
On Tue, 2013-09-24 at 14:10 -0700, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
>
> Signed-off-by: Joe Perches <joe@perches.com>
> ---
> drivers/net/ethernet/toshiba/ps3_gelic_net.h | 29 +++++++++++------------
> drivers/net/ethernet/toshiba/ps3_gelic_wireless.h | 6 ++---
> drivers/net/ethernet/toshiba/spider_net.h | 4 ++--
> 3 files changed, 19 insertions(+), 20 deletions(-)
Looks good. Thanks.
Acked-by: Geoff Levand <geoff@infradead.org>
^ permalink raw reply
* Re: [PATCH 1/2 v2] net: Add function to get SW rxhash
From: Eric Dumazet @ 2013-09-24 21:30 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev
In-Reply-To: <alpine.DEB.2.02.1309241335380.23856@tomh.mtv.corp.google.com>
On Tue, 2013-09-24 at 13:42 -0700, Tom Herbert wrote:
> Some uses of skb_get_rxhash expect that the function will return
> a consistent value whether it is called on RX or TX paths. On RX
> path, we will use the rxhash if provided by the NIC, so this
> would not normally be the same result computed in TX path would be
> a software calculation.
>
> This patch adds skb_get_sw_rxhash to explicitly request a hash
> calculated by the stack, disregarding the hash provided by NIC.
As I said, I think this is overhead in network fast path.
This can be done without adding a new skb field.
I suspect tun should not use rxhash but a proper hash, as conntrack or
tcp...
^ permalink raw reply
* Re: [PATCH] Allow userspace code to use flag IFA_F_SECONDARY to specify an ip address to be primary or secondary ip on an interface
From: Vincent Li @ 2013-09-24 21:34 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev@vger.kernel.org, linux-kernel, davem
In-Reply-To: <alpine.LFD.2.00.1309242255350.1875@ja.ssi.bg>
Thanks Julian for the comments, I imagined it would not be so simple
as it changed old behavior with ip binary and some actions in
__inet_del_ifa() that I am not fully aware of. my intention is to
preserve the old behavior and extend the flexibility, I am unable to
come up with a good patch to achieve the intended behavior.
I had to patch the ip binary to sort of preserve original ip binary
behavior with the kernel patch I provided., the ip command patch
below:
diff --git a/ip/ipaddress.c b/ip/ipaddress.c
index 1c3e4da..9f2802c 100644
--- a/ip/ipaddress.c
+++ b/ip/ipaddress.c
@@ -1259,6 +1259,7 @@ static int ipaddr_modify(int cmd, int flags, int
argc, char **argv)
req.n.nlmsg_flags = NLM_F_REQUEST | flags;
req.n.nlmsg_type = cmd;
req.ifa.ifa_family = preferred_family;
+ req.ifa.ifa_flags |= IFA_F_SECONDARY;
while (argc > 0) {
if (strcmp(*argv, "peer") == 0 ||
@@ -1307,6 +1308,11 @@ static int ipaddr_modify(int cmd, int flags,
int argc, char **argv)
invarg("invalid scope value.", *argv);
req.ifa.ifa_scope = scope;
scoped = 1;
+ } else if (strcmp(*argv, "secondary") == 0 ||
+ strcmp(*argv, "temporary") == 0) {
+ req.ifa.ifa_flags |= IFA_F_SECONDARY;
+ } else if (strcmp(*argv, "primary") == 0) {
+ req.ifa.ifa_flags &= ~IFA_F_SECONDARY;
} else if (strcmp(*argv, "dev") == 0) {
NEXT_ARG();
d = *argv;
if someone can point me to the right patch directions or coming up
with better patches, it is very much appreciated.
On Tue, Sep 24, 2013 at 2:13 PM, Julian Anastasov <ja@ssi.bg> wrote:
>
> Hello,
>
> On Tue, 24 Sep 2013, Vincent Li wrote:
>
>> the current behavior is when an IP is added to an interface, the primary
>> or secondary attributes is depending on the order of ip added to the interface
>> the first IP will be primary and second, third,... or alias IP will be secondary
>> if the IP subnet matches
>>
>> this patch add the flexiblity to allow user to specify an argument 'primary' or 'secondary'
>> (use 'ip addr add ip/mask primary|secondary dev ethX ' from iproute2 for example) to specify
>> an IP address to be primary or secondary.
>>
>> the reason for this patch is that we have a multi blade cluster platform sharing 'floating management ip'
>> and also that each blade has its own management ip on the management interface, so whichever blade in the
>> cluster becomes primary blade, the 'floating mangaement ip' follows it, and we want any of our traffic
>> originated from the primary blade source from the 'floating management ip' for consistency. but in this
>> case, since the local blade management ip is always the primary ip on the mangaement interface and 'floating
>> management ip' is always secondary, kernel always choose the primary ip as source ip address. thus we would
>> like to add the flexibility in kernel to allow us to specify which ip to be primary or secondary.
>>
>> Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
>> ---
>> net/ipv4/devinet.c | 9 +++++++--
>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>
>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>> index a1b5bcb..bfc702a 100644
>> --- a/net/ipv4/devinet.c
>> +++ b/net/ipv4/devinet.c
>> @@ -440,9 +440,11 @@ static int __inet_insert_ifa(struct in_ifaddr *ifa, struct nlmsghdr *nlh,
>> return 0;
>> }
>>
>> - ifa->ifa_flags &= ~IFA_F_SECONDARY;
>> last_primary = &in_dev->ifa_list;
>>
>> + if((*last_primary) == NULL)
>> + ifa->ifa_flags &= ~IFA_F_SECONDARY;
>> +
>> for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
>> ifap = &ifa1->ifa_next) {
>> if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>> @@ -458,7 +460,10 @@ static int __inet_insert_ifa(struct in_ifaddr *ifa, struct nlmsghdr *nlh,
>> inet_free_ifa(ifa);
>> return -EINVAL;
>> }
>> - ifa->ifa_flags |= IFA_F_SECONDARY;
>
> There is some confusion here, when ifa has
> IFA_F_SECONDARY bit set, in the 'else' we set it again.
> I guess the 'else' part is not needed.
>
>> + if (!(ifa->ifa_flags & IFA_F_SECONDARY))
>> + ifa1->ifa_flags |= IFA_F_SECONDARY;
>> + else
>> + ifa->ifa_flags |= IFA_F_SECONDARY;
>
> It should not be so simple. You can not
> just change the flag of existing address (ifa1) to secondary.
> See __inet_del_ifa(), there are many more actions that
> follow:
>
> - kernel routes that use this primary address
> should be deleted and recreated with the new primary
> address as source. This includes local routes to secondary
> IPs.
>
> - RTM_NEWADDR should be sent, so that user space see
> the IFA_F_SECONDARY flag
>
> Some questions:
>
> - should we allow adding of secondary IPs when no primary
> address exists for the subnet, it can happen when primary
> for another subnet already exists
>
> - by default, existing 'ip addr' binaries will provide
> address without IFA_F_SECONDARY flag. Before now we added
> such addresses as last for the subnet, now the
> behaviour changes, we start to add addresses in reverse
> order. Is that true? I.e. before now the operation was
> APPEND, now we need a way to provide PREPEND operation.
>
> Regards
>
> --
> Julian Anastasov <ja@ssi.bg>
^ permalink raw reply related
* Re: [PATCH v5] IPv6 NAT: Do not drop DNATed 6to4/6rd packets
From: Hannes Frederic Sowa @ 2013-09-24 21:36 UTC (permalink / raw)
To: Catalin(ux) M. BOIE; +Cc: netdev, yoshfuji, davem, joe
In-Reply-To: <1379966659-28838-1-git-send-email-catab@embedromix.ro>
On Mon, Sep 23, 2013 at 11:04:19PM +0300, Catalin(ux) M. BOIE wrote:
> When a router is doing DNAT for 6to4/6rd packets the latest anti-spoofing
> patch (218774dc) will drop them because the IPv6 address embedded
> does not match the IPv4 destination. This patch will allow them to
> pass by testing if we have an address that matches on 6to4/6rd interface.
> I have been hit by this problem using Fedora and IPV6TO4_IPV4ADDR.
> Also, log the dropped packets (with rate limit).
>
> Signed-off-by: Catalin(ux) M. BOIE <catab@embedromix.ro>
Acked-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
Thanks,
Hannes
^ permalink raw reply
* Re: [PATCH] Allow userspace code to use flag IFA_F_SECONDARY to specify an ip address to be primary or secondary ip on an interface
From: Vincent Li @ 2013-09-24 21:54 UTC (permalink / raw)
To: Julian Anastasov; +Cc: netdev@vger.kernel.org, linux-kernel, davem
In-Reply-To: <CAK3+h2y8eAKFC7BbnDwfZLzTw=t-G9qWSqznp4ggwDy7R_O6Ag@mail.gmail.com>
sorry Julian to miss your point after reading the __inet_del_ifa and
see the rtmsg_ifa, fib_del_ifaddr/fib_add_ifaddr, I can try another
patch and actually test if the patches changes works as it is
intended, not just checking from ip binary output.
Vincent
On Tue, Sep 24, 2013 at 2:34 PM, Vincent Li <vincent.mc.li@gmail.com> wrote:
> Thanks Julian for the comments, I imagined it would not be so simple
> as it changed old behavior with ip binary and some actions in
> __inet_del_ifa() that I am not fully aware of. my intention is to
> preserve the old behavior and extend the flexibility, I am unable to
> come up with a good patch to achieve the intended behavior.
>
> I had to patch the ip binary to sort of preserve original ip binary
> behavior with the kernel patch I provided., the ip command patch
> below:
>
> diff --git a/ip/ipaddress.c b/ip/ipaddress.c
> index 1c3e4da..9f2802c 100644
> --- a/ip/ipaddress.c
> +++ b/ip/ipaddress.c
> @@ -1259,6 +1259,7 @@ static int ipaddr_modify(int cmd, int flags, int
> argc, char **argv)
> req.n.nlmsg_flags = NLM_F_REQUEST | flags;
> req.n.nlmsg_type = cmd;
> req.ifa.ifa_family = preferred_family;
> + req.ifa.ifa_flags |= IFA_F_SECONDARY;
>
> while (argc > 0) {
> if (strcmp(*argv, "peer") == 0 ||
> @@ -1307,6 +1308,11 @@ static int ipaddr_modify(int cmd, int flags,
> int argc, char **argv)
> invarg("invalid scope value.", *argv);
> req.ifa.ifa_scope = scope;
> scoped = 1;
> + } else if (strcmp(*argv, "secondary") == 0 ||
> + strcmp(*argv, "temporary") == 0) {
> + req.ifa.ifa_flags |= IFA_F_SECONDARY;
> + } else if (strcmp(*argv, "primary") == 0) {
> + req.ifa.ifa_flags &= ~IFA_F_SECONDARY;
> } else if (strcmp(*argv, "dev") == 0) {
> NEXT_ARG();
> d = *argv;
>
> if someone can point me to the right patch directions or coming up
> with better patches, it is very much appreciated.
>
>
> On Tue, Sep 24, 2013 at 2:13 PM, Julian Anastasov <ja@ssi.bg> wrote:
>>
>> Hello,
>>
>> On Tue, 24 Sep 2013, Vincent Li wrote:
>>
>>> the current behavior is when an IP is added to an interface, the primary
>>> or secondary attributes is depending on the order of ip added to the interface
>>> the first IP will be primary and second, third,... or alias IP will be secondary
>>> if the IP subnet matches
>>>
>>> this patch add the flexiblity to allow user to specify an argument 'primary' or 'secondary'
>>> (use 'ip addr add ip/mask primary|secondary dev ethX ' from iproute2 for example) to specify
>>> an IP address to be primary or secondary.
>>>
>>> the reason for this patch is that we have a multi blade cluster platform sharing 'floating management ip'
>>> and also that each blade has its own management ip on the management interface, so whichever blade in the
>>> cluster becomes primary blade, the 'floating mangaement ip' follows it, and we want any of our traffic
>>> originated from the primary blade source from the 'floating management ip' for consistency. but in this
>>> case, since the local blade management ip is always the primary ip on the mangaement interface and 'floating
>>> management ip' is always secondary, kernel always choose the primary ip as source ip address. thus we would
>>> like to add the flexibility in kernel to allow us to specify which ip to be primary or secondary.
>>>
>>> Signed-off-by: Vincent Li <vincent.mc.li@gmail.com>
>>> ---
>>> net/ipv4/devinet.c | 9 +++++++--
>>> 1 file changed, 7 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/net/ipv4/devinet.c b/net/ipv4/devinet.c
>>> index a1b5bcb..bfc702a 100644
>>> --- a/net/ipv4/devinet.c
>>> +++ b/net/ipv4/devinet.c
>>> @@ -440,9 +440,11 @@ static int __inet_insert_ifa(struct in_ifaddr *ifa, struct nlmsghdr *nlh,
>>> return 0;
>>> }
>>>
>>> - ifa->ifa_flags &= ~IFA_F_SECONDARY;
>>> last_primary = &in_dev->ifa_list;
>>>
>>> + if((*last_primary) == NULL)
>>> + ifa->ifa_flags &= ~IFA_F_SECONDARY;
>>> +
>>> for (ifap = &in_dev->ifa_list; (ifa1 = *ifap) != NULL;
>>> ifap = &ifa1->ifa_next) {
>>> if (!(ifa1->ifa_flags & IFA_F_SECONDARY) &&
>>> @@ -458,7 +460,10 @@ static int __inet_insert_ifa(struct in_ifaddr *ifa, struct nlmsghdr *nlh,
>>> inet_free_ifa(ifa);
>>> return -EINVAL;
>>> }
>>> - ifa->ifa_flags |= IFA_F_SECONDARY;
>>
>> There is some confusion here, when ifa has
>> IFA_F_SECONDARY bit set, in the 'else' we set it again.
>> I guess the 'else' part is not needed.
>>
>>> + if (!(ifa->ifa_flags & IFA_F_SECONDARY))
>>> + ifa1->ifa_flags |= IFA_F_SECONDARY;
>>> + else
>>> + ifa->ifa_flags |= IFA_F_SECONDARY;
>>
>> It should not be so simple. You can not
>> just change the flag of existing address (ifa1) to secondary.
>> See __inet_del_ifa(), there are many more actions that
>> follow:
>>
>> - kernel routes that use this primary address
>> should be deleted and recreated with the new primary
>> address as source. This includes local routes to secondary
>> IPs.
>>
>> - RTM_NEWADDR should be sent, so that user space see
>> the IFA_F_SECONDARY flag
>>
>> Some questions:
>>
>> - should we allow adding of secondary IPs when no primary
>> address exists for the subnet, it can happen when primary
>> for another subnet already exists
>>
>> - by default, existing 'ip addr' binaries will provide
>> address without IFA_F_SECONDARY flag. Before now we added
>> such addresses as last for the subnet, now the
>> behaviour changes, we start to add addresses in reverse
>> order. Is that true? I.e. before now the operation was
>> APPEND, now we need a way to provide PREPEND operation.
>>
>> Regards
>>
>> --
>> Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [PATCH 02/10] intel: Remove extern from function prototypes
From: Jeff Kirsher @ 2013-09-24 22:07 UTC (permalink / raw)
To: Joe Perches
Cc: Don, e1000-devel, netdev, Bruce Allan, Brandeburg, John Ronciak,
David S. Miller, linux-kernel, Jesse
In-Reply-To: <5ccc921af41a862fe969809228f029035f851502.1380056108.git.joe@perches.com>
[-- Attachment #1.1: Type: text/plain, Size: 596 bytes --]
On Tue, 2013-09-24 at 14:09 -0700, Joe Perches wrote:
> There are a mix of function prototypes with and without extern
> in the kernel sources. Standardize on not using extern for
> function prototypes.
>
> Function prototypes don't need to be written with extern.
> extern is assumed by the compiler. Its use is as unnecessary as
> using auto to declare automatic/local variables in a block.
So you are able to confirm that all compilers make this assumption
correctly? The initial reason for using extern was because not all
compilers made the assumption or made it correctly.
[-- Attachment #1.2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
[-- Attachment #2: Type: text/plain, Size: 416 bytes --]
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: [PATCH 1/2 v2] net: Add function to get SW rxhash
From: Tom Herbert @ 2013-09-24 22:16 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, Linux Netdev List
In-Reply-To: <1380058203.3165.121.camel@edumazet-glaptop>
On Tue, Sep 24, 2013 at 2:30 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> On Tue, 2013-09-24 at 13:42 -0700, Tom Herbert wrote:
>> Some uses of skb_get_rxhash expect that the function will return
>> a consistent value whether it is called on RX or TX paths. On RX
>> path, we will use the rxhash if provided by the NIC, so this
>> would not normally be the same result computed in TX path would be
>> a software calculation.
>>
>> This patch adds skb_get_sw_rxhash to explicitly request a hash
>> calculated by the stack, disregarding the hash provided by NIC.
>
> As I said, I think this is overhead in network fast path.
>
The overhead is setting one in additional bit in skb_get_rxhash.
Alternatively, we could just take out the symmetric hashing code in
get_rps_code which is two or three conditionals and have tun do its
own hash as you mention. Since skb_get_rxhash tries to use HW value
anyway, it's pretty non deterministic as to how often we'd set the
symmetric hash, much less be able advantage of the symmetric property.
If it's a big win for conntrack to process packets on same CPUs for
both directions, we should program the RFS table to accomplish that.
> This can be done without adding a new skb field.
>
> I suspect tun should not use rxhash but a proper hash, as conntrack or
> tcp...
>
>
>
^ permalink raw reply
* Re: [PATCH 02/10] intel: Remove extern from function prototypes
From: Ben Hutchings @ 2013-09-24 22:16 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Joe Perches, netdev, David S. Miller, Jesse Brandeburg,
Bruce Allan, Carolyn Wyborny, Don Skidmore, Greg Rose,
Peter P Waskiewicz Jr, Alex Duyck, John Ronciak, Tushar Dave,
e1000-devel, linux-kernel
In-Reply-To: <1380060449.2189.6.camel@jtkirshe-mobl>
On Tue, 2013-09-24 at 15:07 -0700, Jeff Kirsher wrote:
> On Tue, 2013-09-24 at 14:09 -0700, Joe Perches wrote:
> > There are a mix of function prototypes with and without extern
> > in the kernel sources. Standardize on not using extern for
> > function prototypes.
> >
> > Function prototypes don't need to be written with extern.
> > extern is assumed by the compiler. Its use is as unnecessary as
> > using auto to declare automatic/local variables in a block.
>
> So you are able to confirm that all compilers make this assumption
> correctly? The initial reason for using extern was because not all
> compilers made the assumption or made it correctly.
You are probably thinking of global variables, where declarations
without either 'extern' or an initialiser might or might not be treated
as 'common'. On function declarations, 'extern' really is redundant.
Ben.
--
Ben Hutchings, Staff Engineer, Solarflare
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH 02/10] intel: Remove extern from function prototypes
From: Joe Perches @ 2013-09-24 22:22 UTC (permalink / raw)
To: Jeff Kirsher
Cc: Don, e1000-devel, netdev, Bruce Allan, Brandeburg, John Ronciak,
David S. Miller, linux-kernel, Jesse
In-Reply-To: <1380060449.2189.6.camel@jtkirshe-mobl>
On Tue, 2013-09-24 at 15:07 -0700, Jeff Kirsher wrote:
> On Tue, 2013-09-24 at 14:09 -0700, Joe Perches wrote:
> > There are a mix of function prototypes with and without extern
> > in the kernel sources. Standardize on not using extern for
> > function prototypes.
> >
> > Function prototypes don't need to be written with extern.
> > extern is assumed by the compiler. Its use is as unnecessary as
> > using auto to declare automatic/local variables in a block.
>
> So you are able to confirm that all compilers make this assumption
> correctly? The initial reason for using extern was because not all
> compilers made the assumption or made it correctly.
No, I didn't bother.
Any current compilers already do make this assumption
valid as it's been part of the c spec since 1989 and
prototypes without extern already are the predominate
form in .h files for linux kernel sources.
Even in drivers/net/ethernet/intel/... there are more
prototypes without extern than with extern.
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Cannot re-enable 'auto' for IPv6 link local?
From: Ben Greear @ 2013-09-24 22:54 UTC (permalink / raw)
To: netdev
At one time, I'm fairly certain this worked, but not having much
luck in a hacked 3.9.11+ kernel:
The goal is to enable the link-local address to be auto-configured.
At start of this, there is no /proc/sys/net/ipv6/config/eth30 dir
because all IPv6 addrs were removed (I suppose).
# ./local/sbin/ip -6 addr add 2345::18 dev eth30
# echo 1 > /proc/sys/net/ipv6/conf/eth30/autoconf
# cat /proc/sys/net/ipv6/conf/eth30/autoconf
1
# ./local/sbin/ip -6 addr del 2345::18 dev eth30
# cat /proc/sys/net/ipv6/conf/eth30/autoconf
cat: /proc/sys/net/ipv6/conf/eth30/autoconf: No such file or directory
What is the proper way to turn on ipv6 auto configuration?
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: Cannot re-enable 'auto' for IPv6 link local?
From: Hannes Frederic Sowa @ 2013-09-24 22:57 UTC (permalink / raw)
To: Ben Greear; +Cc: netdev
In-Reply-To: <5242181A.6090300@candelatech.com>
On Tue, Sep 24, 2013 at 03:54:18PM -0700, Ben Greear wrote:
> At one time, I'm fairly certain this worked, but not having much
> luck in a hacked 3.9.11+ kernel:
>
> The goal is to enable the link-local address to be auto-configured.
> At start of this, there is no /proc/sys/net/ipv6/config/eth30 dir
> because all IPv6 addrs were removed (I suppose).
>
> # ./local/sbin/ip -6 addr add 2345::18 dev eth30
> # echo 1 > /proc/sys/net/ipv6/conf/eth30/autoconf
> # cat /proc/sys/net/ipv6/conf/eth30/autoconf
> 1
> # ./local/sbin/ip -6 addr del 2345::18 dev eth30
> # cat /proc/sys/net/ipv6/conf/eth30/autoconf
> cat: /proc/sys/net/ipv6/conf/eth30/autoconf: No such file or directory
>
>
> What is the proper way to turn on ipv6 auto configuration?
This issue is fixed by commit 876fd05ddbae03166e7037fca957b55bb3be6594 ("ipv6:
don't disable interface if last ipv6 address is removed").
Greetings,
Hannes
^ permalink raw reply
* Re: Cannot re-enable 'auto' for IPv6 link local?
From: Ben Greear @ 2013-09-24 23:04 UTC (permalink / raw)
To: netdev
In-Reply-To: <20130924225700.GC4446@order.stressinduktion.org>
On 09/24/2013 03:57 PM, Hannes Frederic Sowa wrote:
> On Tue, Sep 24, 2013 at 03:54:18PM -0700, Ben Greear wrote:
>> At one time, I'm fairly certain this worked, but not having much
>> luck in a hacked 3.9.11+ kernel:
>>
>> The goal is to enable the link-local address to be auto-configured.
>> At start of this, there is no /proc/sys/net/ipv6/config/eth30 dir
>> because all IPv6 addrs were removed (I suppose).
>>
>> # ./local/sbin/ip -6 addr add 2345::18 dev eth30
>> # echo 1 > /proc/sys/net/ipv6/conf/eth30/autoconf
>> # cat /proc/sys/net/ipv6/conf/eth30/autoconf
>> 1
>> # ./local/sbin/ip -6 addr del 2345::18 dev eth30
>> # cat /proc/sys/net/ipv6/conf/eth30/autoconf
>> cat: /proc/sys/net/ipv6/conf/eth30/autoconf: No such file or directory
>>
>>
>> What is the proper way to turn on ipv6 auto configuration?
>
> This issue is fixed by commit 876fd05ddbae03166e7037fca957b55bb3be6594 ("ipv6:
> don't disable interface if last ipv6 address is removed").
>
> Greetings,
>
> Hannes
>
Thanks!
I'll add that to my 3.9 kernel.
A secondary problem in my case is that the NIC and/or fibre cable
has issues and it had just lost link and I did not notice
right away...
Thanks,
Ben
--
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc http://www.candelatech.com
^ permalink raw reply
* Re: [PATCH] net: net_secret should not depend on TCP
From: Hannes Frederic Sowa @ 2013-09-24 23:51 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Tom Herbert, davem, netdev, jesse.brandeburg
In-Reply-To: <1380028797.3165.65.camel@edumazet-glaptop>
On Tue, Sep 24, 2013 at 06:19:57AM -0700, Eric Dumazet wrote:
> From: Eric Dumazet <edumazet@google.com>
>
> A host might need net_secret[] and never open a single socket.
>
> Problem added in commit aebda156a570782
> ("net: defer net_secret[] initialization")
>
> Based on prior patch from Hannes Frederic Sowa.
>
> Reported-by: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
FWIW, I reviewed that the loop indeed cannot block and gave the patch a
quick test drive. Also, the ipv6_hash_secret is only used by the ehash
functions. So this is a superior patch than mine:
Acked-by: Hannes Frederic Sowa <hannes@strressinduktion.org>
Thanks, Eric!
^ permalink raw reply
* Re: linux-next: manual merge of the ipsec-next tree with the net-next tree
From: Stephen Rothwell @ 2013-09-24 23:59 UTC (permalink / raw)
To: Steffen Klassert
Cc: linux-next, linux-kernel, Fan Du, Joe Perches, David Miller,
netdev
In-Reply-To: <20130924102505.GS7660@secunet.com>
[-- Attachment #1: Type: text/plain, Size: 829 bytes --]
Hi Steffen,
On Tue, 24 Sep 2013 12:25:05 +0200 Steffen Klassert <steffen.klassert@secunet.com> wrote:
>
> On Tue, Sep 24, 2013 at 12:16:29PM +1000, Stephen Rothwell wrote:
> >
> > Today's linux-next merge of the ipsec-next tree got a conflict in
> > include/net/xfrm.h between commit d511337a1eda ("xfrm.h: Remove extern
> > from function prototypes") from the net-next tree and commit aba826958830
> > ("{ipv4,xfrm}: Introduce xfrm_tunnel_notifier for xfrm tunnel mode
> > callback") from the ipsec-next tree.
>
> Thanks for the information, I'll do a rebase of the ipsec-next
> tree tomorrow.
Did you miss the end of the next paragraph: "no action is required"?
Dave can fix this up (like I did) when he merges your tree into his.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2 v2] net: Add function to get SW rxhash
From: Eric Dumazet @ 2013-09-25 0:17 UTC (permalink / raw)
To: Tom Herbert; +Cc: David Miller, Linux Netdev List
In-Reply-To: <CA+mtBx94yRWRNkfcbkOmFhMcspdyb-Q=jn0=dkAVTZrj-XFCDQ@mail.gmail.com>
On Tue, 2013-09-24 at 15:16 -0700, Tom Herbert wrote:
> If it's a big win for conntrack to process packets on same CPUs for
> both directions, we should program the RFS table to accomplish that.
conntrack uses no userland code, no user thread, so what are you going
to put in RFS table ?
Right now, RPS can be used for proper steering, you only have to
"ethtool -K eth{x} rxhash off"
[ Of course, this is becoming less a concern with multiqueue nics ]
^ permalink raw reply
* nftables-dports
From: Anand Raj Manickam @ 2013-09-25 0:18 UTC (permalink / raw)
To: netdev
How do i add a multiport rule
nft add rule ip filter output tcp dports 99,200 ip daddr 1.1.1.1
counter meta oif eth0 fails.
I see that the range works,
nft add rule ip filter output tcp dport 99-105 ip daddr 1.1.1.1
counter meta oif eth0
^ permalink raw reply
* Re: [PATCH] ipvs: improved SH fallback strategy
From: Simon Horman @ 2013-09-25 0:30 UTC (permalink / raw)
To: Alexander Frolkin
Cc: Sergei Shtylyov, Julian Anastasov, lvs-devel, Wensong Zhang,
netdev, linux-kernel
In-Reply-To: <20130924093238.GD18494@eldamar.org.uk>
On Tue, Sep 24, 2013 at 10:32:38AM +0100, Alexander Frolkin wrote:
> Improve the SH fallback realserver selection strategy.
>
> With sh and sh-fallback, if a realserver is down, this attempts to
> distribute the traffic that would have gone to that server evenly
> among the remaining servers.
>
> Signed-off-by: Alexander Frolkin <avf@eldamar.org.uk>
Hi Alexander,
could you add some comments to the code or at least a description of the
algorithm to the above the function. The intent of original code may not
have been obvious to the eye but this version certainly isn't obvious to
mine.
> --
> diff --git a/net/netfilter/ipvs/ip_vs_sh.c b/net/netfilter/ipvs/ip_vs_sh.c
> index 3588fae..0db7d01 100644
> --- a/net/netfilter/ipvs/ip_vs_sh.c
> +++ b/net/netfilter/ipvs/ip_vs_sh.c
> @@ -120,22 +120,33 @@ static inline struct ip_vs_dest *
> ip_vs_sh_get_fallback(struct ip_vs_service *svc, struct ip_vs_sh_state *s,
> const union nf_inet_addr *addr, __be16 port)
> {
> - unsigned int offset;
> - unsigned int hash;
> + unsigned int offset, roffset;
> + unsigned int hash, ihash;
> struct ip_vs_dest *dest;
>
> - for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
> - hash = ip_vs_sh_hashkey(svc->af, addr, port, offset);
> - dest = rcu_dereference(s->buckets[hash].dest);
> - if (!dest)
> - break;
> - if (is_unavailable(dest))
> - IP_VS_DBG_BUF(6, "SH: selected unavailable server "
> - "%s:%d (offset %d)",
> + ihash = ip_vs_sh_hashkey(svc->af, addr, port, 0);
> + dest = rcu_dereference(s->buckets[ihash].dest);
> + if (!dest)
> + return NULL;
> + if (is_unavailable(dest)) {
> + IP_VS_DBG_BUF(6, "SH: selected unavailable server "
> + "%s:%d, reselecting",
> + IP_VS_DBG_ADDR(svc->af, &dest->addr),
> + ntohs(dest->port));
> + for (offset = 0; offset < IP_VS_SH_TAB_SIZE; offset++) {
> + roffset = (offset + ihash) % IP_VS_SH_TAB_SIZE;
> + hash = ip_vs_sh_hashkey(svc->af, addr, port, roffset);
> + dest = rcu_dereference(s->buckets[hash].dest);
> + if (is_unavailable(dest))
> + IP_VS_DBG_BUF(6, "SH: selected unavailable "
> + "server %s:%d (offset %d), reselecting",
> IP_VS_DBG_ADDR(svc->af, &dest->addr),
> - ntohs(dest->port), offset);
> - else
> - return dest;
> + ntohs(dest->port), roffset);
> + else
> + return dest;
> + }
> + } else {
> + return dest;
> }
>
> return NULL;
>
> --
> To unsubscribe from this list: send the line "unsubscribe lvs-devel" 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 02/10] intel: Remove extern from function prototypes
From: David Miller @ 2013-09-25 1:34 UTC (permalink / raw)
To: bhutchings
Cc: jeffrey.t.kirsher, joe, netdev, jesse.brandeburg, bruce.w.allan,
carolyn.wyborny, donald.c.skidmore, gregory.v.rose,
peter.p.waskiewicz.jr, alexander.h.duyck, john.ronciak,
tushar.n.dave, e1000-devel, linux-kernel
In-Reply-To: <1380061012.2736.57.camel@bwh-desktop.uk.level5networks.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Tue, 24 Sep 2013 23:16:52 +0100
> On Tue, 2013-09-24 at 15:07 -0700, Jeff Kirsher wrote:
>> On Tue, 2013-09-24 at 14:09 -0700, Joe Perches wrote:
>> > There are a mix of function prototypes with and without extern
>> > in the kernel sources. Standardize on not using extern for
>> > function prototypes.
>> >
>> > Function prototypes don't need to be written with extern.
>> > extern is assumed by the compiler. Its use is as unnecessary as
>> > using auto to declare automatic/local variables in a block.
>>
>> So you are able to confirm that all compilers make this assumption
>> correctly? The initial reason for using extern was because not all
>> compilers made the assumption or made it correctly.
>
> You are probably thinking of global variables, where declarations
> without either 'extern' or an initialiser might or might not be treated
> as 'common'. On function declarations, 'extern' really is redundant.
Furthermore, these networking headers include existing generic kernel
headers which already have removed the 'extern' from function
declarations in certain cases.
So I don't think there isn't an issue, and if there is it has existed
already for some time. :-)
^ permalink raw reply
* [PATCH tip/core/rcu 03/13] bridge: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: Stephen Hemminger, tglx, laijs, edumazet, peterz, fweisbec,
bridge, josh, rostedt, David S. Miller, dhowells, sbw, niv,
netdev, mathieu.desnoyers, dipankar, darren, akpm,
Paul E. McKenney, mingo
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the uses in
br_multicast_del_pg() and br_multicast_new_port_group() are legitimate:
They is assigning a pointer to an element from an RCU-protected list,
and all elements of this list are already visible to caller.
This commit therefore silences these false positives by laundering the
pointers using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: bridge@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
---
net/bridge/br_multicast.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/bridge/br_multicast.c b/net/bridge/br_multicast.c
index d1c5786..314c81c 100644
--- a/net/bridge/br_multicast.c
+++ b/net/bridge/br_multicast.c
@@ -267,7 +267,7 @@ static void br_multicast_del_pg(struct net_bridge *br,
if (p != pg)
continue;
- rcu_assign_pointer(*pp, p->next);
+ rcu_assign_pointer(*pp, rcu_access_pointer(p->next));
hlist_del_init(&p->mglist);
del_timer(&p->timer);
call_rcu_bh(&p->rcu, br_multicast_free_pg);
@@ -646,7 +646,7 @@ struct net_bridge_port_group *br_multicast_new_port_group(
p->addr = *group;
p->port = port;
p->state = state;
- rcu_assign_pointer(p->next, next);
+ rcu_assign_pointer(p->next, rcu_access_pointer(next));
hlist_add_head(&p->mglist, &port->mglist);
setup_timer(&p->timer, br_multicast_port_group_expired,
(unsigned long)p);
--
1.8.1.5
^ permalink raw reply related
* [PATCH tip/core/rcu 04/13] wireless: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: Stephen Hemminger, tglx, laijs, edumazet, peterz, fweisbec,
bridge, josh, rostedt, David S. Miller, dhowells, sbw, niv,
netdev, mathieu.desnoyers, dipankar, darren, akpm,
Paul E. McKenney, mingo
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the uses in
cfg80211_combine_bsses() and cfg80211_bss_update() are legitimate:
They is assigning a pointer to an element from an RCU-protected list,
and all elements of this list are already visible to caller.
This commit therefore silences these false positives by laundering the
pointers using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: bridge@lists.linux-foundation.org
Cc: netdev@vger.kernel.org
---
net/wireless/scan.c | 14 +++++++-------
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/net/wireless/scan.c b/net/wireless/scan.c
index eeb7148..edde117 100644
--- a/net/wireless/scan.c
+++ b/net/wireless/scan.c
@@ -671,7 +671,7 @@ static bool cfg80211_combine_bsses(struct cfg80211_registered_device *dev,
bss->pub.hidden_beacon_bss = &new->pub;
new->refcount += bss->refcount;
rcu_assign_pointer(bss->pub.beacon_ies,
- new->pub.beacon_ies);
+ rcu_access_pointer(new->pub.beacon_ies));
}
return true;
@@ -706,10 +706,10 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
old = rcu_access_pointer(found->pub.proberesp_ies);
rcu_assign_pointer(found->pub.proberesp_ies,
- tmp->pub.proberesp_ies);
+ rcu_access_pointer(tmp->pub.proberesp_ies));
/* Override possible earlier Beacon frame IEs */
rcu_assign_pointer(found->pub.ies,
- tmp->pub.proberesp_ies);
+ rcu_access_pointer(tmp->pub.proberesp_ies));
if (old)
kfree_rcu((struct cfg80211_bss_ies *)old,
rcu_head);
@@ -740,12 +740,12 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
old = rcu_access_pointer(found->pub.beacon_ies);
rcu_assign_pointer(found->pub.beacon_ies,
- tmp->pub.beacon_ies);
+ rcu_access_pointer(tmp->pub.beacon_ies));
/* Override IEs if they were from a beacon before */
if (old == rcu_access_pointer(found->pub.ies))
rcu_assign_pointer(found->pub.ies,
- tmp->pub.beacon_ies);
+ rcu_access_pointer(tmp->pub.beacon_ies));
/* Assign beacon IEs to all sub entries */
list_for_each_entry(bss, &found->hidden_list,
@@ -756,7 +756,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
WARN_ON(ies != old);
rcu_assign_pointer(bss->pub.beacon_ies,
- tmp->pub.beacon_ies);
+ rcu_access_pointer(tmp->pub.beacon_ies));
}
if (old)
@@ -804,7 +804,7 @@ cfg80211_bss_update(struct cfg80211_registered_device *dev,
&hidden->hidden_list);
hidden->refcount++;
rcu_assign_pointer(new->pub.beacon_ies,
- hidden->pub.beacon_ies);
+ rcu_access_pointer(hidden->pub.beacon_ies));
}
} else {
/*
--
1.8.1.5
^ permalink raw reply related
* [PATCH tip/core/rcu 05/13] decnet: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, laijs, dipankar, akpm, mathieu.desnoyers, josh, niv, tglx,
peterz, rostedt, dhowells, edumazet, darren, fweisbec, sbw,
Paul E. McKenney, David S. Miller, Thomas Graf, Gao feng,
Stephen Hemminger, linux-decnet-user, netdev
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the use in
dn_insert_route() is legitimate: It is assigning a pointer to an element
from an RCU-protected list, and all elements of this list are already
visible to caller.
This commit therefore silences this false positive by laundering the
pointer using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Thomas Graf <tgraf@suug.ch>
Cc: Gao feng <gaofeng@cn.fujitsu.com>
Cc: Stephen Hemminger <shemminger@vyatta.com>
Cc: linux-decnet-user@lists.sourceforge.net
Cc: netdev@vger.kernel.org
---
net/decnet/dn_route.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/decnet/dn_route.c b/net/decnet/dn_route.c
index fe32388..3b1357b 100644
--- a/net/decnet/dn_route.c
+++ b/net/decnet/dn_route.c
@@ -345,7 +345,7 @@ static int dn_insert_route(struct dn_route *rt, unsigned int hash, struct dn_rou
/* Put it first */
*rthp = rth->dst.dn_next;
rcu_assign_pointer(rth->dst.dn_next,
- dn_rt_hash_table[hash].chain);
+ rcu_access_pointer(dn_rt_hash_table[hash].chain));
rcu_assign_pointer(dn_rt_hash_table[hash].chain, rth);
dst_use(&rth->dst, now);
@@ -358,7 +358,8 @@ static int dn_insert_route(struct dn_route *rt, unsigned int hash, struct dn_rou
rthp = &rth->dst.dn_next;
}
- rcu_assign_pointer(rt->dst.dn_next, dn_rt_hash_table[hash].chain);
+ rcu_assign_pointer(rt->dst.dn_next,
+ rcu_access_pointer(dn_rt_hash_table[hash].chain));
rcu_assign_pointer(dn_rt_hash_table[hash].chain, rt);
dst_use(&rt->dst, now);
--
1.8.1.5
^ permalink raw reply related
* [PATCH tip/core/rcu 06/13] ipv4/ip_socketglue: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, laijs, dipankar, akpm, mathieu.desnoyers, josh, niv, tglx,
peterz, rostedt, dhowells, edumazet, darren, fweisbec, sbw,
Paul E. McKenney, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the use in
ip_ra_control() is legitimate: It is assigning a pointer to an element
from an RCU-protected list, and all elements of this list are already
visible to caller.
This commit therefore silences this false positive by laundering the
pointer using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
---
net/ipv4/ip_sockglue.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv4/ip_sockglue.c b/net/ipv4/ip_sockglue.c
index d9c4f11..d328f15 100644
--- a/net/ipv4/ip_sockglue.c
+++ b/net/ipv4/ip_sockglue.c
@@ -269,7 +269,7 @@ int ip_ra_control(struct sock *sk, unsigned char on,
}
/* dont let ip_call_ra_chain() use sk again */
ra->sk = NULL;
- rcu_assign_pointer(*rap, ra->next);
+ rcu_assign_pointer(*rap, rcu_access_pointer(ra->next));
spin_unlock_bh(&ip_ra_lock);
if (ra->destructor)
--
1.8.1.5
^ permalink raw reply related
* [PATCH tip/core/rcu 08/13] ipv6/ip6_gre: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, laijs, dipankar, akpm, mathieu.desnoyers, josh, niv, tglx,
peterz, rostedt, dhowells, edumazet, darren, fweisbec, sbw,
Paul E. McKenney, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the use in
ip6gre_tunnel_unlink() is legitimate: It is assigning a pointer to an
element from an RCU-protected list, and all elements of this list are
already visible to caller.
This commit therefore silences this false positive by laundering the
pointer using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
---
net/ipv6/ip6_gre.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/ip6_gre.c b/net/ipv6/ip6_gre.c
index 6b26e9f..a0b8f40 100644
--- a/net/ipv6/ip6_gre.c
+++ b/net/ipv6/ip6_gre.c
@@ -276,7 +276,7 @@ static void ip6gre_tunnel_unlink(struct ip6gre_net *ign, struct ip6_tnl *t)
(iter = rtnl_dereference(*tp)) != NULL;
tp = &iter->next) {
if (t == iter) {
- rcu_assign_pointer(*tp, t->next);
+ rcu_assign_pointer(*tp, rcu_access_pointer(t->next));
break;
}
}
--
1.8.1.5
^ permalink raw reply related
* [PATCH tip/core/rcu 09/13] ipv6/sit: Apply rcu_access_pointer() to avoid sparse false positive
From: Paul E. McKenney @ 2013-09-25 1:35 UTC (permalink / raw)
To: linux-kernel
Cc: mingo, laijs, dipankar, akpm, mathieu.desnoyers, josh, niv, tglx,
peterz, rostedt, dhowells, edumazet, darren, fweisbec, sbw,
Paul E. McKenney, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, netdev
In-Reply-To: <1380072916-31557-1-git-send-email-paulmck@linux.vnet.ibm.com>
From: "Paul E. McKenney" <paulmck@linux.vnet.ibm.com>
The sparse checking for rcu_assign_pointer() was recently upgraded
to reject non-__kernel address spaces. This also rejects __rcu,
which is almost always the right thing to do. However, the use in
ipip6_tunnel_unlink() is legitimate: It is assigning a pointer to an
element from an RCU-protected list, and all elements of this list are
already visible to caller.
This commit therefore silences this false positive by laundering the
pointer using rcu_access_pointer() as suggested by Josh Triplett.
Reported-by: kbuild test robot <fengguang.wu@intel.com>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Cc: "David S. Miller" <davem@davemloft.net>
Cc: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
Cc: James Morris <jmorris@namei.org>
Cc: Hideaki YOSHIFUJI <yoshfuji@linux-ipv6.org>
Cc: Patrick McHardy <kaber@trash.net>
Cc: netdev@vger.kernel.org
---
net/ipv6/sit.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/net/ipv6/sit.c b/net/ipv6/sit.c
index 7ee5cb9..fcb050a 100644
--- a/net/ipv6/sit.c
+++ b/net/ipv6/sit.c
@@ -157,7 +157,7 @@ static void ipip6_tunnel_unlink(struct sit_net *sitn, struct ip_tunnel *t)
(iter = rtnl_dereference(*tp)) != NULL;
tp = &iter->next) {
if (t == iter) {
- rcu_assign_pointer(*tp, t->next);
+ rcu_assign_pointer(*tp, rcu_access_pointer(t->next));
break;
}
}
--
1.8.1.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox