* Re: [PATCH] e1000: the power down when running ifdown command
From: Jeff Kirsher @ 2009-11-03 21:37 UTC (permalink / raw)
To: Naohiro Ooiwa
Cc: jesse.brandeburg, peter.p.waskiewicz.jr, john.ronciak, davem,
Andrew Morton, netdev, svaidy, e1000-devel
In-Reply-To: <4AF00097.4040708@miraclelinux.com>
2009/11/3 Naohiro Ooiwa <nooiwa@miraclelinux.com>:
> Jeff Kirsher wrote:
>> 2009/10/31 Naohiro Ooiwa <nooiwa@miraclelinux.com>:
>>
>> I have added this patch to my tree for testing. This patch requires a
>> fair amount of regression testing, so once its passed testing I will
>> push the patch to David/netdev.
>
> I appreciate the marge your tree.
> If there is anything I can do, please let me know.
>
> And I know this patch is good for e100 driver too.
> I would really like to create patch for it.
> How do you think about e100 driver.
>
>
> Thanks,
> Naohiro Ooiwa
>
Patches are always welcome (referring to a e100 patch).
As far as the e1000 patch goes, it has a number of issues which were
found in testing. Here are just a few problems we saw:
1. ethtool -t - crashes the system
2. ethtool eth0 - always shows link/speed as 1000/Full even when there
is no cable
3. ethtool -s eth0 autoneg on/off - system hang. Sometimes a copper
interface will show up as fiber after this.
4. ethtool -d/-S/-g etc - will corrupt the stats of the interface
while doing ifup/down
So it appears that more needs to be done to the driver to get this to
work as expected.
NAK
--
Cheers,
Jeff
^ permalink raw reply
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Ilpo JÀrvinen @ 2009-11-03 21:34 UTC (permalink / raw)
To: Gilad Ben-Yossef
Cc: Valdis.Kletnieks, Eric Dumazet, Andrew Morton, linux-kernel,
netdev, Ori Finkelman
In-Reply-To: <4AF08292.7090102@codefidence.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 854 bytes --]
On Tue, 3 Nov 2009, Gilad Ben-Yossef wrote:
> Eric Dumazet wrote:
>
> > Valdis.Kletnieks@vt.edu a écrit :
> >
> > > Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
> > > I'll bisect this tonight if nobody jumps up and yells they know what it
> > > is...
> > >
> Bah... this is most probably my fault. Sorry about that.
>
> Can you please try the patch in the next email?
>
> But also, can you please send me the route table in effect when this happened
> and the fetchmail command line/config (removing any passwords or account
> details of course)? I want to understand better when this happens.
According to the stacktrace, it came from ipv6 side which doesn't have any
null checking what so ever atm (you only handled ipv4 correctly). ...You
should be a bit more careful next time when adding any BUG_ONs...
--
i.
^ permalink raw reply
* Re: [PATCH 1/3] sysfs directory scaling: rbtree for dirent name lookups
From: Eric W. Biederman @ 2009-11-03 21:32 UTC (permalink / raw)
To: Benjamin LaHaise
Cc: Greg KH, Eric Dumazet, Octavian Purdila, netdev, Cosmin Ratiu,
linux-kernel
In-Reply-To: <20091103200155.GQ8227@kvack.org>
Benjamin LaHaise <bcrl@lhnet.ca> writes:
> On Mon, Nov 02, 2009 at 07:50:58PM -0800, Greg KH wrote:
>> On Sun, Nov 01, 2009 at 11:31:30AM -0500, Benjamin LaHaise wrote:
>> > Use an rbtree in sysfs_dirent to speed up file lookup times
>> >
>> > Systems with large numbers (tens of thousands and more) of network
>> > interfaces stress the sysfs code in ways that make the linear search for
>> > a name match take far too long. Avoid this by using an rbtree.
>>
>> What kind of speedups are you seeing here? And do these changes cause a
>> memory increase due to the structure changes which outweigh the
>> speedups?
>
> Depends on the number of interfaces being created. Without the patch,
> interface creation time tends to double or worse for every 5,000-10,000
> additional network interfaces.
>
>> What kind of test are you doing to reproduce this?
>
> I'm creating 30,000+ network interfaces, with the goal being 100,000.
> With other hacks in the tree to get around the sysctl and procfs scaling
> issues, as well as disabling things like NetworkManager, the results look
> as follows:
>
> Interfaces no-rb rbtree rbtree+list
> 0-5,000 13.8s 14.0s 13.0s
> 5,000-10,000 20.0s 17.4s 14.4s
> 10,000-15,000 27.3s 24.1s 16.9s
> 15,000-20,000 36.3s 32.2s 19.7s
> 20,000-25,000 45.2s 40.0s 22.9s
> 25,000-30,000 54.2s 48.2s 26.6s
> 30,000-35,000 63.9s 54.9s 30.7s
>
> Thoughts?
Something is very weird. I just took your no-rb numbers
and divided by the number of interfaces to see how well we are
scaling. I got:
Interfaces per-interface cost
5,000 0.002760s
10,000 0.002000s
15,000 0.001820s
20,000 0.001815s
25,000 0.001808s
30,000 0.001807s
35,000 0.001826s
I ran a variant of this test a long time ago and at that the
cost per interface grew with additional interfaces added. This
jives with the fact that the fundamental cost of adding N
network interfaces to sysfs is O(N^2).
Are your numbers from your application and are they real world?
In which case they are interesting, but it would be good if
we could also have microbenchmark numbers that just measure
the sysfs costs. If nothing else I am seeing a big startup
overhead that isn't being subtracted out that makes it hard
to see the real costs here.
Eric
^ permalink raw reply
* [PATCH torvalds-2.6] cdc_ether: additional Ericsson MBM PID's to the whitelist
From: Torgny Johansson @ 2009-11-03 21:28 UTC (permalink / raw)
To: davem; +Cc: netdev, saurin.shah
Hi!
This is another attempt to submit this patch that adds more Ericsson Mobile Broadband modules to the cdc_ether whitelist.
The last patch was rejected since it produced rejects with the Torvalds tree. I've tried it again after adding
another vid/pid and also rechecked it with the
checkpatch script. It still applies cleanly for me and checkpatch gives no errors or warnings.
I suspect Outlook garbles it when I send it.
Trying with another e-mail client to see if that works better. I've sent it to my own gmail first and if I "view original" in gmail
the patch works and applies cleanly after downloading it so I'm hoping it will work for you guys too.
Devices added to the whitelist:
- Ericsson Mobile Broadband variants (F3607gw, F3307 and c3607w)
- Dell F3607gw variants
- Toshiba F3607gw variants
Thanks!
Regards
Torgny Johansson
---
Signed-off-by: Torgny Johansson <torgny.johansson@gmail.com>
diff --git a/drivers/net/usb/Kconfig b/drivers/net/usb/Kconfig
index c47237c..32d9356 100644
--- a/drivers/net/usb/Kconfig
+++ b/drivers/net/usb/Kconfig
@@ -174,7 +174,7 @@ config USB_NET_CDCETHER
* Ericsson Mobile Broadband Module (all variants)
* Motorola (DM100 and SB4100)
* Broadcom Cable Modem (reference design)
- * Toshiba (PCX1100U and F3507g)
+ * Toshiba (PCX1100U and F3507g/F3607gw)
* ...
This driver creates an interface named "ethX", where X depends on
diff --git a/drivers/net/usb/cdc_ether.c b/drivers/net/usb/cdc_ether.c
index 4a6aff5..21e1ba1 100644
--- a/drivers/net/usb/cdc_ether.c
+++ b/drivers/net/usb/cdc_ether.c
@@ -544,20 +544,60 @@ static const struct usb_device_id products [] = {
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
}, {
- /* Ericsson F3307 */
+ /* Ericsson F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1905, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Ericsson F3607gw ver 3 */
USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1906, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
}, {
+ /* Ericsson F3307 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x190a, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Ericsson F3307 ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1909, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Ericsson C3607w */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0bdb, 0x1049, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
/* Toshiba F3507g */
USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130b, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
}, {
+ /* Toshiba F3607gw */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x130c, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Toshiba F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x0930, 0x1311, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
/* Dell F3507g */
USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8147, USB_CLASS_COMM,
USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
.driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Dell F3607gw */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8183, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
+}, {
+ /* Dell F3607gw ver 2 */
+ USB_DEVICE_AND_INTERFACE_INFO(0x413c, 0x8184, USB_CLASS_COMM,
+ USB_CDC_SUBCLASS_MDLM, USB_CDC_PROTO_NONE),
+ .driver_info = (unsigned long) &cdc_info,
},
{ }, // END
};
^ permalink raw reply related
* Re: [PATCH 1/2] alchemy: add au1000-eth platform device
From: Florian Fainelli @ 2009-11-03 21:14 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: Ralf Baechle, linux-mips, Manuel Lauss, David Miller, netdev
In-Reply-To: <4AE1DEFD.4090902@ru.mvista.com>
Hi Sergei,
On Friday 23 October 2009 18:51:09 Sergei Shtylyov wrote:
> Hello.
>
> Florian Fainelli wrote:
> > Please find below and updated version, hopefully addressing most if not
> > all of your comments.
>
> Thanks. I still have some comments on the code testing the NI2 bit. :-)
This version hopefully addresses your last comments. Thanks !
--
From: Florian Fainelli <florian@openwrt.org>
Subject: [PATCH 1/2] alchemy: add au1000-eth platform device (v4)
This patch makes the board code register the au1000-eth
platform device. The au1000-eth platform data can be
overriden with the au1xxx_override_eth_cfg function
like it has to be done for the Bosporus board which uses
a different MAC/PHY setup.
Changes from v3:
- declare a static au1000_eth_platform_data structure for bosporus and
initialize it
- remove parenthis and bit shifting on SYS_PF_NI2
Changes from v2:
- declared the au1000-eth second driver instance platform_data
- made the override function generic and pass it the port number too
Changes from v1:
- remove per-board platform.c file
- add an override function to pass custom eth0 platform_data PHY settings
Signed-off-by: Florian Fainelli <florian@openwrt.org>
---
diff --git a/arch/mips/alchemy/common/platform.c b/arch/mips/alchemy/common/platform.c
index 3be14b0..3fbe30c 100644
--- a/arch/mips/alchemy/common/platform.c
+++ b/arch/mips/alchemy/common/platform.c
@@ -19,6 +19,7 @@
#include <asm/mach-au1x00/au1xxx.h>
#include <asm/mach-au1x00/au1xxx_dbdma.h>
#include <asm/mach-au1x00/au1100_mmc.h>
+#include <asm/mach-au1x00/au1xxx_eth.h>
#define PORT(_base, _irq) \
{ \
@@ -326,6 +327,88 @@ static struct platform_device pbdb_smbus_device = {
};
#endif
+/* Macro to help defining the Ethernet MAC resources */
+#define MAC_RES(_base, _enable, _irq) \
+ { \
+ .start = CPHYSADDR(_base), \
+ .end = CPHYSADDR(_base + 0xffff), \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = CPHYSADDR(_enable), \
+ .end = CPHYSADDR(_enable + 0x3), \
+ .flags = IORESOURCE_MEM, \
+ }, \
+ { \
+ .start = _irq, \
+ .end = _irq, \
+ .flags = IORESOURCE_IRQ \
+ }
+
+static struct resource au1xxx_eth0_resources[] = {
+#if defined(CONFIG_SOC_AU1000)
+ MAC_RES(AU1000_ETH0_BASE, AU1000_MAC0_ENABLE, AU1000_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1100)
+ MAC_RES(AU1100_ETH0_BASE, AU1100_MAC0_ENABLE, AU1100_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1550)
+ MAC_RES(AU1550_ETH0_BASE, AU1550_MAC0_ENABLE, AU1550_MAC0_DMA_INT),
+#elif defined(CONFIG_SOC_AU1500)
+ MAC_RES(AU1500_ETH0_BASE, AU1500_MAC0_ENABLE, AU1500_MAC0_DMA_INT),
+#endif
+};
+
+static struct resource au1xxx_eth1_resources[] = {
+#if defined(CONFIG_SOC_AU1000)
+ MAC_RES(AU1000_ETH1_BASE, AU1000_MAC1_ENABLE, AU1000_MAC1_DMA_INT),
+#elif defined(CONFIG_SOC_AU1550)
+ MAC_RES(AU1550_ETH1_BASE, AU1550_MAC1_ENABLE, AU1550_MAC1_DMA_INT),
+#elif defined(CONFIG_SOC_AU1500)
+ MAC_RES(AU1500_ETH1_BASE, AU1500_MAC1_ENABLE, AU1500_MAC1_DMA_INT),
+#endif
+};
+
+static struct au1000_eth_platform_data au1xxx_eth0_platform_data = {
+ .phy1_search_mac0 = 1,
+};
+
+static struct platform_device au1xxx_eth0_device = {
+ .name = "au1000-eth",
+ .id = 0,
+ .num_resources = ARRAY_SIZE(au1xxx_eth0_resources),
+ .resource = au1xxx_eth0_resources,
+ .dev.platform_data = &au1xxx_eth0_platform_data,
+};
+
+#ifndef CONFIG_SOC_AU1100
+static struct au1000_eth_platform_data au1xxx_eth1_platform_data = {
+ .phy1_search_mac0 = 1,
+};
+
+static struct platform_device au1xxx_eth1_device = {
+ .name = "au1000-eth",
+ .id = 1,
+ .num_resources = ARRAY_SIZE(au1xxx_eth1_resources),
+ .resource = au1xxx_eth1_resources,
+ .dev.platform_data = &au1xxx_eth1_platform_data,
+};
+#endif
+
+void __init au1xxx_override_eth_cfg(unsigned int port,
+ struct au1000_eth_platform_data *eth_data)
+{
+ if (!eth_data || port > 1)
+ return;
+
+ if (port == 0)
+ memcpy(&au1xxx_eth0_platform_data, eth_data,
+ sizeof(struct au1000_eth_platform_data));
+#ifndef CONFIG_SOC_AU1100
+ else
+ memcpy(&au1xxx_eth1_platform_data, eth_data,
+ sizeof(struct au1000_eth_platform_data));
+#endif
+}
+
static struct platform_device *au1xxx_platform_devices[] __initdata = {
&au1xx0_uart_device,
&au1xxx_usb_ohci_device,
@@ -345,6 +428,7 @@ static struct platform_device *au1xxx_platform_devices[] __initdata = {
#ifdef SMBUS_PSC_BASE
&pbdb_smbus_device,
#endif
+ &au1xxx_eth0_device,
};
static int __init au1xxx_platform_init(void)
@@ -356,6 +440,12 @@ static int __init au1xxx_platform_init(void)
for (i = 0; au1x00_uart_data[i].flags; i++)
au1x00_uart_data[i].uartclk = uartclk;
+#ifndef CONFIG_SOC_AU1100
+ /* Register second MAC if enabled in pinfunc */
+ if (!(au_readl(SYS_PINFUNC) & (u32)SYS_PF_NI2))
+ platform_device_register(&au1xxx_eth1_device);
+#endif
+
return platform_add_devices(au1xxx_platform_devices,
ARRAY_SIZE(au1xxx_platform_devices));
}
diff --git a/arch/mips/alchemy/devboards/db1x00/board_setup.c b/arch/mips/alchemy/devboards/db1x00/board_setup.c
index 7aee14d..ad26db2 100644
--- a/arch/mips/alchemy/devboards/db1x00/board_setup.c
+++ b/arch/mips/alchemy/devboards/db1x00/board_setup.c
@@ -32,6 +32,7 @@
#include <linux/interrupt.h>
#include <asm/mach-au1x00/au1000.h>
+#include <asm/mach-au1x00/au1xxx_eth.h>
#include <asm/mach-db1x00/db1x00.h>
#include <asm/mach-db1x00/bcsr.h>
@@ -43,6 +44,18 @@ char irq_tab_alchemy[][5] __initdata = {
[13] = { -1, AU1500_PCI_INTA, AU1500_PCI_INTB, AU1500_PCI_INTC, AU1500_PCI_INTD }, /* IDSEL 13 - PCI slot */
};
#endif
+
+/*
+ * Micrel/Kendin 5 port switch attached to MAC0,
+ * MAC0 is associated with PHY address 5 (== WAN port)
+ * MAC1 is not associated with any PHY, since it's connected directly
+ * to the switch.
+ * no interrupts are used
+ */
+static struct au1000_eth_platform_data eth0_pdata = {
+ .phy_static_config = 1,
+ .phy_addr = 5,
+};
#ifdef CONFIG_MIPS_BOSPORUS
char irq_tab_alchemy[][5] __initdata = {
@@ -50,6 +63,8 @@ char irq_tab_alchemy[][5] __initdata = {
[12] = { -1, AU1500_PCI_INTA, 0xff, 0xff, 0xff }, /* IDSEL 12 - SN1741 */
[13] = { -1, AU1500_PCI_INTA, AU1500_PCI_INTB, AU1500_PCI_INTC, AU1500_PCI_INTD }, /* IDSEL 13 - PCI slot */
};
+
+
#endif
#ifdef CONFIG_MIPS_MIRAGE
@@ -103,6 +118,8 @@ void __init board_setup(void)
printk(KERN_INFO "AMD Alchemy Au1100/Db1100 Board\n");
#endif
#ifdef CONFIG_MIPS_BOSPORUS
+ au1xxx_override_eth_cfg(0, ð0_pdata);
+
printk(KERN_INFO "AMD Alchemy Bosporus Board\n");
#endif
#ifdef CONFIG_MIPS_MIRAGE
diff --git a/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
new file mode 100644
index 0000000..f30529e
--- /dev/null
+++ b/arch/mips/include/asm/mach-au1x00/au1xxx_eth.h
@@ -0,0 +1,18 @@
+#ifndef __AU1X00_ETH_DATA_H
+#define __AU1X00_ETH_DATA_H
+
+/* Platform specific PHY configuration passed to the MAC driver */
+struct au1000_eth_platform_data {
+ int phy_static_config;
+ int phy_search_highest_addr;
+ int phy1_search_mac0;
+ int phy_addr;
+ int phy_busid;
+ int phy_irq;
+};
+
+void __init au1xxx_override_eth_cfg(unsigned port,
+ struct au1000_eth_platform_data *eth_data);
+
+#endif /* __AU1X00_ETH_DATA_H */
+
^ permalink raw reply related
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Eric Dumazet @ 2009-11-03 21:11 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: Gregory Haskins, netdev, virtualization, kvm, linux-kernel, mingo,
linux-mm, akpm, hpa, Rusty Russell, s.hetze, Paul E. McKenney
In-Reply-To: <20091103195841.GB6669@redhat.com>
Michael S. Tsirkin a écrit :
>
> Paul, you acked this previously. Should I add you acked-by line so
> people calm down? If you would rather I replace
> rcu_dereference/rcu_assign_pointer with rmb/wmb, I can do this.
> Or maybe patch Documentation to explain this RCU usage?
>
So you believe I am over-reacting to this dubious use of RCU ?
RCU documentation is already very complex, we dont need to add yet another
subtle use, and makes it less readable.
It seems you use 'RCU api' in drivers/vhost/net.c as convenient macros :
#define rcu_dereference(p) ({ \
typeof(p) _________p1 = ACCESS_ONCE(p); \
smp_read_barrier_depends(); \
(_________p1); \
})
#define rcu_assign_pointer(p, v) \
({ \
if (!__builtin_constant_p(v) || \
((v) != NULL)) \
smp_wmb(); \
(p) = (v); \
})
There are plenty regular uses of smp_wmb() in kernel, not related to Read Copy Update,
there is nothing wrong to use barriers with appropriate comments.
(And you already use mb(), wmb(), rmb(), smp_wmb() in your patch)
BTW there is at least one locking bug in vhost_net_set_features()
Apparently, mutex_unlock() doesnt trigger a fault if mutex is not locked
by current thread... even with DEBUG_MUTEXES / DEBUG_LOCK_ALLOC
static void vhost_net_set_features(struct vhost_net *n, u64 features)
{
size_t hdr_size = features & (1 << VHOST_NET_F_VIRTIO_NET_HDR) ?
sizeof(struct virtio_net_hdr) : 0;
int i;
<<!>> mutex_unlock(&n->dev.mutex);
n->dev.acked_features = features;
smp_wmb();
for (i = 0; i < VHOST_NET_VQ_MAX; ++i) {
mutex_lock(&n->vqs[i].mutex);
n->vqs[i].hdr_size = hdr_size;
mutex_unlock(&n->vqs[i].mutex);
}
mutex_unlock(&n->dev.mutex);
vhost_net_flush(n);
}
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 21:04 UTC (permalink / raw)
To: Ivo van Doorn
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911032132.31533.IvDoorn@gmail.com>
On Tuesday 03 November 2009 21:32:30 Ivo van Doorn wrote:
> > rt2800pci patch itself has been getting dust in your tree since at least
> > April (it hasn't received any bigger updates since then)..
>
> And how many times do I have to repeat the reason?
> I think that after dozens of mails, the message should have been clear, especially
> to somebody who apparently has been monitoring and worrying about the development
> process for the last 2 years....
Just for the record:
I got only interested in rt2x00 support around April this year (while I was
doing major staging cleanups everywhere) and I was hearing back then that
rt2800pci will be merged "really soon" and that the project is making "great
progress"..
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Gertjan van Wingerde @ 2009-11-03 21:01 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA, Ivo van Doorn, Randy Dunlap,
Luis Correia, John W. Linville, Ingo Molnar, Johannes Berg,
Jarek Poplawski, Pekka Enberg, David Miller
In-Reply-To: <200911031951.05235.bzolnier-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Hi,
On 11/03/09 19:51, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> The following patch series (against wireless-next) addresses issues raised
> during code review and subsequently rejected by rt2x00/wireless/networking
> maintainers.
>
This seems to be a misrepresentation of the situation. The issues raised by
you were acknowledged as being valid, however they were not deemed important
enough to stop inclusion in wireless-next and net-next.
However, it is good to see that you have put effort in providing a patch series
for these issues.
Now, since I believe that it is better to work with people, rather than against
them, would it be possible to post this patch series somewhere as a set of
separate patches, so that they can be reviewed as such?
---
Gertjan
rt2x00 project developer
>
> Namely, it:
>
> - Adds abstraction of chipset register access for chipsets connected to
> different buses by using new structure (struct rt2800_ops) which contains
> all needed register access methods.
>
> [ It is a prerequisite for fixing code duplication between rt2800usb.c
> and rt2800pci.c drivers. ]
>
> - Fixes code duplication in rt2800usb.h and rt2800pci.h header files by
> using new shared rt2800.h header (almost 1800 LOC gone).
>
> Updated debugging scripts are located here:
>
> http://www.kernel.org/pub/linux/kernel/people/bart/rt2800/scripts/
>
> (they also work fine with older drivers)
>
> - Adds rt2800 library containing common code for PCI and USB versions
> of rt2800 chipsets. This removes over 1300 LOC and allows us to save
> a lot of maintenance burden in the future.
>
>
> It also fixes two real bugs (one in rt2800pci and one in rt2800usb) found
> as a direct result of the code de-duplication:
>
> - Fix rt2800usb driver to write the rfcsr read request into RF_CSR_CFG
> register and not BBP_CSR_CFG one in rt2800usb_rfcsr_read().
>
> - Use the correct encryption key index for TX frames in rt2800pci (this is
> based on rt2800usb patch from Benoit PAPILLAULT already in Linus' tree,
> unfortunately the fix was not ported over to rt2800pci).
>
> [ There are also some minor code rt2x00 infrastructure fixes and improvements
> here and there... ]
>
>
> All in all over 3100 LOC are gone and rt2800pci specific code is:
>
> 1685 drivers/net/wireless/rt2x00/rt2800pci.c
> 180 drivers/net/wireless/rt2x00/rt2800pci.h
> 1865 total
>
> instead of:
>
> 3323 drivers/net/wireless/rt2x00/rt2800pci.c
> 1960 drivers/net/wireless/rt2x00/rt2800pci.h
> 5283 total
>
> (wireless-next and net-next trees)
>
> which means decrease of the code needed for rt2800pci by 65% (this in turn
> translates to 31% decrease for rt2800 specific code and 9% for whole rt2x00
> infrastructure).
>
> The rewrite was quite conservative and there is still a room for improvement
> but it should serve as a good starting base for all future work on rt2800
> drivers, and there is a lot to do there (both drivers are still practically
> non-functional).
>
> Comments and patches are welcomed.
>
>
> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
> Juuso Oikarinen (1):
> wl1271: Generalize command response reading
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
>
> Bartlomiej Zolnierkiewicz (40):
> rt2800usb: fix rt2800usb_rfcsr_read()
> rt2800pci: fix crypto in TX frame
> rt2800pci: fix comment about register access
> rt2800pci: fix comment about IV/EIV fields
> rt2x00: fix rt2x00usb_register_read() comment
> rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
> rt2800usb: add rt2800_register_[read,write]() wrappers
> rt2800pci: add rt2800_register_[read,write]() wrappers
> rt2800usb: add rt2800_register_multi[read,write]() wrappers
> rt2800pci: add rt2800_register_multi[read,write]() wrappers
> rt2800usb: add rt2800_regbusy_read() wrapper
> rt2800pci: add rt2800_regbusy_read() wrapper
> rt2800usb: add rt2800_bbp_[read,write]() wrappers
> rt2800pci: add rt2800_bbp_[read,write]() wrappers
> rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
> rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
> rt2800usb: add rt2800_rf_[read,write]() wrappers
> rt2800pci: add rt2800_rf_[read,write]() wrappers
> rt2800usb: add rt2800_mcu_request() wrapper
> rt2800pci: add rt2800_mcu_request() wrapper
> rt2x00: add driver private field to struct rt2x00_dev
> rt2800usb: convert to use struct rt2800_ops methods
> rt2800pci: convert to use struct rt2800_ops methods
> rt2x00: fix rt2x00usb_register_multiwrite() arguments
> rt2x00: fix rt2x00usb_regbusy_read() arguments
> rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
> rt2800: add rt2800lib.h
> rt2800usb: fix comments in rt2800usb.h
> rt2800usb: add RXINFO_DESC_SIZE definition
> rt2800: fix duplication in header files
> rt2800: fix comments in rt2800.h
> rt2x00: add support for different chipset interfaces
> rt2800: prepare for rt2800lib addition
> rt2800: add rt2800lib (part one)
> rt2x00: remove needless ifdefs from rt2x00leds.h
> rt2800: add rt2800lib (part two)
> rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
> rt2800: add rt2800lib (part three)
> rt2800: add rt2800lib (part four)
> MAINTAINERS: add rt2800 entry
>
> MAINTAINERS | 7 +
> drivers/net/wireless/rt2x00/Kconfig | 5 +
> drivers/net/wireless/rt2x00/Makefile | 1 +
> drivers/net/wireless/rt2x00/rt2800.h | 1816 ++++++++++++++++++++++++++++
> drivers/net/wireless/rt2x00/rt2800lib.c | 1817 ++++++++++++++++++++++++++++
> drivers/net/wireless/rt2x00/rt2800lib.h | 134 +++
> drivers/net/wireless/rt2x00/rt2800pci.c | 1908 +++---------------------------
> drivers/net/wireless/rt2x00/rt2800pci.h | 1780 ----------------------------
> drivers/net/wireless/rt2x00/rt2800usb.c | 1828 ++---------------------------
> drivers/net/wireless/rt2x00/rt2800usb.h | 1818 +----------------------------
> drivers/net/wireless/rt2x00/rt2x00.h | 33 +
> drivers/net/wireless/rt2x00/rt2x00leds.h | 4 -
> drivers/net/wireless/rt2x00/rt2x00pci.h | 24 +-
> drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +-
> drivers/net/wireless/rt2x00/rt2x00usb.h | 17 +-
> 15 files changed, 4036 insertions(+), 7158 deletions(-)
> create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
> create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
To unsubscribe from this list: send the line "unsubscribe linux-wireless" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [announce] new rt2800 drivers for Ralink wireless & project tree
From: Ivo van Doorn @ 2009-11-03 21:00 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: linux-wireless, linux-kernel, netdev, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
In-Reply-To: <200911031951.05235.bzolnier@gmail.com>
On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
>
> Hi,
>
> The following patch series (against wireless-next) addresses issues raised
> during code review and subsequently rejected by rt2x00/wireless/networking
> maintainers.
Really stop reading only the half of emails, try reading it entirely (or at least don't
stop at the second word in a sentence). It really starts the bug me to repeat
myself over and over again because you refuse to read.
Your comments during code review were ACCEPTED with the only remark that
it shouldn't be done right here and now.
[snip]
> The rewrite was quite conservative and there is still a room for improvement
> but it should serve as a good starting base for all future work on rt2800
> drivers, and there is a lot to do there (both drivers are still practically
> non-functional).
Hence the reason I can use my rt2800usb device as long as I don't connect to
a 11n AP. But since everybody in the world has 11n devices, the rt2800usb device
is not capable of doing anything...
> Comments and patches are welcomed.
>
>
> The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
> Juuso Oikarinen (1):
> wl1271: Generalize command response reading
>
> are available in the git repository at:
>
> git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
>
> Bartlomiej Zolnierkiewicz (40):
> rt2800usb: fix rt2800usb_rfcsr_read()
> rt2800pci: fix crypto in TX frame
> rt2800pci: fix comment about register access
> rt2800pci: fix comment about IV/EIV fields
> rt2x00: fix rt2x00usb_register_read() comment
> rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
[.. snip..]
> rt2800usb: fix comments in rt2800usb.h
> rt2800usb: add RXINFO_DESC_SIZE definition
[..snip..]
> rt2800: fix comments in rt2800.h
[..snip..]
> rt2x00: remove needless ifdefs from rt2x00leds.h
These 10 patches look sane enough. Please send them as patch series
to linux-wireless.
> rt2x00: add support for different chipset interfaces
Not needed, you can determine exactly what chipset you have
by looking at the other fields. So extending the structure to
repeat the same information isn't needed.
> MAINTAINERS: add rt2800 entry
I see you decided to take over the maintainership?
Doesn't that need the current maintainer to move away, or was this part
of the "going over other peoples head" plan?
> rt2800usb: add rt2800_register_[read,write]() wrappers
> rt2800pci: add rt2800_register_[read,write]() wrappers
> rt2800usb: add rt2800_register_multi[read,write]() wrappers
> rt2800pci: add rt2800_register_multi[read,write]() wrappers
> rt2800usb: add rt2800_regbusy_read() wrapper
> rt2800pci: add rt2800_regbusy_read() wrapper
> rt2800usb: add rt2800_bbp_[read,write]() wrappers
> rt2800pci: add rt2800_bbp_[read,write]() wrappers
> rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
> rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
> rt2800usb: add rt2800_rf_[read,write]() wrappers
> rt2800pci: add rt2800_rf_[read,write]() wrappers
> rt2800usb: add rt2800_mcu_request() wrapper
> rt2800pci: add rt2800_mcu_request() wrapper
> rt2x00: add driver private field to struct rt2x00_dev
> rt2800usb: convert to use struct rt2800_ops methods
> rt2800pci: convert to use struct rt2800_ops methods
> rt2x00: fix rt2x00usb_register_multiwrite() arguments
> rt2x00: fix rt2x00usb_regbusy_read() arguments
> rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
> rt2800: add rt2800lib.h
> rt2800: fix duplication in header files
> rt2800: prepare for rt2800lib addition
> rt2800: add rt2800lib (part one)
> rt2800: add rt2800lib (part two)
> rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
> rt2800: add rt2800lib (part three)
> rt2800: add rt2800lib (part four)
These are too much (and too big) patches for me to review at once, I'll look at
them later.
Ivo
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Ivo van Doorn @ 2009-11-03 20:32 UTC (permalink / raw)
To: Bartlomiej Zolnierkiewicz
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911032059.23409.bzolnier@gmail.com>
On Tuesday 03 November 2009, Bartlomiej Zolnierkiewicz wrote:
> On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> > Well and then another rt2x00 developer discovered this nice little
> > fight about rt2x00 on the mailinglists...
> >
> > First for the record, because at the start people where talking about the
> > maintainership of rt2x00, one thing needs to be straight:
> >
> > As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> > for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> > drivers/net/wireless/rt2x00 folder.
> >
> > At this time I am hold the position within the rt2x00 team which is making the
> > decisions about the rt2x00 code and design.
>
> rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
You really have problems reading mails, haven't you? Or at least you
only want to read what you want to read...
Please READ the paragraph again.
I will highlight the thing again:
"about the rt2x00 code and design"
I am not talking about Ralink support I am talking about RT2X00 support.
If you feel that the maintainer of a particular driver has no say about the driver
he wrote himself, then I am not seeing the point of having maintainers. We can
then all just randomly hack in all drivers without any form of structure.
> > I am also the one that is (N)Acks the patches from others when they are send
> > to the rt2x00-users or linux-wireless mailinglist.
>
> If you are not willing to stand behind your own patches, how do you expect
> others to trust your judgment?
Ehm, please explain? I am sending patches upstream, but apparently I don't stand behind them?
Then why the f*** am I sending them?
> > As for my behavior in discussions:
> >
> > I am doing my best to listen to all complains regarding the rt2x00 code and design and
> > improve it if the complainer has a valid point. However, obviously I can disagree with
> > the complainer and in that case I will explain to that person _why_ I disagree. It is up
> > to the complainer to convince me that he is right, agree with my response, or whine.
> >
> > Now as for more specific responses:
> >
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > rt2800 drivers have their maintainers and I would like to know what they
> > > are doing besides complaining about users and staging tree..
> >
> > Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> > But I guess you mean rt2x00 specific work?
> > Well that list consists of:
> > - Listening to people complain
> > - Responding to those people, because otherwise they complain that they are being ignored.
> > - Following bug reports, and request testing or additional information if required
> > - Bugfixing
> > - Reviewing patches from contributors
> > - Applying patches from contributors
> > - Discussing improvements over patches from contributors
> >
> > Well nothing of this list should be new to you, but apparently you needed some confirmation.
>
> I meant rt2800 support specifically, sorry if this was not clear.
>
> The work on rt2800 drivers was started in the beginning of 2008 and after
> few months you were already behind deadlines that you had set yourself:
>
> http://markmail.org/message/a753dws6tqytb3a4
>
> During almost two years rt2x00 project didn't manage to produce working
> support for rt2800.. in the meantime the world has moved on and we have
> another chipset generation (rt30x0) to worry about, and also rt33xx one
> on the horizon..
And thank you for your valuable effort in assisting in the driver development
during those 2 years. I am really happy about people looking from the sideline
and complaining things are not moving as fast as they would like it.
If you cared about the slow progress, then you had the past 2 years to help out,
but apparently that is too much to ask. Unfortunately a lot of people think like
you, which means that during those 2 years dozens of people have complained
about the lack of progress without any of them helping out (and I am not talking
about users only, I am also talking about people who have programming skills).
If you look at the Signed-off list of the rt2800pci/usb patches you will see that
only a handfull of people actually helped.
> > On Thursday 29 October 2009, Johannes Berg wrote:
> > > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> > >
> > > > In case you're concerned, I actually agree with John and others
> > > > on this issue, and disagree with your position.
> > >
> > > In this particular case, I think it makes more sense to duplicate the
> > > code _especially_ because it's not working yet. That frees people
> > > hacking on it of having to worry about breaking other devices.t initialization sequences) and in the review
> >
> > Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> > in the previous discussion.
>
> Nope, it just adds needles development/maintenance burden since it will
> make people lose fixes already applied to the working code, please see my
> other mail.
As mentioned in my mail, there were differences in the drivers during development,
and I had a working rt2800usb driver as base. But with the same settings the rt2800pci
couldn't get to work.
With the merged drivers you would constantly need to check if it works for rt2800pci,
but also if you haven't broken rt2800usb in the meantime. This way rt2800usb was
able to be merged months before rt2800pci because there was no common code.
Once both drivers are solid working, then there are no problems with merging them,
I wonder how many times I have to repeat that...
> > On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > I find it rather disappointing that all my review comments regarding
> > > rt2800pci support were just completely ignored and then the initial
> > > patch was merged just as it was..
> >
> > Your code review comments were commented upon with my reasons
> > why this code duplication exists. I even admitted that when the time is
> > ready I will remove the code duplication.
>
> The right time was two years ago when you were starting working on those
> drivers. IOW It shouldn't have happened in the first place.
Please see my other mail, please read my above comment, and thank you again
for participating in the rt2800 development of those 2 years.
> I also have serious questions about transparency of the process and cannot
> understand why it takes so long for the code to be pushed upstream.
So you start looking now, and complain you can't see the process of the last 2 years?
There have been dozens of status reports regarding rt2800, and the number of responses
in general have always been limited.
But now I reread that last sentence, you are complaining that rt2800pci wasn't pushed
upstream earlier? While this whole discussion is about that merging rt2800pci was a bad
idea?
> commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
> tree back in September (you're re-basing rt2x00 tree at random moments so it
> is impossible to track the status of patches that you are handling).
I'm missing the point here.
> rt2800pci patch itself has been getting dust in your tree since at least
> April (it hasn't received any bigger updates since then)..
And how many times do I have to repeat the reason?
I think that after dozens of mails, the message should have been clear, especially
to somebody who apparently has been monitoring and worrying about the development
process for the last 2 years....
> > On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > > Quite the contrary, I'm pretty confident that addressing my review concerns
> > > would result in better RT28x00 / RT30x0 support in the very near future.
> >
> > The review concerns regarding the duplicate code would only reduce the
> > amount of code. It would not magically fix bugs (at least the chance of that
> > would be quite small).
>
> Please see my other mail.
And did your patches make rt2800pci work better?
Does rt2800usb suddenly work for 11n networks?
> > So far rt2800usb performs better then rt2800pci, and the difference gets
> > only bigger when I use the exact same register initialization from rt2800usb
> > in rt2800pci.
> >
> > But Bartjmoiej knows that the register initialization can be exactly the same,
> > from his experience with the staging drivers.
> > So far hasn't been interested in sharing the knowledge in what must be
> > changed in rt2800pci/usb to make them both work with the same register
> > initialization.
>
> The knowledge is all in your local copy of linux-next (I don't memorize
> things like chipset initialization sequences) and in the review comments
> that you have happily dismissed.
Your review comments were regarding _moving_ code to a generic stack
for rt2800pci and rt2800usb while I already indicated that would not improve
the status of rt2800pci (instead it would make it worse, since I already tested
if those settings would work). But apparently merging the code is better then
fixing the code.
Ivo
^ permalink raw reply
* CLONE_NEWNET requires CAP_NET_RAW (and the intended CAP_SYS_ADMIN)
From: Eric Paris @ 2009-11-03 20:15 UTC (permalink / raw)
To: netdev; +Cc: nhorman, acme, dwalsh
We just saw today, because vsftpd just started using by default, that
CLONE_NEWNET requires both the intended CAP_SYS_ADMIN (see
kernel/nsproxy.c::copy_namespace()) and the unintended CAP_NET_RAW.
This is because tcp_sk_init() calls inet_ctl_sock_create() with
SOCK_RAW. Ultimately we end up in inet_create() which see that
answer->capability is equal to CAP_NET_RAW. So now it checks
capable(CAP_NET_RAW).
What you will find is that the generic __sock_create() has an argument
"int kern" which is passed to the security server to bypass checks which
were caused by the kernel, not because of userspace. That flag is not
passed down to the create() function in struct net_proto_family. I
think the easiest solution is to add the kern argument to the
net_proto_family create function and pass it along to the security
system so it can make the right decision.
I also see that the whole capability checking in struct inet_protosw
(and can, dccp, and sctp) seem overly complicated. Most of it (all but
inet) could just be deleted since they aren't doing anything. Inet
could replace it with just a single if (SOCK_RAW) which make the
security server changes very simple....
Did I explain my problem (I don't want to check CAP_NET_RAW)? Do people
see an issue with me passing kern down to create? Anyone have problems
with me ripping out the half ass unused security infrastructure?
-Eric
^ permalink raw reply
* Re: [PATCH 1/3] sysfs directory scaling: rbtree for dirent name lookups
From: Benjamin LaHaise @ 2009-11-03 20:01 UTC (permalink / raw)
To: Greg KH
Cc: Eric Dumazet, Eric W. Biederman, Octavian Purdila, netdev,
Cosmin Ratiu, linux-kernel
In-Reply-To: <20091103035058.GA19515@kroah.com>
On Mon, Nov 02, 2009 at 07:50:58PM -0800, Greg KH wrote:
> On Sun, Nov 01, 2009 at 11:31:30AM -0500, Benjamin LaHaise wrote:
> > Use an rbtree in sysfs_dirent to speed up file lookup times
> >
> > Systems with large numbers (tens of thousands and more) of network
> > interfaces stress the sysfs code in ways that make the linear search for
> > a name match take far too long. Avoid this by using an rbtree.
>
> What kind of speedups are you seeing here? And do these changes cause a
> memory increase due to the structure changes which outweigh the
> speedups?
Depends on the number of interfaces being created. Without the patch,
interface creation time tends to double or worse for every 5,000-10,000
additional network interfaces.
> What kind of test are you doing to reproduce this?
I'm creating 30,000+ network interfaces, with the goal being 100,000.
With other hacks in the tree to get around the sysctl and procfs scaling
issues, as well as disabling things like NetworkManager, the results look
as follows:
Interfaces no-rb rbtree rbtree+list
0-5,000 13.8s 14.0s 13.0s
5,000-10,000 20.0s 17.4s 14.4s
10,000-15,000 27.3s 24.1s 16.9s
15,000-20,000 36.3s 32.2s 19.7s
20,000-25,000 45.2s 40.0s 22.9s
25,000-30,000 54.2s 48.2s 26.6s
30,000-35,000 63.9s 54.9s 30.7s
Thoughts?
-ben
^ permalink raw reply
* Re: pull request: wireless-next-2.6 2009-10-28
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 19:59 UTC (permalink / raw)
To: Ivo van Doorn
Cc: netdev, Randy Dunlap, Luis Correia, John W. Linville, Ingo Molnar,
Johannes Berg, Jarek Poplawski, Pekka Enberg, David Miller,
linux-wireless, linux-kernel
In-Reply-To: <200911021943.12069.IvDoorn@gmail.com>
On Monday 02 November 2009 19:43:10 Ivo van Doorn wrote:
> Well and then another rt2x00 developer discovered this nice little
> fight about rt2x00 on the mailinglists...
>
> First for the record, because at the start people where talking about the
> maintainership of rt2x00, one thing needs to be straight:
>
> As mentioned in the MAINTAINERS file, the rt2x00 project is listed as maintainer
> for the rt2x00 drivers. The rt2x00 drivers include _all_ drivers in the
> drivers/net/wireless/rt2x00 folder.
>
> At this time I am hold the position within the rt2x00 team which is making the
> decisions about the rt2x00 code and design.
rt2x00 doesn't "own" Linux Ralink support, ditto for rt2800 drivers.
This is not how things work here, sorry.
> I am also the one that is (N)Acks the patches from others when they are send
> to the rt2x00-users or linux-wireless mailinglist.
If you are not willing to stand behind your own patches, how do you expect
others to trust your judgment?
> As for my behavior in discussions:
>
> I am doing my best to listen to all complains regarding the rt2x00 code and design and
> improve it if the complainer has a valid point. However, obviously I can disagree with
> the complainer and in that case I will explain to that person _why_ I disagree. It is up
> to the complainer to convince me that he is right, agree with my response, or whine.
>
> Now as for more specific responses:
>
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > rt2800 drivers have their maintainers and I would like to know what they
> > are doing besides complaining about users and staging tree..
>
> Working for Avanade, Zarafa and as freelancer for Linux Magazine.
> But I guess you mean rt2x00 specific work?
> Well that list consists of:
> - Listening to people complain
> - Responding to those people, because otherwise they complain that they are being ignored.
> - Following bug reports, and request testing or additional information if required
> - Bugfixing
> - Reviewing patches from contributors
> - Applying patches from contributors
> - Discussing improvements over patches from contributors
>
> Well nothing of this list should be new to you, but apparently you needed some confirmation.
I meant rt2800 support specifically, sorry if this was not clear.
The work on rt2800 drivers was started in the beginning of 2008 and after
few months you were already behind deadlines that you had set yourself:
http://markmail.org/message/a753dws6tqytb3a4
During almost two years rt2x00 project didn't manage to produce working
support for rt2800.. in the meantime the world has moved on and we have
another chipset generation (rt30x0) to worry about, and also rt33xx one
on the horizon..
> On Thursday 29 October 2009, Johannes Berg wrote:
> > On Thu, 2009-10-29 at 07:20 -0700, David Miller wrote:
> >
> > > In case you're concerned, I actually agree with John and others
> > > on this issue, and disagree with your position.
> >
> > In this particular case, I think it makes more sense to duplicate the
> > code _especially_ because it's not working yet. That frees people
> > hacking on it of having to worry about breaking other devices.
>
> Thank you Johannes, that is exactly what I was trying to tell Bartlomiej
> in the previous discussion.
Nope, it just adds needles development/maintenance burden since it will
make people lose fixes already applied to the working code, please see my
other mail.
> On Wednesday 28 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > I find it rather disappointing that all my review comments regarding
> > rt2800pci support were just completely ignored and then the initial
> > patch was merged just as it was..
>
> Your code review comments were commented upon with my reasons
> why this code duplication exists. I even admitted that when the time is
> ready I will remove the code duplication.
The right time was two years ago when you were starting working on those
drivers. IOW It shouldn't have happened in the first place.
I also have serious questions about transparency of the process and cannot
understand why it takes so long for the code to be pushed upstream.
commit 1761631 -- obvious bugfix and I'm pretty sure I've seen it in rt2x00
tree back in September (you're re-basing rt2x00 tree at random moments so it
is impossible to track the status of patches that you are handling).
rt2800pci patch itself has been getting dust in your tree since at least
April (it hasn't received any bigger updates since then)..
> On Thursday 29 October 2009, Bartlomiej Zolnierkiewicz wrote:
> > Quite the contrary, I'm pretty confident that addressing my review concerns
> > would result in better RT28x00 / RT30x0 support in the very near future.
>
> The review concerns regarding the duplicate code would only reduce the
> amount of code. It would not magically fix bugs (at least the chance of that
> would be quite small).
Please see my other mail.
> So far rt2800usb performs better then rt2800pci, and the difference gets
> only bigger when I use the exact same register initialization from rt2800usb
> in rt2800pci.
>
> But Bartjmoiej knows that the register initialization can be exactly the same,
> from his experience with the staging drivers.
> So far hasn't been interested in sharing the knowledge in what must be
> changed in rt2800pci/usb to make them both work with the same register
> initialization.
The knowledge is all in your local copy of linux-next (I don't memorize
things like chipset initialization sequences) and in the review comments
that you have happily dismissed.
--
Bartlomiej Zolnierkiewicz
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-11-03 19:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Gregory Haskins, netdev, virtualization, kvm, linux-kernel, mingo,
linux-mm, akpm, hpa, Rusty Russell, s.hetze, Paul E. McKenney
In-Reply-To: <4AF07BB7.1020802@gmail.com>
On Tue, Nov 03, 2009 at 07:51:35PM +0100, Eric Dumazet wrote:
> Gregory Haskins a écrit :
> > Gregory Haskins wrote:
> >> Eric Dumazet wrote:
> >>> Michael S. Tsirkin a écrit :
> >>>> +static void handle_tx(struct vhost_net *net)
> >>>> +{
> >>>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> >>>> + unsigned head, out, in, s;
> >>>> + struct msghdr msg = {
> >>>> + .msg_name = NULL,
> >>>> + .msg_namelen = 0,
> >>>> + .msg_control = NULL,
> >>>> + .msg_controllen = 0,
> >>>> + .msg_iov = vq->iov,
> >>>> + .msg_flags = MSG_DONTWAIT,
> >>>> + };
> >>>> + size_t len, total_len = 0;
> >>>> + int err, wmem;
> >>>> + size_t hdr_size;
> >>>> + struct socket *sock = rcu_dereference(vq->private_data);
> >>>> + if (!sock)
> >>>> + return;
> >>>> +
> >>>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> >>>> + if (wmem >= sock->sk->sk_sndbuf)
> >>>> + return;
> >>>> +
> >>>> + use_mm(net->dev.mm);
> >>>> + mutex_lock(&vq->mutex);
> >>>> + vhost_no_notify(vq);
> >>>> +
> >>> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
> >>> that your use of RCU is not correct.
> >>>
> >>> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
> >>> we are not allowed to sleep in such a section.
> >>> (Quoting Documentation/RCU/whatisRCU.txt :
> >>> It is illegal to block while in an RCU read-side critical section, )
> >>>
> >>> 2) mutex_lock() can sleep (ie block)
> >>>
> >>
> >> Michael,
> >> I warned you that this needed better documentation ;)
> >>
> >> Eric,
> >> I think I flagged this once before, but Michael convinced me that it
> >> was indeed "ok", if but perhaps a bit unconventional. I will try to
> >> find the thread.
> >>
> >> Kind Regards,
> >> -Greg
> >>
> >
> > Here it is:
> >
> > http://lkml.org/lkml/2009/8/12/173
> >
>
> Yes, this doesnt convince me at all, and could be a precedent for a wrong RCU use.
> People wanting to use RCU do a grep on kernel sources to find how to correctly
> use RCU.
>
> Michael, please use existing locking/barrier mechanisms, and not pretend to use RCU.
>
> Some automatic tools might barf later.
>
> For example, we could add a debugging facility to check that rcu_dereference() is used
> in an appropriate context, ie conflict with existing mutex_lock() debugging facility.
Paul, you acked this previously. Should I add you acked-by line so
people calm down? If you would rather I replace
rcu_dereference/rcu_assign_pointer with rmb/wmb, I can do this.
Or maybe patch Documentation to explain this RCU usage?
--
MST
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Michael S. Tsirkin @ 2009-11-03 19:55 UTC (permalink / raw)
To: Eric Dumazet
Cc: netdev, virtualization, kvm, linux-kernel, mingo, linux-mm, akpm,
hpa, gregory.haskins, Rusty Russell, s.hetze, Paul E. McKenney
In-Reply-To: <4AF0708B.4020406@gmail.com>
On Tue, Nov 03, 2009 at 07:03:55PM +0100, Eric Dumazet wrote:
> Michael S. Tsirkin a écrit :
> > +static void handle_tx(struct vhost_net *net)
> > +{
> > + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
> > + unsigned head, out, in, s;
> > + struct msghdr msg = {
> > + .msg_name = NULL,
> > + .msg_namelen = 0,
> > + .msg_control = NULL,
> > + .msg_controllen = 0,
> > + .msg_iov = vq->iov,
> > + .msg_flags = MSG_DONTWAIT,
> > + };
> > + size_t len, total_len = 0;
> > + int err, wmem;
> > + size_t hdr_size;
> > + struct socket *sock = rcu_dereference(vq->private_data);
> > + if (!sock)
> > + return;
> > +
> > + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
> > + if (wmem >= sock->sk->sk_sndbuf)
> > + return;
> > +
> > + use_mm(net->dev.mm);
> > + mutex_lock(&vq->mutex);
> > + vhost_no_notify(vq);
> > +
>
> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
> that your use of RCU is not correct.
>
> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
> we are not allowed to sleep in such a section.
> (Quoting Documentation/RCU/whatisRCU.txt :
> It is illegal to block while in an RCU read-side critical section, )
>
> 2) mutex_lock() can sleep (ie block)
This use is correct. See comment in vhost.h This use of RCU has been
acked by Paul E. McKenney (paulmck@linux.vnet.ibm.com) as well.
There are many ways to use RCU not all of which involve read_rcu_lock.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-11-03 19:50 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael S. Tsirkin, netdev, virtualization, kvm, linux-kernel,
mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
Paul E. McKenney
In-Reply-To: <4AF07BB7.1020802@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1995 bytes --]
Eric Dumazet wrote:
> Gregory Haskins a écrit :
>> Gregory Haskins wrote:
>>> Eric Dumazet wrote:
>>>> Michael S. Tsirkin a écrit :
>>>> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
>>>> that your use of RCU is not correct.
>>>>
>>>> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
>>>> we are not allowed to sleep in such a section.
>>>> (Quoting Documentation/RCU/whatisRCU.txt :
>>>> It is illegal to block while in an RCU read-side critical section, )
>>>>
>>>> 2) mutex_lock() can sleep (ie block)
>>>>
>>> Michael,
>>> I warned you that this needed better documentation ;)
>>>
>>> Eric,
>>> I think I flagged this once before, but Michael convinced me that it
>>> was indeed "ok", if but perhaps a bit unconventional. I will try to
>>> find the thread.
>>>
>>> Kind Regards,
>>> -Greg
>>>
>> Here it is:
>>
>> http://lkml.org/lkml/2009/8/12/173
>>
>
> Yes, this doesnt convince me at all, and could be a precedent for a wrong RCU use.
> People wanting to use RCU do a grep on kernel sources to find how to correctly
> use RCU.
>
> Michael, please use existing locking/barrier mechanisms, and not pretend to use RCU.
Yes, I would tend to agree with you. In fact, I think I suggested that
a normal barrier should be used instead of abusing rcu_dereference().
But as far as his code is concerned, I think it technically works
properly, and that was my main point. Also note that the usage
rcu_dereference+mutex_lock() are not necessarily broken, per se: it
could be an srcu-based critical section created by the caller, for
instance. It would be perfectly legal to sleep on the mutex if that
were the case.
To me, the bigger issue is that the rcu_dereference() without any
apparent hint of a corresponding RSCS is simply confusing as a reviewer.
smp_rmb() (or whatever is proper in this case) is probably more
appropriate.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* [PATCH 1/1] Use defaults when no route options are available
From: Gilad Ben-Yossef @ 2009-11-03 19:21 UTC (permalink / raw)
To: Valdis.Kletnieks; +Cc: netdev, ori, linux-kernel, Andrew Morton
In-Reply-To: <4AF07024.80103@gmail.com>
Trying to parse the option of a SYN packet that we have
no route entry for should just use global wide defaults
for route entry options.
Signed-off-by: Gilad Ben-Yossef <gilad@codefidence.com>
---
include/net/dst.h | 2 +-
net/ipv4/tcp_input.c | 2 --
2 files changed, 1 insertions(+), 3 deletions(-)
diff --git a/include/net/dst.h b/include/net/dst.h
index b562be3..0654c27 100644
--- a/include/net/dst.h
+++ b/include/net/dst.h
@@ -114,7 +114,7 @@ dst_metric(const struct dst_entry *dst, int metric)
static inline u32
dst_feature(const struct dst_entry *dst, u32 feature)
{
- return dst_metric(dst, RTAX_FEATURES) & feature;
+ return (dst ? dst_metric(dst, RTAX_FEATURES) & feature : 0);
}
static inline u32 dst_mtu(const struct dst_entry *dst)
diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c
index 4262da5..57e99e1 100644
--- a/net/ipv4/tcp_input.c
+++ b/net/ipv4/tcp_input.c
@@ -3704,8 +3704,6 @@ void tcp_parse_options(struct sk_buff *skb, struct tcp_options_received *opt_rx,
struct tcphdr *th = tcp_hdr(skb);
int length = (th->doff * 4) - sizeof(struct tcphdr);
- BUG_ON(!estab && !dst);
-
ptr = (unsigned char *)(th + 1);
opt_rx->saw_tstamp = 0;
--
1.5.6.3
^ permalink raw reply related
* Re: 2.6.32-rc5-mmotm1101 - kernel BUG at net/ipv4/tcp_input.c:3707!
From: Gilad Ben-Yossef @ 2009-11-03 19:20 UTC (permalink / raw)
To: Valdis.Kletnieks
Cc: Eric Dumazet, Andrew Morton, linux-kernel, netdev, Ori Finkelman
In-Reply-To: <4AF07024.80103@gmail.com>
Eric Dumazet wrote:
> Valdis.Kletnieks@vt.edu a écrit :
>
>> Seen right after I started 'fetchmail'. Reproducible - 3 out of 3.
>> I'll bisect this tonight if nobody jumps up and yells they know what it is...
>>
Bah... this is most probably my fault. Sorry about that.
Can you please try the patch in the next email?
But also, can you please send me the route table in effect when this
happened and the fetchmail command line/config (removing any passwords
or account details of course)? I want to understand better when this
happens.
Thanks!
Gilad
--
Gilad Ben-Yossef
Chief Coffee Drinker & CTO
Codefidence Ltd.
Web: http://codefidence.com
Cell: +972-52-8260388
Skype: gilad_codefidence
Tel: +972-8-9316883 ext. 201
Fax: +972-8-9316884
Email: gilad@codefidence.com
Check out our Open Source technology and training blog - http://tuxology.net
"The biggest risk you can take it is to take no risk."
-- Mark Zuckerberg and probably others
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Eric Dumazet @ 2009-11-03 18:51 UTC (permalink / raw)
To: Gregory Haskins
Cc: Michael S. Tsirkin, netdev, virtualization, kvm, linux-kernel,
mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
Paul E. McKenney
In-Reply-To: <4AF072EE.9020202@gmail.com>
Gregory Haskins a écrit :
> Gregory Haskins wrote:
>> Eric Dumazet wrote:
>>> Michael S. Tsirkin a écrit :
>>>> +static void handle_tx(struct vhost_net *net)
>>>> +{
>>>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
>>>> + unsigned head, out, in, s;
>>>> + struct msghdr msg = {
>>>> + .msg_name = NULL,
>>>> + .msg_namelen = 0,
>>>> + .msg_control = NULL,
>>>> + .msg_controllen = 0,
>>>> + .msg_iov = vq->iov,
>>>> + .msg_flags = MSG_DONTWAIT,
>>>> + };
>>>> + size_t len, total_len = 0;
>>>> + int err, wmem;
>>>> + size_t hdr_size;
>>>> + struct socket *sock = rcu_dereference(vq->private_data);
>>>> + if (!sock)
>>>> + return;
>>>> +
>>>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
>>>> + if (wmem >= sock->sk->sk_sndbuf)
>>>> + return;
>>>> +
>>>> + use_mm(net->dev.mm);
>>>> + mutex_lock(&vq->mutex);
>>>> + vhost_no_notify(vq);
>>>> +
>>> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
>>> that your use of RCU is not correct.
>>>
>>> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
>>> we are not allowed to sleep in such a section.
>>> (Quoting Documentation/RCU/whatisRCU.txt :
>>> It is illegal to block while in an RCU read-side critical section, )
>>>
>>> 2) mutex_lock() can sleep (ie block)
>>>
>>
>> Michael,
>> I warned you that this needed better documentation ;)
>>
>> Eric,
>> I think I flagged this once before, but Michael convinced me that it
>> was indeed "ok", if but perhaps a bit unconventional. I will try to
>> find the thread.
>>
>> Kind Regards,
>> -Greg
>>
>
> Here it is:
>
> http://lkml.org/lkml/2009/8/12/173
>
Yes, this doesnt convince me at all, and could be a precedent for a wrong RCU use.
People wanting to use RCU do a grep on kernel sources to find how to correctly
use RCU.
Michael, please use existing locking/barrier mechanisms, and not pretend to use RCU.
Some automatic tools might barf later.
For example, we could add a debugging facility to check that rcu_dereference() is used
in an appropriate context, ie conflict with existing mutex_lock() debugging facility.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* [announce] new rt2800 drivers for Ralink wireless & project tree
From: Bartlomiej Zolnierkiewicz @ 2009-11-03 18:51 UTC (permalink / raw)
To: linux-wireless
Cc: linux-kernel, netdev, Ivo van Doorn, Randy Dunlap, Luis Correia,
John W. Linville, Ingo Molnar, Johannes Berg, Jarek Poplawski,
Pekka Enberg, David Miller
Hi,
The following patch series (against wireless-next) addresses issues raised
during code review and subsequently rejected by rt2x00/wireless/networking
maintainers.
Namely, it:
- Adds abstraction of chipset register access for chipsets connected to
different buses by using new structure (struct rt2800_ops) which contains
all needed register access methods.
[ It is a prerequisite for fixing code duplication between rt2800usb.c
and rt2800pci.c drivers. ]
- Fixes code duplication in rt2800usb.h and rt2800pci.h header files by
using new shared rt2800.h header (almost 1800 LOC gone).
Updated debugging scripts are located here:
http://www.kernel.org/pub/linux/kernel/people/bart/rt2800/scripts/
(they also work fine with older drivers)
- Adds rt2800 library containing common code for PCI and USB versions
of rt2800 chipsets. This removes over 1300 LOC and allows us to save
a lot of maintenance burden in the future.
It also fixes two real bugs (one in rt2800pci and one in rt2800usb) found
as a direct result of the code de-duplication:
- Fix rt2800usb driver to write the rfcsr read request into RF_CSR_CFG
register and not BBP_CSR_CFG one in rt2800usb_rfcsr_read().
- Use the correct encryption key index for TX frames in rt2800pci (this is
based on rt2800usb patch from Benoit PAPILLAULT already in Linus' tree,
unfortunately the fix was not ported over to rt2800pci).
[ There are also some minor code rt2x00 infrastructure fixes and improvements
here and there... ]
All in all over 3100 LOC are gone and rt2800pci specific code is:
1685 drivers/net/wireless/rt2x00/rt2800pci.c
180 drivers/net/wireless/rt2x00/rt2800pci.h
1865 total
instead of:
3323 drivers/net/wireless/rt2x00/rt2800pci.c
1960 drivers/net/wireless/rt2x00/rt2800pci.h
5283 total
(wireless-next and net-next trees)
which means decrease of the code needed for rt2800pci by 65% (this in turn
translates to 31% decrease for rt2800 specific code and 9% for whole rt2x00
infrastructure).
The rewrite was quite conservative and there is still a room for improvement
but it should serve as a good starting base for all future work on rt2800
drivers, and there is a lot to do there (both drivers are still practically
non-functional).
Comments and patches are welcomed.
The following changes since commit fa867e7355a1bdcd9bf7d55ebe9296f5b9c4028a:
Juuso Oikarinen (1):
wl1271: Generalize command response reading
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/bart/misc.git rt2800
Bartlomiej Zolnierkiewicz (40):
rt2800usb: fix rt2800usb_rfcsr_read()
rt2800pci: fix crypto in TX frame
rt2800pci: fix comment about register access
rt2800pci: fix comment about IV/EIV fields
rt2x00: fix rt2x00usb_register_read() comment
rt2800usb: use rt2x00usb_register_multiwrite() to set key entries
rt2800usb: add rt2800_register_[read,write]() wrappers
rt2800pci: add rt2800_register_[read,write]() wrappers
rt2800usb: add rt2800_register_multi[read,write]() wrappers
rt2800pci: add rt2800_register_multi[read,write]() wrappers
rt2800usb: add rt2800_regbusy_read() wrapper
rt2800pci: add rt2800_regbusy_read() wrapper
rt2800usb: add rt2800_bbp_[read,write]() wrappers
rt2800pci: add rt2800_bbp_[read,write]() wrappers
rt2800usb: add rt2800_rfcsr_[read,write]() wrappers
rt2800pci: add rt2800_rfcsr_[read,write]() wrappers
rt2800usb: add rt2800_rf_[read,write]() wrappers
rt2800pci: add rt2800_rf_[read,write]() wrappers
rt2800usb: add rt2800_mcu_request() wrapper
rt2800pci: add rt2800_mcu_request() wrapper
rt2x00: add driver private field to struct rt2x00_dev
rt2800usb: convert to use struct rt2800_ops methods
rt2800pci: convert to use struct rt2800_ops methods
rt2x00: fix rt2x00usb_register_multiwrite() arguments
rt2x00: fix rt2x00usb_regbusy_read() arguments
rt2x00: fix rt2x00pci_register_multi[read,write]() arguments
rt2800: add rt2800lib.h
rt2800usb: fix comments in rt2800usb.h
rt2800usb: add RXINFO_DESC_SIZE definition
rt2800: fix duplication in header files
rt2800: fix comments in rt2800.h
rt2x00: add support for different chipset interfaces
rt2800: prepare for rt2800lib addition
rt2800: add rt2800lib (part one)
rt2x00: remove needless ifdefs from rt2x00leds.h
rt2800: add rt2800lib (part two)
rt2x00: move REGISTER_BUSY_* definitions to rt2x00.h
rt2800: add rt2800lib (part three)
rt2800: add rt2800lib (part four)
MAINTAINERS: add rt2800 entry
MAINTAINERS | 7 +
drivers/net/wireless/rt2x00/Kconfig | 5 +
drivers/net/wireless/rt2x00/Makefile | 1 +
drivers/net/wireless/rt2x00/rt2800.h | 1816 ++++++++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt2800lib.c | 1817 ++++++++++++++++++++++++++++
drivers/net/wireless/rt2x00/rt2800lib.h | 134 +++
drivers/net/wireless/rt2x00/rt2800pci.c | 1908 +++---------------------------
drivers/net/wireless/rt2x00/rt2800pci.h | 1780 ----------------------------
drivers/net/wireless/rt2x00/rt2800usb.c | 1828 ++---------------------------
drivers/net/wireless/rt2x00/rt2800usb.h | 1818 +----------------------------
drivers/net/wireless/rt2x00/rt2x00.h | 33 +
drivers/net/wireless/rt2x00/rt2x00leds.h | 4 -
drivers/net/wireless/rt2x00/rt2x00pci.h | 24 +-
drivers/net/wireless/rt2x00/rt2x00usb.c | 2 +-
drivers/net/wireless/rt2x00/rt2x00usb.h | 17 +-
15 files changed, 4036 insertions(+), 7158 deletions(-)
create mode 100644 drivers/net/wireless/rt2x00/rt2800.h
create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.c
create mode 100644 drivers/net/wireless/rt2x00/rt2800lib.h
^ permalink raw reply
* RE: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
From: Rasesh Mody @ 2009-11-03 18:24 UTC (permalink / raw)
To: Joe Perches
Cc: netdev@vger.kernel.org, Adapter Linux Open SRC Team,
Greg Kroah-Hartman
In-Reply-To: <1257053039.1917.147.camel@Joe-Laptop.home>
Joe,
Thanks for your input. We are in the process addressing the comments that we are getting.
Can you please give examples or elaborate your comment? It would be really helpful.
Thanks,
-- Rasesh
-----Original Message-----
From: Joe Perches [mailto:joe@perches.com]
Sent: Saturday, October 31, 2009 10:24 PM
To: Rasesh Mody
Cc: netdev@vger.kernel.org; Adapter Linux Open SRC Team; Greg Kroah-Hartman
Subject: Re: Subject: [PATCH 1/6] bna: Brocade 10Gb Ethernet device driver
There are an awful lot of non linux standard
uses in this code set.
Perhaps staging would be a good place to start?
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-11-03 18:14 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael S. Tsirkin, netdev, virtualization, kvm, linux-kernel,
mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
Paul E. McKenney
In-Reply-To: <4AF07199.2020601@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1658 bytes --]
Gregory Haskins wrote:
> Eric Dumazet wrote:
>> Michael S. Tsirkin a écrit :
>>> +static void handle_tx(struct vhost_net *net)
>>> +{
>>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
>>> + unsigned head, out, in, s;
>>> + struct msghdr msg = {
>>> + .msg_name = NULL,
>>> + .msg_namelen = 0,
>>> + .msg_control = NULL,
>>> + .msg_controllen = 0,
>>> + .msg_iov = vq->iov,
>>> + .msg_flags = MSG_DONTWAIT,
>>> + };
>>> + size_t len, total_len = 0;
>>> + int err, wmem;
>>> + size_t hdr_size;
>>> + struct socket *sock = rcu_dereference(vq->private_data);
>>> + if (!sock)
>>> + return;
>>> +
>>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
>>> + if (wmem >= sock->sk->sk_sndbuf)
>>> + return;
>>> +
>>> + use_mm(net->dev.mm);
>>> + mutex_lock(&vq->mutex);
>>> + vhost_no_notify(vq);
>>> +
>> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
>> that your use of RCU is not correct.
>>
>> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
>> we are not allowed to sleep in such a section.
>> (Quoting Documentation/RCU/whatisRCU.txt :
>> It is illegal to block while in an RCU read-side critical section, )
>>
>> 2) mutex_lock() can sleep (ie block)
>>
>
>
> Michael,
> I warned you that this needed better documentation ;)
>
> Eric,
> I think I flagged this once before, but Michael convinced me that it
> was indeed "ok", if but perhaps a bit unconventional. I will try to
> find the thread.
>
> Kind Regards,
> -Greg
>
Here it is:
http://lkml.org/lkml/2009/8/12/173
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH net-next-2.6] bnx2: avoid compiler warnings
From: Michael Chan @ 2009-11-03 18:01 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, Linux Netdev List
In-Reply-To: <4AEFF536.1020402@gmail.com>
On Tue, 2009-11-03 at 01:17 -0800, Eric Dumazet wrote:
> drivers/net/bnx2.c: In function ‘bnx2_enable_forced_2g5’:
> drivers/net/bnx2.c:1447: warning: ‘bmcr’ may be used uninitialized in this function
> drivers/net/bnx2.c: In function ‘bnx2_disable_forced_2g5’:
> drivers/net/bnx2.c:1482: warning: ‘bmcr’ may be used uninitialized in this function
>
> One fix would be to have an initial value, but a plain return might be better.
I agree that plain return is better. Thanks.
Acked-by: Michael Chan <mchan@broadcom.com>
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> ---
>
> diff --git a/drivers/net/bnx2.c b/drivers/net/bnx2.c
> index 08cddb6..539d23b 100644
> --- a/drivers/net/bnx2.c
> +++ b/drivers/net/bnx2.c
> @@ -1466,6 +1466,8 @@ bnx2_enable_forced_2g5(struct bnx2 *bp)
> } else if (CHIP_NUM(bp) == CHIP_NUM_5708) {
> bnx2_read_phy(bp, bp->mii_bmcr, &bmcr);
> bmcr |= BCM5708S_BMCR_FORCE_2500;
> + } else {
> + return;
> }
>
> if (bp->autoneg & AUTONEG_SPEED) {
> @@ -1500,6 +1502,8 @@ bnx2_disable_forced_2g5(struct bnx2 *bp)
> } else if (CHIP_NUM(bp) == CHIP_NUM_5708) {
> bnx2_read_phy(bp, bp->mii_bmcr, &bmcr);
> bmcr &= ~BCM5708S_BMCR_FORCE_2500;
> + } else {
> + return;
> }
>
> if (bp->autoneg & AUTONEG_SPEED)
>
^ permalink raw reply
* Re: [PATCHv7 3/3] vhost_net: a kernel-level virtio server
From: Gregory Haskins @ 2009-11-03 18:08 UTC (permalink / raw)
To: Eric Dumazet
Cc: Michael S. Tsirkin, netdev, virtualization, kvm, linux-kernel,
mingo, linux-mm, akpm, hpa, Rusty Russell, s.hetze,
Paul E. McKenney
In-Reply-To: <4AF0708B.4020406@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1496 bytes --]
Eric Dumazet wrote:
> Michael S. Tsirkin a écrit :
>> +static void handle_tx(struct vhost_net *net)
>> +{
>> + struct vhost_virtqueue *vq = &net->dev.vqs[VHOST_NET_VQ_TX];
>> + unsigned head, out, in, s;
>> + struct msghdr msg = {
>> + .msg_name = NULL,
>> + .msg_namelen = 0,
>> + .msg_control = NULL,
>> + .msg_controllen = 0,
>> + .msg_iov = vq->iov,
>> + .msg_flags = MSG_DONTWAIT,
>> + };
>> + size_t len, total_len = 0;
>> + int err, wmem;
>> + size_t hdr_size;
>> + struct socket *sock = rcu_dereference(vq->private_data);
>> + if (!sock)
>> + return;
>> +
>> + wmem = atomic_read(&sock->sk->sk_wmem_alloc);
>> + if (wmem >= sock->sk->sk_sndbuf)
>> + return;
>> +
>> + use_mm(net->dev.mm);
>> + mutex_lock(&vq->mutex);
>> + vhost_no_notify(vq);
>> +
>
> using rcu_dereference() and mutex_lock() at the same time seems wrong, I suspect
> that your use of RCU is not correct.
>
> 1) rcu_dereference() should be done inside a read_rcu_lock() section, and
> we are not allowed to sleep in such a section.
> (Quoting Documentation/RCU/whatisRCU.txt :
> It is illegal to block while in an RCU read-side critical section, )
>
> 2) mutex_lock() can sleep (ie block)
>
Michael,
I warned you that this needed better documentation ;)
Eric,
I think I flagged this once before, but Michael convinced me that it
was indeed "ok", if but perhaps a bit unconventional. I will try to
find the thread.
Kind Regards,
-Greg
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 267 bytes --]
^ permalink raw reply
* Re: [PATCH] iproute2: Avoid rounding errors for 100%.
From: Stephen Hemminger @ 2009-11-03 18:05 UTC (permalink / raw)
To: Arnd Hannemann; +Cc: netdev@vger.kernel.org
In-Reply-To: <4AF06617.6030804@nets.rwth-aachen.de>
On Tue, 03 Nov 2009 18:19:19 +0100
Arnd Hannemann <hannemann@nets.rwth-aachen.de> wrote:
> Stephen Hemminger wrote:
> > On Tue, 03 Nov 2009 17:19:45 +0100
> > Arnd Hannemann <hannemann@nets.rwth-aachen.de> wrote:
> >
> >> Although the patch makes sense,
> >> it does not fix the bug/effect we were seeing.
> >> A netem reorder percentage of 100% will still get packets reordered.
> >> (if the netem queue is not empty)
> >>
> >>
> >> hannemann@nets.rwth-aachen.de wrote:
> >>> From: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> >>>
> >>> We noticed that a netem reorder percentage of 100% will still get packets reordered.
> >>> This patch fixes that.
> >>>
> >>> Signed-off-by: Arnd Hannemann <hannemann@nets.rwth-aachen.de>
> >>> ---
> >>> tc/tc_util.c | 6 ++++--
> >>> 1 files changed, 4 insertions(+), 2 deletions(-)
> >>>
> >>> diff --git a/tc/tc_util.c b/tc/tc_util.c
> >>> index fe2c7eb..2641f2e 100644
> >>> --- a/tc/tc_util.c
> >>> +++ b/tc/tc_util.c
> >>> @@ -363,8 +363,10 @@ int get_percent(__u32 *percent, const char *str)
> >>> return -1;
> >>> if (*p && strcmp(p, "%"))
> >>> return -1;
> >>> -
> >>> - *percent = (unsigned) rint(per * max_percent_value);
> >>> + if (per == 1.)
> >>> + *percent = max_percent_value;
> >>> + else
> >>> + *percent = (unsigned) rint(per * max_percent_value);
> >>> return 0;
> >>> }
> >>>
> >>
> >
> > If you don't want reordering, don't specify reordering?
>
> Are you arguing against the correctness of my patch?
>
> Regarding, the reordering thingy/bug/effect whatever:
> We would like to specify reordering with something like this:
> Please delay 1% of the packets with 5ms.
>
> We thought that would be possible with
> tc qdisc add dev eth0 root netem delay 5m reorder 99%
>
> But unfortunately it is not. Any better idea?
>
I think the problem isn't in iproute utilities but in the code inside
netem kernel module.
--
^ 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