* [PATCH 2/2] net: remove obsolete simple_strto<foo>
From: Abhijit Pawar @ 2012-12-11 5:30 UTC (permalink / raw)
To: David S. Miller, Pablo Neira Ayuso, Patrick McHardy,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
John W. Linville, Johannes Berg, Cong Wang, Eric Dumazet,
Neil Horman, Joe Perches
Cc: netdev-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netfilter-devel-u79uwXL29TY76Z2rM5mHXA,
netfilter-u79uwXL29TY76Z2rM5mHXA, coreteam-Cap9r6Oaw4JrovVCs/uTlw,
linux-wireless-u79uwXL29TY76Z2rM5mHXA, Abhijit Pawar
This patch removes the redundant occurences of simple_strto<foo>
Signed-off-by: Abhijit Pawar <abhi.c.pawar-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
net/core/netpoll.c | 1 -
net/mac80211/debugfs_sta.c | 1 -
net/netfilter/nf_conntrack_core.c | 1 -
3 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 12c129f..3151acf 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -706,7 +706,6 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
*delim = 0;
if (*cur == ' ' || *cur == '\t')
np_info(np, "warning: whitespace is not allowed\n");
- np->remote_port = simple_strtol(cur, NULL, 10);
if (kstrtou16(cur, 10, &np->remote_port))
goto parse_failed;
cur = delim;
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 0dedb4b..6fb1168 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -220,7 +220,6 @@ static ssize_t sta_agg_status_write(struct file *file, const char __user *userbu
} else
return -EINVAL;
- tid = simple_strtoul(buf, NULL, 0);
ret = kstrtoul(buf, 0, &tid);
if (ret)
return ret;
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index 37d9e62..08cdc71 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1422,7 +1422,6 @@ int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp)
if (!nf_conntrack_htable_size)
return param_set_uint(val, kp);
- hashsize = simple_strtoul(val, NULL, 0);
rc = kstrtouint(val, 0, &hashsize);
if (rc)
return rc;
--
1.7.7.6
--
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 related
* Re: [PATCH RESEND RESEND] net: remove obsolete simple_strto<foo>
From: Abhijit Pawar @ 2012-12-11 5:29 UTC (permalink / raw)
To: David Miller
Cc: abhi.c.pawar, pablo, kaber, kuznet, jmorris, yoshfuji, linville,
johannes, amwang, edumazet, nhorman, joe, netdev, linux-kernel,
netfilter-devel, netfilter, coreteam, linux-wireless
In-Reply-To: <20121210.234923.94776338088489257.davem@davemloft.net>
On 12/11/2012 10:19 AM, David Miller wrote:
> From: Abhijit Pawar <abhi.c.pawar@gmail.com>
> Date: Tue, 11 Dec 2012 09:04:20 +0530
>
>> This patch replace the obsolete simple_strto<foo> with kstrto<foo>
>>
>> Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
>
> You can't submit replacement patches for ones which I have already
> applied.
>
> Patches I apply are permanently applied, and therefore you must submit
> changes relative the ones I've applied already.
>
I am sorry to create this confusion. I have created and sent the new
patch which you can apply over the old one to fix the issues.
--
-
Abhijit
^ permalink raw reply
* Re: netconsole fun
From: Cong Wang @ 2012-12-11 4:51 UTC (permalink / raw)
To: netdev
In-Reply-To: <1355149033.3142.14.camel@thor>
On Mon, 10 Dec 2012 at 14:17 GMT, Peter Hurley <peter@hurleysoftware.com> wrote:
> Now that netpoll has been disabled for slaved devices, is there a
> recommended method of running netconsole on a machine that has a slaved
> device?
>
Yes, running it on the master device instead.
^ permalink raw reply
* Re: [PATCH RESEND RESEND] net: remove obsolete simple_strto<foo>
From: David Miller @ 2012-12-11 4:49 UTC (permalink / raw)
To: abhi.c.pawar
Cc: pablo, kaber, kuznet, jmorris, yoshfuji, linville, johannes,
amwang, edumazet, nhorman, joe, netdev, linux-kernel,
netfilter-devel, netfilter, coreteam, linux-wireless
In-Reply-To: <1355196860-10708-1-git-send-email-abhi.c.pawar@gmail.com>
From: Abhijit Pawar <abhi.c.pawar@gmail.com>
Date: Tue, 11 Dec 2012 09:04:20 +0530
> This patch replace the obsolete simple_strto<foo> with kstrto<foo>
>
> Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
You can't submit replacement patches for ones which I have already
applied.
Patches I apply are permanently applied, and therefore you must submit
changes relative the ones I've applied already.
^ permalink raw reply
* Re: [PATCH RESEND] net: remove obsolete simple_strto<foo>
From: David Miller @ 2012-12-11 4:48 UTC (permalink / raw)
To: abhi.c.pawar
Cc: pablo, kaber, kuznet, jmorris, yoshfuji, linville, johannes,
amwang, edumazet, nhorman, joe, netdev, linux-kernel,
netfilter-devel, netfilter, coreteam, linux-wireless
In-Reply-To: <50C6A995.1020908@gmail.com>
From: Abhijit Pawar <abhi.c.pawar@gmail.com>
Date: Tue, 11 Dec 2012 09:03:41 +0530
> On 12/11/2012 12:40 AM, David Miller wrote:
>> From: Abhijit Pawar <abhi.c.pawar@gmail.com>
>> Date: Mon, 10 Dec 2012 14:42:28 +0530
>>
>>> This patch replace the obsolete simple_strto<foo> with kstrto<foo>
>>>
>>> Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
>>
>> Applied.
>>
> Hi David,
> It seems that there are occurences of simple_strto* still present in the
> couple of files which are not yet removed correctly by this patch. I
> will send a modified patch shortly. Please revert this commit and use
> the newly sent patch to merge with the tree.
Again, you cannot send "modified" patches.
When I say I've applied your patch, that cannot be undone.
You must therefore send me fixup patches relative to the ones
I've applied already.
^ permalink raw reply
* Re: [PATCH RESEND] net: remove obsolete simple_strto<foo>
From: David Miller @ 2012-12-11 4:43 UTC (permalink / raw)
To: abhi.c.pawar
Cc: amwang, joe, jmorris, edumazet, pablo, kaber, coreteam, yoshfuji,
netfilter-devel, johannes, linux-kernel, netfilter, linville,
linux-wireless, netdev, nhorman, kuznet
In-Reply-To: <CA+kxV1GBxdZKnjqs1bm1qBJE8dGXtOfqP_oYbB-hw5Ga1xE65g@mail.gmail.com>
From: Abhijit Pawar <abhi.c.pawar@gmail.com>
Date: Tue, 11 Dec 2012 06:36:59 +0530
> It looks like there are two occurences of simple_strtoul which has not been
> removed cleanly from the patch.
> They are in netpoll.c and debugfs_sta.c
> I will send the modified corrected clean patch shortly.
You can't simply send me a replacement patch, since I already applied
the original one and that patch will not be reverted.
^ permalink raw reply
* [PATCH v2 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: Mugunthan V N @ 2012-12-11 3:43 UTC (permalink / raw)
To: netdev; +Cc: davem, linux-arm-kernel, linux-omap, s.hauer, Mugunthan V N
When there is heavy transmission traffic in the CPDMA, then Rx descriptors
memory is also utilized as tx desc memory looses all rx descriptors and the
driver stops working then.
This patch adds boundary for tx and rx descriptors in bd ram dividing the
descriptor memory to ensure that during heavy transmission tx doesn't use
rx descriptors.
This patch is already applied to davinci_emac driver, since CPSW and
davici_dmac shares the same CPDMA, moving the boundry seperation from
Davinci EMAC driver to CPDMA driver which was done in the following
commit
commit 86d8c07ff2448eb4e860e50f34ef6ee78e45c40c
Author: Sascha Hauer <s.hauer@pengutronix.de>
Date: Tue Jan 3 05:27:47 2012 +0000
net/davinci: do not use all descriptors for tx packets
The driver uses a shared pool for both rx and tx descriptors.
During open it queues fixed number of 128 descriptors for receive
packets. For each received packet it tries to queue another
descriptor. If this fails the descriptor is lost for rx.
The driver has no limitation on tx descriptors to use, so it
can happen during a nmap / ping -f attack that the driver
allocates all descriptors for tx and looses all rx descriptors.
The driver stops working then.
To fix this limit the number of tx descriptors used to half of
the descriptors available, the rx path uses the other half.
Tested on a custom board using nmap / ping -f to the board from
two different hosts.
Signed-off-by: Mugunthan V N <mugunthanvnm@ti.com>
---
Changes from initial patch:
* Modified commit message with proper description as in previous commit message
drivers/net/ethernet/ti/davinci_cpdma.c | 20 ++++++++++++++------
drivers/net/ethernet/ti/davinci_emac.c | 8 --------
2 files changed, 14 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 4995673..d37f546 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.c
+++ b/drivers/net/ethernet/ti/davinci_cpdma.c
@@ -105,13 +105,13 @@ struct cpdma_ctlr {
};
struct cpdma_chan {
+ struct cpdma_desc __iomem *head, *tail;
+ void __iomem *hdp, *cp, *rxfree;
enum cpdma_state state;
struct cpdma_ctlr *ctlr;
int chan_num;
spinlock_t lock;
- struct cpdma_desc __iomem *head, *tail;
int count;
- void __iomem *hdp, *cp, *rxfree;
u32 mask;
cpdma_handler_fn handler;
enum dma_data_direction dir;
@@ -217,7 +217,7 @@ desc_from_phys(struct cpdma_desc_pool *pool, dma_addr_t dma)
}
static struct cpdma_desc __iomem *
-cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
+cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc, bool is_rx)
{
unsigned long flags;
int index;
@@ -225,8 +225,14 @@ cpdma_desc_alloc(struct cpdma_desc_pool *pool, int num_desc)
spin_lock_irqsave(&pool->lock, flags);
- index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
- num_desc, 0);
+ if (is_rx) {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc/2, 0, num_desc, 0);
+ } else {
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc, pool->num_desc/2, num_desc, 0);
+ }
+
if (index < pool->num_desc) {
bitmap_set(pool->bitmap, index, num_desc);
desc = pool->iomap + pool->desc_size * index;
@@ -660,6 +666,7 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
unsigned long flags;
u32 mode;
int ret = 0;
+ bool is_rx;
spin_lock_irqsave(&chan->lock, flags);
@@ -668,7 +675,8 @@ int cpdma_chan_submit(struct cpdma_chan *chan, void *token, void *data,
goto unlock_ret;
}
- desc = cpdma_desc_alloc(ctlr->pool, 1);
+ is_rx = (chan->rxfree != 0);
+ desc = cpdma_desc_alloc(ctlr->pool, 1, is_rx);
if (!desc) {
chan->stats.desc_alloc_fail++;
ret = -ENOMEM;
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index fce89a0..f349273 100644
--- a/drivers/net/ethernet/ti/davinci_emac.c
+++ b/drivers/net/ethernet/ti/davinci_emac.c
@@ -120,7 +120,6 @@ static const char emac_version_string[] = "TI DaVinci EMAC Linux v6.1";
#define EMAC_DEF_TX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_CH (0) /* Default 0th channel */
#define EMAC_DEF_RX_NUM_DESC (128)
-#define EMAC_DEF_TX_NUM_DESC (128)
#define EMAC_DEF_MAX_TX_CH (1) /* Max TX channels configured */
#define EMAC_DEF_MAX_RX_CH (1) /* Max RX channels configured */
#define EMAC_POLL_WEIGHT (64) /* Default NAPI poll weight */
@@ -342,7 +341,6 @@ struct emac_priv {
u32 mac_hash2;
u32 multicast_hash_cnt[EMAC_NUM_MULTICAST_BITS];
u32 rx_addr_type;
- atomic_t cur_tx;
const char *phy_id;
#ifdef CONFIG_OF
struct device_node *phy_node;
@@ -1050,9 +1048,6 @@ static void emac_tx_handler(void *token, int len, int status)
{
struct sk_buff *skb = token;
struct net_device *ndev = skb->dev;
- struct emac_priv *priv = netdev_priv(ndev);
-
- atomic_dec(&priv->cur_tx);
if (unlikely(netif_queue_stopped(ndev)))
netif_start_queue(ndev);
@@ -1101,9 +1096,6 @@ static int emac_dev_xmit(struct sk_buff *skb, struct net_device *ndev)
goto fail_tx;
}
- if (atomic_inc_return(&priv->cur_tx) >= EMAC_DEF_TX_NUM_DESC)
- netif_stop_queue(ndev);
-
return NETDEV_TX_OK;
fail_tx:
--
1.7.9.5
^ permalink raw reply related
* [PATCH RESEND RESEND] net: remove obsolete simple_strto<foo>
From: Abhijit Pawar @ 2012-12-11 3:34 UTC (permalink / raw)
To: David S. Miller, Pablo Neira Ayuso, Patrick McHardy,
Alexey Kuznetsov, James Morris, Hideaki YOSHIFUJI,
John W. Linville, Johannes Berg, Cong Wang, Eric Dumazet,
Neil Horman, Joe Perches
Cc: netdev, linux-kernel, netfilter-devel, netfilter, coreteam,
linux-wireless, Abhijit Pawar
This patch replace the obsolete simple_strto<foo> with kstrto<foo>
Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
---
net/core/netpoll.c | 6 ++++--
net/ipv4/netfilter/ipt_CLUSTERIP.c | 9 +++++++--
net/mac80211/debugfs_sta.c | 4 +++-
net/netfilter/nf_conntrack_core.c | 6 ++++--
4 files changed, 18 insertions(+), 7 deletions(-)
diff --git a/net/core/netpoll.c b/net/core/netpoll.c
index 77a0388..3151acf 100644
--- a/net/core/netpoll.c
+++ b/net/core/netpoll.c
@@ -674,7 +674,8 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
if ((delim = strchr(cur, '@')) == NULL)
goto parse_failed;
*delim = 0;
- np->local_port = simple_strtol(cur, NULL, 10);
+ if (kstrtou16(cur, 10, &np->local_port))
+ goto parse_failed;
cur = delim;
}
cur++;
@@ -705,7 +706,8 @@ int netpoll_parse_options(struct netpoll *np, char *opt)
*delim = 0;
if (*cur == ' ' || *cur == '\t')
np_info(np, "warning: whitespace is not allowed\n");
- np->remote_port = simple_strtol(cur, NULL, 10);
+ if (kstrtou16(cur, 10, &np->remote_port))
+ goto parse_failed;
cur = delim;
}
cur++;
diff --git a/net/ipv4/netfilter/ipt_CLUSTERIP.c b/net/ipv4/netfilter/ipt_CLUSTERIP.c
index fe5daea..75e33a7 100644
--- a/net/ipv4/netfilter/ipt_CLUSTERIP.c
+++ b/net/ipv4/netfilter/ipt_CLUSTERIP.c
@@ -661,6 +661,7 @@ static ssize_t clusterip_proc_write(struct file *file, const char __user *input,
#define PROC_WRITELEN 10
char buffer[PROC_WRITELEN+1];
unsigned long nodenum;
+ int rc;
if (size > PROC_WRITELEN)
return -EIO;
@@ -669,11 +670,15 @@ static ssize_t clusterip_proc_write(struct file *file, const char __user *input,
buffer[size] = 0;
if (*buffer == '+') {
- nodenum = simple_strtoul(buffer+1, NULL, 10);
+ rc = kstrtoul(buffer+1, 10, &nodenum);
+ if (rc)
+ return rc;
if (clusterip_add_node(c, nodenum))
return -ENOMEM;
} else if (*buffer == '-') {
- nodenum = simple_strtoul(buffer+1, NULL,10);
+ rc = kstrtoul(buffer+1, 10, &nodenum);
+ if (rc)
+ return rc;
if (clusterip_del_node(c, nodenum))
return -ENOENT;
} else
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index 49a1c70..6fb1168 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -220,7 +220,9 @@ static ssize_t sta_agg_status_write(struct file *file, const char __user *userbu
} else
return -EINVAL;
- tid = simple_strtoul(buf, NULL, 0);
+ ret = kstrtoul(buf, 0, &tid);
+ if (ret)
+ return ret;
if (tid >= IEEE80211_NUM_TIDS)
return -EINVAL;
diff --git a/net/netfilter/nf_conntrack_core.c b/net/netfilter/nf_conntrack_core.c
index af17516..08cdc71 100644
--- a/net/netfilter/nf_conntrack_core.c
+++ b/net/netfilter/nf_conntrack_core.c
@@ -1409,7 +1409,7 @@ EXPORT_SYMBOL_GPL(nf_ct_alloc_hashtable);
int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp)
{
- int i, bucket;
+ int i, bucket, rc;
unsigned int hashsize, old_size;
struct hlist_nulls_head *hash, *old_hash;
struct nf_conntrack_tuple_hash *h;
@@ -1422,7 +1422,9 @@ int nf_conntrack_set_hashsize(const char *val, struct kernel_param *kp)
if (!nf_conntrack_htable_size)
return param_set_uint(val, kp);
- hashsize = simple_strtoul(val, NULL, 0);
+ rc = kstrtouint(val, 0, &hashsize);
+ if (rc)
+ return rc;
if (!hashsize)
return -EINVAL;
--
1.7.7.6
^ permalink raw reply related
* Re: [PATCH RESEND] net: remove obsolete simple_strto<foo>
From: Abhijit Pawar @ 2012-12-11 3:33 UTC (permalink / raw)
To: David Miller
Cc: abhi.c.pawar, pablo, kaber, kuznet, jmorris, yoshfuji, linville,
johannes, amwang, edumazet, nhorman, joe, netdev, linux-kernel,
netfilter-devel, netfilter, coreteam, linux-wireless
In-Reply-To: <20121210.141002.450030380391247897.davem@davemloft.net>
On 12/11/2012 12:40 AM, David Miller wrote:
> From: Abhijit Pawar <abhi.c.pawar@gmail.com>
> Date: Mon, 10 Dec 2012 14:42:28 +0530
>
>> This patch replace the obsolete simple_strto<foo> with kstrto<foo>
>>
>> Signed-off-by: Abhijit Pawar <abhi.c.pawar@gmail.com>
>
> Applied.
>
Hi David,
It seems that there are occurences of simple_strto* still present in the
couple of files which are not yet removed correctly by this patch. I
will send a modified patch shortly. Please revert this commit and use
the newly sent patch to merge with the tree.
--
-
Abhijit
^ permalink raw reply
* Hello Do you need a loan?
From: intercomloanfirmservice @ 2012-12-11 3:23 UTC (permalink / raw)
Hello
Do you need a loan?
If yes, then you have no problem because all we are doing is
give credit to the pepole 3% rates with us, you are sure of your sum
credit.
We are making history, and many others.
as we are the best online lenders have loans internet.We different
customers in Singapore, United States of America and its
surroundings.
You can contact us by.
mail: starbicloanagency@gmail.com
^ permalink raw reply
* Re: [PATCH][RFC] smsc95xx: enable dynamic autosuspend (RFC)
From: Ming Lei @ 2012-12-11 2:24 UTC (permalink / raw)
To: Steve Glendinning
Cc: Oliver Neukum, Steve Glendinning, netdev,
linux-usb-u79uwXL29TY76Z2rM5mHXA, Greg Kroah-Hartman
In-Reply-To: <CAKh2mn5LgZBJDJWNzN8A3NK72Vk_fiUjJfmdn5njSrm400q36w-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Mon, Dec 10, 2012 at 10:18 PM, Steve Glendinning <steve-nksJyM/082jR7s880joybQ@public.gmane.org> wrote:
> On 10 December 2012 12:09, Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote:
>> So this is a problem with remote wakeup on older hardware?
>
> Exactly, the older hardware revisions can't reliably do it.
>
>>> Unfortunately we don't know if the connected device supports
>>> this feature until we query its ID register at runtime.
>>>
>>> Suggestions on how best to indicate this capability at runtime
>>> instead of compile-time would be appreciated, so we don't have
>>> to repeatedly fail if accidentally enabled. Or maybe this is
>>> actually the best way?
>>
>> If this is a problem with remote wakeup, you should up the
>> pm counter (usb_autopm_get_noresume()) in .manage_power
>> That was the reason I implemented this is a callback and not as
>> a helper in usbnet.
>
> Thanks, so something like this should do the job?
This will do, but not simple as clearing .manage_power function
pointer in bind(), and still disable runtime suspend for link off case
since these devices which don't support suspend 3 can generate
remote wakeup for link change event.
I suggest to introduce link-off triggered runtime suspend for these
usbnet devices(non-LAN9500A device, devices which don't support
USB auto-suspend), and I have posted one patch set before[1].
If no one objects that, I'd like to post them again with some fix and
update for checking link after link_reset().
[1], http://marc.info/?w=2&r=1&s=usbnet%3A+support+runtime+PM+triggered+by+&q=t
>
> static int smsc95xx_manage_power(struct usbnet *dev, int on)
> {
> struct smsc95xx_priv *pdata = (struct smsc95xx_priv *)(dev->data[0]);
>
> dev->intf->needs_remote_wakeup = on;
>
> if (pdata->features & FEATURE_AUTOSUSPEND)
> return 0;
>
> /* this chip revision doesn't support autosuspend */
> netdev_info(dev->net, "hardware doesn't support USB autosuspend\n");
>
> if (on)
> usb_autopm_get_interface_no_resume(dev->intf);
> else
> usb_autopm_put_interface_no_suspend(dev->intf);
>
> return 0;
> }
Thanks,
--
Ming Lei
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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
* request to queue patches for stable
From: CAI Qian @ 2012-12-11 2:03 UTC (permalink / raw)
To: netdev
In-Reply-To: <20121206.222321.485936471142281291.davem@davemloft.net>
----- Original Message -----
> From: "David Miller" <davem@davemloft.net>
> To: caiqian@redhat.com
> Cc: greg@kroah.com, stable@vger.kernel.org, mbizon@freebox.fr, ja@ssi.bg
> Sent: Friday, December 7, 2012 11:23:21 AM
> Subject: Re: [PATCH] ipv4: do not cache looped multicasts
>
> From: CAI Qian <caiqian@redhat.com>
> Date: Thu, 6 Dec 2012 21:56:35 -0500 (EST)
>
> > OK, I have a few network patches in the queue that looks applicable
> > to
> > the stable as well. I think I'll send them out here too to seek
> > their
> > ACKs. David, please let me know if I should stop doing this.
>
> Please stop doing this.
>
> If you want networking patches to reach stable, first
> consult:
>
> http://patchwork.ozlabs.org/bundle/davem/stable/
>
> to see if the patch you want isn't queued up already.
>
> If it is not, ask me to queue it up on netdev@vger.kernel.org
>
> But note that I like to let networking patches "cook" upstream
> in Linus's tree for a certain amount of time before I submit
> them to -stable. There can be up to even a week or two.
Dave, the following patches looks applicable for the stable
releases. Please queue them up if you agree.
0e376bd0b791ac6ac6bdb051492df0769c840848 (for 3.0.x, 3.4.x and 3.6.x)
e196c0e579902f42cf72414461fb034e5a1ffbf7 (for 3.0.x, 3.4.x and 3.6.x)
6e51fe7572590d8d86e93b547fab6693d305fd0d (for 3.0.x, 3.4.x and 3.6.x)
e1a676424c290b1c8d757e3860170ac7ecd89af4 (for 3.6.x)
636174219b52b5a8bc51bc23bbcba97cd30a65e3 (for 3.6.x)
CAI Qian
^ permalink raw reply
* [PATCH] tun: allow setting ethernet addresss while running
From: Stephen Hemminger @ 2012-12-11 1:16 UTC (permalink / raw)
To: davem; +Cc: netdev, jasowang, Stephen Hemminger
This is a pure software device, and ok with live address change.
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/tun.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/net/tun.c b/drivers/net/tun.c
index 14a0454..2ac2164 100644
--- a/drivers/net/tun.c
+++ b/drivers/net/tun.c
@@ -849,6 +849,7 @@ static void tun_net_init(struct net_device *dev)
/* Ethernet TAP Device */
ether_setup(dev);
dev->priv_flags &= ~IFF_TX_SKB_SHARING;
+ dev->priv_flags |= IFF_LIVE_ADDR_CHANGE;
eth_hw_addr_random(dev);
--
1.7.10.4
^ permalink raw reply related
* RE: [net-next 1/7] bna: Code Cleanup and Enhancements
From: Rasesh Mody @ 2012-12-11 0:39 UTC (permalink / raw)
To: David Miller
Cc: netdev@vger.kernel.org, bhutchings@solarflare.com,
David.Laight@ACULAB.COM, Adapter Linux Open SRC Team
In-Reply-To: <20121210.171349.1368932708858713762.davem@davemloft.net>
>From: David Miller [mailto:davem@davemloft.net]
>Sent: Monday, December 10, 2012 2:14 PM
>
>From: Rasesh Mody <rmody@brocade.com>
>Date: Mon, 10 Dec 2012 13:41:59 -0800
>
>> - skb = unmap_array[unmap_cons].skb;
>> - BUG_ON(!(skb));
>> - unmap_array[unmap_cons].skb = NULL;
>> + curr_ua = &unmap_array[unmap_cons];
>> +
>> + skb = curr_ua->skb;
>> + BUG_ON(!(skb));\
> ^^^
>
>Really?
>
>Please carefully review your own work before submitting it for
>inclusion. When you have erroneous things like this in the very first
>patch it reflects very poorly upon the quality of your work.
Sorry Dave, it accidentally got introduced. I will rectify it and resend the patches after carefully reviewing patches for similar errors.
Thanks
Rasesh
^ permalink raw reply
* Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
From: Ani Sinha @ 2012-12-11 0:11 UTC (permalink / raw)
To: Michael Richardson
Cc: Eric W. Biederman, tcpdump-workers, netdev, Francesco Ruggeri
In-Reply-To: <8795.1354845553@obiwan.sandelman.ca>
On Thu, 6 Dec 2012, Michael Richardson wrote:
> Date: Thu, 6 Dec 2012 17:59:13
> From: Michael Richardson <mcr@sandelman.ca>
> To: Eric W. Biederman <ebiederm@xmission.com>
> Cc: ani@aristanetworks.com, tcpdump-workers@lists.tcpdump.org,
> netdev@vger.kernel.org, Francesco Ruggeri <fruggeri@aristanetworks.com>
> Subject: Re: [tcpdump-workers] vlan tagged packets and libpcap breakage
>
>
> >>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> Eric> It is a bit odd that you are indenting with spaces instead of tabs
> Eric> in a file that is indented with tab. Again libpcap isn't my code so I
> Eric> don't care but someone else might.
Here's an updated patch. I have converted spaces to tabs consistent with
rest of the file. I have also set up github and sent a pull request
:
commit b977ebd9d9608bb8a8e4927e7a6286bdfd6b94a8
Author: Ani Sinha <ani@aristanetworks.com>
Date: Mon Dec 10 14:58:15 2012 -0800
Linux kernel 3.0 uses TP_STATUS_VLAN_VALID flag in packet
auxilliary data aux->tp_status to indicate a packet tagged
with a valid vlan ID 0 with another packet that is not
vlan tagged. Use this flag to check for the presence of
a vlan tagged packet. Also be careful not to cause any
breakage when libpcap is compiled against a newer kernel
(>=3.0) and used on top of an older kernel that does not
use this flag.
Signed-off-by: Ani Sinha <ani@aristanetworks.com>
diff --git a/pcap-linux.c b/pcap-linux.c
index a42c3ac..ffcabdf 100644
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -133,6 +133,7 @@ static const char rcsid[] _U_ =
#include <sys/utsname.h>
#include <sys/mman.h>
#include <linux/if.h>
+#include <linux/if_packet.h>
#include <netinet/in.h>
#include <linux/if_ether.h>
#include <net/if_arp.h>
@@ -1543,7 +1544,13 @@ pcap_read_packet(pcap_t *handle, pcap_handler callback, u_char *userdata)
continue;
aux = (struct tpacket_auxdata *)CMSG_DATA(cmsg);
- if (aux->tp_vlan_tci == 0)
+#if defined(TP_STATUS_VLAN_VALID)
+ if ((aux->tp_vlan_tci == 0) && !(aux->tp_status & TP_STATUS_VLAN_VALID))
+#else
+ if (aux->tp_vlan_tci == 0) /* this is ambigious but without the
+ TP_STATUS_VLAN_VALID flag, there is
+ nothing that we can do */
+#endif
continue;
len = packet_len > iov.iov_len ? iov.iov_len : packet_len;
@@ -3936,7 +3943,12 @@ pcap_read_linux_mmap(pcap_t *handle, int max_packets, pcap_handler callback,
}
#ifdef HAVE_TPACKET2
- if (handle->md.tp_version == TPACKET_V2 && h.h2->tp_vlan_tci &&
+ if ((handle->md.tp_version == TPACKET_V2) &&
+#if defined(TP_STATUS_VLAN_VALID)
+ (h.h2->tp_vlan_tci || (h.h2->tp_status & TP_STATUS_VLAN_VALID)) &&
+#else
+ h.h2->tp_vlan_tci &&
+#endif
handle->md.vlan_offset != -1 &&
tp_snaplen >= (unsigned int) handle->md.vlan_offset) {
struct vlan_tag *tag;
^ permalink raw reply related
* Re: linux-next: build failure after merge of the virtio tree
From: Rusty Russell @ 2012-12-10 22:41 UTC (permalink / raw)
To: Stephen Rothwell
Cc: linux-next, linux-kernel, Jason Wang, David Miller, netdev
In-Reply-To: <20121210133725.cb4a76545691b099c73c40ea@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> writes:
> Hi Rusty,
>
> After merging the virtio tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/net/virtio_net.c: In function 'vq2txq':
> drivers/net/virtio_net.c:150:2: error: implicit declaration of function 'virtqueue_get_queue_index' [-Werror=implicit-function-declaration]
>
> Caused by commit 986a4f4d452d ("virtio_net: multiqueue support") from the
> net-next tree interacting with commit 105e892960e1 ("virtio: move
> queue_index and num_free fields into core struct virtqueue") from the
> virtio tree.
>
> I applied the patch below and can carry it as necessary.
Thanks for this, your fix is correct.
Cheers,
Rusty.
^ permalink raw reply
* Re: [PATCHv7] virtio-spec: virtio network device multiqueue support
From: Rusty Russell @ 2012-12-10 23:50 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: bhutchings, netdev, kvm, virtualization
In-Reply-To: <20121210104025.GA26640@redhat.com>
"Michael S. Tsirkin" <mst@redhat.com> writes:
> Add multiqueue support to virtio network device.
> Add a new feature flag VIRTIO_NET_F_MQ for this feature, a new
> configuration field max_virtqueue_pairs to detect supported number of
> virtqueues as well as a new command VIRTIO_NET_CTRL_MQ to program
> packet steering for unidirectional protocols.
>
> Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
Thanks, applied.
Cheers,
Rusty.
^ permalink raw reply
* [PATCH net-next] net: gro: dev_gro_receive() cleanup
From: Eric Dumazet @ 2012-12-10 23:28 UTC (permalink / raw)
To: David Miller; +Cc: netdev
From: Eric Dumazet <edumazet@google.com>
__napi_gro_receive() is inlined from two call sites for no good reason.
Lets move the prep stuff in a function of its own, called only if/when
needed. This saves 300 bytes on x86 :
# size net/core/dev.o.after net/core/dev.o.before
text data bss dec hex filename
51968 1238 1040 54246 d3e6 net/core/dev.o.before
51664 1238 1040 53942 d2b6 net/core/dev.o.after
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
net/core/dev.c | 52 +++++++++++++++++++++++------------------------
1 file changed, 26 insertions(+), 26 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index a4c4a1b..4783850 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -3603,6 +3603,28 @@ void napi_gro_flush(struct napi_struct *napi, bool flush_old)
}
EXPORT_SYMBOL(napi_gro_flush);
+static void gro_list_prepare(struct napi_struct *napi, struct sk_buff *skb)
+{
+ struct sk_buff *p;
+ unsigned int maclen = skb->dev->hard_header_len;
+
+ for (p = napi->gro_list; p; p = p->next) {
+ unsigned long diffs;
+
+ diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
+ diffs |= p->vlan_tci ^ skb->vlan_tci;
+ if (maclen == ETH_HLEN)
+ diffs |= compare_ether_header(skb_mac_header(p),
+ skb_gro_mac_header(skb));
+ else if (!diffs)
+ diffs = memcmp(skb_mac_header(p),
+ skb_gro_mac_header(skb),
+ maclen);
+ NAPI_GRO_CB(p)->same_flow = !diffs;
+ NAPI_GRO_CB(p)->flush = 0;
+ }
+}
+
static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
struct sk_buff **pp = NULL;
@@ -3619,6 +3641,8 @@ static enum gro_result dev_gro_receive(struct napi_struct *napi, struct sk_buff
if (skb_is_gso(skb) || skb_has_frag_list(skb))
goto normal;
+ gro_list_prepare(napi, skb);
+
rcu_read_lock();
list_for_each_entry_rcu(ptype, head, list) {
if (ptype->type != type || !ptype->callbacks.gro_receive)
@@ -3695,30 +3719,6 @@ normal:
goto pull;
}
-static inline gro_result_t
-__napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
-{
- struct sk_buff *p;
- unsigned int maclen = skb->dev->hard_header_len;
-
- for (p = napi->gro_list; p; p = p->next) {
- unsigned long diffs;
-
- diffs = (unsigned long)p->dev ^ (unsigned long)skb->dev;
- diffs |= p->vlan_tci ^ skb->vlan_tci;
- if (maclen == ETH_HLEN)
- diffs |= compare_ether_header(skb_mac_header(p),
- skb_gro_mac_header(skb));
- else if (!diffs)
- diffs = memcmp(skb_mac_header(p),
- skb_gro_mac_header(skb),
- maclen);
- NAPI_GRO_CB(p)->same_flow = !diffs;
- NAPI_GRO_CB(p)->flush = 0;
- }
-
- return dev_gro_receive(napi, skb);
-}
static gro_result_t napi_skb_finish(gro_result_t ret, struct sk_buff *skb)
{
@@ -3768,7 +3768,7 @@ gro_result_t napi_gro_receive(struct napi_struct *napi, struct sk_buff *skb)
{
skb_gro_reset_offset(skb);
- return napi_skb_finish(__napi_gro_receive(napi, skb), skb);
+ return napi_skb_finish(dev_gro_receive(napi, skb), skb);
}
EXPORT_SYMBOL(napi_gro_receive);
@@ -3866,7 +3866,7 @@ gro_result_t napi_gro_frags(struct napi_struct *napi)
if (!skb)
return GRO_DROP;
- return napi_frags_finish(napi, skb, __napi_gro_receive(napi, skb));
+ return napi_frags_finish(napi, skb, dev_gro_receive(napi, skb));
}
EXPORT_SYMBOL(napi_gro_frags);
^ permalink raw reply related
* Re: [PATCH] smsc75xx: only set mac address once on bind
From: Dan Williams @ 2012-12-10 23:00 UTC (permalink / raw)
To: Steve Glendinning; +Cc: netdev, Bjorn Mork
In-Reply-To: <1355137279-2695-1-git-send-email-steve.glendinning@shawell.net>
On Mon, 2012-12-10 at 11:01 +0000, Steve Glendinning wrote:
> This patch changes when we decide what the device's MAC address
> is from per ifconfig up to once when the device is connected.
>
> Without this patch, a manually forced device MAC is overwritten
> on ifconfig down/up. Also devices that have no EEPROM are
> assigned a new random address on ifconfig down/up instead of
> persisting the same one.
Does this mean that on devices without EEPROM, ifconfig XXX
down/ifconfig XXX up will generate a *new* random address? That seems a
bit odd; why wouldn't the first random address generated for the device
persist until either (a) changed by ifconfig or (b) device was
disconnected?
Dan
> Signed-off-by: Steve Glendinning <steve.glendinning@shawell.net>
> Reported-by: Robert Cunningham <rcunningham@nsmsurveillance.com>
> Cc: Bjorn Mork <bjorn@mork.no>
> Cc: Dan Williams <dcbw@redhat.com>
> ---
> drivers/net/usb/smsc75xx.c | 10 ++++++++--
> 1 file changed, 8 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/net/usb/smsc75xx.c b/drivers/net/usb/smsc75xx.c
> index 1cbd936..251a335 100644
> --- a/drivers/net/usb/smsc75xx.c
> +++ b/drivers/net/usb/smsc75xx.c
> @@ -1054,8 +1054,6 @@ static int smsc75xx_reset(struct usbnet *dev)
>
> netif_dbg(dev, ifup, dev->net, "PHY reset complete\n");
>
> - smsc75xx_init_mac_address(dev);
> -
> ret = smsc75xx_set_mac_address(dev);
> if (ret < 0) {
> netdev_warn(dev->net, "Failed to set mac address\n");
> @@ -1422,6 +1420,14 @@ static int smsc75xx_bind(struct usbnet *dev, struct usb_interface *intf)
> dev->net->hw_features = NETIF_F_IP_CSUM | NETIF_F_IPV6_CSUM |
> NETIF_F_SG | NETIF_F_TSO | NETIF_F_TSO6 | NETIF_F_RXCSUM;
>
> + ret = smsc75xx_wait_ready(dev, 0);
> + if (ret < 0) {
> + netdev_warn(dev->net, "device not ready in smsc75xx_bind\n");
> + return ret;
> + }
> +
> + smsc75xx_init_mac_address(dev);
> +
> /* Init all registers */
> ret = smsc75xx_reset(dev);
> if (ret < 0) {
^ permalink raw reply
* RE: [PATCH net-next] bnx2x: use netdev_alloc_frag()
From: Dmitry Kravkov @ 2012-12-10 22:57 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev, Eilon Greenstein
In-Reply-To: <1355177766.27891.68.camel@edumazet-glaptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Tuesday, December 11, 2012 12:16 AM
> To: David Miller
> Cc: netdev; Eilon Greenstein; Dmitry Kravkov
> Subject: [PATCH net-next] bnx2x: use netdev_alloc_frag()
>
> From: Eric Dumazet <edumazet@google.com>
>
> Using netdev_alloc_frag() instead of kmalloc() permits better GRO or
> TCP coalescing behavior, as skb_gro_receive() doesn't have to fallback
> to frag_list overhead.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Dmitry Kravkov <dmitry@broadcom.com>
> Cc: Eilon Greenstein <eilong@broadcom.com>
Thanks a lot, Eric!
Acked-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
* RE: [PATCH] net: fix a race in gro_cell_poll()
From: Dmitry Kravkov @ 2012-12-10 22:46 UTC (permalink / raw)
To: Eric Dumazet, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <1355178723.27891.85.camel@edumazet-glaptop>
> -----Original Message-----
> From: Eric Dumazet [mailto:eric.dumazet@gmail.com]
> Sent: Tuesday, December 11, 2012 12:32 AM
> To: Dmitry Kravkov; David Miller
> Cc: netdev@vger.kernel.org
> Subject: [PATCH] net: fix a race in gro_cell_poll()
>
> From: Eric Dumazet <edumazet@google.com>
>
> Dmitry Kravkov reported packet drops for GRE packets since GRO support
> was added.
>
> There is a race in gro_cell_poll() because we call napi_complete()
> without any synchronization with a concurrent gro_cells_receive()
>
> Once bug was triggered, we queued packets but did not schedule NAPI
> poll.
>
> We can fix this issue using the spinlock protected the napi_skbs queue,
> as we have to hold it to perform skb dequeue anyway.
>
> As we open-code skb_dequeue(), we no longer need to mask IRQS, as both
> producer and consumer run under BH context.
>
> Bug added in commit c9e6bc644e (net: add gro_cells infrastructure)
>
> Reported-by: Dmitry Kravkov <dmitry@broadcom.com>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> ---
>
> David: I could reproduce the bug Dmitry reported, and have
> verified this patch fixes the issue.
>
> include/net/gro_cells.h | 14 +++++++++-----
> 1 file changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
> index 4fd8a4b..e5062c9 100644
> --- a/include/net/gro_cells.h
> +++ b/include/net/gro_cells.h
> @@ -17,7 +17,6 @@ struct gro_cells {
>
> static inline void gro_cells_receive(struct gro_cells *gcells, struct sk_buff *skb)
> {
> - unsigned long flags;
> struct gro_cell *cell = gcells->cells;
> struct net_device *dev = skb->dev;
>
> @@ -35,32 +34,37 @@ static inline void gro_cells_receive(struct gro_cells
> *gcells, struct sk_buff *s
> return;
> }
>
> - spin_lock_irqsave(&cell->napi_skbs.lock, flags);
> + /* We run in BH context */
> + spin_lock(&cell->napi_skbs.lock);
>
> __skb_queue_tail(&cell->napi_skbs, skb);
> if (skb_queue_len(&cell->napi_skbs) == 1)
> napi_schedule(&cell->napi);
>
> - spin_unlock_irqrestore(&cell->napi_skbs.lock, flags);
> + spin_unlock(&cell->napi_skbs.lock);
> }
>
> +/* called unser BH context */
> static inline int gro_cell_poll(struct napi_struct *napi, int budget)
> {
> struct gro_cell *cell = container_of(napi, struct gro_cell, napi);
> struct sk_buff *skb;
> int work_done = 0;
>
> + spin_lock(&cell->napi_skbs.lock);
> while (work_done < budget) {
> - skb = skb_dequeue(&cell->napi_skbs);
> + skb = __skb_dequeue(&cell->napi_skbs);
> if (!skb)
> break;
> -
> + spin_unlock(&cell->napi_skbs.lock);
> napi_gro_receive(napi, skb);
> work_done++;
> + spin_lock(&cell->napi_skbs.lock);
> }
>
> if (work_done < budget)
> napi_complete(napi);
> + spin_unlock(&cell->napi_skbs.lock);
> return work_done;
> }
>
>
My scenario is working, now
Thanks Eric.
Tested-by: Dmitry Kravkov <dmitry@broadcom.com>
^ permalink raw reply
* Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices
From: Paul Moore @ 2012-12-10 22:43 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: netdev, linux-security-module, selinux, jasowang
In-Reply-To: <20121210175035.GA31856@redhat.com>
On Monday, December 10, 2012 07:50:35 PM Michael S. Tsirkin wrote:
> On Mon, Dec 10, 2012 at 12:33:49PM -0500, Paul Moore wrote:
> > On Monday, December 10, 2012 07:26:56 PM Michael S. Tsirkin wrote:
> > > On Mon, Dec 10, 2012 at 12:04:35PM -0500, Paul Moore wrote:
> > > > On Friday, December 07, 2012 02:25:16 PM Michael S. Tsirkin wrote:
> > > > > On Thu, Dec 06, 2012 at 04:09:51PM -0500, Paul Moore wrote:
> > > > > > On Thursday, December 06, 2012 10:57:16 PM Michael S. Tsirkin
wrote:
> > > > > > > On Thu, Dec 06, 2012 at 11:56:45AM -0500, Paul Moore wrote:
> > > > > > > > The SETQUEUE/tun_socket:create_queue permissions do not yet
> > > > > > > > exist
> > > > > > > > in any released SELinux policy as we are just now adding them
> > > > > > > > with
> > > > > > > > this patchset. With current policies loaded into a kernel with
> > > > > > > > this patchset applied the SETQUEUE/tun_socket:create_queue
> > > > > > > > permission would be treated according to the policy's unknown
> > > > > > > > permission setting.
> > > > > > >
> > > > > > > OK I think we need to rethink what we are doing here: what you
> > > > > > > sent
> > > > > > > addresses the problem as stated but I think we mis-stated it.
> > > > > > > Let
> > > > > > > me try to restate the problem: it is not just selinux problem.
> > > > > > > Let's
> > > > > > > assume qemu wants to use tun, I (libvirt) don't want to run it
> > > > > > > as
> > > > > > > root.
> > > > > > >
> > > > > > > 1. TUNSETIFF: I can open tun, attach an fd and pass it to qemu.
> > > > > > > Now, qemu does not invoke TUNSETIFF so it can run without
> > > > > > > kernel priveledges.
> > > > > >
> > > > > > Correct me if I'm wrong, but I believe libvirt does this while
> > > > > > running
> > > > > > as root. Assuming that is the case, why not simply
> > > > > > setuid()/setgid()
> > > > > > to the same credentials as the QEMU instance before creating the
> > > > > > TUN
> > > > > > device? You can always (re)configure the device afterwards while
> > > > > > running as root/CAP_NET_ADMIN.
> > > > >
> > > > > We want isolation between qemu instances.
> > > >
> > > > Understood, I agree.
> > > >
> > > > Achieving separation via SELinux is easily done, with libvirt/sVirt
> > > > already doing this for us automatically in most cases; the only thing
> > > > we
> > > > will want to do is make sure the SELinux policy is aware of the new
> > > > permission.
> > > >
> > > > Achieving separation via DAC should also be easily done, simply run
> > > > each
> > > > QEMU instance with a separate UID and/or GID.
> > > >
> > > > > Giving qemu right to open tun and SETIFF would give it rights
> > > > > to access any tun device.
> > > >
> > > > I'm quickly looked at tun_chr_open() again and I don't see any special
> > > > rights/privileges required, the same for tun_chr_ioctl() and
> > > > __tun_chr_ioctl(). Looking at tun_set_queue() I see we call
> > > > tun_not_capable() which does a simple DAC check; it must have the same
> > > > UID/GID or have CAP_NET_ADMIN.
> > > >
> > > > I'm having a hard time seeing the problem you are describing; help me
> > > > understand.
> > >
> > > The issue is guest controls the number of queues in use.
> > > So qemu would be required to be allowed to call tun_set_queue.
> > > If we allow this we have a problem as one qemu will be
> > > able to access any tun.
> >
> > QEMU can call tun_set_queue() as long as it satisfies tun_not_capable(),
> > which from a practical point of view means that the TUN device was
> > created with the same UID/GID as the QEMU instance. If you want TUN
> > device separation between QEMU instances using DAC you need to run each
> > QEMU instance with a different UID/GID (which you should be doing anyway
> > if you want DAC enforced general separation).
> >
> > I believe I've stated this point several times now and I don't feel you've
> > addressed it properly.
>
> Look at how it works at the moment:
> a priveledged libvirt server calls tun_set_iff
> and passes the fd to qemu which is not priveledged.
>
> The result is isolation between qemu instances without
> need to create uid per qemu instance.
Okay, good. That is my understanding.
> How do we create multiple queues? It makes sense to
> follow this model and pass in fds for individual queues.
Okay.
> However they need to be disabled initially
> so libvirt can not do tun_set_queue for us.
Unrelated question: why do the queues need to be disabled initially? Is this
to prevent traffic from being queued up? Some other reason? I'm just curious
as to the reason ...
> When qemu later calls tun_set_queue it will fail which means we
> can't utilize multiqueue.
I still don't understand why in the multiqueue case libvirt doesn't just
change it's effective UID/GID when creating the TUN device, or just use the
TUNSETOWNER/TUNSETGROUP commands. This would solve the problem you describe
above and - at least to me - seems like a better solution conceptually.
Help me understand why you believe that will not work.
Do you not want to give ownership of the TUN device to QEMU? That would be
the only reason I can think of, but all of your comments that I can recall
have been about isolation between QEMU instances and not access control
between a QEMU instance and its assigned TUN device.
> My solution is an unpriveledged variant
> of tun_set_queue that only enables/disables
> a queue without attach/detach.
--
paul moore
security and virtualization @ redhat
^ permalink raw reply
* [PATCH] net: fix a race in gro_cell_poll()
From: Eric Dumazet @ 2012-12-10 22:32 UTC (permalink / raw)
To: Dmitry Kravkov, David Miller; +Cc: netdev@vger.kernel.org
In-Reply-To: <1355176551.27891.57.camel@edumazet-glaptop>
From: Eric Dumazet <edumazet@google.com>
Dmitry Kravkov reported packet drops for GRE packets since GRO support
was added.
There is a race in gro_cell_poll() because we call napi_complete()
without any synchronization with a concurrent gro_cells_receive()
Once bug was triggered, we queued packets but did not schedule NAPI
poll.
We can fix this issue using the spinlock protected the napi_skbs queue,
as we have to hold it to perform skb dequeue anyway.
As we open-code skb_dequeue(), we no longer need to mask IRQS, as both
producer and consumer run under BH context.
Bug added in commit c9e6bc644e (net: add gro_cells infrastructure)
Reported-by: Dmitry Kravkov <dmitry@broadcom.com>
Signed-off-by: Eric Dumazet <edumazet@google.com>
---
David: I could reproduce the bug Dmitry reported, and have
verified this patch fixes the issue.
include/net/gro_cells.h | 14 +++++++++-----
1 file changed, 9 insertions(+), 5 deletions(-)
diff --git a/include/net/gro_cells.h b/include/net/gro_cells.h
index 4fd8a4b..e5062c9 100644
--- a/include/net/gro_cells.h
+++ b/include/net/gro_cells.h
@@ -17,7 +17,6 @@ struct gro_cells {
static inline void gro_cells_receive(struct gro_cells *gcells, struct sk_buff *skb)
{
- unsigned long flags;
struct gro_cell *cell = gcells->cells;
struct net_device *dev = skb->dev;
@@ -35,32 +34,37 @@ static inline void gro_cells_receive(struct gro_cells *gcells, struct sk_buff *s
return;
}
- spin_lock_irqsave(&cell->napi_skbs.lock, flags);
+ /* We run in BH context */
+ spin_lock(&cell->napi_skbs.lock);
__skb_queue_tail(&cell->napi_skbs, skb);
if (skb_queue_len(&cell->napi_skbs) == 1)
napi_schedule(&cell->napi);
- spin_unlock_irqrestore(&cell->napi_skbs.lock, flags);
+ spin_unlock(&cell->napi_skbs.lock);
}
+/* called unser BH context */
static inline int gro_cell_poll(struct napi_struct *napi, int budget)
{
struct gro_cell *cell = container_of(napi, struct gro_cell, napi);
struct sk_buff *skb;
int work_done = 0;
+ spin_lock(&cell->napi_skbs.lock);
while (work_done < budget) {
- skb = skb_dequeue(&cell->napi_skbs);
+ skb = __skb_dequeue(&cell->napi_skbs);
if (!skb)
break;
-
+ spin_unlock(&cell->napi_skbs.lock);
napi_gro_receive(napi, skb);
work_done++;
+ spin_lock(&cell->napi_skbs.lock);
}
if (work_done < budget)
napi_complete(napi);
+ spin_unlock(&cell->napi_skbs.lock);
return work_done;
}
^ permalink raw reply related
* [GIT] Networking
From: David Miller @ 2012-12-10 22:31 UTC (permalink / raw)
To: torvalds; +Cc: akpm, netdev, linux-kernel
1) Netlink socket dumping had several missing verifications and
checks.
In particular, address comparisons in the request byte code
interpreter could access past the end of the address in the
inet_request_sock.
Also, address family and address prefix lengths were not
validated properly at all.
This means arbitrary applications can read past the end of
certain kernel data structures.
Fixes from Neal Cardwell.
2) ip_check_defrag() operates in contexts where we're in the
process of, or about to, input the packet into the real
protocols (specifically macvlan and AF_PACKET snooping).
Unfortunately, it does a pskb_may_pull() which can modify
the backing packet data which is not legal if the SKB is
shared. It very much can be shared in this context.
Deal with the possibility that the SKB is segmented by
using skb_copy_bits().
Fix from Johannes Berg based upon a report by Eric Leblond.
Please pull, thanks a lot!
The following changes since commit ed23ec4f0a510528e0ffe415f9394107418ae854:
mm: vmscan: fix inappropriate zone congestion clearing (2012-12-08 08:41:18 -0800)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/davem/net.git master
for you to fetch changes up to 1bf3751ec90cc3174e01f0d701e8449ce163d113:
ipv4: ip_check_defrag must not modify skb before unsharing (2012-12-10 13:51:44 -0500)
----------------------------------------------------------------
Johannes Berg (1):
ipv4: ip_check_defrag must not modify skb before unsharing
Neal Cardwell (4):
inet_diag: fix oops for IPv4 AF_INET6 TCP SYN-RECV state
inet_diag: validate byte code to prevent oops in inet_diag_bc_run()
inet_diag: avoid unsafe and nonsensical prefix matches in inet_diag_bc_run()
inet_diag: validate port comparison byte code to prevent unsafe reads
net/ipv4/inet_diag.c | 154 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---------------------
net/ipv4/ip_fragment.c | 19 ++++++-------
2 files changed, 131 insertions(+), 42 deletions(-)
^ permalink raw reply
* Re: [RFC PATCH v2 3/3] tun: fix LSM/SELinux labeling of tun/tap devices
From: Paul Moore @ 2012-12-10 22:21 UTC (permalink / raw)
To: Eric Paris
Cc: Michael S. Tsirkin, Linux Netdev List, LSM List, SE-Linux,
jasowang
In-Reply-To: <CACLa4pu6UCpzKfscVoEPzLySHitta1yTqPa7cA0d=xUj5ws6HA@mail.gmail.com>
On Monday, December 10, 2012 01:42:12 PM Eric Paris wrote:
> Let me abstract a little here Paul. Lets say user A starts an
> unclassified process and a top secret process. SELinux policy darn
> well better be able to enforce that they can not attach to the same
> tun.
>
> Am I missing something here?
Relax, all the SELinux enforced separation still exists, and works. We're
just fixing the LSM/SELinux stuff that was broken with the multiqueue addition
and adding a new SELinux permission to control access to the new queue
command.
What we are currently discussing is DAC only. While Michael have different
opinions on how to solve the DAC issues, we agree that SELinux works
correctly.
--
paul moore
security and virtualization @ redhat
^ 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