[3.8-rc1] Networking problems after pulling-in net.git#master

Hi,

after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
function called from invalid context"" [1] I decided to pull-in
net.git#master (up to commit 9b1536c490d5: "bridge: call
br_netpoll_disable in br_add_if") on top of Linus upstream.

With this kernel I can't neither ping my router nor does DNS work.
IIRC there were 6 commits, not sure which of them is culprit.

I tried the v3.8-rc1-raring from [2] which works nicely here on
Ubuntu/precise AMD64.
Can't say if NetworkManager is involved or not.

Any feedback appreciated, Thanks.

Regards,
- Sedat -

[1] https://lkml.org/lkml/2012/12/22/79
[2] http://kernel.ubuntu.com/~kernel-ppa/mainline/v3.8-rc1-raring/

On Sun, Dec 23, 2012 at 04:14:39AM +0100, Sedat Dilek wrote:

Hi,

after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
function called from invalid context"" [1] I decided to pull-in
net.git#master (up to commit 9b1536c490d5: "bridge: call
br_netpoll_disable in br_add_if") on top of Linus upstream.

With this kernel I can't neither ping my router nor does DNS work.
IIRC there were 6 commits, not sure which of them is culprit.

I tried the v3.8-rc1-raring from [2] which works nicely here on
Ubuntu/precise AMD64.
Can't say if NetworkManager is involved or not.

Does that mean that with Linus upstream, i.e. 3.8-rc1, you can ping your
router, etc?

If so, you could bisect the 6 commits...

Thanks.

-- 
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

On Sun, Dec 23, 2012 at 12:42 PM, Borislav Petkov [off-list ref] wrote:

On Sun, Dec 23, 2012 at 04:14:39AM +0100, Sedat Dilek wrote:

quoted

Hi,

after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
function called from invalid context"" [1] I decided to pull-in
net.git#master (up to commit 9b1536c490d5: "bridge: call
br_netpoll_disable in br_add_if") on top of Linus upstream.

With this kernel I can't neither ping my router nor does DNS work.
IIRC there were 6 commits, not sure which of them is culprit.

I tried the v3.8-rc1-raring from [2] which works nicely here on
Ubuntu/precise AMD64.
Can't say if NetworkManager is involved or not.

Does that mean that with Linus upstream, i.e. 3.8-rc1, you can ping your
router, etc?

If so, you could bisect the 6 commits...

Nah, he said that b-word :-).
The machine I am working on has some hardware damage (keyboard gets
not detected on bios start or even within daily-work, recently I could
not type further while writing an email, so raping that machine is not
a good idea. I could bisect within a reduced localmodconfig setup. No
big promises...)

- Sedat -

Thanks.

--
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

On Sun, Dec 23, 2012 at 1:26 PM, Sedat Dilek [off-list ref] wrote:

On Sun, Dec 23, 2012 at 12:42 PM, Borislav Petkov [off-list ref] wrote:

quoted

On Sun, Dec 23, 2012 at 04:14:39AM +0100, Sedat Dilek wrote:

quoted

Hi,

after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
function called from invalid context"" [1] I decided to pull-in
net.git#master (up to commit 9b1536c490d5: "bridge: call
br_netpoll_disable in br_add_if") on top of Linus upstream.

With this kernel I can't neither ping my router nor does DNS work.
IIRC there were 6 commits, not sure which of them is culprit.

I tried the v3.8-rc1-raring from [2] which works nicely here on
Ubuntu/precise AMD64.
Can't say if NetworkManager is involved or not.

Does that mean that with Linus upstream, i.e. 3.8-rc1, you can ping your
router, etc?

If so, you could bisect the 6 commits...

Nah, he said that b-word :-).
The machine I am working on has some hardware damage (keyboard gets
not detected on bios start or even within daily-work, recently I could
not type further while writing an email, so raping that machine is not
a good idea. I could bisect within a reduced localmodconfig setup. No
big promises...)

Starting bisect session with a "localmodconfig" setup... (bad: last
commit and good: v3.8-rc1)...

- Sedat -

[1] http://www.h-online.com/open/features/Good-and-quick-kernel-configuration-creation-1403046.html
[2] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

- Sedat -

quoted

Thanks.

--
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

On Sun, Dec 23, 2012 at 1:40 PM, Sedat Dilek [off-list ref] wrote:

On Sun, Dec 23, 2012 at 1:26 PM, Sedat Dilek [off-list ref] wrote:

quoted

On Sun, Dec 23, 2012 at 12:42 PM, Borislav Petkov [off-list ref] wrote:

quoted

On Sun, Dec 23, 2012 at 04:14:39AM +0100, Sedat Dilek wrote:

quoted

Hi,

after reading the thread "Regression in 3.8-rc1: "BUG: sleeping
function called from invalid context"" [1] I decided to pull-in
net.git#master (up to commit 9b1536c490d5: "bridge: call
br_netpoll_disable in br_add_if") on top of Linus upstream.

With this kernel I can't neither ping my router nor does DNS work.
IIRC there were 6 commits, not sure which of them is culprit.

I tried the v3.8-rc1-raring from [2] which works nicely here on
Ubuntu/precise AMD64.
Can't say if NetworkManager is involved or not.

Does that mean that with Linus upstream, i.e. 3.8-rc1, you can ping your
router, etc?

If so, you could bisect the 6 commits...

Nah, he said that b-word :-).
The machine I am working on has some hardware damage (keyboard gets
not detected on bios start or even within daily-work, recently I could
not type further while writing an email, so raping that machine is not
a good idea. I could bisect within a reduced localmodconfig setup. No
big promises...)

Starting bisect session with a "localmodconfig" setup... (bad: last
commit and good: v3.8-rc1)...

The culprit commit here seems to be...

commit 9650388b5c56578fdccc79c57a8c82fb92b8e7f1
Author: Eric Dumazet [off-list ref]
Date:   Fri Dec 21 07:32:10 2012 +0000

    ipv4: arp: fix a lockdep splat in arp_solicit()

...see also attached git-bisect log-files.

For the sake of completeness I have attached also my kernel-config
file and an output of lspci.

While my last steps of bisecting I also hit a MEI problem on restart,
I have seen a fix "[PATCH] mei: fix mismatch in mutex unlock-lock in
mei_amthif_read()" for this on LKML [1].

Hope this helps you to track down the problem.

Feel free to add any credits...

- Sedat -

[1] http://marc.info/?l=linux-kernel&m=135612627527193&w=2

- Sedat -

[1] http://www.h-online.com/open/features/Good-and-quick-kernel-configuration-creation-1403046.html
[2] http://www.kernel.org/pub/software/scm/git/docs/git-bisect.html

quoted

- Sedat -

quoted

Thanks.

--
Regards/Gruss,
    Boris.

Sent from a fat crate under my desk. Formatting is fine.
--

On Sun, Dec 23, 2012 at 9:19 PM, Sedat Dilek [off-list ref] wrote:

The culprit commit here seems to be...

commit 9650388b5c56578fdccc79c57a8c82fb92b8e7f1
Author: Eric Dumazet [off-list ref]
Date:   Fri Dec 21 07:32:10 2012 +0000

    ipv4: arp: fix a lockdep splat in arp_solicit()

Can you try the following one-line fix?

Thanks.

------------>

diff --git a/net/ipv4/arp.c b/net/ipv4/arp.c
index 1169ed4..75e0d7c 100644
--- a/net/ipv4/arp.c
+++ b/net/ipv4/arp.c

@@ -365,7 +365,7 @@ static void arp_solicit(struct neighbour *neigh,

struct sk_buff *skb)
                        pr_debug("trying to ucast probe in NUD_INVALID\n");
                neigh_ha_snapshot(dst_ha, neigh, dev);
        } else {
-               memset(dst_ha, 0, dev->addr_len);
+               memcpy(dst_ha, dev->broadcast, MAX_ADDR_LEN);
                probes -= neigh->parms->app_probes;
                if (probes < 0) {
 #ifdef CONFIG_ARPD

On Sun, Dec 23, 2012 at 2:44 PM, Cong Wang [off-list ref] wrote:

[ CCing Eric ]

YES, thie fixes my problem.
But your patch was somehow malformed, so I attached mine.

- Sedat -

	Hello,

On Sun, 23 Dec 2012, Cong Wang wrote:

	Use dev->addr_len instead of MAX_ADDR_LEN or
better provide NULL ptr to arp_send as before the
"ipv4: arp: fix a lockdep splat in arp_solicit" change,
for example by keeping dst_ha as pointer and using another
name for the temp array that is now dst_ha[MAX_ADDR_LEN].

                probes -= neigh->parms->app_probes;
                if (probes < 0) {
 #ifdef CONFIG_ARPD

Regards

--
Julian Anastasov [off-list ref]

On Sun, Dec 23, 2012 at 10:14 PM, Sedat Dilek [off-list ref] wrote:

[ CCing Eric ]

YES, thie fixes my problem.
But your patch was somehow malformed, so I attached mine.

Thanks for testing!

I knew it as I replied in wed Gmail. :) I will send a normal patch
with your Reported-by and Tested-by.

On Sun, Dec 23, 2012 at 10:10 PM, Julian Anastasov [off-list ref] wrote:

quoted

-               memset(dst_ha, 0, dev->addr_len);
+               memcpy(dst_ha, dev->broadcast, MAX_ADDR_LEN);

        Use dev->addr_len instead of MAX_ADDR_LEN or
better provide NULL ptr to arp_send as before the
"ipv4: arp: fix a lockdep splat in arp_solicit" change,
for example by keeping dst_ha as pointer and using another
name for the temp array that is now dst_ha[MAX_ADDR_LEN].

OK, I will use a new temp variable.

Thanks.

On Sun, Dec 23, 2012 at 3:25 PM, Cong Wang [off-list ref] wrote:

On Sun, Dec 23, 2012 at 10:14 PM, Sedat Dilek [off-list ref] wrote:

quoted

[ CCing Eric ]

YES, thie fixes my problem.
But your patch was somehow malformed, so I attached mine.

Thanks for testing!

I knew it as I replied in wed Gmail. :) I will send a normal patch
with your Reported-by and Tested-by.

/o\ for your quick reply and patch!

Just as a sidenote:
The mentioned MEI patch [1] did also fix the ugly locking on
soft-reboot (for people who are affected and know about GIYF) :-).
Good I am doing a (filesystem) sync before reboots.

I did not much testing, but for a -rc1 release this looks now fine to me.

- Sedat -

[1] http://marc.info/?l=linux-kernel&m=135612627527193&w=2