public inbox for linux-efi@vger.kernel.org
 help / color / mirror / Atom feed
From: Lingzhu Xiang <lxiang-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
To: Anton Vorontsov
	<anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org>
Cc: linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
	Matthew Garrett <mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org>,
	Tony Luck <tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>,
	Kees Cook <keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org>,
	Matt Fleming
	<matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Subject: Re: EFI pstore: BUG: scheduling while atomic, and possible circular locking dependency
Date: Thu, 22 Nov 2012 15:32:25 +0800	[thread overview]
Message-ID: <50ADD509.2060800@redhat.com> (raw)
In-Reply-To: <20121122041239.GA24623-SAfYLu58TvsVgZ49a2IoEzcLetGT9WKNKwcig+XE9tjR7s880joybQ@public.gmane.org>

On 11/22/2012 12:12 PM, Anton Vorontsov wrote:
>> [   83.505022]  [<ffffffff810d59a0>] ? print_irqtrace_events+0xd0/0xe0
>> [   83.505022]  [<ffffffff810a401d>] __might_sleep+0x18d/0x250
>> [   83.505022]  [<ffffffff811b9dc7>] __kmalloc+0x67/0x2d0
>> [   83.505022]  [<ffffffff8156375b>] ? efivar_create_sysfs_entry+0x3b/0x1b0
>> [   83.505022]  [<ffffffff8156375b>] efivar_create_sysfs_entry+0x3b/0x1b0
> 
> efi_pstore_write calls create_sysfs_entry, which is obviosly unsafe from
> the dumper code, we're in the atomic context.
> 
>> [   83.505022]  [<ffffffff81563c03>] efi_pstore_write+0x333/0x3a0
>> [   83.505022]  [<ffffffff8106a3fe>] ? kmsg_dump_get_buffer+0x24e/0x2b0
>> [   83.505022]  [<ffffffff812ca4c5>] ? pstore_dump+0x195/0x210
>> [   83.505022]  [<ffffffff812ca45f>] pstore_dump+0x12f/0x210
>> [   83.505022]  [<ffffffff8106c459>] kmsg_dump+0xf9/0x240

With the previous patch, this backtrace disappears during crash.


>> After reboot, mount pstore
>> ==========================
>>
>> [root@localhost ~]# mount -t pstore -o kmsg_bytes=8000 - /dev/pstore
>> [   36.502832] BUG: sleeping function called from invalid context at mm/slub.c:928
>> [   36.504379] in_atomic(): 1, irqs_disabled(): 0, pid: 851, name: mount
>> [   36.505652] 3 locks held by mount/851:
>> [   36.506355]  #0:  (&type->s_umount_key#38/1){+.+.+.}, at: [<ffffffff811d5aed>] sget+0x37d/0x640
>> [   36.508899]  #1:  (&psinfo->read_mutex){+.+.+.}, at: [<ffffffff812ca59b>] pstore_get_records+0x3b/0x130
>> [   36.510688]  #2:  (&(&efivars->lock)->rlock){+.+.+.}, at: [<ffffffff8156273d>] efi_pstore_open+0x1d/0x40
>> [   36.512468] Pid: 851, comm: mount Tainted: G        W    3.7.0-0.rc5.git2.1.fc19.x86_64 #1
>> [   36.514001] Call Trace:
>> [   36.514440]  [<ffffffff810a401d>] __might_sleep+0x18d/0x250
>> [   36.515634]  [<ffffffff811b9dc7>] __kmalloc+0x67/0x2d0
>> [   36.516509]  [<ffffffff81562103>] ? efi_pstore_read+0x1c3/0x220
>> [   36.517525]  [<ffffffff81562103>] efi_pstore_read+0x1c3/0x220
>> [   36.518507]  [<ffffffff812ca5f1>] pstore_get_records+0x91/0x130
> 
> get_records() calls pinfo->open, which is efi_pstore_open, which grabs a
> spin_lock. Then efi_pstore_read tries to kmalloc things with GFP_KERNEL,
> which clearly a bug, since we're holding the spinlock.
> 
> The second issue is easy to fix, but the fix is not pretty: we must
> allocate buf with GFP_ATOMIC (the lock is required during ->read(), it
> protects efivars->list, so we can't simply drop it).
> 
> The first issue requires us to not create the sysfs entry (since it must
> be done in a non-atomic context). This makes pstore efi vars invisible via
> /sys/firmware/efi. :( If anyone wants to fix it, he'd have to "sync"
> efivars with sysfs thru a workqueue.

efi_pstore_read stops trying to kmalloc(GFP_KERNEL), but some others still do.

[   38.185217] BUG: sleeping function called from invalid context at mm/slub.c:930
[   38.186584] in_atomic(): 1, irqs_disabled(): 0, pid: 852, name: mount
[   38.187749] 3 locks held by mount/852:
[   38.188457]  #0:  (&type->s_umount_key#38/1){+.+.+.}, at: [<ffffffff811d0cce>] sget+0x3ae/0x670
[   38.190208]  #1:  (&psinfo->read_mutex){+.+.+.}, at: [<ffffffff812c060b>] pstore_get_records+0x3b/0x130
[   38.191956]  #2:  (&(&efivars->lock)->rlock){+.+.+.}, at: [<ffffffff8154e55d>] efi_pstore_open+0x1d/0x40
[   38.193790] Pid: 852, comm: mount Tainted: G        W    3.6.6-1.fc17.x86_64.debug #1
[   38.195162] Call Trace:
[   38.195606]  [<ffffffff810a2a1a>] __might_sleep+0x18a/0x240
[   38.196631]  [<ffffffff811b2497>] kmem_cache_alloc+0x47/0x290
[   38.197662]  [<ffffffff811ea621>] alloc_inode+0x61/0xa0
[   38.198615]  [<ffffffff811ec8aa>] new_inode_pseudo+0x1a/0x70
[   38.199687]  [<ffffffff811ec91d>] new_inode+0x1d/0x40
[   38.200658]  [<ffffffff812bfc43>] pstore_get_inode+0x13/0x50
[   38.201684]  [<ffffffff812c008b>] pstore_mkfile+0xfb/0x390
[   38.202619]  [<ffffffff812c0691>] pstore_get_records+0xc1/0x130
[   38.203690]  [<ffffffff812bfc80>] ? pstore_get_inode+0x50/0x50
[   38.204728]  [<ffffffff812bfd22>] pstore_fill_super+0xa2/0xc0
[   38.205754]  [<ffffffff811d1d22>] mount_single+0xb2/0xe0
[   38.206724]  [<ffffffff812bfb08>] pstore_mount+0x18/0x20
[   38.207695]  [<ffffffff811d1f43>] mount_fs+0x43/0x1b0
[   38.208619]  [<ffffffff811ef023>] vfs_kern_mount+0x73/0x110
[   38.209634]  [<ffffffff811efac4>] do_kern_mount+0x54/0x110
[   38.210633]  [<ffffffff811f1675>] do_mount+0x315/0x8e0
[   38.211561]  [<ffffffff811f11ca>] ? copy_mount_options+0x3a/0x180
[   38.212663]  [<ffffffff811f1ccd>] sys_mount+0x8d/0xe0
[   38.213591]  [<ffffffff816e2329>] system_call_fastpath+0x16/0x1b
[   38.214686] BUG: scheduling while atomic: mount/852/0x10000002
[   38.215782] 3 locks held by mount/852:
[   38.216483]  #0:  (&type->s_umount_key#38/1){+.+.+.}, at: [<ffffffff811d0cce>] sget+0x3ae/0x670
[   38.218182]  #1:  (&psinfo->read_mutex){+.+.+.}, at: [<ffffffff812c060b>] pstore_get_records+0x3b/0x130
[   38.219860]  #2:  (&(&efivars->lock)->rlock){+.+.+.}, at: [<ffffffff8154e55d>] efi_pstore_open+0x1d/0x40
[   38.221656] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vfat fat microcode i2c_piix4 virtio_net i2c_core
[   38.230376] Pid: 852, comm: mount Tainted: G        W    3.6.6-1.fc17.x86_64.debug #1
[   38.231778] Call Trace:
[   38.233584]  [<ffffffff816cc82c>] __schedule_bug+0x67/0x75
[   38.234625]  [<ffffffff816d74cb>] __schedule+0x98b/0x9f0
[   38.235612]  [<ffffffff811ea621>] ? alloc_inode+0x61/0xa0
[   38.236848]  [<ffffffff810a520a>] __cond_resched+0x2a/0x40
[   38.238584]  [<ffffffff816d75b0>] _cond_resched+0x30/0x40
[   38.239696]  [<ffffffff811b249c>] kmem_cache_alloc+0x4c/0x290
[   38.240763]  [<ffffffff811ea621>] alloc_inode+0x61/0xa0
[   38.241721]  [<ffffffff811ec8aa>] new_inode_pseudo+0x1a/0x70
[   38.242741]  [<ffffffff811ec91d>] new_inode+0x1d/0x40
[   38.243679]  [<ffffffff812bfc43>] pstore_get_inode+0x13/0x50
[   38.244745]  [<ffffffff812c008b>] pstore_mkfile+0xfb/0x390
[   38.245751]  [<ffffffff812c0691>] pstore_get_records+0xc1/0x130
[   38.246833]  [<ffffffff812bfc80>] ? pstore_get_inode+0x50/0x50
[   38.247954]  [<ffffffff812bfd22>] pstore_fill_super+0xa2/0xc0
[   38.249006]  [<ffffffff811d1d22>] mount_single+0xb2/0xe0
[   38.253548]  [<ffffffff812bfb08>] pstore_mount+0x18/0x20
[   38.254571]  [<ffffffff811d1f43>] mount_fs+0x43/0x1b0
[   38.255504]  [<ffffffff811ef023>] vfs_kern_mount+0x73/0x110
[   38.256515]  [<ffffffff811efac4>] do_kern_mount+0x54/0x110
[   38.257539]  [<ffffffff811f1675>] do_mount+0x315/0x8e0
[   38.264673]  [<ffffffff811f11ca>] ? copy_mount_options+0x3a/0x180
[   38.265783]  [<ffffffff811f1ccd>] sys_mount+0x8d/0xe0
[   38.266714]  [<ffffffff816e2329>] system_call_fastpath+0x16/0x1b
[   38.268096] BUG: scheduling while atomic: mount/852/0x10000002
[   38.269169] 3 locks held by mount/852:
[   38.269841]  #0:  (&type->s_umount_key#38/1){+.+.+.}, at: [<ffffffff811d0cce>] sget+0x3ae/0x670
[   38.271546]  #1:  (&psinfo->read_mutex){+.+.+.}, at: [<ffffffff812c060b>] pstore_get_records+0x3b/0x130
[   38.273323]  #2:  (&(&efivars->lock)->rlock){+.+.+.}, at: [<ffffffff8154e55d>] efi_pstore_open+0x1d/0x40
[   38.275134] Modules linked in: ipt_MASQUERADE nf_conntrack_netbios_ns nf_conntrack_broadcast ip6table_mangle ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 ip6table_filter ip6_tables iptable_nat nf_nat iptable_mangle nf_conntrack_ipv4 nf_defrag_ipv4 xt_conntrack nf_conntrack be2iscsi iscsi_boot_sysfs bnx2i cnic uio cxgb4i cxgb4 cxgb3i cxgb3 mdio libcxgbi ib_iser rdma_cm ib_addr iw_cm ib_cm ib_sa ib_mad ib_core iscsi_tcp libiscsi_tcp libiscsi scsi_transport_iscsi vfat fat microcode i2c_piix4 virtio_net i2c_core
[   38.283936] Pid: 852, comm: mount Tainted: G        W    3.6.6-1.fc17.x86_64.debug #1
[   38.285345] Call Trace:
[   38.285755]  [<ffffffff816cc82c>] __schedule_bug+0x67/0x75
[   38.286758]  [<ffffffff816d74cb>] __schedule+0x98b/0x9f0
[   38.287685]  [<ffffffff811ea621>] ? alloc_inode+0x61/0xa0
[   38.288672]  [<ffffffff810a520a>] __cond_resched+0x2a/0x40
[   38.289659]  [<ffffffff816d75b0>] _cond_resched+0x30/0x40
[   38.290632]  [<ffffffff811b249c>] kmem_cache_alloc+0x4c/0x290
[   38.291646]  [<ffffffff811ea621>] alloc_inode+0x61/0xa0
[   38.292579]  [<ffffffff811ec8aa>] new_inode_pseudo+0x1a/0x70
[   38.293591]  [<ffffffff811ec91d>] new_inode+0x1d/0x40
[   38.294510]  [<ffffffff812bfc43>] pstore_get_inode+0x13/0x50
[   38.295523]  [<ffffffff812c008b>] pstore_mkfile+0xfb/0x390
[   38.296519]  [<ffffffff812c0691>] pstore_get_records+0xc1/0x130
[   38.297583]  [<ffffffff812bfc80>] ? pstore_get_inode+0x50/0x50
[   38.298642]  [<ffffffff812bfd22>] pstore_fill_super+0xa2/0xc0
[   38.299675]  [<ffffffff811d1d22>] mount_single+0xb2/0xe0
[   38.300644]  [<ffffffff812bfb08>] pstore_mount+0x18/0x20
[   38.301603]  [<ffffffff811d1f43>] mount_fs+0x43/0x1b0
[   38.302519]  [<ffffffff811ef023>] vfs_kern_mount+0x73/0x110
[   38.303531]  [<ffffffff811efac4>] do_kern_mount+0x54/0x110
[   38.304470]  [<ffffffff811f1675>] do_mount+0x315/0x8e0
[   38.305390]  [<ffffffff811f11ca>] ? copy_mount_options+0x3a/0x180
[   38.306470]  [<ffffffff811f1ccd>] sys_mount+0x8d/0xe0
[   38.307368]  [<ffffffff816e2329>] system_call_fastpath+0x16/0x1b


>> After reboot, rm a pstore entry
>> ===============================
>>
>> [root@localhost ~]# rm -f /dev/pstore/dmesg-efi-9
>> [   55.572466]
>> [   55.572767] ======================================================
>> [   55.573015] [ INFO: possible circular locking dependency detected ]
>> [   55.573015] 3.7.0-0.rc5.git2.1.fc19.x86_64 #1 Tainted: G        W
> 
> I don't see an obvious problem, but let's solve the first two, and see if
> this will help, since the kernel was tainted already.

This info persists.

  parent reply	other threads:[~2012-11-22  7:32 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-11-22  2:57 EFI pstore: BUG: scheduling while atomic, and possible circular locking dependency Lingzhu Xiang
     [not found] ` <50AD94A4.4030100-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-22  4:12   ` Anton Vorontsov
     [not found]     ` <20121122041239.GA24623-SAfYLu58TvsVgZ49a2IoEzcLetGT9WKNKwcig+XE9tjR7s880joybQ@public.gmane.org>
2012-11-22  7:32       ` Lingzhu Xiang [this message]
     [not found]         ` <50ADD509.2060800-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2012-11-22 10:07           ` Anton Vorontsov
2012-11-26 17:06       ` Seiji Aguchi
     [not found]         ` <A5ED84D3BB3A384992CBB9C77DEDA4D4149FA32A-ohthHghroY0jroPwUH3sq+6wyyQG6/Uh@public.gmane.org>
2012-11-26 17:50           ` Matt Fleming
2013-04-12 11:54   ` Lingzhu Xiang
     [not found]     ` <5167F5DE.8070804-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org>
2013-04-13 14:40       ` Seiji Aguchi

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50ADD509.2060800@redhat.com \
    --to=lxiang-h+wxahxf7alqt0dzr+alfa@public.gmane.org \
    --cc=anton.vorontsov-QSEj5FYQhm4dnm+yROfE0A@public.gmane.org \
    --cc=keescook-F7+t8E8rja9g9hUCZPvPmw@public.gmane.org \
    --cc=linux-efi-u79uwXL29TY76Z2rM5mHXA@public.gmane.org \
    --cc=matt.fleming-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    --cc=mjg59-1xO5oi07KQx4cg9Nei1l7Q@public.gmane.org \
    --cc=tony.luck-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox