From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: akpm@linux-foundation.org
Cc: linux-kernel@vger.kernel.org, linux-mm@kvack.org
Subject: [PATCH] driver/firmware/memmap: don't create memmap sysfs of same firmware_map_entry
Date: Tue, 30 Sep 2014 18:25:48 +0900 [thread overview]
Message-ID: <542A771C.9040605@jp.fujitsu.com> (raw)
By the following commits, we prevented from allocating firmware_map_entry
of same memory range:
f0093ede: drivers/firmware/memmap.c: don't allocate firmware_map_entry
of same memory range
49c8b24d: drivers/firmware/memmap.c: pass the correct argument to
firmware_map_find_entry_bootmem()
But it's not enough. When PNP0C80 device is added by acpi_scan_init(),
memmap sysfses of same firmware_map_entry are created twice as follows:
# cat /sys/firmware/memmap/*/start
0x40000000000
0x60000000000
0x4a837000
0x4a83a000
0x4a8b5000
...
0x40000000000
0x60000000000
...
The flows of the issues are as follows:
1. e820_reserve_resources() allocates firmware_map_entrys of all
memory ranges defined in e820. And, these firmware_map_entrys
are linked with map_entries list.
map_entries -> entry 1 -> ... -> entry N
2. When PNP0C80 device is limited by mem= boot option, acpi_scan_init()
added the memory device. In this case, firmware_map_add_hotplug()
allocates firmware_map_entry and creates memmap sysfs.
map_entries -> entry 1 -> ... -> entry N -> entry N+1
|
memmap 1
3. firmware_memmap_init() creates memmap sysfses of firmware_map_entrys
linked with map_entries.
map_entries -> entry 1 -> ... -> entry N -> entry N+1
| | |
memmap 2 memmap N+1 memmap 1
memmap N+2
So while hot removing the PNP0C80 device, kernel panic occurs as follows:
BUG: unable to handle kernel paging request at 00000001003e000b
IP: sysfs_open_file+0x46/0x2b0
PGD 203a89fe067 PUD 0
Oops: 0000 [#1] SMP
...
Call Trace:
do_dentry_open+0x1ef/0x2a0
finish_open+0x31/0x40
do_last+0x57c/0x1220
path_openat+0xc2/0x4c0
do_filp_open+0x4b/0xb0
do_sys_open+0xf3/0x1f0
SyS_open+0x1e/0x20
system_call_fastpath+0x16/0x1b
The patch adds a check of confirming whether memmap sysfs of
firmware_map_entry has been created, and does not create memmap
sysfs of same firmware_map_entry.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
---
drivers/firmware/memmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 79f18e6..cc016c6 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -184,6 +184,9 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
static int map_entries_nr;
static struct kset *mmap_kset;
+ if (entry->kobj.state_in_sysfs)
+ return -EEXIST;
+
if (!mmap_kset) {
mmap_kset = kset_create_and_add("memmap", NULL, firmware_kobj);
if (!mmap_kset)
--
1.8.3.1
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
WARNING: multiple messages have this Message-ID (diff)
From: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
To: <akpm@linux-foundation.org>
Cc: <linux-kernel@vger.kernel.org>, <linux-mm@kvack.org>
Subject: [PATCH] driver/firmware/memmap: don't create memmap sysfs of same firmware_map_entry
Date: Tue, 30 Sep 2014 18:25:48 +0900 [thread overview]
Message-ID: <542A771C.9040605@jp.fujitsu.com> (raw)
By the following commits, we prevented from allocating firmware_map_entry
of same memory range:
f0093ede: drivers/firmware/memmap.c: don't allocate firmware_map_entry
of same memory range
49c8b24d: drivers/firmware/memmap.c: pass the correct argument to
firmware_map_find_entry_bootmem()
But it's not enough. When PNP0C80 device is added by acpi_scan_init(),
memmap sysfses of same firmware_map_entry are created twice as follows:
# cat /sys/firmware/memmap/*/start
0x40000000000
0x60000000000
0x4a837000
0x4a83a000
0x4a8b5000
...
0x40000000000
0x60000000000
...
The flows of the issues are as follows:
1. e820_reserve_resources() allocates firmware_map_entrys of all
memory ranges defined in e820. And, these firmware_map_entrys
are linked with map_entries list.
map_entries -> entry 1 -> ... -> entry N
2. When PNP0C80 device is limited by mem= boot option, acpi_scan_init()
added the memory device. In this case, firmware_map_add_hotplug()
allocates firmware_map_entry and creates memmap sysfs.
map_entries -> entry 1 -> ... -> entry N -> entry N+1
|
memmap 1
3. firmware_memmap_init() creates memmap sysfses of firmware_map_entrys
linked with map_entries.
map_entries -> entry 1 -> ... -> entry N -> entry N+1
| | |
memmap 2 memmap N+1 memmap 1
memmap N+2
So while hot removing the PNP0C80 device, kernel panic occurs as follows:
BUG: unable to handle kernel paging request at 00000001003e000b
IP: sysfs_open_file+0x46/0x2b0
PGD 203a89fe067 PUD 0
Oops: 0000 [#1] SMP
...
Call Trace:
do_dentry_open+0x1ef/0x2a0
finish_open+0x31/0x40
do_last+0x57c/0x1220
path_openat+0xc2/0x4c0
do_filp_open+0x4b/0xb0
do_sys_open+0xf3/0x1f0
SyS_open+0x1e/0x20
system_call_fastpath+0x16/0x1b
The patch adds a check of confirming whether memmap sysfs of
firmware_map_entry has been created, and does not create memmap
sysfs of same firmware_map_entry.
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
---
drivers/firmware/memmap.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c
index 79f18e6..cc016c6 100644
--- a/drivers/firmware/memmap.c
+++ b/drivers/firmware/memmap.c
@@ -184,6 +184,9 @@ static int add_sysfs_fw_map_entry(struct firmware_map_entry *entry)
static int map_entries_nr;
static struct kset *mmap_kset;
+ if (entry->kobj.state_in_sysfs)
+ return -EEXIST;
+
if (!mmap_kset) {
mmap_kset = kset_create_and_add("memmap", NULL, firmware_kobj);
if (!mmap_kset)
--
1.8.3.1
next reply other threads:[~2014-09-30 9:26 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-30 9:25 Yasuaki Ishimatsu [this message]
2014-09-30 9:25 ` [PATCH] driver/firmware/memmap: don't create memmap sysfs of same firmware_map_entry Yasuaki Ishimatsu
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=542A771C.9040605@jp.fujitsu.com \
--to=isimatu.yasuaki@jp.fujitsu.com \
--cc=akpm@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.