* Re: [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Eric Dumazet @ 2012-11-26 2:55 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50B2D42A.6090804@asianux.com>
On Mon, 2012-11-26 at 10:30 +0800, Chen Gang wrote:
> maybe a hacker can do ? (I just guess).
>
> for my experience:
> It is necessary to think of more coding ways, when we have to give comments inside a function.
I have absolutely no idea of what you are trying to say.
^ permalink raw reply
* Re: [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Chen Gang @ 2012-11-26 2:30 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353896372.30446.866.camel@edumazet-glaptop>
于 2012年11月26日 10:19, Eric Dumazet 写道:
> On Mon, 2012-11-26 at 09:34 +0800, Chen Gang wrote:
>
>> if "pimre%u" (or another format), will not hurt the functional features, I suggest to use it
>> since, we need try our best to not touch the OS API.
>> ("pimreg%u" seems an internal format, not OS API Level)
>
> Have you taken a look at user code base before suggesting such a
> change ?
maybe a hacker can do ? (I just guess).
for my experience:
It is necessary to think of more coding ways, when we have to give comments inside a function.
>
> My patch is the safest change: Just make sure machine doesnt crash if
> user ask stupid things.
>
> No possible regression.
>
>
>
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Eric Dumazet @ 2012-11-26 2:19 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50B2C72F.9000100@asianux.com>
On Mon, 2012-11-26 at 09:34 +0800, Chen Gang wrote:
> if "pimre%u" (or another format), will not hurt the functional features, I suggest to use it
> since, we need try our best to not touch the OS API.
> ("pimreg%u" seems an internal format, not OS API Level)
Have you taken a look at user code base before suggesting such a
change ?
My patch is the safest change: Just make sure machine doesnt crash if
user ask stupid things.
No possible regression.
^ permalink raw reply
* Re: [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Chen Gang @ 2012-11-26 1:34 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <50B2C470.5090802@asianux.com>
于 2012年11月26日 09:22, Chen Gang 写道:
> 于 2012年11月26日 03:44, Eric Dumazet 写道:
>> From: Eric Dumazet <edumazet@google.com>
>>
>> Name of pimreg devices are built from following format :
>>
>> char name[IFNAMSIZ]; // IFNAMSIZ == 16
>>
>> sprintf(name, "pimreg%u", mrt->id);
>>
>> We must therefore limit mrt->id to 9 decimal digits
>> or risk a buffer overflow and a crash.
>>
>> Restrict table identifiers in [0 ... 999999999] interval.
>>
if "pimre%u" (or another format), will not hurt the functional features, I suggest to use it
since, we need try our best to not touch the OS API.
("pimreg%u" seems an internal format, not OS API Level)
>
> if we have to stick to "pimreg%u" (or will hurt the functional features)
> suggest to let user mode know this limitation.
> define a macro in public header (user mode can know it) and give comments.
> use macro instead of number.
> remove the comments which is inside internal function.
>
> thanks.
>
> gchen.
>
>
>> Reported-by: Chen Gang <gang.chen@asianux.com>
>> Signed-off-by: Eric Dumazet <edumazet@google.com>
>> ---
>> net/ipv4/ipmr.c | 4 ++++
>> 1 file changed, 4 insertions(+)
>>
>> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
>> index 6168c4d..3eab2b2 100644
>> --- a/net/ipv4/ipmr.c
>> +++ b/net/ipv4/ipmr.c
>> @@ -1318,6 +1318,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
>> if (get_user(v, (u32 __user *)optval))
>> return -EFAULT;
>>
>> + /* "pimreg%u" should not exceed 16 bytes (IFNAMSIZ) */
>> + if (v != RT_TABLE_DEFAULT && v >= 1000000000)
>> + return -EINVAL;
>> +
>> rtnl_lock();
>> ret = 0;
>> if (sk == rtnl_dereference(mrt->mroute_sk)) {
>>
>>
>>
>>
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Chen Gang @ 2012-11-26 1:22 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David Miller, netdev
In-Reply-To: <1353872669.30446.863.camel@edumazet-glaptop>
于 2012年11月26日 03:44, Eric Dumazet 写道:
> From: Eric Dumazet <edumazet@google.com>
>
> Name of pimreg devices are built from following format :
>
> char name[IFNAMSIZ]; // IFNAMSIZ == 16
>
> sprintf(name, "pimreg%u", mrt->id);
>
> We must therefore limit mrt->id to 9 decimal digits
> or risk a buffer overflow and a crash.
>
> Restrict table identifiers in [0 ... 999999999] interval.
>
if we have to stick to "pimreg%u" (or will hurt the functional features)
suggest to let user mode know this limitation.
define a macro in public header (user mode can know it) and give comments.
use macro instead of number.
remove the comments which is inside internal function.
thanks.
gchen.
> Reported-by: Chen Gang <gang.chen@asianux.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
> net/ipv4/ipmr.c | 4 ++++
> 1 file changed, 4 insertions(+)
>
> diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
> index 6168c4d..3eab2b2 100644
> --- a/net/ipv4/ipmr.c
> +++ b/net/ipv4/ipmr.c
> @@ -1318,6 +1318,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
> if (get_user(v, (u32 __user *)optval))
> return -EFAULT;
>
> + /* "pimreg%u" should not exceed 16 bytes (IFNAMSIZ) */
> + if (v != RT_TABLE_DEFAULT && v >= 1000000000)
> + return -EINVAL;
> +
> rtnl_lock();
> ret = 0;
> if (sk == rtnl_dereference(mrt->mroute_sk)) {
>
>
>
>
--
Chen Gang
Asianux Corporation
^ permalink raw reply
* Re: [PATCH] atm: br2684: Fix excessive queue bloat
From: Krzysztof Mazur @ 2012-11-25 23:52 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, John Crispin, Dave Täht, Chas Williams (CONTRACTOR)
In-Reply-To: <1353880892.26346.300.camel@shinybook.infradead.org>
On Sun, Nov 25, 2012 at 10:01:32PM +0000, David Woodhouse wrote:
>
> Yeah. This is fairly much the same conversation I ended up having when I
> did the same for PPPoATM.
>
> Some day *perhaps* we might look at doing something adaptive, so it'll
> detect a TX underrun and increase the amount of buffering. But this
> seems perfectly good for now.
The biggest problem is the existence of additional, mostly unnecessary
huge software queue that we have between us and the hardware on "ATM sockets".
Most of ATM drivers have some hardware queue, but accept and queue
additional frames in software and it just adds unnecessary delay
- it's much better to queue those frames in netdev queue. With this patch
we limit this queue by limiting the number of frames in this queue and
hardware queue to 2 frames, but the hardware may require larger *hardware*
queue to saturate the link. If we had only the hardware queue, the queue
would be probably sized adequately in ATM driver or could be tuned by user.
I think that the 2 frame queue is much better than the huge queue,
that we have now.
>
> > Maybe this magic "2" and the comment should be moved to some #define.
>
> Doesn't make it any less magic. I'm happier with it as it is, with a
> clear comment describing why it's done that way.
>
In PPPoATM we have NONE_INFLIGHT.
Krzysiek
^ permalink raw reply
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: Francois Romieu @ 2012-11-25 22:43 UTC (permalink / raw)
To: David Woodhouse; +Cc: netdev, jasowang, gilboad, jgarzik
In-Reply-To: <1353799650.26346.289.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> :
> On Sat, 2012-11-24 at 23:58 +0100, Francois Romieu wrote:
> > While you are at it, do you see what would prevent the watchdog
> > timer and the rx napi handler to race on two different CPUs
>
> Hm, good point. Is it sufficient just to stick napi_disable() and
> napi_enable() in there?
No, napi_disable() may sleep.
> And should we try to reset the TX state machine without stomping on
> RX at all ?
Either that or the watchdog timer will have to queue some user context
work. Things may change later when you go lockless (hint, hint).
--
Ueimor
^ permalink raw reply
* [PATCH v2] atm: br2684: Fix excessive queue bloat
From: David Woodhouse @ 2012-11-25 22:06 UTC (permalink / raw)
To: netdev, John Crispin, Dave Täht, Chas Williams (CONTRACTOR)
[-- Attachment #1: Type: text/plain, Size: 5330 bytes --]
There's really no excuse for an additional wmem_default of buffering
between the netdev queue and the ATM device. Two packets (one in-flight,
and one ready to send) ought to be fine. It's not as if it should take
long to get another from the netdev queue when we need it.
If necessary we can make the queue space configurable later, but I don't
think it's likely to be necessary.
cf. commit 9d02daf754238adac48fa075ee79e7edd3d79ed3 (pppoatm: Fix
excessive queue bloat) which did something very similar for PPPoATM.
Note that there is a tremendously unlikely race condition which may
result in qspace temporarily going negative. If a CPU running the
br2684_pop() function goes off into the weeds for a long period of time
after incrementing qspace to 1, but before calling netdev_wake_queue()...
and another CPU ends up calling br2684_start_xmit() and *stopping* the
queue again before the first CPU comes back, the netdev queue could
end up being woken when qspace has already reached zero.
An alternative approach to coping with this race would be to check in
br2684_start_xmit() for qspace==0 and return NETDEV_TX_BUSY, but just
using '> 0' and '< 1' for comparison instead of '== 0' and '!= 0' is
simpler. It just warranted a mention of *why* we do it that way...
Move the call to atmvcc->send() to happen *after* the accounting and
potentially stopping the netdev queue, in br2684_xmit_vcc(). This matters
if the ->send() call suffers an immediate failure, because it'll call
br2684_pop() with the offending skb before returning. We want that to
happen *after* we've done the initial accounting for the packet in
question. Also make it return an appropriate success/failure indication
while we're at it.
Tested by running 'ping -l 1000 bottomless.aaisp.net.uk' from within my
network, with only a single PPPoE-over-BR2684 link running. And after
setting txqueuelen on the nas0 interface to something low (5, in fact).
Before the patch, we'd see about 15 packets being queued and a resulting
latency of ~56ms being reached. After the patch, we see only about 8,
which is fairly much what we expect. And a max latency of ~36ms. On this
OpenWRT box, wmem_default is 163840.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Reviewed-by: Krzysztof Mazur <krzysiek@podlesie.net>
---
[v2: Comment format fixed]
net/atm/br2684.c | 36 ++++++++++++++++++++++--------------
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 4819d315..8eb6fbe 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -74,6 +74,7 @@ struct br2684_vcc {
struct br2684_filter filter;
#endif /* CONFIG_ATM_BR2684_IPFILTER */
unsigned int copies_needed, copies_failed;
+ atomic_t qspace;
};
struct br2684_dev {
@@ -181,18 +182,15 @@ static struct notifier_block atm_dev_notifier = {
static void br2684_pop(struct atm_vcc *vcc, struct sk_buff *skb)
{
struct br2684_vcc *brvcc = BR2684_VCC(vcc);
- struct net_device *net_dev = skb->dev;
- pr_debug("(vcc %p ; net_dev %p )\n", vcc, net_dev);
+ pr_debug("(vcc %p ; net_dev %p )\n", vcc, brvcc->device);
brvcc->old_pop(vcc, skb);
- if (!net_dev)
- return;
-
- if (atm_may_send(vcc, 0))
- netif_wake_queue(net_dev);
-
+ /* If the queue space just went up from zero, wake */
+ if (atomic_inc_return(&brvcc->qspace) == 1)
+ netif_wake_queue(brvcc->device);
}
+
/*
* Send a packet out a particular vcc. Not to useful right now, but paves
* the way for multiple vcc's per itf. Returns true if we can send,
@@ -256,16 +254,19 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
ATM_SKB(skb)->atm_options = atmvcc->atm_options;
dev->stats.tx_packets++;
dev->stats.tx_bytes += skb->len;
- atmvcc->send(atmvcc, skb);
- if (!atm_may_send(atmvcc, 0)) {
+ if (atomic_dec_return(&brvcc->qspace) < 1) {
+ /* No more please! */
netif_stop_queue(brvcc->device);
- /*check for race with br2684_pop*/
- if (atm_may_send(atmvcc, 0))
- netif_start_queue(brvcc->device);
+ /* We might have raced with br2684_pop() */
+ if (unlikely(atomic_read(&brvcc->qspace) > 0))
+ netif_wake_queue(brvcc->device);
}
- return 1;
+ /* If this fails immediately, the skb will be freed and br2684_pop()
+ will wake the queue if appropriate. Just return an error so that
+ the stats are updated correctly */
+ return !atmvcc->send(atmvcc, skb);
}
static inline struct br2684_vcc *pick_outgoing_vcc(const struct sk_buff *skb,
@@ -504,6 +505,13 @@ static int br2684_regvcc(struct atm_vcc *atmvcc, void __user * arg)
brvcc = kzalloc(sizeof(struct br2684_vcc), GFP_KERNEL);
if (!brvcc)
return -ENOMEM;
+ /*
+ * Allow two packets in the ATM queue. One actually being sent, and one
+ * for the ATM 'TX done' handler to send. It shouldn't take long to get
+ * the next one from the netdev queue, when we need it. More than that
+ * would be bufferbloat.
+ */
+ atomic_set(&brvcc->qspace, 2);
write_lock_irq(&devs_lock);
net_dev = br2684_find_dev(&be.ifspec);
if (net_dev == NULL) {
--
1.8.0
--
David Woodhouse Open Source Technology Centre
David.Woodhouse@intel.com Intel Corporation
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* Re: [PATCH] atm: br2684: Fix excessive queue bloat
From: David Woodhouse @ 2012-11-25 22:01 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: netdev, John Crispin, Dave Täht, Chas Williams (CONTRACTOR)
In-Reply-To: <20121125214332.GA2722@shrek.podlesie.net>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Sun, 2012-11-25 at 22:43 +0100, Krzysztof Mazur wrote:
> On Sat, Nov 24, 2012 at 12:01:32AM +0000, David Woodhouse wrote:
> > There's really no excuse for an additional wmem_default of buffering
> > between the netdev queue and the ATM device. Two packets (one in-flight,
> > and one ready to send) ought to be fine. It's not as if it should take
> > long to get another from the netdev queue when we need it.
> >
> > If necessary we can make the queue space configurable later, but I don't
> > think it's likely to be necessary.
>
> Maybe some high-speed devices will require larger queue, especially for
> smaller packets, but 2 packet queue should be sufficient in almost all cases.
Yeah. This is fairly much the same conversation I ended up having when I
did the same for PPPoATM.
Some day *perhaps* we might look at doing something adaptive, so it'll
detect a TX underrun and increase the amount of buffering. But this
seems perfectly good for now.
> Maybe this magic "2" and the comment should be moved to some #define.
Doesn't make it any less magic. I'm happier with it as it is, with a
clear comment describing why it's done that way.
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH] atm: br2684: Fix excessive queue bloat
From: Krzysztof Mazur @ 2012-11-25 21:43 UTC (permalink / raw)
To: David Woodhouse
Cc: netdev, John Crispin, Dave Täht, Chas Williams (CONTRACTOR)
In-Reply-To: <1353715292.26346.237.camel@shinybook.infradead.org>
On Sat, Nov 24, 2012 at 12:01:32AM +0000, David Woodhouse wrote:
> There's really no excuse for an additional wmem_default of buffering
> between the netdev queue and the ATM device. Two packets (one in-flight,
> and one ready to send) ought to be fine. It's not as if it should take
> long to get another from the netdev queue when we need it.
>
> If necessary we can make the queue space configurable later, but I don't
> think it's likely to be necessary.
Maybe some high-speed devices will require larger queue, especially for
smaller packets, but 2 packet queue should be sufficient in almost all cases.
> static inline struct br2684_vcc *pick_outgoing_vcc(const struct sk_buff *skb,
> @@ -504,6 +505,11 @@ static int br2684_regvcc(struct atm_vcc *atmvcc, void __user * arg)
> brvcc = kzalloc(sizeof(struct br2684_vcc), GFP_KERNEL);
> if (!brvcc)
> return -ENOMEM;
> + /* Allow two packets in the ATM queue. One actually being sent, and one
> + for the ATM 'TX done' handler to send. It shouldn't take long to get
> + the next one from the netdev queue, when we need it. More than that
> + would be bufferbloat. */
> + atomic_set(&brvcc->qspace, 2);
Maybe this magic "2" and the comment should be moved to some #define.
> write_lock_irq(&devs_lock);
> net_dev = br2684_find_dev(&be.ifspec);
> if (net_dev == NULL) {
Looks good,
Reviewed-by: Krzysztof Mazur <krzysiek@podlesie.net>
Krzysiek
^ permalink raw reply
* Re: [PATCH] ipv4/ipmr and ipv6/ip6mr: Convert int mroute_do_<foo> to bool
From: David Miller @ 2012-11-25 21:40 UTC (permalink / raw)
To: joe; +Cc: eric.dumazet, netdev
In-Reply-To: <1353872130.6558.17.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sun, 25 Nov 2012 11:35:30 -0800
> Save a few bytes per table by convert mroute_do_assert and
> mroute_do_pim from int to bool.
>
> Remove !! as the compiler does that when assigning int to bool.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next] ipv4: ipmr: various fixes and cleanups
From: David Miller @ 2012-11-25 21:40 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev
In-Reply-To: <1353861705.30446.675.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Sun, 25 Nov 2012 08:41:45 -0800
> From: Eric Dumazet <edumazet@google.com>
>
> 1) ip_mroute_setsockopt() & ip_mroute_getsockopt() should not
> access/set raw_sk(sk)->ipmr_table before making sure the socket
> is a raw socket, and protocol is IGMP
>
> 2) MRT_INIT should return -EINVAL if optlen != sizeof(int), not
> -ENOPROTOOPT
>
> 3) MRT_ASSERT & MRT_PIM should validate optlen
>
> 4) " (v) ? 1 : 0 " can be written as " !!v "
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH] MAINTAINERS: Add Q: patchwork entries for net/ and drivers/net/
From: David Miller @ 2012-11-25 21:17 UTC (permalink / raw)
To: joe; +Cc: netdev
In-Reply-To: <1353791905.6558.7.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 24 Nov 2012 13:18:25 -0800
> Add the netdev patchwork entries for networking drivers.
> Change the W: entry to Q:for networking.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] smsc: Add logging message newlines
From: David Miller @ 2012-11-25 21:15 UTC (permalink / raw)
To: joe; +Cc: steve.glendinning, gregkh, netdev, linux-usb, linux-kernel
In-Reply-To: <1353756469.6558.3.camel@joe-AO722>
From: Joe Perches <joe@perches.com>
Date: Sat, 24 Nov 2012 03:27:49 -0800
> Avoid any possible message logging interleaving by adding
> missing newlines.
>
> Align arguments.
>
> Signed-off-by: Joe Perches <joe@perches.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] qlcnic: fix sparse check endian warnings
From: David Miller @ 2012-11-25 21:14 UTC (permalink / raw)
To: sony.chacko; +Cc: netdev, Dept_NX_Linux_NIC_Driver, shahed.shaikh
In-Reply-To: <1353751012-28431-2-git-send-email-sony.chacko@qlogic.com>
From: Sony Chacko <sony.chacko@qlogic.com>
Date: Sat, 24 Nov 2012 04:56:52 -0500
> From: Shahed Shaikh <shahed.shaikh@qlogic.com>
>
> Signed-off-by: Shahed Shaikh <shahed.shaikh@qlogic.com>
> Signed-off-by: Sony Chacko <sony.chacko@qlogic.com>
Applied to net-next.
^ permalink raw reply
* Re: [PATCH V2 resend] net: dsa/slave: Fix compilation warnings
From: David Miller @ 2012-11-25 21:12 UTC (permalink / raw)
To: viresh.kumar; +Cc: bhutchings, akpm, netdev, linaro-dev, linux-kernel, patches
In-Reply-To: <ecc711bf44722707f57188ee953bbde2f1e20c8c.1353736229.git.viresh.kumar@linaro.org>
From: Viresh Kumar <viresh.kumar@linaro.org>
Date: Sat, 24 Nov 2012 11:23:54 +0530
> Currently when none of CONFIG_NET_DSA_TAG_DSA, CONFIG_NET_DSA_TAG_EDSA and
> CONFIG_NET_DSA_TAG_TRAILER is defined, we get following compilation warnings:
>
> net/dsa/slave.c:51:12: warning: 'dsa_slave_init' defined but not used [-Wunused-function]
> net/dsa/slave.c:60:12: warning: 'dsa_slave_open' defined but not used [-Wunused-function]
> net/dsa/slave.c:98:12: warning: 'dsa_slave_close' defined but not used [-Wunused-function]
> net/dsa/slave.c:116:13: warning: 'dsa_slave_change_rx_flags' defined but not used [-Wunused-function]
> net/dsa/slave.c:127:13: warning: 'dsa_slave_set_rx_mode' defined but not used [-Wunused-function]
> net/dsa/slave.c:136:12: warning: 'dsa_slave_set_mac_address' defined but not used [-Wunused-function]
> net/dsa/slave.c:164:12: warning: 'dsa_slave_ioctl' defined but not used [-Wunused-function]
>
> Earlier approach to fix this was discussed here:
>
> lkml.org/lkml/2012/10/29/549
>
> This is another approach to fix it. This is done by some changes in config
> options, which make more sense than the earlier approach. As, atleast one
> tagging option must always be selected for using net/dsa/ infrastructure, this
> patch selects NET_DSA from tagging configs instead of having it as an selectable
> config.
>
> Signed-off-by: Viresh Kumar <viresh.kumar@linaro.org>
Applied to net-next, thanks.
^ permalink raw reply
* Re: [PATCH] atm: br2684: Fix excessive queue bloat
From: David Miller @ 2012-11-25 21:09 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, blogic, dave.taht, krzysiek, chas
In-Reply-To: <1353715292.26346.237.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Sat, 24 Nov 2012 00:01:32 +0000
> + /* Allow two packets in the ATM queue. One actually being sent, and one
> + for the ATM 'TX done' handler to send. It shouldn't take long to get
> + the next one from the netdev queue, when we need it. More than that
> + would be bufferbloat. */
Please format this:
/* Like
* this.
*/
and I'll apply this, thanks.
^ permalink raw reply
* Re: [PATCH] net: sched: enable CAN Identifier to be build into kernel
From: David Miller @ 2012-11-25 21:06 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <1353667497-25676-1-git-send-email-mkl@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Fri, 23 Nov 2012 11:44:57 +0100
> This patch makes it possible to build the CAN Identifier into the kernel, even
> if the CAN support is build as a module.
>
> Signed-off-by: Marc Kleine-Budde <mkl@pengutronix.de>
Applied to net-next, thanks.
> is there a nicer solution to this problem? Or remove the "&& CAN" at all?
I don't see how enabling this with CAN disabled could be
useful, so better to have the dependency there.
^ permalink raw reply
* Re: [PATCH] bonding: in balance-rr mode, set curr_active_slave only if it is up
From: David Miller @ 2012-11-25 21:03 UTC (permalink / raw)
To: mkubecek; +Cc: netdev, fubar, andy, linux-kernel
In-Reply-To: <20121122125202.14252C35B8@unicorn.suse.cz>
From: Michal Kubecek <mkubecek@suse.cz>
Date: Thu, 22 Nov 2012 13:48:39 +0100
> If all slaves of a balance-rr bond with ARP monitor are enslaved
> with down link state, bond keeps down state even after slaves
> go up.
>
> This is caused by bond_enslave() setting curr_active_slave to
> first slave not taking into account its link state. As
> bond_loadbalance_arp_mon() uses curr_active_slave to identify
> whether slave's down->up transition should update bond's link
> state, bond stays down even if slaves are up (until first slave
> goes from up to down at least once).
>
> Before commit f31c7937 "bonding: start slaves with link down for
> ARP monitor", this was masked by slaves always starting in UP
> state with ARP monitor (and MII monitor not relying on
> curr_active_slave being NULL if there is no slave up).
>
> Signed-off-by: Michal Kubecek <mkubecek@suse.cz>
Jay/Andy please review.
^ permalink raw reply
* Re: [PATCH] sctp: fix -ENOMEM result with invalid user space pointer in sendto() syscall
From: David Miller @ 2012-11-25 21:03 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590596-12216-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:23:16 +0200
> Consider the following program, that sets the second argument to the
> sendto() syscall incorrectly:
...
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
This also looks good, Vlad please review this.
Thanks.
^ permalink raw reply
* Re: [PATCH] sctp: fix memory leak in sctp_datamsg_from_user() when copy from user space fails
From: David Miller @ 2012-11-25 21:01 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1353590491-12166-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Thu, 22 Nov 2012 15:21:31 +0200
> Trinity (the syscall fuzzer) discovered a memory leak in SCTP,
> reproducible e.g. with the sendto() syscall by passing invalid
> user space pointer in the second argument:
...
> As far as I can tell, the leak has been around since ~2003.
>
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Looks good to me, Vlad please review.
^ permalink raw reply
* Re: [PATCH] 8139cp: re-enable interrupts after tx timeout
From: David Miller @ 2012-11-25 20:57 UTC (permalink / raw)
To: romieu; +Cc: dwmw2, netdev, jasowang, gilboad, jgarzik
In-Reply-To: <20121124225855.GA17340@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Sat, 24 Nov 2012 23:58:55 +0100
> David Woodhouse <dwmw2@infradead.org> :
>> Recovery doesn't work too well if we leave interrupts disabled...
>>
>> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied to net-next
^ permalink raw reply
* Re: [PATCH] 8139cp: enable bql
From: David Miller @ 2012-11-25 20:55 UTC (permalink / raw)
To: dwmw2; +Cc: netdev, codel
In-Reply-To: <1353590218.26346.214.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Thu, 22 Nov 2012 13:16:58 +0000
> This adds support for byte queue limits on RTL8139C+
>
> Tested on real hardware.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
> Acked-By: Dave Täht <dave.taht@bufferbloat.net>
Applied to net-next.
> --- drivers/net/ethernet/realtek/8139cp.c~ 2012-11-21 20:49:47.000000000 +0000
> +++ drivers/net/ethernet/realtek/8139cp.c 2012-11-22 13:07:26.119076315 +0000
Please "-p1" root your patches in the future.
^ permalink raw reply
* Re: [PATCH] 8139cp: set ring address after enabling C+ mode
From: David Miller @ 2012-11-25 20:54 UTC (permalink / raw)
To: dwmw2; +Cc: jgarzik, jasowang, netdev
In-Reply-To: <1353529639.26346.164.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 21 Nov 2012 20:27:19 +0000
> This fixes (for me) a regression introduced by commit b01af457 ("8139cp:
> set ring address before enabling receiver"). That commit configured the
> descriptor ring addresses earlier in the initialisation sequence, in
> order to avoid the possibility of triggering stray DMA before the
> correct address had been set up.
>
> Unfortunately, it seems that the hardware will scribble garbage into the
> TxRingAddr registers when we enable "plus mode" Tx in the CpCmd
> register. Observed on a Traverse Geos router board.
>
> To deal with this, while not reintroducing the problem which led to the
> original commit, we augment cp_start_hw() to write to the CpCmd register
> *first*, then set the descriptor ring addresses, and then finally to
> enable Rx and Tx in the original 8139 Cmd register. The datasheet
> actually indicates that we should enable Tx/Rx in the Cmd register
> *before* configuring the descriptor addresses, but that would appear to
> re-introduce the problem that the offending commit b01af457 was trying
> to solve. And this variant appears to work fine on real hardware.
>
> Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
Applied to net-next.
^ permalink raw reply
* [PATCH] net: ipmr: limit MRT_TABLE identifiers
From: Eric Dumazet @ 2012-11-25 19:44 UTC (permalink / raw)
To: Chen Gang; +Cc: David Miller, netdev
In-Reply-To: <50AC9CF6.2020501@asianux.com>
From: Eric Dumazet <edumazet@google.com>
Name of pimreg devices are built from following format :
char name[IFNAMSIZ]; // IFNAMSIZ == 16
sprintf(name, "pimreg%u", mrt->id);
We must therefore limit mrt->id to 9 decimal digits
or risk a buffer overflow and a crash.
Restrict table identifiers in [0 ... 999999999] interval.
Reported-by: Chen Gang <gang.chen@asianux.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/ipv4/ipmr.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/net/ipv4/ipmr.c b/net/ipv4/ipmr.c
index 6168c4d..3eab2b2 100644
--- a/net/ipv4/ipmr.c
+++ b/net/ipv4/ipmr.c
@@ -1318,6 +1318,10 @@ int ip_mroute_setsockopt(struct sock *sk, int optname, char __user *optval, unsi
if (get_user(v, (u32 __user *)optval))
return -EFAULT;
+ /* "pimreg%u" should not exceed 16 bytes (IFNAMSIZ) */
+ if (v != RT_TABLE_DEFAULT && v >= 1000000000)
+ return -EINVAL;
+
rtnl_lock();
ret = 0;
if (sk == rtnl_dereference(mrt->mroute_sk)) {
^ 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