Patches for arch/arm/mm/cache-l2x0.c

Over the past few months, I wrote board-support code based on kernel v4.2 and things worked as expected.

Then I had to rebase to a LTS kernel (I used v4.1.13) and something broke in the L2 cache setup. Apparently, Russell King did a lot of fixing and cleaning up between v4.1 and v4.2

I cherry-picked the following 5 patches, and my 4.1 kernel works again:

346248a2d1e3a815297125c1347d90dafcc51990 ARM: l2c: avoid passing auxiliary control register through enable method

 arch/arm/mm/cache-l2x0.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)
dc63c0733050996143a82f2b095fc378a04274f0 ARM: l2c: only unlock caches if NS_LOCKDOWN bit is set
 arch/arm/mm/cache-l2x0.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)
7787be2a74dc618bf32348a0f588eebf7ebe0a06 ARM: l2c: clean up l2c_configure()
 arch/arm/mm/cache-l2x0.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
8f80afa16002e9b4784dc1d51c48f95f52838cfb ARM: l2c: write auxiliary control register first
 arch/arm/mm/cache-l2x0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
9749167eec6a057122b7a1ab2193abd079645aba ARM: l2c: restore the behaviour documented above l2c_enable()
 arch/arm/mm/cache-l2x0.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

The problem is that my system runs Linux in NS (non-secure) mode, and there are a bunch of instructions that Linux can't use in that mode.

I suspect the crash comes from trying to unconditionally unlock the caches, thus patch dc63c0733050.

But 9749167eec6a and 8f80afa16002 also look like good candidates for back-porting to v4.1

What do you think?

[ Back-porting v4.2 patches to v4.1 LTS ]

Quoted 32 lines · Mason

Over the past few months, I wrote board-support code based on kernel v4.2 and things worked as expected.

Then I had to rebase to a LTS kernel (I used v4.1.13) and something broke in the L2 cache setup. Apparently, Russell King did a lot of fixing and cleaning up between v4.1 and v4.2

I cherry-picked the following 5 patches, and my 4.1 kernel works again:

346248a2d1e3a815297125c1347d90dafcc51990 ARM: l2c: avoid passing auxiliary control register through enable method

 arch/arm/mm/cache-l2x0.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)
dc63c0733050996143a82f2b095fc378a04274f0 ARM: l2c: only unlock caches if NS_LOCKDOWN bit is set
 arch/arm/mm/cache-l2x0.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)
7787be2a74dc618bf32348a0f588eebf7ebe0a06 ARM: l2c: clean up l2c_configure()
 arch/arm/mm/cache-l2x0.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
8f80afa16002e9b4784dc1d51c48f95f52838cfb ARM: l2c: write auxiliary control register first
 arch/arm/mm/cache-l2x0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
9749167eec6a057122b7a1ab2193abd079645aba ARM: l2c: restore the behaviour documented above l2c_enable()
 arch/arm/mm/cache-l2x0.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

The problem is that my system runs Linux in NS (non-secure) mode, and there are a bunch of instructions that Linux can't use in that mode.

I suspect the crash comes from trying to unconditionally unlock the caches, thus patch dc63c0733050.

Quoted 4 lines

But 9749167eec6a and 8f80afa16002 also look like good candidates for back-porting to v4.1

What do you think?

Any opinion on this topic?

Quoted 39 lines · Mason

[ Back-porting v4.2 patches to v4.1 LTS ]

Quoted 35 lines · Mason

Over the past few months, I wrote board-support code based on kernel v4.2 and things worked as expected.

Then I had to rebase to a LTS kernel (I used v4.1.13) and something broke in the L2 cache setup. Apparently, Russell King did a lot of fixing and cleaning up between v4.1 and v4.2

I cherry-picked the following 5 patches, and my 4.1 kernel works again:

346248a2d1e3a815297125c1347d90dafcc51990 ARM: l2c: avoid passing auxiliary control register through enable method

 arch/arm/mm/cache-l2x0.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)
dc63c0733050996143a82f2b095fc378a04274f0 ARM: l2c: only unlock caches if NS_LOCKDOWN bit is set
 arch/arm/mm/cache-l2x0.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)
7787be2a74dc618bf32348a0f588eebf7ebe0a06 ARM: l2c: clean up l2c_configure()
 arch/arm/mm/cache-l2x0.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
8f80afa16002e9b4784dc1d51c48f95f52838cfb ARM: l2c: write auxiliary control register first
 arch/arm/mm/cache-l2x0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
9749167eec6a057122b7a1ab2193abd079645aba ARM: l2c: restore the behaviour documented above l2c_enable()
 arch/arm/mm/cache-l2x0.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

The problem is that my system runs Linux in NS (non-secure) mode, and there are a bunch of instructions that Linux can't use in that mode.

