Re: Why kmem_cache_free occupy CPU for more than 10 seconds?
On 4/11/07, Zhao Forrest <[EMAIL PROTECTED]> wrote: We're using RHEL5 with kernel version 2.6.18-8.el5. When doing a stress test on raw device for about 3-4 hours, we found the soft lockup message in dmesg. I know we're not reporting the bug on the latest kernel, but does any expert know if this is the known issue in old kernel? Or why kmem_cache_free occupy CPU for more than 10 seconds? Sounds like slab corruption. CONFIG_DEBUG_SLAB should tell you more. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
On Wed, Apr 11, 2007 at 02:23:49PM +0800, Fengguang Wu wrote: >On Sun, Apr 01, 2007 at 02:20:46PM +0800, Cong WANG wrote: >> 2007/4/1, Andrew Morton <[EMAIL PROTECTED]>: >> > >> >Also, please always prepare patches in `patch -p1' form, as per >> >http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks. >> > >> > >> >> Sorry. I am confused with this. Does that mean I should make patches >> _upon_ the root kernel source directory or first make a copy of the >> original source code and then diff against the two dirs? But I was >> told that "patches should be based _in_ the root kernel source >> directory" and when only one file was modified just to diff it with >> the original single file. (See Documentation/SubmittingPatches.) >> >> Can you help out? And should I remake this patch? Thanks again! > >quilt(http://savannah.nongnu.org/projects/quilt) is your friend. > >cd /usr/src/linux >quilt new my-fix.patch >quilt edit mm/readahead.c >quilt refresh --diffstat >quilt diff >... Thanks. I will try it. ;-) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm3 PATCH] (Retry) Check the return value of kobject_add and etc.
On Tue, Apr 10, 2007 at 03:18:15PM -0700, Andrew Morton wrote:
>On Tue, 10 Apr 2007 22:08:29 +0800
>WANG Cong <[EMAIL PROTECTED]> wrote:
>
>> Since kobject_add, sysfs_create_link and sysfs_create_file are marked as
>> '__must_check', we must always check their return values.
>>
>
>Your mail client replaces tabs with spaces - please fix it.
>
Oh, I did't notice that. Thank you. I will fix it soon.
>The code duplication is unpleasing. We normally do this as below (please
>review this code).
>
Er, I see.
>Note that I changed it to not send the KOBJ_REMOVE if we didn't send a
>KOBJ_ADD.
>
I think you are right.
>
>From: WANG Cong <[EMAIL PROTECTED]>
>
>Since kobject_add, sysfs_create_link and sysfs_create_file are marked as
>'__must_check', we must always check their return values.
>
>Signed-off-by: WANG Cong <[EMAIL PROTECTED]>
>Acked-by: Cornelia Huck <[EMAIL PROTECTED]>
>Signed-off-by: Andrew Morton <[EMAIL PROTECTED]>
>---
>
> fs/partitions/check.c | 25 -
> 1 files changed, 20 insertions(+), 5 deletions(-)
>
>diff -puN
>fs/partitions/check.c~partitions-check-the-return-value-of-kobject_add-etc
>fs/partitions/check.c
>---
>a/fs/partitions/check.c~partitions-check-the-return-value-of-kobject_add-etc
>+++ a/fs/partitions/check.c
>@@ -383,26 +383,41 @@ void add_partition(struct gendisk *disk,
> p->policy = disk->policy;
>
> if (isdigit(disk->kobj.name[strlen(disk->kobj.name)-1]))
>-
>snprintf(p->kobj.name,KOBJ_NAME_LEN,"%sp%d",disk->kobj.name,part);
>+ snprintf(p->kobj.name, KOBJ_NAME_LEN, "%sp%d",
>+ disk->kobj.name, part);
^^^
Andrew, it seems that you left an additional whitespace in the above line
(marked as ^^^).
> else
>-
>snprintf(p->kobj.name,KOBJ_NAME_LEN,"%s%d",disk->kobj.name,part);
>+ snprintf(p->kobj.name, KOBJ_NAME_LEN, "%s%d",
>+ disk->kobj.name, part);
^^^
Also here. ;-p
> p->kobj.parent = &disk->kobj;
> p->kobj.ktype = &ktype_part;
> kobject_init(&p->kobj);
>- kobject_add(&p->kobj);
>+ if (kobject_add(&p->kobj))
>+ goto out_put;
> if (!disk->part_uevent_suppress)
> kobject_uevent(&p->kobj, KOBJ_ADD);
>- sysfs_create_link(&p->kobj, &block_subsys.kset.kobj, "subsystem");
>+ if (sysfs_create_link(&p->kobj, &block_subsys.kset.kobj, "subsystem"))
>+ goto out_uevent;
> if (flags & ADDPART_FLAG_WHOLEDISK) {
> static struct attribute addpartattr = {
> .name = "whole_disk",
> .mode = S_IRUSR | S_IRGRP | S_IROTH,
> };
>
>- sysfs_create_file(&p->kobj, &addpartattr);
>+ if (sysfs_create_file(&p->kobj, &addpartattr))
>+ goto out_link;
> }
> partition_sysfs_add_subdir(p);
> disk->part[part-1] = p;
>+ return;
>+
>+out_link:
>+ sysfs_remove_link(&p->kobj, "subsystem");
>+out_uevent:
>+ if (!disk->part_uevent_suppress)
>+ kobject_uevent(&p->kobj, KOBJ_REMOVE);
>+ kobject_del(&p->kobj);
>+out_put:
>+ kobject_put(&p->kobj);
> }
>
> static char *make_block_name(struct gendisk *disk)
>_
Your code is better. Thanks again!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: link error : 2.6.21-rc6-mm1 for s390
On Tue, 10 Apr 2007 22:11:01 -0700 (PDT) David Miller <[EMAIL PROTECTED]> wrote:
> diff --git a/arch/s390/lib/Makefile b/arch/s390/lib/Makefile
> index 7a44fed..59aea65 100644
> --- a/arch/s390/lib/Makefile
> +++ b/arch/s390/lib/Makefile
> @@ -5,6 +5,6 @@
> EXTRA_AFLAGS := -traditional
>
> lib-y += delay.o string.o uaccess_std.o uaccess_pt.o qrnnd.o
> -lib-$(CONFIG_32BIT) += div64.o
> +obj-$(CONFIG_32BIT) += div64.o
> lib-$(CONFIG_64BIT) += uaccess_mvcos.o
> lib-$(CONFIG_SMP) += spinlock.o
> diff --git a/arch/s390/lib/div64.c b/arch/s390/lib/div64.c
> index 0481f34..a5f8300 100644
> --- a/arch/s390/lib/div64.c
> +++ b/arch/s390/lib/div64.c
> @@ -147,5 +147,3 @@ uint32_t __div64_32(uint64_t *n, uint32_t base)
> }
>
> #endif /* MARCH_G5 */
> -
> -EXPORT_SYMBOL(__div64_32);
> diff --git a/lib/div64.c b/lib/div64.c
> index 74f0c8c..b71cf93 100644
> --- a/lib/div64.c
> +++ b/lib/div64.c
> @@ -23,7 +23,7 @@
> /* Not needed on 64bit architectures */
> #if BITS_PER_LONG == 32
>
> -uint32_t __div64_32(uint64_t *n, uint32_t base)
> +uint32_t __attribute__((weak)) __div64_32(uint64_t *n, uint32_t base)
> {
> uint64_t rem = *n;
> uint64_t b = base;
I think this means that if CONFIG_32BIT=y, s390 networking gets the whizzy
assembly version and if CONFIG_32BIT=n, it gets to use the generic version.
Possibly the whizzy version could be used if CONFIG_32BIT=n, too. But
I'd let the s390 people worry about that ;)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 6/13] maps#2: Move the page walker code to lib/
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
Still should go into mm/
If it had, you might have also noticed your pagetable walking code
is completely different from how everyone else does it, and fixed
that too.
BTW. Is it the case that unused and unexported symbols don't get
pruned by the linker except inside lib/?
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-27 22:13:43.0 -0500
+++ mm/fs/proc/task_mmu.c 2007-03-27 22:13:51.0 -0500
@@ -280,123 +280,6 @@ static int clear_refs_pte_range(pmd_t *p
return 0;
}
-struct mm_walk {
- int (*pgd_entry)(pgd_t *, unsigned long, unsigned long, void *);
- int (*pud_entry)(pud_t *, unsigned long, unsigned long, void *);
- int (*pmd_entry)(pmd_t *, unsigned long, unsigned long, void *);
- int (*pte_entry)(pte_t *, unsigned long, unsigned long, void *);
-};
-
-static int walk_pte_range(pmd_t *pmd, unsigned long addr, unsigned long end,
- struct mm_walk *walk, void *private)
-{
- pte_t *pte;
- int err;
-
- for (pte = pte_offset_map(pmd, addr); addr != end;
-addr += PAGE_SIZE, pte++) {
- if (pte_none(*pte))
- continue;
- err = walk->pte_entry(pte, addr, addr, private);
- if (err) {
- pte_unmap(pte);
- return err;
- }
- }
- pte_unmap(pte);
- return 0;
-}
-
-static int walk_pmd_range(pud_t *pud, unsigned long addr, unsigned long end,
- struct mm_walk *walk, void *private)
-{
- pmd_t *pmd;
- unsigned long next;
- int err;
-
- for (pmd = pmd_offset(pud, addr); addr != end;
-pmd++, addr = next) {
- next = pmd_addr_end(addr, end);
- if (pmd_none_or_clear_bad(pmd))
- continue;
- if (walk->pmd_entry) {
- err = walk->pmd_entry(pmd, addr, next, private);
- if (err)
- return err;
- }
- if (walk->pte_entry) {
- err = walk_pte_range(pmd, addr, next, walk, private);
- if (err)
- return err;
- }
- }
- return 0;
-}
-
-static int walk_pud_range(pgd_t *pgd, unsigned long addr, unsigned long end,
- struct mm_walk *walk, void *private)
-{
- pud_t *pud;
- unsigned long next;
- int err;
-
- for (pud = pud_offset(pgd, addr); addr != end;
-pud++, addr = next) {
- next = pud_addr_end(addr, end);
- if (pud_none_or_clear_bad(pud))
- continue;
- if (walk->pud_entry) {
- err = walk->pud_entry(pud, addr, next, private);
- if (err)
- return err;
- }
- if (walk->pmd_entry || walk->pte_entry) {
- err = walk_pmd_range(pud, addr, next, walk, private);
- if (err)
- return err;
- }
- }
- return 0;
-}
-
-/*
- * walk_page_range - walk a memory map's page tables with a callback
- * @mm - memory map to walk
- * @addr - starting address
- * @end - ending address
- * @action - callback invoked for every bottom-level (PTE) page table
- * @private - private data passed to the callback function
- *
- * Recursively walk the page table for the memory area in a VMA, calling
- * a callback for every bottom-level (PTE) page table.
- */
-static int walk_page_range(struct mm_struct *mm,
- unsigned long addr, unsigned long end,
- struct mm_walk *walk, void *private)
-{
- pgd_t *pgd;
- unsigned long next;
- int err;
-
- for (pgd = pgd_offset(mm, addr); addr != end;
-pgd++, addr = next) {
- next = pgd_addr_end(addr, end);
- if (pgd_none_or_clear_bad(pgd))
- continue;
- if (walk->pgd_entry) {
- err = walk->pgd_entry(pgd, addr, next, private);
- if (err)
- return err;
- }
- if (walk->pud_entry || walk->pmd_entry || walk->pte_entry) {
- err = walk_pud_range(pgd, addr, next, walk, private);
- if (err)
- return err;
- }
- }
- return 0;
-}
-
static struct mm_walk smaps_walk = { .pmd_entry = smaps_pte_range };
static int show_smap(struct seq_file *m, void *v)
Index: mm/i
Re: [PATCH 0/4] hard_smp_processor_id overhaul (v.2)
On Wed, Apr 04, 2007 at 05:51:07PM +0900, Fernando Luis Vázquez Cao wrote:
> This new version (v.2) fixes generic arch i386 up build, has (hopefully)
> clearer explanations, and does not break git bisect searches.
> ---
> With the advent of kdump, the assumption that the boot CPU when running
> an UP kernel is always the CPU with a particular hardware ID (often 0)
> (usually referred to as BSP on some architectures) is not valid anymore.
> The reason being that the dump capture kernel boots on the crashed CPU
> (the CPU that invoked crash_kexec), which may be or may not be that
> particular CPU.
>
> As a consequence, the hardcoding of hard_smp_processor_id() to 0 on UP
> systems (see "linux/smp.h") is not correct.
>
> This patch-set does the following:
>
> 1- Remove hardcoding of hard_smp_processor_id on UP systems (patch 1).
>
> 2- Move definition of hard_smp_processor_id for the UP case to
> architecture specific code ("asm/smp.h") where it belongs, so that each
> architecture can provide its own implementation (patch 1).
>
> 3- Ask the hardware when possible to obtain the hardware processor id on
> i386 (patch 2), x86_64 (patch 3), and ia64 (patch 4), independently of
> whether CONFIG_SMP is set or not.
>
> I guess that something similar could be done for the rest of the
> architectures, but since I am not an expert in all of them I am just
> moving the definition of hard_smp_processor_id to "asm/smp.h" for those.
> Of course, help from the respective maintainers to fill this gap would
> be greatly appreciated.
>
> The patches have been tested on i386, x86_64, and ia64.
Sorry for the delay in getting back to you, I've been on the road.
All these patches seem fine to me.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [-mm3 patch]Warning fix: check the return value of kobject_add etc.
On Sun, Apr 01, 2007 at 02:20:46PM +0800, Cong WANG wrote: > 2007/4/1, Andrew Morton <[EMAIL PROTECTED]>: > > > >Also, please always prepare patches in `patch -p1' form, as per > >http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt, thanks. > > > > > > Sorry. I am confused with this. Does that mean I should make patches > _upon_ the root kernel source directory or first make a copy of the > original source code and then diff against the two dirs? But I was > told that "patches should be based _in_ the root kernel source > directory" and when only one file was modified just to diff it with > the original single file. (See Documentation/SubmittingPatches.) > > Can you help out? And should I remake this patch? Thanks again! quilt(http://savannah.nongnu.org/projects/quilt) is your friend. cd /usr/src/linux quilt new my-fix.patch quilt edit mm/readahead.c quilt refresh --diffstat quilt diff ... - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Doc for your Adaptive ReadAhead patch
On Wed, Apr 11, 2007 at 04:44:34AM +, Jin Steve wrote:
> Just like the function check_ra_success: (Does it mean: last time
> RA>VM_MAX_CACHE_HIT, so next time no need readahead?)
The cache hit logic is to prevent doing pointless readahead for
an already cached file: the pages are already there.
VM_MAX_CACHE_HIT is the threshold to disable readahead in this case.
> static inline int check_ra_success(struct file_ra_state *ra,
> unsigned long nr_to_read, unsigned long actual)
> {
> if (actual == 0) {
> ra->cache_hit += nr_to_read;
> if (ra->cache_hit >= VM_MAX_CACHE_HIT) {
> ra_off(ra);
> ra->flags |= RA_FLAG_INCACHE;
> return 0;
> }
> } else {
> ra->cache_hit=0;
> }
> return 1;
> }
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] uninline remove/add_parent() APIs
here's a (tested) patch i did that should simplify changes done to
p->children and p->sibling handling.
Ingo
-->
Subject: [patch] uninline remove/add_parent() APIs
From: Ingo Molnar <[EMAIL PROTECTED]>
uninline/simplify remove/add_parent() APIs.
Signed-off-by: Ingo Molnar <[EMAIL PROTECTED]>
---
include/linux/sched.h |5 +++--
kernel/exit.c | 31 +--
kernel/fork.c |2 +-
kernel/ptrace.c | 11 ---
4 files changed, 29 insertions(+), 20 deletions(-)
Index: linux/include/linux/sched.h
===
--- linux.orig/include/linux/sched.h
+++ linux/include/linux/sched.h
@@ -1418,8 +1418,9 @@ extern void wait_task_inactive(struct ta
#define wait_task_inactive(p) do { } while (0)
#endif
-#define remove_parent(p) list_del_init(&(p)->sibling)
-#define add_parent(p)
list_add_tail(&(p)->sibling,&(p)->parent->children)
+extern void
+task_relink_parent(struct task_struct *p, struct task_struct *new_real_parent,
+ struct task_struct *new_parent);
#define next_task(p) list_entry(rcu_dereference((p)->tasks.next), struct
task_struct, tasks)
Index: linux/kernel/exit.c
===
--- linux.orig/kernel/exit.c
+++ linux/kernel/exit.c
@@ -52,6 +52,20 @@ extern void sem_exit (void);
static void exit_mm(struct task_struct * tsk);
+void
+task_relink_parent(struct task_struct *p,
+ struct task_struct *new_real_parent,
+ struct task_struct *new_parent)
+{
+ /*
+* Move this task to a new parent's children list.
+* (if p->parent == new->parent this this requeues from head to tail)
+*/
+ list_move_tail(&p->sibling, &new_parent->children);
+ p->real_parent = new_real_parent;
+ p->parent = new_parent;
+}
+
static void __unhash_process(struct task_struct *p)
{
nr_threads--;
@@ -64,7 +78,7 @@ static void __unhash_process(struct task
__get_cpu_var(process_counts)--;
}
list_del_rcu(&p->thread_group);
- remove_parent(p);
+ list_del_init(&p->sibling);
}
/*
@@ -268,14 +282,14 @@ static int has_stopped_jobs(struct pid *
*/
static void reparent_to_init(void)
{
+ struct task_struct *reaper;
+
write_lock_irq(&tasklist_lock);
ptrace_unlink(current);
/* Reparent to init */
- remove_parent(current);
- current->parent = child_reaper(current);
- current->real_parent = child_reaper(current);
- add_parent(current);
+ reaper = child_reaper(current);
+ task_relink_parent(current, reaper, reaper);
/* Set the exit signal to SIGCHLD so we signal init on exit */
current->exit_signal = SIGCHLD;
@@ -611,9 +625,7 @@ reparent_thread(struct task_struct *p, s
* anyway, so let go of it.
*/
p->ptrace = 0;
- remove_parent(p);
- p->parent = p->real_parent;
- add_parent(p);
+ task_relink_parent(p, p->real_parent, p->real_parent);
if (p->state == TASK_TRACED) {
/*
@@ -1344,8 +1356,7 @@ bail_ref:
}
/* move to end of parent's list to avoid starvation */
- remove_parent(p);
- add_parent(p);
+ task_relink_parent(p, p->real_parent, p->parent);
write_unlock_irq(&tasklist_lock);
Index: linux/kernel/fork.c
===
--- linux.orig/kernel/fork.c
+++ linux/kernel/fork.c
@@ -1242,7 +1242,7 @@ static struct task_struct *copy_process(
}
if (likely(p->pid)) {
- add_parent(p);
+ list_add_tail(&p->sibling, &p->parent->children);
if (unlikely(p->ptrace & PT_PTRACED))
__ptrace_link(p, current->parent);
Index: linux/kernel/ptrace.c
===
--- linux.orig/kernel/ptrace.c
+++ linux/kernel/ptrace.c
@@ -34,11 +34,9 @@ void __ptrace_link(struct task_struct *c
if (child->parent == new_parent)
return;
list_add(&child->ptrace_list, &child->parent->ptrace_children);
- remove_parent(child);
- child->parent = new_parent;
- add_parent(child);
+ task_relink_parent(child, new_parent, child->real_parent);
}
-
+
/*
* Turn a tracing stop into a normal stop now, since with no tracer there
* would be no way to wake it up with SIGCONT or SIGKILL. If there was a
@@ -72,9 +70,8 @@ void __ptrace_unlink(struct task_struct
child->ptrace = 0;
if (!list_empty(&child->ptrace_list)) {
list_del_init(&child->ptrace_list);
- remove_parent(child);
- child->parent = child->real_parent;
- add_parent(child);
+
Why kmem_cache_free occupy CPU for more than 10 seconds?
Hi, We're using RHEL5 with kernel version 2.6.18-8.el5. When doing a stress test on raw device for about 3-4 hours, we found the soft lockup message in dmesg. I know we're not reporting the bug on the latest kernel, but does any expert know if this is the known issue in old kernel? Or why kmem_cache_free occupy CPU for more than 10 seconds? Please let me know if you need any information. Thanks, Forrest -- BUG: soft lockup detected on CPU#1! Call Trace: [] softlockup_tick+0xdb/0xed [] update_process_times+0x42/0x68 [] smp_local_timer_interrupt+0x23/0x47 [] smp_apic_timer_interrupt+0x41/0x47 [] apic_timer_interrupt+0x66/0x6c [] kmem_cache_free+0x1c0/0x1cb [] free_buffer_head+0x2a/0x43 [] try_to_free_buffers+0x89/0x9d [] invalidate_mapping_pages+0x90/0x15f [] kill_bdev+0xe/0x21 [] __blkdev_put+0x4f/0x169 [] __fput+0xae/0x198 [] filp_close+0x5c/0x64 [] put_files_struct+0x6c/0xc3 [] do_exit+0x2d2/0x8b1 [] cpuset_exit+0x0/0x6c [] get_signal_to_deliver+0x427/0x456 [] do_notify_resume+0x9c/0x7a9 [] default_wake_function+0x0/0xe [] audit_syscall_exit+0x2cd/0x2ec [] int_signal+0x12/0x17 -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/13] fs: convert core functions to zero_user_page
On 4/10/07, Andrew Morton <[EMAIL PROTECTED]> wrote:
On Tue, 10 Apr 2007 20:36:00 -0700 Nate Diller <[EMAIL PROTECTED]> wrote:
> It's very common for file systems to need to zero part or all of a page, the
> simplist way is just to use kmap_atomic() and memset(). There's actually a
> library function in include/linux/highmem.h that does exactly that, but it's
> confusingly named memclear_highpage_flush(), which is descriptive of *how*
> it does the work rather than what the *purpose* is. So this patchset
> renames the function to zero_user_page(), and calls it from the various
> places that currently open code it.
>
> This first patch introduces the new function call, and converts all the core
> kernel callsites, both the open-coded ones and the old
> memclear_highpage_flush() ones. Following this patch is a series of
> conversions for each file system individually, per AKPM, and finally a patch
> deprecating the old call.
For the reasons Anton identified, I think it is better design while we're here
to force callers to pass in the kmap-type which they wish to use for the atomic
kmap. It makes the programmer think about what he wants to happen. The price
of getting this wrong tends to be revoltingly rare file corruption.
yeah, I actually agree with you, on thinking about it. Thanks for
doing the conversion :)
But we cannot make this change in the obvious fashion, because the KM_FOO
identifiers are undefined if CONFIG_HIGHMEM=n. So
zero_user_page(page, 1, 2, KM_USER0);
won't compile on non-highmem.
So we are forced to use a macro, like below.
Also, you forgot to mark memclear_highpage_flush() __deprecated.
that follows in a later patch ... for some reason I had trouble
compiling using your notation, and i had to add a function prototype
with the __deprecated flag. shrug.
And I'm surprised that this:
+static inline void memclear_highpage_flush(struct page *page, unsigned int
offset, unsigned int size)
+{
+ return zero_user_page(page, offset, size);
+}
compiled. zero_user_page() returns void...
it's funny, it didn't even warn about it. also it seems your version
below is incomplete ... shouldn't it read:
+static inline void memclear_highpage_flush(struct page *page,
+ unsigned int offset, unsigned int size) __deprecated
{
- return zero_user_page(page, offset, size);
+ zero_user_page(page, offset, size, KM_USER0);
}
NATE
drivers/block/loop.c|2 +-
fs/buffer.c | 21 -
fs/direct-io.c |2 +-
fs/mpage.c |6 --
include/linux/highmem.h | 29 +
mm/filemap_xip.c|2 +-
6 files changed, 36 insertions(+), 26 deletions(-)
diff -puN
drivers/block/loop.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
drivers/block/loop.c
---
a/drivers/block/loop.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
+++ a/drivers/block/loop.c
@@ -250,7 +250,7 @@ static int do_lo_send_aops(struct loop_d
*/
printk(KERN_ERR "loop: transfer error block %llu\n",
(unsigned long long)index);
- zero_user_page(page, offset, size);
+ zero_user_page(page, offset, size, KM_USER0);
}
flush_dcache_page(page);
ret = aops->commit_write(file, page, offset,
diff -puN
fs/buffer.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
fs/buffer.c
--- a/fs/buffer.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
+++ a/fs/buffer.c
@@ -1855,7 +1855,7 @@ static int __block_prepare_write(struct
break;
if (buffer_new(bh)) {
clear_buffer_new(bh);
- zero_user_page(page, block_start, bh->b_size);
+ zero_user_page(page, block_start, bh->b_size, KM_USER0);
set_buffer_uptodate(bh);
mark_buffer_dirty(bh);
}
@@ -1943,7 +1943,8 @@ int block_read_full_page(struct page *pa
SetPageError(page);
}
if (!buffer_mapped(bh)) {
- zero_user_page(page, i * blocksize, blocksize);
+ zero_user_page(page, i * blocksize, blocksize,
+ KM_USER0);
if (!err)
set_buffer_uptodate(bh);
continue;
@@ -2107,7 +2108,8 @@ int cont_prepare_write(struct page *page
PAGE_CACHE_SIZE, get_block);
if (status)
goto out_unmap;
- zero_user_page(page, zerofrom, PAGE_CACHE_SIZE-zerofrom);
+ zero_user_page(page, zerofrom, PAGE_CACHE_SI
Re: [QUICKLIST 1/4] Quicklists for page table pages V5
On Wed, 2007-04-11 at 15:41 +1000, Paul Mackerras wrote: > Benjamin Herrenschmidt writes: > > > > > For a 64K page size kernel, we have 3 level page tables and we use 3 > > > > caches: a PGD pages are 128 bytes (yeah, not big heh...), our pmd > > > > pages are 32K (half a page) and PTE pages are PAGE_SIZE (64K). > > > > > > Ok so use quicklists for the PTEs and slab for the rest? A PGD of only > > > 128 > > > bytes? Stuff one at the end of the mm_struct or the task struct? That way > > > you can avoid allocation overhead. > > > > Yeah, maybe... I need to think about it a bit more. I might be able to > > make the PMD a full page too. > > There was a reason for making the PMD level map 256MB. I'd have to > remember what that was and make sure it didn't apply any more first... For dynamic VSIDs Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships.
On Tue, 2007-04-10 at 06:03 -0700, Greg KH wrote:
> On Tue, Apr 10, 2007 at 04:11:38PM +0800, Shaohua Li wrote:
> > On Mon, 2007-04-09 at 20:46 -0700, Greg KH wrote:
> > > On Mon, Apr 09, 2007 at 02:55:54PM -0700, Ashok Raj wrote:
> > > > +/*
> > > > + * find the upstream PCIE-to-PCI bridge of a PCI device
> > > > + * if the device is PCIE, return NULL
> > > > + * if the device isn't connected to a PCIE bridge (that is its parent
> > > > is a
> > > > + * legacy PCI bridge and the bridge is directly connected to bus 0),
> > > > return its
> > > > + * parent
> > > > + */
> > > > +struct pci_dev *
> > > > +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
> > > > +{
> > > > + struct pci_dev *tmp = NULL;
> > > > +
> > > > + if (pdev->is_pcie)
> > > > + return NULL;
> > > > + while (1) {
> > > > + if (!pdev->bus->self)
> > > > + break;
> > > > + pdev = pdev->bus->self;
> > > > + /* a p2p bridge */
> > > > + if (!pdev->is_pcie) {
> > > > + tmp = pdev;
> > > > + continue;
> > > > + }
> > > > + /* PCI device should connect to a PCIE bridge */
> > > > + BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);
> > > > + return pdev;
> > > > + }
> > > > +
> > > > + return tmp;
> > > > +}
> > >
> > > No locking while you walk up the bus list?
> > hmm, iommu driver didn't support pci hotplug in current stage. But we
> > can add lock here.
>
> Please do, as PCI-E hotplug is much more common than PCI hotplug these
> days (think ExpressCard in millions of laptops...)
Sounds we can't add lock here. pci_bus_sem is a semaphore, but the api
can be called within a spinlock and maybe with interrupt disabled. On
the other hand, there is no hotplug risk here. The pdev is in use (the
driver is doing dma buf allocation) when the api is called, so it's
parent can't be hotpluged too. If you feel others misuse the api, we
could move it to intel_iommu.c.
Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[patch] Broadcom 2045
Here's a patch that enables the necessary SCO work-around for the Broadcom
2045 chip, which comes in the most recent IOGear dongles.
-Jeff Hansen
---
"If someone's gotta do it, it might as well be me."
[EMAIL PROTECTED]diff --git a/drivers/bluetooth/hci_usb.c b/drivers/bluetooth/hci_usb.c
index 6bdf593..16ea856 100644
--- a/drivers/bluetooth/hci_usb.c
+++ b/drivers/bluetooth/hci_usb.c
@@ -115,6 +115,9 @@ static struct usb_device_id blacklist_ids[] = {
{ USB_DEVICE(0x0a5c, 0x200a), .driver_info = HCI_RESET |
HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x2009), .driver_info = HCI_BCM92035 },
+ /* Broadcom BCM2045 */
+ { USB_DEVICE(0x0a5c, 0x2101), .driver_info = HCI_WRONG_SCO_MTU },
+
/* IBM/Lenovo ThinkPad with Broadcom chip */
{ USB_DEVICE(0x0a5c, 0x201e), .driver_info = HCI_WRONG_SCO_MTU },
{ USB_DEVICE(0x0a5c, 0x2110), .driver_info = HCI_WRONG_SCO_MTU },
Re: [PATCH 13/13] fs: deprecate memclear_highpage_flush
On Tue, 10 Apr 2007 20:36:00 -0700 Nate Diller <[EMAIL PROTECTED]> wrote:
> Now that all the in-tree users are converted over to zero_user_page(),
> deprecate the old memclear_highpage_flush() call.
>
> Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
>
> ---
>
> diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/include/linux/highmem.h
> linux-2.6.21-rc6-mm1-test/include/linux/highmem.h
> --- linux-2.6.21-rc6-mm1/include/linux/highmem.h 2007-04-10
> 18:32:41.0 -0700
> +++ linux-2.6.21-rc6-mm1-test/include/linux/highmem.h 2007-04-10
> 19:40:14.0 -0700
> @@ -149,6 +149,8 @@ static inline void zero_user_page(struct
> kunmap_atomic(kaddr, KM_USER0);
> }
>
> +static void memclear_highpage_flush(struct page *page, unsigned int offset,
> + unsigned int size) __deprecated;
> static inline void memclear_highpage_flush(struct page *page, unsigned int
> offset, unsigned int size)
> {
> return zero_user_page(page, offset, size);
oh, there it is.
one can stick the __deprecated at the end of the definition, actually.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/13] fs: convert core functions to zero_user_page
On Tue, 10 Apr 2007 20:36:00 -0700 Nate Diller <[EMAIL PROTECTED]> wrote:
> It's very common for file systems to need to zero part or all of a page, the
> simplist way is just to use kmap_atomic() and memset(). There's actually a
> library function in include/linux/highmem.h that does exactly that, but it's
> confusingly named memclear_highpage_flush(), which is descriptive of *how*
> it does the work rather than what the *purpose* is. So this patchset
> renames the function to zero_user_page(), and calls it from the various
> places that currently open code it.
>
> This first patch introduces the new function call, and converts all the core
> kernel callsites, both the open-coded ones and the old
> memclear_highpage_flush() ones. Following this patch is a series of
> conversions for each file system individually, per AKPM, and finally a patch
> deprecating the old call.
For the reasons Anton identified, I think it is better design while we're here
to force callers to pass in the kmap-type which they wish to use for the atomic
kmap. It makes the programmer think about what he wants to happen. The price
of getting this wrong tends to be revoltingly rare file corruption.
But we cannot make this change in the obvious fashion, because the KM_FOO
identifiers are undefined if CONFIG_HIGHMEM=n. So
zero_user_page(page, 1, 2, KM_USER0);
won't compile on non-highmem.
So we are forced to use a macro, like below.
Also, you forgot to mark memclear_highpage_flush() __deprecated.
And I'm surprised that this:
+static inline void memclear_highpage_flush(struct page *page, unsigned int
offset, unsigned int size)
+{
+ return zero_user_page(page, offset, size);
+}
compiled. zero_user_page() returns void...
drivers/block/loop.c|2 +-
fs/buffer.c | 21 -
fs/direct-io.c |2 +-
fs/mpage.c |6 --
include/linux/highmem.h | 29 +
mm/filemap_xip.c|2 +-
6 files changed, 36 insertions(+), 26 deletions(-)
diff -puN
drivers/block/loop.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
drivers/block/loop.c
---
a/drivers/block/loop.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
+++ a/drivers/block/loop.c
@@ -250,7 +250,7 @@ static int do_lo_send_aops(struct loop_d
*/
printk(KERN_ERR "loop: transfer error block %llu\n",
(unsigned long long)index);
- zero_user_page(page, offset, size);
+ zero_user_page(page, offset, size, KM_USER0);
}
flush_dcache_page(page);
ret = aops->commit_write(file, page, offset,
diff -puN
fs/buffer.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
fs/buffer.c
--- a/fs/buffer.c~fs-convert-core-functions-to-zero_user_page-pass-kmap-type
+++ a/fs/buffer.c
@@ -1855,7 +1855,7 @@ static int __block_prepare_write(struct
break;
if (buffer_new(bh)) {
clear_buffer_new(bh);
- zero_user_page(page, block_start, bh->b_size);
+ zero_user_page(page, block_start, bh->b_size, KM_USER0);
set_buffer_uptodate(bh);
mark_buffer_dirty(bh);
}
@@ -1943,7 +1943,8 @@ int block_read_full_page(struct page *pa
SetPageError(page);
}
if (!buffer_mapped(bh)) {
- zero_user_page(page, i * blocksize, blocksize);
+ zero_user_page(page, i * blocksize, blocksize,
+ KM_USER0);
if (!err)
set_buffer_uptodate(bh);
continue;
@@ -2107,7 +2108,8 @@ int cont_prepare_write(struct page *page
PAGE_CACHE_SIZE, get_block);
if (status)
goto out_unmap;
- zero_user_page(page, zerofrom, PAGE_CACHE_SIZE-zerofrom);
+ zero_user_page(page, zerofrom, PAGE_CACHE_SIZE - zerofrom,
+ KM_USER0);
generic_commit_write(NULL, new_page, zerofrom, PAGE_CACHE_SIZE);
unlock_page(new_page);
page_cache_release(new_page);
@@ -2134,7 +2136,7 @@ int cont_prepare_write(struct page *page
if (status)
goto out1;
if (zerofrom < offset) {
- zero_user_page(page, zerofrom, offset-zerofrom);
+ zero_user_page(page, zerofrom, offset - zerofrom, KM_USER0);
__block_commit_write(inode, page, zerofrom, offset);
}
return 0;
@@ -2333,7 +2335,7 @@ failed:
* Error recovery is pretty slack. Clear the p
Re: [PATCH 0/30] Use menuconfig objects
On Wed, 11 Apr 2007, Adrian Bunk wrote: > On Wed, Apr 11, 2007 at 12:09:01AM +0200, Jan Engelhardt wrote: > > > > On Apr 11 2007 00:04, Stefan Richter wrote: > > > > > >[...] I tried one of the patches > > > - with make xconfig: OK > > > - with make gconfig: OK > > > - with make menuconfig: less so, because: > > >When one switches a menuconfig _on_, one might miss that there are > > >subsequent options to configure. (Although the availability of further > > >options is indicated by the '--->' suffix to the menu title.) > > > > The kconfig files had some menuconfigs for some time > > (CONFIG_EMBEDDED to be one). I do not think these menu entry types > > are unknown. > > And the EMBEDDED menu has the interesting property that it's not > empty with CONFIG_EMBEDDED=n . that entire "Embedded" submenu is a hideous mis-design, as selecting it simply presents you with options you can now "*de-select*. that is *anything* but intuitive. rday -- Robert P. J. Day Linux Consulting, Training and Annoying Kernel Pedantry Waterloo, Ontario, CANADA http://fsdev.net/wiki/index.php?title=Main_Page - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/4] Quicklists for page table pages V5
Benjamin Herrenschmidt writes: > > > For a 64K page size kernel, we have 3 level page tables and we use 3 > > > caches: a PGD pages are 128 bytes (yeah, not big heh...), our pmd > > > pages are 32K (half a page) and PTE pages are PAGE_SIZE (64K). > > > > Ok so use quicklists for the PTEs and slab for the rest? A PGD of only 128 > > bytes? Stuff one at the end of the mm_struct or the task struct? That way > > you can avoid allocation overhead. > > Yeah, maybe... I need to think about it a bit more. I might be able to > make the PMD a full page too. There was a reason for making the PMD level map 256MB. I'd have to remember what that was and make sure it didn't apply any more first... Paul. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] NET: [UPDATED] Multiqueue network device support implementation.
Waskiewicz Jr, Peter P wrote: >>This leaks the device. You treat every single-queue device as >>having a single subqueue. If it doesn't get too ugly it would >>be nice to avoid this and only allocate the subqueue states >>for real multiqueue devices. > > > We went back and forth on this. The reason we allocate a queue in every > case, even on single-queue devices, was to make the stack not have > branching for multiqueue and non-multiqueue devices. If we don't have > at least one queue on a device, then we can't have > netif_subqueue_stopped() in the hotpath unless we check if a device is > multiqueue before. The original patches I released had this branching, > and I was asked to not do that. OK, thanks for the explanation. >>>+skb->queue_mapping = >>>+ q->prio2band[q->band2queue[band&TC_PRIO_MAX]]; >> >> >>Does this needs to be cleared at some point again? TC actions >>might redirect or mirror packets to other (multiqueue) devices. > > > If an skb is redirected to another device, the skb should be filtered > through that device's qdisc, yes? Yes, but the device might not have a queue or use something different than prio, so the value would stay the same. I think you need to clear it before enqueueing a packet or alternatively when redirecting in the mirred action. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KJ] remove SPIN_LOCK_UNLOCKED
On Tue, 10 Apr 2007, Matthew Wilcox wrote:
> On Tue, Apr 10, 2007 at 05:45:07PM -0400, Robert P. J. Day wrote:
> > that works fine if you're defining a single spinlock, but what do you
> > do in cases like this:
> >
> > arch/sparc/lib/atomic32.c: [0 ... (ATOMIC_HASH_SIZE-1)] =
> > SPIN_LOCK_UNLOCKED
> >
> > that is, when you're assigning an array of them? you still need
> > some kind of generic, unnamed spinlock in those circumstances, no?
>
> That's a special case for architecture-only code. It's not to be
> used by drivers.
be that as it may, it still means you need to take it into account
whenever someone says they want to entirely remove the
SPIN_LOCK_UNLOCKED macro from the source tree, as suggested in
Documentation/spinlocks.txt.
if you do that removal, you can always replace SPIN_LOCK_UNLOCKED with
its current definition of __SPIN_LOCK_UNLOCKED(old_style_spin_init),
or what have you. but you would obviously have to replace it with
*something* that represents an unnamed spinlock if SPIN_LOCK_UNLOCKED
goes away.
rday
p.s. just FYI:
$ grep -r "\.\.\..*SPIN_LOCK_UNLOCKED" *
arch/sparc/lib/atomic32.c: [0 ... (ATOMIC_HASH_SIZE-1)] =
SPIN_LOCK_UNLOCKED
arch/cris/arch-v32/kernel/smp.c:spinlock_t cris_atomic_locks[] = { [0 ...
LOCK_COUNT - 1] = SPIN_LOCK_UNLOCKED};
arch/parisc/lib/bitops.c: [0 ... (ATOMIC_HASH_SIZE-1)] =
__RAW_SPIN_LOCK_UNLOCKED
arch/mips/kernel/gdb-stub.c:[0 ... NR_CPUS-1] = __RAW_SPIN_LOCK_UNLOCKED,
arch/powerpc/platforms/iseries/htab.c: { [0 ... 63] = SPIN_LOCK_UNLOCKED};
so, as matthew says, it's clearly not for drivers.
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] kthread: Don't depend on work queues
Currently there is a circular reference between work queue initialization
and kthread initialization. This prevents the kernel thread
infrastructure from initializing until after work queues have been
initialized.
For kernel threads we want something that is as close as possible to the
init_task and is not contaminated by user processes. The later we start
our kthreadd that forks the rest of the kernel threads the harder this is
to do and the more of a mess we have to clean up because the defaults have
changed on us.
So this patch modifies the kthread support to not use work queues but to
instead use a simple list of structures, and to have kthreadd start from
init_task immediately after our kernel thread that execs /sbin/init.
By being a true child of init_task we only have to change those process
settings that we want to have different from init_task, such as our
process name, blocking all signals and setting SIGCHLD to SIG_IGN
so that all of our children are reaped automatically.
By being a tre child of init_task we also naturally get our ppid set to 0
and do not wind up as a child of PID == 1. Ensuring that kernel threads
will not slow down the functioning of the wait family of functions.
Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>
---
include/linux/kthread.h |2 +
init/main.c |2 +
kernel/kthread.c| 121 +--
3 files changed, 69 insertions(+), 56 deletions(-)
diff --git a/include/linux/kthread.h b/include/linux/kthread.h
index 1c65e7a..113bd7c 100644
--- a/include/linux/kthread.h
+++ b/include/linux/kthread.h
@@ -30,4 +30,6 @@ void kthread_bind(struct task_struct *k, unsigned int cpu);
int kthread_stop(struct task_struct *k);
int kthread_should_stop(void);
+int kthreadd(void *unused);
+
#endif /* _LINUX_KTHREAD_H */
diff --git a/init/main.c b/init/main.c
index a92989e..12a8aba 100644
--- a/init/main.c
+++ b/init/main.c
@@ -54,6 +54,7 @@
#include
#include
#include
+#include
#include
#include
@@ -437,6 +438,7 @@ static void noinline rest_init(void)
{
kernel_thread(init, NULL, CLONE_FS | CLONE_SIGHAND);
numa_default_policy();
+ kernel_thread(kthreadd, NULL, CLONE_FS | CLONE_FILES);
unlock_kernel();
/*
diff --git a/kernel/kthread.c b/kernel/kthread.c
index 87c50cc..8638a04 100644
--- a/kernel/kthread.c
+++ b/kernel/kthread.c
@@ -1,7 +1,7 @@
/* Kernel thread helper functions.
* Copyright (C) 2004 IBM Corporation, Rusty Russell.
*
- * Creation is done via keventd, so that we get a clean environment
+ * Creation is done via kthreadd, so that we get a clean environment
* even if we're invoked from userspace (think modprobe, hotplug cpu,
* etc.).
*/
@@ -15,24 +15,22 @@
#include
#include
-/*
- * We dont want to execute off keventd since it might
- * hold a semaphore our callers hold too:
- */
-static struct workqueue_struct *helper_wq;
+static DEFINE_SPINLOCK(kthread_create_lock);
+static LIST_HEAD(kthread_create_list);
+static DECLARE_WAIT_QUEUE_HEAD(kthread_create_work);
struct kthread_create_info
{
- /* Information passed to kthread() from keventd. */
+ /* Information passed to kthread() from kthreadd. */
int (*threadfn)(void *data);
void *data;
struct completion started;
- /* Result passed back to kthread_create() from keventd. */
+ /* Result passed back to kthread_create() from kthreadd. */
struct task_struct *result;
struct completion done;
- struct work_struct work;
+ struct list_head list;
};
struct kthread_stop_info
@@ -60,42 +58,17 @@ int kthread_should_stop(void)
}
EXPORT_SYMBOL(kthread_should_stop);
-static void kthread_exit_files(void)
-{
- struct fs_struct *fs;
- struct task_struct *tsk = current;
-
- exit_fs(tsk); /* current->fs->count--; */
- fs = init_task.fs;
- tsk->fs = fs;
- atomic_inc(&fs->count);
- exit_files(tsk);
- current->files = init_task.files;
- atomic_inc(&tsk->files->count);
-}
-
static int kthread(void *_create)
{
struct kthread_create_info *create = _create;
int (*threadfn)(void *data);
void *data;
- sigset_t blocked;
int ret = -EINTR;
- kthread_exit_files();
-
- /* Copy data: it's on keventd's stack */
+ /* Copy data: it's on kthread's stack */
threadfn = create->threadfn;
data = create->data;
- /* Block and flush all signals (in case we're not from keventd). */
- sigfillset(&blocked);
- sigprocmask(SIG_BLOCK, &blocked, NULL);
- flush_signals(current);
-
- /* By default we can run anywhere, unlike keventd. */
- set_cpus_allowed(current, CPU_MASK_ALL);
-
/* OK, tell user we're spawned, wait for stop or wakeup */
__set_current_state(TASK_INTERRUPTIBLE);
complete(&create->started);
@@ -112,11 +85,8 @@ static int kthread(void
Re: PATCH 7/8] lguest: the block driver
On 4/11/07, Rusty Russell <[EMAIL PROTECTED]> wrote: What a question! end_request() doesn't end a request! What a crazy idea! Aah, indeed, end_request() uses req->hard_cur_sectors while end_entire_request() uses req->hard_nr_sectors which I missed. On 4/11/07, Rusty Russell <[EMAIL PROTECTED]> wrote: Hope that clarifies! It does. Thanks Rusty :) Pekka - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
Venki, On Tue, Apr 10, 2007 at 05:15:14PM -0700, Venki Pallipadi wrote: > > > x86-64 expects all idle handlers to enable interrupts before returning > > > from > > > idle handler. This is due to enter_idle(), exit_idle() races. Make > > > cpuidle_idle_call() confirm to this when there is no pm_idle_old. > > > > > > Also, cpuidle look at the return values of attch_driver() and set > > > current_driver to NULL if attach fails on all CPUs. > > > > My vote would be to instead remove enter_idle() and exit_idle() from > > x86-64, just as was done with i386. Performance monitoring > > infrastructure shouldn't be interfering with the idle interrupt > > delivery, as that could only hurt performance... Besides, there's > > probably a better way of doing this than an idle notifier anyway. > > > > Agreed. I did not like local_irq_enable() in cpuidle either, but added it > anyway as it was a corner case when cpuidle is active and no driver is > active and not a common case. I thought we will have it as a bandaid solution > until enter_idle, exit_idle is around. > > Andi/Stephane: What are the plans around enter_idle exit_idle in x86-64. > Is it still being used by perfmon for x86-64 arch? > The next kernel patch for Perfmon will not make use of the idle notification anymore on any platform. -- -Stephane - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch] convert aio event reap to use atomic-op instead of spin_lock
On Tue, 10 Apr 2007 16:53:53 -0700 (PDT) [EMAIL PROTECTED] (Ken Chen) wrote: > + } while (head != cmpxchg(&ring->head, head, head + 1)); A hasty grep indicates that only 14 out of 23 architectures implement cmpxchg(). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: link error : 2.6.21-rc6-mm1 for s390
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:47:38 -0700
> attribute(weak) would give a nicer result?
>
> We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up
> using lib/div64.c's EXPORT_SYMBOL().
Ok, here is the version of the fix I'll use for now:
commit c3abb3b8d41814ce4691cc4cc3998b0f5242c8d0
Author: David S. Miller <[EMAIL PROTECTED]>
Date: Tue Apr 10 22:10:39 2007 -0700
[S390]: Fix build on 31-bit.
Allow s390 to properly override the generic
__div64_32() implementation by:
1) Using obj-y for div64.o in s390's makefile instead
of lib-y
2) Adding the weak attribute to the generic implementation.
Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
diff --git a/arch/s390/lib/Makefile b/arch/s390/lib/Makefile
index 7a44fed..59aea65 100644
--- a/arch/s390/lib/Makefile
+++ b/arch/s390/lib/Makefile
@@ -5,6 +5,6 @@
EXTRA_AFLAGS := -traditional
lib-y += delay.o string.o uaccess_std.o uaccess_pt.o qrnnd.o
-lib-$(CONFIG_32BIT) += div64.o
+obj-$(CONFIG_32BIT) += div64.o
lib-$(CONFIG_64BIT) += uaccess_mvcos.o
lib-$(CONFIG_SMP) += spinlock.o
diff --git a/arch/s390/lib/div64.c b/arch/s390/lib/div64.c
index 0481f34..a5f8300 100644
--- a/arch/s390/lib/div64.c
+++ b/arch/s390/lib/div64.c
@@ -147,5 +147,3 @@ uint32_t __div64_32(uint64_t *n, uint32_t base)
}
#endif /* MARCH_G5 */
-
-EXPORT_SYMBOL(__div64_32);
diff --git a/lib/div64.c b/lib/div64.c
index 74f0c8c..b71cf93 100644
--- a/lib/div64.c
+++ b/lib/div64.c
@@ -23,7 +23,7 @@
/* Not needed on 64bit architectures */
#if BITS_PER_LONG == 32
-uint32_t __div64_32(uint64_t *n, uint32_t base)
+uint32_t __attribute__((weak)) __div64_32(uint64_t *n, uint32_t base)
{
uint64_t rem = *n;
uint64_t b = base;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] h8300 trivial conversion to GENERIC_TIME
On Wed, 11 Apr 2007 12:35:33 +0900 Yoshinori Sato <[EMAIL PROTECTED]> wrote: > At Tue, 10 Apr 2007 16:25:00 -0700, > john stultz wrote: > > > > Here is a trivial conversion of the h8300 arch to the GENERIC_TIME > > infrastructure (h8300 does not have better then jiffies resolution, so > > there are no clocksources to add). I have not tested this at all, but it > > seems pretty straight forward > > > > I'd appreciate any comments or feedback! > > > > thanks > > -john > > > > There will not be a problem. > Because it is a place working now, I correct it if there > was a problem. > > > > > Signed-off-by: John Stultz <[EMAIL PROTECTED]> > Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]> This patch has actually been in -mm since Feb 27. I'll merge it into 2.6.22-rc1, thanks. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships.
On Wed, Apr 11, 2007 at 09:40:36AM +0800, Shaohua Li wrote:
> On Tue, 2007-04-10 at 06:03 -0700, Greg KH wrote:
> > On Tue, Apr 10, 2007 at 04:11:38PM +0800, Shaohua Li wrote:
> > > On Mon, 2007-04-09 at 20:46 -0700, Greg KH wrote:
> > > > On Mon, Apr 09, 2007 at 02:55:54PM -0700, Ashok Raj wrote:
> > > > > +/*
> > > > > + * find the upstream PCIE-to-PCI bridge of a PCI device
> > > > > + * if the device is PCIE, return NULL
> > > > > + * if the device isn't connected to a PCIE bridge (that is its
> > > > > parent is a
> > > > > + * legacy PCI bridge and the bridge is directly connected to bus 0),
> > > > > return its
> > > > > + * parent
> > > > > + */
> > > > > +struct pci_dev *
> > > > > +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
> > > > > +{
> > > > > + struct pci_dev *tmp = NULL;
> > > > > +
> > > > > + if (pdev->is_pcie)
> > > > > + return NULL;
> > > > > + while (1) {
> > > > > + if (!pdev->bus->self)
> > > > > + break;
> > > > > + pdev = pdev->bus->self;
> > > > > + /* a p2p bridge */
> > > > > + if (!pdev->is_pcie) {
> > > > > + tmp = pdev;
> > > > > + continue;
> > > > > + }
> > > > > + /* PCI device should connect to a PCIE bridge */
> > > > > + BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);
> > > > > + return pdev;
> > > > > + }
> > > > > +
> > > > > + return tmp;
> > > > > +}
> > > >
> > > > No locking while you walk up the bus list?
> > > hmm, iommu driver didn't support pci hotplug in current stage. But we
> > > can add lock here.
> >
> > Please do, as PCI-E hotplug is much more common than PCI hotplug these
> > days (think ExpressCard in millions of laptops...)
> >
> > > > > --- linux-2.6.21-rc5.orig/include/linux/pci.h 2007-04-03
> > > > > 04:30:51.0 -0700
> > > > > +++ linux-2.6.21-rc5/include/linux/pci.h 2007-04-03
> > > > > 06:58:58.0 -0700
> > > > > @@ -126,6 +126,7 @@
> > > > > unsigned short subsystem_device;
> > > > > unsigned intclass; /* 3 bytes: (base,sub,prog-if)
> > > > > */
> > > > > u8 hdr_type; /* PCI header type (`multi'
> > > > > flag masked out) */
> > > > > + u8 pcie_type; /* PCI-E device/port type */
> > > > > u8 rom_base_reg; /* which config register
> > > > > controls the ROM */
> > > > > u8 pin;/* which interrupt pin this
> > > > > device uses */
> > > > >
> > > > > @@ -168,6 +169,7 @@
> > > > > unsigned intmsi_enabled:1;
> > > > > unsigned intmsix_enabled:1;
> > > > > unsigned intis_managed:1;
> > > > > + unsigned intis_pcie:1;
> > > >
> > > > Do you really need both fields? Wouldn't just the pcie_type one work
> > > > (with some NOT_PCIE type being set for it if it isn't I suppose.)
> > > There are some encodings are reserved for future. Just don't want to use
> > > reserved bits, as we don't know which one is proper for NOT_PCIE.
> >
> > What are the current encodings? I don't have my copy of the pci spec
> > availble at the moment...
> 0 - 1010b is defined. Other bits are reserved. How about the pcie_type's
> highest bit determines NOT_PCIE? the pcie spec just use 4 bits for pcie
> type.
No, nevermind, it's fine to use two variables, it would just be too
messy to put them in the same one with no real benifit.
thanks,
greg k-h
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 17/30] Use menuconfig objects - IPVS
On Tue, Apr 10, 2007 at 11:25:59PM +0200, Jan Engelhardt wrote: > > Use menuconfigs instead of menus, so the whole menu can be disabled at > once instead of going through all options. > > Signed-off-by: Jan Engelhardt <[EMAIL PROTECTED]> This seems to work fine to me. Signed-off-by: Simon Horman <[EMAIL PROTECTED]> -- Horms H: http://www.vergenet.net/~horms/ W: http://www.valinux.co.jp/en/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: is there any generic GPIO chip framework like IRQ chips?
On Tuesday 10 April 2007 4:11 pm, Paul Sokolovsky wrote:
>
> > /* defined by the platform using array, if/else/..., IDR, or
> > whatever */
> > struct gpio_yyy *gpio_to_yyy(unsigned gpio);
>
>I assume by "platform" you mean CPU architecture.
Nope. ARM (v4, v5, v6, etc) is a CPU architecture. "Platform" is
fuzzily defined but it's more than the CPU. It's a "family" notion
that probably ties better to SOC chip vendor and branding ... things
work differently on TI OMAP processors than on Intel IOP ones, or than
the PXA ones (originally from Intel). For many folk, "platform" is a
board-level notion ... like "x86_PC with ACPI firmware".
>For example, say, ASIC3 appears in both PXA and S3Cxxx
> devices. Suppose driver which uses ASIC3 works well on PXA, but acts up
> on S3Cxxx.
The thing to do with bugs is fix them. If S3C were to have a failure
at that level, there'd be a lot more failures than just that one.
>So, let me
> continue this and ask: how GPIO handling relates to CPU architecture
> at all (and that's what I assume you mean by "platform")? The answer:
> it does not.
Certainly not ... and the interface doesn't. Any more than IRQs do.
Implementations most certainly can be platform-specific. And they
usually are, of necessity (different controllers, etc).
So, talking about what an (optional) implementation framework might
look like (and which could handle the SOC, FPGA, I2C, and MFD cases
I've looked at):
> > then you could do something like this (maybe passing "private" not "yyy"):
>
> > int gpio_get_value(unsigned gpio)
> > {
> > struct gpio_yyy *yyy = gpio_to_yyy(gpio);
>
> > return yyy->get(yyy, gpio - base);
>
> ^^^ this subtraction makes me wonder what
> exactly it does here - anything useful, or ... ?
See the next lines:
> > /* where get(yyy, offset) might look like:
> > * u32 mask = 1 << offset;
> > * return mask & __raw_readl(yyy->private +
> > GPIO_PIN_READ);
> > */
Each GPIO controller manages no more than a few pins at a time,
normally as many as fit into one register.
> > }
> >
> []
>
> > ... of course, those two might also be wrapped to understand that
> > the first N gpios could become inlined accesses to the relevant
> > platform registers when "gpio" is constant ...
>
> Why first N could be inlined? What if I need second N inlined?
> Here, PXA GPIOs have really low-frequency stuff, while ASIC3 does
> bitbanging,
What's being bit-banged? I2C isn't speed-critical. SPI can be.
My opinion on the inlining is that the API should _allow_ that as
a source-compatible optimization, for cases where e.g. 1 Mbit/sec
isn't good enough but 2Mbit/sec is. Luckily that optimization (to
make GPIO access into about three instructions, no subroutining, if
the particular GPIO is known at compile time) can be very easy.
GPIOs are a really light weight hardware mechanism, and should never
become fat'n'heavy. Remember: GPIO ~= Bit. Keep it simple.
If a given implementation doesn't implement inline optimization,
some drivers may observe suckage but it probably won't matter for
most cases. However, if an interface doesn't *ever* allow that
optimization, that's a sign of something wrong.
> so that's what should be inlined. And on system X, GPIO
> chips #1, #3, #4, #7 needs to be inlined, while the rest could be not.
So you're arguing about what N is. That's obviously an implementation
concern, nothing to do with any decent interface.
It happens to be especially easy to ensure that if some GPIO controllers
are always there (e.g. ones built into the platform, like the ones on a
PXA SOC) then you can inline access to them .. no abstraction functions
necessary. And it's impractical to inline when you can't guarantee the
same controller is always there. (Absent altinstr style patching ...
which level of effort is not justifiable here.)
> So, why don't we handle this in following way: have two different
> levels of API: one which is concerned with inlinability (as noone
> disagrees this is important feature), and another - with generality
> and extensibility? That's why gpiodev API proposed to be on top of
> gpio API.
By analogy, irq_chip is not part of the driver API, so gpio_chip
doesn't need to be either. All that's *necessary* in the API is
a single level.
If there's to be a gpio_chip, it can go neatly _below_ the public
interface. I think you didn't notice that what I sketched closely
resembles the innards of most GPIO implementations in the kernel,
even those not yet supporting the gpio_*() interfaces...
> In GPIO API, GPIO id's are integers, 4 bytes on 32bit platform,
> passed by value. In GPIODEV API, GPIO id's are fixed-size structures,
> 8 bytes, passed by reference, 4 bytes, so the same overhead.
No; for N GPIOs, it's the differen
Re: [PATCH 3/7] Containers (V8): Add generic multi-subsystem API to containers
[ Sorry abt piece meal reviews, I am sending comments as and when I spot
something ]
On Fri, Apr 06, 2007 at 04:32:24PM -0700, [EMAIL PROTECTED] wrote:
> -void container_exit(struct task_struct *tsk)
> +void container_exit(struct task_struct *tsk, int run_callbacks)
> {
[snip]
> + /* Reassign the task to the init_container_group. */
> task_lock(tsk);
[snip]
> + if (tsk->containers != &init_container_group) {
Is this check needed? If we have the check, then:
> + task_unlock(tsk);
> + if (cg)
> + put_container_group(cg);
init_container_group refcount is leaky (fork increments it, but exit
doesnt). Not a big prob perhaps, but ..would be nice to avoid?
--
Regards,
vatsa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1 build error with mips
Mathieu Desnoyers wrote: > Hi Andrew, > > I get the following error when compiling 2.6.21-rc6-mm1 for MIPS : > > > > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc > -Wp,-MD,arch/mips/sgi-ip22/.ip22-time.o.d -nostdinc -isystem > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/3.4.5/include > -D__KERNEL__ -Iinclude -Iinclude2 > -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h > -I/home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22 -Iarch/mips/sgi-ip22 > -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing > -fno-common -Os -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float > -ffreestanding -march=r5000 -Wa,--trap > -I/home/compudj/git/linux-2.6-lttng/include/asm-mips/mach-ip22 > -Iinclude/asm-mips/mach-ip22 > -I/home/compudj/git/linux-2.6-lttng/include/asm-mips/mach-generic > -Iinclude/asm-mips/mach-generic -fomit-frame-pointer > -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" > -D"KBUILD_BASENAME=KBUILD_STR(ip22_time)" > -D"KBUILD_MODNAME=KBUILD_STR(ip22_time)" -c -o arch/m ips/sgi-ip22/ip22-time.o /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c > In file included from include2/asm/time.h:21, > from > /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c:25: > /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:64:27: > asm/tracehook.h: No such file or directory Last I checked... only sources from linux-mips.org's git repository work. Other source trees need to be specially patched to build for MIPS. Regards, -- Stuart Longland (aka Redhatter) .'''. Gentoo Linux/MIPS Cobalt and Docs Developer '.'` : . . . . . . . . . . . . . . . . . . . . . . .'.' http://dev.gentoo.org/~redhatter :.' I haven't lost my mind... ...it's backed up on a tape somewhere. signature.asc Description: OpenPGP digital signature
Re: [PATCH 3/7] Containers (V8): Add generic multi-subsystem API to containers
On Fri, Apr 06, 2007 at 04:32:24PM -0700, [EMAIL PROTECTED] wrote: > -int cpuset_create(struct container *cont) > +int cpuset_create(struct container_subsys *ss, struct container *cont) Minor nit: The static declaration for cpuset_create (and friends) can be re-introduced, since they won't be accessed directly from other files? -- Regards, vatsa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/30] Use menuconfig objects
Jan Engelhardt wrote: > On Apr 11 2007 01:12, Al Boldi wrote: > >Jan Engelhardt wrote: > >> the following patch series turns some menus into menuconfigs, so they > >> can be disabled whilst "walking" thorugh the parent menu > > > >Great, but instead of making it a simple on/off, make it tri-state that > > would default select all child-options appropriately. (see HW_RANDOM) > > I do not remember having touched the Random Number Generators or Character > Devices anywhere in this series. > > Don't worry, I have paid attention (or at least I hope so ;-) to > 'm'-able options, for example the SCSI, IEEE1394, or I2C stacks. > > But, for example you will see > [*] Old CD-ROM drivers (not SCSI, not IDE) > > which is because this entry in itself does not generate any object file. > > Generally, I just made the 'menuconfig' entry have the same state > (bool/tristate) as the original entry. If I have overseen that > somewhere, please let me know! Correct, no oversight here; but it may be more meaningful, if you could default select child-options based on the parent-state, like HW_RANDOM. Also, I don't think it's necessary to touch any of the "depends on"; keep them as is, as they don't hurt staying that way, and may actually be necessary under certain circumstances. (see EMBEDDED) Thanks! -- Al - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] make MADV_FREE lazily free memory
Make it possible for applications to have the kernel free memory
lazily. This reduces a repeated free/malloc cycle from freeing
pages and allocating them, to just marking them freeable. If the
application wants to reuse them before the kernel needs the memory,
not even a page fault will happen.
This version has one bugfix over the last one: if a PG_lazyfree
page was found dirty at fork time, we clear the flag in
copy_one_pte().
Ulrich Drepper has test glibc RPMS for this functionality at:
http://people.redhat.com/drepper/rpms
Because MADV_FREE has not been defined as a fixed number yet,
for the moment MADV_DONTNEED is defined to have the same
functionality.
Any test results of this patch in combination with Ulrich's
test glibc are welcome.
--
Politics is the struggle between those who want to make their country
the best in the world, and those who believe it already is. Each group
calls the other unpatriotic.
--- linux-2.6.20.noarch/include/asm-alpha/mman.h.madvise 2007-04-04 16:44:50.0 -0400
+++ linux-2.6.20.noarch/include/asm-alpha/mman.h 2007-04-04 16:56:24.0 -0400
@@ -42,6 +42,7 @@
#define MADV_WILLNEED 3 /* will need these pages */
#define MADV_SPACEAVAIL 5 /* ensure resources are available */
#define MADV_DONTNEED 6 /* don't need these pages */
+#define MADV_FREE 7 /* don't need the pages or the data */
/* common/generic parameters */
#define MADV_REMOVE 9 /* remove these pages & resources */
--- linux-2.6.20.noarch/include/asm-generic/mman.h.madvise 2007-04-04 16:44:50.0 -0400
+++ linux-2.6.20.noarch/include/asm-generic/mman.h 2007-04-04 16:56:53.0 -0400
@@ -29,6 +29,7 @@
#define MADV_SEQUENTIAL 2 /* expect sequential page references */
#define MADV_WILLNEED 3 /* will need these pages */
#define MADV_DONTNEED 4 /* don't need these pages */
+#define MADV_FREE 5 /* don't need the pages or the data */
/* common parameters: try to keep these consistent across architectures */
#define MADV_REMOVE 9 /* remove these pages & resources */
--- linux-2.6.20.noarch/include/asm-mips/mman.h.madvise 2007-04-04 16:44:50.0 -0400
+++ linux-2.6.20.noarch/include/asm-mips/mman.h 2007-04-04 16:58:02.0 -0400
@@ -65,6 +65,7 @@
#define MADV_SEQUENTIAL 2 /* expect sequential page references */
#define MADV_WILLNEED 3 /* will need these pages */
#define MADV_DONTNEED 4 /* don't need these pages */
+#define MADV_FREE 5 /* don't need the pages or the data */
/* common parameters: try to keep these consistent across architectures */
#define MADV_REMOVE 9 /* remove these pages & resources */
--- linux-2.6.20.noarch/include/asm-parisc/mman.h.madvise 2007-04-04 16:44:50.0 -0400
+++ linux-2.6.20.noarch/include/asm-parisc/mman.h 2007-04-04 16:58:40.0 -0400
@@ -38,6 +38,7 @@
#define MADV_SPACEAVAIL 5 /* insure that resources are reserved */
#define MADV_VPS_PURGE 6 /* Purge pages from VM page cache */
#define MADV_VPS_INHERIT 7 /* Inherit parents page size */
+#define MADV_FREE 8 /* don't need the pages or the data */
/* common/generic parameters */
#define MADV_REMOVE 9 /* remove these pages & resources */
--- linux-2.6.20.noarch/include/asm-xtensa/mman.h.madvise 2007-04-04 16:44:51.0 -0400
+++ linux-2.6.20.noarch/include/asm-xtensa/mman.h 2007-04-04 16:59:14.0 -0400
@@ -72,6 +72,7 @@
#define MADV_SEQUENTIAL 2 /* expect sequential page references */
#define MADV_WILLNEED 3 /* will need these pages */
#define MADV_DONTNEED 4 /* don't need these pages */
+#define MADV_FREE 5 /* don't need the pages or the data */
/* common parameters: try to keep these consistent across architectures */
#define MADV_REMOVE 9 /* remove these pages & resources */
--- linux-2.6.20.noarch/include/linux/mm_inline.h.madvise 2007-04-03 22:53:25.0 -0400
+++ linux-2.6.20.noarch/include/linux/mm_inline.h 2007-04-04 22:19:24.0 -0400
@@ -13,6 +13,13 @@ add_page_to_inactive_list(struct zone *z
}
static inline void
+add_page_to_inactive_list_tail(struct zone *zone, struct page *page)
+{
+ list_add_tail(&page->lru, &zone->inactive_list);
+ __inc_zone_state(zone, NR_INACTIVE);
+}
+
+static inline void
del_page_from_active_list(struct zone *zone, struct page *page)
{
list_del(&page->lru);
--- linux-2.6.20.noarch/include/linux/mm.h.madvise 2007-04-03 22:53:25.0 -0400
+++ linux-2.6.20.noarch/include/linux/mm.h 2007-04-04 22:06:45.0 -0400
@@ -716,6 +716,7 @@ struct zap_details {
pgoff_t last_index; /* Highest page->index to unmap */
spinlock_t *i_mmap_lock; /* For unmap_mapping_range: */
unsigned long truncate_count; /* Compare vm_truncate_count */
+ short madv_free; /* MADV_FREE anonymous memory */
};
struct page *vm_normal_page(struct vm_area_struct *, unsigned long, pte_t);
--- linux-2.6.20.noarch/include/linux/page-flags.h.madvise 2007-04-03 22:54:58.0 -0400
+++ linux-2.6.20.noarch/include/linux/page-flags.h 20
[PATCH 14/14 UPDATED] sysfs: kill unnecessary attribute->owner
sysfs is now completely out of driver/module lifetime game. After deletion, a sysfs node doesn't access anything outside sysfs proper, so there's no reason to hold onto the attribute owners. Note that often the wrong modules were accounted for as owners leading to accessing removed modules. This patch kills now unnecessary attribute->owner. Note that with this change, userland holding a sysfs node does not prevent the backing module from being unloaded. For more info regarding lifetime rule cleanup, please read the following message. http://article.gmane.org/gmane.linux.kernel/510293 s390 attributes changes are from Cornelia Huck. Signed-off-by: Tejun Heo <[EMAIL PROTECTED]> Cc: Cornelia Huck <[EMAIL PROTECTED]> --- Andrew, please use this patch instead of the original one. Thanks. arch/s390/kernel/ipl.c |2 -- drivers/base/class.c|2 -- drivers/base/core.c |4 drivers/base/firmware_class.c |2 +- drivers/block/pktcdvd.c |3 +-- drivers/char/ipmi/ipmi_msghandler.c | 10 -- drivers/cpufreq/cpufreq_stats.c |3 +-- drivers/cpufreq/cpufreq_userspace.c |2 +- drivers/cpufreq/freq_table.c|1 - drivers/firmware/dcdbas.h |3 +-- drivers/firmware/dell_rbu.c |6 +++--- drivers/firmware/edd.c |2 +- drivers/firmware/efivars.c |6 +++--- drivers/i2c/chips/eeprom.c |1 - drivers/i2c/chips/max6875.c |1 - drivers/infiniband/core/sysfs.c |1 - drivers/input/mouse/psmouse.h |1 - drivers/media/video/pvrusb2/pvrusb2-sysfs.c | 13 - drivers/misc/asus-laptop.c |3 +-- drivers/pci/hotplug/acpiphp_ibm.c |1 - drivers/pci/pci-sysfs.c |4 drivers/pcmcia/socket_sysfs.c |2 +- drivers/rtc/rtc-ds1553.c|1 - drivers/rtc/rtc-ds1742.c|1 - drivers/s390/cio/chsc.c |2 -- drivers/s390/net/qeth_sys.c |2 +- drivers/scsi/arcmsr/arcmsr_attr.c |3 --- drivers/scsi/lpfc/lpfc_attr.c |2 -- drivers/scsi/qla2xxx/qla_attr.c |6 -- drivers/spi/at25.c |1 - drivers/video/aty/radeon_base.c |2 -- drivers/video/backlight/backlight.c |2 +- drivers/video/backlight/lcd.c |2 +- drivers/w1/slaves/w1_ds2433.c |1 - drivers/w1/slaves/w1_therm.c|1 - drivers/w1/w1.c |2 -- fs/ecryptfs/main.c |2 -- fs/ocfs2/cluster/masklog.c |1 - fs/partitions/check.c |1 - fs/sysfs/bin.c | 19 +-- fs/sysfs/file.c | 21 + include/linux/sysdev.h |3 +-- include/linux/sysfs.h |7 +++ kernel/module.c |9 +++-- kernel/params.c |1 - net/bridge/br_sysfs_br.c|3 +-- net/bridge/br_sysfs_if.c|3 +-- 47 files changed, 36 insertions(+), 135 deletions(-) Index: work/fs/sysfs/bin.c === --- work.orig/fs/sysfs/bin.c +++ work/fs/sysfs/bin.c @@ -175,25 +175,20 @@ static int open(struct inode * inode, st if (!sysfs_get_active(attr_sd)) return -ENODEV; - /* Grab the module reference for this attribute */ - error = -ENODEV; - if (!try_module_get(attr->attr.owner)) - goto err_sput; - error = -EACCES; if ((file->f_mode & FMODE_WRITE) && !(attr->write || attr->mmap)) - goto err_mput; + goto err_out; if ((file->f_mode & FMODE_READ) && !(attr->read || attr->mmap)) - goto err_mput; + goto err_out; error = -ENOMEM; bb = kzalloc(sizeof(*bb), GFP_KERNEL); if (!bb) - goto err_mput; + goto err_out; bb->buffer = kmalloc(PAGE_SIZE, GFP_KERNEL); if (!bb->buffer) - goto err_mput; + goto err_out; mutex_init(&bb->mutex); file->private_data = bb; @@ -203,9 +198,7 @@ static int open(struct inode * inode, st sysfs_get(attr_sd); return 0; - err_mput: - module_put(attr->attr.owner); - err_sput: + err_out: sysfs_put_active(attr_sd); kfree(bb); return error; @@ -214,13 +207,11 @@ static int open(struct inode * inode, st static int release(struct inode * inode, struct file
Re: [PATCH 14/14] sysfs: kill unnecessary attribute->owner
Cornelia Huck wrote: > On Tue, 10 Apr 2007 16:17:06 +0200, > Cornelia Huck <[EMAIL PROTECTED]> wrote: > >> You missed some s390 attributes :) Yeap, I used allyesconfig on x86 to do the patch, so attrs on other archs are not there. I'll merge this patch and post the updated version. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/4] Quicklists for page table pages V5
On Tue, 2007-04-10 at 21:04 -0700, Christoph Lameter wrote: > On Tue, 10 Apr 2007, Benjamin Herrenschmidt wrote: > > > On Mon, 2007-04-09 at 11:25 -0700, Christoph Lameter wrote: > > > > > Quicklists for page table pages V5 > > > > Looks interesting, but unfortunately not very useful at this point for > > powerpc unless you remove the assumption that quicklists contain > > pages... > > Then quicklists wont be as simple anymore. > > > On powerpc, we currently use kmem cache slabs (though that isn't > > terribly node friendly) whose sizes depend on the page size. > > > > For a 4K page size kernel, we have 4 level page tables and use 2 caches, > > PTE and PGD pages are 4K (thus are PAGE_SIZE'd), and PMD & PUD are 1K. > > PTE and PGD could be run via quicklists? With PTEs you cover the most > common case. Quicklists using PGDs will allow to optimize using > preconstructed pages. > > Its probably best to keep the slabs for the 1K pages. > > > For a 64K page size kernel, we have 3 level page tables and we use 3 > > caches: a PGD pages are 128 bytes (yeah, not big heh...), our pmd > > pages are 32K (half a page) and PTE pages are PAGE_SIZE (64K). > > Ok so use quicklists for the PTEs and slab for the rest? A PGD of only 128 > bytes? Stuff one at the end of the mm_struct or the task struct? That way > you can avoid allocation overhead. Yeah, maybe... I need to think about it a bit more. I might be able to make the PMD a full page too. Ben. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] [KERNEL-DOC] generate main index page when building 'htmldocs'
On Wed, 11 Apr 2007 01:44:22 +0200 Borislav Petkov wrote: > Here's a patch for kernel-doc that enables the generation of a global, > TOC-like index.html > page after building 'htmldocs' > > Signed-off-by: Borislav Petkov <[EMAIL PROTECTED]> Acked-by: Randy Dunlap <[EMAIL PROTECTED]> Nice idea. However, the order of entries in index.html is suboptimal, due to the order of DOCBOOKS in the Makefile. You could submit a patch for that, or I'll change it. Thanks. > Index: 21-rc6/Documentation/DocBook/Makefile > === > --- 21-rc6.orig/Documentation/DocBook/Makefile2007-04-11 > 00:02:02.0 +0200 > +++ 21-rc6/Documentation/DocBook/Makefile 2007-04-11 01:00:21.0 > +0200 > @@ -44,6 +44,7 @@ > > HTML := $(patsubst %.xml, %.html, $(BOOKS)) > htmldocs: $(HTML) > + $(call build_main_index) > > MAN := $(patsubst %.xml, %.9, $(BOOKS)) > mandocs: $(MAN) > @@ -133,10 +134,17 @@ > %.pdf : %.xml > $(call cmd,db2pdf) > > + > +main_idx = Documentation/DocBook/index.html > +build_main_index = rm -rf $(main_idx) && \ > +echo 'Linux Kernel HTML Documentation' >> > $(main_idx) && \ > +echo 'Kernel Version: $(KERNELVERSION)' >> > $(main_idx) && \ > +cat $(HTML) >> $(main_idx) > + > quiet_cmd_db2html = HTML $@ >cmd_db2html = xmlto xhtml $(XMLTOFLAGS) -o $(patsubst %.html,%,$@) $< > && \ > echo ' \ > - Goto $(patsubst %.html,%,$(notdir $@))' > $@ > +$(patsubst %.html,%,$(notdir $@))' > $@ > > %.html: %.xml > @(which xmlto > /dev/null 2>&1) || \ > - --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCHSET #master] sysfs: make sysfs disconnect immediately on deletion, take 2
Cornelia Huck wrote: > On Mon, 9 Apr 2007 13:18:46 +0900, > Tejun Heo <[EMAIL PROTECTED]> wrote: > >> With all the patches applied, the same test used in the last take ran >> 9+hrs without any problem. > > I get the following on startup: > > = > [ BUG: bad unlock balance detected! ] > - > start_udev/197 is trying to release lock (&sd->s_active) at: > [<00209024>] release_sysfs_dirent+0x8c/0x118 > but there are no more locks to release! Thanks a lot for spotting this. I thought I enabled lock debugging but apparently, didn't. Anyways, the bug doesn't affect actual behavior. It's just doing up_write() on an unlocked rwsem which is about to be freed. I've just posted the updated version of patch 12 to fix this. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/14 UPDATED] sysfs: implement sysfs_dirent active reference and immediate disconnect
[PATCH] sysfs: implement sysfs_dirent active reference and immediate disconnect
Opening a sysfs node references its associated kobject, so userland
can arbitrarily prolong lifetime of a kobject which complicates
lifetime rules in drivers. This patch implements active reference and
makes the association between kobject and sysfs immediately breakable.
Now each sysfs_dirent has two reference counts - s_count and s_active.
s_count is a regular reference count which guarantees that the
containing sysfs_dirent is accessible. As long as s_count reference
is held, all sysfs internal fields in sysfs_dirent are accessible
including s_parent and s_name.
The newly added s_active is active reference count. This is acquired
by invoking sysfs_get_active() and it's the caller's responsibility to
ensure sysfs_dirent itself is accessible (should be holding s_count
one way or the other). Dereferencing sysfs_dirent to access objects
out of sysfs proper requires active reference. This includes access
to the associated kobjects, attributes and ops.
The active references can be drained and denied by calling
sysfs_deactivate(). All active sysfs_dirents must be deactivated
after deletion but before the default reference is dropped. This
enables immediate disconnect of sysfs nodes. Once a sysfs_dirent is
deleted, it won't access any entity external to sysfs proper.
Because attr/bin_attr ops access both the node itself and its parent
for kobject, they need to hold active references to both.
sysfs_get/put_active_two() helpers are provided to help grabbing both
references. Parent's is acquired first and released last.
Unlike other operations, mmapped area lingers on after mmap() is
finished and the module implement implementing it and kobj need to
stay referenced till all the mapped pages are gone. This is
accomplished by holding one set of active references to the bin_attr
and its parent if there have been any mmap during lifetime of an
openfile. The references are dropped when the openfile is released.
This change makes sysfs lifetime rules independent from both kobject's
and module's. It not only fixes several race conditions caused by
sysfs not holding onto the proper module when referencing kobject, but
also helps fixing and simplifying lifetime management in driver model
and drivers by taking sysfs out of the equation.
Please read the following message for more info.
http://article.gmane.org/gmane.linux.kernel/510293
Signed-off-by: Tejun Heo <[EMAIL PROTECTED]>
---
Cornelia, this should fix the problem you reported. It's caused by
doing up_write() on sysfs_dirent which is used for readdir cursor
which is not deactivated before being released.
release_sysfs_dirent() is udpated such that it does
down_write_trylock() on s_active before doing up_write(). This also
covers error paths where allocated sysfs_dirent is put due to errors
during initialization.
Andrew, please use this patch instead of the original one.
Thanks.
fs/sysfs/bin.c | 95 +--
fs/sysfs/dir.c | 22 +++--
fs/sysfs/file.c | 132 ---
fs/sysfs/inode.c |8 ++-
fs/sysfs/sysfs.h | 107 +++-
5 files changed, 250 insertions(+), 114 deletions(-)
Index: work/fs/sysfs/dir.c
===
--- work.orig/fs/sysfs/dir.c
+++ work/fs/sysfs/dir.c
@@ -22,6 +22,13 @@ void release_sysfs_dirent(struct sysfs_d
repeat:
parent_sd = sd->s_parent;
+ /* If @sd is being released after deletion, s_active is write
+* locked. If @sd is cursor for directory walk or being
+* released prematurely, s_active has no reader or writer.
+*/
+ down_write_trylock(&sd->s_active);
+ up_write(&sd->s_active);
+
if (sd->s_type & SYSFS_KOBJ_LINK)
sysfs_put(sd->s_elem.symlink.target_sd);
if (sd->s_type & SYSFS_COPY_NAME)
@@ -69,6 +76,7 @@ struct sysfs_dirent *sysfs_new_dirent(co
atomic_set(&sd->s_count, 1);
atomic_set(&sd->s_event, 1);
+ init_rwsem(&sd->s_active);
INIT_LIST_HEAD(&sd->s_children);
INIT_LIST_HEAD(&sd->s_sibling);
@@ -316,7 +324,6 @@ static void remove_dir(struct dentry * d
d_delete(d);
sd = d->d_fsdata;
list_del_init(&sd->s_sibling);
- sysfs_put(sd);
if (d->d_inode)
simple_rmdir(parent->d_inode,d);
@@ -325,6 +332,9 @@ static void remove_dir(struct dentry * d
mutex_unlock(&parent->d_inode->i_mutex);
dput(parent);
+
+ sysfs_deactivate(sd);
+ sysfs_put(sd);
}
void sysfs_remove_subdir(struct dentry * d)
@@ -335,6 +345,7 @@ void sysfs_remove_subdir(struct dentry *
static void __sysfs_remove_dir(struct dentry *dentry)
{
+ LIST_HEAD(removed);
struct sysfs_dirent * parent_sd;
struct sysfs_dirent * sd, * tmp;
@@ -348,12 +359,17 @@ static v
Re: [PATCH 5/13] ext4: use zero_user_page
On Apr 10, 2007 20:36 -0700, Nate Diller wrote:
> Use zero_user_page() instead of open-coding it.
>
> Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
> To: Andrew Morton <[EMAIL PROTECTED]>,
>Alexander Viro <[EMAIL PROTECTED]>
>Cc: linux-kernel@vger.kernel.org, linux-fsdevel@vger.kernel.org
Would have been better to CC the filesystem maintainers directly
(which was one of the reasons Andrew wanted per-fs patches so they
can be Ack/Nack independently.
Looks good in any case,
Signed-off-by: Andreas Dilger <[EMAIL PROTECTED]>
> diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext4/inode.c
> linux-2.6.21-rc6-mm1-test/fs/ext4/inode.c
> --- linux-2.6.21-rc6-mm1/fs/ext4/inode.c 2007-04-10 17:15:04.0
> -0700
> +++ linux-2.6.21-rc6-mm1-test/fs/ext4/inode.c 2007-04-10 18:33:04.0
> -0700
> @@ -1791,7 +1791,6 @@ int ext4_block_truncate_page(handle_t *h
> struct inode *inode = mapping->host;
> struct buffer_head *bh;
> int err = 0;
> - void *kaddr;
>
> if ((EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL) &&
> test_opt(inode->i_sb, EXTENTS) &&
> @@ -1808,10 +1807,7 @@ int ext4_block_truncate_page(handle_t *h
>*/
> if (!page_has_buffers(page) && test_opt(inode->i_sb, NOBH) &&
>ext4_should_writeback_data(inode) && PageUptodate(page)) {
> - kaddr = kmap_atomic(page, KM_USER0);
> - memset(kaddr + offset, 0, length);
> - flush_dcache_page(page);
> - kunmap_atomic(kaddr, KM_USER0);
> + zero_user_page(page, offset, length);
> set_page_dirty(page);
> goto unlock;
> }
> @@ -1864,11 +1860,7 @@ int ext4_block_truncate_page(handle_t *h
> goto unlock;
> }
>
> - kaddr = kmap_atomic(page, KM_USER0);
> - memset(kaddr + offset, 0, length);
> - flush_dcache_page(page);
> - kunmap_atomic(kaddr, KM_USER0);
> -
> + zero_user_page(page, offset, length);
> BUFFER_TRACE(bh, "zeroed end of block");
>
> err = 0;
> diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext4/writeback.c
> linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c
> --- linux-2.6.21-rc6-mm1/fs/ext4/writeback.c 2007-04-10 18:05:52.0
> -0700
> +++ linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c 2007-04-10
> 18:33:04.0 -0700
> @@ -961,7 +961,6 @@ int ext4_wb_writepage(struct page *page,
> loff_t i_size = i_size_read(inode);
> pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
> unsigned offset;
> - void *kaddr;
>
> wb_debug("writepage %lu from inode %lu\n", page->index, inode->i_ino);
>
> @@ -1011,10 +1010,7 @@ int ext4_wb_writepage(struct page *page,
>* the page size, the remaining memory is zeroed when mapped, and
>* writes to that region are not written out to the file."
>*/
> - kaddr = kmap_atomic(page, KM_USER0);
> - memset(kaddr + offset, 0, PAGE_CACHE_SIZE - offset);
> - flush_dcache_page(page);
> - kunmap_atomic(kaddr, KM_USER0);
> + zero_user_page(page, offset, PAGE_CACHE_SIZE - offset);
> return ext4_wb_write_single_page(page, wbc);
> }
>
> @@ -1065,7 +1061,6 @@ int ext4_wb_block_truncate_page(handle_t
> struct inode *inode = mapping->host;
> struct buffer_head bh, *bhw = &bh;
> unsigned blocksize, length;
> - void *kaddr;
> int err = 0;
>
> wb_debug("partial truncate from %lu on page %lu from inode %lu\n",
> @@ -1104,10 +1099,7 @@ int ext4_wb_block_truncate_page(handle_t
> }
> }
>
> - kaddr = kmap_atomic(page, KM_USER0);
> - memset(kaddr + offset, 0, length);
> - flush_dcache_page(page);
> - kunmap_atomic(kaddr, KM_USER0);
> + zero_user_page(page, offset, length);
> SetPageUptodate(page);
> __set_page_dirty_nobuffers(page);
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
Cheers, Andreas
--
Andreas Dilger
Principal Software Engineer
Cluster File Systems, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clean up x86 control register and MSR macros (corrected)
On Tue, 2007-04-10 at 10:36 -0700, H. Peter Anvin wrote: > This patch is based on Rusty's recent cleanup of the EFLAGS-related > macros; it extends the same kind of cleanup to control registers and > MSRs. Thanks hpa, this looks nice. Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Clean up x86 control register and MSR macros
On Tue, 2007-04-10 at 10:31 -0700, H. Peter Anvin wrote: > Jeremy Fitzhardinge wrote: > > > > Is having separate bit numbers and masks useful? If so, is it worth > > doing for the others? > > > > I presume it's useful, or at least *used* in the current code, since > that was there already. If deemed useful, it's something we could add > to the other bitmasks. I don't think it needs to be done now, as long as it follows a clear convention. I'd prefer eg. X86_EFLAGS_IF_BIT == 9, X86_EFLAGS_IF == 512, but _X86_EFLAGS_IF seems to be the current practice. Cheers, Rusty. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [KJ] remove SPIN_LOCK_UNLOCKED
On 4/11/07, Matthew Wilcox <[EMAIL PROTECTED]> wrote:
On Tue, Apr 10, 2007 at 05:45:07PM -0400, Robert P. J. Day wrote:
> that works fine if you're defining a single spinlock, but what do you
> do in cases like this:
>
> arch/sparc/lib/atomic32.c: [0 ... (ATOMIC_HASH_SIZE-1)] =
SPIN_LOCK_UNLOCKED
>
> that is, when you're assigning an array of them? you still need some
> kind of generic, unnamed spinlock in those circumstances, no?
That's a special case for architecture-only code. It's not to be used
by drivers.
as per my understanding, [which i should have keyed in earlier]
different places where SPIN_LOCK_UNLOCKED currently appears are
1. static spinlock_t foobar = SPIN_LOCK_UNLOCKED;
needs to be replaced bye DEFINE_SPINLOCK
e.g linux-core/drm_memory_debug.h
-static spinlock_t drm_mem_lock = SPIN_LOCK_UNLOCKED;
+static DEFINE_SPINLOCK(drm_mem_lock);
there are very few occurrences left in the tree i see
2. allocating a data structure dynamically
& initializing the spinlock embedded within
use spin_lock_init()
e.g linux-core/via_dmablit.c
- blitq->blit_lock = SPIN_LOCK_UNLOCKED;
+ spin_lock_init(&blitq->blit_lock);
3. static initialization of structure members
struct foo bar ={
.
.
.
.lock = SPIN_LOCK_UNLOCKED,
.
}
use
struct foo bar ={
.
.
.
.lock = __SPIN_LOCK_UNLOCKED(bar.lock),
.
}
e.g arch/i386/kernel/traps.c
- .lock = SPIN_LOCK_UNLOCKED,
+ .lock = __SPIN_LOCK_UNLOCKED(die.lock),
plenty of these are still there
may be some patches queued
4. arrays of spinlocks
e.g arch/cris/arch-v32/kernel/smp.c
-spinlock_t cris_atomic_locks[] = { [0 ... LOCK_COUNT - 1] =
SPIN_LOCK_UNLOCKED};
+raw_spinlock_t cris_atomic_locks[] = { [0 ... LOCK_COUNT - 1] =
__RAW_SPIN_LOCK_UNLOCKED};
my question is still there in the original post
about spin_lock_init()
CMIIW
Refer:
http://lkml.org/lkml/2005/6/20/47
http://lkml.org/lkml/2007/1/16/90
http://lists.openwall.net/linux-kernel/2007/02/01/258
--
Milind Arun Choudhary
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 3/3] reparent kernel threads to swapper
Oleg Nesterov <[EMAIL PROTECTED]> writes: > A lot of kernel threads parented to /sbin/init slow down do_wait() when > a non-detached (user-space) process exits. Change reparent_kthread() to > use init_task as a parent. Since init_task can't go away, we don't need > to put the caller on init_task.children list. Is there any downside of putting tasks on init_task.children? If not it is probably a good idea to put processes there just for good measure. > NOTE: pstree doesn't show kernel threads with this patch. > > Signed-off-by: Oleg Nesterov <[EMAIL PROTECTED]> > > --- 2.6.21-rc5/kernel/exit.c~3_SWAPPER2007-04-10 21:59:41.0 > +0400 > +++ 2.6.21-rc5/kernel/exit.c 2007-04-10 22:25:25.0 +0400 > @@ -255,11 +255,11 @@ static int has_stopped_jobs(struct pid * > } > > /** > - * reparent_kthread - Reparent the calling kernel thread to the init task of > the pid space that the thread belongs to. > + * reparent_kthread - Reparent the calling kernel thread to swapper. > * > * If a kernel thread is launched as a result of a system call, or if > - * it ever exits, it should generally reparent itself to init so that > - * it is correctly cleaned up on exit. > + * it ever exits, it should generally reparent itself so that it is > + * correctly cleaned up on exit. > * > * The various task state such as scheduling policy and priority may have > * been inherited from a user process, so we reset them to sane values here. > @@ -272,9 +272,8 @@ void reparent_kthread(void) > > ptrace_unlink(current); > remove_parent(current); > - current->parent = init_pid_ns.child_reaper; > + current->parent = &init_task; > current->real_parent = current->parent; > - add_parent(current); > > /* make the task auto-reap */ > current->exit_signal = -1; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [QUICKLIST 1/4] Quicklists for page table pages V5
On Tue, 10 Apr 2007, Benjamin Herrenschmidt wrote: > On Mon, 2007-04-09 at 11:25 -0700, Christoph Lameter wrote: > > > Quicklists for page table pages V5 > > Looks interesting, but unfortunately not very useful at this point for > powerpc unless you remove the assumption that quicklists contain > pages... Then quicklists wont be as simple anymore. > On powerpc, we currently use kmem cache slabs (though that isn't > terribly node friendly) whose sizes depend on the page size. > > For a 4K page size kernel, we have 4 level page tables and use 2 caches, > PTE and PGD pages are 4K (thus are PAGE_SIZE'd), and PMD & PUD are 1K. PTE and PGD could be run via quicklists? With PTEs you cover the most common case. Quicklists using PGDs will allow to optimize using preconstructed pages. Its probably best to keep the slabs for the 1K pages. > For a 64K page size kernel, we have 3 level page tables and we use 3 > caches: a PGD pages are 128 bytes (yeah, not big heh...), our pmd > pages are 32K (half a page) and PTE pages are PAGE_SIZE (64K). Ok so use quicklists for the PTEs and slab for the rest? A PGD of only 128 bytes? Stuff one at the end of the mm_struct or the task struct? That way you can avoid allocation overhead. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I give up
On Tuesday 10 April 2007, Phillip Susi wrote: >Gene Heskett wrote: >> YOU Tell the tar people, they are flabbergasted that linux is >> apparently the only unstable OS that tar can be run on. > >How about cygwin/windows? It has no concept of static device numbers. >And what about external usb disks on any other unix os? Surely they >don't have static minor device numbers in the face of hot plugging? > >The bug is in tar and that is what needs fixed. It should not attach >any meaning to the device number, but rather should assume that the >admin knows what he is doing when he said to backup a given path using a >given incremental backup log, and that he isn't yanking tar's chain and >pointing it to a different path between incremental backups. I violently agree on that point, but the limited conversations I've had with the tar maintainer so far indicates that AFAHIC, its linux that's broken. A new device number is a new disk and must be treated as such. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) QOTD: "I'll listen to reason when it comes out on CD." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I give up
On Tuesday 10 April 2007, H. Peter Anvin wrote: >Gene Heskett wrote: >> I haven't seen any 200GB for $55 yet, more like $129 & maybe a rebate >> at Circuit City. We don't have a Fry's around here. > >Fry's: >http:/http://shop1.outpost.com/product/4697788?site=sr:SEARCH:MAIN_RSLT_ >PG > >500 GB SATA for $119. Pricewatch shows several other vendors having the >same pricing. > > -hpa I got a 320GB Maxtor, 3 year warranty, at Staples tonight for $90 & change. It could have been worse locally. -- Cheers, Gene "There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed Howdershelt (Author) QOTD: "I'll listen to reason when it comes out on CD." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve heuristic detecting sequential reads
On Tue, Apr 10, 2007 at 04:45:40PM -0700, Andrew Morton wrote: > On 11 Apr 2007 00:56:51 +0200 > Andi Kleen <[EMAIL PROTECTED]> wrote: > > > There's a much more complete patchkit for this that gets reposted > > regularly on l-k. Perhaps it would make sense to test that first? > > adaptive readahead? Has been in -mm for a year. Problem is, it is > _so_ complete that I just don't know how to merge it. It's huge, and > only Wu understands it. So it's really rather stuck. Yeah, it is. I'll come up with a minimal patch to first simplify the current readahead algorithm. The code is ready, if ignoring the document ;-) Wu - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: PATCH 7/8] lguest: the block driver
On Tue, 2007-04-10 at 14:36 +0300, Pekka Enberg wrote:
> On 4/10/07, Rusty Russell <[EMAIL PROTECTED]> wrote:
> > > +/* Jens gave me this nice helper to end all chunks of a request. */
> > > +static void end_entire_request(struct request *req, int uptodate)
> > > +{
> > > + if (end_that_request_first(req, uptodate, req->hard_nr_sectors))
> > > + BUG();
> > > + add_disk_randomness(req->rq_disk);
> > > + blkdev_dequeue_request(req);
> > > + end_that_request_last(req, uptodate);
> > > +}
>
> On 4/10/07, Pekka Enberg <[EMAIL PROTECTED]> wrote:
> > Perhaps we should move this to generic code (i.e. block/ll_rw_blk.c)?
Yeah, Jens said to put it in here and he'd hoist it later.
> Uhm, I am bit confused now. Why don't you just use end_request() here?
What a question! end_request() doesn't end a request! What a crazy
idea!
As far as I can tell, every name in the block layer is actually some
variant of "fuck off, this is too complicated for you to understand".
Hope that clarifies!
Rusty.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] make kernel threads invisible to /sbin/init
Oleg Nesterov <[EMAIL PROTECTED]> writes: > 1. rename reparent_to_init() to reparent_kthread() and export it > > 2. use init_pid_ns.child_reaper instead of child_reaper(current) > > 3. set ->exit_signal = -1, so init can't see us and we don't use >it to reap the task. > > 4. add reparent_kthread() to kthread() and stopmachine() > If the goal is to hide from /sbin/init. We don't need to touch kernel/kthread.c or kernel/stop_machine.c Their parents are already kernel threads. Yes. There is a startup issue for kernel/kthread.c I just about have a patch I can stand that addresses that issue. For the kernel thread they all inherit signals with SIGCHLD set to SIG_IGN, so there is child auto reaping in that form. Adding the ->exit_signal = -1 would be a bonus but is not required. I am a little concerned with removing the knowledge of who our real parent is as that may compromise debugging. The reason why kernel threads are visible in the first place. I do support reparenting kernel threads that call daemonize, and the modifications to reparent_kthread here look reasonable. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: I give up
On Tuesday 10 April 2007, Jan Engelhardt wrote:
>On Apr 10 2007 03:51, Gene Heskett wrote:
>>On Tuesday 10 April 2007, Olaf Hering wrote:
>>>On Mon, Apr 09, Dave Dillow wrote:
It's not /dev he's backing up -- its /home, /usr, and others. GNU
tar saves the device and inode numbers from the {,l}stat() call on
each file and decides it is a new file if either number changes from
run to run.
>>>
>>>So fix tar to not do silly things.
>>>Kernel major:minor numbers are not stable.
>>
>>YOU Tell that to the tar/star people, they are flabbergasted that its
>> not stable. It apparently is for every other OS tar can be run on.
>
>FreeBSD also seems to be quite "dynamic".
>/dev/da0 is (0,92) for the 'fixit shell' -- how about you?
>
I don't have such a beast here. Whats that supposed to do?
>
>Jan
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Life sucks, but death doesn't put out at all.
-- Thomas J. Kopp
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] h8300 trivial conversion to GENERIC_TIME
At Tue, 10 Apr 2007 16:25:00 -0700,
john stultz wrote:
>
> Here is a trivial conversion of the h8300 arch to the GENERIC_TIME
> infrastructure (h8300 does not have better then jiffies resolution, so
> there are no clocksources to add). I have not tested this at all, but it
> seems pretty straight forward
>
> I'd appreciate any comments or feedback!
>
> thanks
> -john
>
There will not be a problem.
Because it is a place working now, I correct it if there
was a problem.
>
> Signed-off-by: John Stultz <[EMAIL PROTECTED]>
Signed-off-by: Yoshinori Sato <[EMAIL PROTECTED]>
>
> diff --git a/arch/h8300/Kconfig b/arch/h8300/Kconfig
> index 1734d96..86f6ca3 100644
> --- a/arch/h8300/Kconfig
> +++ b/arch/h8300/Kconfig
> @@ -53,6 +53,10 @@ config GENERIC_CALIBRATE_DELAY
> bool
> default y
>
> +config GENERIC_TIME
> + bool
> + default y
> +
> config TIME_LOW_RES
> bool
> default y
> diff --git a/arch/h8300/kernel/time.c b/arch/h8300/kernel/time.c
> index d1ef615..91d3b56 100644
> --- a/arch/h8300/kernel/time.c
> +++ b/arch/h8300/kernel/time.c
> @@ -66,55 +66,3 @@ void time_init(void)
>
> platform_timer_setup(timer_interrupt);
> }
> -
> -/*
> - * This version of gettimeofday has near microsecond resolution.
> - */
> -void do_gettimeofday(struct timeval *tv)
> -{
> - unsigned long flags;
> - unsigned long usec, sec;
> -
> - read_lock_irqsave(&xtime_lock, flags);
> - usec = 0;
> - sec = xtime.tv_sec;
> - usec += (xtime.tv_nsec / 1000);
> - read_unlock_irqrestore(&xtime_lock, flags);
> -
> - while (usec >= 100) {
> - usec -= 100;
> - sec++;
> - }
> -
> - tv->tv_sec = sec;
> - tv->tv_usec = usec;
> -}
> -
> -EXPORT_SYMBOL(do_gettimeofday);
> -
> -int do_settimeofday(struct timespec *tv)
> -{
> - if ((unsigned long)tv->tv_nsec >= NSEC_PER_SEC)
> - return -EINVAL;
> -
> - write_lock_irq(&xtime_lock);
> - /* This is revolting. We need to set the xtime.tv_usec
> - * correctly. However, the value in this location is
> - * is value at the last tick.
> - * Discover what correction gettimeofday
> - * would have done, and then undo it!
> - */
> - while (tv->tv_nsec < 0) {
> - tv->tv_nsec += NSEC_PER_SEC;
> - tv->tv_sec--;
> - }
> -
> - xtime.tv_sec = tv->tv_sec;
> - xtime.tv_nsec = tv->tv_nsec;
> - ntp_clear();
> - write_sequnlock_irq(&xtime_lock);
> - clock_was_set();
> - return 0;
> -}
> -
> -EXPORT_SYMBOL(do_settimeofday);
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 8/13] ntfs: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ntfs/aops.c
linux-2.6.21-rc6-mm1-test/fs/ntfs/aops.c
--- linux-2.6.21-rc6-mm1/fs/ntfs/aops.c 2007-04-09 10:41:47.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/ntfs/aops.c2007-04-09 18:18:23.0
-0700
@@ -245,8 +241,7 @@ static int ntfs_read_block(struct page *
rl = NULL;
nr = i = 0;
do {
- u8 *kaddr;
- int err;
+ int err = 0;
if (unlikely(buffer_uptodate(bh)))
continue;
@@ -254,7 +249,6 @@ static int ntfs_read_block(struct page *
arr[nr++] = bh;
continue;
}
- err = 0;
bh->b_bdev = vol->sb->s_bdev;
/* Is the block within the allowed limits? */
if (iblock < lblock) {
@@ -340,10 +334,7 @@ handle_hole:
bh->b_blocknr = -1UL;
clear_buffer_mapped(bh);
handle_zblock:
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + i * blocksize, 0, blocksize);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(page);
+ zero_user_page(page, i * blocksize, blocksize);
if (likely(!err))
set_buffer_uptodate(bh);
} while (i++, iblock++, (bh = bh->b_this_page) != head);
@@ -460,10 +451,7 @@ retry_readpage:
* ok to ignore the compressed flag here.
*/
if (unlikely(page->index > 0)) {
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr, 0, PAGE_CACHE_SIZE);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE);
goto done;
}
if (!NInoAttr(ni))
@@ -790,14 +778,9 @@ lock_retry_remap:
* uptodate so it can get discarded by the VM.
*/
if (err == -ENOENT || lcn == LCN_ENOENT) {
- u8 *kaddr;
-
bh->b_blocknr = -1;
clear_buffer_dirty(bh);
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + bh_offset(bh), 0, blocksize);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(page);
+ zero_user_page(page, bh_offset(bh), blocksize);
set_buffer_uptodate(bh);
err = 0;
continue;
@@ -1422,10 +1405,7 @@ retry_writepage:
if (page->index >= (i_size >> PAGE_CACHE_SHIFT)) {
/* The page straddles i_size. */
unsigned int ofs = i_size & ~PAGE_CACHE_MASK;
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + ofs, 0, PAGE_CACHE_SIZE - ofs);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(page);
+ zero_user_page(page, ofs, PAGE_CACHE_SIZE - ofs);
}
/* Handle mst protected attributes. */
if (NInoMstProtected(ni))
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ntfs/file.c
linux-2.6.21-rc6-mm1-test/fs/ntfs/file.c
--- linux-2.6.21-rc6-mm1/fs/ntfs/file.c 2007-04-09 17:24:03.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/ntfs/file.c2007-04-09 18:18:23.0
-0700
@@ -606,11 +606,8 @@ do_next_page:
ntfs_submit_bh_for_read(bh);
*wait_bh++ = bh;
} else {
- u8 *kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + bh_offset(bh), 0,
+ zero_user_page(page, bh_offset(bh),
blocksize);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(page);
set_buffer_uptodate(bh);
}
}
@@ -685,12 +682,8 @@ map_buffer_cached:
ntfs_submit_bh_for_read(bh);
*wait_bh++ = bh;
} else {
- u8 *kaddr = kmap_atomic(page,
- KM_USER0);
- memset(kaddr + bh_offset(bh),
- 0, blocksize);
- kunmap_atomic(kaddr, K
[PATCH 2/13] affs: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/affs/file.c
linux-2.6.21-rc6-mm1-test/fs/affs/file.c
--- linux-2.6.21-rc6-mm1/fs/affs/file.c 2007-04-09 17:23:48.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/affs/file.c2007-04-09 18:18:23.0
-0700
@@ -628,11 +628,7 @@ static int affs_prepare_write_ofs(struct
return err;
}
if (to < PAGE_CACHE_SIZE) {
- char *kaddr = kmap_atomic(page, KM_USER0);
-
- memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, to, PAGE_CACHE_SIZE - to);
if (size > offset + to) {
if (size < offset + PAGE_CACHE_SIZE)
tmp = size & ~PAGE_CACHE_MASK;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 5/13] ext4: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext4/inode.c
linux-2.6.21-rc6-mm1-test/fs/ext4/inode.c
--- linux-2.6.21-rc6-mm1/fs/ext4/inode.c2007-04-10 17:15:04.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ext4/inode.c 2007-04-10 18:33:04.0
-0700
@@ -1791,7 +1791,6 @@ int ext4_block_truncate_page(handle_t *h
struct inode *inode = mapping->host;
struct buffer_head *bh;
int err = 0;
- void *kaddr;
if ((EXT4_I(inode)->i_flags & EXT4_EXTENTS_FL) &&
test_opt(inode->i_sb, EXTENTS) &&
@@ -1808,10 +1807,7 @@ int ext4_block_truncate_page(handle_t *h
*/
if (!page_has_buffers(page) && test_opt(inode->i_sb, NOBH) &&
ext4_should_writeback_data(inode) && PageUptodate(page)) {
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset, length);
set_page_dirty(page);
goto unlock;
}
@@ -1864,11 +1860,7 @@ int ext4_block_truncate_page(handle_t *h
goto unlock;
}
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
-
+ zero_user_page(page, offset, length);
BUFFER_TRACE(bh, "zeroed end of block");
err = 0;
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext4/writeback.c
linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c
--- linux-2.6.21-rc6-mm1/fs/ext4/writeback.c2007-04-10 18:05:52.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ext4/writeback.c 2007-04-10
18:33:04.0 -0700
@@ -961,7 +961,6 @@ int ext4_wb_writepage(struct page *page,
loff_t i_size = i_size_read(inode);
pgoff_t end_index = i_size >> PAGE_CACHE_SHIFT;
unsigned offset;
- void *kaddr;
wb_debug("writepage %lu from inode %lu\n", page->index, inode->i_ino);
@@ -1011,10 +1010,7 @@ int ext4_wb_writepage(struct page *page,
* the page size, the remaining memory is zeroed when mapped, and
* writes to that region are not written out to the file."
*/
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, PAGE_CACHE_SIZE - offset);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset, PAGE_CACHE_SIZE - offset);
return ext4_wb_write_single_page(page, wbc);
}
@@ -1065,7 +1061,6 @@ int ext4_wb_block_truncate_page(handle_t
struct inode *inode = mapping->host;
struct buffer_head bh, *bhw = &bh;
unsigned blocksize, length;
- void *kaddr;
int err = 0;
wb_debug("partial truncate from %lu on page %lu from inode %lu\n",
@@ -1104,10 +1099,7 @@ int ext4_wb_block_truncate_page(handle_t
}
}
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset, length);
SetPageUptodate(page);
__set_page_dirty_nobuffers(page);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 4/13] ext3: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ext3/inode.c
linux-2.6.21-rc6-mm1-test/fs/ext3/inode.c
--- linux-2.6.21-rc6-mm1/fs/ext3/inode.c2007-04-09 17:24:03.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ext3/inode.c 2007-04-09 18:18:23.0
-0700
@@ -1767,7 +1767,6 @@ static int ext3_block_truncate_page(hand
struct inode *inode = mapping->host;
struct buffer_head *bh;
int err = 0;
- void *kaddr;
blocksize = inode->i_sb->s_blocksize;
length = blocksize - (offset & (blocksize - 1));
@@ -1779,10 +1778,7 @@ static int ext3_block_truncate_page(hand
*/
if (!page_has_buffers(page) && test_opt(inode->i_sb, NOBH) &&
ext3_should_writeback_data(inode) && PageUptodate(page)) {
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset, length);
set_page_dirty(page);
goto unlock;
}
@@ -1835,11 +1831,7 @@ static int ext3_block_truncate_page(hand
goto unlock;
}
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
-
+ zero_user_page(page, offset, length);
BUFFER_TRACE(bh, "zeroed end of block");
err = 0;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 6/13] gfs2: use zero_user_page
Use zero_user_page() instead of open-coding it. Signed-off-by: Nate Diller <[EMAIL PROTECTED]> --- diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/gfs2/bmap.c linux-2.6.21-rc6-mm1-test/fs/gfs2/bmap.c --- linux-2.6.21-rc6-mm1/fs/gfs2/bmap.c 2007-04-09 17:23:48.0 -0700 +++ linux-2.6.21-rc6-mm1-test/fs/gfs2/bmap.c2007-04-09 18:18:23.0 -0700 @@ -885,7 +885,6 @@ static int gfs2_block_truncate_page(stru unsigned blocksize, iblock, length, pos; struct buffer_head *bh; struct page *page; - void *kaddr; int err; page = grab_cache_page(mapping, index); @@ -933,10 +932,7 @@ static int gfs2_block_truncate_page(stru if (sdp->sd_args.ar_data == GFS2_DATA_ORDERED || gfs2_is_jdata(ip)) gfs2_trans_add_bh(ip->i_gl, bh, 0); - kaddr = kmap_atomic(page, KM_USER0); - memset(kaddr + offset, 0, length); - flush_dcache_page(page); - kunmap_atomic(kaddr, KM_USER0); + zero_user_page(page, offset, length); unlock: unlock_page(page); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 11/13] reiserfs: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/reiserfs/file.c
linux-2.6.21-rc6-mm1-test/fs/reiserfs/file.c
--- linux-2.6.21-rc6-mm1/fs/reiserfs/file.c 2007-04-09 17:24:03.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiserfs/file.c2007-04-09
18:18:23.0 -0700
@@ -1059,20 +1059,12 @@ static int reiserfs_prepare_file_region_
maping blocks, since there is none, so we just zero out remaining
parts of first and last pages in write area (if needed) */
if ((pos & ~((loff_t) PAGE_CACHE_SIZE - 1)) > inode->i_size) {
- if (from != 0) {/* First page needs to be partially
zeroed */
- char *kaddr = kmap_atomic(prepared_pages[0], KM_USER0);
- memset(kaddr, 0, from);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(prepared_pages[0]);
- }
- if (to != PAGE_CACHE_SIZE) {/* Last page needs to be
partially zeroed */
- char *kaddr =
- kmap_atomic(prepared_pages[num_pages - 1],
- KM_USER0);
- memset(kaddr + to, 0, PAGE_CACHE_SIZE - to);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(prepared_pages[num_pages - 1]);
- }
+ if (from != 0) /* First page needs to be partially
zeroed */
+ zero_user_page(prepared_pages[0], 0, from);
+
+ if (to != PAGE_CACHE_SIZE) /* Last page needs to be
partially zeroed */
+ zero_user_page(prepared_pages[num_pages-1], to,
+ PAGE_CACHE_SIZE - to);
/* Since all blocks are new - use already calculated value */
return blocks;
@@ -1199,13 +1191,9 @@ static int reiserfs_prepare_file_region_
ll_rw_block(READ, 1, &bh);
*wait_bh++ = bh;
} else {/* Not mapped, zero it */
- char *kaddr =
- kmap_atomic(prepared_pages[0],
- KM_USER0);
- memset(kaddr + block_start, 0,
- from - block_start);
- kunmap_atomic(kaddr, KM_USER0);
- flush_dcache_page(prepared_pages[0]);
+ zero_user_page(prepared_pages[0],
+ block_start,
+ from - block_start);
set_buffer_uptodate(bh);
}
}
@@ -1237,13 +1225,8 @@ static int reiserfs_prepare_file_region_
ll_rw_block(READ, 1, &bh);
*wait_bh++ = bh;
} else {/* Not mapped, zero it */
- char *kaddr =
- kmap_atomic(prepared_pages
- [num_pages - 1],
- KM_USER0);
- memset(kaddr + to, 0, block_end - to);
- kunmap_atomic(kaddr, KM_USER0);
-
flush_dcache_page(prepared_pages[num_pages - 1]);
+
zero_user_page(prepared_pages[num_pages-1],
+ to, block_end - to);
set_buffer_uptodate(bh);
}
}
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/reiserfs/inode.c
linux-2.6.21-rc6-mm1-test/fs/reiserfs/inode.c
--- linux-2.6.21-rc6-mm1/fs/reiserfs/inode.c2007-04-09 10:41:47.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiserfs/inode.c 2007-04-09
18:18:23.0 -0700
@@ -2148,13 +2148,8 @@ int reiserfs_truncate_file(struct inode
length = offset & (blocksize - 1);
/* if we are not on a block boundary */
if (length) {
- char *kaddr;
-
length = blocksize - length;
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, length);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset,
[PATCH 10/13] reiser4: use zero_user_page
Use zero_user_page() instead of open-coding it. Also replace the (mostly)
redundant zero_page() function.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff
linux-2.6.21-rc6-mm1/fs/reiser4/plugin/file/cryptcompress.c
linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/file/cryptcompress.c
--- linux-2.6.21-rc6-mm1/fs/reiser4/plugin/file/cryptcompress.c 2007-04-10
17:15:04.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/file/cryptcompress.c
2007-04-10 18:35:44.0 -0700
@@ -1897,7 +1897,6 @@ static int
write_hole(struct inode *inode, reiser4_cluster_t * clust, loff_t file_off,
loff_t to_file)
{
- char *data;
int result = 0;
unsigned cl_off, cl_count = 0;
unsigned to_pg, pg_off;
@@ -1934,10 +1933,7 @@ write_hole(struct inode *inode, reiser4_
to_pg = min_count(PAGE_CACHE_SIZE - pg_off, cl_count);
lock_page(page);
- data = kmap_atomic(page, KM_USER0);
- memset(data + pg_off, 0, to_pg);
- flush_dcache_page(page);
- kunmap_atomic(data, KM_USER0);
+ zero_user_page(page, pg_off, to_pg);
SetPageUptodate(page);
unlock_page(page);
@@ -2167,7 +2163,6 @@ read_some_cluster_pages(struct inode *in
if (clust->nr_pages) {
int off;
- char *data;
struct page * pg;
assert("edward-1419", clust->pages != NULL);
pg = clust->pages[clust->nr_pages - 1];
@@ -2175,10 +2170,7 @@ read_some_cluster_pages(struct inode *in
off = off_to_pgoff(win->off+win->count+win->delta);
if (off) {
lock_page(pg);
- data = kmap_atomic(pg, KM_USER0);
- memset(data + off, 0, PAGE_CACHE_SIZE - off);
- flush_dcache_page(pg);
- kunmap_atomic(data, KM_USER0);
+ zero_user_page(pg, off, PAGE_CACHE_SIZE - off);
unlock_page(pg);
}
}
@@ -2217,20 +2209,15 @@ read_some_cluster_pages(struct inode *in
(count_to_nrpages(inode->i_size) <= pg->index)) {
/* .. and appended,
so set zeroes to the rest */
- char *data;
int offset;
lock_page(pg);
- data = kmap_atomic(pg, KM_USER0);
-
assert("edward-1260",
count_to_nrpages(win->off + win->count +
win->delta) - 1 == i);
offset =
off_to_pgoff(win->off + win->count + win->delta);
- memset(data + offset, 0, PAGE_CACHE_SIZE - offset);
- flush_dcache_page(pg);
- kunmap_atomic(data, KM_USER0);
+ zero_user_page(pg, offset, PAGE_CACHE_SIZE - offset);
unlock_page(pg);
/* still not uptodate */
break;
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/reiser4/plugin/file/file.c
linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/file/file.c
--- linux-2.6.21-rc6-mm1/fs/reiser4/plugin/file/file.c 2007-04-10
17:15:04.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/file/file.c 2007-04-10
18:35:44.0 -0700
@@ -433,7 +433,6 @@ static int shorten_file(struct inode *in
struct page *page;
int padd_from;
unsigned long index;
- char *kaddr;
unix_file_info_t *uf_info;
/*
@@ -523,10 +522,7 @@ static int shorten_file(struct inode *in
lock_page(page);
assert("vs-1066", PageLocked(page));
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + padd_from, 0, PAGE_CACHE_SIZE - padd_from);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, padd_from, PAGE_CACHE_SIZE - padd_from);
unlock_page(page);
page_cache_release(page);
/* the below does up(sbinfo->delete_mutex). Do not get confused */
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/reiser4/plugin/item/ctail.c
linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/item/ctail.c
--- linux-2.6.21-rc6-mm1/fs/reiser4/plugin/item/ctail.c 2007-04-10
17:15:04.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/reiser4/plugin/item/ctail.c2007-04-10
18:35:44.0 -0700
@@ -627,11 +627,7 @@ int do_readpage_ctail(struct inode * ino
#endif
case FAKE_DISK_CLUSTER:
/* fill the page by zeroes */
- data = kmap_atomic(page, KM_USER0);
-
- memset(data, 0, PAGE_CACHE_SIZE);
-
[PATCH 9/13] ocfs2: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ocfs2/aops.c
linux-2.6.21-rc6-mm1-test/fs/ocfs2/aops.c
--- linux-2.6.21-rc6-mm1/fs/ocfs2/aops.c2007-04-09 17:24:03.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ocfs2/aops.c 2007-04-09 18:18:23.0
-0700
@@ -234,10 +234,7 @@ static int ocfs2_readpage(struct file *f
* XXX sys_readahead() seems to get that wrong?
*/
if (start >= i_size_read(inode)) {
- char *addr = kmap(page);
- memset(addr, 0, PAGE_SIZE);
- flush_dcache_page(page);
- kunmap(page);
+ zero_user_page(page, 0, PAGE_SIZE);
SetPageUptodate(page);
ret = 0;
goto out_alloc;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 12/13] xfs: use zero_user_page
Use zero_user_page() instead of the newly deprecated memclear_highpage_flush(). Signed-off-by: Nate Diller <[EMAIL PROTECTED]> --- diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/xfs/linux-2.6/xfs_lrw.c linux-2.6.21-rc6-mm1-test/fs/xfs/linux-2.6/xfs_lrw.c --- linux-2.6.21-rc6-mm1/fs/xfs/linux-2.6/xfs_lrw.c 2007-04-09 17:24:03.0 -0700 +++ linux-2.6.21-rc6-mm1-test/fs/xfs/linux-2.6/xfs_lrw.c2007-04-09 18:18:23.0 -0700 @@ -159,7 +159,7 @@ xfs_iozero( if (status) goto unlock; - memclear_highpage_flush(page, offset, bytes); + zero_user_page(page, offset, bytes); status = mapping->a_ops->commit_write(NULL, page, offset, offset + bytes); - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH 13/13] fs: deprecate memclear_highpage_flush
Now that all the in-tree users are converted over to zero_user_page(),
deprecate the old memclear_highpage_flush() call.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/include/linux/highmem.h
linux-2.6.21-rc6-mm1-test/include/linux/highmem.h
--- linux-2.6.21-rc6-mm1/include/linux/highmem.h2007-04-10
18:32:41.0 -0700
+++ linux-2.6.21-rc6-mm1-test/include/linux/highmem.h 2007-04-10
19:40:14.0 -0700
@@ -149,6 +149,8 @@ static inline void zero_user_page(struct
kunmap_atomic(kaddr, KM_USER0);
}
+static void memclear_highpage_flush(struct page *page, unsigned int offset,
+ unsigned int size) __deprecated;
static inline void memclear_highpage_flush(struct page *page, unsigned int
offset, unsigned int size)
{
return zero_user_page(page, offset, size);
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 7/13] nfs: use zero_user_page
Use zero_user_page() instead of the newly deprecated memclear_highpage_flush().
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/nfs/read.c
linux-2.6.21-rc6-mm1-test/fs/nfs/read.c
--- linux-2.6.21-rc6-mm1/fs/nfs/read.c 2007-04-09 17:23:48.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/nfs/read.c 2007-04-09 18:18:23.0
-0700
@@ -79,7 +79,7 @@ void nfs_readdata_release(void *data)
static
int nfs_return_empty_page(struct page *page)
{
- memclear_highpage_flush(page, 0, PAGE_CACHE_SIZE);
+ zero_user_page(page, 0, PAGE_CACHE_SIZE);
SetPageUptodate(page);
unlock_page(page);
return 0;
@@ -103,10 +103,10 @@ static void nfs_readpage_truncate_uninit
pglen = PAGE_CACHE_SIZE - base;
for (;;) {
if (remainder <= pglen) {
- memclear_highpage_flush(*pages, base, remainder);
+ zero_user_page(*pages, base, remainder);
break;
}
- memclear_highpage_flush(*pages, base, pglen);
+ zero_user_page(*pages, base, pglen);
pages++;
remainder -= pglen;
pglen = PAGE_CACHE_SIZE;
@@ -130,7 +130,7 @@ static int nfs_readpage_async(struct nfs
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len);
nfs_list_add_request(new, &one_request);
nfs_pagein_one(&one_request, inode);
@@ -561,7 +561,7 @@ readpage_async_filler(void *data, struct
return PTR_ERR(new);
}
if (len < PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, len, PAGE_CACHE_SIZE - len);
+ zero_user_page(page, len, PAGE_CACHE_SIZE - len);
nfs_list_add_request(new, desc->head);
return 0;
}
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/nfs/write.c
linux-2.6.21-rc6-mm1-test/fs/nfs/write.c
--- linux-2.6.21-rc6-mm1/fs/nfs/write.c 2007-04-09 17:24:03.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/nfs/write.c2007-04-09 18:18:23.0
-0700
@@ -169,7 +169,7 @@ static void nfs_mark_uptodate(struct pag
if (count != nfs_page_length(page))
return;
if (count != PAGE_CACHE_SIZE)
- memclear_highpage_flush(page, count, PAGE_CACHE_SIZE - count);
+ zero_user_page(page, count, PAGE_CACHE_SIZE - count);
SetPageUptodate(page);
}
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 3/13] ecryptfs: use zero_user_page
Use zero_user_page() instead of open-coding it.
Signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/ecryptfs/mmap.c
linux-2.6.21-rc6-mm1-test/fs/ecryptfs/mmap.c
--- linux-2.6.21-rc6-mm1/fs/ecryptfs/mmap.c 2007-04-09 17:24:03.0
-0700
+++ linux-2.6.21-rc6-mm1-test/fs/ecryptfs/mmap.c2007-04-09
18:19:34.0 -0700
@@ -364,18 +364,14 @@ static int fill_zeros_to_end_of_page(str
{
struct inode *inode = page->mapping->host;
int end_byte_in_page;
- char *page_virt;
if ((i_size_read(inode) / PAGE_CACHE_SIZE) != page->index)
goto out;
end_byte_in_page = i_size_read(inode) % PAGE_CACHE_SIZE;
if (to > end_byte_in_page)
end_byte_in_page = to;
- page_virt = kmap_atomic(page, KM_USER0);
- memset((page_virt + end_byte_in_page), 0,
- (PAGE_CACHE_SIZE - end_byte_in_page));
- kunmap_atomic(page_virt, KM_USER0);
- flush_dcache_page(page);
+ zero_user_page(page, end_byte_in_page,
+ PAGE_CACHE_SIZE - end_byte_in_page);
out:
return 0;
}
@@ -740,7 +736,6 @@ int write_zeros(struct file *file, pgoff
{
int rc = 0;
struct page *tmp_page;
- char *tmp_page_virt;
tmp_page = ecryptfs_get1page(file, index);
if (IS_ERR(tmp_page)) {
@@ -757,10 +752,7 @@ int write_zeros(struct file *file, pgoff
page_cache_release(tmp_page);
goto out;
}
- tmp_page_virt = kmap_atomic(tmp_page, KM_USER0);
- memset(((char *)tmp_page_virt + start), 0, num_zeros);
- kunmap_atomic(tmp_page_virt, KM_USER0);
- flush_dcache_page(tmp_page);
+ zero_user_page(tmp_page, start, num_zeros);
rc = ecryptfs_commit_write(file, tmp_page, start, start + num_zeros);
if (rc < 0) {
ecryptfs_printk(KERN_ERR, "Error attempting to write zero's "
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH 1/13] fs: convert core functions to zero_user_page
It's very common for file systems to need to zero part or all of a page, the
simplist way is just to use kmap_atomic() and memset(). There's actually a
library function in include/linux/highmem.h that does exactly that, but it's
confusingly named memclear_highpage_flush(), which is descriptive of *how*
it does the work rather than what the *purpose* is. So this patchset
renames the function to zero_user_page(), and calls it from the various
places that currently open code it.
This first patch introduces the new function call, and converts all the core
kernel callsites, both the open-coded ones and the old
memclear_highpage_flush() ones. Following this patch is a series of
conversions for each file system individually, per AKPM, and finally a patch
deprecating the old call. The diffstat below shows the entire patchset.
Compile tested in x86_64.
signed-off-by: Nate Diller <[EMAIL PROTECTED]>
---
drivers/block/loop.c |6 ---
fs/affs/file.c |6 ---
fs/buffer.c | 53 +--
fs/direct-io.c |8 +---
fs/ecryptfs/mmap.c | 14 +---
fs/ext3/inode.c | 12 +--
fs/ext4/inode.c | 12 +--
fs/ext4/writeback.c | 12 +--
fs/gfs2/bmap.c |6 ---
fs/mpage.c | 11 +-
fs/nfs/read.c| 10 ++---
fs/nfs/write.c |2 -
fs/ntfs/aops.c | 26 ++-
fs/ntfs/file.c | 47 +--
fs/ocfs2/aops.c |5 --
fs/reiser4/plugin/file/cryptcompress.c | 19 +--
fs/reiser4/plugin/file/file.c|6 ---
fs/reiser4/plugin/item/ctail.c |6 ---
fs/reiser4/plugin/item/extent_file_ops.c | 19 +++
fs/reiser4/plugin/item/tail.c|8 +---
fs/reiserfs/file.c | 39 ++
fs/reiserfs/inode.c | 13 +--
fs/xfs/linux-2.6/xfs_lrw.c |2 -
include/linux/highmem.h |7 +++-
mm/filemap_xip.c |7
mm/truncate.c|2 -
26 files changed, 82 insertions(+), 276 deletions(-)
---
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/drivers/block/loop.c
linux-2.6.21-rc6-mm1-test/drivers/block/loop.c
--- linux-2.6.21-rc6-mm1/drivers/block/loop.c 2007-04-10 18:27:04.0
-0700
+++ linux-2.6.21-rc6-mm1-test/drivers/block/loop.c 2007-04-10
18:18:16.0 -0700
@@ -244,17 +244,13 @@ static int do_lo_send_aops(struct loop_d
transfer_result = lo_do_transfer(lo, WRITE, page, offset,
bvec->bv_page, bv_offs, size, IV);
if (unlikely(transfer_result)) {
- char *kaddr;
-
/*
* The transfer failed, but we still write the data to
* keep prepare/commit calls balanced.
*/
printk(KERN_ERR "loop: transfer error block %llu\n",
(unsigned long long)index);
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + offset, 0, size);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, offset, size);
}
flush_dcache_page(page);
ret = aops->commit_write(file, page, offset,
diff -urpN -X dontdiff linux-2.6.21-rc6-mm1/fs/buffer.c
linux-2.6.21-rc6-mm1-test/fs/buffer.c
--- linux-2.6.21-rc6-mm1/fs/buffer.c2007-04-10 18:27:04.0 -0700
+++ linux-2.6.21-rc6-mm1-test/fs/buffer.c 2007-04-10 18:18:16.0
-0700
@@ -1862,13 +1862,8 @@ static int __block_prepare_write(struct
if (block_start >= to)
break;
if (buffer_new(bh)) {
- void *kaddr;
-
clear_buffer_new(bh);
- kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr+block_start, 0, bh->b_size);
- flush_dcache_page(page);
- kunmap_atomic(kaddr, KM_USER0);
+ zero_user_page(page, block_start, bh->b_size);
set_buffer_uptodate(bh);
mark_buffer_dirty(bh);
}
@@ -1956,10 +1951,7 @@ int block_read_full_page(struct page *pa
SetPageError(page);
}
if (!buffer_mapped(bh)) {
- void *kaddr = kmap_atomic(page, KM_USER0);
- memset(kaddr + i
Re: RAID1 "out of memory" error, was Re: 2.6.21-rc5-mm4
On Friday April 6, [EMAIL PROTECTED] wrote: > > Looks like some damage, or maybe intolerance to on-disk damage, to RAID-1. Difference is that kzalloc(0, ) now returns NULL. Maybe it is a SLUB/SLAB difference? (So maybe it did use memory it shouldn't have before, but now it fails, which is the better behaviour). This patch fixes the maths and should probably go in various 'stable' kernels. Bug is in 2.6.18, but not 2.6.16. Patch won't work for 2.6.18 as DIV_ROUND_UP is missing, but 2.6.19 and later have it. Thanks for the bug report. NeilBrown - Fix calculation for size of filemap_attr array in md/bitmap. If 'num_pages' were ever 1 more than a multiple of 8 (32bit platforms) for of 16 (64 bit platforms). filemap_attr would be allocated one 'unsigned long' shorter than required. We need a round-up in there. Signed-off-by: Neil Brown <[EMAIL PROTECTED]> ### Diffstat output ./drivers/md/bitmap.c |4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff .prev/drivers/md/bitmap.c ./drivers/md/bitmap.c --- .prev/drivers/md/bitmap.c 2007-04-11 13:24:50.0 +1000 +++ ./drivers/md/bitmap.c 2007-04-11 13:24:59.0 +1000 @@ -863,9 +863,7 @@ static int bitmap_init_from_disk(struct /* We need 4 bits per page, rounded up to a multiple of sizeof(unsigned long) */ bitmap->filemap_attr = kzalloc( - (((num_pages*4/8)+sizeof(unsigned long)-1) -/sizeof(unsigned long)) - *sizeof(unsigned long), + roundup( DIV_ROUND_UP(num_pages*4, 8), sizeof(unsigned long)), GFP_KERNEL); if (!bitmap->filemap_attr) goto out; - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2/3] make kernel threads invisible to /sbin/init
"Serge E. Hallyn" <[EMAIL PROTECTED]> writes: > Quoting Oleg Nesterov ([EMAIL PROTECTED]): >> 1. rename reparent_to_init() to reparent_kthread() and export it >> >> 2. use init_pid_ns.child_reaper instead of child_reaper(current) > > Each of these patches looks good to me, but this part in particular > is a must-have bugfix. Removing daemonize is a must have bug fix. This falls short of that so it is a good fix, but it doesn't solve the core problem that kernel daemons are being assigned pids inside of child pid namespaces. It doesn't solve the problem that some kernel daemons are using signals to communicate with user space. It doesn't solve the problem that we have to do a lot of massaging and maintenance to get kernel threads from grabbing references to namespaces and other kernel pieces they should not be grabbing. Eric - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Only send pdeath_signal when getppid changes.
On 4/10/07, Roland McGrath <[EMAIL PROTECTED]> wrote: > Does a parent death signal make most sense between separately written programs? I don't think it does. It has always seemed an utterly cockamamy feature to me, and I've never understood what actually motivated it. It's useful, but the other case is more important. > Does a parent death signal make most sense between processes that are part of > a larger program. That is the only way I can really see it being used. The only actual example of use I know is what Albert Cahalan reported. To my mind, the only semantics that matter for pdeath_signal are what previous uses expected in the past and still need for compatibility. If we started with a fresh rationale from the ground up on what the feature is good for, I am rather skeptical it would pass muster to be added today. Until inotify and dnotify work on /proc/12345/task, there really isn't an alternative for some of us. Polling is unusable. Ideally one could pick any container, session, process group, mm, task group, or task for notification of state change. State change means various things like destruction, addition of something new, exec, etc. (stuff one can see in /proc) With appropriate privs, having the debug-related stuff would be good as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 5/8] [Intel IOMMU] Graphics driver workarounds to provide unity map
On 2007.04.10 11:12:17 +, Andi Kleen wrote:
> > > On Mon, Apr 09, 2007 at 02:55:57PM -0700, Ashok Raj wrote:
> > > > Most GFX drivers don't call standard PCI DMA APIs to allocate DMA
> > > > buffer,
> > > > Such drivers will be broken with IOMMU enabled. To workaround this
> > > > issue,
> > > > we added two options.
> > >
> > > All drm drivers do it. If the usual out of tree crap vendors are too
> > > stupid for their own sake it's their fault.
> > >
> > > So NACK to this patch.
> >
> > That's my feeling as well, everything we care about should be using
> > the proper APIs or else what is the point of them...
>
> They can't. There is no proper API to do IOMMU mappings from user space.
> And that is how Xorg on x86 works.
>
> I had some hackish patches to enable mapping on
> /sys/bus/pci/.../coherent_mem, but
> you need ioctls to pass out the translated address and it wasn't
> exactly pretty. Still also not sure that's the right way.
>
For agpgart based gfx driver, we need to enable dma mapping on agpgart module,
which would work in the IOMMU case. I attach my current patches to do this.
Dave, how do you think about it?
diff --git a/drivers/char/agp/agp.h b/drivers/char/agp/agp.h
index 552815d..0d3312d 100644
--- a/drivers/char/agp/agp.h
+++ b/drivers/char/agp/agp.h
@@ -115,6 +115,9 @@ struct agp_bridge_driver {
void *(*agp_alloc_page)(struct agp_bridge_data *);
void (*agp_destroy_page)(void *);
int (*agp_type_to_mask_type) (struct agp_bridge_data *, int);
+ int (*agp_map_dma_pages)(struct agp_bridge_data *, struct agp_memory*);
+ void (*agp_unmap_dma_pages)(struct agp_bridge_data *,
+ struct agp_memory *);
};
struct agp_bridge_data {
diff --git a/drivers/char/agp/generic.c b/drivers/char/agp/generic.c
index f902d71..03a001a 100644
--- a/drivers/char/agp/generic.c
+++ b/drivers/char/agp/generic.c
@@ -112,22 +112,34 @@ void agp_alloc_page_array(size_t size, s
mem->memory = NULL;
mem->vmalloc_flag = 0;
- if (size <= 2*PAGE_SIZE)
+ if (size <= 2*PAGE_SIZE) {
mem->memory = kmalloc(size, GFP_KERNEL | __GFP_NORETRY);
+ mem->dma_memory = kmalloc(size, GFP_KERNEL | __GFP_NORETRY);
+ }
if (mem->memory == NULL) {
mem->memory = vmalloc(size);
- mem->vmalloc_flag = 1;
+ mem->vmalloc_flag = AGP_MEMORY_VMALLOC;
+ }
+ if (mem->dma_memory == NULL) {
+ mem->dma_memory = vmalloc(size);
+ /* XXX this is a little overdo */
+ mem->vmalloc_flag |= AGP_DMA_MEMORY_VMALLOC;
}
}
EXPORT_SYMBOL(agp_alloc_page_array);
void agp_free_page_array(struct agp_memory *mem)
{
- if (mem->vmalloc_flag) {
+ if (mem->vmalloc_flag & AGP_MEMORY_VMALLOC) {
vfree(mem->memory);
} else {
kfree(mem->memory);
}
+ if (mem->vmalloc_flag & AGP_DMA_MEMORY_VMALLOC) {
+ vfree(mem->dma_memory);
+ } else {
+ kfree(mem->dma_memory);
+ }
}
EXPORT_SYMBOL(agp_free_page_array);
@@ -155,6 +167,15 @@ static struct agp_memory *agp_create_use
kfree(new);
return NULL;
}
+ if (new->dma_memory == NULL) {
+ agp_free_key(new->key);
+ if (new->vmalloc_flag)
+ vfree(new->memory);
+ else
+ kfree(new->memory);
+ kfree(new);
+ return NULL;
+ }
new->num_scratch_pages = 0;
return new;
}
@@ -181,6 +202,15 @@ struct agp_memory *agp_create_memory(int
kfree(new);
return NULL;
}
+ if (new->dma_memory == NULL) {
+ agp_free_key(new->key);
+ if (new->vmalloc_flag)
+ vfree(new->memory);
+ else
+ kfree(new->memory);
+ kfree(new);
+ return NULL;
+ }
new->num_scratch_pages = scratch_pages;
new->type = AGP_NORMAL_MEMORY;
return new;
@@ -433,6 +463,13 @@ int agp_bind_memory(struct agp_memory *c
curr->bridge->driver->cache_flush();
curr->is_flushed = TRUE;
}
+
+ if (curr->bridge->driver->agp_map_dma_pages) {
+ if (!curr->bridge->driver->agp_map_dma_pages(curr->bridge,
curr))
+ return -EINVAL;
+ curr->is_dma_mapped = 1;
+ }
+
ret_val = curr->bridge->driver->insert_memory(curr, pg_start,
curr->type);
if (ret_val != 0)
@@ -470,6 +507,10 @@ int agp_unbind_memory(struct agp_memory
if (ret_val != 0)
return ret_val;
+ if (curr->bridge->driver->agp_unmap_dma_pages)
+ curr->bridge->driver->agp_unmap_dma_pages(curr->bridge, curr);
+ curr->is_dma_mapped = 0;
+
curr->is_bound = FALSE;
c
Re: Build error : 2.6.21-rc6-mm1 on sparc64
* Andrew Morton ([EMAIL PROTECTED]) wrote: > On Wed, 11 Apr 2007 11:15:39 +0900 Fernando Luis Vázquez Cao <[EMAIL > PROTECTED]> wrote: > > > The problem is that to use hard_smp_processor_id in UP kernels just > > including linux/smp.h does not suffice anymore. Now > > hard_smp_processor_id is architecture specific code and consequently > > asm/smp.h should be included explicitly. > > yeah. The fact that linux/smp.h only exposes asm/smp.h if CONFIG_SMP hits > us again and again and again. It would be good to fix that up, I guess by > including asm/smp.h unconditionally from within linux/smp.h. > > But that's a separate little project. > > > Mathieu, does the (untested) patch below fix this issue? > With this patch, sparc64 builds correctly. Thanks! > I'll test it. > -- Mathieu Desnoyers Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F BA06 3F25 A8FE 3BAE 9A68 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] markers-doc-update-flags-example
On Tue, 10 Apr 2007 19:26:20 -0400 Mathieu Desnoyers wrote:
> -- CUT -
> /* probe-example.c
> *
> - * Loads a function at a marker call site.
> + * Connects a two functions to marker call sites.
s/a //
> *
> * (C) Copyright 2007 Mathieu Desnoyers <[EMAIL PROTECTED]>
> *
> @@ -109,67 +113,83 @@ Flag compatibility is checked before connecting the
> probe to the marker.
>
> #include
> #include
> +#include
> #include
> +#include
> +
> +#define NUM_PROBES (sizeof(probe_array) / sizeof(struct probe_data))
#define NUM_PROBES ARRAY_SIZE(probe_array)
> -#define SUBSYSTEM_EVENT_FORMAT "%d %s %p[struct task_struct]"
> -void probe_subsystem_event(const char *format, ...)
> +struct probe_data {
> + const char *name;
> + const char *format;
> + marker_probe_func *probe_func;
> +};
> +
>
> +static struct probe_data probe_array[] =
> +{
> + { .name = "subsystem_event",
> + .format = "%d %s",
> + .probe_func = probe_subsystem_event },
> + { .name = "subsystem_eventb",
> + .format = MARK_NOARGS,
> + .probe_func = probe_subsystem_eventb },
> +};
> +
---
~Randy
*** Remember to use Documentation/SubmitChecklist when testing your code ***
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Build error : 2.6.21-rc6-mm1 on sparc64
On Wed, 11 Apr 2007 11:15:39 +0900 Fernando Luis Vázquez Cao <[EMAIL PROTECTED]> wrote: > The problem is that to use hard_smp_processor_id in UP kernels just > including linux/smp.h does not suffice anymore. Now > hard_smp_processor_id is architecture specific code and consequently > asm/smp.h should be included explicitly. yeah. The fact that linux/smp.h only exposes asm/smp.h if CONFIG_SMP hits us again and again and again. It would be good to fix that up, I guess by including asm/smp.h unconditionally from within linux/smp.h. But that's a separate little project. > Mathieu, does the (untested) patch below fix this issue? I'll test it. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Improve heuristic detecting sequential reads
On Tue, 10 Apr 2007 17:54:11 +0200 Jan Kara <[EMAIL PROTECTED]> wrote: > Introduce ra.offset and store in it an offset where the previous read ended. > This way > we can detect whether reads are really sequential (and thus we should not > mark the page > as accessed repeatedly) or whether they are random and just happen to be in > the same page > (and the page should really be marked accessed again). (less columns, please) OK. So prev_page and prev_offset are now a complexified representation of a loff_t, no? So why don't we just use a loff_t for this? Anyway, the asymmetry in our handling of prev_index (sometimes called prev_page!) and prev_offset is unpleasing. This: --- a/mm/filemap.c~readahead-improve-heuristic-detecting-sequential-reads-tidy +++ a/mm/filemap.c @@ -933,6 +933,7 @@ page_ok: if (prev_index != index || offset != prev_offset) mark_page_accessed(page); prev_index = index; + prev_offset = ra.offset = offset; /* * Ok, we have the page, and it's up-to-date, so @@ -948,7 +949,6 @@ page_ok: offset += ret; index += offset >> PAGE_CACHE_SHIFT; offset &= ~PAGE_CACHE_MASK; - prev_offset = ra.offset = offset; page_cache_release(page); if (ret == nr && desc->count) improves things somewhat. But I think it would be nicer if their handling was unified, or at least consistent. We update ra.offset here, and we update ra.prev_page over there. And shouldn't offset be called prev_offset? Or should prev_page be called page? Or index? Or prev_index? Or Marmaduke? The naming is all a mess. Wanna take a look at all of this, please? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build error : 2.6.21-rc6-mm1 on sparc64
On Tue, 2007-04-10 at 18:18 -0700, Andrew Morton wrote: > On Tue, 10 Apr 2007 20:48:38 -0400 > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > I get the following build error when building 2.6.21-rc6-mm1 for > > sparc64: > > > > > > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc > > -Wp,-MD,arch/sparc64/kernel/.traps.o.d -nostdinc -isystem > > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/lib/gcc/sparc64-unknown-linux-gnu/3.4.5/include > > -D__KERNEL__ -Iinclude -Iinclude2 > > -I/home/compudj/git/linux-2.6-lttng/include -include > > include/linux/autoconf.h > > -I/home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel > > -Iarch/sparc64/kernel -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs > > -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc > > -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare > > -Wa,--undeclared-regs -fomit-frame-pointer -Wdeclaration-after-statement > > -Werror -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(traps)" > > -D"KBUILD_MODNAME=KBUILD_STR(traps)" -c -o arch/sparc64/kernel/traps.o > > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c > > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c: In function > > `init_cur_cpu_trap': > > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c:2497: > > warning: implicit declaration of function `hard_smp_processor_id' > > make[2]: *** [arch/sparc64/kernel/traps.o] Error 1 > > make[1]: *** [arch/sparc64/kernel] Error 2 > > make: *** [_all] Error 2 > > Not sure what the approved fix is here. Fernando, please take a look, and > review all other architectures? The problem is that to use hard_smp_processor_id in UP kernels just including linux/smp.h does not suffice anymore. Now hard_smp_processor_id is architecture specific code and consequently asm/smp.h should be included explicitly. Mathieu, does the (untested) patch below fix this issue? [PATCH] Remove hardcoding of hard_smp_processor_id on UP systems - sparc64 fix To use hard_smp_processor_id in UP kernels just including linux/smp.h does not suffice anymore. Now hard_smp_processor_id is architecture specific code and consequently asm/smp.h should be included explicitly. Signed-off-by: Fernando Luis Vazquez Cao <[EMAIL PROTECTED]> --- diff -urNp linux-2.6.21-rc6-mm1-orig/arch/sparc64/kernel/traps.c linux-2.6.21-rc6-mm1/arch/sparc64/kernel/traps.c --- linux-2.6.21-rc6-mm1-orig/arch/sparc64/kernel/traps.c 2007-04-11 10:48:09.0 +0900 +++ linux-2.6.21-rc6-mm1/arch/sparc64/kernel/traps.c2007-04-11 10:57:06.0 +0900 @@ -19,6 +19,7 @@ #include #include +#include #include #include #include - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] gpiodev - API definitions
Hello Eric,
Wednesday, April 11, 2007, 3:30:45 AM, you wrote:
> it looks ok, but I have several questions:
> 1. why should we bind this to platform_device, what if the gpio device
> is not actually a "platform_device", say, a I2C device, a SPI device or
> even a USB device?
Good point. That was handhelds.org-specific "optimization", as we so
far mostly dealing with GPIO devices on platform bus, and could save
us writing "&pdev.dev". This must be changed to use struct device,
sure.
> 2. I still doubt the benefit of using of a structure for a gpio, isn't a gpio
> number not enough?
Well, I replied to David's earlier post to LAKML after posting this,
and discussed both approach in more detail (and even more color). To
sum up, yes, we can use either structures for GPIOs, or scalar ints.
But both these approaches leads to some tradeoffs. Our argument is
that "scalar" (aka flat) approach leads to more tradeoffs - you need
to "flatten" your GPIO space first, and this is least evil, as indeed
this could be done using compile-time defines. But then you need to
"unflatten" it, and this happens at runtime, wasting cycles.
Using structure GPIO ids skips this "flattening"/"unflattening"
(maybe multiplexing/demultiplexing are better terms) phases. Trade off
is necessity to write:
.gpio = {&gpio_device, GPIO_DEVICE_GPIO_1}
instead of:
#define BASE_FOR_GPIO_DEVICE_ON_MY_BOARD 1000
.gpio = BASE_FOR_GPIO_DEVICE_ON_MY_BOARD + GPIO_DEVICE_GPIO_1
IMHO, pretty acceptable syntactical tradeoff ;-)
> 3. If one is going to use a GPIO, he has to initialize a "struct gpio"
> before that, how is he suppose to know the value for "gpio->gpio_dev"?
Yes, so the target usage of GPIODEV API is to write
device-independent driver. Such driver simply shouldn't care what
device is used for GPIO - it should be able to accept any, - and how
exactly GPIO ops are performed.
But something should care what actual GPIO device is being used. And
we know what's that - something which people call "platform code", but
I better call old good "machine definition file", to remove any
ambiguities. Such a definition is written for a specific machine, so
obviously you know what GPIO devices it has, and for what purpose pins
of them I used for. So, you have something like:
struct platform_device my_gpio_device = { .dev = {.name = "asic_foo"}};
struct some_driver_platform_data some_driver_pdata = {
...
.pullup = {&my_gpio_device.dev, ASIC_FOO_GPIO_PULLUP},
...
}
Important thing to note here is that structured GPIO id's are still
constants! Link-time constant, not compile-time, as scalar id's would
be, but still there's zero overhead at runtime.
> 4. how can we optimize to a direct register access instruction (e.g.
> to GPDR in PXA) for bit-banging operation (pardon me, I don't exactly
> remember the name for such operation, maybe bit-banging)
Well, you should first decide what exactly you want. If you want to
do bit-banging on PXA, then well, - you don't need GPIODEV and its
polymorphic support at all! If you know GPIO# beforehand, just use
David's GPIO API - it will constant-optimize it to GPCR/GPSR access
rigth away.
If you need to support arbitrary GPIO#, you can get better
frequency/throughput by skipping GPIO API still, like in the following
pseudocode:
MASK = 1 << GPIO#;
for (;count < SIZE; count--) {
GPSR = MASK;
nop;
GPCR = MASK;
}
If you'd use GPIO API, it would recompute MASK on each call, wasting
your cycles.
But now it's completely different story if you have a need to
write a driver which will bang bits on any GPIO of any device,
including such devices which you can't imagine at the time of driver's
writing at all - that's the GPIODEV estate. Obviously, for such general
usage it doesn't make too much sense to speak about optimization for a one
tiny specific device out of infinity of its domain - it's purpose is
exactly generality, not optimality, and it's well known that these
notions are reciprocals.
If you still want super-optimal handling for PXA case, while being
able to still support anything else, solution is also known - have two
drivers, one fast and PXA-adhoc, another generic but slower, and use
extraneous logic to select which one to use.
Back to GPIODEV's traits, it's still offers best performance which
can be achieved for infinitely extendable solution (within bounds of
the interface defined, of course), because it uses best known solution
for such problem (and such solution is simple and fast) - indirect
function call, and all data needed for such call are available right
away due to the magic of structural GPIO id's.
In this regard, your implementation draft, which uses scalars and
looping to find out owning GPIO device/handler, pretty bad suited for
bit-banging at all: just consider that GPIO operation overhead in this
case is dependent on number of GPIO devices present. Add new one, and
your (supposedly) carefully tuned latencies and delay "float".
Davi
Re: link error : 2.6.21-rc6-mm1 for s390
From: Andrew Morton <[EMAIL PROTECTED]> Date: Tue, 10 Apr 2007 18:47:38 -0700 > On Tue, 10 Apr 2007 18:36:29 -0700 (PDT) > David Miller <[EMAIL PROTECTED]> wrote: > > > From: Andrew Morton <[EMAIL PROTECTED]> > > Date: Tue, 10 Apr 2007 18:29:37 -0700 > > > > > git-net.patch implements generic lib/div64.c, but s390 also has a > > > private one. Presumably the appropriate fix is to remove s390's > > > private implementation within davem's tree. > > > > The s390 version seems to be optimized in assembler for that > > processor, therefore we should probably instead elide the > > generic version on s390. > > We're sure that it has the same API? Yes, I read over it, I'm pretty sure it does. > attribute(weak) would give a nicer result? I'm not so sure. > We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up > using lib/div64.c's EXPORT_SYMBOL(). It shouldn't matter if we use s390's or the generic version's Oh, I see, s390 uses lib-y for it's div64.o object, that's a bug. I'll fix that up, thanks Andrew. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: Build error : 2.6.21-rc6-mm1 for arm
> From: Andrew Morton [mailto:[EMAIL PROTECTED] > On Tue, 10 Apr 2007 20:54:20 -0400 > Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > > > I get the following build error when compiling 2.6.21-rc6-mm1 for arm > > "footbridge" : > > > > ... > > > > make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=init > > /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/bin/arm- > unknown-linux-gnu-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem > /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/lib/gcc/arm- > unknown-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -Iinclude2 - > I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h - > mlittle-endian -I/home/compudj/git/linux-2.6-lttng/init -Iinit -Wall -Wundef - > Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -marm - > fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=apcs-gnu -mno-thumb- > interwork -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 -msoft-float > -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after- > statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" - > D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o > init/main.o /home/compudj/git/linux-2.6-lttng/init/main.c > > In file included from /home/compudj/git/linux-2.6-lttng/include/linux/dma- > mapping.h:34, > > from /home/compudj/git/linux-2.6- > lttng/include/linux/dmaengine.h:29, > > from /home/compudj/git/linux-2.6- > lttng/include/linux/skbuff.h:30, > > from /home/compudj/git/linux-2.6- > lttng/include/linux/netlink.h:140, > > from /home/compudj/git/linux-2.6- > lttng/include/linux/genetlink.h:4, > > from /home/compudj/git/linux-2.6- > lttng/include/net/genetlink.h:4, > > from /home/compudj/git/linux-2.6- > lttng/include/linux/taskstats_kern.h:12, > > from /home/compudj/git/linux-2.6-lttng/init/main.c:45: > > include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_cpu': > > include2/asm/dma-mapping.h:320: warning: implicit declaration of function > 'dma_sync_single_for_cpu' > > include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_device': > > include2/asm/dma-mapping.h:329: warning: implicit declaration of function > 'dma_sync_single_for_device' > > include2/asm/dma-mapping.h: At top level: > > include2/asm/dma-mapping.h:352: warning: conflicting types for > 'dma_sync_single_for_cpu' > > include2/asm/dma-mapping.h:352: error: static declaration of > 'dma_sync_single_for_cpu' follows non-static declaration > > include2/asm/dma-mapping.h:320: error: previous implicit declaration of > 'dma_sync_single_for_cpu' was here > > include2/asm/dma-mapping.h:360: warning: conflicting types for > 'dma_sync_single_for_device' > > include2/asm/dma-mapping.h:360: error: static declaration of > 'dma_sync_single_for_device' follows non-static declaration > > include2/asm/dma-mapping.h:329: error: previous implicit declaration of > 'dma_sync_single_for_device' was here > > make[2]: *** [init/main.o] Error 1 > > make[1]: *** [init] Error 2 > > make: *** [_all] Error 2 > > Dan, this is caused by git-md-accel.patch > Looks like arm-dma-mappingh.patch is the culprit. Fix attached. -- Dan fix-arm-dma-mappingh.patch Description: fix-arm-dma-mappingh.patch
Re: link error : 2.6.21-rc6-mm1 for s390
On Tue, 10 Apr 2007 18:36:29 -0700 (PDT)
David Miller <[EMAIL PROTECTED]> wrote:
> From: Andrew Morton <[EMAIL PROTECTED]>
> Date: Tue, 10 Apr 2007 18:29:37 -0700
>
> > git-net.patch implements generic lib/div64.c, but s390 also has a
> > private one. Presumably the appropriate fix is to remove s390's
> > private implementation within davem's tree.
>
> The s390 version seems to be optimized in assembler for that
> processor, therefore we should probably instead elide the
> generic version on s390.
We're sure that it has the same API?
> How about something like this?
>
> diff --git a/include/asm-s390/div64.h b/include/asm-s390/div64.h
> index 6cd978c..21aea15 100644
> --- a/include/asm-s390/div64.h
> +++ b/include/asm-s390/div64.h
> @@ -1 +1,2 @@
> #include
> +#define HAVE_ARCH_DIV64_32
> diff --git a/lib/div64.c b/lib/div64.c
> index 74f0c8c..5b480fa 100644
> --- a/lib/div64.c
> +++ b/lib/div64.c
> @@ -23,6 +23,8 @@
> /* Not needed on 64bit architectures */
> #if BITS_PER_LONG == 32
>
> +#ifndef HAVE_ARCH_DIV64_32
> +
> uint32_t __div64_32(uint64_t *n, uint32_t base)
> {
> uint64_t rem = *n;
> @@ -58,6 +60,8 @@ uint32_t __div64_32(uint64_t *n, uint32_t base)
>
> EXPORT_SYMBOL(__div64_32);
>
> +#endif /* !(HAVE_ARCH_DIV64_32) */
> +
> /* 64bit divisor, dividend and result. dynamic precision */
> uint64_t div64_64(uint64_t dividend, uint64_t divisor)
> {
attribute(weak) would give a nicer result?
We'd also need to remove s390's EXPORT_SYMBOL(__div64_32), so s390 ends up
using lib/div64.c's EXPORT_SYMBOL().
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: If not readdir() then what?
In article <[EMAIL PROTECTED]> you wrote: > Otherwise, the client would have to cache _all_ previous READDIR results > since the last opendir()/rewinddir() in order to be able to do its own > loop detection and that will obviously never scale for large directories > or for directories that change frequently... Unless you have a COW style filesystem with versioning (think oracle tables) you will have to invalidate cookies often or do copies - on client or server. And I am not sure whats worse (for apps)... disappearing/missing files or duplicates. Gruss bernd - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2/8] [Intel IOMMU] Some generic search functions required to lookup device relationships.
On Tue, 2007-04-10 at 06:03 -0700, Greg KH wrote:
> On Tue, Apr 10, 2007 at 04:11:38PM +0800, Shaohua Li wrote:
> > On Mon, 2007-04-09 at 20:46 -0700, Greg KH wrote:
> > > On Mon, Apr 09, 2007 at 02:55:54PM -0700, Ashok Raj wrote:
> > > > +/*
> > > > + * find the upstream PCIE-to-PCI bridge of a PCI device
> > > > + * if the device is PCIE, return NULL
> > > > + * if the device isn't connected to a PCIE bridge (that is its parent
> > > > is a
> > > > + * legacy PCI bridge and the bridge is directly connected to bus 0),
> > > > return its
> > > > + * parent
> > > > + */
> > > > +struct pci_dev *
> > > > +pci_find_upstream_pcie_bridge(struct pci_dev *pdev)
> > > > +{
> > > > + struct pci_dev *tmp = NULL;
> > > > +
> > > > + if (pdev->is_pcie)
> > > > + return NULL;
> > > > + while (1) {
> > > > + if (!pdev->bus->self)
> > > > + break;
> > > > + pdev = pdev->bus->self;
> > > > + /* a p2p bridge */
> > > > + if (!pdev->is_pcie) {
> > > > + tmp = pdev;
> > > > + continue;
> > > > + }
> > > > + /* PCI device should connect to a PCIE bridge */
> > > > + BUG_ON(pdev->pcie_type != PCI_EXP_TYPE_PCI_BRIDGE);
> > > > + return pdev;
> > > > + }
> > > > +
> > > > + return tmp;
> > > > +}
> > >
> > > No locking while you walk up the bus list?
> > hmm, iommu driver didn't support pci hotplug in current stage. But we
> > can add lock here.
>
> Please do, as PCI-E hotplug is much more common than PCI hotplug these
> days (think ExpressCard in millions of laptops...)
>
> > > > --- linux-2.6.21-rc5.orig/include/linux/pci.h 2007-04-03
> > > > 04:30:51.0 -0700
> > > > +++ linux-2.6.21-rc5/include/linux/pci.h2007-04-03
> > > > 06:58:58.0 -0700
> > > > @@ -126,6 +126,7 @@
> > > > unsigned short subsystem_device;
> > > > unsigned intclass; /* 3 bytes: (base,sub,prog-if)
> > > > */
> > > > u8 hdr_type; /* PCI header type (`multi'
> > > > flag masked out) */
> > > > + u8 pcie_type; /* PCI-E device/port type */
> > > > u8 rom_base_reg; /* which config register
> > > > controls the ROM */
> > > > u8 pin;/* which interrupt pin this
> > > > device uses */
> > > >
> > > > @@ -168,6 +169,7 @@
> > > > unsigned intmsi_enabled:1;
> > > > unsigned intmsix_enabled:1;
> > > > unsigned intis_managed:1;
> > > > + unsigned intis_pcie:1;
> > >
> > > Do you really need both fields? Wouldn't just the pcie_type one work
> > > (with some NOT_PCIE type being set for it if it isn't I suppose.)
> > There are some encodings are reserved for future. Just don't want to use
> > reserved bits, as we don't know which one is proper for NOT_PCIE.
>
> What are the current encodings? I don't have my copy of the pci spec
> availble at the moment...
0 - 1010b is defined. Other bits are reserved. How about the pcie_type's
highest bit determines NOT_PCIE? the pcie spec just use 4 bits for pcie
type.
Thanks,
Shaohua
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: link error : 2.6.21-rc6-mm1 for s390
From: Andrew Morton <[EMAIL PROTECTED]>
Date: Tue, 10 Apr 2007 18:29:37 -0700
> git-net.patch implements generic lib/div64.c, but s390 also has a
> private one. Presumably the appropriate fix is to remove s390's
> private implementation within davem's tree.
The s390 version seems to be optimized in assembler for that
processor, therefore we should probably instead elide the
generic version on s390.
How about something like this?
diff --git a/include/asm-s390/div64.h b/include/asm-s390/div64.h
index 6cd978c..21aea15 100644
--- a/include/asm-s390/div64.h
+++ b/include/asm-s390/div64.h
@@ -1 +1,2 @@
#include
+#define HAVE_ARCH_DIV64_32
diff --git a/lib/div64.c b/lib/div64.c
index 74f0c8c..5b480fa 100644
--- a/lib/div64.c
+++ b/lib/div64.c
@@ -23,6 +23,8 @@
/* Not needed on 64bit architectures */
#if BITS_PER_LONG == 32
+#ifndef HAVE_ARCH_DIV64_32
+
uint32_t __div64_32(uint64_t *n, uint32_t base)
{
uint64_t rem = *n;
@@ -58,6 +60,8 @@ uint32_t __div64_32(uint64_t *n, uint32_t base)
EXPORT_SYMBOL(__div64_32);
+#endif /* !(HAVE_ARCH_DIV64_32) */
+
/* 64bit divisor, dividend and result. dynamic precision */
uint64_t div64_64(uint64_t dividend, uint64_t divisor)
{
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: link error : 2.6.21-rc6-mm1 for s390
On Tue, 10 Apr 2007 20:56:16 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > The last for today : link error of 2.6.21-rc6-mm1 for s390 : > > > > /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld > -m elf_s390 -e start -o .tmp_vmlinux1 -T arch/s390/kernel/vmlinux.lds > arch/s390/kernel/head.o arch/s390/kernel/init_task.o init/built-in.o > --start-group usr/built-in.o arch/s390/mm/built-in.o > arch/s390/kernel/built-in.o arch/s390/crypto/built-in.o > arch/s390/appldata/built-in.o arch/s390/hypfs/built-in.o kernel/built-in.o > mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o > crypto/built-in.o block/built-in.o ltt/built-in.o lib/lib.a > arch/s390/lib/lib.a lib/built-in.o arch/s390/lib/built-in.o > drivers/built-in.o sound/built-in.o drivers/s390/built-in.o > arch/s390/math-emu/built-in.o net/built-in.o --end-group > lib/built-in.o: In function `__div64_32': > : multiple definition of `__div64_32' > arch/s390/lib/lib.a(div64.o):div64.c:(.text+0x0): first defined here > /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld: > Warning: size of symbol `__div64_32' changed from 218 in > arch/s390/lib/lib.a(div64.o) to 260 in lib/built-in.o git-net.patch implements generic lib/div64.c, but s390 also has a private one. Presumably the appropriate fix is to remove s390's private implementation within davem's tree. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build error : 2.6.21-rc6-mm1 for arm
On Tue, 10 Apr 2007 20:54:20 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > I get the following build error when compiling 2.6.21-rc6-mm1 for arm > "footbridge" : > > ... > > make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=init > > /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc > -Wp,-MD,init/.main.o.d -nostdinc -isystem > /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/4.0.2/include > -D__KERNEL__ -Iinclude -Iinclude2 > -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h > -mlittle-endian -I/home/compudj/git/linux-2.6-lttng/init -Iinit -Wall -Wundef > -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -marm > -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=apcs-gnu > -mno-thumb-interwork -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 > -msoft-float -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls > -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" > -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c > -o init/main.o /home/compudj/git/linux-2.6-lttng/init/main.c > In file included from > /home/compudj/git/linux-2.6-lttng/include/linux/dma-mapping.h:34, > from > /home/compudj/git/linux-2.6-lttng/include/linux/dmaengine.h:29, > from > /home/compudj/git/linux-2.6-lttng/include/linux/skbuff.h:30, > from > /home/compudj/git/linux-2.6-lttng/include/linux/netlink.h:140, > from > /home/compudj/git/linux-2.6-lttng/include/linux/genetlink.h:4, > from > /home/compudj/git/linux-2.6-lttng/include/net/genetlink.h:4, > from > /home/compudj/git/linux-2.6-lttng/include/linux/taskstats_kern.h:12, > from /home/compudj/git/linux-2.6-lttng/init/main.c:45: > include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_cpu': > include2/asm/dma-mapping.h:320: warning: implicit declaration of function > 'dma_sync_single_for_cpu' > include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_device': > include2/asm/dma-mapping.h:329: warning: implicit declaration of function > 'dma_sync_single_for_device' > include2/asm/dma-mapping.h: At top level: > include2/asm/dma-mapping.h:352: warning: conflicting types for > 'dma_sync_single_for_cpu' > include2/asm/dma-mapping.h:352: error: static declaration of > 'dma_sync_single_for_cpu' follows non-static declaration > include2/asm/dma-mapping.h:320: error: previous implicit declaration of > 'dma_sync_single_for_cpu' was here > include2/asm/dma-mapping.h:360: warning: conflicting types for > 'dma_sync_single_for_device' > include2/asm/dma-mapping.h:360: error: static declaration of > 'dma_sync_single_for_device' follows non-static declaration > include2/asm/dma-mapping.h:329: error: previous implicit declaration of > 'dma_sync_single_for_device' was here > make[2]: *** [init/main.o] Error 1 > make[1]: *** [init] Error 2 > make: *** [_all] Error 2 Dan, this is caused by git-md-accel.patch > > my .config : - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build error : 2.6.21-rc6-mm1 on sparc64
On Tue, 10 Apr 2007 20:48:38 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > I get the following build error when building 2.6.21-rc6-mm1 for > sparc64: > > > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc > -Wp,-MD,arch/sparc64/kernel/.traps.o.d -nostdinc -isystem > /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/lib/gcc/sparc64-unknown-linux-gnu/3.4.5/include > -D__KERNEL__ -Iinclude -Iinclude2 > -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h > -I/home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel -Iarch/sparc64/kernel > -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing > -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow > -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs > -fomit-frame-pointer -Wdeclaration-after-statement -Werror > -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(traps)" > -D"KBUILD_MODNAME=KBUILD_STR(traps)" -c -o arch/sparc64/kernel/traps.o > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c: In function > `init_cur_cpu_trap': > /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c:2497: warning: > implicit declaration of function `hard_smp_processor_id' > make[2]: *** [arch/sparc64/kernel/traps.o] Error 1 > make[1]: *** [arch/sparc64/kernel] Error 2 > make: *** [_all] Error 2 Not sure what the approved fix is here. Fernando, please take a look, and review all other architectures? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Build error : 2.6.21-rc6-mm1 for ppc 405
On Tue, 10 Apr 2007 20:50:42 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > Hi Andrew, > > I get the following build error when building 2.6.21-rc6-mm1 for ppc > 405: > > > /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c: In function > 'ppc4xx_alloc_dma_handle': > /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c:374: > warning: implicit declaration of function 'dma_alloc_coherent' gregkh-pci-pci-cleanup-the-includes-of-linux-pcih.patch removes the pci.h include, which presumably is what broke this. Appropriate fix is to include dma-mapping.h in ppc4xx_sgdma.c. I queued a fix. > /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:37: warning: > 'struct device_node' declared inside parameter list Srinivasa Ds <[EMAIL PROTECTED]> sent a fix for this today. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
Roland Dreier wrote: > Is there any chance of getting a fix for the use-after-free that can > be caused by allocating something from userspace, failing to mmap the > buffer and then exiting? To see what happens, look at how > ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap > "list" (and yes it would be much cleaner to just use struct list_head > here rather than reimplementing a linked list yourself), and then look > at how ipath_destroy_cq() frees the same structure without checking if > it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? We're tracking it here (bug 12010 on our internal bugzilla), and it's on my list to get done "soon". I'm currently in the middle of some other bug fixes, but when I get to a good stopping point, I'll get this fixed. Shouldn't be too difficult. If you'd like to track it yourself, feel free to open an OpenFabrics bug. I'll update the bug when I get a patch done. Regards, Robert. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1 build fails for m68k
On Tue, 10 Apr 2007 20:41:12 -0400 Mathieu Desnoyers <[EMAIL PROTECTED]> wrote: > I get the following compiler error when building 2.6.21-rc6-mm1 for > m68k: > > > > /opt/crosstool/gcc-4.1.1-glibc-2.3.6/m68k-unknown-linux-gnu/bin/m68k-unknown-linux-gnu-gcc > -Wp,-MD,arch/m68k/kernel/.asm-offsets.s.d -nostdinc -isystem > /opt/crosstool/gcc-4.1.1-glibc-2.3.6/m68k-unknown-linux-gnu/lib/gcc/m68k-unknown-linux-gnu/4.1.1/include > -D__KERNEL__ -Iinclude -Iinclude2 > -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h > -I/home/compudj/git/linux-2.6-lttng/. -I. -Wall -Wundef -Wstrict-prototypes > -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -pipe > -fno-strength-reduce -ffixed-a2 -m68040 -fomit-frame-pointer > -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign > -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(asm_offsets)" > -D"KBUILD_MODNAME=KBUILD_STR(asm_offsets)" -fverbose-asm -S -o > arch/m68k/kernel/asm-offsets.s > /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c > /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c: In function > 'main': > /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c:27: error: > 'struct task_struct' has no member named 'ptrace' That's because m68k is missing utrace support. Quite a lot of architectures are in that state. If you're using quilt (you should be) you can - remove utrace patches from the series file - quilt push linux-kernel-markers-documentation.patch - do work I'll reorder the -mm series file so that utrace comes much later, which will simplify this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
link error : 2.6.21-rc6-mm1 for s390
Hi Andrew, The last for today : link error of 2.6.21-rc6-mm1 for s390 : /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld -m elf_s390 -e start -o .tmp_vmlinux1 -T arch/s390/kernel/vmlinux.lds arch/s390/kernel/head.o arch/s390/kernel/init_task.o init/built-in.o --start-group usr/built-in.o arch/s390/mm/built-in.o arch/s390/kernel/built-in.o arch/s390/crypto/built-in.o arch/s390/appldata/built-in.o arch/s390/hypfs/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o block/built-in.o ltt/built-in.o lib/lib.a arch/s390/lib/lib.a lib/built-in.o arch/s390/lib/built-in.o drivers/built-in.o sound/built-in.o drivers/s390/built-in.o arch/s390/math-emu/built-in.o net/built-in.o --end-group lib/built-in.o: In function `__div64_32': : multiple definition of `__div64_32' arch/s390/lib/lib.a(div64.o):div64.c:(.text+0x0): first defined here /opt/crosstool/gcc-4.1.1-glibc-2.3.6/s390-unknown-linux-gnu/bin/s390-unknown-linux-gnu-ld: Warning: size of symbol `__div64_32' changed from 218 in arch/s390/lib/lib.a(div64.o) to 260 in lib/built-in.o make[1]: *** [.tmp_vmlinux1] Error 1 make: *** [_all] Error 2 my .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:18 2007 # CONFIG_MMU=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_RWSEM_XCHGADD_ALGORITHM=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_TIME=y CONFIG_GENERIC_BUG=y CONFIG_NO_IOMEM=y CONFIG_NO_DMA=y CONFIG_S390=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set # CONFIG_CPUSETS is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Base setup # # # Processor type and features # # CONFIG_64BIT is not set CONFIG_32BIT=y CONFIG_SMP=y CONFIG_NR_CPUS=32 # CONFIG_HOTPLUG_CPU is not set CONFIG_DEFAULT_MIGRATION_COST=100 CONFIG_MATHEMU=y CONFIG_AUDIT_ARCH=y # CONFIG_S390_SWITCH_AMODE is not set # CONFIG_S390_EXEC_PROTECT is not set # # Code generation options # CONFIG_MARCH_G5=y # CONFIG_MARCH_Z900 is not set # CONFIG_MARCH_Z990 is not set # CONFIG_MARCH_Z9_109 is not set # CONFIG_PACK_STACK is not set # CONFIG_CHECK_STACK is not set # CONFIG_WARN_STACK is not set CONFIG_ARCH_POPULATES_NODE_MAP=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=0 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_HOLES_IN_ZONE=y # # I/O subsystem configuration # # CONFIG_MACHCHK_WARNING is not set # CONFIG_QDIO is not set # # Misc # # CONFIG_PREEMPT is not set CONFIG_IPL=y # CONFIG_IPL_TAPE is not set CONFIG_IPL_VM=y CONFIG_BINFMT_ELF=y # CONFIG_BINFMT_MISC is not set # CONFIG_PROCESS_DEBUG is not set CONFIG_PFAULT=y # CONFIG_SHARED_KERNEL is not set # CONFIG_CMM is not set # CONFIG_VIRT_TIMER is not set # CONFIG_NO_IDLE_HZ is not set CONFIG_S390_HYPFS_FS=y # CONFIG_KEXEC is not set # CONFIG_Z
Build error : 2.6.21-rc6-mm1 for arm
Hi Andrew, I get the following build error when compiling 2.6.21-rc6-mm1 for arm "footbridge" : /bin/sh /home/compudj/git/linux-2.6-lttng/scripts/checksyscalls.sh /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc -Wp,-MD,./.missing-syscalls.d -nostdinc -isystem /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -mlittle-endian -I/home/compudj/git/linux-2.6-lttng/. -I. -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -marm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=apcs-gnu -mno-thumb-interwork -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 -msoft-float -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(missing_syscalls)" -D"KBUILD_MODNAME=KBUILD_STR(missing_syscalls)" :1092:2: warning: #warning syscall fadvise64 not implemented :1176:2: warning: #warning syscall fadvise64_64 not implemented :1260:2: warning: #warning syscall migrate_pages not implemented :1316:2: warning: #warning syscall pselect6 not implemented :1320:2: warning: #warning syscall ppoll not implemented :1340:2: warning: #warning syscall sync_file_range not implemented :1360:2: warning: #warning syscall epoll_pwait not implemented :1364:2: warning: #warning syscall lutimesat not implemented :1368:2: warning: #warning syscall signalfd not implemented :1372:2: warning: #warning syscall timerfd not implemented :1376:2: warning: #warning syscall eventfd not implemented :1380:2: warning: #warning syscall revokeat not implemented :1384:2: warning: #warning syscall frevoke not implemented make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=scripts make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=scripts/mod make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=init /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/bin/arm-unknown-linux-gnu-gcc -Wp,-MD,init/.main.o.d -nostdinc -isystem /opt/crosstool/gcc-4.0.2-glibc-2.3.6/arm-unknown-linux-gnu/lib/gcc/arm-unknown-linux-gnu/4.0.2/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -mlittle-endian -I/home/compudj/git/linux-2.6-lttng/init -Iinit -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -marm -fno-omit-frame-pointer -mapcs -mno-sched-prolog -mabi=apcs-gnu -mno-thumb-interwork -D__LINUX_ARM_ARCH__=4 -march=armv4 -mtune=strongarm110 -msoft-float -Uarm -fno-omit-frame-pointer -fno-optimize-sibling-calls -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(main)" -D"KBUILD_MODNAME=KBUILD_STR(main)" -c -o init/main.o /home/compudj/git/linux-2.6-lttng/init/main.c In file included from /home/compudj/git/linux-2.6-lttng/include/linux/dma-mapping.h:34, from /home/compudj/git/linux-2.6-lttng/include/linux/dmaengine.h:29, from /home/compudj/git/linux-2.6-lttng/include/linux/skbuff.h:30, from /home/compudj/git/linux-2.6-lttng/include/linux/netlink.h:140, from /home/compudj/git/linux-2.6-lttng/include/linux/genetlink.h:4, from /home/compudj/git/linux-2.6-lttng/include/net/genetlink.h:4, from /home/compudj/git/linux-2.6-lttng/include/linux/taskstats_kern.h:12, from /home/compudj/git/linux-2.6-lttng/init/main.c:45: include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_cpu': include2/asm/dma-mapping.h:320: warning: implicit declaration of function 'dma_sync_single_for_cpu' include2/asm/dma-mapping.h: In function 'dma_sync_single_range_for_device': include2/asm/dma-mapping.h:329: warning: implicit declaration of function 'dma_sync_single_for_device' include2/asm/dma-mapping.h: At top level: include2/asm/dma-mapping.h:352: warning: conflicting types for 'dma_sync_single_for_cpu' include2/asm/dma-mapping.h:352: error: static declaration of 'dma_sync_single_for_cpu' follows non-static declaration include2/asm/dma-mapping.h:320: error: previous implicit declaration of 'dma_sync_single_for_cpu' was here include2/asm/dma-mapping.h:360: warning: conflicting types for 'dma_sync_single_for_device' include2/asm/dma-mapping.h:360: error: static declaration of 'dma_sync_single_for_device' follows non-static declaration include2/asm/dma-mapping.h:329: error: previous implicit declaration of 'dma_sync_single_for_device' was here make[2]: *** [init/main.o] Error 1 make[1]: *** [init] Error 2 make: *** [_all] Error 2 my .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:19 2007 # CONFIG_ARM=y CONFIG_SYS_SU
Build error : 2.6.21-rc6-mm1 for ppc 405
Hi Andrew, I get the following build error when building 2.6.21-rc6-mm1 for ppc 405: /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc -m32 -Wp,-MD,arch/ppc/syslib/.ppc4xx_sgdma.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/lib/gcc/powerpc-405-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -I/home/compudj/git/linux-2.6-lttng/arch/ppc/syslib -Iarch/ppc/syslib -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -I/home/compudj/git/linux-2.6-lttng/arch/ppc -Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mno-altivec -mstring -Wa,-m405 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ppc4xx_sgdma)" -D"KBUILD_MODNAME=KBUILD_STR(ppc4xx_sgdma)" -c -o arch/ppc/syslib/.tmp_ppc4xx_sgdma.o /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c: In function 'ppc4xx_alloc_dma_handle': /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c:374: warning: implicit declaration of function 'dma_alloc_coherent' /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c:374: warning: assignment makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c: In function 'ppc4xx_free_dma_handle': /home/compudj/git/linux-2.6-lttng/arch/ppc/syslib/ppc4xx_sgdma.c:454: warning: implicit declaration of function 'dma_free_coherent' /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-ld -m elf32ppc -r -o arch/ppc/syslib/built-in.o arch/ppc/syslib/ocp.o arch/ppc/syslib/ibm_ocp.o arch/ppc/syslib/ppc4xx_pic.o arch/ppc/syslib/ppc4xx_setup.o arch/ppc/syslib/ppc4xx_dma.o arch/ppc/syslib/ppc4xx_sgdma.o make -f /home/compudj/git/linux-2.6-lttng/scripts/Makefile.build obj=arch/powerpc/sysdev /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc -m32 -Wp,-MD,arch/powerpc/sysdev/.dcr.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/lib/gcc/powerpc-405-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -I/home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev -Iarch/powerpc/sysdev -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -I/home/compudj/git/linux-2.6-lttng/arch/ppc -Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mno-altivec -mstring -Wa,-m405 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(dcr)" -D"KBUILD_MODNAME=KBUILD_STR(dcr)" -c -o arch/powerpc/sysdev/.tmp_dcr.o /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:26: warning: 'struct device_node' declared inside parameter list /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:26: warning: its scope is only this definition or declaration, which is probably not what you want /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:37: warning: 'struct device_node' declared inside parameter list /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c: In function 'dcr_resource_start': /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:31: warning: 'ds' is used uninitialized in this function /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c: In function 'dcr_resource_len': /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/dcr.c:42: warning: 'ds' is used uninitialized in this function /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/bin/powerpc-405-linux-gnu-gcc -m32 -Wp,-MD,arch/powerpc/sysdev/.timer.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/powerpc-405-linux-gnu/lib/gcc/powerpc-405-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -Iarch/ppc -Iarch/ppc/include -I/home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev -Iarch/powerpc/sysdev -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -I/home/compudj/git/linux-2.6-lttng/arch/ppc -Iarch/ppc -msoft-float -pipe -ffixed-r2 -mmultiple -mno-altivec -mstring -Wa,-m405 -fomit-frame-pointer -g -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(timer)" -D"KBUILD_MODNAME=KBUILD_STR(timer)" -c -o arch/powerpc/sysdev/.tmp_timer.o /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/timer.c /home/compudj/git/linux-2.6-lttng/arch/powerpc/sysdev/timer.
Build error : 2.6.21-rc6-mm1 on sparc64
Hi Andrew, I get the following build error when building 2.6.21-rc6-mm1 for sparc64: /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/bin/sparc64-unknown-linux-gnu-gcc -Wp,-MD,arch/sparc64/kernel/.traps.o.d -nostdinc -isystem /opt/crosstool/gcc-3.4.5-glibc-2.3.6/sparc64-unknown-linux-gnu/lib/gcc/sparc64-unknown-linux-gnu/3.4.5/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel -Iarch/sparc64/kernel -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m64 -pipe -mno-fpu -mcpu=ultrasparc -mcmodel=medlow -ffixed-g4 -ffixed-g5 -fcall-used-g7 -Wno-sign-compare -Wa,--undeclared-regs -fomit-frame-pointer -Wdeclaration-after-statement -Werror -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(traps)" -D"KBUILD_MODNAME=KBUILD_STR(traps)" -c -o arch/sparc64/kernel/traps.o /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c: In function `init_cur_cpu_trap': /home/compudj/git/linux-2.6-lttng/arch/sparc64/kernel/traps.c:2497: warning: implicit declaration of function `hard_smp_processor_id' make[2]: *** [arch/sparc64/kernel/traps.o] Error 1 make[1]: *** [arch/sparc64/kernel] Error 2 make: *** [_all] Error 2 my .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:19 2007 # CONFIG_SPARC=y CONFIG_SPARC64=y CONFIG_64BIT=y CONFIG_MMU=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_TIME_INTERPOLATION=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_AUDIT_ARCH=y CONFIG_SPARC64_PAGE_SIZE_8KB=y # CONFIG_SPARC64_PAGE_SIZE_64KB is not set # CONFIG_SPARC64_PAGE_SIZE_512KB is not set # CONFIG_SPARC64_PAGE_SIZE_4MB is not set CONFIG_SECCOMP=y # CONFIG_HZ_100 is not set CONFIG_HZ_250=y # CONFIG_HZ_300 is not set # CONFIG_HZ_1000 is not set CONFIG_HZ=250 CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y # CONFIG_SWAP is not set # CONFIG_SYSVIPC is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_UTS_NS is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set # CONFIG_BLK_DEV_INITRD is not set CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_BLK_DEV_IO_TRACE is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" CONFIG_GENERIC_HARDIRQS=y # # General machine setup # # CONFIG_SMP is not set # CONFIG_CPU_FREQ is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_DEFAULT=y CONFIG_LARGE_ALLOCS=y CONFIG_SELECT_MEMORY_MODEL=y # CONFIG_FLATMEM_MANUAL is not set # CONFIG_DISCONTIGMEM_MANUAL is not set CONFIG_SPARSEMEM_MANUAL=y CONFIG_SPARSEMEM=y CONFIG_HAVE_MEMORY_PRESENT=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPARSEMEM_EXTREME=y CONFIG_SPLIT_PTLOCK_CPUS=4 CONFIG_RESOURCES_64BIT=y CONFIG_ZONE_DMA_FLAG=0 CONFIG_ADAPTIVE_READAHEAD=y CONFIG_SBUS=y CONFIG_SBUSCHAR=y CONFIG_SUN_AUXIO=y CONFIG_SUN_IO=y # CONFIG_PCI is not set # CONFIG_PCI_DOMAINS is not set # CONFIG_SUN_OPENPROMFS is not set # CONFIG_SPARC32_COMPAT is not set # # Executable file formats # # CONFIG_BINFMT_ELF is not set # CONFIG_BINFMT_MISC is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set # CONFIG_CMDLINE_BOOL is not set # # Networking # # CONFIG_NET is not set # # Device Drivers # # # Generic Driver Options # CONFIG_STANDALONE=y CONFIG_PREVENT_FI
Build error : 2.6.21-rc6-mm1 on sparc
Hi Andrew, I get the following build error on sparc : /opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/bin/sparc-unknown-linux-gnu-gcc -Wp,-MD,arch/sparc/kernel/.irq.o.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/sparc-unknown-linux-gnu/lib/gcc/sparc-unknown-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/arch/sparc/kernel -Iarch/sparc/kernel -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -m32 -pipe -mno-fpu -fcall-used-g5 -fcall-used-g7 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(irq)" -D"KBUILD_MODNAME=KBUILD_STR(irq)" -c -o arch/sparc/kernel/.tmp_irq.o /home/compudj/git/linux-2.6-lttng/arch/sparc/kernel/irq.c In file included from /home/compudj/git/linux-2.6-lttng/arch/sparc/kernel/irq.c:16: /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:64:27: error: asm/tracehook.h: No such file or directory In file included from /home/compudj/git/linux-2.6-lttng/arch/sparc/kernel/irq.c:16: /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function 'ptrace_whole_regset': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:115: warning: implicit declaration of function 'utrace_native_view' /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:116: warning: passing argument 3 of 'ptrace_regset_access' makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function 'ptrace_peekusr': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:166: warning: passing argument 3 of 'ptrace_layout_access' makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function 'ptrace_pokeusr': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:177: warning: passing argument 3 of 'ptrace_layout_access' makes pointer from integer without a cast make[2]: *** [arch/sparc/kernel/irq.o] Error 1 make[1]: *** [arch/sparc/kernel] Error 2 make: *** [_all] Error 2 my .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:18 2007 # CONFIG_MMU=y CONFIG_HIGHMEM=y CONFIG_ZONE_DMA=y CONFIG_GENERIC_ISA_DMA=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set CONFIG_MODVERSIONS=y # CONFIG_MODULE_SRCVERSION_ALL is not set CONFIG_KMOD=y # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # General machine setup # # CONFIG_SMP is not set CONFIG_SPARC=y CONFIG_SPARC32=y CONFIG_SBUS=y CONFIG_SBUSCHAR=y CONFIG_SERIAL_CONSOLE=y CONFIG_SUN_AUXIO=y CONFIG_SUN_IO=y CONFIG_RWSEM_GENERIC_SPINLOCK=y CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_SUN_PM=y # CONFIG_SUN4 is not set # CONFIG_PCI is not set CONFIG_SUN_OPENPROMFS=m # CONFIG_SPARC_LED is not set CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=m CONFIG_SUNOS_EMUL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set #
2.6.21-rc6-mm1 build error with mips
Hi Andrew, I get the following error when compiling 2.6.21-rc6-mm1 for MIPS : /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc -Wp,-MD,arch/mips/sgi-ip22/.ip22-time.o.d -nostdinc -isystem /opt/crosstool/gcc-3.4.5-glibc-2.3.6/mips-unknown-linux-gnu/lib/gcc/mips-unknown-linux-gnu/3.4.5/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22 -Iarch/mips/sgi-ip22 -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Os -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -ffreestanding -march=r5000 -Wa,--trap -I/home/compudj/git/linux-2.6-lttng/include/asm-mips/mach-ip22 -Iinclude/asm-mips/mach-ip22 -I/home/compudj/git/linux-2.6-lttng/include/asm-mips/mach-generic -Iinclude/asm-mips/mach-generic -fomit-frame-pointer -Wdeclaration-after-statement -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(ip22_time)" -D"KBUILD_MODNAME=KBUILD_STR(ip22_time)" -c -o arch/mips/sgi-ip22/ip22-time.o /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c In file included from include2/asm/time.h:21, from /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c:25: /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:64:27: asm/tracehook.h: No such file or directory In file included from include2/asm/time.h:21, from /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c:25: /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function `ptrace_whole_regset': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:115: warning: implicit declaration of function `utrace_native_view' /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:116: warning: passing arg 3 of `ptrace_regset_access' makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function `ptrace_peekusr': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:166: warning: passing arg 3 of `ptrace_layout_access' makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h: In function `ptrace_pokeusr': /home/compudj/git/linux-2.6-lttng/include/linux/ptrace.h:177: warning: passing arg 3 of `ptrace_layout_access' makes pointer from integer without a cast /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c: In function `dosample': /home/compudj/git/linux-2.6-lttng/arch/mips/sgi-ip22/ip22-time.c:118: warning: passing arg 2 of `writeb' makes pointer from integer without a cast My .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:18 2007 # CONFIG_MIPS=y # # Machine selection # CONFIG_ZONE_DMA=y # CONFIG_MIPS_MTX1 is not set # CONFIG_MIPS_BOSPORUS is not set # CONFIG_MIPS_PB1000 is not set # CONFIG_MIPS_PB1100 is not set # CONFIG_MIPS_PB1500 is not set # CONFIG_MIPS_PB1550 is not set # CONFIG_MIPS_PB1200 is not set # CONFIG_MIPS_DB1000 is not set # CONFIG_MIPS_DB1100 is not set # CONFIG_MIPS_DB1500 is not set # CONFIG_MIPS_DB1550 is not set # CONFIG_MIPS_DB1200 is not set # CONFIG_MIPS_MIRAGE is not set # CONFIG_BASLER_EXCITE is not set # CONFIG_MIPS_COBALT is not set # CONFIG_MACH_DECSTATION is not set # CONFIG_MIPS_EV64120 is not set # CONFIG_MACH_JAZZ is not set # CONFIG_LASAT is not set # CONFIG_MIPS_ATLAS is not set # CONFIG_MIPS_MALTA is not set # CONFIG_MIPS_SEAD is not set # CONFIG_WR_PPMC is not set # CONFIG_MIPS_SIM is not set # CONFIG_MOMENCO_JAGUAR_ATX is not set # CONFIG_MOMENCO_OCELOT is not set # CONFIG_MOMENCO_OCELOT_3 is not set # CONFIG_MOMENCO_OCELOT_C is not set # CONFIG_MOMENCO_OCELOT_G is not set # CONFIG_MIPS_XXS1500 is not set # CONFIG_PNX8550_JBS is not set # CONFIG_PNX8550_STB810 is not set # CONFIG_DDB5477 is not set # CONFIG_MACH_VR41XX is not set # CONFIG_PMC_YOSEMITE is not set # CONFIG_QEMU is not set # CONFIG_MARKEINS is not set CONFIG_SGI_IP22=y # CONFIG_SGI_IP27 is not set # CONFIG_SGI_IP32 is not set # CONFIG_SIBYTE_BIGSUR is not set # CONFIG_SIBYTE_SWARM is not set # CONFIG_SIBYTE_SENTOSA is not set # CONFIG_SIBYTE_RHONE is not set # CONFIG_SIBYTE_CARMEL is not set # CONFIG_SIBYTE_PTSWARM is not set # CONFIG_SIBYTE_LITTLESUR is not set # CONFIG_SIBYTE_CRHINE is not set # CONFIG_SIBYTE_CRHONE is not set # CONFIG_SNI_RM is not set # CONFIG_TOSHIBA_JMR3927 is not set # CONFIG_TOSHIBA_RBTX4927 is not set # CONFIG_TOSHIBA_RBTX4938 is not set CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_FIND_NEXT_BIT=y CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_GENERIC_TIME=y CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y # CONFIG_GENERIC_HARDIRQS_NO__DO_IRQ is not set CONFIG_ARC=y CONFIG_DMA_NONCOHERENT=y CONFIG_DMA_NEED_PCI_MAP_STATE=y CONFIG_EARLY_PRINTK=y CONFIG_SYS_HAS_EARLY_PRINTK=y CONFI
2.6.21-rc6-mm1 build fails for m68k
Hi Andrew, I get the following compiler error when building 2.6.21-rc6-mm1 for m68k: /opt/crosstool/gcc-4.1.1-glibc-2.3.6/m68k-unknown-linux-gnu/bin/m68k-unknown-linux-gnu-gcc -Wp,-MD,arch/m68k/kernel/.asm-offsets.s.d -nostdinc -isystem /opt/crosstool/gcc-4.1.1-glibc-2.3.6/m68k-unknown-linux-gnu/lib/gcc/m68k-unknown-linux-gnu/4.1.1/include -D__KERNEL__ -Iinclude -Iinclude2 -I/home/compudj/git/linux-2.6-lttng/include -include include/linux/autoconf.h -I/home/compudj/git/linux-2.6-lttng/. -I. -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -O2 -pipe -fno-strength-reduce -ffixed-a2 -m68040 -fomit-frame-pointer -fno-stack-protector -Wdeclaration-after-statement -Wno-pointer-sign -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(asm_offsets)" -D"KBUILD_MODNAME=KBUILD_STR(asm_offsets)" -fverbose-asm -S -o arch/m68k/kernel/asm-offsets.s /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c: In function 'main': /home/compudj/git/linux-2.6-lttng/arch/m68k/kernel/asm-offsets.c:27: error: 'struct task_struct' has no member named 'ptrace' make[2]: *** [arch/m68k/kernel/asm-offsets.s] Error 1 make[1]: *** [prepare0] Error 2 make: *** [_all] Error 2 My .config : # # Automatically generated make config: don't edit # Linux kernel version: 2.6.21-rc6-mm1 # Tue Apr 10 16:33:19 2007 # CONFIG_M68K=y CONFIG_MMU=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_GENERIC_CALIBRATE_DELAY=y CONFIG_TIME_LOW_RES=y CONFIG_NO_IOPORT=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # Code maturity level options # CONFIG_EXPERIMENTAL=y CONFIG_BROKEN_ON_SMP=y CONFIG_INIT_ENV_ARG_LIMIT=32 # # General setup # CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y CONFIG_SWAP_PREFETCH=y CONFIG_SYSVIPC=y # CONFIG_IPC_NS is not set CONFIG_SYSVIPC_SYSCTL=y CONFIG_POSIX_MQUEUE=y CONFIG_BSD_PROCESS_ACCT=y # CONFIG_BSD_PROCESS_ACCT_V3 is not set # CONFIG_TASKSTATS is not set # CONFIG_UTS_NS is not set # CONFIG_AUDIT is not set # CONFIG_IKCONFIG is not set CONFIG_SYSFS_DEPRECATED=y # CONFIG_RELAY is not set CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y # CONFIG_KALLSYMS_ALL is not set # CONFIG_KALLSYMS_EXTRA_PASS is not set CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_TIMERFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_PROC_SMAPS=y CONFIG_PROC_CLEAR_REFS=y CONFIG_PROC_PAGEMAP=y CONFIG_PROC_KPAGEMAP=y CONFIG_SLAB=y # CONFIG_SLUB is not set # CONFIG_SLOB is not set CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 CONFIG_PAGE_GROUP_BY_MOBILITY=y # # Loadable module support # CONFIG_MODULES=y # CONFIG_MODULE_UNLOAD is not set # CONFIG_MODVERSIONS is not set # CONFIG_MODULE_SRCVERSION_ALL is not set # CONFIG_KMOD is not set # # Process debugging support # CONFIG_UTRACE=y CONFIG_PTRACE=y # # Block layer # CONFIG_BLOCK=y # CONFIG_LBD is not set # CONFIG_BLK_DEV_IO_TRACE is not set # CONFIG_LSF is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y CONFIG_IOSCHED_AS=y CONFIG_IOSCHED_DEADLINE=y CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Platform dependent setup # # CONFIG_SUN3 is not set CONFIG_AMIGA=y # CONFIG_ATARI is not set # CONFIG_MAC is not set # CONFIG_APOLLO is not set # CONFIG_VME is not set # CONFIG_HP300 is not set # CONFIG_SUN3X is not set # CONFIG_Q40 is not set # # Processor type # # CONFIG_M68020 is not set # CONFIG_M68030 is not set CONFIG_M68040=y # CONFIG_M68060 is not set CONFIG_MMU_MOTOROLA=y # CONFIG_M68KFPU_EMU is not set CONFIG_ADVANCED=y CONFIG_RMW_INSNS=y CONFIG_SINGLE_MEMORY_CHUNK=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y # CONFIG_SPARSEMEM_STATIC is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_ADAPTIVE_READAHEAD=y # # General setup # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y CONFIG_BINFMT_MISC=y CONFIG_ZORRO=y # CONFIG_AMIGA_PCMCIA is not set CONFIG_HEARTBEAT=y CONFIG_PROC_HARDWARE=y CONFIG_ZONE_DMA=y CONFIG_ZORRO_NAMES=y # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y # CONFIG_PACKET_MMAP is not set CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set CONFIG_NET_KEY=y # CONFIG_NET_KEY_MIGRATE is not set CONFIG_INET=y # CONFIG_IP_MULTICAST is not set # CONFIG_IP_ADVAN
Re: [ofa-general] Re: [PATCH 00 of 33] Set of ipath patches for 2.6.22
> Is there any chance of getting a fix for the use-after-free that can > be caused by allocating something from userspace, failing to mmap the > buffer and then exiting? To see what happens, look at how > ipath_create_cq sticks a struct ipath_mmap_info into the pending mmap > "list" (and yes it would be much cleaner to just use struct list_head > here rather than reimplementing a linked list yourself), and then look > at how ipath_destroy_cq() frees the same structure without checking if > it has been removed from the pending mmap list. By the way, would it help get this fixed if I opened a bug on openfabrics.org? Or is that a waste of time? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC, PATCH 1/3] gpiodev - API definitions
it looks ok, but I have several questions: 1. why should we bind this to platform_device, what if the gpio device is not actually a "platform_device", say, a I2C device, a SPI device or even a USB device? 2. I still doubt the benefit of using of a structure for a gpio, isn't a gpio number not enough? 3. If one is going to use a GPIO, he has to initialize a "struct gpio" before that, how is he suppose to know the value for "gpio->gpio_dev"? 4. how can we optimize to a direct register access instruction (e.g. to GPDR in PXA) for bit-banging operation (pardon me, I don't exactly remember the name for such operation, maybe bit-banging) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: If not readdir() then what?
On Wed, 2007-04-11 at 08:33 +1000, Neil Brown wrote: > A READDIR (aka getdents2) should take a directory handle, a cookie, > and a filename, and should return filenames and cookies. The > cookies may all be identical or may not. The filename might be used > by the filesystem, or it might not. > > Filesystems that require a cursor in the 'struct file' to support > (local) getdents cannot be used with NFS. > > While it doesn't make it possible to support all conceivable > filesystems, it should make it easier for some filesystems to support > the demands of NFS. In order to be useful, I think you need to add a demand that the READDIR call cannot loop back on itself for the case of a series of sequential reads. IOW: if a client attempts to step sequentially through the directory, and is supplying valid filenames+cookies from the preceding READDIR call, then the next READDIR call should be guaranteed never to loop back to an earlier entry. Alternatively, if there is a danger that it might due to some sudden and radical change in the directory layout, then it should notify the client by returning something like a BAD_COOKIE error. Otherwise, the client would have to cache _all_ previous READDIR results since the last opendir()/rewinddir() in order to be able to do its own loop detection and that will obviously never scale for large directories or for directories that change frequently... Cheers Trond - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.21-rc6-mm1
On Tue, Apr 10, 2007 at 07:59:29PM -0400, Adam Belay wrote: > On Tue, 2007-04-10 at 15:20 -0700, Venki Pallipadi wrote: > > On Mon, Apr 09, 2007 at 07:40:52PM +0200, Rafael J. Wysocki wrote: > > > On Monday, 9 April 2007 18:14, Pallipadi, Venkatesh wrote: > > > > > > > > >-Original Message- > > > > >From: Rafael J. Wysocki [mailto:[EMAIL PROTECTED] > > > > >Sent: Monday, April 09, 2007 9:08 AM > > > > >To: Andrew Morton > > > > >Cc: linux-kernel@vger.kernel.org; [EMAIL PROTECTED]; > > > > >[EMAIL PROTECTED]; Pallipadi, Venkatesh > > > > >Subject: Re: 2.6.21-rc6-mm1 > > > > > > > > > >On Sunday, 8 April 2007 23:35, Andrew Morton wrote: > > > > >> > > > > >> > > > > >ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2 > > > > >.6.21-rc6/2.6.21-rc6-mm1/ > > > > >> > > > > >> > > > > >> - Lots of x86 updates > > > > >> > > > > >> - This is a 25MB diff against mainline, which is rather large. > > > > > > > > > >The cpuidle thing tends to hang my x86-64 machines on boot. > > > > > > > > > > > > > Hi Rafael, > > > > > > > > At what point during boot does it hang? > > > > > > When mounting the root filesystem. It hangs completely, even the magic > > > SysRq > > > doesn't work > > > > > > > Rafael: Below patch should fix the hang. > > Len: Please include this patch in acpi-test. > > > > Thanks, > > Venki > > > > Prevent hang on x86-64, when ACPI processor driver is added as a module on > > a system that does not support C-states. > > > > x86-64 expects all idle handlers to enable interrupts before returning from > > idle handler. This is due to enter_idle(), exit_idle() races. Make > > cpuidle_idle_call() confirm to this when there is no pm_idle_old. > > > > Also, cpuidle look at the return values of attch_driver() and set > > current_driver to NULL if attach fails on all CPUs. > > My vote would be to instead remove enter_idle() and exit_idle() from > x86-64, just as was done with i386. Performance monitoring > infrastructure shouldn't be interfering with the idle interrupt > delivery, as that could only hurt performance... Besides, there's > probably a better way of doing this than an idle notifier anyway. > Agreed. I did not like local_irq_enable() in cpuidle either, but added it anyway as it was a corner case when cpuidle is active and no driver is active and not a common case. I thought we will have it as a bandaid solution until enter_idle, exit_idle is around. Andi/Stephane: What are the plans around enter_idle exit_idle in x86-64. Is it still being used by perfmon for x86-64 arch? Thanks, Venki - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [patch 2.6.21-rc5-git] make /proc/acpi/wakeup more useful
On Tuesday 10 April 2007 4:29 pm, David Brownell wrote: > ... the appended > patch goes on top of the previous pnpacpi patch, and should (nyet tested!) > fix another place I saw that warning. And here's a tested version. Curiouser and curiouser. I think the mapping of ACPI tables to sysfs nodes still needs a bunch of work... - Dave == CUT HERE Handle PNP devices that have the same IDs a bit more sanely ... this at least arranges multiple one-to-one mappings between PNP nodes and ACPI nodes that all share the same PNP0c02 id. (Maybe mapped to the wrong node though...) This remains a hack, since it masks failures where PNP0a03 (a PCI root bridge) is handled by ACPI special case code (/sys/devices/pci:00 on my systems instead of /sys/devices/pnp0/pnp00:0/pci:00!) not pure PNPACPI logic. I suspect that pnp_dev.number and some acpi_device field need to be compared, (so the right PNP0c02 nodes hook up to each other, PNP0a03 likewise) but I'll leave that to someone who knows how those ACPI table lookups "should" work. Signed-off-by: David Brownell <[EMAIL PROTECTED]> --- g26.orig/drivers/pnp/pnpacpi/core.c 2007-04-10 01:38:53.0 -0700 +++ g26/drivers/pnp/pnpacpi/core.c 2007-04-10 16:35:13.0 -0700 @@ -243,6 +243,7 @@ static int __init acpi_pnp_match(struct /* true means it matched */ return acpi->flags.hardware_id + && !acpi_get_physical_device(acpi->handle) && compare_pnp_id(pnp->id, acpi->pnp.hardware_id); } - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
