* [PATCH 06/11] rt2x00: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Ivo van Doorn, Gertjan van Wingerde, John W. Linville,
Helmut Schaa, Alban Browaeys, linux-wireless, users, netdev,
linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/wireless/rt2x00/rt2x00pci.c | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/drivers/net/wireless/rt2x00/rt2x00pci.c b/drivers/net/wireless/rt2x00/rt2x00pci.c
index 19b262e..63c2cc4 100644
--- a/drivers/net/wireless/rt2x00/rt2x00pci.c
+++ b/drivers/net/wireless/rt2x00/rt2x00pci.c
@@ -240,16 +240,16 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
struct rt2x00_dev *rt2x00dev;
int retval;
- retval = pci_request_regions(pci_dev, pci_name(pci_dev));
+ retval = pci_enable_device(pci_dev);
if (retval) {
- ERROR_PROBE("PCI request regions failed.\n");
+ ERROR_PROBE("Enable device failed.\n");
return retval;
}
- retval = pci_enable_device(pci_dev);
+ retval = pci_request_regions(pci_dev, pci_name(pci_dev));
if (retval) {
- ERROR_PROBE("Enable device failed.\n");
- goto exit_release_regions;
+ ERROR_PROBE("PCI request regions failed.\n");
+ goto exit_disable_device;
}
pci_set_master(pci_dev);
@@ -260,14 +260,14 @@ int rt2x00pci_probe(struct pci_dev *pci_dev, const struct pci_device_id *id)
if (dma_set_mask(&pci_dev->dev, DMA_BIT_MASK(32))) {
ERROR_PROBE("PCI DMA not supported.\n");
retval = -EIO;
- goto exit_disable_device;
+ goto exit_release_regions;
}
hw = ieee80211_alloc_hw(sizeof(struct rt2x00_dev), ops->hw);
if (!hw) {
ERROR_PROBE("Failed to allocate hardware.\n");
retval = -ENOMEM;
- goto exit_disable_device;
+ goto exit_release_regions;
}
pci_set_drvdata(pci_dev, hw);
@@ -300,13 +300,12 @@ exit_free_reg:
exit_free_device:
ieee80211_free_hw(hw);
-exit_disable_device:
- if (retval != -EBUSY)
- pci_disable_device(pci_dev);
-
exit_release_regions:
pci_release_regions(pci_dev);
+exit_disable_device:
+ pci_disable_device(pci_dev);
+
pci_set_drvdata(pci_dev, NULL);
return retval;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 04/11] cxgb4vf: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors; +Cc: David S. Miller, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/cxgb4vf/cxgb4vf_main.c | 31 ++++++++++++++++---------------
1 files changed, 16 insertions(+), 15 deletions(-)
diff --git a/drivers/net/cxgb4vf/cxgb4vf_main.c b/drivers/net/cxgb4vf/cxgb4vf_main.c
index a165632..7b6d07f 100644
--- a/drivers/net/cxgb4vf/cxgb4vf_main.c
+++ b/drivers/net/cxgb4vf/cxgb4vf_main.c
@@ -2462,23 +2462,24 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
version_printed = 1;
}
+
/*
- * Reserve PCI resources for the device. If we can't get them some
- * other driver may have already claimed the device ...
+ * Initialize generic PCI device state.
*/
- err = pci_request_regions(pdev, KBUILD_MODNAME);
+ err = pci_enable_device(pdev);
if (err) {
- dev_err(&pdev->dev, "cannot obtain PCI resources\n");
+ dev_err(&pdev->dev, "cannot enable PCI device\n");
return err;
}
/*
- * Initialize generic PCI device state.
+ * Reserve PCI resources for the device. If we can't get them some
+ * other driver may have already claimed the device ...
*/
- err = pci_enable_device(pdev);
+ err = pci_request_regions(pdev, KBUILD_MODNAME);
if (err) {
- dev_err(&pdev->dev, "cannot enable PCI device\n");
- goto err_release_regions;
+ dev_err(&pdev->dev, "cannot obtain PCI resources\n");
+ goto err_disable_device;
}
/*
@@ -2491,14 +2492,14 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "unable to obtain 64-bit DMA for"
" coherent allocations\n");
- goto err_disable_device;
+ goto err_release_regions;
}
pci_using_dac = 1;
} else {
err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32));
if (err != 0) {
dev_err(&pdev->dev, "no usable DMA configuration\n");
- goto err_disable_device;
+ goto err_release_regions;
}
pci_using_dac = 0;
}
@@ -2514,7 +2515,7 @@ static int __devinit cxgb4vf_pci_probe(struct pci_dev *pdev,
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
err = -ENOMEM;
- goto err_disable_device;
+ goto err_release_regions;
}
pci_set_drvdata(pdev, adapter);
adapter->pdev = pdev;
@@ -2750,13 +2751,13 @@ err_free_adapter:
kfree(adapter);
pci_set_drvdata(pdev, NULL);
-err_disable_device:
- pci_disable_device(pdev);
- pci_clear_master(pdev);
-
err_release_regions:
pci_release_regions(pdev);
pci_set_drvdata(pdev, NULL);
+ pci_clear_master(pdev);
+
+err_disable_device:
+ pci_disable_device(pdev);
err_out:
return err;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 05/11] via-velocity: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Francois Romieu, David S. Miller, Simon Kagstrom, Ben Hutchings,
Jiri Pirko, Eric Dumazet, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/via-velocity.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/via-velocity.c b/drivers/net/via-velocity.c
index 42dffd3..fd69095 100644
--- a/drivers/net/via-velocity.c
+++ b/drivers/net/via-velocity.c
@@ -2763,12 +2763,12 @@ static int __devinit velocity_found1(struct pci_dev *pdev, const struct pci_devi
vptr->dev = dev;
- dev->irq = pdev->irq;
-
ret = pci_enable_device(pdev);
if (ret < 0)
goto err_free_dev;
+ dev->irq = pdev->irq;
+
ret = velocity_get_pci_info(vptr, pdev);
if (ret < 0) {
/* error message already printed */
--
1.7.0.4
^ permalink raw reply related
* [PATCH 03/11] cxgb3: do not use PCI resources before pci_enable_device()
From: Kulikov Vasiliy @ 2010-08-03 15:43 UTC (permalink / raw)
To: kernel-janitors
Cc: Divy Le Ray, David S. Miller, Roland Dreier, Steve Wise,
Ben Hutchings, netdev, linux-kernel
IRQ and resource[] may not have correct values until
after PCI hotplug setup occurs at pci_enable_device() time.
The semantic match that finds this problem is as follows:
// <smpl>
@@
identifier x;
identifier request ~= "pci_request.*|pci_resource.*";
@@
(
* x->irq
|
* x->resource
|
* request(x, ...)
)
...
*pci_enable_device(x)
// </smpl>
Signed-off-by: Kulikov Vasiliy <segooon@gmail.com>
---
drivers/net/cxgb3/cxgb3_main.c | 25 +++++++++++++------------
1 files changed, 13 insertions(+), 12 deletions(-)
diff --git a/drivers/net/cxgb3/cxgb3_main.c b/drivers/net/cxgb3/cxgb3_main.c
index 066fd5b..ad19585 100644
--- a/drivers/net/cxgb3/cxgb3_main.c
+++ b/drivers/net/cxgb3/cxgb3_main.c
@@ -3198,17 +3198,17 @@ static int __devinit init_one(struct pci_dev *pdev,
}
}
- err = pci_request_regions(pdev, DRV_NAME);
+ err = pci_enable_device(pdev);
if (err) {
- /* Just info, some other driver may have claimed the device. */
- dev_info(&pdev->dev, "cannot obtain PCI resources\n");
- return err;
+ dev_err(&pdev->dev, "cannot enable PCI device\n");
+ goto out;
}
- err = pci_enable_device(pdev);
+ err = pci_request_regions(pdev, DRV_NAME);
if (err) {
- dev_err(&pdev->dev, "cannot enable PCI device\n");
- goto out_release_regions;
+ /* Just info, some other driver may have claimed the device. */
+ dev_info(&pdev->dev, "cannot obtain PCI resources\n");
+ goto out_disable_device;
}
if (!pci_set_dma_mask(pdev, DMA_BIT_MASK(64))) {
@@ -3217,11 +3217,11 @@ static int __devinit init_one(struct pci_dev *pdev,
if (err) {
dev_err(&pdev->dev, "unable to obtain 64-bit DMA for "
"coherent allocations\n");
- goto out_disable_device;
+ goto out_release_regions;
}
} else if ((err = pci_set_dma_mask(pdev, DMA_BIT_MASK(32))) != 0) {
dev_err(&pdev->dev, "no usable DMA configuration\n");
- goto out_disable_device;
+ goto out_release_regions;
}
pci_set_master(pdev);
@@ -3234,7 +3234,7 @@ static int __devinit init_one(struct pci_dev *pdev,
adapter = kzalloc(sizeof(*adapter), GFP_KERNEL);
if (!adapter) {
err = -ENOMEM;
- goto out_disable_device;
+ goto out_release_regions;
}
adapter->nofail_skb =
@@ -3370,11 +3370,12 @@ out_free_dev:
out_free_adapter:
kfree(adapter);
-out_disable_device:
- pci_disable_device(pdev);
out_release_regions:
pci_release_regions(pdev);
+out_disable_device:
+ pci_disable_device(pdev);
pci_set_drvdata(pdev, NULL);
+out:
return err;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] hso: Add new product ID
From: Filip Aben @ 2010-08-03 15:36 UTC (permalink / raw)
To: davem-fT/PcQaiUtIeIZ0/mPfg9Q, gregkh-l3A5Bk7waGM
Cc: linux-usb-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
This patch adds a new product ID to the hso driver.
Signed-off-by: Filip Aben <f.aben-x9gZzRpC1QbQT0dZR+AlfA@public.gmane.org>
---
diff --git a/drivers/net/usb/hso.c b/drivers/net/usb/hso.c
index 4dd2351..041f0e3 100644
--- a/drivers/net/usb/hso.c
+++ b/drivers/net/usb/hso.c
@@ -478,6 +478,7 @@ static const struct usb_device_id hso_ids[] = {
{USB_DEVICE(0x0af0, 0x8600)},
{USB_DEVICE(0x0af0, 0x8800)},
{USB_DEVICE(0x0af0, 0x8900)},
+ {USB_DEVICE(0x0af0, 0x9000)},
{USB_DEVICE(0x0af0, 0xd035)},
{USB_DEVICE(0x0af0, 0xd055)},
{USB_DEVICE(0x0af0, 0xd155)},
--
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 related
* [PATCH] about net/core/pktgen.c module.
From: ustc.mail @ 2010-08-03 15:20 UTC (permalink / raw)
To: robert, netdev; +Cc: robert.olsson
Hi,
I find that there is a bug in the pktgen kernel packet generator. It's
my first time to add a patch, so welcome to give me suggestion about
patch work.
description: the bug makes the first generated packets (one or more
which depend on the configuration from usespace script.)enter to the
same NIC queue of multi-queue NIC for the wrong position of
mod_cur_headers(pkt_dev) call while building the IPV4 and IPV6
skb_buff.
kernel version: linux-2.6.33.3
file: linux-2.6.33.3/net/core/pktgen.c
result: while setting skb_clone more than one, specially for a
considerable number, the multiqueue function is not efficient for its
wrong queue_map value.
patch as following:
--- pktgen.c 2010-08-03 22:46:55.001682745 +0800
+++ pktgen.patch.c 2010-08-03 22:48:03.367409102 +0800
@@ -2567,8 +2567,8 @@
/* Update any of the values, used when we're incrementing various
* fields.
*/
- queue_map = pkt_dev->cur_queue_map;
mod_cur_headers(pkt_dev);
+ queue_map = pkt_dev->cur_queue_map;
datalen = (odev->hard_header_len + 16) & ~0xf;
skb = __netdev_alloc_skb(odev,
@@ -2913,8 +2913,8 @@
/* Update any of the values, used when we're incrementing various
* fields.
*/
- queue_map = pkt_dev->cur_queue_map;
mod_cur_headers(pkt_dev);
+ queue_map = pkt_dev->cur_queue_map;
skb = __netdev_alloc_skb(odev,
pkt_dev->cur_pkt_size + 64
--------------------------------------patch
end-------------------------------------------------
Best regards!
from backyes
---------------------------------------reply
end-------------------------------------------------
On Tue, Aug 3, 2010 at 10:30 PM, ustc.mail <backyes@mail.ustc.edu.cn> wrote:
> Thanks for your reply!
> It's my pleasure to patch it.
> -Yanfei
>
> On Tue, Aug 3, 2010 at 7:44 PM, <robert@herjulf.net> wrote:
>>
>> > Dear robert, I am doing some research on the
>> >pktgen.c implementation. While reading the source code, I find some
>> >doubts about cur->cur_queue_map for multiqueue NIC . The following
>> >code is from pktgen.c in kernel 2.6.33.3. For line 2919 and line
>> >2920, the first generated packets is sent to same queue of NIC for
>> >every thread. Because the the first generated packets is sent while
>> >the cur_queue_map is not setted yet. "reverse the two line" is OK.
>> >Am I right?
>>
>> Right first time we're using queue_map that's not been set by
>> set_cur_queue_map(pkt_dev);
>>
>> queue_map = pkt_dev->cur_queue_map;
>> mod_cur_headers(pkt_dev);
>>
>> Can you make a patch and submit to netdev?
>>
>>
>> --ro
>>
>
>
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 15:27 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <201008031817.40664.remi@remlab.net>
[-- Attachment #1: Type: text/plain, Size: 1134 bytes --]
On Tue, Aug 03, 2010 at 06:17:40PM +0300, Rémi Denis-Courmont wrote:
> > And what happens when IPv8 comes along?
> > Or we want to parse IPX/SPX or
> > any of those thousands of other network protocols?
>
> It does not work. That's why your SKB_TRANS_OFF proposal sucks totally because
> it is not implementable. On the other hand, n IPv6-specific opcode sucks only
> a little due to its ugliness and lack of forward compatibility.
Huh? So now you want to make every BPF program IPv6-specific, so we've
no hope in hell of making them cope with The Next Big Thing? As opposed
to my idea, which makes them neutral on the subject, and puts all the
knowledge of the protocol in the -kernel-, where we can easily implement
new things?
When some brandnew protocol comes long we'd like to filter on, kernel is
going to have to know about it. Which is -exactly- the same as the
current situation with regards SKF_NET_OFF / SKF_AD_PROTO, so I don't
really see what difference that makes.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: softirq warnings when calling dev_kfree_skb_irq - bug in conntrack?
From: Jeremy Fitzhardinge @ 2010-08-03 15:24 UTC (permalink / raw)
To: David Miller
Cc: johannes, netdev, dongxiao.xu, Xen-devel, Ian.Campbell, kaber,
eric.dumazet
In-Reply-To: <20100803.002318.209965574.davem@davemloft.net>
On 08/03/2010 12:23 AM, David Miller wrote:
> From: Johannes Berg<johannes@sipsolutions.net>
> Date: Tue, 03 Aug 2010 09:04:34 +0200
>
>> I had this too:
>> http://article.gmane.org/gmane.linux.network/167590
>>
>> But I'm not convinced it's conntrack, I'd think it's
>>
>> commit 15e83ed78864d0625e87a85f09b297c0919a4797
>> Author: Eric Dumazet<eric.dumazet@gmail.com>
>> Date: Wed May 19 23:16:03 2010 +0000
>>
>> net: remove zap_completion_queue
>>
>> which, from the looks of it, ought to be reverted because it failed to
>> take into account that dev_kfree_skb() can do more things that require
>> non-irq-context than just calling skb->destructor, like for instance the
>> conntrack thing we see here.
> Agreed. I'll revert this and queue that up for 2.6.35-stable
>
FWIW I only see this in linux-next, not released 2.6.35. But it does
look like a likely root cause.
J
^ permalink raw reply
* Re: [PATCH] can-raw: Fix skb_orphan_try handling
From: Oliver Hartkopp @ 2010-08-03 15:22 UTC (permalink / raw)
To: David Miller
Cc: socketcan-core-0fE9KPoRgkgATYTw5x5z8w,
netdev-u79uwXL29TY76Z2rM5mHXA,
patrick.ohly-ral2JQCrhuEAvxtiuMwx3w,
eric.dumazet-Re5JQEeQqe8AvxtiuMwx3w
In-Reply-To: <20100803.003056.216763358.davem-fT/PcQaiUtIeIZ0/mPfg9Q@public.gmane.org>
On 03.08.2010 09:30, David Miller wrote:
> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
> Date: Sun, 01 Aug 2010 12:50:16 +0200
>
>> On 01.08.2010 10:03, David Miller wrote:
>>> From: Oliver Hartkopp <socketcan-fJ+pQTUTwRTk1uMJSBkQmQ@public.gmane.org>
>>> Date: Fri, 30 Jul 2010 11:44:27 +0200
>>>
>>>> Hello Eric, hello Patrick,
>>>>
>>>> Commit fc6055a5ba31e2c14e36e8939f9bf2b6d586a7f5 (net: Introduce
>>>> skb_orphan_try()) allows an early orphan of the skb and takes care on
>>>> tx timestamping, which needs the sk-reference in the skb on driver level.
>>>> So does the can-raw socket, which has not been taken into account here.
>>>>
>>>> The patch below adds a 'prevent_sk_orphan' bit in the skb tx shared info,
>>>> which fixes the problem discovered by Matthias Fuchs here:
>>>>
>>>> http://marc.info/?t=128030411900003&r=1&w=2
>>>
>>> Your patch sets this new value, but I never see it getting tested anywhere.
>>>
>>> How does this work?
>>
>>
>> The flags are tested all together in skb_orphan_try() ...
>
> This is why I hate using unions in situations like this... it makes
> code impossible to audit easily.
>
> This damn thing should just be a "u8 flags" and a bunch of bit mask
> CPP macro defines for the various boolean values.
Yep! I also felt like this.
Maybe Patrick Ohly can give some feedback, if he's ok with that kind of
change. So far there are only a few places that would need to be changed for
the flags bitops.
> Anyways, I'll apply your patch thanks.
Thanks!
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Rémi Denis-Courmont @ 2010-08-03 15:17 UTC (permalink / raw)
To: netdev
In-Reply-To: <20100803141924.GV11110@cel.leo>
Le mardi 3 août 2010 17:19:24 Paul LeoNerd Evans, vous avez écrit :
> On Tue, Aug 03, 2010 at 04:16:02PM +0200, Rémi Denis-Courmont wrote:
> > > Is there any way it could be done lazily, at the moment that filter.c
> > > knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
> >
> > You would essentially need to implement dedicated parsing for each
> > protocols family.
> > So you might as well add an opcode dedicated to IPv6...
>
> And what happens when IPv8 comes along?
> Or we want to parse IPX/SPX or
> any of those thousands of other network protocols?
It does not work. That's why your SKB_TRANS_OFF proposal sucks totally because
it is not implementable. On the other hand, n IPv6-specific opcode sucks only
a little due to its ugliness and lack of forward compatibility.
--
Rémi Denis-Courmont
http://www.remlab.net/
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* [ANNOUNCE]: Release of iptables-1.4.9
From: Patrick McHardy @ 2010-08-03 15:17 UTC (permalink / raw)
To: Netfilter Development Mailinglist
Cc: Linux Netdev List, 'netfilter@vger.kernel.org',
netfilter-announce
[-- Attachment #1: Type: text/plain, Size: 769 bytes --]
The netfilter coreteam presents:
iptables version 1.4.9
the iptables release for the 2.6.35 kernel. Changes include:
- support for the LED target, which hadn't been merged so far because
the kernel module had some bugs
- a new version of the set extension for the upcoming release supporting
IPv6
- negation support for the quota match
- support for the SACK-IMMEDIATELY SCTP extension and FORWARD_TSN
chunk type in the sctp match
- documentation updates and various smaller bugfixes
See the Changelog for more details.
Version 1.4.9 can be obtained from:
http://www.netfilter.org/projects/iptables/downloads.html
ftp://ftp.netfilter.org/pub/iptables/
git://git.netfilter.org/iptables.git
On behalf of the Netfilter Core Team.
Happy firewalling!
[-- Attachment #2: changes-iptables-1.4.9.txt --]
[-- Type: text/plain, Size: 1338 bytes --]
Adam Nielsen (1):
extensions: add the LED target
Eric Dumazet (1):
extensions: REDIRECT: add random help
Jan Engelhardt (10):
utils: add missing include flags to Makefile
doc: xt_string: correct copy-and-pasting in manpage
doc: xt_hashlimit: fix a typo
doc: xt_LED: nroff formatting requirements
includes: sync header files from Linux 2.6.35-rc1
xtables: another try at chain name length checking
xtables: remove xtables_set_revision function
libxt_hashlimit: always print burst value
libxt_conntrack: do print netmask
xt_quota: also document negation
Jozsef Kadlecsik (1):
libxt_set: new revision added
Luciano Coelho (2):
extensions: libxt_rateest: fix typo in the man page
extensions: libxt_rateest: fix bps options for iptables-save
Patrick McHardy (5):
Revert "Revert "Merge branch 'iptables-next'""
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'master' of git://dev.medozas.de/iptables
Merge branch 'master' of vishnu.netfilter.org:/data/git/iptables
Bump version to 1.4.9
Samuel Ortiz (1):
extensions: libxt_quota.c: Support option negation
Shan Wei (2):
xt_sctp: Trace DATA chunk that supports SACK-IMMEDIATELY extension
xt_sctp: support FORWARD_TSN chunk type
^ permalink raw reply
* Re: [PATCH net-next 3/3] drivers/net/bfin_mac.c: Misc function cleanups, neatening
From: Denis Kirjanov @ 2010-08-03 14:48 UTC (permalink / raw)
To: Robin Getz
Cc: Joe Perches, Mike Frysinger, Hennerich, Michael,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org
In-Reply-To: <201008030940.28831.rgetz@blackfin.uclinux.org>
On Tue, Aug 3, 2010 at 5:40 PM, Robin Getz <rgetz@blackfin.uclinux.org> wrote:
> On Thu 29 Jul 2010 21:45, Joe Perches pondered:
>> On Thu, 2010-07-29 at 20:18 -0400, Mike Frysinger wrote:
>> > i'll ack the idea, but i think it better i pull these patches into the
>> > Blackfin repo to get some real hardware testing before i forward them
>> > back to David/netdev ...
>> >
>> > that OK with you ?
>>
>> Fine by me. These are trivial patches.
>> I don't have the hardware.
>
> Do you want the hardware?
>
> I'm moving my office, and found some extras if anyone wants them...
I can take one if that is no problem..
>
> -Robin
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Regards,
Denis
^ permalink raw reply
* Re: [patch] usbnet: fix 100% CPU use on suspended device
From: Oliver Neukum @ 2010-08-03 14:39 UTC (permalink / raw)
To: Elly Jones
Cc: Alan Stern, David Miller, netdev-u79uwXL29TY76Z2rM5mHXA, USB list
In-Reply-To: <AANLkTi=KbThErL-jXXSVGdkod-p7B7u6eDL5LtnU5SG--JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Am Montag, 2. August 2010, 15:31:33 schrieb Elly Jones:
> On Mon, Jul 26, 2010 at 12:21 PM, Oliver Neukum <oliver-GvhC2dPhHPQdnm+yROfE0A@public.gmane.org> wrote:
> > Am Montag, 26. Juli 2010, 17:13:23 schrieb Alan Stern:
> >> On Mon, 26 Jul 2010, Elly Jones wrote:
> >>
> >> > > This isn't right. The problem should be fixed some other way. Under
> >> > > what circumstances are URBs submitted incorrectly?
> >> >
> >> > When the device is autosuspended. What is the proper thing for a
> >> > device to do here?
> >>
> >> From looking at the code, it appears that the EVENT_DEV_ASLEEP flag
> >> should be tested in usbnet_bh() the way it is in rx_submit(). But I'm
> >> not an expert on usbnet; we should ask someone who is, like Oliver.
> >
> > Sorry, I didn't notice this thread.
> >
> > The correct way to check for autosuspend in usbnet is to look
> > at EVENT_DEV_ASLEEP under txq.lock. That being said, usbnet_bh()
> > uses rx_submit() which does the correct check. The bug seems to be
> > a lack of error handling in usbnet_bh() regarding the return of rx_submit()
>
> If rx_submit() fails, should usbnet_bh() just not tasklet_schedule() itself?
That would not work unless the cause of the failure would be removed.
If you get -ENOLINK the sane option seems to me to give up.
Regards
Oliver
--
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: RFC: New BGF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:34 UTC (permalink / raw)
To: Andi Kleen, netdev; +Cc: David Miller
In-Reply-To: <20100803141110.GT11110@cel.leo>
[-- Attachment #1: Type: text/plain, Size: 1287 bytes --]
On Tue, Aug 03, 2010 at 03:11:10PM +0100, Paul LeoNerd Evans wrote:
> switch(hdrtype)
> {
> case 1:
> length = someconst; break;
> case 2:
> length = someotherconst; break;
> case 3:
> length = b[someoffset]; break;
> ...
> }
Of course, I completely forgot about finding also the offset of the
'next header' from the current header. That results in some code which,
in C, would look like:
int hdrtype = b[IPv6_nexthdr];
int x = size_of_IPv6_header;
while(hdrtype != hdr_wanted) {
int len;
switch(hdrtype) {
case 1:
len = someconst;
hdrtype = someotherconst;
break;
case 2:
len = b[x+someoffs];
hdrtype = b[x+someotheroffs];
break;
/* other IPv6 header types here */
}
x += len;
}
You can't compile that idea into BPF without using a scratch memory
cell, because you can't have both 'len' and 'hdrtype' live in A at the
same time, nor can you atomically x += b[x+someoffs].
In short, much much easier if the C code did this part...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH 2/8] davinci: add mdio platform devices
From: Cyril Chemparathy @ 2010-08-03 14:32 UTC (permalink / raw)
To: Igor Grinberg
Cc: netdev@vger.kernel.org,
davinci-linux-open-source@linux.davincidsp.com,
linux-omap@vger.kernel.org, Nori, Sekhar,
Govindarajan, Sriramakrishnan
In-Reply-To: <4C58227A.4080502@compulab.co.il>
Hi Igor,
> Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
> I think it should, or else it will be broken by:
> [PATCH 5/8] netdev: cleanup unused davinci mdio emac code
Correct. As stated in the series summary:
> Additional omap tree patches will be required for am35xx as well
> (not included here).
Regards
Cyril.
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:19 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <f350f48de92da479bfb224527bc70c10@chewa.net>
[-- Attachment #1: Type: text/plain, Size: 1082 bytes --]
On Tue, Aug 03, 2010 at 04:16:02PM +0200, Rémi Denis-Courmont wrote:
> > Is there any way it could be done lazily, at the moment that filter.c
> > knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
>
> You would essentially need to implement dedicated parsing for each
> protocols family.
> So you might as well add an opcode dedicated to IPv6...
And what happens when IPv8 comes along? Or we want to parse IPX/SPX or
any of those thousands of other network protocols?
I'd prefer to keep the BPF layer (relatively) protocol-neutral. Yes, we
have LDX MSH which with hindsight I'd say looks like a very
protocol-specific instruction. But there's nothing protocol-specific
about asking for where the transport header is and what type it is, no
moreso than asking where the network offset and type are, out of the
link-level header. This just extends that layer model.
How to -implement- it is quite another matter.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Rémi Denis-Courmont @ 2010-08-03 14:16 UTC (permalink / raw)
To: Paul LeoNerd Evans; +Cc: netdev
In-Reply-To: <20100803141313.GU11110@cel.leo>
On Tue, 3 Aug 2010 15:13:13 +0100, Paul LeoNerd Evans
<leonerd@leonerd.org.uk> wrote:
> Is there any way it could be done lazily, at the moment that filter.c
> knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO?
You would essentially need to implement dedicated parsing for each
protocols family.
So you might as well add an opcode dedicated to IPv6...
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:13 UTC (permalink / raw)
To: Rémi Denis-Courmont, netdev
In-Reply-To: <72ff93eb4581b198faa6ce62d2b5162b@chewa.net>
[-- Attachment #1: Type: text/plain, Size: 1122 bytes --]
On Tue, Aug 03, 2010 at 04:09:53PM +0200, Rémi Denis-Courmont wrote:
>
> On Tue, 3 Aug 2010 14:34:43 +0100, Paul LeoNerd Evans
> <leonerd@leonerd.org.uk> wrote:
> > What if we added a new constant SKF_TRANS_OFF to store the start address
> > of the transport header, and a new SKF_AD storage area for the transport
> > protocol:
> (...)
> > Does this sound workable?
>
> The network header has not been processed by the time the skbuff hits the
> packet socket. So the transport header offset is not defined yet.
Is there any way it could be done lazily, at the moment that filter.c
knows it has to provide either SKF_TRANS_OFF or SKF_AD_TRANSPROTO? It
doesn't even need to do a full parse, just enough to find the length and
protocol type.
That processing -has- to be done one way or another, if BPF is ever to
support filtering on TCP headers in IPv6 in a sane way. Either encode
the algorithm in BPF, or in compiled C code - the latter would be more
performant.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BGF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 14:11 UTC (permalink / raw)
To: Andi Kleen, netdev; +Cc: David Miller
In-Reply-To: <20100803140539.GE31096@basil.fritz.box>
[-- Attachment #1: Type: text/plain, Size: 1706 bytes --]
On Tue, Aug 03, 2010 at 04:05:39PM +0200, Andi Kleen wrote:
> Well you could generalize it, like "SKIP headers where length
> is at offset X and type at offset Y"
Except that doesn't work for IPv6.
Some IPv6 headers are implied-length; their length never appears in the
packet. You have to "just know".
Some IPv6 headers store their length somewhere in the header body.
Different headers use different offsets within the body.
Some IPv6 headers do not make their length known on the wire -at all-,
such as IPsec's AH. Only the IPsec endpoints know how long this header
is.
This is what makes IPv6 -really- difficult to actually parse like this.
Ignoring even for a moment the impossible ones (IPsec's AH and ESP), the
rest of the headers end up becoming a giant lookup table, analogous to:
switch(hdrtype)
{
case 1:
length = someconst; break;
case 2:
length = someotherconst; break;
case 3:
length = b[someoffset]; break;
...
}
This is why I wanted a LOOP instruction, the above switch code could
then be written -once- in BPF and LOOP'ed over to find the required
header. Instead, that loop must be statically unrolled some number of
times into an n-times-longer program script of less-than-equivalent
power. E.g. tcpdump/libpcap unrolls it a statically-configured 6 times,
meaning if the packet is particularly large, and the header comes 7th,
you'll never see it. My LOOP idea would mean the code is run once for
every header in the packet, regardless how many there were.
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Rémi Denis-Courmont @ 2010-08-03 14:09 UTC (permalink / raw)
To: Paul LeoNerd Evans; +Cc: netdev
In-Reply-To: <20100803133442.GQ11110@cel.leo>
On Tue, 3 Aug 2010 14:34:43 +0100, Paul LeoNerd Evans
<leonerd@leonerd.org.uk> wrote:
> What if we added a new constant SKF_TRANS_OFF to store the start address
> of the transport header, and a new SKF_AD storage area for the transport
> protocol:
(...)
> Does this sound workable?
The network header has not been processed by the time the skbuff hits the
packet socket. So the transport header offset is not defined yet.
--
Rémi Denis-Courmont
http://www.remlab.net
http://fi.linkedin.com/in/remidenis
^ permalink raw reply
* Re: [PATCH 2/8] davinci: add mdio platform devices
From: Igor Grinberg @ 2010-08-03 14:06 UTC (permalink / raw)
To: Cyril Chemparathy
Cc: netdev, davinci-linux-open-source, linux-omap, nsekhar, srk
In-Reply-To: <1280842313-3743-3-git-send-email-cyril@ti.com>
On 08/03/10 16:31, Cyril Chemparathy wrote:
> This patch adds mdio platform devices on SoCs that have the necessary
> hardware. Clock lookup entries (aliases) have also been added, so that the
> MDIO and EMAC drivers can independently enable/disable a shared underlying
> clock. Further, the EMAC MMR region has been split down into separate MDIO
> and EMAC regions.
>
> Signed-off-by: Cyril Chemparathy <cyril@ti.com>
> ---
> arch/arm/mach-davinci/devices-da8xx.c | 29 +++++++++++++++++++++++++-
> arch/arm/mach-davinci/dm365.c | 22 +++++++++++++++++++-
> arch/arm/mach-davinci/dm644x.c | 22 +++++++++++++++++++-
> arch/arm/mach-davinci/dm646x.c | 22 +++++++++++++++++++-
> arch/arm/mach-davinci/include/mach/dm365.h | 1 +
> arch/arm/mach-davinci/include/mach/dm644x.h | 1 +
> arch/arm/mach-davinci/include/mach/dm646x.h | 1 +
> 7 files changed, 93 insertions(+), 5 deletions(-)
>
Shouldn't arch/arm/mach-omap2/board-am3517evm.c be on your list?
I think it should, or else it will be broken by:
[PATCH 5/8] netdev: cleanup unused davinci mdio emac code
--
Regards,
Igor.
^ permalink raw reply
* Re: RFC: New BGF 'LOOP' instruction
From: Andi Kleen @ 2010-08-03 14:05 UTC (permalink / raw)
To: David Miller; +Cc: andi, leonerd, netdev
In-Reply-To: <20100803.060754.26959298.davem@davemloft.net>
On Tue, Aug 03, 2010 at 06:07:54AM -0700, David Miller wrote:
> From: Andi Kleen <andi@firstfloor.org>
> Date: Tue, 03 Aug 2010 14:58:02 +0200
>
> > David Miller <davem@davemloft.net> writes:
> >>
> >> That makes the looping construct largely useless, which I mentioned in
> >> my second reply to this thread.
> >
> > How about simply adding a "skip ipv6 extension headers until header type
> > X" opcode?
> >
> > I bet that would solve most of the problems here in practice.
>
> BPF really should not have protocol specific opcodes.
Well you could generalize it, like "SKIP headers where length
is at offset X and type at offset Y"
-Andi
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: RFC: New BPF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 13:42 UTC (permalink / raw)
To: netdev; +Cc: andi
In-Reply-To: <20100803133442.GQ11110@cel.leo>
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
On Tue, Aug 03, 2010 at 02:34:43PM +0100, Paul LeoNerd Evans wrote:
> LD BYTE[SKF_NET_OFF+0]
> JEQ 80, #accept, 0
> LD BYTE[SKF_NET_OFF+2]
> JEQ 80, 0, #reject
My apologies; theabove should be "LD HALF" instructions; TCP ports are
16 bit quantities. Hopefully this mistake does not detract from my
argument...
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: RFC: New BGF 'LOOP' instruction
From: Paul LeoNerd Evans @ 2010-08-03 13:40 UTC (permalink / raw)
To: Hagen Paul Pfeifer, netdev; +Cc: David Miller
In-Reply-To: <6809423e656a160df11216ea5acc3d8b@localhost>
[-- Attachment #1: Type: text/plain, Size: 1812 bytes --]
On Tue, Aug 03, 2010 at 11:10:28AM +0200, Hagen Paul Pfeifer wrote:
> >> Rightnow, BPF is all but useless for parsing, say, IPv6. I only pick
> >> IPv6 as one example, I'm sure there must exist a great number more
> >> packet-based protocols that use a "linked-list" style approach to
> >> headers. None of those are currently filterable on the current set of
> >> instructions. LOOP would allow these.
> >
> > It's not meant for detailed packet protocol header analysis,
> > it's for stateless straight line matching of masked values
> > in packet headers.
>
> David is right, BPF cannot - and will not - keep with any high level
> connection tracking packet filter. There is an processing trade-off between
> packet classification and packet storage with post processing analysis.
This has nothing to do with high-level connection tracking.
I want to accept all (IPv4 or IPv6) TCP packets concerning port 80.
That's all. No connection tracking. Simply a "stateless straight line
matching of masked values in packet headers". Namely, the TCP source or
destination ports, being 80.
Should BPF be allowed to implement such a filter?
This is the core question.
If yes, then we either need LOOP, or alternatively my SKF_AD_TRANSPROTO
/ SKF_TRANS_OFF idea (see the other thread fork). Without either LOOP or
TRANSPROTO, it becomes next-to-impossible to -find- the TCP header in an
IPv6 packet, and hence make filtering decisions based on it.
If no, please justify what BPF -is- for then, given that right now
applications like tcpdump/libpcap already use it for this very purpose.
Please further justify why BPF has the "LDX MSH" instruction
--
Paul "LeoNerd" Evans
leonerd@leonerd.org.uk
ICQ# 4135350 | Registered Linux# 179460
http://www.leonerd.org.uk/
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 190 bytes --]
^ permalink raw reply
* Re: [PATCH net-next 3/3] drivers/net/bfin_mac.c: Misc function cleanups, neatening
From: Robin Getz @ 2010-08-03 13:40 UTC (permalink / raw)
To: Joe Perches
Cc: Mike Frysinger, Hennerich, Michael, netdev@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <1280454323.21777.4.camel@Joe-Laptop.home>
On Thu 29 Jul 2010 21:45, Joe Perches pondered:
> On Thu, 2010-07-29 at 20:18 -0400, Mike Frysinger wrote:
> > i'll ack the idea, but i think it better i pull these patches into the
> > Blackfin repo to get some real hardware testing before i forward them
> > back to David/netdev ...
> >
> > that OK with you ?
>
> Fine by me. These are trivial patches.
> I don't have the hardware.
Do you want the hardware?
I'm moving my office, and found some extras if anyone wants them...
-Robin
^ 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