Re: [PATCH] EDAC/altera: Use fast register IO for S10 IRQs

From: Thor Thayer
Date: Wed Nov 20 2019 - 13:50:33 EST


Hi Boris,

On 11/20/19 12:07 PM, Borislav Petkov wrote:
On Wed, Nov 20, 2019 at 11:38:01AM -0600, thor.thayer@xxxxxxxxxxxxxxx wrote:
From: Thor Thayer <thor.thayer@xxxxxxxxxxxxxxx>

When an irq occurs in altera edac driver, regmap_xxx() is invoked
in atomic context. Regmap must indicate register IO is fast so
that a spinlock is used instead of a mutex to avoid sleeping
in atomic context.

Fixes mutex-lock error
lock_acquire+0xfc/0x288
__mutex_lock+0x8c/0x808
mutex_lock_nested+0x3c/0x50
regmap_lock_mutex+0x24/0x30
regmap_write+0x40/0x78
a10_eccmgr_irq_unmask+0x34/0x40
unmask_irq.part.0+0x30/0x50
irq_enable+0x74/0x80
__irq_startup+0x80/0xa8
irq_startup+0x70/0x150
__setup_irq+0x650/0x6d0
request_threaded_irq+0xe4/0x180
devm_request_threaded_irq+0x7c/0xf0
altr_sdram_probe+0x2c4/0x600
<snip>

Upstream fix pending [1] (common code uses fast mode)
[1] https://lkml.org/lkml/2019/11/7/1014

I don't understand - I picked those up and are already queued for 5.5:

https://git.kernel.org/pub/scm/linux/kernel/git/ras/ras.git/log/?h=edac-for-next

What is that patch for?

Are you saying, I should stick it before the two patches above so that
it gets backported to stable so that you have older kernels addressed?

But then the above ones won't apply anymore because

EDAC/altera: Use the Altera System Manager driver

removes s10_sdram_regmap_cfg.

What I can offer you is to remove the two patches and apply this one so
that it goes in next week. Then, you can send me the two rediffed after
5.5-rc1 is out. Ok?

Fixes: 3dab6bd52687 ("EDAC, altera: Add support for Stratix10 SDRAM EDAC")
Cc: stable@xxxxxxxxxxxxxxx
Reported-by: Meng Li <Meng.Li@xxxxxxxxxxxxx>
Signed-off-by: Meng Li <Meng.Li@xxxxxxxxxxxxx>

What does Meng's SOB mean?

Signed-off-by: Thor Thayer <thor.thayer@xxxxxxxxxxxxxxx>

Thx.


Sorry, I didn't explain this well enough. The patches you have queued will fix this for the next 5.5 branch.

This patch should to be applied to the stable branches to fix the issue in older branches. Although I knew the To: had to be to stable@xxxxxxxxxxxxxxx, I wasn't sure how that worked with the EDAC reviewers. This was a weird situation where I couldn't fix the upstream because it had already been fixed a different way.

Meng sent me the notification and the patch with a SOB so I put Meng first in the order.

Sorry for the confusion,

Thor