* Re: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Andy Gospodarek @ 2013-01-17 1:10 UTC (permalink / raw)
To: Williams, Mitch A
Cc: Rose, Gregory V, Stefan Assmann, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D2A3468AE@FMSMSX107.amr.corp.intel.com>
On Wed, Jan 16, 2013 at 7:42 PM, Williams, Mitch A
<mitch.a.williams@intel.com> wrote:
>
> > -----Original Message-----
> > From: Rose, Gregory V
> > Sent: Tuesday, January 15, 2013 10:32 AM
> > To: Andy Gospodarek
> > Cc: Williams, Mitch A; Stefan Assmann; netdev@vger.kernel.org; e1000-
> > devel@lists.sourceforge.net
> > Subject: Re: [E1000-devel] [PATCH net-next] igbvf: fix setting
> > addr_assign_type if PF is up
> >
> > On Mon, 14 Jan 2013 17:25:42 -0500
> > Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> > > On Wed, Jan 09, 2013 at 01:37:45PM -0800, Greg Rose wrote:
> > > > On Wed, 9 Jan 2013 18:56:36 +0000
> > > > "Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> > > >
> > > > > > >> When the PF is up and igbvf is loaded the MAC address is not
> > > > > > >> generated using eth_hw_addr_random(). This results in
> > > > > > >> addr_assign_type not to be set.
> > > > > > >> Make sure it gets set.
> > > > > > >>
> > > > > > >
> > > > > > > NAK - In this case, the address may or may not be random. The
> > > > > > > user may have (and should have!) explicitly set this address
> > > > > > > from the host to ensure that the VF device receives the same
> > > > > > > address each time it
> > > > > > boots.
> > > > > >
> > > > > > Maybe you can give me some advice on this then. Why is there
> > > > > > different behaviour depending on the PF being up or down? The
> > > > > > problem I'm facing is that if the user did not set a MAC address
> > > > > > for the VF manually and the PF is up during igbvf_probe it will
> > > > > > not be labelled as random although it is.
> > > > > > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > > > > > NET_ADDR_RANDOM if the flag is cleared?
> > > > > >
> > > > >
> > > > > The difference in behavior is because we cannot get any MAC
> > > > > address at all if the PF is down. The interface won't operate at
> > > > > all in this case, but if the PF comes up sometime later, we can
> > > > > start working. The other alternative is to leave the MAC address
> > > > > as all zeros and forcing the user to assign an address manually.
> > > > > We chose to use a random address to at least give it a chance of
> > > > > working once the PF woke up.
> > > >
> > > > Having been around at the inception of SR-IOV in Linux I recall that
> > > > the primary reason we used a random ethernet address was so that the
> > > > VF could at least work because there was no infrastructure to allow
> > > > the host administrator to set the MAC address of the VF.
> > > > This hobbled testing and validation because the user would have to
> > > > go to each VM and use a command local to the VM to set the VF MAC
> > > > address to some LAA via ifconfig or ip. When testing large numbers
> > > > of VFs this was a definite pain.
> > > >
> > > > Now that has changed and I wonder if maybe we shouldn't back out the
> > > > random ethernet address assignment and go ahead with all zeros,
> > > > leaving the device non-functional until the user has intentionally
> > > > set either an LAA through the VF itself, or an administratively
> > > > assigned MAC through the ip tool via the PF.
> > > >
> > > > Use of the random MAC address is not recommended by Intel's own best
> > > > known methods literature, it was used mostly so that we could get
> > > > the technology working and it should probably be at least considered
> > > > for deprecation or out right elimination.
> > > >
> > >
> > > It would be great to remove the bits that created random MAC addresses
> > > for VFs, but wouldn't that break Linus' rule to "not break userspace"
> > > if it was removed?
> >
> > It may, I'm not sure but before we make any changes we'd want to do our
> > due diligence.
> >
> > >
> > > There are 2 options that immediately come to mind when looking to
> > > resolve this:
> > >
> > > 1. Use some of the left-over bits in the mailbox messages to pass
> > > along a flag with the E1000_VF_RESET messages to indicate whether the
> > > MAC was randomly generated. This would be pretty easy, but there
> > > could be compatibility issues for a while.
> >
> > We recently introduced the concept of mailbox message API versions in
> > our PF and VF drivers to handle this sort of thing. We could probably
> > leverage that method to introduce a new API version that supports the
> > additional bits in the reset message. It would only be used if the VF
> > could negotiate to the proper mailbox message API version with the PF.
> >
> > >
> > > 2. Default to a MAC address of all zeros, and as a device with
> > > all-zeros for a MAC is brought up, randomly create one with
> > > eth_hw_addr_random. This may not immediately help cases where device
> > > assignment are a problem, but it would ensure that any device with a
> > > random MAC as assigned by the kernel, would have NET_ADDR_RANDOM set
> > > in addr_assign_type.
> >
> > Thanks for the suggestions. We're considering some changes in this area
> > but we (Intel) need to give this a lot of thought and right now we're
> > just in a preliminary discussion mode about it. Stay tuned.
> >
> > - Greg
>
> OK, here's what I'm thinking. We don't need to change the communications
> protocol for this, and it shouldn't break userspace.
>
> First, have the PF driver quit assigning random addresses. It will either
> give the VF the address assigned by the administrator, or it will give
> all zeros.
>
> Second, modify the VF driver init sequence slightly. If it gets all
> zeros from the PF driver, then it should give itself a random address
> and set NET_ADDR_RANDOM.
>
> If we do it this way, the VF will still come up with a random address if
> one has not been assigned, and it will always know whether or not the
> address that it is using is random.
>
> If there are no objections, I'll try to get some patches done in the next
> few days and get them into our internal test queue. These would then
> escape into the real world in a few weeks.
>
> -Mitch
Oh, I like this even better than my proposed option 2. I say, go for it.
^ permalink raw reply
* Re: [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Andy Gospodarek @ 2013-01-17 1:06 UTC (permalink / raw)
To: Williams, Mitch A
Cc: e1000-devel@lists.sourceforge.net, Stefan Assmann,
netdev@vger.kernel.org
In-Reply-To: <AAEA33E297BCAC4B9BB20A7C2DF0AB8D2A3468AE@FMSMSX107.amr.corp.intel.com>
[-- Attachment #1.1: Type: text/plain, Size: 6045 bytes --]
On Jan 16, 2013 7:42 PM, "Williams, Mitch A" <mitch.a.williams@intel.com>
wrote:
>
> > -----Original Message-----
> > From: Rose, Gregory V
> > Sent: Tuesday, January 15, 2013 10:32 AM
> > To: Andy Gospodarek
> > Cc: Williams, Mitch A; Stefan Assmann; netdev@vger.kernel.org; e1000-
> > devel@lists.sourceforge.net
> > Subject: Re: [E1000-devel] [PATCH net-next] igbvf: fix setting
> > addr_assign_type if PF is up
> >
> > On Mon, 14 Jan 2013 17:25:42 -0500
> > Andy Gospodarek <andy@greyhouse.net> wrote:
> >
> > > On Wed, Jan 09, 2013 at 01:37:45PM -0800, Greg Rose wrote:
> > > > On Wed, 9 Jan 2013 18:56:36 +0000
> > > > "Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> > > >
> > > > > > >> When the PF is up and igbvf is loaded the MAC address is not
> > > > > > >> generated using eth_hw_addr_random(). This results in
> > > > > > >> addr_assign_type not to be set.
> > > > > > >> Make sure it gets set.
> > > > > > >>
> > > > > > >
> > > > > > > NAK - In this case, the address may or may not be random. The
> > > > > > > user may have (and should have!) explicitly set this address
> > > > > > > from the host to ensure that the VF device receives the same
> > > > > > > address each time it
> > > > > > boots.
> > > > > >
> > > > > > Maybe you can give me some advice on this then. Why is there
> > > > > > different behaviour depending on the PF being up or down? The
> > > > > > problem I'm facing is that if the user did not set a MAC address
> > > > > > for the VF manually and the PF is up during igbvf_probe it will
> > > > > > not be labelled as random although it is.
> > > > > > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > > > > > NET_ADDR_RANDOM if the flag is cleared?
> > > > > >
> > > > >
> > > > > The difference in behavior is because we cannot get any MAC
> > > > > address at all if the PF is down. The interface won't operate at
> > > > > all in this case, but if the PF comes up sometime later, we can
> > > > > start working. The other alternative is to leave the MAC address
> > > > > as all zeros and forcing the user to assign an address manually.
> > > > > We chose to use a random address to at least give it a chance of
> > > > > working once the PF woke up.
> > > >
> > > > Having been around at the inception of SR-IOV in Linux I recall that
> > > > the primary reason we used a random ethernet address was so that the
> > > > VF could at least work because there was no infrastructure to allow
> > > > the host administrator to set the MAC address of the VF.
> > > > This hobbled testing and validation because the user would have to
> > > > go to each VM and use a command local to the VM to set the VF MAC
> > > > address to some LAA via ifconfig or ip. When testing large numbers
> > > > of VFs this was a definite pain.
> > > >
> > > > Now that has changed and I wonder if maybe we shouldn't back out the
> > > > random ethernet address assignment and go ahead with all zeros,
> > > > leaving the device non-functional until the user has intentionally
> > > > set either an LAA through the VF itself, or an administratively
> > > > assigned MAC through the ip tool via the PF.
> > > >
> > > > Use of the random MAC address is not recommended by Intel's own best
> > > > known methods literature, it was used mostly so that we could get
> > > > the technology working and it should probably be at least considered
> > > > for deprecation or out right elimination.
> > > >
> > >
> > > It would be great to remove the bits that created random MAC addresses
> > > for VFs, but wouldn't that break Linus' rule to "not break userspace"
> > > if it was removed?
> >
> > It may, I'm not sure but before we make any changes we'd want to do our
> > due diligence.
> >
> > >
> > > There are 2 options that immediately come to mind when looking to
> > > resolve this:
> > >
> > > 1. Use some of the left-over bits in the mailbox messages to pass
> > > along a flag with the E1000_VF_RESET messages to indicate whether the
> > > MAC was randomly generated. This would be pretty easy, but there
> > > could be compatibility issues for a while.
> >
> > We recently introduced the concept of mailbox message API versions in
> > our PF and VF drivers to handle this sort of thing. We could probably
> > leverage that method to introduce a new API version that supports the
> > additional bits in the reset message. It would only be used if the VF
> > could negotiate to the proper mailbox message API version with the PF.
> >
> > >
> > > 2. Default to a MAC address of all zeros, and as a device with
> > > all-zeros for a MAC is brought up, randomly create one with
> > > eth_hw_addr_random. This may not immediately help cases where device
> > > assignment are a problem, but it would ensure that any device with a
> > > random MAC as assigned by the kernel, would have NET_ADDR_RANDOM set
> > > in addr_assign_type.
> >
> > Thanks for the suggestions. We're considering some changes in this area
> > but we (Intel) need to give this a lot of thought and right now we're
> > just in a preliminary discussion mode about it. Stay tuned.
> >
> > - Greg
>
> OK, here's what I'm thinking. We don't need to change the communications
> protocol for this, and it shouldn't break userspace.
>
> First, have the PF driver quit assigning random addresses. It will either
> give the VF the address assigned by the administrator, or it will give
> all zeros.
>
> Second, modify the VF driver init sequence slightly. If it gets all
> zeros from the PF driver, then it should give itself a random address
> and set NET_ADDR_RANDOM.
>
> If we do it this way, the VF will still come up with a random address if
> one has not been assigned, and it will always know whether or not the
> address that it is using is random.
>
> If there are no objections, I'll try to get some patches done in the next
> few days and get them into our internal test queue. These would then
> escape into the real world in a few weeks.
>
> -Mitch
Oh, I like this even better than my proposed option 2. I say, go for it.
[-- Attachment #2: Type: text/plain, Size: 383 bytes --]
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. ON SALE this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122712
[-- Attachment #3: Type: text/plain, Size: 257 bytes --]
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* RE: [E1000-devel] [PATCH net-next] igbvf: fix setting addr_assign_type if PF is up
From: Williams, Mitch A @ 2013-01-17 0:42 UTC (permalink / raw)
To: Rose, Gregory V, Andy Gospodarek
Cc: Stefan Assmann, netdev@vger.kernel.org,
e1000-devel@lists.sourceforge.net
In-Reply-To: <20130115103141.00001e96@unknown>
> -----Original Message-----
> From: Rose, Gregory V
> Sent: Tuesday, January 15, 2013 10:32 AM
> To: Andy Gospodarek
> Cc: Williams, Mitch A; Stefan Assmann; netdev@vger.kernel.org; e1000-
> devel@lists.sourceforge.net
> Subject: Re: [E1000-devel] [PATCH net-next] igbvf: fix setting
> addr_assign_type if PF is up
>
> On Mon, 14 Jan 2013 17:25:42 -0500
> Andy Gospodarek <andy@greyhouse.net> wrote:
>
> > On Wed, Jan 09, 2013 at 01:37:45PM -0800, Greg Rose wrote:
> > > On Wed, 9 Jan 2013 18:56:36 +0000
> > > "Williams, Mitch A" <mitch.a.williams@intel.com> wrote:
> > >
> > > > > >> When the PF is up and igbvf is loaded the MAC address is not
> > > > > >> generated using eth_hw_addr_random(). This results in
> > > > > >> addr_assign_type not to be set.
> > > > > >> Make sure it gets set.
> > > > > >>
> > > > > >
> > > > > > NAK - In this case, the address may or may not be random. The
> > > > > > user may have (and should have!) explicitly set this address
> > > > > > from the host to ensure that the VF device receives the same
> > > > > > address each time it
> > > > > boots.
> > > > >
> > > > > Maybe you can give me some advice on this then. Why is there
> > > > > different behaviour depending on the PF being up or down? The
> > > > > problem I'm facing is that if the user did not set a MAC address
> > > > > for the VF manually and the PF is up during igbvf_probe it will
> > > > > not be labelled as random although it is.
> > > > > What about checking IGB_VF_FLAG_PF_SET_MAC and only set
> > > > > NET_ADDR_RANDOM if the flag is cleared?
> > > > >
> > > >
> > > > The difference in behavior is because we cannot get any MAC
> > > > address at all if the PF is down. The interface won't operate at
> > > > all in this case, but if the PF comes up sometime later, we can
> > > > start working. The other alternative is to leave the MAC address
> > > > as all zeros and forcing the user to assign an address manually.
> > > > We chose to use a random address to at least give it a chance of
> > > > working once the PF woke up.
> > >
> > > Having been around at the inception of SR-IOV in Linux I recall that
> > > the primary reason we used a random ethernet address was so that the
> > > VF could at least work because there was no infrastructure to allow
> > > the host administrator to set the MAC address of the VF.
> > > This hobbled testing and validation because the user would have to
> > > go to each VM and use a command local to the VM to set the VF MAC
> > > address to some LAA via ifconfig or ip. When testing large numbers
> > > of VFs this was a definite pain.
> > >
> > > Now that has changed and I wonder if maybe we shouldn't back out the
> > > random ethernet address assignment and go ahead with all zeros,
> > > leaving the device non-functional until the user has intentionally
> > > set either an LAA through the VF itself, or an administratively
> > > assigned MAC through the ip tool via the PF.
> > >
> > > Use of the random MAC address is not recommended by Intel's own best
> > > known methods literature, it was used mostly so that we could get
> > > the technology working and it should probably be at least considered
> > > for deprecation or out right elimination.
> > >
> >
> > It would be great to remove the bits that created random MAC addresses
> > for VFs, but wouldn't that break Linus' rule to "not break userspace"
> > if it was removed?
>
> It may, I'm not sure but before we make any changes we'd want to do our
> due diligence.
>
> >
> > There are 2 options that immediately come to mind when looking to
> > resolve this:
> >
> > 1. Use some of the left-over bits in the mailbox messages to pass
> > along a flag with the E1000_VF_RESET messages to indicate whether the
> > MAC was randomly generated. This would be pretty easy, but there
> > could be compatibility issues for a while.
>
> We recently introduced the concept of mailbox message API versions in
> our PF and VF drivers to handle this sort of thing. We could probably
> leverage that method to introduce a new API version that supports the
> additional bits in the reset message. It would only be used if the VF
> could negotiate to the proper mailbox message API version with the PF.
>
> >
> > 2. Default to a MAC address of all zeros, and as a device with
> > all-zeros for a MAC is brought up, randomly create one with
> > eth_hw_addr_random. This may not immediately help cases where device
> > assignment are a problem, but it would ensure that any device with a
> > random MAC as assigned by the kernel, would have NET_ADDR_RANDOM set
> > in addr_assign_type.
>
> Thanks for the suggestions. We're considering some changes in this area
> but we (Intel) need to give this a lot of thought and right now we're
> just in a preliminary discussion mode about it. Stay tuned.
>
> - Greg
OK, here's what I'm thinking. We don't need to change the communications
protocol for this, and it shouldn't break userspace.
First, have the PF driver quit assigning random addresses. It will either
give the VF the address assigned by the administrator, or it will give
all zeros.
Second, modify the VF driver init sequence slightly. If it gets all
zeros from the PF driver, then it should give itself a random address
and set NET_ADDR_RANDOM.
If we do it this way, the VF will still come up with a random address if
one has not been assigned, and it will always know whether or not the
address that it is using is random.
If there are no objections, I'll try to get some patches done in the next
few days and get them into our internal test queue. These would then
escape into the real world in a few weeks.
-Mitch
^ permalink raw reply
* Re: [RFC PATCH v2 10/10] ixgbe: Add support for set_channels ethtool operation
From: Alexander Duyck @ 2013-01-17 0:35 UTC (permalink / raw)
To: Ben Hutchings; +Cc: netdev, therbert, ycai, eric.dumazet, davem
In-Reply-To: <1358353157.2923.18.camel@bwh-desktop.uk.solarflarecom.com>
On 01/16/2013 08:19 AM, Ben Hutchings wrote:
> On Thu, 2013-01-10 at 10:58 -0800, Alexander Duyck wrote:
>> This change adds support for the ethtool set_channels operation.
>>
>> Since the ixgbe driver has to support DCB as well as the other modes the
>> assumption I made here is that the number of channels in DCB modes refers
>> to the number of queues per traffic class, not the number of queues total.
>>
>> Signed-off-by: Alexander Duyck <alexander.h.duyck@intel.com>
>
> In DCB mode are there separate IRQs for the different classes?
>
> [...]
>> --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>> +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_ethtool.c
>> @@ -2775,6 +2775,45 @@ static void ixgbe_get_channels(struct net_device *dev,
>> ch->combined_count = adapter->ring_feature[RING_F_FDIR].indices;
>> }
>>
>> +static int ixgbe_set_channels(struct net_device *dev,
>> + struct ethtool_channels *ch)
>> +{
>> + struct ixgbe_adapter *adapter = netdev_priv(dev);
>> + unsigned int count = ch->combined_count;
>> +
>> + /* verify they are not requesting separate vectors */
>> + if (ch->rx_count || ch->tx_count)
>> + return -EINVAL;
>> +
>> + /* ignore other_count since it is not changeable */
> [...]
>
> Please do return an error if the command specifies a change to
> other_count.
>
> Ben.
>
I will update the patch to return an error if other_count is not equal
to NON_Q_VECTORS.
Thanks,
Alex
^ permalink raw reply
* Re: [patch net-next v2] doc: add nf_conntrack sysctl api documentation
From: Simon Horman @ 2013-01-17 0:30 UTC (permalink / raw)
To: Jiri Pirko
Cc: netdev, davem, rob, linux-doc, kuznet, jmorris, yoshfuji, pablo,
netfilter-devel, netfilter, coreteam, fw
In-Reply-To: <1358348193-2201-1-git-send-email-jiri@resnulli.us>
On Wed, Jan 16, 2013 at 03:56:33PM +0100, Jiri Pirko wrote:
> I grepped through the code and picked bits about nf_conntrack sysctl api
> and put that into one documentation file.
Excellent, I was looking for documentation of some of these values
only yesterday :)
^ permalink raw reply
* [PATCH v4 1/1] net: ethernet: davinci_cpdma: Add boundary for rx and tx descriptors
From: Mugunthan V N @ 2013-01-17 0:10 UTC (permalink / raw)
To: netdev; +Cc: davem, 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 v3
* Changed multiline commenting as per networking style
drivers/net/ethernet/ti/cpsw.c | 9 ++++++
drivers/net/ethernet/ti/davinci_cpdma.c | 51 ++++++++++++++++++++++++++-----
drivers/net/ethernet/ti/davinci_cpdma.h | 1 +
drivers/net/ethernet/ti/davinci_emac.c | 13 ++++----
4 files changed, 61 insertions(+), 13 deletions(-)
diff --git a/drivers/net/ethernet/ti/cpsw.c b/drivers/net/ethernet/ti/cpsw.c
index 3772804..b35e6a7 100644
--- a/drivers/net/ethernet/ti/cpsw.c
+++ b/drivers/net/ethernet/ti/cpsw.c
@@ -374,6 +374,9 @@ void cpsw_tx_handler(void *token, int len, int status)
struct net_device *ndev = skb->dev;
struct cpsw_priv *priv = netdev_priv(ndev);
+ /* Check whether the queue is stopped due to stalled tx dma, if the
+ * queue is stopped then start the queue as we have free desc for tx
+ */
if (unlikely(netif_queue_stopped(ndev)))
netif_start_queue(ndev);
cpts_tx_timestamp(&priv->cpts, skb);
@@ -736,6 +739,12 @@ static netdev_tx_t cpsw_ndo_start_xmit(struct sk_buff *skb,
goto fail;
}
+ /* If there is no more tx desc left free then we need to
+ * tell the kernel to stop sending us tx frames.
+ */
+ if (unlikely(cpdma_check_free_tx_desc(priv->txch)))
+ netif_stop_queue(ndev);
+
return NETDEV_TX_OK;
fail:
priv->stats.tx_dropped++;
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.c b/drivers/net/ethernet/ti/davinci_cpdma.c
index 4995673..4f6d82f 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,17 +217,29 @@ 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;
+ int desc_start;
+ int desc_end;
struct cpdma_desc __iomem *desc = NULL;
spin_lock_irqsave(&pool->lock, flags);
- index = bitmap_find_next_zero_area(pool->bitmap, pool->num_desc, 0,
- num_desc, 0);
- if (index < pool->num_desc) {
+ if (is_rx) {
+ desc_start = 0;
+ desc_end = pool->num_desc/2;
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc/2, 0, num_desc, 0);
+ } else {
+ desc_start = pool->num_desc/2;
+ desc_end = pool->num_desc;
+ }
+
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ desc_end, desc_start, num_desc, 0);
+ if (index < desc_end) {
bitmap_set(pool->bitmap, index, num_desc);
desc = pool->iomap + pool->desc_size * index;
pool->used_desc++;
@@ -660,6 +672,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 +681,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;
@@ -704,6 +718,29 @@ unlock_ret:
}
EXPORT_SYMBOL_GPL(cpdma_chan_submit);
+bool cpdma_check_free_tx_desc(struct cpdma_chan *chan)
+{
+ unsigned long flags;
+ int index;
+ bool ret;
+ struct cpdma_ctlr *ctlr = chan->ctlr;
+ struct cpdma_desc_pool *pool = ctlr->pool;
+
+ spin_lock_irqsave(&pool->lock, flags);
+
+ index = bitmap_find_next_zero_area(pool->bitmap,
+ pool->num_desc, pool->num_desc/2, 1, 0);
+
+ if (index < pool->num_desc)
+ ret = true;
+ else
+ ret = false;
+
+ spin_unlock_irqrestore(&pool->lock, flags);
+ return ret;
+}
+EXPORT_SYMBOL_GPL(cpdma_check_free_tx_desc);
+
static void __cpdma_chan_free(struct cpdma_chan *chan,
struct cpdma_desc __iomem *desc,
int outlen, int status)
diff --git a/drivers/net/ethernet/ti/davinci_cpdma.h b/drivers/net/ethernet/ti/davinci_cpdma.h
index afa19a0..8d2aeb2 100644
--- a/drivers/net/ethernet/ti/davinci_cpdma.h
+++ b/drivers/net/ethernet/ti/davinci_cpdma.h
@@ -88,6 +88,7 @@ int cpdma_chan_process(struct cpdma_chan *chan, int quota);
int cpdma_ctlr_int_ctrl(struct cpdma_ctlr *ctlr, bool enable);
void cpdma_ctlr_eoi(struct cpdma_ctlr *ctlr);
int cpdma_chan_int_ctrl(struct cpdma_chan *chan, bool enable);
+bool cpdma_check_free_tx_desc(struct cpdma_chan *chan);
enum cpdma_control {
CPDMA_CMD_IDLE, /* write-only */
diff --git a/drivers/net/ethernet/ti/davinci_emac.c b/drivers/net/ethernet/ti/davinci_emac.c
index 8478d98..1c97c81 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,10 +1048,10 @@ 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);
+ /* Check whether the queue is stopped due to stalled tx dma, if the
+ * queue is stopped then start the queue as we have free desc for tx
+ */
if (unlikely(netif_queue_stopped(ndev)))
netif_start_queue(ndev);
ndev->stats.tx_packets++;
@@ -1101,7 +1099,10 @@ 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)
+ /* If there is no more tx desc left free then we need to
+ * tell the kernel to stop sending us tx frames.
+ */
+ if (unlikely(cpdma_check_free_tx_desc(priv->txch)))
netif_stop_queue(ndev);
return NETDEV_TX_OK;
--
1.7.9.5
^ permalink raw reply related
* Re: [RFC PATCH 1/3] Avoid making inappropriate requests of NETIF_F_V[46]_CSUM devices
From: David Woodhouse @ 2013-01-17 0:03 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130116.180044.630688719598008373.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wed, 2013-01-16 at 18:00 -0500, David Miller wrote:
> I'm saying that tun can't inject unchecked crap into our stack.
That's a very strange way of putting it.
Our stack has explicit support for sane hardware devices with
NETIF_F_HW_CSUM capability that can checksum anything.
And it has checks (harmonize_features) on output, so that if the device
on which a packet is being emitted *doesn't* have appropriate hardware
checksum capability, we'll do the checksum in software.
Except that the check in harmonize_features() doesn't do that check
*properly*. It only catches *some* of the packets that the device can't
handle, and lets others through.
So we basically can't use NETIF_F_HW_CSUM in the general case, for
anything like SCTP or any other protocol, because harmonize_features()
is buggy and will let it go out a device that can't handle it.
Um, SCTP *does* use CHECKSUM_PARTIAL. Am I missing something or does
that suffer the same problem?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* [PATCH] net: calxedaxgmac: throw away overrun frames
From: Rob Herring @ 2013-01-16 23:36 UTC (permalink / raw)
To: netdev; +Cc: Rob Herring, linux-kernel
From: Rob Herring <rob.herring@calxeda.com>
The xgmac driver assumes 1 frame per descriptor. If a frame larger than
the descriptor's buffer size is received, the frame will spill over into
the next descriptor. So check for received frames that span more than one
descriptor and discard them. This prevents a crash if we receive erroneous
large packets.
Signed-off-by: Rob Herring <rob.herring@calxeda.com>
Cc: netdev@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
---
drivers/net/ethernet/calxeda/xgmac.c | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/drivers/net/ethernet/calxeda/xgmac.c b/drivers/net/ethernet/calxeda/xgmac.c
index b407043..f7f0290 100644
--- a/drivers/net/ethernet/calxeda/xgmac.c
+++ b/drivers/net/ethernet/calxeda/xgmac.c
@@ -548,6 +548,10 @@ static int desc_get_rx_status(struct xgmac_priv *priv, struct xgmac_dma_desc *p)
return -1;
}
+ /* All frames should fit into a single buffer */
+ if (!(status & RXDESC_FIRST_SEG) || !(status & RXDESC_LAST_SEG))
+ return -1;
+
/* Check if packet has checksum already */
if ((status & RXDESC_FRAME_TYPE) && (status & RXDESC_EXT_STATUS) &&
!(ext_status & RXDESC_IP_PAYLOAD_MASK))
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] r8169: remove unneeded dirty_rx index
From: David Miller @ 2013-01-16 23:02 UTC (permalink / raw)
To: romieu; +Cc: timo.teras, netdev
In-Reply-To: <20130116221640.GB32073@electric-eye.fr.zoreil.com>
From: Francois Romieu <romieu@fr.zoreil.com>
Date: Wed, 16 Jan 2013 23:16:40 +0100
> Timo Teräs <timo.teras@iki.fi> :
>> After commit 6f0333b ("r8169: use 50% less ram for RX ring") the rx
>> ring buffers are always copied making dirty_rx useless.
>>
>> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
>
> Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Applied to net-next.
^ permalink raw reply
* Re: [RFC PATCH 1/3] Avoid making inappropriate requests of NETIF_F_V[46]_CSUM devices
From: David Miller @ 2013-01-16 23:00 UTC (permalink / raw)
To: dwmw2; +Cc: netdev
In-Reply-To: <1358375658.2397.69.camel@shinybook.infradead.org>
From: David Woodhouse <dwmw2@infradead.org>
Date: Wed, 16 Jan 2013 22:34:18 +0000
> On Wed, 2013-01-16 at 15:54 -0500, David Miller wrote:
>>
>> My opinion on this is that the injectors of packets are responsible
>> for ensuring checksum types are set on SKBs in an appropriate way.
>>
>> So we ensure this in the local protocol stacks that generate packets,
>> and if foreign alien entities can inject SKBs with these checksum
>> settings (like the tun device can) the burdon of verification falls
>> upon whatever layer allows that to happen.
>>
>> So really, the fix is in the tun device and the virtio layer.
>
> The virtio layer (and the tun device) expose the equivalent of the
> NETIF_F_HW_CSUM capability to the guest. In the case where we have a
> real device on the host which *also* has NETIF_F_HW_CSUM capability, are
> you saying that the tun driver should do the checksum for non-UDP/TCP
> packets in software *anyway*, just because the packet might end up going
> out a device *without* that capability, and the check in
> harmonize_features() isn't sophisticated enough to cope properly?
I'm saying that tun can't inject unchecked crap into our stack.
^ permalink raw reply
* [PATCH 1/1] ipv6: fix header length calculation in ip6_append_data()
From: Romain KUNTZ @ 2013-01-16 22:47 UTC (permalink / raw)
To: netdev@vger.kernel.org
Cc: yoshfuji@linux-ipv6.org Hideaki, davem@davemloft.net,
Steffen Klassert, linux-kernel@vger.kernel.org, Romain KUNTZ
Commit 299b0767 (ipv6: Fix IPsec slowpath fragmentation problem)
has introduced a error in the header length calculation that
provokes corrupted packets when non-fragmentable extensions
headers (Destination Option or Routing Header Type 2) are used.
rt->rt6i_nfheader_len is the length of the non-fragmentable
extension header, and it should be substracted to
rt->dst.header_len, and not to exthdrlen, as it was done before
commit 299b0767.
This patch reverts to the original and correct behavior. It has
been successfully tested with and without IPsec on packets
that include non-fragmentable extensions headers.
Signed-off-by: Romain Kuntz <r.kuntz@ipflavors.com>
Acked-by: Steffen Klassert <steffen.klassert@secunet.com>
---
net/ipv6/ip6_output.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/ip6_output.c b/net/ipv6/ip6_output.c
index 5552d13..0c7c03d 100644
--- a/net/ipv6/ip6_output.c
+++ b/net/ipv6/ip6_output.c
@@ -1213,10 +1213,10 @@ int ip6_append_data(struct sock *sk, int getfrag(void *from, char *to,
if (dst_allfrag(rt->dst.path))
cork->flags |= IPCORK_ALLFRAG;
cork->length = 0;
- exthdrlen = (opt ? opt->opt_flen : 0) - rt->rt6i_nfheader_len;
+ exthdrlen = (opt ? opt->opt_flen : 0);
length += exthdrlen;
transhdrlen += exthdrlen;
- dst_exthdrlen = rt->dst.header_len;
+ dst_exthdrlen = rt->dst.header_len - rt->rt6i_nfheader_len;
} else {
rt = (struct rt6_info *)cork->dst;
fl6 = &inet->cork.fl.u.ip6;
--
1.7.2.5
^ permalink raw reply related
* Re: [PATCH] r8169: remove unneeded dirty_rx index
From: Francois Romieu @ 2013-01-16 22:16 UTC (permalink / raw)
To: Timo Teräs; +Cc: netdev
In-Reply-To: <1358319684-32364-1-git-send-email-timo.teras@iki.fi>
Timo Teräs <timo.teras@iki.fi> :
> After commit 6f0333b ("r8169: use 50% less ram for RX ring") the rx
> ring buffers are always copied making dirty_rx useless.
>
> Signed-off-by: Timo Teräs <timo.teras@iki.fi>
Acked-by: Francois Romieu <romieu@fr.zoreil.com>
Even if it is obviously not -net material, please specify the branch you
aim at (eg [PATCH net-next] or [PATCH net]).
--
Ueimor
^ permalink raw reply
* BUG when hot docking my laptop (v3.8-rc3-273-g3152ba0)
From: Stephen Rothwell @ 2013-01-16 22:39 UTC (permalink / raw)
To: LKML; +Cc: netdev, linux-pci
[-- Attachment #1: Type: text/plain, Size: 4992 bytes --]
Hi all,
This morning when I hot docked my laptop (after it actually resumed for
once!) it produced this BUG message:
[16045.661684] genirq: Flags mismatch irq 46. 00000000 (eth0) vs. 00000000 (eth0)
[16045.661749] ------------[ cut here ]------------
[16045.661827] kernel BUG at drivers/pci/msi.c:346!
[16045.661902] invalid opcode: 0000 [#1] SMP
[16045.661974] Modules linked in: xhci_hcd hid_generic usbhid hid ip6table_filter ip6_tables iptable_filter ip_tables x_tables tun bnep rfcomm cpufreq_conservative cpufreq_stats cpufreq_powersave cpufreq_userspace uinput deflate zlib_deflate ctr twofish_generic twofish_x86_64_3way twofish_x86_64 twofish_common camellia_generic camellia_x86_64 serpent_sse2_x86_64 serpent_generic glue_helper lrw xts gf128mul blowfish_generic blowfish_x86_64 blowfish_common cast5_generic cast_common ablk_helper cryptd des_generic cbc xcbc rmd160 sha512_generic sha256_generic sha1_ssse3 sha1_generic hmac crypto_null af_key xfrm_algo nf_conntrack_ftp nf_conntrack loop fuse dm_crypt dm_mod snd_hda_codec_hdmi btusb bluetooth iTCO_wdt arc4 iTCO_vendor_support snd_hda_codec_conexant iwldvm mac80211 sg sr_mod cdrom coretemp kvm_intel kvm crc32c_intel pcspkr psmouse serio_raw firewire_ohci i7core_edac edac_core firewire_core thinkpad_acpi lpc_ich i2c_i801 mfd_core crc_itu_t nvram battery ac snd_seq_midi nouve
au sdhci_pci acpi_cpufreq sdhci mperf mmc_core snd_hda_intel snd_rawmidi snd_hda_codec snd_hwdep iwlwifi snd_pcm_oss video snd_seq_midi_event mxm_wmi snd_mixer_oss cfg80211 wmi ehci_pci ehci_hcd snd_pcm snd_seq usbcore rfkill usb_common snd_seq_device snd_page_alloc snd_timer button drm_kms_helper e1000e ttm snd drm processor i2c_algo_bit i2c_core soundcore microcode thermal thermal_sys [last unloaded: xhci_hcd]
[16045.664620] CPU 6
[16045.664668] Pid: 8840, comm: ifconfig Not tainted 3.8.0-rc3+ #1 LENOVO 4389A97/4389A97
[16045.664828] RIP: 0010:[<ffffffff8120a3a3>] [<ffffffff8120a3a3>] free_msi_irqs+0x56/0x107
[16045.664962] RSP: 0018:ffff8801296e9c48 EFLAGS: 00010282
[16045.665043] RAX: ffff880127be1d80 RBX: ffff88012a5fb9c0 RCX: 00000000fffffffa
[16045.665161] RDX: 0000000000000000 RSI: 000000000000002e RDI: 0000000000000000
[16045.665298] RBP: ffff880131d2a000 R08: ffff880133000050 R09: 0000000000000030
[16045.665447] R10: 00000000000000c8 R11: 0000000000000000 R12: 0000000000000000
[16045.665589] R13: ffff880131d2a848 R14: 0000000000000001 R15: 0000000000000000
[16045.665728] FS: 0000000000000000(0000) GS:ffff880137d80000(0063) knlGS:00000000f765c8d0
[16045.665894] CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
[16045.666010] CR2: 0000000008062e00 CR3: 00000001104aa000 CR4: 00000000000007e0
[16045.666153] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[16045.666300] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[16045.666456] Process ifconfig (pid: 8840, threadinfo ffff8801296e8000, task ffff88013083f6a0)
[16045.666636] Stack:
[16045.666686] ffff880131d2a000 ffff880130af0000 0000000000000000 ffff880131d2a098
[16045.666869] 0000000000000001 ffffffff8120ae37 ffff880130af07c0 ffffffffa00ec658
[16045.667031] ffff880130af07c0 ffffffffa00ec924 ffff880130af0000 ffff880130af07c0
[16045.667209] Call Trace:
[16045.667277] [<ffffffff8120ae37>] ? pci_disable_msi+0x28/0x41
[16045.667448] [<ffffffffa00ec658>] ? e1000e_reset_interrupt_capability+0x48/0x54 [e1000e]
[16045.667654] [<ffffffffa00ec924>] ? e1000_request_irq+0x1d2/0x249 [e1000e]
[16045.667807] [<ffffffffa00eecdd>] ? e1000_open+0xe7/0x393 [e1000e]
[16045.667931] [<ffffffff81399c14>] ? notifier_call_chain+0x2e/0x59
[16045.668068] [<ffffffff812e63ca>] ? __dev_open+0x8c/0xce
[16045.668184] [<ffffffff812e65d1>] ? __dev_change_flags+0x9d/0x118
[16045.668310] [<ffffffff812e66b2>] ? dev_change_flags+0x12/0x42
[16045.668429] [<ffffffff813308e7>] ? devinet_ioctl+0x247/0x53d
[16045.668553] [<ffffffff812e6e4a>] ? dev_ioctl+0x46d/0x5d4
[16045.668674] [<ffffffff812d252a>] ? sock_do_ioctl+0x1b/0x36
[16045.668806] [<ffffffff812d3458>] ? compat_sock_ioctl+0xaf5/0xb68
[16045.668951] [<ffffffff811a0553>] ? file_has_perm+0x6b/0x74
[16045.669073] [<ffffffff8112a99b>] ? compat_sys_ioctl+0x1bf/0x10bc
[16045.669207] [<ffffffff810e6ca5>] ? kmem_cache_alloc+0x4f/0xbd
[16045.669330] [<ffffffff8139d11c>] ? sysenter_dispatch+0x7/0x21
[16045.669444] Code: eb 10 eb 33 8a 0b 41 be 01 00 00 00 45 31 e4 d0 e9 83 e1 07 41 d3 e6 eb 17 8b 7b 0c 44 01 e7 e8 90 30 e8 ff 48 83 78 58 00 74 02 <0f> 0b 41 ff c4 45 39 f4 7c e4 eb c3 48 8d 43 10 49 39 c5 75 b4
[16045.670155] RIP [<ffffffff8120a3a3>] free_msi_irqs+0x56/0x107
[16045.670288] RSP <ffff8801296e9c48>
This is v3.8-rc3-273-g3152ba0, config at
http://ozlabs.org/~sfr/config.oops, "lspci -vv -k output at
http://ozlabs.org/~sfr/lspci.oops
The laptop continued running enough for me to switch back to X and shut
it down.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [RFC PATCH 1/3] Avoid making inappropriate requests of NETIF_F_V[46]_CSUM devices
From: David Woodhouse @ 2013-01-16 22:34 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130116.155406.351676228334066120.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1033 bytes --]
On Wed, 2013-01-16 at 15:54 -0500, David Miller wrote:
>
> My opinion on this is that the injectors of packets are responsible
> for ensuring checksum types are set on SKBs in an appropriate way.
>
> So we ensure this in the local protocol stacks that generate packets,
> and if foreign alien entities can inject SKBs with these checksum
> settings (like the tun device can) the burdon of verification falls
> upon whatever layer allows that to happen.
>
> So really, the fix is in the tun device and the virtio layer.
The virtio layer (and the tun device) expose the equivalent of the
NETIF_F_HW_CSUM capability to the guest. In the case where we have a
real device on the host which *also* has NETIF_F_HW_CSUM capability, are
you saying that the tun driver should do the checksum for non-UDP/TCP
packets in software *anyway*, just because the packet might end up going
out a device *without* that capability, and the check in
harmonize_features() isn't sophisticated enough to cope properly?
--
dwmw2
[-- Attachment #2: smime.p7s --]
[-- Type: application/x-pkcs7-signature, Size: 6171 bytes --]
^ permalink raw reply
* Re: [PATCH 2/5] soreuseport: TCP/IPv4 implementation
From: Vijay Subramanian @ 2013-01-16 22:14 UTC (permalink / raw)
To: Tom Herbert; +Cc: netdev, davem, netdev, eric.dumazet
In-Reply-To: <CA+mtBx-rAV46Q6pabLjm5AZhdT+0_CDVuR4ydJSKmhoFhF9NPg@mail.gmail.com>
On 16 January 2013 13:30, Tom Herbert <therbert@google.com> wrote:
> I'll send updated patches today fixing the issue raised so far. You
> might want to put these on top of those?
>
Apologies for letting the mailer mangle the patch. I think I have fixed it now.
Instead of resending this version, I will wait till your patches are
applied and send a version on top of those.
Thanks,
Vijay
^ permalink raw reply
* Re: [PATCH net-next V6 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Michał Mirosław @ 2013-01-16 22:03 UTC (permalink / raw)
To: Vlad Yasevich; +Cc: netdev, bridge, davem, shemminger, mst, shmulik.ladkani
In-Reply-To: <1358360289-23249-2-git-send-email-vyasevic@redhat.com>
(resend with proper To:)
> Wrap VLAN hardware acceleration calls into separate functions. This way
> other code can re-use it.
Maybe instead of jumping aroung bugs that are easily fixed just don't
let them in? See untested patch below. Affected drivers can be either
fixed or have NETIF_F_HW_VLAN_FILTER removed from advertised features.
--cut-here--
net: disallow drivers with buggy VLAN accel to register_netdevice()
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/8021q/vlan.c | 7 -------
net/8021q/vlan_core.c | 6 ++----
net/core/dev.c | 9 +++++++++
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index babfde9..addc578 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -117,19 +117,12 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
int vlan_check_real_dev(struct net_device *real_dev, u16 vlan_id)
{
const char *name = real_dev->name;
- const struct net_device_ops *ops = real_dev->netdev_ops;
if (real_dev->features & NETIF_F_VLAN_CHALLENGED) {
pr_info("VLANs not supported on %s\n", name);
return -EOPNOTSUPP;
}
- if ((real_dev->features & NETIF_F_HW_VLAN_FILTER) &&
- (!ops->ndo_vlan_rx_add_vid || !ops->ndo_vlan_rx_kill_vid)) {
- pr_info("Device %s has buggy VLAN hw accel\n", name);
- return -EOPNOTSUPP;
- }
-
if (vlan_find_dev(real_dev, vlan_id) != NULL)
return -EEXIST;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 380440b..71b64fd 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -224,8 +224,7 @@ static int __vlan_vid_add(struct vlan_info *vlan_info, unsigned short vid,
if (!vid_info)
return -ENOMEM;
- if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
- ops->ndo_vlan_rx_add_vid) {
+ if (dev->features & NETIF_F_HW_VLAN_FILTER) {
err = ops->ndo_vlan_rx_add_vid(dev, vid);
if (err) {
kfree(vid_info);
@@ -282,8 +281,7 @@ static void __vlan_vid_del(struct vlan_info *vlan_info,
unsigned short vid = vid_info->vid;
int err;
- if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
- ops->ndo_vlan_rx_kill_vid) {
+ if (dev->features & NETIF_F_HW_VLAN_FILTER) {
err = ops->ndo_vlan_rx_kill_vid(dev, vid);
if (err) {
pr_warn("failed to kill vid %d for device %s\n",
diff --git a/net/core/dev.c b/net/core/dev.c
index b6d2b32..f87cdc2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6211,6 +6211,15 @@ int register_netdevice(struct net_device *dev)
}
}
+ if (((dev->hw_features & NETIF_F_HW_VLAN_FILTER) ||
+ (dev->features & NETIF_F_HW_VLAN_FILTER)) &&
+ (!dev->netdev_ops->ndo_vlan_rx_add_vid ||
+ !dev->netdev_ops->ndo_vlan_rx_kill_vid)) {
+ netdev_WARN(dev, "Buggy VLAN acceleration in driver!\n");
+ ret = -EINVAL;
+ goto err_uninit;
+ }
+
ret = -EBUSY;
if (!dev->ifindex)
dev->ifindex = dev_new_index(net);
--
1.7.10.4
----- End forwarded message -----
^ permalink raw reply related
* Re: [PATCH net-next V6 01/14] vlan: wrap hw-acceleration calls in separate functions.
From: Michał Mirosław @ 2013-01-16 22:00 UTC (permalink / raw)
To: netdev
In-Reply-To: <1358360289-23249-2-git-send-email-vyasevic@redhat.com>
> Wrap VLAN hardware acceleration calls into separate functions. This way
> other code can re-use it.
Maybe instead of jumping aroung bugs that are easily fixed just don't
let them in? See untested patch below. Affected drivers can be either
fixed or have NETIF_F_HW_VLAN_FILTER removed from advertised features.
--cut-here--
net: disallow drivers with buggy VLAN accel to register_netdevice()
Signed-off-by: Michał Mirosław <mirq-linux@rere.qmqm.pl>
---
net/8021q/vlan.c | 7 -------
net/8021q/vlan_core.c | 6 ++----
net/core/dev.c | 9 +++++++++
3 files changed, 11 insertions(+), 11 deletions(-)
diff --git a/net/8021q/vlan.c b/net/8021q/vlan.c
index babfde9..addc578 100644
--- a/net/8021q/vlan.c
+++ b/net/8021q/vlan.c
@@ -117,19 +117,12 @@ void unregister_vlan_dev(struct net_device *dev, struct list_head *head)
int vlan_check_real_dev(struct net_device *real_dev, u16 vlan_id)
{
const char *name = real_dev->name;
- const struct net_device_ops *ops = real_dev->netdev_ops;
if (real_dev->features & NETIF_F_VLAN_CHALLENGED) {
pr_info("VLANs not supported on %s\n", name);
return -EOPNOTSUPP;
}
- if ((real_dev->features & NETIF_F_HW_VLAN_FILTER) &&
- (!ops->ndo_vlan_rx_add_vid || !ops->ndo_vlan_rx_kill_vid)) {
- pr_info("Device %s has buggy VLAN hw accel\n", name);
- return -EOPNOTSUPP;
- }
-
if (vlan_find_dev(real_dev, vlan_id) != NULL)
return -EEXIST;
diff --git a/net/8021q/vlan_core.c b/net/8021q/vlan_core.c
index 380440b..71b64fd 100644
--- a/net/8021q/vlan_core.c
+++ b/net/8021q/vlan_core.c
@@ -224,8 +224,7 @@ static int __vlan_vid_add(struct vlan_info *vlan_info, unsigned short vid,
if (!vid_info)
return -ENOMEM;
- if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
- ops->ndo_vlan_rx_add_vid) {
+ if (dev->features & NETIF_F_HW_VLAN_FILTER) {
err = ops->ndo_vlan_rx_add_vid(dev, vid);
if (err) {
kfree(vid_info);
@@ -282,8 +281,7 @@ static void __vlan_vid_del(struct vlan_info *vlan_info,
unsigned short vid = vid_info->vid;
int err;
- if ((dev->features & NETIF_F_HW_VLAN_FILTER) &&
- ops->ndo_vlan_rx_kill_vid) {
+ if (dev->features & NETIF_F_HW_VLAN_FILTER) {
err = ops->ndo_vlan_rx_kill_vid(dev, vid);
if (err) {
pr_warn("failed to kill vid %d for device %s\n",
diff --git a/net/core/dev.c b/net/core/dev.c
index b6d2b32..f87cdc2 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -6211,6 +6211,15 @@ int register_netdevice(struct net_device *dev)
}
}
+ if (((dev->hw_features & NETIF_F_HW_VLAN_FILTER) ||
+ (dev->features & NETIF_F_HW_VLAN_FILTER)) &&
+ (!dev->netdev_ops->ndo_vlan_rx_add_vid ||
+ !dev->netdev_ops->ndo_vlan_rx_kill_vid)) {
+ netdev_WARN(dev, "Buggy VLAN acceleration in driver!\n");
+ ret = -EINVAL;
+ goto err_uninit;
+ }
+
ret = -EBUSY;
if (!dev->ifindex)
dev->ifindex = dev_new_index(net);
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] sk-filter: Add ability to lock a socket filter program
From: Vincent Bernat @ 2013-01-16 21:57 UTC (permalink / raw)
To: David Miller; +Cc: netdev
In-Reply-To: <20130116.162012.1782638746075880444.davem@davemloft.net>
❦ 16 janvier 2013 22:20 CET, David Miller <davem@davemloft.net> :
>> +SO_LOCK_FILTER ioctl allows to lock the filter attached to a
>
> It's not an ioctl, it's a socket option.
I have sent an updated patch. I have also fixed the wording of other
options in the same file. I can do a separate patch if you think this is
worth it.
--
Treat end of file conditions in a uniform manner.
- The Elements of Programming Style (Kernighan & Plauger)
^ permalink raw reply
* [PATCH net-next] sk-filter: Add ability to lock a socket filter program
From: Vincent Bernat @ 2013-01-16 21:55 UTC (permalink / raw)
To: netdev, David Miller; +Cc: Vincent Bernat
In-Reply-To: <20130116.162012.1782638746075880444.davem@davemloft.net>
While a privileged program can open a raw socket, attach some
restrictive filter and drop its privileges (or send the socket to an
unprivileged program through some Unix socket), the filter can still
be removed or modified by the unprivileged program. This commit adds a
socket option to lock the filter (SO_LOCK_FILTER) preventing any
modification of a socket filter program.
This is similar to OpenBSD BIOCLOCK ioctl on bpf sockets, except even
root is not allowed change/drop the filter.
The state of the lock can be read with getsockopt(). No error is
triggered if the state is not changed. -EPERM is returned when a user
tries to remove the lock or to change/remove the filter while the lock
is active. The check is done directly in sk_attach_filter() and
sk_detach_filter() and does not affect only setsockopt() syscall.
Signed-off-by: Vincent Bernat <bernat@luffy.cx>
---
Documentation/networking/filter.txt | 11 +++++++++--
arch/alpha/include/uapi/asm/socket.h | 1 +
arch/avr32/include/uapi/asm/socket.h | 2 ++
arch/cris/include/uapi/asm/socket.h | 2 ++
arch/frv/include/uapi/asm/socket.h | 2 ++
arch/h8300/include/uapi/asm/socket.h | 2 ++
arch/ia64/include/uapi/asm/socket.h | 2 ++
arch/m32r/include/uapi/asm/socket.h | 2 ++
arch/mips/include/uapi/asm/socket.h | 1 +
arch/mn10300/include/uapi/asm/socket.h | 2 ++
arch/parisc/include/uapi/asm/socket.h | 1 +
arch/powerpc/include/uapi/asm/socket.h | 2 ++
arch/s390/include/uapi/asm/socket.h | 2 ++
arch/sparc/include/uapi/asm/socket.h | 1 +
arch/xtensa/include/uapi/asm/socket.h | 2 ++
include/net/sock.h | 1 +
include/uapi/asm-generic/socket.h | 2 ++
net/core/filter.c | 6 ++++++
net/core/sock.c | 11 +++++++++++
19 files changed, 53 insertions(+), 2 deletions(-)
diff --git a/Documentation/networking/filter.txt b/Documentation/networking/filter.txt
index bbf2005..cdb3e40 100644
--- a/Documentation/networking/filter.txt
+++ b/Documentation/networking/filter.txt
@@ -17,12 +17,12 @@ creating filters.
LSF is much simpler than BPF. One does not have to worry about
devices or anything like that. You simply create your filter
-code, send it to the kernel via the SO_ATTACH_FILTER ioctl and
+code, send it to the kernel via the SO_ATTACH_FILTER option and
if your filter code passes the kernel check on it, you then
immediately begin filtering data on that socket.
You can also detach filters from your socket via the
-SO_DETACH_FILTER ioctl. This will probably not be used much
+SO_DETACH_FILTER option. This will probably not be used much
since when you close a socket that has a filter on it the
filter is automagically removed. The other less common case
may be adding a different filter on the same socket where you had another
@@ -31,12 +31,19 @@ the old one and placing your new one in its place, assuming your
filter has passed the checks, otherwise if it fails the old filter
will remain on that socket.
+SO_LOCK_FILTER option allows to lock the filter attached to a
+socket. Once set, a filter cannot be removed or changed. This allows
+one process to setup a socket, attach a filter, lock it then drop
+privileges and be assured that the filter will be kept until the
+socket is closed.
+
Examples
========
Ioctls-
setsockopt(sockfd, SOL_SOCKET, SO_ATTACH_FILTER, &Filter, sizeof(Filter));
setsockopt(sockfd, SOL_SOCKET, SO_DETACH_FILTER, &value, sizeof(value));
+setsockopt(sockfd, SOL_SOCKET, SO_LOCK_FILTER, &value, sizeof(value));
See the BSD bpf.4 manpage and the BSD Packet Filter paper written by
Steven McCanne and Van Jacobson of Lawrence Berkeley Laboratory.
diff --git a/arch/alpha/include/uapi/asm/socket.h b/arch/alpha/include/uapi/asm/socket.h
index 097c157..755702e 100644
--- a/arch/alpha/include/uapi/asm/socket.h
+++ b/arch/alpha/include/uapi/asm/socket.h
@@ -77,5 +77,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/avr32/include/uapi/asm/socket.h b/arch/avr32/include/uapi/asm/socket.h
index 486df68..f3f38a0 100644
--- a/arch/avr32/include/uapi/asm/socket.h
+++ b/arch/avr32/include/uapi/asm/socket.h
@@ -70,4 +70,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* __ASM_AVR32_SOCKET_H */
diff --git a/arch/cris/include/uapi/asm/socket.h b/arch/cris/include/uapi/asm/socket.h
index b681b04..406b583 100644
--- a/arch/cris/include/uapi/asm/socket.h
+++ b/arch/cris/include/uapi/asm/socket.h
@@ -72,6 +72,8 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/frv/include/uapi/asm/socket.h b/arch/frv/include/uapi/asm/socket.h
index 871f89b..d8e1132 100644
--- a/arch/frv/include/uapi/asm/socket.h
+++ b/arch/frv/include/uapi/asm/socket.h
@@ -70,5 +70,7 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/h8300/include/uapi/asm/socket.h b/arch/h8300/include/uapi/asm/socket.h
index 90a2e57..c8b87a8 100644
--- a/arch/h8300/include/uapi/asm/socket.h
+++ b/arch/h8300/include/uapi/asm/socket.h
@@ -70,4 +70,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/ia64/include/uapi/asm/socket.h b/arch/ia64/include/uapi/asm/socket.h
index 23d6759..f390896 100644
--- a/arch/ia64/include/uapi/asm/socket.h
+++ b/arch/ia64/include/uapi/asm/socket.h
@@ -79,4 +79,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_IA64_SOCKET_H */
diff --git a/arch/m32r/include/uapi/asm/socket.h b/arch/m32r/include/uapi/asm/socket.h
index 5e7088a..6a89515 100644
--- a/arch/m32r/include/uapi/asm/socket.h
+++ b/arch/m32r/include/uapi/asm/socket.h
@@ -70,4 +70,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_M32R_SOCKET_H */
diff --git a/arch/mips/include/uapi/asm/socket.h b/arch/mips/include/uapi/asm/socket.h
index 17307ab..9d11a77 100644
--- a/arch/mips/include/uapi/asm/socket.h
+++ b/arch/mips/include/uapi/asm/socket.h
@@ -90,5 +90,6 @@ To add: #define SO_REUSEPORT 0x0200 /* Allow local address and port reuse. */
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
#endif /* _UAPI_ASM_SOCKET_H */
diff --git a/arch/mn10300/include/uapi/asm/socket.h b/arch/mn10300/include/uapi/asm/socket.h
index af5366b..ab702c4 100644
--- a/arch/mn10300/include/uapi/asm/socket.h
+++ b/arch/mn10300/include/uapi/asm/socket.h
@@ -70,4 +70,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/parisc/include/uapi/asm/socket.h b/arch/parisc/include/uapi/asm/socket.h
index d9ff473..da2c8d3 100644
--- a/arch/parisc/include/uapi/asm/socket.h
+++ b/arch/parisc/include/uapi/asm/socket.h
@@ -69,6 +69,7 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 0x4024
+#define SO_LOCK_FILTER 0x4025
/* O_NONBLOCK clashes with the bits used for socket types. Therefore we
* have to define SOCK_NONBLOCK to a different value here.
diff --git a/arch/powerpc/include/uapi/asm/socket.h b/arch/powerpc/include/uapi/asm/socket.h
index eb0b186..e6ca318 100644
--- a/arch/powerpc/include/uapi/asm/socket.h
+++ b/arch/powerpc/include/uapi/asm/socket.h
@@ -77,4 +77,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_POWERPC_SOCKET_H */
diff --git a/arch/s390/include/uapi/asm/socket.h b/arch/s390/include/uapi/asm/socket.h
index 436d07c..9ce60b6 100644
--- a/arch/s390/include/uapi/asm/socket.h
+++ b/arch/s390/include/uapi/asm/socket.h
@@ -76,4 +76,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _ASM_SOCKET_H */
diff --git a/arch/sparc/include/uapi/asm/socket.h b/arch/sparc/include/uapi/asm/socket.h
index c83a937..fbbba57 100644
--- a/arch/sparc/include/uapi/asm/socket.h
+++ b/arch/sparc/include/uapi/asm/socket.h
@@ -66,6 +66,7 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 0x0027
+#define SO_LOCK_FILTER 0x0028
/* Security levels - as per NRL IPv6 - don't actually do anything */
#define SO_SECURITY_AUTHENTICATION 0x5001
diff --git a/arch/xtensa/include/uapi/asm/socket.h b/arch/xtensa/include/uapi/asm/socket.h
index 38079be..dbf3164 100644
--- a/arch/xtensa/include/uapi/asm/socket.h
+++ b/arch/xtensa/include/uapi/asm/socket.h
@@ -81,4 +81,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* _XTENSA_SOCKET_H */
diff --git a/include/net/sock.h b/include/net/sock.h
index 182ca99..5a34e2f 100644
--- a/include/net/sock.h
+++ b/include/net/sock.h
@@ -664,6 +664,7 @@ enum sock_flags {
* Will use last 4 bytes of packet sent from
* user-space instead.
*/
+ SOCK_FILTER_LOCKED, /* Filter cannot be changed anymore */
};
static inline void sock_copy_flags(struct sock *nsk, struct sock *osk)
diff --git a/include/uapi/asm-generic/socket.h b/include/uapi/asm-generic/socket.h
index 2d32d07..3f6a992 100644
--- a/include/uapi/asm-generic/socket.h
+++ b/include/uapi/asm-generic/socket.h
@@ -73,4 +73,6 @@
/* Instruct lower device to use last 4-bytes of skb data as FCS */
#define SO_NOFCS 43
+#define SO_LOCK_FILTER 44
+
#endif /* __ASM_GENERIC_SOCKET_H */
diff --git a/net/core/filter.c b/net/core/filter.c
index 2ead2a9..2e20b55 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -721,6 +721,9 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock *sk)
unsigned int fsize = sizeof(struct sock_filter) * fprog->len;
int err;
+ if (sock_flag(sk, SOCK_FILTER_LOCKED))
+ return -EPERM;
+
/* Make sure new filter is there and in the right amounts. */
if (fprog->filter == NULL)
return -EINVAL;
@@ -757,6 +760,9 @@ int sk_detach_filter(struct sock *sk)
int ret = -ENOENT;
struct sk_filter *filter;
+ if (sock_flag(sk, SOCK_FILTER_LOCKED))
+ return -EPERM;
+
filter = rcu_dereference_protected(sk->sk_filter,
sock_owned_by_user(sk));
if (filter) {
diff --git a/net/core/sock.c b/net/core/sock.c
index bc131d4..8258fb7 100644
--- a/net/core/sock.c
+++ b/net/core/sock.c
@@ -861,6 +861,13 @@ set_rcvbuf:
ret = sk_detach_filter(sk);
break;
+ case SO_LOCK_FILTER:
+ if (sock_flag(sk, SOCK_FILTER_LOCKED) && !valbool)
+ ret = -EPERM;
+ else
+ sock_valbool_flag(sk, SOCK_FILTER_LOCKED, valbool);
+ break;
+
case SO_PASSSEC:
if (valbool)
set_bit(SOCK_PASSSEC, &sock->flags);
@@ -1140,6 +1147,10 @@ int sock_getsockopt(struct socket *sock, int level, int optname,
goto lenout;
+ case SO_LOCK_FILTER:
+ v.val = sock_flag(sk, SOCK_FILTER_LOCKED);
+ break;
+
default:
return -ENOPROTOOPT;
}
--
1.7.10.4
^ permalink raw reply related
* Re: [PATCH] r8169: remove unneeded dirty_rx index
From: Francois Romieu @ 2013-01-16 21:26 UTC (permalink / raw)
To: David Miller; +Cc: timo.teras, netdev
In-Reply-To: <20130116.162500.1216966272191204366.davem@davemloft.net>
David Miller <davem@davemloft.net> :
[...]
> > @@ -6035,10 +6034,8 @@ static int rtl_rx(struct net_device *dev, struct rtl8169_private *tp, u32 budget
> > unsigned int count;
> >
> > cur_rx = tp->cur_rx;
> > - rx_left = NUM_RX_DESC + tp->dirty_rx - cur_rx;
> > - rx_left = min(rx_left, budget);
> >
> > - for (; rx_left > 0; rx_left--, cur_rx++) {
> > + for (rx_left = min(budget, NUM_RX_DESC); rx_left > 0; rx_left--, cur_rx++) {
>
> Is this really equivalent? I think cur_rx still needs to be
> incorporated into whatever you use as the initial rx_left.
The rx ring can't contain hole so the code above must be read with
"tp->cur_rx == tp->dirty_rx" in mind.
--
Ueimor
^ permalink raw reply
* Re: [PATCH 2/2] 6lowpan: Handle uncompressed IPv6 packets over 6LoWPAN
From: Alan Ott @ 2013-01-16 21:53 UTC (permalink / raw)
To: David Miller
Cc: alex.bluesman.smirnov, dbaryshkov, linux-zigbee-devel, netdev,
linux-kernel, tony.cheneau, eric.dumazet
In-Reply-To: <20130116.162214.444431638469568669.davem@davemloft.net>
On 01/16/2013 04:22 PM, David Miller wrote:
> From: Alan Ott <alan@signal11.us>
> Date: Wed, 16 Jan 2013 00:43:57 -0500
>
>> + local_skb = skb_copy_expand(skb, NET_SKB_PAD - 1,
>> + skb_tailroom(skb), GFP_ATOMIC);
> This is not indented properly.
>
> When a function call spans multiple lines, the second and subsequent
> lines should be indented to the column right after the openning
> parenthesis of the call itself, using a combination of TAB and
> SPC characters as needed.
Thanks David, I'll fix and re-submit.
Alan.
^ permalink raw reply
* Fw: [Bug 52151] via_rhine stops making new tcp connections.
From: Stephen Hemminger @ 2013-01-16 21:45 UTC (permalink / raw)
To: Roger Luethi; +Cc: netdev
Begin forwarded message:
Date: Wed, 16 Jan 2013 12:56:07 -0800
From: "bugzilla-daemon@bugzilla.kernel.org" <bugzilla-daemon@bugzilla.kernel.org>
To: "stephen@networkplumber.org" <stephen@networkplumber.org>
Subject: [Bug 52151] via_rhine stops making new tcp connections.
https://bugzilla.kernel.org/show_bug.cgi?id=52151
--- Comment #4 from David W. Hodgins <davidwhodgins@gmail.com> 2013-01-16 20:55:59 ---
Created an attachment (id=91411)
--> (https://bugzilla.kernel.org/attachment.cgi?id=91411)
dmesg output
Now that it's happened again, I've been able to get proper
dmesg output, but as shown, there are no error messages
being generated related to networking.
--
Configure bugmail: https://bugzilla.kernel.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] CDC_NCM adding support IFF_NOARP for infineon modem platform
From: Dan Williams @ 2013-01-16 21:45 UTC (permalink / raw)
To: Wei Shuai
Cc: gregkh-hQyY1W1yCW8ekmWlsbkhG0B+6BGkLq7r,
alexey.orishko-0IS4wlFg1OjSUeElwK9/Pw, bjorn-yOkvZcmFvRU,
linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1357990479-5836-1-git-send-email-cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
On Sat, 2013-01-12 at 19:34 +0800, Wei Shuai wrote:
> Infineon(now Intel) HSPA Modem platform NCM cannot support ARP. so I introduce a flag CDC_NCM_DRIVER_DATA_NOARP which is defined in driver_info:data. so later on, if more such buggy devices are found, they could use same flag to handle.
So given that Dave now approves of IFF_NOARP, let's change your original
patch to add a FLAG_NOARP for the .flags structure instead of inventing
another mechanism for .data.
Dan
> Signed-off-by: Wei Shuai <cpuwolf-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> ---
> drivers/net/usb/cdc_ncm.c | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/net/usb/cdc_ncm.c b/drivers/net/usb/cdc_ncm.c
> index 71b6e92..6093e07 100644
> --- a/drivers/net/usb/cdc_ncm.c
> +++ b/drivers/net/usb/cdc_ncm.c
> @@ -55,6 +55,9 @@
>
> #define DRIVER_VERSION "14-Mar-2012"
>
> +/* Flags for driver_info::data */
> +#define CDC_NCM_DRIVER_DATA_NOARP 1
> +
> static void cdc_ncm_txpath_bh(unsigned long param);
> static void cdc_ncm_tx_timeout_start(struct cdc_ncm_ctx *ctx);
> static enum hrtimer_restart cdc_ncm_tx_timer_cb(struct hrtimer *hr_timer);
> @@ -573,6 +576,10 @@ static int cdc_ncm_bind(struct usbnet *dev, struct usb_interface *intf)
> return -ENODEV;
> #endif
>
> + if (dev->driver_info->data & CDC_NCM_DRIVER_DATA_NOARP) {
> + /* some buggy device cannot do ARP*/
> + dev->net->flags |= IFF_NOARP;
> + }
> /* NCM data altsetting is always 1 */
> ret = cdc_ncm_bind_common(dev, intf, 1);
>
> @@ -1155,6 +1162,21 @@ static const struct driver_info wwan_info = {
> .tx_fixup = cdc_ncm_tx_fixup,
> };
>
> +/* Same as wwan_info, but with IFF_NOARP */
> +static const struct driver_info wwan_noarp_info = {
> + .description = "Mobile Broadband Network Device (NO ARP)",
> + .flags = FLAG_POINTTOPOINT | FLAG_NO_SETINT | FLAG_MULTI_PACKET
> + | FLAG_WWAN,
> + .data = CDC_NCM_DRIVER_DATA_NOARP,
> + .bind = cdc_ncm_bind,
> + .unbind = cdc_ncm_unbind,
> + .check_connect = cdc_ncm_check_connect,
> + .manage_power = usbnet_manage_power,
> + .status = cdc_ncm_status,
> + .rx_fixup = cdc_ncm_rx_fixup,
> + .tx_fixup = cdc_ncm_tx_fixup,
> +};
> +
> static const struct usb_device_id cdc_devs[] = {
> /* Ericsson MBM devices like F5521gw */
> { .match_flags = USB_DEVICE_ID_MATCH_INT_INFO
> @@ -1194,6 +1216,13 @@ static const struct usb_device_id cdc_devs[] = {
> .driver_info = (unsigned long)&wwan_info,
> },
>
> + /* Infineon(now Intel) HSPA Modem platform */
> + { USB_DEVICE_AND_INTERFACE_INFO(0x1519, 0x0443,
> + USB_CLASS_COMM,
> + USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
> + .driver_info = (unsigned long)&wwan_noarp_info,
> + },
> +
> /* Generic CDC-NCM devices */
> { USB_INTERFACE_INFO(USB_CLASS_COMM,
> USB_CDC_SUBCLASS_NCM, USB_CDC_PROTO_NONE),
--
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
* Re: Redefinition of struct in6_addr in <netinet/in.h> and <linux/in6.h>
From: David Miller @ 2013-01-16 21:45 UTC (permalink / raw)
To: bhutchings
Cc: yoshfuji, amwang, tmb, eblake, netdev, linux-kernel, libvirt-list,
tgraf, libc-alpha, schwab, carlos
In-Reply-To: <1358351232.2923.10.camel@bwh-desktop.uk.solarflarecom.com>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Wed, 16 Jan 2013 15:47:12 +0000
> On Wed, 2013-01-16 at 23:21 +0900, YOSHIFUJI Hideaki wrote:
>> Cong Wang wrote:
>> > (Cc'ing some glibc developers...)
>> >
>> > Hello,
>> >
>> > In glibc source file inet/netinet/in.h and kernel source file
>> > include/uapi/linux/in6.h, both define struct in6_addr, and both are
>> > visible to user applications. Thomas reported a conflict below.
>> >
>> > So, how can we handle this? /me is wondering why we didn't see this
>> > before.
> [...]
>> This is not a new issue. In addition to this,
>> netinet/in.h also conflits with linux/in.h.
>>
>> We might have
>> #if !defined(__GLIBC__) || !defined(_NETINET_IN_H)
>> :
>> #endif
>> around those conflicting definitions in uapi/linux/in{,6}.h.
>
> This only solves half the problem, as <netinet/in.h> might be included
> after <linux/in.h>. Also, not all Linux userland uses glibc.
So I've been looking at reasonable ways to fix this.
What would be really nice is if GCC treated multiple identical
definitions of structures the same way it handles multiple identical
definitions of CPP defines. Which is to silently accept them.
But that's not the case, so we need a different solution.
Another thing to do is to use a new structure for in6_addr in kernel
headers exported to userland.
If we were to make the structure members and accessor macros identical
we could avoid breaking most if not all apps.
However the type name is different so:
struct in6_addr *p = &kern_struct->member;
wouldn't work so well. And you couldn't fix up the sources to these
kinds of accesses in a way that work cleanly both before and after
changing the kernel headers.
I'm out of ideas for today.
^ permalink raw reply
* Re: [PATCH net-next] ipv6: fix ipv6_prefix_equal64_half mask conversion
From: David Miller @ 2013-01-16 21:37 UTC (permalink / raw)
To: fabio.baltieri; +Cc: netdev, yoshfuji, linux-kernel, kuznet, jmorris, kaber
In-Reply-To: <1358371817-15378-1-git-send-email-fabio.baltieri@linaro.org>
From: Fabio Baltieri <fabio.baltieri@linaro.org>
Date: Wed, 16 Jan 2013 22:30:17 +0100
> Fix the 64bit optimized version of ipv6_prefix_equal to convert the
> bitmask to network byte order only after the bit-shift.
>
> The bug was introduced in:
>
> 3867517 ipv6: 64bit version of ipv6_prefix_equal().
>
> Signed-off-by: Fabio Baltieri <fabio.baltieri@linaro.org>
Applied, 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