* Re: [PATCH v2] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Changli Gao @ 2010-09-22 9:24 UTC (permalink / raw)
To: David Miller; +Cc: mst, eric.dumazet, socketcan, netdev
In-Reply-To: <20100914.202023.193706826.davem@davemloft.net>
On Wed, Sep 15, 2010 at 11:20 AM, David Miller <davem@davemloft.net> wrote:
>
>
> Changli, I have one other minor request, please name this something
> like "shinfo->data_destructor" and "shinfo->data_destructor_arg".
>
> I think that will make it easier for other humans to understand :)
>
OK. Thanks.
But there is another issue, when splice() is involved. If we splice
the skbs generated by AF_PACKET socket to a pipe, the fragment pages
will be hold by the pipe, but the skbs are freed, and AF_PACKET socket
will been told that the corresponding TX ring buffers are available
for the other uses wrongly.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH v2] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Changli Gao @ 2010-09-22 9:35 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, eric.dumazet, socketcan, netdev
In-Reply-To: <20100915052332.GB25340@redhat.com>
On Wed, Sep 15, 2010 at 1:23 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
>
> Hmm, and there's another issue I think I see here:
> destructor_arg now points to a socket.
> What happens if the skb gets queued on an interface for a very long time
> (as can be the case with e.g. tap), and meanwhile
> you try to kill the task that owns the socket, which
> will try to destroy the socket?
>
> Original code handles this by relevant devices orphaning an skb
> if it's queued indefinitely.
>
I don't think the skb_orphan() there is used to destroy the socket in
time, but notify the socket that skbs are sent out and it can send new
skbs.
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* Re: [PATCH 1/5] ptp: Added a brand new class driver for ptp clocks.
From: Richard Cochran @ 2010-09-22 10:14 UTC (permalink / raw)
To: Kyle Moffett
Cc: Rodolfo Giometti, John Stultz,
devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
netdev-u79uwXL29TY76Z2rM5mHXA,
linuxppc-dev-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r,
Krzysztof Halasa
In-Reply-To: <AANLkTinRM3_kBc5S3wV=_S6P8+x7A43kz0qSYbixJYnq-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Tue, Sep 21, 2010 at 04:47:45PM -0400, Kyle Moffett wrote:
> Well how about something much more straightforward:
I am about to post another patch set for discussion, so please comment
on it when it appears.
Thanks,
Richard
^ permalink raw reply
* Re: [PATCH] netfilter: don't disable BH again in BH disabled context
From: Changli Gao @ 2010-09-22 10:20 UTC (permalink / raw)
To: Eric Dumazet; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <1282028127.2487.754.camel@edumazet-laptop>
On Tue, Aug 17, 2010 at 2:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
>
> Its a thing that might change in a future version. Not a hard fact.
>
> You can probably change iptables to allow softirqs while processing
> OUTPUT chains.
>
> We had some attempts in the past to switch to RCU.
>
> It failed at that time because of some RCU implementation details, but
> with recent RCU changes, we might try again, and have a clean
> implementation, allowing softirqs.
>
> So your patch would need to be reverted.
>
So the smp_processor_id() in xt_cpu.c should be replaced with
raw_smp_processor_id()?
--
Regards,
Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* [net-next] stmmac: review the wake-up support
From: Giuseppe CAVALLARO @ 2010-09-22 10:38 UTC (permalink / raw)
To: netdev; +Cc: Giuseppe Cavallaro
If the PM support is available this is passed
through the platform instead to be hard-coded
in the core files.
WoL on Magic Frame can be enabled by using
the ethtool support.
Signed-off-by: Giuseppe Cavallaro <peppe.cavallaro@st.com>
---
drivers/net/stmmac/common.h | 1 -
drivers/net/stmmac/dwmac1000_core.c | 1 -
drivers/net/stmmac/dwmac100_core.c | 1 -
drivers/net/stmmac/stmmac_ethtool.c | 14 +++++++++-----
drivers/net/stmmac/stmmac_main.c | 26 ++++++++++++++------------
include/linux/stmmac.h | 1 +
6 files changed, 24 insertions(+), 20 deletions(-)
diff --git a/drivers/net/stmmac/common.h b/drivers/net/stmmac/common.h
index 673ef86..dec7ce4 100644
--- a/drivers/net/stmmac/common.h
+++ b/drivers/net/stmmac/common.h
@@ -238,7 +238,6 @@ struct mac_device_info {
struct stmmac_ops *mac;
struct stmmac_desc_ops *desc;
struct stmmac_dma_ops *dma;
- unsigned int pmt; /* support Power-Down */
struct mii_regs mii; /* MII register Addresses */
struct mac_link link;
};
diff --git a/drivers/net/stmmac/dwmac1000_core.c b/drivers/net/stmmac/dwmac1000_core.c
index c18c859..65667b6 100644
--- a/drivers/net/stmmac/dwmac1000_core.c
+++ b/drivers/net/stmmac/dwmac1000_core.c
@@ -239,7 +239,6 @@ struct mac_device_info *dwmac1000_setup(void __iomem *ioaddr)
mac->mac = &dwmac1000_ops;
mac->dma = &dwmac1000_dma_ops;
- mac->pmt = PMT_SUPPORTED;
mac->link.port = GMAC_CONTROL_PS;
mac->link.duplex = GMAC_CONTROL_DM;
mac->link.speed = GMAC_CONTROL_FES;
diff --git a/drivers/net/stmmac/dwmac100_core.c b/drivers/net/stmmac/dwmac100_core.c
index 58a914b..94eeccf 100644
--- a/drivers/net/stmmac/dwmac100_core.c
+++ b/drivers/net/stmmac/dwmac100_core.c
@@ -193,7 +193,6 @@ struct mac_device_info *dwmac100_setup(void __iomem *ioaddr)
mac->mac = &dwmac100_ops;
mac->dma = &dwmac100_dma_ops;
- mac->pmt = PMT_NOT_SUPPORTED;
mac->link.port = MAC_CONTROL_PS;
mac->link.duplex = MAC_CONTROL_F;
mac->link.speed = 0;
diff --git a/drivers/net/stmmac/stmmac_ethtool.c b/drivers/net/stmmac/stmmac_ethtool.c
index b32c16a..25a7e38 100644
--- a/drivers/net/stmmac/stmmac_ethtool.c
+++ b/drivers/net/stmmac/stmmac_ethtool.c
@@ -322,7 +322,7 @@ static void stmmac_get_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
struct stmmac_priv *priv = netdev_priv(dev);
spin_lock_irq(&priv->lock);
- if (priv->wolenabled == PMT_SUPPORTED) {
+ if (device_can_wakeup(priv->device)) {
wol->supported = WAKE_MAGIC;
wol->wolopts = priv->wolopts;
}
@@ -334,16 +334,20 @@ static int stmmac_set_wol(struct net_device *dev, struct ethtool_wolinfo *wol)
struct stmmac_priv *priv = netdev_priv(dev);
u32 support = WAKE_MAGIC;
- if (priv->wolenabled == PMT_NOT_SUPPORTED)
+ if (!device_can_wakeup(priv->device))
return -EINVAL;
if (wol->wolopts & ~support)
return -EINVAL;
- if (wol->wolopts == 0)
- device_set_wakeup_enable(priv->device, 0);
- else
+ if (wol->wolopts) {
+ pr_info("stmmac: wakeup enable\n");
device_set_wakeup_enable(priv->device, 1);
+ enable_irq_wake(dev->irq);
+ } else {
+ device_set_wakeup_enable(priv->device, 0);
+ disable_irq_wake(dev->irq);
+ }
spin_lock_irq(&priv->lock);
priv->wolopts = wol->wolopts;
diff --git a/drivers/net/stmmac/stmmac_main.c b/drivers/net/stmmac/stmmac_main.c
index a908f72..823b9e6 100644
--- a/drivers/net/stmmac/stmmac_main.c
+++ b/drivers/net/stmmac/stmmac_main.c
@@ -1568,9 +1568,8 @@ static int stmmac_mac_device_setup(struct net_device *dev)
priv->hw = device;
- priv->wolenabled = priv->hw->pmt; /* PMT supported */
- if (priv->wolenabled == PMT_SUPPORTED)
- priv->wolopts = WAKE_MAGIC; /* Magic Frame */
+ if (device_can_wakeup(priv->device))
+ priv->wolopts = WAKE_MAGIC; /* Magic Frame as default */
return 0;
}
@@ -1709,6 +1708,12 @@ static int stmmac_dvr_probe(struct platform_device *pdev)
priv->enh_desc = plat_dat->enh_desc;
priv->ioaddr = addr;
+ /* PMT module is not integrated in all the MAC devices. */
+ if (plat_dat->pmt) {
+ pr_info("\tPMT module supported\n");
+ device_set_wakeup_capable(&pdev->dev, 1);
+ }
+
platform_set_drvdata(pdev, ndev);
/* Set the I/O base addr */
@@ -1836,13 +1841,11 @@ static int stmmac_suspend(struct platform_device *pdev, pm_message_t state)
stmmac_mac_disable_tx(priv->ioaddr);
- if (device_may_wakeup(&(pdev->dev))) {
- /* Enable Power down mode by programming the PMT regs */
- if (priv->wolenabled == PMT_SUPPORTED)
- priv->hw->mac->pmt(priv->ioaddr, priv->wolopts);
- } else {
+ /* Enable Power down mode by programming the PMT regs */
+ if (device_can_wakeup(priv->device))
+ priv->hw->mac->pmt(priv->ioaddr, priv->wolopts);
+ else
stmmac_mac_disable_rx(priv->ioaddr);
- }
} else {
priv->shutdown = 1;
/* Although this can appear slightly redundant it actually
@@ -1877,9 +1880,8 @@ static int stmmac_resume(struct platform_device *pdev)
* is received. Anyway, it's better to manually clear
* this bit because it can generate problems while resuming
* from another devices (e.g. serial console). */
- if (device_may_wakeup(&(pdev->dev)))
- if (priv->wolenabled == PMT_SUPPORTED)
- priv->hw->mac->pmt(priv->ioaddr, 0);
+ if (device_can_wakeup(priv->device))
+ priv->hw->mac->pmt(priv->ioaddr, 0);
netif_device_attach(dev);
diff --git a/include/linux/stmmac.h b/include/linux/stmmac.h
index 1d8baf7..d66c617 100644
--- a/include/linux/stmmac.h
+++ b/include/linux/stmmac.h
@@ -37,6 +37,7 @@ struct plat_stmmacenet_data {
int enh_desc;
int tx_coe;
int bugged_jumbo;
+ int pmt;
void (*fix_mac_speed)(void *priv, unsigned int speed);
void (*bus_setup)(void __iomem *ioaddr);
#ifdef CONFIG_STM_DRIVERS
--
1.5.5.6
^ permalink raw reply related
* Re: [PATCH v2] net: af_packet: don't call tpacket_destruct_skb() until the skb is sent out
From: Michael S. Tsirkin @ 2010-09-22 10:59 UTC (permalink / raw)
To: Changli Gao; +Cc: David Miller, eric.dumazet, socketcan, netdev
In-Reply-To: <AANLkTi=iYahjwZt5w53xFsU7fyHr72wXHd9tycwUiNE9@mail.gmail.com>
On Wed, Sep 22, 2010 at 05:35:07PM +0800, Changli Gao wrote:
> On Wed, Sep 15, 2010 at 1:23 PM, Michael S. Tsirkin <mst@redhat.com> wrote:
> >
> > Hmm, and there's another issue I think I see here:
> > destructor_arg now points to a socket.
> > What happens if the skb gets queued on an interface for a very long time
> > (as can be the case with e.g. tap), and meanwhile
> > you try to kill the task that owns the socket, which
> > will try to destroy the socket?
> >
> > Original code handles this by relevant devices orphaning an skb
> > if it's queued indefinitely.
> >
>
> I don't think the skb_orphan() there is used to destroy the socket in
> time, but notify the socket that skbs are sent out and it can send new
> skbs.
Well, the result is that we drop a socket reference from the skb,
so it becomes possible to free the socket.
> --
> Regards,
> Changli Gao(xiaosuo@gmail.com)
^ permalink raw reply
* RE: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
From: Xin, Xiaohui @ 2010-09-22 11:41 UTC (permalink / raw)
To: Michael S. Tsirkin
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <20100921131421.GA10439@redhat.com>
>-----Original Message-----
>From: Michael S. Tsirkin [mailto:mst@redhat.com]
>Sent: Tuesday, September 21, 2010 9:14 PM
>To: Xin, Xiaohui
>Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>jdike@linux.intel.com
>Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>
>On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
>> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
>> >Sent: Monday, September 20, 2010 7:37 PM
>> >To: Xin, Xiaohui
>> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
>> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
>> >jdike@linux.intel.com
>> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
>> >
>> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
>> >> From: Xin Xiaohui <xiaohui.xin@intel.com>
>> >>
>> >> ---
>> >> Michael,
>> >> I have move the ioctl to configure the locked memory to vhost
>> >
>> >It's ok to move this to vhost but vhost does not
>> >know how much memory is needed by the backend.
>>
>> I think the backend here you mean is mp device.
>> Actually, the memory needed is related to vq->num to run zero-copy
>> smoothly.
>> That means mp device did not know it but vhost did.
>
>Well, this might be so if you insist on locking
>all posted buffers immediately. However, let's assume I have a
>very large ring and prepost a ton of RX buffers:
>there's no need to lock all of them directly:
>
>if we have buffers A and B, we can lock A, pass it
>to hardware, and when A is consumed unlock A, lock B
>and pass it to hardware.
>
>
>It's not really critical. But note we can always have userspace
>tell MP device all it wants to know, after all.
>
Ok. Here are two values we have mentioned, one is how much memory
user application wants to lock, and one is how much memory locked
is needed to run smoothly. When net backend is setup, we first need
an ioctl to get how much memory is needed to lock, and then we call
another ioctl to set how much it want to lock. Is that what's in your mind?
>> And the rlimt stuff is per process, we use current pointer to set
>> and check the rlimit, the operations should be in the same process.
>
>Well no, the ring is handled from the kernel thread: we switch the mm to
>point to the owner task so copy from/to user and friends work, but you
>can't access the rlimit etc.
>
Yes, the userspace and vhost kernel is not the same process. But we can
record the task pointer as mm.
>> Now the check operations are in vhost process, as mp_recvmsg() or
>> mp_sendmsg() are called by vhost.
>
>Hmm, what do you mean by the check operations?
>send/recv are data path operations, they shouldn't
>do any checks, should they?
>
As you mentioned what infiniband driver done:
down_write(¤t->mm->mmap_sem);
locked = npages + current->mm->locked_vm;
lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
if ((locked > lock_limit) && !capable(CAP_IPC_LOCK)) {
ret = -ENOMEM;
goto out;
}
cur_base = addr & PAGE_MASK;
ret = 0;
while (npages) {
ret = get_user_pages(current, current->mm, cur_base,
min_t(unsigned long, npages,
PAGE_SIZE / sizeof (struct page *)),
1, !umem->writable, page_list, vma_list);
I think it's a data path too. We do the check because get_user_pages() really pin and locked
the memory.
>> So set operations should be in
>> vhost process too, it's natural.
>>
>> >So I think we'll need another ioctl in the backend
>> >to tell userspace how much memory is needed?
>> >
>> Except vhost tells it to mp device, mp did not know
>> how much memory is needed to run zero-copy smoothly.
>> Is userspace interested about the memory mp is needed?
>
>Couldn't parse this last question.
>I think userspace generally does want control over
>how much memory we'll lock. We should not just lock
>as much as we can.
>
>--
>MST
^ permalink raw reply
* Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
From: Michael S. Tsirkin @ 2010-09-22 11:55 UTC (permalink / raw)
To: Xin, Xiaohui
Cc: netdev@vger.kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, mingo@elte.hu, davem@davemloft.net,
herbert@gondor.hengli.com.au, jdike@linux.intel.com
In-Reply-To: <F2E9EB7348B8264F86B6AB8151CE2D792D171853DF@shsmsx502.ccr.corp.intel.com>
On Wed, Sep 22, 2010 at 07:41:36PM +0800, Xin, Xiaohui wrote:
> >-----Original Message-----
> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >Sent: Tuesday, September 21, 2010 9:14 PM
> >To: Xin, Xiaohui
> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
> >jdike@linux.intel.com
> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
> >
> >On Tue, Sep 21, 2010 at 09:39:31AM +0800, Xin, Xiaohui wrote:
> >> >From: Michael S. Tsirkin [mailto:mst@redhat.com]
> >> >Sent: Monday, September 20, 2010 7:37 PM
> >> >To: Xin, Xiaohui
> >> >Cc: netdev@vger.kernel.org; kvm@vger.kernel.org; linux-kernel@vger.kernel.org;
> >> >mingo@elte.hu; davem@davemloft.net; herbert@gondor.hengli.com.au;
> >> >jdike@linux.intel.com
> >> >Subject: Re: [RFC PATCH v9 12/16] Add mp(mediate passthru) device.
> >> >
> >> >On Mon, Sep 20, 2010 at 04:08:48PM +0800, xiaohui.xin@intel.com wrote:
> >> >> From: Xin Xiaohui <xiaohui.xin@intel.com>
> >> >>
> >> >> ---
> >> >> Michael,
> >> >> I have move the ioctl to configure the locked memory to vhost
> >> >
> >> >It's ok to move this to vhost but vhost does not
> >> >know how much memory is needed by the backend.
> >>
> >> I think the backend here you mean is mp device.
> >> Actually, the memory needed is related to vq->num to run zero-copy
> >> smoothly.
> >> That means mp device did not know it but vhost did.
> >
> >Well, this might be so if you insist on locking
> >all posted buffers immediately. However, let's assume I have a
> >very large ring and prepost a ton of RX buffers:
> >there's no need to lock all of them directly:
> >
> >if we have buffers A and B, we can lock A, pass it
> >to hardware, and when A is consumed unlock A, lock B
> >and pass it to hardware.
> >
> >
> >It's not really critical. But note we can always have userspace
> >tell MP device all it wants to know, after all.
> >
> Ok. Here are two values we have mentioned, one is how much memory
> user application wants to lock, and one is how much memory locked
> is needed to run smoothly. When net backend is setup, we first need
> an ioctl to get how much memory is needed to lock, and then we call
> another ioctl to set how much it want to lock. Is that what's in your mind?
That's fine.
> >> And the rlimt stuff is per process, we use current pointer to set
> >> and check the rlimit, the operations should be in the same process.
> >
> >Well no, the ring is handled from the kernel thread: we switch the mm to
> >point to the owner task so copy from/to user and friends work, but you
> >can't access the rlimit etc.
> >
> Yes, the userspace and vhost kernel is not the same process. But we can
> record the task pointer as mm.
So you will have to store mm and do device->mm, not current->mm.
Anyway, better not touch mm on data path.
> >> Now the check operations are in vhost process, as mp_recvmsg() or
> >> mp_sendmsg() are called by vhost.
> >
> >Hmm, what do you mean by the check operations?
> >send/recv are data path operations, they shouldn't
> >do any checks, should they?
> >
> As you mentioned what infiniband driver done:
> down_write(¤t->mm->mmap_sem);
>
> locked = npages + current->mm->locked_vm;
> lock_limit = rlimit(RLIMIT_MEMLOCK) >> PAGE_SHIFT;
>
> if ((locked > lock_limit) && !capable(CAP_IPC_LOCK)) {
> ret = -ENOMEM;
> goto out;
> }
>
> cur_base = addr & PAGE_MASK;
>
> ret = 0;
> while (npages) {
> ret = get_user_pages(current, current->mm, cur_base,
> min_t(unsigned long, npages,
> PAGE_SIZE / sizeof (struct page *)),
> 1, !umem->writable, page_list, vma_list);
>
> I think it's a data path too.
in infiniband this is used to 'register memory' which is not data path.
> We do the check because get_user_pages() really pin and locked
> the memory.
Don't do this. Performance will be bad.
Do the check once in ioctl and increment locked_vm by max amount you will use.
On data path just make sure you do not exceed what userspace told you
to.
>
> >> So set operations should be in
> >> vhost process too, it's natural.
> >>
> >> >So I think we'll need another ioctl in the backend
> >> >to tell userspace how much memory is needed?
> >> >
> >> Except vhost tells it to mp device, mp did not know
> >> how much memory is needed to run zero-copy smoothly.
> >> Is userspace interested about the memory mp is needed?
> >
> >Couldn't parse this last question.
> >I think userspace generally does want control over
> >how much memory we'll lock. We should not just lock
> >as much as we can.
> >
> >--
> >MST
^ permalink raw reply
* Re: [PATCH v4 0/2] Get and Set Feature Reports on HIDRAW (USB and Bluetooth)
From: Jiri Kosina @ 2010-09-22 12:09 UTC (permalink / raw)
To: Alan Ott, Marcel Holtmann, David S. Miller
Cc: Stefan Achatz, Antonio Ospite, Alexey Dobriyan, Tejun Heo,
Alan Stern, Greg Kroah-Hartman, Stephane Chatty, Michael Poole,
Bastien Nocera, Eric Dumazet, linux-input, linux-kernel,
linux-usb, linux-bluetooth, netdev
In-Reply-To: <alpine.LNX.2.00.1009021724480.26813@pobox.suse.cz>
On Thu, 2 Sep 2010, Jiri Kosina wrote:
> > > This is version 4. Built against 2.6.35+ revision 320b2b8de12698 .
> > >
> > > Alan Ott (2):
> > > HID: Add Support for Setting and Getting Feature Reports from hidraw
> > > Bluetooth: hidp: Add support for hidraw HIDIOCGFEATURE and
> > > HIDIOCSFEATURE
> > >
> > > drivers/hid/hidraw.c | 105 ++++++++++++++++++++++++++++++++++++--
> > > drivers/hid/usbhid/hid-core.c | 37 +++++++++++++-
> > > include/linux/hid.h | 3 +
> > > include/linux/hidraw.h | 3 +
> > > net/bluetooth/hidp/core.c | 114 +++++++++++++++++++++++++++++++++++++++--
> > > net/bluetooth/hidp/hidp.h | 8 +++
> > > 6 files changed, 260 insertions(+), 10 deletions(-)
> >
> > Marcel, as per our previous discussion -- what is your word on this? I'd
> > be glad taking it once you Ack the bluetooth bits (which, as far as I
> > understood from your last mail, don't have strong objections against any
> > more).
>
> ... Marcel?
>
> I'd really like not to miss 2.6.37 merge window with this.
Seemingly I have not enought powers to get statement from Marcel here
these days/weeks.
Davem, would you perhaps be able to step in here?
Thanks,
--
Jiri Kosina
SUSE Labs, Novell Inc.
^ permalink raw reply
* linux/netpoll.h:67 invoked rcu_dereference warning at boot
From: Andi Kleen @ 2010-09-22 13:20 UTC (permalink / raw)
To: netdev
When booting a recent Linus tree with debugging enabled I get
the following warning at boot.
I haven't looked into it closely.
-Andi
===================================================
[ INFO: suspicious rcu_dereference_check() usage. ]
---------------------------------------------------
/home/lsrc/git/linux-work2/include/linux/netpoll.h:67 invoked rcu_dereferenceeck() without protection!
other info that might help us debug this:
rcu_scheduler_active = 1, debug_locks = 1
1 lock held by iceccd/2574:
#0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff81721bf9>] udp_sendmsg+0x289/00
stack backtrace:
Pid: 2574, comm: iceccd Not tainted 2.6.36-rc4-00228-g5647824 #1
Call Trace:
[<ffffffff81090a24>] lockdep_rcu_dereference+0xa4/0xc0
[<ffffffff816d3475>] netif_rx+0x215/0x240
[<ffffffff81135fbf>] ? cache_alloc_debugcheck_after+0x5f/0x280
[<ffffffff8104cc61>] ? get_parent_ip+0x11/0x50
[<ffffffff816d36b3>] netif_rx_ni+0x23/0x80
[<ffffffff816fd3f3>] ip_dev_loopback_xmit+0x83/0xf0
[<ffffffff816fddfa>] ip_mc_output+0x18a/0x220
[<ffffffff816fd53d>] ip_local_out+0x2d/0x80
[<ffffffff816ff414>] ip_push_pending_frames+0x284/0x420
[<ffffffff81720586>] udp_push_pending_frames+0x146/0x3e0
[<ffffffff81721bf9>] ? udp_sendmsg+0x289/0x720
[<ffffffff81721de4>] udp_sendmsg+0x474/0x720
[<ffffffff8105ec82>] ? local_bh_enable_ip+0x82/0x100
[<ffffffff8172aee4>] inet_sendmsg+0xc4/0x160
[<ffffffff8172ae20>] ? inet_sendmsg+0x0/0x160
[<ffffffff816bddd0>] sock_sendmsg+0xc0/0xf0
[<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
[<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
[<ffffffff8110e083>] ? might_fault+0xc3/0xd0
[<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
[<ffffffff816bfe80>] ? move_addr_to_kernel+0x50/0x60
[<ffffffff816c0ba5>] sys_sendto+0xf5/0x130
[<ffffffff8100311b>] system_call_fastpath+0x16/0x1b
--
ak@linux.intel.com -- Speaking for myself only.
^ permalink raw reply
* Re: [PATCH] netfilter: don't disable BH again in BH disabled context
From: Eric Dumazet @ 2010-09-22 13:22 UTC (permalink / raw)
To: Changli Gao; +Cc: Patrick McHardy, David S. Miller, netfilter-devel, netdev
In-Reply-To: <AANLkTi=r23zwZpO=Y++a608=K6f7-FvcL2d-gY+foggm@mail.gmail.com>
Le mercredi 22 septembre 2010 à 18:20 +0800, Changli Gao a écrit :
> On Tue, Aug 17, 2010 at 2:55 PM, Eric Dumazet <eric.dumazet@gmail.com> wrote:
> >
> > Its a thing that might change in a future version. Not a hard fact.
> >
> > You can probably change iptables to allow softirqs while processing
> > OUTPUT chains.
> >
> > We had some attempts in the past to switch to RCU.
> >
> > It failed at that time because of some RCU implementation details, but
> > with recent RCU changes, we might try again, and have a clean
> > implementation, allowing softirqs.
> >
> > So your patch would need to be reverted.
> >
>
> So the smp_processor_id() in xt_cpu.c should be replaced with
> raw_smp_processor_id()?
>
Using smp_processor_id() is better. This provides automatic checking.
If we change output processing to allow softirqs, that doesnt mean we
allow preemption or cpu migration :)
--
To unsubscribe from this list: send the line "unsubscribe netfilter-devel" 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
* Re: linux/netpoll.h:67 invoked rcu_dereference warning at boot
From: Eric Dumazet @ 2010-09-22 13:30 UTC (permalink / raw)
To: Andi Kleen; +Cc: netdev
In-Reply-To: <20100922132014.GA8853@basil.fritz.box>
Le mercredi 22 septembre 2010 à 15:20 +0200, Andi Kleen a écrit :
> When booting a recent Linus tree with debugging enabled I get
> the following warning at boot.
>
> I haven't looked into it closely.
>
> -Andi
>
> ===================================================
> [ INFO: suspicious rcu_dereference_check() usage. ]
> ---------------------------------------------------
> /home/lsrc/git/linux-work2/include/linux/netpoll.h:67 invoked rcu_dereferenceeck() without protection!
>
> other info that might help us debug this:
>
>
> rcu_scheduler_active = 1, debug_locks = 1
> 1 lock held by iceccd/2574:
> #0: (sk_lock-AF_INET){+.+.+.}, at: [<ffffffff81721bf9>] udp_sendmsg+0x289/00
>
> stack backtrace:
> Pid: 2574, comm: iceccd Not tainted 2.6.36-rc4-00228-g5647824 #1
> Call Trace:
> [<ffffffff81090a24>] lockdep_rcu_dereference+0xa4/0xc0
> [<ffffffff816d3475>] netif_rx+0x215/0x240
> [<ffffffff81135fbf>] ? cache_alloc_debugcheck_after+0x5f/0x280
> [<ffffffff8104cc61>] ? get_parent_ip+0x11/0x50
> [<ffffffff816d36b3>] netif_rx_ni+0x23/0x80
> [<ffffffff816fd3f3>] ip_dev_loopback_xmit+0x83/0xf0
> [<ffffffff816fddfa>] ip_mc_output+0x18a/0x220
> [<ffffffff816fd53d>] ip_local_out+0x2d/0x80
> [<ffffffff816ff414>] ip_push_pending_frames+0x284/0x420
> [<ffffffff81720586>] udp_push_pending_frames+0x146/0x3e0
> [<ffffffff81721bf9>] ? udp_sendmsg+0x289/0x720
> [<ffffffff81721de4>] udp_sendmsg+0x474/0x720
> [<ffffffff8105ec82>] ? local_bh_enable_ip+0x82/0x100
> [<ffffffff8172aee4>] inet_sendmsg+0xc4/0x160
> [<ffffffff8172ae20>] ? inet_sendmsg+0x0/0x160
> [<ffffffff816bddd0>] sock_sendmsg+0xc0/0xf0
> [<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
> [<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
> [<ffffffff8110e083>] ? might_fault+0xc3/0xd0
> [<ffffffff8110e03a>] ? might_fault+0x7a/0xd0
> [<ffffffff816bfe80>] ? move_addr_to_kernel+0x50/0x60
> [<ffffffff816c0ba5>] sys_sendto+0xf5/0x130
> [<ffffffff8100311b>] system_call_fastpath+0x16/0x1b
>
>
Thanks Andi
I believe I sent a patch this morning
http://lkml.org/lkml/2010/9/22/35
^ permalink raw reply
* Re: [PATCH net-next-2.6 0/8] sfc and ethtool changes for 2.6.37
From: Ben Hutchings @ 2010-09-22 15:27 UTC (permalink / raw)
To: David Miller; +Cc: netdev, linux-net-drivers
In-Reply-To: <20100921.162326.226765001.davem@davemloft.net>
On Tue, 2010-09-21 at 16:23 -0700, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 21 Sep 2010 14:58:27 -0700 (PDT)
>
> > From: Ben Hutchings <bhutchings@solarflare.com>
> > Date: Mon, 20 Sep 2010 19:40:56 +0100
> >
> >> This series adds Ethernet-level filtering and explicit filter clearing
> >> to the ethtool RX n-tuple interface, and implements it in the sfc
> >> driver.
> >>
> >> There is a cleanup patch on the end which is preparation for the
> >> following RFC patch series but is worthwhile anyway.
> >>
> >> Ben Hutchings (8):
> >> ethtool: Define RX n-tuple action to clear a rule
> >> ethtool: Add Ethernet MAC-level filtering/steering
> >> ethtool: Allocate register dump buffer with vmalloc()
> >> sfc: Add filter table management
> >> sfc: Implement the ethtool RX n-tuple control functions
> >> sfc: Include RX IP filter table in register dump
> >> sfc: Set net_device::num_rx_queues once we know the correct value
> >> sfc: Clean up and correct comments on efx_monitor()
> >
> > All applied except patch #7 as noted in the thread for that patch.
>
> Ben, just FYI, I had to add "linux/vmalloc.h" includes to both
> net/core/ethtool.c and drivers/net/sfc/net_driver.h otherwise
> the build breaks on some architectures.
>
> x86 can be a really bad arch to validates builds on because it
> currently gets vmalloc.h implicitly by some of it's core header files.
>
> In particular, asm/io.h :-/
Thanks, and sorry for missing this. We have some SPARC systems that I
could potentially test on but I think they're limited to running
Solaris.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6 7/8] sfc: Set net_device::num_rx_queues once we know the correct value
From: Ben Hutchings @ 2010-09-22 15:28 UTC (permalink / raw)
To: David Miller; +Cc: eric.dumazet, netdev, linux-net-drivers
In-Reply-To: <20100921.183834.70182767.davem@davemloft.net>
On Tue, 2010-09-21 at 18:38 -0700, David Miller wrote:
> From: Ben Hutchings <bhutchings@solarflare.com>
> Date: Wed, 22 Sep 2010 02:31:36 +0100
>
> > Right, but we do need to have some way for drivers to specify the actual
> > number of RX queues.
>
> Ok, the problem stems merely from the fact that we only specify one
> "queue count" in alloc_netdev_mq(). We should specify two, one for
> TX and one for RX.
>
> So why not fix that instead of putting hacks into the drivers? :-)
That still doesn't solve the original problem, since drivers generally
won't know how many RX queues they should (or can) create until some
time after calling alloc_netdev_mq().
You know very well why we distinguish real_num_tx_queues and
num_tx_queues; what's so different about RX queues?
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [PATCH net-next-2.6 7/8] sfc: Set net_device::num_rx_queues once we know the correct value
From: Eric Dumazet @ 2010-09-22 15:44 UTC (permalink / raw)
To: Ben Hutchings; +Cc: David Miller, netdev, linux-net-drivers
In-Reply-To: <1285169327.2279.3.camel@achroite.uk.solarflarecom.com>
Le mercredi 22 septembre 2010 à 16:28 +0100, Ben Hutchings a écrit :
>
> That still doesn't solve the original problem, since drivers generally
> won't know how many RX queues they should (or can) create until some
> time after calling alloc_netdev_mq().
>
> You know very well why we distinguish real_num_tx_queues and
> num_tx_queues; what's so different about RX queues?
rx queues were added by Tom for RPS.
No function prototypes were changed to provide it as a new parameter.
What we need is to extend alloc_netdev_mq() to take a new rx_queue_count
parameter.
Then allow these txq/rxq parameters to be "unset for the moment", and
provide a new function to allocate / populate queues when driver knows
what to do, _after_ its alloc_netdev_mq() call.
Your one line patch is a work around, not a clean solution.
^ permalink raw reply
* Re: [PATCH] Move "struct net" declaration inside the __KERNEL__ macro guard
From: Ollie Wild @ 2010-09-22 15:54 UTC (permalink / raw)
To: David Miller; +Cc: linux-kernel, netdev, akpm, davem
In-Reply-To: <20100917.165120.139548355.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 437 bytes --]
On Fri, Sep 17, 2010 at 6:51 PM, David Miller <davem@davemloft.net> wrote:
>
> From: Ollie Wild <aaw@google.com>
> Date: Fri, 17 Sep 2010 14:38:59 -0500
>
> > (Resending with a proper signoff.)
>
> Your patch is still unusable because your email client white-space mangled
> the patch, turning tabs into space characters.
>
> Please fix this up and resubmit, thanks.
Third time's a charm ...
Signed-off-by: Ollie Wild <aaw@google.com>
[-- Attachment #2: netlink.txt --]
[-- Type: text/plain, Size: 1037 bytes --]
commit 27fb1ec3fe29978ca7f195aac5dbda6f301c7c24
Author: Ollie Wild <aaw@google.com>
Date: Fri Aug 13 14:21:44 2010 -0500
Move "struct net" declaration inside the __KERNEL__ macro guard.
This patch reduces namespace pollution by moving the "struct net" declaration
out of the userspace-facing portion of linux/netlink.h. It has no impact on
the kernel.
(This came up because we have several C++ applications which use "net" as a
namespace name.)
Ollie
diff --git a/include/linux/netlink.h b/include/linux/netlink.h
index 59d0669..1235669 100644
--- a/include/linux/netlink.h
+++ b/include/linux/netlink.h
@@ -27,8 +27,6 @@
#define MAX_LINKS 32
-struct net;
-
struct sockaddr_nl {
sa_family_t nl_family; /* AF_NETLINK */
unsigned short nl_pad; /* zero */
@@ -151,6 +149,8 @@ struct nlattr {
#include <linux/capability.h>
#include <linux/skbuff.h>
+struct net;
+
static inline struct nlmsghdr *nlmsg_hdr(const struct sk_buff *skb)
{
return (struct nlmsghdr *)skb->data;
^ permalink raw reply related
* Re: [RFC][PATCH 1/4] IRQ: IRQ groups for multiqueue devices
From: Ben Hutchings @ 2010-09-22 16:00 UTC (permalink / raw)
To: Thomas Gleixner
Cc: Tom Herbert, netdev, linux-net-drivers, linux-kernel,
Peter Zijlstra, Ingo Molnar
In-Reply-To: <alpine.LFD.2.00.1009211827440.2416@localhost6.localdomain6>
On Tue, 2010-09-21 at 21:04 +0200, Thomas Gleixner wrote:
[...]
> Talked to Peter about it and we came to the conclusion, that we should
> just provide a callback infrastructure in the irq code which does not
> care about the action behind it. That's going to solve #1,#2,#3,#5,#6
> and parts of #8
>
> That queue/index map code should move to lib/ or some other
> appropriate place so it can be shared with storage or whatever is
> going to grow multiqueue. comments #4, #7, #8 (s@kernel/irq@lib/@)
> above still apply :)
OK.
> The modification to the genirq code would be based on registering
>
> struct irq_affinity_callback {
> unsigned int irq;
> struct kref kref;
> struct work work;
> void (*callback)(struct irq_affinity_callback *, const cpumask_t *mask);
> void (*release)(struct kref *ref);
> };
>
> for an interrupt via
>
> int irq_set_affinity_callback(unsigned int irq,
> struct irq_affinity_callback *cb);
>
> That function can be called with cb=NULL to remove the callback. if
> cb!=NULL, irq, kref and work are initialized.
When should it be called, relative to {request,free}_irq() and
pci_{disable,enable}_msix()?
[...]
> That allows you to do all kind of magic in thread context, updating
> the queue map, reallocating queue memory when the node affinity
> changes (I know that you want to), go wild.
I definitely don't want to reallocate queues if node affinity of the IRQ
is changed by irqbalance, because this will disrupt traffic. So
changing the node affinity of queues has to be a separate operation.
> Thoughts ?
This does look like something I can use, thanks.
Ben.
--
Ben Hutchings, Senior Software Engineer, Solarflare Communications
Not speaking for my employer; that's the marketing department's job.
They asked us to note that Solarflare product names are trademarked.
^ permalink raw reply
* Re: [RFC][PATCH 1/4] IRQ: IRQ groups for multiqueue devices
From: Thomas Gleixner @ 2010-09-22 16:06 UTC (permalink / raw)
To: Ben Hutchings
Cc: Tom Herbert, netdev, linux-net-drivers, linux-kernel,
Peter Zijlstra, Ingo Molnar
In-Reply-To: <1285171249.2279.11.camel@achroite.uk.solarflarecom.com>
On Wed, 22 Sep 2010, Ben Hutchings wrote:
> On Tue, 2010-09-21 at 21:04 +0200, Thomas Gleixner wrote:
> [...]
> > Talked to Peter about it and we came to the conclusion, that we should
> > just provide a callback infrastructure in the irq code which does not
> > care about the action behind it. That's going to solve #1,#2,#3,#5,#6
> > and parts of #8
> >
> > That queue/index map code should move to lib/ or some other
> > appropriate place so it can be shared with storage or whatever is
> > going to grow multiqueue. comments #4, #7, #8 (s@kernel/irq@lib/@)
> > above still apply :)
>
> OK.
>
> > The modification to the genirq code would be based on registering
> >
> > struct irq_affinity_callback {
> > unsigned int irq;
> > struct kref kref;
> > struct work work;
> > void (*callback)(struct irq_affinity_callback *, const cpumask_t *mask);
> > void (*release)(struct kref *ref);
> > };
> >
> > for an interrupt via
> >
> > int irq_set_affinity_callback(unsigned int irq,
> > struct irq_affinity_callback *cb);
> >
> > That function can be called with cb=NULL to remove the callback. if
> > cb!=NULL, irq, kref and work are initialized.
>
> When should it be called, relative to {request,free}_irq() and
> pci_{disable,enable}_msix()?
It should be called before request_irq and before free_irq. free_irq
will warn when the pointer is !NULL.
> [...]
> > That allows you to do all kind of magic in thread context, updating
> > the queue map, reallocating queue memory when the node affinity
> > changes (I know that you want to), go wild.
>
> I definitely don't want to reallocate queues if node affinity of the IRQ
> is changed by irqbalance, because this will disrupt traffic. So
> changing the node affinity of queues has to be a separate operation.
Fair enough.
> > Thoughts ?
>
> This does look like something I can use, thanks.
Will look into it in the next days.
Thanks,
tglx
^ permalink raw reply
* [RFC PATCH] dont create cached routes from ARP requests
From: Ulrich Weber @ 2010-09-22 16:22 UTC (permalink / raw)
To: netdev
Do we really have to cache routes based on ARP requests?
Are there any other reasons than expecting new connections?
Attached is a patch to skip caching for ARP requests
not related to local IP addresses or ARP proxy.
Background: At home I have two Internet connections, DSL and Cable.
DSL is the primary uplink while Cable is the secondary.
My Cable ISP is flooding me with ARP request from 10.0.0.0/8,
which creates routes via the primary uplink.
There are thousands of cached routes and after some time
I get "Neighbour table overflow" messages.
Cheers
Ulrich
---
[PATCH] dont create cached routes from ARP requests
except for local destination or enabled ARP proxy. Otherwise
Neighbour table can overflow on broken network setups.
Signed-off-by: Ulrich Weber <uweber@astaro.com>
---
include/linux/in_route.h | 1 +
net/ipv4/route.c | 5 ++++-
2 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/include/linux/in_route.h b/include/linux/in_route.h
index b261b8c..d97dd35 100644
--- a/include/linux/in_route.h
+++ b/include/linux/in_route.h
@@ -18,6 +18,7 @@
#define RTCF_MASQ 0x00400000 /* unused */
#define RTCF_SNAT 0x00800000 /* unused */
#define RTCF_DOREDIRECT 0x01000000
+#define RTCF_NOCACHE 0x02000000
#define RTCF_DIRECTSRC 0x04000000
#define RTCF_DNAT 0x08000000
#define RTCF_BROADCAST 0x10000000
diff --git a/net/ipv4/route.c b/net/ipv4/route.c
index e24d48d..7f05e45 100644
--- a/net/ipv4/route.c
+++ b/net/ipv4/route.c
@@ -1090,7 +1090,7 @@ restart:
candp = NULL;
now = jiffies;
- if (!rt_caching(dev_net(rt->dst.dev))) {
+ if (rt->rt_flags & RTCF_NOCACHE || !rt_caching(dev_net(rt->dst.dev))) {
/*
* If we're not caching, just tell the caller we
* were successful and don't touch the route. The
@@ -2001,6 +2001,9 @@ static int __mkroute_input(struct sk_buff *skb,
err = -EINVAL;
goto cleanup;
}
+ if (!(out_dev->dev->flags & IFF_LOOPBACK) &&
+ !IN_DEV_PROXY_ARP(in_dev) && !IN_DEV_PROXY_ARP_PVLAN(in_dev))
+ flags |= RTCF_NOCACHE;
}
--
1.7.0.4
^ permalink raw reply related
* [PATCH] xfrm4: strip ECN bits from tos field
From: Ulrich Weber @ 2010-09-22 16:45 UTC (permalink / raw)
To: davem; +Cc: netdev
otherwise ECT(1) bit will get interpreted as RTO_ONLINK
and routing will fail with XfrmOutBundleGenError.
Signed-off-by: Ulrich Weber <uweber@astaro.com>
---
net/ipv4/xfrm4_policy.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/ipv4/xfrm4_policy.c b/net/ipv4/xfrm4_policy.c
index 869078d..a580349 100644
--- a/net/ipv4/xfrm4_policy.c
+++ b/net/ipv4/xfrm4_policy.c
@@ -61,7 +61,7 @@ static int xfrm4_get_saddr(struct net *net,
static int xfrm4_get_tos(struct flowi *fl)
{
- return fl->fl4_tos;
+ return IPTOS_RT_MASK & fl->fl4_tos; /* Strip ECN bits */
}
static int xfrm4_init_path(struct xfrm_dst *path, struct dst_entry *dst,
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2.6.36-rc3 1/1] IPv6 BUG: Temp addresses are immediately deleted after being created.
From: Glenn Wurster @ 2010-09-22 16:04 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: linux-kernel
There is a bug in the interaction between ipv6_create_tempaddr and
addrconf_verify. Because ipv6_create_tempaddr uses the cstamp and tstamp
from the public address in creating a private address, if we have not
received a router advertisement in a while, tstamp + temp_valid_lft might be
< now. If this happens, the new address is created inside
ipv6_create_tempaddr, then the loop within addrconf_verify starts again and
the address is immediately deleted. We are left with no temporary addresses
on the interface, and no more will be created until the public IP address is
updated. To avoid this, set the expiry time to be the minimum of the time
left on the public address or the config option PLUS the current age of the
public interface.
Sending again because of a previous e-mail header issue.
Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
---
net/ipv6/addrconf.c | 7 ++++---
1 files changed, 4 insertions(+), 3 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index cfee6ae..9c74454 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -836,7 +836,7 @@ static int ipv6_create_tempaddr(struct inet6_ifaddr *ifp,
struct inet6_ifaddr *i
{
struct inet6_dev *idev = ifp->idev;
struct in6_addr addr, *tmpaddr;
- unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp;
+ unsigned long tmp_prefered_lft, tmp_valid_lft, tmp_cstamp, tmp_tstamp, age;
unsigned long regen_advance;
int tmp_plen;
int ret = 0;
@@ -886,12 +886,13 @@ retry:
goto out;
}
memcpy(&addr.s6_addr[8], idev->rndid, 8);
+ age = (jiffies - ifp->tstamp) / HZ;
tmp_valid_lft = min_t(__u32,
ifp->valid_lft,
- idev->cnf.temp_valid_lft);
+ idev->cnf.temp_valid_lft + age);
tmp_prefered_lft = min_t(__u32,
ifp->prefered_lft,
- idev->cnf.temp_prefered_lft -
+ idev->cnf.temp_prefered_lft + age -
idev->cnf.max_desync_factor);
tmp_plen = ifp->prefix_len;
max_addresses = idev->cnf.max_addresses;
^ permalink raw reply related
* [PATCH 2.6.36-rc3 1/1] IPv6: Create temporary address if none exists.
From: Glenn Wurster @ 2010-09-22 16:04 UTC (permalink / raw)
To: David S. Miller, Alexey Kuznetsov, Pekka Savola (ipv6),
James Morris, Hideaki YOSHIFUJI <yosh
Cc: linux-kernel
If privacy extentions are enabled, but no current temporary address exists,
then create one when we get a router advertisement.
Sending again because of a previous e-mail header issue.
Signed-off-by: Glenn Wurster <gwurster@scs.carleton.ca>
---
net/ipv6/addrconf.c | 5 +++--
1 files changed, 3 insertions(+), 2 deletions(-)
diff --git a/net/ipv6/addrconf.c b/net/ipv6/addrconf.c
index ab70a3f..cfee6ae 100644
--- a/net/ipv6/addrconf.c
+++ b/net/ipv6/addrconf.c
@@ -2022,10 +2022,11 @@ ok:
ipv6_ifa_notify(0, ift);
}
- if (create && in6_dev->cnf.use_tempaddr > 0) {
+ if ((create || list_empty(&in6_dev->tempaddr_list)) &&
in6_dev->cnf.use_tempaddr > 0) {
/*
* When a new public address is created as described in [ADDRCONF],
- * also create a new temporary address.
+ * also create a new temporary address. Also create a temporary
+ * address if it's enabled but no temporary address currently exists.
*/
read_unlock_bh(&in6_dev->lock);
ipv6_create_tempaddr(ifp, NULL);
^ permalink raw reply related
* Re: [2.6.36-rc5] INET?: possible irq lock inversion dependency
From: Eric Dumazet @ 2010-09-22 17:35 UTC (permalink / raw)
To: Tetsuo Handa; +Cc: linux-fsdevel, netdev
In-Reply-To: <201009220858.o8M8w8s3094017@www262.sakura.ne.jp>
Le mercredi 22 septembre 2010 à 17:58 +0900, Tetsuo Handa a écrit :
> > Updated and booted/tested patch :
>
> The warning by test.sh disappeared by your patch.
> But the warning which I encounter upon reboot still appears.
> FYI,
>
> # cat /etc/exports
> /usr/src/ *(rw,no_root_squash,async)
>
> # grep nfs /proc/mounts
> 127.0.0.1:/usr/src/ /mnt nfs rw,relatime,vers=3,rsize=32768,wsize=32768,namlen=255,hard,proto=udp,port=65535,timeo=7,retrans=3,sec=sys,addr=127.0.0.1 0 0
>
> test.sh does not trigger this warning on 2.6.34.7 and
> triggers this warning on 2.6.35.5 .
>
Thanks !
We have for each socket :
One spinlock (sk_slock.slock)
One rwlock (sk_callback_lock)
It is legal to use :
A) (this is used in net/sunrpc/xprtsock.c)
read_lock(&sk->sk_callback_lock) (without blocking BH)
<BH>
spin_lock(&sk->sk_slock.slock);
...
read_lock(&sk->sk_callback_lock);
...
Its also legal to do
B)
write_lock_bh(&sk->sk_callback_lock)
stuff
write_unlock_bh(&sk->sk_callback_lock)
But if we have a path that :
C)
spin_lock_bh(&sk->sk_slock)
...
write_lock_bh(&sk->sk_callback_lock)
stuff
write_unlock_bh(&sk->sk_callback_lock)
Then we can have a deadlock with A)
CPU1 [A] CPU2 [C]
read_lock(&sk->sk_callback_lock)
<BH> spin_lock_bh(&sk->sk_slock)
<wait to spin_lock(slock)>
<wait to write_lock_bh(callback_lock)>
We have one such path C) in inet_csk_listen_stop() :
local_bh_disable();
bh_lock_sock(child); // spin_lock_bh(&sk->sk_slock)
WARN_ON(sock_owned_by_user(child));
...
sock_orphan(child); // write_lock_bh(&sk->sk_callback_lock)
This is a false positive because its not possible that this particular
deadlock can occur, since inet_csk_listen_stop() manipulates half
sockets (not yet given to a listener)
Give me a moment to think about it and write a fix.
^ permalink raw reply
* [PATCH] Use firmware provided index to register a network interface
From: Narendra K @ 2010-09-22 18:31 UTC (permalink / raw)
To: netdev, linux-hotplug, linux-pci
Cc: matt_domsch, charles_rose, jordan_hargrave, vijay_nijhawan
Hello,
Here is another approach to address the issue of "eth0 does not always
map to the Integrated NIC Port 1 as denoted on server chassis label".
For more details please refer to the thread -
http://marc.info/?l=linux-netdev&m=128163454631618&w=3.
Patch makes use of the firmware provided index to derive ethN names.
That way the naming scheme adheres to the existing requirements of
ethN namespace and with IFNAMSIZ length.
Please find the patch here -
From: Narendra K <narendra_k@dell.com>
Subject: [PATCH] Use firmware provided index to register a network device
This patch uses the firmware provided index to derive the ethN name.
If the firmware provides an index for the corresponding pdev, the N
is derived from the index.
As an example, consider a PowerEdge R710 which has 4 BCM5709
Lan-On-Motherboard ports,1 Intel 82572EI port and 4 82575GB ports.
The system firmware communicates the order of the 4 Lan-On-Motherboard
ports by assigning indexes to each one of them. This is available to
the OS as the SMBIOS type 41 record(for onboard devices), in the field
'device type index'. It looks like below -
Handle 0x2900, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 1
Type: Ethernet
Status: Enabled
Type Instance: 1
Bus Address: 0000:01:00.0
Handle 0x2901, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 2
Type: Ethernet
Status: Enabled
Type Instance: 2
Bus Address: 0000:01:00.1
Handle 0x2902, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 3
Type: Ethernet
Status: Enabled
Type Instance: 3
Bus Address: 0000:02:00.0
Handle 0x2903, DMI type 41, 11 bytes
Onboard Device
Reference Designation: Embedded NIC 4
Type: Ethernet
Status: Enabled
Type Instance: 4
Bus Address: 0000:02:00.1
The OS can use this index to name the network interfaces as below.
Onboard devices -
Interface Fwindex Driver
Name
eth[fwindex - 1] =eth0 1 bnx2
eth[fwindex - 1] =eth1 2 bnx2
eth[fwindex - 1] =eth2 3 bnx2
eth[fwindex - 1] =eth3 4 bnx2
The add-in devices do not get any index and they will get names from
eth4 onwards.
Add-in interfaces -
eth4 e1000e
eth5 igb
eth6 igb
eth7 igb
eth8 igb
With this patch,
1. This patch adheres to the established ABI of ethN namespace with
IFNAMSIZ length and ensures that onboard network interfaces get
expected names at the first instance itself and avoids any renaming
later.
2. The 'eth0' of the OS always corresponds to the 'Gb1' as labeled on
the system chassis. There is determinism in the way Lan-On-Motherboard
ports get named.
3. The add-in devices will always be named from beyond what the
Lan-On-Motherboard names as show above. But there is no determinism
as to which add-in interface gets what ethN name.
Signed-off-by: Narendra K <narendra_k@dell.com>
---
drivers/pci/pci-label.c | 1 +
drivers/pci/pci-sysfs.c | 5 +++++
include/linux/netdevice.h | 2 ++
include/linux/pci.h | 1 +
net/core/dev.c | 28 ++++++++++++++++++++++------
5 files changed, 31 insertions(+), 6 deletions(-)
diff --git a/drivers/pci/pci-label.c b/drivers/pci/pci-label.c
index 90c0a72..8086268 100644
--- a/drivers/pci/pci-label.c
+++ b/drivers/pci/pci-label.c
@@ -55,6 +55,7 @@ find_smbios_instance_string(struct pci_dev *pdev, char *buf,
"%s\n",
dmi->name);
}
+ pdev->firmware_index = donboard->instance;
return strlen(dmi->name);
}
}
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index b5a7d9b..448ed9d 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -28,6 +28,7 @@
#include "pci.h"
static int sysfs_initialized; /* = 0 */
+int pci_netdevs_with_fwindex;
/* show configuration fields */
#define pci_config_attr(field, format_string) \
@@ -1167,6 +1168,10 @@ int __must_check pci_create_sysfs_dev_files (struct pci_dev *pdev)
pci_create_firmware_label_files(pdev);
+ if (pdev->firmware_index && (pdev->class >> 16) ==
+ PCI_BASE_CLASS_NETWORK)
+ pci_netdevs_with_fwindex++;
+
return 0;
err_vga_file:
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 46c36ff..4398dcf 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1080,6 +1080,8 @@ struct net_device {
#define NETDEV_ALIGN 32
+extern int pci_netdevs_with_fwindex;
+
static inline
struct netdev_queue *netdev_get_tx_queue(const struct net_device *dev,
unsigned int index)
diff --git a/include/linux/pci.h b/include/linux/pci.h
index b1d1795..90113bb 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -243,6 +243,7 @@ struct pci_dev {
unsigned short subsystem_vendor;
unsigned short subsystem_device;
unsigned int class; /* 3 bytes: (base,sub,prog-if) */
+ unsigned int firmware_index; /* Firmware provided index */
u8 revision; /* PCI revision, low byte of class word */
u8 hdr_type; /* PCI header type (`multi' flag masked out) */
u8 pcie_cap; /* PCI-E capability offset */
diff --git a/net/core/dev.c b/net/core/dev.c
index 1ae6543..b177ccc 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -855,7 +855,7 @@ EXPORT_SYMBOL(dev_valid_name);
/**
* __dev_alloc_name - allocate a name for a device
- * @net: network namespace to allocate the device name in
+ * @dev: device
* @name: name format string
* @buf: scratch buffer and result name string
*
@@ -868,13 +868,15 @@ EXPORT_SYMBOL(dev_valid_name);
* Returns the number of the unit assigned or a negative errno code.
*/
-static int __dev_alloc_name(struct net *net, const char *name, char *buf)
+static int __dev_alloc_name(struct net_device *dev, const char *name, char *buf)
{
int i = 0;
const char *p;
const int max_netdevices = 8*PAGE_SIZE;
unsigned long *inuse;
struct net_device *d;
+ struct net *net;
+ struct pci_dev *pdev;
p = strnchr(name, IFNAMSIZ-1, '%');
if (p) {
@@ -886,15 +888,31 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
if (p[1] != 'd' || strchr(p + 2, '%'))
return -EINVAL;
+ pdev = to_pci_dev(dev->dev.parent);
+ if (pdev && pdev->firmware_index) {
+ snprintf(buf, IFNAMSIZ, name,
+ pdev->firmware_index - 1);
+ return pdev->firmware_index - 1;
+ }
+
/* Use one page as a bit array of possible slots */
inuse = (unsigned long *) get_zeroed_page(GFP_ATOMIC);
if (!inuse)
return -ENOMEM;
+ /* Reserve 0 to < pci_netdevs_with_fwindex for integrated
+ * ports with fwindex and allocate from pci_netdevs_with_fwindex
+ * onwards for add-in devices
+ */
+ for (i = 0; i < pci_netdevs_with_fwindex; i++)
+ set_bit(i, inuse);
+
+ net = dev_net(dev);
+
for_each_netdev(net, d) {
if (!sscanf(d->name, name, &i))
continue;
- if (i < 0 || i >= max_netdevices)
+ if (i < pci_netdevs_with_fwindex || i >= max_netdevices)
continue;
/* avoid cases where sscanf is not exact inverse of printf */
@@ -936,12 +954,10 @@ static int __dev_alloc_name(struct net *net, const char *name, char *buf)
int dev_alloc_name(struct net_device *dev, const char *name)
{
char buf[IFNAMSIZ];
- struct net *net;
int ret;
BUG_ON(!dev_net(dev));
- net = dev_net(dev);
- ret = __dev_alloc_name(net, name, buf);
+ ret = __dev_alloc_name(dev, name, buf);
if (ret >= 0)
strlcpy(dev->name, buf, IFNAMSIZ);
return ret;
--
1.7.0.1
With regards,
Narendra K
^ permalink raw reply related
* igmp: Allow mininum interval specification for igmp timers.
From: Christoph Lameter @ 2010-09-22 18:59 UTC (permalink / raw)
To: linux-rdma-u79uwXL29TY76Z2rM5mHXA, netdev-u79uwXL29TY76Z2rM5mHXA
Cc: Bob Arendt, David S. Miller, David L Stevens
IGMP timers sometimes fire too rapidly due to randomization of the
intervalsfrom 0 to max_delay in igmp_start_timer(). For some situations
(like the initial IGMP reports that are not responses to an IGMP query) we
do not want them in too rapid succession otherwise all the initial reports
may be lost due to a race conditions with the reconfiguration of the
routers and switches going on via the link layer (like on Infiniband). If
those are lost then the router will only discover that a new mc group was
joined when the igmp query was sent. General IGMP queries may be sent
rarely on large fabrics resulting in excessively long wait times until
data starts flowing. The application may abort before then concluding that
the network hardware is not operational.
The worst case scenario without the changes will send 3 igmp reports on join:
First 3 jiffies ("immediate" (spec) ~3 ms)
Second 3 jiffies (randomization leads to shortest interval) 3 ms
Third 3 jiffies (randomization leads to shortest interval) 3 ms
Which may result in a total of less than 10ms until the kernel gives up sending
igmp requests.
Change the IGMP layer to allow the specification of minimum and maximum delay.
Calculate the IGMP_Unsolicated_Report interval based on what the interval
before this patch would be on a 100HZ kernel. 3 jiffies at 100 HZ would result
in a mininum ~30 milliseconds spacing between the initial two IGMP reports.
Round it up to 40ms.
This will result in 3 initial unsolicited reports
First "immediately" 3 jiffies (~ 3ms)
Second randomized 40ms to 10seconds later
Third randomized 40ms to 10seconds later
So a mininum of ~83ms will pass before the unsolicted reports are
given up.
Signed-off-by: Christoph Lameter <cl-vYTEC60ixJUAvxtiuMwx3w@public.gmane.org>
---
net/ipv4/igmp.c | 45 +++++++++++++++++++++++++++++++--------------
1 file changed, 31 insertions(+), 14 deletions(-)
Index: linux-2.6/net/ipv4/igmp.c
===================================================================
--- linux-2.6.orig/net/ipv4/igmp.c 2010-09-22 11:15:19.000000000 -0500
+++ linux-2.6/net/ipv4/igmp.c 2010-09-22 12:50:32.000000000 -0500
@@ -116,10 +116,17 @@
#define IGMP_V2_Router_Present_Timeout (400*HZ)
#define IGMP_Unsolicited_Report_Interval (10*HZ)
#define IGMP_Query_Response_Interval (10*HZ)
-#define IGMP_Unsolicited_Report_Count 2
+/* Parameters not specified in igmp rfc. */
+
+/* Mininum ticks to have a meaningful notion of delay */
+#define IGMP_Mininum_Delay (2)
+
+/* Control of unsolilcited reports (after join) */
+#define IGMP_Unsolicited_Report_Count 2
#define IGMP_Initial_Report_Delay (1)
+#define IGMP_Unsolicited_Report_Min_Delay (HZ/25)
/* IGMP_Initial_Report_Delay is not from IGMP specs!
* IGMP specs require to report membership immediately after
@@ -174,22 +181,30 @@ static __inline__ void igmp_stop_timer(s
spin_unlock_bh(&im->lock);
}
-/* It must be called with locked im->lock */
-static void igmp_start_timer(struct ip_mc_list *im, int max_delay)
+static inline unsigned long jiffies_rand_delay(int min_delay, int max_delay)
{
- int tv = net_random() % max_delay;
+ int d = min_delay;
+
+ if (min_delay < max_delay)
+ d += net_random() % (max_delay - min_delay);
+ return jiffies + d;
+}
+
+/* It must be called with locked im->lock */
+static void igmp_start_timer(struct ip_mc_list *im, int min_delay, int max_delay)
+{
im->tm_running = 1;
- if (!mod_timer(&im->timer, jiffies+tv+2))
+ if (!mod_timer(&im->timer, jiffies_rand_delay(min_delay, max_delay)))
atomic_inc(&im->refcnt);
}
static void igmp_gq_start_timer(struct in_device *in_dev)
{
- int tv = net_random() % in_dev->mr_maxdelay;
-
in_dev->mr_gq_running = 1;
- if (!mod_timer(&in_dev->mr_gq_timer, jiffies+tv+2))
+ if (!mod_timer(&in_dev->mr_gq_timer,
+ jiffies_rand_delay(IGMP_Mininum_Delay,
+ in_dev->mr_maxdelay)))
in_dev_hold(in_dev);
}
@@ -201,7 +216,7 @@ static void igmp_ifc_start_timer(struct
in_dev_hold(in_dev);
}
-static void igmp_mod_timer(struct ip_mc_list *im, int max_delay)
+static void igmp_mod_timer(struct ip_mc_list *im, int min_delay, int max_delay)
{
spin_lock_bh(&im->lock);
im->unsolicit_count = 0;
@@ -214,7 +229,7 @@ static void igmp_mod_timer(struct ip_mc_
}
atomic_dec(&im->refcnt);
}
- igmp_start_timer(im, max_delay);
+ igmp_start_timer(im, min_delay, max_delay);
spin_unlock_bh(&im->lock);
}
@@ -733,7 +748,8 @@ static void igmp_timer_expire(unsigned l
if (im->unsolicit_count) {
im->unsolicit_count--;
- igmp_start_timer(im, IGMP_Unsolicited_Report_Interval);
+ igmp_start_timer(im, IGMP_Unsolicited_Report_Min_Delay,
+ IGMP_Unsolicited_Report_Interval);
}
im->reporter = 1;
spin_unlock(&im->lock);
@@ -911,7 +927,7 @@ static void igmp_heard_query(struct in_d
igmp_marksources(im, ntohs(ih3->nsrcs), ih3->srcs);
spin_unlock_bh(&im->lock);
if (changed)
- igmp_mod_timer(im, max_delay);
+ igmp_mod_timer(im, IGMP_Mininum_Delay, max_delay);
}
read_unlock(&in_dev->mc_list_lock);
}
@@ -1169,7 +1185,7 @@ static void igmp_group_added(struct ip_m
return;
if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev)) {
spin_lock_bh(&im->lock);
- igmp_start_timer(im, IGMP_Initial_Report_Delay);
+ igmp_start_timer(im, IGMP_Mininum_Delay, IGMP_Initial_Report_Delay);
spin_unlock_bh(&im->lock);
return;
}
@@ -1258,7 +1274,8 @@ void ip_mc_rejoin_group(struct ip_mc_lis
return;
if (IGMP_V1_SEEN(in_dev) || IGMP_V2_SEEN(in_dev)) {
- igmp_mod_timer(im, IGMP_Initial_Report_Delay);
+ igmp_mod_timer(im, IGMP_Mininum_Delay,
+ IGMP_Initial_Report_Delay);
return;
}
/* else, v3 */
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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
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