__pm_runtime_resume() returns -1 Was: Regression in 2.6.36

From: Christian Bahls
Date: Fri Oct 22 2010 - 09:38:34 EST

Thanks to the help by Matthias Schniedermeyer
i was able to bisect the change in less than 24 hours

The regression seems to have been introduced by the merge:
92b4522f72916ff2675060e29e4b24cf26ab59ce

Parent: 67a3e12b05e055c0415c556a315a3d3eb637e29e (Linux 2.6.35-rc1)
Parent: 2903037400a26e7c0cc93ab75a7d62abfacdf485 (net: fix
sk_forward_alloc corruptions)
Branches: compile, remotes/origin/master, work
Follows: v2.6.35-rc1
Precedes: v2.6.36-rc1

Merge branch 'master' of
master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6

Which (according to git bisect visualize) contains following Change:

Author: Eric Dumazet <eric.dumazet@xxxxxxxxx> 2010-05-29 09:20:48
Committer: David S. Miller <davem@xxxxxxxxxxxxx> 2010-05-29 09:20:48
Child: 92b4522f72916ff2675060e29e4b24cf26ab59ce (Merge branch
'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6)
Branches: compile, master, remotes/origin/master, remotes/v35/master, work
Follows: v2.6.34
Precedes: first_bad, v2.6.35-rc2

net: fix sk_forward_alloc corruptions

As David found out, sock_queue_err_skb() should be called with socket
lock hold, or we risk sk_forward_alloc corruption, since we use non
atomic operations to update this field.

This patch adds bh_lock_sock()/bh_unlock_sock() pair to three spots.
(BH already disabled)

1) skb_tstamp_tx()
2) Before calling ip_icmp_error(), in __udp4_lib_err()
3) Before calling ipv6_icmp_error(), in __udp6_lib_err()

Reported-by: Anton Blanchard <anton@xxxxxxxxx>
Signed-off-by: Eric Dumazet <eric.dumazet@xxxxxxxxx>
Signed-off-by: David S. Miller <davem@xxxxxxxxxxxxx>

------------------------------ net/core/skbuff.c ------------------------------
index 4667d4d..f2913ae 100644
@@ -2992,7 +2992,11 @@ void skb_tstamp_tx(struct sk_buff *orig_skb,
memset(serr, 0, sizeof(*serr));
serr->ee.ee_errno = ENOMSG;
serr->ee.ee_origin = SO_EE_ORIGIN_TIMESTAMPING;
+
+ bh_lock_sock(sk);
err = sock_queue_err_skb(sk, skb);
+ bh_unlock_sock(sk);
+
if (err)
kfree_skb(skb);
}

-------------------------------- net/ipv4/udp.c --------------------------------
index b9d0d40..acdc9be 100644
@@ -634,7 +634,9 @@ void __udp4_lib_err(struct sk_buff *skb, u32 info,
struct udp_table *udptable)
if (!harderr || sk->sk_state != TCP_ESTABLISHED)
goto out;
} else {
+ bh_lock_sock(sk);
ip_icmp_error(sk, skb, err, uh->dest, info, (u8 *)(uh+1));
+ bh_unlock_sock(sk);
}
sk->sk_err = err;
sk->sk_error_report(sk);

-------------------------------- net/ipv6/udp.c --------------------------------
index 87be586..3048f90 100644
@@ -466,9 +466,11 @@ void __udp6_lib_err(struct sk_buff *skb, struct
inet6_skb_parm *opt,
if (sk->sk_state != TCP_ESTABLISHED && !np->recverr)
goto out;

- if (np->recverr)
+ if (np->recverr) {
+ bh_lock_sock(sk);
ipv6_icmp_error(sk, skb, err, uh->dest, ntohl(info), (u8 *)(uh+1));
-
+ bh_unlock_sock(sk);
+ }
sk->sk_err = err;
sk->sk_error_report(sk);
out:


On Thu, Oct 21, 2010 at 5:24 PM, Matthias Schniedermeyer <ms@xxxxxxx> wrote:
> On 21.10.2010 16:34, Christian Bahls wrote:
>> Dear List
>>
>> PPS: bisecting this regression seems to be out of question
>> Ârecompiling the kernel on this computer takes a few hours
>> Âas all the other computers i use are 64bit
>> Âi would alternatively have to setup a cross-compilation environment
>> Âwhich i have not done in years (and not without rocklinux either)
>
> As far as it is my experience, x86 32bit/64bit can build each other.
>
> On the "big" machine just add "ARCH=x86" to (all!) make invocations.
> ARCH=x86 makes "CONFIG_64BIT" an actual configuration option and
> honours whatever is configured in the .config-file.
>
>
>
>
>
> Bis denn
>
> --
> Real Programmers consider "what you see is what you get" to be just as
> bad a concept in Text Editors as it is in women. No, the Real Programmer
> wants a "you asked for it, you got it" text editor -- complicated,
> cryptic, powerful, unforgiving, dangerous.
>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/