* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Julian Anastasov @ 2013-10-17 19:52 UTC (permalink / raw)
To: Kristian Evensen; +Cc: netdev
In-Reply-To: <1382028894-14236-1-git-send-email-kristian.evensen@gmail.com>
Hello,
On Thu, 17 Oct 2013, Kristian Evensen wrote:
> From: Kristian Evensen <kristian.evensen@gmail.com>
>
> When a link is set as down using for example "ip link set dev X down", routes
> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
> removed, and makes rtnelink route deletion behavior consistent across commands.
> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
> include required information otherwise unavailable in trie_flush_list().
>
> One use case that is simplified by this patch is IPv4 WAN connection monitoring.
> Instead of listening for and handling both RTM_*ROUTE and RTM_*LINK-messages, it
> is sufficient to handle RTM_*ROUTE.
IIRC, such notifications were not implemented
to avoid storms to routing daemons. Not sure if this is
still true.
Regards
--
Julian Anastasov <ja@ssi.bg>
^ permalink raw reply
* Re: [patch] yam: integer underflow in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014121931.GI6247@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:28:38 +0300
> We cap bitrate at YAM_MAXBITRATE in yam_ioctl(), but it could also be
> negative. I don't know the impact of using a negative bitrate but let's
> prevent it.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [patch] yam: remove a no-op in yam_ioctl()
From: David Miller @ 2013-10-17 19:54 UTC (permalink / raw)
To: dan.carpenter; +Cc: jpr, linux-hams, netdev, kernel-janitors
In-Reply-To: <20131014123726.GA17034@mwanda>
From: Dan Carpenter <dan.carpenter@oracle.com>
Date: Mon, 14 Oct 2013 15:46:15 +0300
> We overwrite the ->bitrate with the user supplied information on the
> next line.
>
> Signed-off-by: Dan Carpenter <dan.carpenter@oracle.com>
Applied.
^ permalink raw reply
* Re: [PATCH net V2 1/2] virtio-net: don't respond to cpu hotplug notifier if we're not ready
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: mst, netdev, linux-kernel, virtualization
In-Reply-To: <1381807139-3450-1-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:58 +0800
> We're trying to re-configure the affinity unconditionally in cpu hotplug
> callback. This may lead the issue during resuming from s3/s4 since
>
> - virt queues haven't been allocated at that time.
> - it's unnecessary since thaw method will re-configure the affinity.
>
> Fix this issue by checking the config_enable and do nothing is we're not ready.
>
> The bug were introduced by commit 8de4b2f3ae90c8fc0f17eeaab87d5a951b66ee17
> (virtio-net: reset virtqueue affinity when doing cpu hotplug).
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Cc: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Acked-by: Michael S. Tsirkin <mst@redhat.com>
> Reviewed-by: Wanlong Gao <gaowanlong@cn.fujitsu.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH net V2 2/2] virtio-net: refill only when device is up during setting queues
From: David Miller @ 2013-10-17 19:55 UTC (permalink / raw)
To: jasowang; +Cc: netdev, virtualization, linux-kernel, mst
In-Reply-To: <1381807139-3450-2-git-send-email-jasowang@redhat.com>
From: Jason Wang <jasowang@redhat.com>
Date: Tue, 15 Oct 2013 11:18:59 +0800
> We used to schedule the refill work unconditionally after changing the
> number of queues. This may lead an issue if the device is not
> up. Since we only try to cancel the work in ndo_stop(), this may cause
> the refill work still work after removing the device. Fix this by only
> schedule the work when device is up.
>
> The bug were introduce by commit 9b9cd8024a2882e896c65222aa421d461354e3f2.
> (virtio-net: fix the race between channels setting and refill)
>
> Cc: Rusty Russell <rusty@rustcorp.com.au>
> Cc: Michael S. Tsirkin <mst@redhat.com>
> Signed-off-by: Jason Wang <jasowang@redhat.com>
Applied and queued up for -stable, thanks Jason.
^ permalink raw reply
* Re: [PATCH -next] netdev: inet_timewait_sock.h missing semi-colon when KMEMCHECK is enabled
From: David Miller @ 2013-10-17 19:57 UTC (permalink / raw)
To: rdunlap; +Cc: thierry.reding, linux-next, linux-kernel, broonie, netdev
In-Reply-To: <525C47C0.2000907@infradead.org>
From: Randy Dunlap <rdunlap@infradead.org>
Date: Mon, 14 Oct 2013 12:36:32 -0700
> From: Randy Dunlap <rdunlap@infradead.org>
>
> Fix (a few hundred) build errors due to missing semi-colon when
> KMEMCHECK is enabled:
>
> include/net/inet_timewait_sock.h:139:2: error: expected ',', ';' or '}' before 'int'
> include/net/inet_timewait_sock.h:148:28: error: 'const struct inet_timewait_sock' has no member named 'tw_death_node'
>
> Signed-off-by: Randy Dunlap <rdunlap@infradead.org>
Applied, thanks Randy.
^ permalink raw reply
* Re: [net-next REPOST] 8390 ei_debug : Reenable the use of debugging in 8390 based chips
From: David Miller @ 2013-10-17 19:59 UTC (permalink / raw)
To: tedheadster; +Cc: netdev
In-Reply-To: <1381805161-18833-1-git-send-email-tedheadster@gmail.com>
From: Matthew Whitehead <tedheadster@gmail.com>
Date: Mon, 14 Oct 2013 22:46:01 -0400
> Ethernet boards based on the 8390 chip had an '#ifdef notdef' disabling the
> use of the debug variable ei_debug. Reenable it for those of us who still
> occasionally use it.
>
> Also handle the case of the 'ne' driver which uses 8390p.o rather than
> 8390.o. In that case ei_debug is aliased to eip_debug so it doesn't clash
> with the previously exported ei_debug.
>
> Signed-off-by: Matthew Whitehead <tedheadster@gmail.com>
I'd rather not encourage the use of things like this.
We have a standard, run time, way to enable and disable debugging
output on a per-netdevice basis. And the "default" value of which can
be controlled by a module parameter if need be.
Please convert the driver to this method instead.
Thank you.
^ permalink raw reply
* Re: [PATCH] net: qmi_wwan: Olivetti Olicard 200 support
From: David Miller @ 2013-10-17 20:01 UTC (permalink / raw)
To: mrkiko.rs
Cc: gregkh, bjorn, dcbw, christian.schmiedl, linux-usb, netdev,
linux-kernel, anto.pellizzari83
In-Reply-To: <1381842408-10800-2-git-send-email-mrkiko.rs@gmail.com>
From: Enrico Mioso <mrkiko.rs@gmail.com>
Date: Tue, 15 Oct 2013 15:06:48 +0200
> This is a QMI device, manufactured by TCT Mobile Phones.
> A companion patch blacklisting this device's QMI interface in the option.c
> driver has been sent.
>
> Signed-off-by: Enrico Mioso <mrkiko.rs@gmail.com>
> Signed-off-by: Antonella Pellizzari <anto.pellizzari83@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] X.25: Fix address field length calculation
From: David Miller @ 2013-10-17 20:04 UTC (permalink / raw)
To: GKelleter; +Cc: andrew.hendry, linux-x25, netdev, linux-kernel
In-Reply-To: <525D5131.9070007@datus.com>
From: Kelleter, Günther <GKelleter@datus.com>
Date: Tue, 15 Oct 2013 14:29:06 +0000
> Addresses are BCD encoded, not ASCII. x25_addr_ntoa got it right.
>
> Signed-off-by: Guenther Kelleter <gkelleter@datus.com>
> ---
> Wrong length calculation leads to rejection of CALL ACCEPT packets.
This patch doesn't apply because it was severely corrupted by your
email client, turn off all encodings etc. in your client, send
a test patch to yourself, and do not submit this patch again until
you can successfully apply the patch you receive in those test emails.
Thanks.
^ permalink raw reply
* Re: pull request: wireless 2013-10-15
From: David Miller @ 2013-10-17 20:06 UTC (permalink / raw)
To: linville-2XuSBdqkA4R54TAoqtyWWQ
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20131015175611.GA15706-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
From: "John W. Linville" <linville-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Date: Tue, 15 Oct 2013 13:56:12 -0400
> Please pull this batch of fixes intended for the 3.12 stream!
>
> For the mac80211 bits, Johannes says:
>
> "Jouni fixes a remain-on-channel vs. scan bug, and Felix fixes client TX
> probing on VLANs."
>
> And also:
>
> "This time I have two fixes from Emmanuel for RF-kill issues, and fixed
> two issues reported by Evan Huus and Thomas Lindroth respectively."
>
> On top of those...
>
> Avinash Patil adds a couple of mwifiex fixes to properly inform cfg80211
> about some different types of disconnects, avoiding WARNINGs.
>
> Mark Cave-Ayland corrects a pointer arithmetic problem in rtlwifi,
> avoiding incorrect automatic gain calculations.
>
> Solomon Peachy sends a cw1200 fix for locking around calls to
> cw1200_irq_handler, addressing "lost interrupt" problems.
>
> Please let me know if there are problems!
Pulled, thanks a lot John.
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" 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
* Re: [PATCH 1/2] tcp: must unclone packets before mangling them
From: David Miller @ 2013-10-17 20:08 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381863270.2045.62.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 11:54:30 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> TCP stack should make sure it owns skbs before mangling them.
>
> We had various crashes using bnx2x, and it turned out gso_size
> was cleared right before bnx2x driver was populating TC descriptor
> of the _previous_ packet send. TCP stack can sometime retransmit
> packets that are still in Qdisc.
>
> Of course we could make bnx2x driver more robust (using
> ACCESS_ONCE(shinfo->gso_size) for example), but the bug is TCP stack.
>
> We have identified two points where skb_unclone() was needed.
>
> This patch adds a WARN_ON_ONCE() to warn us if we missed another
> fix of this kind.
>
> Kudos to Neal for finding the root cause of this bug. Its visible
> using small MSS.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Cc: Yuchung Cheng <ycheng@google.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [PATCH 2/2] tcp: remove the sk_can_gso() check from tcp_set_skb_tso_segs()
From: David Miller @ 2013-10-17 20:09 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, ncardwell, ycheng
In-Reply-To: <1381865094.2045.69.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 15 Oct 2013 12:24:54 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> sk_can_gso() should only be used as a hint in tcp_sendmsg() to build GSO
> packets in the first place. (As a performance hint)
>
> Once we have GSO packets in write queue, we can not decide they are no
> longer GSO only because flow now uses a route which doesn't handle
> TSO/GSO.
>
> Core networking stack handles the case very well for us, all we need
> is keeping track of packet counts in MSS terms, regardless of
> segmentation done later (in GSO or hardware)
>
> Right now, if tcp_fragment() splits a GSO packet in two parts,
> @left and @right, and route changed through a non GSO device,
> both @left and @right have pcount set to 1, which is wrong,
> and leads to incorrect packet_count tracking.
>
> This problem was added in commit d5ac99a648 ("[TCP]: skb pcount with MTU
> discovery")
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Signed-off-by: Neal Cardwell <ncardwell@google.com>
> Signed-off-by: Yuchung Cheng <ycheng@google.com>
Also applied and queued up for -stable, thanks everyone.
^ permalink raw reply
* Re: [PATCH] net bridge: remove unused field
From: David Miller @ 2013-10-17 20:10 UTC (permalink / raw)
To: jhs; +Cc: shemminger, netdev
In-Reply-To: <525C5DED.1080406@mojatatu.com>
From: Jamal Hadi Salim <jhs@mojatatu.com>
Date: Mon, 14 Oct 2013 17:11:09 -0400
> Trivial patch
I know it seems rediculous, but anything we export to userspace, as we
do in this UAPI header, could be potentially be used by some piece of
source out there.
I'd rather just leave it be, you can add a comment saying it's unused
if you wish, but I'd really rather not remove it and run the risk of
breaking someone's build out there.
Thanks.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: shrink rt_cache_stat
From: David Miller @ 2013-10-17 20:11 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1381916944.2045.124.camel@edumazet-glaptop.roam.corp.google.com>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Wed, 16 Oct 2013 02:49:04 -0700
> From: Eric Dumazet <edumazet@google.com>
>
> Half of the rt_cache_stat fields are no longer used after IP
> route cache removal, lets shrink this per cpu area.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Looks good, applied, thanks Eric.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Kristian Evensen @ 2013-10-17 20:11 UTC (permalink / raw)
To: Julian Anastasov; +Cc: Network Development
In-Reply-To: <alpine.LFD.2.03.1310172245440.2016@ssi.bg>
Hi,
On Thu, Oct 17, 2013 at 9:52 PM, Julian Anastasov <ja@ssi.bg> wrote:
> IIRC, such notifications were not implemented
> to avoid storms to routing daemons. Not sure if this is
> still true.
Thanks for letting me know. I was wondering if this was the case, but
then I saw that the deletion of IPv6 routes are announced (when
running "ip link set dev X down") and assumed that message storms was
(is?) not considered a problem.
-Kristian
^ permalink raw reply
* Re: [PATCH] bridge: Correctly clamp MAX forward_delay when enabling STP
From: David Miller @ 2013-10-17 20:12 UTC (permalink / raw)
To: herbert; +Cc: vyasevic, netdev, shemminger
In-Reply-To: <20131016005657.GA5394@gondor.apana.org.au>
From: Herbert Xu <herbert@gondor.apana.org.au>
Date: Wed, 16 Oct 2013 08:56:57 +0800
> On Tue, Oct 15, 2013 at 02:57:45PM -0400, Vlad Yasevich wrote:
>> Commit be4f154d5ef0ca147ab6bcd38857a774133f5450
>> bridge: Clamp forward_delay when enabling STP
>> had a typo when attempting to clamp maximum forward delay.
>>
>> It is possible to set bridge_forward_delay to be higher then
>> permitted maximum when STP is off. When turning STP on, the
>> higher then allowed delay has to be clamed down to max value.
>>
>> CC: Herbert Xu <herbert@gondor.apana.org.au>
>> CC: Stephen Hemminger <shemminger@vyatta.com>
>> Signed-off-by: Vlad Yasevich <vyasevic@redhat.com>
>
> Good catch!
>
> Acked-by: Herbert Xu <herbert@gondor.apana.org.au>
Applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: Kristian Evensen @ 2013-10-17 20:14 UTC (permalink / raw)
To: Joe Perches; +Cc: Network Development
In-Reply-To: <1382030610.22110.112.camel@joe-AO722>
Hi,
On Thu, Oct 17, 2013 at 7:23 PM, Joe Perches <joe@perches.com> wrote:
>
> Perhaps this memset should be moved into the
> list_for_each_entry_safe loop where cfg is used.
Thanks for your comment. I decided to put it there to avoid calling it
for each route that will be deleted. Since the struct is never
modified (only read in fib_rtmsg()) and we have the rtnl_lock, I
assumed it to be safe. Are there cases where this assumption is wrong?
-Kristian
^ permalink raw reply
* Re: pull request: wireless-next 2013-10-17
From: David Miller @ 2013-10-17 20:15 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev
In-Reply-To: <20131017182339.GC1812@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Thu, 17 Oct 2013 14:23:40 -0400
> This is a batch of updates intended for the 3.13 stream...
>
> The biggest item of interest in here is wcn36xx, the new mac80211
> driver for Qualcomm WCN3660/WCN3680 hardware.
>
> Regarding the mac80211 bits, Johannes says:
>
> "We have an assortment of cleanups and new features, of which the
> biggest one is probably the channel-switch support in IBSS. Nothing
> else really stands out much."
>
> On top of that, the ath9k and rt2x00 get a lot of update action from
> Felix Fietkau and Gabor Juhos, respectively. There are a handful of
> updates to other drivers here and there as well.
>
> Please let me know if there are problems!
Pulled, thanks John.
^ permalink raw reply
* Re: [PATCH net 2/9] bnx2x: Prevent an illegal pointer dereference during panic
From: David Miller @ 2013-10-17 20:15 UTC (permalink / raw)
To: eilong; +Cc: yuvalmin, netdev, ariele, dmitry
In-Reply-To: <1382035647.20308.3.camel@lb-tlvb-eilong.il.broadcom.com>
From: "Eilon Greenstein" <eilong@broadcom.com>
Date: Thu, 17 Oct 2013 21:47:27 +0300
> I guess we should really re-spin and check for all 1's, or add some more
> code to make it really accurate, or at least fix the ">" to ">=". We
> will send a revised series with a fix.
Thanks Eilon.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: David Miller @ 2013-10-17 20:19 UTC (permalink / raw)
To: ja; +Cc: kristian.evensen, netdev
In-Reply-To: <alpine.LFD.2.03.1310172245440.2016@ssi.bg>
From: Julian Anastasov <ja@ssi.bg>
Date: Thu, 17 Oct 2013 22:52:43 +0300 (EEST)
>
> Hello,
>
> On Thu, 17 Oct 2013, Kristian Evensen wrote:
>
>> From: Kristian Evensen <kristian.evensen@gmail.com>
>>
>> When a link is set as down using for example "ip link set dev X down", routes
>> are deleted, but RTM_DELROUTE messages are not sent to RTNLGRP_IPV4_ROUTE. This
>> patch makes trie_flush_list() send a RTM_DELROUTE for each route that is
>> removed, and makes rtnelink route deletion behavior consistent across commands.
>> The parameter lists for trie_flush_list() and trie_flush_leaf() are expanded to
>> include required information otherwise unavailable in trie_flush_list().
>>
>> One use case that is simplified by this patch is IPv4 WAN connection monitoring.
>> Instead of listening for and handling both RTM_*ROUTE and RTM_*LINK-messages, it
>> is sufficient to handle RTM_*ROUTE.
>
> IIRC, such notifications were not implemented
> to avoid storms to routing daemons. Not sure if this is
> still true.
I'm definitely not applying this patch.
Routing daemons maintain the routing table internally, and they
therefore can purge their internal data structures when the link
down event occurs.
This is how it has worked forever and for real BGP tables the
RTM_DELROUTE traffic would be enormous and at nearly DoS levels
for anyone listening for them.
^ permalink raw reply
* Re: [PATCH net-next] fib_trie: Send RTM_DELROUTE when link goes down
From: David Miller @ 2013-10-17 20:19 UTC (permalink / raw)
To: kristian.evensen; +Cc: ja, netdev
In-Reply-To: <CAKfDRXiM-8dnGqFMofdiaD=EMJNLxzx-yhVManRSiQHgziuVdQ@mail.gmail.com>
From: Kristian Evensen <kristian.evensen@gmail.com>
Date: Thu, 17 Oct 2013 22:11:39 +0200
> On Thu, Oct 17, 2013 at 9:52 PM, Julian Anastasov <ja@ssi.bg> wrote:
>> IIRC, such notifications were not implemented
>> to avoid storms to routing daemons. Not sure if this is
>> still true.
>
> Thanks for letting me know. I was wondering if this was the case, but
> then I saw that the deletion of IPv6 routes are announced (when
> running "ip link set dev X down") and assumed that message storms was
> (is?) not considered a problem.
I really wish IPV6 wouldn't be inconsistent and behave that way.
^ permalink raw reply
* Re: [PATCH v4 net 0/3] sctp: Use software checksum under certain
From: Vlad Yasevich @ 2013-10-17 20:21 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-sctp, fan.du
In-Reply-To: <20131017.152634.216002495730124314.davem@davemloft.net>
On 10/17/2013 03:26 PM, David Miller wrote:
> From: Vlad Yasevich <vyasevich@gmail.com>
> Date: Tue, 15 Oct 2013 22:01:28 -0400
>
>> There are some cards that support SCTP checksum offloading. When using
>> these cards with IPSec or forcing IP fragmentation of SCTP traffic,
>> the checksum is computed incorrectly due to the fact that xfrm and IP/IPv6
>> fragmentation code do not know that this is SCTP traffic and do not
>> know that checksum has to be computed differently.
>>
>> To fix this, we let SCTP detect these conditions and perform software
>> checksum calculation.
>
> Series applied, thanks Vlad.
>
Hi David
Could you please queue this to stable as well.
Thanks
-vlad
^ permalink raw reply
* [PATCH net-next] fib: Use const struct nl_info * in rtmsg_fib
From: Joe Perches @ 2013-10-17 20:34 UTC (permalink / raw)
To: Kristian Evensen; +Cc: Network Development
In-Reply-To: <CAKfDRXjctGkcqSt9cM=iWbckLt4=7n8434WAA8rr4_cEofEO=Q@mail.gmail.com>
The rtmsg_fib function doesn't modify this argument so mark
it const.
Signed-off-by: Joe Perches <joe@perches.com>
---
On Thu, 2013-10-17 at 22:14 +0200, Kristian Evensen wrote:
> Hi,
Hi Kristian.
> On Thu, Oct 17, 2013 at 7:23 PM, Joe Perches <joe@perches.com> wrote:
> >
> > Perhaps this memset should be moved into the
> > list_for_each_entry_safe loop where cfg is used.
>
> Thanks for your comment. I decided to put it there to avoid calling it
> for each route that will be deleted. Since the struct is never
> modified (only read in fib_rtmsg()) and we have the rtnl_lock, I
> assumed it to be safe. Are there cases where this assumption is wrong?
I didn't look too hard.
I just glanced at the prototype and saw it wasn't const.
If rtmsg_fib() doesn't modify cfg (and it doesn't seem to)
then the prototype and function should be marked const.
And you're right, it doesn't need to be inside the loop.
cheers, Joe
net/ipv4/fib_lookup.h | 2 +-
net/ipv4/fib_semantics.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv4/fib_lookup.h b/net/ipv4/fib_lookup.h
index af0f14a..50cfb3e 100644
--- a/net/ipv4/fib_lookup.h
+++ b/net/ipv4/fib_lookup.h
@@ -32,7 +32,7 @@ extern int fib_dump_info(struct sk_buff *skb, u32 pid, u32 seq, int event,
int dst_len, u8 tos, struct fib_info *fi,
unsigned int);
extern void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info,
+ int dst_len, u32 tb_id, const struct nl_info *info,
unsigned int nlm_flags);
extern struct fib_alias *fib_find_alias(struct list_head *fah,
u8 tos, u32 prio);
diff --git a/net/ipv4/fib_semantics.c b/net/ipv4/fib_semantics.c
index d5dbca5..e63f47a 100644
--- a/net/ipv4/fib_semantics.c
+++ b/net/ipv4/fib_semantics.c
@@ -380,7 +380,7 @@ static inline size_t fib_nlmsg_size(struct fib_info *fi)
}
void rtmsg_fib(int event, __be32 key, struct fib_alias *fa,
- int dst_len, u32 tb_id, struct nl_info *info,
+ int dst_len, u32 tb_id, const struct nl_info *info,
unsigned int nlm_flags)
{
struct sk_buff *skb;
^ permalink raw reply related
* [PATCH net] net: unix: inherit SOCK_PASS{CRED,SEC} flags from socket to fix race
From: Daniel Borkmann @ 2013-10-17 20:51 UTC (permalink / raw)
To: davem; +Cc: netdev, Eric Dumazet, Eric W. Biederman
In-Reply-To: <cover.1382042286.git.dborkman@redhat.com>
In the case of credentials passing in unix stream sockets (dgram
sockets seem not affected), we get a rather sparse race after
commit 16e5726 ("af_unix: dont send SCM_CREDENTIALS by default").
We have a stream server on receiver side that requests credential
passing from senders (e.g. nc -U). Since we need to set SO_PASSCRED
on each spawned/accepted socket on server side to 1 first (as it's
not inherited), it can happen that in the time between accept() and
setsockopt() we get interrupted, the sender is being scheduled and
continues with passing data to our receiver. At that time SO_PASSCRED
is neither set on sender nor receiver side, hence in cmsg's
SCM_CREDENTIALS we get eventually pid:0, uid:65534, gid:65534
(== overflow{u,g}id) instead of what we actually would like to see.
On the sender side, here nc -U, the tests in maybe_add_creds()
invoked through unix_stream_sendmsg() would fail, as at that exact
time, as mentioned, the sender has neither SO_PASSCRED on his side
nor sees it on the server side, and we have a valid 'other' socket
in place. Thus, sender believes it would just look like a normal
connection, not needing/requesting SO_PASSCRED at that time.
As reverting 16e5726 would not be an option due to the significant
performance regression reported when having creds always passed,
one way/trade-off to prevent that would be to set SO_PASSCRED on
the listener socket and allow inheriting these flags to the spawned
socket on server side in accept(). It seems also logical to do so
if we'd tell the listener socket to pass those flags onwards, and
would fix the race.
Before, strace:
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS{pid=0, uid=65534, gid=65534}},
msg_flags=0}, 0) = 5
After, strace:
recvmsg(4, {msg_name(0)=NULL, msg_iov(1)=[{"blub\n", 4096}],
msg_controllen=32, {cmsg_len=28, cmsg_level=SOL_SOCKET,
cmsg_type=SCM_CREDENTIALS{pid=11580, uid=1000, gid=1000}},
msg_flags=0}, 0) = 5
Signed-off-by: Daniel Borkmann <dborkman@redhat.com>
Cc: Eric Dumazet <edumazet@google.com>
Cc: Eric W. Biederman <ebiederm@xmission.com>
---
net/unix/af_unix.c | 10 ++++++++++
1 file changed, 10 insertions(+)
diff --git a/net/unix/af_unix.c b/net/unix/af_unix.c
index 86de99a..c1f403b 100644
--- a/net/unix/af_unix.c
+++ b/net/unix/af_unix.c
@@ -1246,6 +1246,15 @@ static int unix_socketpair(struct socket *socka, struct socket *sockb)
return 0;
}
+static void unix_sock_inherit_flags(const struct socket *old,
+ struct socket *new)
+{
+ if (test_bit(SOCK_PASSCRED, &old->flags))
+ set_bit(SOCK_PASSCRED, &new->flags);
+ if (test_bit(SOCK_PASSSEC, &old->flags))
+ set_bit(SOCK_PASSSEC, &new->flags);
+}
+
static int unix_accept(struct socket *sock, struct socket *newsock, int flags)
{
struct sock *sk = sock->sk;
@@ -1280,6 +1289,7 @@ static int unix_accept(struct socket *sock, struct socket *newsock, int flags)
/* attach accepted sock to socket */
unix_state_lock(tsk);
newsock->state = SS_CONNECTED;
+ unix_sock_inherit_flags(sock, newsock);
sock_graft(tsk, newsock);
unix_state_unlock(tsk);
return 0;
--
1.8.3.1
^ permalink raw reply related
* Oficiální vyhlá?ení OZNÁMENÍ
From: undp_chevronpetroleum1 @ 2013-10-17 20:16 UTC (permalink / raw)
Číslo ?ar?e : ( UK- 209-634 , E- 931-51 )
Oficiální vyhlá?ení OZNÁMENÍ
To je Vám oznámit, ?e jste byl vybrán pro peně?ní cenu
1,600,000.00 GB kilo mezinárodních programů uskutečňovaných na 15.října
2013 ve Spojeném království Chevron ropy / OSN o rozvoj
Program ( UNDP) Chcete-li zahájit zpracování va?í cenu jste kontaktovat
va?e nároky důstojník prostřednictvím na?ich akreditovaných agentů Prize Přenos jak je uvedeno
ní?e :
Mr.D. Matt
Organizace spojených národů Komplexní
PE9 2YP , Londýn
Spojené království
E- mail: derickmatt@googlemail.com
Kontaktujte jej , a poskytne mu na tajnou PIN kódu x5pukg2013 a
Va?e referenční číslo pro UNDP : 62082013EA-UK/21 . Také se Vám doporučuje
aby mu na základě uvedených informací, co nejdříve :
NÁROK PO?ADAVEK :
1.Name v plné vý?i : , 2.Address : , 3.Phone/Fax : ,
S pozdravem ,
Mrs.Tulise hnědá
Program Coordinator
POZNÁMKA: Chci, abyste věděli, ?e máme tři ?ťastné výherce v České republice se stalo, ?e jeden z nich
bude i rady, které byste se obrátit na vý?e uvedené tvrzení důstojníka co nejdříve .
^ 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