Skip to contentSkip to conversation

3.19.7-stable review

PATCH In review Greg Kroah-Hartman 12 participants 200 messages May 2, 2015 – May 8, 2015 Page 2 of 2

Subsystems (6)
Stable branch KVM MIPS netfilter +2 more subsystems
lore
Share & tools
lore
#174 lore raw

Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks

In reply to Greg Kroah-Hartman

Hi Greg, hi Pablo,

Quoted 61 lines · Greg Kroah-Hartman
Quoted 60 lines · Thomas Backlund

Den 02.05.2015 22:03, Greg Kroah-Hartman skrev:

Quoted 34 lines

3.19-stable review patch. If anyone has any objections, please let me know.

------------------

From: Daniel Borkmann <[email protected]>

commit afb7718016fcb0370ac29a83b2839c78b76c2960 upstream.

While originally only being intended for outgoing traffic, commit a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks") enabled xt_cgroups for the NF_INET_LOCAL_IN hook as well, in order to allow for nfacct accounting.

Besides being currently limited to early demuxes only, commit a00e76349f35 forgot to add a check if we deal with full sockets, i.e. in this case not with time wait sockets. TCP time wait sockets do not have the same memory layout as full sockets, a lower memory footprint and consequently also don't have a sk_classid member; probing for sk_classid member there could potentially lead to a crash.

Fixes a00e76349f35 ("netfilter: x_tables: allow to use cgroup match for LOCAL_IN nf hooks")
Cc Alexey Perevalov <[email protected]>
---
  net/netfilter/xt_cgroup.c |    2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

