* Re: [PATCH] net-netlink: fix diag to export IPv4 tos for dual-stack IPv6 sockets
From: David Miller @ 2011-11-22 21:03 UTC (permalink / raw)
To: zenczykowski; +Cc: netdev, maze, muralira, shemminger, eric.dumazet
In-Reply-To: <CAHo-OoxNkDvuTJWfz=Q6XxS_gJyf-w_A=V_3Qi8hL_k5-18RPg@mail.gmail.com>
From: Maciej Żenczykowski <zenczykowski@gmail.com>
Date: Mon, 21 Nov 2011 17:52:09 -0800
> As you see, I've decided to go with the simplest 'punt the problem to
> userspace' solution.
>
> Hope this is acceptable...
It's a good solution, especially for 3.2-rcX
Thanks.
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: David Miller @ 2011-11-22 21:05 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122205655.GE8452@tuxdriver.com>
From: "John W. Linville" <linville@tuxdriver.com>
Date: Tue, 22 Nov 2011 15:56:55 -0500
> On Tue, Nov 22, 2011 at 03:14:29PM -0500, David Miller wrote:
>> From: "John W. Linville" <linville@tuxdriver.com>
>> Date: Tue, 22 Nov 2011 14:35:05 -0500
>>
>> > Here is the latest batch of fixes intended for 3.2. This includes a
>> > correction for a user-visible error in mac80211's debugfs info, a fix
>> > for a potential memory corrupter in prism54, an endian fix for rt2x00,
>> > an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
>> > locking fix and a deadlock fix for p54spi, and a pair of rt2x00 fixes
>> > for handling some spurious interrupts that hardware can generate.
>> >
>> > Please let me know if there are problems!
>>
>> The rt2800pci change doesn't look correct.
>>
>> If the IRQ line is shared with another device, this change will make it
>> never see interrupts. Once you say "IRQ_HANDLED" the IRQ dispatch
>> stops processing the interrupt handler list.
>
> I thought this at first as well. But looking at the code in
> kernel/irq/handle.c doesn't support that conclusion. In fact, every
> handler gets invoked no matter what they all return. All of the irq
> handler return values are ORed together and passed to note_interrupt.
> Only if every irq handler returns IRQ_NONE does the code in
> kernel/irq/spurious.c start getting involved.
>
> Anyway, this seems to be safe even for shared interrupts. That said,
> this is a bit ugly. But it makes a serious difference in performance
> for those afflicted with this issue.
It just means that we won't notice spurious interrupts if the device
sharing the line with rt2800pci generates one.
This change is wrong.
^ permalink raw reply
* Re: [PATCH net-next v2 0/4] e1000e: ethtool setfeatures fixes + loopback
From: David Decotigny @ 2011-11-22 21:13 UTC (permalink / raw)
To: jeffrey.t.kirsher
Cc: Ian Campbell, Paul Gortmaker, e1000-devel@lists.sourceforge.net,
Mahesh Bandewar, Allan, Bruce W, Brandeburg, Jesse,
linux-kernel@vger.kernel.org, Ronciak, John,
Maciej Żenczykowski, netdev@vger.kernel.org, David S. Miller
In-Reply-To: <1321994813.2304.90.camel@jtkirshe-mobl>
Jeff, Bruce,
Please drop this patch series as I was informed that:
- http://patchwork.ozlabs.org/patch/95175/ already implemented
loopback for ethtool and is under review. Please note, though, that
the version (patch 2) I submitted builds on top of newer net-next
changes
- Maciej Żenczykowski would prefer not to use the version I sent for
patches 3 and 4, and will provide an improved patch
I will mark the series as rejected on patchwork and will resend patch
1 (fix) as "v3".
My apologies for this hick-up.
Regards,
--
David Decotigny
On Tue, Nov 22, 2011 at 12:46 PM, Jeff Kirsher
<jeffrey.t.kirsher@intel.com> wrote:
> On Tue, 2011-11-22 at 11:23 -0800, David Decotigny wrote:
>> This series fixes a bug in ethtool setfeatures and adds loopback
>> support through ethtool setfeatures.
>>
>> I believe these patches could easily be adapted to e1000, but I don't
>> have the hardware to test.
>>
>> Changes since v1:
>> - simplification in patch 1/4 (from Michał Mirosław)
>>
>> ############################################
>> # Patch Set Summary:
>>
>> David Decotigny (2):
>> net-e1000e: fix ethtool set_features taking new features into account
>> too late
>> net-e1000e: ethtool loopback support
>>
>> Maciej Żenczykowski (2):
>> net-e1000e: reworked carrier detection logic
>> net-e1000e: Report carrier in loopback mode
>>
>> drivers/net/ethernet/intel/e1000e/e1000.h | 2 +
>> drivers/net/ethernet/intel/e1000e/ethtool.c | 6 +-
>> drivers/net/ethernet/intel/e1000e/netdev.c | 32 +++++++++++-
>> drivers/net/ethernet/intel/e1000e/phy.c | 69 +++++++++++++++++----------
>> 4 files changed, 78 insertions(+), 31 deletions(-)
>>
>
> Thanks David for the patch set. I have added the e1000e patches to my
> queue. As an fyi, I want Bruce Allan to look over these patches and he
> is out this week on vacation.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: David Miller @ 2011-11-22 21:13 UTC (permalink / raw)
To: linville; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122.160511.2302883259439708995.davem@davemloft.net>
From: David Miller <davem@davemloft.net>
Date: Tue, 22 Nov 2011 16:05:11 -0500 (EST)
> From: "John W. Linville" <linville@tuxdriver.com>
> Date: Tue, 22 Nov 2011 15:56:55 -0500
>
>> On Tue, Nov 22, 2011 at 03:14:29PM -0500, David Miller wrote:
>>> From: "John W. Linville" <linville@tuxdriver.com>
>>> Date: Tue, 22 Nov 2011 14:35:05 -0500
>>>
>>> > Here is the latest batch of fixes intended for 3.2. This includes a
>>> > correction for a user-visible error in mac80211's debugfs info, a fix
>>> > for a potential memory corrupter in prism54, an endian fix for rt2x00,
>>> > an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
>>> > locking fix and a deadlock fix for p54spi, and a pair of rt2x00 fixes
>>> > for handling some spurious interrupts that hardware can generate.
>>> >
>>> > Please let me know if there are problems!
>>>
>>> The rt2800pci change doesn't look correct.
>>>
>>> If the IRQ line is shared with another device, this change will make it
>>> never see interrupts. Once you say "IRQ_HANDLED" the IRQ dispatch
>>> stops processing the interrupt handler list.
>>
>> I thought this at first as well. But looking at the code in
>> kernel/irq/handle.c doesn't support that conclusion. In fact, every
>> handler gets invoked no matter what they all return. All of the irq
>> handler return values are ORed together and passed to note_interrupt.
>> Only if every irq handler returns IRQ_NONE does the code in
>> kernel/irq/spurious.c start getting involved.
>>
>> Anyway, this seems to be safe even for shared interrupts. That said,
>> this is a bit ugly. But it makes a serious difference in performance
>> for those afflicted with this issue.
>
> It just means that we won't notice spurious interrupts if the device
> sharing the line with rt2800pci generates one.
>
> This change is wrong.
BTW, look at it this way, if what you say is true John then what's the point
in returning any specific value at all?
Everyone can just return IRQ_HANDLED and everything would just work.
But you know that's not the case, and that it's important that this value
is returned accurately.
^ permalink raw reply
* Re: [PATCH net-next 0/5] atm: cleanups and MSK_PEEK for atm sockets
From: David Miller @ 2011-11-22 21:16 UTC (permalink / raw)
To: jorge; +Cc: netdev, linux-atm-general
In-Reply-To: <1321907158-27857-1-git-send-email-jorge@dti2.net>
From: "Jorge Boncompte [DTI2]" <jorge@dti2.net>
Date: Mon, 21 Nov 2011 21:25:53 +0100
> This series does some cleanup and introduces MSG_PEEK support for ATM
> sockets.
Applied, thank you.
^ permalink raw reply
* Re: [PATCH] net: correct comments of skb_shift
From: David Miller @ 2011-11-22 21:19 UTC (permalink / raw)
To: kinwin2008; +Cc: netdev
In-Reply-To: <1321876031-2543-1-git-send-email-kinwin2008@gmail.com>
From: Feng King <kinwin2008@gmail.com>
Date: Mon, 21 Nov 2011 19:47:11 +0800
> when skb_shift, we want to shift paged data from skb to tgt frag area.
> Original comments revert the shift order
>
> Signed-off-by: Feng King <kinwin2008@gmail.com>
Applied, thank you.
^ permalink raw reply
* [PATCH net-next v3] net-e1000e: fix ethtool set_features taking new features into account too late
From: David Decotigny @ 2011-11-22 21:22 UTC (permalink / raw)
To: Jeff Kirsher, Jesse Brandeburg, Bruce Allan, Carolyn Wyborny,
Don Skidmore, Greg Rose, Peter P Waskiewicz Jr, Alex Duyck,
John Ronciak, e1000-devel, netdev, linux-kernel
Cc: David Decotigny, David S. Miller, Eric Dumazet, Ian Campbell,
Paul Gortmaker
In-Reply-To: <cover.1321996918.git.david.decotigny@google.com>
Before this patch, the set_features() ethtool callback would not take
the new specified features into account when configuring the NIC. It
would only consider the current features, ie. the ones after previous
set_features(). A second ethtool set_features() with the same
specified features cannot work around that issue because it would boil
down to a nop (code checks wether specified features changed or not).
This patch solves this by propagating the requested features.
Tested:
printk in code + custom ethtool (based on
http://patchwork.ozlabs.org/patch/95836/)
Signed-off-by: David Decotigny <david.decotigny@google.com>
---
drivers/net/ethernet/intel/e1000e/netdev.c | 11 +++++++++--
1 files changed, 9 insertions(+), 2 deletions(-)
diff --git a/drivers/net/ethernet/intel/e1000e/netdev.c b/drivers/net/ethernet/intel/e1000e/netdev.c
index a5bd7a3..a83a108 100644
--- a/drivers/net/ethernet/intel/e1000e/netdev.c
+++ b/drivers/net/ethernet/intel/e1000e/netdev.c
@@ -5901,7 +5901,7 @@ static void e1000_eeprom_checks(struct e1000_adapter *adapter)
}
static int e1000_set_features(struct net_device *netdev,
- netdev_features_t features)
+ netdev_features_t features)
{
struct e1000_adapter *adapter = netdev_priv(netdev);
netdev_features_t changed = features ^ netdev->features;
@@ -5913,12 +5913,19 @@ static int e1000_set_features(struct net_device *netdev,
NETIF_F_RXCSUM)))
return 0;
+ /* We will make sure to return 1 below so that we can change
+ * netdev->features on the fly from within the functions
+ * called below in case of error, without core/dev.c
+ * overriding it. */
+ netdev->features = features;
+
if (netif_running(netdev))
e1000e_reinit_locked(adapter);
else
e1000e_reset(adapter);
- return 0;
+ return 1; /* tell net/core/dev.c not to override
+ * netdev->features */
}
static const struct net_device_ops e1000e_netdev_ops = {
--
1.7.3.1
^ permalink raw reply related
* Re: [patch v2 1/1] fix error handle in ip_mc_add_src()
From: David Miller @ 2011-11-22 21:22 UTC (permalink / raw)
To: mypopydev; +Cc: eric.dumazet, netdev, dlstevens
In-Reply-To: <1321891516.14281.62.camel@barry.pixelworks.com>
From: Jun Zhao <mypopydev@gmail.com>
Date: Tue, 22 Nov 2011 00:05:16 +0800
> from: Jun Zhao <mypopydev@gmail.com>
>
> When add sources to interface failure, need to roll back the sfcount[MODE]
> to before state. We need to match it corresponding.
>
> Acked-by: David L Stevens <dlstevens@us.ibm.com>
> Acked-by: Eric Dumazet <eric.dumazet@gmail.com>
> Signed-off-by: Jun Zhao <mypopydev@gmail.com>
Please use an appropriate prefix in your subject line after the
closing "]" bracket. For example, something like "ipv4: " for this
specific patch is fine.
Your patch has also been corrupted by your email client, it turned tab
characters into spaces amongst other things. Please correct this,
email a test patch to yourself, and make absolutely sure you are able
to successfully apply it before you retry submitting your fix here.
Thank you.
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: John W. Linville @ 2011-11-22 21:26 UTC (permalink / raw)
To: David Miller; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122.161322.454163033398038634.davem@davemloft.net>
On Tue, Nov 22, 2011 at 04:13:22PM -0500, David Miller wrote:
> From: David Miller <davem@davemloft.net>
> Date: Tue, 22 Nov 2011 16:05:11 -0500 (EST)
>
> > From: "John W. Linville" <linville@tuxdriver.com>
> > Date: Tue, 22 Nov 2011 15:56:55 -0500
> >
> >> On Tue, Nov 22, 2011 at 03:14:29PM -0500, David Miller wrote:
> >>> From: "John W. Linville" <linville@tuxdriver.com>
> >>> Date: Tue, 22 Nov 2011 14:35:05 -0500
> >>>
> >>> > Here is the latest batch of fixes intended for 3.2. This includes a
> >>> > correction for a user-visible error in mac80211's debugfs info, a fix
> >>> > for a potential memory corrupter in prism54, an endian fix for rt2x00,
> >>> > an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
> >>> > locking fix and a deadlock fix for p54spi, and a pair of rt2x00 fixes
> >>> > for handling some spurious interrupts that hardware can generate.
> >>> >
> >>> > Please let me know if there are problems!
> >>>
> >>> The rt2800pci change doesn't look correct.
> >>>
> >>> If the IRQ line is shared with another device, this change will make it
> >>> never see interrupts. Once you say "IRQ_HANDLED" the IRQ dispatch
> >>> stops processing the interrupt handler list.
> >>
> >> I thought this at first as well. But looking at the code in
> >> kernel/irq/handle.c doesn't support that conclusion. In fact, every
> >> handler gets invoked no matter what they all return. All of the irq
> >> handler return values are ORed together and passed to note_interrupt.
> >> Only if every irq handler returns IRQ_NONE does the code in
> >> kernel/irq/spurious.c start getting involved.
> >>
> >> Anyway, this seems to be safe even for shared interrupts. That said,
> >> this is a bit ugly. But it makes a serious difference in performance
> >> for those afflicted with this issue.
> >
> > It just means that we won't notice spurious interrupts if the device
> > sharing the line with rt2800pci generates one.
> >
> > This change is wrong.
>
> BTW, look at it this way, if what you say is true John then what's the point
> in returning any specific value at all?
>
> Everyone can just return IRQ_HANDLED and everything would just work.
>
> But you know that's not the case, and that it's important that this value
> is returned accurately.
Alright, that a good point. I'll drop those two patches.
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: Larry Finger @ 2011-11-22 21:30 UTC (permalink / raw)
To: David Miller; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122.161322.454163033398038634.davem@davemloft.net>
On 11/22/2011 03:13 PM, David Miller wrote:
> From: David Miller<davem@davemloft.net>
> Date: Tue, 22 Nov 2011 16:05:11 -0500 (EST)
>
>> From: "John W. Linville"<linville@tuxdriver.com>
>> Date: Tue, 22 Nov 2011 15:56:55 -0500
>>
>>> On Tue, Nov 22, 2011 at 03:14:29PM -0500, David Miller wrote:
>>>> From: "John W. Linville"<linville@tuxdriver.com>
>>>> Date: Tue, 22 Nov 2011 14:35:05 -0500
>>>>
>>>>> Here is the latest batch of fixes intended for 3.2. This includes a
>>>>> correction for a user-visible error in mac80211's debugfs info, a fix
>>>>> for a potential memory corrupter in prism54, an endian fix for rt2x00,
>>>>> an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
>>>>> locking fix and a deadlock fix for p54spi, and a pair of rt2x00 fixes
>>>>> for handling some spurious interrupts that hardware can generate.
>>>>>
>>>>> Please let me know if there are problems!
>>>>
>>>> The rt2800pci change doesn't look correct.
>>>>
>>>> If the IRQ line is shared with another device, this change will make it
>>>> never see interrupts. Once you say "IRQ_HANDLED" the IRQ dispatch
>>>> stops processing the interrupt handler list.
>>>
>>> I thought this at first as well. But looking at the code in
>>> kernel/irq/handle.c doesn't support that conclusion. In fact, every
>>> handler gets invoked no matter what they all return. All of the irq
>>> handler return values are ORed together and passed to note_interrupt.
>>> Only if every irq handler returns IRQ_NONE does the code in
>>> kernel/irq/spurious.c start getting involved.
>>>
>>> Anyway, this seems to be safe even for shared interrupts. That said,
>>> this is a bit ugly. But it makes a serious difference in performance
>>> for those afflicted with this issue.
>>
>> It just means that we won't notice spurious interrupts if the device
>> sharing the line with rt2800pci generates one.
>>
>> This change is wrong.
>
> BTW, look at it this way, if what you say is true John then what's the point
> in returning any specific value at all?
>
> Everyone can just return IRQ_HANDLED and everything would just work.
>
> But you know that's not the case, and that it's important that this value
> is returned accurately.
I was trying to find the thread that reported the improvement in performance
with this change, but failed. Is it possible that their change just papered over
an interrupt storm from some other device that shared that interrupt?
I'm following this because the rtlwifi-family of drivers already did what was
suggested here. If this is wrong, then so is it.
Larry
^ permalink raw reply
* Re: Kernel v3.0.8 igb driver dies when pulling network cable
From: Alexander Duyck @ 2011-11-22 21:35 UTC (permalink / raw)
To: Stefan Priebe - Profihost AG
Cc: Stable Tree, stable, Greg KH, LKML, Linux Netdev List,
Jeff Kirsher,
Jesse Brandeburg <jesse.brandeburg@intel.com> Bruce Allan,
Carolyn Wyborny, Don Skidmore, Greg Rose, PJ Waskiewicz,
John Ronciak
In-Reply-To: <4ECB6D1C.8010208@profihost.ag>
On 11/22/2011 01:36 AM, Stefan Priebe - Profihost AG wrote:
>> It would be useful if you could try the latest driver from e1000.sf.net
>> just to verify if this is a bug in the upstream kernel or if it is also
>> present in our e1000.sf.net.driver. This way we can figure out if this
>> is an issue where a patch wasn't pushed into the stable kernel or if it
>> is an issue that still exists in our latest release.
>>
>> Also could you provide us with the part number you are currently using.
>> If you could provide us with the device ID for the part via lspci we can
>> start narrowing down the root cause for the issue as currently we don't
>> have any information about what hardware you are experiencing this
>> issue on.
>
> Ok another note i missed last time. Ethernet and Server stays fully
> functional - it just prints the message and resets the adapter.
>
> OK let's start with lspci:
> a:00.0 Ethernet controller: Intel Corporation Device 10c9 (rev 01)
> Subsystem: Super Micro Computer Inc Device 10c9
> Flags: bus master, fast devsel, latency 0, IRQ 28
> Memory at fbe60000 (32-bit, non-prefetchable) [size=128K]
> Memory at fbe40000 (32-bit, non-prefetchable) [size=128K]
> I/O ports at e880 [size=32]
> Memory at fbe1c000 (32-bit, non-prefetchable) [size=16K]
> Expansion ROM at fbe20000 [disabled] [size=128K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+
> Queue=0/0 Enable-
> Capabilities: [70] MSI-X: Enable+ Mask- TabSize=10
> Capabilities: [a0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting <?>
> Capabilities: [140] Device Serial Number ce-5a-2b-ff-ff-90-25-00
> Capabilities: [150] #0e
> Capabilities: [160] #10
> Kernel driver in use: igb
>
> 0a:00.1 Ethernet controller: Intel Corporation Device 10c9 (rev 01)
> Subsystem: Super Micro Computer Inc Device 10c9
> Flags: bus master, fast devsel, latency 0, IRQ 40
> Memory at fbee0000 (32-bit, non-prefetchable) [size=128K]
> Memory at fbec0000 (32-bit, non-prefetchable) [size=128K]
> I/O ports at ec00 [size=32]
> Memory at fbe9c000 (32-bit, non-prefetchable) [size=16K]
> Expansion ROM at fbea0000 [disabled] [size=128K]
> Capabilities: [40] Power Management version 3
> Capabilities: [50] Message Signalled Interrupts: Mask+ 64bit+
> Queue=0/0 Enable-
> Capabilities: [70] MSI-X: Enable+ Mask- TabSize=10
> Capabilities: [a0] Express Endpoint, MSI 00
> Capabilities: [100] Advanced Error Reporting <?>
> Capabilities: [140] Device Serial Number ce-5a-2b-ff-ff-90-25-00
> Capabilities: [150] #0e
> Capabilities: [160] #10
> Kernel driver in use: igb
>
> Using the latest stable igb driver from e1000.sf.net works fine
> without any message.
>
> Thanks,
>
> Stefan
Hi Stefan,
It seems like there might be an issue with something specific to your
board since I tried reproducing the issue here on an 82576 based adapter
and the stable 3.0.9 kernel I have and I have not had much success.
I'm assuming the device that is failing is eth0. I was wondering if you
could send me the output of the following three commands so that I can
do some further work to try and isolate the root cause for this issue:
ethtool eth0
ethtool -e eth0
grep eth0 /proc/interrupts
The issue seems to be that your adapter is not detecting that the cable
was unplugged. This in turn is leaving stale packets on the Tx ring and
is what is resulting in the dev_watchdog message you are seeing.
Typically this is due to one of two possible causes. Either the device
is not detecting that the link went down, or the interrupt for the link
down event was never delivered. Once we can isolate which of these two
events is occurring we will be much closer to having the root cause.
Thanks,
Alex
^ permalink raw reply
* Re: [PATCH] tc: comment spelling fixes
From: David Miller @ 2011-11-22 21:38 UTC (permalink / raw)
To: bhutchings; +Cc: shemminger, netdev
In-Reply-To: <1321895528.2692.4.camel@bwh-desktop>
From: Ben Hutchings <bhutchings@solarflare.com>
Date: Mon, 21 Nov 2011 17:12:08 +0000
> On Mon, 2011-11-21 at 08:53 -0800, Stephen Hemminger wrote:
>> Signed-off-by: Stephen Hemminger <shemminger@vyatta.com>
>>
>> --- a/include/linux/pkt_sched.h 2011-11-09 13:54:59.780009551 -0800
>> +++ b/include/linux/pkt_sched.h 2011-11-21 08:51:20.062228855 -0800
>> @@ -30,7 +30,7 @@
>> */
>>
>> struct tc_stats {
>> - __u64 bytes; /* NUmber of enqueues bytes */
>> + __u64 bytes; /* Number of enqueues bytes */
> [...]
>
> Further fix needed: 'enqueued'.
I took care of this when applying Stephen's patch.
^ permalink raw reply
* Re: MPLS for Linux kernel
From: Igor Maravić @ 2011-11-22 21:41 UTC (permalink / raw)
Cc: netdev
In-Reply-To: <CAFdo_mUH=21_+xuLqE6tytHmD-QwXb9XXfTzixYFqUcbcLAfWQ@mail.gmail.com>
To sum up,
I would like to know what is necesary for MPLS implementation to have,
and to do, so it would be accepted in upstream kernel?
BR
Igor
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: David Miller @ 2011-11-22 21:40 UTC (permalink / raw)
To: Larry.Finger; +Cc: linville, linux-wireless, netdev, linux-kernel
In-Reply-To: <4ECC1479.8090209@lwfinger.net>
From: Larry Finger <Larry.Finger@lwfinger.net>
Date: Tue, 22 Nov 2011 15:30:33 -0600
> On 11/22/2011 03:13 PM, David Miller wrote:
>> From: David Miller<davem@davemloft.net>
>> Date: Tue, 22 Nov 2011 16:05:11 -0500 (EST)
>>
>>> From: "John W. Linville"<linville@tuxdriver.com>
>>> Date: Tue, 22 Nov 2011 15:56:55 -0500
>>>
>>>> On Tue, Nov 22, 2011 at 03:14:29PM -0500, David Miller wrote:
>>>>> From: "John W. Linville"<linville@tuxdriver.com>
>>>>> Date: Tue, 22 Nov 2011 14:35:05 -0500
>>>>>
>>>>>> Here is the latest batch of fixes intended for 3.2. This includes a
>>>>>> correction for a user-visible error in mac80211's debugfs info, a fix
>>>>>> for a potential memory corrupter in prism54, an endian fix for rt2x00,
>>>>>> an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
>>>>>> locking fix and a deadlock fix for p54spi, and a pair of rt2x00 fixes
>>>>>> for handling some spurious interrupts that hardware can generate.
>>>>>>
>>>>>> Please let me know if there are problems!
>>>>>
>>>>> The rt2800pci change doesn't look correct.
>>>>>
>>>>> If the IRQ line is shared with another device, this change will make
>>>>> it
>>>>> never see interrupts. Once you say "IRQ_HANDLED" the IRQ dispatch
>>>>> stops processing the interrupt handler list.
>>>>
>>>> I thought this at first as well. But looking at the code in
>>>> kernel/irq/handle.c doesn't support that conclusion. In fact, every
>>>> handler gets invoked no matter what they all return. All of the irq
>>>> handler return values are ORed together and passed to note_interrupt.
>>>> Only if every irq handler returns IRQ_NONE does the code in
>>>> kernel/irq/spurious.c start getting involved.
>>>>
>>>> Anyway, this seems to be safe even for shared interrupts. That said,
>>>> this is a bit ugly. But it makes a serious difference in performance
>>>> for those afflicted with this issue.
>>>
>>> It just means that we won't notice spurious interrupts if the device
>>> sharing the line with rt2800pci generates one.
>>>
>>> This change is wrong.
>>
>> BTW, look at it this way, if what you say is true John then what's the
>> point
>> in returning any specific value at all?
>>
>> Everyone can just return IRQ_HANDLED and everything would just work.
>>
>> But you know that's not the case, and that it's important that this
>> value
>> is returned accurately.
>
> I was trying to find the thread that reported the improvement in
> performance with this change, but failed. Is it possible that their
> change just papered over an interrupt storm from some other device
> that shared that interrupt?
It doesn't fix a performance problem, it fixes a problem wherein the
IRQ line is disabled by the generic IRQ code because all handlers
return IRQ_NONE.
^ permalink raw reply
* Re: pull request: wireless 2011-11-22
From: John W. Linville @ 2011-11-22 21:44 UTC (permalink / raw)
To: Larry Finger; +Cc: David Miller, linux-wireless, netdev, linux-kernel
In-Reply-To: <4ECC1479.8090209@lwfinger.net>
On Tue, Nov 22, 2011 at 03:30:33PM -0600, Larry Finger wrote:
> On 11/22/2011 03:13 PM, David Miller wrote:
> >From: David Miller<davem@davemloft.net>
> >Date: Tue, 22 Nov 2011 16:05:11 -0500 (EST)
> >Everyone can just return IRQ_HANDLED and everything would just work.
> >
> >But you know that's not the case, and that it's important that this value
> >is returned accurately.
>
> I was trying to find the thread that reported the improvement in
> performance with this change, but failed. Is it possible that their
> change just papered over an interrupt storm from some other device
> that shared that interrupt?
Original patch was posted here:
http://marc.info/?l=linux-wireless&m=132143811916674&w=2
And the Red Hat Bugzilla entry is here:
https://bugzilla.redhat.com/show_bug.cgi?id=658451
> I'm following this because the rtlwifi-family of drivers already did
> what was suggested here. If this is wrong, then so is it.
Sounds like that nees to be fixed...
John
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply
* Re: MPLS for Linux kernel
From: David Miller @ 2011-11-22 21:49 UTC (permalink / raw)
To: igorm; +Cc: netdev
In-Reply-To: <CAFdo_mVdva4=4bJOaXQTNHhD-3h5LSLvERi8D7s-45SdRO5ibA@mail.gmail.com>
From: Igor Maravić <igorm@etf.rs>
Date: Tue, 22 Nov 2011 22:41:44 +0100
> I would like to know what is necesary for MPLS implementation to have,
> and to do, so it would be accepted in upstream kernel?
A long and laborious back and forth review process, taking into consideration
not just the technical details of the patches themselves, but the top level
and overall design.
That's what it will take.
Taking someone else's work, fixing all the bugs and cleaning them up is
far from sufficient for a feature of this nature. There is natural
overlap all over and we have to make sure the implementation bits are
going into the right places.
One issue of constant contention is that people want to add all of their
favorite packet filtering and packet mangling into their protocol handling
code, with all kinds of custom controls and configuration mechanisms.
WE HATE THIS.
We have the packet scheduler classifiers and packet actions for a reason,
and we want them to used instead of ignored.
We are going through the same thing in the review process for the openvswitch
code, which brings up another design question for MPLS, which is whether MPLS
can be better implemented in terms of openvswitch.
You're in the unfortunate position of submitting a feature that has a
lot of overlap with many other subsystems, existing code, and features
being submitted at the same time. We want as much reuse as possible,
and we want it all designed right before it gets integrated.
I frankly don't care very much about MPLS personally, it's such a
fringe facility. So if people just argue themselves into oblivion and
no forward progress is made, just like last time an MPLS submission
was attempted, that's also fine with me :-)
^ permalink raw reply
* Re: [PATCH net-next] net: remove netdev_alloc_page and use __GFP_COLD
From: David Miller @ 2011-11-22 21:52 UTC (permalink / raw)
To: eric.dumazet; +Cc: netdev, jeffrey.t.kirsher, dm
In-Reply-To: <1321995461.19663.16.camel@edumazet-laptop>
From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Tue, 22 Nov 2011 21:57:41 +0100
> Given we dont use anymore the struct net_device *dev argument, and this
> interface brings litle benefit, remove netdev_{alloc|free}_page(), to
> debloat include/linux/skbuff.h a bit.
>
> (Some drivers used a mix of these interfaces and alloc_pages())
>
> When allocating a page given to device for DMA transfert (device to
> memory), it makes sense to use a cold one (__GFP_COLD)
>
> Signed-off-by: Eric Dumazet <eric.dumazet@gmail.com>
> CC: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
> CC: Dimitris Michailidis <dm@chelsio.com>
Fair enough, applied.
^ permalink raw reply
* Re: [PATCH] net: remove ipv6_addr_copy()
From: David Miller @ 2011-11-22 21:53 UTC (permalink / raw)
To: adobriyan; +Cc: netdev
In-Reply-To: <20111121133903.GA18453@p183.telecom.by>
From: Alexey Dobriyan <adobriyan@gmail.com>
Date: Mon, 21 Nov 2011 16:39:03 +0300
> C assignment can handle struct in6_addr copying.
>
> Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com>
Fair enough, applied.
^ permalink raw reply
* Re: [PATCH net-next] Sweep away N/A fw_version dustbunnies from the .get_drvinfo routine of a number of drivers
From: David Miller @ 2011-11-22 21:53 UTC (permalink / raw)
To: raj
Cc: jcliburn, e1000-devel, netdev, dm, sbhatewara, ron.mercer,
chris.snook, divy
In-Reply-To: <20111121205405.A0FF1290041F@tardy>
From: raj@tardy.cup.hp.com (Rick Jones)
Date: Mon, 21 Nov 2011 12:54:05 -0800 (PST)
> From: Rick Jones <rick.jones2@hp.com>
>
> Per discussion with Ben Hutchings and David Miller, go through and
> remove assignments of "N/A" to fw_version in various drivers'
> .get_drvinfo routines. While there clean-up some use of bare
> constants and such.
>
> Signed-off-by: Rick Jones <rick.jones2@hp.com>
Applied, thanks Rick.
------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraudulent activity, and more. Splunk takes this
data and makes sense of it. IT sense. And common sense.
http://p.sf.net/sfu/splunk-novd2d
_______________________________________________
E1000-devel mailing list
E1000-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/e1000-devel
To learn more about Intel® Ethernet, visit http://communities.intel.com/community/wired
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Benjamin Herrenschmidt @ 2011-11-22 21:58 UTC (permalink / raw)
To: Eric Dumazet
Cc: Christoph Lameter, Christian Kujau, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1321948113.27077.24.camel@edumazet-laptop>
On Tue, 2011-11-22 at 08:48 +0100, Eric Dumazet wrote:
> Le lundi 21 novembre 2011 à 21:18 -0600, Christoph Lameter a écrit :
>
> > Hmmm... That means that c->page points to page not frozen. Per cpu
> > partial pages are frozen until they are reused or until the partial list
> > is flushed.
> >
> > Does this ever happen on x86 or only on other platforms? In put_cpu_partial() the
> > this_cpu_cmpxchg really needs really to be irq safe. this_cpu_cmpxchg is
> > only preempt safe.
> >
> > Index: linux-2.6/mm/slub.c
> > ===================================================================
> > --- linux-2.6.orig/mm/slub.c 2011-11-21 21:15:41.575673204 -0600
> > +++ linux-2.6/mm/slub.c 2011-11-21 21:16:33.442336849 -0600
> > @@ -1969,7 +1969,7 @@
> > page->pobjects = pobjects;
> > page->next = oldpage;
> >
> > - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > + } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > stat(s, CPU_PARTIAL_FREE);
> > return pobjects;
> > }
> >
>
> For x86, I wonder if our !X86_FEATURE_CX16 support is correct on SMP
> machines.
>
> this_cpu_cmpxchg16b_emu() claims to be IRQ safe, but may be buggy...
>
> Could we have somewhere a NMI handler calling kmalloc() ?
Christian and I are on ppc, which uses the generic implementation of
this_cpu_cmpxchg() which is not irq safe. So the above patch is needed
regardless.
Christian, can you try it see if that helps in your case ?
Cheers,
Ben.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* pull request: wireless 2011-11-22 #2
From: John W. Linville @ 2011-11-22 21:56 UTC (permalink / raw)
To: davem; +Cc: linux-wireless, netdev, linux-kernel
In-Reply-To: <20111122193505.GC8452@tuxdriver.com>
Dave,
Here is the latest batch of fixes intended for 3.2. This includes a
correction for a user-visible error in mac80211's debugfs info, a fix
for a potential memory corrupter in prism54, an endian fix for rt2x00,
an endian fix for mac80211, a fix for a NULL derefernce in cfg80211, a
locking fix for p54spi and a deadlock fix also for p54spi.
This reverts the problematic rt2x00 patches from the earlier pull
request.
Please let me know if there are problems!
Thanks,
John
---
The following changes since commit 5eccdf5e06eb67779716ae26142402a1ae9b012c:
tc: comment spelling fixes (2011-11-22 16:37:01 -0500)
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/linville/wireless.git for-davem
Ben Greear (1):
mac80211: Fix AMSDU rate printout in debugfs.
Dan Carpenter (1):
prism54: potential memory corruption in prism54_get_essid()
Gertjan van Wingerde (1):
rt2x00: Fix efuse EEPROM reading on PPC32.
Helmut Schaa (1):
mac80211: Fix endian bug in radiotap header generation
Johannes Berg (1):
cfg80211: fix regulatory NULL dereference
John W. Linville (3):
Revert "rt2x00: handle spurious pci interrupts"
Revert "rt2800pci: handle spurious interrupts"
Merge branch 'master' of git://git.kernel.org/.../linville/wireless into for-davem
Michael Buesch (2):
p54spi: Add missing spin_lock_init
p54spi: Fix workqueue deadlock
Stanislaw Gruszka (2):
rt2800pci: handle spurious interrupts
rt2x00: handle spurious pci interrupts
drivers/net/wireless/p54/p54spi.c | 5 +++--
drivers/net/wireless/prism54/isl_ioctl.c | 2 +-
drivers/net/wireless/rt2x00/rt2800lib.c | 2 +-
net/mac80211/debugfs_sta.c | 4 ++--
net/mac80211/status.c | 8 ++++----
net/wireless/reg.c | 4 ++++
6 files changed, 15 insertions(+), 10 deletions(-)
diff --git a/drivers/net/wireless/p54/p54spi.c b/drivers/net/wireless/p54/p54spi.c
index f18df82..78d0d69 100644
--- a/drivers/net/wireless/p54/p54spi.c
+++ b/drivers/net/wireless/p54/p54spi.c
@@ -588,8 +588,6 @@ static void p54spi_op_stop(struct ieee80211_hw *dev)
WARN_ON(priv->fw_state != FW_STATE_READY);
- cancel_work_sync(&priv->work);
-
p54spi_power_off(priv);
spin_lock_irqsave(&priv->tx_lock, flags);
INIT_LIST_HEAD(&priv->tx_pending);
@@ -597,6 +595,8 @@ static void p54spi_op_stop(struct ieee80211_hw *dev)
priv->fw_state = FW_STATE_OFF;
mutex_unlock(&priv->mutex);
+
+ cancel_work_sync(&priv->work);
}
static int __devinit p54spi_probe(struct spi_device *spi)
@@ -656,6 +656,7 @@ static int __devinit p54spi_probe(struct spi_device *spi)
init_completion(&priv->fw_comp);
INIT_LIST_HEAD(&priv->tx_pending);
mutex_init(&priv->mutex);
+ spin_lock_init(&priv->tx_lock);
SET_IEEE80211_DEV(hw, &spi->dev);
priv->common.open = p54spi_op_start;
priv->common.stop = p54spi_op_stop;
diff --git a/drivers/net/wireless/prism54/isl_ioctl.c b/drivers/net/wireless/prism54/isl_ioctl.c
index d97a2ca..bc2ba80 100644
--- a/drivers/net/wireless/prism54/isl_ioctl.c
+++ b/drivers/net/wireless/prism54/isl_ioctl.c
@@ -778,7 +778,7 @@ prism54_get_essid(struct net_device *ndev, struct iw_request_info *info,
dwrq->flags = 0;
dwrq->length = 0;
}
- essid->octets[essid->length] = '\0';
+ essid->octets[dwrq->length] = '\0';
memcpy(extra, essid->octets, dwrq->length);
kfree(essid);
diff --git a/drivers/net/wireless/rt2x00/rt2800lib.c b/drivers/net/wireless/rt2x00/rt2800lib.c
index 3f183a1..1ba079d 100644
--- a/drivers/net/wireless/rt2x00/rt2800lib.c
+++ b/drivers/net/wireless/rt2x00/rt2800lib.c
@@ -3771,7 +3771,7 @@ static void rt2800_efuse_read(struct rt2x00_dev *rt2x00dev, unsigned int i)
/* Apparently the data is read from end to start */
rt2800_register_read_lock(rt2x00dev, EFUSE_DATA3, ®);
/* The returned value is in CPU order, but eeprom is le */
- rt2x00dev->eeprom[i] = cpu_to_le32(reg);
+ *(u32 *)&rt2x00dev->eeprom[i] = cpu_to_le32(reg);
rt2800_register_read_lock(rt2x00dev, EFUSE_DATA2, ®);
*(u32 *)&rt2x00dev->eeprom[i + 2] = cpu_to_le32(reg);
rt2800_register_read_lock(rt2x00dev, EFUSE_DATA1, ®);
diff --git a/net/mac80211/debugfs_sta.c b/net/mac80211/debugfs_sta.c
index c5f3417..3110cbd 100644
--- a/net/mac80211/debugfs_sta.c
+++ b/net/mac80211/debugfs_sta.c
@@ -274,9 +274,9 @@ static ssize_t sta_ht_capa_read(struct file *file, char __user *userbuf,
PRINT_HT_CAP((htc->cap & BIT(10)), "HT Delayed Block Ack");
- PRINT_HT_CAP((htc->cap & BIT(11)), "Max AMSDU length: "
- "3839 bytes");
PRINT_HT_CAP(!(htc->cap & BIT(11)), "Max AMSDU length: "
+ "3839 bytes");
+ PRINT_HT_CAP((htc->cap & BIT(11)), "Max AMSDU length: "
"7935 bytes");
/*
diff --git a/net/mac80211/status.c b/net/mac80211/status.c
index 80de436..16518f3 100644
--- a/net/mac80211/status.c
+++ b/net/mac80211/status.c
@@ -260,7 +260,7 @@ static void ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band
struct ieee80211_hdr *hdr = (struct ieee80211_hdr *) skb->data;
struct ieee80211_radiotap_header *rthdr;
unsigned char *pos;
- __le16 txflags;
+ u16 txflags;
rthdr = (struct ieee80211_radiotap_header *) skb_push(skb, rtap_len);
@@ -290,13 +290,13 @@ static void ieee80211_add_tx_radiotap_header(struct ieee80211_supported_band
txflags = 0;
if (!(info->flags & IEEE80211_TX_STAT_ACK) &&
!is_multicast_ether_addr(hdr->addr1))
- txflags |= cpu_to_le16(IEEE80211_RADIOTAP_F_TX_FAIL);
+ txflags |= IEEE80211_RADIOTAP_F_TX_FAIL;
if ((info->status.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS) ||
(info->status.rates[0].flags & IEEE80211_TX_RC_USE_CTS_PROTECT))
- txflags |= cpu_to_le16(IEEE80211_RADIOTAP_F_TX_CTS);
+ txflags |= IEEE80211_RADIOTAP_F_TX_CTS;
else if (info->status.rates[0].flags & IEEE80211_TX_RC_USE_RTS_CTS)
- txflags |= cpu_to_le16(IEEE80211_RADIOTAP_F_TX_RTS);
+ txflags |= IEEE80211_RADIOTAP_F_TX_RTS;
put_unaligned_le16(txflags, pos);
pos += 2;
diff --git a/net/wireless/reg.c b/net/wireless/reg.c
index e71f5a6..77e9267 100644
--- a/net/wireless/reg.c
+++ b/net/wireless/reg.c
@@ -2037,6 +2037,10 @@ static int __set_regdom(const struct ieee80211_regdomain *rd)
}
request_wiphy = wiphy_idx_to_wiphy(last_request->wiphy_idx);
+ if (!request_wiphy) {
+ reg_set_request_processed();
+ return -ENODEV;
+ }
if (!last_request->intersect) {
int r;
--
John W. Linville Someday the world will need a hero, and you
linville@tuxdriver.com might be all we have. Be ready.
^ permalink raw reply related
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Benjamin Herrenschmidt @ 2011-11-22 22:16 UTC (permalink / raw)
To: Christian Kujau
Cc: Eric Dumazet, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <alpine.DEB.2.01.1111220038060.8000@trent.utfs.org>
On Tue, 2011-11-22 at 00:39 -0800, Christian Kujau wrote:
> On Tue, 22 Nov 2011 at 08:48, Eric Dumazet wrote:
> > > --- linux-2.6.orig/mm/slub.c 2011-11-21 21:15:41.575673204 -0600
> > > +++ linux-2.6/mm/slub.c 2011-11-21 21:16:33.442336849 -0600
> > > @@ -1969,7 +1969,7 @@
> > > page->pobjects = pobjects;
> > > page->next = oldpage;
> > >
> > > - } while (this_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > > + } while (irqsafe_cpu_cmpxchg(s->cpu_slab->partial, oldpage, page) != oldpage);
> > > stat(s, CPU_PARTIAL_FREE);
> > > return pobjects;
> > > }
>
> Is this a patch to try for my PowerPC machine? With CONFIG_SLUB=y?
>
> > For x86, I wonder if our !X86_FEATURE_CX16 support is correct on SMP
> > machines.
>
> I'm on UP, don't have any x68/SMP machines to test atm :(
Yes, please try the patch with SLUB and let us know if it makes a
difference.
Eric, Christoph, the generic version of this_cpu_cmpxchg() is not
interrupt safe, so I suppose this patch should go in right ?
Cheers,
Ben.
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* CONGRAT!!!
From: Roland Anthony @ 2011-11-22 19:42 UTC (permalink / raw)
To: Recipients
You Won £650,000.00GBP from Sony Ericsson Promotion,Nigeria 2011. Contact Mr. Roland Anthony with Ticket number: SCP/5000021/2011 (roland_1963@filipinos.ca) for your winning claims with your Name,Address,Country,Phone Number
^ permalink raw reply
* Re: [PATCH net-next] Sweep away N/A fw_version dustbunnies from the .get_drvinfo routine of a number of drivers
From: Francois Romieu @ 2011-11-22 22:22 UTC (permalink / raw)
To: Rick Jones; +Cc: netdev
In-Reply-To: <20111121205405.A0FF1290041F@tardy>
Rick Jones <raj@tardy.cup.hp.com> :
[...]
> Per discussion with Ben Hutchings and David Miller, go through and
> remove assignments of "N/A" to fw_version in various drivers'
> .get_drvinfo routines. While there clean-up some use of bare
> constants and such.
Any reason why drivers/net/ethernet/realtek/r8169.c is left in the
cold ?
--
Ueimor
^ permalink raw reply
* Re: WARNING: at mm/slub.c:3357, kernel BUG at mm/slub.c:3413
From: Eric Dumazet @ 2011-11-22 22:31 UTC (permalink / raw)
To: Benjamin Herrenschmidt
Cc: Christian Kujau, Christoph Lameter, Markus Trippelsdorf, Alex,Shi,
linux-kernel@vger.kernel.org, linux-mm@kvack.org, Pekka Enberg,
Matt Mackall, netdev@vger.kernel.org, Tejun Heo
In-Reply-To: <1322000195.14573.13.camel@pasglop>
Le mercredi 23 novembre 2011 à 09:16 +1100, Benjamin Herrenschmidt a
écrit :
> Yes, please try the patch with SLUB and let us know if it makes a
> difference.
>
> Eric, Christoph, the generic version of this_cpu_cmpxchg() is not
> interrupt safe, so I suppose this patch should go in right ?
>
Sure. Dont worry, Christoph is the slub maintainer :)
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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