2005-04-17 02:20:36 +04:00
/*
* linux / kernel / resource . c
*
* Copyright ( C ) 1999 Linus Torvalds
* Copyright ( C ) 1999 Martin Mares < mj @ ucw . cz >
*
* Arbitrary resource management .
*/
2012-07-31 01:42:58 +04:00
# define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
2011-05-23 22:51:41 +04:00
# include <linux/export.h>
2005-04-17 02:20:36 +04:00
# include <linux/errno.h>
# include <linux/ioport.h>
# include <linux/init.h>
# include <linux/slab.h>
# include <linux/spinlock.h>
# include <linux/fs.h>
# include <linux/proc_fs.h>
2010-03-29 21:38:00 +04:00
# include <linux/sched.h>
2005-04-17 02:20:36 +04:00
# include <linux/seq_file.h>
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
# include <linux/device.h>
2008-10-28 21:45:42 +03:00
# include <linux/pfn.h>
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
# include <linux/mm.h>
2015-02-05 08:44:43 +03:00
# include <linux/resource_ext.h>
2005-04-17 02:20:36 +04:00
# include <asm/io.h>
struct resource ioport_resource = {
. name = " PCI IO " ,
2006-06-13 04:11:31 +04:00
. start = 0 ,
2005-04-17 02:20:36 +04:00
. end = IO_SPACE_LIMIT ,
. flags = IORESOURCE_IO ,
} ;
EXPORT_SYMBOL ( ioport_resource ) ;
struct resource iomem_resource = {
. name = " PCI mem " ,
2006-06-13 04:11:31 +04:00
. start = 0 ,
. end = - 1 ,
2005-04-17 02:20:36 +04:00
. flags = IORESOURCE_MEM ,
} ;
EXPORT_SYMBOL ( iomem_resource ) ;
2011-07-06 10:44:30 +04:00
/* constraints to be met while allocating resources */
struct resource_constraint {
resource_size_t min , max , align ;
resource_size_t ( * alignf ) ( void * , const struct resource * ,
resource_size_t , resource_size_t ) ;
void * alignf_data ;
} ;
2005-04-17 02:20:36 +04:00
static DEFINE_RWLOCK ( resource_lock ) ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
/*
* For memory hotplug , there is no way to free resource entries allocated
* by boot mem after the system is up . So for reusing the resource entry
* we need to remember the resource .
*/
static struct resource * bootmem_resource_free ;
static DEFINE_SPINLOCK ( bootmem_resource_lock ) ;
2014-08-09 01:25:50 +04:00
static struct resource * next_resource ( struct resource * p , bool sibling_only )
2005-04-17 02:20:36 +04:00
{
2014-08-09 01:25:50 +04:00
/* Caller wants to traverse through siblings only */
if ( sibling_only )
return p - > sibling ;
2005-04-17 02:20:36 +04:00
if ( p - > child )
return p - > child ;
while ( ! p - > sibling & & p - > parent )
p = p - > parent ;
return p - > sibling ;
}
2014-08-09 01:25:50 +04:00
static void * r_next ( struct seq_file * m , void * v , loff_t * pos )
{
struct resource * p = v ;
( * pos ) + + ;
return ( void * ) next_resource ( p , false ) ;
}
2008-09-26 12:10:12 +04:00
# ifdef CONFIG_PROC_FS
enum { MAX_IORES_LEVEL = 5 } ;
2005-04-17 02:20:36 +04:00
static void * r_start ( struct seq_file * m , loff_t * pos )
__acquires ( resource_lock )
{
2018-04-11 12:52:39 +03:00
struct resource * p = PDE_DATA ( file_inode ( m - > file ) ) ;
2005-04-17 02:20:36 +04:00
loff_t l = 0 ;
read_lock ( & resource_lock ) ;
for ( p = p - > child ; p & & l < * pos ; p = r_next ( m , p , & l ) )
;
return p ;
}
static void r_stop ( struct seq_file * m , void * v )
__releases ( resource_lock )
{
read_unlock ( & resource_lock ) ;
}
static int r_show ( struct seq_file * m , void * v )
{
2018-04-11 12:52:39 +03:00
struct resource * root = PDE_DATA ( file_inode ( m - > file ) ) ;
2005-04-17 02:20:36 +04:00
struct resource * r = v , * p ;
2016-04-14 22:05:37 +03:00
unsigned long long start , end ;
2005-04-17 02:20:36 +04:00
int width = root - > end < 0x10000 ? 4 : 8 ;
int depth ;
for ( depth = 0 , p = r ; depth < MAX_IORES_LEVEL ; depth + + , p = p - > parent )
if ( p - > parent = = root )
break ;
2016-04-14 22:05:37 +03:00
if ( file_ns_capable ( m - > file , & init_user_ns , CAP_SYS_ADMIN ) ) {
start = r - > start ;
end = r - > end ;
} else {
start = end = 0 ;
}
2006-06-13 02:18:31 +04:00
seq_printf ( m , " %*s%0*llx-%0*llx : %s \n " ,
2005-04-17 02:20:36 +04:00
depth * 2 , " " ,
2016-04-14 22:05:37 +03:00
width , start ,
width , end ,
2005-04-17 02:20:36 +04:00
r - > name ? r - > name : " <BAD> " ) ;
return 0 ;
}
2006-12-07 07:40:36 +03:00
static const struct seq_operations resource_op = {
2005-04-17 02:20:36 +04:00
. start = r_start ,
. next = r_next ,
. stop = r_stop ,
. show = r_show ,
} ;
static int __init ioresources_init ( void )
{
2018-04-11 12:52:39 +03:00
proc_create_seq_data ( " ioports " , 0 , NULL , & resource_op ,
& ioport_resource ) ;
proc_create_seq_data ( " iomem " , 0 , NULL , & resource_op , & iomem_resource ) ;
2005-04-17 02:20:36 +04:00
return 0 ;
}
__initcall ( ioresources_init ) ;
# endif /* CONFIG_PROC_FS */
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
static void free_resource ( struct resource * res )
{
if ( ! res )
return ;
if ( ! PageSlab ( virt_to_head_page ( res ) ) ) {
spin_lock ( & bootmem_resource_lock ) ;
res - > sibling = bootmem_resource_free ;
bootmem_resource_free = res ;
spin_unlock ( & bootmem_resource_lock ) ;
} else {
kfree ( res ) ;
}
}
static struct resource * alloc_resource ( gfp_t flags )
{
struct resource * res = NULL ;
spin_lock ( & bootmem_resource_lock ) ;
if ( bootmem_resource_free ) {
res = bootmem_resource_free ;
bootmem_resource_free = res - > sibling ;
}
spin_unlock ( & bootmem_resource_lock ) ;
if ( res )
memset ( res , 0 , sizeof ( struct resource ) ) ;
else
res = kzalloc ( sizeof ( struct resource ) , flags ) ;
return res ;
}
2005-04-17 02:20:36 +04:00
/* Return the conflict entry if you can't request it */
static struct resource * __request_resource ( struct resource * root , struct resource * new )
{
2006-06-13 03:09:23 +04:00
resource_size_t start = new - > start ;
resource_size_t end = new - > end ;
2005-04-17 02:20:36 +04:00
struct resource * tmp , * * p ;
if ( end < start )
return root ;
if ( start < root - > start )
return root ;
if ( end > root - > end )
return root ;
p = & root - > child ;
for ( ; ; ) {
tmp = * p ;
if ( ! tmp | | tmp - > start > end ) {
new - > sibling = tmp ;
* p = new ;
new - > parent = root ;
return NULL ;
}
p = & tmp - > sibling ;
if ( tmp - > end < start )
continue ;
return tmp ;
}
}
2016-03-09 22:47:04 +03:00
static int __release_resource ( struct resource * old , bool release_child )
2005-04-17 02:20:36 +04:00
{
2016-03-09 22:47:04 +03:00
struct resource * tmp , * * p , * chd ;
2005-04-17 02:20:36 +04:00
p = & old - > parent - > child ;
for ( ; ; ) {
tmp = * p ;
if ( ! tmp )
break ;
if ( tmp = = old ) {
2016-03-09 22:47:04 +03:00
if ( release_child | | ! ( tmp - > child ) ) {
* p = tmp - > sibling ;
} else {
for ( chd = tmp - > child ; ; chd = chd - > sibling ) {
chd - > parent = tmp - > parent ;
if ( ! ( chd - > sibling ) )
break ;
}
* p = tmp - > child ;
chd - > sibling = tmp - > sibling ;
}
2005-04-17 02:20:36 +04:00
old - > parent = NULL ;
return 0 ;
}
p = & tmp - > sibling ;
}
return - EINVAL ;
}
2009-12-23 02:02:22 +03:00
static void __release_child_resources ( struct resource * r )
{
struct resource * tmp , * p ;
resource_size_t size ;
p = r - > child ;
r - > child = NULL ;
while ( p ) {
tmp = p ;
p = p - > sibling ;
tmp - > parent = NULL ;
tmp - > sibling = NULL ;
__release_child_resources ( tmp ) ;
printk ( KERN_DEBUG " release child resource %pR \n " , tmp ) ;
/* need to restore size, and keep flags */
size = resource_size ( tmp ) ;
tmp - > start = 0 ;
tmp - > end = size - 1 ;
}
}
void release_child_resources ( struct resource * r )
{
write_lock ( & resource_lock ) ;
__release_child_resources ( r ) ;
write_unlock ( & resource_lock ) ;
}
2006-10-03 12:13:51 +04:00
/**
2010-03-12 03:01:09 +03:00
* request_resource_conflict - request and reserve an I / O or memory resource
2006-10-03 12:13:51 +04:00
* @ root : root resource descriptor
* @ new : resource descriptor desired by caller
*
2010-03-12 03:01:09 +03:00
* Returns 0 for success , conflict resource on error .
2006-10-03 12:13:51 +04:00
*/
2010-03-12 03:01:09 +03:00
struct resource * request_resource_conflict ( struct resource * root , struct resource * new )
2005-04-17 02:20:36 +04:00
{
struct resource * conflict ;
write_lock ( & resource_lock ) ;
conflict = __request_resource ( root , new ) ;
write_unlock ( & resource_lock ) ;
2010-03-12 03:01:09 +03:00
return conflict ;
}
/**
* request_resource - request and reserve an I / O or memory resource
* @ root : root resource descriptor
* @ new : resource descriptor desired by caller
*
* Returns 0 for success , negative error code on error .
*/
int request_resource ( struct resource * root , struct resource * new )
{
struct resource * conflict ;
conflict = request_resource_conflict ( root , new ) ;
2005-04-17 02:20:36 +04:00
return conflict ? - EBUSY : 0 ;
}
EXPORT_SYMBOL ( request_resource ) ;
2006-10-03 12:13:51 +04:00
/**
* release_resource - release a previously reserved resource
* @ old : resource pointer
*/
2005-04-17 02:20:36 +04:00
int release_resource ( struct resource * old )
{
int retval ;
write_lock ( & resource_lock ) ;
2016-03-09 22:47:04 +03:00
retval = __release_resource ( old , true ) ;
2005-04-17 02:20:36 +04:00
write_unlock ( & resource_lock ) ;
return retval ;
}
EXPORT_SYMBOL ( release_resource ) ;
2018-11-05 12:33:07 +03:00
/**
* Finds the lowest iomem resource that covers part of [ @ start . . @ end ] . The
* caller must specify @ start , @ end , @ flags , and @ desc ( which may be
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
* IORES_DESC_NONE ) .
*
2018-11-05 12:33:07 +03:00
* If a resource is found , returns 0 and @ * res is overwritten with the part
* of the resource that ' s within [ @ start . . @ end ] ; if none is found , returns
* - 1 or - EINVAL for other invalid parameters .
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
*
* This function walks the whole tree and not just first level children
2018-10-09 17:11:21 +03:00
* unless @ first_lvl is true .
2018-11-05 12:33:07 +03:00
*
* @ start : start address of the resource searched for
* @ end : end address of same resource
* @ flags : flags which the resource must have
* @ desc : descriptor the resource must have
* @ first_lvl : walk only the first level children , if set
* @ res : return ptr , if resource found
2006-06-27 13:53:36 +04:00
*/
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
static int find_next_iomem_res ( resource_size_t start , resource_size_t end ,
unsigned long flags , unsigned long desc ,
2018-10-09 17:11:21 +03:00
bool first_lvl , struct resource * res )
2006-06-27 13:53:36 +04:00
{
struct resource * p ;
2018-10-09 17:11:21 +03:00
if ( ! res )
return - EINVAL ;
2006-06-27 13:53:36 +04:00
2018-10-09 17:11:21 +03:00
if ( start > = end )
return - EINVAL ;
2014-08-09 01:25:50 +04:00
2014-08-30 02:18:29 +04:00
read_lock ( & resource_lock ) ;
2018-10-09 17:11:21 +03:00
for ( p = iomem_resource . child ; p ; p = next_resource ( p , first_lvl ) ) {
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
if ( ( p - > flags & flags ) ! = flags )
2006-06-27 13:53:36 +04:00
continue ;
2016-01-26 23:57:29 +03:00
if ( ( desc ! = IORES_DESC_NONE ) & & ( desc ! = p - > desc ) )
continue ;
2006-06-27 13:53:36 +04:00
if ( p - > start > end ) {
p = NULL ;
break ;
}
resource: Include resource end in walk_*() interfaces
find_next_iomem_res() finds an iomem resource that covers part of a range
described by "start, end". All callers expect that range to be inclusive,
i.e., both start and end are included, but find_next_iomem_res() doesn't
handle the end address correctly.
If it finds an iomem resource that contains exactly the end address, it
skips it, e.g., if "start, end" is [0x0-0x10000] and there happens to be an
iomem resource [mem 0x10000-0x10000] (the single byte at 0x10000), we skip
it:
find_next_iomem_res(...)
{
start = 0x0;
end = 0x10000;
for (p = next_resource(...)) {
# p->start = 0x10000;
# p->end = 0x10000;
# we *should* return this resource, but this condition is false:
if ((p->end >= start) && (p->start < end))
break;
Adjust find_next_iomem_res() so it allows a resource that includes the
single byte at the end of the range. This is a corner case that we
probably don't see in practice.
Fixes: 58c1b5b07907 ("[PATCH] memory hotadd fixes: find_next_system_ram catch range fix")
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812254.1157.16736368485811773752.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:02 +03:00
if ( ( p - > end > = start ) & & ( p - > start < = end ) )
2006-06-27 13:53:36 +04:00
break ;
}
2014-08-09 01:25:50 +04:00
2006-06-27 13:53:36 +04:00
read_unlock ( & resource_lock ) ;
if ( ! p )
return - 1 ;
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
2006-06-27 13:53:36 +04:00
/* copy data */
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
res - > start = max ( start , p - > start ) ;
res - > end = min ( end , p - > end ) ;
2017-10-20 17:30:52 +03:00
res - > flags = p - > flags ;
res - > desc = p - > desc ;
2006-06-27 13:53:36 +04:00
return 0 ;
}
2009-09-23 03:45:46 +04:00
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
static int __walk_iomem_res_desc ( resource_size_t start , resource_size_t end ,
unsigned long flags , unsigned long desc ,
2018-10-09 17:11:21 +03:00
bool first_lvl , void * arg ,
2017-10-20 17:30:51 +03:00
int ( * func ) ( struct resource * , void * ) )
2017-10-20 17:30:50 +03:00
{
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
struct resource res ;
2019-02-25 21:57:30 +03:00
int ret = - EINVAL ;
2017-10-20 17:30:50 +03:00
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
while ( start < end & &
2018-10-09 17:11:21 +03:00
! find_next_iomem_res ( start , end , flags , desc , first_lvl , & res ) ) {
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
ret = ( * func ) ( & res , arg ) ;
2017-10-20 17:30:50 +03:00
if ( ret )
break ;
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
start = res . end + 1 ;
2017-10-20 17:30:50 +03:00
}
return ret ;
}
2018-10-09 17:11:21 +03:00
/**
2018-11-05 12:33:07 +03:00
* Walks through iomem resources and calls func ( ) with matching resource
2014-08-09 01:25:50 +04:00
* ranges . This walks through whole tree and not just first level children .
* All the memory ranges which overlap start , end and also match flags and
2016-01-26 23:57:29 +03:00
* desc are valid candidates .
*
* @ desc : I / O resource descriptor . Use IORES_DESC_NONE to skip @ desc check .
* @ flags : I / O resource flags
* @ start : start addr
* @ end : end addr
2018-11-05 05:40:14 +03:00
* @ arg : function argument for the callback @ func
* @ func : callback function that is called for each qualifying resource area
2016-01-26 23:57:29 +03:00
*
* NOTE : For a new descriptor search , define a new IORES_DESC in
* < linux / ioport . h > and set it in ' desc ' of a target resource entry .
*/
int walk_iomem_res_desc ( unsigned long desc , unsigned long flags , u64 start ,
2017-10-20 17:30:51 +03:00
u64 end , void * arg , int ( * func ) ( struct resource * , void * ) )
2016-01-26 23:57:29 +03:00
{
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
return __walk_iomem_res_desc ( start , end , flags , desc , false , arg , func ) ;
2016-01-26 23:57:29 +03:00
}
2018-06-02 21:43:39 +03:00
EXPORT_SYMBOL_GPL ( walk_iomem_res_desc ) ;
2016-01-26 23:57:29 +03:00
2014-08-09 01:25:50 +04:00
/*
2016-01-26 23:57:26 +03:00
* This function calls the @ func callback against all memory ranges of type
* System RAM which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY .
* Now , this function is only for System RAM , it deals with full ranges and
* not PFNs . If resources are not PFN - aligned , dealing with PFNs can truncate
* ranges .
2014-08-09 01:25:50 +04:00
*/
int walk_system_ram_res ( u64 start , u64 end , void * arg ,
2018-10-09 17:11:21 +03:00
int ( * func ) ( struct resource * , void * ) )
2014-08-09 01:25:50 +04:00
{
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
unsigned long flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY ;
2014-08-09 01:25:50 +04:00
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
return __walk_iomem_res_desc ( start , end , flags , IORES_DESC_NONE , true ,
2017-10-20 17:30:52 +03:00
arg , func ) ;
}
/*
* This function calls the @ func callback against all memory ranges , which
* are ranges marked as IORESOURCE_MEM and IORESOUCE_BUSY .
*/
int walk_mem_res ( u64 start , u64 end , void * arg ,
int ( * func ) ( struct resource * , void * ) )
{
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
unsigned long flags = IORESOURCE_MEM | IORESOURCE_BUSY ;
2017-10-20 17:30:52 +03:00
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
return __walk_iomem_res_desc ( start , end , flags , IORES_DESC_NONE , true ,
2017-10-20 17:30:50 +03:00
arg , func ) ;
2014-08-09 01:25:50 +04:00
}
2009-09-23 03:45:46 +04:00
/*
2016-01-26 23:57:26 +03:00
* This function calls the @ func callback against all memory ranges of type
* System RAM which are marked as IORESOURCE_SYSTEM_RAM and IORESOUCE_BUSY .
* It is to be used only for System RAM .
2019-02-25 21:57:38 +03:00
*
* This will find System RAM ranges that are children of top - level resources
* in addition to top - level System RAM resources .
2009-09-23 03:45:46 +04:00
*/
int walk_system_ram_range ( unsigned long start_pfn , unsigned long nr_pages ,
2018-10-09 17:11:21 +03:00
void * arg , int ( * func ) ( unsigned long , unsigned long , void * ) )
2007-10-16 12:26:10 +04:00
{
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
resource_size_t start , end ;
unsigned long flags ;
2007-10-16 12:26:10 +04:00
struct resource res ;
2010-03-01 16:55:51 +03:00
unsigned long pfn , end_pfn ;
2019-02-25 21:57:30 +03:00
int ret = - EINVAL ;
2009-09-23 03:45:46 +04:00
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
start = ( u64 ) start_pfn < < PAGE_SHIFT ;
end = ( ( u64 ) ( start_pfn + nr_pages ) < < PAGE_SHIFT ) - 1 ;
flags = IORESOURCE_SYSTEM_RAM | IORESOURCE_BUSY ;
while ( start < end & &
! find_next_iomem_res ( start , end , flags , IORES_DESC_NONE ,
2019-02-25 21:57:38 +03:00
false , & res ) ) {
2010-03-01 16:55:51 +03:00
pfn = ( res . start + PAGE_SIZE - 1 ) > > PAGE_SHIFT ;
end_pfn = ( res . end + 1 ) > > PAGE_SHIFT ;
if ( end_pfn > pfn )
2010-03-02 22:21:09 +03:00
ret = ( * func ) ( pfn , end_pfn - pfn , arg ) ;
2007-10-16 12:26:10 +04:00
if ( ret )
break ;
resource: Fix find_next_iomem_res() iteration issue
Previously find_next_iomem_res() used "*res" as both an input parameter for
the range to search and the type of resource to search for, and an output
parameter for the resource we found, which makes the interface confusing.
The current callers use find_next_iomem_res() incorrectly because they
allocate a single struct resource and use it for repeated calls to
find_next_iomem_res(). When find_next_iomem_res() returns a resource, it
overwrites the start, end, flags, and desc members of the struct. If we
call find_next_iomem_res() again, we must update or restore these fields.
The previous code restored res.start and res.end, but not res.flags or
res.desc.
Since the callers did not restore res.flags, if they searched for flags
IORESOURCE_MEM | IORESOURCE_BUSY and found a resource with flags
IORESOURCE_MEM | IORESOURCE_BUSY | IORESOURCE_SYSRAM, the next search would
incorrectly skip resources unless they were also marked as
IORESOURCE_SYSRAM.
Fix this by restructuring the interface so it takes explicit "start, end,
flags" parameters and uses "*res" only as an output parameter.
Based on a patch by Lianbo Jiang <lijiang@redhat.com>.
[ bp: While at it:
- make comments kernel-doc style.
-
Originally-by: http://lore.kernel.org/lkml/20180921073211.20097-2-lijiang@redhat.com
Signed-off-by: Bjorn Helgaas <bhelgaas@google.com>
Signed-off-by: Borislav Petkov <bp@suse.de>
CC: Andrew Morton <akpm@linux-foundation.org>
CC: Brijesh Singh <brijesh.singh@amd.com>
CC: Dan Williams <dan.j.williams@intel.com>
CC: H. Peter Anvin <hpa@zytor.com>
CC: Lianbo Jiang <lijiang@redhat.com>
CC: Takashi Iwai <tiwai@suse.de>
CC: Thomas Gleixner <tglx@linutronix.de>
CC: Tom Lendacky <thomas.lendacky@amd.com>
CC: Vivek Goyal <vgoyal@redhat.com>
CC: Yaowei Bai <baiyaowei@cmss.chinamobile.com>
CC: bhe@redhat.com
CC: dan.j.williams@intel.com
CC: dyoung@redhat.com
CC: kexec@lists.infradead.org
CC: mingo@redhat.com
CC: x86-ml <x86@kernel.org>
Link: http://lkml.kernel.org/r/153805812916.1157.177580438135143788.stgit@bhelgaas-glaptop.roam.corp.google.com
2018-09-27 17:22:09 +03:00
start = res . end + 1 ;
2007-10-16 12:26:10 +04:00
}
return ret ;
}
2010-01-22 11:16:19 +03:00
static int __is_ram ( unsigned long pfn , unsigned long nr_pages , void * arg )
{
return 1 ;
}
2017-10-20 17:30:50 +03:00
2010-01-22 11:16:19 +03:00
/*
* This generic page_is_ram ( ) returns true if specified address is
2016-01-26 23:57:26 +03:00
* registered as System RAM in iomem_resource list .
2010-01-22 11:16:19 +03:00
*/
2010-01-27 03:31:19 +03:00
int __weak page_is_ram ( unsigned long pfn )
2010-01-22 11:16:19 +03:00
{
return walk_system_ram_range ( pfn , 1 , NULL , __is_ram ) = = 1 ;
}
2013-06-07 02:20:51 +04:00
EXPORT_SYMBOL_GPL ( page_is_ram ) ;
2010-01-22 11:16:19 +03:00
2015-08-11 06:07:05 +03:00
/**
* region_intersects ( ) - determine intersection of region with known resources
* @ start : region start address
* @ size : size of region
2016-01-26 23:57:28 +03:00
* @ flags : flags of resource ( in iomem_resource )
* @ desc : descriptor of resource ( in iomem_resource ) or IORES_DESC_NONE
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
*
2015-08-11 06:07:05 +03:00
* Check if the specified region partially overlaps or fully eclipses a
2016-01-26 23:57:28 +03:00
* resource identified by @ flags and @ desc ( optional with IORES_DESC_NONE ) .
* Return REGION_DISJOINT if the region does not overlap @ flags / @ desc ,
* return REGION_MIXED if the region overlaps @ flags / @ desc and another
* resource , and return REGION_INTERSECTS if the region overlaps @ flags / @ desc
* and no other defined resource . Note that REGION_INTERSECTS is also
* returned in the case when the specified region overlaps RAM and undefined
* memory holes .
2015-08-11 06:07:05 +03:00
*
* region_intersect ( ) is used by memory remapping functions to ensure
* the user is not remapping RAM and is a vast speed up over walking
* through the resource table page by page .
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
*/
2016-01-26 23:57:28 +03:00
int region_intersects ( resource_size_t start , size_t size , unsigned long flags ,
unsigned long desc )
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
{
2015-08-11 06:07:05 +03:00
resource_size_t end = start + size - 1 ;
int type = 0 ; int other = 0 ;
struct resource * p ;
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
read_lock ( & resource_lock ) ;
for ( p = iomem_resource . child ; p ; p = p - > sibling ) {
2016-01-26 23:57:28 +03:00
bool is_type = ( ( ( p - > flags & flags ) = = flags ) & &
( ( desc = = IORES_DESC_NONE ) | |
( desc = = p - > desc ) ) ) ;
2015-08-11 06:07:05 +03:00
if ( start > = p - > start & & start < = p - > end )
is_type ? type + + : other + + ;
if ( end > = p - > start & & end < = p - > end )
is_type ? type + + : other + + ;
if ( p - > start > = start & & p - > end < = end )
is_type ? type + + : other + + ;
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
}
read_unlock ( & resource_lock ) ;
2015-08-11 06:07:05 +03:00
if ( other = = 0 )
return type ? REGION_INTERSECTS : REGION_DISJOINT ;
if ( type )
return REGION_MIXED ;
return REGION_DISJOINT ;
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
}
2016-01-26 23:57:28 +03:00
EXPORT_SYMBOL_GPL ( region_intersects ) ;
x86: optimize resource lookups for ioremap
We have a large university system in the UK that is experiencing very long
delays modprobing the driver for a specific I/O device. The delay is from
8-10 minutes per device and there are 31 devices in the system. This 4 to
5 hour delay in starting up those I/O devices is very much a burden on the
customer.
There are two causes for requiring a restart/reload of the drivers. First
is periodic preventive maintenance (PM) and the second is if any of the
devices experience a fatal error. Both of these trigger this excessively
long delay in bringing the system back up to full capability.
The problem was tracked down to a very slow IOREMAP operation and the
excessively long ioresource lookup to insure that the user is not
attempting to ioremap RAM. These patches provide a speed up to that
function.
The modprobe time appears to be affected quite a bit by previous activity
on the ioresource list, which I suspect is due to cache preloading. While
the overall improvement is impacted by other overhead of starting the
devices, this drastically improves the modprobe time.
Also our system is considerably smaller so the percentages gained will not
be the same. Best case improvement with the modprobe on our 20 device
smallish system was from 'real 5m51.913s' to 'real 0m18.275s'.
This patch (of 2):
Since the ioremap operation is verifying that the specified address range
is NOT RAM, it will search the entire ioresource list if the condition is
true. To make matters worse, it does this one 4k page at a time. For a
128M BAR region this is 32 passes to determine the entire region does not
contain any RAM addresses.
This patch provides another resource lookup function, region_is_ram, that
searches for the entire region specified, verifying that it is completely
contained within the resource region. If it is found, then it is checked
to be RAM or not, within a single pass.
The return result reflects if it was found or not (-1), and whether it is
RAM (1) or not (0). This allows the caller to fallback to the previous
page by page search if it was not found.
[akpm@linux-foundation.org: fix spellos and typos in comment]
Signed-off-by: Mike Travis <travis@sgi.com>
Acked-by: Alex Thorlton <athorlton@sgi.com>
Reviewed-by: Cliff Wickman <cpw@sgi.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Mark Salter <msalter@redhat.com>
Cc: Dave Young <dyoung@redhat.com>
Cc: Rik van Riel <riel@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Mel Gorman <mgorman@suse.de>
Cc: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2014-10-14 02:54:03 +04:00
2010-12-16 20:38:46 +03:00
void __weak arch_remove_reservations ( struct resource * avail )
{
}
2010-10-27 01:41:13 +04:00
static resource_size_t simple_align_resource ( void * data ,
const struct resource * avail ,
resource_size_t size ,
resource_size_t align )
{
return avail - > start ;
}
2010-10-27 01:41:18 +04:00
static void resource_clip ( struct resource * res , resource_size_t min ,
resource_size_t max )
{
if ( res - > start < min )
res - > start = min ;
if ( res - > end > max )
res - > end = max ;
}
2005-04-17 02:20:36 +04:00
/*
2011-07-06 10:44:30 +04:00
* Find empty slot in the resource tree with the given range and
* alignment constraints
2005-04-17 02:20:36 +04:00
*/
2011-07-06 10:44:30 +04:00
static int __find_resource ( struct resource * root , struct resource * old ,
struct resource * new ,
resource_size_t size ,
struct resource_constraint * constraint )
2005-04-17 02:20:36 +04:00
{
struct resource * this = root - > child ;
2010-10-27 01:41:28 +04:00
struct resource tmp = * new , avail , alloc ;
2005-04-17 02:20:36 +04:00
2009-12-20 12:50:02 +03:00
tmp . start = root - > start ;
2005-04-17 02:20:36 +04:00
/*
2010-12-16 20:38:41 +03:00
* Skip past an allocated resource that starts at 0 , since the assignment
* of this - > start - 1 to tmp - > end below would cause an underflow .
2005-04-17 02:20:36 +04:00
*/
2011-07-06 10:44:30 +04:00
if ( this & & this - > start = = root - > start ) {
tmp . start = ( this = = old ) ? old - > start : this - > end + 1 ;
2005-04-17 02:20:36 +04:00
this = this - > sibling ;
}
2010-12-16 20:38:41 +03:00
for ( ; ; ) {
2005-04-17 02:20:36 +04:00
if ( this )
2011-07-06 10:44:30 +04:00
tmp . end = ( this = = old ) ? this - > end : this - > start - 1 ;
2005-04-17 02:20:36 +04:00
else
2009-12-20 12:50:02 +03:00
tmp . end = root - > end ;
2010-10-27 01:41:18 +04:00
2011-09-22 11:48:58 +04:00
if ( tmp . end < tmp . start )
goto next ;
2011-07-06 10:44:30 +04:00
resource_clip ( & tmp , constraint - > min , constraint - > max ) ;
2010-12-16 20:38:46 +03:00
arch_remove_reservations ( & tmp ) ;
2010-10-27 01:41:13 +04:00
2010-10-27 01:41:28 +04:00
/* Check for overflow after ALIGN() */
2011-07-06 10:44:30 +04:00
avail . start = ALIGN ( tmp . start , constraint - > align ) ;
2010-10-27 01:41:28 +04:00
avail . end = tmp . end ;
2014-02-05 07:32:28 +04:00
avail . flags = new - > flags & ~ IORESOURCE_UNSET ;
2010-10-27 01:41:28 +04:00
if ( avail . start > = tmp . start ) {
2014-02-05 07:32:28 +04:00
alloc . flags = avail . flags ;
2011-07-06 10:44:30 +04:00
alloc . start = constraint - > alignf ( constraint - > alignf_data , & avail ,
size , constraint - > align ) ;
2010-10-27 01:41:28 +04:00
alloc . end = alloc . start + size - 1 ;
2018-04-14 01:35:13 +03:00
if ( alloc . start < = alloc . end & &
resource_contains ( & avail , & alloc ) ) {
2010-10-27 01:41:28 +04:00
new - > start = alloc . start ;
new - > end = alloc . end ;
return 0 ;
}
2005-04-17 02:20:36 +04:00
}
2011-09-22 11:48:58 +04:00
next : if ( ! this | | this - > end = = root - > end )
2005-04-17 02:20:36 +04:00
break ;
2011-09-22 11:48:58 +04:00
2011-07-06 10:44:30 +04:00
if ( this ! = old )
tmp . start = this - > end + 1 ;
2005-04-17 02:20:36 +04:00
this = this - > sibling ;
}
return - EBUSY ;
}
2011-07-06 10:44:30 +04:00
/*
* Find empty slot in the resource tree given range and alignment .
*/
static int find_resource ( struct resource * root , struct resource * new ,
resource_size_t size ,
struct resource_constraint * constraint )
{
return __find_resource ( root , NULL , new , size , constraint ) ;
}
2006-10-03 12:13:51 +04:00
/**
2011-07-06 10:44:30 +04:00
* reallocate_resource - allocate a slot in the resource tree given range & alignment .
* The resource will be relocated if the new size cannot be reallocated in the
* current location .
*
* @ root : root resource descriptor
* @ old : resource descriptor desired by caller
* @ newsize : new size of the resource descriptor
* @ constraint : the size and alignment constraints to be met .
*/
2014-04-04 01:48:36 +04:00
static int reallocate_resource ( struct resource * root , struct resource * old ,
2018-10-09 17:11:21 +03:00
resource_size_t newsize ,
struct resource_constraint * constraint )
2011-07-06 10:44:30 +04:00
{
int err = 0 ;
struct resource new = * old ;
struct resource * conflict ;
write_lock ( & resource_lock ) ;
if ( ( err = __find_resource ( root , old , & new , newsize , constraint ) ) )
goto out ;
if ( resource_contains ( & new , old ) ) {
old - > start = new . start ;
old - > end = new . end ;
goto out ;
}
if ( old - > child ) {
err = - EBUSY ;
goto out ;
}
if ( resource_contains ( old , & new ) ) {
old - > start = new . start ;
old - > end = new . end ;
} else {
2016-03-09 22:47:04 +03:00
__release_resource ( old , true ) ;
2011-07-06 10:44:30 +04:00
* old = new ;
conflict = __request_resource ( root , old ) ;
BUG_ON ( conflict ) ;
}
out :
write_unlock ( & resource_lock ) ;
return err ;
}
/**
* allocate_resource - allocate empty slot in the resource tree given range & alignment .
* The resource will be reallocated with a new size if it was already allocated
2006-10-03 12:13:51 +04:00
* @ root : root resource descriptor
* @ new : resource descriptor desired by caller
* @ size : requested resource region size
2012-06-01 03:26:05 +04:00
* @ min : minimum boundary to allocate
* @ max : maximum boundary to allocate
2006-10-03 12:13:51 +04:00
* @ align : alignment requested , in bytes
* @ alignf : alignment function , optional , called if not NULL
* @ alignf_data : arbitrary data to pass to the @ alignf function
2005-04-17 02:20:36 +04:00
*/
int allocate_resource ( struct resource * root , struct resource * new ,
2006-06-13 03:09:23 +04:00
resource_size_t size , resource_size_t min ,
resource_size_t max , resource_size_t align ,
2010-01-01 19:40:49 +03:00
resource_size_t ( * alignf ) ( void * ,
2010-01-01 19:40:50 +03:00
const struct resource * ,
2010-01-01 19:40:49 +03:00
resource_size_t ,
resource_size_t ) ,
2005-04-17 02:20:36 +04:00
void * alignf_data )
{
int err ;
2011-07-06 10:44:30 +04:00
struct resource_constraint constraint ;
2005-04-17 02:20:36 +04:00
2010-10-27 01:41:13 +04:00
if ( ! alignf )
alignf = simple_align_resource ;
2011-07-06 10:44:30 +04:00
constraint . min = min ;
constraint . max = max ;
constraint . align = align ;
constraint . alignf = alignf ;
constraint . alignf_data = alignf_data ;
if ( new - > parent ) {
/* resource is already allocated, try reallocating with
the new constraints */
return reallocate_resource ( root , new , size , & constraint ) ;
}
2005-04-17 02:20:36 +04:00
write_lock ( & resource_lock ) ;
2011-07-06 10:44:30 +04:00
err = find_resource ( root , new , size , & constraint ) ;
2005-04-17 02:20:36 +04:00
if ( err > = 0 & & __request_resource ( root , new ) )
err = - EBUSY ;
write_unlock ( & resource_lock ) ;
return err ;
}
EXPORT_SYMBOL ( allocate_resource ) ;
2011-05-07 22:53:16 +04:00
/**
* lookup_resource - find an existing resource by a resource start address
* @ root : root resource descriptor
* @ start : resource start address
*
* Returns a pointer to the resource if found , NULL otherwise
*/
struct resource * lookup_resource ( struct resource * root , resource_size_t start )
{
struct resource * res ;
read_lock ( & resource_lock ) ;
for ( res = root - > child ; res ; res = res - > sibling ) {
if ( res - > start = = start )
break ;
}
read_unlock ( & resource_lock ) ;
return res ;
}
2008-08-30 07:18:31 +04:00
/*
* Insert a resource into the resource tree . If successful , return NULL ,
* otherwise return the conflicting resource ( compare to __request_resource ( ) )
2005-04-17 02:20:36 +04:00
*/
2008-08-30 07:18:31 +04:00
static struct resource * __insert_resource ( struct resource * parent , struct resource * new )
2005-04-17 02:20:36 +04:00
{
struct resource * first , * next ;
2006-06-30 13:31:24 +04:00
for ( ; ; parent = first ) {
first = __request_resource ( parent , new ) ;
if ( ! first )
2008-08-30 07:18:31 +04:00
return first ;
2006-06-30 13:31:24 +04:00
if ( first = = parent )
2008-08-30 07:18:31 +04:00
return first ;
2010-10-28 02:34:52 +04:00
if ( WARN_ON ( first = = new ) ) /* duplicated insertion */
return first ;
2006-06-30 13:31:24 +04:00
if ( ( first - > start > new - > start ) | | ( first - > end < new - > end ) )
break ;
if ( ( first - > start = = new - > start ) & & ( first - > end = = new - > end ) )
break ;
2005-04-17 02:20:36 +04:00
}
for ( next = first ; ; next = next - > sibling ) {
/* Partial overlap? Bad, and unfixable */
if ( next - > start < new - > start | | next - > end > new - > end )
2008-08-30 07:18:31 +04:00
return next ;
2005-04-17 02:20:36 +04:00
if ( ! next - > sibling )
break ;
if ( next - > sibling - > start > new - > end )
break ;
}
new - > parent = parent ;
new - > sibling = next - > sibling ;
new - > child = first ;
next - > sibling = NULL ;
for ( next = first ; next ; next = next - > sibling )
next - > parent = new ;
if ( parent - > child = = first ) {
parent - > child = new ;
} else {
next = parent - > child ;
while ( next - > sibling ! = first )
next = next - > sibling ;
next - > sibling = new ;
}
2008-08-30 07:18:31 +04:00
return NULL ;
}
2005-04-17 02:20:36 +04:00
2008-08-30 07:18:31 +04:00
/**
2010-03-12 03:01:09 +03:00
* insert_resource_conflict - Inserts resource in the resource tree
2008-08-30 07:18:31 +04:00
* @ parent : parent of the new resource
* @ new : new resource to insert
*
2010-03-12 03:01:09 +03:00
* Returns 0 on success , conflict resource if the resource can ' t be inserted .
2008-08-30 07:18:31 +04:00
*
2010-03-12 03:01:09 +03:00
* This function is equivalent to request_resource_conflict when no conflict
2008-08-30 07:18:31 +04:00
* happens . If a conflict happens , and the conflicting resources
* entirely fit within the range of the new resource , then the new
* resource is inserted and the conflicting resources become children of
* the new resource .
2016-03-09 22:47:04 +03:00
*
* This function is intended for producers of resources , such as FW modules
* and bus drivers .
2008-08-30 07:18:31 +04:00
*/
2010-03-12 03:01:09 +03:00
struct resource * insert_resource_conflict ( struct resource * parent , struct resource * new )
2008-08-30 07:18:31 +04:00
{
struct resource * conflict ;
write_lock ( & resource_lock ) ;
conflict = __insert_resource ( parent , new ) ;
write_unlock ( & resource_lock ) ;
2010-03-12 03:01:09 +03:00
return conflict ;
}
/**
* insert_resource - Inserts a resource in the resource tree
* @ parent : parent of the new resource
* @ new : new resource to insert
*
* Returns 0 on success , - EBUSY if the resource can ' t be inserted .
2016-03-09 22:47:04 +03:00
*
* This function is intended for producers of resources , such as FW modules
* and bus drivers .
2010-03-12 03:01:09 +03:00
*/
int insert_resource ( struct resource * parent , struct resource * new )
{
struct resource * conflict ;
conflict = insert_resource_conflict ( parent , new ) ;
2008-08-30 07:18:31 +04:00
return conflict ? - EBUSY : 0 ;
}
2016-03-09 22:47:05 +03:00
EXPORT_SYMBOL_GPL ( insert_resource ) ;
2008-08-30 07:18:31 +04:00
/**
* insert_resource_expand_to_fit - Insert a resource into the resource tree
2008-09-01 07:31:55 +04:00
* @ root : root resource descriptor
2008-08-30 07:18:31 +04:00
* @ new : new resource to insert
*
* Insert a resource into the resource tree , possibly expanding it in order
* to make it encompass any conflicting resources .
*/
void insert_resource_expand_to_fit ( struct resource * root , struct resource * new )
{
if ( new - > parent )
return ;
write_lock ( & resource_lock ) ;
for ( ; ; ) {
struct resource * conflict ;
conflict = __insert_resource ( root , new ) ;
if ( ! conflict )
break ;
if ( conflict = = root )
break ;
/* Ok, expand resource to cover the conflict, then try again .. */
if ( conflict - > start < new - > start )
new - > start = conflict - > start ;
if ( conflict - > end > new - > end )
new - > end = conflict - > end ;
printk ( " Expanded resource %s due to conflict with %s \n " , new - > name , conflict - > name ) ;
}
2005-04-17 02:20:36 +04:00
write_unlock ( & resource_lock ) ;
}
2016-03-09 22:47:04 +03:00
/**
* remove_resource - Remove a resource in the resource tree
* @ old : resource to remove
*
* Returns 0 on success , - EINVAL if the resource is not valid .
*
* This function removes a resource previously inserted by insert_resource ( )
* or insert_resource_conflict ( ) , and moves the children ( if any ) up to
* where they were before . insert_resource ( ) and insert_resource_conflict ( )
* insert a new resource , and move any conflicting resources down to the
* children of the new resource .
*
* insert_resource ( ) , insert_resource_conflict ( ) and remove_resource ( ) are
* intended for producers of resources , such as FW modules and bus drivers .
*/
int remove_resource ( struct resource * old )
{
int retval ;
write_lock ( & resource_lock ) ;
retval = __release_resource ( old , false ) ;
write_unlock ( & resource_lock ) ;
return retval ;
}
2016-03-09 22:47:05 +03:00
EXPORT_SYMBOL_GPL ( remove_resource ) ;
2016-03-09 22:47:04 +03:00
2013-04-30 02:08:17 +04:00
static int __adjust_resource ( struct resource * res , resource_size_t start ,
resource_size_t size )
2005-04-17 02:20:36 +04:00
{
struct resource * tmp , * parent = res - > parent ;
2006-06-13 03:09:23 +04:00
resource_size_t end = start + size - 1 ;
2005-04-17 02:20:36 +04:00
int result = - EBUSY ;
2012-05-18 05:51:11 +04:00
if ( ! parent )
goto skip ;
2005-04-17 02:20:36 +04:00
if ( ( start < parent - > start ) | | ( end > parent - > end ) )
goto out ;
if ( res - > sibling & & ( res - > sibling - > start < = end ) )
goto out ;
tmp = parent - > child ;
if ( tmp ! = res ) {
while ( tmp - > sibling ! = res )
tmp = tmp - > sibling ;
if ( start < = tmp - > end )
goto out ;
}
2012-05-18 05:51:11 +04:00
skip :
for ( tmp = res - > child ; tmp ; tmp = tmp - > sibling )
if ( ( tmp - > start < start ) | | ( tmp - > end > end ) )
goto out ;
2005-04-17 02:20:36 +04:00
res - > start = start ;
res - > end = end ;
result = 0 ;
out :
2013-04-30 02:08:17 +04:00
return result ;
}
/**
* adjust_resource - modify a resource ' s start and size
* @ res : resource to modify
* @ start : new start value
* @ size : new size
*
* Given an existing resource , change its start and size to match the
* arguments . Returns 0 on success , - EBUSY if it can ' t fit .
* Existing children of the resource are assumed to be immutable .
*/
int adjust_resource ( struct resource * res , resource_size_t start ,
2018-10-09 17:11:21 +03:00
resource_size_t size )
2013-04-30 02:08:17 +04:00
{
int result ;
write_lock ( & resource_lock ) ;
result = __adjust_resource ( res , start , size ) ;
2005-04-17 02:20:36 +04:00
write_unlock ( & resource_lock ) ;
return result ;
}
2012-02-03 17:42:39 +04:00
EXPORT_SYMBOL ( adjust_resource ) ;
2005-04-17 02:20:36 +04:00
2018-10-09 17:11:21 +03:00
static void __init
__reserve_region_with_split ( struct resource * root , resource_size_t start ,
resource_size_t end , const char * name )
2008-09-04 23:02:44 +04:00
{
struct resource * parent = root ;
struct resource * conflict ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
struct resource * res = alloc_resource ( GFP_ATOMIC ) ;
2012-10-05 04:16:55 +04:00
struct resource * next_res = NULL ;
2017-12-01 23:07:18 +03:00
int type = resource_type ( root ) ;
2008-09-04 23:02:44 +04:00
if ( ! res )
return ;
res - > name = name ;
res - > start = start ;
res - > end = end ;
2017-12-01 23:07:18 +03:00
res - > flags = type | IORESOURCE_BUSY ;
2016-01-26 23:57:19 +03:00
res - > desc = IORES_DESC_NONE ;
2008-09-04 23:02:44 +04:00
2012-10-05 04:16:55 +04:00
while ( 1 ) {
2008-09-04 23:02:44 +04:00
2012-10-05 04:16:55 +04:00
conflict = __request_resource ( parent , res ) ;
if ( ! conflict ) {
if ( ! next_res )
break ;
res = next_res ;
next_res = NULL ;
continue ;
}
2008-09-04 23:02:44 +04:00
2012-10-05 04:16:55 +04:00
/* conflict covered whole area */
if ( conflict - > start < = res - > start & &
conflict - > end > = res - > end ) {
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( res ) ;
2012-10-05 04:16:55 +04:00
WARN_ON ( next_res ) ;
break ;
}
/* failed, split and try again */
if ( conflict - > start > res - > start ) {
end = res - > end ;
res - > end = conflict - > start - 1 ;
if ( conflict - > end < end ) {
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
next_res = alloc_resource ( GFP_ATOMIC ) ;
2012-10-05 04:16:55 +04:00
if ( ! next_res ) {
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( res ) ;
2012-10-05 04:16:55 +04:00
break ;
}
next_res - > name = name ;
next_res - > start = conflict - > end + 1 ;
next_res - > end = end ;
2017-12-01 23:07:18 +03:00
next_res - > flags = type | IORESOURCE_BUSY ;
2016-01-26 23:57:19 +03:00
next_res - > desc = IORES_DESC_NONE ;
2012-10-05 04:16:55 +04:00
}
} else {
res - > start = conflict - > end + 1 ;
}
}
2008-09-04 23:02:44 +04:00
}
2018-10-09 17:11:21 +03:00
void __init
reserve_region_with_split ( struct resource * root , resource_size_t start ,
resource_size_t end , const char * name )
2008-09-04 23:02:44 +04:00
{
2012-07-31 01:42:58 +04:00
int abort = 0 ;
2008-09-04 23:02:44 +04:00
write_lock ( & resource_lock ) ;
2012-07-31 01:42:58 +04:00
if ( root - > start > start | | root - > end < end ) {
pr_err ( " requested range [0x%llx-0x%llx] not in root %pr \n " ,
( unsigned long long ) start , ( unsigned long long ) end ,
root ) ;
if ( start > root - > end | | end < root - > start )
abort = 1 ;
else {
if ( end > root - > end )
end = root - > end ;
if ( start < root - > start )
start = root - > start ;
pr_err ( " fixing request to [0x%llx-0x%llx] \n " ,
( unsigned long long ) start ,
( unsigned long long ) end ) ;
}
dump_stack ( ) ;
}
if ( ! abort )
__reserve_region_with_split ( root , start , end , name ) ;
2008-09-04 23:02:44 +04:00
write_unlock ( & resource_lock ) ;
}
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
/**
* resource_alignment - calculate resource ' s alignment
* @ res : resource pointer
*
* Returns alignment on success , 0 ( invalid alignment ) on failure .
*/
resource_size_t resource_alignment ( struct resource * res )
{
switch ( res - > flags & ( IORESOURCE_SIZEALIGN | IORESOURCE_STARTALIGN ) ) {
case IORESOURCE_SIZEALIGN :
2008-07-30 09:32:57 +04:00
return resource_size ( res ) ;
PCI: clean up resource alignment management
Done per Linus' request and suggestions. Linus has explained that
better than I'll be able to explain:
On Thu, Mar 27, 2008 at 10:12:10AM -0700, Linus Torvalds wrote:
> Actually, before we go any further, there might be a less intrusive
> alternative: add just a couple of flags to the resource flags field (we
> still have something like 8 unused bits on 32-bit), and use those to
> implement a generic "resource_alignment()" routine.
>
> Two flags would do it:
>
> - IORESOURCE_SIZEALIGN: size indicates alignment (regular PCI device
> resources)
>
> - IORESOURCE_STARTALIGN: start field is alignment (PCI bus resources
> during probing)
>
> and then the case of both flags zero (or both bits set) would actually be
> "invalid", and we would also clear the IORESOURCE_STARTALIGN flag when we
> actually allocate the resource (so that we don't use the "start" field as
> alignment incorrectly when it no longer indicates alignment).
>
> That wouldn't be totally generic, but it would have the nice property of
> automatically at least add sanity checking for that whole "res->start has
> the odd meaning of 'alignment' during probing" and remove the need for a
> new field, and it would allow us to have a generic "resource_alignment()"
> routine that just gets a resource pointer.
Besides, I removed IORESOURCE_BUS_HAS_VGA flag which was unused for ages.
Signed-off-by: Ivan Kokshaysky <ink@jurassic.park.msu.ru>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Gary Hade <garyhade@us.ibm.com>
Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de>
2008-03-30 19:50:14 +04:00
case IORESOURCE_STARTALIGN :
return res - > start ;
default :
return 0 ;
}
}
2005-04-17 02:20:36 +04:00
/*
* This is compatibility stuff for IO resources .
*
* Note how this , unlike the above , knows about
* the IO flag meanings ( busy etc ) .
*
2006-10-03 12:13:51 +04:00
* request_region creates a new busy region .
2005-04-17 02:20:36 +04:00
*
2006-10-03 12:13:51 +04:00
* release_region releases a matching busy region .
*/
2010-03-29 21:38:00 +04:00
static DECLARE_WAIT_QUEUE_HEAD ( muxed_resource_wait ) ;
2006-10-03 12:13:51 +04:00
/**
* __request_region - create a new busy resource region
* @ parent : parent resource descriptor
* @ start : resource start address
* @ n : resource region size
* @ name : reserving caller ' s ID string
2009-01-16 00:51:01 +03:00
* @ flags : IO resource flags
2005-04-17 02:20:36 +04:00
*/
2006-06-13 03:09:23 +04:00
struct resource * __request_region ( struct resource * parent ,
resource_size_t start , resource_size_t n ,
2008-10-23 06:55:31 +04:00
const char * name , int flags )
2005-04-17 02:20:36 +04:00
{
2010-03-29 21:38:00 +04:00
DECLARE_WAITQUEUE ( wait , current ) ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
struct resource * res = alloc_resource ( GFP_KERNEL ) ;
2005-04-17 02:20:36 +04:00
2008-10-16 09:05:14 +04:00
if ( ! res )
return NULL ;
res - > name = name ;
res - > start = start ;
res - > end = start + n - 1 ;
write_lock ( & resource_lock ) ;
for ( ; ; ) {
struct resource * conflict ;
2016-03-09 22:47:03 +03:00
res - > flags = resource_type ( parent ) | resource_ext_type ( parent ) ;
res - > flags | = IORESOURCE_BUSY | flags ;
res - > desc = parent - > desc ;
2008-10-16 09:05:14 +04:00
conflict = __request_resource ( parent , res ) ;
if ( ! conflict )
2005-04-17 02:20:36 +04:00
break ;
2019-02-25 21:57:33 +03:00
/*
* mm / hmm . c reserves physical addresses which then
* become unavailable to other users . Conflicts are
* not expected . Warn to aid debugging if encountered .
*/
if ( conflict - > desc = = IORES_DESC_DEVICE_PRIVATE_MEMORY ) {
pr_warn ( " Unaddressable device %s %pR conflicts with %pR " ,
conflict - > name , conflict , res ) ;
}
2008-10-16 09:05:14 +04:00
if ( conflict ! = parent ) {
2015-09-10 01:15:18 +03:00
if ( ! ( conflict - > flags & IORESOURCE_BUSY ) ) {
parent = conflict ;
2008-10-16 09:05:14 +04:00
continue ;
2015-09-10 01:15:18 +03:00
}
2005-04-17 02:20:36 +04:00
}
2010-03-29 21:38:00 +04:00
if ( conflict - > flags & flags & IORESOURCE_MUXED ) {
add_wait_queue ( & muxed_resource_wait , & wait ) ;
write_unlock ( & resource_lock ) ;
set_current_state ( TASK_UNINTERRUPTIBLE ) ;
schedule ( ) ;
remove_wait_queue ( & muxed_resource_wait , & wait ) ;
write_lock ( & resource_lock ) ;
continue ;
}
2008-10-16 09:05:14 +04:00
/* Uhhuh, that didn't work out.. */
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( res ) ;
2008-10-16 09:05:14 +04:00
res = NULL ;
break ;
2005-04-17 02:20:36 +04:00
}
2008-10-16 09:05:14 +04:00
write_unlock ( & resource_lock ) ;
2005-04-17 02:20:36 +04:00
return res ;
}
EXPORT_SYMBOL ( __request_region ) ;
2006-10-03 12:13:51 +04:00
/**
* __release_region - release a previously reserved resource region
* @ parent : parent resource descriptor
* @ start : resource start address
* @ n : resource region size
*
* The described resource region must match a currently busy region .
*/
2006-06-13 03:09:23 +04:00
void __release_region ( struct resource * parent , resource_size_t start ,
2018-10-09 17:11:21 +03:00
resource_size_t n )
2005-04-17 02:20:36 +04:00
{
struct resource * * p ;
2006-06-13 03:09:23 +04:00
resource_size_t end ;
2005-04-17 02:20:36 +04:00
p = & parent - > child ;
end = start + n - 1 ;
write_lock ( & resource_lock ) ;
for ( ; ; ) {
struct resource * res = * p ;
if ( ! res )
break ;
if ( res - > start < = start & & res - > end > = end ) {
if ( ! ( res - > flags & IORESOURCE_BUSY ) ) {
p = & res - > child ;
continue ;
}
if ( res - > start ! = start | | res - > end ! = end )
break ;
* p = res - > sibling ;
write_unlock ( & resource_lock ) ;
2010-03-29 21:38:00 +04:00
if ( res - > flags & IORESOURCE_MUXED )
wake_up ( & muxed_resource_wait ) ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( res ) ;
2005-04-17 02:20:36 +04:00
return ;
}
p = & res - > sibling ;
}
write_unlock ( & resource_lock ) ;
2006-06-13 02:18:31 +04:00
printk ( KERN_WARNING " Trying to free nonexistent resource "
" <%016llx-%016llx> \n " , ( unsigned long long ) start ,
( unsigned long long ) end ) ;
2005-04-17 02:20:36 +04:00
}
EXPORT_SYMBOL ( __release_region ) ;
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
# ifdef CONFIG_MEMORY_HOTREMOVE
/**
* release_mem_region_adjustable - release a previously reserved memory region
* @ parent : parent resource descriptor
* @ start : resource start address
* @ size : resource region size
*
* This interface is intended for memory hot - delete . The requested region
* is released from a currently busy memory resource . The requested region
* must either match exactly or fit into a single busy resource entry . In
* the latter case , the remaining resource is adjusted accordingly .
* Existing children of the busy memory resource must be immutable in the
* request .
*
* Note :
* - Additional release conditions , such as overlapping region , can be
* supported after they are confirmed as valid cases .
* - When a busy memory resource gets split into two entries , the code
* assumes that all children remain in the lower address entry for
* simplicity . Enhance this logic when necessary .
*/
int release_mem_region_adjustable ( struct resource * parent ,
2018-10-09 17:11:21 +03:00
resource_size_t start , resource_size_t size )
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
{
struct resource * * p ;
struct resource * res ;
struct resource * new_res ;
resource_size_t end ;
int ret = - EINVAL ;
end = start + size - 1 ;
if ( ( start < parent - > start ) | | ( end > parent - > end ) )
return ret ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
/* The alloc_resource() result gets checked later */
new_res = alloc_resource ( GFP_KERNEL ) ;
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
p = & parent - > child ;
write_lock ( & resource_lock ) ;
while ( ( res = * p ) ) {
if ( res - > start > = end )
break ;
/* look for the next resource if it does not fit into */
if ( res - > start > start | | res - > end < end ) {
p = & res - > sibling ;
continue ;
}
2018-12-28 11:36:26 +03:00
/*
* All memory regions added from memory - hotplug path have the
* flag IORESOURCE_SYSTEM_RAM . If the resource does not have
* this flag , we know that we are dealing with a resource coming
* from HMM / devm . HMM / devm use another mechanism to add / release
* a resource . This goes via devm_request_mem_region and
* devm_release_mem_region .
* HMM / devm take care to release their resources when they want ,
* so if we are dealing with them , let us just back off here .
*/
if ( ! ( res - > flags & IORESOURCE_SYSRAM ) ) {
ret = 0 ;
break ;
}
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
if ( ! ( res - > flags & IORESOURCE_MEM ) )
break ;
if ( ! ( res - > flags & IORESOURCE_BUSY ) ) {
p = & res - > child ;
continue ;
}
/* found the target resource; let's adjust accordingly */
if ( res - > start = = start & & res - > end = = end ) {
/* free the whole entry */
* p = res - > sibling ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( res ) ;
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
ret = 0 ;
} else if ( res - > start = = start & & res - > end ! = end ) {
/* adjust the start */
ret = __adjust_resource ( res , end + 1 ,
res - > end - end ) ;
} else if ( res - > start ! = start & & res - > end = = end ) {
/* adjust the end */
ret = __adjust_resource ( res , res - > start ,
start - res - > start ) ;
} else {
/* split into two entries */
if ( ! new_res ) {
ret = - ENOMEM ;
break ;
}
new_res - > name = res - > name ;
new_res - > start = end + 1 ;
new_res - > end = res - > end ;
new_res - > flags = res - > flags ;
2016-01-26 23:57:19 +03:00
new_res - > desc = res - > desc ;
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
new_res - > parent = res - > parent ;
new_res - > sibling = res - > sibling ;
new_res - > child = NULL ;
ret = __adjust_resource ( res , res - > start ,
start - res - > start ) ;
if ( ret )
break ;
res - > sibling = new_res ;
new_res = NULL ;
}
break ;
}
write_unlock ( & resource_lock ) ;
mem hotunplug: fix kfree() of bootmem memory
When hot removing memory presented at boot time, following messages are shown:
kernel BUG at mm/slub.c:3409!
invalid opcode: 0000 [#1] SMP
Modules linked in: ebtable_nat ebtables xt_CHECKSUM iptable_mangle bridge stp llc ipmi_devintf ipmi_msghandler sunrpc ipt_REJECT nf_conntrack_ipv4 nf_defrag_ipv4 iptable_filter ip_tables ip6t_REJECT nf_conntrack_ipv6 nf_defrag_ipv6 xt_state nf_conntrack ip6table_filter ip6_tables binfmt_misc vfat fat dm_mirror dm_region_hash dm_log dm_mod vhost_net macvtap macvlan tun uinput iTCO_wdt iTCO_vendor_support coretemp kvm_intel kvm crc32c_intel ghash_clmulni_intel microcode pcspkr sg i2c_i801 lpc_ich mfd_core igb i2c_algo_bit i2c_core e1000e ptp pps_core tpm_infineon ioatdma dca sr_mod cdrom sd_mod crc_t10dif usb_storage megaraid_sas lpfc scsi_transport_fc scsi_tgt scsi_mod
CPU 0
Pid: 5091, comm: kworker/0:2 Tainted: G W 3.9.0-rc6+ #15
RIP: kfree+0x232/0x240
Process kworker/0:2 (pid: 5091, threadinfo ffff88084678c000, task ffff88083928ca80)
Call Trace:
__release_region+0xd4/0xe0
__remove_pages+0x52/0x110
arch_remove_memory+0x89/0xd0
remove_memory+0xc4/0x100
acpi_memory_device_remove+0x6d/0xb1
acpi_device_remove+0x89/0xab
__device_release_driver+0x7c/0xf0
device_release_driver+0x2f/0x50
acpi_bus_device_detach+0x6c/0x70
acpi_ns_walk_namespace+0x11a/0x250
acpi_walk_namespace+0xee/0x137
acpi_bus_trim+0x33/0x7a
acpi_bus_hot_remove_device+0xc4/0x1a1
acpi_os_execute_deferred+0x27/0x34
process_one_work+0x1f7/0x590
worker_thread+0x11a/0x370
kthread+0xee/0x100
ret_from_fork+0x7c/0xb0
RIP [<ffffffff811c41d2>] kfree+0x232/0x240
RSP <ffff88084678d968>
The reason why the messages are shown is to release a resource
structure, allocated by bootmem, by kfree(). So when we release a
resource structure, we should check whether it is allocated by bootmem
or not.
But even if we know a resource structure is allocated by bootmem, we
cannot release it since SLxB cannot treat it. So for reusing a resource
structure, this patch remembers it by using bootmem_resource as follows:
When releasing a resource structure by free_resource(), free_resource()
checks whether the resource structure is allocated by bootmem or not.
If it is allocated by bootmem, free_resource() adds it to
bootmem_resource. If it is not allocated by bootmem, free_resource()
release it by kfree().
And when getting a new resource structure by get_resource(),
get_resource() checks whether bootmem_resource has released resource
structures or not. If there is a released resource structure,
get_resource() returns it. If there is not a releaed resource
structure, get_resource() returns new resource structure allocated by
kzalloc().
[akpm@linux-foundation.org: s/get_resource/alloc_resource/]
Signed-off-by: Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Reviewed-by: Toshi Kani <toshi.kani@hp.com>
Cc: Johannes Weiner <hannes@cmpxchg.org>
Cc: Ram Pai <linuxram@us.ibm.com>
Cc: David Rientjes <rientjes@google.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:56 +04:00
free_resource ( new_res ) ;
resource: add release_mem_region_adjustable()
Add release_mem_region_adjustable(), which releases a requested region
from a currently busy memory resource. This interface adjusts the
matched memory resource accordingly even if the requested region does
not match exactly but still fits into.
This new interface is intended for memory hot-delete. During bootup,
memory resources are inserted from the boot descriptor table, such as
EFI Memory Table and e820. Each memory resource entry usually covers
the whole contigous memory range. Memory hot-delete request, on the
other hand, may target to a particular range of memory resource, and its
size can be much smaller than the whole contiguous memory. Since the
existing release interfaces like __release_region() require a requested
region to be exactly matched to a resource entry, they do not allow a
partial resource to be released.
This new interface is restrictive (i.e. release under certain
conditions), which is consistent with other release interfaces,
__release_region() and __release_resource(). Additional release
conditions, such as an overlapping region to a resource entry, can be
supported after they are confirmed as valid cases.
There is no change to the existing interfaces since their restriction is
valid for I/O resources.
[akpm@linux-foundation.org: use GFP_ATOMIC under write_lock()]
[akpm@linux-foundation.org: switch back to GFP_KERNEL, less buggily]
[akpm@linux-foundation.org: remove unneeded and wrong kfree(), per Toshi]
Signed-off-by: Toshi Kani <toshi.kani@hp.com>
Reviewed-by : Yasuaki Ishimatsu <isimatu.yasuaki@jp.fujitsu.com>
Cc: David Rientjes <rientjes@google.com>
Reviewed-by: Ram Pai <linuxram@us.ibm.com>
Cc: T Makphaibulchoke <tmac@hp.com>
Cc: Wen Congyang <wency@cn.fujitsu.com>
Cc: Tang Chen <tangchen@cn.fujitsu.com>
Cc: Jiang Liu <jiang.liu@huawei.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2013-04-30 02:08:19 +04:00
return ret ;
}
# endif /* CONFIG_MEMORY_HOTREMOVE */
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
/*
* Managed region resource
*/
2014-08-01 16:15:10 +04:00
static void devm_resource_release ( struct device * dev , void * ptr )
{
struct resource * * r = ptr ;
release_resource ( * r ) ;
}
/**
* devm_request_resource ( ) - request and reserve an I / O or memory resource
* @ dev : device for which to request the resource
* @ root : root of the resource tree from which to request the resource
* @ new : descriptor of the resource to request
*
* This is a device - managed version of request_resource ( ) . There is usually
* no need to release resources requested by this function explicitly since
* that will be taken care of when the device is unbound from its driver .
* If for some reason the resource needs to be released explicitly , because
* of ordering issues for example , drivers must call devm_release_resource ( )
* rather than the regular release_resource ( ) .
*
* When a conflict is detected between any existing resources and the newly
* requested resource , an error message will be printed .
*
* Returns 0 on success or a negative error code on failure .
*/
int devm_request_resource ( struct device * dev , struct resource * root ,
struct resource * new )
{
struct resource * conflict , * * ptr ;
ptr = devres_alloc ( devm_resource_release , sizeof ( * ptr ) , GFP_KERNEL ) ;
if ( ! ptr )
return - ENOMEM ;
* ptr = new ;
conflict = request_resource_conflict ( root , new ) ;
if ( conflict ) {
dev_err ( dev , " resource collision: %pR conflicts with %s %pR \n " ,
new , conflict - > name , conflict ) ;
devres_free ( ptr ) ;
return - EBUSY ;
}
devres_add ( dev , ptr ) ;
return 0 ;
}
EXPORT_SYMBOL ( devm_request_resource ) ;
static int devm_resource_match ( struct device * dev , void * res , void * data )
{
struct resource * * ptr = res ;
return * ptr = = data ;
}
/**
* devm_release_resource ( ) - release a previously requested resource
* @ dev : device for which to release the resource
* @ new : descriptor of the resource to release
*
* Releases a resource previously requested using devm_request_resource ( ) .
*/
void devm_release_resource ( struct device * dev , struct resource * new )
{
WARN_ON ( devres_release ( dev , devm_resource_release , devm_resource_match ,
new ) ) ;
}
EXPORT_SYMBOL ( devm_release_resource ) ;
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
struct region_devres {
struct resource * parent ;
resource_size_t start ;
resource_size_t n ;
} ;
static void devm_region_release ( struct device * dev , void * res )
{
struct region_devres * this = res ;
__release_region ( this - > parent , this - > start , this - > n ) ;
}
static int devm_region_match ( struct device * dev , void * res , void * match_data )
{
struct region_devres * this = res , * match = match_data ;
return this - > parent = = match - > parent & &
this - > start = = match - > start & & this - > n = = match - > n ;
}
2018-10-09 17:11:21 +03:00
struct resource *
__devm_request_region ( struct device * dev , struct resource * parent ,
resource_size_t start , resource_size_t n , const char * name )
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
{
struct region_devres * dr = NULL ;
struct resource * res ;
dr = devres_alloc ( devm_region_release , sizeof ( struct region_devres ) ,
GFP_KERNEL ) ;
if ( ! dr )
return NULL ;
dr - > parent = parent ;
dr - > start = start ;
dr - > n = n ;
2008-10-23 06:55:31 +04:00
res = __request_region ( parent , start , n , name , 0 ) ;
devres: device resource management
Implement device resource management, in short, devres. A device
driver can allocate arbirary size of devres data which is associated
with a release function. On driver detach, release function is
invoked on the devres data, then, devres data is freed.
devreses are typed by associated release functions. Some devreses are
better represented by single instance of the type while others need
multiple instances sharing the same release function. Both usages are
supported.
devreses can be grouped using devres group such that a device driver
can easily release acquired resources halfway through initialization
or selectively release resources (e.g. resources for port 1 out of 4
ports).
This patch adds devres core including documentation and the following
managed interfaces.
* alloc/free : devm_kzalloc(), devm_kzfree()
* IO region : devm_request_region(), devm_release_region()
* IRQ : devm_request_irq(), devm_free_irq()
* DMA : dmam_alloc_coherent(), dmam_free_coherent(),
dmam_declare_coherent_memory(), dmam_pool_create(),
dmam_pool_destroy()
* PCI : pcim_enable_device(), pcim_pin_device(), pci_is_managed()
* iomap : devm_ioport_map(), devm_ioport_unmap(), devm_ioremap(),
devm_ioremap_nocache(), devm_iounmap(), pcim_iomap_table(),
pcim_iomap(), pcim_iounmap()
Signed-off-by: Tejun Heo <htejun@gmail.com>
Signed-off-by: Jeff Garzik <jeff@garzik.org>
2007-01-20 10:00:26 +03:00
if ( res )
devres_add ( dev , dr ) ;
else
devres_free ( dr ) ;
return res ;
}
EXPORT_SYMBOL ( __devm_request_region ) ;
void __devm_release_region ( struct device * dev , struct resource * parent ,
resource_size_t start , resource_size_t n )
{
struct region_devres match_data = { parent , start , n } ;
__release_region ( parent , start , n ) ;
WARN_ON ( devres_destroy ( dev , devm_region_release , devm_region_match ,
& match_data ) ) ;
}
EXPORT_SYMBOL ( __devm_release_region ) ;
2005-04-17 02:20:36 +04:00
/*
2017-12-01 20:50:33 +03:00
* Reserve I / O ports or memory based on " reserve= " kernel parameter .
2005-04-17 02:20:36 +04:00
*/
# define MAXRESERVE 4
static int __init reserve_setup ( char * str )
{
static int reserved ;
static struct resource reserve [ MAXRESERVE ] ;
for ( ; ; ) {
2009-06-30 22:41:31 +04:00
unsigned int io_start , io_num ;
2005-04-17 02:20:36 +04:00
int x = reserved ;
2017-12-01 20:50:33 +03:00
struct resource * parent ;
2005-04-17 02:20:36 +04:00
2017-12-01 20:50:33 +03:00
if ( get_option ( & str , & io_start ) ! = 2 )
2005-04-17 02:20:36 +04:00
break ;
2017-12-01 20:50:33 +03:00
if ( get_option ( & str , & io_num ) = = 0 )
2005-04-17 02:20:36 +04:00
break ;
if ( x < MAXRESERVE ) {
struct resource * res = reserve + x ;
2017-12-01 20:50:33 +03:00
/*
* If the region starts below 0x10000 , we assume it ' s
* I / O port space ; otherwise assume it ' s memory .
*/
if ( io_start < 0x10000 ) {
res - > flags = IORESOURCE_IO ;
parent = & ioport_resource ;
} else {
res - > flags = IORESOURCE_MEM ;
parent = & iomem_resource ;
}
2005-04-17 02:20:36 +04:00
res - > name = " reserved " ;
res - > start = io_start ;
res - > end = io_start + io_num - 1 ;
2017-12-01 20:50:33 +03:00
res - > flags | = IORESOURCE_BUSY ;
2016-01-26 23:57:19 +03:00
res - > desc = IORES_DESC_NONE ;
2005-04-17 02:20:36 +04:00
res - > child = NULL ;
2017-12-01 20:50:33 +03:00
if ( request_resource ( parent , res ) = = 0 )
2005-04-17 02:20:36 +04:00
reserved = x + 1 ;
}
}
return 1 ;
}
__setup ( " reserve= " , reserve_setup ) ;
2008-09-26 05:43:34 +04:00
/*
* Check if the requested addr and size spans more than any slot in the
* iomem resource tree .
*/
int iomem_map_sanity_check ( resource_size_t addr , unsigned long size )
{
struct resource * p = & iomem_resource ;
int err = 0 ;
loff_t l ;
read_lock ( & resource_lock ) ;
for ( p = p - > child ; p ; p = r_next ( NULL , p , & l ) ) {
/*
* We can probably skip the resources without
* IORESOURCE_IO attribute ?
*/
if ( p - > start > = addr + size )
continue ;
if ( p - > end < addr )
continue ;
2008-10-28 21:45:42 +03:00
if ( PFN_DOWN ( p - > start ) < = PFN_DOWN ( addr ) & &
PFN_DOWN ( p - > end ) > = PFN_DOWN ( addr + size - 1 ) )
2008-09-26 05:43:34 +04:00
continue ;
2008-12-13 20:15:27 +03:00
/*
* if a resource is " BUSY " , it ' s not a hardware resource
* but a driver mapping of such a resource ; we don ' t want
* to warn for those ; some drivers legitimately map only
* partial hardware resources . ( example : vesafb )
*/
if ( p - > flags & IORESOURCE_BUSY )
continue ;
2014-04-15 01:38:11 +04:00
printk ( KERN_WARNING " resource sanity check: requesting [mem %#010llx-%#010llx], which spans more than %s %pR \n " ,
2008-09-26 12:10:12 +04:00
( unsigned long long ) addr ,
( unsigned long long ) ( addr + size - 1 ) ,
2014-04-15 01:38:11 +04:00
p - > name , p ) ;
2008-09-26 05:43:34 +04:00
err = - 1 ;
break ;
}
read_unlock ( & resource_lock ) ;
return err ;
}
2008-10-23 06:55:31 +04:00
# ifdef CONFIG_STRICT_DEVMEM
static int strict_iomem_checks = 1 ;
# else
static int strict_iomem_checks ;
# endif
/*
* check if an address is reserved in the iomem resource tree
2018-02-07 02:41:28 +03:00
* returns true if reserved , false if not reserved .
2008-10-23 06:55:31 +04:00
*/
2018-02-07 02:41:28 +03:00
bool iomem_is_exclusive ( u64 addr )
2008-10-23 06:55:31 +04:00
{
struct resource * p = & iomem_resource ;
2018-02-07 02:41:28 +03:00
bool err = false ;
2008-10-23 06:55:31 +04:00
loff_t l ;
int size = PAGE_SIZE ;
if ( ! strict_iomem_checks )
2018-02-07 02:41:28 +03:00
return false ;
2008-10-23 06:55:31 +04:00
addr = addr & PAGE_MASK ;
read_lock ( & resource_lock ) ;
for ( p = p - > child ; p ; p = r_next ( NULL , p , & l ) ) {
/*
* We can probably skip the resources without
* IORESOURCE_IO attribute ?
*/
if ( p - > start > = addr + size )
break ;
if ( p - > end < addr )
continue ;
2015-11-24 02:49:03 +03:00
/*
* A resource is exclusive if IORESOURCE_EXCLUSIVE is set
* or CONFIG_IO_STRICT_DEVMEM is enabled and the
* resource is busy .
*/
if ( ( p - > flags & IORESOURCE_BUSY ) = = 0 )
continue ;
if ( IS_ENABLED ( CONFIG_IO_STRICT_DEVMEM )
| | p - > flags & IORESOURCE_EXCLUSIVE ) {
2018-02-07 02:41:28 +03:00
err = true ;
2008-10-23 06:55:31 +04:00
break ;
}
}
read_unlock ( & resource_lock ) ;
return err ;
}
2015-02-05 08:44:43 +03:00
struct resource_entry * resource_list_create_entry ( struct resource * res ,
size_t extra_size )
{
struct resource_entry * entry ;
entry = kzalloc ( sizeof ( * entry ) + extra_size , GFP_KERNEL ) ;
if ( entry ) {
INIT_LIST_HEAD ( & entry - > node ) ;
entry - > res = res ? res : & entry - > __res ;
}
return entry ;
}
EXPORT_SYMBOL ( resource_list_create_entry ) ;
void resource_list_free ( struct list_head * head )
{
struct resource_entry * entry , * tmp ;
list_for_each_entry_safe ( entry , tmp , head , node )
resource_list_destroy_entry ( entry ) ;
}
EXPORT_SYMBOL ( resource_list_free ) ;
2008-10-23 06:55:31 +04:00
static int __init strict_iomem ( char * str )
{
if ( strstr ( str , " relaxed " ) )
strict_iomem_checks = 0 ;
if ( strstr ( str , " strict " ) )
strict_iomem_checks = 1 ;
return 1 ;
}
__setup ( " iomem= " , strict_iomem ) ;