I suspect the crash comes from trying to unconditionally unlock the caches, thus patch dc63c0733050.

But 9749167eec6a and 8f80afa16002 also look like good candidates for back-porting to v4.1

Quoted 3 lines

Quoted 1 line

What do you think?

Any opinion on this topic?

You can find the answer to this question yourself if you read Documentation/stable_kernel_rules.txt, which gives the rules for what's suitable to be backported to stable trees. Let's go through them one by one:

- It must be obviously correct and tested.
Tested yes. Obviously correct - maybe (it's been some time since I wrote the patches.)

- It cannot be bigger than 100 lines, with context.
Doubtful, though for individual patches this may be true.

- It must fix only one thing.
True of each individual patch.

- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
Maybe for your situation, but you're an out of tree user, and the problem doesn't exist with mainline kernels.

- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
Maybe causes an oops for you, but not for any already merged platform, so it isn't a problem that is seen with mainline kernels.

Quoted 40 lines · Russell King - ARM Linux

Quoted 39 lines · Mason

[ Back-porting v4.2 patches to v4.1 LTS ]

Quoted 35 lines · Mason

Over the past few months, I wrote board-support code based on kernel v4.2 and things worked as expected.

Then I had to rebase to a LTS kernel (I used v4.1.13) and something broke in the L2 cache setup. Apparently, Russell King did a lot of fixing and cleaning up between v4.1 and v4.2

I cherry-picked the following 5 patches, and my 4.1 kernel works again:

346248a2d1e3a815297125c1347d90dafcc51990 ARM: l2c: avoid passing auxiliary control register through enable method

 arch/arm/mm/cache-l2x0.c | 32 +++++++++++++++++---------------
 1 file changed, 17 insertions(+), 15 deletions(-)
dc63c0733050996143a82f2b095fc378a04274f0 ARM: l2c: only unlock caches if NS_LOCKDOWN bit is set
 arch/arm/mm/cache-l2x0.c | 26 +++++++++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)
7787be2a74dc618bf32348a0f588eebf7ebe0a06 ARM: l2c: clean up l2c_configure()
 arch/arm/mm/cache-l2x0.c | 23 ++++++++++++++---------
 1 file changed, 14 insertions(+), 9 deletions(-)
8f80afa16002e9b4784dc1d51c48f95f52838cfb ARM: l2c: write auxiliary control register first
 arch/arm/mm/cache-l2x0.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
9749167eec6a057122b7a1ab2193abd079645aba ARM: l2c: restore the behaviour documented above l2c_enable()
 arch/arm/mm/cache-l2x0.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

The problem is that my system runs Linux in NS (non-secure) mode, and there are a bunch of instructions that Linux can't use in that mode.

I suspect the crash comes from trying to unconditionally unlock the caches, thus patch dc63c0733050.

But 9749167eec6a and 8f80afa16002 also look like good candidates for back-porting to v4.1

Quoted 8 lines

Quoted 3 lines

Quoted 1 line

What do you think?

Any opinion on this topic?

You can find the answer to this question yourself if you read Documentation/stable_kernel_rules.txt, which gives the rules for what's suitable to be backported to stable trees. Let's go through them one by one:

I get the feeling you've also brought tar and feathers :-)

Quoted 6 lines

- It must be obviously correct and tested.
Tested yes. Obviously correct - maybe (it's been some time since I wrote the patches.)

- It cannot be bigger than 100 lines, with context.
Doubtful, though for individual patches this may be true.

FWIW, I provided the diffstat in my original message. (32, 26, 23, 4, 10)

Quoted 7 lines

- It must fix only one thing.
True of each individual patch.

- It must fix a real bug that bothers people (not a, "This could be a problem..." type thing).
Maybe for your situation, but you're an out of tree user, and the problem doesn't exist with mainline kernels.

<confused>
Problem would hit anyone running Linux in non-secure mode. The kernel will crash when it executes l2c_unlock() which unconditionally writes to a secure register.

Quoted 6 lines

- It must fix a problem that causes a build error (but not for things marked CONFIG_BROKEN), an oops, a hang, data corruption, a real security issue, or some "oh, that's not good" issue. In short, something critical.
Maybe causes an oops for you, but not for any already merged platform, so it isn't a problem that is seen with mainline kernels.

<confused>
Why would this problem not affect e.g. arch/arm/mach-highbank ? (CCing Rob)

Quoted 2 lines · Mason

Why would this problem not affect e.g. arch/arm/mach-highbank ? (CCing Rob)

It could be broken as I don't have h/w. Some people do, but they may have not updated to 4.1 yet.

However, the lockdown function is configurable to be enabled for non-secure mode or not, and on highbank it is enabled for non-secure mode.