diff options
| author | Yinghai Lu <yinghai@kernel.org> | 2009-06-16 15:31:16 -0700 |
|---|---|---|
| committer | Linus Torvalds <torvalds@linux-foundation.org> | 2009-06-16 19:47:28 -0700 |
| commit | 3b0fde0fac19c180317eb0601b3504083f4b9bf5 (patch) | |
| tree | 5458ec10f3c6759ec64c6fa27e12e692a575d07a /drivers/firmware | |
| parent | 021415468c889979117b1a07b96f7e36de33e995 (diff) | |
| download | linux-3b0fde0fac19c180317eb0601b3504083f4b9bf5.tar.bz2 | |
firmware_map: fix hang with x86/32bit
Addresses http://bugzilla.kernel.org/show_bug.cgi?id=13484
Peer reported:
| The bug is introduced from kernel 2.6.27, if E820 table reserve the memory
| above 4G in 32bit OS(BIOS-e820: 00000000fff80000 - 0000000120000000
| (reserved)), system will report Int 6 error and hang up. The bug is caused by
| the following code in drivers/firmware/memmap.c, the resource_size_t is 32bit
| variable in 32bit OS, the BUG_ON() will be invoked to result in the Int 6
| error. I try the latest 32bit Ubuntu and Fedora distributions, all hit this
| bug.
|======
|static int firmware_map_add_entry(resource_size_t start, resource_size_t end,
| const char *type,
| struct firmware_map_entry *entry)
and it only happen with CONFIG_PHYS_ADDR_T_64BIT is not set.
it turns out we need to pass u64 instead of resource_size_t for that.
[akpm@linux-foundation.org: add comment]
Reported-and-tested-by: Peer Chen <pchen@nvidia.com>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
Cc: Ingo Molnar <mingo@elte.hu>
Acked-by: H. Peter Anvin <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: <stable@kernel.org>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Diffstat (limited to 'drivers/firmware')
| -rw-r--r-- | drivers/firmware/memmap.c | 16 |
1 files changed, 9 insertions, 7 deletions
diff --git a/drivers/firmware/memmap.c b/drivers/firmware/memmap.c index 05aa2d406ac6..d5ea8a68d338 100644 --- a/drivers/firmware/memmap.c +++ b/drivers/firmware/memmap.c @@ -31,8 +31,12 @@ * information is necessary as for the resource tree. */ struct firmware_map_entry { - resource_size_t start; /* start of the memory range */ - resource_size_t end; /* end of the memory range (incl.) */ + /* + * start and end must be u64 rather than resource_size_t, because e820 + * resources can lie at addresses above 4G. + */ + u64 start; /* start of the memory range */ + u64 end; /* end of the memory range (incl.) */ const char *type; /* type of the memory range */ struct list_head list; /* entry for the linked list */ struct kobject kobj; /* kobject for each entry */ @@ -101,7 +105,7 @@ static LIST_HEAD(map_entries); * Common implementation of firmware_map_add() and firmware_map_add_early() * which expects a pre-allocated struct firmware_map_entry. **/ -static int firmware_map_add_entry(resource_size_t start, resource_size_t end, +static int firmware_map_add_entry(u64 start, u64 end, const char *type, struct firmware_map_entry *entry) { @@ -132,8 +136,7 @@ static int firmware_map_add_entry(resource_size_t start, resource_size_t end, * * Returns 0 on success, or -ENOMEM if no memory could be allocated. **/ -int firmware_map_add(resource_size_t start, resource_size_t end, - const char *type) +int firmware_map_add(u64 start, u64 end, const char *type) { struct firmware_map_entry *entry; @@ -157,8 +160,7 @@ int firmware_map_add(resource_size_t start, resource_size_t end, * * Returns 0 on success, or -ENOMEM if no memory could be allocated. **/ -int __init firmware_map_add_early(resource_size_t start, resource_size_t end, - const char *type) +int __init firmware_map_add_early(u64 start, u64 end, const char *type) { struct firmware_map_entry *entry; |