Re: [PATCH -v2 13/13] x86, 64bit: Map first 1M ram early before memblock_x86_fill()
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> This one intend to fix bugs:
> when efi booting have too many memmap entries, will need to double memblock
> memory array or reserved array.
Okay, why do we need to do that?
> +RESERVE_BRK(early_pgt_alloc, 65536);
What is this needed for?
> +void __init early_init_mem_mapping(void)
> +{
> + unsigned long tables;
> + phys_addr_t base;
> + unsigned long start = 0, end = ISA_END_ADDRESS;
> +
> + probe_page_size_mask();
> +
> + if (max_pfn_mapped)
> + return;
I find this confusing - what is this protecting for? Why is
'max_pfn_mapped' set when someone calls early_init_mem_mappings()?
Side note: we have multiple "pfn_mapped" globals and it's not at all
obvious to me what the semantics for them are. Maybe adding a comment
or two in arch/x86/include/asm/page_types.h would help.
> +
> + tables = calculate_table_space_size(start, end);
> + base = __pa(extend_brk(tables, PAGE_SIZE));
> +
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 08/20] memory-hotplug: remove /sys/firmware/memmap/X sysfs
At 09/01/2012 05:06 AM, Andrew Morton Wrote:
> On Tue, 28 Aug 2012 18:00:15 +0800
> we...@cn.fujitsu.com wrote:
>
>> From: Yasuaki Ishimatsu
>>
>> When (hot)adding memory into system, /sys/firmware/memmap/X/{end, start,
>> type}
>> sysfs files are created. But there is no code to remove these files. The
>> patch
>> implements the function to remove them.
>>
>> Note : The code does not free firmware_map_entry since there is no way to
>> free
>>memory which is allocated by bootmem.
>>
>>
>>
>> +#define to_memmap_entry(obj) container_of(obj, struct firmware_map_entry,
>> kobj)
>
> It would be better to implement this as an inlined C function. That
> has improved type safety and improved readability.
>
>> +static void release_firmware_map_entry(struct kobject *kobj)
>> +{
>> +struct firmware_map_entry *entry = to_memmap_entry(kobj);
>> +struct page *page;
>> +
>> +page = virt_to_page(entry);
>> +if (PageSlab(page) || PageCompound(page))
>
> That PageCompound() test looks rather odd. Why is this done?
Liu Jiang and Christoph Lameter discussed how to find slab page
in this mail:
https://lkml.org/lkml/2012/7/6/333.
>
>> +kfree(entry);
>> +
>> +/* There is no way to free memory allocated from bootmem*/
>> +}
>
> This function is a bit ugly - poking around in page flags to determine
> whether or not the memory came from bootmem. It would be cleaner to
> use a separate boolean. Although I guess we can live with it as you
> have it here.
>
>> static struct kobj_type memmap_ktype = {
>> +.release= release_firmware_map_entry,
>> .sysfs_ops = _attr_ops,
>> .default_attrs = def_attrs,
>> };
>> @@ -123,6 +139,16 @@ static int firmware_map_add_entry(u64 start, u64 end,
>> return 0;
>> }
>>
>> +/**
>> + * firmware_map_remove_entry() - Does the real work to remove a firmware
>> + * memmap entry.
>> + * @entry: removed entry.
>> + **/
>> +static inline void firmware_map_remove_entry(struct firmware_map_entry
>> *entry)
>> +{
>> +list_del(>list);
>> +}
>
> Is there no locking to protect that list?
>
>> /*
>> * Add memmap entry on sysfs
>> */
>> @@ -144,6 +170,31 @@ static int add_sysfs_fw_map_entry(struct
>> firmware_map_entry *entry)
>> return 0;
>> }
>>
>> +/*
>> + * Remove memmap entry on sysfs
>> + */
>> +static inline void remove_sysfs_fw_map_entry(struct firmware_map_entry
>> *entry)
>> +{
>> +kobject_put(>kobj);
>> +}
>> +
>> +/*
>> + * Search memmap entry
>> + */
>> +
>> +struct firmware_map_entry * __meminit
>> +find_firmware_map_entry(u64 start, u64 end, const char *type)
>
> A better name would be firmware_map_find_entry(). To retain the (good)
> convention that symbols exported from here all start with
> "firmware_map_".
OK.
>
>> +{
>> +struct firmware_map_entry *entry;
>> +
>> +list_for_each_entry(entry, _entries, list)
>> +if ((entry->start == start) && (entry->end == end) &&
>> +(!strcmp(entry->type, type)))
>> +return entry;
>> +
>> +return NULL;
>> +}
>> +
>> /**
>> * firmware_map_add_hotplug() - Adds a firmware mapping entry when we do
>> * memory hotplug.
>> @@ -196,6 +247,32 @@ int __init firmware_map_add_early(u64 start, u64 end,
>> const char *type)
>> return firmware_map_add_entry(start, end, type, entry);
>> }
>>
>> +/**
>> + * firmware_map_remove() - remove a firmware mapping entry
>> + * @start: Start of the memory range.
>> + * @end: End of the memory range.
>> + * @type: Type of the memory range.
>> + *
>> + * removes a firmware mapping entry.
>> + *
>> + * Returns 0 on success, or -EINVAL if no entry.
>> + **/
>> +int __meminit firmware_map_remove(u64 start, u64 end, const char *type)
>> +{
>> +struct firmware_map_entry *entry;
>> +
>> +entry = find_firmware_map_entry(start, end - 1, type);
>> +if (!entry)
>> +return -EINVAL;
>> +
>> +firmware_map_remove_entry(entry);
>> +
>> +/* remove the memmap entry */
>> +remove_sysfs_fw_map_entry(entry);
>> +
>> +return 0;
>> +}
>
> Again, the lack of locking looks bad.
>
>> ...
>>
>> --- a/mm/memory_hotplug.c
>> +++ b/mm/memory_hotplug.c
>> @@ -1052,9 +1052,9 @@ int offline_memory(u64 start, u64 size)
>> return 0;
>> }
>>
>> -int remove_memory(int nid, u64 start, u64 size)
>> +int __ref remove_memory(int nid, u64 start, u64 size)
>
> Why was __ref added?
Hmm, firmware_map_remove() was put in meminit section, and we call it
in this function, so __ref is added here.
Thanks
Wen Congyang
>
>> {
>> -int ret = -EBUSY;
>> +int ret = 0;
>> lock_memory_hotplug();
>> /*
>> * The memory might become online by other task, even if you offine it.
>>
>> ...
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at
Re: 3.5.2: moving files from xfs/disk -> nfs: radix_tree_lookup_slot+0xe/0x10
On Sat, Sep 01, 2012 at 07:13:38PM -0400, Christoph Hellwig wrote: > I'd suspect it's something with the actual radix tree code, Ccing > linux-mm in case they know more. I don't think it has anything to do with the radix tree code > On Mon, Aug 27, 2012 at 11:00:10AM -0400, Justin Piszcz wrote: > > Hi, > > > > Moving ~276GB of files (mainly large backups) and everything has > > seemed to lockup on the client moving data to the server, it is still > > in this state.. . > > [75716.705720] Call Trace: > > [75716.705729] [] ? radix_tree_lookup_slot+0xe/0x10 It's just a symbol that was found in the stack. The real trace is this: > > [75716.705747] [] schedule+0x24/0x70 > > [75716.705751] [] schedule_timeout+0x1a9/0x210 > > [75716.705764] [] wait_for_common+0xc0/0x150 > > [75716.705773] [] wait_for_completion+0x18/0x20 > > [75716.705777] [] writeback_inodes_sb_nr+0x77/0xa0 > > [75716.705785] [] writeback_inodes_sb+0x29/0x40 > > [75716.705788] [] __sync_filesystem+0x47/0x90 > > [75716.705791] [] sync_one_sb+0x1b/0x20 > > [75716.705795] [] iterate_supers+0xe1/0xf0 > > [75716.705798] [] sys_sync+0x2b/0x60 > > [75716.705802] [] system_call_fastpath+0x1a/0x1f > > [75836.701197] INFO: task sync:8790 blocked for more than 120 seconds. Which simply says that writeback of the dirty data at the time of the sync call has taken longer than 120s. Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 12/13] x86, mm: Use func pointer to table size calculation and mapping.
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > +static void __init with_all_ram_ranges( > + void (*work_fn)(unsigned long, unsigned long, void *), > + void *data) > +static void __init size_work_fn(unsigned long start, unsigned long end, void > *data) > +static void __init mapping_work_fn(unsigned long start, unsigned long end, > +void *data) So I passionately hate the naming convention. How about something similar to mm/pagewalk.c: s/with_all_ram_ranges/walk_ram_ranges/g s/size_work_fn/table_space_size/g s/mapping_work_fn/map_memory/g -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 11/13] x86/mm: calculate_table_space_size based on memory ranges that are being mapped
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > From: Jacob Shin > > Current logic finds enough space for direct mapping page tables from 0 > to end. Instead, we only need to find enough space to cover mr[0].start > to mr[nr_range].end -- the range that is actually being mapped by > init_memory_mapping() > > This patch also reportedly fixes suspend/resume issue reported in: > > https://lkml.org/lkml/2012/8/11/83 > > -v2: update with calculate_table_space_size() > clear max_pfn_mapped before init_all_memory_mapping to get right value > -Yinghai Lu > > Signed-off-by: Jacob Shin Yinghai's sign-off is missing. Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 10/13] x86: Only direct map addresses that are marked as E820_RAM
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > From: Jacob Shin > > Currently direct mappings are created for [ 0 to max_low_pfn< and [ 4GB to max_pfn< backed by actual DRAM. This is fine for holes under 4GB which are covered > by fixed and variable range MTRRs to be UC. However, we run into trouble > on higher memory addresses which cannot be covered by MTRRs. > > Our system with 1TB of RAM has an e820 that looks like this: > > BIOS-e820: [mem 0x-0x000983ff] usable > BIOS-e820: [mem 0x00098400-0x0009] reserved > BIOS-e820: [mem 0x000d-0x000f] reserved > BIOS-e820: [mem 0x0010-0xc7eb] usable > BIOS-e820: [mem 0xc7ec-0xc7ed7fff] ACPI data > BIOS-e820: [mem 0xc7ed8000-0xc7ed9fff] ACPI NVS > BIOS-e820: [mem 0xc7eda000-0xc7ff] reserved > BIOS-e820: [mem 0xfec0-0xfec0] reserved > BIOS-e820: [mem 0xfee0-0xfee00fff] reserved > BIOS-e820: [mem 0xfff0-0x] reserved > BIOS-e820: [mem 0x0001-0x00e037ff] usable > BIOS-e820: [mem 0x00e03800-0x00fc] reserved > BIOS-e820: [mem 0x0100-0x011ffeff] usable > > and so direct mappings are created for huge memory hole between > 0x00e03800 to 0x0100. Even though the kernel never > generates memory accesses in that region, since the page tables mark > them incorrectly as being WB, our (AMD) processor ends up causing a MCE > while doing some memory bookkeeping/optimizations around that area. > > This patch iterates through e820 and only direct maps ranges that are > marked as E820_RAM, and keeps track of those pfn ranges. Depending on > the alignment of E820 ranges, this may possibly result in using smaller > size (i.e. 4K instead of 2M or 1G) page tables. > > -v2: move changes from setup.c to mm/init.c, also use for_each_mem_pfn_range > instead. - Yinghai Lu > -v3: add calculate_all_table_space_size() to get correct needed page table > size. - Yinghai Lu > > Signed-off-by: Jacob Shin Yinghai's sign-off is missing. Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 09/13] x86: Fixup code testing if a pfn is direct mapped
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > From: Jacob Shin > > Update code that previously assumed pfns [ 0 - max_low_pfn_mapped ) and > [ 4GB - max_pfn_mapped ) were always direct mapped, to now look up > pfn_mapped ranges instead. What problem does this fix? How did you find about it? > -v2: change applying sequence to keep git bisecting working. > so add dummy pfn_range_is_mapped(). - Yinghai Lu > > Signed-off-by: Jacob Shin Yinghai's sign-off is missing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 08/13] x86: if kernel .text .data .bss are not marked as E820_RAM, complain and fix
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > From: Jacob Shin > > There could be cases where user supplied memmap=exactmap memory > mappings do not mark the region where the kernel .text .data and > .bss reside as E820_RAM, as reported here: > > https://lkml.org/lkml/2012/8/14/86 > > Handle it by complaining, and adding the range back into the e820. > > Signed-off-by: Jacob Shin This should have Yinghai's sign-off and the warning could be less cryptic. As for the fix itself: Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 07/13] x86, mm: Move down two calculate_table_space_size down.
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> So later could make it call split_mem_range...
>
> Signed-off-by: Yinghai Lu
The commit title is utterly confusing. And it has a trailing dot (".").
As for the actual change:
Reviewed-by: Pekka Enberg
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/1] x86/oprofile: Fix the calltrace upon profiling some specified events with oprofile
On 08/28/2012 05:17 PM, Robert Richter wrote:
On 27.08.12 09:32:13, wei.y...@windriver.com wrote:
From: Wei Yang
Upon enabling the call-graph functionality of oprofile, A few minutes
later the following calltrace will always occur.
BUG: unable to handle kernel paging request at 656d6153
This is probably the same I found to yesterday. Will test your fix.
OK, I have already tested it on some boards based on intel atom e6xx and
intel atom n4xx & d5xx.
Thanks
Wei
-Robert
IP: [] print_context_stack+0x55/0x110
*pde =
Oops: [#1] PREEMPT SMP
Modules linked in:
Pid: 0, comm: swapper/0 Not tainted 3.6.0-rc3-WR5.0+snapshot-20120820_standard
EIP: 0060:[] EFLAGS: 00010093 CPU: 0
EIP is at print_context_stack+0x55/0x110
EAX: 656d7ffc EBX: 656d6153 ECX: c1837ee0 EDX: 656d6153
ESI: EDI: e000 EBP: f600deac ESP: f600de88
DS: 007b ES: 007b FS: 00d8 GS: SS: 0068
CR0: 8005003b CR2: 656d6153 CR3: 01934000 CR4: 07d0
DR0: DR1: DR2: DR3:
DR6: 0ff0 DR7: 0400
Process swapper/0 (pid: 0, ti=f600c000 task=c18411a0 task.ti=c1836000)
Stack:
1a7f76ea 656d7ffc 656d6000 c1837ee0 e000 c1837ee0 656d6153 c188e27c
656d6000 f600dedc c10040f8 c188e27c f600def0 f600dec8 c1837ee0
f600ded4 c1837ee0 f600dfc4 001f f600df08 c1564d22
Call Trace:
[] dump_trace+0x68/0xf0
[] x86_backtrace+0xb2/0xc0
[] oprofile_add_sample+0xa2/0xc0
[] ? do_softirq+0x6f/0xa0
[] ppro_check_ctrs+0x79/0x100
[] ? ppro_shutdown+0x60/0x60
[] profile_exceptions_notify+0x8f/0xb0
[] nmi_handle.isra.0+0x48/0x70
[] do_nmi+0xd3/0x3c0
[] ? __local_bh_enable+0x29/0x70
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] nmi_stack_correct+0x28/0x2d
[] ? ftrace_define_fields_irq_handler_entry+0x80/0x80
[] ? do_softirq+0x6f/0xa0
[] irq_exit+0x65/0x70
[] smp_apic_timer_interrupt+0x59/0x89
[] apic_timer_interrupt+0x2a/0x30
[] ? acpi_idle_enter_bm+0x245/0x273
[] cpuidle_enter+0x15/0x20
[] cpuidle_idle_call+0xa0/0x320
[] cpu_idle+0x55/0xb0
[] rest_init+0x6c/0x74
[] start_kernel+0x2ec/0x2f3
[] ? repair_env_string+0x51/0x51
[] i386_start_kernel+0x78/0x7d
Code: e0 ff ff 89 7d ec 74 5a 8d b4 26 00 00 00 00 8d bc 27 00 00
00 00 39 f3 72 0c 8b 45 f0 8d 64 24 18 5b 5e 5f 5d c3 3b 5d ec 72
ef<8b> 3b 89 f8 89 7d dc e8 ef 40 04 00 85 c0 74 20 8b 40
EIP: [] print_context_stack+0x55/0x110 SS:ESP 0068:f600de88
CR2: 656d6153
---[ end trace 751c9b47c6ff5e29 ]---
Let's assume a scenario that do_softirq() switches the stack to a soft irq
stack, and the soft irq stack is totally empty. At this moment, a nmi interrupt
occurs, subsequently, CPU does not automatically save SS and SP registers
and switch any stack, but instead only stores EFLAGS, CS and IP to the soft irq
stack. since the CPU is in kernel mode when the NMI exception occurs.
the layout of the current soft irq stack is this:
+--+<-the top of soft irq
| EFLAGS |
+--+
|CS|
+--+
|IP|
+--+
| SAVE_ALL |
+--+
but the return value of the function kernel_stack_pointer() is'>sp'
(for x86_32 CPU), which is invoked by the x86_backtrace function. Since
the type of regs pointer is a pt_regs structure, the return value is not
in the range of the soft irq stack, as the SP register is not save in the
soft irq stack. Therefore, we need to check if the return value of the function
resides in valid range. Additionally, the changes has no impact on the normal
NMI exception.
Signed-off-by: Yang Wei
---
arch/x86/oprofile/backtrace.c | 10 ++
1 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/arch/x86/oprofile/backtrace.c b/arch/x86/oprofile/backtrace.c
index d6aa6e8..a5fca0b 100644
--- a/arch/x86/oprofile/backtrace.c
+++ b/arch/x86/oprofile/backtrace.c
@@ -17,6 +17,11 @@
#include
#include
+static inline int valid_stack_ptr(struct thread_info *tinfo, void *p)
+{
+ void *t = tinfo;
+ return p> t + sizeof(struct thread_info)&& p< t + THREAD_SIZE;
+}
static int backtrace_stack(void *data, char *name)
{
/* Yes, we want all stacks */
@@ -110,9 +115,14 @@ void
x86_backtrace(struct pt_regs * const regs, unsigned int depth)
{
struct stack_frame *head = (struct stack_frame *)frame_pointer(regs);
+ struct thread_info *context;
if (!user_mode_vm(regs)) {
unsigned long stack = kernel_stack_pointer(regs);
+ context = (struct thread_info *)
+ (stack& (~(THREAD_SIZE - 1)));
+ if (!valid_stack_ptr(context, (void *)stack))
+ return;
if (depth)
dump_trace(NULL, regs, (unsigned long *)stack, 0,
_ops,);
--
1.7.0.2
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Re: [PATCH -v2 06/13] x86, mm: Separate out calculate_table_space_size()
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > it should take physical address range that will need to be mapped. > and find_early_table_space should take range that pgt buff should be in. > Separate those two to reduce confusion. > > Signed-off-by: Yinghai Lu Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 05/13] x86, mm: Find early page table only one time
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote:
> Should not do that in every calling of init_memory_mapping.
> Actually in early time, only need do once.
>
> Also move down early_memtest.
>
> Signed-off-by: Yinghai Lu
The changelog is too terse for my liking. I think it could use some
more context on what the code is actually doing now and why the change
makes it better.
> ---
> arch/x86/mm/init.c | 72 ++-
> 1 files changed, 37 insertions(+), 35 deletions(-)
>
> diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
> index cca9b7d..0ada295 100644
> --- a/arch/x86/mm/init.c
> +++ b/arch/x86/mm/init.c
> @@ -37,7 +37,7 @@ struct map_range {
>
> static int page_size_mask;
>
> -static void __init find_early_table_space(struct map_range *mr,
> +static void __init find_early_table_space(unsigned long begin,
> unsigned long end)
> {
> unsigned long puds, pmds, ptes, tables, start = 0, good_end = end;
> @@ -64,8 +64,8 @@ static void __init find_early_table_space(struct map_range
> *mr,
> extra += PMD_SIZE;
> #endif
> /* The first 2/4M doesn't use large pages. */
> - if (mr->start < PMD_SIZE)
> - extra += mr->end - mr->start;
> + if (begin < PMD_SIZE)
> + extra += (PMD_SIZE - begin) >> PAGE_SHIFT;
>
> ptes = (extra + PAGE_SIZE - 1) >> PAGE_SHIFT;
> } else
> @@ -265,16 +265,6 @@ unsigned long __init_refok init_memory_mapping(unsigned
> long start,
> nr_range = 0;
> nr_range = split_mem_range(mr, nr_range, start, end);
>
> - /*
> -* Find space for the kernel direct mapping tables.
> -*
> -* Later we should allocate these tables in the local node of the
> -* memory mapped. Unfortunately this is done currently before the
> -* nodes are discovered.
> -*/
> - if (!after_bootmem)
> - find_early_table_space([0], end);
> -
> for (i = 0; i < nr_range; i++)
> ret = kernel_physical_mapping_init(mr[i].start, mr[i].end,
>mr[i].page_size_mask);
> @@ -287,6 +277,36 @@ unsigned long __init_refok init_memory_mapping(unsigned
> long start,
>
> __flush_tlb_all();
>
> + return ret >> PAGE_SHIFT;
> +}
> +
> +void __init init_mem_mapping(void)
> +{
> + probe_page_size_mask();
> +
> + /*
> +* Find space for the kernel direct mapping tables.
> +*
> +* Later we should allocate these tables in the local node of the
> +* memory mapped. Unfortunately this is done currently before the
> +* nodes are discovered.
> +*/
> +#ifdef CONFIG_X86_64
> + find_early_table_space(0, max_pfn< +#else
> + find_early_table_space(0, max_low_pfn< +#endif
> + max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< + max_pfn_mapped = max_low_pfn_mapped;
> +
> +#ifdef CONFIG_X86_64
> + if (max_pfn > max_low_pfn) {
> + max_pfn_mapped = init_memory_mapping(1UL<<32,
> +max_pfn< + /* can we preseve max_low_pfn ?*/
> + max_low_pfn = max_pfn;
> + }
> +#endif
> /*
> * Reserve the kernel pagetable pages we used (pgt_buf_start -
> * pgt_buf_end) and free the other ones (pgt_buf_end - pgt_buf_top)
> @@ -302,32 +322,14 @@ unsigned long __init_refok init_memory_mapping(unsigned
> long start,
> * RO all the pagetable pages, including the ones that are beyond
> * pgt_buf_end at that time.
> */
> - if (!after_bootmem && pgt_buf_end > pgt_buf_start)
> + if (pgt_buf_end > pgt_buf_start)
> x86_init.mapping.pagetable_reserve(PFN_PHYS(pgt_buf_start),
> PFN_PHYS(pgt_buf_end));
>
> - if (!after_bootmem)
> - early_memtest(start, end);
> + /* stop the wrong using */
> + pgt_buf_top = 0;
>
> - return ret >> PAGE_SHIFT;
> -}
> -
> -void __init init_mem_mapping(void)
> -{
> - probe_page_size_mask();
> -
> - /* max_pfn_mapped is updated here */
> - max_low_pfn_mapped = init_memory_mapping(0, max_low_pfn< - max_pfn_mapped = max_low_pfn_mapped;
> -
> -#ifdef CONFIG_X86_64
> - if (max_pfn > max_low_pfn) {
> - max_pfn_mapped = init_memory_mapping(1UL<<32,
> -max_pfn< - /* can we preseve max_low_pfn ?*/
> - max_low_pfn = max_pfn;
> - }
> -#endif
> + early_memtest(0, max_pfn_mapped << PAGE_SHIFT);
> }
>
> /*
> --
> 1.7.7
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at
Re: [PATCH -v2 04/13] x86, mm: Revert back good_end setting for 64bit
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > So we could put page table high again for 64bit. > > Signed-off-by: Yinghai Lu The changelog for this is too terse for me to actually understand why this is needed. > --- > arch/x86/mm/init.c |2 +- > 1 files changed, 1 insertions(+), 1 deletions(-) > > diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c > index 15a6a38..cca9b7d 100644 > --- a/arch/x86/mm/init.c > +++ b/arch/x86/mm/init.c > @@ -76,8 +76,8 @@ static void __init find_early_table_space(struct map_range > *mr, > #ifdef CONFIG_X86_32 > /* for fixmap */ > tables += roundup(__end_of_fixed_addresses * sizeof(pte_t), > PAGE_SIZE); > -#endif > good_end = max_pfn_mapped << PAGE_SHIFT; > +#endif > > base = memblock_find_in_range(start, good_end, tables, PAGE_SIZE); > if (!base) > -- > 1.7.7 > > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majord...@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 03/13] x86, mm: Moving init_memory_mapping calling
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > from setup.c to mm/init.c > > So could update all related calling together later > > Signed-off-by: Yinghai Lu Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 02/13] x86, mm: Split out split_mem_range
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > from init_memory_mapping, so make init_memory_mapping readable. > > Suggested-by: Ingo Molnar > Signed-off-by: Yinghai Lu Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH -v2 01/13] x86, mm: Add global page_size_mask
On Sun, Sep 2, 2012 at 10:46 AM, Yinghai Lu wrote: > detect if need to use 1G or 2M and store them in page_size_mask. > > Only probe them one time. > > Suggested-by: Ingo Molnar > Signed-off-by: Yinghai Lu Reviewed-by: Pekka Enberg -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] x86, defconfig: Turn off CONFIG_BLK_DEV_RAM
The vast majority of systems either use initramfs or mount a root filesystem directly from the kernel. Distros have defaulted to initramfs for years. Only highly specialized systems would use an actual filesystem-image initrd at this point, and such systems don't rely on defconfig anyway. Drop initrd support (and specifically RAM block device support) from the defconfigs. Signed-off-by: Josh Triplett --- arch/x86/configs/i386_defconfig |2 -- arch/x86/configs/x86_64_defconfig |2 -- 2 files changed, 4 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index d833bb6..a6533a2 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -144,8 +144,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 7ddcd99..18f3cc4 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -144,8 +144,6 @@ CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_DEBUG_DEVRES=y CONFIG_CONNECTOR=y CONFIG_BLK_DEV_LOOP=y -CONFIG_BLK_DEV_RAM=y -CONFIG_BLK_DEV_RAM_SIZE=16384 CONFIG_BLK_DEV_SD=y CONFIG_BLK_DEV_SR=y CONFIG_BLK_DEV_SR_VENDOR=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/5] x86: Disable CONFIG_CRC_T10DIF in defconfigs
CONFIG_CRC_T10DIF explicitly states that it exists only for use by out-of-tree modules; anything in-kernel that needs it selects it. Thus, compile it out by default. Signed-off-by: Josh Triplett --- arch/x86/configs/i386_defconfig |1 - arch/x86/configs/x86_64_defconfig |1 - 2 files changed, 2 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 2701b8a..d833bb6 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -311,4 +311,3 @@ CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y CONFIG_CRYPTO_AES_586=y # CONFIG_CRYPTO_ANSI_CPRNG is not set -CONFIG_CRC_T10DIF=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index c17614e..7ddcd99 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -309,4 +309,3 @@ CONFIG_SECURITY_SELINUX=y CONFIG_SECURITY_SELINUX_BOOTPARAM=y CONFIG_SECURITY_SELINUX_DISABLE=y # CONFIG_CRYPTO_ANSI_CPRNG is not set -CONFIG_CRC_T10DIF=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] x86: Switch to ext4 in defconfigs
The current x86 and x86-64 defconfigs do not enable ext4, which most current distributions default to. Switch the defconfigs to ext4, so they will boot on current systems without additional configuration. Signed-off-by: Josh Triplett --- arch/x86/configs/i386_defconfig |7 +++ arch/x86/configs/x86_64_defconfig |7 +++ 2 files changed, 6 insertions(+), 8 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 1903408..2701b8a 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -260,10 +260,9 @@ CONFIG_RTC_CLASS=y CONFIG_DMADEVICES=y CONFIG_EEEPC_LAPTOP=y CONFIG_EFI_VARS=y -CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_EXT3_FS_POSIX_ACL=y -CONFIG_EXT3_FS_SECURITY=y +CONFIG_EXT4_FS=y +CONFIG_EXT4_FS_POSIX_ACL=y +CONFIG_EXT4_FS_SECURITY=y CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index c2c0448..c17614e 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -260,10 +260,9 @@ CONFIG_AMD_IOMMU_STATS=y CONFIG_INTEL_IOMMU=y # CONFIG_INTEL_IOMMU_DEFAULT_ON is not set CONFIG_EFI_VARS=y -CONFIG_EXT3_FS=y -# CONFIG_EXT3_DEFAULTS_TO_ORDERED is not set -CONFIG_EXT3_FS_POSIX_ACL=y -CONFIG_EXT3_FS_SECURITY=y +CONFIG_EXT4_FS=y +CONFIG_EXT4_FS_POSIX_ACL=y +CONFIG_EXT4_FS_SECURITY=y CONFIG_QUOTA=y CONFIG_QUOTA_NETLINK_INTERFACE=y # CONFIG_PRINT_QUOTA_WARNING is not set -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf bench: fix assert when NDEBUG is defined
On Mon, Sep 3, 2012 at 4:45 AM, Namhyung Kim wrote:
> On Mon, 3 Sep 2012 03:04:32 +0300, Irina Tirdea wrote:
>> From: Irina Tirdea
>>
>> When NDEBUG is defined, the assert macro will be expanded to nothing.
>> Some assert calls used in perf are also including some functionality
>> (e.g. system calls), not only validity checks. Therefore, if NDEBUG is
>> defined, these functionality will be removed along with the assert.
>>
>> The functionality of the program needs to be separated from the assert
>> checks.
>> In perf, BUG_ON is also defined on assert, so we need to fix these statements
>> too.
>>
>> Signed-off-by: Irina Tirdea
>> ---
>> tools/perf/bench/mem-memcpy.c |8 +---
>> tools/perf/bench/mem-memset.c |8 +---
>> tools/perf/bench/sched-pipe.c |6 --
>> 3 files changed, 14 insertions(+), 8 deletions(-)
>>
>> diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c
>> index 02dad5d..bccb783 100644
>> --- a/tools/perf/bench/mem-memcpy.c
>> +++ b/tools/perf/bench/mem-memcpy.c
>> @@ -144,17 +144,19 @@ static double do_memcpy_gettimeofday(memcpy_t
>> fn, size_t len, bool prefault)
>> {
>> struct timeval tv_start, tv_end, tv_diff;
>> void *src = NULL, *dst = NULL;
>> - int i;
>> + int i, ret;
>>
>> alloc_mem(, , len);
>>
>> if (prefault)
>> fn(dst, src, len);
>>
>> - BUG_ON(gettimeofday(_start, NULL));
>> + ret = gettimeofday(_start, NULL);
>> + BUG_ON(ret);
>
> I think one of good thing of assert is that it outputs the exact failure
> condition when it fails. So with patch, it will convert
>
> Assertion `gettimeofday(_start, NULL)' failed.
>
> into
>
> Assertion `ret' failed.
>
> which is not so informative.
>
> So I'd rather suggest using more descriptive names like ret_gtod ?
No, please don't do that. That'll make the code ugly and it's really
just papering over the fact that the assertions should be converted to
proper error handling.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] x86: Update defconfigs to current results of "make savedefconfig"
The x86 defconfigs have become somewhat out of date compared to the current result of "make savedefconfig". Update them to the current output, as a prelude to further defconfig changes, to avoid unrelated noise in those further changes. Signed-off-by: Josh Triplett --- arch/x86/configs/i386_defconfig | 12 arch/x86/configs/x86_64_defconfig | 12 2 files changed, 8 insertions(+), 16 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index 119db67..1903408 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -8,6 +8,8 @@ CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_CGROUPS=y CONFIG_CGROUP_FREEZER=y @@ -34,8 +36,6 @@ CONFIG_SGI_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_X86_GENERIC=y CONFIG_HPET_TIMER=y @@ -231,8 +231,6 @@ CONFIG_SND_HRTIMER=y CONFIG_SND_HDA_INTEL=y CONFIG_SND_HDA_HWDEP=y CONFIG_HIDRAW=y -CONFIG_HID_PID=y -CONFIG_USB_HIDDEV=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y CONFIG_HID_NTRIG=y @@ -243,11 +241,11 @@ CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_HID_SUNPLUS=y CONFIG_HID_TOPSEED=y +CONFIG_HID_PID=y +CONFIG_USB_HIDDEV=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y -# CONFIG_USB_DEVICE_CLASS is not set CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_TT_NEWSCHED is not set @@ -280,7 +278,6 @@ CONFIG_PROC_KCORE=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y @@ -299,7 +296,6 @@ CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_STACK_USAGE=y -CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_EARLY_PRINTK_DBGP=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 76eb290..c2c0448 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -8,6 +8,8 @@ CONFIG_TASK_DELAY_ACCT=y CONFIG_TASK_XACCT=y CONFIG_TASK_IO_ACCOUNTING=y CONFIG_AUDIT=y +CONFIG_NO_HZ=y +CONFIG_HIGH_RES_TIMERS=y CONFIG_LOG_BUF_SHIFT=18 CONFIG_CGROUPS=y CONFIG_CGROUP_FREEZER=y @@ -34,8 +36,6 @@ CONFIG_SGI_PARTITION=y CONFIG_SUN_PARTITION=y CONFIG_KARMA_PARTITION=y CONFIG_EFI_PARTITION=y -CONFIG_NO_HZ=y -CONFIG_HIGH_RES_TIMERS=y CONFIG_SMP=y CONFIG_CALGARY_IOMMU=y CONFIG_NR_CPUS=64 @@ -227,8 +227,6 @@ CONFIG_SND_HRTIMER=y CONFIG_SND_HDA_INTEL=y CONFIG_SND_HDA_HWDEP=y CONFIG_HIDRAW=y -CONFIG_HID_PID=y -CONFIG_USB_HIDDEV=y CONFIG_HID_GYRATION=y CONFIG_LOGITECH_FF=y CONFIG_HID_NTRIG=y @@ -239,11 +237,11 @@ CONFIG_HID_SAMSUNG=y CONFIG_HID_SONY=y CONFIG_HID_SUNPLUS=y CONFIG_HID_TOPSEED=y +CONFIG_HID_PID=y +CONFIG_USB_HIDDEV=y CONFIG_USB=y CONFIG_USB_DEBUG=y CONFIG_USB_ANNOUNCE_NEW_DEVICES=y -CONFIG_USB_DEVICEFS=y -# CONFIG_USB_DEVICE_CLASS is not set CONFIG_USB_MON=y CONFIG_USB_EHCI_HCD=y # CONFIG_USB_EHCI_TT_NEWSCHED is not set @@ -280,7 +278,6 @@ CONFIG_PROC_KCORE=y CONFIG_TMPFS_POSIX_ACL=y CONFIG_HUGETLBFS=y CONFIG_NFS_FS=y -CONFIG_NFS_V3=y CONFIG_NFS_V3_ACL=y CONFIG_NFS_V4=y CONFIG_ROOT_NFS=y @@ -298,7 +295,6 @@ CONFIG_DEBUG_KERNEL=y CONFIG_SCHEDSTATS=y CONFIG_TIMER_STATS=y CONFIG_DEBUG_STACK_USAGE=y -CONFIG_SYSCTL_SYSCALL_CHECK=y CONFIG_BLK_DEV_IO_TRACE=y CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_EARLY_PRINTK_DBGP=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] x86: Turn off DEBUG_NX_TEST module in defconfigs
The x86 defconfigs include exactly one module: test_nx.ko, a special-purpose module which just exists to do evil things like executing code off the stack to see if the kernel has enabled NX support. Anyone who actually uses that module can easily enable it themselves, but the vast majority of kernel builds don't need it; disable it by default. Signed-off-by: Josh Triplett --- arch/x86/configs/i386_defconfig |1 - arch/x86/configs/x86_64_defconfig |1 - 2 files changed, 2 deletions(-) diff --git a/arch/x86/configs/i386_defconfig b/arch/x86/configs/i386_defconfig index a6533a2..5598547 100644 --- a/arch/x86/configs/i386_defconfig +++ b/arch/x86/configs/i386_defconfig @@ -298,7 +298,6 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_RODATA_TEST is not set -CONFIG_DEBUG_NX_TEST=m CONFIG_DEBUG_BOOT_PARAMS=y CONFIG_OPTIMIZE_INLINING=y CONFIG_KEYS_DEBUG_PROC_KEYS=y diff --git a/arch/x86/configs/x86_64_defconfig b/arch/x86/configs/x86_64_defconfig index 18f3cc4..671524d 100644 --- a/arch/x86/configs/x86_64_defconfig +++ b/arch/x86/configs/x86_64_defconfig @@ -297,7 +297,6 @@ CONFIG_PROVIDE_OHCI1394_DMA_INIT=y CONFIG_EARLY_PRINTK_DBGP=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_RODATA_TEST is not set -CONFIG_DEBUG_NX_TEST=m CONFIG_DEBUG_BOOT_PARAMS=y CONFIG_OPTIMIZE_INLINING=y CONFIG_KEYS_DEBUG_PROC_KEYS=y -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 0/5] x86: Improve defconfigs for use on current systems
After repeatedly going through the cycle of building a "make defconfig" kernel, trying to boot it, getting a kernel panic, turning on ext4, and rebuilding, I figured I'd actually get the defconfigs fixed to work on modern systems with ext4 root filesystems. Patch 2 of this patch series does exactly that. Hopefully this will prove uncontroversial. To avoid extraneous noise in patch 2, I first updated the defconfigs to match the current results of "make defconfig && make savedefconfig", resulting in patch 1. Finally, while reviewing the defconfigs, I also ran into a few other random things to clean up, resulting in patches 3-5. Patch 3 disables some library code that only exists to support out-of-tree modules (in-tree modules properly depend on it); patch 4 disables initrd support (in favor of initramfs); patch 5 disables a special-purpose test module that represents the one and only module built by default. These seem reasonable to me, but if anyone finds one of these three changes objectionable, please feel free to drop that change. I primarily care about getting patches 1-2 merged, to avoid a very common annoyance. Josh Triplett (5): x86: Update defconfigs to current results of "make savedefconfig" x86: Switch to ext4 in defconfigs x86: Disable CONFIG_CRC_T10DIF in defconfigs x86, defconfig: Turn off CONFIG_BLK_DEV_RAM x86: Turn off DEBUG_NX_TEST module in defconfigs arch/x86/configs/i386_defconfig | 23 +++ arch/x86/configs/x86_64_defconfig | 23 +++ 2 files changed, 14 insertions(+), 32 deletions(-) -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] virtio-blk: Fix kconfig option
Whoops, need VIRTIO_RING too >From 79dc9ae40e40cefd6079e4197cac858a1d59e1d8 Mon Sep 17 00:00:00 2001 From: Kent Overstreet Date: Sun, 2 Sep 2012 21:44:37 -0700 Subject: [PATCH] virtio-blk: Fix kconfig option CONFIG_VIRTIO isn't exposed, everything else is supposed to select it instead. Signed-off-by: Kent Overstreet --- drivers/block/Kconfig |4 +++- 1 file changed, 3 insertions(+), 1 deletion(-) diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index a796407..40532b8 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -521,7 +521,9 @@ config XEN_BLKDEV_BACKEND config VIRTIO_BLK tristate "Virtio block driver (EXPERIMENTAL)" - depends on EXPERIMENTAL && VIRTIO + select VIRTIO + select VIRTIO_RING + depends on EXPERIMENTAL ---help--- This is the virtual block driver for virtio. It can be used with lguest or QEMU based VMMs (like KVM or Xen). Say Y or M. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] hid: Remove "default m" from HID_LOGITECH_DJ
HID_LOGITECH_DJ uses "default m", which enables it in default kernel builds. Since this module just enables extra, non-critical functionality for one particular piece of hardware (specifically, differentiating multiple wireless keyboards and mice as separate input devices rather than treating them as one device), and the hardware works just fine with the default USB HID support, drop the "default m". Signed-off-by: Josh Triplett --- drivers/hid/Kconfig |1 - 1 file changed, 1 deletion(-) diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index fbf4950..d004528 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -307,7 +307,6 @@ config HID_LOGITECH config HID_LOGITECH_DJ tristate "Logitech Unifying receivers full support" depends on HID_LOGITECH - default m ---help--- Say Y if you want support for Logitech Unifying receivers and devices. Unifying receivers are capable of pairing up to 6 Logitech compliant -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] virtio-blk: Fix kconfig option
CONFIG_VIRTIO isn't exposed, everything else is supposed to select it instead. Signed-off-by: Kent Overstreet --- drivers/block/Kconfig |3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/drivers/block/Kconfig b/drivers/block/Kconfig index a796407..d4e1d12 100644 --- a/drivers/block/Kconfig +++ b/drivers/block/Kconfig @@ -521,7 +521,8 @@ config XEN_BLKDEV_BACKEND config VIRTIO_BLK tristate "Virtio block driver (EXPERIMENTAL)" - depends on EXPERIMENTAL && VIRTIO + select VIRTIO + depends on EXPERIMENTAL ---help--- This is the virtual block driver for virtio. It can be used with lguest or QEMU based VMMs (like KVM or Xen). Say Y or M. -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can not get output of command line on SH
On Mon, Sep 03, 2012 at 11:56:59AM +0900, Nobuhiro Iwamatsu wrote: > On Fri, Aug 31, 2012 at 10:10 PM, Al Viro wrote: > > Smells like broken TIF_NOTIFY_RESUME hookup on sh... Arrrgh. Looks like > > while it is in the relevant masks *and* checked in do_notify_resume() both > > on 32bit and 64bit variants since commit > > ab99c733ae73cce31f2a2434f7099564e5a73d95 > > Author: Paul Mundt > > Date: Wed Jul 30 19:55:30 2008 +0900 > > > > sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME. > > > > they are actually *not* reached without simulataneous SIGPENDING, since the > > actual glue in the callers had not been updated back then and still checks > > for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume() > > or not. Looks like the following ought to fix that: > > Thanks for your reply and explanation. > I confirmed that revise this problem with your patch. > > > > > Signed-off-by: Al Viro > Tested-by: Nobuhiro Iwamatsu > I'll queue it up, thanks! -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 4/4] linsched: add the simulation of schedule after ipi interrupt
From: Michael Wang
In real world of x86, during an interrupt, if current thread need to
be reschedule, we will do it after invoke do_IRQ.
And in linsched, while handle the softirq, it may cause the
reschedule ipi on other cpu, so we need to do schedule for them at
that time, otherwise we will got inaccuracy results.
Signed-off-by: Michael Wang
---
tools/linsched/hrtimer.c | 21 +
tools/linsched/linsched.h |2 ++
tools/linsched/numa.c |2 ++
3 files changed, 25 insertions(+), 0 deletions(-)
diff --git a/tools/linsched/hrtimer.c b/tools/linsched/hrtimer.c
index 3203253..4df4e14 100644
--- a/tools/linsched/hrtimer.c
+++ b/tools/linsched/hrtimer.c
@@ -158,6 +158,24 @@ void linsched_enter_idle(void)
tick_nohz_idle_enter();
}
+cpumask_t linsched_cpu_resched_pending;
+void process_pending_resched(void)
+{
+ int cpu, old_cpu = smp_processor_id();
+
+ if (cpumask_empty(_cpu_resched_pending))
+ return;
+
+ while (!cpumask_empty(_cpu_resched_pending)) {
+ cpu = cpumask_first(_cpu_resched_pending);
+ linsched_change_cpu(cpu);
+ cpumask_clear_cpu(cpu, _cpu_resched_pending);
+ schedule();
+ }
+
+ linsched_change_cpu(old_cpu);
+}
+
/* Run a simulation for some number of ticks. Each tick,
* scheduling and load balancing decisions are made. Obviously, we
* could create tasks, change priorities, etc., at certain ticks
@@ -217,6 +235,9 @@ void linsched_run_sim(int sim_ticks)
linsched_rcu_invoke();
+ process_pending_resched();
+ linsched_check_idle_cpu();
+
BUG_ON(irqs_disabled());
if (idle_cpu(active_cpu) && !need_resched()) {
linsched_enter_idle();
diff --git a/tools/linsched/linsched.h b/tools/linsched/linsched.h
index d56d801..c4964c5 100644
--- a/tools/linsched/linsched.h
+++ b/tools/linsched/linsched.h
@@ -34,6 +34,8 @@ extern struct cgroup *root_cgroup;
extern u64 current_time;
+extern cpumask_t linsched_cpu_resched_pending;
+
struct sleep_run_data {
struct hrtimer timer;
struct task_struct *p;
diff --git a/tools/linsched/numa.c b/tools/linsched/numa.c
index 255ff51..e2e7568 100644
--- a/tools/linsched/numa.c
+++ b/tools/linsched/numa.c
@@ -113,6 +113,8 @@ void linsched_trigger_cpu(int cpu)
* Call the scheduler ipi when queueing up tasks on the wakelist
*/
scheduler_ipi();
+ if (need_resched())
+ cpumask_set_cpu(cpu, _cpu_resched_pending);
linsched_change_cpu(curr_cpu);
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 2/4] linsched: add check on invoke tick_nohz_irq_exit() in irq_exit()
From: Michael Wang tick_nohz_irq_exit() will make sure the tick timer reprogram correctly after cpu enter idle. With out this check, after the interrupt, tick timer will be enabled even cpu is still in idle, this will cause inaccuracy. Signed-off-by: Michael Wang --- arch/linsched/kernel/irq.c |4 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/linsched/kernel/irq.c b/arch/linsched/kernel/irq.c index 3000d47..5f88af4 100644 --- a/arch/linsched/kernel/irq.c +++ b/arch/linsched/kernel/irq.c @@ -2,6 +2,7 @@ #include #include #include +#include unsigned long linsched_irq_flags = ARCH_IRQ_ENABLED; @@ -87,6 +88,9 @@ void irq_exit(void) sub_preempt_count(IRQ_EXIT_OFFSET); if (!in_interrupt() && local_softirq_pending()) do_softirq(); + + if (idle_cpu(smp_processor_id()) && !in_interrupt() && !need_resched()) + tick_nohz_irq_exit(); } void local_bh_enable_ip(unsigned long ip) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 3/4] linsched: avoid invoke tick_nohz_idle_enter() multiple times in idle
From: Michael Wang
In real world, tick_nohz_idle_enter() will be invoked by idle thread
when the cpu change from active to idle, and will only be invoked
again after tick_nohz_idle_exit() was invoked by idle thread when
cpu is going to recover, invoke it multiple times in one idle may
cause unexpected troubles.
The patch add a check to avoid invoke tick_nohz_idle_enter() again
after idle.
Signed-off-by: Michael Wang
---
tools/linsched/hrtimer.c | 11 ++-
1 files changed, 10 insertions(+), 1 deletions(-)
diff --git a/tools/linsched/hrtimer.c b/tools/linsched/hrtimer.c
index de88b25..3203253 100644
--- a/tools/linsched/hrtimer.c
+++ b/tools/linsched/hrtimer.c
@@ -149,6 +149,15 @@ void linsched_check_idle_cpu(void)
}
}
+void linsched_enter_idle(void)
+{
+ int cpu = smp_processor_id();
+ struct tick_sched *ts = _cpu(tick_cpu_sched, cpu);
+
+ if (!ts->inidle && idle_cpu(cpu))
+ tick_nohz_idle_enter();
+}
+
/* Run a simulation for some number of ticks. Each tick,
* scheduling and load balancing decisions are made. Obviously, we
* could create tasks, change priorities, etc., at certain ticks
@@ -210,7 +219,7 @@ void linsched_run_sim(int sim_ticks)
BUG_ON(irqs_disabled());
if (idle_cpu(active_cpu) && !need_resched()) {
- tick_nohz_idle_enter();
+ linsched_enter_idle();
} else {
linsched_current_handler();
}
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 1/4] linsched: remove process_all_softirqs() in main loop for accuracy
From: Michael Wang process_all_softirqs() will handle softirq for all the cpu even it's not the right timing for them, this will cause inaccuracy. This patch stop invoke process_all_softirqs(), so softirq will only be handled after timer interrupt arrived. Signed-off-by: Michael Wang --- tools/linsched/hrtimer.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/tools/linsched/hrtimer.c b/tools/linsched/hrtimer.c index 26be1d8..de88b25 100644 --- a/tools/linsched/hrtimer.c +++ b/tools/linsched/hrtimer.c @@ -206,7 +206,6 @@ void linsched_run_sim(int sim_ticks) /* a handler should never leave this state changed */ BUG_ON(smp_processor_id() != active_cpu); - process_all_softirqs(); linsched_rcu_invoke(); BUG_ON(irqs_disabled()); -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[RFC PATCH 0/4] linsched: fix issues to make the test results more accurately
From: Michael Wang This patch set fix several issues in linsched, help it to behave more close to the real world, in order to make the test results more accurately. Signed-off-by: Michael Wang --- b/arch/linsched/kernel/irq.c |4 b/tools/linsched/hrtimer.c |1 - b/tools/linsched/linsched.h |2 ++ b/tools/linsched/numa.c |2 ++ tools/linsched/hrtimer.c | 32 +++- 5 files changed, 39 insertions(+), 2 deletions(-) -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] mtd: fix possible memory leak in logfs_mtd_can_write_buf()
On Sun, Sep 02, 2012 at 10:19:06PM +0800, Wei Yongjun wrote: > From: Wei Yongjun > > buf has been allocated in this function and should be > freed before leaving from the error handling case. > > spatch with a semantic match is used to found this problem. > (http://coccinelle.lip6.fr/) > > Signed-off-by: Wei Yongjun > --- Applied, Thanks! > fs/logfs/dev_mtd.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/fs/logfs/dev_mtd.c b/fs/logfs/dev_mtd.c > index 9c50144..427bb73 100644 > --- a/fs/logfs/dev_mtd.c > +++ b/fs/logfs/dev_mtd.c > @@ -245,8 +245,8 @@ static int logfs_mtd_can_write_buf(struct super_block > *sb, u64 ofs) > goto out; > if (memchr_inv(buf, 0xff, super->s_writesize)) > err = -EIO; > - kfree(buf); > out: > + kfree(buf); > return err; > } > > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sysctl: Use BUG_ON instead of BUG
The use of if (!head) BUG(); can be replaced with single line
BUG_ON(!head).
Signed-off-by: Prasad Joshi
---
fs/proc/proc_sysctl.c |3 +--
1 files changed, 1 insertions(+), 2 deletions(-)
diff --git a/fs/proc/proc_sysctl.c b/fs/proc/proc_sysctl.c
index dfafeb2..63bdfa0 100644
--- a/fs/proc/proc_sysctl.c
+++ b/fs/proc/proc_sysctl.c
@@ -266,8 +266,7 @@ void sysctl_head_put(struct ctl_table_header *head)
static struct ctl_table_header *sysctl_head_grab(struct ctl_table_header *head)
{
- if (!head)
- BUG();
+ BUG_ON(!head);
spin_lock(_lock);
if (!use_table(head))
head = ERR_PTR(-ENOENT);
--
1.7.5.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH] efi: Add support for a UEFI variable filesystem
On Sun, Sep 02, 2012 at 06:59:37PM -0700, H. Peter Anvin wrote: > Well, appending is an action, not really a property of the variable that > sticks around, no? We could do this for append, but what happens if an attribute with similar variables appears and doesn't neatly map to an O_ option? We can't really argue for limiting attributes purely because they don't map neatly onto POSIX semantics... -- Matthew Garrett | mj...@srcf.ucam.org -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH] efi: Add support for a UEFI variable filesystem
Hi hpa, > Well, appending is an action, not really a property of the variable > that sticks around, no? True, but they're still all defined as the same thing in the UEFI spec. If you're looking to define which attributes to pass, you now need to know the extra information that you pass most of the SetVariable() attributes through the filename, but APPEND_WRITE is passed a completely different way. To me, this sounds fairly non-intuitive for a developer to discover. Cheers, Jeremy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] mfd: add syscon driver based on regmap
On Mon, Sep 03, 2012 at 10:31:03AM +0800, Dong Aisheng wrote: > > > > I think of_node_put should be moved out from here and put into > > syscon_node_to_regmap and syscon_regmap_lookup_by_compatible. > > > I guess no, if you want to move of_node_put into > syscon_regmap_lookup_by_phandle, > then syscon_regmap_lookup_by_phandle has the same issue. I guess not. syscon_regmap_lookup_by_phandle itself calls of_parse_phandle, and that's where the refcount gets incremented, so syscon_regmap_lookup_by_phandle should be responsible for calling of_node_put to get the refcount decremented. -- Regards, Shawn -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 2/7] ARM: imx6q: add iomuxc gpr support into syscon
On Fri, Aug 31, 2012 at 10:02:48AM +0800, Shawn Guo wrote: > On Wed, Aug 29, 2012 at 06:56:53PM +0800, Dong Aisheng wrote: > > From: Dong Aisheng > > > > Include headfile for easy using. > > > > Acked-by: Stephen Warren > > Signed-off-by: Dong Aisheng > > --- > > arch/arm/boot/dts/imx6q.dtsi |5 + > > include/linux/fsl/imx6q-iomuxc-gpr.h | 319 > > ++ > > I assume that all the users of this header file are imx6q syscon > clients. In that case, this header belongs to mfd/syscon subsystem. > > I have been told by people that it was a mistake to create > include/linux/fsl. Each header in include/linux should go to > respective subsystem sub-directory. For this particular case, > it should be include/linux/mfd or include/linux/mfd/syscon even > better, IMO. > I like the later one if not put in include/linux/fsl. :) > > +#define IMX6Q_GPR13_SATA_PHY_1_MED (0x1 << 0) > > +#define IMX6Q_GPR13_SATA_PHY_1_SLOW(0x2 << 0) > > + > > +#endif /* !__LINUX_IMX6Q_IOMUXC_GPR_H */ > > Nit: why do we have a "!" there? > You're right. We do not need a '!' for such macro. Sorry for my mistake. Regards Dong Aisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] sound: Remove the last mention of SNDRV_MAIN_OBJECT_FILE
SNDRV_MAIN_OBJECT_FILE hasn't done anything since the pre-git days, and the only remaining reference occurs as a #define in sound/last.c. Drop that last mention of it. Signed-off-by: Josh Triplett --- sound/last.c |1 - 1 file changed, 1 deletion(-) diff --git a/sound/last.c b/sound/last.c index 7ffc182..43f2228 100644 --- a/sound/last.c +++ b/sound/last.c @@ -19,7 +19,6 @@ * */ -#define SNDRV_MAIN_OBJECT_FILE #include #include -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/5] perf gtk/browser: Use perf_hpp__format functions
From: Namhyung Kim
Now we can support color using pango markup with this change.
Acked-by: Pekka Enberg
Signed-off-by: Namhyung Kim
---
tools/perf/ui/gtk/browser.c | 101 +---
tools/perf/ui/gtk/gtk.h | 1 +
tools/perf/ui/gtk/setup.c | 1 +
3 files changed, 87 insertions(+), 16 deletions(-)
diff --git a/tools/perf/ui/gtk/browser.c b/tools/perf/ui/gtk/browser.c
index 26b5b652a8cd..3c16ab50e0f8 100644
--- a/tools/perf/ui/gtk/browser.c
+++ b/tools/perf/ui/gtk/browser.c
@@ -36,6 +36,57 @@ static void perf_gtk__resize_window(GtkWidget *window)
gtk_window_resize(GTK_WINDOW(window), width, height);
}
+static const char *perf_gtk__get_percent_color(double percent)
+{
+ if (percent >= MIN_RED)
+ return "";
+ if (percent >= MIN_GREEN)
+ return "";
+ return NULL;
+}
+
+#define HPP__COLOR_FN(_name, _field)
\
+static int perf_gtk__hpp_color_ ## _name(struct perf_hpp *hpp,
\
+struct hist_entry *he)
\
+{
\
+ double percent = 100.0 * he->_field / hpp->total_period;
\
+ const char *markup;
\
+ int ret = 0;
\
+
\
+ markup = perf_gtk__get_percent_color(percent);
\
+ if (markup)
\
+ ret += scnprintf(hpp->buf, hpp->size, "%s", markup);
\
+ ret += scnprintf(hpp->buf + ret, hpp->size - ret, "%5.2f%%", percent);
\
+ if (markup)
\
+ ret += scnprintf(hpp->buf + ret, hpp->size - ret, "");
\
+
\
+ return ret;
\
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void perf_gtk__init_hpp(void)
+{
+ perf_hpp__init(false, false);
+
+ perf_hpp__format[PERF_HPP__OVERHEAD].color =
+ perf_gtk__hpp_color_overhead;
+ perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+ perf_gtk__hpp_color_overhead_sys;
+ perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+ perf_gtk__hpp_color_overhead_us;
+ perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+ perf_gtk__hpp_color_overhead_guest_sys;
+ perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+ perf_gtk__hpp_color_overhead_guest_us;
+}
+
static void perf_gtk__show_hists(GtkWidget *window, struct hists *hists)
{
GType col_types[MAX_COLUMNS];
@@ -43,15 +94,25 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists)
struct sort_entry *se;
GtkListStore *store;
struct rb_node *nd;
- u64 total_period;
GtkWidget *view;
- int col_idx;
+ int i, col_idx;
int nr_cols;
+ char s[512];
+
+ struct perf_hpp hpp = {
+ .buf= s,
+ .size = sizeof(s),
+ .total_period = hists->stats.total_period,
+ };
nr_cols = 0;
- /* The percentage column */
- col_types[nr_cols++] = G_TYPE_STRING;
+ for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+ if (!perf_hpp__format[i].cond)
+ continue;
+
+ col_types[nr_cols++] = G_TYPE_STRING;
+ }
list_for_each_entry(se, _entry__sort_list, list) {
if (se->elide)
@@ -68,11 +129,17 @@ static void perf_gtk__show_hists(GtkWidget *window, struct
hists *hists)
col_idx = 0;
- /* The percentage column */
- gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
- -1, "Overhead (%)",
- renderer, "text",
- col_idx++, NULL);
+ for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+ if (!perf_hpp__format[i].cond)
+ continue;
+
+ perf_hpp__format[i].header();
+
+ gtk_tree_view_insert_column_with_attributes(GTK_TREE_VIEW(view),
+ -1, s,
+
[PATCH 1/5] perf hists: Introduce perf_hpp for hist period printing
From: Namhyung Kim
Current hist print functions are messy because it has to consider many
of command line options and the code doing that is scattered around to
places. So when someone wants to add an option to manipulate the hist
output it'd very easy to miss to update all of them in sync. And things
getting worse as more options/features are added continuously.
So I'd like to refactor them using hpp formats and move common code to
ui/hist.c in order to make it easy to maintain and to add new features.
Signed-off-by: Namhyung Kim
---
tools/perf/Makefile| 2 +
tools/perf/builtin-diff.c | 1 +
tools/perf/ui/hist.c | 316 +
tools/perf/ui/setup.c | 8 +-
tools/perf/ui/stdio/hist.c | 238 ++
tools/perf/util/hist.h | 37 ++
6 files changed, 402 insertions(+), 200 deletions(-)
create mode 100644 tools/perf/ui/hist.c
diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 722ddee61f9f..23e5c6ab4276 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -403,7 +403,9 @@ LIB_OBJS += $(OUTPUT)util/cgroup.o
LIB_OBJS += $(OUTPUT)util/target.o
LIB_OBJS += $(OUTPUT)util/rblist.o
LIB_OBJS += $(OUTPUT)util/intlist.o
+
LIB_OBJS += $(OUTPUT)ui/helpline.o
+LIB_OBJS += $(OUTPUT)ui/hist.o
LIB_OBJS += $(OUTPUT)ui/stdio/hist.o
BUILTIN_OBJS += $(OUTPUT)builtin-annotate.o
diff --git a/tools/perf/builtin-diff.c b/tools/perf/builtin-diff.c
index d29d350fb2b7..3fc53f8b098e 100644
--- a/tools/perf/builtin-diff.c
+++ b/tools/perf/builtin-diff.c
@@ -235,6 +235,7 @@ int cmd_diff(int argc, const char **argv, const char
*prefix __used)
if (symbol__init() < 0)
return -1;
+ perf_hpp__init(true, show_displacement);
setup_sorting(diff_usage, options);
setup_pager();
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
new file mode 100644
index ..c9a566cfd9c2
--- /dev/null
+++ b/tools/perf/ui/hist.c
@@ -0,0 +1,316 @@
+#include
+
+#include "../util/hist.h"
+#include "../util/util.h"
+#include "../util/sort.h"
+
+
+/* hist period print (hpp) functions */
+static int hpp__header_overhead(struct perf_hpp *hpp)
+{
+ if (hpp->ptr)
+ return scnprintf(hpp->buf, hpp->size, "Baseline");
+ else
+ return scnprintf(hpp->buf, hpp->size, "Overhead");
+}
+
+static int hpp__width_overhead(struct perf_hpp *hpp __used)
+{
+ return 8;
+}
+
+static int hpp__color_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period / hpp->total_period;
+ return percent_color_snprintf(hpp->buf, hpp->size, " %5.2f%%",
percent);
+}
+
+static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period / hpp->total_period;
+ return scnprintf(hpp->buf, hpp->size, " %5.2f%%", percent);
+}
+
+static int hpp__header_overhead_sys(struct perf_hpp *hpp)
+{
+ return scnprintf(hpp->buf, hpp->size, " sys ");
+}
+
+static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
+{
+ return 6;
+}
+
+static int hpp__color_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_sys / hpp->total_period;
+ return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_sys / hpp->total_period;
+ return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__header_overhead_us(struct perf_hpp *hpp)
+{
+ return scnprintf(hpp->buf, hpp->size, " user ");
+}
+
+static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
+{
+ return 6;
+}
+
+static int hpp__color_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_us / hpp->total_period;
+ return percent_color_snprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_us / hpp->total_period;
+ return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+}
+
+static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
+{
+ return scnprintf(hpp->buf, hpp->size, "guest sys");
+}
+
+static int hpp__width_overhead_guest_sys(struct perf_hpp *hpp __used)
+{
+ return 9;
+}
+
+static int hpp__color_overhead_guest_sys(struct perf_hpp *hpp,
+struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_guest_sys / hpp->total_period;
+ return percent_color_snprintf(hpp->buf, hpp->size, " %5.2f%% ",
percent);
+}
+
+static int hpp__entry_overhead_guest_sys(struct perf_hpp *hpp,
+struct hist_entry *he)
+{
+ double percent = 100.0 * he->period_guest_sys /
[PATCH 3/5] perf hists: Use perf_hpp__format->width to calculate the column widths
From: Namhyung Kim
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 27 +++
tools/perf/util/hist.c | 33 -
2 files changed, 27 insertions(+), 33 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index 802a8659c15a..16dc486d02be 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -337,3 +337,30 @@ int hist_entry__sort_snprintf(struct hist_entry *he, char
*s, size_t size,
return ret;
}
+
+/*
+ * See hists__fprintf to match the column widths
+ */
+unsigned int hists__sort_list_width(struct hists *hists)
+{
+ struct sort_entry *se;
+ int i, ret = 0;
+
+ for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+ if (!perf_hpp__format[i].cond)
+ continue;
+ if (i)
+ ret += 2;
+
+ ret += perf_hpp__format[i].width(NULL);
+ }
+
+ list_for_each_entry(se, _entry__sort_list, list)
+ if (!se->elide)
+ ret += 2 + hists__col_len(hists, se->se_width_idx);
+
+ if (verbose) /* Addr + origin */
+ ret += 3 + BITS_PER_LONG / 4;
+
+ return ret;
+}
diff --git a/tools/perf/util/hist.c b/tools/perf/util/hist.c
index b1817f15bb87..0ba65ad07cd1 100644
--- a/tools/perf/util/hist.c
+++ b/tools/perf/util/hist.c
@@ -563,39 +563,6 @@ void hists__output_resort_threaded(struct hists *hists)
return __hists__output_resort(hists, true);
}
-/*
- * See hists__fprintf to match the column widths
- */
-unsigned int hists__sort_list_width(struct hists *hists)
-{
- struct sort_entry *se;
- int ret = 9; /* total % */
-
- if (symbol_conf.show_cpu_utilization) {
- ret += 7; /* count_sys % */
- ret += 6; /* count_us % */
- if (perf_guest) {
- ret += 13; /* count_guest_sys % */
- ret += 12; /* count_guest_us % */
- }
- }
-
- if (symbol_conf.show_nr_samples)
- ret += 11;
-
- if (symbol_conf.show_total_period)
- ret += 13;
-
- list_for_each_entry(se, _entry__sort_list, list)
- if (!se->elide)
- ret += 2 + hists__col_len(hists, se->se_width_idx);
-
- if (verbose) /* Addr + origin */
- ret += 3 + BITS_PER_LONG / 4;
-
- return ret;
-}
-
static void hists__remove_entry_filter(struct hists *hists, struct hist_entry
*h,
enum hist_filter filter)
{
--
1.7.11.4
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] perf ui/browser: Use perf_hpp__format functions
From: Namhyung Kim
Override hpp->color functions for TUI. Because line coloring is done
outside of the function, it just sets the percent value and pass it.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/browsers/hists.c | 94 --
tools/perf/ui/tui/setup.c | 4 ++
2 files changed, 76 insertions(+), 22 deletions(-)
diff --git a/tools/perf/ui/browsers/hists.c b/tools/perf/ui/browsers/hists.c
index 81bd8c2af730..144d7be2872e 100644
--- a/tools/perf/ui/browsers/hists.c
+++ b/tools/perf/ui/browsers/hists.c
@@ -28,6 +28,8 @@ struct hist_browser {
bool has_symbols;
};
+extern void hist_browser__init_hpp(void);
+
static int hists__browser_title(struct hists *hists, char *bf, size_t size,
const char *ev_name);
@@ -563,14 +565,47 @@ static int hist_browser__show_callchain(struct
hist_browser *browser,
return row - first_row;
}
+#define HPP__COLOR_FN(_name, _field) \
+static int hist_browser__hpp_color_ ## _name(struct perf_hpp *hpp, \
+struct hist_entry *he) \
+{ \
+ double percent = 100.0 * he->_field / hpp->total_period;\
+ *(double *)hpp->ptr = percent; \
+ return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent); \
+}
+
+HPP__COLOR_FN(overhead, period)
+HPP__COLOR_FN(overhead_sys, period_sys)
+HPP__COLOR_FN(overhead_us, period_us)
+HPP__COLOR_FN(overhead_guest_sys, period_guest_sys)
+HPP__COLOR_FN(overhead_guest_us, period_guest_us)
+
+#undef HPP__COLOR_FN
+
+void hist_browser__init_hpp(void)
+{
+ perf_hpp__init(false, false);
+
+ perf_hpp__format[PERF_HPP__OVERHEAD].color =
+ hist_browser__hpp_color_overhead;
+ perf_hpp__format[PERF_HPP__OVERHEAD_SYS].color =
+ hist_browser__hpp_color_overhead_sys;
+ perf_hpp__format[PERF_HPP__OVERHEAD_US].color =
+ hist_browser__hpp_color_overhead_us;
+ perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_SYS].color =
+ hist_browser__hpp_color_overhead_guest_sys;
+ perf_hpp__format[PERF_HPP__OVERHEAD_GUEST_US].color =
+ hist_browser__hpp_color_overhead_guest_us;
+}
+
static int hist_browser__show_entry(struct hist_browser *browser,
struct hist_entry *entry,
unsigned short row)
{
char s[256];
double percent;
- int printed = 0;
- int width = browser->b.width - 6; /* The percentage */
+ int i, printed = 0;
+ int width = browser->b.width;
char folded_sign = ' ';
bool current_entry = ui_browser__is_current_entry(>b, row);
off_t row_offset = entry->row_offset;
@@ -586,35 +621,50 @@ static int hist_browser__show_entry(struct hist_browser
*browser,
}
if (row_offset == 0) {
- hist_entry__sort_snprintf(entry, s, sizeof(s), browser->hists);
- percent = (entry->period * 100.0) /
browser->hists->stats.total_period;
+ struct perf_hpp hpp = {
+ .buf= s,
+ .size = sizeof(s),
+ .total_period = browser->hists->stats.total_period,
+ };
- ui_browser__set_percent_color(>b, percent,
current_entry);
ui_browser__gotorc(>b, row, 0);
- if (symbol_conf.use_callchain) {
- slsmg_printf("%c ", folded_sign);
- width -= 2;
- }
- slsmg_printf(" %5.2f%%", percent);
+ for (i = 0; i < PERF_HPP__MAX_INDEX; i++) {
+ if (!perf_hpp__format[i].cond)
+ continue;
- /* The scroll bar isn't being used */
- if (!browser->b.navkeypressed)
- width += 1;
+ if (i) {
+ slsmg_printf(" ");
+ width -= 2;
+ }
- if (!current_entry || !browser->b.navkeypressed)
- ui_browser__set_color(>b, HE_COLORSET_NORMAL);
+ if (perf_hpp__format[i].color) {
+ hpp.ptr =
+ /* It will set percent for us. See
HPP__COLOR_FN above. */
+ width -= perf_hpp__format[i].color(, entry);
- if (symbol_conf.show_nr_samples) {
- slsmg_printf(" %11u", entry->nr_events);
- width -= 12;
- }
+ ui_browser__set_percent_color(>b,
percent, current_entry);
+
+
[PATCH 2/5] perf hists: Handle field separator properly
From: Namhyung Kim
When a field separator is given, the output format doesn't need to be
fancy like aligning to column length, coloring the percent value and
so on. And since there's a slight difference to normal format, fix it
not to break backward compatibility.
Signed-off-by: Namhyung Kim
---
tools/perf/ui/hist.c | 75 ++
tools/perf/ui/stdio/hist.c | 3 +-
2 files changed, 51 insertions(+), 27 deletions(-)
diff --git a/tools/perf/ui/hist.c b/tools/perf/ui/hist.c
index c9a566cfd9c2..802a8659c15a 100644
--- a/tools/perf/ui/hist.c
+++ b/tools/perf/ui/hist.c
@@ -8,10 +8,9 @@
/* hist period print (hpp) functions */
static int hpp__header_overhead(struct perf_hpp *hpp)
{
- if (hpp->ptr)
- return scnprintf(hpp->buf, hpp->size, "Baseline");
- else
- return scnprintf(hpp->buf, hpp->size, "Overhead");
+ const char *fmt = hpp->ptr ? "Baseline" : "Overhead";
+
+ return scnprintf(hpp->buf, hpp->size, fmt);
}
static int hpp__width_overhead(struct perf_hpp *hpp __used)
@@ -28,12 +27,16 @@ static int hpp__color_overhead(struct perf_hpp *hpp, struct
hist_entry *he)
static int hpp__entry_overhead(struct perf_hpp *hpp, struct hist_entry *he)
{
double percent = 100.0 * he->period / hpp->total_period;
- return scnprintf(hpp->buf, hpp->size, " %5.2f%%", percent);
+ const char *fmt = symbol_conf.field_sep ? "%.2f" : " %5.2f%%";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, percent);
}
static int hpp__header_overhead_sys(struct perf_hpp *hpp)
{
- return scnprintf(hpp->buf, hpp->size, " sys ");
+ const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, "sys");
}
static int hpp__width_overhead_sys(struct perf_hpp *hpp __used)
@@ -50,12 +53,16 @@ static int hpp__color_overhead_sys(struct perf_hpp *hpp,
struct hist_entry *he)
static int hpp__entry_overhead_sys(struct perf_hpp *hpp, struct hist_entry *he)
{
double percent = 100.0 * he->period_sys / hpp->total_period;
- return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+ const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, percent);
}
static int hpp__header_overhead_us(struct perf_hpp *hpp)
{
- return scnprintf(hpp->buf, hpp->size, " user ");
+ const char *fmt = symbol_conf.field_sep ? "%s" : "%6s";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, "user");
}
static int hpp__width_overhead_us(struct perf_hpp *hpp __used)
@@ -72,7 +79,9 @@ static int hpp__color_overhead_us(struct perf_hpp *hpp,
struct hist_entry *he)
static int hpp__entry_overhead_us(struct perf_hpp *hpp, struct hist_entry *he)
{
double percent = 100.0 * he->period_us / hpp->total_period;
- return scnprintf(hpp->buf, hpp->size, "%5.2f%%", percent);
+ const char *fmt = symbol_conf.field_sep ? "%.2f" : "%5.2f%%";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, percent);
}
static int hpp__header_overhead_guest_sys(struct perf_hpp *hpp)
@@ -96,7 +105,9 @@ static int hpp__entry_overhead_guest_sys(struct perf_hpp
*hpp,
struct hist_entry *he)
{
double percent = 100.0 * he->period_guest_sys / hpp->total_period;
- return scnprintf(hpp->buf, hpp->size, " %5.2f%% ", percent);
+ const char *fmt = symbol_conf.field_sep ? "%.2f" : " %5.2f%% ";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, percent);
}
static int hpp__header_overhead_guest_us(struct perf_hpp *hpp)
@@ -120,12 +131,16 @@ static int hpp__entry_overhead_guest_us(struct perf_hpp
*hpp,
struct hist_entry *he)
{
double percent = 100.0 * he->period_guest_us / hpp->total_period;
- return scnprintf(hpp->buf, hpp->size, " %5.2f%% ", percent);
+ const char *fmt = symbol_conf.field_sep ? "%.2f" : " %5.2f%% ";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, percent);
}
static int hpp__header_samples(struct perf_hpp *hpp)
{
- return scnprintf(hpp->buf, hpp->size, " Samples ");
+ const char *fmt = symbol_conf.field_sep ? "%s" : "%11s";
+
+ return scnprintf(hpp->buf, hpp->size, fmt, "Samples");
}
static int hpp__width_samples(struct perf_hpp *hpp __used)
@@ -135,12 +150,16 @@ static int hpp__width_samples(struct perf_hpp *hpp __used)
static int hpp__entry_samples(struct perf_hpp *hpp, struct hist_entry *he)
{
- return scnprintf(hpp->buf, hpp->size, "%11" PRIu64, he->nr_events);
+ const char *fmt = symbol_conf.field_sep ? "%" PRIu64 : "%11" PRIu64;
+
+ return scnprintf(hpp->buf, hpp->size, fmt, he->nr_events);
}
static int hpp__header_period(struct perf_hpp *hpp)
{
- return scnprintf(hpp->buf, hpp->size, " Period ");
+ const char *fmt = symbol_conf.field_sep ? "%s" : "%12s";
+
+ return
[PATCHSET RESEND 0/5] perf tools: Cleanup hist printing code (v4)
Hi, This is a cleanup and refactoring patchset for the hist printing code by adding perf_hpp__format functions and perf_hpp. I believe it makes the code easy to maintain and to add new features like upcoming group viewing and callchain accumulation. Any comments are welcome, thanks. Namhyung v3 -> v4: * Rebase to current acme/perf/core * The first two in the previous series have been merged * Rename hist_period_print to perf_hpp_fmt (Arnaldo) * Rename ctx->s to hpp->buf (Arnaldo) v2 -> v3: * Move fprintf code to ui/stdio/hist.c (Arnaldo) * Add ack from Pekka Namhyung Kim (5): perf hists: Introduce perf_hpp for hist period printing perf hists: Handle field separator properly perf hists: Use perf_hpp__format->width to calculate the column widths perf ui/browser: Use perf_hpp__format functions perf gtk/browser: Use perf_hpp__format functions tools/perf/Makefile| 2 + tools/perf/builtin-diff.c | 1 + tools/perf/ui/browsers/hists.c | 94 --- tools/perf/ui/gtk/browser.c| 101 ++-- tools/perf/ui/gtk/gtk.h| 1 + tools/perf/ui/gtk/setup.c | 1 + tools/perf/ui/hist.c | 366 + tools/perf/ui/setup.c | 8 +- tools/perf/ui/stdio/hist.c | 239 +-- tools/perf/ui/tui/setup.c | 4 + tools/perf/util/hist.c | 33 tools/perf/util/hist.h | 37 + 12 files changed, 616 insertions(+), 271 deletions(-) create mode 100644 tools/perf/ui/hist.c -- 1.7.11.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Can not get output of command line on SH
On Fri, Aug 31, 2012 at 10:10 PM, Al Viro wrote: > On Fri, Aug 31, 2012 at 04:32:45PM +0900, Nobuhiro Iwamatsu wrote: >> Hi, Al. >> >> I can not get output of command line on SH in latest linux kernel. >> I bisected, I confirmed that this problem occurred by following commit. >> >> - >> commit 4a9d4b024a3102fc083c925c242d98ac27b1c5f6 >> Author: Al Viro >> Date: Sun Jun 24 09:56:45 2012 +0400 >> >> switch fput to task_work_add > >> For example ,when I input 'ls', nothing is displayed. >> However, it is outputted when 'Ctrl+C' is inputted. >> I checked other CPUs, it is only SH that this problem occurs. >> >> Paul, do you think about this? > > Smells like broken TIF_NOTIFY_RESUME hookup on sh... Arrrgh. Looks like > while it is in the relevant masks *and* checked in do_notify_resume() both > on 32bit and 64bit variants since commit > ab99c733ae73cce31f2a2434f7099564e5a73d95 > Author: Paul Mundt > Date: Wed Jul 30 19:55:30 2008 +0900 > > sh: Make syscall tracer use tracehook notifiers, add TIF_NOTIFY_RESUME. > > they are actually *not* reached without simulataneous SIGPENDING, since the > actual glue in the callers had not been updated back then and still checks > for _TIF_SIGPENDING alone when deciding whether to hit do_notify_resume() > or not. Looks like the following ought to fix that: Thanks for your reply and explanation. I confirmed that revise this problem with your patch. > > Signed-off-by: Al Viro Tested-by: Nobuhiro Iwamatsu > --- > diff --git a/arch/sh/kernel/cpu/sh5/entry.S b/arch/sh/kernel/cpu/sh5/entry.S > index b7cf6a5..7e605b9 100644 > --- a/arch/sh/kernel/cpu/sh5/entry.S > +++ b/arch/sh/kernel/cpu/sh5/entry.S > @@ -933,7 +933,7 @@ ret_with_reschedule: > > pta restore_all, tr1 > > - movi_TIF_SIGPENDING, r8 > + movi(_TIF_SIGPENDING|_TIF_NOTIFY_RESUME), r8 > and r8, r7, r8 > pta work_notifysig, tr0 > bne r8, ZERO, tr0 > diff --git a/arch/sh/kernel/entry-common.S b/arch/sh/kernel/entry-common.S > index f67601c..b96489d 100644 > --- a/arch/sh/kernel/entry-common.S > +++ b/arch/sh/kernel/entry-common.S > @@ -139,7 +139,7 @@ work_pending: > ! r8: current_thread_info > ! t: result of "tst#_TIF_NEED_RESCHED, r0" > bf/swork_resched > -tst#_TIF_SIGPENDING, r0 > +tst#(_TIF_SIGPENDING | _TIF_NOTIFY_RESUME), r0 > work_notifysig: > bt/s__restore_all > movr15, r4 > -- Best regards, Nobuhiro -- Nobuhiro Iwamatsu -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 7/7] mfd: anatop-mfd: remove anatop driver
On Fri, Aug 31, 2012 at 09:39:26AM +0800, Shawn Guo wrote: > On Wed, Aug 29, 2012 at 06:56:58PM +0800, Dong Aisheng wrote: > > -config MFD_ANATOP > > - bool "Support for Freescale i.MX on-chip ANATOP controller" > > - depends on SOC_IMX6Q > > - help > > - Select this option to enable Freescale i.MX on-chip ANATOP > > - MFD controller. This controller embeds regulator and > > - thermal devices for Freescale i.MX platforms. > > - > > All the occurrences of MFD_ANATOP should be removed too. I know there > is one in arch/arm/mach-imx/Kconfig. > Yes, it has been made in patch 5: [PATCH v4 5/7] ARM: imx6q: convert to use syscon to access anatop registers Regards Dong Aisheng -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v4 1/7] mfd: add syscon driver based on regmap
On Fri, Aug 31, 2012 at 09:26:29AM +0800, Shawn Guo wrote:
> On Wed, Aug 29, 2012 at 06:56:52PM +0800, Dong Aisheng wrote:
> > +config MFD_SYSCON
> > +bool "System Controller Register R/W Based on Regmap"
>
> If the driver only compiles and works for device tree probe, we should
> have the following?
>
> depends on OF
>
Correct.
For currently it only supports dt.
> > +select REGMAP_MMIO
> > +help
> > + Select this option to enable accessing system control registers
> > + via regmap.
> > +
>
>
>
> > +struct regmap *syscon_node_to_regmap(struct device_node *np)
> > +{
> > + struct syscon *syscon;
> > + struct device *dev;
> > +
> > + dev = driver_find_device(_driver.driver, NULL, np,
> > +syscon_match);
> > + of_node_put(np);
>
> This looks a little unnatural to me. Function syscon_node_to_regmap
> becomes an API visible to clients, who might never know that np will
> be put inside the API. I'm saying the client may also call of_node_put
> to put the node they get.
We probably could add a comment here for the API to avoid this happen.
>
> I think of_node_put should be moved out from here and put into
> syscon_node_to_regmap and syscon_regmap_lookup_by_compatible.
>
I guess no, if you want to move of_node_put into
syscon_regmap_lookup_by_phandle,
then syscon_regmap_lookup_by_phandle has the same issue.
Actually i had considered your concern when writing this API...
The original purpose of doing like that is saving some duplicated 'of_node_put'
and make the API easy to use.
I searched the kernel dt code and found it existed some similar cases.
e.g: of_irq_find_parent, of_get_next_parent
So it looks to me that it may be usually to do like that for the cases that
the conversion from a node to other thing since the client may only care
about the things converted. For our case, it's regmap.
So i can't think it make too much sense for all client driver have to write
duplicated and meaningless 'of_node_put' code.
Regards
Dong Aisheng
> > +
> > + if (!dev)
> > + return ERR_PTR(-EPROBE_DEFER);
> > +
> > + syscon = dev_get_drvdata(dev);
> > +
> > + return syscon->regmap;
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_node_to_regmap);
> > +
> > +struct regmap *syscon_regmap_lookup_by_compatible(const char *s)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_find_compatible_node(NULL, NULL, s);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_compatible);
> > +
> > +struct regmap *syscon_regmap_lookup_by_phandle(struct device_node *np,
> > + const char *property)
> > +{
> > + struct device_node *syscon_np;
> > +
> > + syscon_np = of_parse_phandle(np, property, 0);
> > + if (!syscon_np)
> > + return ERR_PTR(-ENODEV);
> > +
> > + return syscon_node_to_regmap(syscon_np);
> > +}
> > +EXPORT_SYMBOL_GPL(syscon_regmap_lookup_by_phandle);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] trace: Stop compiling in trace_clock unconditionally
Commit 56449f437add737a1e5e1cb7e00f63ac8ead1938, in April 2009, made trace_clock available unconditionally, since CONFIG_X86_DS used it too. Commit faa4602e47690fb11221e00f9b9697c8dc0d4b19, in March 2010, removed CONFIG_X86_DS, and now only CONFIG_RING_BUFFER (split out from CONFIG_TRACING for general use) has a dependency on trace_clock. So, only compile in trace_clock with CONFIG_RING_BUFFER or CONFIG_TRACING enabled. Signed-off-by: Josh Triplett --- kernel/Makefile |2 +- kernel/trace/Kconfig |5 + kernel/trace/Makefile |6 +- 3 files changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/Makefile b/kernel/Makefile index c0cc67a..29d993b 100644 --- a/kernel/Makefile +++ b/kernel/Makefile @@ -98,7 +98,7 @@ obj-$(CONFIG_COMPAT_BINFMT_ELF) += elfcore.o obj-$(CONFIG_BINFMT_ELF_FDPIC) += elfcore.o obj-$(CONFIG_FUNCTION_TRACER) += trace/ obj-$(CONFIG_TRACING) += trace/ -obj-$(CONFIG_X86_DS) += trace/ +obj-$(CONFIG_TRACE_CLOCK) += trace/ obj-$(CONFIG_RING_BUFFER) += trace/ obj-$(CONFIG_TRACEPOINTS) += trace/ obj-$(CONFIG_IRQ_WORK) += irq_work.o diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig index 8c4c070..e8b7c26 100644 --- a/kernel/trace/Kconfig +++ b/kernel/trace/Kconfig @@ -57,8 +57,12 @@ config HAVE_C_RECORDMCOUNT config TRACER_MAX_TRACE bool +config TRACE_CLOCK + bool + config RING_BUFFER bool + select TRACE_CLOCK config FTRACE_NMI_ENTER bool @@ -109,6 +113,7 @@ config TRACING select NOP_TRACER select BINARY_PRINTF select EVENT_TRACING + select TRACE_CLOCK config GENERIC_TRACER bool diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile index b831087..1b8e4c7 100644 --- a/kernel/trace/Makefile +++ b/kernel/trace/Makefile @@ -17,11 +17,7 @@ endif CFLAGS_trace_events_filter.o := -I$(src) -# -# Make the trace clocks available generally: it's infrastructure -# relied on by ptrace for example: -# -obj-y += trace_clock.o +obj-$(CONFIG_TRACE_CLOCK) += trace_clock.o obj-$(CONFIG_FUNCTION_TRACER) += libftrace.o obj-$(CONFIG_RING_BUFFER) += ring_buffer.o -- 1.7.10.4 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 6/9] misc: Generic on-chip SRAM allocation driver
On Fri, Aug 31, 2012 at 11:27:01AM +0200, Philipp Zabel wrote:
> This driver requests and remaps a memory region as configured in the
> device tree. It serves memory from this region via the genalloc API.
>
> Other drivers can retrieve the genalloc pool from a phandle pointing
> to this drivers' device node in the device tree.
>
> Signed-off-by: Philipp Zabel
> ---
> drivers/misc/Kconfig |8
> drivers/misc/Makefile |1 +
> drivers/misc/sram.c | 105
> +
> 3 files changed, 114 insertions(+)
> create mode 100644 drivers/misc/sram.c
>
> diff --git a/drivers/misc/Kconfig b/drivers/misc/Kconfig
> index 98a442d..8a55284 100644
> --- a/drivers/misc/Kconfig
> +++ b/drivers/misc/Kconfig
> @@ -509,6 +509,14 @@ config USB_SWITCH_FSA9480
> stereo and mono audio, video, microphone and UART data to use
> a common connector port.
>
> +config SRAM
> + bool "Generic on-chip SRAM driver\n"
Remove the "\n".
And "depends on HAS_IOMEM"?
> + select GENERIC_ALLOCATOR
> + help
> + This driver allows to declare a memory region to be managed
> + by the genalloc API. It is supposed to be used for small
> + on-chip SRAM areas found on many ARM SoCs.
> +
> source "drivers/misc/c2port/Kconfig"
> source "drivers/misc/eeprom/Kconfig"
> source "drivers/misc/cb710/Kconfig"
> diff --git a/drivers/misc/Makefile b/drivers/misc/Makefile
> index b88df7a..ccc759a 100644
> --- a/drivers/misc/Makefile
> +++ b/drivers/misc/Makefile
> @@ -50,3 +50,4 @@ obj-y += carma/
> obj-$(CONFIG_USB_SWITCH_FSA9480) += fsa9480.o
> obj-$(CONFIG_ALTERA_STAPL) +=altera-stapl/
> obj-$(CONFIG_INTEL_MEI) += mei/
> +obj-$(CONFIG_SRAM) += sram.o
> diff --git a/drivers/misc/sram.c b/drivers/misc/sram.c
> new file mode 100644
> index 000..c5cf67e
> --- /dev/null
> +++ b/drivers/misc/sram.c
> @@ -0,0 +1,105 @@
> +/*
> + * Generic on-chip SRAM allocation driver
> + *
> + * Copyright (C) 2012 Philipp Zabel, Pengutronix
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License
> + * as published by the Free Software Foundation; either version 2
> + * of the License, or (at your option) any later version.
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 51 Franklin Street, Fifth Floor, Boston,
> + * MA 02110-1301, USA.
> + */
> +
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +#include
> +
> +struct sram_dev {
> + struct gen_pool *pool;
> +};
> +
> +static int __devinit sram_probe(struct platform_device *pdev)
> +{
> + void __iomem *virt_base;
> + struct sram_dev *sram;
> + struct resource *res;
> + unsigned long size;
> + int ret;
> +
> + res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
> + if (!res)
> + return -EINVAL;
> +
> + size = resource_size(res);
> +
> + virt_base = devm_request_and_ioremap(>dev, res);
> + if (!virt_base)
> + return -ENOMEM;
The kerneldoc of devm_request_and_ioremap suggests -EADDRNOTAVAIL.
Regards,
Shawn
> +
> + sram = devm_kzalloc(>dev, sizeof(*sram), GFP_KERNEL);
> + if (!sram)
> + return -ENOMEM;
> +
> + sram->pool = gen_pool_create(PAGE_SHIFT, -1);
> + if (!sram->pool)
> + return -ENOMEM;
> +
> + ret = gen_pool_add_virt(sram->pool, (unsigned long)virt_base,
> + res->start, size, -1);
> + if (ret < 0) {
> + gen_pool_destroy(sram->pool);
> + return ret;
> + }
> +
> + platform_set_drvdata(pdev, sram);
> +
> + dev_dbg(>dev, "SRAM pool: %ld KiB @ 0x%p\n", size / 1024,
> virt_base);
> +
> + return 0;
> +}
> +
> +static int __devexit sram_remove(struct platform_device *pdev)
> +{
> + struct sram_dev *sram = platform_get_drvdata(pdev);
> +
> + if (gen_pool_avail(sram->pool) < gen_pool_size(sram->pool))
> + dev_dbg(>dev, "removed while SRAM allocated\n");
> +
> + gen_pool_destroy(sram->pool);
> +
> + return 0;
> +}
> +
> +#ifdef CONFIG_OF
> +static struct of_device_id sram_dt_ids[] = {
> + { .compatible = "sram" },
> + { /* sentinel */ }
> +};
> +#endif
> +
> +static struct platform_driver sram_driver = {
> + .driver = {
> + .name = "sram",
> + .of_match_table = of_match_ptr(sram_dt_ids),
> + },
> + .probe = sram_probe,
> + .remove = __devexit_p(sram_remove),
> +};
> +
> +module_platform_driver(sram_driver);
> +
>
Re: [PATCH] sched: unify the check on atomic sleeping in __might_sleep() and schedule_bug()
On 08/22/2012 10:40 AM, Michael Wang wrote: > From: Michael Wang > > Fengguang Wu has reported the bug: > > [0.043953] BUG: scheduling while atomic: swapper/0/1/0x1002 > [0.044017] no locks held by swapper/0/1. > [0.044692] Pid: 1, comm: swapper/0 Not tainted 3.6.0-rc1-00420-gb7aebb9 > #34 > [0.045861] Call Trace: > [0.048071] [] __schedule_bug+0x5e/0x70 > [0.048890] [] __schedule+0x91/0xb10 > [0.049660] [] ? vsnprintf+0x33a/0x450 > [0.050444] [] ? lg_local_lock+0x6/0x70 > [0.051256] [] ? wait_for_xmitr+0x31/0x90 > [0.052019] [] ? do_raw_spin_unlock+0xa5/0xf0 > [0.052903] [] ? _raw_spin_unlock+0x22/0x30 > [0.053759] [] ? up+0x1b/0x70 > [0.054421] [] __cond_resched+0x1b/0x30 > [0.055228] [] _cond_resched+0x45/0x50 > [0.056020] [] mutex_lock_nested+0x28/0x370 > [0.056884] [] ? console_unlock+0x3a2/0x4e0 > [0.057741] [] __irq_alloc_descs+0x39/0x1c0 > [0.058589] [] io_apic_setup_irq_pin+0x2c/0x310 > [0.060042] [] setup_IO_APIC+0x101/0x744 > [0.060878] [] ? clear_IO_APIC+0x31/0x50 > [0.061695] [] native_smp_prepare_cpus+0x538/0x680 > [0.062644] [] ? do_one_initcall+0x12c/0x12c > [0.063517] [] ? do_one_initcall+0x12c/0x12c > [0.064016] [] kernel_init+0x4b/0x17f > [0.064790] [] ? do_one_initcall+0x12c/0x12c > [0.065660] [] kernel_thread_helper+0x6/0x10 > > It was caused by that: > > native_smp_prepare_cpus() > preempt_disable() //preempt_count++ > mutex_lock()//in __irq_alloc_descs > __might_sleep() //system is booting, avoid check > might_resched() > __schedule() > preempt_disable() //preempt_count++ > schedule_bug() //preempt_count > 1, report bug > > The __might_sleep() avoid check on atomic sleeping until the system booted > while the schedule_bug() doesn't, it's the reason for the bug. > > This patch will add one additional check in schedule_bug() to avoid check > until the system booted, so the check on atomic sleeping will be unified. Could I get some comments on this patch? Regards, Michael Wang > > Signed-off-by: Michael Wang > Tested-by: Fengguang Wu > --- > kernel/sched/core.c |3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/kernel/sched/core.c b/kernel/sched/core.c > index 4376c9f..3396c33 100644 > --- a/kernel/sched/core.c > +++ b/kernel/sched/core.c > @@ -3321,7 +3321,8 @@ static inline void schedule_debug(struct task_struct > *prev) >* schedule() atomically, we ignore that path for now. >* Otherwise, whine if we are scheduling when we should not be. >*/ > - if (unlikely(in_atomic_preempt_off() && !prev->exit_state)) > + if (unlikely(in_atomic_preempt_off() && !prev->exit_state > + && system_state == SYSTEM_RUNNING)) > __schedule_bug(prev); > rcu_sleep_check(); > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/2] md: modify dm_io() so it could return bios instead of submitting it
From: Robin Dong
When trying to modify flashcache to request based (current it's bio based), we
need
to make request from bios by ourselves, but dm_io() will submit these bios
directly,
so we propose to modify the dm_io() to return bios instead of submiting it.
This could also improve the flexibility of dm_io().
Signed-off-by: Robin Dong
---
drivers/md/dm-bufio.c |2 +
drivers/md/dm-io.c | 58 +++
drivers/md/dm-kcopyd.c |1 +
drivers/md/dm-log.c |1 +
drivers/md/dm-raid1.c |3 ++
drivers/md/dm-snap-persistent.c |1 +
include/linux/dm-io.h |3 ++
7 files changed, 45 insertions(+), 24 deletions(-)
diff --git a/drivers/md/dm-bufio.c b/drivers/md/dm-bufio.c
index cc06a1e..f5867b9 100644
--- a/drivers/md/dm-bufio.c
+++ b/drivers/md/dm-bufio.c
@@ -487,6 +487,7 @@ static void use_dmio(struct dm_buffer *b, int rw, sector_t
block,
.notify.fn = dmio_complete,
.notify.context = b,
.client = b->c->dm_io,
+ .submit_bio = 1,
};
struct dm_io_region region = {
.bdev = b->c->bdev,
@@ -1200,6 +1201,7 @@ int dm_bufio_issue_flush(struct dm_bufio_client *c)
.mem.type = DM_IO_KMEM,
.mem.ptr.addr = NULL,
.client = c->dm_io,
+ .submit_bio = 1,
};
struct dm_io_region io_reg = {
.bdev = c->bdev,
diff --git a/drivers/md/dm-io.c b/drivers/md/dm-io.c
index ea5dd28..f235182 100644
--- a/drivers/md/dm-io.c
+++ b/drivers/md/dm-io.c
@@ -287,8 +287,8 @@ static void km_dp_init(struct dpages *dp, void *data)
/*-
* IO routines that accept a list of pages.
*---*/
-static void do_region(int rw, unsigned region, struct dm_io_region *where,
- struct dpages *dp, struct io *io)
+static void do_region(struct dm_io_request *io_req, unsigned region,
+ struct dm_io_region *where, struct dpages *dp, struct io *io)
{
struct bio *bio;
struct page *page;
@@ -298,6 +298,7 @@ static void do_region(int rw, unsigned region, struct
dm_io_region *where,
sector_t remaining = where->count;
struct request_queue *q = bdev_get_queue(where->bdev);
sector_t discard_sectors;
+ int rw = io_req->bi_rw;
/*
* where->count may be zero if rw holds a flush and we need to
@@ -339,15 +340,26 @@ static void do_region(int rw, unsigned region, struct
dm_io_region *where,
}
atomic_inc(>count);
- submit_bio(rw, bio);
+ if (io_req->submit_bio)
+ submit_bio(rw, bio);
+ else {
+ bio->bi_rw |= rw;
+ if (io_req->start) {
+ io_req->end->bi_next = bio;
+ io_req->end = bio;
+ } else
+ io_req->start = io_req->end = bio;
+ bio->bi_next = NULL;
+ }
} while (remaining);
}
-static void dispatch_io(int rw, unsigned int num_regions,
+static void dispatch_io(struct dm_io_request *io_req, unsigned int num_regions,
struct dm_io_region *where, struct dpages *dp,
struct io *io, int sync)
{
int i;
+ int rw = io_req->bi_rw;
struct dpages old_pages = *dp;
BUG_ON(num_regions > DM_IO_MAX_REGIONS);
@@ -362,7 +374,7 @@ static void dispatch_io(int rw, unsigned int num_regions,
for (i = 0; i < num_regions; i++) {
*dp = old_pages;
if (where[i].count || (rw & REQ_FLUSH))
- do_region(rw, i, where + i, dp, io);
+ do_region(io_req, i, where + i, dp, io);
}
/*
@@ -372,8 +384,8 @@ static void dispatch_io(int rw, unsigned int num_regions,
dec_count(io, 0, 0);
}
-static int sync_io(struct dm_io_client *client, unsigned int num_regions,
- struct dm_io_region *where, int rw, struct dpages *dp,
+static int sync_io(struct dm_io_request *io_req, unsigned int num_regions,
+ struct dm_io_region *where, struct dpages *dp,
unsigned long *error_bits)
{
/*
@@ -385,7 +397,7 @@ static int sync_io(struct dm_io_client *client, unsigned
int num_regions,
volatile char io_[sizeof(struct io) + __alignof__(struct io) - 1];
struct io *io = (struct io *)PTR_ALIGN(_, __alignof__(struct io));
- if (num_regions > 1 && (rw & RW_MASK) != WRITE) {
+ if (num_regions > 1 && (io_req->bi_rw & RW_MASK) != WRITE) {
WARN_ON(1);
return -EIO;
}
@@ -393,12 +405,12 @@ static int sync_io(struct
[PATCH 1/2] md: add new interface 'mk_rq' in target_type
From: Robin Dong
We are now trying to modify flashcache(https://github.com/facebook/flashcache)
to make it request based so that
we can let cfq io-controller control the bandwidth between different
io cgroups.
A search in the dm directory tells me that only multipath is a request
based dm target and its functionality
is very simple and map_rq() is used to map the request to different underlying
devices.
We can't work in this way because:
1. the request which processed by map_rq() need to be issued to
different lower devices (disk device and cache device, in flashcache),
therefore the request
can't be totally remapped by simply changing its queue and returning
DM_MAPIO_REMAPPED in map_rq() like multipath_map()
2. to submit bios drectly in map_rq() (by return DM_MAPIO_SUBMITTED) will cause
BUG_ON(!irqs_disabled())
in dm_request_fn() because the
submit_bio()->generic_make_request()->blk_queue_bio() will definitly call
spin_unlock_irq to enable the irqs
As above,the interface map_rq() provided by devcie-mapper framework
is not enough for an autonomous target, like flashcache.
We propose to add a new
mk_rq interface so that we can make the requests
by ourselves.
Signed-off-by: Robin Dong
---
drivers/md/dm.c | 10 ++
include/linux/device-mapper.h |3 +++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/drivers/md/dm.c b/drivers/md/dm.c
index 4e09b6f..3ae67de 100644
--- a/drivers/md/dm.c
+++ b/drivers/md/dm.c
@@ -1459,11 +1459,21 @@ static int dm_request_based(struct mapped_device *md)
static void dm_request(struct request_queue *q, struct bio *bio)
{
struct mapped_device *md = q->queuedata;
+ struct dm_table *map = dm_get_live_table(md);
+ struct dm_target *ti = dm_table_find_target(map, bio->bi_sector);
+
+ if (ti->type->mk_rq) {
+ ti->type->mk_rq(ti, q, bio);
+ goto out;
+ }
if (dm_request_based(md))
blk_queue_bio(q, bio);
else
_dm_request(q, bio);
+
+out:
+ dm_table_put(map);
}
void dm_dispatch_request(struct request *rq)
diff --git a/include/linux/device-mapper.h b/include/linux/device-mapper.h
index 38d27a1..2386389 100644
--- a/include/linux/device-mapper.h
+++ b/include/linux/device-mapper.h
@@ -50,6 +50,8 @@ typedef int (*dm_map_fn) (struct dm_target *ti, struct bio
*bio,
union map_info *map_context);
typedef int (*dm_map_request_fn) (struct dm_target *ti, struct request *clone,
union map_info *map_context);
+typedef int (*dm_make_request_fn) (struct dm_target *ti,
+ struct request_queue *q, struct bio *bio);
/*
* Returns:
@@ -136,6 +138,7 @@ struct target_type {
dm_dtr_fn dtr;
dm_map_fn map;
dm_map_request_fn map_rq;
+ dm_make_request_fn mk_rq;
dm_endio_fn end_io;
dm_request_endio_fn rq_end_io;
dm_presuspend_fn presuspend;
--
1.7.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 5/9] genalloc: add a global pool list, allow to find pools by phys address
On Fri, Aug 31, 2012 at 11:27:00AM +0200, Philipp Zabel wrote:
> This patch keeps all created pools in a global list and adds two
> functions that allow to retrieve the gen_pool pointer from a known
> physical address and from a device tree node.
>
> Signed-off-by: Philipp Zabel
> ---
> include/linux/genalloc.h | 14 +
> lib/genalloc.c | 77
> ++
> 2 files changed, 91 insertions(+)
>
> diff --git a/include/linux/genalloc.h b/include/linux/genalloc.h
> index 5e98eeb..46ff435 100644
> --- a/include/linux/genalloc.h
> +++ b/include/linux/genalloc.h
> @@ -33,6 +33,7 @@
> * General purpose special memory pool descriptor.
> */
> struct gen_pool {
> + struct list_head next_pool; /* pool in global list */
> spinlock_t lock;
> struct list_head chunks;/* list of chunks in this pool */
> int min_alloc_order;/* minimum allocation order */
> @@ -78,4 +79,17 @@ extern void gen_pool_for_each_chunk(struct gen_pool *,
> void (*)(struct gen_pool *, struct gen_pool_chunk *, void *), void *);
> extern size_t gen_pool_avail(struct gen_pool *);
> extern size_t gen_pool_size(struct gen_pool *);
> +extern struct gen_pool *gen_pool_find_by_phys(phys_addr_t phys);
> +
> +#ifdef CONFIG_OF
> +struct device_node;
This should be put above/outside #ifdef, as it's used in #else block
as well?
> +extern struct gen_pool *of_get_named_gen_pool(struct device_node *np,
> + const char *propname, int index);
> +#else
> +inline struct gen_pool *of_get_named_gen_pool(struct device_node *np,
> + const char *propname, int index)
> +{
> + return NULL;
> +}
> +#endif
> #endif /* __GENALLOC_H__ */
> diff --git a/lib/genalloc.c b/lib/genalloc.c
> index 6bc04aa..df2d8f9 100644
> --- a/lib/genalloc.c
> +++ b/lib/genalloc.c
> @@ -34,6 +34,11 @@
> #include
> #include
> #include
> +#include
> +#include
> +
> +static LIST_HEAD(pools);
> +static DEFINE_SPINLOCK(list_lock);
>
> static int set_bits_ll(unsigned long *addr, unsigned long mask_to_set)
> {
> @@ -152,6 +157,9 @@ struct gen_pool *gen_pool_create(int min_alloc_order, int
> nid)
> spin_lock_init(>lock);
> INIT_LIST_HEAD(>chunks);
> pool->min_alloc_order = min_alloc_order;
> + spin_lock(_lock);
> + list_add_rcu(>next_pool, );
> + spin_unlock(_lock);
> }
> return pool;
> }
> @@ -234,6 +242,9 @@ void gen_pool_destroy(struct gen_pool *pool)
> int order = pool->min_alloc_order;
> int bit, end_bit;
>
> + spin_lock(_lock);
> + list_del_rcu(>next_pool);
> + spin_unlock(_lock);
> list_for_each_safe(_chunk, _next_chunk, >chunks) {
> chunk = list_entry(_chunk, struct gen_pool_chunk, next_chunk);
> list_del(>next_chunk);
> @@ -400,3 +411,69 @@ size_t gen_pool_size(struct gen_pool *pool)
> return size;
> }
> EXPORT_SYMBOL_GPL(gen_pool_size);
> +
> +/**
> + * gen_pool_find_by_phys - find a pool by physical start address
> + * @phys: physical address as added with gen_pool_add_virt
> + *
> + * Returns the pool that contains the chunk starting at phys,
> + * or NULL if not found.
> + */
> +struct gen_pool *gen_pool_find_by_phys(phys_addr_t phys)
> +{
> + struct gen_pool *pool, *found = NULL;
> + struct gen_pool_chunk *chunk;
> +
> + rcu_read_lock();
> + list_for_each_entry_rcu(pool, , next_pool) {
> + list_for_each_entry_rcu(chunk, >chunks, next_chunk) {
> + if (phys == chunk->phys_addr) {
> + found = pool;
> + break;
> + }
> + }
> + }
> + rcu_read_unlock();
> +
> + return found;
> +}
> +EXPORT_SYMBOL_GPL(gen_pool_find_by_phys);
> +
> +#ifdef CONFIG_OF
> +/**
> + * of_get_named_gen_pool - find a pool by the physical address in
"in" what?
> + * @np: device node
@propname
@index
> + *
> + * Returns the pool that contains the chunk starting at the physical
> + * address of the np device node, or NULL if not found.
> + */
> +struct gen_pool *of_get_named_gen_pool(struct device_node *np,
> + const char *propname, int index)
> +{
> + struct property *prop;
> + const __be32 *list;
> + int size;
> + phandle phandle;
> + struct device_node *np_pool;
> + const u32 *reg;
> + u64 addr;
> +
> + prop = of_find_property(np, propname, );
> + if (!prop)
> + return NULL;
> + list = prop->value;
> + size /= sizeof(*list);
> + phandle = be32_to_cpup(list);
> + np_pool = of_find_node_by_phandle(phandle);
> + if (!np_pool)
> + return NULL;
Helper of_parse_phandle() helps here.
> + reg = of_get_property(np_pool, "reg", NULL);
> + if (!reg)
> + return NULL;
> + addr = of_translate_address(np_pool, reg);
> + if (addr == OF_BAD_ADDR)
> + return NULL;
I
Re: [RFC,PATCH] efi: Add support for a UEFI variable filesystem
Well, appending is an action, not really a property of the variable that sticks around, no? Jeremy Kerr wrote: >hi hpa, > >> Wouldn't that be better handled by O_APPEND? > >Possibly, but this then means that there are now two "interfaces" that >specify the variable attributes. > >[Also, in that case we should support the same mechanism through >open(); >llseek(0, SEEK_END) then, right?] > >In general, I think the attributes-in-a-header mechanism is a little >tidier than providing them in the filename. For instance, finding if a >variable exists from userspace will require iterating the dentries (or >trying all combinations of variables), if the attributes aren't known. > >However, I'm happy to implement this if it's the generally-preferred >solution. > >Cheers, > > >Jeremy -- Sent from my mobile phone. Please excuse brevity and lack of formatting. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v2 0/9] Add device tree support for on-chip SRAM
I do not understand the point of introducing those imx patches, 1 ~ 4
and 7, 8. They are all unnecessary churns to me. IMO, 4 patches are
enough.
* genalloc: add a global pool list, allow to find pools by phys address
* misc: Generic on-chip SRAM allocation driver
* ARM i.MX: remove IRAM_ALLOC facility
* ARM: dts: add sram for imx53 and imx6q
Regards,
Shawn
On Fri, Aug 31, 2012 at 11:26:55AM +0200, Philipp Zabel wrote:
> These patches add support to configure on-chip SRAM via device-tree
> node and to obtain the resulting genalloc pool from a phandle pointing
> at the node.
> This allows drivers to allocate SRAM with the genalloc API without
> hard-coding the genalloc pool address.
>
> The on-chip SRAM on i.MX53 and i.MX6q is registered via device tree and
> changed to use the simple generic SRAM driver:
>
> ocram: ocram@0090 {
> compatible = "fsl,imx-ocram", "sram";
> reg = <0x0090 0x3f000>;
> };
>
> A driver that needs to allocate SRAM buffers, like the video processing
> unit on i.MX53, can retrieve the genalloc pool from a phandle in the
> device tree using of_get_named_gen_pool(node, "iram", 0) from patch 5:
>
> vpu@63ff4000 {
> /* ... */
> iram = <>;
> };
>
> Changes since v1:
> - Added a generic SRAM driver in drivers/misc that does nothing but
>request/ioremap its given memory region and serve it via the genalloc
>API.
> - Renamed the i.MX device tree nodes from "iram" to "ocram".
>
> regards
> Philipp
>
> ---
> arch/arm/boot/dts/imx53.dtsi |5 ++
> arch/arm/boot/dts/imx6q.dtsi |5 ++
> arch/arm/plat-mxc/Kconfig |4 --
> arch/arm/plat-mxc/Makefile|1 -
> arch/arm/plat-mxc/include/mach/iram.h | 41 -
> arch/arm/plat-mxc/iram_alloc.c| 73 ---
> drivers/misc/Kconfig |8 +++
> drivers/misc/Makefile |1 +
> drivers/misc/sram.c | 105
> +
> include/linux/genalloc.h | 14 +
> lib/genalloc.c| 77
> 11 files changed, 215 insertions(+), 119 deletions(-)
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] perf bench: fix assert when NDEBUG is defined
On Mon, 3 Sep 2012 03:04:32 +0300, Irina Tirdea wrote:
> From: Irina Tirdea
>
> When NDEBUG is defined, the assert macro will be expanded to nothing.
> Some assert calls used in perf are also including some functionality
> (e.g. system calls), not only validity checks. Therefore, if NDEBUG is
> defined, these functionality will be removed along with the assert.
>
> The functionality of the program needs to be separated from the assert checks.
> In perf, BUG_ON is also defined on assert, so we need to fix these statements
> too.
>
> Signed-off-by: Irina Tirdea
> ---
> tools/perf/bench/mem-memcpy.c |8 +---
> tools/perf/bench/mem-memset.c |8 +---
> tools/perf/bench/sched-pipe.c |6 --
> 3 files changed, 14 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c
> index 02dad5d..bccb783 100644
> --- a/tools/perf/bench/mem-memcpy.c
> +++ b/tools/perf/bench/mem-memcpy.c
> @@ -144,17 +144,19 @@ static double do_memcpy_gettimeofday(memcpy_t
> fn, size_t len, bool prefault)
> {
> struct timeval tv_start, tv_end, tv_diff;
> void *src = NULL, *dst = NULL;
> - int i;
> + int i, ret;
>
> alloc_mem(, , len);
>
> if (prefault)
> fn(dst, src, len);
>
> - BUG_ON(gettimeofday(_start, NULL));
> + ret = gettimeofday(_start, NULL);
> + BUG_ON(ret);
I think one of good thing of assert is that it outputs the exact failure
condition when it fails. So with patch, it will convert
Assertion `gettimeofday(_start, NULL)' failed.
into
Assertion `ret' failed.
which is not so informative.
So I'd rather suggest using more descriptive names like ret_gtod ?
> for (i = 0; i < iterations; ++i)
> fn(dst, src, len);
> - BUG_ON(gettimeofday(_end, NULL));
> + ret = gettimeofday(_end, NULL);
> + BUG_ON(ret);
>
> timersub(_end, _start, _diff);
>
> diff --git a/tools/perf/bench/mem-memset.c b/tools/perf/bench/mem-memset.c
> index 350cc95..e0702d2 100644
> --- a/tools/perf/bench/mem-memset.c
> +++ b/tools/perf/bench/mem-memset.c
> @@ -139,17 +139,19 @@ static double do_memset_gettimeofday(memset_t
> fn, size_t len, bool prefault)
> {
> struct timeval tv_start, tv_end, tv_diff;
> void *dst = NULL;
> - int i;
> + int i, ret;
>
> alloc_mem(, len);
>
> if (prefault)
> fn(dst, -1, len);
>
> - BUG_ON(gettimeofday(_start, NULL));
> + ret = gettimeofday(_start, NULL);
> + BUG_ON(ret);
> for (i = 0; i < iterations; ++i)
> fn(dst, i, len);
> - BUG_ON(gettimeofday(_end, NULL));
> + ret = gettimeofday(_end, NULL);
> + BUG_ON(ret);
Ditto.
>
> timersub(_end, _start, _diff);
>
> diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
> index 0c7454f..b35c94b 100644
> --- a/tools/perf/bench/sched-pipe.c
> +++ b/tools/perf/bench/sched-pipe.c
> @@ -61,8 +61,10 @@ int bench_sched_pipe(int argc, const char **argv,
> argc = parse_options(argc, argv, options,
>bench_sched_pipe_usage, 0);
>
> - assert(!pipe(pipe_1));
> - assert(!pipe(pipe_2));
> + ret = pipe(pipe_1);
> + assert(!ret);
> + ret = !pipe(pipe_2);
> + assert(!ret);
What about converting these raw assert's to BUG_ONs (with negating the
conditions) for consistency?
Thanks,
Namhyung
>
> pid = fork();
> assert(pid >= 0);
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH v7 1/1] ieee802154: MRF24J40 driver
Driver for the Microchip MRF24J40 802.15.4 WPAN module.
Signed-off-by: Alan Ott
---
drivers/net/ieee802154/Kconfig| 11 +
drivers/net/ieee802154/Makefile | 1 +
drivers/net/ieee802154/mrf24j40.c | 767 ++
3 files changed, 779 insertions(+)
create mode 100644 drivers/net/ieee802154/mrf24j40.c
diff --git a/drivers/net/ieee802154/Kconfig b/drivers/net/ieee802154/Kconfig
index 1fc4eef..08ae465 100644
--- a/drivers/net/ieee802154/Kconfig
+++ b/drivers/net/ieee802154/Kconfig
@@ -34,3 +34,14 @@ config IEEE802154_AT86RF230
depends on IEEE802154_DRIVERS && MAC802154
tristate "AT86RF230/231 transceiver driver"
depends on SPI
+
+config IEEE802154_MRF24J40
+ tristate "Microchip MRF24J40 transceiver driver"
+ depends on IEEE802154_DRIVERS && MAC802154
+ depends on SPI
+ ---help---
+ Say Y here to enable the MRF24J20 SPI 802.15.4 wireless
+ controller.
+
+ This driver can also be built as a module. To do so, say M here.
+ the module will be called 'mrf24j40'.
diff --git a/drivers/net/ieee802154/Makefile b/drivers/net/ieee802154/Makefile
index 4f4371d..abb0c08 100644
--- a/drivers/net/ieee802154/Makefile
+++ b/drivers/net/ieee802154/Makefile
@@ -1,3 +1,4 @@
obj-$(CONFIG_IEEE802154_FAKEHARD) += fakehard.o
obj-$(CONFIG_IEEE802154_FAKELB) += fakelb.o
obj-$(CONFIG_IEEE802154_AT86RF230) += at86rf230.o
+obj-$(CONFIG_IEEE802154_MRF24J40) += mrf24j40.o
diff --git a/drivers/net/ieee802154/mrf24j40.c
b/drivers/net/ieee802154/mrf24j40.c
new file mode 100644
index 000..0e53d4f
--- /dev/null
+++ b/drivers/net/ieee802154/mrf24j40.c
@@ -0,0 +1,767 @@
+/*
+ * Driver for Microchip MRF24J40 802.15.4 Wireless-PAN Networking controller
+ *
+ * Copyright (C) 2012 Alan Ott
+ *Signal 11 Software
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
+ */
+
+#include
+#include
+#include
+#include
+#include
+
+/* MRF24J40 Short Address Registers */
+#define REG_RXMCR0x00 /* Receive MAC control */
+#define REG_PANIDL 0x01 /* PAN ID (low) */
+#define REG_PANIDH 0x02 /* PAN ID (high) */
+#define REG_SADRL0x03 /* Short address (low) */
+#define REG_SADRH0x04 /* Short address (high) */
+#define REG_EADR00x05 /* Long address (low) (high is EADR7) */
+#define REG_TXMCR0x11 /* Transmit MAC control */
+#define REG_PACON0 0x16 /* Power Amplifier Control */
+#define REG_PACON1 0x17 /* Power Amplifier Control */
+#define REG_PACON2 0x18 /* Power Amplifier Control */
+#define REG_TXNCON 0x1B /* Transmit Normal FIFO Control */
+#define REG_TXSTAT 0x24 /* TX MAC Status Register */
+#define REG_SOFTRST 0x2A /* Soft Reset */
+#define REG_TXSTBL 0x2E /* TX Stabilization */
+#define REG_INTSTAT 0x31 /* Interrupt Status */
+#define REG_INTCON 0x32 /* Interrupt Control */
+#define REG_RFCTL0x36 /* RF Control Mode Register */
+#define REG_BBREG1 0x39 /* Baseband Registers */
+#define REG_BBREG2 0x3A /* */
+#define REG_BBREG6 0x3E /* */
+#define REG_CCAEDTH 0x3F /* Energy Detection Threshold */
+
+/* MRF24J40 Long Address Registers */
+#define REG_RFCON0 0x200 /* RF Control Registers */
+#define REG_RFCON1 0x201
+#define REG_RFCON2 0x202
+#define REG_RFCON3 0x203
+#define REG_RFCON5 0x205
+#define REG_RFCON6 0x206
+#define REG_RFCON7 0x207
+#define REG_RFCON8 0x208
+#define REG_RSSI 0x210
+#define REG_SLPCON00x211 /* Sleep Clock Control Registers */
+#define REG_SLPCON10x220
+#define REG_WAKETIMEL 0x222 /* Wake-up Time Match Value Low */
+#define REG_WAKETIMEH 0x223 /* Wake-up Time Match Value High */
+#define REG_RX_FIFO0x300 /* Receive FIFO */
+
+/* Device configuration: Only channels 11-26 on page 0 are supported. */
+#define MRF24J40_CHAN_MIN 11
+#define MRF24J40_CHAN_MAX 26
+#define CHANNEL_MASK (((u32)1 << (MRF24J40_CHAN_MAX + 1)) \
+ - ((u32)1 << MRF24J40_CHAN_MIN))
+
+#define TX_FIFO_SIZE 128 /* From datasheet */
+#define RX_FIFO_SIZE 144 /* From datasheet */
+#define SET_CHANNEL_DELAY_US 192 /* From datasheet */
+
+/* Device Private Data */
+struct mrf24j40 {
+ struct spi_device *spi;
+ struct ieee802154_dev *dev;
+
+ struct mutex buffer_mutex; /* only used to protect buf */
+
[PATCH v7 0/1] Driver for Microchip MRF24J40
This is a driver for the Microchip MRF24J40 802.15.4 transceiver. This is the same as v6 except that it now puts the driver in drivers/net/ieee802154 instead of drivers/ieee802154, since drivers/ieee802154 was recently moved to drivers/net/ieee802154 in 0739d643b8dda866d1011bcf Full history and discussion can be found on the archives of the linux-zigbee mailing list: http://www.mail-archive.com/linux-zigbee-devel@lists.sourceforge.net/msg01014.html Alan Ott (1): ieee802154: MRF24J40 driver drivers/net/ieee802154/Kconfig| 11 + drivers/net/ieee802154/Makefile | 1 + drivers/net/ieee802154/mrf24j40.c | 767 ++ 3 files changed, 779 insertions(+) create mode 100644 drivers/net/ieee802154/mrf24j40.c -- 1.7.11.2 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC,PATCH] efi: Add support for a UEFI variable filesystem
hi hpa, > Wouldn't that be better handled by O_APPEND? Possibly, but this then means that there are now two "interfaces" that specify the variable attributes. [Also, in that case we should support the same mechanism through open(); llseek(0, SEEK_END) then, right?] In general, I think the attributes-in-a-header mechanism is a little tidier than providing them in the filename. For instance, finding if a variable exists from userspace will require iterating the dentries (or trying all combinations of variables), if the attributes aren't known. However, I'm happy to implement this if it's the generally-preferred solution. Cheers, Jeremy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH v2] block: Avoid deadlocks with bio allocation by stacking drivers
On Fri, Aug 31, 2012 at 07:13:48PM -0700, Tejun Heo wrote:
> Hello, Vivek.
>
> On Thu, Aug 30, 2012 at 06:07:45PM -0400, Vivek Goyal wrote:
> > Here is one quick and dirty proof of concept patch. It checks for stack
> > depth and if remaining space is less than 20% of stack size, then it
> > defers the bio submission to per queue worker.
>
> So, it removes breadth-first walking of bio construction by ensuring
> stack overflow never happens by bouncing to workqueue if stack usage
> seems too high.
>
> I do like removal of breadth-first walking. It makes failure
> scenarios a lot less mind-bending. That said, Kent is right that this
> can incur significant overhead for certain configurations, and looking
> at stack usage in block layer is rather nasty both in design and
> implementation.
>
> If we're gonna need rescuer anyway and can get it right and the
> mechanism can be contained in block proper relatively well, I think it
> would be better to make bread-first walking safe. Both are nasty in
> their own ways after all.
I added that filtering I was talking about, and I like this version much
better.
To me at least, it's much clearer what it's actually doing; when we go
sleep in an allocation, we first unblock only the bios that were
allocated from this bio_set - i.e. only the bios that caused the
original deadlock.
It's still trickier than Vivek's approach but the performance impact
certainly lowers, since we're only using the workqueue thread on
allocation failure.
commit c61f9c16dc8c7ae833a73b857936106c71daab3f
Author: Kent Overstreet
Date: Fri Aug 31 20:52:41 2012 -0700
block: Avoid deadlocks with bio allocation by stacking drivers
Previously, if we ever try to allocate more than once from the same bio
set while running under generic_make_request() (i.e. a stacking block
driver), we risk deadlock.
This is because of the code in generic_make_request() that converts
recursion to iteration; any bios we submit won't actually be submitted
(so they can complete and eventually be freed) until after we return -
this means if we allocate a second bio, we're blocking the first one
from ever being freed.
Thus if enough threads call into a stacking block driver at the same
time with bios that need multiple splits, and the bio_set's reserve gets
used up, we deadlock.
This can be worked around in the driver code - we could check if we're
running under generic_make_request(), then mask out __GFP_WAIT when we
go to allocate a bio, and if the allocation fails punt to workqueue and
retry the allocation.
But this is tricky and not a generic solution. This patch solves it for
all users by inverting the previously described technique. We allocate a
rescuer workqueue for each bio_set, and then in the allocation code if
there are bios on current->bio_list we would be blocking, we punt them
to the rescuer workqueue to be submitted.
Tested it by forcing the rescue codepath to be taken (by disabling the
first GFP_NOWAIT) attempt, and then ran it with bcache (which does a lot
of arbitrary bio splitting) and verified that the rescuer was being
invoked.
Signed-off-by: Kent Overstreet
CC: Jens Axboe
diff --git a/fs/bio.c b/fs/bio.c
index 22d654f..076751f 100644
--- a/fs/bio.c
+++ b/fs/bio.c
@@ -286,6 +286,43 @@ void bio_reset(struct bio *bio)
}
EXPORT_SYMBOL(bio_reset);
+static void bio_alloc_rescue(struct work_struct *work)
+{
+ struct bio_set *bs = container_of(work, struct bio_set, rescue_work);
+ struct bio *bio;
+
+ while (1) {
+ spin_lock(>rescue_lock);
+ bio = bio_list_pop(>rescue_list);
+ spin_unlock(>rescue_lock);
+
+ if (!bio)
+ break;
+
+ generic_make_request(bio);
+ }
+}
+
+static void punt_bios_to_rescuer(struct bio_set *bs)
+{
+ struct bio_list punt, nopunt;
+ struct bio *bio;
+
+ bio_list_init();
+ bio_list_init();
+
+ while ((bio = bio_list_pop(current->bio_list)))
+ bio_list_add(bio->bi_pool == bs ? : , bio);
+
+ *current->bio_list = nopunt;
+
+ spin_lock(>rescue_lock);
+ bio_list_merge(>rescue_list, );
+ spin_unlock(>rescue_lock);
+
+ queue_work(bs->rescue_workqueue, >rescue_work);
+}
+
/**
* bio_alloc_bioset - allocate a bio for I/O
* @gfp_mask: the GFP_ mask given to the slab allocator
@@ -308,6 +345,7 @@ EXPORT_SYMBOL(bio_reset);
*/
struct bio *bio_alloc_bioset(gfp_t gfp_mask, int nr_iovecs, struct bio_set *bs)
{
+ gfp_t saved_gfp = gfp_mask;
unsigned front_pad;
unsigned inline_vecs;
unsigned long idx = BIO_POOL_NONE;
@@ -325,13 +363,37 @@ struct bio *bio_alloc_bioset(gfp_t gfp_mask, int
nr_iovecs, struct bio_set *bs)
front_pad = 0;
inline_vecs = nr_iovecs;
} else {
+
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Fri, Aug 31, 2012 at 11:01:59AM -0400, Vivek Goyal wrote: > On Thu, Aug 30, 2012 at 06:43:59PM -0700, Kent Overstreet wrote: > > On Thu, Aug 30, 2012 at 06:07:45PM -0400, Vivek Goyal wrote: > > > On Wed, Aug 29, 2012 at 10:13:45AM -0700, Kent Overstreet wrote: > > > > > > [..] > > > > > Performance aside, punting submission to per device worker in case of > > > > > deep > > > > > stack usage sounds cleaner solution to me. > > > > > > > > Agreed, but performance tends to matter in the real world. And either > > > > way the tricky bits are going to be confined to a few functions, so I > > > > don't think it matters that much. > > > > > > > > If someone wants to code up the workqueue version and test it, they're > > > > more than welcome... > > > > > > Here is one quick and dirty proof of concept patch. It checks for stack > > > depth and if remaining space is less than 20% of stack size, then it > > > defers the bio submission to per queue worker. > > > > I can't think of any correctness issues. I see some stuff that could be > > simplified (blk_drain_deferred_bios() is redundant, just make it a > > wrapper around blk_deffered_bio_work()). > > > > Still skeptical about the performance impact, though - frankly, on some > > of the hardware I've been running bcache on this would be a visible > > performance regression - probably double digit percentages but I'd have > > to benchmark it. That kind of of hardware/usage is not normal today, > > but I've put a lot of work into performance and I don't want to make > > things worse without good reason. > > Would you like to give this patch a quick try and see with bcache on your > hardware how much performance impact do you see. If I can get a test system I can publish numbers setup with a modern kernel, on I will. Will take a bit though. > Given the fact that submission through worker happens only in case of > when stack usage is high, that should reduce the impact of the patch > and common use cases should reamin unaffected. Except depending on how users have their systems configured, it'll either never happen or it'll happen for most every bio. That makes the performance overhead unpredictable, too. > > > > Have you tested/benchmarked it? > > No, I have not. I will run some simple workloads on SSD. Normal SATA ssds are not going to show the overhead - achi is a pig and it'll be lost in the noise. > There are so many places in kernel where worker threads do work on behalf > of each process. I think this is really a minor concern and I would not > be too worried about it. Yeah, but this is somewhat unprecedented in the amount of cpu time you're potentially moving to worker threads. It is a concern. > What is concerning though really is the greater stack usage due to > recursive nature of make_request() and performance impact of deferral > to a worker thread. Your patch shouldn't increase stack usage (at least if your threshold is safe - it's too high as is). -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC v8 PATCH 04/20] memory-hotplug: offline and remove memory when removing the memory device
At 09/01/2012 04:55 AM, Andrew Morton Wrote:
> On Tue, 28 Aug 2012 18:00:11 +0800
> we...@cn.fujitsu.com wrote:
>
>> +int remove_memory(int nid, u64 start, u64 size)
>> +{
>> +int ret = -EBUSY;
>> +lock_memory_hotplug();
>> +/*
>> + * The memory might become online by other task, even if you offine it.
>> + * So we check whether the cpu has been onlined or not.
>
> I think you meant "memory", not "cpu".
Yes. I will fix it.
Thanks
Wen Congyang
>
> Actually, "check whether any part of this memory range has been
> onlined" would be better. If that is accurate ;)
>
>> + */
>> +if (!is_memblk_offline(start, size)) {
>> +pr_warn("memory removing [mem %#010llx-%#010llx] failed, "
>> +"because the memmory range is online\n",
>> +start, start + size);
>> +ret = -EAGAIN;
>> +}
>> +
>> +unlock_memory_hotplug();
>> +return ret;
>> +
>> +}
>> +EXPORT_SYMBOL_GPL(remove_memory);
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Mon, Sep 03, 2012 at 10:49:27AM +1000, Dave Chinner wrote: > Given that we are working around stack depth issues in the > filesystems already in several places, and now it seems like there's > a reason to work around it in the block layers as well, shouldn't we > simply increase the default stack size rather than introduce > complexity and performance regressions to try and work around not > having enough stack? > > I mean, we can deal with it like the ia32 4k stack issue was dealt > with (i.e. ignore those stupid XFS people, that's an XFS bug), or > we can face the reality that storage stacks have become so complex > that 8k is no longer a big enough stack for a modern system I'm not arguing against increasing the default stack size (I really don't have an opinion there) - but it's not a solution for the block layer, as stacking block devices can require an unbounded amount of stack without the generic_make_request() convert recursion-to-iteration thing. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 11/13] perf tools: replace mempcpy with memcpy
On Wed, 29 Aug 2012 01:22:16 +0300, Irina Tirdea wrote:
> mempcpy is not supported by bionic in Android
> and will lead to compilation errors.
>
> Replacing mempcpy with memcpy so it will work in Android.
Unfortunately I've added another instance of the mempcpy in a
libtraceevent code. :-/
Thanks,
Namhyung
>
> Signed-off-by: Irina Tirdea
> ---
> tools/perf/util/target.c |4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/tools/perf/util/target.c b/tools/perf/util/target.c
> index 051eaa6..065528b 100644
> --- a/tools/perf/util/target.c
> +++ b/tools/perf/util/target.c
> @@ -117,8 +117,8 @@ int perf_target__strerror(struct perf_target
> *target, int errnum,
>
> if (err != buf) {
> size_t len = strlen(err);
> - char *c = mempcpy(buf, err, min(buflen - 1, len));
> - *c = '\0';
> + memcpy(buf, err, min(buflen - 1, len));
> + *(buf + min(buflen - 1, len)) = '\0';
> }
>
> return 0;
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 08/13] perf tools: Use __maybe_used for unused variables
Hi, On Wed, 29 Aug 2012 01:04:25 +0300, Irina Tirdea wrote: > perf defines __used to for marking unused variables. > The variable __used is defined to __attribute__((__unused__)), which > contradicts the kernel definition to __attribute__((__used__)) > for new gcc versions. On Android), __used is also defined in > system headers and this leads to warnings like: > warning: '__used__' attribute ignored > > This patch simply replaces all instances of __used with __maybe_unused > so there will be no such warnings. How about just using '__unused' for less typing? Btw, the patch looks whitespace-damaged. Thanks, Namhyung -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH v7 9/9] block: Avoid deadlocks with bio allocation by stacking drivers
On Thu, Aug 30, 2012 at 06:07:45PM -0400, Vivek Goyal wrote: > On Wed, Aug 29, 2012 at 10:13:45AM -0700, Kent Overstreet wrote: > > [..] > > > Performance aside, punting submission to per device worker in case of deep > > > stack usage sounds cleaner solution to me. > > > > Agreed, but performance tends to matter in the real world. And either > > way the tricky bits are going to be confined to a few functions, so I > > don't think it matters that much. > > > > If someone wants to code up the workqueue version and test it, they're > > more than welcome... > > Here is one quick and dirty proof of concept patch. It checks for stack > depth and if remaining space is less than 20% of stack size, then it > defers the bio submission to per queue worker. Given that we are working around stack depth issues in the filesystems already in several places, and now it seems like there's a reason to work around it in the block layers as well, shouldn't we simply increase the default stack size rather than introduce complexity and performance regressions to try and work around not having enough stack? I mean, we can deal with it like the ia32 4k stack issue was dealt with (i.e. ignore those stupid XFS people, that's an XFS bug), or we can face the reality that storage stacks have become so complex that 8k is no longer a big enough stack for a modern system Cheers, Dave. -- Dave Chinner da...@fromorbit.com -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCHv2] tty: Added a CONFIG_TTY option to allow removal of TTY
The option allows you to remove TTY and compile without errors. This saves space on systems that won't support TTY interfaces anyway. bloat-o-meter output is below. The bulk of this patch consists of Kconfig changes adding "depends on TTY" to various serial devices and similar drivers that require the TTY layer. Ideally, these dependencies would occur on a common intermediate symbol such as SERIO, but most drivers "select SERIO" rather than "depends on SERIO", and "select" does not respect dependencies. bloat-o-meter output filtered to not show removed entries with awk '$3 != "-"' as the list was very long. add/remove: 0/385 grow/shrink: 2/18 up/down: 14/-54016 (-54002) function old new delta chr_dev_init 193 205 +12 selinux_setprocattr 11671169 +2 static.__warned 557 556 -1 start_kernel 840 835 -5 proc_root_init 167 162 -5 unregister_console 165 157 -8 sys_setsid 213 205 -8 sys_vhangup 37 21 -16 daemonize689 673 -16 t_stop72 54 -18 t_next 129 108 -21 static.do_acct_process 838 806 -32 release_task11571125 -32 do_exit 23252288 -37 t_start 269 221 -48 static.__func__18289 18219 -70 do_task_stat29622892 -70 flush_unauthorized_files 740 614-126 static._rs 14401280-160 static.__key85608384-176 Signed-off-by: Joe Millenbach Reviewed-by: Josh Triplett --- v2: Incorporated feedback from Alan Cox: used "if TTY ... endif" to wrap long runs of symbols that all need "depends on TTY"; grouped all the stubbed-out functions together in linux/tty.h. arch/tile/Kconfig |1 + drivers/bluetooth/Kconfig |1 + drivers/char/Kconfig|7 +++--- drivers/char/pcmcia/Kconfig |4 ++-- drivers/i2c/busses/Kconfig |2 +- drivers/input/joystick/Kconfig |4 drivers/input/keyboard/Kconfig | 10 +++- drivers/input/mouse/Kconfig |3 +++ drivers/input/serio/Kconfig |1 + drivers/input/touchscreen/Kconfig | 24 ++- drivers/isdn/Kconfig|1 + drivers/isdn/capi/Kconfig |1 + drivers/isdn/gigaset/Kconfig|1 + drivers/isdn/hardware/mISDN/Kconfig |1 + drivers/lguest/Kconfig |2 +- drivers/media/radio/wl128x/Kconfig |2 +- drivers/misc/Kconfig|2 +- drivers/misc/ti-st/Kconfig |2 +- drivers/mmc/card/Kconfig|1 + drivers/net/caif/Kconfig|2 +- drivers/net/can/Kconfig |2 +- drivers/net/hamradio/Kconfig|4 ++-- drivers/net/irda/Kconfig|2 +- drivers/net/ppp/Kconfig |3 +++ drivers/net/slip/Kconfig|1 + drivers/net/usb/Kconfig |4 ++-- drivers/net/wan/Kconfig |2 +- drivers/pps/clients/Kconfig |2 +- drivers/tty/Kconfig | 13 +++ drivers/tty/Makefile|2 +- drivers/tty/hvc/Kconfig |3 +++ drivers/tty/serial/Kconfig |4 drivers/usb/class/Kconfig |2 +- drivers/usb/serial/Kconfig |2 +- fs/proc/Makefile|4 ++-- include/linux/console.h |5 include/linux/proc_fs.h |5 include/linux/tty.h | 44 ++- lib/Kconfig.kgdb|1 + net/bluetooth/rfcomm/Kconfig|1 + net/irda/ircomm/Kconfig |2 +- sound/soc/codecs/Kconfig|3 ++- 42 files changed, 144 insertions(+), 39 deletions(-) diff --git a/arch/tile/Kconfig b/arch/tile/Kconfig index 11270ca..44620cd 100644 --- a/arch/tile/Kconfig +++ b/arch/tile/Kconfig @@ -102,6 +102,7 @@ config DEBUG_COPY_FROM_USER def_bool n config HVC_TILE + depends on TTY select HVC_DRIVER def_bool y diff --git a/drivers/bluetooth/Kconfig b/drivers/bluetooth/Kconfig index 5ccf142..fb7acc2 100644 --- a/drivers/bluetooth/Kconfig +++ b/drivers/bluetooth/Kconfig @@ -26,6 +26,7 @@ config BT_HCIBTSDIO config BT_HCIUART tristate "HCI UART driver" + depends on TTY help
Re: [PATCH 3/3] HWPOISON: prevent inode cache removal to keep AS_HWPOISON sticky
On Wed, Aug 29, 2012 at 02:32:04PM +0900, Jun'ichi Nomura wrote: > On 08/29/12 11:59, Dave Chinner wrote: > > On Mon, Aug 27, 2012 at 06:05:06PM -0400, Naoya Horiguchi wrote: > >> And yes, I understand it's ideal, but many applications choose not to > >> do that for performance reason. > >> So I think it's helpful if we can surely report to such applications. > > I suspect "performance vs. integrity" is not a correct > description of the problem. Right, to be more precise, it's a "eat my data" vs "integrity" problem. And in almost all cases I've seen over the years, "eat my data" is done for performance reasons... > > If performance is chosen over data integrity, we are under no > > obligation to keep the error around indefinitely. Fundamentally, > > ensuring a write completes successfully is the reponsibility of the > > application, not the kernel. There are so many different filesytem > > and storage errors that can be lost right now because data is not > > fsync()d, adding another one to them really doesn't change anything. > > IOWs, a memory error is no different to a disk failing or the system > > crashing when it comes to data integrity. If you care, you use > > fsync(). > > I agree that applications should fsync() or O_SYNC > when it wants to make sure the written data in on disk. > > AFAIU, what Naoya is going to address is the case where > fsync() is not necessarily needed. > > For example, if someone do: > $ patch -p1 < ../a.patch > $ tar cf . > ../a.tar > > and disk failure occurred between "patch" and "tar", > "tar" will either see uptodate data or I/O error. No, it won't. The only place AS_EIO is tested is in filemap_fdatawait_range(), which is only called in the fsync() path. The only way to report async write IO errors is to use fsync() - subsequent reads of the file do *not* see the write error. IOWs, tar will be oblivious of any IO error that preceeded it reading the files it is copying. > OTOH, if the failure was detected on dirty pagecache, the current memory > failure handler invalidates the dirty page and the "tar" command will > re-read old contents from disk without error. After an IO error, the dirty page is no longer uptodate - that gets cleared - so when the page is read the data will be re-read from disk just like if a memory error occurred. So tar will behave the same regardless of whether it is a memory error or an IO error (i.e. reread old data from disk) > (Well, the failures above are permanent failures. Write IO errors can also be transient or permanent. Transient, for example, when a path failure occurs and multipathing then detects this and fails over to a good path. A subsequent write will then succeed. Permanent, for example, when someone unplugs a USB drive. > IOW, the current > memory failure handler turns permanent failure into transient error, > which is often more difficult to handle, I think.) The patch I commented on is turning a transient error (error in a page that is then poisoned and never used again) into a permanent error (error on an address space that is reported on every future operation that tries to insert a page into the page cache). > Naoya's patch will keep the failure information and allows the reader > to get I/O error when it reads from broken pagecache. It only adds a hwposion check in add_to_page_cache_locked(). If the page is already in the cache, then no error will be sent to the reader because it never gets to add_to_page_cache_locked(). So there's no guarantee that the reader is even going to see the error, or that they see the error on the page that actually caused it - access to any missing page in the page cache will trigger it. And as memory reclaim clears pages off the inode, more and more of the range of the inode's data will return an error, even though there is nothing wrong with the data in most of the file. Indeed, what happens if the application calls fsync, gets the error and tries to rewrite the page? i.e. it does everything correctly to handle the write error? With this patch set, the application cannot insert a replacement page into the page cache, so all subsequent writes fail! IOWs, it makes it impossible for applications to recover from a detected and handled memory failure. I have no issue with reporting the problem to userspace - that needs t am I saying that the current IO reporting is wonderful and can't be improved. What I am saying, though, is that I really don't think this patch set has been well thought through from either an IO path or userspace error handling point of view. The problems with this patch set are quite significant: - permanent, unclearable error except by complete removal of all data on the file. (forcing the removal of all good data to recover from a transient error on a small amount of data). - while the error is present, bad data cannot be overwritten (applications cannot recover even if they catch the
[PATCHv2] x86: Removing invalid reference to Intel CPUs in CONFIG_SWIOTLB
Deleted the no longer valid example of which x86 CPUs lack a hardware IOMMU, and moved the "If unsure..." statement to a new line to follow the style of surrounding options. Signed-off-by: Joe Millenbach Reviewed-by: Josh Triplett --- v2: Incorporated feedback from Konrad Rzeszutek Wilk that no mention of Intel CPUs was needed. arch/x86/Kconfig |8 1 file changed, 4 insertions(+), 4 deletions(-) diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig index 5bed94e..c5b08e3 100644 --- a/arch/x86/Kconfig +++ b/arch/x86/Kconfig @@ -755,10 +755,10 @@ config SWIOTLB def_bool y if X86_64 ---help--- Support for software bounce buffers used on x86-64 systems - which don't have a hardware IOMMU (e.g. the current generation - of Intel's x86-64 CPUs). Using this PCI devices which can only - access 32-bits of memory can be used on systems with more than - 3 GB of memory. If unsure, say Y. + which don't have a hardware IOMMU. Using this PCI devices + which can only access 32-bits of memory can be used on systems + with more than 3 GB of memory. + If unsure, say Y. config IOMMU_HELPER def_bool (CALGARY_IOMMU || GART_IOMMU || SWIOTLB || AMD_IOMMU) -- 1.7.9.5 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 4/5] platform: x86: remove acpi_bus_generate_proc_event
On Mon, Sep 03, 2012 at 02:03:31AM +0200, Davidlohr Bueso wrote:
> Calling this function no longer makes sense as /proc/acpi/event
> is being removed.
>
> Signed-off-by: Davidlohr Bueso
> :
> drivers/platform/x86/fujitsu-laptop.c |4
> :
> diff --git a/drivers/platform/x86/fujitsu-laptop.c
> b/drivers/platform/x86/fujitsu-laptop.c
> index c4c1a54..2fac1c5 100644
> --- a/drivers/platform/x86/fujitsu-laptop.c
> +++ b/drivers/platform/x86/fujitsu-laptop.c
> @@ -773,8 +773,6 @@ static void acpi_fujitsu_notify(struct acpi_device
> *device, u32 event)
> else
> set_lcd_level(newb);
> }
> - acpi_bus_generate_proc_event(fujitsu->dev,
> - ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS, 0);
> keycode = KEY_BRIGHTNESSUP;
> } else if (oldb > newb) {
> if (disable_brightness_adjust != 1) {
> @@ -783,8 +781,6 @@ static void acpi_fujitsu_notify(struct acpi_device
> *device, u32 event)
> else
> set_lcd_level(newb);
> }
> - acpi_bus_generate_proc_event(fujitsu->dev,
> - ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS, 0);
> keycode = KEY_BRIGHTNESSDOWN;
> }
> break;
Presumedly the intention here is for these events to be delivered via the
input layer after the removal of /proc/acpi/event (as is done later in the
above function).
If that's the case, then:
Acked-by: Jonathan Woithe
Regards
jonathan
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: input0: bad kobj_uevent_env content in show_uevent()
On Mon, Sep 03, 2012 at 12:38:31AM +0800, Fengguang Wu wrote:
> On Sun, Sep 02, 2012 at 03:41:34PM +0200, Bjørn Mork wrote:
> > Fengguang Wu writes:
> >
> > > After the __devinit* removal series, I can still get kernel panic in
> > > show_uevent(). So there are more sources of bug..
> > >
> > > Debug patch:
> > >
> > > @@ -343,8 +343,11 @@ static ssize_t show_uevent(struct device
> > > goto out;
> > >
> > > /* copy keys to file */
> > > - for (i = 0; i < env->envp_idx; i++)
> > > + dev_err(dev, "uevent %d env[%d]: %s/.../%s\n", env->buflen,
> > > env->envp_idx, top_kobj->name, dev->kobj.name);
> > > + for (i = 0; i < env->envp_idx; i++) {
> > > + printk(KERN_ERR "uevent %d env[%d]: %s\n", (int)count, i,
> > > env->envp[i]);
> > > count += sprintf([count], "%s\n", env->envp[i]);
> > > + }
> > >
> > > Oops message, the env[] is again not properly initilized:
> > >
> > > [ 44.068623] input input0: uevent 61 env[805306368]: input0/.../input0
> > > [ 44.069552] uevent 0 env[0]: (null)
> >
> > This is a completely different CONFIG_HOTPLUG problem, only
> > demonstrating another reason why CONFIG_HOTPLUG should go away. I had a
> > hard time trying to disable it anyway ;-)
> >
> > The problem this time is lots of code assuming that a call to
> > add_uevent_var() will guarantee that env->buflen > 0. This is not true
> > if CONFIG_HOTPLUG is unset. So things like this end up overwriting
> > env->envp_idx because the array index is -1:
> >
> > if (add_uevent_var(env, "MODALIAS="))
> > return -ENOMEM;
> > len = input_print_modalias(>buf[env->buflen - 1],
> >sizeof(env->buf) - env->buflen,
> >dev, 0);
> >
> >
> > Don't know what the best action is, given that there seem to be a *lot*
> > of this around the kernel. This patch "fixes" the problem for me, but I
>
> It also works reliably for me: 300 boots without a single failure.
>
> Tested-by: Fengguang Wu
Thanks for figuring this out. I'll apply it for 3.6, but work to get
rid of CONFIG_HOTPLUG completly for 3.7 as it just causes problems.
greg k-h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] perf bench: fix assert when NDEBUG is defined
From: Irina Tirdea
When NDEBUG is defined, the assert macro will be expanded to nothing.
Some assert calls used in perf are also including some functionality
(e.g. system calls), not only validity checks. Therefore, if NDEBUG is
defined, these functionality will be removed along with the assert.
The functionality of the program needs to be separated from the assert checks.
In perf, BUG_ON is also defined on assert, so we need to fix these statements
too.
Signed-off-by: Irina Tirdea
---
tools/perf/bench/mem-memcpy.c |8 +---
tools/perf/bench/mem-memset.c |8 +---
tools/perf/bench/sched-pipe.c |6 --
3 files changed, 14 insertions(+), 8 deletions(-)
diff --git a/tools/perf/bench/mem-memcpy.c b/tools/perf/bench/mem-memcpy.c
index 02dad5d..bccb783 100644
--- a/tools/perf/bench/mem-memcpy.c
+++ b/tools/perf/bench/mem-memcpy.c
@@ -144,17 +144,19 @@ static double do_memcpy_gettimeofday(memcpy_t
fn, size_t len, bool prefault)
{
struct timeval tv_start, tv_end, tv_diff;
void *src = NULL, *dst = NULL;
- int i;
+ int i, ret;
alloc_mem(, , len);
if (prefault)
fn(dst, src, len);
- BUG_ON(gettimeofday(_start, NULL));
+ ret = gettimeofday(_start, NULL);
+ BUG_ON(ret);
for (i = 0; i < iterations; ++i)
fn(dst, src, len);
- BUG_ON(gettimeofday(_end, NULL));
+ ret = gettimeofday(_end, NULL);
+ BUG_ON(ret);
timersub(_end, _start, _diff);
diff --git a/tools/perf/bench/mem-memset.c b/tools/perf/bench/mem-memset.c
index 350cc95..e0702d2 100644
--- a/tools/perf/bench/mem-memset.c
+++ b/tools/perf/bench/mem-memset.c
@@ -139,17 +139,19 @@ static double do_memset_gettimeofday(memset_t
fn, size_t len, bool prefault)
{
struct timeval tv_start, tv_end, tv_diff;
void *dst = NULL;
- int i;
+ int i, ret;
alloc_mem(, len);
if (prefault)
fn(dst, -1, len);
- BUG_ON(gettimeofday(_start, NULL));
+ ret = gettimeofday(_start, NULL);
+ BUG_ON(ret);
for (i = 0; i < iterations; ++i)
fn(dst, i, len);
- BUG_ON(gettimeofday(_end, NULL));
+ ret = gettimeofday(_end, NULL);
+ BUG_ON(ret);
timersub(_end, _start, _diff);
diff --git a/tools/perf/bench/sched-pipe.c b/tools/perf/bench/sched-pipe.c
index 0c7454f..b35c94b 100644
--- a/tools/perf/bench/sched-pipe.c
+++ b/tools/perf/bench/sched-pipe.c
@@ -61,8 +61,10 @@ int bench_sched_pipe(int argc, const char **argv,
argc = parse_options(argc, argv, options,
bench_sched_pipe_usage, 0);
- assert(!pipe(pipe_1));
- assert(!pipe(pipe_2));
+ ret = pipe(pipe_1);
+ assert(!ret);
+ ret = !pipe(pipe_2);
+ assert(!ret);
pid = fork();
assert(pid >= 0);
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/5] platform: x86: remove acpi_bus_generate_proc_event
Calling this function no longer makes sense as /proc/acpi/event
is being removed.
Signed-off-by: Davidlohr Bueso
---
drivers/platform/x86/asus-laptop.c |1 -
drivers/platform/x86/eeepc-laptop.c |1 -
drivers/platform/x86/fujitsu-laptop.c |4
drivers/platform/x86/panasonic-laptop.c |2 --
drivers/platform/x86/sony-laptop.c |3 ---
drivers/platform/x86/thinkpad_acpi.c| 11 ---
6 files changed, 0 insertions(+), 22 deletions(-)
diff --git a/drivers/platform/x86/asus-laptop.c
b/drivers/platform/x86/asus-laptop.c
index e38f91b..6c4e31d 100644
--- a/drivers/platform/x86/asus-laptop.c
+++ b/drivers/platform/x86/asus-laptop.c
@@ -1514,7 +1514,6 @@ static void asus_acpi_notify(struct acpi_device *device,
u32 event)
/* TODO Find a better way to handle events count. */
count = asus->event_count[event % 128]++;
- acpi_bus_generate_proc_event(asus->device, event, count);
acpi_bus_generate_netlink_event(asus->device->pnp.device_class,
dev_name(>device->dev), event,
count);
diff --git a/drivers/platform/x86/eeepc-laptop.c
b/drivers/platform/x86/eeepc-laptop.c
index dab91b4..8a94d4d 100644
--- a/drivers/platform/x86/eeepc-laptop.c
+++ b/drivers/platform/x86/eeepc-laptop.c
@@ -1267,7 +1267,6 @@ static void eeepc_acpi_notify(struct acpi_device *device,
u32 event)
if (event > ACPI_MAX_SYS_NOTIFY)
return;
count = eeepc->event_count[event % 128]++;
- acpi_bus_generate_proc_event(device, event, count);
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(>dev), event,
count);
diff --git a/drivers/platform/x86/fujitsu-laptop.c
b/drivers/platform/x86/fujitsu-laptop.c
index c4c1a54..2fac1c5 100644
--- a/drivers/platform/x86/fujitsu-laptop.c
+++ b/drivers/platform/x86/fujitsu-laptop.c
@@ -773,8 +773,6 @@ static void acpi_fujitsu_notify(struct acpi_device *device,
u32 event)
else
set_lcd_level(newb);
}
- acpi_bus_generate_proc_event(fujitsu->dev,
- ACPI_VIDEO_NOTIFY_INC_BRIGHTNESS, 0);
keycode = KEY_BRIGHTNESSUP;
} else if (oldb > newb) {
if (disable_brightness_adjust != 1) {
@@ -783,8 +781,6 @@ static void acpi_fujitsu_notify(struct acpi_device *device,
u32 event)
else
set_lcd_level(newb);
}
- acpi_bus_generate_proc_event(fujitsu->dev,
- ACPI_VIDEO_NOTIFY_DEC_BRIGHTNESS, 0);
keycode = KEY_BRIGHTNESSDOWN;
}
break;
diff --git a/drivers/platform/x86/panasonic-laptop.c
b/drivers/platform/x86/panasonic-laptop.c
index 8e8caa7..a140e7f 100644
--- a/drivers/platform/x86/panasonic-laptop.c
+++ b/drivers/platform/x86/panasonic-laptop.c
@@ -465,8 +465,6 @@ static void acpi_pcc_generate_keyinput(struct pcc_acpi *pcc)
return;
}
- acpi_bus_generate_proc_event(pcc->device, HKEY_NOTIFY, result);
-
if (!sparse_keymap_report_event(hotk_input_dev,
result & 0xf, result & 0x80, false))
ACPI_DEBUG_PRINT((ACPI_DB_ERROR,
diff --git a/drivers/platform/x86/sony-laptop.c
b/drivers/platform/x86/sony-laptop.c
index daaddec..5bfcfbc 100644
--- a/drivers/platform/x86/sony-laptop.c
+++ b/drivers/platform/x86/sony-laptop.c
@@ -1269,8 +1269,6 @@ static void sony_nc_notify(struct acpi_device *device,
u32 event)
sony_laptop_report_input_event(real_ev);
}
- acpi_bus_generate_proc_event(sony_nc_acpi_device, ev_type, real_ev);
-
acpi_bus_generate_netlink_event(sony_nc_acpi_device->pnp.device_class,
dev_name(_nc_acpi_device->dev), ev_type, real_ev);
}
@@ -4100,7 +4098,6 @@ static irqreturn_t sony_pic_irq(int irq, void *dev_id)
found:
sony_laptop_report_input_event(device_event);
- acpi_bus_generate_proc_event(dev->acpi_dev, 1, device_event);
sonypi_compat_report_event(device_event);
return IRQ_HANDLED;
}
diff --git a/drivers/platform/x86/thinkpad_acpi.c
b/drivers/platform/x86/thinkpad_acpi.c
index 80e3779..fb105fa 100644
--- a/drivers/platform/x86/thinkpad_acpi.c
+++ b/drivers/platform/x86/thinkpad_acpi.c
@@ -2286,10 +2286,6 @@ static struct tp_acpi_drv_struct ibm_hotkey_acpidriver;
static void tpacpi_hotkey_send_key(unsigned int scancode)
{
tpacpi_input_send_key_masked(scancode);
- if (hotkey_report_mode < 2) {
- acpi_bus_generate_proc_event(ibm_hotkey_acpidriver.device,
- 0x80,
[PATCH 3/5] PCI: hotplug: remove acpi_bus_generate_proc_event
Calling this function no longer makes sense as /proc/acpi/event
is being removed.
Signed-off-by: Davidlohr Bueso
---
drivers/pci/hotplug/acpiphp_ibm.c |1 -
1 files changed, 0 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_ibm.c
b/drivers/pci/hotplug/acpiphp_ibm.c
index c35e8ad..5394fff 100644
--- a/drivers/pci/hotplug/acpiphp_ibm.c
+++ b/drivers/pci/hotplug/acpiphp_ibm.c
@@ -270,7 +270,6 @@ static void ibm_handle_events(acpi_handle handle, u32
event, void *context)
if (subevent == 0x80) {
dbg("%s: generationg bus event\n", __func__);
- acpi_bus_generate_proc_event(note->device, note->event, detail);
acpi_bus_generate_netlink_event(note->device->pnp.device_class,
dev_name(>device->dev),
note->event, detail);
--
1.7.4.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 2/5] sonypi: remove acpi_bus_generate_proc_event
Calling this function no longer makes sense as /proc/acpi/event is being removed. Signed-off-by: Davidlohr Bueso --- drivers/char/sonypi.c |5 - 1 files changed, 0 insertions(+), 5 deletions(-) diff --git a/drivers/char/sonypi.c b/drivers/char/sonypi.c index f877805..4543473 100644 --- a/drivers/char/sonypi.c +++ b/drivers/char/sonypi.c @@ -876,11 +876,6 @@ found: if (useinput) sonypi_report_input_event(event); -#ifdef CONFIG_ACPI - if (sonypi_acpi_device) - acpi_bus_generate_proc_event(sonypi_acpi_device, 1, event); -#endif - kfifo_in_locked(_device.fifo, (unsigned char *), sizeof(event), _device.fifo_lock); kill_fasync(_device.fifo_async, SIGIO, POLL_IN); -- 1.7.4.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/5] acpi: remove CONFIG_ACPI_PROCFS_POWER option
The long time deprecated procfs interface for ACPI power devices has
been scheduled for removal since linux 2.6.39.
Signed-off-by: Davidlohr Bueso
---
Documentation/feature-removal-schedule.txt | 11 -
drivers/acpi/Kconfig | 17 --
drivers/acpi/Makefile |1 -
drivers/acpi/ac.c | 128 +---
drivers/acpi/battery.c | 328 +---
drivers/acpi/cm_sbs.c | 105 -
drivers/acpi/sbs.c | 333 +---
7 files changed, 8 insertions(+), 915 deletions(-)
delete mode 100644 drivers/acpi/cm_sbs.c
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index afaff31..db385ee 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -181,17 +181,6 @@ Who: Zhang Rui
---
-What: CONFIG_ACPI_PROCFS_POWER
-When: 2.6.39
-Why: sysfs I/F for ACPI power devices, including AC and Battery,
-has been working in upstream kernel since 2.6.24, Sep 2007.
- In 2.6.37, we make the sysfs I/F always built in and this option
- disabled by default.
- Remove this option and the ACPI power procfs interface in 2.6.39.
-Who: Zhang Rui
-
-
What: /proc/acpi/event
When: February 2008
Why: /proc/acpi/event has been replaced by events via the input layer
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 8099895..6aa0cc8 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -56,23 +56,6 @@ config ACPI_PROCFS
Say N to delete /proc/acpi/ files that have moved to /sys/
-config ACPI_PROCFS_POWER
- bool "Deprecated power /proc/acpi directories"
- depends on PROC_FS
- help
- For backwards compatibility, this option allows
- deprecated power /proc/acpi/ directories to exist, even when
- they have been replaced by functions in /sys.
- The deprecated directories (and their replacements) include:
- /proc/acpi/battery/* (/sys/class/power_supply/*)
- /proc/acpi/ac_adapter/* (sys/class/power_supply/*)
- This option has no effect on /proc/acpi/ directories
- and functions, which do not yet exist in /sys
- This option, together with the proc directories, will be
- deleted in 2.6.39.
-
- Say N to delete power /proc/acpi/ directories that have moved to /sys/
-
config ACPI_EC_DEBUGFS
tristate "EC read/write access through /sys/kernel/debug/ec"
default n
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 47199e2..4455be2 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -41,7 +41,6 @@ acpi-y+= event.o
acpi-y += sysfs.o
acpi-$(CONFIG_DEBUG_FS)+= debugfs.o
acpi-$(CONFIG_ACPI_NUMA) += numa.o
-acpi-$(CONFIG_ACPI_PROCFS_POWER) += cm_sbs.o
ifdef CONFIG_ACPI_VIDEO
acpi-y += video_detect.o
endif
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index d5fdd36..7e00303 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -28,10 +28,6 @@
#include
#include
#include
-#ifdef CONFIG_ACPI_PROCFS_POWER
-#include
-#include
-#endif
#include
#include
#include
@@ -53,12 +49,6 @@ MODULE_AUTHOR("Paul Diefenbaugh");
MODULE_DESCRIPTION("ACPI AC Adapter Driver");
MODULE_LICENSE("GPL");
-#ifdef CONFIG_ACPI_PROCFS_POWER
-extern struct proc_dir_entry *acpi_lock_ac_dir(void);
-extern void *acpi_unlock_ac_dir(struct proc_dir_entry *acpi_ac_dir);
-static int acpi_ac_open_fs(struct inode *inode, struct file *file);
-#endif
-
static int acpi_ac_add(struct acpi_device *device);
static int acpi_ac_remove(struct acpi_device *device, int type);
static void acpi_ac_notify(struct acpi_device *device, u32 event);
@@ -95,16 +85,6 @@ struct acpi_ac {
#define to_acpi_ac(x) container_of(x, struct acpi_ac, charger)
-#ifdef CONFIG_ACPI_PROCFS_POWER
-static const struct file_operations acpi_ac_fops = {
- .owner = THIS_MODULE,
- .open = acpi_ac_open_fs,
- .read = seq_read,
- .llseek = seq_lseek,
- .release = single_release,
-};
-#endif
-
/* --
AC Adapter Management
--
*/
@@ -156,83 +136,6 @@ static enum power_supply_property ac_props[] = {
POWER_SUPPLY_PROP_ONLINE,
};
-#ifdef CONFIG_ACPI_PROCFS_POWER
-/* --
- FS Interface (/proc)
- --
*/
-
-static struct proc_dir_entry *acpi_ac_dir;
-
-static int
[PATCH 5/5] acpi: events: remove procfs interface
The /proc/acpi/event interface has been replaced by events through the
input layer and netlink, and scheduled for removal over four years ago.
Signed-off-by: Davidlohr Bueso
---
Documentation/feature-removal-schedule.txt |8 --
drivers/acpi/Kconfig | 18 -
drivers/acpi/ac.c |1 -
drivers/acpi/acpi_pad.c|1 -
drivers/acpi/battery.c |2 -
drivers/acpi/bus.c | 98 -
drivers/acpi/button.c |2 -
drivers/acpi/event.c | 107 +---
drivers/acpi/processor_driver.c|4 -
drivers/acpi/sbs.c | 16 +
drivers/acpi/thermal.c |3 -
drivers/acpi/video.c | 10 ---
include/acpi/acpi_bus.h|8 --
13 files changed, 4 insertions(+), 274 deletions(-)
diff --git a/Documentation/feature-removal-schedule.txt
b/Documentation/feature-removal-schedule.txt
index db385ee..3021e77 100644
--- a/Documentation/feature-removal-schedule.txt
+++ b/Documentation/feature-removal-schedule.txt
@@ -181,14 +181,6 @@ Who: Zhang Rui
---
-What: /proc/acpi/event
-When: February 2008
-Why: /proc/acpi/event has been replaced by events via the input layer
- and netlink since 2.6.23.
-Who: Len Brown
-
-
What: i386/x86_64 bzImage symlinks
When: April 2010
diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig
index 6aa0cc8..37110d1 100644
--- a/drivers/acpi/Kconfig
+++ b/drivers/acpi/Kconfig
@@ -74,24 +74,6 @@ config ACPI_EC_DEBUGFS
Thus this option is a debug option that helps to write ACPI drivers
and can be used to identify ACPI code or EC firmware bugs.
-config ACPI_PROC_EVENT
- bool "Deprecated /proc/acpi/event support"
- depends on PROC_FS
- default y
- help
- A user-space daemon, acpid, typically reads /proc/acpi/event
- and handles all ACPI-generated events.
-
- These events are now delivered to user-space either
- via the input layer or as netlink events.
-
- This build option enables the old code for legacy
- user-space implementation. After some time, this will
- be moved under CONFIG_ACPI_PROCFS, and then deleted.
-
- Say Y here to retain the old behaviour. Say N if your
- user-space is newer than kernel 2.6.23 (September 2007).
-
config ACPI_AC
tristate "AC Adapter"
depends on X86
diff --git a/drivers/acpi/ac.c b/drivers/acpi/ac.c
index 7e00303..af56697 100644
--- a/drivers/acpi/ac.c
+++ b/drivers/acpi/ac.c
@@ -156,7 +156,6 @@ static void acpi_ac_notify(struct acpi_device *device, u32
event)
case ACPI_NOTIFY_BUS_CHECK:
case ACPI_NOTIFY_DEVICE_CHECK:
acpi_ac_get_state(ac);
- acpi_bus_generate_proc_event(device, event, (u32) ac->state);
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(>dev), event,
(u32) ac->state);
diff --git a/drivers/acpi/acpi_pad.c b/drivers/acpi/acpi_pad.c
index af4aad6..fe1085d 100644
--- a/drivers/acpi/acpi_pad.c
+++ b/drivers/acpi/acpi_pad.c
@@ -452,7 +452,6 @@ static void acpi_pad_notify(acpi_handle handle, u32 event,
switch (event) {
case ACPI_PROCESSOR_AGGREGATOR_NOTIFY:
acpi_pad_handle_notify(handle);
- acpi_bus_generate_proc_event(device, event, 0);
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(>dev), event, 0);
break;
diff --git a/drivers/acpi/battery.c b/drivers/acpi/battery.c
index bd364a4..38a37bd 100644
--- a/drivers/acpi/battery.c
+++ b/drivers/acpi/battery.c
@@ -657,8 +657,6 @@ static void acpi_battery_notify(struct acpi_device *device,
u32 event)
if (event == ACPI_BATTERY_NOTIFY_INFO)
acpi_battery_refresh(battery);
acpi_battery_update(battery);
- acpi_bus_generate_proc_event(device, event,
-acpi_battery_present(battery));
acpi_bus_generate_netlink_event(device->pnp.device_class,
dev_name(>dev), event,
acpi_battery_present(battery));
diff --git a/drivers/acpi/bus.c b/drivers/acpi/bus.c
index 9628652..63b903b 100644
--- a/drivers/acpi/bus.c
+++ b/drivers/acpi/bus.c
@@ -593,104 +593,6 @@ static void acpi_bus_osc_support(void)
}
/* --
-Event Management
- --
*/
-
-#ifdef CONFIG_ACPI_PROC_EVENT
-static
[PATCH 0/5] acpi: remove some legacy procfs interfaces
Hi, This patchset is a first attempt to remove some of the deprecated procfs ACPI interfaces - in the final overall idea to remove /proc/acpi entirely. Based on the feature removal file, the CONFIG_ACPI_PROCFS_POWER and CONFIG_ACPI_PROC_EVENT options are dropped. patch 1: removes CONFIG_ACPI_PROCFS_POWER patch 2-5: removes CONFIG_ACPI_PROC_EVENT for acpi and respective drivers that use /proc/acpi/event. The set applies ontop of Linus' latest. Thanks, Davidlohr -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] KVM: VMX: invalidate vpid for invlpg instruction
On Fri, 2012-08-31 at 14:37 -0300, Marcelo Tosatti wrote: > On Fri, Aug 31, 2012 at 06:10:48PM +0200, Davidlohr Bueso wrote: > > For processors that support VPIDs we should invalidate the page table entry > > specified by the lineal address. For this purpose add support for individual > > address invalidations. > > Not necessary - a single context invalidation is performed through > KVM_REQ_TLB_FLUSH. Since vpid_sync_context() supports both single and all-context vpid invalidations, wouldn't it make sense to also add individual address ones as well, supporting further granularity? > > Single-context. If the INVVPID type is 1, the logical processor > invalidates all > linear mappings and combined mappings associated with the VPID specified > in the INVVPID descriptor. > > -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: kernel 3.2.27 on arm: WARNING: at mm/page_alloc.c:2109 __alloc_pages_nodemask+0x1d4/0x68c()
Since I had a rare occasion to physically access the machine, I did the following experiment: connect another machine to the serial console, run while true ; do date ; cat /proc/slabinfo ; echo '***' ; sleep 3 ; done and generate lots of IPv6 traffic through the box (as I mentioned, for some reason, a Firefox compilation through ssh seems particularly effective). So I now have lots of slabinfo data and, beyond the initial WARNING, I also got messages along the lines of "swapper: page allocation failure: order:10, mode:0x4020". I put the full log in http://www.madore.org/~david/.tmp/pollux-dump.0 > (unfortunately a bit garbled, because sometimes the cat slabinfo was interspaced with printk output, but there are still plenty of usable lines of each sort). For completeness, here's a sample message from a page allocation failure, and a copy of /proc/slabinfo from just about that time (I have no idea how to read this, but one thing I can say is that there is no extraordinarily large number in this): [ 567.757489] swapper: page allocation failure: order:10, mode:0x4020 [ 567.763815] [] (unwind_backtrace+0x0/0xf0) from [] (warn_alloc_failed+0xcc/0x10c) [ 567.773119] [] (warn_alloc_failed+0xcc/0x10c) from [] (__alloc_pages_nodemask+0x530/0x68c) [ 567.783184] [] (__alloc_pages_nodemask+0x530/0x68c) from [] (__get_free_pages+0x10/0x3c) [ 567.793084] [] (__get_free_pages+0x10/0x3c) from [] (kmalloc_order_trace+0x24/0xdc) [ 567.802547] [] (kmalloc_order_trace+0x24/0xdc) from [] (pskb_expand_head+0x68/0x298) [ 567.812317] [] (pskb_expand_head+0x68/0x298) from [] (ip6_forward+0x4d4/0x7bc [ipv6]) [ 567.822056] [] (ip6_forward+0x4d4/0x7bc [ipv6]) from [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) [ 567.831751] [] (ipv6_rcv+0x2bc/0x3dc [ipv6]) from [] (__netif_receive_skb+0x544/0x66c) [ 567.841521] [] (__netif_receive_skb+0x544/0x66c) from [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) [ 567.853306] [] (br_nf_pre_routing_finish_ipv6+0x10c/0x160 [bridge]) from [] (br_nf_pre_routing+0x59c/0x67c [bridge]) [ 567.865673] [] (br_nf_pre_routing+0x59c/0x67c [bridge]) from [] (nf_iterate+0x8c/0xb4) [ 567.875387] [] (nf_iterate+0x8c/0xb4) from [] (nf_hook_slow+0x5c/0x118) [ 567.883800] [] (nf_hook_slow+0x5c/0x118) from [] (br_handle_frame+0x1b8/0x290 [bridge]) [ 567.893624] [] (br_handle_frame+0x1b8/0x290 [bridge]) from [] (__netif_receive_skb+0x3cc/0x66c) [ 567.904137] [] (__netif_receive_skb+0x3cc/0x66c) from [] (mv643xx_eth_poll+0x540/0x734) [ 567.913928] [] (mv643xx_eth_poll+0x540/0x734) from [] (net_rx_action+0x118/0x314) [ 567.923215] [] (net_rx_action+0x118/0x314) from [] (__do_softirq+0xac/0x234) [ 567.932058] [] (__do_softirq+0xac/0x234) from [] (irq_exit+0x94/0x9c) [ 567.940421] [] (irq_exit+0x94/0x9c) from [] (handle_IRQ+0x34/0x84) [ 567.948392] [] (handle_IRQ+0x34/0x84) from [] (__irq_svc+0x34/0x98) [ 567.956454] [] (__irq_svc+0x34/0x98) from [] (kirkwood_enter_idle+0x4c/0x94) [ 567.965299] [] (kirkwood_enter_idle+0x4c/0x94) from [] (cpuidle_idle_call+0xc8/0x35c) [ 567.974925] [] (cpuidle_idle_call+0xc8/0x35c) from [] (cpu_idle+0x88/0xdc) [ 567.983581] [] (cpu_idle+0x88/0xdc) from [] (start_kernel+0x2a0/0x2f0) [ 567.991893] Mem-info: [ 567.994185] Normal per-cpu: [ 567.996995] CPU0: hi: 186, btch: 31 usd: 84 [ 568.001815] active_anon:5592 inactive_anon:34 isolated_anon:0 [ 568.001820] active_file:2845 inactive_file:6118 isolated_file:0 [ 568.001825] unevictable:418 dirty:13 writeback:0 unstable:0 [ 568.001829] free:12507 slab_reclaimable:632 slab_unreclaimable:1124 [ 568.001835] mapped:2546 shmem:47 pagetables:152 bounce:0 [ 568.031126] Normal free:50028kB min:2884kB low:3604kB high:4324kB active_anon:22368kB inactive_anon:136kB active_file:11380kB inactive_file:24472kB unevictable:1672kB isolated(anon):0kB isolated(file):0kB present:520192kB mlocked:1672kB dirty:52kB writeback:0kB mapped:10184kB shmem:188kB slab_reclaimable:2528kB slab_unreclaimable:4496kB kernel_stack:584kB pagetables:608kB unstable:0kB bounce:0kB writeback_tmp:0kB pages_scanned:0 all_unreclaimable? no [ 568.071329] lowmem_reserve[]: 0 0 [ 568.074696] Normal: 1*4kB 1*8kB 8*16kB 7*32kB 0*64kB 2*128kB 1*256kB 4*512kB 20*1024kB 11*2048kB 1*4096kB = 50028kB [ 568.085282] 9350 total pagecache pages [ 568.089039] 0 pages in swap cache [ 568.092363] Swap cache stats: add 0, delete 0, find 0/0 [ 568.097621] Free swap = 0kB [ 568.100506] Total swap = 0kB [ 568.117927] 131072 pages of RAM [ 568.121087] 12771 free pages [ 568.123972] 2839 reserved pages [ 568.127140] 1361 slab pages [ 568.129945] 8003 pages shared [ 568.132919] 0 pages swap cached slabinfo - version: 2.1 # name : tunables: slabdata nf_conntrack_expect 0 0176 231 : tunables000 : slabdata 0 0 0 nf_conntrack_c06d1258128128248 161 : tunables000 : slabdata 8 8 0 ip6_dst_cache 72
[PATCH part3 01/11] PCI: Separate out pci_assign_unassigned_bus_resources()
It is main portion of pci_rescan_bus().
Separate it out and need to use it for pci root bus hot add later.
Signed-off-by: Yinghai Lu
---
drivers/pci/setup-bus.c | 32 ++--
include/linux/pci.h |1 +
2 files changed, 19 insertions(+), 14 deletions(-)
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index f0e959c..e5c45c8 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1511,25 +1511,12 @@ enable_all:
}
EXPORT_SYMBOL_GPL(pci_assign_unassigned_bridge_resources);
-#ifdef CONFIG_HOTPLUG
-/**
- * pci_rescan_bus - scan a PCI bus for devices.
- * @bus: PCI bus to scan
- *
- * Scan a PCI bus and child buses for new devices, adds them,
- * and enables them.
- *
- * Returns the max number of subordinate bus discovered.
- */
-unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
+void pci_assign_unassigned_bus_resources(struct pci_bus *bus)
{
- unsigned int max;
struct pci_dev *dev;
LIST_HEAD(add_list); /* list of resources that
want additional resources */
- max = pci_scan_child_bus(bus);
-
down_read(_bus_sem);
list_for_each_entry(dev, >devices, bus_list)
if (dev->hdr_type == PCI_HEADER_TYPE_BRIDGE ||
@@ -1542,6 +1529,23 @@ unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
BUG_ON(!list_empty(_list));
pci_enable_bridges(bus);
+}
+#ifdef CONFIG_HOTPLUG
+/**
+ * pci_rescan_bus - scan a PCI bus for devices.
+ * @bus: PCI bus to scan
+ *
+ * Scan a PCI bus and child buses for new devices, adds them,
+ * and enables them.
+ *
+ * Returns the max number of subordinate bus discovered.
+ */
+unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
+{
+ unsigned int max;
+
+ max = pci_scan_child_bus(bus);
+ pci_assign_unassigned_bus_resources(bus);
pci_bus_add_devices(bus);
return max;
diff --git a/include/linux/pci.h b/include/linux/pci.h
index 29a4704..1bd7559 100644
--- a/include/linux/pci.h
+++ b/include/linux/pci.h
@@ -983,6 +983,7 @@ void pci_bus_size_bridges(struct pci_bus *bus);
int pci_claim_resource(struct pci_dev *, int);
void pci_assign_unassigned_resources(void);
void pci_assign_unassigned_bridge_resources(struct pci_dev *bridge);
+void pci_assign_unassigned_bus_resources(struct pci_bus *bus);
void pdev_enable_device(struct pci_dev *);
int pci_enable_resources(struct pci_dev *, int mask);
void pci_fixup_irqs(u8 (*)(struct pci_dev *, u8 *),
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part3 02/11] PCI: Move back pci_rescan_bus() to probe.c
We have pci_assign_unassigned_bus_resources() in as global function now.
So could move back pci_rescan_bus to probe.c where it should be.
Signed-off-by: Yinghai Lu
---
drivers/pci/probe.c | 21 +
drivers/pci/setup-bus.c | 22 --
2 files changed, 21 insertions(+), 22 deletions(-)
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index d8f513b..bc22308 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -1890,6 +1890,27 @@ unsigned int __ref pci_rescan_bus_bridge_resize(struct
pci_dev *bridge)
return max;
}
+/**
+ * pci_rescan_bus - scan a PCI bus for devices.
+ * @bus: PCI bus to scan
+ *
+ * Scan a PCI bus and child buses for new devices, adds them,
+ * and enables them.
+ *
+ * Returns the max number of subordinate bus discovered.
+ */
+unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
+{
+ unsigned int max;
+
+ max = pci_scan_child_bus(bus);
+ pci_assign_unassigned_bus_resources(bus);
+ pci_bus_add_devices(bus);
+
+ return max;
+}
+EXPORT_SYMBOL_GPL(pci_rescan_bus);
+
EXPORT_SYMBOL(pci_add_new_bus);
EXPORT_SYMBOL(pci_scan_slot);
EXPORT_SYMBOL(pci_scan_bridge);
diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c
index e5c45c8..1dc22b3 100644
--- a/drivers/pci/setup-bus.c
+++ b/drivers/pci/setup-bus.c
@@ -1530,25 +1530,3 @@ void pci_assign_unassigned_bus_resources(struct pci_bus
*bus)
pci_enable_bridges(bus);
}
-#ifdef CONFIG_HOTPLUG
-/**
- * pci_rescan_bus - scan a PCI bus for devices.
- * @bus: PCI bus to scan
- *
- * Scan a PCI bus and child buses for new devices, adds them,
- * and enables them.
- *
- * Returns the max number of subordinate bus discovered.
- */
-unsigned int __ref pci_rescan_bus(struct pci_bus *bus)
-{
- unsigned int max;
-
- max = pci_scan_child_bus(bus);
- pci_assign_unassigned_bus_resources(bus);
- pci_bus_add_devices(bus);
-
- return max;
-}
-EXPORT_SYMBOL_GPL(pci_rescan_bus);
-#endif
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part3 05/11] PCI, sysfs: Use device_type and attr_groups with pci dev
We want to create rescan in sys only for pci bridge instead of all pci dev.
We could use attribute_groups/is_visible method to do that.
Now pci dev does not use device type yet. So add pci_dev_type to take
attr_groups with it.
Add pci_dev_bridge_attrs_are_visible() to control attr_bridge_group only create
attr for bridge.
This is the framework related change, later could attr to bridge_attr_group,
to make those attr only show up on pci bridge device.
Also We could add more attr groups with is_visible to reduce messness in
pci_create_sysfs_dev_files. ( at least for boot_vga one )
Signed-off-by: Yinghai Lu
---
drivers/pci/pci-sysfs.c | 30 ++
drivers/pci/pci.h |1 +
drivers/pci/probe.c |1 +
3 files changed, 32 insertions(+), 0 deletions(-)
diff --git a/drivers/pci/pci-sysfs.c b/drivers/pci/pci-sysfs.c
index 6869009..e37a0e0 100644
--- a/drivers/pci/pci-sysfs.c
+++ b/drivers/pci/pci-sysfs.c
@@ -1369,3 +1369,33 @@ static int __init pci_sysfs_init(void)
}
late_initcall(pci_sysfs_init);
+
+static struct attribute *pci_dev_bridge_attrs[] = {
+ NULL,
+};
+
+static umode_t pci_dev_bridge_attrs_are_visible(struct kobject *kobj,
+ struct attribute *a, int n)
+{
+ struct device *dev = container_of(kobj, struct device, kobj);
+ struct pci_dev *pdev = to_pci_dev(dev);
+
+ if (!pdev->subordinate)
+ return 0;
+
+ return a->mode;
+}
+
+static struct attribute_group pci_dev_bridge_attr_group = {
+ .attrs = pci_dev_bridge_attrs,
+ .is_visible = pci_dev_bridge_attrs_are_visible,
+};
+
+static const struct attribute_group *pci_dev_attr_groups[] = {
+ _dev_bridge_attr_group,
+ NULL,
+};
+
+struct device_type pci_dev_type = {
+ .groups = pci_dev_attr_groups,
+};
diff --git a/drivers/pci/pci.h b/drivers/pci/pci.h
index bacbcba..6f6cd14 100644
--- a/drivers/pci/pci.h
+++ b/drivers/pci/pci.h
@@ -157,6 +157,7 @@ static inline int pci_no_d1d2(struct pci_dev *dev)
}
extern struct device_attribute pci_dev_attrs[];
extern struct device_attribute pcibus_dev_attrs[];
+extern struct device_type pci_dev_type;
#ifdef CONFIG_HOTPLUG
extern struct bus_attribute pci_bus_attrs[];
#else
diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c
index bc22308..d1796fe 100644
--- a/drivers/pci/probe.c
+++ b/drivers/pci/probe.c
@@ -970,6 +970,7 @@ int pci_setup_device(struct pci_dev *dev)
dev->sysdata = dev->bus->sysdata;
dev->dev.parent = dev->bus->bridge;
dev->dev.bus = _bus_type;
+ dev->dev.type = _dev_type;
dev->hdr_type = hdr_type & 0x7f;
dev->multifunction = !!(hdr_type & 0x80);
dev->error_state = pci_channel_io_normal;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 01/11] PCI: Fix a device reference count leakage issue in pci_dev_present()
From: Jiang Liu
Function pci_get_dev_by_id() will hold a reference count on the pci device
returned, so pci_dev_present() should release the corresponding reference
count to avoid memory leakage.
Signed-off-by: Jiang Liu
---
drivers/pci/search.c | 10 +-
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/search.c b/drivers/pci/search.c
index d84cdcf..cd11bd8 100644
--- a/drivers/pci/search.c
+++ b/drivers/pci/search.c
@@ -338,13 +338,13 @@ int pci_dev_present(const struct pci_device_id *ids)
WARN_ON(in_interrupt());
while (ids->vendor || ids->subvendor || ids->class_mask) {
found = pci_get_dev_by_id(ids, NULL);
- if (found)
- goto exit;
+ if (found) {
+ pci_dev_put(found);
+ return 1;
+ }
ids++;
}
-exit:
- if (found)
- return 1;
+
return 0;
}
EXPORT_SYMBOL(pci_dev_present);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 02/11] PCI: Correctly clean up pci root buses in function pci_remove_bus()
From: Jiang Liu
The function pci_create_root_bus() allocates the pci bus structure,
registers the bus device and creates the legacy files for a pci root
bus, but returns without setting the is_added flag. The is_added flag
for a pci root bus will be set by function pci_scan_child_bus().
If a pci root bus is destroyed before calling pci_scan_child_bus(),
the is_added flag will not be set. So teach function pci_remove_bus()
to detect such a case and correctly clean up pci root buses.
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/pci/remove.c |9 -
1 files changed, 4 insertions(+), 5 deletions(-)
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index aaae16e..b9f553b 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -48,11 +48,10 @@ void pci_remove_bus(struct pci_bus *bus)
list_del(>node);
pci_bus_release_busn_res(bus);
up_write(_bus_sem);
- if (!bus->is_added)
- return;
-
- pci_remove_legacy_files(bus);
- device_unregister(>dev);
+ if (bus->is_added || pci_is_root_bus(bus)) {
+ pci_remove_legacy_files(bus);
+ device_unregister(>dev);
+ }
}
EXPORT_SYMBOL(pci_remove_bus);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 04/11] PCI: Fix an access-after-free issue in function pci_stop_and_remove_bus()
From: Jiang Liu
If pci_stop_and_remove_bus() is called to remove a pci root bus,
the host_bridge structure may have already been freed after returning
from pci_remove_bus(). To avoid that, hold an extra reference count
to the root bus before calling pci_remove_bus(), so we can safely
access the pci_host_bridge structure after returning from function
pci_remove_bus().
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/pci/remove.c |5 -
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/pci/remove.c b/drivers/pci/remove.c
index 94407d4..40f8148 100644
--- a/drivers/pci/remove.c
+++ b/drivers/pci/remove.c
@@ -154,6 +154,7 @@ void pci_stop_and_remove_bus(struct pci_bus *bus)
if (pci_is_root_bus(bus)) {
host_bridge = to_pci_host_bridge(bus->bridge);
+ get_device(_bridge->dev);
pci_stop_host_bridge(host_bridge);
} else
pci_bridge = bus->self;
@@ -162,8 +163,10 @@ void pci_stop_and_remove_bus(struct pci_bus *bus)
pci_remove_bus(bus);
- if (host_bridge)
+ if (host_bridge) {
host_bridge->bus = NULL;
+ put_device(_bridge->dev);
+ }
if (pci_bridge)
pci_bridge->subordinate = NULL;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 07/11] PCI, ACPI: Add pci_root_hp hot removal notification support.
Add missing hot_remove support for root device.
How to use it?
Find out root bus number to acpi root name mapping from dmesg or /sys
echo "\_SB.PCIB 3" > /proc/acpi/sci/notify
to remove root bus
Signed-off-by: Yinghai Lu
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/pci_root_hp.c | 61
1 files changed, 61 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/pci_root_hp.c b/drivers/acpi/pci_root_hp.c
index e07c31b..214adcb 100644
--- a/drivers/acpi/pci_root_hp.c
+++ b/drivers/acpi/pci_root_hp.c
@@ -73,6 +73,12 @@ static void add_acpi_root_bridge(acpi_handle handle)
list_add(>list, _root_bridge_list);
}
+static void remove_acpi_root_bridge(struct acpi_root_bridge *bridge)
+{
+ list_del(>list);
+ kfree(bridge);
+}
+
struct acpi_root_hp_work {
struct work_struct work;
acpi_handle handle;
@@ -143,6 +149,55 @@ static void handle_root_bridge_insertion(acpi_handle
handle)
printk(KERN_ERR "cannot start bridge\n");
}
+static int acpi_root_evaluate_object(acpi_handle handle, char *cmd, int val)
+{
+ acpi_status status;
+ struct acpi_object_list arg_list;
+ union acpi_object arg;
+
+ arg_list.count = 1;
+ arg_list.pointer =
+ arg.type = ACPI_TYPE_INTEGER;
+ arg.integer.value = val;
+
+ status = acpi_evaluate_object(handle, cmd, _list, NULL);
+ if (ACPI_FAILURE(status)) {
+ printk(KERN_WARNING "%s: %s to %d failed\n",
+__func__, cmd, val);
+ return -1;
+ }
+
+ return 0;
+}
+
+static void handle_root_bridge_removal(acpi_handle handle,
+struct acpi_root_bridge *bridge)
+{
+ u32 flags = 0;
+ struct acpi_device *device;
+
+ if (bridge) {
+ flags = bridge->flags;
+ remove_acpi_root_bridge(bridge);
+ }
+
+ if (!acpi_bus_get_device(handle, )) {
+ int ret_val = acpi_bus_trim(device, 1);
+
+ printk(KERN_DEBUG "acpi_bus_trim return %x\n", ret_val);
+ }
+
+ if (flags & ROOT_BRIDGE_HAS_PS3) {
+ acpi_status status;
+
+ status = acpi_evaluate_object(handle, "_PS3", NULL, NULL);
+ if (ACPI_FAILURE(status))
+ printk(KERN_WARNING "%s: _PS3 failed\n", __func__);
+ }
+ if (flags & ROOT_BRIDGE_HAS_EJ0)
+ acpi_root_evaluate_object(handle, "_EJ0", 1);
+}
+
static void _handle_hotplug_event_root(struct work_struct *work)
{
struct acpi_root_bridge *bridge;
@@ -183,6 +238,12 @@ static void _handle_hotplug_event_root(struct work_struct
*work)
}
break;
+ case ACPI_NOTIFY_EJECT_REQUEST:
+ /* request device eject */
+ printk(KERN_DEBUG "%s: Device eject notify on %s\n", __func__,
+objname);
+ handle_root_bridge_removal(handle, bridge);
+ break;
default:
printk(KERN_WARNING "notify_handler: unknown event type 0x%x
for %s\n",
type, objname);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 2/7] ACPI, PCI: Notify acpi_pci_drivers when hot-plugging PCI root bridges
From: Jiang Liu
When hot-plugging PCI root bridge, acpi_pci_drivers' add()/remove()
methods should be invoked to notify registered drivers.
-v2: Move add calling to acpi_pci_root_start by Yinghai
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c | 11 +++
1 files changed, 11 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 2aec08d..9ba516b 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -626,14 +626,25 @@ end:
static int acpi_pci_root_start(struct acpi_device *device)
{
struct acpi_pci_root *root = acpi_driver_data(device);
+ struct acpi_pci_driver *driver;
+
+ list_for_each_entry(driver, _pci_drivers, node)
+ if (driver->add)
+ driver->add(device->handle);
pci_bus_add_devices(root->bus);
+
return 0;
}
static int acpi_pci_root_remove(struct acpi_device *device, int type)
{
struct acpi_pci_root *root = acpi_driver_data(device);
+ struct acpi_pci_driver *driver;
+
+ list_for_each_entry(driver, _pci_drivers, node)
+ if (driver->remove)
+ driver->remove(root->device->handle);
/* that root bus could be removed already */
if (!pci_find_bus(root->segment, root->secondary.start)) {
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 6/7] PCI, x86: Move pci_enable_bridges() down
After we get hot-added ioapic registered. pci_enable_bridges will try to enable ioapic irq for pci bridge. So need to move it down. Or We can move out pcibios_enable_irq() out of pci_enable_device() and call pcibios_enable_irq in pci_bus_add_devices ? also will need to move ... pcibios_resource_survey_bus(root->bus); pci_assign_unassigned_bus_resources(root->bus); to the start add Signed-off-by: Yinghai Lu --- drivers/acpi/pci_root.c |3 +++ drivers/pci/probe.c |1 + drivers/pci/setup-bus.c |2 -- 3 files changed, 4 insertions(+), 2 deletions(-) diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c index 59aa947..80adbbb 100644 --- a/drivers/acpi/pci_root.c +++ b/drivers/acpi/pci_root.c @@ -646,6 +646,9 @@ static int acpi_pci_root_start(struct acpi_device *device) if (driver->add) driver->add(device->handle); + /* need to after hot-added ioapic is registered */ + pci_enable_bridges(root->bus); + pci_bus_add_devices(root->bus); mutex_unlock(_pci_root_lock); diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index dd84224..b18f429 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1909,6 +1909,7 @@ unsigned int __ref pci_rescan_bus(struct pci_bus *bus) max = pci_scan_child_bus(bus); pci_assign_unassigned_bus_resources(bus); + pci_enable_bridges(bus); pci_bus_add_devices(bus); return max; diff --git a/drivers/pci/setup-bus.c b/drivers/pci/setup-bus.c index 054d54b..ec10d51 100644 --- a/drivers/pci/setup-bus.c +++ b/drivers/pci/setup-bus.c @@ -1527,6 +1527,4 @@ void pci_assign_unassigned_bus_resources(struct pci_bus *bus) up_read(_bus_sem); __pci_bus_assign_resources(bus, _list, NULL); BUG_ON(!list_empty(_list)); - - pci_enable_bridges(bus); } -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 4/7] ACPI, PCI: Stop pci devices before acpi_pci_driver remove calling
During stop pci drivers, it still need to access ioapic and iommu.
So need to make sure those drivers need to be stop at first.
Also change the acpi_pci_drivers remove calling sequence to reverse.
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c | 11 +++
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index f3402df..59aa947 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -659,10 +659,6 @@ static int acpi_pci_root_remove(struct acpi_device
*device, int type)
mutex_lock(_pci_root_lock);
- list_for_each_entry(driver, _pci_drivers, node)
- if (driver->remove)
- driver->remove(root->device->handle);
-
/* that root bus could be removed already */
if (!pci_find_bus(root->segment, root->secondary.start)) {
dev_printk(KERN_DEBUG, >dev,
@@ -670,6 +666,13 @@ static int acpi_pci_root_remove(struct acpi_device
*device, int type)
goto out;
}
+ /* stop normal pci drivers before we stop ioapic and dmar etc */
+ pci_stop_bus_devices(root->bus);
+
+ list_for_each_entry_reverse(driver, _pci_drivers, node)
+ if (driver->remove)
+ driver->remove(root->device->handle);
+
device_set_run_wake(root->bus->bridge, false);
pci_acpi_remove_bus_pm_notifier(device);
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 0/7] PCI, ACPI: pci root bus hotplug support - part5
This part is to make sure ioapic and dmar handling sequence. aka need to start driver for ioapic and dmar before regular pci device drivers. and need to stop dmar and ioapic driver after pci device drivers. user acpi_pci_driver to start and stop ioapic and dmar driver. could get from git://git.kernel.org/pub/scm/linux/kernel/git/yinghai/linux-yinghai.git for-pci-root-bus-hotplug-part5 Jiang Liu (3): ACPI, PCI: Use normal list for struct acpi_pci_driver ACPI, PCI: Notify acpi_pci_drivers when hot-plugging PCI root bridges ACPI, PCI: Protect global lists in drivers/acpi/pci_root.c Yinghai Lu (4): ACPI, PCI: Stop pci devices before acpi_pci_driver remove calling PCI: Set dev_node early for pci_dev PCI, x86: Move pci_enable_bridges() down ACPI, PCI: Skip extra pci_enable_bridges for non hot-add root drivers/acpi/pci_root.c| 121 +++- drivers/acpi/pci_root_hp.c |1 + drivers/pci/probe.c|2 + drivers/pci/setup-bus.c|2 - include/acpi/acpi_bus.h|1 + include/linux/acpi.h |2 +- 6 files changed, 79 insertions(+), 50 deletions(-) -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 7/7] ACPI, PCI: Skip extra pci_enable_bridges for non hot-add root
Pre-installed will be handled later, need to skip the one only for hot-added
roots.
Otherwise will get anonying failing message about can not reserve, irq ...
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c|3 ++-
drivers/acpi/pci_root_hp.c |1 +
include/acpi/acpi_bus.h|1 +
3 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 80adbbb..576fe9a 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -647,7 +647,8 @@ static int acpi_pci_root_start(struct acpi_device *device)
driver->add(device->handle);
/* need to after hot-added ioapic is registered */
- pci_enable_bridges(root->bus);
+ if (root->hot_added)
+ pci_enable_bridges(root->bus);
pci_bus_add_devices(root->bus);
mutex_unlock(_pci_root_lock);
diff --git a/drivers/acpi/pci_root_hp.c b/drivers/acpi/pci_root_hp.c
index d2ace81..2800fb4 100644
--- a/drivers/acpi/pci_root_hp.c
+++ b/drivers/acpi/pci_root_hp.c
@@ -86,6 +86,7 @@ static void acpi_root_configure_bridge(acpi_handle handle)
pcibios_resource_survey_bus(root->bus);
pci_assign_unassigned_bus_resources(root->bus);
+ root->hot_added = true;
}
static void handle_root_bridge_insertion(acpi_handle handle)
diff --git a/include/acpi/acpi_bus.h b/include/acpi/acpi_bus.h
index bde976e..47de196 100644
--- a/include/acpi/acpi_bus.h
+++ b/include/acpi/acpi_bus.h
@@ -406,6 +406,7 @@ struct acpi_pci_root {
u32 osc_support_set;/* _OSC state of support bits */
u32 osc_control_set;/* _OSC state of control bits */
+ bool hot_added;
phys_addr_t mcfg_addr;
};
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 3/7] ACPI, PCI: Protect global lists in drivers/acpi/pci_root.c
From: Jiang Liu
There are two global lists inf file drivers/acpi/pci_root.c.
One is for registered acpi_pci_drivers, the other is for
enumerated ACPI PCI root bridge objects. These two global
lists may change dynamically when registering/deregistering
acpi_pci_drivers or adding/removing ACPI PCI root bridge
objects. So protect them by mutex lock and RCU list.
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c | 87 --
1 files changed, 53 insertions(+), 34 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 9ba516b..f3402df 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -27,7 +27,8 @@
#include
#include
#include
-#include
+#include
+#include
#include
#include
#include
@@ -71,6 +72,8 @@ static struct acpi_driver acpi_pci_root_driver = {
},
};
+/* Lock to protect both acpi_pci_roots and acpi_pci_drivers lists */
+static DEFINE_MUTEX(acpi_pci_root_lock);
static LIST_HEAD(acpi_pci_roots);
static LIST_HEAD(acpi_pci_drivers);
@@ -81,47 +84,48 @@ int acpi_pci_register_driver(struct acpi_pci_driver *driver)
int n = 0;
struct acpi_pci_root *root;
+ mutex_lock(_pci_root_lock);
list_add_tail(>node, _pci_drivers);
-
- if (!driver->add)
- return 0;
-
- list_for_each_entry(root, _pci_roots, node) {
- driver->add(root->device->handle);
- n++;
- }
+ if (driver->add)
+ list_for_each_entry_rcu(root, _pci_roots, node) {
+ driver->add(root->device->handle);
+ n++;
+ }
+ mutex_unlock(_pci_root_lock);
return n;
}
-
EXPORT_SYMBOL(acpi_pci_register_driver);
void acpi_pci_unregister_driver(struct acpi_pci_driver *driver)
{
struct acpi_pci_root *root;
+ mutex_lock(_pci_root_lock);
list_del(>node);
-
- if (!driver->remove)
- return;
-
- list_for_each_entry(root, _pci_roots, node)
- driver->remove(root->device->handle);
+ if (driver->remove)
+ list_for_each_entry_rcu(root, _pci_roots, node)
+ driver->remove(root->device->handle);
+ mutex_unlock(_pci_root_lock);
}
-
EXPORT_SYMBOL(acpi_pci_unregister_driver);
acpi_handle acpi_get_pci_rootbridge_handle(unsigned int seg, unsigned int bus)
{
struct acpi_pci_root *root;
+ struct acpi_handle *handle = NULL;
- list_for_each_entry(root, _pci_roots, node)
+ rcu_read_lock();
+ list_for_each_entry_rcu(root, _pci_roots, node)
if ((root->segment == (u16) seg) &&
- (root->secondary.start == (u16) bus))
- return root->device->handle;
- return NULL;
-}
+ (root->secondary.start == (u16) bus)) {
+ handle = root->device->handle;
+ break;
+ }
+ rcu_read_unlock();
+ return handle;
+}
EXPORT_SYMBOL_GPL(acpi_get_pci_rootbridge_handle);
/**
@@ -268,10 +272,15 @@ struct acpi_pci_root *acpi_pci_find_root(acpi_handle
handle)
{
struct acpi_pci_root *root;
- list_for_each_entry(root, _pci_roots, node) {
- if (root->device->handle == handle)
+ rcu_read_lock();
+ list_for_each_entry_rcu(root, _pci_roots, node) {
+ if (root->device->handle == handle) {
+ rcu_read_unlock();
return root;
+ }
}
+ rcu_read_unlock();
+
return NULL;
}
EXPORT_SYMBOL_GPL(acpi_pci_find_root);
@@ -459,7 +468,7 @@ static int __devinit acpi_pci_root_add(struct acpi_device
*device)
if (ACPI_FAILURE(status) && status != AE_NOT_FOUND) {
printk(KERN_ERR PREFIX "can't evaluate _SEG\n");
result = -ENODEV;
- goto end;
+ goto out_free;
}
/* Check _CRS first, then _BBN. If no _BBN, default to zero. */
@@ -484,7 +493,7 @@ static int __devinit acpi_pci_root_add(struct acpi_device
*device)
else {
printk(KERN_ERR PREFIX "can't evaluate _BBN\n");
result = -ENODEV;
- goto end;
+ goto out_free;
}
}
@@ -508,8 +517,8 @@ static int __devinit acpi_pci_root_add(struct acpi_device
*device)
* TBD: Need PCI interface for enumeration/configuration of roots.
*/
- /* TBD: Locking */
- list_add_tail(>node, _pci_roots);
+ mutex_lock(_pci_root_lock);
+ list_add_tail_rcu(>node, _pci_roots);
printk(KERN_INFO PREFIX "%s [%s] (domain %04x %pR)\n",
acpi_device_name(device), acpi_device_bid(device),
@@ -528,7 +537,7 @@ static int __devinit acpi_pci_root_add(struct acpi_device
[PATCH part5 5/7] PCI: Set dev_node early for pci_dev
otherwise irq_desc for pci bridge with hot-added ioapic can not be on local node. Signed-off-by: Yinghai Lu --- drivers/pci/probe.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/pci/probe.c b/drivers/pci/probe.c index 59345ac..dd84224 100644 --- a/drivers/pci/probe.c +++ b/drivers/pci/probe.c @@ -1293,6 +1293,7 @@ void pci_device_add(struct pci_dev *dev, struct pci_bus *bus) dev->dev.release = pci_release_dev; pci_dev_get(dev); + set_dev_node(>dev, pcibus_to_node(bus)); dev->dev.dma_mask = >dma_mask; dev->dev.dma_parms = >dma_parms; dev->dev.coherent_dma_mask = 0xull; -- 1.7.7 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH part5 1/7] ACPI, PCI: Use normal list for struct acpi_pci_driver
From: Jiang Liu
Use normal list for struct acpi_pci_driver to simplify code.
Signed-off-by: Jiang Liu
Signed-off-by: Yinghai Lu
---
drivers/acpi/pci_root.c | 16 +++-
include/linux/acpi.h|2 +-
2 files changed, 4 insertions(+), 14 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index 12791fd..2aec08d 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -72,8 +72,8 @@ static struct acpi_driver acpi_pci_root_driver = {
};
static LIST_HEAD(acpi_pci_roots);
+static LIST_HEAD(acpi_pci_drivers);
-static struct acpi_pci_driver *sub_driver;
static DEFINE_MUTEX(osc_lock);
int acpi_pci_register_driver(struct acpi_pci_driver *driver)
@@ -81,10 +81,7 @@ int acpi_pci_register_driver(struct acpi_pci_driver *driver)
int n = 0;
struct acpi_pci_root *root;
- struct acpi_pci_driver **pptr = _driver;
- while (*pptr)
- pptr = &(*pptr)->next;
- *pptr = driver;
+ list_add_tail(>node, _pci_drivers);
if (!driver->add)
return 0;
@@ -103,14 +100,7 @@ void acpi_pci_unregister_driver(struct acpi_pci_driver
*driver)
{
struct acpi_pci_root *root;
- struct acpi_pci_driver **pptr = _driver;
- while (*pptr) {
- if (*pptr == driver)
- break;
- pptr = &(*pptr)->next;
- }
- BUG_ON(!*pptr);
- *pptr = (*pptr)->next;
+ list_del(>node);
if (!driver->remove)
return;
diff --git a/include/linux/acpi.h b/include/linux/acpi.h
index 3ad510b..a54cf8e 100644
--- a/include/linux/acpi.h
+++ b/include/linux/acpi.h
@@ -138,7 +138,7 @@ void acpi_penalize_isa_irq(int irq, int active);
void acpi_pci_irq_disable (struct pci_dev *dev);
struct acpi_pci_driver {
- struct acpi_pci_driver *next;
+ struct list_head node;
int (*add)(acpi_handle handle);
void (*remove)(acpi_handle handle);
};
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 09/11] PCI, acpiphp: Use acpi_hp_work
Remove local defined acpiphp_hp_work.
Signed-off-by: Yinghai Lu
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
drivers/pci/hotplug/acpiphp_glue.c | 42 +--
1 files changed, 6 insertions(+), 36 deletions(-)
diff --git a/drivers/pci/hotplug/acpiphp_glue.c
b/drivers/pci/hotplug/acpiphp_glue.c
index dc54d57..a4c5a81 100644
--- a/drivers/pci/hotplug/acpiphp_glue.c
+++ b/drivers/pci/hotplug/acpiphp_glue.c
@@ -1193,34 +1193,6 @@ check_sub_bridges(acpi_handle handle, u32 lvl, void
*context, void **rv)
return AE_OK ;
}
-struct acpiphp_hp_work {
- struct work_struct work;
- acpi_handle handle;
- u32 type;
- void *context;
-};
-
-static void alloc_acpiphp_hp_work(acpi_handle handle, u32 type,
- void *context,
- void (*func)(struct work_struct *work))
-{
- struct acpiphp_hp_work *hp_work;
- int ret;
-
- hp_work = kmalloc(sizeof(*hp_work), GFP_KERNEL);
- if (!hp_work)
- return;
-
- hp_work->handle = handle;
- hp_work->type = type;
- hp_work->context = context;
-
- INIT_WORK(_work->work, func);
- ret = queue_work(kacpi_hotplug_wq, _work->work);
- if (!ret)
- kfree(hp_work);
-}
-
static void _handle_hotplug_event_bridge(struct work_struct *work)
{
struct acpiphp_bridge *bridge;
@@ -1229,11 +1201,11 @@ static void _handle_hotplug_event_bridge(struct
work_struct *work)
.pointer = objname };
struct acpi_device *device;
int num_sub_bridges = 0;
- struct acpiphp_hp_work *hp_work;
+ struct acpi_hp_work *hp_work;
acpi_handle handle;
u32 type;
- hp_work = container_of(work, struct acpiphp_hp_work, work);
+ hp_work = container_of(work, struct acpi_hp_work, work);
handle = hp_work->handle;
type = hp_work->type;
@@ -1336,8 +1308,7 @@ static void handle_hotplug_event_bridge(acpi_handle
handle, u32 type,
* For now just re-add this work to the kacpi_hotplug_wq so we
* don't deadlock on hotplug actions.
*/
- alloc_acpiphp_hp_work(handle, type, context,
- _handle_hotplug_event_bridge);
+ alloc_acpi_hp_work(handle, type, context, _handle_hotplug_event_bridge);
}
static void _handle_hotplug_event_func(struct work_struct *work)
@@ -1346,12 +1317,12 @@ static void _handle_hotplug_event_func(struct
work_struct *work)
char objname[64];
struct acpi_buffer buffer = { .length = sizeof(objname),
.pointer = objname };
- struct acpiphp_hp_work *hp_work;
+ struct acpi_hp_work *hp_work;
acpi_handle handle;
u32 type;
void *context;
- hp_work = container_of(work, struct acpiphp_hp_work, work);
+ hp_work = container_of(work, struct acpi_hp_work, work);
handle = hp_work->handle;
type = hp_work->type;
context = hp_work->context;
@@ -1412,8 +1383,7 @@ static void handle_hotplug_event_func(acpi_handle handle,
u32 type,
* For now just re-add this work to the kacpi_hotplug_wq so we
* don't deadlock on hotplug actions.
*/
- alloc_acpiphp_hp_work(handle, type, context,
- _handle_hotplug_event_func);
+ alloc_acpi_hp_work(handle, type, context, _handle_hotplug_event_func);
}
static struct acpi_pci_driver acpi_pci_hp_driver = {
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 06/11] PCI, ACPI: Make acpi_pci_root_remove remove pci root bus too
It will call new added pci_stop_and_remove_bus() to stop/remove pci root bus.
Also checking if that pci_root_bus get removed already in bus remove in /sys
Signed-off-by: Yinghai Lu
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/pci_root.c | 14 ++
1 files changed, 14 insertions(+), 0 deletions(-)
diff --git a/drivers/acpi/pci_root.c b/drivers/acpi/pci_root.c
index ec54014..12791fd 100644
--- a/drivers/acpi/pci_root.c
+++ b/drivers/acpi/pci_root.c
@@ -645,10 +645,24 @@ static int acpi_pci_root_remove(struct acpi_device
*device, int type)
{
struct acpi_pci_root *root = acpi_driver_data(device);
+ /* that root bus could be removed already */
+ if (!pci_find_bus(root->segment, root->secondary.start)) {
+ dev_printk(KERN_DEBUG, >dev,
+ "freeing acpi_pci_root, but pci root bus was removed before");
+ goto out;
+ }
+
device_set_run_wake(root->bus->bridge, false);
pci_acpi_remove_bus_pm_notifier(device);
+ dev_printk(KERN_DEBUG, >dev,
+ "freeing acpi_pci_root, will remove pci root bus at first");
+ pci_stop_and_remove_bus(root->bus);
+
+out:
+ list_del(>node);
kfree(root);
+
return 0;
}
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH part4 05/11] PCI, acpiphp: Separate out hot-add support of pci host bridge
It causes confusion.
We may only need acpi hp for pci host bridge.
Split host bridge hot-add support to pci_root_hp, and keep acpiphp simple.
Also remove not used res_lock in the struct.
-v2: put back pci_root_hp change in one patch
-v3: add pcibios_resource_survey_bus() calling
-v4: remove not needed code with remove_bridge
-v5: put back support for acpiphp support for slots just on root bus.
Signed-off-by: Yinghai Lu
---
drivers/acpi/Makefile |1 +
drivers/acpi/pci_root_hp.c | 238
drivers/pci/hotplug/acpiphp_glue.c | 37 +-
3 files changed, 246 insertions(+), 30 deletions(-)
create mode 100644 drivers/acpi/pci_root_hp.c
diff --git a/drivers/acpi/Makefile b/drivers/acpi/Makefile
index 47199e2..c9abd4c 100644
--- a/drivers/acpi/Makefile
+++ b/drivers/acpi/Makefile
@@ -36,6 +36,7 @@ acpi-y+= processor_core.o
acpi-y += ec.o
acpi-$(CONFIG_ACPI_DOCK) += dock.o
acpi-y += pci_root.o pci_link.o pci_irq.o pci_bind.o
+acpi-$(CONFIG_HOTPLUG) += pci_root_hp.o
acpi-y += power.o
acpi-y += event.o
acpi-y += sysfs.o
diff --git a/drivers/acpi/pci_root_hp.c b/drivers/acpi/pci_root_hp.c
new file mode 100644
index 000..e07c31b
--- /dev/null
+++ b/drivers/acpi/pci_root_hp.c
@@ -0,0 +1,238 @@
+/*
+ * Separated from drivers/pci/hotplug/acpiphp_glue.c
+ * only support root bridge
+ */
+
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+
+static LIST_HEAD(acpi_root_bridge_list);
+struct acpi_root_bridge {
+ struct list_head list;
+ acpi_handle handle;
+ u32 flags;
+};
+
+/* bridge flags */
+#define ROOT_BRIDGE_HAS_EJ0(0x0002)
+#define ROOT_BRIDGE_HAS_PS3(0x0080)
+
+#define ACPI_STA_FUNCTIONING (0x0008)
+
+static struct acpi_root_bridge *acpi_root_handle_to_bridge(acpi_handle handle)
+{
+ struct acpi_root_bridge *bridge;
+
+ list_for_each_entry(bridge, _root_bridge_list, list)
+ if (bridge->handle == handle)
+ return bridge;
+
+ return NULL;
+}
+
+/* allocate and initialize host bridge data structure */
+static void add_acpi_root_bridge(acpi_handle handle)
+{
+ struct acpi_root_bridge *bridge;
+ acpi_handle dummy_handle;
+ acpi_status status;
+
+ /* if the bridge doesn't have _STA, we assume it is always there */
+ status = acpi_get_handle(handle, "_STA", _handle);
+ if (ACPI_SUCCESS(status)) {
+ unsigned long long tmp;
+
+ status = acpi_evaluate_integer(handle, "_STA", NULL, );
+ if (ACPI_FAILURE(status)) {
+ printk(KERN_DEBUG "%s: _STA evaluation failure\n",
+__func__);
+ return;
+ }
+ if ((tmp & ACPI_STA_FUNCTIONING) == 0)
+ /* don't register this object */
+ return;
+ }
+
+ bridge = kzalloc(sizeof(struct acpi_root_bridge), GFP_KERNEL);
+ if (!bridge)
+ return;
+
+ bridge->handle = handle;
+
+ if (ACPI_SUCCESS(acpi_get_handle(handle, "_EJ0", _handle)))
+ bridge->flags |= ROOT_BRIDGE_HAS_EJ0;
+ if (ACPI_SUCCESS(acpi_get_handle(handle, "_PS3", _handle)))
+ bridge->flags |= ROOT_BRIDGE_HAS_PS3;
+
+ list_add(>list, _root_bridge_list);
+}
+
+struct acpi_root_hp_work {
+ struct work_struct work;
+ acpi_handle handle;
+ u32 type;
+ void *context;
+};
+
+static void alloc_acpi_root_hp_work(acpi_handle handle, u32 type,
+ void *context,
+ void (*func)(struct work_struct *work))
+{
+ struct acpi_root_hp_work *hp_work;
+ int ret;
+
+ hp_work = kmalloc(sizeof(*hp_work), GFP_KERNEL);
+ if (!hp_work)
+ return;
+
+ hp_work->handle = handle;
+ hp_work->type = type;
+ hp_work->context = context;
+
+ INIT_WORK(_work->work, func);
+ ret = queue_work(kacpi_hotplug_wq, _work->work);
+ if (!ret)
+ kfree(hp_work);
+}
+
+/* Program resources in newly inserted bridge */
+static void acpi_root_configure_bridge(acpi_handle handle)
+{
+ struct acpi_pci_root *root = acpi_pci_find_root(handle);
+
+ pcibios_resource_survey_bus(root->bus);
+ pci_assign_unassigned_bus_resources(root->bus);
+}
+
+static void handle_root_bridge_insertion(acpi_handle handle)
+{
+ struct acpi_device *device, *pdevice;
+ acpi_handle phandle;
+ int ret_val;
+
+ acpi_get_parent(handle, );
+ if (acpi_bus_get_device(phandle, )) {
+ printk(KERN_DEBUG "no parent device, assuming NULL\n");
+ pdevice = NULL;
+ }
+ if
[PATCH part4 11/11] PCI, ACPI: Make kacpi_hotplug_wq static
No external user anymore.
Signed-off-by: Yinghai Lu
Cc: Len Brown
Cc: linux-a...@vger.kernel.org
---
drivers/acpi/osl.c |3 +--
include/acpi/acpiosxf.h |2 --
2 files changed, 1 insertions(+), 4 deletions(-)
diff --git a/drivers/acpi/osl.c b/drivers/acpi/osl.c
index 0719fa7..311a921 100644
--- a/drivers/acpi/osl.c
+++ b/drivers/acpi/osl.c
@@ -84,8 +84,7 @@ static acpi_osd_handler acpi_irq_handler;
static void *acpi_irq_context;
static struct workqueue_struct *kacpid_wq;
static struct workqueue_struct *kacpi_notify_wq;
-struct workqueue_struct *kacpi_hotplug_wq;
-EXPORT_SYMBOL(kacpi_hotplug_wq);
+static struct workqueue_struct *kacpi_hotplug_wq;
/*
* This list of permanent mappings is for memory that may be accessed from
diff --git a/include/acpi/acpiosxf.h b/include/acpi/acpiosxf.h
index 6ff92ea..9f68f69 100644
--- a/include/acpi/acpiosxf.h
+++ b/include/acpi/acpiosxf.h
@@ -194,8 +194,6 @@ void acpi_os_fixed_event_count(u32 fixed_event_number);
/*
* Threads and Scheduling
*/
-extern struct workqueue_struct *kacpi_hotplug_wq;
-
struct acpi_hp_work {
struct work_struct work;
acpi_handle handle;
--
1.7.7
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
