* RE: [net-next 07/12] ixgbe: Enable timesync clock-out feature for PPS support on X540
From: Keller, Jacob E @ 2012-05-10 22:08 UTC (permalink / raw)
To: Keller, Jacob E, Richard Cochran, Kirsher, Jeffrey T
Cc: davem@davemloft.net, netdev@vger.kernel.org, gospo@redhat.com,
sassmann@redhat.com
In-Reply-To: <20120510141721.GC3392@localhost.localdomain>
> -----Original Message-----
> From: Keller, Jacob E
> Sent: Thursday, May 10, 2012 2:55 PM
> To: 'Richard Cochran'; Kirsher, Jeffrey T
> Cc: davem@davemloft.net; netdev@vger.kernel.org; gospo@redhat.com;
> sassmann@redhat.com
> Subject: RE: [net-next 07/12] ixgbe: Enable timesync clock-out feature for PPS
> support on X540
>
>
>
> > -----Original Message-----
> > From: Richard Cochran [mailto:richardcochran@gmail.com]
> > Sent: Thursday, May 10, 2012 7:17 AM
> > To: Kirsher, Jeffrey T
> > Cc: davem@davemloft.net; Keller, Jacob E; netdev@vger.kernel.org;
> > gospo@redhat.com; sassmann@redhat.com
> > Subject: Re: [net-next 07/12] ixgbe: Enable timesync clock-out feature
> > for PPS support on X540
> >
> > On Wed, May 09, 2012 at 11:46:48PM -0700, Jeff Kirsher wrote:
> > > From: Jacob E Keller <jacob.e.keller@intel.com>
> > >
> > > This patch enables the PPS system in the PHC framework, by enabling
> > > the clock-out feature on the X540 device. Causes the SDP0 to be set
> > > as a 1Hz clock. Also configures the timesync interrupt cause in
> > > order to report each pulse to the PPS via the PHC framework, which
> > > can be used for general system clock synchronization. (This allows a
> > > stable method for tuning the general system time via the on-board
> > > SYSTIM register based clock.)
> >
> > Glad to see the PPS output and internal PPS support.
> >
> > > diff --git a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > index 9a83c40..1ad6e2a 100644
> > > --- a/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> > > +++ b/drivers/net/ethernet/intel/ixgbe/ixgbe_main.c
> >
> > ...
> >
> > > /**
> > > + * ixgbe_ptp_check_pps_event
> > > + * @adapter - the private adapter structure
> > > + * @eicr - the interrupt cause register value
> > > + *
> > > + * This function is called by the interrupt routine when checking
> > > +for
> > > + * interrupts. It will check and handle a pps event.
> > > + */
> > > +void ixgbe_ptp_check_pps_event(struct ixgbe_adapter *adapter, u32
> > > +eicr) {
> > > + struct ixgbe_hw *hw = &adapter->hw;
> > > + struct ptp_clock_event event;
> > > +
> > > + event.type = PTP_CLOCK_PPS;
> > > +
> > > + /* Make sure ptp clock is valid, and PPS event enabled */
> > > + if (!adapter->ptp_clock ||
> > > + !(adapter->flags2 & IXGBE_FLAG2_PTP_PPS_ENABLED))
> > > + return;
> > > +
> > > + switch (hw->mac.type) {
> > > + case ixgbe_mac_X540:
> > > + if (eicr & IXGBE_EICR_TIMESYNC)
> >
> > Since this function is called in every interrupt, I would check this
> > flag first thing.
> >
> Not sure what you mean? Check this before checking the other interrupts?
> I can do that.
>
> > > + ptp_clock_event(adapter->ptp_clock, &event);
> > > + break;
> > > + default:
> > > + break;
> > > + }
> > > +}
> >
> > Thanks,
> > Richard
Oops stupid mail program sent that on accident. Anyways: I think you might be
right, Richard. We don't read those timestamp values unless the stat err bit
for timestamps is set on the descriptor. But I am not sure what happens when the
tjmestamped packet is dropped off the end of the ring. What would you propose
here? How can we detect if this timestamp doesn't match the packet? I can look
into using the extra hardware features for matching timestamps. That might be
a more useful, in that it would help prevent this case.
- Jake
^ permalink raw reply
* RE: [NET_NEXT RFC PATCH 2/3] ixgbe: added netdev_ops file to debugfs
From: Sullivan, Catherine @ 2012-05-10 22:29 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: David Miller, netdev@vger.kernel.org
In-Reply-To: <20120510143539.5584e87e@nehalam.linuxnetplumber.net>
> From: Stephen Hemminger [mailto:shemminger@vyatta.com]
> Sent: Thursday, May 10, 2012 2:36 PM
>
> On Thu, 10 May 2012 21:14:49 +0000
> "Sullivan, Catherine" <catherine.sullivan@intel.com> wrote:
>
> > I was aware of this, however this does not allow a call to the
> ndo_tx_timeout function which is what my patch does. Is there a way to
> do this with sysfs? I could not find this functionality.
> >
> > -----Original Message-----
> > From: David Miller [mailto:davem@davemloft.net]
> > Sent: Thursday, May 10, 2012 1:32 PM
> >
> > From: "Sullivan, Catherine" <catherine.sullivan@intel.com>
> > Date: Thu, 10 May 2012 20:28:28 +0000
> >
> > > Could you point me to where this is available in sysfs please? I'm
> > > not familiar with it.
> >
> > Is the 'find' program not properly functioning on your computer?
> >
> > [davem@drr net-next]$ find /sys -type f -name tx_timeout
> > /sys/devices/virtual/net/lo/queues/tx-0/tx_timeout
> > /sys/devices/virtual/net/redhat0/queues/tx-0/tx_timeout
> >
> /sys/devices/pci0000:00/0000:00:1c.2/0000:06:00.0/net/p34p1/queues/tx-
> > 0/tx_timeout
> > [davem@drr net-next]$
>
> Are you trying to induce timeout for some tests or code coverage?
Yes, we are using this for testing and debugging purposes.
^ permalink raw reply
* [PATCH] ks8851: Update link status during link change interrupt
From: Stephen Boyd @ 2012-05-10 22:51 UTC (permalink / raw)
To: netdev; +Cc: linux-kernel, Ben Dooks
If a link change interrupt comes in we just clear the interrupt
and continue along without notifying the upper networking layers
that the link has changed. Use the mii_check_link() function to
update the link status whenever a link change interrupt occurs.
Cc: Ben Dooks <ben-linux@fluff.org>
Signed-off-by: Stephen Boyd <sboyd@codeaurora.org>
---
drivers/net/ethernet/micrel/ks8851.c | 7 ++++---
1 file changed, 4 insertions(+), 3 deletions(-)
diff --git a/drivers/net/ethernet/micrel/ks8851.c b/drivers/net/ethernet/micrel/ks8851.c
index f8dda00..5e313e9 100644
--- a/drivers/net/ethernet/micrel/ks8851.c
+++ b/drivers/net/ethernet/micrel/ks8851.c
@@ -618,10 +618,8 @@ static void ks8851_irq_work(struct work_struct *work)
netif_dbg(ks, intr, ks->netdev,
"%s: status 0x%04x\n", __func__, status);
- if (status & IRQ_LCI) {
- /* should do something about checking link status */
+ if (status & IRQ_LCI)
handled |= IRQ_LCI;
- }
if (status & IRQ_LDI) {
u16 pmecr = ks8851_rdreg16(ks, KS_PMECR);
@@ -684,6 +682,9 @@ static void ks8851_irq_work(struct work_struct *work)
mutex_unlock(&ks->lock);
+ if (status & IRQ_LCI)
+ mii_check_link(&ks->mii);
+
if (status & IRQ_TXI)
netif_wake_queue(ks->netdev);
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply related
* Re: [PATCH] xfrm: take iphdr size into account for esp payload size calculation
From: Benjamin Poirier @ 2012-05-11 1:02 UTC (permalink / raw)
To: Steffen Klassert
Cc: netdev, David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, linux-kernel
In-Reply-To: <20120510121857.GJ1021@secunet.com>
On 2012/05/10 14:18, Steffen Klassert wrote:
> On Wed, May 09, 2012 at 06:35:52PM -0400, Benjamin Poirier wrote:
> >
> > According to what is done, mainly in esp_output(), net_header_len aka
> > sizeof(struct iphdr) must be taken into account before doing the alignment
> > calculation.
>
> Why do you need to take the ip header into account here?
The value returned by this function is tuned for tcp segment size:
1) from tcp_mtu_to_mss()
mss = pmtu - tcp_hlen - net_hlen
2) frame structure for transport mode
mtu = mss + tcp_hlen + esp_header_len(esp_payload_len) + ah_len + net_hlen
The "mtu" parameter of esp4_get_mtu is in fact mtu - ah_len.
The return value of esp4_get_mtu is put into pmtu.
If we put 1 and 2 together we have:
pmtu = mtu - ah_len - esp_header_len(esp_payload_len)
with esp_payload_len = mss + tcp_hlen
This formula expands to:
pmtu = mtu - ah_len - (header_len + align(align(pmtu - net_hlen + 2, blksize),
esp->padlen) - (pmtu - net_hlen) + alen)
and simplifies to:
pmtu = (mtu - ah_len - net_hlen - header_len - alen) & ~(max(blksize,
esp->padlen) - 1) + (net_hlen - 2)
which, in the context of esp4_get_mtu, becomes:
((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) - sizeof(struct
iphdr)) & ~(align - 1)) + (sizeof(struct iphdr) - 2)
This is the same formula as before, except for sizeof(struct iphdr) which was
missing.
> Your patch breaks
> pmtu discovery, at least on tunnel mode with aes-sha1 (aes blocksize 16 bytes).
>
> With your patch applied:
>
> tracepath -n 192.168.1.2
> 1?: [LOCALHOST] pmtu 1442
> 1: send failed
> 1: send failed
> Resume: pmtu 1442
>
> Without your patch:
>
> tracepath -n 192.168.1.2
> 1?: [LOCALHOST] pmtu 1438
> 1: 192.168.1.2 0.736ms reached
> 1: 192.168.1.2 0.390ms reached
> Resume: pmtu 1438 hops 1 back 64
>
> Your patch increases the mtu by 4 bytes. Be aware that adding
> one byte of payload may increase the packet size up to 16 bytes
> in the case of aes, as we have to pad the encryption payload
> always to a multiple of the cipher blocksize.
Thanks for testing. My own testing had been limited to rsync'ing large
files.
The problem with tunnel mode in v1 of the patch was twofold.
First, we don't play games with mss and tcp_hlen. esp_payload_len = pmtu
directly, instead of esp_payload_len = pmtu - net_hlen.
Second, in the tunnel case, header_len already includes net_hlen, see
esp_init_state().
The net result is that the formula for tunnel mode was already correct.
>
> > -
> > - switch (x->props.mode) {
> > - case XFRM_MODE_TUNNEL:
> > - break;
> > - default:
> > - case XFRM_MODE_TRANSPORT:
> > - /* The worst case */
> > - mtu -= blksize - 4;
> > - mtu += min_t(u32, blksize - 4, rem);
> > - break;
>
> Btw. why we are doing the calculation above for transport mode?
^ permalink raw reply
* [PATCH v2] xfrm: take iphdr size into account for esp payload size calculation
From: Benjamin Poirier @ 2012-05-11 1:07 UTC (permalink / raw)
To: netdev
Cc: David S. Miller, Alexey Kuznetsov, James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, linux-kernel
In-Reply-To: <20120511010249.GA23584@d2.synalogic.ca>
Corrects the function that determines the esp payload size.
The calculations done in esp4_get_mtu lead to overlength frames in transport
mode for certain mtu values and suboptimal frames for others.
According to what is done, mainly in esp_output(), net_header_len aka
sizeof(struct iphdr) must be taken into account before doing the alignment
calculation.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
---
Changes since v1:
* introduce l3_adj to preserve the same returned value as before for tunnel
mode
For example, with md5 AH and 3des ESP (transport mode):
mtu = 1499 leads to FRAGFAILS
mtu = 1500 the addition of padding in the esp header could be avoided
Tested with
* transport mode E
* transport mode EA
* transport mode E + ah
* tunnel mode E
Not tested with BEET, but it should be the same as transport mode
draft-nikander-esp-beet-mode-03.txt Section 5.2:
"The wire packet format is identical to the ESP transport mode"
---
net/ipv4/esp4.c | 24 +++++++++---------------
1 files changed, 9 insertions(+), 15 deletions(-)
diff --git a/net/ipv4/esp4.c b/net/ipv4/esp4.c
index 89a47b3..b2503f6 100644
--- a/net/ipv4/esp4.c
+++ b/net/ipv4/esp4.c
@@ -459,28 +459,22 @@ static u32 esp4_get_mtu(struct xfrm_state *x, int mtu)
struct esp_data *esp = x->data;
u32 blksize = ALIGN(crypto_aead_blocksize(esp->aead), 4);
u32 align = max_t(u32, blksize, esp->padlen);
- u32 rem;
-
- mtu -= x->props.header_len + crypto_aead_authsize(esp->aead);
- rem = mtu & (align - 1);
- mtu &= ~(align - 1);
+ unsigned int l3_adj;
switch (x->props.mode) {
- case XFRM_MODE_TUNNEL:
- break;
- default:
case XFRM_MODE_TRANSPORT:
- /* The worst case */
- mtu -= blksize - 4;
- mtu += min_t(u32, blksize - 4, rem);
- break;
case XFRM_MODE_BEET:
- /* The worst case. */
- mtu += min_t(u32, IPV4_BEET_PHMAXLEN, rem);
+ l3_adj = sizeof(struct iphdr);
break;
+ case XFRM_MODE_TUNNEL:
+ l3_adj = 0;
+ break;
+ default:
+ BUG();
}
- return mtu - 2;
+ return ((mtu - x->props.header_len - crypto_aead_authsize(esp->aead) -
+ l3_adj) & ~(align - 1)) + (l3_adj - 2);
}
static void esp4_err(struct sk_buff *skb, u32 info)
--
1.7.7
^ permalink raw reply related
* [net] igb: fix rtnl race in PM resume path
From: Jeff Kirsher @ 2012-05-11 1:38 UTC (permalink / raw)
To: davem; +Cc: Benjamin Poirier, netdev, gospo, sassmann, Jeff Kirsher
From: Benjamin Poirier <bpoirier@suse.de>
Since the caller (PM resume code) is not the one holding rtnl, when taking the
'else' branch rtnl may be released at any moment, thereby defeating the whole
purpose of this code block.
Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
---
This patch is also available on my net tree on kernel.org, but did not
send a pull-request since I did not see the point in pulling a single
patch.
The following are changes since commit 0e0c55165b638e96c8d7097ea638aa368daa268a:
Merge branch 'sfc-3.4' of git://git.kernel.org/pub/scm/linux/kernel/git/bwh/sfc
and are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net master
---
drivers/net/ethernet/intel/igb/igb_main.c | 20 ++++++--------------
1 files changed, 6 insertions(+), 14 deletions(-)
diff --git a/drivers/net/ethernet/intel/igb/igb_main.c b/drivers/net/ethernet/intel/igb/igb_main.c
index d223500..8683ca4 100644
--- a/drivers/net/ethernet/intel/igb/igb_main.c
+++ b/drivers/net/ethernet/intel/igb/igb_main.c
@@ -1111,9 +1111,12 @@ msi_only:
adapter->flags |= IGB_FLAG_HAS_MSI;
out:
/* Notify the stack of the (possibly) reduced queue counts. */
+ rtnl_lock();
netif_set_real_num_tx_queues(adapter->netdev, adapter->num_tx_queues);
- return netif_set_real_num_rx_queues(adapter->netdev,
- adapter->num_rx_queues);
+ err = netif_set_real_num_rx_queues(adapter->netdev,
+ adapter->num_rx_queues);
+ rtnl_unlock();
+ return err;
}
/**
@@ -6796,18 +6799,7 @@ static int igb_resume(struct device *dev)
pci_enable_wake(pdev, PCI_D3hot, 0);
pci_enable_wake(pdev, PCI_D3cold, 0);
- if (!rtnl_is_locked()) {
- /*
- * shut up ASSERT_RTNL() warning in
- * netif_set_real_num_tx/rx_queues.
- */
- rtnl_lock();
- err = igb_init_interrupt_scheme(adapter);
- rtnl_unlock();
- } else {
- err = igb_init_interrupt_scheme(adapter);
- }
- if (err) {
+ if (igb_init_interrupt_scheme(adapter)) {
dev_err(&pdev->dev, "Unable to allocate memory for queues\n");
return -ENOMEM;
}
--
1.7.7.6
^ permalink raw reply related
* [PATCH] ipv4: Do not use dead fib_info entries.
From: David Miller @ 2012-05-11 2:17 UTC (permalink / raw)
To: netdev; +Cc: yevgen.pronenko
Due to RCU lookups and RCU based release, fib_info objects can
be found during lookup which have fi->fib_dead set.
We must ignore these entries, otherwise we risk dereferencing
the parts of the entry which are being torn down.
Reported-by: Yevgen Pronenko <yevgen.pronenko@sonymobile.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
net/ipv4/fib_trie.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/net/ipv4/fib_trie.c b/net/ipv4/fib_trie.c
index bce36f1..30b88d7 100644
--- a/net/ipv4/fib_trie.c
+++ b/net/ipv4/fib_trie.c
@@ -1370,6 +1370,8 @@ static int check_leaf(struct fib_table *tb, struct trie *t, struct leaf *l,
if (fa->fa_tos && fa->fa_tos != flp->flowi4_tos)
continue;
+ if (fi->fib_dead)
+ continue;
if (fa->fa_info->fib_scope < flp->flowi4_scope)
continue;
fib_alias_accessed(fa);
--
1.7.10.1
^ permalink raw reply related
* Re: linux-next: Tree for May 10 (net/phy)
From: Paul Gortmaker @ 2012-05-11 2:36 UTC (permalink / raw)
To: Randy Dunlap; +Cc: Stephen Rothwell, linux-next, LKML, netdev, linuxppc-dev
In-Reply-To: <4FAC35E2.4060900@xenotime.net>
On Thu, May 10, 2012 at 5:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
> On 05/10/2012 02:26 AM, Stephen Rothwell wrote:
>
>> Hi all,
>>
>> Changes since 20120508:
>
>
>
> ERROR: "of_mdio_find_bus" [drivers/net/phy/mdio-mux.ko] undefined!
Not just randconfig, but also powerpc allmodconfig:
http://kisskb.ellerman.id.au/kisskb/buildresult/6291463/
Adding ppc ML to cc.
P.
--
>
> Full randconfig file is attached.
>
> --
> ~Randy
^ permalink raw reply
* Re: [Q/RFC] BPF use in broader scope
From: Li Yu @ 2012-05-11 2:41 UTC (permalink / raw)
To: Jiri Pirko
Cc: Eric Dumazet, David Miller, netdev, bhutchings, shemminger, matt
In-Reply-To: <20120329093158.GA2275@minipsycho.brq.redhat.com>
于 2012年03月29日 17:31, Jiri Pirko 写道:
> Thu, Mar 29, 2012 at 10:45:32AM CEST, eric.dumazet@gmail.com wrote:
>> On Thu, 2012-03-29 at 10:31 +0200, Jiri Pirko wrote:
>>> Thu, Mar 29, 2012 at 10:02:25AM CEST, eric.dumazet@gmail.com wrote:
>>>> On Thu, 2012-03-29 at 09:54 +0200, Jiri Pirko wrote:
>>>>
>>>>> Yep, I'm aware. I must admit that the JIT code scares me a litte :(
>>>>>
>>>>
>>>> If you add a new XOR instruction in interpreter only, JIT compiler will
>>>> automatically aborts, so no risk.
>>>>
>>>> Each arch maintainer will add the support for the new instructions as
>>>> separate patches.
>>>>
>>>> So you can focus on net/core/filter.c file only.
>>>>
>>>
>>> Ok - I can do this for 2). But for 3) JITs need to be modified. So I
>>> would like to kindly ask you and Matt if you can do this modification so
>>> bpf_func takes pointer to mem (scratch store) as second parameter. I'm
>>> sure it's very easy for you to do.
>>
>> I am not sure why you want this.
>>
>> This adds register pressure (at least for x86) ...
>
> Well I think that there would become handy to be able to pass some data
> to bpf_func (other than skb). But it's just an idea.
>
Hi, Jiri Pirko, any progress of extended BPF? :)
I am interesting in 3) much. For my requirements,
it just only need BPF has ability to handle arbitrary
"pre-filled memory area", but not handle both a skb and
such a memory area at same time, so I think that register
pressure should not be become the performance bottleneck
here.
Otherwise, I must construct a fake sk_buff to execute filter
feature, it is ugly, isn't it?
I guess that Nuno Martins's requirements also are similar.
And, I also would like join this project, if you need.
Thanks
Yu
>>
>>
>>
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: linux-next: Tree for May 10 (net/phy)
From: David Miller @ 2012-05-11 2:43 UTC (permalink / raw)
To: paul.gortmaker
Cc: rdunlap, sfr, linux-next, linux-kernel, netdev, linuxppc-dev,
david.daney
In-Reply-To: <CAP=VYLon7XRoh9s==wGYjUPNAYaTk8QQx7FGRnaDR97v+O-zXA@mail.gmail.com>
From: Paul Gortmaker <paul.gortmaker@windriver.com>
Date: Thu, 10 May 2012 22:36:55 -0400
> On Thu, May 10, 2012 at 5:40 PM, Randy Dunlap <rdunlap@xenotime.net> wrote:
>> On 05/10/2012 02:26 AM, Stephen Rothwell wrote:
>>
>>> Hi all,
>>>
>>> Changes since 20120508:
>>
>>
>>
>> ERROR: "of_mdio_find_bus" [drivers/net/phy/mdio-mux.ko] undefined!
>
> Not just randconfig, but also powerpc allmodconfig:
>
> http://kisskb.ellerman.id.au/kisskb/buildresult/6291463/
>
> Adding ppc ML to cc.
Adding the guilty party to the CC:. This really stinks, especially
after I did give the patch submitter a hard time about getting the
dependencies right. :-/
^ permalink raw reply
* Re: [net] igb: fix rtnl race in PM resume path
From: David Miller @ 2012-05-11 2:45 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: bpoirier, netdev, gospo, sassmann
In-Reply-To: <1336700317-31929-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Thu, 10 May 2012 18:38:37 -0700
> From: Benjamin Poirier <bpoirier@suse.de>
>
> Since the caller (PM resume code) is not the one holding rtnl, when taking the
> 'else' branch rtnl may be released at any moment, thereby defeating the whole
> purpose of this code block.
>
> Signed-off-by: Benjamin Poirier <bpoirier@suse.de>
> Tested-by: Jeff Pieper <jeffrey.e.pieper@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied, thanks Jeff.
^ permalink raw reply
* Re: [PATCH] ehea: fix losing of NEQ events when one event occurred early
From: David Miller @ 2012-05-11 2:46 UTC (permalink / raw)
To: cascardo; +Cc: netdev
In-Reply-To: <1336658453-687-1-git-send-email-cascardo@linux.vnet.ibm.com>
From: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Date: Thu, 10 May 2012 11:00:53 -0300
> The NEQ interrupt is only triggered when there was no previous pending
> interrupt. If we request irq handling after an interrupt has occurred,
> we will never get an interrupt until we call H_RESET_EVENTS.
>
> Events seem to be cleared when we first register the NEQ. So, when we
> requested irq handling right after registering it, a possible race with
> an interrupt was much less likely. Now, there is a chance we may lose
> this race and never get any events.
>
> The fix here is to poll and acknowledge any events that might have
> happened right after registering the irq handler.
>
> Signed-off-by: Thadeu Lima de Souza Cascardo <cascardo@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: skb_set_dev do not unconditionally drop ref to dst
From: David Miller @ 2012-05-11 3:06 UTC (permalink / raw)
To: blaschka; +Cc: netdev, arnd, linux-s390, eric.dumazet
In-Reply-To: <20120509104803.GA52076@tuxmaker.boeblingen.de.ibm.com>
From: Frank Blaschka <blaschka@linux.vnet.ibm.com>
Date: Wed, 9 May 2012 12:48:03 +0200
> On Thu, May 03, 2012 at 02:28:37AM -0400, David Miller wrote:
>> From: Eric Dumazet <eric.dumazet@gmail.com>
>> Date: Wed, 02 May 2012 08:59:21 +0200
>>
>> > If Arnd doesnt care to even reply, we can just revert his buggy
>> > patch, instead of trying to understand and fix all issues.
>>
>> Agreed, it's the best sounding solution by far.
> Hi Dave,
>
> looks like discussion is done and everybody is ok with reverting
> Arnds patch. Can you revert commit 8a83a00b0735190384a348156837918271034144 ?
Done, and I'll queue this up for -stable too.
[PATCH] Revert "net: maintain namespace isolation between vlan and real device"
This reverts commit 8a83a00b0735190384a348156837918271034144.
It causes regressions for S390 devices, because it does an
unconditional DST drop on SKBs for vlans and the QETH device
needs the neighbour entry hung off the DST for certain things
on transmit.
Arnd can't remember exactly why he even needed this change.
Conflicts:
drivers/net/macvlan.c
net/8021q/vlan_dev.c
net/core/dev.c
Signed-off-by: David S. Miller <davem@davemloft.net>
---
drivers/net/macvlan.c | 2 +-
include/linux/netdevice.h | 9 ---------
net/8021q/vlan_dev.c | 2 +-
net/core/dev.c | 36 +++++-------------------------------
4 files changed, 7 insertions(+), 42 deletions(-)
diff --git a/drivers/net/macvlan.c b/drivers/net/macvlan.c
index f975afd..025367a 100644
--- a/drivers/net/macvlan.c
+++ b/drivers/net/macvlan.c
@@ -259,7 +259,7 @@ static int macvlan_queue_xmit(struct sk_buff *skb, struct net_device *dev)
xmit_world:
skb->ip_summed = ip_summed;
- skb_set_dev(skb, vlan->lowerdev);
+ skb->dev = vlan->lowerdev;
return dev_queue_xmit(skb);
}
diff --git a/include/linux/netdevice.h b/include/linux/netdevice.h
index 5cbaa20..33900a5 100644
--- a/include/linux/netdevice.h
+++ b/include/linux/netdevice.h
@@ -1403,15 +1403,6 @@ static inline bool netdev_uses_dsa_tags(struct net_device *dev)
return 0;
}
-#ifndef CONFIG_NET_NS
-static inline void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
-{
- skb->dev = dev;
-}
-#else /* CONFIG_NET_NS */
-void skb_set_dev(struct sk_buff *skb, struct net_device *dev);
-#endif
-
static inline bool netdev_uses_trailer_tags(struct net_device *dev)
{
#ifdef CONFIG_NET_DSA_TAG_TRAILER
diff --git a/net/8021q/vlan_dev.c b/net/8021q/vlan_dev.c
index 9988d4a..9757c19 100644
--- a/net/8021q/vlan_dev.c
+++ b/net/8021q/vlan_dev.c
@@ -157,7 +157,7 @@ static netdev_tx_t vlan_dev_hard_start_xmit(struct sk_buff *skb,
skb = __vlan_hwaccel_put_tag(skb, vlan_tci);
}
- skb_set_dev(skb, vlan_dev_priv(dev)->real_dev);
+ skb->dev = vlan_dev_priv(dev)->real_dev;
len = skb->len;
if (netpoll_tx_running(dev))
return skb->dev->netdev_ops->ndo_start_xmit(skb, skb->dev);
diff --git a/net/core/dev.c b/net/core/dev.c
index 9bb8f87..99e1d75 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -1617,10 +1617,14 @@ int dev_forward_skb(struct net_device *dev, struct sk_buff *skb)
return NET_RX_DROP;
}
skb->skb_iif = 0;
- skb_set_dev(skb, dev);
+ skb->dev = dev;
+ skb_dst_drop(skb);
skb->tstamp.tv64 = 0;
skb->pkt_type = PACKET_HOST;
skb->protocol = eth_type_trans(skb, dev);
+ skb->mark = 0;
+ secpath_reset(skb);
+ nf_reset(skb);
return netif_rx(skb);
}
EXPORT_SYMBOL_GPL(dev_forward_skb);
@@ -1869,36 +1873,6 @@ void netif_device_attach(struct net_device *dev)
}
EXPORT_SYMBOL(netif_device_attach);
-/**
- * skb_dev_set -- assign a new device to a buffer
- * @skb: buffer for the new device
- * @dev: network device
- *
- * If an skb is owned by a device already, we have to reset
- * all data private to the namespace a device belongs to
- * before assigning it a new device.
- */
-#ifdef CONFIG_NET_NS
-void skb_set_dev(struct sk_buff *skb, struct net_device *dev)
-{
- skb_dst_drop(skb);
- if (skb->dev && !net_eq(dev_net(skb->dev), dev_net(dev))) {
- secpath_reset(skb);
- nf_reset(skb);
- skb_init_secmark(skb);
- skb->mark = 0;
- skb->priority = 0;
- skb->nf_trace = 0;
- skb->ipvs_property = 0;
-#ifdef CONFIG_NET_SCHED
- skb->tc_index = 0;
-#endif
- }
- skb->dev = dev;
-}
-EXPORT_SYMBOL(skb_set_dev);
-#endif /* CONFIG_NET_NS */
-
static void skb_warn_bad_offload(const struct sk_buff *skb)
{
static const netdev_features_t null_features = 0;
--
1.7.10.1
^ permalink raw reply related
* Re: [PATCH] pktgen: fix crash at module unload
From: David Miller @ 2012-05-11 3:12 UTC (permalink / raw)
To: eric.dumazet; +Cc: ebiederm, netdev
In-Reply-To: <1336606191.12504.97.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 May 2012 01:29:51 +0200
> [PATCH v2] pktgen: fix crash at module unload
>
> commit 7d3d43dab4e9 (net: In unregister_netdevice_notifier unregister
> the netdevices.) makes pktgen crashing at module unload.
...
> Hold the pktgen_thread_lock while splicing pktgen_threads, and test
> pktgen_exiting in pktgen_device_event() to make unload faster.
>
> Signed-off-by: Eric Dumazet <edumazet@google.com>
> Cc: Eric W. Biederman <ebiederm@xmission.com>
Applied and queued up for -stable.
^ permalink raw reply
* Re: [Lksctp-developers] Bug: sctp packets are dropped after IPSEC rekeying (route cache issue)
From: David Miller @ 2012-05-11 3:15 UTC (permalink / raw)
To: vyasevich
Cc: nicolas.dichtel, babu.srinivasan, lksctp-developers, linux-sctp,
netdev, michael.kreuzer
In-Reply-To: <CAGCdqXFjyWst22DJgxNfakz3-JwRq0Z+WZVj-XT=qRQFY5w3rw@mail.gmail.com>
From: Vladislav Yasevich <vyasevich@gmail.com>
Date: Fri, 4 May 2012 14:15:05 -0400
> Acked-by: Vlad Yaseivch <vyasevich@gmail.com>
Applied.
^ permalink raw reply
* Re: [net-next 00/12][pull request] Intel Wired LAN Driver Updates
From: David Miller @ 2012-05-11 3:18 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: netdev, gospo, sassmann
In-Reply-To: <1336632413-19135-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Wed, 9 May 2012 23:46:41 -0700
> This series of patches contains updates for igb and ixgbe.
> Special note ixgbe patches contain the addition of PTP support from
> Jacob Keller.
>
> The following are changes since commit 8feedbb4a710784d2858acba5c90e903e93e36eb:
> dsa: Convert compare_ether_addr to ether_addr_equal
> and are available in the git repository at:
> git://git.kernel.org/pub/scm/linux/kernel/git/jkirsher/net-next master
Pulled, thanks Jeff.
^ permalink raw reply
* Re: [patch 1/1] connector/userns: replace netlink uses of cap_raised() with capable()
From: David Miller @ 2012-05-11 3:21 UTC (permalink / raw)
To: akpm
Cc: netdev, ebiederm, dhowells, james.l.morris, kaber, morgan,
philipp.reisner, segoon, serge.hallyn
In-Reply-To: <20120504213403.BD3A4A0367@akpm.mtv.corp.google.com>
From: akpm@linux-foundation.org
Date: Fri, 04 May 2012 14:34:03 -0700
> In 2009 Philip Reiser notied that a few users of netlink connector
> interface needed a capability check and added the idiom
> cap_raised(nsp->eff_cap, CAP_SYS_ADMIN) to a few of them, on the premise
> that netlink was asynchronous.
>
> In 2011 Patrick McHardy noticed we were being silly because netlink is
> synchronous and removed eff_cap from the netlink_skb_params and changed
> the idiom to cap_raised(current_cap(), CAP_SYS_ADMIN).
>
> Looking at those spots with a fresh eye we should be calling
> capable(CAP_SYS_ADMIN). The only reason I can see for not calling capable
> is that it once appeared we were not in the same task as the caller which
> would have made calling capable() impossible.
>
> In the initial user_namespace the only difference between between
> cap_raised(current_cap(), CAP_SYS_ADMIN) and capable(CAP_SYS_ADMIN) are a
> few sanity checks and the fact that capable(CAP_SYS_ADMIN) sets
> PF_SUPERPRIV if we use the capability.
>
> Since we are going to be using root privilege setting PF_SUPERPRIV seems
> the right thing to do.
>
> The motivation for this that patch is that in a child user namespace
> cap_raised(current_cap(),...) tests your capabilities with respect to that
> child user namespace not capabilities in the initial user namespace and
> thus will allow processes that should be unprivielged to use the kernel
> services that are only protected with cap_raised(current_cap(),..).
>
> To fix possible user_namespace issues and to just clean up the code
> replace cap_raised(current_cap(), CAP_SYS_ADMIN) with
> capable(CAP_SYS_ADMIN).
>
> Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
> Cc: Patrick McHardy <kaber@trash.net>
> Cc: Philipp Reisner <philipp.reisner@linbit.com>
> Acked-by: Serge E. Hallyn <serge.hallyn@canonical.com>
> Acked-by: Andrew G. Morgan <morgan@kernel.org>
> Cc: Vasiliy Kulikov <segoon@openwall.com>
> Cc: David Howells <dhowells@redhat.com>
> Reviewed-by: James Morris <james.l.morris@oracle.com>
> Cc: David Miller <davem@davemloft.net>
> Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Applied, thanks.
^ permalink raw reply
* Re: [PATCH] irda: irda-usb.c URL to sigmatel stir 4210/4220/4116 fw from archive.org
From: David Miller @ 2012-05-11 3:23 UTC (permalink / raw)
To: xose.vazquez; +Cc: samuel, netdev, linux-kernel
In-Reply-To: <1336167477-28835-1-git-send-email-xose.vazquez@gmail.com>
From: Xose Vazquez Perez <xose.vazquez@gmail.com>
Date: Fri, 4 May 2012 23:37:57 +0200
> @@ -1081,6 +1081,7 @@ static int stir421x_patch_device(struct irda_usb_cb *self)
> /*
> * Known firmware patch file names for STIR421x dongles
> * are "42101001.sb" or "42101002.sb"
> + * http://web.archive.org/web/http://www.sigmatel.com/documents/stir4210_4220_4116_patch_files.tar.gz
This really doesn't scale in the long term.
Someone needs to host this firmware at a location which serves the
needs of the people who have an interest in using this driver.
^ permalink raw reply
* Re: [PATCH 1/3] tcp: Move rcvq sending to tcp_input.c
From: David Miller @ 2012-05-11 3:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: xemul, netdev
In-Reply-To: <1336651214.12504.149.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 May 2012 14:00:14 +0200
> On Thu, 2012-05-10 at 15:49 +0400, Pavel Emelyanov wrote:
>> It actually works on the input queue and will use its read mem
>> routines, thus it's better to have in in the tcp_input.c file.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>> ---
>> include/net/tcp.h | 3 +--
>> net/ipv4/tcp.c | 33 ---------------------------------
>> net/ipv4/tcp_input.c | 35 ++++++++++++++++++++++++++++++++++-
>> 3 files changed, 35 insertions(+), 36 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 2/3] tcp: Schedule rmem for rcvq repair send
From: David Miller @ 2012-05-11 3:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: xemul, netdev
In-Reply-To: <1336651229.12504.150.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 May 2012 14:00:29 +0200
> On Thu, 2012-05-10 at 15:50 +0400, Pavel Emelyanov wrote:
>> As noted by Eric, no checks are performed on the data size we're
>> putting in the read queue during repair. Thus, validate the given
>> data size with the common rmem management routine.
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>> ---
>> net/ipv4/tcp_input.c | 3 +++
>> 1 files changed, 3 insertions(+), 0 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH 3/3] tcp: Out-line tcp_try_rmem_schedule
From: David Miller @ 2012-05-11 3:25 UTC (permalink / raw)
To: eric.dumazet; +Cc: xemul, netdev
In-Reply-To: <1336651256.12504.151.camel@edumazet-glaptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Thu, 10 May 2012 14:00:56 +0200
> On Thu, 2012-05-10 at 15:50 +0400, Pavel Emelyanov wrote:
>> As proposed by Eric, make the tcp_input.o thinner.
>>
>> add/remove: 1/1 grow/shrink: 1/4 up/down: 868/-1329 (-461)
>> function old new delta
>> tcp_try_rmem_schedule - 864 +864
>> tcp_ack 4811 4815 +4
>> tcp_validate_incoming 817 815 -2
>> tcp_collapse 860 858 -2
>> tcp_send_rcvq 555 353 -202
>> tcp_data_queue 3435 3033 -402
>> tcp_prune_queue 721 - -721
>>
>> Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
>> ---
>> net/ipv4/tcp_input.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>
> Acked-by: Eric Dumazet <edumazet@google.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 1/2] l2tp: fix reorder timeout recovery
From: David Miller @ 2012-05-11 3:27 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <1336642989-4785-1-git-send-email-jchapman@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Thu, 10 May 2012 10:43:08 +0100
> When L2TP data packet reordering is enabled, packets are held in a
> queue while waiting for out-of-sequence packets. If a packet gets
> lost, packets will be held until the reorder timeout expires, when we
> are supposed to then advance to the sequence number of the next packet
> but we don't currently do so. As a result, the data channel is stuck
> because we are waiting for a packet that will never arrive - all
> packets age out and none are passed.
>
> The fix is to add a flag to the session context, which is set when the
> reorder timeout expires and tells the receive code to reset the next
> expected sequence number to that of the next packet in the queue.
>
> Tested in a production L2TP network with Starent and Nortel L2TP gear.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
Applied, but reorder_skip should really be a 'bool'.
^ permalink raw reply
* Re: [PATCH net-next 2/2] l2tp: fix data packet sequence number handling
From: David Miller @ 2012-05-11 3:27 UTC (permalink / raw)
To: jchapman; +Cc: netdev
In-Reply-To: <1336642989-4785-2-git-send-email-jchapman@katalix.com>
From: James Chapman <jchapman@katalix.com>
Date: Thu, 10 May 2012 10:43:09 +0100
> If enabled, L2TP data packets have sequence numbers which a receiver
> can use to drop out of sequence frames or try to reorder them. The
> first frame has sequence number 0, but the L2TP code currently expects
> it to be 1. This results in the first data frame being handled as out
> of sequence.
>
> This one-line patch fixes the problem.
>
> Signed-off-by: James Chapman <jchapman@katalix.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3][resend] bonding: don't increase rx_dropped after processing LACPDUs
From: David Miller @ 2012-05-11 3:31 UTC (permalink / raw)
To: jbohac; +Cc: andy, netdev, fubar
In-Reply-To: <20120509110140.GA9817@midget.suse.cz>
From: Jiri Bohac <jbohac@suse.cz>
Date: Wed, 9 May 2012 13:01:40 +0200
> Since commit 3aba891d, bonding processes LACP frames (802.3ad
> mode) with bond_handle_frame(). Currently a copy of the skb is
> made and the original is left to be processed by other
> rx_handlers and the rest of the network stack by returning
> RX_HANDLER_ANOTHER. As there is no protocol handler for
> PKT_TYPE_LACPDU, the frame is dropped and dev->rx_dropped
> increased.
>
> Fix this by making bond_handle_frame() return RX_HANDLER_CONSUMED
> if bonding has processed the LACP frame.
>
> Signed-off-by: Jiri Bohac <jbohac@suse.cz>
>
Don't send me garbage you didn't even check the compile of:
drivers/net/bonding/bond_main.c: In function ‘bond_handle_frame’:
drivers/net/bonding/bond_main.c:1463:13: warning: assignment from incompatible pointer type [enabled by default]
drivers/net/bonding/bond_main.c: In function ‘bond_open’:
drivers/net/bonding/bond_main.c:3441:21: warning: assignment from incompatible pointer type [enabled by default]
drivers/net/bonding/bond_main.c:3448:20: warning: assignment from incompatible pointer type [enabled by default]
^ permalink raw reply
* Re: [PATCH net-next] be2net: avoid disabling sriov while VFs are assigned
From: David Miller @ 2012-05-11 3:35 UTC (permalink / raw)
To: sathya.perla; +Cc: netdev
In-Reply-To: <647fcd25-8a85-4d63-a1ef-8b867832c2c7@exht1.ad.emulex.com>
From: Sathya Perla <sathya.perla@emulex.com>
Date: Wed, 9 May 2012 11:11:24 +0530
> Calling pci_disable_sriov() while VFs are assigned to VMs causes
> kernel panic. This patch uses PCI_DEV_FLAGS_ASSIGNED bit state of the
> VF's pci_dev to avoid this. Also, the unconditional function reset cmd
> issued on a PF probe can delete the VF configuration for the
> previously enabled VFs. A scratchpad register is now used to issue a
> function reset only when needed (i.e., in a crash dump scenario.)
>
> Signed-off-by: Sathya Perla <sathya.perla@emulex.com>
Applied.
^ 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