* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Arnd Bergmann @ 2010-10-19 7:26 UTC (permalink / raw)
To: Dave Airlie
Cc: Theodore Kilgore, Steven Rostedt, Greg KH, codalist, autofs,
Samuel Ortiz, Jan Kara, Mikulas Patocka, Jan Harkes, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, ksummit-2010-discuss, Petr Vandrovec,
Arnaldo Carvalho de Melo, linux-fsdevel, Evgeniy Dushistov,
Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <AANLkTi=oAeuz8ZxcOMpf=3MVY=WMt0BwHiGCUxO7OAEV@mail.gmail.com>
On Tuesday 19 October 2010 06:52:32 Dave Airlie wrote:
> > I might be able to find some hardware still lying around here that uses an
> > i810. Not sure unless I go hunting it. But I get the impression that if
> > the kernel is a single-CPU kernel there is not any problem anyway? Don't
> > distros offer a non-smp kernel as an installation option in case the user
> > needs it? So in reality how big a problem is this?
>
> Not anymore, which is my old point of making a fuss. Nowadays in the
> modern distro world, we supply a single kernel that can at runtime
> decide if its running on SMP or UP and rewrite the text section
> appropriately with locks etc. Its like magic, and something like
> marking drivers as BROKEN_ON_SMP at compile time is really wrong when
> what you want now is a runtime warning if someone tries to hotplug a
> CPU with a known iffy driver loaded or if someone tries to load the
> driver when we are already in SMP mode.
We could make the driver run-time non-SMP by adding
if (num_present_cpus() > 1) {
pr_err("i810 no longer supports SMP\n");
return -EINVAL;
}
to the init function. That would cover the vast majority of the
users of i810 hardware, I guess.
Arnd
^ permalink raw reply
* Re: [Bugme-new] [Bug 19692] New: linux-2.6.36-rc5 crash with gianfar ethernet at full line rate traffic
From: emin ak @ 2010-10-19 6:44 UTC (permalink / raw)
To: Jarek Poplawski
Cc: Andrew Morton, netdev, bugzilla-daemon, bugme-daemon,
Anton Vorontsov
In-Reply-To: <20101016194815.GA1894@del.dom.local>
Hi Jarek;
After 5 days and more then 20 billion packets passed without crash, it
seems that this patch is working for me, at least for crash type 2.
(For type 1, it only occured once and I can never reproduce this
again, but still trying. I think with this patch is also lowers the
risk for type 1.
For adding a new bug entry for skb_over_panic, before that I think I
must find a reliable way to make this type of crash reproducable,
otherwise I don't know how to test it if it solved or not.
Lastly, thanks a lot for your valuable help to overcome this problem
and also is there anything that I can do for testing / commiting this
patch to mainline?
Thanks
Emin
^ permalink raw reply
* RE: [PATCH net-next] netxen: make local function static.
From: Amit Salecha @ 2010-10-19 6:36 UTC (permalink / raw)
To: Stephen Hemminger, David S. Miller, Narender Kumar,
Rajesh Borundia
Cc: netdev@vger.kernel.org
In-Reply-To: <20101018204010.1dc01291@nehalam>
> -----Original Message-----
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Tuesday, October 19, 2010 9:10 AM
> To: Amit Salecha; David S. Miller; Narender Kumar; Rajesh Borundia
> Cc: netdev@vger.kernel.org
> Subject: [PATCH net-next] netxen: make local function static.
>
>
> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>
> ---
> drivers/net/netxen/netxen_nic.h | 18 +-----------------
> drivers/net/netxen/netxen_nic_hw.c | 29 +++++++++++---------------
> ---
> drivers/net/netxen/netxen_nic_main.c | 6 ++++--
> 3 files changed, 16 insertions(+), 37 deletions(-)
>
Thanks for this. I always run sparse tool before submitting patches, but I never got warning about this.
-Amit
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Changli Gao @ 2010-10-19 6:03 UTC (permalink / raw)
To: Eric Dumazet; +Cc: David S. Miller, netdev
In-Reply-To: <1287467263.2775.2.camel@edumazet-laptop>
On Tue, Oct 19, 2010 at 1:47 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> Le mardi 19 octobre 2010 à 13:24 +0800, Changli Gao a écrit :
>> And since ctl_table.data is initialized later, we don't need to initialize
>> the data member of the template variable unix_table.
>>
>
> The init cost is nothing, since its a data blob that must be there
> anyway.
Yes. I have tried to avoid global variable unix_table and unix_path,
then I got a bigger kernel image, so I gave it up.
>
> We could even avoid the kmemdup() if CONFIG_NET_NS is not set
>
>
It is a good idea. We can check if the NS is init_net before kmalloc and kfree.
I'll send a update patch later. Thanks.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Stephen Hemminger @ 2010-10-19 6:03 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1287465842-2958-1-git-send-email-xiaosuo@gmail.com>
On Tue, 19 Oct 2010 13:24:02 +0800
Changli Gao <xiaosuo@gmail.com> wrote:
> And since ctl_table.data is initialized later, we don't need to initialize
> the data member of the template variable unix_table.
>
> Signed-off-by: Changli Gao <xiaosuo@gmail.com>
> ---
> net/unix/sysctl_net_unix.c | 5 ++---
> 1 file changed, 2 insertions(+), 3 deletions(-)
> diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
> index 397cffe..1114ccc 100644
> --- a/net/unix/sysctl_net_unix.c
> +++ b/net/unix/sysctl_net_unix.c
> @@ -15,10 +15,9 @@
>
> #include <net/af_unix.h>
>
> -static ctl_table unix_table[] = {
> +const static ctl_table unix_table[] = {
Typical convention is "static const" rather than "const static"
git grep 'const static' | wc -l => 5
git grep 'static const' | wc -l => 18589
--
^ permalink raw reply
* Re: [PATCH] net: unix: make some variables constant
From: Eric Dumazet @ 2010-10-19 5:47 UTC (permalink / raw)
To: Changli Gao; +Cc: David S. Miller, netdev
In-Reply-To: <1287465842-2958-1-git-send-email-xiaosuo@gmail.com>
Le mardi 19 octobre 2010 à 13:24 +0800, Changli Gao a écrit :
> And since ctl_table.data is initialized later, we don't need to initialize
> the data member of the template variable unix_table.
>
The init cost is nothing, since its a data blob that must be there
anyway.
We could even avoid the kmemdup() if CONFIG_NET_NS is not set
^ permalink raw reply
* Re: [PATCH v6] Gigabit Ethernet driver of Topcliff PCH
From: Masayuki Ohtake @ 2010-10-19 5:30 UTC (permalink / raw)
To: seedshope
Cc: David S. Miller, Randy Dunlap, John Linn, Ralf Baechle,
Kristoffer Glembo, Maxime Bizon, Greg Rose, ML netdev, LKML,
Toshiharu Okada, Takahiro Shimizu, Tomoya Morinaga, Wang, Qi,
Wang, Yong Y, Andrew, Intel OTC, Foster, Margie, MeeGo
In-Reply-To: <AANLkTinedgQJq04PHdGmZqs4p6Du4PA16QC2JNTaGhAa@mail.gmail.com>
Hi seedshope,
>why it is need to compare the INT_EN bit?
>As general, the pch_gbe_intr function was call,the interrupt is enable.
>In addition to the interrupt generate, what other conditions would call the interrupt function?
PCI devices in Topcliff IOH are connected with external PCI Express through logical PCI bus.
In Topcliff IOH, more PCI devices are sharing interruption.
Gigabit Ethernet device and USB Host are sharing interruption.
The pch_gbe_intr function is called on condition of others.
So, the comparison with INT_EN bit is necessary.
>resently , I fail to test the kgdboe on the gbe driver.
>The pch_gbe_netpoll will call the pch_gbe_intr function.
>The interruption will be disable before enter the pch_gbe_intr.
>So the pch_gbe_netpoll is fail for ever. Is it a bug?
I think it is not a bug.
The INT_EN bit is a value of Gigabit Ethernet device's register.
The interruption disable processing before pch_gbe_intr() in pch_gbe_netpoll() function is a disable_irq() function.
The disable_irq() function does not change the register of a Gigabit Ethernet device.
Best regards.
Masayuki Otake.
-----
Date: Mon, 18 Oct 2010 16:48:50 +0800
From: seedshope
Hi Masayuki,
>/**
> * pch_gbe_intr - Interrupt Handler
> * @irq: Interrupt number
> * @data: Pointer to a network interface device structure
> * Returns
> * - IRQ_HANDLED: Our interrupt
> * - IRQ_NONE: Not our interrupt
> */
>static irqreturn_t pch_gbe_intr(int irq, void *data)
>{
> struct net_device *netdev = data;
> struct pch_gbe_adapter *adapter = netdev_priv(netdev);
> struct pch_gbe_hw *hw = &adapter->hw;
> u32 int_st;
> u32 int_en;
>
> /* Check request status */
> int_st = ioread32(&hw->reg->INT_ST);
> int_st = int_st & ioread32(&hw->reg->INT_EN);
why it is need to compare the INT_EN bit? As general, the pch_gbe_intr function was call,the interrupt is enable. In
addition to the interrupt generate, what other conditions would call the interrupt function?
resently , I fail to test the kgdboe on the gbe driver. The pch_gbe_netpoll will call the pch_gbe_intr function. The
interruption will be disable before enter the pch_gbe_intr.
So the pch_gbe_netpoll is fail for ever. Is it a bug?
> /* When request status is no interruption factor */
> if (unlikely(!int_st))
> return IRQ_NONE; /* Not our interrupt. End processing. */
> pr_debug("%s occur int_st = 0x%08x\n", __func__, int_st);
> if (int_st & PCH_GBE_INT_RX_FRAME_ERR)
> adapter->stats.intr_rx_frame_err_count++;
> if (int_st & PCH_GBE_INT_RX_FIFO_ERR)
> adapter->stats.intr_rx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_RX_DMA_ERR)
> adapter->stats.intr_rx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TX_FIFO_ERR)
> adapter->stats.intr_tx_fifo_err_count++;
> if (int_st & PCH_GBE_INT_TX_DMA_ERR)
> adapter->stats.intr_tx_dma_err_count++;
> if (int_st & PCH_GBE_INT_TCPIP_ERR)
> adapter->stats.intr_tcpip_err_count++;
> /* When Rx descriptor is empty */
> if ((int_st & PCH_GBE_INT_RX_DSC_EMP)) {
> adapter->stats.intr_rx_dsc_empty_count++;
> pr_err("Rx descriptor is empty\n");
> int_en = ioread32(&hw->reg->INT_EN);
> iowrite32((int_en & ~PCH_GBE_INT_RX_DSC_EMP), &hw->reg->INT_EN);
> if (hw->mac.tx_fc_enable) {
> /* Set Pause packet */
> pch_gbe_mac_set_pause_packet(hw);
> }
> if ((int_en & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))
> == 0) {
> return IRQ_HANDLED;
> }
> }
>
> /* When request status is Receive interruption */
> if ((int_st & (PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT))) {
> if (likely(napi_schedule_prep(&adapter->napi))) {
> /* Enable only Rx Descriptor empty */
> atomic_inc(&adapter->irq_sem);
> int_en = ioread32(&hw->reg->INT_EN);
> int_en &=
> ~(PCH_GBE_INT_RX_DMA_CMPLT | PCH_GBE_INT_TX_CMPLT);
> iowrite32(int_en, &hw->reg->INT_EN);
> /* Start polling for NAPI */
> __napi_schedule(&adapter->napi);
> }
> }
> pr_debug("return = 0x%08x INT_EN reg = 0x%08x\n",
> IRQ_HANDLED, ioread32(&hw->reg->INT_EN));
> return IRQ_HANDLED;
>}
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply
* [PATCH] net: unix: make some variables constant
From: Changli Gao @ 2010-10-19 5:24 UTC (permalink / raw)
To: David S. Miller; +Cc: netdev, Changli Gao
And since ctl_table.data is initialized later, we don't need to initialize
the data member of the template variable unix_table.
Signed-off-by: Changli Gao <xiaosuo@gmail.com>
---
net/unix/sysctl_net_unix.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/net/unix/sysctl_net_unix.c b/net/unix/sysctl_net_unix.c
index 397cffe..1114ccc 100644
--- a/net/unix/sysctl_net_unix.c
+++ b/net/unix/sysctl_net_unix.c
@@ -15,10 +15,9 @@
#include <net/af_unix.h>
-static ctl_table unix_table[] = {
+const static ctl_table unix_table[] = {
{
.procname = "max_dgram_qlen",
- .data = &init_net.unx.sysctl_max_dgram_qlen,
.maxlen = sizeof(int),
.mode = 0644,
.proc_handler = proc_dointvec
@@ -26,7 +25,7 @@ static ctl_table unix_table[] = {
{ }
};
-static struct ctl_path unix_path[] = {
+const static struct ctl_path unix_path[] = {
{ .procname = "net", },
{ .procname = "unix", },
{ },
^ permalink raw reply related
* Re: [PATCH] bonding: various fixes for bonding, netpoll & netconsole (v3)
From: Cong Wang @ 2010-10-19 5:21 UTC (permalink / raw)
To: David Miller; +Cc: nhorman, netdev, bonding-devel, fubar, andy
In-Reply-To: <20101018.082529.115920035.davem@davemloft.net>
On 10/18/10 23:25, David Miller wrote:
> From: nhorman@tuxdriver.com
> Date: Wed, 13 Oct 2010 22:01:48 -0400
>
>> Version 3, taking the following changes into account:
> ...
>> Signed-off-by: Neil Horman<nhorman@tuxdriver.com>
>
> Applied, thanks Neil.
Hi, David,
Which tree do you apply this patchset to? I checked both net-2.6
and net-next-2.6, neither of them has these patches.
I have some patches based on these patches.
Thanks.
^ permalink raw reply
* Re: [PATCH 1/3 v2] net: fail alloc_netdev_mq if queue count < 1
From: Eric Dumazet @ 2010-10-19 5:02 UTC (permalink / raw)
To: Tom Herbert; +Cc: davem, netdev, bhutchings
In-Reply-To: <alpine.DEB.1.00.1010182053060.6676@pokey.mtv.corp.google.com>
Le lundi 18 octobre 2010 à 20:55 -0700, Tom Herbert a écrit :
> In alloc_netdev_mq fail if requested queue_count < 1.
>
> Signed-off-by: Tom Herbert <therbert@google.com>
> ---
> net/core/dev.c | 6 ++++++
> 1 files changed, 6 insertions(+), 0 deletions(-)
Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Theodore Kilgore @ 2010-10-19 5:00 UTC (permalink / raw)
To: Steven Rostedt
Cc: Dave Airlie, Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <1287459219.16971.352.camel@gandalf.stny.rr.com>
On Mon, 18 Oct 2010, Steven Rostedt wrote:
> On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> > On Tue, Oct 19, 2010 at 12:24 PM, Greg KH <greg@kroah.com> wrote:
>
> > > So, there is no need for the i830 driver? Can it just be removed
> > > because i915 works instead?
> >
> > No because it provides a different userspace ABI to the i915 driver to
> > a different userspace X driver etc.
> >
> > like I'm sure the intersection of this driver and reality are getting
> > quite limited, but its still a userspace ABI change and needs to be
> > treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
> > old driver/API.
>
> Thus, you are saying that this will break for people with older user
> apps and have a newer kernel?
>
> >
> > >> So it really only leaves the problem case of what do distros do if we
> > >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
> > >> when you boot the SMP kernels on UP they don't run as SMP so not
> > >> having the driver load on those is a problem. Maybe we just need some
> > >> sort of warn on smp if a smp unfriendly driver is loaded and we
> > >> transition to SMP mode. Though this sounds like either (a) something
> > >> we do now and I don't about it, (b) work.
> > >
> > > So you are saying that just because distros will never build such a
> > > thing, we should keep it building for SMP mode? Why not prevent it from
> > > being built and if a distro really cares, then they will pony up the
> > > development to fix the driver up?
> >
> > Distros build the driver now even it it didn't work on SMP it wouldn't
> > matter to the 99% of people who have this hw since it can't suppport
> > SMP except in some corner cases. So not building for SMP is the same
> > as just throwing it out of the kernel since most people don't run
> > kernel.org kernels, and shouldn't have to just to get a driver for
> > some piece of hardware that worked fine up until now.
>
> Ah! Exactly! Thus, those that do not run kernel.org kernels are using a
> distro kernel. Wont these same people use the distro userspace? That is,
> if they have upgraded their kernel, most likely, they also update their
> X interface.
>
> >
> > Look at this from a user who has this hardware pov, it works for them
> > now with a distro kernel, us breaking it isn't going to help that user
> > or make any distro care, its just going to screw over the people who
> > are actually using it.
>
> But they can use the i915 driver instead, because they are using the
> newer userspace apps.
>
> >
> > > In other words, if someone really cares, then they will do the work,
> > > otherwise why worry? Especially as it seems that no one here is going
> > > to do it, right?
> >
> > Well the thing is doing the work right is a non-trivial task and just
> > dropping support only screws the people using the hardware,
> > it doesn't place any burden on the distro developers to fix it up. If
> > people are really serious about making the BKL go away completely, I
> > think the onus should be on them to fix the drivers not on the users
> > who are using it, like I'm guessing if this gets broken the bug will
> > end up in Novell or RH bugzilla in a year and nobody will ever see it.
>
> Well the problem comes down to testing it. I don't know of any developer
> that is removing the BKL that actually owns hardware to test out these
> broken drivers. And for the change not being trivial, means that there's
> no way to do in correctly.
>
> -- Steve
I might be able to find some hardware still lying around here that uses an
i810. Not sure unless I go hunting it. But I get the impression that if
the kernel is a single-CPU kernel there is not any problem anyway? Don't
distros offer a non-smp kernel as an installation option in case the user
needs it? So in reality how big a problem is this?
Theodore Kilgore
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Dave Airlie @ 2010-10-19 4:52 UTC (permalink / raw)
To: Theodore Kilgore
Cc: Steven Rostedt, Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <alpine.LNX.2.00.1010182342120.31740@banach.math.auburn.edu>
> I might be able to find some hardware still lying around here that uses an
> i810. Not sure unless I go hunting it. But I get the impression that if
> the kernel is a single-CPU kernel there is not any problem anyway? Don't
> distros offer a non-smp kernel as an installation option in case the user
> needs it? So in reality how big a problem is this?
Not anymore, which is my old point of making a fuss. Nowadays in the
modern distro world, we supply a single kernel that can at runtime
decide if its running on SMP or UP and rewrite the text section
appropriately with locks etc. Its like magic, and something like
marking drivers as BROKEN_ON_SMP at compile time is really wrong when
what you want now is a runtime warning if someone tries to hotplug a
CPU with a known iffy driver loaded or if someone tries to load the
driver when we are already in SMP mode.
Dave.
^ permalink raw reply
* [PATCH 3/3 v2] net: allocate tx queues in register_netdevice
From: Tom Herbert @ 2010-10-19 4:04 UTC (permalink / raw)
To: davem, netdev; +Cc: bhutchings, eric.dumazet
This patch introduces netif_alloc_netdev_queues which is called from
register_device instead of alloc_netdev_mq. This makes TX queue
allocation symmetric with RX allocation. Also, queue locks allocation
is done in netdev_init_one_queue. Change set_real_num_tx_queues to
fail if requested number < 1 or greater than number of allocated
queues.
Signed-off-by: Tom Herbert <therbert@google.com>
---
include/linux/netdevice.h | 4 +-
net/core/dev.c | 106 ++++++++++++++++++++++----------------------
2 files changed, 55 insertions(+), 55 deletions(-)
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 14fbb04..880d565 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1696,8 +1696,8 @@ static inline int netif_is_multiqueue(const struct net_device *dev)
return dev->num_tx_queues > 1;
}
-extern void netif_set_real_num_tx_queues(struct net_device *dev,
- unsigned int txq);
+extern int netif_set_real_num_tx_queues(struct net_device *dev,
+ unsigned int txq);
#ifdef CONFIG_RPS
extern int netif_set_real_num_rx_queues(struct net_device *dev,
diff --git a/net/core/dev.c b/net/core/dev.c
index d33adec..7ae5c7e 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1553,18 +1553,20 @@ static void dev_queue_xmit_nit(struct sk_buff *skb, struct net_device *dev)
* Routine to help set real_num_tx_queues. To avoid skbs mapped to queues
* greater then real_num_tx_queues stale skbs on the qdisc must be flushed.
*/
-void netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
+int netif_set_real_num_tx_queues(struct net_device *dev, unsigned int txq)
{
- unsigned int real_num = dev->real_num_tx_queues;
+ if (txq < 1 || txq > dev->num_tx_queues)
+ return -EINVAL;
- if (unlikely(txq > dev->num_tx_queues))
- ;
- else if (txq > real_num)
- dev->real_num_tx_queues = txq;
- else if (txq < real_num) {
- dev->real_num_tx_queues = txq;
- qdisc_reset_all_tx_gt(dev, txq);
+ if (dev->reg_state == NETREG_REGISTERED) {
+ ASSERT_RTNL();
+
+ if (txq < dev->real_num_tx_queues)
+ qdisc_reset_all_tx_gt(dev, txq);
}
+
+ dev->real_num_tx_queues = txq;
+ return 0;
}
EXPORT_SYMBOL(netif_set_real_num_tx_queues);
@@ -4928,20 +4930,6 @@ static void rollback_registered(struct net_device *dev)
rollback_registered_many(&single);
}
-static void __netdev_init_queue_locks_one(struct net_device *dev,
- struct netdev_queue *dev_queue,
- void *_unused)
-{
- spin_lock_init(&dev_queue->_xmit_lock);
- netdev_set_xmit_lockdep_class(&dev_queue->_xmit_lock, dev->type);
- dev_queue->xmit_lock_owner = -1;
-}
-
-static void netdev_init_queue_locks(struct net_device *dev)
-{
- netdev_for_each_tx_queue(dev, __netdev_init_queue_locks_one, NULL);
-}
-
unsigned long netdev_fix_features(unsigned long features, const char *name)
{
/* Fix illegal SG+CSUM combinations. */
@@ -5034,6 +5022,41 @@ static int netif_alloc_rx_queues(struct net_device *dev)
return 0;
}
+static int netif_alloc_netdev_queues(struct net_device *dev)
+{
+ unsigned int count = dev->num_tx_queues;
+ struct netdev_queue *tx;
+
+ BUG_ON(count < 1);
+
+ tx = kcalloc(count, sizeof(struct netdev_queue), GFP_KERNEL);
+ if (!tx) {
+ pr_err("netdev: Unable to allocate %u tx queues.\n",
+ count);
+ return -ENOMEM;
+ }
+ dev->_tx = tx;
+ return 0;
+}
+
+static void netdev_init_one_queue(struct net_device *dev,
+ struct netdev_queue *queue,
+ void *_unused)
+{
+ queue->dev = dev;
+
+ /* Initialize queue lock */
+ spin_lock_init(&queue->_xmit_lock);
+ netdev_set_xmit_lockdep_class(&queue->_xmit_lock, dev->type);
+ queue->xmit_lock_owner = -1;
+}
+
+static void netdev_init_queues(struct net_device *dev)
+{
+ netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
+ spin_lock_init(&dev->tx_global_lock);
+}
+
/**
* register_netdevice - register a network device
* @dev: device to register
@@ -5067,7 +5090,6 @@ int register_netdevice(struct net_device *dev)
spin_lock_init(&dev->addr_list_lock);
netdev_set_addr_lockdep_class(dev);
- netdev_init_queue_locks(dev);
dev->iflink = -1;
@@ -5075,6 +5097,12 @@ int register_netdevice(struct net_device *dev)
if (ret)
goto out;
+ ret = netif_alloc_netdev_queues(dev);
+ if (ret)
+ goto out;
+
+ netdev_init_queues(dev);
+
/* Init, if this function is available */
if (dev->netdev_ops->ndo_init) {
ret = dev->netdev_ops->ndo_init(dev);
@@ -5456,19 +5484,6 @@ struct rtnl_link_stats64 *dev_get_stats(struct net_device *dev,
}
EXPORT_SYMBOL(dev_get_stats);
-static void netdev_init_one_queue(struct net_device *dev,
- struct netdev_queue *queue,
- void *_unused)
-{
- queue->dev = dev;
-}
-
-static void netdev_init_queues(struct net_device *dev)
-{
- netdev_for_each_tx_queue(dev, netdev_init_one_queue, NULL);
- spin_lock_init(&dev->tx_global_lock);
-}
-
struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
{
struct netdev_queue *queue = dev_ingress_queue(dev);
@@ -5480,7 +5495,6 @@ struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
if (!queue)
return NULL;
netdev_init_one_queue(dev, queue, NULL);
- __netdev_init_queue_locks_one(dev, queue, NULL);
queue->qdisc = &noop_qdisc;
queue->qdisc_sleeping = &noop_qdisc;
rcu_assign_pointer(dev->ingress_queue, queue);
@@ -5502,7 +5516,6 @@ struct netdev_queue *dev_ingress_queue_create(struct net_device *dev)
struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
void (*setup)(struct net_device *), unsigned int queue_count)
{
- struct netdev_queue *tx;
struct net_device *dev;
size_t alloc_size;
struct net_device *p;
@@ -5530,20 +5543,12 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
return NULL;
}
- tx = kcalloc(queue_count, sizeof(struct netdev_queue), GFP_KERNEL);
- if (!tx) {
- printk(KERN_ERR "alloc_netdev: Unable to allocate "
- "tx qdiscs.\n");
- goto free_p;
- }
-
-
dev = PTR_ALIGN(p, NETDEV_ALIGN);
dev->padded = (char *)dev - (char *)p;
dev->pcpu_refcnt = alloc_percpu(int);
if (!dev->pcpu_refcnt)
- goto free_tx;
+ goto free_p;
if (dev_addr_init(dev))
goto free_pcpu;
@@ -5553,7 +5558,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev_net_set(dev, &init_net);
- dev->_tx = tx;
dev->num_tx_queues = queue_count;
dev->real_num_tx_queues = queue_count;
@@ -5564,8 +5568,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
dev->gso_max_size = GSO_MAX_SIZE;
- netdev_init_queues(dev);
-
INIT_LIST_HEAD(&dev->ethtool_ntuple_list.list);
dev->ethtool_ntuple_list.count = 0;
INIT_LIST_HEAD(&dev->napi_list);
@@ -5576,8 +5578,6 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
strcpy(dev->name, name);
return dev;
-free_tx:
- kfree(tx);
free_pcpu:
free_percpu(dev->pcpu_refcnt);
free_p:
--
1.7.1
^ permalink raw reply related
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Dave Airlie @ 2010-10-19 4:03 UTC (permalink / raw)
To: Steven Rostedt
Cc: Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <1287459219.16971.352.camel@gandalf.stny.rr.com>
>>
>> like I'm sure the intersection of this driver and reality are getting
>> quite limited, but its still a userspace ABI change and needs to be
>> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
>> old driver/API.
>
> Thus, you are saying that this will break for people with older user
> apps and have a newer kernel?
There are two drivers here:
i810
i830
The i830 case is the case I care less about since the ABI is only used
by older userspace and i915 provides a replacement.
the i810 case ABI is still in use today by distro userspaces that are
still released, i.e. i810 is still used in F14, Ubuntu 10.10, RHEL6
Beta etc.
I've snipped the rest of the argument on the grounds you are
conflating two cases that aren't the same.
>
>>
>> Well the thing is doing the work right is a non-trivial task and just
>> dropping support only screws the people using the hardware,
>> it doesn't place any burden on the distro developers to fix it up. If
>> people are really serious about making the BKL go away completely, I
>> think the onus should be on them to fix the drivers not on the users
>> who are using it, like I'm guessing if this gets broken the bug will
>> end up in Novell or RH bugzilla in a year and nobody will ever see it.
>
> Well the problem comes down to testing it. I don't know of any developer
> that is removing the BKL that actually owns hardware to test out these
> broken drivers. And for the change not being trivial, means that there's
> no way to do in correctly.
>
So we can drop i830 using deprecation, however its pointless since the
fix for i810 is the same fix for i830 if we can work out the fix.
Well the way to do it correctly is make it so if the driver is
initialised and we do an SMP transition we warn the users, or we make
BROKEN_ON_SMP into a runtime thing that warns when the driver is
loaded on an SMP system. The intersection of SMP and this hardware is
definitely a very very small number and a lot more workable.
Dave.
--
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* [PATCH 2/3 v2] net: cleanups in RX queue allocation
From: Tom Herbert @ 2010-10-19 4:00 UTC (permalink / raw)
To: davem, netdev; +Cc: bhutchings, eric.dumazet
Clean up in RX queue allocation. In netif_set_real_num_rx_queues
return error on attempt to set zero queues, or requested number is
greater than number of allocated queues. In netif_alloc_rx_queues,
do BUG_ON if queue_count is zero.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 36 +++++++++++++++++-------------------
1 files changed, 17 insertions(+), 19 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index f44d29a..d33adec 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1583,12 +1583,12 @@ int netif_set_real_num_rx_queues(struct net_device *dev, unsigned int rxq)
{
int rc;
+ if (rxq < 1 || rxq > dev->num_rx_queues)
+ return -EINVAL;
+
if (dev->reg_state == NETREG_REGISTERED) {
ASSERT_RTNL();
- if (rxq > dev->num_rx_queues)
- return -EINVAL;
-
rc = net_rx_queue_update_kobjects(dev, dev->real_num_rx_queues,
rxq);
if (rc)
@@ -5013,25 +5013,23 @@ static int netif_alloc_rx_queues(struct net_device *dev)
{
#ifdef CONFIG_RPS
unsigned int i, count = dev->num_rx_queues;
+ struct netdev_rx_queue *rx;
- if (count) {
- struct netdev_rx_queue *rx;
-
- rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
- if (!rx) {
- pr_err("netdev: Unable to allocate %u rx queues.\n",
- count);
- return -ENOMEM;
- }
- dev->_rx = rx;
+ BUG_ON(count < 1);
- /*
- * Set a pointer to first element in the array which holds the
- * reference count.
- */
- for (i = 0; i < count; i++)
- rx[i].first = rx;
+ rx = kcalloc(count, sizeof(struct netdev_rx_queue), GFP_KERNEL);
+ if (!rx) {
+ pr_err("netdev: Unable to allocate %u rx queues.\n", count);
+ return -ENOMEM;
}
+ dev->_rx = rx;
+
+ /*
+ * Set a pointer to first element in the array which holds the
+ * reference count.
+ */
+ for (i = 0; i < count; i++)
+ rx[i].first = rx;
#endif
return 0;
}
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3 v2] net: fail alloc_netdev_mq if queue count < 1
From: Tom Herbert @ 2010-10-19 3:55 UTC (permalink / raw)
To: davem, netdev; +Cc: bhutchings, eric.dumazet
In alloc_netdev_mq fail if requested queue_count < 1.
Signed-off-by: Tom Herbert <therbert@google.com>
---
net/core/dev.c | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/net/core/dev.c b/net/core/dev.c
index 04972a4..f44d29a 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -5511,6 +5511,12 @@ struct net_device *alloc_netdev_mq(int sizeof_priv, const char *name,
BUG_ON(strlen(name) >= sizeof(dev->name));
+ if (queue_count < 1) {
+ pr_err("alloc_netdev: Unable to allocate device "
+ "with zero queues.\n");
+ return NULL;
+ }
+
alloc_size = sizeof(struct net_device);
if (sizeof_priv) {
/* ensure 32-byte alignment of private area */
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] netxen: make local function static.
From: Stephen Hemminger @ 2010-10-19 3:40 UTC (permalink / raw)
To: Amit Kumar Salecha, David S. Miller, Narender Kumar,
Rajesh Borundia; +Cc: netdev
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
---
drivers/net/netxen/netxen_nic.h | 18 +-----------------
drivers/net/netxen/netxen_nic_hw.c | 29 +++++++++++------------------
drivers/net/netxen/netxen_nic_main.c | 6 ++++--
3 files changed, 16 insertions(+), 37 deletions(-)
--- a/drivers/net/netxen/netxen_nic_hw.c 2010-10-15 16:16:11.934234483 -0700
+++ b/drivers/net/netxen/netxen_nic_hw.c 2010-10-15 16:25:09.920752564 -0700
@@ -319,6 +319,8 @@ static unsigned crb_hub_agt[64] =
#define NETXEN_PCIE_SEM_TIMEOUT 10000
+static int netxen_nic_set_mtu_xgb(struct netxen_adapter *adapter, int new_mtu);
+
int
netxen_pcie_sem_lock(struct netxen_adapter *adapter, int sem, u32 id_reg)
{
@@ -345,7 +347,7 @@ netxen_pcie_sem_unlock(struct netxen_ada
NXRD32(adapter, NETXEN_PCIE_REG(PCIE_SEM_UNLOCK(sem)));
}
-int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port)
+static int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port)
{
if (NX_IS_REVISION_P2(adapter->ahw.revision_id)) {
NXWR32(adapter, NETXEN_NIU_XGE_CONFIG_1+(0x10000*port), 0x1447);
@@ -356,7 +358,7 @@ int netxen_niu_xg_init_port(struct netxe
}
/* Disable an XG interface */
-int netxen_niu_disable_xg_port(struct netxen_adapter *adapter)
+static int netxen_niu_disable_xg_port(struct netxen_adapter *adapter)
{
__u32 mac_cfg;
u32 port = adapter->physical_port;
@@ -383,7 +385,7 @@ int netxen_niu_disable_xg_port(struct ne
#define MAC_LO(addr) \
((addr[5] << 16) | (addr[4] << 8) | (addr[3]))
-int netxen_p2_nic_set_promisc(struct netxen_adapter *adapter, u32 mode)
+static int netxen_p2_nic_set_promisc(struct netxen_adapter *adapter, u32 mode)
{
u32 mac_cfg;
u32 cnt = 0;
@@ -434,7 +436,7 @@ int netxen_p2_nic_set_promisc(struct net
return 0;
}
-int netxen_p2_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr)
+static int netxen_p2_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr)
{
u32 mac_hi, mac_lo;
u32 reg_hi, reg_lo;
@@ -531,7 +533,7 @@ netxen_nic_set_mcast_addr(struct netxen_
return 0;
}
-void netxen_p2_nic_set_multi(struct net_device *netdev)
+static void netxen_p2_nic_set_multi(struct net_device *netdev)
{
struct netxen_adapter *adapter = netdev_priv(netdev);
struct netdev_hw_addr *ha;
@@ -674,7 +676,7 @@ static int nx_p3_nic_add_mac(struct netx
cur->mac_addr, NETXEN_MAC_ADD);
}
-void netxen_p3_nic_set_multi(struct net_device *netdev)
+static void netxen_p3_nic_set_multi(struct net_device *netdev)
{
struct netxen_adapter *adapter = netdev_priv(netdev);
struct netdev_hw_addr *ha;
@@ -721,7 +723,7 @@ send_fw_cmd:
}
}
-int netxen_p3_nic_set_promisc(struct netxen_adapter *adapter, u32 mode)
+static int netxen_p3_nic_set_promisc(struct netxen_adapter *adapter, u32 mode)
{
nx_nic_req_t req;
u64 word;
@@ -754,7 +756,7 @@ void netxen_p3_free_mac_list(struct netx
}
}
-int netxen_p3_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr)
+static int netxen_p3_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr)
{
/* assuming caller has already copied new addr to netdev */
netxen_p3_nic_set_multi(adapter->netdev);
@@ -1867,16 +1869,7 @@ int netxen_nic_get_board_info(struct net
}
/* NIU access sections */
-
-int netxen_nic_set_mtu_gb(struct netxen_adapter *adapter, int new_mtu)
-{
- new_mtu += MTU_FUDGE_FACTOR;
- NXWR32(adapter, NETXEN_NIU_GB_MAX_FRAME_SIZE(adapter->physical_port),
- new_mtu);
- return 0;
-}
-
-int netxen_nic_set_mtu_xgb(struct netxen_adapter *adapter, int new_mtu)
+static int netxen_nic_set_mtu_xgb(struct netxen_adapter *adapter, int new_mtu)
{
new_mtu += MTU_FUDGE_FACTOR;
if (adapter->physical_port == 0)
--- a/drivers/net/netxen/netxen_nic_main.c 2010-10-15 16:18:10.750321685 -0700
+++ b/drivers/net/netxen/netxen_nic_main.c 2010-10-15 16:21:45.277705058 -0700
@@ -95,6 +95,8 @@ static irqreturn_t netxen_msi_intr(int i
static irqreturn_t netxen_msix_intr(int irq, void *data);
static void netxen_config_indev_addr(struct net_device *dev, unsigned long);
+static struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev);
+static int netxen_nic_set_mac(struct net_device *netdev, void *p);
/* PCI Device ID Table */
#define ENTRY(device) \
@@ -460,7 +462,7 @@ netxen_read_mac_addr(struct netxen_adapt
return 0;
}
-int netxen_nic_set_mac(struct net_device *netdev, void *p)
+static int netxen_nic_set_mac(struct net_device *netdev, void *p)
{
struct netxen_adapter *adapter = netdev_priv(netdev);
struct sockaddr *addr = p;
@@ -2027,7 +2029,7 @@ request_reset:
clear_bit(__NX_RESETTING, &adapter->state);
}
-struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
+static struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev)
{
struct netxen_adapter *adapter = netdev_priv(netdev);
struct net_device_stats *stats = &netdev->stats;
--- a/drivers/net/netxen/netxen_nic.h 2010-10-15 16:16:06.350042428 -0700
+++ b/drivers/net/netxen/netxen_nic.h 2010-10-15 16:22:27.963174722 -0700
@@ -1253,19 +1253,9 @@ struct netxen_adapter {
const struct firmware *fw;
};
-int netxen_niu_xg_init_port(struct netxen_adapter *adapter, int port);
-int netxen_niu_disable_xg_port(struct netxen_adapter *adapter);
-
int nx_fw_cmd_query_phy(struct netxen_adapter *adapter, u32 reg, u32 *val);
int nx_fw_cmd_set_phy(struct netxen_adapter *adapter, u32 reg, u32 val);
-/* Functions available from netxen_nic_hw.c */
-int netxen_nic_set_mtu_xgb(struct netxen_adapter *adapter, int new_mtu);
-int netxen_nic_set_mtu_gb(struct netxen_adapter *adapter, int new_mtu);
-
-int netxen_p2_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr);
-int netxen_p3_nic_set_mac_addr(struct netxen_adapter *adapter, u8 *addr);
-
#define NXRD32(adapter, off) \
(adapter->crb_read(adapter, off))
#define NXWR32(adapter, off, val) \
@@ -1345,11 +1335,8 @@ void netxen_post_rx_buffers(struct netxe
struct nx_host_rds_ring *rds_ring);
int netxen_process_cmd_ring(struct netxen_adapter *adapter);
int netxen_process_rcv_ring(struct nx_host_sds_ring *sds_ring, int max);
-void netxen_p2_nic_set_multi(struct net_device *netdev);
-void netxen_p3_nic_set_multi(struct net_device *netdev);
+
void netxen_p3_free_mac_list(struct netxen_adapter *adapter);
-int netxen_p2_nic_set_promisc(struct netxen_adapter *adapter, u32 mode);
-int netxen_p3_nic_set_promisc(struct netxen_adapter *adapter, u32);
int netxen_config_intr_coalesce(struct netxen_adapter *adapter);
int netxen_config_rss(struct netxen_adapter *adapter, int enable);
int netxen_config_ipaddr(struct netxen_adapter *adapter, u32 ip, int cmd);
@@ -1364,9 +1351,6 @@ int netxen_config_hw_lro(struct netxen_a
int netxen_config_bridged_mode(struct netxen_adapter *adapter, int enable);
int netxen_send_lro_cleanup(struct netxen_adapter *adapter);
-int netxen_nic_set_mac(struct net_device *netdev, void *p);
-struct net_device_stats *netxen_nic_get_stats(struct net_device *netdev);
-
void netxen_nic_update_cmd_producer(struct netxen_adapter *adapter,
struct nx_host_tx_ring *tx_ring);
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Steven Rostedt @ 2010-10-19 3:33 UTC (permalink / raw)
To: Dave Airlie
Cc: Greg KH, codalist, autofs, Samuel Ortiz, Jan Kara,
Mikulas Patocka, Arnd Bergmann, Jan Harkes, netdev, Anders Larsen,
linux-kernel, dri-devel, Bryan Schumaker, Christoph Hellwig,
ksummit-2010-discuss, Petr Vandrovec, Arnaldo Carvalho de Melo,
linux-fsdevel, Evgeniy Dushistov, Ingo Molnar, Andrew Hendry,
linux-media
In-Reply-To: <AANLkTinv4VFpi=Jkc_5oyFgPbdLRg0ResJx9u9Puhm-7@mail.gmail.com>
On Tue, 2010-10-19 at 12:45 +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 12:24 PM, Greg KH <greg@kroah.com> wrote:
> > So, there is no need for the i830 driver? Can it just be removed
> > because i915 works instead?
>
> No because it provides a different userspace ABI to the i915 driver to
> a different userspace X driver etc.
>
> like I'm sure the intersection of this driver and reality are getting
> quite limited, but its still a userspace ABI change and needs to be
> treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
> old driver/API.
Thus, you are saying that this will break for people with older user
apps and have a newer kernel?
>
> >> So it really only leaves the problem case of what do distros do if we
> >> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
> >> when you boot the SMP kernels on UP they don't run as SMP so not
> >> having the driver load on those is a problem. Maybe we just need some
> >> sort of warn on smp if a smp unfriendly driver is loaded and we
> >> transition to SMP mode. Though this sounds like either (a) something
> >> we do now and I don't about it, (b) work.
> >
> > So you are saying that just because distros will never build such a
> > thing, we should keep it building for SMP mode? Why not prevent it from
> > being built and if a distro really cares, then they will pony up the
> > development to fix the driver up?
>
> Distros build the driver now even it it didn't work on SMP it wouldn't
> matter to the 99% of people who have this hw since it can't suppport
> SMP except in some corner cases. So not building for SMP is the same
> as just throwing it out of the kernel since most people don't run
> kernel.org kernels, and shouldn't have to just to get a driver for
> some piece of hardware that worked fine up until now.
Ah! Exactly! Thus, those that do not run kernel.org kernels are using a
distro kernel. Wont these same people use the distro userspace? That is,
if they have upgraded their kernel, most likely, they also update their
X interface.
>
> Look at this from a user who has this hardware pov, it works for them
> now with a distro kernel, us breaking it isn't going to help that user
> or make any distro care, its just going to screw over the people who
> are actually using it.
But they can use the i915 driver instead, because they are using the
newer userspace apps.
>
> > In other words, if someone really cares, then they will do the work,
> > otherwise why worry? Especially as it seems that no one here is going
> > to do it, right?
>
> Well the thing is doing the work right is a non-trivial task and just
> dropping support only screws the people using the hardware,
> it doesn't place any burden on the distro developers to fix it up. If
> people are really serious about making the BKL go away completely, I
> think the onus should be on them to fix the drivers not on the users
> who are using it, like I'm guessing if this gets broken the bug will
> end up in Novell or RH bugzilla in a year and nobody will ever see it.
Well the problem comes down to testing it. I don't know of any developer
that is removing the BKL that actually owns hardware to test out these
broken drivers. And for the change not being trivial, means that there's
no way to do in correctly.
-- Steve
^ permalink raw reply
* Re: [PATCH] bridge: Forward reserved group addresses if !STP
From: Stephen Hemminger @ 2010-10-19 3:28 UTC (permalink / raw)
To: Benjamin Poirier
Cc: David S. Miller, Herbert Xu, Eric Dumazet, Jiri Pirko, bridge,
netdev, linux-kernel
In-Reply-To: <1287454175-22903-1-git-send-email-benjamin.poirier@polymtl.ca>
On Mon, 18 Oct 2010 22:09:35 -0400
Benjamin Poirier <benjamin.poirier@polymtl.ca> wrote:
> Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
> 01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
> forwarding EAPOL frames, among other things.
>
> Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
^ permalink raw reply
* Re: [RFC PATCH 1/7] ebtables: Allow filtering of hardware accelerated vlan frames.
From: Jesse Gross @ 2010-10-19 3:14 UTC (permalink / raw)
To: Ben Hutchings; +Cc: davem, netdev
In-Reply-To: <1287431892.2252.575.camel@achroite.uk.solarflarecom.com>
On Mon, Oct 18, 2010 at 12:58 PM, Ben Hutchings
<bhutchings@solarflare.com> wrote:
> On Wed, 2010-10-13 at 13:02 -0700, Jesse Gross wrote:
>> An upcoming commit will allow packets with hardware vlan acceleration
>> information to be passed though more parts of the network stack, including
>> packets trunked through the bridge. This adds support for matching and
>> filtering those packets through ebtables.
>>
>> Signed-off-by: Jesse Gross <jesse@nicira.com>
>> ---
>> net/bridge/br_netfilter.c | 16 +++++++++-------
>> net/bridge/netfilter/ebt_vlan.c | 38 +++++++++++++++++++++++---------------
>> net/bridge/netfilter/ebtables.c | 15 +++++++++++----
>> 3 files changed, 43 insertions(+), 26 deletions(-)
>>
>> diff --git a/net/bridge/br_netfilter.c b/net/bridge/br_netfilter.c
>> index 7f9ce96..d6a4fec 100644
>> --- a/net/bridge/br_netfilter.c
>> +++ b/net/bridge/br_netfilter.c
>> @@ -64,22 +64,24 @@ static int brnf_filter_pppoe_tagged __read_mostly = 0;
>>
>> static inline __be16 vlan_proto(const struct sk_buff *skb)
>> {
>> - return vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
>> + if (skb->protocol == htons(ETH_P_8021Q))
>> + return vlan_eth_hdr(skb)->h_vlan_encapsulated_proto;
>> + else if (vlan_tx_tag_present(skb))
>> + return skb->protocol;
>
> If there are two levels of VLAN-encapsulation, this will return either
> the inner or outer tag depending on whether VLAN acceleration is being
> used. It should behave consistently.
Thanks, you're right. I fixed it to always use the outer tag (same as
previous behavior).
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Dave Airlie @ 2010-10-19 2:45 UTC (permalink / raw)
To: Greg KH
Cc: Arnd Bergmann, codalist, ksummit-2010-discuss, autofs, Jan Harkes,
Samuel Ortiz, Jan Kara, Arnaldo Carvalho de Melo, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, Petr Vandrovec, Mikulas Patocka, linux-fsdevel,
Evgeniy Dushistov, Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <20101019022413.GB30307@kroah.com>
On Tue, Oct 19, 2010 at 12:24 PM, Greg KH <greg@kroah.com> wrote:
> On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
>> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH <greg@kroah.com> wrote:
>> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
>> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH <greg@kroah.com> wrote:
>> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
>> >> >>
>> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
>> >> >> up not getting fixed at all, we can either mark them non-SMP or move them
>> >> >> to drivers/staging once all the others are done.
>> >> >
>> >> > I recommend moving them to staging, and then retire them from there if
>> >> > no one steps up to maintain them.
>> >>
>> >> I think this sets a bad precedent, these drivers work fine. Removing
>> >> BKL from them is hard, and involves finding and booting hw that
>> >> developers don't have much time/interest in at the moment. Anyone who
>> >> has access to the i810 hw and has time to work out the locking has
>> >> more important things to be doing with modern hw, however it doesn't
>> >> mean we should just drop support for old drivers because they don't
>> >> have active maintainers. Removing the BKL from the kernel is a great
>> >> goal, but breaking userspace ABI by removing drivers isn't.
>> >
>> > Should we just restrict such drivers to only be able to build on UP
>> > machines with preempt disabled so that the BKL could be safely removed
>> > from them?
>> >
>> > Or what other idea do you have as to what could be done here?
>> >
>> > I do have access to this hardware, but its on an old single processor
>> > laptop, so any work that it would take to help do this development,
>> > really wouldn't be able to be tested to be valid at all.
>>
>> There is only very rare case where the i830 driver might get used with
>> SMP and really I think that case is in the don't care place, since if
>> you have that hw you probably should be using i915 on it anyways.
>
> So, there is no need for the i830 driver? Can it just be removed
> because i915 works instead?
No because it provides a different userspace ABI to the i915 driver to
a different userspace X driver etc.
like I'm sure the intersection of this driver and reality are getting
quite limited, but its still a userspace ABI change and needs to be
treated as such. Xorg 6.7 and XFree86 4.3 were the last users of the
old driver/API.
>> So it really only leaves the problem case of what do distros do if we
>> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
>> when you boot the SMP kernels on UP they don't run as SMP so not
>> having the driver load on those is a problem. Maybe we just need some
>> sort of warn on smp if a smp unfriendly driver is loaded and we
>> transition to SMP mode. Though this sounds like either (a) something
>> we do now and I don't about it, (b) work.
>
> So you are saying that just because distros will never build such a
> thing, we should keep it building for SMP mode? Why not prevent it from
> being built and if a distro really cares, then they will pony up the
> development to fix the driver up?
Distros build the driver now even it it didn't work on SMP it wouldn't
matter to the 99% of people who have this hw since it can't suppport
SMP except in some corner cases. So not building for SMP is the same
as just throwing it out of the kernel since most people don't run
kernel.org kernels, and shouldn't have to just to get a driver for
some piece of hardware that worked fine up until now.
Look at this from a user who has this hardware pov, it works for them
now with a distro kernel, us breaking it isn't going to help that user
or make any distro care, its just going to screw over the people who
are actually using it.
> In other words, if someone really cares, then they will do the work,
> otherwise why worry? Especially as it seems that no one here is going
> to do it, right?
Well the thing is doing the work right is a non-trivial task and just
dropping support only screws the people using the hardware,
it doesn't place any burden on the distro developers to fix it up. If
people are really serious about making the BKL go away completely, I
think the onus should be on them to fix the drivers not on the users
who are using it, like I'm guessing if this gets broken the bug will
end up in Novell or RH bugzilla in a year and nobody will ever see it.
Dave.
^ permalink raw reply
* Re: [Ksummit-2010-discuss] [v2] Remaining BKL users, what to do
From: Greg KH @ 2010-10-19 2:24 UTC (permalink / raw)
To: Dave Airlie
Cc: Arnd Bergmann, codalist, ksummit-2010-discuss, autofs, Jan Harkes,
Samuel Ortiz, Jan Kara, Arnaldo Carvalho de Melo, netdev,
Anders Larsen, linux-kernel, dri-devel, Bryan Schumaker,
Christoph Hellwig, Petr Vandrovec, Mikulas Patocka, linux-fsdevel,
Evgeniy Dushistov, Ingo Molnar, Andrew Hendry, linux-media
In-Reply-To: <AANLkTi=ffaihP5-yNYFKAbAbX+XbRgWRXXfCZd4J3KwQ@mail.gmail.com>
On Tue, Oct 19, 2010 at 10:57:43AM +1000, Dave Airlie wrote:
> On Tue, Oct 19, 2010 at 10:40 AM, Greg KH <greg@kroah.com> wrote:
> > On Tue, Oct 19, 2010 at 09:00:09AM +1000, Dave Airlie wrote:
> >> On Tue, Oct 19, 2010 at 4:43 AM, Greg KH <greg@kroah.com> wrote:
> >> > On Mon, Oct 18, 2010 at 05:42:06PM +0200, Arnd Bergmann wrote:
> >> >>
> >> >> Out of the remaining modules, I guess i810/i830, adfs, hpfs and ufs might end
> >> >> up not getting fixed at all, we can either mark them non-SMP or move them
> >> >> to drivers/staging once all the others are done.
> >> >
> >> > I recommend moving them to staging, and then retire them from there if
> >> > no one steps up to maintain them.
> >>
> >> I think this sets a bad precedent, these drivers work fine. Removing
> >> BKL from them is hard, and involves finding and booting hw that
> >> developers don't have much time/interest in at the moment. Anyone who
> >> has access to the i810 hw and has time to work out the locking has
> >> more important things to be doing with modern hw, however it doesn't
> >> mean we should just drop support for old drivers because they don't
> >> have active maintainers. Removing the BKL from the kernel is a great
> >> goal, but breaking userspace ABI by removing drivers isn't.
> >
> > Should we just restrict such drivers to only be able to build on UP
> > machines with preempt disabled so that the BKL could be safely removed
> > from them?
> >
> > Or what other idea do you have as to what could be done here?
> >
> > I do have access to this hardware, but its on an old single processor
> > laptop, so any work that it would take to help do this development,
> > really wouldn't be able to be tested to be valid at all.
>
> There is only very rare case where the i830 driver might get used with
> SMP and really I think that case is in the don't care place, since if
> you have that hw you probably should be using i915 on it anyways.
So, there is no need for the i830 driver? Can it just be removed
because i915 works instead?
> So it really only leaves the problem case of what do distros do if we
> mark things as BROKEN_ON_SMP, since no distro builds UP kernels and
> when you boot the SMP kernels on UP they don't run as SMP so not
> having the driver load on those is a problem. Maybe we just need some
> sort of warn on smp if a smp unfriendly driver is loaded and we
> transition to SMP mode. Though this sounds like either (a) something
> we do now and I don't about it, (b) work.
So you are saying that just because distros will never build such a
thing, we should keep it building for SMP mode? Why not prevent it from
being built and if a distro really cares, then they will pony up the
development to fix the driver up?
In other words, if someone really cares, then they will do the work,
otherwise why worry? Especially as it seems that no one here is going
to do it, right?
thanks,
greg k-h
^ permalink raw reply
* Re: Linux 2.6.35/TIPC 2.0 ABI breaking changes
From: Leandro Lucarella @ 2010-10-19 2:16 UTC (permalink / raw)
To: Neil Horman
Cc: Paul Gortmaker, jon.maloy, netdev, linux-kernel, tipc-discussion,
David Miller
In-Reply-To: <20101018234547.GA5703@hmsreliant.think-freely.org>
Neil Horman, el 18 de octubre a las 19:45 me escribiste:
> > What I think has happened here (and I'll double check this
> > tomorrow, since it is before I started assisting with tipc)
> > is that a backwards incompatible change *did* inadvertently
> > creep in via these two (related) commits:
> >
> > --------------
> > commit d88dca79d3852a3623f606f781e013d61486828a
> > Author: Neil Horman <nhorman@tuxdriver.com>
> > Date: Mon Mar 8 12:20:58 2010 -0800
> >
> > tipc: fix endianness on tipc subscriber messages
> > --------------
> >
> > and
> >
> > ---------------
> > commit c6537d6742985da1fbf12ae26cde6a096fd35b5c
> > Author: Jon Paul Maloy <jon.maloy@ericsson.com>
> > Date: Tue Apr 6 11:40:52 2010 +0000
> >
> > TIPC: Updated topology subscription protocol according to latest spec
> > ---------------
> >
> > Based on Leandro's info, I think it comes down to userspace
> > not knowing exactly where to find these bits anymore:
> >
> > #define TIPC_SUB_SERVICE 0x00 /* Filter for service availability */
> > #define TIPC_SUB_PORTS 0x01 /* Filter for port availability */
> > #define TIPC_SUB_CANCEL 0x04 /* Cancel a subscription */
> >
> That shouldn't be the case. Prior to the above changes the tipc implementation
> tracked the endianess of the hosts to which it was connected and swapped data
> that it sent to those hosts accordingly. With these changes the kernel client
> simply swaps the data to network byte order on send and swaps it back to local
> order on receive universally. That second commit added a bit from the reserved
> pool of one of the connection establishment messages to indicate that a peer was
> using this new protocol. If some non-local byte order information is making it
> into user space, thats a bug that needs fixing.
>
> What may be happening is some old client that doesn't know about the new bit
> might be communicating with an new client that does. IIRC the spec called for
> clients that set bits in the reserved field to drop frames from that client, so
> that condition shouldn't occur, but TIPC may just be ignoring reserved bits. I
> wouldn't be suprised.
>
> Its also possible that the payload data between applications using tipc follow
> the same broken byte swapping method that the protocol itself did, but if that
> were the case I would expect the application to continue running normally,
> unless user space had direct access to the protocol header in its entirety, and
> read it directly, in which case I think I would just cry.
I think there is some misunderstanding here. The compatibility was
broken only for subscriptions messages. The subscriptions messages are
not sent between tipc clients (or maybe they are, but that's not how
tipc developers normally use them AFAIK). You send a subscription
message to your host tipc stack and the stack reply you with event
notifications. Even when they are message sent through a socket, they
are used as an API.
So, this has nothing to do with payload data transmitted by applications
using tipc. We are talking about the tipc API, which is "masked" into
a socket.
Here is a small example (~150 SLOC with comments). Using TIPC 2.0 API:
http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/allan/tipcutils.git;a=blob;h=efdfa3802e51d9a2a9091b3d97625de9e686b72e;hb=tipcutils2.0;f=demos/topology_subscr_demo/client_tipc.c
Using the "old" TIPC 1.6 API:
http://tipc.cslab.ericsson.net/cgi-bin/gitweb.cgi?p=people/allan/tipcutils.git;a=blob;h=ac5dfc5004b482372abb7905c90fe3073fc9165d;hb=15f57f7572898959e0aaa66293895a8255d77021;f=demos/topology_subscr_demo/subscriptions.c
> > ...because it doesn't know if there is the old auto endian
> > swap thing being done or not being done.
> >
> > Assuming it is possible to do so in some non-kludgy way,
> > it sounds like we want to be looking into an in-kernel change
> > that ensures the older user space binaries get their
> > functionality restored then?
> >
> Lets try figure out exactly what data is getting mis-read first. Maybe we can
> fix it without having to go back to making a sending host figure out a receiving
> hosts byte order. That would be nice. Can you describe the problem in more
> detail?
The problem is not between the tipc stacks in different hosts, is
between the tipc stack and the applications using it (well, maybe there
is a problem somewhere else too).
This was a deliberate API change, not a subtle bug...
--
Leandro Lucarella (AKA luca) http://llucax.com.ar/
----------------------------------------------------------------------
GPG Key: 5F5A8D05 (F8CD F9A7 BF00 5431 4145 104C 949E BFB6 5F5A 8D05)
----------------------------------------------------------------------
For me to ask a woman out, I've got to get into a mental state like the karate
guys before they break the bricks.
-- George Constanza
^ permalink raw reply
* [PATCH] bridge: Forward reserved group addresses if !STP
From: Benjamin Poirier @ 2010-10-19 2:09 UTC (permalink / raw)
To: Stephen Hemminger
Cc: David S. Miller, Herbert Xu, Eric Dumazet, Jiri Pirko, bridge,
netdev, linux-kernel
In-Reply-To: <20101018093837.26bb149a@nehalam>
Make all frames sent to reserved group MAC addresses (01:80:c2:00:00:00 to
01:80:c2:00:00:0f) be forwarded if STP is disabled. This enables
forwarding EAPOL frames, among other things.
Signed-off-by: Benjamin Poirier <benjamin.poirier@polymtl.ca>
---
net/bridge/br_input.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bridge/br_input.c b/net/bridge/br_input.c
index 826cd52..436488c 100644
--- a/net/bridge/br_input.c
+++ b/net/bridge/br_input.c
@@ -159,7 +159,7 @@ struct sk_buff *br_handle_frame(struct sk_buff *skb)
goto drop;
/* If STP is turned off, then forward */
- if (p->br->stp_enabled == BR_NO_STP && dest[5] == 0)
+ if (p->br->stp_enabled == BR_NO_STP)
goto forward;
if (NF_HOOK(NFPROTO_BRIDGE, NF_BR_LOCAL_IN, skb, skb->dev,
--
1.7.1
^ permalink raw reply related
* [PATCH net-next] bnx2: Increase max rx ring size from 1K to 2K
From: Michael Chan @ 2010-10-19 0:30 UTC (permalink / raw)
To: davem; +Cc: andy, jfeeney, netdev
A number of customers are reporting packet loss under certain workloads
(e.g. heavy bursts of small packets) with flow control disabled. A larger
rx ring helps to prevent these losses.
No change in default rx ring size and memory consumption.
Signed-off-by: Andy Gospodarek <andy@greyhouse.net>
Acked-by: John Feeney <jfeeney@redhat.com>
Signed-off-by: Michael Chan <mchan@broadcom.com>
---
drivers/net/bnx2.h | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/net/bnx2.h b/drivers/net/bnx2.h
index efdfbc2..62ac83e 100644
--- a/drivers/net/bnx2.h
+++ b/drivers/net/bnx2.h
@@ -6502,8 +6502,8 @@ struct l2_fhdr {
#define TX_DESC_CNT (BCM_PAGE_SIZE / sizeof(struct tx_bd))
#define MAX_TX_DESC_CNT (TX_DESC_CNT - 1)
-#define MAX_RX_RINGS 4
-#define MAX_RX_PG_RINGS 16
+#define MAX_RX_RINGS 8
+#define MAX_RX_PG_RINGS 32
#define RX_DESC_CNT (BCM_PAGE_SIZE / sizeof(struct rx_bd))
#define MAX_RX_DESC_CNT (RX_DESC_CNT - 1)
#define MAX_TOTAL_RX_DESC_CNT (MAX_RX_DESC_CNT * MAX_RX_RINGS)
--
1.6.4.GIT
^ permalink raw reply related
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