* Re: [PATCH 4/5] smsc95xx: fix smsc_crc return type
From: Joe Perches @ 2012-11-30 15:59 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev
In-Reply-To: <1354290952-27109-5-git-send-email-steve.glendinning@shawell.net>
On Fri, 2012-11-30 at 15:55 +0000, Steve Glendinning wrote:
> This patch fixes a bug introduced in bbd9f9e which could prevent
> some wakeups from working correctly if multiple wol options were
> selected.
>
> This helper function calculates a 16-bit crc and shifts it into
> either the high or low 16 bits of a u32 so the caller can or it
> directly into place. The function previously had a u16 return
> type so would always have returned zero when filter was odd.
>
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
> Reported-by: Bjorn Mork <bjorn@mork.no>
> Cc: Joe Perches <joe@perches.com>
> ---
> drivers/net/usb/smsc95xx.c | 5 +++--
> 1 file changed, 3 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
> index 064df1a..b9eb490 100644
> --- a/drivers/net/usb/smsc95xx.c
> +++ b/drivers/net/usb/smsc95xx.c
> @@ -1074,9 +1074,10 @@ static void smsc95xx_unbind(struct usbnet *dev, struct usb_interface *intf)
> }
> }
>
> -static u16 smsc_crc(const u8 *buffer, size_t len, int filter)
> +static u32 smsc_crc(const u8 *buffer, size_t len, int filter)
> {
> - return bitrev16(crc16(0xFFFF, buffer, len)) << ((filter % 2) * 16);
> + u32 crc = bitrev16(crc16(0xFFFF, buffer, len));
> + return crc << ((filter % 2) * 16);
> }
>
> static int smsc95xx_enable_phy_wakeup_interrupts(struct usbnet *dev, u16 mask)
Having filter as an argument to this function really
just confuses things.
The shift should be done when the result is or'd onto the
control variable.
^ permalink raw reply
* Re: [PATCH] sctp: verify length provided in heartbeat information parameter
From: Neil Horman @ 2012-11-30 16:01 UTC (permalink / raw)
To: Thomas Graf; +Cc: davem, netdev, linux-sctp
In-Reply-To: <20121130121627.GG30697@casper.infradead.org>
On Fri, Nov 30, 2012 at 12:16:27PM +0000, Thomas Graf wrote:
> If the variable parameter length provided in the mandatory
> heartbeat information parameter exceeds the calculated payload
> length the packet has been corrupted. Reply with a parameter
> length protocol violation message.
>
> Signed-off-by: Thomas Graf <tgraf@suug.ch>
> ---
> net/sctp/sm_statefuns.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/net/sctp/sm_statefuns.c b/net/sctp/sm_statefuns.c
> index b6adef8..e92079d 100644
> --- a/net/sctp/sm_statefuns.c
> +++ b/net/sctp/sm_statefuns.c
> @@ -1055,6 +1055,7 @@ sctp_disposition_t sctp_sf_beat_8_3(struct net *net,
> void *arg,
> sctp_cmd_seq_t *commands)
> {
> + sctp_paramhdr_t *param_hdr;
> struct sctp_chunk *chunk = arg;
> struct sctp_chunk *reply;
> size_t paylen = 0;
> @@ -1072,12 +1073,17 @@ sctp_disposition_t sctp_sf_beat_8_3(struct net *net,
> * Information field copied from the received HEARTBEAT chunk.
> */
> chunk->subh.hb_hdr = (sctp_heartbeathdr_t *) chunk->skb->data;
> + param_hdr = (sctp_paramhdr_t *) chunk->subh.hb_hdr;
> paylen = ntohs(chunk->chunk_hdr->length) - sizeof(sctp_chunkhdr_t);
> +
> + if (ntohs(param_hdr->length) > paylen)
> + return sctp_sf_violation_paramlen(net, ep, asoc, type, arg,
> + param_hdr, commands);
> +
> if (!pskb_pull(chunk->skb, paylen))
> goto nomem;
>
> - reply = sctp_make_heartbeat_ack(asoc, chunk,
> - chunk->subh.hb_hdr, paylen);
> + reply = sctp_make_heartbeat_ack(asoc, chunk, param_hdr, paylen);
> if (!reply)
> goto nomem;
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Looks good, thanks Thomas.
Acked-by: Neil Horman <nhorman@tuxdriver.com>
^ permalink raw reply
* Re: [PATCH 1/5] smsc95xx: fix suspend buffer overflow
From: Joe Perches @ 2012-11-30 16:03 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev, Bjorn Mork
In-Reply-To: <1354290952-27109-2-git-send-email-steve.glendinning@shawell.net>
On Fri, 2012-11-30 at 15:55 +0000, Steve Glendinning wrote:
> This patch fixes a buffer overflow introduced by bbd9f9e, where
> the filter_mask array is accessed beyond its bounds.
[]
> diff --git a/drivers/net/usb/smsc95xx.c b/drivers/net/usb/smsc95xx.c
[]
> @@ -1281,7 +1281,7 @@ static int smsc95xx_suspend(struct usb_interface *intf, pm_message_t message)
> }
>
> if (pdata->wolopts & (WAKE_BCAST | WAKE_MCAST | WAKE_ARP | WAKE_UCAST)) {
> - u32 *filter_mask = kzalloc(32, GFP_KERNEL);
> + u32 *filter_mask = kzalloc(sizeof(u32) * 32, GFP_KERNEL);
Just get rid of the alloc and use 32 u8's on stack.
It's small enough
No filter value is > FF and the compiler with expand
the u8 to u32 when writing to the card.
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: David Woodhouse @ 2012-11-30 16:23 UTC (permalink / raw)
To: Krzysztof Mazur
Cc: Chas Williams (CONTRACTOR), David Laight, davem, netdev,
linux-kernel, nathan
In-Reply-To: <1354277415.21562.284.camel@shinybook.infradead.org>
[-- Attachment #1: Type: text/plain, Size: 5095 bytes --]
On Fri, 2012-11-30 at 12:10 +0000, David Woodhouse wrote:
> In that case I think we're fine. I'll just do the same thing in
> br2684_push(), fix up the comment you just corrected, and we're all
> good.
OK, here's an update to me my patch 8/17 'br2684: don't send frames on
not-ready vcc'. It takes the socket lock and does fairly much the same
thing as your pppoatm version. It returns NETDEV_TX_BUSY and stops the
queue if the socket is locked, and it gets woken from the ->release_cb
callback.
I've dropped your Acked-By: since it's mostly new, but feel free to give
me a fresh one. With this I think we're done.
Unless Chas has any objections, I'll ask Dave to pull it...
From 47d5ad4c98452bcddfd00da1c659dac85202f213 Mon Sep 17 00:00:00 2001
From: David Woodhouse <dwmw2@infradead.org>
Date: Tue, 27 Nov 2012 23:28:36 +0000
Subject: [PATCH] br2684: don't send frames on not-ready vcc
Avoid submitting packets to a vcc which is being closed. Things go badly
wrong when the ->pop method gets later called after everything's been
torn down.
Use the ATM socket lock for synchronisation with vcc_destroy_socket(),
which clears the ATM_VF_READY bit under the same lock. Otherwise, we
could end up submitting a packet to the device driver even after its
->ops->close method has been called. And it could call the vcc's ->pop
method after the protocol has been shut down. Which leads to a panic.
Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
---
net/atm/br2684.c | 48 +++++++++++++++++++++++++++++++++++++++++++++---
1 file changed, 45 insertions(+), 3 deletions(-)
diff --git a/net/atm/br2684.c b/net/atm/br2684.c
index 8eb6fbe..5ff145f 100644
--- a/net/atm/br2684.c
+++ b/net/atm/br2684.c
@@ -68,6 +68,7 @@ struct br2684_vcc {
/* keep old push, pop functions for chaining */
void (*old_push)(struct atm_vcc *vcc, struct sk_buff *skb);
void (*old_pop)(struct atm_vcc *vcc, struct sk_buff *skb);
+ void (*old_release_cb)(struct atm_vcc *vcc);
enum br2684_encaps encaps;
struct list_head brvccs;
#ifdef CONFIG_ATM_BR2684_IPFILTER
@@ -269,6 +270,22 @@ static int br2684_xmit_vcc(struct sk_buff *skb, struct net_device *dev,
return !atmvcc->send(atmvcc, skb);
}
+static void br2684_release_cb(struct atm_vcc *atmvcc)
+{
+ struct br2684_vcc *brvcc = BR2684_VCC(atmvcc);
+
+ /*
+ * A race with br2684_xmit_vcc() might cause a spurious wakeup just
+ * after that function *stops* the queue, and qspace might actually
+ * go negative before the queue stops again. We cope with that.
+ */
+ if (atomic_read(&brvcc->qspace) > 0)
+ netif_wake_queue(brvcc->device);
+
+ if (brvcc->old_release_cb)
+ brvcc->old_release_cb(atmvcc);
+}
+
static inline struct br2684_vcc *pick_outgoing_vcc(const struct sk_buff *skb,
const struct br2684_dev *brdev)
{
@@ -280,6 +297,8 @@ static netdev_tx_t br2684_start_xmit(struct sk_buff *skb,
{
struct br2684_dev *brdev = BRPRIV(dev);
struct br2684_vcc *brvcc;
+ struct atm_vcc *atmvcc;
+ netdev_tx_t ret = NETDEV_TX_OK;
pr_debug("skb_dst(skb)=%p\n", skb_dst(skb));
read_lock(&devs_lock);
@@ -290,9 +309,26 @@ static netdev_tx_t br2684_start_xmit(struct sk_buff *skb,
dev->stats.tx_carrier_errors++;
/* netif_stop_queue(dev); */
dev_kfree_skb(skb);
- read_unlock(&devs_lock);
- return NETDEV_TX_OK;
+ goto out_devs;
+ }
+ atmvcc = brvcc->atmvcc;
+
+ bh_lock_sock(sk_atm(atmvcc));
+
+ if (test_bit(ATM_VF_RELEASED, &atmvcc->flags) ||
+ test_bit(ATM_VF_CLOSE, &atmvcc->flags) ||
+ !test_bit(ATM_VF_READY, &atmvcc->flags)) {
+ dev->stats.tx_dropped++;
+ dev_kfree_skb(skb);
+ goto out;
}
+
+ if (sock_owned_by_user(sk_atm(atmvcc))) {
+ netif_stop_queue(brvcc->device);
+ ret = NETDEV_TX_BUSY;
+ goto out;
+ }
+
if (!br2684_xmit_vcc(skb, dev, brvcc)) {
/*
* We should probably use netif_*_queue() here, but that
@@ -304,8 +340,11 @@ static netdev_tx_t br2684_start_xmit(struct sk_buff *skb,
dev->stats.tx_errors++;
dev->stats.tx_fifo_errors++;
}
+ out:
+ bh_unlock_sock(sk_atm(atmvcc));
+ out_devs:
read_unlock(&devs_lock);
- return NETDEV_TX_OK;
+ return ret;
}
/*
@@ -378,6 +417,7 @@ static void br2684_close_vcc(struct br2684_vcc *brvcc)
list_del(&brvcc->brvccs);
write_unlock_irq(&devs_lock);
brvcc->atmvcc->user_back = NULL; /* what about vcc->recvq ??? */
+ brvcc->atmvcc->release_cb = brvcc->old_release_cb;
brvcc->old_push(brvcc->atmvcc, NULL); /* pass on the bad news */
kfree(brvcc);
module_put(THIS_MODULE);
@@ -554,9 +594,11 @@ static int br2684_regvcc(struct atm_vcc *atmvcc, void __user * arg)
brvcc->encaps = (enum br2684_encaps)be.encaps;
brvcc->old_push = atmvcc->push;
brvcc->old_pop = atmvcc->pop;
+ brvcc->old_release_cb = atmvcc->release_cb;
barrier();
atmvcc->push = br2684_push;
atmvcc->pop = br2684_pop;
+ atmvcc->release_cb = br2684_release_cb;
/* initialize netdev carrier state */
if (atmvcc->dev->signal == ATM_PHY_SIG_LOST)
--
1.8.0
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply related
* Re: [net-next PATCH V2 1/9] net: frag evictor, avoid killing warm frag queues
From: Eric Dumazet @ 2012-11-30 16:37 UTC (permalink / raw)
To: Jesper Dangaard Brouer
Cc: David Miller, fw, netdev, pablo, tgraf, amwang, kaber, paulmck,
herbert
In-Reply-To: <1354290335.11754.447.camel@localhost>
On Fri, 2012-11-30 at 16:45 +0100, Jesper Dangaard Brouer wrote:
> On Fri, 2012-11-30 at 06:52 -0800, Eric Dumazet wrote:
>
> > I dont know how you expect that many
> > datagrams being correctly reassembled with ipfrag_high_thresh=262144
>
> That's my point... I'm showing that its not possible, with out current
> implementation!
What I was saying is that the limits are too small, and we should
increase them for this particular need.
This has little to do with the underlying algo.
Assuming we have a hash table size of 1024 buckets, you could
easily add the following :
diff --git a/net/ipv4/ip_fragment.c b/net/ipv4/ip_fragment.c
index 448e685..bc1bdf9 100644
--- a/net/ipv4/ip_fragment.c
+++ b/net/ipv4/ip_fragment.c
@@ -849,13 +849,13 @@ static inline void ip4_frags_ctl_register(void)
static int __net_init ipv4_frags_init_net(struct net *net)
{
/*
- * Fragment cache limits. We will commit 256K at one time. Should we
- * cross that limit we will prune down to 192K. This should cope with
+ * Fragment cache limits. We will commit 4M at one time. Should we
+ * cross that limit we will prune down to 3M. This should cope with
* even the most extreme cases without allowing an attacker to
* measurably harm machine performance.
*/
- net->ipv4.frags.high_thresh = 256 * 1024;
- net->ipv4.frags.low_thresh = 192 * 1024;
+ net->ipv4.frags.high_thresh = 4 << 20;
+ net->ipv4.frags.low_thresh = 3 << 20;
/*
* Important NOTE! Fragment queue must be destroyed before MSL expires.
* RFC791 is wrong proposing to prolongate timer each fragment arrival
^ permalink raw reply related
* Re: linux-next: Tree for Nov 29 (netlabel)
From: Randy Dunlap @ 2012-11-30 16:55 UTC (permalink / raw)
To: Paul Moore
Cc: Stephen Rothwell, linux-next, linux-kernel,
netdev@vger.kernel.org, Casey Schaufler, linux-security-module
In-Reply-To: <2664553.2TRaVqlkGg@sifl>
On 11/30/2012 07:31 AM, Paul Moore wrote:
> On Friday, November 30, 2012 10:19:16 AM Paul Moore wrote:
>> On Thursday, November 29, 2012 04:05:26 PM Randy Dunlap wrote:
>>> On 11/28/2012 10:40 PM, Stephen Rothwell wrote:
>>>> Hi all,
>>>
>>>> Changes since 20121128:
>>> (on i386:)
>>
>> If I had to guess it looks like CONFIG_NETLABEL needs to be dependent on
>> CONFIG_INET. While the net/ Kconfig only pulls in the net/netlabel Kconfig
>> if CONFIG_INET is defined, I'm guessing that without the explicit
>> dependency there is nothing preventing someone from arriving at a bad
>> configuration as we see here.
>>
>> Let me test this out to make sure my reasoning is right and if it is I'll
>> post a patch to netdev later today.
>>
>> Thanks for catching this.
>
> Hmmm. The existing logic in net/Kconfig seems to disable CONFIG_NETLABEL at
> build time whenever CONFIG_INET is disabled in my .config file. The only way
> I can recreate what you are seeing here is if I move the NetLabel include
> outside of the INET conditional in net/Kconfig.
>
> Regardless, adding an explicit dependency on INET to NETLABEL shouldn't hurt
> anything so I'll go ahead and post the patch to netdev. Hopefully someone who
> understands Kconfig better than I do can help shed some light on this.
Sorry, this patch doesn't help.
I just checked the kernel .config again. SECURITY_SMACK
selects NETLABEL even when INET is not enabled. Bad SMACK.
I added Casey and mailing list to the cc:
>>> net/built-in.o: In function `netlbl_cfg_cipsov4_add':
>>> (.text+0x61757): undefined reference to `cipso_v4_doi_add'
>>> net/built-in.o: In function `netlbl_cfg_cipsov4_del':
>>> (.text+0x6177d): undefined reference to `cipso_v4_doi_remove'
>>> net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
>>> (.text+0x617ae): undefined reference to `cipso_v4_doi_getdef'
>>> net/built-in.o: In function `netlbl_cfg_cipsov4_map_add':
>>> (.text+0x61a49): undefined reference to `cipso_v4_doi_putdef'
>>> net/built-in.o: In function `netlbl_sock_setattr':
>>> (.text+0x6218c): undefined reference to `cipso_v4_sock_setattr'
>>> net/built-in.o: In function `netlbl_sock_delattr':
>>> (.text+0x6220b): undefined reference to `cipso_v4_sock_delattr'
>>> net/built-in.o: In function `netlbl_sock_getattr':
>>> (.text+0x62238): undefined reference to `cipso_v4_sock_getattr'
>>> net/built-in.o: In function `netlbl_conn_setattr':
>>> (.text+0x622de): undefined reference to `cipso_v4_sock_setattr'
>>> net/built-in.o: In function `netlbl_conn_setattr':
>>> (.text+0x62303): undefined reference to `cipso_v4_sock_delattr'
>>> net/built-in.o: In function `netlbl_req_setattr':
>>> (.text+0x62429): undefined reference to `cipso_v4_req_setattr'
>>> net/built-in.o: In function `netlbl_req_setattr':
>>> (.text+0x6244e): undefined reference to `cipso_v4_req_delattr'
>>> net/built-in.o: In function `netlbl_req_delattr':
>>> (.text+0x624ba): undefined reference to `cipso_v4_req_delattr'
>>> net/built-in.o: In function `netlbl_skbuff_setattr':
>>> (.text+0x62551): undefined reference to `cipso_v4_skbuff_setattr'
>>> net/built-in.o: In function `netlbl_skbuff_setattr':
>>> (.text+0x62576): undefined reference to `cipso_v4_skbuff_delattr'
>>> net/built-in.o: In function `netlbl_skbuff_getattr':
>>> (.text+0x62619): undefined reference to `cipso_v4_skbuff_getattr'
>>> net/built-in.o: In function `netlbl_skbuff_err':
>>> (.text+0x62685): undefined reference to `cipso_v4_error'
>>> net/built-in.o: In function `netlbl_cache_invalidate':
>>> (.text+0x626ab): undefined reference to `cipso_v4_cache_invalidate'
>>> net/built-in.o: In function `netlbl_cache_add':
>>> (.text+0x626ec): undefined reference to `cipso_v4_cache_add'
>>> net/built-in.o: In function `netlbl_domhsh_remove_entry':
>>> (.text+0x63294): undefined reference to `cipso_v4_doi_putdef'
>>> net/built-in.o: In function `netlbl_domhsh_remove_entry':
>>> (.text+0x632eb): undefined reference to `cipso_v4_doi_putdef'
>>> net/built-in.o: In function `netlbl_domhsh_remove_af4':
>>> (.text+0x6349b): undefined reference to `cipso_v4_doi_putdef'
>>> net/built-in.o: In function `netlbl_mgmt_add_common.clone.1':
>>> netlabel_mgmt.c:(.text+0x64a87): undefined reference to
>>> `cipso_v4_doi_getdef' netlabel_mgmt.c:(.text+0x64c83): undefined reference
>>> to `cipso_v4_doi_putdef' net/built-in.o: In function
>>> `netlbl_cipsov4_listall':
>>> netlabel_cipso_v4.c:(.text+0x66e52): undefined reference to
>>> `cipso_v4_doi_walk' net/built-in.o: In function `netlbl_cipsov4_list':
>>> netlabel_cipso_v4.c:(.text+0x67199): undefined reference to
>>> `cipso_v4_doi_getdef' net/built-in.o: In function `netlbl_cipsov4_remove':
>>> netlabel_cipso_v4.c:(.text+0x6771b): undefined reference to
>>> `cipso_v4_doi_remove' net/built-in.o: In function
>>> `netlbl_cipsov4_add_pass':
>>> netlabel_cipso_v4.c:(.text+0x67a4b): undefined reference to
>>> `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67a76): undefined
>>> reference
>>> to `cipso_v4_doi_free' net/built-in.o: In function
>>> `netlbl_cipsov4_add_local':
>>> netlabel_cipso_v4.c:(.text+0x67b9a): undefined reference to
>>> `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x67bc5): undefined
>>> reference
>>> to `cipso_v4_doi_free' net/built-in.o: In function
>>> `netlbl_cipsov4_add_std':
>>> netlabel_cipso_v4.c:(.text+0x68535): undefined reference to
>>> `cipso_v4_doi_add' netlabel_cipso_v4.c:(.text+0x68575): undefined
>>> reference
>>> to `cipso_v4_doi_free'
>>>
>>>
>>> Full randconfig file is attached.
--
~Randy
^ permalink raw reply
* Re: [PATCH V2 1/5] cxgb4: Add T4 filter support
From: David Miller @ 2012-11-30 16:56 UTC (permalink / raw)
To: vipul-ut6Up61K2wZBDgjK7y7TUQ
Cc: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA,
roland-BHEL68pLQRGGvPXPguhicg, divy-ut6Up61K2wZBDgjK7y7TUQ,
dm-ut6Up61K2wZBDgjK7y7TUQ, kumaras-ut6Up61K2wZBDgjK7y7TUQ,
swise-7bPotxP6k4+P2YhJcF5u+vpXobYPEAuW,
abhishek-ut6Up61K2wZBDgjK7y7TUQ
In-Reply-To: <1354277370-8727-1-git-send-email-vipul-ut6Up61K2wZBDgjK7y7TUQ@public.gmane.org>
I really don't understand how we're supposed to review your patches
when you only post some parts of the patch series to netdev, and
others not.
Please do not do this.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: Krzysztof Mazur @ 2012-11-30 17:00 UTC (permalink / raw)
To: David Woodhouse
Cc: Chas Williams (CONTRACTOR), David Laight, davem, netdev,
linux-kernel, nathan
In-Reply-To: <1354292626.21562.298.camel@shinybook.infradead.org>
On Fri, Nov 30, 2012 at 04:23:46PM +0000, David Woodhouse wrote:
>
> +static void br2684_release_cb(struct atm_vcc *atmvcc)
> +{
> + struct br2684_vcc *brvcc = BR2684_VCC(atmvcc);
> +
> + /*
> + * A race with br2684_xmit_vcc() might cause a spurious wakeup just
> + * after that function *stops* the queue, and qspace might actually
> + * go negative before the queue stops again. We cope with that.
> + */
We cannot race with br2684_xmit_vcc() because both br2684_xmit_vcc()
and br2684_release_cb() are called with locked sk->sk_lock.slock.
> + if (atomic_read(&brvcc->qspace) > 0)
> + netif_wake_queue(brvcc->device);
> +
> + if (brvcc->old_release_cb)
> + brvcc->old_release_cb(atmvcc);
> +}
Except that comment, the patch looks good:
Acked-by: Krzysztof Mazur <krzysiek@podlesie.net>
Krzysiek
^ permalink raw reply
* Re: "tuntap: multiqueue support" causes udev fork bombs
From: Jiri Slaby @ 2012-11-30 17:01 UTC (permalink / raw)
To: Jason Wang
Cc: David S. Miller, ML netdev, LKML, rmilasan, Jiri Slaby, maxk,
vtun
In-Reply-To: <4146845.d5imC0scLB@jason-thinkpad-t430s>
On 11/29/2012 06:47 AM, Jason Wang wrote:
> On Wednesday, November 28, 2012 11:25:41 AM Jiri Slaby wrote:
>> Hi,
>>
>> with this commit:
>> commit c8d68e6be1c3b242f1c598595830890b65cea64a
>> Author: Jason Wang <jasowang@redhat.com>
>> Date: Wed Oct 31 19:46:00 2012 +0000
>>
>> tuntap: multiqueue support
>>
>>
>> I see fork bombs from udev. It is trying to create 2048 processes. 1024
>> for tx, 1024 for rx. OOM killer indeed steps in and kills everything.
>
> Hi, thanks for the reporting, could you pls try the following patch?
Hi, it is gone with this patch.
> ---
>
> diff --git a/drivers/net/tun.c b/drivers/net/tun.c
> index b44d7b7..cc3f878 100644
> --- a/drivers/net/tun.c
> +++ b/drivers/net/tun.c
> @@ -492,9 +492,6 @@ static int tun_attach(struct tun_struct *tun, struct file *file)
>
> tun_set_real_num_queues(tun);
>
> - if (tun->numqueues == 1)
> - netif_carrier_on(tun->dev);
> -
> /* device is allowed to go away first, so no need to hold extra
> * refcnt.
> */
> @@ -1611,6 +1608,10 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> TUN_USER_FEATURES;
> dev->features = dev->hw_features;
>
> + err = tun_attach(tun, file);
> + if (err < 0)
> + goto err_free_dev;
> +
> err = register_netdevice(tun->dev);
> if (err < 0)
> goto err_free_dev;
> @@ -1620,9 +1621,7 @@ static int tun_set_iff(struct net *net, struct file *file, struct ifreq *ifr)
> device_create_file(&tun->dev->dev, &dev_attr_group))
> pr_err("Failed to create tun sysfs files\n");
>
> - err = tun_attach(tun, file);
> - if (err < 0)
> - goto err_free_dev;
> + netif_carrier_on(tun->dev);
> }
>
> tun_debug(KERN_INFO, tun, "tun_set_iff\n");
>
--
js
suse labs
^ permalink raw reply
* Re: [GIT net-next] Open vSwitch
From: David Miller @ 2012-11-30 17:03 UTC (permalink / raw)
To: jesse; +Cc: netdev, dev
In-Reply-To: <1354214149-33651-1-git-send-email-jesse@nicira.com>
From: Jesse Gross <jesse@nicira.com>
Date: Thu, 29 Nov 2012 10:35:42 -0800
> This series of improvements for 3.8/net-next contains four components:
> * Support for modifying IPv6 headers
> * Support for matching and setting skb->mark for better integration with
> things like iptables
> * Ability to recognize the EtherType for RARP packets
> * Two small performance enhancements
>
> The movement of ipv6_find_hdr() into exthdrs_core.c causes two small merge
> conflicts. I left it as is but can do the merge if you want. The conflicts
> are:
> * ipv6_find_hdr() and ipv6_find_tlv() were both moved to the bottom of
> exthdrs_core.c. Both should stay.
> * A new use of ipv6_find_hdr() was added to net/netfilter/ipvs/ip_vs_core.c
> after this patch. The IPVS user has two instances of the old constant
> name IP6T_FH_F_FRAG which has been renamed to IP6_FH_F_FRAG.
Pulled, thanks Jesse.
The merge conflict directions were particularly helpful.
If you ever do the merge yourself (I'm ambivalent about where you or I
do it), make sure you force the merge commit message to have a
description of the conflict resolution similarly to what you provided
here.
Thanks again.
^ permalink raw reply
* [PATCH] MAINTAINERS: fix bouncing tun/tap entries
From: Jiri Slaby @ 2012-11-30 17:05 UTC (permalink / raw)
To: maxk; +Cc: netdev, jirislaby, linux-kernel
Delivery to the following recipient failed permanently:
vtun@office.satix.net
Technical details of permanent failure:
DNS Error: Domain name not found
Of course:
$ host office.satix.net
Host office.satix.net not found: 3(NXDOMAIN)
===========
And "Change of Email Address Notification":
Old Address New Address Email Subject
------------------------------------------------------
maxk@qualcomm.com maxk@qti.qualcomm.com "tuntap: multiqueue...
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: Maxim Krasnyansky <maxk@qti.qualcomm.com>
---
MAINTAINERS | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 61b2e14..75d3b88 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -7696,8 +7696,7 @@ S: Maintained
F: drivers/net/ethernet/dec/tulip/
TUN/TAP driver
-M: Maxim Krasnyansky <maxk@qualcomm.com>
-L: vtun@office.satix.net
+M: Maxim Krasnyansky <maxk@qti.qualcomm.com>
W: http://vtun.sourceforge.net/tun
S: Maintained
F: Documentation/networking/tuntap.txt
--
1.8.0.1
^ permalink raw reply related
* Re: [PATCH] bonding: rlb mode of bond should not alter ARP originating via bridge
From: David Miller @ 2012-11-30 17:08 UTC (permalink / raw)
To: fubar; +Cc: zheng.x.li, netdev, andy, linux-kernel, joe.jin
In-Reply-To: <15005.1354213705@death.nxdomain>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Thu, 29 Nov 2012 10:28:25 -0800
> Zheng Li <zheng.x.li@oracle.com> wrote:
>
>>Do not modify or load balance ARP packets passing through balance-alb
>>mode (wherein the ARP did not originate locally, and arrived via a bridge).
>>
>>Modifying pass-through ARP replies causes an incorrect MAC address
>>to be placed into the ARP packet, rendering peers unable to communicate
>>with the actual destination from which the ARP reply originated.
>>
>>Load balancing pass-through ARP requests causes an entry to be
>>created for the peer in the rlb table, and bond_alb_monitor will
>>occasionally issue ARP updates to all peers in the table instrucing them
>>as to which MAC address they should communicate with; this occurs when
>>some event sets rx_ntt. In the bridged case, however, the MAC address
>>used for the update would be the MAC of the slave, not the actual source
>>MAC of the originating destination. This would render peers unable to
>>communicate with the destinations beyond the bridge.
>>
>>Signed-off-by: Zheng Li <zheng.x.li@oracle.com>
>>Cc: Jay Vosburgh <fubar@us.ibm.com>
>>Cc: Andy Gospodarek <andy@greyhouse.net>
>>Cc: "David S. Miller" <davem@davemloft.net>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH][RESEND] bonding: delete migrated IP addresses from the rlb hash table
From: David Miller @ 2012-11-30 17:08 UTC (permalink / raw)
To: fubar; +Cc: jbohac, andy, netdev
In-Reply-To: <18712.1354223407@death.nxdomain>
From: Jay Vosburgh <fubar@us.ibm.com>
Date: Thu, 29 Nov 2012 13:10:07 -0800
> Jiri Bohac <jbohac@suse.cz> wrote:
>
>>Signed-off-by: Jiri Bohac <jbohac@suse.cz>
>
> Signed-off-by: Jay Vosburgh <fubar@us.ibm.com>
Applied.
^ permalink raw reply
* Re: [net-next PATCH v1] 8021q: fix vlan device to inherit the unicast filtering capability flag
From: David Miller @ 2012-11-30 17:09 UTC (permalink / raw)
To: yi.zou; +Cc: netdev, devel
In-Reply-To: <20121128234520.6615.41220.stg.yi.zou@intel.com>
From: Yi Zou <yi.zou@intel.com>
Date: Wed, 28 Nov 2012 15:45:24 -0800
> This bug is observed on running FCoE over a VLAN device associated w/
> a real device that has IFF_UNICAST_FLT set since FCoE would add unicast
> address such as FLOGI MAC to the VLAN interface that FCoE is on. Since
> currently, VLAN device is not inheriting the IFF_UNICAST_FLT flag from the
> parent real device even though the real device is capable of doing unicast
> filtering. This forces the VLAN device and its real device go to promiscuous
> mode unnecessarily even the added address is actually being added to the
> available unicast filter table in real device.
>
> Signed-off-by: Yi Zou <yi.zou@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] ipv6: unify logic evaluating inet6_dev's accept_ra property
From: David Miller @ 2012-11-30 17:09 UTC (permalink / raw)
To: shmulik.ladkani; +Cc: netdev, yoshfuji, tgraf, tore
In-Reply-To: <1354181179-16294-1-git-send-email-shmulik.ladkani@gmail.com>
From: Shmulik Ladkani <shmulik.ladkani@gmail.com>
Date: Thu, 29 Nov 2012 11:26:19 +0200
> + /*
> + * If forwarding is enabled, RA are not accepted unless the special
> + * hybrid mode (accept_ra=2) is enabled.
> + */
Please format this comment correctly, in the networking we use
the style:
/* That looks
* like this.
*/
/*
* Not
* like this.
*/
Thanks.
^ permalink raw reply
* Re: [PATCH] mISDN: improve bitops usage
From: David Miller @ 2012-11-30 17:11 UTC (permalink / raw)
To: akinobu.mita; +Cc: netdev, isdn
In-Reply-To: <1354188465-29012-1-git-send-email-akinobu.mita@gmail.com>
From: Akinobu Mita <akinobu.mita@gmail.com>
Date: Thu, 29 Nov 2012 20:27:45 +0900
> This improves bitops usages in several points:
>
> - Convert u64 to a proper bitmap declaration. This enables to remove
> superfluous typecasting from 'u64' to 'unsigned long *'.
>
> - Convert superfluous atomic bitops to non atomic bitops. The bitmap
> is allocated on the stack and it is not accessed by any other threads,
> so using atomic bitops is not necessary.
>
> - Use find_next_zero_bit and find_next_zero_bit instead of calling
> test_bit() for each bit.
>
> Signed-off-by: Akinobu Mita <akinobu.mita@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: pull-request: can-next 2012-11-29
From: David Miller @ 2012-11-30 17:12 UTC (permalink / raw)
To: mkl; +Cc: netdev, linux-can
In-Reply-To: <50B76815.8010907@pengutronix.de>
From: Marc Kleine-Budde <mkl@pengutronix.de>
Date: Thu, 29 Nov 2012 14:50:13 +0100
> this pull request is for net-next/master. There is a patch by Alexander
> Stein fixing a reference counter problem which can make driver
> unloading impossible (stable Cc'ed). And several patches by me which
> remove an obsolete mechanism from several drivers, which is already
> handled at the infrastructure level.
Applied thanks.
^ permalink raw reply
* Re: [PATCH v2 3/3] pppoatm: protect against freeing of vcc
From: chas williams - CONTRACTOR @ 2012-11-30 17:12 UTC (permalink / raw)
To: David Woodhouse
Cc: Krzysztof Mazur, David Laight, davem, netdev, linux-kernel,
nathan
In-Reply-To: <1354292626.21562.298.camel@shinybook.infradead.org>
On Fri, 30 Nov 2012 16:23:46 +0000
David Woodhouse <dwmw2@infradead.org> wrote:
> On Fri, 2012-11-30 at 12:10 +0000, David Woodhouse wrote:
> > In that case I think we're fine. I'll just do the same thing in
> > br2684_push(), fix up the comment you just corrected, and we're all
> > good.
>
> OK, here's an update to me my patch 8/17 'br2684: don't send frames on
> not-ready vcc'. It takes the socket lock and does fairly much the same
> thing as your pppoatm version. It returns NETDEV_TX_BUSY and stops the
> queue if the socket is locked, and it gets woken from the ->release_cb
> callback.
>
> I've dropped your Acked-By: since it's mostly new, but feel free to give
> me a fresh one. With this I think we're done.
>
> Unless Chas has any objections, I'll ask Dave to pull it...
no objections. i think this deals with my concerns. as for splitting
the close functions, from one of your previous messages:
>Really, what we're saying is that *one* of the driver or protocol close
>functions needs to be split, and we need to do DPD or PDP. Since the
>device driver *can* abort/flush the TX queue and also any pending RX
>being handled by a tasklet, I think it makes most sense to keep it in
>the middle, with the protocol being handled first and last... which is
>the current order, as long as we consider setting ATM_VF_CLOSE to be the
>first part.
i believe this is essentially already done with the release_cb()
implementation right? that is splitting the protocol detach/shutdown
into two parts.
^ permalink raw reply
* Re: [PATCH net-next v1 3/3] net/mlx4_en: Set number of rx/tx channels using ethtool
From: David Miller @ 2012-11-30 17:16 UTC (permalink / raw)
To: amirv; +Cc: ogerlitz, oren, netdev
In-Reply-To: <1354216903-830-4-git-send-email-amirv@mellanox.com>
From: Amir Vadai <amirv@mellanox.com>
Date: Thu, 29 Nov 2012 21:21:43 +0200
> +static void mlx4_en_get_channels(struct net_device *dev,
> + struct ethtool_channels *channel)
This is not formatted correctly, the argument on the second line
must line up with the first column after the openning "(" on the
previous line.
^ permalink raw reply
* Re: [PATCH v3 net-next 0/2] myri10ge: LRO to GRO conversion
From: David Miller @ 2012-11-30 17:17 UTC (permalink / raw)
To: gallatin; +Cc: netdev
In-Reply-To: <50B7CE83.1020809@myri.com>
From: Andrew Gallatin <gallatin@myri.com>
Date: Thu, 29 Nov 2012 16:07:15 -0500
>
> drivers/net/ethernet/myricom/Kconfig | 1 -
> drivers/net/ethernet/myricom/myri10ge/myri10ge.c | 275
> ++++++----------------
> 2 files changed, 74 insertions(+), 202 deletions(-)
>
Your email client is chopping up long lines, corrupting your
patches.
^ permalink raw reply
* Re: [PATCH] 6lowpan: consider checksum bytes in fragmentation threshold
From: David Miller @ 2012-11-30 17:19 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
linux-kernel
In-Reply-To: <1354240544-22214-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Thu, 29 Nov 2012 20:55:44 -0500
> Change the threshold for framentation of a lowpan packet from
> using the MTU size to now use the MTU size minus the checksum length,
> which is added by the hardware. For IEEE 802.15.4, this effectively
> changes it from 127 bytes to 125 bytes.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied.
^ permalink raw reply
* Re: [PATCH 1/2] mac802154: fix memory leaks
From: David Miller @ 2012-11-30 17:19 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, eric.dumazet,
linux-zigbee-devel, netdev, linux-kernel
In-Reply-To: <1354249511-8086-1-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Thu, 29 Nov 2012 23:25:10 -0500
> kfree_skb() was not getting called in the case of some failures.
> This was pointed out by Eric Dumazet.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied.
^ permalink raw reply
* Re: [PATCH 2/2] mac802154: use kfree_skb() instead of dev_kfree_skb()
From: David Miller @ 2012-11-30 17:19 UTC (permalink / raw)
To: alan
Cc: alex.bluesman.smirnov, dbaryshkov, eric.dumazet,
linux-zigbee-devel, netdev, linux-kernel
In-Reply-To: <1354249511-8086-2-git-send-email-alan@signal11.us>
From: Alan Ott <alan@signal11.us>
Date: Thu, 29 Nov 2012 23:25:11 -0500
> kfree_skb() indicates failure, which is where this is being used.
>
> Signed-off-by: Alan Ott <alan@signal11.us>
Applied.
^ permalink raw reply
* Re: [PATCH] sctp: fix CONFIG_SCTP_DBG_MSG=y null pointer dereference in sctp_v6_get_dst()
From: David Miller @ 2012-11-30 17:21 UTC (permalink / raw)
To: tt.rantala; +Cc: linux-sctp, netdev, nhorman, vyasevich, sri, davej
In-Reply-To: <1354267062-15888-1-git-send-email-tt.rantala@gmail.com>
From: Tommi Rantala <tt.rantala@gmail.com>
Date: Fri, 30 Nov 2012 11:17:42 +0200
> Trinity (the syscall fuzzer) triggered the following BUG, reproducible
> only when the kernel is configured with CONFIG_SCTP_DBG_MSG=y.
>
> When CONFIG_SCTP_DBG_MSG is not set, the null pointer is never
> dereferenced.
...
> Signed-off-by: Tommi Rantala <tt.rantala@gmail.com>
Applied, thanks.
^ permalink raw reply
* Re: pull request: batman-adv 2012-11-30
From: David Miller @ 2012-11-30 17:22 UTC (permalink / raw)
To: ordex; +Cc: netdev, b.a.t.m.a.n
In-Reply-To: <1354270450-25935-1-git-send-email-ordex@autistici.org>
From: Antonio Quartulli <ordex@autistici.org>
Date: Fri, 30 Nov 2012 11:14:09 +0100
> Here is a lonely patch intended for net-next/linux-3.8.
> It it simply adapting the batman-adv code to use the new ETH_P_BATMAN define
> recently introduced in if_ether.h.
Pulled, thanks.
^ 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