* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Thomas Gleixner @ 2013-09-16 9:01 UTC (permalink / raw)
To: Fan Du
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <52365021.8040906@windriver.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2076 bytes --]
On Mon, 16 Sep 2013, Fan Du wrote:
> On 2013年09月13日 22:32, Thomas Gleixner wrote:
> > On Fri, 13 Sep 2013, Fan Du wrote:
> > > (2) What I have been bugging you around here for this long time is really
> > > the
> > > second
> > > problem, I'm sorry I didn't make it clearly to you and others, which
> > > is
> > > below:
> > >
> > > Why using wall clock time to calculate soft/hard IPsec events when
> > > xfrm_state timer
> > > out happens in its timeout handler? Because even if xfrm_state using
> > > CLOCK_BOOTTIME,
> > > system wall clock time changing will surely disturb soft/hard IPsec
> > > events, which
> > > you raised your concern about in (*a*).
> >
> > No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
> > basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
> > well. So without a suspend/resume cycle CLOCK_MONOTONIC and
> > CLOCK_BOOTTIME are the same. After a suspend/resume cycle
> > CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
> > the number of seconds spent in suspend.
>
> Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
> suspend/resume time as well as not affected by wall clock time change.
>
> Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
> affected by wall clock time change, as well as keep the timer valid when
> suspend/resume.
>
> A classic way of using timer is:
> a- Arm a timer with specified interval
> b- Wait for the timer to timeout
> c- After the timeout, notify the event to other place in the timer handler.
>
> IPsec key lifetime timer does its this way:
> a- Arm a timer with specified interval
> b- Wait for the timer to timeout
> c- After timeout, in the timer handler, using wall clock time to calculate
> which kind of event to notify user(soft or hard for both key use time,
> and key created time). So the problem arises at this stage if wall clock
> time changed.
And why on earth must it use wall clock time for selecting the event
type?
Thanks,
tglx
^ permalink raw reply
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Ethan Tuttle @ 2013-09-16 8:56 UTC (permalink / raw)
To: Willy Tarreau
Cc: Thomas Petazzoni, Andrew Lunn, Jason Cooper, netdev,
Ezequiel Garcia, Gregory Clément, linux-arm-kernel
In-Reply-To: <20130916065047.GH27487@1wt.eu>
Hi guys. Here's the config I was building with:
https://gist.github.com/anonymous/6578139
It's based on the one I found in archlinuxarm's git repo. I didn't
change any of the options - at least, not manually.
Thanks for the follow up!
Ethan
On Sun, Sep 15, 2013 at 11:50 PM, Willy Tarreau <w@1wt.eu> wrote:
> Hi Thomas,
>
> On Sun, Sep 15, 2013 at 08:57:01PM +0200, Thomas Petazzoni wrote:
>> Hello Ethan,
>>
>> On Sat, 14 Sep 2013 18:05:32 -0700, Ethan Tuttle wrote:
>> > When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
>> > oopses while receiving network traffic (see below). Sending a flood
>> > ping will trigger the oops within a few minutes.
>> >
>> > The stack looks similar, but not identical to, the one reported
>> > earlier by Jochen De Smet[1]. In my case the PC is always
>> > __rcu_read_lock.
>> >
>> > A git bisect found a878764 "Merge
>> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
>> > first bad commit... interesting, because neither of the merge parents
>> > produce the oops. I rebased the net changes onto the other merge
>> > parent and bisected that series, which identified 702821f "net: revert
>> > 8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
>> > Indeed, reverting 702821f from 3.11 produces a kernel which stands up
>> > to a ping flood for hours.
>> >
>> > Each of the times I reproduced this, it was identified as "Unhandled
>> > prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
>> > got "unknown 16 (0x400)".
>> >
>> > I'm assuming this is an mvneta bug that was exposed by 702821f.
>> > That's just a guess, and I don't have the skills to debug this any
>> > further. In any case, I figured the maintainers would want to know
>> > about it.
>>
>> Thanks a lot for the report and the detailed investigation.
>> Unfortunately, I don't have Armada 370 hardware with me this week, so
>> I'm unable to test and reproduce the issue.
>>
>> However, I've added a bunch of Armada 370 people/maintainers in Cc,
>> hopefully they can at least try to reproduce and confirm that reverting
>> this patch makes the problem go away, which would confirm that we
>> should look for a bug in the mvneta driver around this problem.
>
> I'm currently testing on 3.11.1 (which I had here) and am not getting
> any issue after 50M packets. My kernel is running in thumb mode and
> without SMP.
>
> Ethan, we'll need your config I guess.
>
> Thanks,
> Willy
>
^ permalink raw reply
* Re: usbnet transmit path problems
From: Oliver Neukum @ 2013-09-16 8:13 UTC (permalink / raw)
To: Ming Lei; +Cc: David Laight, Network Development, linux-usb
In-Reply-To: <CACVXFVNrbeEthBH0vGKN2gymoSwu3jTkcGicKNU1-Oez8bNhvg-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
On Thu, 2013-09-12 at 09:56 +0800, Ming Lei wrote:
> On Thu, Sep 12, 2013 at 12:05 AM, David Laight <David.Laight-JxhZ9S5GRejQT0dZR+AlfA@public.gmane.org> wrote:
> Patches are always welcome, :-)
Indeed, I think your patch, if no better alternatives come up soon,
should be taken.
> > None of this is helping me sort out why netperf udp rr tests with
> > burst 19 are losing all the packets at once :-(
>
> If you can share your test case, guys in list may help you to troubleshoot
> it, :-)
Indeed.
Regards
Oliver
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: mvneta: oops in __rcu_read_lock on mirabox
From: Willy Tarreau @ 2013-09-16 6:50 UTC (permalink / raw)
To: Thomas Petazzoni
Cc: Ethan Tuttle, Andrew Lunn, Jason Cooper, netdev, Ezequiel Garcia,
Gregory Clément, linux-arm-kernel
In-Reply-To: <20130915205701.5c61a444@skate>
Hi Thomas,
On Sun, Sep 15, 2013 at 08:57:01PM +0200, Thomas Petazzoni wrote:
> Hello Ethan,
>
> On Sat, 14 Sep 2013 18:05:32 -0700, Ethan Tuttle wrote:
> > When I upgraded my mirabox from 3.11-rc4 to 3.11, I started seeing
> > oopses while receiving network traffic (see below). Sending a flood
> > ping will trigger the oops within a few minutes.
> >
> > The stack looks similar, but not identical to, the one reported
> > earlier by Jochen De Smet[1]. In my case the PC is always
> > __rcu_read_lock.
> >
> > A git bisect found a878764 "Merge
> > git://git.kernel.org/pub/scm/linux/kernel/git/davem/net" to be the
> > first bad commit... interesting, because neither of the merge parents
> > produce the oops. I rebased the net changes onto the other merge
> > parent and bisected that series, which identified 702821f "net: revert
> > 8728c544a9c ("net: dev_pick_tx() fix")" as the first bad commit.
> > Indeed, reverting 702821f from 3.11 produces a kernel which stands up
> > to a ping flood for hours.
> >
> > Each of the times I reproduced this, it was identified as "Unhandled
> > prefetch abort: unknown 25 (0x409) at 0xc0036ea0", except once when I
> > got "unknown 16 (0x400)".
> >
> > I'm assuming this is an mvneta bug that was exposed by 702821f.
> > That's just a guess, and I don't have the skills to debug this any
> > further. In any case, I figured the maintainers would want to know
> > about it.
>
> Thanks a lot for the report and the detailed investigation.
> Unfortunately, I don't have Armada 370 hardware with me this week, so
> I'm unable to test and reproduce the issue.
>
> However, I've added a bunch of Armada 370 people/maintainers in Cc,
> hopefully they can at least try to reproduce and confirm that reverting
> this patch makes the problem go away, which would confirm that we
> should look for a bug in the mvneta driver around this problem.
I'm currently testing on 3.11.1 (which I had here) and am not getting
any issue after 50M packets. My kernel is running in thumb mode and
without SMP.
Ethan, we'll need your config I guess.
Thanks,
Willy
^ permalink raw reply
* Re: [PATCH] ethernet/arc/arc_emac: Fix huge delays in large file copies
From: Vineet Gupta @ 2013-09-16 5:43 UTC (permalink / raw)
To: greg Kroah-Hartman
Cc: David Miller, netdev, Alexey.Brodkin, linux-kernel,
stable@vger.kernel.org
In-Reply-To: <522EBBD2.1060003@synopsys.com>
On 09/10/2013 11:57 AM, Vineet Gupta wrote:
> On 09/05/2013 11:55 PM, David Miller wrote:
>> From: Vineet Gupta <Vineet.Gupta1@synopsys.com>
>> Date: Wed, 4 Sep 2013 17:17:15 +0530
>>
>>> copying large files to a NFS mounted host was taking absurdly large
>>> time.
>>>
>>> Turns out that TX BD reclaim had a sublte bug.
>>>
>>> Loop starts off from @txbd_dirty cursor and stops when it hits a BD
>>> still in use by controller. However when it stops it needs to keep the
>>> cursor at that very BD to resume scanning in next iteration. However it
>>> was erroneously incrementing the cursor, causing the next scan(s) to
>>> fail too, unless the BD chain was completely drained out.
>>>
>>> [ARCLinux]$ ls -l -sh /disk/log.txt
>>> 17976 -rw-r--r-- 1 root root 17.5M Sep /disk/log.txt
>>>
>>> ========== Before =====================
>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>> real 31m 7.95s
>>> user 0m 0.00s
>>> sys 0m 0.10s
>>>
>>> ========== After =====================
>>> [ARCLinux]$ time cp /disk/log.txt /mnt/.
>>> real 0m 24.33s
>>> user 0m 0.00s
>>> sys 0m 0.19s
>>>
>>> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
>>
>> Applied.
>>
>
> Hi Greg,
>
> This needs a stable backport (3.11).
> Mainline commit 27082ee1b92f4d41e78b85
>
> Thx,
> -Vineet
Hi Greg,
I didn't spot this one in your stable-queue for 3.11.
Please apply.
Thx,
Vineet
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: Wei Yang @ 2013-09-16 5:28 UTC (permalink / raw)
To: David Miller; +Cc: weiyang, dm, netdev
In-Reply-To: <20130916.005324.187580687457026092.davem@davemloft.net>
On Mon, Sep 16, 2013 at 12:53:24AM -0400, David Miller wrote:
>From: Wei Yang <weiyang@linux.vnet.ibm.com>
>Date: Sun, 15 Sep 2013 21:53:00 +0800
>
>> When driver registration fails, we need to clean up the resources allocated
>> before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>>
>> This patch destroies the workqueue when registration fails.
>>
>> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
>
>Applied.
Thanks~
--
Richard Yang
Help you, Help me
^ permalink raw reply
* Re: [PATCH] net: ps3_gelic: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:56 UTC (permalink / raw)
To: michael.opdenacker; +Cc: geoff, netdev, cbe-oss-dev, linux-kernel
In-Reply-To: <1379046798-7192-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:33:18 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/toshiba/ps3_gelic_net.c
>
> It's a NOOP since 2.6.35 and I will remove it one day ;)
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: smsc: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:56 UTC (permalink / raw)
To: michael.opdenacker; +Cc: steve.glendinning, netdev, linux-kernel, will.deacon
In-Reply-To: <1379046467-6900-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:27:47 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/smsc/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: pasemi: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: olof, netdev, linux-kernel
In-Reply-To: <1379046084-6825-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:21:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/pasemi/pasemi_mac.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: natsemi: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045813-6762-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:16:53 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> code in drivers/net/ethernet/natsemi/
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: ks8851-ml: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045410-6687-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:10:10 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/micrel/ks8851_mll.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: pxa168_eth: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379045063-6604-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 06:04:23 +0200
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: lantiq_etop: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: netdev, linux-kernel
In-Reply-To: <1379044782-6542-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:59:42 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/lantiq_etop.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: hp100: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker; +Cc: perex, netdev, linux-kernel
In-Reply-To: <1379044284-6448-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:51:24 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/hp/hp100.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH] net: fec: remove deprecated IRQF_DISABLED
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: michael.opdenacker
Cc: fabio.estevam, frank.li, B38611, jim_baxter, netdev, linux-kernel
In-Reply-To: <1379043878-6376-1-git-send-email-michael.opdenacker@free-electrons.com>
From: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Date: Fri, 13 Sep 2013 05:44:38 +0200
> This patch proposes to remove the IRQF_DISABLED flag from
> drivers/net/ethernet/freescale/fec_main.c
>
> It's a NOOP since 2.6.35 and it will be removed one day.
>
> Signed-off-by: Michael Opdenacker <michael.opdenacker@free-electrons.com>
Applied.
^ permalink raw reply
* Re: [PATCH net-next 0/2] bridge: fix NULL pointer deref of br_port_get_rcu
From: David Miller @ 2013-09-16 4:55 UTC (permalink / raw)
To: honkiko; +Cc: netdev, eric.dumazet, vyasevic, zhiguohong
In-Reply-To: <1379169748-767-1-git-send-email-zhiguohong@tencent.com>
From: Hong Zhiguo <honkiko@gmail.com>
Date: Sat, 14 Sep 2013 22:42:26 +0800
> Hong Zhiguo (2):
> bridge: use br_port_get_rtnl within rtnl lock
> bridge: fix NULL pointer deref of br_port_get_rcu
Both applied and queued up for -stable, thanks.
^ permalink raw reply
* Re: [PATCH net 1/1] qlcnic: Fix VF reset recovery
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: manish.chopra; +Cc: netdev, Dept-HSGLinuxNICDev
In-Reply-To: <1379067227-10362-1-git-send-email-manish.chopra@qlogic.com>
From: Manish Chopra <manish.chopra@qlogic.com>
Date: Fri, 13 Sep 2013 06:13:47 -0400
> o At the time of firmware hang "adapter->need_fw_reset" variable gets
> set but after re-initialization of firmware OR at the time of VF
> re-initialization that variable was not getting cleared which
> was leading to failure in VF reset recovery.Fix it by clearing
> this variable before re-initializing VF
>
> Signed-off-by: Manish Chopra <manish.chopra@qlogic.com>
Applied.
^ permalink raw reply
* Re: [net] vxlan: Fix sparse warnings
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: jeffrey.t.kirsher; +Cc: joseph.gasparakis, netdev, gospo, sassmann
In-Reply-To: <1379082853-28172-1-git-send-email-jeffrey.t.kirsher@intel.com>
From: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Date: Fri, 13 Sep 2013 07:34:13 -0700
> From: Joseph Gasparakis <joseph.gasparakis@intel.com>
>
> This patch fixes sparse warnings when incorrectly handling the port number
> and using int instead of unsigned int iterating through &vn->sock_list[].
> Keeping the port as __be16 also makes things clearer wrt endianess.
> Also, it was pointed out that vxlan_get_rx_port() had unnecessary checks
> which got removed.
>
> Signed-off-by: Joseph Gasparakis <joseph.gasparakis@intel.com>
> Signed-off-by: Jeff Kirsher <jeffrey.t.kirsher@intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH] atm: nicstar: fix regression made by previous patch
From: David Miller @ 2013-09-16 4:54 UTC (permalink / raw)
To: andriy.shevchenko; +Cc: chas, linux-atm-general, netdev
In-Reply-To: <1379084458-23793-1-git-send-email-andriy.shevchenko@linux.intel.com>
From: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Date: Fri, 13 Sep 2013 18:00:58 +0300
> The commit 8390f814 "atm: nicstar: re-use native mac_pton() helper" did a
> usefull thing. However, mac_pton() returns 1 in the case of the successfully
> parsed input. This patch fixes a typo.
>
> Signed-off-by: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Applied.
^ permalink raw reply
* Re: [PATCH v3] bonding: Make alb learning packet interval configurable
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: nhorman; +Cc: netdev, vfalico, fubar, andy
In-Reply-To: <1379084733-9219-1-git-send-email-nhorman@tuxdriver.com>
From: Neil Horman <nhorman@tuxdriver.com>
Date: Fri, 13 Sep 2013 11:05:33 -0400
> running bonding in ALB mode requires that learning packets be sent periodically,
> so that the switch knows where to send responding traffic. However, depending
> on switch configuration, there may not be any need to send traffic at the
> default rate of 3 packets per second, which represents little more than wasted
> data. Allow the ALB learning packet interval to be made configurable via sysfs
>
> Signed-off-by: Neil Horman <nhorman@tuxdriver.com>
> Acked-by: Acked-by: Veaceslav Falico <vfalico@redhat.com>
Applied, thanks Neil.
^ permalink raw reply
* Re: [PATCH 1/1] isdn: hfcpci_softirq: get func return to suppress compiler warning
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: antonio.alecrim; +Cc: isdn, standby24x7, netdev, linux-kernel
In-Reply-To: <1379179240-21927-1-git-send-email-antonio.alecrim@gmail.com>
From: Antonio Alecrim Jr <antonio.alecrim@gmail.com>
Date: Sat, 14 Sep 2013 14:20:40 -0300
> Signed-off-by: Antonio Alecrim Jr <antonio.alecrim@gmail.com>
Applied.
^ permalink raw reply
* Re: [PATCH] cxgb4: remove workqueue when driver registration fails
From: David Miller @ 2013-09-16 4:53 UTC (permalink / raw)
To: weiyang; +Cc: dm, netdev
In-Reply-To: <1379253180-10292-1-git-send-email-weiyang@linux.vnet.ibm.com>
From: Wei Yang <weiyang@linux.vnet.ibm.com>
Date: Sun, 15 Sep 2013 21:53:00 +0800
> When driver registration fails, we need to clean up the resources allocated
> before. cxgb4 missed to destroy the workqueue allocated at the very beginning.
>
> This patch destroies the workqueue when registration fails.
>
> Signed-off-by: Wei Yang <weiyang@linux.vnet.ibm.com>
Applied.
^ permalink raw reply
* Re: [PATCH 1/1] net: race condition when removing virtual net_device
From: Francesco Ruggeri @ 2013-09-16 2:54 UTC (permalink / raw)
To: Eric W. Biederman
Cc: David S. Miller, Eric Dumazet, Jiri Pirko, Alexander Duyck,
Cong Wang, netdev
In-Reply-To: <87d2ocrx9b.fsf@xmission.com>
On Fri, Sep 13, 2013 at 6:46 PM, Eric W. Biederman
<ebiederm@xmission.com> wrote:
> Francesco Ruggeri <fruggeri@aristanetworks.com> writes:
>
>> On Thu, Sep 12, 2013 at 10:50 PM, Eric W. Biederman
>> <ebiederm@xmission.com> wrote:
>>
>> I do have some concerns about both correctness and feasibility of this approach.
>>
>> About 2), namespace dependent operations triggered by unregistering
>> the virtual devices (eg rt_flush_dev, dst_dev_event/dst_ifdown and
>> probably more) would not be done in the namespaces where they should.
>
> Yes they will. That is what dev_change_net_namespace does.
You are right, I don't know what I was thinking.
>
> It was worth a second look. I can not find anything wrong with your
> patch but I can not convince myself that it is correct either. The
> moving around the loopback device in the net dev todo list to prevent
> deadlock I can't imagine why you are doing that.
>
That is in order not to introduce a potential deadlock when multiple
namespaces are destroyed in default_device_exit_batch.
Take the same veth scenario as before:
v0 in namespace ns0 (loopback_dev lo0) and similarly for v1, ns1 and lo1.
Assume two processes destroy ns0 and ns1. cleanup_net is executed in a
workqueue and the two namespaces can end up being processed in the
same instance of cleanup_net/ops_exit_list/default_device_exit_batch.
default_device_exit_batch traverses each namespace's dev_base list and
unregister_netdevice_queue is executed in this order:
v0 v1 lo0 v1 v0 lo1.
unregister_netdevice_queue is executed twice on v0 and v1 but that is
ok because it uses list_move_tail and only the last one sticks.
The resulting list for unregister_netdevice_many is:
lo0 v1 v0 lo1.
If v0 holds a reference to lo0 there will be a deadlock in
netdev_run_todo if v0 does not come before lo0 in net_todo_list. By
pushing all loopback_devs to the end of net_todo_list this situation
is avoided.
This is the sequence with today's (actually 3.4) code:
unregister_netdevice_queue: v0 (ns ffff880037aecd00)
unregister_netdevice_queue: v1 (ns ffff880037aed800)
unregister_netdevice_queue: lo (ns ffff880037aecd00)
unregister_netdevice_queue: v1 (ns ffff880037aed800)
unregister_netdevice_queue: v0 (ns ffff880037aecd00)
unregister_netdevice_queue: lo (ns ffff880037aed800)
unregister_netdevice_many: lo (ns ffff880037aecd00) v1 (ns
ffff880037aed800) v0 (ns ffff880037aecd00) lo (ns ffff880037aed800)
netdev_run_todo: lo (ns ffff880037aecd00) v1 (ns ffff880037aed800) v0
(ns ffff880037aecd00) lo (ns ffff880037aed800)
and this is the sequence after pushing the loopback_devs to the tail
of net_todo_list:
unregister_netdevice_queue: v0 (ns ffff8800379f8000)
unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
unregister_netdevice_queue: lo (ns ffff8800379f8000)
unregister_netdevice_queue: v1 (ns ffff8800378c0b00)
unregister_netdevice_queue: v0 (ns ffff8800379f8000)
unregister_netdevice_queue: lo (ns ffff8800378c0b00)
unregister_netdevice_many: lo (ns ffff8800379f8000) v1 (ns
ffff8800378c0b00) v0 (ns ffff8800379f8000) lo (ns ffff8800378c0b00)
netdev_run_todo: v1 (ns ffff8800378c0b00) v0 (ns ffff8800379f8000) lo
(ns ffff8800379f8000) lo (ns ffff8800378c0b00)
Should we take this discussion offline?
I do appreciate your spending time on this.
Thanks,
Francesco
>
> Eric
>
^ permalink raw reply
* Re: [PATCHv3 linux-next] hrtimer: Add notifier when clock_was_set was called
From: Fan Du @ 2013-09-16 0:26 UTC (permalink / raw)
To: Thomas Gleixner
Cc: David Miller, herbert, steffen.klassert, dborkman, linux-kernel,
netdev, John Stultz
In-Reply-To: <alpine.DEB.2.02.1309131628250.4089@ionos.tec.linutronix.de>
Hi, Thomas
On 2013年09月13日 22:32, Thomas Gleixner wrote:
> On Fri, 13 Sep 2013, Fan Du wrote:
>> (2) What I have been bugging you around here for this long time is really the
>> second
>> problem, I'm sorry I didn't make it clearly to you and others, which is
>> below:
>>
>> Why using wall clock time to calculate soft/hard IPsec events when
>> xfrm_state timer
>> out happens in its timeout handler? Because even if xfrm_state using
>> CLOCK_BOOTTIME,
>> system wall clock time changing will surely disturb soft/hard IPsec
>> events, which
>> you raised your concern about in (*a*).
>
> No CLOCK_BOOTTIME is not affected by wall clock time changes. It's
> basically CLOCK_MONOTONIC, it just keeps counting the suspend time as
> well. So without a suspend/resume cycle CLOCK_MONOTONIC and
> CLOCK_BOOTTIME are the same. After a suspend/resume cycle
> CLOCK_BOOTTIME will be N seconds ahead of CLOCK_MONOTONIC, where N is
> the number of seconds spent in suspend.
Sorry for the ambiguity. Yes, CLOCK_BOOTTIME is monotonic *and* counting
suspend/resume time as well as not affected by wall clock time change.
Using CLOCK_BOOTTIME guarantees b- will timeout in a right manner, i.e., not
affected by wall clock time change, as well as keep the timer valid when
suspend/resume.
A classic way of using timer is:
a- Arm a timer with specified interval
b- Wait for the timer to timeout
c- After the timeout, notify the event to other place in the timer handler.
IPsec key lifetime timer does its this way:
a- Arm a timer with specified interval
b- Wait for the timer to timeout
c- After timeout, in the timer handler, using wall clock time to calculate
which kind of event to notify user(soft or hard for both key use time,
and key created time). So the problem arises at this stage if wall clock
time changed.
Thanks
> Thanks,
>
> tglx
>
--
浮沉随浪只记今朝笑
--fan
^ permalink raw reply
* [PATCH] bgmac: implement unaligned addressing for DMA rings that support it
From: Rafał Miłecki @ 2013-09-15 21:13 UTC (permalink / raw)
To: netdev, David S. Miller; +Cc: Hauke Mehrtens, Rafał Miłecki
This is important patch for new devices that support unaligned
addressing. That devices suffer from the backward-compatibility bug in
DMA engine. In theory we should be able to use old mechanism, but in
practice DMA address seems to be randomly copied into status register
when hardware reaches end of a ring. This breaks reading slot number
from status register and we can't use DMA anymore.
Signed-off-by: Rafał Miłecki <zajec5@gmail.com>
---
drivers/net/ethernet/broadcom/bgmac.c | 38 ++++++++++++++++++++++++---------
drivers/net/ethernet/broadcom/bgmac.h | 2 ++
2 files changed, 30 insertions(+), 10 deletions(-)
diff --git a/drivers/net/ethernet/broadcom/bgmac.c b/drivers/net/ethernet/broadcom/bgmac.c
index 59f3e0c..249468f 100644
--- a/drivers/net/ethernet/broadcom/bgmac.c
+++ b/drivers/net/ethernet/broadcom/bgmac.c
@@ -157,6 +157,7 @@ static netdev_tx_t bgmac_dma_tx_add(struct bgmac *bgmac,
if (++ring->end >= BGMAC_TX_RING_SLOTS)
ring->end = 0;
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_INDEX,
+ ring->index_base +
ring->end * sizeof(struct bgmac_dma_desc));
/* Always keep one slot free to allow detecting bugged calls. */
@@ -181,6 +182,8 @@ static void bgmac_dma_tx_free(struct bgmac *bgmac, struct bgmac_dma_ring *ring)
/* The last slot that hardware didn't consume yet */
empty_slot = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_TX_STATUS);
empty_slot &= BGMAC_DMA_TX_STATDPTR;
+ empty_slot -= ring->index_base;
+ empty_slot &= BGMAC_DMA_TX_STATDPTR;
empty_slot /= sizeof(struct bgmac_dma_desc);
while (ring->start != empty_slot) {
@@ -274,6 +277,8 @@ static int bgmac_dma_rx_read(struct bgmac *bgmac, struct bgmac_dma_ring *ring,
end_slot = bgmac_read(bgmac, ring->mmio_base + BGMAC_DMA_RX_STATUS);
end_slot &= BGMAC_DMA_RX_STATDPTR;
+ end_slot -= ring->index_base;
+ end_slot &= BGMAC_DMA_RX_STATDPTR;
end_slot /= sizeof(struct bgmac_dma_desc);
ring->end = end_slot;
@@ -418,9 +423,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
ring = &bgmac->tx_ring[i];
ring->num_slots = BGMAC_TX_RING_SLOTS;
ring->mmio_base = ring_base[i];
- if (bgmac_dma_unaligned(bgmac, ring, BGMAC_DMA_RING_TX))
- bgmac_warn(bgmac, "TX on ring 0x%X supports unaligned addressing but this feature is not implemented\n",
- ring->mmio_base);
/* Alloc ring of descriptors */
size = ring->num_slots * sizeof(struct bgmac_dma_desc);
@@ -435,6 +437,13 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
if (ring->dma_base & 0xC0000000)
bgmac_warn(bgmac, "DMA address using 0xC0000000 bit(s), it may need translation trick\n");
+ ring->unaligned = bgmac_dma_unaligned(bgmac, ring,
+ BGMAC_DMA_RING_TX);
+ if (ring->unaligned)
+ ring->index_base = lower_32_bits(ring->dma_base);
+ else
+ ring->index_base = 0;
+
/* No need to alloc TX slots yet */
}
@@ -444,9 +453,6 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
ring = &bgmac->rx_ring[i];
ring->num_slots = BGMAC_RX_RING_SLOTS;
ring->mmio_base = ring_base[i];
- if (bgmac_dma_unaligned(bgmac, ring, BGMAC_DMA_RING_RX))
- bgmac_warn(bgmac, "RX on ring 0x%X supports unaligned addressing but this feature is not implemented\n",
- ring->mmio_base);
/* Alloc ring of descriptors */
size = ring->num_slots * sizeof(struct bgmac_dma_desc);
@@ -462,6 +468,13 @@ static int bgmac_dma_alloc(struct bgmac *bgmac)
if (ring->dma_base & 0xC0000000)
bgmac_warn(bgmac, "DMA address using 0xC0000000 bit(s), it may need translation trick\n");
+ ring->unaligned = bgmac_dma_unaligned(bgmac, ring,
+ BGMAC_DMA_RING_RX);
+ if (ring->unaligned)
+ ring->index_base = lower_32_bits(ring->dma_base);
+ else
+ ring->index_base = 0;
+
/* Alloc RX slots */
for (j = 0; j < ring->num_slots; j++) {
err = bgmac_dma_rx_skb_for_slot(bgmac, &ring->slots[j]);
@@ -489,12 +502,14 @@ static void bgmac_dma_init(struct bgmac *bgmac)
for (i = 0; i < BGMAC_MAX_TX_RINGS; i++) {
ring = &bgmac->tx_ring[i];
- /* We don't implement unaligned addressing, so enable first */
- bgmac_dma_tx_enable(bgmac, ring);
+ if (!ring->unaligned)
+ bgmac_dma_tx_enable(bgmac, ring);
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_RINGLO,
lower_32_bits(ring->dma_base));
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_TX_RINGHI,
upper_32_bits(ring->dma_base));
+ if (ring->unaligned)
+ bgmac_dma_tx_enable(bgmac, ring);
ring->start = 0;
ring->end = 0; /* Points the slot that should *not* be read */
@@ -505,12 +520,14 @@ static void bgmac_dma_init(struct bgmac *bgmac)
ring = &bgmac->rx_ring[i];
- /* We don't implement unaligned addressing, so enable first */
- bgmac_dma_rx_enable(bgmac, ring);
+ if (!ring->unaligned)
+ bgmac_dma_rx_enable(bgmac, ring);
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGLO,
lower_32_bits(ring->dma_base));
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_RINGHI,
upper_32_bits(ring->dma_base));
+ if (ring->unaligned)
+ bgmac_dma_rx_enable(bgmac, ring);
for (j = 0, dma_desc = ring->cpu_base; j < ring->num_slots;
j++, dma_desc++) {
@@ -531,6 +548,7 @@ static void bgmac_dma_init(struct bgmac *bgmac)
}
bgmac_write(bgmac, ring->mmio_base + BGMAC_DMA_RX_INDEX,
+ ring->index_base +
ring->num_slots * sizeof(struct bgmac_dma_desc));
ring->start = 0;
diff --git a/drivers/net/ethernet/broadcom/bgmac.h b/drivers/net/ethernet/broadcom/bgmac.h
index 12a35cf..66c8afb 100644
--- a/drivers/net/ethernet/broadcom/bgmac.h
+++ b/drivers/net/ethernet/broadcom/bgmac.h
@@ -384,6 +384,8 @@ struct bgmac_dma_ring {
u16 mmio_base;
struct bgmac_dma_desc *cpu_base;
dma_addr_t dma_base;
+ u32 index_base; /* Used for unaligned rings only, otherwise 0 */
+ bool unaligned;
struct bgmac_slot_info slots[BGMAC_RX_RING_SLOTS];
};
--
1.7.10.4
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox