Re: [PATCH] net: sky2: Fix shutdown crash

[Sudeep Holla]

On 17/11/16 15:14, Jeremy Linton wrote:

The sky2 frequently crashes during machine shutdown with:

sky2_get_stats+0x60/0x3d8 [sky2]
dev_get_stats+0x68/0xd8
rtnl_fill_stats+0x54/0x140
rtnl_fill_ifinfo+0x46c/0xc68
rtmsg_ifinfo_build_skb+0x7c/0xf0
rtmsg_ifinfo.part.22+0x3c/0x70
rtmsg_ifinfo+0x50/0x5c
netdev_state_change+0x4c/0x58
linkwatch_do_dev+0x50/0x88
__linkwatch_run_queue+0x104/0x1a4
linkwatch_event+0x30/0x3c
process_one_work+0x140/0x3e0
worker_thread+0x60/0x44c
kthread+0xdc/0xf0
ret_from_fork+0x10/0x50

This is caused by the sky2 being called after it has been shutdown.
A previous thread about this can be found here:

https://lkml.org/lkml/2016/4/12/410

An alternative fix is to assure that IFF_UP gets cleared by
calling dev_close() during shutdown. This is similar to what the
bnx2/tg3/xgene and maybe others are doing to assure that the driver
isn't being called following _shutdown().

Signed-off-by: Jeremy Linton <jeremy.lin...@arm.com>


Since this issue has been very random and on/off recently, it's quite
hard to test this and confirm. However I did around 20 reboot/shutdown
and could not reproduce the issue after applying this patch. So,

Tested-by: Sudeep Holla <sudeep.ho...@arm.com>

--
Regards,
Sudeep

Re: [PATCH RESEND 8/8] af_unix: charge buffers to kmemcg

[Sudeep Holla]

On 23/08/16 17:44, Vladimir Davydov wrote:

Hello,

On Tue, Aug 23, 2016 at 02:48:11PM +0100, Sudeep K N wrote:

On Tue, May 24, 2016 at 5:36 PM, Vladimir Davydov
 wrote:

On Tue, May 24, 2016 at 06:02:06AM -0700, Eric Dumazet wrote:

On Tue, 2016-05-24 at 11:49 +0300, Vladimir Davydov wrote:

Unix sockets can consume a significant amount of system memory, hence
they should be accounted to kmemcg.

Since unix socket buffers are always allocated from process context,
all we need to do to charge them to kmemcg is set __GFP_ACCOUNT in
sock->sk_allocation mask.


I have two questions :

1) What happens when a buffer, allocated from socket  lands in a
different socket , maybe owned by another user/process.

Who owns it now, in term of kmemcg accounting ?


We never move memcg charges. E.g. if two processes from different
cgroups are sharing a memory region, each page will be charged to the
process which touched it first. Or if two processes are working with the
same directory tree, inodes and dentries will be charged to the first
user. The same is fair for unix socket buffers - they will be charged to
the sender.



2) Has performance impact been evaluated ?


I ran netperf STREAM_STREAM with default options in a kmemcg on
a 4 core x 2 HT box. The results are below:

 # clientsbandwidth (10^6bits/sec)
base  patched
 1  67643 +-  725  64874 +-  353- 4.0 %
 4 193585 +- 2516 186715 +- 1460- 3.5 %
 8 194820 +-  377 187443 +- 1229- 3.7 %

So the accounting doesn't come for free - it takes ~4% of performance.
I believe we could optimize it by using per cpu batching not only on
charge, but also on uncharge in memcg core, but that's beyond the scope
of this patch set - I'll take a look at this later.

Anyway, if performance impact is found to be unacceptable, it is always
possible to disable kmem accounting at boot time (cgroup.memory=nokmem)
or not use memory cgroups at runtime at all (thanks to jump labels
there'll be no overhead even if they are compiled in).



I started seeing almost 10% degradation in the hackbench score with v4.8-rc1
Bisecting it resulted in this patch, i.e. Commit 3aa9799e1364 ("af_unix: charge
buffers to kmemcg") in the mainline.

As per the commit log, it seems like that's expected but I was not sure about
the margin. I also see the hackbench score is more inconsistent after this
patch, but I may be wrong as that's based on limited observation.

Is this something we can ignore as hackbench is more synthetic compared
to the gain this patch provides in some real workloads ?


AFAIU hackbench essentially measures the rate of sending data over a
unix socket back and forth between processes running on different cpus,
so it isn't a surprise that the patch resulted in a degradation, as it
makes every skb page allocation/deallocation inc/dec an atomic counter
inside memcg. The more processes/cpus running in the same cgroup are
involved in this test, the more significant the overhead of this atomic
counter is going to be.



Understood.


The degradation is not unavoidable - it can be fixed by making kmem
charge/uncharge code use per-cpu batches. The infrastructure for this
already exists in memcontrol.c. If it were not for the legacy
mem_cgroup->kmem counter (which is actually useless and will be dropped
in cgroup v2), the issue would be pretty easy to fix. However, this
legacy counter makes a possible implementation quite messy, so I'd like
to postpone it until cgroup v2 has finally settled down.



Sure


Regarding your problem. As a workaround you can either start your
workload in the root memory cgroup or disable kmem accounting for memory
cgroups altogether (via cgroup.memory=nokmem boot option). If you find
the issue critical, I don't mind reverting the patch - we can always
re-apply it once per-cpu batches are implemented for kmem charges.



I did try "cgroup.memory=nokmem" as specified in the commit message, I
saw the result to be not so consistent. I need to check again to be sure.

I am not asking to revert, just wanted to know if that's expected so
that we can adjust the scores when comparing especially if we are using
it as some kind of benchmark in development.

--
Regards,
Sudeep

Re: [PATCH 3/3] RFC: net: smsc911x: add wake-up event interrupt support

[Sudeep Holla]

On 08/07/16 10:07, Linus Walleij wrote:

The SMSC911x have a line out of the chip called "PME",
Power Management Event. When connected to an asynchronous
interrupt controller this is able to wake the system up
from sleep in response to certain network events.

This is the first attempt to support this in the Linux
driver: the Qualcomm APQ8060 Dragonboard has this line
routed to a GPIO line on the primary SoC padring, and as
such it can be armed as a wakeup interrupt.

The patch is inspired by the wakeup code in the RTC
subsystem.

The code looks for an additional interrupt - apart from the
ordinary device interrupt - and in case that is present,
we register an interrupt handler to respons to this,
and flag the device and this interrupt as a wakeup.

Cc: Sudeep Holla <sudeep.ho...@arm.com>
Cc: Alexandre Belloni <alexandre.bell...@free-electrons.com>
Cc: Tony Lindgren <t...@atomide.com>
Cc: Rafael J. Wysocki <r...@rjwysocki.net>
Cc: John Stultz <john.stu...@linaro.org>
Signed-off-by: Linus Walleij <linus.wall...@linaro.org>
---
Added some wakeup people at CC who can (hopefully) tell me if
I'm doing this right or not.
---
  drivers/net/ethernet/smsc/smsc911x.c | 48 
  1 file changed, 48 insertions(+)

diff --git a/drivers/net/ethernet/smsc/smsc911x.c 
b/drivers/net/ethernet/smsc/smsc911x.c
index 125d58ac22bd..e43755ae130a 100644
--- a/drivers/net/ethernet/smsc/smsc911x.c
+++ b/drivers/net/ethernet/smsc/smsc911x.c


[...]


@@ -2525,6 +2540,33 @@ static int smsc911x_drv_probe(struct platform_device 
*pdev)
goto out_disable_resources;
}

+   irq = platform_get_irq(pdev, 1);
+   if (irq == -EPROBE_DEFER) {
+   retval = -EPROBE_DEFER;
+   goto out_disable_resources;
+   /* It's perfectly fine to not have a PME IRQ */
+   } else if (irq > 0) {
+   char *pme_name;
+
+   /*
+* The Power Management Event (PME) IRQ appears as
+* a pulse waking up the system from sleep in response to  a
+* network event.
+*/
+   retval = request_threaded_irq(irq, NULL,
+ smsc911x_pme_irq_thread,
+ IRQF_ONESHOT, "smsc911x-pme",
+ dev);
+   if (retval) {
+   SMSC_WARN(pdata, probe,
+   "Unable to claim requested PME irq: %d", irq);
+   goto out_disable_resources;
+   }
+   pdata->pme_irq = irq;
+   device_init_wakeup(>dev, true);
+   dev_pm_set_wake_irq(>dev, irq);
+   }
+
netif_carrier_off(dev);

retval = register_netdev(dev);
@@ -2613,6 +2655,9 @@ static int smsc911x_suspend(struct device *dev)
PMT_CTRL_PM_MODE_D1_ | PMT_CTRL_WOL_EN_ |
PMT_CTRL_ED_EN_ | PMT_CTRL_PME_EN_);

+   if (pdata->pme_irq && device_may_wakeup(dev))
+   enable_irq_wake(pdata->pme_irq);
+


Based on my understanding of dev_pm_{set,clear}_wake_irq, we don't need
this and the below hunk. It's taken care in device_wakeup_arm_wake_irqs
which is called from suspend_enter>dpm_suspend_noirq path once you
have done the setup with dev_pm_set_wake_irq and is enabled both of
which is true in your case.


return 0;
  }

@@ -2622,6 +2667,9 @@ static int smsc911x_resume(struct device *dev)
struct smsc911x_data *pdata = netdev_priv(ndev);
unsigned int to = 100;

+   if (pdata->pme_irq && device_may_wakeup(dev))
+   disable_irq_wake(pdata->pme_irq);
+


Same as above.

--
Regards,
Sudeep

Re: Unhandled fault during system suspend in sky2_shutdown

[Sudeep Holla]

On 11/04/16 19:24, Stephen Hemminger wrote:

On Mon, 11 Apr 2016 17:24:37 +0100
Sudeep Holla <sudeep.ho...@arm.com> wrote:



[...]



diff --git i/drivers/net/ethernet/marvell/sky2.c
w/drivers/net/ethernet/marvell/sky2.c
index ec0a22119e09..0ff0434e32fc 100644
--- i/drivers/net/ethernet/marvell/sky2.c
+++ w/drivers/net/ethernet/marvell/sky2.c
@@ -5220,6 +5220,13 @@ static SIMPLE_DEV_PM_OPS(sky2_pm_ops,
sky2_suspend, sky2_resume);

   static void sky2_shutdown(struct pci_dev *pdev)
   {
+   struct sky2_hw *hw = pci_get_drvdata(pdev);
+   int i;
+
+   for (i = hw->ports - 1; i >= 0; --i) {
+   sky2_detach(hw->dev[i]);
+   unregister_netdev(hw->dev[i]);
+   }
  sky2_suspend(>dev);
  pci_wake_from_d3(pdev, device_may_wakeup(>dev));
  pci_set_power_state(pdev, PCI_D3hot);


This is not the correct fix, the device is supposed to stay
registered. The correct way to fix this would be to make get_stats
ignore requests  for device when suspended.


Yes I agree it's not correct fix. But I tried ignoring it in get_stat32
but the crash just moves the bug elsewhere. IMO patching all the places
to check the suspended state might be bit heavy ?

E.g. with something like below the crash moves to sky2_get_eeprom_len
function.

sky2_get_eeprom_len+0x10/0x30
dev_ethtool+0x29c/0x1d78
dev_ioctl+0x31c/0x5a8
sock_ioctl+0x2ac/0x310
do_vfs_ioctl+0xa4/0x750
SyS_ioctl+0x8c/0xa0
el0_svc_naked+0x24/0x2

Sorry if I am missing something fundamental, I am bit new to net drivers

Regards,
Sudeep

-->8

diff --git i/drivers/net/ethernet/marvell/sky2.c 
w/drivers/net/ethernet/marvell/sky2.c

index ec0a22119e09..d4cfcd89e7e5 100644
--- i/drivers/net/ethernet/marvell/sky2.c
+++ w/drivers/net/ethernet/marvell/sky2.c
@@ -5175,6 +5175,7 @@ static int sky2_suspend(struct device *dev)
}

sky2_power_aux(hw);
+   hw->suspended = true;
rtnl_unlock();

return 0;
@@ -5198,6 +5199,7 @@ static int sky2_resume(struct device *dev)
}

rtnl_lock();
+   hw->suspended = false;
sky2_reset(hw);
sky2_all_up(hw);
rtnl_unlock();
diff --git i/drivers/net/ethernet/marvell/sky2.h 
w/drivers/net/ethernet/marvell/sky2.h

index ec6dcd80152b..1386e5b635ff 100644
--- i/drivers/net/ethernet/marvell/sky2.h
+++ w/drivers/net/ethernet/marvell/sky2.h
@@ -2308,6 +2308,7 @@ struct sky2_hw {
wait_queue_head_tmsi_wait;

char irq_name[0];
+   bool suspended;
 };

 static inline int sky2_is_copper(const struct sky2_hw *hw)
@@ -2378,6 +2379,9 @@ static inline u32 get_stats32(struct sky2_hw *hw, 
unsigned port, unsigned reg)

 {
u32 val;

+   if (hw->suspended)
+   return 0;
+
do {
val = gma_read32(hw, port, reg);
} while (gma_read32(hw, port, reg) != val);

Unhandled fault during system suspend in sky2_shutdown

[Sudeep Holla]

Hi,

I am seeing unhandled fault during system suspend in sky2_shutdown.
I am not sure if it's something missing in the firmware, but just wanted
to check. I see that networkmanager is invoking calling to 
netlink_sendmsg which calls sky2_get_stats after the device is shutdown.


Unhandled fault: synchronous external abort (0x96000210) at 
0x091c2918

Internal error: : 96000210 [#1] PREEMPT SMP
Modules linked in:
CPU: 3 PID: 2029 Comm: NetworkManager Not tainted 4.6.0-rc3 #126
Hardware name: ARM Juno development board (r2) (DT)
task: 80007a673000 ti: 800940b5c000 task.ti: 800940b5c000
PC is at sky2_get_stats+0x44/0x3b8
LR is at dev_get_stats+0x58/0xc8
 sky2_get_stats+0x44/0x3b8
 rtnl_fill_stats+0x20/0x138
 rtnl_fill_ifinfo+0x440/0xb38
 rtnl_getlink+0xe8/0x198
 rtnetlink_rcv_msg+0xe4/0x220
 netlink_rcv_skb+0xc4/0xf8
 rtnetlink_rcv+0x2c/0x40
 netlink_unicast+0x160/0x238
 netlink_sendmsg+0x2f0/0x358
 sock_sendmsg+0x18/0x30
 ___sys_sendmsg+0x204/0x218
 __sys_sendmsg+0x44/0x88
 SyS_sendmsg+0xc/0x18
 el0_svc_naked+0x24/0x28

The below patch is the hack I came up to check if the netdev is detached 
and unregistered, I no longer see the issue.


Regards,
Sudeep

-->8

diff --git i/drivers/net/ethernet/marvell/sky2.c 
w/drivers/net/ethernet/marvell/sky2.c

index ec0a22119e09..0ff0434e32fc 100644
--- i/drivers/net/ethernet/marvell/sky2.c
+++ w/drivers/net/ethernet/marvell/sky2.c
@@ -5220,6 +5220,13 @@ static SIMPLE_DEV_PM_OPS(sky2_pm_ops, 
sky2_suspend, sky2_resume);


 static void sky2_shutdown(struct pci_dev *pdev)
 {
+   struct sky2_hw *hw = pci_get_drvdata(pdev);
+   int i;
+
+   for (i = hw->ports - 1; i >= 0; --i) {
+   sky2_detach(hw->dev[i]);
+   unregister_netdev(hw->dev[i]);
+   }
sky2_suspend(>dev);
pci_wake_from_d3(pdev, device_may_wakeup(>dev));
pci_set_power_state(pdev, PCI_D3hot);

Re: [PATCH 2/2] Convert smsc911x to use ACPI as well as DT

[Sudeep Holla]

On 23/09/15 18:22, Jeremy Linton wrote:

Marc,

|FWIW, mainline booting with this patch on Juno r1 with ACPI enabled
dies a |horrible death:

Sorry about the delay, I didn't see this message.



|How did you get this to work? Firmware release?

Yes, it's a firmware problem with the ACPI tables. It is likely you
need _DSD changes for the SMSC. If your trying to run juno with ACPI
there are a few other ACPI table changes you will need beyond what
was in the last linaro release. I wanted to just provide a direct
link to the correct firmware in this response, but it seems the
required version is sort of up in the air at the moment. Be assured I
will really push on this next week, and will provide a follow up
here.

Originally, the lack of DSD wasn't a problem, but as this patch
evolved  the fact that it consolidates a number of configuration code
paths balancing that got tricky, and ACPI machines with "bad" tables
were the victims (rather than breaking something I can't control).



Even now absence of _DSD *should* continue to be just fine. We can
bailout without initializing the device. Pulling the entire kernel down
just because of an incomplete device entry make no sense IMO.


In the meantime, if this is blocking anyone I can provide
instructions on how to update the required ACPI tables.



I found that the driver has issues even with DT missing some of the
optional properties. We need to fix it but I don't have much knowledge
of the driver and also not sure how these properties are defined in
ACPI/DSD world i.e. required vs optional.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/17] net: gianfar: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 22/09/15 15:04, Manoil Claudiu wrote:

-Original Message-
From: Thomas Gleixner [mailto:t...@linutronix.de]


[...]


on PPC architectures, the flag did the job.  When did this change? Since
when using IRQF_NO_SUSPEND is a "misuse"?


It always was. Simply because IRQF_NO_SUSPEND has absolutely nothing
to do with wakeup interrupt sources. It's a flag which excludes the
interrupt from the suspend mechanism, but it does not flag it a wakeup
source.



I'm seeing also a "powerpc: mpic" patch in the series, unfortunately I can't


Yes I think that was a redundant code, so I removed it. IIRC it was
setting IRQF_NO_SUSPEND in irq_set_wake callback which again is incorrect.


afford to test it right now. However I ran a quick test with this gianfar patch
in isolation on a powerpc system, and seen some difference in the behavior
(with and w/o the patch).  In both cases the system wakes up from standby
by magic packet.  However, without the IRQF_NO_SUSPEND flag 2 wake-up
interrupts are reported in /proc/interrupts for one magic packet; with the


OK that's interesting, will have check if I have similar behavior on my
setup too.


flag on there's just 1 interrupt.  Maybe this is not relevant, maybe the
"powerpc: mpic" patch from this series changes this behavior.


Hmm not sure, but better to test it together if possible. If required we
can reorder for bisect-ability reasons.


But if this is the API, what can I say? We'll see in time.  Btw, 
enable_irq_wake()
returns an error code, normally it should be handled by printing a warning
message at least, right?  But since most drivers don't handle that, I'm assuming
it should be left unhandled to avoid overcomplicating things.


Yes I left it so that I can add if the maintainer insist and not churn
too much code adding warning.


FWIW
Acked-by: Claudiu Manoil 



Thanks.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[PATCH 13/17] net: gianfar: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

The device is set as wakeup capable using proper wakeup API but the
driver misuses IRQF_NO_SUSPEND to set the interrupt as wakeup source
which is incorrect.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.

Cc: "David S. Miller" <da...@davemloft.net>
Cc: Claudiu Manoil <claudiu.man...@freescale.com>
Cc: Kevin Hao <haoke...@gmail.com>
Cc: netdev@vger.kernel.org
Signed-off-by: Sudeep Holla <sudeep.ho...@arm.com>
---
 drivers/net/ethernet/freescale/gianfar.c | 9 +
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/ethernet/freescale/gianfar.c 
b/drivers/net/ethernet/freescale/gianfar.c
index 4b69d061d90f..803ed4c93503 100644
--- a/drivers/net/ethernet/freescale/gianfar.c
+++ b/drivers/net/ethernet/freescale/gianfar.c
@@ -1970,8 +1970,7 @@ static int register_grp_irqs(struct gfar_priv_grp *grp)
/* Install our interrupt handlers for Error,
 * Transmit, and Receive
 */
-   err = request_irq(gfar_irq(grp, ER)->irq, gfar_error,
- IRQF_NO_SUSPEND,
+   err = request_irq(gfar_irq(grp, ER)->irq, gfar_error, 0,
  gfar_irq(grp, ER)->name, grp);
if (err < 0) {
netif_err(priv, intr, dev, "Can't get IRQ %d\n",
@@ -1979,6 +1978,8 @@ static int register_grp_irqs(struct gfar_priv_grp *grp)
 
goto err_irq_fail;
}
+   enable_irq_wake(gfar_irq(grp, ER)->irq);
+
err = request_irq(gfar_irq(grp, TX)->irq, gfar_transmit, 0,
  gfar_irq(grp, TX)->name, grp);
if (err < 0) {
@@ -1994,14 +1995,14 @@ static int register_grp_irqs(struct gfar_priv_grp *grp)
goto rx_irq_fail;
}
} else {
-   err = request_irq(gfar_irq(grp, TX)->irq, gfar_interrupt,
- IRQF_NO_SUSPEND,
+   err = request_irq(gfar_irq(grp, TX)->irq, gfar_interrupt, 0,
  gfar_irq(grp, TX)->name, grp);
if (err < 0) {
netif_err(priv, intr, dev, "Can't get IRQ %d\n",
  gfar_irq(grp, TX)->irq);
goto err_irq_fail;
}
+   enable_irq_wake(gfar_irq(grp, TX)->irq);
}
 
return 0;
-- 
1.9.1

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [PATCH 13/17] net: gianfar: remove misuse of IRQF_NO_SUSPEND flag

[Sudeep Holla]

On 21/09/15 17:24, Manoil Claudiu wrote:

-Original Message-
From: Sudeep Holla [mailto:sudeep.ho...@arm.com]
Sent: Monday, September 21, 2015 6:47 PM
To: linux...@vger.kernel.org; linux-ker...@vger.kernel.org
Cc: Sudeep Holla <sudeep.ho...@arm.com>; Thomas Gleixner
<t...@linutronix.de>; Rafael J. Wysocki <r...@rjwysocki.net>; David S. Miller
<da...@davemloft.net>; Manoil Claudiu-B08782
<claudiu.man...@freescale.com>; Kevin Hao <haoke...@gmail.com>;
netdev@vger.kernel.org
Subject: [PATCH 13/17] net: gianfar: remove misuse of IRQF_NO_SUSPEND
flag

The device is set as wakeup capable using proper wakeup API but the
driver misuses IRQF_NO_SUSPEND to set the interrupt as wakeup source
which is incorrect.

This patch removes the use of IRQF_NO_SUSPEND flags replacing it with
enable_irq_wake instead.



What would be the purpose of IRQF_NO_SUSPEND flag then?


If you look at the section "IRQF_NO_SUSPEND Flag" in
Documentation/power/suspend-and-interrupts.txt, it states it doesn't
guarantee that the interrupt will wake the system from a suspended state
-- for such cases it is necessary to use enable_irq_wake().


The flag is a friendlier API compared to calling enable_irq_wake().


In what sense ?


For older kernels, on PPC architectures, the flag did the job.


Agreed, it does the job even now, just that it's not designed for that.
One can change that anytime internally as the APIs for configuring
wakeups as in place now. I am just making use of right APIs.


When did this change? Since when using IRQF_NO_SUSPEND is a "misuse"?



Sorry if the term "misuse" is not appropriate here, since the intention
of the flag usage doesn't meet the requirements, I mentioned it as misuse.

Regards,
Sudeep
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: Suspicious RCU usage in bridge with Linux v4.0-9362-g1fc149933fd4

[Sudeep Holla]

On Thu, Apr 23, 2015 at 6:07 PM, Josh Boyer jwbo...@fedoraproject.org wrote:
 Hi All,

 We've had a user report the following backtrace from the bridge module
 with a recent Linus' tree.  Has anything like this been reported yet?
 If you have any questions on setup, the user is CC'd.


I too observed similar backtrace once(not able to reproduce it again)
while I was trying to check inconsistent lock state[1] with lockdep enabled.

Regards,
Sudeep

[1] https://lkml.org/lkml/2015/4/23/329


---8

===
[ INFO: suspicious RCU usage. ]
4.0.0 #269 Not tainted
---
include/trace/events/ipi.h:68 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0 #269
Hardware name: ARM-Versatile Express
[c00151f1] (unwind_backtrace) from [c0011971] (show_stack+0x11/0x14)
[c0011971] (show_stack) from [c05627c7] (dump_stack+0x73/0x8c)
[c05627c7] (dump_stack) from [c0013e63] (handle_IPI+0x257/0x410)
[c0013e63] (handle_IPI) from [c000932b] (gic_handle_irq+0x4f/0x50)
[c000932b] (gic_handle_irq) from [c00121ff] (__irq_svc+0x3f/0x64)
Exception stack(0xc083bf30 to 0xc083bf78)
bf20: 0001 0001  c0841938
bf40: c083a000 c083d5fc c08ba5c8 c083d598   c08b938f c056afc8
bf60: 0008 c083bf78 c005d157 c000f288 4133 
[c00121ff] (__irq_svc) from [c000f288] (arch_cpu_idle+0x30/0x34)
[c000f288] (arch_cpu_idle) from [c00555d5] (cpu_startup_entry+0x339/0x404)
[c00555d5] (cpu_startup_entry) from [c07d1a4f] (start_kernel+0x32f/0x338)
[c07d1a4f] (start_kernel) from [8000807f] (0x8000807f)

===
[ INFO: suspicious RCU usage. ]
4.0.0 #269 Not tainted
---
include/trace/events/ipi.h:84 suspicious rcu_dereference_check() usage!

other info that might help us debug this:


RCU used illegally from idle CPU!
rcu_scheduler_active = 1, debug_locks = 1
RCU used illegally from extended quiescent state!
no locks held by swapper/0/0.

stack backtrace:
CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.0.0 #269
Hardware name: ARM-Versatile Express
[c00151f1] (unwind_backtrace) from [c0011971] (show_stack+0x11/0x14)
[c0011971] (show_stack) from [c05627c7] (dump_stack+0x73/0x8c)
[c05627c7] (dump_stack) from [c0013f85] (handle_IPI+0x379/0x410)
[c0013f85] (handle_IPI) from [c000932b] (gic_handle_irq+0x4f/0x50)
[c000932b] (gic_handle_irq) from [c00121ff] (__irq_svc+0x3f/0x64)
Exception stack(0xc083bf30 to 0xc083bf78)
bf20: 0001 0001  c0841938
bf40: c083a000 c083d5fc c08ba5c8 c083d598   c08b938f c056afc8
bf60: 0008 c083bf78 c005d157 c000f288 4133 
[c00121ff] (__irq_svc) from [c000f288] (arch_cpu_idle+0x30/0x34)
[c000f288] (arch_cpu_idle) from [c00555d5] (cpu_startup_entry+0x339/0x404)
[c00555d5] (cpu_startup_entry) from [c07d1a4f] (start_kernel+0x32f/0x338)
[c07d1a4f] (start_kernel) from [8000807f] (0x8000807f)
--
To unsubscribe from this list: send the line unsubscribe netdev in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html