net/netfilter/xt_cgroup.c cgroup_mt(const struct sk_buff *skb, str · line 45

Quoted 8 lines
net/netfilter/xt_cgroup.c +1 -1
@@ -39,7 +39,7 @@ cgroup_mt(const struct sk_buff *skb, str
  {
  	const struct xt_cgroup_info *info = par->matchinfo;
 
-	if (skb->sk == NULL)
+	if (skb->sk == NULL || !sk_fullsock(skb->sk))
  		return false;
 
  	return (info->id == skb->sk->sk_classid) ^ info->invert;

This one breaks the build with:

net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock' [-Werror=implicit-function-declaration]

In order to fix it, you also need to add:

From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <[email protected]>
Date: Sun, 15 Mar 2015 21:12:12 -0700
Subject: [PATCH] net: add sk_fullsock() helper

which in turn needs this one:

Quoted 7 lines
Quoted 4 lines

From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <[email protected]>
Date: Thu, 12 Mar 2015 16:44:04 -0700
Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state

I've just dropped the patch, thanks for letting me know, odd that my build tests missed it.

If you're nevertheless interested in this fix, you could use this version, which should apply/build just fine:

http://patchwork.ozlabs.org/patch/455546/

I believe Pablo usually sends netfilter patches in bundles to you.

Thanks a lot,
Daniel

#175 lore raw

Re: [PATCH 3.19 176/177] netfilter: x_tables: fix cgroup matching on non-full sks

Quoted 17 lines · Daniel Borkmann
Quoted 9 lines
Quoted 9 lines

In order to fix it, you also need to add:

From 1d0ab253872cdd3d8e7913f59c266c7fd01771d0 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <[email protected]>
Date: Sun, 15 Mar 2015 21:12:12 -0700
Subject: [PATCH] net: add sk_fullsock() helper

which in turn needs this one:

Quoted 7 lines
Quoted 4 lines

From 10feb428a5045d5eb18a5d755fbb8f0cc9645626 Mon Sep 17 00:00:00 2001
From: Eric Dumazet <[email protected]>
Date: Thu, 12 Mar 2015 16:44:04 -0700
Subject: [PATCH] inet: add TCP_NEW_SYN_RECV state

I've just dropped the patch, thanks for letting me know, odd that my build tests missed it.

Quoted 6 lines

If you're nevertheless interested in this fix, you could use this version, which should apply/build just fine:

http://patchwork.ozlabs.org/patch/455546/

I believe Pablo usually sends netfilter patches in bundles to you.

Yes, I keep an internal queue netfilter patches that I consider important to go to -stable.

I think it's better if anyone willing to get some netfilter related patch into -stable just point that to me so I take care of it. At least that should add one extra filter step to make sure things don't break in this process.

Thanks.

author maintainer
#176 lore raw

PATCH 177/177 netfilter: bridge: really save frag_max_size between PRE and POST_ROUTING

In reply to Greg Kroah-Hartman

3.19-stable review patch. If anyone has any objections, please let me know.

------------------

From: Florian Westphal <[email protected]>

commit 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream.

We also need to save/store in forward, else br_parse_ip_options call will zero frag_max_size as well.

Fixes 93fdd47e5 ('bridge: Save frag_max_size between PRE_ROUTING and POST_ROUTING')
---
 net/bridge/br_netfilter.c |   17 +++++++++++++++--
 1 file changed, 15 insertions(+), 2 deletions(-)
net/bridge/br_netfilter.c +15 -2
@@ -651,6 +651,13 @@ static int br_nf_forward_finish(struct s
 	struct net_device *in;
 
 	if (!IS_ARP(skb) && !IS_VLAN_ARP(skb)) {
+		int frag_max_size;
+
+		if (skb->protocol == htons(ETH_P_IP)) {
+			frag_max_size = IPCB(skb)->frag_max_size;
+			BR_INPUT_SKB_CB(skb)->frag_max_size = frag_max_size;
+		}
+
 		in = nf_bridge->physindev;
 		if (nf_bridge->mask & BRNF_PKT_TYPE) {
 			skb->pkt_type = PACKET_OTHERHOST;
@@ -710,8 +717,14 @@ static unsigned int br_nf_forward_ip(con
 		nf_bridge->mask |= BRNF_PKT_TYPE;
 	}
 
-	if (pf == NFPROTO_IPV4 && br_parse_ip_options(skb))
-		return NF_DROP;
+	if (pf == NFPROTO_IPV4) {
+		int frag_max = BR_INPUT_SKB_CB(skb)->frag_max_size;
+
+		if (br_parse_ip_options(skb))
+			return NF_DROP;
+
+		IPCB(skb)->frag_max_size = frag_max;
+	}
 
 	/* The physdev module checks on this */
 	nf_bridge->mask |= BRNF_BRIDGED;
#177 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Build results:

	total: 125 pass: 101 fail: 24
Failed builds:
	alpha:allmodconfig
	arm:allmodconfig
	arm64:allmodconfig
	i386:allyesconfig
	i386:allmodconfig
	m68k:allmodconfig
	mips:defconfig
	mips:allmodconfig
	mips:bcm47xx_defconfig
	mips:bcm63xx_defconfig
	mips:nlm_xlp_defconfig
	mips:ath79_defconfig
	mips:ar7_defconfig
	mips:fuloong2e_defconfig
	mips:e55_defconfig
	mips:cavium_octeon_defconfig
	mips:malta_defconfig
	powerpc:defconfig
	powerpc:allmodconfig
	s390:allmodconfig
	sparc64:allmodconfig
	x86_64:allyesconfig
	x86_64:allmodconfig
	xtensa:allmodconfig

Qemu test results:

	total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

Build error:

net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock'

3.19.y and 4.0.y are being rebuilt right mow, so maybe you fixed that problem as well as the same failure in 4.0.y. I'll resend my report for 3.19.y and wait with the report for 4.0.y until after the rebuild is complete.

Guenter

#178 lore raw
Quoted 10 lines · Guenter Roeck

Build error:

net/netfilter/xt_cgroup.c: In function 'cgroup_mt':
net/netfilter/xt_cgroup.c:42:2: error: implicit declaration of function 'sk_fullsock'

3.19.y and 4.0.y are being rebuilt right mow, so maybe you fixed that problem as well as the same failure in 4.0.y. I'll resend my report for 3.19.y and wait with the report for 4.0.y until after the rebuild is complete.

Another build failure, affecting powerpc:defconfig and powerpc:allmodconfig builds for 4.0.y and 3.19.y (and it looks like it is still there).

Error log:
include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,' include/linux/bug.h:9: Error: junk at end of line, first unrecognized character is `,'

[ and many more similar messages ]

Bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

After reverting the patch in 4.0.y, the files affected by it still compile, so I don't entirely understand why this patch would be needed in -stable.

Guenter

#179 lore raw
Quoted 3 lines · Guenter Roeck

Bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

Btw, since you do these bisections (great!), it would be doubly useful if you then (automatically?) would add the people involved with the particular commit to the cc. At least the ones that signed off and/or acked the commit (that jump-label commit has a lot of people on the cc, but if they never _responded_ to the cc, I'm not sure that they should necessarily be disturbed).

The people who signed off on it hopefully are aware of any dependencies for that commit, in ways that Greg himself (or the stable team) may not be.

Linus

#180 lore raw
Quoted 12 lines · Linus Torvalds
Quoted 3 lines · Guenter Roeck

Bisect points to 'powerpc, jump_label: Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.

Btw, since you do these bisections (great!), it would be doubly useful if you then (automatically?) would add the people involved with the particular commit to the cc. At least the ones that signed off and/or acked the commit (that jump-label commit has a lot of people on the cc, but if they never _responded_ to the cc, I'm not sure that they should necessarily be disturbed).

Quoted 4 lines

The people who signed off on it hopefully are aware of any dependencies for that commit, in ways that Greg himself (or the stable team) may not be.

Yes, I know. Quite often I do that. I didn't do it today because of time constraints and, in the hurry I was in, I simply forgot.

Doing the bisects automatically would be great. Unfortunately that part (and sending the e-mail) is all manual, and I don't think I'll find the time anytime soon to automate it.

Guenter

#181 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

	total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

---
powerpc:

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,'

As mentioned earlier, bisect points to 'powerpc, jump_label:
Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.'.

Guenter

#182 lore raw
Quoted 55 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

	total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

---
powerpc:

Quoted 6 lines

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,'

As mentioned earlier, bisect points to 'powerpc, jump_label:
Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.'.

That commit might be missing its dependencies:

c0ccf6f99e3a jump_label: Allow jump labels to be used in assembly 55dd0df781e5 jump_label: Allow asm/jump_label.h to be included in assembly

But I don't think the PowerPC commit should be in -stable to begin with, just like the two core patches are not.

Thanks,

Ingo

author maintainer
#183 lore raw
Quoted 65 lines · Ingo Molnar
Quoted 55 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

	total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

---
powerpc:

Quoted 6 lines

include/linux/bug.h: Assembler messages:
include/linux/bug.h:7: Error: unrecognized opcode: enum' include/linux/bug.h:8: Error: junk at end of line, first unrecognized character is ,'

As mentioned earlier, bisect points to 'powerpc, jump_label:
Include linux/jump_label.h to get HAVE_JUMP_LABEL define'.'.

Quoted 7 lines

That commit might be missing its dependencies:

c0ccf6f99e3a jump_label: Allow jump labels to be used in assembly 55dd0df781e5 jump_label: Allow asm/jump_label.h to be included in assembly

But I don't think the PowerPC commit should be in -stable to begin with, just like the two core patches are not.

Yes, now removed from the queue, thanks.

greg k-h

#184 lore raw
In reply to Guenter Roeck
Quoted 44 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

     total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

     total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

Quoted 8 lines

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

The latest 3.19.y still fails to build mips images with this error. A quick test suggests that reverting the patch appears to fix the problem.

Powerpc images now build without errors.

Guenter

author maintainer
#185 lore raw
Quoted 50 lines · Guenter Roeck
Quoted 49 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

    total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

    total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Quoted 6 lines
Quoted 3 lines

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

The latest 3.19.y still fails to build mips images with this error. A quick test suggests that reverting the patch appears to fix the problem.

Ok, now removed, thanks.

greg k-h

#186 lore raw
In reply to Guenter Roeck
Quoted 44 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

    total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

    total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

Quoted 8 lines

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

I guess this is a fallout caused by the missing dependencies.

Patches

- [PATCH] MIPS: unaligned: Prevent EVA instructions on kernel unaligned" (eeb538950367e3966cbf0237ab1a1dc30e059818)

- [PATCH] MIPS: unaligned: Surround load/store macros in do {} while (3563c32d6532ece53c9dd8905a8e41983ef9952f)

couldn't be applied to 3.19 stable according to the emails I got from Greg, so the third one in that series (aka the offending one) is now broken.

Please remove 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA' (6eae35485b26f9e51ab896eb8a936bed9908fdf6)

I will create a suitable 3.19 backport for that patchset.

Thanks and apologies for the breakage.

Signature · 1 line
markos
author maintainer
#187 lore raw
Quoted 64 lines · Markos Chandras
Quoted 44 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

    total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

    total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

Quoted 8 lines

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

I guess this is a fallout caused by the missing dependencies.

Patches

- [PATCH] MIPS: unaligned: Prevent EVA instructions on kernel unaligned" (eeb538950367e3966cbf0237ab1a1dc30e059818)

- [PATCH] MIPS: unaligned: Surround load/store macros in do {} while (3563c32d6532ece53c9dd8905a8e41983ef9952f)

Quoted 8 lines

couldn't be applied to 3.19 stable according to the emails I got from Greg, so the third one in that series (aka the offending one) is now broken.

Please remove 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA' (6eae35485b26f9e51ab896eb8a936bed9908fdf6)

I will create a suitable 3.19 backport for that patchset.

Thanks, now removed.

greg k-h

author maintainer
#188 lore raw
In reply to Guenter Roeck
Quoted 44 lines · Guenter Roeck
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Take two:

Build results:

	total: 125 pass: 112 fail: 13

Failed builds:
mips:defconfig
mips:allmodconfig
mips:bcm47xx_defconfig
mips:bcm63xx_defconfig
mips:nlm_xlp_defconfig
mips:ath79_defconfig
mips:ar7_defconfig
mips:fuloong2e_defconfig
mips:e55_defconfig
mips:cavium_octeon_defconfig
mips:malta_defconfig
powerpc:defconfig
powerpc:allmodconfig

Qemu test results:

	total: 30 pass: 22 fail: 8

Failed tests:
mips:mips_malta_defconfig
mips:mips_malta_smp_defconfig
mips:mipsel_malta_defconfig
mips:mipsel_malta_smp_defconfig
mips64:mips_malta64_defconfig
mips64:mips_malta64_smp_defconfig
powerpc:ppc64_book3s_defconfig
powerpc:ppc64_book3s_smp_defconfig

---
Error logs:

Quoted 7 lines

mips:

arch/mips/kernel/unaligned.c: In function 'emulate_load_store_insn':
arch/mips/kernel/unaligned.c:570:4: error: expected '}' before 'else'

Bisect points to 'MIPS: unaligned: Fix regular load/store instruction emulation for EVA'.

That bisect doesn't make much sense, I don't see a problem with that patch, and it doesn't modify those lines either.

Anyone else have an idea here?

thanks,

greg k-h

#189 lore raw
In reply to Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Quoted 8 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

thanks,

greg k-h

Compiled and booted on my test system. No dmesg regressions.

-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
author maintainer
#190 lore raw
In reply to Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

-rc2 is out now that should work properly:

kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

#191 lore raw
Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Quoted 8 lines
Quoted 3 lines

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

-rc2 is out now that should work properly:

kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

Build results:

	total: 125 pass: 125 fail: 0
Qemu test results:
	total: 30 pass: 30 fail: 0

Details are available at http://server.roeck-us.net:8010/builders.

Guenter

#192 lore raw
In reply to Greg Kroah-Hartman
Quoted 14 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

Review

Quoted 3 lines
(quoted diff) +0 -1
-rc2 is out now that should work properly:
 
 	kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

rc2 is good. Compiled and booted. No dmesg regressions.

-- Shuah

Signature · 5 lines
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
[email protected] | (970) 217-8978
Tested-by Bo Shen
#193 lore raw
In reply to Greg Kroah-Hartman

Hi Greg,

Quoted 9 lines · Greg Kroah-Hartman
Quoted 8 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

Quoted 7 lines
Quoted 3 lines

The whole patch series can be found in one patch at:

      kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

-rc2 is out now that should work properly:

        kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

The kernelci.org robot reported new boot failures in v3.19.7 on a variety of at91 boards[1][2][3]. I instructed the robot perform a boot bisection which yielded...

git bisect start
# bad: [7214c55cba9630a4728f86ae6b3c73c962430711] Linux 3.19.7 git bisect bad 7214c55cba9630a4728f86ae6b3c73c962430711
# good: [3c464c73693b6d118c129d7f07dbc1ea26aa6d8a] Linux 3.19.6 git bisect good 3c464c73693b6d118c129d7f07dbc1ea26aa6d8a
# bad: [31064e86b01887a28fa26af528dc5239be384435] ptrace: fix race between ptrace_resume() and wait_task_stopped()
git bisect bad 31064e86b01887a28fa26af528dc5239be384435
# good: [7595f5425cad83e037639e228ee24d5052510139] md/raid0: fix bug with chunksize not a power of 2.
git bisect good 7595f5425cad83e037639e228ee24d5052510139
# good: [dc7a0b0a432521d4b40987b344a9b5473a9bd18b] usb: phy: Find the right match in devm_usb_phy_match
git bisect good dc7a0b0a432521d4b40987b344a9b5473a9bd18b
# good: [dc7507e89e2c67143e5bb51488f4e5c7e0f6d3bd] usb: host: sl811:
use new USB_RESUME_TIMEOUT
git bisect good dc7507e89e2c67143e5bb51488f4e5c7e0f6d3bd
# bad: [92465054d08aa11c32b77969bc3be89d1c229f9f] ALSA: hda/realtek - Enable the ALC292 dock fixup on the Thinkpad T450
git bisect bad 92465054d08aa11c32b77969bc3be89d1c229f9f
# bad: [c67881fc890916206e723329e774391c6ed354ce] clk: at91: usb:
propagate rate modification to the parent clk
git bisect bad c67881fc890916206e723329e774391c6ed354ce
# good: [d7f24470bf614ff986c9370f5704fa635b448918] usb: core: hub: use new USB_RESUME_TIMEOUT
git bisect good d7f24470bf614ff986c9370f5704fa635b448918

c67881fc890916206e723329e774391c6ed354ce is the first bad commit commit c67881fc890916206e723329e774391c6ed354ce

Author: Boris Brezillon <[email protected]>
Date:   Sun Mar 29 03:45:33 2015 +0200

clk: at91: usb: propagate rate modification to the parent clk

commit 4591243102faa8de92da320edea47219901461e9 upstream.

The at91sam9n12 and at91sam9x5 usb clocks do not propagate rate modification requests to their parents.
This causes a bug when the PLLB is left uninitialized by the bootloader (PLL multiplier set to 0, or in other words, PLL rate = 0 Hz).

Implement the determinate_rate method and propagate the change rate request to the parent clk.

Locally I've reverted c67881fc890916206e723329e774391c6ed354ce on top of v3.19.7 and confirmed that my at91-sama5d3_xplained boots that kernel successfully[4].

Quoted 6 lines

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Cheers,

Tyler

[1] http://kernelci.org/boot/?v3.19&at91
[2] https://lists.linaro.org/pipermail/kernel-build-reports/2015-May/008917.html
[3] http://storage.kernelci.org/stable/v3.19.7/arm-sama5_defconfig/lab-tbaker/boot-at91-sama5d3_xplained.html
[4] http://lava.kernelci.org/scheduler/job/80240/log_file

#194 lore raw
Quoted 5 lines · Tyler Baker

Locally I've reverted c67881fc890916206e723329e774391c6ed354ce on top of v3.19.7 and confirmed that my at91-sama5d3_xplained boots that kernel successfully[4].

And that makes sense as commit 1c8e600440c7 ("clk: Add rate constraints to clocks") isn't in 3.19. This commit changes the signature of .determine_rate to include the 2 extra args present in at91sam9x5_clk_usb_determine_rate() after commit c67881fc890916206e723329e774391c6ed354ce.

Cheers,
--
Lu�s

#195 lore raw

Luis, Tyler,

Quoted 7 lines · On Thu, 7 May 2015 09:55:53 +0100 Luis Henriques…
Quoted 5 lines · Tyler Baker

Locally I've reverted c67881fc890916206e723329e774391c6ed354ce on top of v3.19.7 and confirmed that my at91-sama5d3_xplained boots that kernel successfully[4].

Quoted 5 lines

And that makes sense as commit 1c8e600440c7 ("clk: Add rate constraints to clocks") isn't in 3.19. This commit changes the signature of .determine_rate to include the 2 extra args present in at91sam9x5_clk_usb_determine_rate() after commit c67881fc890916206e723329e774391c6ed354ce.

Oops, indeed. I shouldn't have tagged this commit for stable. Below is a patch fixing this problem.
Sorry for the inconvenience.

Best Regards,

Boris

-- >8 --

Quoted 1 line

From 73a2cf633be185570c7df689afedaebed86d8451 Mon Sep 17 00:00:00 2001

Subject: [PATCH] clk: at91: usb: fix determine_rate prototype

Commit c67881fc890916206e723329e774391c6ed354ce is a backport of 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream commit, fixing a bug on clk rate change propagation.
But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19.

---
 drivers/clk/at91/clk-usb.c | 2 --
 1 file changed, 2 deletions(-)
drivers/clk/at91/clk-usb.c +0 -2
index 0b7c3e8..0283a57 100644
@@ -58,8 +58,6 @@ static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
 
 static long at91sam9x5_clk_usb_determine_rate(struct clk_hw *hw,
 					      unsigned long rate,
-					      unsigned long min_rate,
-					      unsigned long max_rate,
 					      unsigned long *best_parent_rate,
 					      struct clk_hw **best_parent_hw)
 {
Signature · 1 line
1.9.1
#196 lore raw
Quoted 18 lines · Boris Brezillon

Luis, Tyler,

Quoted 7 lines · On Thu, 7 May 2015 09:55:53 +0100 Luis Henriques…
Quoted 5 lines · Tyler Baker

Locally I've reverted c67881fc890916206e723329e774391c6ed354ce on top of v3.19.7 and confirmed that my at91-sama5d3_xplained boots that kernel successfully[4].

Quoted 5 lines

And that makes sense as commit 1c8e600440c7 ("clk: Add rate constraints to clocks") isn't in 3.19. This commit changes the signature of .determine_rate to include the 2 extra args present in at91sam9x5_clk_usb_determine_rate() after commit c67881fc890916206e723329e774391c6ed354ce.

Quoted 3 lines

Oops, indeed. I shouldn't have tagged this commit for stable. Below is a patch fixing this problem.
Sorry for the inconvenience.

Tested this patch, and confirmed it resolves the boot issues. Thanks for a speedy response.

Quoted 34 lines

Best Regards,

Boris

-- >8 --
From 73a2cf633be185570c7df689afedaebed86d8451 Mon Sep 17 00:00:00 2001
Subject: [PATCH] clk: at91: usb: fix determine_rate prototype

Commit c67881fc890916206e723329e774391c6ed354ce is a backport of 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream commit, fixing a bug on clk rate change propagation.
But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19.

---
 drivers/clk/at91/clk-usb.c | 2 --
 1 file changed, 2 deletions(-)
drivers/clk/at91/clk-usb.c +0 -3
index 0b7c3e8..0283a57 100644
@@ -58,8 +58,6 @@ static unsigned long at91sam9x5_clk_usb_recalc_rate(struct clk_hw *hw,
 
 static long at91sam9x5_clk_usb_determine_rate(struct clk_hw *hw,
                                              unsigned long rate,
-                                             unsigned long min_rate,
-                                             unsigned long max_rate,
                                              unsigned long *best_parent_rate,
                                              struct clk_hw **best_parent_hw)
 {
--
Quoted 2 lines

1.9.1

Cheers,

Tyler

author maintainer Applied
#197 lore raw

Patch "clk: at91: usb: fix determine_rate prototype" has been added to the 3.19-stable tree

In reply to Boris Brezillon

This is a note to let you know that I've just added the patch titled

clk: at91: usb: fix determine_rate prototype

to the 3.19-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary

The filename of the patch is:
clk-at91-usb-fix-determine_rate-prototype.patch
and it can be found in the queue-3.19 subdirectory.

If you, or anyone else, feels it should not be added to the stable tree, please let <[email protected]> know about it.

Quoted 1 line

From [email protected] Fri May 8 13:05:22 2015

From: Boris Brezillon <[email protected]>
Date: Thu, 7 May 2015 11:56:44 +0200
To: Luis Henriques <[email protected]>
Subject: clk: at91: usb: fix determine_rate prototype
Cc: Tyler Baker <[email protected]>, Greg Kroah-Hartman <[email protected]>, "[email protected]" <[email protected]>, [email protected], Andrew Morton <[email protected]>, [email protected], [email protected], [email protected], Mike Turquette <[email protected]>
Message-ID: <20150507115644.1ef29d2e@bbrezillon>

From: Boris Brezillon <[email protected]>

Commit c67881fc890916206e723329e774391c6ed354ce is a backport of 0b67c43ce36a9964f1d5e3f973ee19eefd3f9f8f upstream commit, fixing a bug on clk rate change propagation.
But in 4.0 ->determine_rate() prototype has changed, thus introducing a prototype mismatch when applying it on 3.19.

---
 drivers/clk/at91/clk-usb.c |    2 --
 1 file changed, 2 deletions(-)
drivers/clk/at91/clk-usb.c +0 -2
@@ -58,8 +58,6 @@ static unsigned long at91sam9x5_clk_usb_
 
 static long at91sam9x5_clk_usb_determine_rate(struct clk_hw *hw,
 					      unsigned long rate,
-					      unsigned long min_rate,
-					      unsigned long max_rate,
 					      unsigned long *best_parent_rate,
 					      struct clk_hw **best_parent_hw)
 {

Patches currently in stable-queue which might be from [email protected] are

queue-3.19/clk-at91-usb-fix-determine_rate-prototype.patch

#198 lore raw
In reply to Tyler Baker
Quoted 16 lines · Tyler Baker

Hi Greg,

Quoted 13 lines · Greg Kroah-Hartman
Quoted 11 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

       kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz

and the diffstat can be found below.

Quoted 8 lines
Quoted 3 lines

-rc2 is out now that should work properly:

         kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

The kernelci.org robot reported new boot failures in v3.19.7 on a variety of at91 boards[1][2][3]. I instructed the robot perform a boot bisection which yielded...

Can one of those boards be emulated with qemu, by any chance ?

Guenter

#199 lore raw
Quoted 29 lines · Guenter Roeck
Quoted 28 lines · Tyler Baker

Hi Greg,

Quoted 21 lines · Greg Kroah-Hartman
Quoted 6 lines · Greg Kroah-Hartman

This is the start of the stable review cycle for the 3.19.7 release. There are 177 patches in this series, all will be posted as a response to this one. If anyone has any issues with these being applied, please let me know.

Quoted 7 lines

Responses should be made by Mon May 4 18:59:31 UTC 2015. Anything received after that time might be too late.

The whole patch series can be found in one patch at:

kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc1.gz and the diffstat can be found below.

-rc2 is out now that should work properly:

kernel.org/pub/linux/kernel/v3.0/stable-review/patch-3.19.7-rc2.gz

Quoted 6 lines
Quoted 4 lines

The kernelci.org robot reported new boot failures in v3.19.7 on a variety of at91 boards[1][2][3]. I instructed the robot perform a boot bisection which yielded...

Can one of those boards be emulated with qemu, by any chance ?

With qemu-system 2.2... 'qemu-system-arm -machine help' does not list any at91 based machine types. :(

Quoted 3 lines

Guenter

Cheers,

Tyler