Re: [PATCH v2] mm/page_isolation: fix a deadlock with printk()

Qian Cai
2019-10-09T15:25:45Z

On Wed, 2019-10-09 at 15:56 +0200, Peter Oberparleiter wrote:
> On 08.10.2019 18:08, Qian Cai wrote:
> > On Tue, 2019-10-08 at 14:56 +0200, Christian Borntraeger wrote:
> > > Adding Peter Oberparleiter.
> > > Peter, can you have a look?
> > >
> > > On 08.10.19 10:27, Michal Hocko wrote:
> > > > On Tue 08-10-19 09:43:57, Petr Mladek wrote:
> > > > > On Mon 2019-10-07 16:49:37, Michal Hocko wrote:
> > > > > > [Cc s390 maintainers - the lockdep is http://lkml.kernel.org/r/1570228005-24979-1-git-send-email-cai@lca.pw
> > > > > > Petr has explained it is a false positive
> > > > > > http://lkml.kernel.org/r/20191007143002.l37bt2lzqtnqjqxu@pathway.suse.cz]
> > > > > > On Mon 07-10-19 16:30:02, Petr Mladek wrote:
> > > > > > [...]
> > > > > > > I believe that it cannot really happen because:
> > > > > > >
> > > > > > > static int __init
> > > > > > > sclp_console_init(void)
> > > > > > > {
> > > > > > > [...]
> > > > > > > rc = sclp_rw_init();
> > > > > > > [...]
> > > > > > > register_console(&sclp_console);
> > > > > > > return 0;
> > > > > > > }
> > > > > > >
> > > > > > > sclp_rw_init() is called before register_console(). And
> > > > > > > console_unlock() will never call sclp_console_write() before
> > > > > > > the console is registered.
> > > > > > >
> > > > > > > AFAIK, lockdep only compares existing chain of locks. It does
> > > > > > > not know about console registration that would make some
> > > > > > > code paths mutually exclusive.
> > > > > > >
> > > > > > > I believe that it is a false positive. I do not know how to
> > > > > > > avoid this lockdep report. I hope that it will disappear
> > > > > > > by deferring all printk() calls rather soon.
> > > > > >
> > > > > > Thanks a lot for looking into this Petr. I have also checked the code
> > > > > > and I really fail to see why the allocation has to be done under the
> > > > > > lock in the first place. sclp_read_sccb and sclp_init_sccb are global
> > > > > > variables but I strongly suspect that they need a synchronization during
> > > > > > early init, callbacks are registered only later IIUC:
> > > > >
> > > > > Good idea. It would work when the init function is called only once.
> > > > > But see below.
> > > > >
> > > > > > diff --git a/drivers/s390/char/sclp.c b/drivers/s390/char/sclp.c
> > > > > > index d2ab3f07c008..4b1c033e3255 100644
> > > > > > --- a/drivers/s390/char/sclp.c
> > > > > > +++ b/drivers/s390/char/sclp.c
> > > > > > @@ -1169,13 +1169,13 @@ sclp_init(void)
> > > > > > unsigned long flags;
> > > > > > int rc = 0;
> > > > > >
> > > > > > + sclp_read_sccb = (void *) __get_free_page(GFP_ATOMIC | GFP_DMA);
> > > > > > + sclp_init_sccb = (void *) __get_free_page(GFP_ATOMIC | GFP_DMA);
> > > > > > spin_lock_irqsave(&sclp_lock, flags);
> > > > > > /* Check for previous or running initialization */
> > > > > > if (sclp_init_state != sclp_init_state_uninitialized)
> > > > > > goto fail_unlock;
> > > > >
> > > > > It seems that sclp_init() could be called several times in parallel.
> > > > > I see it called from sclp_register() and sclp_initcall().
> > > >
> > > > Interesting. Something for s390 people to answer I guess.
> > > > Anyway, this should be quite trivial to workaround by a cmpxch or alike.
> > > >
> >
> > The above fix is simply insufficient,
> >
> > 00: [    3.654307] WARNING: possible circular locking dependency detected
> > 00: [    3.654309] 5.4.0-rc1-next-20191004+ #4 Not tainted
> > 00: [    3.654311] ------------------------------------------------------
> > 00: [    3.654313] swapper/0/1 is trying to acquire lock:
> > 00: [    3.654314] 00000000553f3fb8 (sclp_lock){-.-.}, at: sclp_add_request+0x34
> > 00: /0x308
> > 00: [    3.654320]
> > 00: [    3.654322] but task is already holding lock:
> > 00: [    3.654323] 00000000550c9fc0 (console_owner){....}, at: console_unlock+0x
> > 00: 328/0xa30
> > 00: [    3.654329]
> > 00: [    3.654331] which lock already depends on the new lock.
>
> I can confirm that both this lockdep warning as well as the original one
> are both false positives: lockdep warns that code in sclp_init could
> trigger a deadlock via the chain
>
> sclp_lock --> &(&zone->lock)->rlock --> console_owner
>
> but
>
> a) before sclp_init successfully completes, register_console is not
> called, so there is no connection between console_owner -> sclp_lock
> b) after sclp_init completed, it won't be called again, so any
> dependency that requires a call-chain including sclp_init is
> impossible to achieve
>
> Apparently lockdep cannot determine that sclp_init won't be called again.
> I'm attaching a patch that moves sclp_init to __init so that lockdep has
> a chance of knowing that the function will be gone after init.
>
> This patch is intended for testing only though, to see if there are other
> paths to similar possible deadlocks. I still need to decide if its worth
> changing the code to remove false positives in lockdep.
>
> A generic solution would be preferable from my point of view though,
> because otherwise each console driver owner would need to ensure that any
> lock taken in their console.write implementation is never held while
> memory is allocated/released.
>
> diff --git a/drivers/s390/char/sclp.c b/drivers/s390/char/sclp.c
> index d2ab3f07c008..13219e43d488 100644
> --- a/drivers/s390/char/sclp.c
> +++ b/drivers/s390/char/sclp.c
> @@ -140,7 +140,6 @@ static void sclp_request_timeout(bool force_restart);
> static void sclp_process_queue(void);
> static void __sclp_make_read_req(void);
> static int sclp_init_mask(int calculate);
> -static int sclp_init(void);
>
> static void
> __sclp_queue_read_req(void)
> @@ -670,7 +669,8 @@ __sclp_get_mask(sccb_mask_t *receive_mask, sccb_mask_t *send_mask)
> }
> }
>
> -/* Register event listener. Return 0 on success, non-zero otherwise. */
> +/* Register event listener. Return 0 on success, non-zero otherwise. Early
> + * callers (<= arch_initcall) must call sclp_init() first. */
> int
> sclp_register(struct sclp_register *reg)
> {
> @@ -679,9 +679,8 @@ sclp_register(struct sclp_register *reg)
> sccb_mask_t send_mask;
> int rc;
>
> - rc = sclp_init();
> - if (rc)
> - return rc;
> + if (sclp_init_state != sclp_init_state_initialized)
> + return -EINVAL;
> spin_lock_irqsave(&sclp_lock, flags);
> /* Check event mask for collisions */
> __sclp_get_mask(&receive_mask, &send_mask);
> @@ -1163,8 +1162,7 @@ static struct platform_device *sclp_pdev;
>
> /* Initialize SCLP driver. Return zero if driver is operational, non-zero
> * otherwise. */
> -static int
> -sclp_init(void)
> +int __init sclp_init(void)
> {
> unsigned long flags;
> int rc = 0;
> diff --git a/drivers/s390/char/sclp.h b/drivers/s390/char/sclp.h
> index 196333013e54..463660261379 100644
> --- a/drivers/s390/char/sclp.h
> +++ b/drivers/s390/char/sclp.h
> @@ -296,6 +296,7 @@ struct sclp_register {
> };
>
> /* externals from sclp.c */
> +int __init sclp_init(void);
> int sclp_add_request(struct sclp_req *req);
> void sclp_sync_wait(void);
> int sclp_register(struct sclp_register *reg);
> diff --git a/drivers/s390/char/sclp_con.c b/drivers/s390/char/sclp_con.c
> index 8966a1c1b548..a08ef2c8379e 100644
> --- a/drivers/s390/char/sclp_con.c
> +++ b/drivers/s390/char/sclp_con.c
> @@ -319,6 +319,9 @@ sclp_console_init(void)
> /* SCLP consoles are handled together */
> if (!(CONSOLE_IS_SCLP || CONSOLE_IS_VT220))
> return 0;
> + rc = sclp_init();
> + if (rc)
> + return rc;
> rc = sclp_rw_init();
> if (rc)
> return rc;
> diff --git a/drivers/s390/char/sclp_vt220.c b/drivers/s390/char/sclp_vt220.c
> index 3f9a6ef650fa..28b23e22248b 100644
> --- a/drivers/s390/char/sclp_vt220.c
> +++ b/drivers/s390/char/sclp_vt220.c
> @@ -694,6 +694,11 @@ static int __init __sclp_vt220_init(int num_pages)
> sclp_vt220_init_count++;
> if (sclp_vt220_init_count != 1)
> return 0;
> + rc = sclp_init();
> + if (rc) {
> + sclp_vt220_init_count--;
> + return rc;
> + }
> spin_lock_init(&sclp_vt220_lock);
> INIT_LIST_HEAD(&sclp_vt220_empty);
> INIT_LIST_HEAD(&sclp_vt220_outqueue);

Unfortunately, the patch does not help here. I guess the lockdep does not really
differential __init or not because those places can still have a chance to
deadlock in general after interrupt and preempt are enabled even during the boot
but it is just not the case here.

00: [    2.812088] WARNING: possible circular locking dependency detected
00: [    2.812090] 5.4.0-rc2-next-20191009+ #4 Not tainted
00: [    2.812092] ------------------------------------------------------
00: [    2.812094] swapper/0/1 is trying to acquire lock:
00: [    2.812095] 0000000036a07ed8 (sclp_lock){-.-.}, at: sclp_add_request+0x34
00: /0x308
00: [    2.812102]
00: [    2.812103] but task is already holding lock:
00: [    2.812105] 00000000366d9ec0 (console_owner){....}, at: console_unlock+0x
00: 328/0xa30
00: [    2.812111]
00: [    2.812113] which lock already depends on the new lock.
00: [    2.812114]
00: [    2.812115]
00: [    2.812117] the existing dependency chain (in reverse order) is:
00: [    2.812118]
00: [    2.812120] -> #2 (console_owner){....}:
00: [    2.812126]        lock_acquire+0x21a/0x468
00: [    2.812127]        console_unlock+0x3a6/0xa30
00: [    2.812129]        vprintk_emit+0x184/0x3c8
00: [    2.812131]        vprintk_default+0x44/0x50
00: [    2.812132]        printk+0xa8/0xc0
00: [    2.812134]        get_random_u64+0x40/0x108
00: [    2.812135]        add_to_free_area_random+0x188/0x1c0
00: [    2.812137]        free_one_page+0x72/0x128
00: [    2.812139]        __free_pages_ok+0x51c/0xc90
00: [    2.812141]        memblock_free_all+0x30a/0x3b0
00: [    2.812142]        mem_init+0x84/0x200
00: [    2.812144]        start_kernel+0x384/0x6a0
00: [    2.812145]        startup_continue+0x70/0xd0
00: [    2.812146]
00: [    2.812147] -> #1 (&(&zone->lock)->rlock){....}:
00: [    2.812154]        lock_acquire+0x21a/0x468
00: [    2.812155]        _raw_spin_lock+0x54/0x68
00: [    2.812157]        get_page_from_freelist+0x8b6/0x2d28
00: [    2.812159]        __alloc_pages_nodemask+0x246/0x658
00: [    2.812161]        __get_free_pages+0x34/0x78
00: [    2.812162]        sclp_init+0xce/0x640
00: [    2.812164]        sclp_console_init+0x4e/0x1c0
00: [    2.812166]        console_init+0x2c8/0x410
00: [    2.812168]        start_kernel+0x530/0x6a0
00: [    2.812169]        startup_continue+0x70/0xd0
00: [    2.812170]
00: [    2.812171] -> #0 (sclp_lock){-.-.}:
00: [    2.812177]        check_noncircular+0x338/0x3e0
00: [    2.812179]        __lock_acquire+0x1e66/0x2d88
00: [    2.812181]        lock_acquire+0x21a/0x468
00: [    2.812182]        _raw_spin_lock_irqsave+0xcc/0xe8
00: [    2.812184]        sclp_add_request+0x34/0x308
00: [    2.812186]        sclp_conbuf_emit+0x100/0x138
00: [    2.812187]        sclp_console_write+0x96/0x3b8
00: [    2.812189]        console_unlock+0x6dc/0xa30
00: [    2.812191]        vprintk_emit+0x184/0x3c8
00: [    2.812192]        vprintk_default+0x44/0x50
00: [    2.812194]        printk+0xa8/0xc0
00: [    2.812196]        iommu_debugfs_setup+0xf2/0x108
00: [    2.812198]        iommu_init+0x6c/0x78
00: [    2.812200]        do_one_initcall+0x162/0x680
00: [    2.812201]        kernel_init_freeable+0x4e8/0x5a8
00: [    2.812203]        kernel_init+0x2a/0x188
00: [    2.812205]        ret_from_fork+0x30/0x34
00: [    2.812206]        kernel_thread_starter+0x0/0xc
00: [    2.812207]
00: [    2.812209] other info that might help us debug this:
00: [    2.812210]
00: [    2.812211] Chain exists of:
00: [    2.812212]   sclp_lock --> &(&zone->lock)->rlock --> console_owner
00: [    2.812221]
00: [    2.812222]  Possible unsafe locking scenario:
00: [    2.812223]
00: [    2.812225]        CPU0                    CPU1
00: [    2.812227]        ----                    ----
00: [    2.812228]   lock(console_owner);
00: [    2.812232]                                lock(&(&zone->lock)->rlock);
00: [    2.812236]                                lock(console_owner);
00: [    2.812239]   lock(sclp_lock);
00: [    2.812243]
00: [    2.812244]  *** DEADLOCK ***
00: [    2.812245]
00: [    2.812247] 2 locks held by swapper/0/1:
00: [    2.812248]  #0: 00000000366da100 (console_lock){+.+.}, at: vprintk_emit+
00: 0x178/0x3c8
00: [    2.812255]  #1: 00000000366d9ec0 (console_owner){....}, at: console_unlo
00: ck+0x328/0xa30
00: [    2.812262]
00: [    2.812264] stack backtrace:
00: [    2.812266] CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.4.0-rc2-next-2019
00: 1009+ #4
00: [    2.812268] Hardware name: IBM 2964 N96 400 (z/VM 6.4.0)
00: [    2.812269] Call Trace:
00: [    2.812271] ([<000000003591e230>] show_stack+0x110/0x1b0)
00: [    2.812273]  [<00000000361e025e>] dump_stack+0x126/0x178
00: [    2.812276]  [<0000000035a149b8>] check_noncircular+0x338/0x3e0
00: [    2.812277]  [<0000000035a1a9a6>] __lock_acquire+0x1e66/0x2d88
00: [    2.812279]  [<0000000035a17cc2>] lock_acquire+0x21a/0x468
00: [    2.812281]  [<000000003621bce4>] _raw_spin_lock_irqsave+0xcc/0xe8
00: [    2.812283]  [<0000000035ff534c>] sclp_add_request+0x34/0x308
00: [    2.812285]  [<0000000035ffc6b8>] sclp_conbuf_emit+0x100/0x138
00: [    2.812287]  [<0000000035ffc7d6>] sclp_console_write+0x96/0x3b8
00: [    2.812289]  [<0000000035a2b4fc>] console_unlock+0x6dc/0xa30
00: [    2.812291]  [<0000000035a2dd0c>] vprintk_emit+0x184/0x3c8
00: [    2.812293]  [<0000000035a2df94>] vprintk_default+0x44/0x50
00: [    2.812295]  [<0000000035a2ea40>] printk+0xa8/0xc0
00: [    2.812297]  [<0000000035f4e5ea>] iommu_debugfs_setup+0xf2/0x108
00: [    2.812299]  [<0000000036b90554>] iommu_init+0x6c/0x78
00: [    2.812301]  [<0000000035900fda>] do_one_initcall+0x162/0x680
00: [    2.812303]  [<0000000036b4f9f0>] kernel_init_freeable+0x4e8/0x5a8
00: [    2.812305]  [<0000000036206bda>] kernel_init+0x2a/0x188
00: [    2.812306]  [<000000003621cfdc>] ret_from_fork+0x30/0x34
00: [    2.812308]  [<000000003621cfe0>] kernel_thread_starter+0x0/0xc
00: [    2.812310] INFO: lockdep is turned off.