Re: 2.6.12-rc2-mm3

2005-04-12 Thread Nick Piggin
Andrew Morton wrote:
So it turns out that patch was broken.  I've fixed it locally and the
results are good, but odd.
The machine is a 4GB x86_64 with aic79xx controllers and MAXTOR
ATLAS10K4_73WLS disks.  ext2 filesystem.
The workload is continuous pagecache writeback versus
read-lots-of-little-files:
while true
do
dd if=/dev/zero of=/mnt/sdb2/x bs=40M count=100 conv=notrunc
done
versus
find /mnt/sdb2/linux-2.4.25 -type f | xargs cat  /dev/null
we measure how long the find+cat takes.
2.6.12-rc2, as, tcq depth=2:7.241 seconds
2.6.12-rc2, as, tcq depth=64:   12.172 seconds
2.6.12-rc2+patch,as,tcq depth=64:   7.199 seconds
2.6.12-rc2, cfq2,   tcq depth=64:   much more than 5 minutes
2.6.12-rc2, cfq3,   tcq depth=64:   much more than 5 minutes
So
- The effects of tcq on AS are much less disastrous than I thought they
 were.  Do I have the wrong workload?  Memory fails me.  Or did we fix the
 anticipatory scheduler?

Yes, we did fix it ;)
Quite a long time ago, so maybe you are thinking of something else
(I haven't been able to work it out).
AS basically does its own TCQ strangulation, which IIRC involves things
like completing all reads before issuing new writes, and completing all
reads from one process before reads from another. As well as the
fundamental way that waiting for a 'dependant read' throttles TCQ.
- as-limit-queue-depth.patch fixes things right up anyway.  Seems to be
 doing the right thing.  


Well it depends on what we want to do. If we hard limit the AS queue
like this, I can remove some of that TCQ throttling logic from AS.
OTOH, the throttling was intended to allow us to sanely use a large
TCQ depth without getting really bad behaviour. Theoretically a process
can make use of TCQ if it is doing a lot of writing, or if it is not
determined to be doing dependant reads.

-
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] git: combo-blobs

2005-04-12 Thread Barry K. Nathan
On Mon, Apr 11, 2005 at 06:33:58PM +0200, Ingo Molnar wrote:
 ok. Meanwhile i found another counter-argument: the average committed 
 file size is 36K, which with gzip -9 would compress down to roughly 8K, 
 with the commit message being another block. That's 2+1 blocks used per 
 commit, while with deltas one could at most cut this down to 1+1+1 
 blocks - just as much space! So we would be almost even with the more 
 complex delta approach, just by increasing the default compression ratio 
 from 6 to 9. (but even with the default we are not that bad.)

I think you forgot about reiserfs/reiser4 tails. (At least, I *think*
reiser4 has tails. I know reiserfs 3.x does.)

BTW, I happen to agree completely with Linus on this issue, but I still
figured I'd mention this for the sake of completeness.

-Barry K. Nathan [EMAIL PROTECTED]
-
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] x86, x86_64: dual core proc-cpuinfo and sibling-map fix

2005-04-12 Thread Siddha, Suresh B
Appended patch fixes

- broken sibling_map setup in x86_64

- grouping all the core and HT related cpuinfo fields.
  We are reasonably sure that adding new cpuinfo fields after siblings field,
  will not cause any app failure. Thats because today's /proc/cpuinfo
  format is completely different on x86, x86_64 and we haven't heard of any
  x86 app breakage because of this issue. Grouping these fields will 
  result in more or less common format on all architectures (ia64, x86 and 
  x86_64) and will cause less confusion.

Signed-off-by: Suresh Siddha [EMAIL PROTECTED]

diff -Nru linux-2.6.12-rc2-mm3/arch/i386/kernel/cpu/proc.c 
linux-mc/arch/i386/kernel/cpu/proc.c
--- linux-2.6.12-rc2-mm3/arch/i386/kernel/cpu/proc.c2005-04-11 
17:12:16.939435632 -0700
+++ linux-mc/arch/i386/kernel/cpu/proc.c2005-04-11 17:13:31.757061624 
-0700
@@ -98,6 +98,8 @@
seq_printf(m, physical id\t: %d\n, phys_proc_id[n]);
seq_printf(m, siblings\t: %d\n,
c-x86_num_cores * smp_num_siblings);
+   seq_printf(m, core id\t\t: %d\n, cpu_core_id[n]);
+   seq_printf(m, cpu cores\t: %d\n, c-x86_num_cores);
}
 #endif

@@ -130,13 +132,6 @@
 c-loops_per_jiffy/(50/HZ),
 (c-loops_per_jiffy/(5000/HZ)) % 100);
 
-#ifdef CONFIG_SMP
-   /* Put new fields at the end to lower the probability of
-  breaking user space parsers. */
-   seq_printf(m, core id\t\t: %d\n, cpu_core_id[n]);
-   seq_printf(m, cpu cores\t: %d\n, c-x86_num_cores);
-#endif
-
return 0;
 }
 
diff -Nru linux-2.6.12-rc2-mm3/arch/x86_64/kernel/setup.c 
linux-mc/arch/x86_64/kernel/setup.c
--- linux-2.6.12-rc2-mm3/arch/x86_64/kernel/setup.c 2005-04-11 
17:12:17.074415112 -0700
+++ linux-mc/arch/x86_64/kernel/setup.c 2005-04-11 17:14:34.250561168 -0700
@@ -1179,6 +1179,8 @@
seq_printf(m, physical id\t: %d\n, phys_proc_id[cpu]);
seq_printf(m, siblings\t: %d\n,
c-x86_num_cores * smp_num_siblings);
+   seq_printf(m, core id\t\t: %d\n, cpu_core_id[cpu]);
+   seq_printf(m, cpu cores\t: %d\n, c-x86_num_cores);
}
 #endif 
 
@@ -1222,15 +1224,8 @@
}
}
 
-   seq_printf(m, \n);
+   seq_printf(m, \n\n);
 
-#ifdef CONFIG_SMP
-   /* Put new fields at the end to lower the probability of
-  breaking user space parsers. */
-   seq_printf(m, core id\t\t: %d\n, cpu_core_id[c - cpu_data]);
-   seq_printf(m, cpu cores\t: %d\n, c-x86_num_cores);
-#endif
-   seq_printf(m, \n);
return 0;
 }
 
diff -Nru linux-2.6.12-rc2-mm3/arch/x86_64/kernel/smpboot.c 
linux-mc/arch/x86_64/kernel/smpboot.c
--- linux-2.6.12-rc2-mm3/arch/x86_64/kernel/smpboot.c   2005-04-11 
17:12:17.076414808 -0700
+++ linux-mc/arch/x86_64/kernel/smpboot.c   2005-04-11 17:41:52.704478312 
-0700
@@ -652,7 +652,7 @@
int i;
if (smp_num_siblings  1) {
for_each_online_cpu (i) {
-   if (cpu_core_id[cpu] == phys_proc_id[i]) {
+   if (cpu_core_id[cpu] == cpu_core_id[i]) {
siblings++;
cpu_set(i, cpu_sibling_map[cpu]);
}
-
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 patch] drivers/block/ll_rw_blk.c: possible cleanups

2005-04-12 Thread Jens Axboe
On Tue, Apr 12 2005, Adrian Bunk wrote:
 On Mon, Apr 11, 2005 at 08:12:34AM +0200, Jens Axboe wrote:
  On Sun, Apr 10 2005, Adrian Bunk wrote:
   This patch contains the following possible cleanups:
   - make needlessly global code static
   - remove the following unused global functions:
 - blkdev_scsi_issue_flush_fn
  
  Kill the function completely, it is not used anymore.
  
 - __blk_attempt_remerge
  
  Normally I would say leave that since it's part of the API, but lets
  just kill it. I don't envision any further users of the remerging
  attempts.
  
   - remove the following unused EXPORT_SYMBOL's:
 - blk_phys_contig_segment
 - blk_hw_contig_segment
 - blkdev_scsi_issue_flush_fn
 - __blk_attempt_remerge
   
   Please review which of these changes make sense.
  
  Looks fine to me, thanks. Can you send a new patch that kills
  blkdev_scsi_issue_flush_fn()?
 
 I have a problem parsing your email.
 
 Which parts of my patch are OK and which shouldn't be applied?
 Or why do you want a separate blkdev_scsi_issue_flush_fn patch?

I have no problems with your patch, I would just like a revised patch
that removes blkdev_scsi_issue_flush_fn completely instead since it is
totally unused. It doesn't make sense to remove the export and make it
static, since it isn't used internally (and never meant to, it's a
helper function for drivers).

-- 
Jens Axboe

-
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 2/6]sibling map initializing rework

2005-04-12 Thread Li Shaohua
Make sibling map init per-cpu. Hotplug CPU may change the map at
runtime.

Signed-off-by: Li Shaohua[EMAIL PROTECTED]

---

 linux-2.6.11-root/arch/i386/kernel/smpboot.c |   86 ++-
 1 files changed, 45 insertions(+), 41 deletions(-)

diff -puN arch/i386/kernel/smpboot.c~sibling_map_init_cleanup 
arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~sibling_map_init_cleanup
2005-04-12 10:36:34.283984464 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-12 
10:36:34.287983856 +0800
@@ -63,11 +63,16 @@ static int __initdata smp_b_stepping;
 
 /* Number of siblings per CPU package */
 int smp_num_siblings = 1;
-int phys_proc_id[NR_CPUS]; /* Package ID of each logical CPU */
+/* Package ID of each logical CPU */
+int phys_proc_id[NR_CPUS] = {[0 ... NR_CPUS-1] = BAD_APICID};
 EXPORT_SYMBOL(phys_proc_id);
-int cpu_core_id[NR_CPUS]; /* Core ID of each logical CPU */
+/* Core ID of each logical CPU */
+int cpu_core_id[NR_CPUS] = {[0 ... NR_CPUS-1] = BAD_APICID};
 EXPORT_SYMBOL(cpu_core_id);
 
+cpumask_t cpu_sibling_map[NR_CPUS] __cacheline_aligned;
+cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
+
 /* bitmap of online cpus */
 cpumask_t cpu_online_map __cacheline_aligned;
 
@@ -417,6 +422,38 @@ static void __init smp_callin(void)
 
 static int cpucount;
 
+static inline void
+set_cpu_sibling_map(int cpu)
+{
+   int i;
+
+   if (smp_num_siblings  1) {
+   for (i = 0; i  NR_CPUS; i++) {
+   if (!cpu_isset(i, cpu_callout_map))
+   continue;
+   if (cpu_core_id[cpu] == cpu_core_id[i]) {
+   cpu_set(i, cpu_sibling_map[cpu]);
+   cpu_set(cpu, cpu_sibling_map[i]);
+   }
+   }
+   } else {
+   cpu_set(cpu, cpu_sibling_map[cpu]);
+   }
+
+   if (current_cpu_data.x86_num_cores  1) {
+   for (i = 0; i  NR_CPUS; i++) {
+   if (!cpu_isset(i, cpu_callout_map))
+   continue;
+   if (phys_proc_id[cpu] == phys_proc_id[i]) {
+   cpu_set(i, cpu_core_map[cpu]);
+   cpu_set(cpu, cpu_core_map[i]);
+   }
+   }
+   } else {
+   cpu_core_map[cpu] = cpu_sibling_map[cpu];
+   }
+}
+
 /*
  * Activate a secondary processor.
  */
@@ -444,6 +481,10 @@ static void __init start_secondary(void 
 */
local_flush_tlb();
 
+   /* This must be done before setting cpu_online_map */
+   set_cpu_sibling_map(_smp_processor_id());
+   wmb();
+
/* Note: this must be done before __cpu_up finish */
enable_sep_cpu();
cpu_set(smp_processor_id(), cpu_online_map);
@@ -896,8 +937,6 @@ static int boot_cpu_logical_apicid;
 /* Where the IO area was mapped on multiquad, always 0 otherwise */
 void *xquad_portio;
 
-cpumask_t cpu_sibling_map[NR_CPUS] __cacheline_aligned;
-cpumask_t cpu_core_map[NR_CPUS] __cacheline_aligned;
 
 static void __init smp_boot_cpus(unsigned int max_cpus)
 {
@@ -1064,43 +1103,8 @@ static void __init smp_boot_cpus(unsigne
cpus_clear(cpu_sibling_map[cpu]);
cpus_clear(cpu_core_map[cpu]);
}
-
-   for (cpu = 0; cpu  NR_CPUS; cpu++) {
-   struct cpuinfo_x86 *c = cpu_data + cpu;
-   int siblings = 0;
-   int i;
-   if (!cpu_isset(cpu, cpu_callout_map))
-   continue;
-
-   if (smp_num_siblings  1) {
-   for (i = 0; i  NR_CPUS; i++) {
-   if (!cpu_isset(i, cpu_callout_map))
-   continue;
-   if (cpu_core_id[cpu] == cpu_core_id[i]) {
-   siblings++;
-   cpu_set(i, cpu_sibling_map[cpu]);
-   }
-   }
-   } else {
-   siblings++;
-   cpu_set(cpu, cpu_sibling_map[cpu]);
-   }
-
-   if (siblings != smp_num_siblings)
-   printk(KERN_WARNING WARNING: %d siblings found for 
CPU%d, should be %d\n, siblings, cpu, smp_num_siblings);
-
-   if (c-x86_num_cores  1) {
-   for (i = 0; i  NR_CPUS; i++) {
-   if (!cpu_isset(i, cpu_callout_map))
-   continue;
-   if (phys_proc_id[cpu] == phys_proc_id[i]) {
-   cpu_set(i, cpu_core_map[cpu]);
-   }
-   }
-   } else {
-   cpu_core_map[cpu] = cpu_sibling_map[cpu];
-   }
-   }
+   cpu_set(0, cpu_sibling_map[0]);
+   

[PATCH 1/6]sep initializing rework

2005-04-12 Thread Li Shaohua
Hi,
These patches (together with 5 patches followed this one) are updated
suspend/resume SMP patches. The patches fixed some bugs and do clean up
as suggested. Now they work for both suspend-to-ram and suspend-to-disk.
Patches are against 2.6.12-rc2-mm3.

Thanks,
Shaohua

---
Make SEP init per-cpu, so it is hotplug safed.

Signed-off-by: Li Shaohua[EMAIL PROTECTED]

---

 linux-2.6.11-root/arch/i386/kernel/smpboot.c   |6 ++
 linux-2.6.11-root/arch/i386/kernel/sysenter.c  |   12 +++-
 linux-2.6.11-root/arch/i386/mach-voyager/voyager_smp.c |4 
 linux-2.6.11-root/arch/i386/power/cpu.c|4 +---
 linux-2.6.11-root/include/asm-i386/smp.h   |3 +++
 5 files changed, 21 insertions(+), 8 deletions(-)

diff -puN arch/i386/kernel/smpboot.c~sep_init_cleanup arch/i386/kernel/smpboot.c
--- linux-2.6.11/arch/i386/kernel/smpboot.c~sep_init_cleanup2005-04-12 
10:36:00.164171464 +0800
+++ linux-2.6.11-root/arch/i386/kernel/smpboot.c2005-04-12 
10:36:00.174169944 +0800
@@ -443,6 +443,9 @@ static void __init start_secondary(void 
 * the local TLBs too.
 */
local_flush_tlb();
+
+   /* Note: this must be done before __cpu_up finish */
+   enable_sep_cpu();
cpu_set(smp_processor_id(), cpu_online_map);
 
/* We can take interrupts now: we're officially up. */
@@ -920,6 +923,9 @@ static void __init smp_boot_cpus(unsigne
cpus_clear(cpu_core_map[0]);
cpu_set(0, cpu_core_map[0]);
 
+   sysenter_setup();
+   enable_sep_cpu();
+
/*
 * If we couldn't find an SMP configuration at boot time,
 * get out of here now!
diff -puN arch/i386/kernel/sysenter.c~sep_init_cleanup 
arch/i386/kernel/sysenter.c
--- linux-2.6.11/arch/i386/kernel/sysenter.c~sep_init_cleanup   2005-04-12 
10:36:00.165171312 +0800
+++ linux-2.6.11-root/arch/i386/kernel/sysenter.c   2005-04-12 
10:36:00.174169944 +0800
@@ -21,11 +21,16 @@
 
 extern asmlinkage void sysenter_entry(void);
 
-void enable_sep_cpu(void *info)
+void enable_sep_cpu(void)
 {
int cpu = get_cpu();
struct tss_struct *tss = per_cpu(init_tss, cpu);
 
+   if (!boot_cpu_has(X86_FEATURE_SEP)) {
+   put_cpu();
+   return;
+   }
+
tss-ss1 = __KERNEL_CS;
tss-esp1 = sizeof(struct tss_struct) + (unsigned long) tss;
wrmsr(MSR_IA32_SYSENTER_CS, __KERNEL_CS, 0);
@@ -41,7 +46,7 @@ void enable_sep_cpu(void *info)
 extern const char vsyscall_int80_start, vsyscall_int80_end;
 extern const char vsyscall_sysenter_start, vsyscall_sysenter_end;
 
-static int __init sysenter_setup(void)
+int __init sysenter_setup(void)
 {
void *page = (void *)get_zeroed_page(GFP_ATOMIC);
 
@@ -58,8 +63,5 @@ static int __init sysenter_setup(void)
   vsyscall_sysenter_start,
   vsyscall_sysenter_end - vsyscall_sysenter_start);
 
-   on_each_cpu(enable_sep_cpu, NULL, 1, 1);
return 0;
 }
-
-__initcall(sysenter_setup);
diff -puN arch/i386/mach-voyager/voyager_smp.c~sep_init_cleanup 
arch/i386/mach-voyager/voyager_smp.c
--- linux-2.6.11/arch/i386/mach-voyager/voyager_smp.c~sep_init_cleanup  
2005-04-12 10:36:00.167171008 +0800
+++ linux-2.6.11-root/arch/i386/mach-voyager/voyager_smp.c  2005-04-12 
10:36:00.175169792 +0800
@@ -499,6 +499,7 @@ start_secondary(void *unused)
while (!cpu_isset(cpuid, smp_commenced_mask))
rep_nop();
local_irq_enable();
+   enable_sep_cpu();
 
local_flush_tlb();
 
@@ -696,6 +697,9 @@ smp_boot_cpus(void)
printk(CPU%d: , boot_cpu_id);
print_cpu_info(cpu_data[boot_cpu_id]);
 
+   sysenter_setup();
+   enable_sep_cpu();
+
if(is_cpu_quad()) {
/* booting on a Quad CPU */
printk(VOYAGER SMP: Boot CPU is Quad\n);
diff -puN arch/i386/power/cpu.c~sep_init_cleanup arch/i386/power/cpu.c
--- linux-2.6.11/arch/i386/power/cpu.c~sep_init_cleanup 2005-04-12 
10:36:00.168170856 +0800
+++ linux-2.6.11-root/arch/i386/power/cpu.c 2005-04-12 10:36:00.175169792 
+0800
@@ -33,8 +33,6 @@ unsigned long saved_context_esp, saved_c
 unsigned long saved_context_esi, saved_context_edi;
 unsigned long saved_context_eflags;
 
-extern void enable_sep_cpu(void *);
-
 void __save_processor_state(struct saved_context *ctxt)
 {
kernel_fpu_begin();
@@ -136,7 +134,7 @@ void __restore_processor_state(struct sa
 * sysenter MSRs
 */
if (boot_cpu_has(X86_FEATURE_SEP))
-   enable_sep_cpu(NULL);
+   enable_sep_cpu();
 
fix_processor_context();
do_fpu_end();
diff -puN include/asm-i386/smp.h~sep_init_cleanup include/asm-i386/smp.h
--- linux-2.6.11/include/asm-i386/smp.h~sep_init_cleanup2005-04-12 
10:36:00.170170552 +0800
+++ linux-2.6.11-root/include/asm-i386/smp.h2005-04-12 10:36:00.176169640 
+0800
@@ -37,6 +37,9 @@ extern int smp_num_siblings;
 extern cpumask_t 

Re: more git updates..

2005-04-12 Thread Paul Jackson
David wrote:
 and version control your entire system

Yeah - that works.  That's how I back up my system.  Not
git actually, but a similar sort of store (no compression,
a line oriented ascii 'index' file).

See my post on Kernel SCM saga.., Sat, 9 Apr 2005 08:15:53 -0700,
Message-Id: [EMAIL PROTECTED]

-- 
  I won't rest till it's the best ...
  Programmer, Linux Scalability
  Paul Jackson [EMAIL PROTECTED] 1.650.933.1373, 
1.925.600.0401
-
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] Simple privacy enhancement for /proc/pid

2005-04-12 Thread Albert Cahalan
On Sun, 2005-04-10 at 17:38 +0200, Rene Scharfe wrote:

 Albert, allowing access based on tty sounds nice, but it _is_ expansive.
 More importantly, perhaps, it would virtualize /proc: every user would
 see different permissions for certain files in there.  That's too comlex
 for my taste.

If you really can't allow access based on tty, then at least allow
access if any UID value matches any UID value. Without this, a user
can not always see a setuid program they are running.

 First, configuring via kernel parameters is sufficient.  It simplifies
 implementation a lot because we know the settings cannot change.  And we
 don't need the added flexibility of sysctls anyway -- I assume these
 parameters are set at installation time and never touched again.

This means mucking with boot parameters, which can be a pain.
The various boot loaders do not all use the same config file.

 Then I suppose we don't need to be able to fine-tune the permissions for
 each file in /proc/pid/.  All that we need is a distinction between
 normal users (which are to be restricted) and admins (which need to
 see everything).

The /proc/*/maps file sure is different from the /proc/*/status file.
The same for all the others, really.

 This patch introduces two kernel parameters: proc.privacy and proc.gid.
 The group ID attribute of all files below /proc/pid is set to
 proc.gid, but only if you activate the feature by setting proc.privacy
 to a non-zero value.

This is very bad. Please do not change the GID as seen by
the stat() call. This value is used.


-
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/6]init call cleanup

2005-04-12 Thread Li Shaohua

Trival patch for CPU hotplug. In CPU identify  part, only did cleaup for
intel CPUs. Need do for other CPUs if they support S3 SMP.

Signed-off-by: Li Shaohua[EMAIL PROTECTED]
---

 linux-2.6.11-root/arch/i386/kernel/apic.c|   14 +++
 linux-2.6.11-root/arch/i386/kernel/cpu/common.c  |   30 +++
 linux-2.6.11-root/arch/i386/kernel/cpu/intel.c   |   12 +++---
 linux-2.6.11-root/arch/i386/kernel/cpu/intel_cacheinfo.c |4 +-
 linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/mce.c  |4 +-
 linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p4.c   |4 +-
 linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p5.c   |2 -
 linux-2.6.11-root/arch/i386/kernel/cpu/mcheck/p6.c   |2 -
 linux-2.6.11-root/arch/i386/kernel/process.c |2 -
 linux-2.6.11-root/arch/i386/kernel/setup.c   |2 -
 linux-2.6.11-root/arch/i386/kernel/smpboot.c |   18 -
 linux-2.6.11-root/arch/i386/kernel/timers/timer_tsc.c|2 -
 12 files changed, 48 insertions(+), 48 deletions(-)

diff -puN arch/i386/kernel/apic.c~init_call_cleanup arch/i386/kernel/apic.c
--- linux-2.6.11/arch/i386/kernel/apic.c~init_call_cleanup  2005-04-12 
10:37:07.216977888 +0800
+++ linux-2.6.11-root/arch/i386/kernel/apic.c   2005-04-12 10:37:07.243973784 
+0800
@@ -405,7 +405,7 @@ void __init init_bsp_APIC(void)
apic_write_around(APIC_LVT1, value);
 }
 
-void __init setup_local_APIC (void)
+void __devinit setup_local_APIC (void)
 {
unsigned long oldvalue, value, ver, maxlvt;
 
@@ -676,7 +676,7 @@ static struct sys_device device_lapic = 
.cls= lapic_sysclass,
 };
 
-static void __init apic_pm_activate(void)
+static void __devinit apic_pm_activate(void)
 {
apic_pm_state.active = 1;
 }
@@ -877,7 +877,7 @@ fake_ioapic_page:
  * but we do not accept timer interrupts yet. We only allow the BP
  * to calibrate.
  */
-static unsigned int __init get_8254_timer_count(void)
+static unsigned int __devinit get_8254_timer_count(void)
 {
extern spinlock_t i8253_lock;
unsigned long flags;
@@ -896,7 +896,7 @@ static unsigned int __init get_8254_time
 }
 
 /* next tick in 8254 can be caught by catching timer wraparound */
-static void __init wait_8254_wraparound(void)
+static void __devinit wait_8254_wraparound(void)
 {
unsigned int curr_count, prev_count;
 
@@ -916,7 +916,7 @@ static void __init wait_8254_wraparound(
  * Default initialization for 8254 timers. If we use other timers like HPET,
  * we override this later
  */
-void (*wait_timer_tick)(void) __initdata = wait_8254_wraparound;
+void (*wait_timer_tick)(void) __devinitdata = wait_8254_wraparound;
 
 /*
  * This function sets up the local APIC timer, with a timeout of
@@ -952,7 +952,7 @@ static void __setup_APIC_LVTT(unsigned i
apic_write_around(APIC_TMICT, clocks/APIC_DIVISOR);
 }
 
-static void __init setup_APIC_timer(unsigned int clocks)
+static void __devinit setup_APIC_timer(unsigned int clocks)
 {
unsigned long flags;
 
@@ -1065,7 +1065,7 @@ void __init setup_boot_APIC_clock(void)
local_irq_enable();
 }
 
-void __init setup_secondary_APIC_clock(void)
+void __devinit setup_secondary_APIC_clock(void)
 {
setup_APIC_timer(calibration_result);
 }
diff -puN arch/i386/kernel/cpu/common.c~init_call_cleanup 
arch/i386/kernel/cpu/common.c
--- linux-2.6.11/arch/i386/kernel/cpu/common.c~init_call_cleanup
2005-04-12 10:37:07.218977584 +0800
+++ linux-2.6.11-root/arch/i386/kernel/cpu/common.c 2005-04-12 
10:37:07.244973632 +0800
@@ -24,9 +24,9 @@ EXPORT_PER_CPU_SYMBOL(cpu_gdt_table);
 DEFINE_PER_CPU(unsigned char, cpu_16bit_stack[CPU_16BIT_STACK_SIZE]);
 EXPORT_PER_CPU_SYMBOL(cpu_16bit_stack);
 
-static int cachesize_override __initdata = -1;
-static int disable_x86_fxsr __initdata = 0;
-static int disable_x86_serial_nr __initdata = 1;
+static int cachesize_override __devinitdata = -1;
+static int disable_x86_fxsr __devinitdata = 0;
+static int disable_x86_serial_nr __devinitdata = 1;
 
 struct cpu_dev * cpu_devs[X86_VENDOR_NUM] = {};
 
@@ -59,7 +59,7 @@ static int __init cachesize_setup(char *
 }
 __setup(cachesize=, cachesize_setup);
 
-int __init get_model_name(struct cpuinfo_x86 *c)
+int __devinit get_model_name(struct cpuinfo_x86 *c)
 {
unsigned int *v;
char *p, *q;
@@ -89,7 +89,7 @@ int __init get_model_name(struct cpuinfo
 }
 
 
-void __init display_cacheinfo(struct cpuinfo_x86 *c)
+void __devinit display_cacheinfo(struct cpuinfo_x86 *c)
 {
unsigned int n, dummy, ecx, edx, l2size;
 
@@ -130,7 +130,7 @@ void __init display_cacheinfo(struct cpu
 /* in particular, if CPUID levels 0x8002..4 are supported, this isn't used 
*/
 
 /* Look up CPU names by table lookup. */
-static char __init *table_lookup_model(struct cpuinfo_x86 *c)
+static char __devinit *table_lookup_model(struct cpuinfo_x86 *c)
 {
struct cpu_model_info *info;
 
@@ -151,7 +151,7 @@ static char __init 

Re: [RFC] FUSE permission modell (Was: fuse review bits)

2005-04-12 Thread Miklos Szeredi
 I think that would be _much_ nicer implemented as a mount which is
 invisible to other users, rather than one which causes the admin's
 scripts to spew error messages.

Spew is a strong word.  It'll get a single EACCES at the mountpoint.
The same is true for directories not accessible by 'nobody' under an
NFS mount exported with root squash.  

 Is the namespace mechanism at all suitable for that?

It is certainly the right tool for this.  However currently private
namespaces are quite limited.  The only sane usage I can think of is
that before mounting the user starts a shell with CLONE_NS, and does
the mount in this.  However all the other programs he already has
running (editor, browser, desktop environment) won't be able to access
the mount.

Shared subtrees and more support in userspace tools is needed before
private namespaces can become really useful.

 It would also be nice to generalise and have virtual filesystems which
 are able to present different views to different users.  Can FUSE do
 that already - is the userspace part told which user is doing each
 operation?

Yes.

 With that, the desire for virtual filesystems which cannot be read
 by your sysadmin (by accident) is easy to satisfy - and that kind of
 mechanism would probably be acceptable to all.

The problem is that this way the responsibility goes to the userspace
program, which can't be trusted.

Either the kernel has to enforce that uid/gid on each file are set to
the mount owner, or the kernel has to enforce that no other user has
access to the mountpoint.  Some policy _must_ be kept in kernel.

I think both these policies have valid uses, so I wouldn't want to
limit FUSE to a single one.  Hmm?

Thanks,
Miklos
-
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.12-rc2-mm3

2005-04-12 Thread Stas Sergeev
Hello.
Andrew Morton wrote:
Program received signal SIGTRAP, Trace/breakpoint trap.
SIGTRAP - it looks like the int $3
triggered, not mov0x30(%esp),%eax,
which is just the next insn and so the
%eip points to it, but it might be
innocent. And besides, 0x30(%esp) is
EFLAGS, not OLDSS. So I think maybe my
patch is not guilty this time, it is
just the non-zero preempt count on the
return path caused by something else.
(gdb) p $eip
$1 = (void *) 0xc0102ee7
Could you please also do
p $esp or info reg, so that we can
see the rest of the registers?
And as we see, we're at the mov0x30(%esp),%eax which accesses above the 
bottom of the stack.
But that's strange. Another instance of
the 0x30(%esp) is there a few instructions
above this one, see it with disas restore_all.
It is much more likely that the real offender
is the previous instruction. $eip points on
the instruction *after* the trap, which might
be innocent.
After applying nmi_stack_correct-fix.patch, rc2-mm3
I can't find this one in an -mm broken-outs.
Where is this patch?
Could you please also test this one:
http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
Interesting.  It could be an interaction between the kgdb patch and the new
vm86 checking code.
I think so too, will have a look if I can
reproduce it.
The above code is accessing esp+56,
Yes, but this particular instruction was
not reached. int $3 killed the system
for some reasons.
-   p-thread.esp0 = (unsigned long) (childregs+1) - 8;
+   p-thread.esp0 = (unsigned long) (childregs+1) - 15;
15 is somewhat nasty - it will make the
stack unaligned, should better be 16 I
think. But I don't see why, the only
scenario we've seen were the not stored
SS/ESP, which is 8 bytes only.
If we definitely think my patch is guilty
again, then probably something like this
is necessary:
--- linux/include/asm-i386/processor.h.old  2005-03-20 14:13:02.0 
+0300
+++ linux/include/asm-i386/processor.h  2005-04-12 07:50:11.0 +0400
@@ -458,7 +458,7 @@
 * be within the limit.
 */
#define INIT_TSS  {\
-   .esp0   = sizeof(init_stack) + (long)init_stack,   \
+   .esp0   = sizeof(init_stack) - 8 + (long)init_stack,   \
   .ss0= __KERNEL_DS,  \
   .ss1= __KERNEL_CS,  \
   .ldt= GDT_ENTRY_LDT,\
But I don't think the init_stack can be
abused on the sysenter path, so this is
just a wild guess.
-
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: more git updates..

2005-04-12 Thread David Eger
So with git, *every* changeset is an entire (compressed) copy of the
kernel.  Really?  Every patch you accept adds 37 MB to your hard disk?

Am I missing something here?

-dte
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-12 Thread Sven Luther
On Tue, Apr 12, 2005 at 02:40:48AM +0200, Marco Colombo wrote:
 Which reminds me. The only reason why this thread belongs here, IMHO,
 it's because when it comes to GPL, it really doesn't matter what
 FSF's interpretation is, or anyone else's. The authors are choosing
 GPL as a license, so _thier_ interpretation is what really matters.

The main problem is that i feel that those binary firmware copyright holders
may have put it under the GPL, but i doubt they realize that this means they
have to release the source code of said firmware blobs.

Also, i believe you are wrong in the above, the only interpretation that is
important is the one the judge will take in case someone goes to suing.

And finally, if anyone could claim that a binary is the prefered form of
modification, which is most of the time obviously false, then the GPL would be
worthless. And anyway, the GPL states this (first paragraph after subclause c
in clause 3) :

  The source code for a work means the preferred form of the work for
  making modifications to it.  For an executable work, complete source
  code means all the source code for all modules it contains, plus any
  associated interface definition files, plus the scripts used to
  control compilation and installation of the executable.

So, this is not some interpretation of the GPL by the FSF, and since it is
written black on white in the actual GPL text, i don't think there is any
doubt what a judge will decice :

  judge : so, to create this piece of work, what do you use to make
  modifications ?
  A (having sworn on the bible to say the truth and only the truth) : euh,
  some C or asm code, and a compiler or assembler to compile it.
  judge : and you did voluntarily place said code and distribute it under the
  GPL ?
  A : yes, it was going into the linux kernel, so ...
  judge : so you should distribute the source code to your work also, and
  distributing it under GPL is a breach of expectation from whoever you
  distribute it to.

Or something such.

If A is going to say that he is the only author, and that he would never sue
because of this breach of the GPL, he could just as well have put it under a
different licence, or put a small disclaimer about it, since we cannot really
act as if we believed that A would never sue us, if he doesn't explicitly say
so.

As an example, i package the unicorn driver for the bewan soft-ADSL pci and
usb modems. These being soft-ADSL modems which use a non-free binary-only ADSL
emulating library, but are otherwise GPL, i discussed the matter with
upstream, and after council from debian-legal, and possibly the FSF people
themselves, we got to use this as GPL exception :

  In addition, as a special exception, BeWAN systems gives permission
  to link the code of this program with the modem SW library
  (modem_ant_PCI.o, modem_ant_USB.o), and distribute linked combinations
  including the two. You are also given permission to redistribute the
  modem SW library (modem_ant_PCI.o, modem_ant_USB.o) with the rest of the
  code.
  You must obey the GNU General Public License in all respects for all of
  the code used other than the modem SW library.

So, really, i doubt any manufacturer distributing non-free firmware would
really have trouble in adding to their licence something like this :

  In addition, manufacturer, considers the firmware blob, identified as 
..., as
  a non-derivative piece of work, and thus not covered by the GPL of the rest
  of it. manufacturer gives permission to distribute said firmware blob as
  part of the linux kernel module driver for their hardware. The actual syntax
  of the inclusion of the code is still covered by the GPL, as is the rest of
  the driver code.

If we where to get something as nicely pu as this, provide a patch, asking
the manufacturer to sign it of, then all issues would be void, i believe. 

 says so and it's A granting D the right to distribute. There's no way C
 can prevent D from distributing A's software, if A is fine with it.
 It's up to A to decide if GPL conditions are met by D.
 
 Even in that case, you still need explicit permission of A, and all the 
 other
 copyright holders of the rest of the GPLed work, to give you an explicit
 exception to link with this non-free bit of code.
 
 Yes, but it does not apply to our case here. There's no all other
 copyright holders. _You_ stated that the firmware is included by mere
 aggregation, so there's no other holders involved. We're talking
 about the firmware case. A is one or two well identified subjects.
 And A wrote it is GPL'ed. Whether you agree or not, that's the licence
 A chose. A placed the copyright notice.

This is where i would need legal counsel, as to whether this means C or
someone else may stop you from distributing unless you provide the source. And
the real problem is that A didn't state anything, so we are only working on
the assumption that this may be the case, and A can change its mind later, and
the costs to defend 

Re: New SCM and commit list

2005-04-12 Thread Arjan van de Ven
On Mon, 2005-04-11 at 16:31 -0500, James Bottomley wrote:
 On Mon, 2005-04-11 at 14:26 -0700, Linus Torvalds wrote:
  I don't think kernel.org mirrors the private home directories, so it you
  do _temporary_ trees, just make them readable in your private home
  directory rather than in /pub/linux/kernel/people. For people with 
  kernel.org accounts, we can use that as the bkbits.net thing.
 
 It's also going to be a slight problem for those of us who don't have a
 kernel.org account...although I think the hosting I use on the parisc
 website might actually be outside the HP firewall, so I can probably beg
 for it to run any protocol you need (like rsync).

rsync also runs over ssh so if you can ssh in you can rsync to 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: 2.6.12-rc2-mm3

2005-04-12 Thread Andrew Morton
Stas Sergeev [EMAIL PROTECTED] wrote:

 Hello.
 
 Andrew Morton wrote:
  Program received signal SIGTRAP, Trace/breakpoint trap.
 SIGTRAP - it looks like the int $3
 triggered, not mov0x30(%esp),%eax,
 which is just the next insn and so the
 %eip points to it, but it might be
 innocent. And besides, 0x30(%esp) is
 EFLAGS, not OLDSS. So I think maybe my
 patch is not guilty this time, it is
 just the non-zero preempt count on the
 return path caused by something else.

OK, the `int $3' is part of the CONFIG_TRAP_BAD_SYSCALL_EXITS thing which I
never use.

I'm not sure what problem is actually being reported here, now you mention it.

  (gdb) p $eip
  $1 = (void *) 0xc0102ee7
 Could you please also do
 p $esp or info reg, so that we can
 see the rest of the registers?
 
  And as we see, we're at the mov0x30(%esp),%eax which accesses above 
  the 
  bottom of the stack.
 But that's strange. Another instance of
 the 0x30(%esp) is there a few instructions
 above this one, see it with disas restore_all.
 It is much more likely that the real offender
 is the previous instruction. $eip points on
 the instruction *after* the trap, which might
 be innocent.

Yup.  But are you sure that the + 8 is correct, given these offsets are
larger than that?

  After applying nmi_stack_correct-fix.patch, rc2-mm3
 I can't find this one in an -mm broken-outs.

It was in rc2-mm2.

 Where is this patch?
 Could you please also test this one:
 http://www.uwsg.iu.edu/hypermail/linux/kernel/0504.0/1287.html
  
  Interesting.  It could be an interaction between the kgdb patch and the new
  vm86 checking code.
 I think so too, will have a look if I can
 reproduce it.
 
  The above code is accessing esp+56,
 Yes, but this particular instruction was
 not reached. int $3 killed the system
 for some reasons.

Probably it decided that some syscall got a bad exit.  Disable
CONFIG_TRAP_BAD_SYSCALL_EXITS.

  -   p-thread.esp0 = (unsigned long) (childregs+1) - 8;
  +   p-thread.esp0 = (unsigned long) (childregs+1) - 15;
 15 is somewhat nasty - it will make the
 stack unaligned, should better be 16 I
 think.

?  It's still 4-byte-aligned.

 But I don't see why, the only
 scenario we've seen were the not stored
 SS/ESP, which is 8 bytes only.
 But the 
 If we definitely think my patch is guilty
 again, then probably something like this
 is necessary:
 
 --- linux/include/asm-i386/processor.h.old  2005-03-20 14:13:02.0 
 +0300
 +++ linux/include/asm-i386/processor.h  2005-04-12 07:50:11.0 +0400
 @@ -458,7 +458,7 @@
   * be within the limit.
   */
  #define INIT_TSS  {\
 -   .esp0   = sizeof(init_stack) + (long)init_stack,   \
 +   .esp0   = sizeof(init_stack) - 8 + (long)init_stack,   \
 .ss0= __KERNEL_DS,  \
 .ss1= __KERNEL_CS,  \
 .ldt= GDT_ENTRY_LDT,\
 
 But I don't think the init_stack can be
 abused on the sysenter path, so this is
 just a wild guess.

I'm suspecting this is all due to CONFIG_TRAP_BAD_SYSCALL_EXITS taking the
debug trap..

-
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] FUSE permission modell (Was: fuse review bits)

2005-04-12 Thread Miklos Szeredi
  Well the sanity check on the server side is always enforced.  You
  can't trick sftp or ftp to not check permissions.  So checking on
  the client side too (where the fuse daemon is running) makes no
  sense, does it?
 
 That argument doesn't make much sense to me.  But we're at the end of
 my useful contributions to this discussion; I'm going to be quiet now
 and hope some folks who know more about filesystems have more useful
 responses.

I'm sorry if this isn't clear enough.  My explanatory powers are not
very strong, so please bear with me.

Imagine an sftp session.  You list the files on the remote server.
You want download a file for which there are very limited permission
(e.g. only readable to owner).  You don't _know_ if you are the owner
since the uid on the file does not ring any bells, but you still try,
since you want that file badly.  And you succeed.

Would it make sense if the sftp client would try to interpret the
uid/gid/permission on each file?  Obviously not.

The same is true for the case when you mount an sshfs.  Since you
entered your password (or have a passwordless login to the server) you
are authorized to browse the files on the server, but only with the
capabilities you have there as a user.  The server does the
authorization.  The same is true for an NFS mount btw.  It's not the
client that checks the permissions.

So do you see why I argue in favor of having an option _not_ to check
permissions on the client by the kernel?

Thanks,
Miklos

-
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/


[ANNOUNCE 5/6] Linux-iSCSI High-Performance Initiator

2005-04-12 Thread Alex Aizman
include/linux/netlink.h changes (added NETLINK_ISCSI)
Signed-off-by: Alex Aizman [EMAIL PROTECTED]
Signed-off-by: Dmitry Yusupov [EMAIL PROTECTED]





--- linux-2.6.12-rc2.orig/include/linux/netlink.h   2005-03-01 
23:38:25.0 -0800
+++ linux-2.6.12-rc2.dima/include/linux/netlink.h   2005-04-11 
18:13:12.0 -0700
@@ -14,6 +14,7 @@
 #define NETLINK_SELINUX7   /* SELinux event notifications 
*/
 #define NETLINK_ARPD   8
 #define NETLINK_AUDIT  9   /* auditing */
+#define NETLINK_ISCSI  10  /* iSCSI Open Interface */
 #define NETLINK_ROUTE6 11  /* af_inet6 route comm channel */
 #define NETLINK_IP6_FW 13
 #define NETLINK_DNRTMSG14  /* DECnet routing messages */




[PATCH] Maintainers list update: linux-net - netdev

2005-04-12 Thread Horms
On Sat, Apr 09, 2005 at 03:52:05PM +0200, Jörn Engel wrote:
 On Fri, 8 April 2005 22:16:07 +0200, Pavel Machek wrote:
  
  More importantly, it is still listed as the list for network
  drivers...
  
  NETWORK DEVICE DRIVERS
  P:  Andrew Morton
  M:  [EMAIL PROTECTED]
  P:  Jeff Garzik
  M:  [EMAIL PROTECTED]
  L:  linux-net@vger.kernel.org
  S:  Maintained
 
 Maybe one of the two maintainers might want to change that? ;)

Use netdev as the mailing list contact instead of the mostly dead
linux-net list.

Signed-off-by: Horms [EMAIL PROTECTED]

= MAINTAINERS 1.295 vs edited =
--- 1.295/MAINTAINERS   2005-04-04 06:20:11 +09:00
+++ edited/MAINTAINERS  2005-04-12 15:11:38 +09:00
@@ -73,7 +73,7 @@
 3C359 NETWORK DRIVER
 P: Mike Phillips
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
@@ -81,13 +81,13 @@
 3C505 NETWORK DRIVER
 P: Philip Blundell
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 3CR990 NETWORK DRIVER
 P: David Dillow
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 3W- ATA-RAID CONTROLLER DRIVER
@@ -143,7 +143,7 @@
 8390 NETWORK DRIVERS [WD80x3/SMC-ELITE, SMC-ULTRA, NE2000, 3C503, etc.]
 P: Paul Gortmaker
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 A2232 SERIAL BOARD DRIVER
@@ -334,7 +334,7 @@
 
 ARPD SUPPORT
 P: Jonathan Layes
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 ASUS ACPI EXTRAS DRIVER
@@ -708,7 +708,7 @@
 
 DIGI RIGHTSWITCH NETWORK DRIVER
 P: Rick Richardson
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 W: http://www.digi.com
 S: Orphaned
 
@@ -814,7 +814,7 @@
 ETHEREXPRESS-16 NETWORK DRIVER
 P: Philip Blundell
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 ETHERNET BRIDGE
@@ -877,7 +877,7 @@
 FRAME RELAY DLCI/FRAD (Sangoma drivers too)
 P: Mike McLagan
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 FREEVXFS FILESYSTEM
@@ -1217,7 +1217,7 @@
 IPX NETWORK LAYER
 P: Arnaldo Carvalho de Melo
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 IRDA SUBSYSTEM
@@ -1594,13 +1594,13 @@
 M: [EMAIL PROTECTED]
 P: Jeff Garzik
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NETWORKING [GENERAL]
 P: Networking Team
 M: netdev@oss.sgi.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NETWORKING [IPv4/IPv6]
@@ -1636,7 +1636,7 @@
 P: Jan-Pascal van Best and Andreas Mohr
 M: Jan-Pascal van Best [EMAIL PROTECTED]
 M: Andreas Mohr [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 NINJA SCSI-3 / NINJA SCSI-32Bi (16bit/CardBus) PCMCIA SCSI HOST ADAPTER DRIVER
@@ -1678,7 +1678,7 @@
 M: [EMAIL PROTECTED]
 P: Mike Phillips
 M: [EMAIL PROTECTED] 
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
@@ -1783,7 +1783,7 @@
 PCNET32 NETWORK DRIVER
 P: Thomas Bogendörfer
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 PHRAM MTD DRIVER
@@ -1795,7 +1795,7 @@
 POSIX CLOCKS and TIMERS
 P: George Anzinger
 M: george@mvista.com
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Supported
 
 PNP SUPPORT
@@ -2042,7 +2042,7 @@
 P: Daniele Venzano
 M: [EMAIL PROTECTED]
 W: http://www.brownhat.org/sis900.html
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 SIS FRAMEBUFFER DRIVER
@@ -2101,7 +2101,7 @@
 SONIC NETWORK DRIVER
 P: Thomas Bogendoerfer
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Maintained
 
 SONY VAIO CONTROL DEVICE DRIVER
@@ -2151,7 +2151,7 @@
 SPX NETWORK LAYER
 P: Jay Schulist
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 S: Supported
 
 SRM (Alpha) environment access
@@ -2230,7 +2230,7 @@
 TOKEN-RING NETWORK DRIVER
 P: Mike Phillips
 M: [EMAIL PROTECTED]
-L: linux-net@vger.kernel.org
+L: netdev@oss.sgi.com
 L: [EMAIL PROTECTED]
 W: http://www.linuxtr.net
 S: Maintained
-
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/3] cifs: md5 cleanup - functions

2005-04-12 Thread Matt Mackall
On Mon, Apr 11, 2005 at 10:11:39PM +0200, Jesper Juhl wrote:
 
 Function names and return types on same line - conform to established 
 fs/cifs/ style.
 
 Patch is also available at:
   http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-funct.patch

I think the right thing to do here is what I did with the SHA1 code
from random.c: put the favorite implementation in lib/ and replace the
cryptoapi and CIFS implementations (and any other users) with it.

If you feel like tackling this, let me know, it's been on my todo list
for a while.

-- 
Mathematics is the supreme nostalgia of our 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: ext3 allocate-with-reservation latencies

2005-04-12 Thread Mingming Cao
On Mon, 2005-04-11 at 20:57 +0100, Stephen C. Tweedie wrote:
 Hi,

Hi Stephen, 

 
 On Mon, 2005-04-11 at 19:38, Mingming Cao wrote:
  Ah.. I see the win with the read lock now: once the a reservation window
  is added, updating it (either winding it forward and or searching for a
  avaliable window) probably is the majorirty of the operations on the
  tree, and using read lock for that should help reduce the latency.
 
 Right.  The down side is that for things like a kernel tar xf, we'll
 be doing lots of small file unpacks, and hopefully most files will be
 just one or two reservations --- so there's little winding forward going
 on.  The searching will still be improved in that case.

Just a side note that tar xf should know the file size before
unpacking it.  So it could set the reservation window size large enough
to fit the entire file before doing the file write through ioctl
command.

 Note that this may improve average case latencies, but it's not likely
 to improve worst-case ones.  We still need a write lock to install a new
 window, and that's going to have to wait for us to finish finding a free
 bit even if that operation starts using a read lock.  
 
Yes indeed. However nothing is free and there are always trade-offs.:) 

By worse case you mean multiple writes trying to allocate blocks around
same area?

But I wonder if the latency saw by Lee belongs to this worst-case: the
latency comes mostly from loop calling find_next_zero_bit() in
bitmap_search_next_usable_block(). Even if we take out the whole
reservation, we still possibility run into this kind of latency: the
bitmap on disk and on journal are extremely inconsistent so we need to
keep searching them both until we find a free bit on both map.

 I'm not really sure what to do about worst-case here.  For that, we
 really do want to drop the lock entirely while we do the bitmap scan.
 

Hmm...if we drop the lock entirely while scan the bitmap, assuming you
mean drop the read lock, then I am afraid we have to re-check the tree
(require a read or write lock ) to see if the new window space is still
there after the scan succeed. This is probably not very interesting for
the window rotating case.

 That leaves two options.  Hold a reservation while we do that; or don't.
 Holding one poses the problems we discussed before: either you hold a
 large reservation (bad for disk layout in the presence of concurrent
 allocators), or you hold smaller ones (high cost as you continually
 advance the window, which requires some read lock on the tree to avoid
 bumping into the next window.)
 

Well, we cannot hold a reservation (which need to update the tree)
without a write lock. I guess if we want to improve the average case
latency by replacing the current spin_lock with the read lock for the
new window space searching, we don't have much choice here.

 Just how bad would it be if we didn't hold a lock _or_ a window at all
 while doing the search for new window space?  

I wonder if this is feasible: Walk through the rb tree without a lock?
What if some node is being removed by another thread while we are
walking through the tree and trying to get the next node from it?


Thanks,

Mingming

-
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] sched: unlocked context-switches

2005-04-12 Thread Ingo Molnar

* David Mosberger [EMAIL PROTECTED] wrote:

 Now, Ingo says that the order is reversed with his patch, i.e., 
 switch_mm() happens after switch_to().  That means flush_tlb_mm() may 
 now see a current-active_mm which hasn't really been activated yet.  
 That should be OK since it would just mean that we'd do an early (and 
 duplicate) activate_context().  While it does not give me a warm and 
 fuzzy feeling to have this inconsistent state be observable by 
 interrupt-handlers (and, in particular, IPI-handlers), I don't see any 
 problem with it off hand.

thanks for the analysis. I fundamentally dont have any fuzzy feeling 
from having _any_ portion of the context-switch path nonatomic, but with 
more complex hardware it's just not possible it seems.

Ingo
-
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.12-rc2-mm3

2005-04-12 Thread Nick Piggin
On Mon, 2005-04-11 at 23:19 -0700, Andrew Morton wrote:
 Nick Piggin [EMAIL PROTECTED] wrote:
 
  - The effects of tcq on AS are much less disastrous than I thought they
 were.  Do I have the wrong workload?  Memory fails me.  Or did we fix 
  the
 anticipatory scheduler?
   
   
  
   Yes, we did fix it ;)
   Quite a long time ago, so maybe you are thinking of something else
   (I haven't been able to work it out).
 
 Steve Pratt's ols2004 presentation made AS look pretty bad.  However the
 numbers in the proceedings
 (http://www.finux.org/proceedings/LinuxSymposium2004_V2.pdf) are much less
 stark.
 
 Steve, what's up with that?  The slides which you talked to had some awful
 numbers.  Was it the same set of tests?
 

Yes, they still do... :P

 Seems that software RAID might have muddied the waters as well.
 

This may be the big issue, and yes software (and hardware) RAID isn't
very good for AS - mainly because it can't make a good guess as to
where the head is.

Probably software RAID should default to using deadline if possible.
I think we can do that easily with Jens' recent ioscheduler work.

 That was 2.6.5.  Do you recall if we did significant AS work after that?
 

I don't think there was.

   AS basically does its own TCQ strangulation, which IIRC involves things
   like completing all reads before issuing new writes, and completing all
   reads from one process before reads from another. As well as the
   fundamental way that waiting for a 'dependant read' throttles TCQ.
 
 My (mpt-fusion-based) workstation is still really slow when there's a lot
 of writeout happening.  Just from a quick test:
 
  2.6.12-rc2, as, tcq depth=2:7.241 seconds
  2.6.12-rc2, as, tcq depth=64:   12.172 seconds
  2.6.12-rc2+patch,as,tcq depth=64:   7.199 seconds
  2.6.12-rc2, cfq2,   tcq depth=64:   much more than 5 minutes
  2.6.12-rc2, cfq3,   tcq depth=64:   much more than 5 minutes
 
 2.6.11-rc4-mm1, as, mpt-f 39.349 seconds
 
 That was really really slow but had a sudden burst of read I/O at the end
 which made the thing look better than it really is.  I wouldn't have a clue
 what tag depth it's using, and it's the only mpt-fusion based machine I
 have handy...
 

Heh. 

   - as-limit-queue-depth.patch fixes things right up anyway.  Seems to be
 doing the right thing.  
   
   
  
   Well it depends on what we want to do. If we hard limit the AS queue
   like this, I can remove some of that TCQ throttling logic from AS.
  
   OTOH, the throttling was intended to allow us to sanely use a large
   TCQ depth without getting really bad behaviour. Theoretically a process
   can make use of TCQ if it is doing a lot of writing, or if it is not
   determined to be doing dependant reads.
 
 OK, I'll have a bit more of a poke at the LSI53C1030 driver, see if I can
 characterise what's going on.

OK. I'd like to start doing a bit of work on AS again too. Hopefully
after the current CPU scheduler work gets resolved.




-
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: Overcommit_memory logic fails when swap is off

2005-04-12 Thread Martin Egholm Nielsen
Hi Alan,
As I can see, the patch never made it in 2.4.x, right?!
So, I would like a diff - if still possible :-)
I submitted it ages ago but it was rejected and punted to 2.6. The 2.4
support is available in Red Hat Enterprise Linux 3, so you can pull it
out of the source rpms on the ftp site or out of Centos etc
Bingo. I seem to have found what looks like it in:
linux-2.4.21-selected-ac-bits.patch
linux-2.4.21-tunable-overcommit.patch
But many of the other patches messes with mmap.c, as well :-), so I 
guess there is some tracking assignment ahead...

But nevertheless, thanks for pointing me to the source...
BR,
 Martin Egholm
-
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: more git updates..

2005-04-12 Thread Barry K. Nathan
On Mon, Apr 11, 2005 at 10:14:13PM -0700, David Lang wrote:
 I've been reading this and have another thought for you guys to keep in 
 mind for this tool.
 
 version control of system config files on linux systems.

I've been thinking about this too. (I won't have time to implement this
however. If I do have time in the near future to do anything involving
git, it probably won't have anything to do with version control of
config files.)

 it sounds like you could put the / fileystem under the control of git 
 (after teaching it to not cross fileystem boundries so you can have 
 another filesystem to work with) and version control your entire system. 
 if this was done it would be nice to add a item type that would referance 
 a file in a distro package to save space. it sounds like you could run a 
 git checkin daily (as part of the updatedb run for example) at very little 
 cost.

I was thinking that the GIT checkin should actually be done by the
distro configuration tools, and not as a cronjob. And maybe the config
tools could do two checkins if there were any manual changes since the
last checkin, or something. (That is, one checkin to check in the manual
changes since the last checkin, and another to check in whatever the
config tool just did.)

Now that I think about it, it would be really good to have a simple tool
for doing a manual checkin after manual editing of config files, but I
think something like the dual-checkin scheme would be needed as a safety
net in case root forgets to do the checkin.

-Barry K. Nathan [EMAIL PROTECTED]

-
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.12-rc2-mm3

2005-04-12 Thread Jens Axboe
On Mon, Apr 11 2005, Andrew Morton wrote:
 - CFQ is seriously, seriously read-starved on this workload.
 
 CFQ3:
 
 procs ---memory-- ---swap-- -io --system-- cpu
  r  b   swpd   free   buff  cache   si   sobibo   incs us sy id wa
  1  5   1008  25888   4204 38458200012 50544 1119   116  0  3 49 
 48
  0  5   1008  24096   4204 384752000 8 51200 1112   110  0  3 49 
 48
  0  5   1008  25824   4204 384582000 8 54816 1117   120  0  4 49 
 48
  0  5   1008  25440   4204 384616000 8 52880 1113   115  0  3 49 
 48
  0  5   1008  25888   4208 38457480016 51024 1121   116  0  3 49 
 48

Looks very bad, I'll have a look at this.

-- 
Jens Axboe

-
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/


[RFC] kallsyms C_SYMBOL_PREFIX support

2005-04-12 Thread Yoshinori Sato
kallsyms does not consider SYMBOL_PREFIX of C.
Consequently do not work in architecture using prefix character (h8300, v850) 
really.

Because I can want to use this, I made a patch.
Please comment.

-- 
Yoshinori Sato
[EMAIL PROTECTED]

= scripts/kallsyms.c 1.16 vs edited =
--- 1.16/scripts/kallsyms.c 2005-01-01 19:22:13 +09:00
+++ edited/scripts/kallsyms.c   2005-04-12 15:50:47 +09:00
@@ -69,6 +69,7 @@
 static int size, cnt;
 static unsigned long long _stext, _etext, _sinittext, _einittext;
 static int all_symbols = 0;
+static char symbol_prefix_char = '\0';
 
 struct token {
unsigned char data[MAX_TOK_SIZE];
@@ -93,7 +94,7 @@
 static void
 usage(void)
 {
-   fprintf(stderr, Usage: kallsyms [--all-symbols]  in.map  out.S\n);
+   fprintf(stderr, Usage: kallsyms [--all-symbols] 
[--symbol-prefix=prefix char]  in.map  out.S\n);
exit(1);
 }
 
@@ -112,6 +113,7 @@
 read_symbol(FILE *in, struct sym_entry *s)
 {
char str[500];
+   char *sym;
int rc;
 
rc = fscanf(in, %llx %c %499s\n, s-addr, s-type, str);
@@ -123,27 +125,32 @@
return -1;
}
 
+   sym = str;
+   /* skip prefix char */
+   if (symbol_prefix_char  str[0] == symbol_prefix_char)
+   sym++;
+
/* Ignore most absolute/undefined (?) symbols. */
-   if (strcmp(str, _stext) == 0)
+   if (strcmp(sym, _stext) == 0)
_stext = s-addr;
-   else if (strcmp(str, _etext) == 0)
+   else if (strcmp(sym, _etext) == 0)
_etext = s-addr;
-   else if (strcmp(str, _sinittext) == 0)
+   else if (strcmp(sym, _sinittext) == 0)
_sinittext = s-addr;
-   else if (strcmp(str, _einittext) == 0)
+   else if (strcmp(sym, _einittext) == 0)
_einittext = s-addr;
else if (toupper(s-type) == 'A')
{
/* Keep these useful absolute symbols */
-   if (strcmp(str, __kernel_syscall_via_break) 
-   strcmp(str, __kernel_syscall_via_epc) 
-   strcmp(str, __kernel_sigtramp) 
-   strcmp(str, __gp))
+   if (strcmp(sym, __kernel_syscall_via_break) 
+   strcmp(sym, __kernel_syscall_via_epc) 
+   strcmp(sym, __kernel_sigtramp) 
+   strcmp(sym, __gp))
return -1;
 
}
else if (toupper(s-type) == 'U' ||
-is_arm_mapping_symbol(str))
+is_arm_mapping_symbol(sym))
return -1;
 
/* include the type field in the symbol name, so that it gets
@@ -177,6 +184,11 @@
_SDA2_BASE_,  /* ppc */
NULL };
int i;
+   int offset = 1;
+
+   /* skip prefix char */
+   if (symbol_prefix_char  *(s-sym + 1) == symbol_prefix_char)
+   offset++;
 
/* if --all-symbols is not specified, then symbols outside the text
 * and inittext sections are discarded */
@@ -190,17 +202,17 @@
 * they may get dropped in pass 2, which breaks the kallsyms
 * rules.
 */
-   if ((s-addr == _etext  strcmp(s-sym + 1, _etext)) ||
-   (s-addr == _einittext  strcmp(s-sym + 1, _einittext)))
+   if ((s-addr == _etext  strcmp(s-sym + offset, _etext)) ||
+   (s-addr == _einittext  strcmp(s-sym + offset, 
_einittext)))
return 0;
}
 
/* Exclude symbols which vary between passes. */
-   if (strstr(s-sym + 1, _compiled.))
+   if (strstr(s-sym + offset, _compiled.))
return 0;
 
for (i = 0; special_symbols[i]; i++)
-   if( strcmp(s-sym + 1, special_symbols[i]) == 0 )
+   if( strcmp(s-sym + offset, special_symbols[i]) == 0 )
return 0;
 
return 1;
@@ -225,9 +237,15 @@
 
 static void output_label(char *label)
 {
-   printf(.globl %s\n,label);
+   if (symbol_prefix_char)
+   printf(.globl %c%s\n, symbol_prefix_char, label);
+   else
+   printf(.globl %s\n, label);
printf(\tALGN\n);
-   printf(%s:\n,label);
+   if (symbol_prefix_char)
+   printf(%c%s:\n, symbol_prefix_char, label);
+   else
+   printf(%s:\n, label);
 }
 
 /* uncompress a compressed symbol. When this function is called, the best table
@@ -665,6 +683,13 @@
 
insert_real_symbols_in_table();
 
+   /* When valid symbol is not registered, exit to error */
+   if (good_head.left == good_head.right 
+   bad_head.left == bad_head.right) {
+   fprintf(stderr, No valid symbol.\n);
+   exit(1);
+   }
+
optimize_result();
 }
 
@@ -672,9 +697,21 @@
 int
 main(int argc, char **argv)
 {
-   if (argc == 2  strcmp(argv[1], --all-symbols) == 0)
-   all_symbols = 1;
-   else if (argc != 1)
+   if 

[ANNOUNCE 1b/6] Linux-iSCSI High-Performance Initiator

2005-04-12 Thread Alex Aizman
For the start of this thread please refer to:
http://marc.theaimsgroup.com/?l=linux-kernelm=111327337005048w=2
and
http://marc.theaimsgroup.com/?l=linux-kernelm=111328256211837w=2
Regards,
The combined open-iscsi and linux-iscsi teams
 SCSI LLDD, the 2nd part:
 - iscsi_if.c (iSCSI open interface over netlink, iSCSI 
generic transport module).

 Signed-off-by: Alex Aizman [EMAIL PROTECTED]
 Signed-off-by: Dmitry Yusupov [EMAIL PROTECTED]

diff -Nru --exclude Kconfig --exclude Makefile 
linux-2.6.12-rc2.orig/drivers/scsi/iscsi_if.c 
linux-2.6.12-rc2.dima/drivers/scsi/iscsi_if.c
--- linux-2.6.12-rc2.orig/drivers/scsi/iscsi_if.c   1969-12-31 
16:00:00.0 -0800
+++ linux-2.6.12-rc2.dima/drivers/scsi/iscsi_if.c   2005-04-11 
18:13:12.0 -0700
@@ -0,0 +1,818 @@
+/*
+ * iSCSI Initiator Kernel/User Interface
+ *
+ * Copyright (C) 2004 Dmitry Yusupov, Alex Aizman
+ * maintained by [EMAIL PROTECTED]
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published
+ * by the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful, but
+ * WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
+ * General Public License for more details.
+ *
+ * See the file COPYING included with this distribution for more details.
+ */
+
+#include linux/module.h
+#include linux/mempool.h
+#include net/tcp.h
+#include scsi/scsi_host.h
+#include scsi/scsi_device.h
+#include scsi/scsi_transport.h
+#ifdef CONFIG_SCSI_ISCSI_ATTRS
+#include scsi/scsi_transport_iscsi.h
+#endif
+#include scsi/iscsi_iftrans.h
+#include scsi/iscsi_ifev.h
+
+MODULE_AUTHOR(Dmitry Yusupov [EMAIL PROTECTED], 
+ Alex Aizman [EMAIL PROTECTED]);
+MODULE_DESCRIPTION(Open-iSCSI Interface);
+MODULE_LICENSE(GPL);
+
+static struct iscsi_transport *transport_table[ISCSI_TRANSPORT_MAX];
+static struct sock *nls;
+static int daemon_pid;
+DECLARE_MUTEX(callsema);
+
+struct mempool_zone {
+   mempool_t *pool;
+   volatile int allocated;
+   int size;
+   int max;
+   int hiwat;
+   struct list_head freequeue;
+   spinlock_t freelock;
+};
+
+static struct mempool_zone z_reply;
+
+#define Z_REPLY0
+#define Z_SIZE_REPLY   NLMSG_SPACE(sizeof(struct iscsi_uevent))
+#define Z_MAX_REPLY8
+#define Z_HIWAT_REPLY  6
+
+#define Z_PDU  1
+#define Z_SIZE_PDU NLMSG_SPACE(sizeof(struct iscsi_uevent) + \
+   sizeof(struct iscsi_hdr) + \
+   DEFAULT_MAX_RECV_DATA_SEGMENT_LENGTH)
+#define Z_MAX_PDU  8
+#define Z_HIWAT_PDU6
+
+#define Z_ERROR2
+#define Z_SIZE_ERROR   NLMSG_SPACE(sizeof(struct iscsi_uevent))
+#define Z_MAX_ERROR16
+#define Z_HIWAT_ERROR  12
+
+#define zone_init(_zp, _zone) ({ \
+   (_zp)-pool = mempool_create(Z_MAX_##_zone, \
+   mempool_zone_alloc_skb, mempool_zone_free_skb, \
+   (void*)(_zp)); \
+   if ((_zp)-pool) { \
+   (_zp)-max = Z_MAX_##_zone; \
+   (_zp)-size = Z_SIZE_##_zone; \
+   (_zp)-hiwat = Z_HIWAT_##_zone; \
+   INIT_LIST_HEAD((_zp)-freequeue); \
+   spin_lock_init((_zp)-freelock); \
+   (_zp)-allocated = 0; \
+   } \
+   (_zp)-pool; \
+})
+
+struct iscsi_if_cnx {
+   struct list_head item;  /* item in cnxlist */
+   struct list_head snxitem;   /* item in snx-connections */
+   iscsi_cnx_t cp_cnx;
+   iscsi_cnx_t dp_cnx;
+   volatile int active;
+   struct Scsi_Host *host; /* originated shost */
+   struct iscsi_transport *transport;
+   struct mempool_zone z_error;
+   struct mempool_zone z_pdu;
+   struct list_head freequeue;
+};
+LIST_HEAD(cnxlist);
+spinlock_t cnxlock;
+
+struct iscsi_if_snx {
+   struct list_head item;  /* item in snxlist */
+   struct list_head connections;
+   iscsi_snx_t cp_snx;
+   iscsi_snx_t dp_snx;
+   struct iscsi_transport *transport;
+};
+LIST_HEAD(snxlist);
+spinlock_t snxlock;
+
+#define H_TYPE_CP  0
+#define H_TYPE_DP  1
+#define H_TYPE_HOST2
+static struct iscsi_if_cnx*
+iscsi_if_find_cnx(uint64_t key, int type)
+{
+   unsigned long flags;
+   struct iscsi_if_cnx *cnx;
+
+   spin_lock_irqsave(cnxlock, flags);
+   list_for_each_entry(cnx, cnxlist, item) {
+   if ((type == H_TYPE_DP  cnx-dp_cnx == key) ||
+   (type == H_TYPE_CP  cnx-cp_cnx == key) ||
+   (type == H_TYPE_HOST  cnx-host == iscsi_ptr(key))) {
+   spin_unlock_irqrestore(cnxlock, flags);
+   return cnx;
+   }
+   }
+   

Re: [PATCH 1/3] cifs: md5 cleanup - functions

2005-04-12 Thread Jesper Juhl
On Mon, 11 Apr 2005, Matt Mackall wrote:

 Date: Mon, 11 Apr 2005 23:37:45 -0700
 From: Matt Mackall [EMAIL PROTECTED]
 To: Jesper Juhl [EMAIL PROTECTED]
 Cc: Steven French [EMAIL PROTECTED], Steve French [EMAIL PROTECTED],
 linux-kernel@vger.kernel.org
 Subject: Re: [PATCH 1/3] cifs: md5 cleanup - functions
 
 On Mon, Apr 11, 2005 at 10:11:39PM +0200, Jesper Juhl wrote:
  
  Function names and return types on same line - conform to established 
  fs/cifs/ style.
  
  Patch is also available at:
  http://www.linuxtux.org/~juhl/kernel_patches/fs_cifs_md5-funct.patch
 
 I think the right thing to do here is what I did with the SHA1 code
 from random.c: put the favorite implementation in lib/ and replace the
 cryptoapi and CIFS implementations (and any other users) with it.
 
 If you feel like tackling this, let me know, it's been on my todo list
 for a while.
 
I wouldn't mind having a go at it, but I don't have too much time this 
week, but next week I should have some time - I'll take a look at it then.

-- 
Jesper Juhl


-
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: Processes stuck on D state on Dual Opteron

2005-04-12 Thread Jens Axboe
On Tue, Apr 12 2005, Nick Piggin wrote:
 Actually the patches I have sent you do fix real bugs, but they also
 make the block layer less likely to recurse into page reclaim, so it
 may be eg. hiding the problem that Neil's patch fixes.

Can you push those to Andrew? I'm quite happy with the way they turned
out. It would be nice if Ken would bench 2.6.12-rc2 with and without
those patches.

-- 
Jens Axboe

-
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: Kernel SCM saga.. (bk license?)

2005-04-12 Thread Kedar Sovani
I was wondering if working on git, is in anyway, in violation of the
Bitkeeper license, which states that you cannot work on any other SCM
(SCM-like?) tool for x amount of time after using Bitkeeper ?


Kedar. 

On Apr 8, 2005 10:12 AM, Linus Torvalds [EMAIL PROTECTED] wrote:
 
 
 On Thu, 7 Apr 2005, Chris Wedgwood wrote:
 
  I'm playing with monotone right now.  Superficially it looks like it
  has tons of gee-whiz neato stuff...  however, it's *agonizingly* slow.
  I mean glacial.  A heavily sedated sloth with no legs is probably
  faster.
 
 Yes. The silly thing is, at least in my local tests it doesn't actually
 seem to be _doing_ anything while it's slow (there are no system calls
 except for a few memory allocations and de-allocations). It seems to have
 some exponential function on the number of pathnames involved etc.
 
 I'm hoping they can fix it, though. The basic notions do not sound wrong.
 
 In the meantime (and because monotone really _is_ that slow), here's a
 quick challenge for you, and any crazy hacker out there: if you want to
 play with something _really_ nasty (but also very _very_ fast), take a
 look at kernel.org:/pub/linux/kernel/people/torvalds/.
 
 First one to send me the changelog tree of sparse-git (and a tool to
 commit and push/pull further changes) gets a gold star, and an honorable
 mention. I've put a hell of a lot of clues in there (*).
 
 I've worked on it (and little else) for the last two days. Time for
 somebody else to tell me I'm crazy.
 
 Linus
 
 (*) It should be easier than it sounds. The database is designed so that
 you can do the equivalent of a nonmerging (ie pure superset) push/pull
 with just plain rsync, so replication really should be that easy (if
 somewhat bandwidth-intensive due to the whole-file format).
 
 Never mind merging. It's not an SCM, it's a distribution and archival
 mechanism. I bet you could make a reasonable SCM on top of it, though.
 Another way of looking at it is to say that it's really a content-
 addressable filesystem, used to track directory trees.
 -
 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/

-
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] ppc32: MV643XX ethernet is an option for Pegasos

2005-04-12 Thread Benjamin Herrenschmidt
Hi !

This patch allows Kconfig to build the MV643xx ethernet driver on
Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing
fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in
there as the interrupt is shared if I understand things correctly.

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Fabio Massimo Di Nitto [EMAIL PROTECTED]

#! /bin/sh -e

. $(dirname $0)/DPATCH

@DPATCH@
diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig 
/usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig
--- linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig   2005-04-11 
16:13:06.0 +0200
+++ 
/usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig
   2005-04-12 08:05:33.535955920 +0200
@@ -2044,7 +2044,7 @@
 
 config MV643XX_ETH
tristate MV-643XX Ethernet support
-   depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || 
MOMENCO_OCELOT_3
+   depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || 
MOMENCO_OCELOT_3 || PPC_MULTIPLATFORM
help
  This driver supports the gigabit Ethernet on the Marvell MV643XX
  chipset which is used in the Momenco Ocelot C and Jaguar ATX and
diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c 
/usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c
--- linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c 2005-04-07 
14:57:16.0 +0200
+++ 
/usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c
 2005-04-12 08:07:36.246301112 +0200
@@ -668,7 +668,7 @@
spin_lock_irq(mp-lock);
 
err = request_irq(dev-irq, mv643xx_eth_int_handler,
-   SA_INTERRUPT | SA_SAMPLE_RANDOM, dev-name, dev);
+   SA_SHIRQ | SA_SAMPLE_RANDOM, dev-name, dev);
 
if (err) {
printk(KERN_ERR Can not assign IRQ number to MV643XX_eth%d\n,



-
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: usbdux registers, but communcation to device times out

2005-04-12 Thread Greg KH
On Fri, Apr 08, 2005 at 02:22:52PM -0700, Melanie Dumas wrote:
 
 We installed comedi and comedilib according to the instructions on
 http://www.linux-usb-daq.co.uk/drivers2/2.6/. There were no errors on
 installation, and the usbdux drivers were auto-detected by hotplug
 when the usbdux controller was plugged in. We saw the message kernel:
 comedi0: usbdux: usb-device 0 is attached to comedi.

Why not ask the authors of that driver, as we do not know anything about
what is in that code (hint, odds are it's due to a usb api change...)

Good luck,

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: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

2005-04-12 Thread Christoph Hellwig
On Mon, Apr 11, 2005 at 10:36:51PM -0700, Greg KH wrote:
 On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
Common header files:
- iscsi_ifev.h (user/kernel events).
 
 These structures cross the user/kernel boundry?  If so, they _must_ use
 the __u32 and friends types, not the horrible uint32_t mess...

No, C99 are just fine.
-
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] usb: kfree() cleanups in drivers/usb/core/devio.c

2005-04-12 Thread Greg KH
On Mon, Apr 11, 2005 at 11:55:22PM +0200, Jesper Juhl wrote:
 Checking for NULL before calling kfree() is redundant. This patch removes 
 these redundant checks and also makes a few tiny whitespace changes.
 
 Signed-off-by: Jesper Juhl [EMAIL PROTECTED]

Applied, 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: 2.6.12-rc2-mm3

2005-04-12 Thread Andrew Morton
Nick Piggin [EMAIL PROTECTED] wrote:

AS basically does its own TCQ strangulation, which IIRC involves things
 like completing all reads before issuing new writes, and completing all
 reads from one process before reads from another. As well as the
 fundamental way that waiting for a 'dependant read' throttles TCQ.
   
   My (mpt-fusion-based) workstation is still really slow when there's a lot
   of writeout happening.  Just from a quick test:
   
2.6.12-rc2,  as, tcq depth=2:7.241 seconds
2.6.12-rc2,  as, tcq depth=64:   12.172 seconds
2.6.12-rc2+patch,as, tcq depth=64:   7.199 seconds
2.6.12-rc2,  cfq2,   tcq depth=64:   much more than 5 minutes
2.6.12-rc2,  cfq3,   tcq depth=64:   much more than 5 minutes
   
   2.6.11-rc4-mm1, as, mpt-f  39.349 seconds
   
   That was really really slow but had a sudden burst of read I/O at the end
   which made the thing look better than it really is.  I wouldn't have a clue
   what tag depth it's using, and it's the only mpt-fusion based machine I
   have handy...
   
 
  Heh. 

Well with my current lineup on the mpt-fusion driver and no
as-limit-queue-depth.patch that test takes 17 seconds.  With
as-limit-queue-depth.patch it's down to 10 seconds.  Which is pretty darn
good btw.  I assume from this:

scsi0 : ioc0: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=25
scsi1 : ioc1: LSI53C1030, FwRev=01030600h, Ports=1, MaxQ=222, IRQ=26

that it's using a tag depth of 222.

int  req_depth; /* Number of request frames */

I wonder if that's true...


One thing which changed is that this kernel now has the fixed-up mpt-fusion
chipset tuning.  That doubles the IO bandwidth, which would pretty well
account for that difference.  I'll wait and see how irritating things get
under writeout load.

Yes, we'll need to decide if we want to retain as-limit-queue-depth.patch
and toss out some of the older AS logic which was designed to address the
TCQ problem.

Steve, could you help to identify a not-too-hard-to-set-up workload at
which AS was particularly poor?  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: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

2005-04-12 Thread Greg KH
On Tue, Apr 12, 2005 at 08:27:33AM +0100, Christoph Hellwig wrote:
 On Mon, Apr 11, 2005 at 10:36:51PM -0700, Greg KH wrote:
  On Mon, Apr 11, 2005 at 08:24:08PM -0700, Alex Aizman wrote:
 Common header files:
 - iscsi_ifev.h (user/kernel events).
  
  These structures cross the user/kernel boundry?  If so, they _must_ use
  the __u32 and friends types, not the horrible uint32_t mess...
 
 No, C99 are just fine.

Um, why?  We've been down this road before, and for types that cross the
boundry, we _must_ use the __ version of the kernel types, not the
uint32_t stuff.

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: PROBLEM: AIPTEK input doesn`t register `device` `driver` section in sysfs (/sys/class/input/event#)

2005-04-12 Thread Greg KH
On Sun, Apr 10, 2005 at 07:21:28PM +0600, Viktor A. Danilov wrote:
 
 PROBLEM: aiptek input doesn`t register `device`  `driver` section in sysfs 
 (/sys/class/input/event#)
 REASON: `dev` - field not filled...
 SOLUTION: in linux/drivers/usb/input/aiptek.c write
   aiptek-inputdev.dev = intf-dev;
 before calling 
   input_register_device(aiptek-inputdev);

Good catch, I've applied this to my kernel trees.

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: Processes stuck on D state on Dual Opteron

2005-04-12 Thread Chen, Kenneth W
On Tue, Apr 12 2005, Nick Piggin wrote:
 Actually the patches I have sent you do fix real bugs, but they also
 make the block layer less likely to recurse into page reclaim, so it
 may be eg. hiding the problem that Neil's patch fixes.

Jens Axboe wrote on Tuesday, April 12, 2005 12:08 AM
 Can you push those to Andrew? I'm quite happy with the way they turned
 out. It would be nice if Ken would bench 2.6.12-rc2 with and without
 those patches.


I like the patch a lot and already did bench it on our db setup.  However,
I'm seeing a negative regression compare to a very very crappy patch (see
attached, you can laugh at me for doing things like that :-).

My first reaction is that the overhead is in wait queue setup and tear down
in get_request_wait function. Throwing the following patch on top does improve
things a bit, but we are still in the negative territory.  I can't explain why.
Everything suppose to be faster.  So I'm staring at the execution profile at
the moment.


diff -Nru a/drivers/block/ll_rw_blk.c b/drivers/block/ll_rw_blk.c
--- a/drivers/block/ll_rw_blk.c 2005-04-12 00:48:12 -07:00
+++ b/drivers/block/ll_rw_blk.c 2005-04-12 00:48:12 -07:00
@@ -1740,10 +1740,35 @@
  */
 static struct request *get_request_wait(request_queue_t *q, int rw)
 {
-   DEFINE_WAIT(wait);
struct request *rq;
+   struct request_list *rl = q-rq;
+   int gfp_flag = GFP_ATOMIC;
+
+   if (rl-count[rw]  queue_congestion_off_threshold(q)) {
+   rq = kmem_cache_alloc(request_cachep, gfp_flag);
+   if (rq) {
+   if (!elv_set_request(q, rq, gfp_flag)) {
+
+   rl-count[rw]++;
+   INIT_LIST_HEAD(rq-queuelist);
+   rq-flags = rw;
+   rq-rq_status = RQ_ACTIVE;
+   rq-ref_count = 1;
+   rq-q = q;
+   rq-rl = rl;
+   rq-special = NULL;
+   rq-data_len = 0;
+   rq-data = NULL;
+   rq-sense = NULL;
+
+   return rq;
+   }
+   kmem_cache_free(request_cachep, rq);
+   }
+   }

do {
+   DEFINE_WAIT(wait);
struct request_list *rl = q-rq;

prepare_to_wait_exclusive(rl-wait[rw], wait,



begin 666 old_freereq.patch
M9EF9B M3G)U($O9')I=F5RR]B;]C:R]L;%]R=U]B;LN8R!B+V1R:79E
MG,O8FQO8VLO;Q?G=?8FQK+F,*+2TM($O9')I=F5RR]B;]C:R]L;%]R
M=U]B;LN8PDR,# U+3 T+3 T(# P.C4X.C4U(TP-SHP, [EMAIL PROTECTED]FEV
M97)S+V)L;V-K+VQL7W)W7V)L:RYC3(P,#4M,#0M,#0@,# [EMAIL PROTECTED]@+3 W
M.C PD! (TQ.3DV+#$U(LQ.3DV+#$T($! B *( ER82 ]()I;RT^8FE?
MG@)B H,2 \/!24]?4E=?04A%040I.PH@BL)[EMAIL PROTECTED])A8B!A(9R964@
MF5Q=65S=!FF]M('1H92!FF5E;ES= J+PHK69R965R97$@/2!G971?
MF5Q=65S=AQ+[EMAIL PROTECTED])0RD[BL*([EMAIL PROTECTED]@7-P:6Y?
M;]C:U]IG$H2T^75E=65?;]C:RD[B *+0EI9B H96QV7W%U975E7V5M
M'1Y*'$I*2![BL):[EMAIL PROTECTED]5L=E]Q=65U95]E;7!T2AQ*2D*( D)8FQK7W!L
M=6=?95V:6-E*'$I.PHM0EG;W1O(=E=%]R3L*+0E]BT):[EMAIL PROTECTED])AG)I
M97(IBT)6=O=[EMAIL PROTECTED])Q.PH@B )96Q?F5T([EMAIL PROTECTED]F=E*'$L
A(9R97$L()I;RD[B )W=I=-H(AE;%]R970I('L*
`
end

-
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/


Gravador de telefone

2005-04-12 Thread Vinicius

Não seja o último saber. Chegou o gravador de conversas telefônicas. Trata-se 
de um mini gravador que pode ser instalado em qualquer ponto do fio da sua 
linha telefônica (inclusive extenções), e basta o seu telefone sair do gancho, 
seja para receber ou efetuar uma chamada, que a gravação é acionada 
automaticamente. E quando o telefone voltar para o gancho a gravação é 
finalizada. A gravação só é acionada quando o telefone está sendo utilizado. 
Depois é só voltar a fita e ouvir tudo o que foi falado. Essa técnologia está 
ao seu alcance por apenas R$ 185,00. Despachamos para todo o Brasil. Contato 
com Sérgio nos fones: 51-471.3583(pela manhã) *  51-8424.1442 (24 hs ) ou 
[EMAIL PROTECTED]
Obs: Instalar esse aparelho em linhas alheias é contra a lei.

-
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] FUSE permission modell (Was: fuse review bits)

2005-04-12 Thread Jan Hudec
On Mon, Apr 11, 2005 at 17:56:09 +0200, Miklos Szeredi wrote:
  Could you explain a little more?  I don't see the point in denying
  access to root, but I also can't tell from your explanation whether you
  do or not.
 
 Fuse by default does.  This can be disabled by one of two mount
 options: allow_other and allow_root.  The former implies the
 later.  These mount options are only allowed for mounting by root, but
 this can be relaxed with a configuration option.
 
  If I mount a filesystem using ssh, I want to be able to sudo cp
  foo.txt /etc and not get an inexplicable permissions error.
 
 If you can do that sudo, you can also modify the configuration and use
 one of the mount options.

And that's as false as it can be! Ok, no sane admin would probably give
out sudo permissions for cp, but other commands may make sense (perhaps
setting some sysctl in /proc -- that needs fsuid=0 -- otherwise one
could teach sudo to set euid, but not fsuid). And than the user would
*NOT* be able to use those mount options.

Anyway, why are the options not available to non-root? It's their
filesystem, they should be allowed to set it up!

 4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
  
  Similar questions.
 
 This behavior can be disabled by the default_permissions mount
 option (wich is not privileged, since it adds restrictions).  A FUSE
 filesystem mounted by root (and not for private purposes) would
 normally be done with allow_other,default_permissions.

I'd hell lot prefer it the other way around. The user write bit is
an accident counter-measure similarly to the root squashing.

It needs to be split to two orthogonal options -- one to specify,
whether all files are owned by the mounter or by whomever the filesystem
says and another whether permissions are checked.

---
 Jan 'Bulb' Hudec [EMAIL 
PROTECTED]


signature.asc
Description: Digital signature


Re: [ANNOUNCE 2/6] Linux-iSCSI High-Performance Initiator

2005-04-12 Thread Christoph Hellwig
On Tue, Apr 12, 2005 at 12:45:14AM -0700, Greg KH wrote:
 Um, why?  We've been down this road before, and for types that cross the
 boundry, we _must_ use the __ version of the kernel types, not the
 uint32_t stuff.

That's total bullshit.  C99 types just work in both the kernel and userland,
while __u* types need to be typedefed to these exact C99 everywhere in
userland bnecause they're only provided in kernelspace.

-
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: Re: more git updates..

2005-04-12 Thread Petr Baudis
Dear diary, on Tue, Apr 12, 2005 at 06:05:19AM CEST, I got a letter
where David Eger [EMAIL PROTECTED] told me that...
 So with git, *every* changeset is an entire (compressed) copy of the
 kernel.  Really?  Every patch you accept adds 37 MB to your hard disk?
 
 Am I missing something here?

Yes. Only changes files re-appear. The unchanged files keep the same
SHA1 hash, therefore they don't re-appear in the repository.

So, if Linus gets a patch which sanitizes drivers/char/selection.c,
only these new objects appear in the repository:

drivers/char/selection.c
drivers/char
drivers
. (project root)
commit message

Kind regards,

-- 
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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.12-rc2-mm3

2005-04-12 Thread Jindrich Makovicka
Andrew Morton wrote:
 Jindrich Makovicka [EMAIL PROTECTED] wrote:
 
Andrew Morton wrote:

ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.12-rc2/2.6.12-rc2-mm3/

MPlayer randomly crashes in various pthread_* calls when using binary
codecs. 2.6.12-rc2-mm2 was ok. I tried to reverse
fix-crash-in-entrys-restore_all.patch, but it didn't help.

 
 
 hm, could be anything.
 
 Does 2.6.12-rc2 also fail?

looks like it's sched-unlocked-context-switches.patch. after reversing
it works fine.

-- 
Jindrich Makovicka

-
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/


Prototype error in linux/debugfs.h

2005-04-12 Thread Chen, Kenneth W
To lazy to write a patch, the inline debugfs function declaration
for the following three functions disagree between CONFIG_DEBUG_FS
and !CONFIG_DEBUG_FS

4th argument mismatch, looks like an obvious copy-n-paste error.
u16, u32, and u32?


static inline struct dentry *debugfs_create_u16(const char *name, mode_t mode,
struct dentry *parent,
u8 *value)
{
return ERR_PTR(-ENODEV);
}

static inline struct dentry *debugfs_create_u32(const char *name, mode_t mode,
struct dentry *parent,
u8 *value)
{
return ERR_PTR(-ENODEV);
}

static inline struct dentry *debugfs_create_bool(const char *name, mode_t mode,
 struct dentry *parent,
 u8 *value)
{
return ERR_PTR(-ENODEV);
}


-
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: New SCM and commit list

2005-04-12 Thread Geert Uytterhoeven
On Mon, 11 Apr 2005, Daniel Barkalow wrote:
 If merge took trees instead of single files, and had some way of detecting
 renames (or it got additional information about the differences between
 files), would that give BK-quality performance? Or does BK also support

I wrote a script to do merges on a tree (so far without rename detection,
though ;-) a long time ago, and still use it every time Linus or Marcelo
release a new version.

Look at `mergetree' on http://linux-m68k-cvs.ubb.ca/~geert/

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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] usb: kfree() cleanups in drivers/usb/core/devio.c

2005-04-12 Thread Jesper Juhl
On Tue, 12 Apr 2005, Greg KH wrote:

 Date: Tue, 12 Apr 2005 00:40:56 -0700
 From: Greg KH [EMAIL PROTECTED]
 To: Jesper Juhl [EMAIL PROTECTED]
 Cc: linux-kernel@vger.kernel.org, Thomas Sailer [EMAIL PROTECTED],
 Greg Kroah-Hartman [EMAIL PROTECTED], 
 linux-usb-devel@lists.sourceforge.net
 Subject: Re: [PATCH] usb: kfree() cleanups in drivers/usb/core/devio.c
 
 On Mon, Apr 11, 2005 at 11:55:22PM +0200, Jesper Juhl wrote:
  Checking for NULL before calling kfree() is redundant. This patch removes 
  these redundant checks and also makes a few tiny whitespace changes.
  
  Signed-off-by: Jesper Juhl [EMAIL PROTECTED]
 
 Applied, thanks.
 
You're welcome. I have a patch 90% done that makes the same change for all 
of drivers/usb/* want me to send that along or would you prefer I stick to 
just drivers/usb/core/* ?  One huge patch OK or would you prefer it split 
into one patch pr modified file?   
I can send the patch later tonight when I get home from work.

-- 
Jesper Juhl

-
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: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

2005-04-12 Thread Geert Uytterhoeven
On Tue, 12 Apr 2005, Petr Baudis wrote:
 Dear diary, on Tue, Apr 12, 2005 at 03:20:18AM CEST, I got a letter
 where Adam J. Richter [EMAIL PROTECTED] told me that...
  Dear diary, on Mon, Apr 11, 2005 at 05:46:38PM CEST, I got a letter
  where Adam J. Richter [EMAIL PROTECTED] told me that...
  ..snip..
   Graydon Hoare.  (By the way, I would prefer that git just punt to
   user level programs for diff and merge when all of the versions
   involved are different or at least have a very thin interface
   for extending the facility, because I would like to do some character
   based merge stuff.)
  ..snip..
  
  But this is what git already does. I agree it could do it even better,
  by checking environment variables for the appropriate tools (then you
  could use that to pass diff e.g. -p etc.).
  
  This message from Linus seemed to imply that git was going to get
  its own 3-way merge code:
  
  | Then the bad news: the merge algorithm is going to suck. It's going to be
  | just plain 3-way merge, the same RCS/CVS thing you've seen before. With no
  | understanding of renames etc. I'll try to find the best parent to base the
  | merge off of, although early testers may have to tell the piece of crud
  | what the most recent common parent was.
 
 Well, from what I can read it says just plain 3-way merge, the same
 RCS/CVS thing you've seen before. :-)
 
 Basically, when you look at merge(1) :
 
 SYNOPSIS
merge [ options ] file1 file2 file3
 DESCRIPTION
merge  incorporates  all  changes that lead from file2 to file3
 into file1.
 
 The only big problem is how to guess the best file2 when you give it
 file3 and file1.

That's either the point just before you started modifying the file, or your
last merge point. Sounds simple, but if your SCM system doesn't track merges,
your SOL...

Gr{oetje,eeting}s,

Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say programmer or something like that.
-- Linus Torvalds
-
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: Prototype error in linux/debugfs.h

2005-04-12 Thread Greg KH
On Tue, Apr 12, 2005 at 01:35:51AM -0700, Chen, Kenneth W wrote:
 To lazy to write a patch, the inline debugfs function declaration
 for the following three functions disagree between CONFIG_DEBUG_FS
 and !CONFIG_DEBUG_FS
 
 4th argument mismatch, looks like an obvious copy-n-paste error.
 u16, u32, and u32?

Already fixed in the -mm tree, patch is queued to be sent to Linus, once
he starts accepting patches again.

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: kernel panic - not syncing: Fatal exception in interupt

2005-04-12 Thread [EMAIL PROTECTED]
The machine crashed again twice today.  I have vga=791 so i caugh a bit more
of the crash.  i enabled serial redirection in the bios so i'm hoping to
catch the full dump next time.


The first screen shot is with the old resolution so didnt catch much more
here...
http://www.unix-scripts.com/shaun/host1-2005-04-12-01.png

But this screen shot got a nice chunk and looks a bit diffrent.
http://www.unix-scripts.com/shaun/host1-2005-04-12-02.png


Still looks like there is alot more that i'm missing but by glancing at that
dump, to me it definitly seams like bridging is causing this.  I'm going to
post this to the ebtables lists tomarrow also.

Best Regards,

Shaun R.


- Original Message -
From: Zwane Mwaikambo [EMAIL PROTECTED]
To: [EMAIL PROTECTED] [EMAIL PROTECTED]
Cc: linux-kernel@vger.kernel.org
Sent: Thursday, April 07, 2005 1:09 AM
Subject: Re: kernel panic - not syncing: Fatal exception in interupt


 On Wed, 6 Apr 2005, [EMAIL PROTECTED] wrote:

  No, sorry, i have to run with bridging support other wise the
guests(UML's)
  wont be able to communicate with the outside world.

 Ok in that case, can you connect a serial console so that you can capture
 the entire output?

 Thanks,
 Zwane



-
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: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

2005-04-12 Thread Peter Baumann
On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
 Peter Baumann [EMAIL PROTECTED] wrote:
 
  
  I'm hitting an annoying bug in kernel 2.6.11.5
  
  Every time I _reboot_ (warmstart) my pc my two network cards won't get
  recognized any longer.
 
  Following error message appears on my screen:
 
  PCI: Enabling device :00:0b.0 ( - 0003)
  ACPI: PCI interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 19
  3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
  :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
  PCI: Setting latency timer of device :00:0b.0 to 64
  *** EEPROM MAC address is invalid.
  3c59x: vortex_probe1 fails.  Returns -22
  3c59x: probe of :00:0b.0 failed with error -22
  PCI: Enabling device :00:0d.0 ( - 0003)
  ACPI: PCI interrupt :00:0d.0[A] - GSI 19 (level, low) - IRQ 19
  :00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19
  PCI: Setting latency timer of device :00:0d.0 to 64
  *** EEPROM MAC address is invalid.
  3c59x: vortex_probe1 fails.  Returns -22
  3c59x: probe of :00:0d.0 failed with error -22
 
  This doesn't happen with older kernels (especially with 2.6.10) and so
  I've done a binary search and narrowed it down to 2.6.11-rc5 where it
  first hits me.
 
  My config, lspci output and the dmesg output of the working and non-working
  version can be found at [1]
 
  Feel free to ask if any information is missing or if I am supposed to try
  a patch.

 Thanks for doing the bsearch - it helps.

 There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.

 The only PCI change I see is

 --- drivers/pci/pci.c   22 Jan 2005 03:20:37 -  1.71
 +++ drivers/pci/pci.c   24 Feb 2005 18:02:37 -  1.72
 @@ -268,7 +268,7 @@
 return -EIO;

 pci_read_config_word(dev,pm + PCI_PM_PMC,pmc);
 -   if ((pmc  PCI_PM_CAP_VER_MASK) != 2) {
 +   if ((pmc  PCI_PM_CAP_VER_MASK)  2) {
 printk(KERN_DEBUG
PCI: %s has unsupported PM cap regs version (%u)\n,
dev-slot_name, pmc  PCI_PM_CAP_VER_MASK);

 and you're not getting that message (are you?)


I have still the problem described above with 2.6.12-rc2-mm2 and
reverting the above patch solved it. And yes, now I get many of those

PCI: :00:0b.0 has unsupported PM cap regs version (1)
PCI: :00:0d.0 has unsupported PM cap regs version (1)
PCI: :00:09.0 has unsupported PM cap regs version (1)

messages.

Greetings,
  Peter Baumann
-
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] Keys: Use RCU to manage session keyring pointer

2005-04-12 Thread David Howells
Paul E. McKenney [EMAIL PROTECTED] wrote:

  spin_lock_irqsave(tsk-sighand-siglock, flags);
  -   old = tsk-signal-session_keyring;
  -   tsk-signal-session_keyring = keyring;
  +   old = rcu_dereference(tsk-signal-session_keyring);
 
 I don't understand why rcu_dereference() is needed in this case.
 Since we are holding the lock, it should not be possible for
 this to change, right?  Or am I missing something?  (Quite possible,
 am not all that familiar with this code.)

Erm... you're right. I stuck the rcu_dereference() in then added the locks
back in when I realised I still needed them.

  +   synchronize_kernel();
 
 This would want to become synchronize_rcu().

I think the deprecation happened since I wrote my patch.

  +   if (tsk-signal-session_keyring) {
  +   rcu_read_lock();
  +   key = keyring_search_aux(
  +   rcu_dereference(tsk-signal-session_keyring),
  +   type, description, match);
  +   rcu_read_unlock();
  +   }
  +   else {
  +   key = keyring_search_aux(tsk-user-session_keyring,
  +type, description, match);
 
 This one is constant, right?  If not, I don't understand the locking design.

Which one? tsk-user-session_keyring is, tsk-signal-session_keyring is not.

Thanks for the review.

David
-
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: [Bug] invalid mac address after rebooting (2.6.12-rc2-mm2)

2005-04-12 Thread Andrew Morton
Peter Baumann [EMAIL PROTECTED] wrote:

 On Wed, Mar 23, 2005 at 06:52:25PM -0800, Andrew Morton wrote:
  Peter Baumann [EMAIL PROTECTED] wrote:
  
   
   I'm hitting an annoying bug in kernel 2.6.11.5
   
   Every time I _reboot_ (warmstart) my pc my two network cards won't get
   recognized any longer.
  
   Following error message appears on my screen:
  
   PCI: Enabling device :00:0b.0 ( - 0003)
   ACPI: PCI interrupt :00:0b.0[A] - GSI 19 (level, low) - IRQ 19
   3c59x: Donald Becker and others. www.scyld.com/network/vortex.html
   :00:0b.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1000. Vers LK1.1.19
   PCI: Setting latency timer of device :00:0b.0 to 64
   *** EEPROM MAC address is invalid.
   3c59x: vortex_probe1 fails.  Returns -22
   3c59x: probe of :00:0b.0 failed with error -22
   PCI: Enabling device :00:0d.0 ( - 0003)
   ACPI: PCI interrupt :00:0d.0[A] - GSI 19 (level, low) - IRQ 19
   :00:0d.0: 3Com PCI 3c905B Cyclone 100baseTx at 0x1080. Vers LK1.1.19
   PCI: Setting latency timer of device :00:0d.0 to 64
   *** EEPROM MAC address is invalid.
   3c59x: vortex_probe1 fails.  Returns -22
   3c59x: probe of :00:0d.0 failed with error -22
  
   This doesn't happen with older kernels (especially with 2.6.10) and so
   I've done a binary search and narrowed it down to 2.6.11-rc5 where it
   first hits me.
  
   My config, lspci output and the dmesg output of the working and 
   non-working
   version can be found at [1]
  
   Feel free to ask if any information is missing or if I am supposed to try
   a patch.
 
  Thanks for doing the bsearch - it helps.
 
  There were no driver changes between 2.6.11-rc4 and 2.6.11-rc5.
 
  The only PCI change I see is
 
  --- drivers/pci/pci.c   22 Jan 2005 03:20:37 -  1.71
  +++ drivers/pci/pci.c   24 Feb 2005 18:02:37 -  1.72
  @@ -268,7 +268,7 @@
  return -EIO;
 
  pci_read_config_word(dev,pm + PCI_PM_PMC,pmc);
  -   if ((pmc  PCI_PM_CAP_VER_MASK) != 2) {
  +   if ((pmc  PCI_PM_CAP_VER_MASK)  2) {
  printk(KERN_DEBUG
 PCI: %s has unsupported PM cap regs version (%u)\n,
 dev-slot_name, pmc  PCI_PM_CAP_VER_MASK);
 
  and you're not getting that message (are you?)
 
 
 I have still the problem described above with 2.6.12-rc2-mm2 and
 reverting the above patch solved it. And yes, now I get many of those
 
 PCI: :00:0b.0 has unsupported PM cap regs version (1)
 PCI: :00:0d.0 has unsupported PM cap regs version (1)
 PCI: :00:09.0 has unsupported PM cap regs version (1)
 
 messages.
 

Yes, we need to work out what's going on here.

Daniel?


-
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] FUSE permission modell (Was: fuse review bits)

2005-04-12 Thread Bodo Eggert [EMAIL PROTECTED]
Jamie Lokier [EMAIL PROTECTED] wrote:
 Miklos Szeredi wrote:

   4) Access should not be further restricted for the owner of the
  mount, even if permission bits, uid or gid would suggest
  otherwise
 
 Why?  Surely you want to prevent writing to files which don't have the
 writable bit set?  A filesystem may also create append-only files -
 and all users including the mount owner should be bound by that.

That will depend on the situation. If the user is mounting a tgz owned
by himself, FUSE should default to being a convenient hex-editor.

   5) As much of the available information should be exported via the
  filesystem as possible
 
 This is the root of the conflict.  You are trying to overload the
 permission bits and uid/gid to mean something different than they
 normally do.
 
 While it's convenient to see some remote information such as the
 uid/gid in a tar file, are you sure it's a good idea to break the unix
 permissions model - which will break some programs?  (For example, try
 editing a file with the broken semantics in an editor which checks the
 uid/gid of the file against the current user).

The editor will try to keep the original permissions, and saving will be
less effective.

   1) Only allow mount over a directory for which the user has write
  access (and is not sticky)
 
 Seems good - but why not sticky?  Mounting a user filesystem in
 /tmp/user-xxx/my-mount-point seems not unreasonable - provided the
 administrator can delete the directory (which is possible with
 detachable mount points).

I once mounted a filesystem in ~/tmp after forgetting about it being a
symlink to /tmp/$me/tmp, and I had to promise never to do that again.
Ng zvqavtug, gur pyrnahc-grzc-fpevcg xvpxrq va.

   5) The filesystem daemon is free to fill in all file attributes to
  any (sane) value, and the kernel won't modify these.
 
 Dangerous, because an administrative program might actually trust the
 attributes to mean what they normally mean in the unix permissions model.

The same risk applies to smbmounted file systems.

Sane daemons will do no check besides matching the owner of a file in the
user's home against the expected UID and checking the permission mask,
since you can't trust users not to mess with files in directories they own.
The best they can do should be shoothing their own feet.

(If the user doesn't own the directory, FUSE shouldn't mount.)
-- 
Top 100 things you don't want the sysadmin to say:
80. I cleaned up the root partition and now there's LOTS of free space.

Friß, Spammer:[EMAIL PROTECTED]@whitedoc.info
-
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: bdflush/rpciod high CPU utilization, profile does not make sense

2005-04-12 Thread Jakob Oestergaard
On Tue, Apr 12, 2005 at 11:03:29AM +1000, Greg Banks wrote:
 On Tue, 2005-04-12 at 01:42, Jakob Oestergaard wrote:
  Yes, as far as I know - the Broadcom Tigeon3 driver does not have the
  option of enabling/disabling RX polling (if we agree that is what we're
  talking about), but looking in tg3.c it seems that it *always*
  unconditionally uses NAPI...
 
 I've whined and moaned about this in the past, but for all its
 faults NAPI on tg3 doesn't lose packets.  It does cause a huge
 increase in irq cpu time on multiple fast CPUs.  What irq rate
 are you seeing?

Around 20.000 interrupts per second during the large write, on the IRQ
where eth0 is (this is not shared with anything else).

[sparrow:joe] $ cat /proc/interrupts
   CPU0   CPU1
...
169:3853488  412570512   IO-APIC-level  eth0
...


But still, guys, it is the *same* server with tg3 that runs well with a
2.4 client but poorly with a 2.6 client.

Maybe I'm just staring myself blind at this, but I can't see how a
general problem on the server (such as packet loss, latency or whatever)
would cause no problems with a 2.4 client but major problems with a 2.6
client.

-- 

 / jakob

-
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/6]init call cleanup

2005-04-12 Thread Rolf Eike Beer
Li Shaohua wrote:
 Trival patch for CPU hotplug. In CPU identify  part, only did cleaup for
 intel CPUs. Need do for other CPUs if they support S3 SMP.

 @@ -405,7 +405,7 @@ void __init init_bsp_APIC(void)
   apic_write_around(APIC_LVT1, value);
  }

 -void __init setup_local_APIC (void)
 +void __devinit setup_local_APIC (void)
  ^

  {
   unsigned long oldvalue, value, ver, maxlvt;


Please remove this space while you are at it.

 @@ -556,7 +556,7 @@ void __init early_cpu_init(void)
   * and IDT. We reload them nevertheless, this function acts as a
   * 'CPU state barrier', nothing should get across.
   */
 -void __init cpu_init (void)
 +void __devinit cpu_init (void)
  {
   int cpu = smp_processor_id();
   struct tss_struct * t = per_cpu(init_tss, cpu);

This one too.

Eike
-
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/


Exploit in 2.6 kernels

2005-04-12 Thread John M Collins
Please CC any reply to jmc AT xisl.com as I'm not subscribed - thanks

We had 5 machines broken into last night all but one with kernel 2.6.8
and found a binary krad-no-longer-private.c had  been downloaded

It contains the string:
 
k-rad.c - linux 2.6.* CPL 0 kernel exploit 
Discovered Jan 2005 by sd [EMAIL PROTECTED]

If you want to look at it, I've copied it (with mode set to 444 of
course) to www.xisl.com/hack

Hope that is helpful

-- 
John Collins Xi Software Ltd www.xisl.com Tel: +44 (0)1707 886110
(Direct) +44 (0)7799 113162 (Mobile)

-
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.12-rc1-mm3] [1/2] kprobes += function-return

2005-04-12 Thread Prasanna S Panchamukhi
   int register_returnprobe(struct rprobe *rp) {
  ...
  
   independent of kprobe and jprobe.
  ...
   
   make unregister exitprobes independent of kprobe/jprobe.
   
  ...
  
  1. When you call register_j/kprobe(), if kprobe-rp is non-null, it is
  assumed to point to a retprobe that will be registered and unregistered
  along with the kprobe.  (But this may make trouble for existing kprobes
  applications that didn't need to initialize the (nonexistent) rp
  pointer.  Probably not a huge deal.)
 
 I suppose if pairing of entry and return probes is important for a user,
 he/she can always do the following:
 
 static int ready; // 1 = everybody registered
   // 2 = everybody knows we're registered
 ...
   ready = 0;
   ... register_kprobe(kp)...
   ... register_retprobe(rp) ...
   /* instant XXX -- see below*/
   ready = 1;
 
 and in kp.pre_handler do
   if (!ready) {
   // return probe not registered yet
   return 0;
   }
   ready = 2;
   body of handler
 
 and in rp.handler do
   if (ready != 2) {
   // Probed function entered during instant XXX,
   // so kp.pre_handler didn't act on it.
   return 0;
   }
   body of handler
 
 Keeping a whole group of kprobes, jprobes, and retprobes in the starting
 gate pending a ready signal (e.g., for SystemTap) could probably be
 handled similarly.
 
 Unregistration shouldn't be an issue.  At any time you can have N active
 instances of the probed function, and have therefore recorded E entries
 and E-N returns.  Hien's code handles all that on retprobe
 deregistration, but the user's instrumentation should never count on #
 probed entries == # probed returns.
 

Jim,

You can do something like you explained above to handle the pairing issues.
You need to provide simple and compact interfaces for return probe feature.

Thanks
Prasanna
-- 

Prasanna S Panchamukhi
Linux Technology Center
India Software Labs, IBM Bangalore
Ph: 91-80-25044636
[EMAIL PROTECTED]
-
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: Kernel SCM saga.. (bk license?)

2005-04-12 Thread Catalin Marinas
Kedar Sovani [EMAIL PROTECTED] wrote:
 I was wondering if working on git, is in anyway, in violation of the
 Bitkeeper license, which states that you cannot work on any other SCM
 (SCM-like?) tool for x amount of time after using Bitkeeper ?

That's valid for the new BK license only which probably wasn't
accepted by Linus.

-- 
Catalin

-
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/


throttling kernel messages: KERNEL: assertion (flags MSG_PEEK) failed at net/ipv4/tcp.c (1282)

2005-04-12 Thread Ulrich Windl
Hi,

I'm affected by the (in)famous bug:
Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679
Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags  MSG_PEEK) failed at 
net/ipv4/tcp.c (1282)
Apr 12 07:03:02 mailgate kernel: recvmsg bug: copied D640F0D1 seq D640F679
Apr 12 07:03:02 mailgate kernel: KERNEL: assertion (flags  MSG_PEEK) failed at 
net/ipv4/tcp.c (1282)

(Kernel of SuSE Linux 9.2, 2.6.8-24.13-default #1 Fri Mar 18 10:19:42 UTC 2005 
i686 i686 i386 GNU/Linux)

The kernel spits out hundreds to thousand messages per second, making klogd and 
syslogd quite busy, and my messages file stopped growing at 2GB.

I'd suggest to enable throttling for this message, or trigger a panic/reboot, 
or 
maybe even fix the bug or message. ;-)

Regards,
Ulrich

-
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/6]suspend/resume SMP support

2005-04-12 Thread Pavel Machek
Hi!

 Using CPU hotplug to support suspend/resume SMP. Both S3 and S4 use
 disable/enable_nonboot_cpus API. The S4 part is based on Pavel's
 original S4 SMP patch.

The series looks good to me, but I was not yet able to actually try
it. Will try to do that in few hours.
Pavel

-- 
Boycott Kodak -- for their patent abuse against Java.
-
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: non-free firmware in kernel modules, aggregation and unclear copyright notice.

2005-04-12 Thread Bodo Eggert [EMAIL PROTECTED]
David Schwartz [EMAIL PROTECTED] wrote:

Copyright law only _explicitly_ grants a monopoly on preparation of
derivative works.  However, it is trivial, and overwhelmingly common,
for a copyright owner to grant a license to create a derivative work
that is conditional on how the licensee agrees to distribute (or not
distribute) the derivative work.
 
 This would, of course, only make sense if you *had* to agree to the license
 to *create* the derivative work. If you were able to create the derivative
 work under first sale or fair use rights, then the restrictions in the
 contract would not apply to you.

If you buy a W*nd*ws install CD, you can create a derived work, e.g. an image
of your installation, under the fair use rights (IANAL). Can you distribute
that image freely?
-- 
Friendly fire isn't. 

Friß, Spammer: [EMAIL PROTECTED] [EMAIL PROTECTED]
 [EMAIL PROTECTED] [EMAIL PROTECTED]
-
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: Re: Re: Re: GIT license (Re: Re: Re: Re: Re: [ANNOUNCE] git-pasky-0.1)

2005-04-12 Thread Petr Baudis
Dear diary, on Tue, Apr 12, 2005 at 10:39:40AM CEST, I got a letter
where Geert Uytterhoeven [EMAIL PROTECTED] told me that...
 On Tue, 12 Apr 2005, Petr Baudis wrote:
..snip..
  Basically, when you look at merge(1) :
  
  SYNOPSIS
 merge [ options ] file1 file2 file3
  DESCRIPTION
 merge  incorporates  all  changes that lead from file2 to file3
  into file1.
  
  The only big problem is how to guess the best file2 when you give it
  file3 and file1.
 
 That's either the point just before you started modifying the file, or your
 last merge point. Sounds simple, but if your SCM system doesn't track merges,
 your SOL...

Well, yes, but the last merge point search may not be so simple:

A --1---26---7
B\   `-4-.  /
C `-3-5'

Now, when at 7, your last merge point is not 1, but 2.

What I have proposed at the git mailing list was to have simple merging
tracking - merges/branch1/branch2 directory structure which would store
merges from branch2 to branch1. Then, when merging say to branch3, you
traverse all of them and if any of the branch1/* commits is newer than
branch3/*, you update it.

The disadvantage is that you now need to strictly use gitmerge.sh to do
the merges - Linus' revtree solution is nicer in the regard that it
works without any explicit bookkeeping, and tracks any merges properly
recorded with commit-file; it is more complex and more expensive,
though.

-- 
Petr Pasky Baudis
Stuff: http://pasky.or.cz/
98% of the time I am right. Why worry about the other 3%.
-
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: New SCM and commit list

2005-04-12 Thread Catalin Marinas
Linus Torvalds [EMAIL PROTECTED] wrote:
 So anything that got modified in just one tree obviously merges to that 
 version. Any file that got modified in two trees will end up just being 
 passed to the merge program. See man merge and man diff3. The merger 
 gets to fix up any conflicts by hand.

merge does a better job than diff3 since it can resolve the
conflicts caused by similar changes to a parent file (this is
available in both BK and GNU Arch). This is useful when you try to
merge 2 branches that both include a patch which is not under the
revision control. It also solves the conflicts caused by
cherry-picking changes (just need to find the last consecutive common
changeset as the common ancestor).

-- 
Catalin

-
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] genalloc for 2.6.12-rc-mm3

2005-04-12 Thread Jes Sorensen
Hi Andrew,

This patch provides the generic allocator needed for the ia64 mspec
driver. Any chance you could add it to the mm tree?

Thanks,
Jes

Generic allocator that can  be used by device driver to manage special
memory etc. in particular it's used to manage uncached memory on ia64
for the mspec driver. The allocator is based on the allocator from the
sym53c8xx_2 driver.

Signed-off-by: Jes Sorensen [EMAIL PROTECTED]


diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/include/linux/genalloc.h 
linux-2.6.12-rc2-mm3/include/linux/genalloc.h
--- linux-2.6.12-rc2-mm3-vanilla/include/linux/genalloc.h   1969-12-31 
16:00:00 -08:00
+++ linux-2.6.12-rc2-mm3/include/linux/genalloc.h   2005-04-12 02:14:06 
-07:00
@@ -0,0 +1,46 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This code is based on the buddy allocator found in the sym53c8xx_2
+ * driver, adapted for general purpose use.
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include linux/spinlock.h
+
+#define ALLOC_MIN_SHIFT5 /* 32 bytes minimum */
+/*
+ *  Link between free memory chunks of a given size.
+ */
+struct gen_pool_link {
+   struct gen_pool_link *next;
+};
+
+/*
+ *  Memory pool of a given kind.
+ *  Ideally, we want to use:
+ *  1) 1 pool for memory we donnot need to involve in DMA.
+ *  2) The same pool for controllers that require same DMA 
+ * constraints and features.
+ * The OS specific m_pool_id_t thing and the gen_pool_match() 
+ * method are expected to tell the driver about.
+ */
+struct gen_pool {
+   spinlock_t lock;
+   unsigned long (*get_new_chunk)(struct gen_pool *);
+   struct gen_pool *next;
+   struct gen_pool_link *h;
+   unsigned long private;
+   int max_chunk_shift;
+};
+
+unsigned long gen_pool_alloc(struct gen_pool *poolp, int size);
+void gen_pool_free(struct gen_pool *mp, unsigned long ptr, int size);
+struct gen_pool *alloc_gen_pool(int nr_chunks, int max_chunk_shift,
+   unsigned long (*fp)(struct gen_pool *),
+   unsigned long data);
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/init/main.c linux-2.6.12-rc2-mm3/init/main.c
--- linux-2.6.12-rc2-mm3-vanilla/init/main.c2005-04-12 02:09:05 -07:00
+++ linux-2.6.12-rc2-mm3/init/main.c2005-04-12 02:14:06 -07:00
@@ -78,6 +78,7 @@
 
 static int init(void *);
 
+extern void gen_pool_init(void);
 extern void init_IRQ(void);
 extern void sock_init(void);
 extern void fork_init(unsigned long);
@@ -489,6 +490,9 @@
 #endif
vfs_caches_init_early();
mem_init();
+#ifdef CONFIG_GENERIC_ALLOCATOR
+   gen_pool_init();
+#endif
kmem_cache_init();
numa_policy_init();
if (late_time_init)
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/lib/Kconfig linux-2.6.12-rc2-mm3/lib/Kconfig
--- linux-2.6.12-rc2-mm3-vanilla/lib/Kconfig2005-03-01 23:38:10 -08:00
+++ linux-2.6.12-rc2-mm3/lib/Kconfig2005-04-12 02:14:06 -07:00
@@ -40,6 +40,12 @@
tristate
 
 #
+# Generic allocator support is selected if needed
+#
+config GENERIC_ALLOCATOR
+   boolean
+
+#
 # reed solomon support is select'ed if needed
 #
 config REED_SOLOMON
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/lib/Makefile linux-2.6.12-rc2-mm3/lib/Makefile
--- linux-2.6.12-rc2-mm3-vanilla/lib/Makefile   2005-04-12 02:09:05 -07:00
+++ linux-2.6.12-rc2-mm3/lib/Makefile   2005-04-12 02:14:41 -07:00
@@ -29,6 +29,7 @@
 obj-$(CONFIG_CRC32)+= crc32.o
 obj-$(CONFIG_LIBCRC32C)+= libcrc32c.o
 obj-$(CONFIG_GENERIC_IOMAP) += iomap.o
+obj-$(CONFIG_GENERIC_ALLOCATOR) += genalloc.o
 
 obj-$(CONFIG_ZLIB_INFLATE) += zlib_inflate/
 obj-$(CONFIG_ZLIB_DEFLATE) += zlib_deflate/
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/lib/genalloc.c linux-2.6.12-rc2-mm3/lib/genalloc.c
--- linux-2.6.12-rc2-mm3-vanilla/lib/genalloc.c 1969-12-31 16:00:00 -08:00
+++ linux-2.6.12-rc2-mm3/lib/genalloc.c 2005-04-12 02:14:06 -07:00
@@ -0,0 +1,220 @@
+/*
+ * Basic general purpose allocator for managing special purpose memory
+ * not managed by the regular kmalloc/kfree interface.
+ * Uses for this includes on-device special memory, uncached memory
+ * etc.
+ *
+ * This code is based on the buddy allocator found in the sym53c8xx_2
+ * driver Copyright (C) 1999-2001  Gerard Roudier [EMAIL PROTECTED],
+ * and adapted for general purpose use.
+ *
+ * Copyright 2005 (C) Jes Sorensen [EMAIL PROTECTED]
+ *
+ * This source code is licensed under the GNU General Public License,
+ * Version 2.  See the file COPYING for more details.
+ */
+
+#include linux/config.h
+#include linux/module.h
+#include 

Re: [PATCH] ppc32: MV643XX ethernet is an option for Pegasos

2005-04-12 Thread Dale Farnsworth
On Tue, Apr 12, 2005 at 07:13:04AM +, Benjamin Herrenschmidt wrote:
 This patch allows Kconfig to build the MV643xx ethernet driver on
 Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing
 fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in
 there as the interrupt is shared if I understand things correctly.
 
 Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
 Signed-off-by: Fabio Massimo Di Nitto [EMAIL PROTECTED]

This looks identical to the patch I posted to netdev two weeks ago
as the first of 20 patches for the MV643xx ethernet driver.

See http://oss.sgi.com/archives/netdev/2005-03/msg01644.html and
http://oss.sgi.com/archives/netdev/2005-03/msg01642.html.

Thanks,
-Dale

 #! /bin/sh -e
 
 . $(dirname $0)/DPATCH
 
 @DPATCH@
 diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig 
 /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig
 --- linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig 2005-04-11 
 16:13:06.0 +0200
 +++ 
 /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/Kconfig
  2005-04-12 08:05:33.535955920 +0200
 @@ -2044,7 +2044,7 @@
  
  config MV643XX_ETH
   tristate MV-643XX Ethernet support
 - depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || 
 MOMENCO_OCELOT_3
 + depends on MOMENCO_OCELOT_C || MOMENCO_JAGUAR_ATX || MV64360 || 
 MOMENCO_OCELOT_3 || PPC_MULTIPLATFORM
   help
 This driver supports the gigabit Ethernet on the Marvell MV643XX
 chipset which is used in the Momenco Ocelot C and Jaguar ATX and
 diff -urNad linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c 
 /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c
 --- linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c   2005-04-07 
 14:57:16.0 +0200
 +++ 
 /usr/src/dpatchtemp/dpep.nYRoKc/linux-source-2.6.12-2.6.11.90/drivers/net/mv643xx_eth.c
2005-04-12 08:07:36.246301112 +0200
 @@ -668,7 +668,7 @@
   spin_lock_irq(mp-lock);
  
   err = request_irq(dev-irq, mv643xx_eth_int_handler,
 - SA_INTERRUPT | SA_SAMPLE_RANDOM, dev-name, dev);
 + SA_SHIRQ | SA_SAMPLE_RANDOM, dev-name, dev);
  
   if (err) {
   printk(KERN_ERR Can not assign IRQ number to MV643XX_eth%d\n,
 
-
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] mspec driver for 2.6.12-rc2-mm3

2005-04-12 Thread Jes Sorensen
Hi Andrew,

This patch includes the mspec driver for the ia64 port. Any chance
you'll take it for the mm tree?

It requires the genalloc patch posted earlier, but otherwise shouldn't
cause any harm.

Cheers,
Jes


Memory special driver for cached, uncached and 'fetchop' (SGI SN2 specific)
memory mappings, formerly known as fetchop. Mostly Used by parallel
appplictions. 

This patch relies on the PG_uncached support patch and the generic
allocator patch (genalloc).

Signed-off-by: Jes Sorensen [EMAIL PROTECTED]


diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/Kconfig 
linux-2.6.12-rc2-mm3/arch/ia64/Kconfig
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/Kconfig  2005-04-12 02:09:02 
-07:00
+++ linux-2.6.12-rc2-mm3/arch/ia64/Kconfig  2005-04-12 02:14:06 -07:00
@@ -217,6 +217,16 @@
  If you are compiling a kernel that will run under SGI's IA-64
  simulator (Medusa) then say Y, otherwise say N.
 
+config MSPEC
+   tristate Special Memory support
+   select GENERIC_ALLOCATOR
+   help
+ This driver allows for cached and uncached mappings of memory
+ to user processes. On SGI SN hardware it will also export the
+ special fetchop memory facility.
+ Fetchops are atomic memory operations that are implemented in the
+ memory controller on SGI SN hardware.
+
 config FORCE_MAX_ZONEORDER
int
default 18
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/configs/sn2_defconfig 
linux-2.6.12-rc2-mm3/arch/ia64/configs/sn2_defconfig
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/configs/sn2_defconfig
2005-04-12 02:09:02 -07:00
+++ linux-2.6.12-rc2-mm3/arch/ia64/configs/sn2_defconfig2005-04-12 
02:14:06 -07:00
@@ -82,6 +82,7 @@
 # CONFIG_IA64_CYCLONE is not set
 CONFIG_IOSAPIC=y
 CONFIG_IA64_SGI_SN_SIM=y
+CONFIG_MSPEC=m
 CONFIG_FORCE_MAX_ZONEORDER=18
 CONFIG_SMP=y
 CONFIG_NR_CPUS=512
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/defconfig 
linux-2.6.12-rc2-mm3/arch/ia64/defconfig
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/defconfig2005-04-12 02:09:02 
-07:00
+++ linux-2.6.12-rc2-mm3/arch/ia64/defconfig2005-04-12 02:14:06 -07:00
@@ -80,6 +80,7 @@
 CONFIG_ARCH_DISCONTIGMEM_ENABLE=y
 CONFIG_IA64_CYCLONE=y
 CONFIG_IOSAPIC=y
+CONFIG_MSPEC=m
 CONFIG_FORCE_MAX_ZONEORDER=18
 CONFIG_SMP=y
 CONFIG_NR_CPUS=512
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/kernel/Makefile 
linux-2.6.12-rc2-mm3/arch/ia64/kernel/Makefile
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/kernel/Makefile  2005-03-01 
23:38:33 -08:00
+++ linux-2.6.12-rc2-mm3/arch/ia64/kernel/Makefile  2005-04-12 02:14:06 
-07:00
@@ -20,6 +20,7 @@
 obj-$(CONFIG_PERFMON)  += perfmon_default_smpl.o
 obj-$(CONFIG_IA64_CYCLONE) += cyclone.o
 obj-$(CONFIG_IA64_MCA_RECOVERY)+= mca_recovery.o
+obj-$(CONFIG_MSPEC)+= mspec.o
 mca_recovery-y += mca_drv.o mca_drv_asm.o
 
 # The gate DSO image is built using a special linker script.
diff -urN -X /usr/people/jes/exclude-linux 
linux-2.6.12-rc2-mm3-vanilla/arch/ia64/kernel/mspec.c 
linux-2.6.12-rc2-mm3/arch/ia64/kernel/mspec.c
--- linux-2.6.12-rc2-mm3-vanilla/arch/ia64/kernel/mspec.c   1969-12-31 
16:00:00 -08:00
+++ linux-2.6.12-rc2-mm3/arch/ia64/kernel/mspec.c   2005-04-12 02:14:06 
-07:00
@@ -0,0 +1,799 @@
+/*
+ * Copyright (C) 2001-2005 Silicon Graphics, Inc.  All rights
+ * reserved.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms of version 2 of the GNU General Public License
+ * as published by the Free Software Foundation.
+ */
+
+/*
+ * SN Platform Special Memory (mspec) Support
+ *
+ * This driver exports the SN special memory (mspec) facility to user 
processes.
+ * There are three types of memory made available thru this driver:
+ * fetchops, uncached and cached.
+ *
+ * Fetchops are atomic memory operations that are implemented in the
+ * memory controller on SGI SN hardware.
+ *
+ * Uncached are used for memory write combining feature of the ia64
+ * cpu.
+ *
+ * Cached are used for areas of memory that are used as cached addresses
+ * on our partition and used as uncached addresses from other partitions.
+ * Due to a design constraint of the SN2 Shub, you can not have processors
+ * on the same FSB perform both a cached and uncached reference to the
+ * same cache line.  These special memory cached regions prevent the
+ * kernel from ever dropping in a TLB entry and therefore prevent the
+ * processor from ever speculating a cache line from this page.
+ */
+
+
+#include linux/config.h
+#include linux/types.h
+#include linux/kernel.h
+#include linux/module.h
+#include linux/init.h
+#include linux/errno.h
+#include linux/miscdevice.h
+#include linux/spinlock.h
+#include linux/mm.h
+#include linux/proc_fs.h
+#include linux/vmalloc.h
+#include linux/bitops.h
+#include 

Re: Call to atention about using hash functions as content indexers (SCM saga)

2005-04-12 Thread Barry K. Nathan
On Tue, Apr 12, 2005 at 12:51:39AM +0200, Petr Baudis wrote:
 Dear diary, on Tue, Apr 12, 2005 at 12:40:21AM CEST, I got a letter
 where Pedro Larroy [EMAIL PROTECTED] told me that...
[snip...]
 (iii) Your argument against comparing with the probability of a hardware
 error does not make sense to me.

I didn't understand it either, at first, but then I read this:

http://www.usenix.org/events/hotos03/tech/full_papers/henson/henson_html/node9.html

Whether this is serious enough to actually worry about is another
question...

-Barry K. Nathan [EMAIL PROTECTED]
-
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: Call to atention about using hash functions as content indexers (SCM saga)

2005-04-12 Thread Catalin Marinas
Magnus Damm [EMAIL PROTECTED] wrote:
 On 4/12/05, Petr Baudis [EMAIL PROTECTED] wrote:

 (iv) You fail to propose a better solution.

 I would feel safer with back end storage filenames based on email and
 mtime together with an optional hash lookup that turns collisions into
 worse performance. But that's just me.

Have a look at bazaar-ng (http://www.bazaar-ng.org/), they seem to do
this. I had a quick look at it and they also seem to store the full
files when they change (similar to git). It is also a bit ahead of git
(started earlier) and looks quite promising.

-- 
Catalin

-
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 encrypted swsusp 1/3] core functionality

2005-04-12 Thread Andreas Steinmetz
Rafael J. Wysocki wrote:
 Hi,
 
 On Monday, 11 of April 2005 23:08, Pavel Machek wrote:
 
Hi!

 
 ]--snip--[
 
@@ -130,6 +150,52 @@
 static unsigned short swapfile_used[MAX_SWAPFILES];
 static unsigned short root_swap;
 
+#ifdef CONFIG_SWSUSP_ENCRYPT
+static struct crypto_tfm *crypto_init(int mode)

I think it's better if this function returns an int error code and the
messages are printed where it's called from.  This way, the essential
part of the code would be easier to grasp (Pavel?).

Agreed. Actually I do not care where messages are printed, but
returning different code for different errors seems right.
 
 
 Hm.  You probably don't want suspend-related messages to be printed during
 resume (this function is called in two different places)? :-)
 
 Rafael
 
 

Will be changed.

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
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] zero disk pages used by swsusp on resume

2005-04-12 Thread Andreas Steinmetz
Rafael J. Wysocki wrote:
 Hi,
 
 On Monday, 11 of April 2005 19:02, Andreas Steinmetz wrote:
 
Rafael J. Wysocki wrote:

Hi,

On Monday, 11 of April 2005 12:37, Oliver Neukum wrote:


Am Sonntag, 10. April 2005 22:14 schrieb Pavel Machek:


Hi!



Oliver Neukum wrote:


What is the point in doing so after they've rested on the disk for ages?

The point is not physical access to the disk but data gathering after
resume or reboot.

After resume or reboot normal access control mechanisms will work
again. Those who can read a swap partition under normal circumstances
can also read /dev/kmem. It seems to me like you are putting an extra
lock on a window on the third floor while leaving the front door open.

Andreas is right, his patches are needed.

Currently, if your laptop is stolen after resume, they can still data
in swsusp image.

Zeroing the swsusp pages helps a lot here, because at least they are
not getting swsusp image data without heavy tools. [Or think root
compromise month after you used swsusp.]

Encrypting swsusp image is of course even better, because you don't
have to write large ammounts of zeros to your disks during resume ;-).

Not only is it better, it completely supercedes wiping the image.
Your laptop being stolen after resume is very much a corner case.
You suspend your laptop while you are not around, don't you?


Not necessarily.  Some people use suspend instead of shutdown. :-)

Now here's what I'm currently doing:

I do usually suspend instead of shutdown. The suspend partition is the
only unencrypted swap partition and it is disabled during regular
operation so it is not used for regular swapping. Except for a small
boot partition without any valuable data all other partitions are encrypted.

The key for dm-crypt setup is stored on an ide flash disk which isn't
inserted during travelling and which is transported separately.

Now let's imagine the laptop gets stolen by an average thief which is
the most common case.Thief needs to know if the laptop is working
because thief wants to sell it so thief powers on the laptop.

swsusp resumes and with the encryption patch renders the suspend image
worthless. The suspend/resume script immediately checks for the presence
of the ide flash disk with the correct key (match is done against the
in-kernel dm-crypt key). If the ide flash disk is not present or if
there is a key mismatch the script shuts the system immediately down, so
the in-kernel key is lost.

The only way for the thief now to access any data on the disk is to come
back and steal the flash disk, too.
 
 
 Yes.  And if you accidentally lose the flash disk, you are locked out of your
 own data. ;-)  The same happens if the data on the flash disk is lost (which
 occurs, from time to time).  You should be _really_ careful doing such things
 and IMO it's not to be tried by Joe User.

Right. But thats what this backup flash disk in some safe place is for.
No risk, no fun :-)

-- 
Andreas Steinmetz   SPAMmers use [EMAIL PROTECTED]
-
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] genalloc for 2.6.12-rc-mm3

2005-04-12 Thread Christoph Hellwig
On Tue, Apr 12, 2005 at 05:55:01AM -0400, Jes Sorensen wrote:
 Hi Andrew,
 
 This patch provides the generic allocator needed for the ia64 mspec
 driver. Any chance you could add it to the mm tree?
 
 Thanks,
 Jes
 
 Generic allocator that can  be used by device driver to manage special
 memory etc. in particular it's used to manage uncached memory on ia64
 for the mspec driver. The allocator is based on the allocator from the
 sym53c8xx_2 driver.

So maybe as an example that your driver is usefull and not just additional
bloat you could convert sym53c8xx_2 (and ncr53c8xxx) to use it?

 +/*
 + *  Memory pool of a given kind.
 + *  Ideally, we want to use:
 + *  1) 1 pool for memory we donnot need to involve in DMA.
 + *  2) The same pool for controllers that require same DMA 
 + * constraints and features.
 + * The OS specific m_pool_id_t thing and the gen_pool_match() 
 + * method are expected to tell the driver about.
 + */

these comments don't make any sense.

 +unsigned long gen_pool_alloc(struct gen_pool *poolp, int size);
 +void gen_pool_free(struct gen_pool *mp, unsigned long ptr, int size);
 +struct gen_pool *alloc_gen_pool(int nr_chunks, int max_chunk_shift,
 + unsigned long (*fp)(struct gen_pool *),
 + unsigned long data);

shouldn't there be a way to release the pool again?  Also we usuælly
call these _create/_destroy

 +#ifdef CONFIG_GENERIC_ALLOCATOR
 + gen_pool_init();
 +#endif

please avoid hardcoded initcalls.

 +config GENERIC_ALLOCATOR
 + boolean

bool

 +#include linux/config.h

not needed.

 +#include linux/module.h
 +#include linux/stddef.h
 +#include linux/kernel.h
 +#include linux/string.h
 +#include linux/slab.h
 +#include linux/init.h
 +#include linux/mm.h
 +#include linux/spinlock.h
 +#include linux/genalloc.h
 +
 +#include asm/page.h
 +#include asm/pal.h
 +
 +

 + /*
 +  * This is really an arbitrary limit, +10 is enough for
 +  * IA64_GRANULE_SHIFT.
 +  */

What's IA64_GRANULE_SHIFT and why do we care?

 +#if DEBUG
 + printk(KERN_DEBUG gen_pool_alloc: s %02x, i %i, h %p\n, s, i, h);
 +#endif

please avoid ifdefs in the middle of the code.  if you think keeping this
trivial debug code in is so valueable add a helper that gets defined away
for the non-debug case.

 +int __init gen_pool_init(void)
 +{
 + printk(KERN_INFO Generic memory pool allocator v1.0\n);
 + return 0;
 +}

no need to print a init message for a set of trivial library function

-
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] genalloc for 2.6.12-rc-mm3

2005-04-12 Thread Andrew Morton
[EMAIL PROTECTED] (Jes Sorensen) wrote:

 Hi Andrew,
 
 This patch provides the generic allocator needed for the ia64 mspec
 driver. Any chance you could add it to the mm tree?

spose so.  Glad it's Kconfigurable.

 +#ifdef CONFIG_GENERIC_ALLOCATOR
 + gen_pool_init();
 +#endif

Suggest you put a !CONFIG_GENERIC_ALLOCATOR stub in genpool.h, remove these
ifdefs.

 +# Generic allocator support is selected if needed
 +#
 +config GENERIC_ALLOCATOR
 + boolean

This will be turned on by some later patch, yes?

So will this code even be compiled in -mm?  I guess allyesconfig will
enable it.


 +
 +struct gen_pool *alloc_gen_pool(int nr_chunks, int max_chunk_shift,
 + unsigned long (*fp)(struct gen_pool *),
 + unsigned long data)

Some API kerneldocs would be useful.

 + /*
 +  * This is really an arbitrary limit, +10 is enough for
 +  * IA64_GRANULE_SHIFT.
 +  */
 + if ((max_chunk_shift  (PAGE_SHIFT + 10)) || 
 + ((max_chunk_shift  ALLOC_MIN_SHIFT)  max_chunk_shift))
 + return NULL;

Does this ia64ism restrict the usefulness of genalloc in any way, or is the
comment stale?

 + *  Simple power of two buddy-like generic allocator.
 + *  Provides naturally aligned memory chunks.
 + */
 +unsigned long gen_pool_alloc(struct gen_pool *poolp, int size)
 +{
 + int j, i, s, max_chunk_size;
 + unsigned long a, flags;
 + struct gen_pool_link *h = poolp-h;
 +
 + max_chunk_size = 1  poolp-max_chunk_shift;
 +
 + if (size  max_chunk_size)
 + return 0;
 +
 + i = 0;
 + s = (1  ALLOC_MIN_SHIFT);
 + while (size  s) {
 + s = 1;
 + i++;
 + }

roundup_pow_of_two()?

 +#if DEBUG
 + printk(KERN_DEBUG gen_pool_alloc: s %02x, i %i, h %p\n, s, i, h);
 +#endif

dprintk?

 + j = i;
 +
 + spin_lock_irqsave(poolp-lock, flags);
 + while (!h[j].next) {
 + if (s == max_chunk_size) {
 + struct gen_pool_link *ptr;
 + spin_unlock_irqrestore(poolp-lock, flags);
 + ptr = (struct gen_pool_link 
 *)poolp-get_new_chunk(poolp);

mabe get_new_chunk() should return void*, avoid the casting?

 +#if DEBUG
 + printk(KERN_DEBUG gen_pool_alloc() splitting i %i j %i 
 %x a %02lx\n, i, j, s, a);
 +#endif

You once sent me a rude email for putting a line 80 cols into acenic.c

 + return;
 +
 + i = 0;
 + while (size  s) {
 + s = 1;
 + i++;
 + }

roundup_pow_of_two()?

 + while (q-next  q-next != (struct gen_pool_link *)b) {
 + q = q-next;
 + }

braces?

 +int __init gen_pool_init(void)
 +{
 + printk(KERN_INFO Generic memory pool allocator v1.0\n);
 + return 0;

Do we need the printk?

 +
 +EXPORT_SYMBOL(alloc_gen_pool);
 +EXPORT_SYMBOL(gen_pool_alloc);
 +EXPORT_SYMBOL(gen_pool_free);

Current style is usually to put the exports at the line after the
function's closing brace.  I prefer that personally - it's easier to
locate.

-
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] mspec driver for 2.6.12-rc2-mm3

2005-04-12 Thread Andrew Morton
[EMAIL PROTECTED] (Jes Sorensen) wrote:

 + if (atomic_dec(vdata-refcnt) == 0) {

atomic_dec() normally returns void.  ia64's returns int, which is a bit
risky for cross-arch developemnt.

atomic_dec_and_test() would be more conventional.
-
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] mspec driver for 2.6.12-rc2-mm3

2005-04-12 Thread Andrew Morton
[EMAIL PROTECTED] (Jes Sorensen) wrote:

 + getpage:
  +/*
  + * Is this really correct?
  + */
  +page = alloc_pages(GFP_USER, 0);
  +spin_unlock(vdata-lock);
  +return page;
  +

sleeping allocation inside a spinlock.
-
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/


incoming

2005-04-12 Thread Andrew Morton

As the commits list probably isn't working at present I'll cc linux-kernel
on this lot.  Fairly cruel, sorry, but I don't like the idea of people not
knowing what's hitting the main tree.



This is the first live test of Linus's git-importing ability.  I'm about
to disappear for 1.5 weeks - hope we'll still have a kernel left when I
get back.

- As we're still a fair way from 2.6.12 and things are still backing up,
  it's a relatively large update.

- Various arch updates

- Big x86_64 update, as discussed

- decent-sized ppc32, ppc64 updates

- big infiniband update

- very nearly the last batch of u32-pm_message_t conversions.  Some
  other bits of this will be sitting out in subsystem trees - this is just
  the stuff which doesn't overlap.

- the important fixes from the md, nfs4 queues

- other random fixes and things we probably want to have in 2.6.12.

- I'd draw especial Linus attention to:

fix crash in entry.S restore_all and
pci enumeration on ixp2000: overflow in kernel/resource.c


-
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] mspec driver for 2.6.12-rc2-mm3

2005-04-12 Thread Andrew Morton
 +/*
 + * Walk the EFI memory map to pull out leftover pages in the lower
 + * memory regions which do not end up in the regular memory map and
 + * stick them into the uncached allocator
 + */
 +static void __init
 +mspec_walk_efi_memmap_uc (void)
 +{
 + void *efi_map_start, *efi_map_end, *p;
 + efi_memory_desc_t *md;
 + u64 efi_desc_size, start, end;
 +
 + efi_map_start = __va(ia64_boot_param-efi_memmap);
 + efi_map_end = efi_map_start + ia64_boot_param-efi_memmap_size;
 + efi_desc_size = ia64_boot_param-efi_memdesc_size;
 +
 + for (p = efi_map_start; p  efi_map_end; p += efi_desc_size) {
 + md = p;
 + if (md-attribute == EFI_MEMORY_UC) {
 + start = PAGE_ALIGN(md-phys_addr);
 + end = PAGE_ALIGN((md-phys_addr+(md-num_pages  
 EFI_PAGE_SHIFT))  PAGE_MASK);
 + if (mspec_build_memmap(start, end)  0)
 + return;
 + }
 + }
 +}
 +

Does this compile without CONFIG_EFI?

(It seems that ia64 Kconfig tries to turn on EFI always, but I thing
allnoconfig will turn it off)

 --- linux-2.6.12-rc2-mm3-vanilla/include/asm-ia64/sn/fetchop.h
 2005-03-01 23:38:12 -08:00
 +++ linux-2.6.12-rc2-mm3/include/asm-ia64/sn/fetchop.h1969-12-31 
 16:00:00 -08:00

Did you mean to remove fetchop.h?

 --- linux-2.6.12-rc2-mm3-vanilla/include/asm-ia64/sn/mspec.h  1969-12-31 
 16:00:00 -08:00
 +++ linux-2.6.12-rc2-mm3/include/asm-ia64/sn/mspec.h  2005-04-12 02:14:06 
 -07:00

I guess so.


-
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 011/198] Fix get_compat_sigevent()

2005-04-12 Thread akpm

From: David S. Miller [EMAIL PROTECTED]

I have no idea how a bug like this lasted so long.  Anyways, obvious
memset()'ing of incorrect pointer.

Signed-off-by: David S. Miller [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/kernel/compat.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN kernel/compat.c~fix-get_compat_sigevent kernel/compat.c
--- 25/kernel/compat.c~fix-get_compat_sigevent  2005-04-12 03:21:06.070214088 
-0700
+++ 25-akpm/kernel/compat.c 2005-04-12 03:21:06.074213480 -0700
@@ -640,7 +640,7 @@ long compat_sys_clock_nanosleep(clockid_
 int get_compat_sigevent(struct sigevent *event,
const struct compat_sigevent __user *u_event)
 {
-   memset(event, 0, sizeof(*event));
+   memset(event, 0, sizeof(*event));
return (!access_ok(VERIFY_READ, u_event, sizeof(*u_event)) ||
__get_user(event-sigev_value.sival_int,
u_event-sigev_value.sival_int) ||
_
-
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 008/198] re-export cancel_rearming_delayed_workqueue

2005-04-12 Thread akpm

From: James Bottomley [EMAIL PROTECTED]

This was unexported by Arjan because we have no current users.

However, during a conversion from tasklets to workqueues of the parisc led
functions, we ran across a case where this was needed.  In particular, the
open coded equivalent of cancel_rearming_delayed_workqueue was implemented
incorrectly, which is, I think, all the evidence necessary that this is a
useful API.

Signed-off-by: James Bottomley [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/include/linux/workqueue.h |2 ++
 25-akpm/kernel/workqueue.c|5 +++--
 2 files changed, 5 insertions(+), 2 deletions(-)

diff -puN include/linux/workqueue.h~re-export-cancel_rearming_delayed_workqueue 
include/linux/workqueue.h
--- 25/include/linux/workqueue.h~re-export-cancel_rearming_delayed_workqueue
2005-04-12 03:21:05.391317296 -0700
+++ 25-akpm/include/linux/workqueue.h   2005-04-12 03:21:05.396316536 -0700
@@ -71,6 +71,8 @@ extern int keventd_up(void);
 
 extern void init_workqueues(void);
 void cancel_rearming_delayed_work(struct work_struct *work);
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *,
+  struct work_struct *);
 
 /*
  * Kill off a pending schedule_delayed_work().  Note that the work callback
diff -puN kernel/workqueue.c~re-export-cancel_rearming_delayed_workqueue 
kernel/workqueue.c
--- 25/kernel/workqueue.c~re-export-cancel_rearming_delayed_workqueue   
2005-04-12 03:21:05.392317144 -0700
+++ 25-akpm/kernel/workqueue.c  2005-04-12 03:21:05.397316384 -0700
@@ -429,12 +429,13 @@ void flush_scheduled_work(void)
  * @wq:   the controlling workqueue structure
  * @work: the delayed work struct
  */
-static void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
-   struct work_struct *work)
+void cancel_rearming_delayed_workqueue(struct workqueue_struct *wq,
+  struct work_struct *work)
 {
while (!cancel_delayed_work(work))
flush_workqueue(wq);
 }
+EXPORT_SYMBOL(cancel_rearming_delayed_workqueue);
 
 /**
  * cancel_rearming_delayed_work - reliably kill off a delayed keventd
_
-
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 025/198] ppc32: fix bogosity in process-freezing code

2005-04-12 Thread akpm

From: Paul Mackerras [EMAIL PROTECTED]

The code that went into arch/ppc/kernel/signal.c recently to handle process
freezing seems to contain a dubious assumption: that a process that calls
do_signal when PF_FREEZE is set will have entered the kernel because of a
system call.  This patch removes that assumption.

Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/arch/ppc/kernel/signal.c |4 +---
 1 files changed, 1 insertion(+), 3 deletions(-)

diff -puN arch/ppc/kernel/signal.c~ppc32-fix-bogosity-in-process-freezing-code 
arch/ppc/kernel/signal.c
--- 25/arch/ppc/kernel/signal.c~ppc32-fix-bogosity-in-process-freezing-code 
2005-04-12 03:21:09.526688624 -0700
+++ 25-akpm/arch/ppc/kernel/signal.c2005-04-12 03:21:09.529688168 -0700
@@ -708,7 +708,6 @@ int do_signal(sigset_t *oldset, struct p
if (current-flags  PF_FREEZE) {
refrigerator(PF_FREEZE);
signr = 0;
-   ret = regs-gpr[3];
if (!signal_pending(current))
goto no_signal;
}
@@ -719,7 +718,7 @@ int do_signal(sigset_t *oldset, struct p
newsp = frame = 0;
 
signr = get_signal_to_deliver(info, ka, regs, NULL);
-
+ no_signal:
if (TRAP(regs) == 0x0C00/* System Call! */
 regs-ccr  0x1000   /* error signalled */
 ((ret = regs-gpr[3]) == ERESTARTSYS
@@ -735,7 +734,6 @@ int do_signal(sigset_t *oldset, struct p
regs-gpr[3] = EINTR;
/* note that the cr0.SO bit is already set */
} else {
-no_signal:
regs-nip -= 4; /* Back up  retry system call */
regs-result = 0;
regs-trap = 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 027/198] ppc32: improve timebase sync for SMP

2005-04-12 Thread akpm

From: Paul Mackerras [EMAIL PROTECTED]

Currently the procedure in the ppc32 kernel that synchronizes the timebase
registers across an SMP powermac system does so by setting both timebases
to zero.  That is OK at boot but causes problems if done later.  So that we
can do hotplug CPU on these machines, this patch changes the code so it
reads the timebase from one CPU and transfers the value to the other CPU. 
(Hotplug CPU is needed for sleep (aka suspend to RAM) to work.)

Signed-off-by: Paul Mackerras [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/arch/ppc/platforms/pmac_smp.c |   78 +++---
 1 files changed, 54 insertions(+), 24 deletions(-)

diff -puN arch/ppc/platforms/pmac_smp.c~ppc32-improve-timebase-sync-for-smp 
arch/ppc/platforms/pmac_smp.c
--- 25/arch/ppc/platforms/pmac_smp.c~ppc32-improve-timebase-sync-for-smp
2005-04-12 03:21:09.950624176 -0700
+++ 25-akpm/arch/ppc/platforms/pmac_smp.c   2005-04-12 03:21:09.954623568 
-0700
@@ -116,6 +116,8 @@ static unsigned int core99_tb_gpio;
 
 /* Sync flag for HW tb sync */
 static volatile int sec_tb_reset = 0;
+static unsigned int pri_tb_hi, pri_tb_lo;
+static unsigned int pri_tb_stamp;
 
 static void __init core99_init_caches(int cpu)
 {
@@ -453,7 +455,7 @@ static int __init smp_core99_probe(void)
 #endif
struct device_node *cpus, *firstcpu;
int i, ncpus = 0, boot_cpu = -1;
-   u32 *tbprop;
+   u32 *tbprop = NULL;
 
if (ppc_md.progress) ppc_md.progress(smp_core99_probe, 0x345);
cpus = firstcpu = find_type_devices(cpu);
@@ -576,46 +578,74 @@ static void __init smp_core99_setup_cpu(
}
 }
 
-void __init smp_core99_take_timebase(void)
+/* not __init, called in sleep/wakeup code */
+void smp_core99_take_timebase(void)
 {
-   /* Secondary processor takes the timebase by freezing
-* it, resetting its local TB and telling CPU 0 to go on
-*/
-   pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, core99_tb_gpio, 4);
-   pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, core99_tb_gpio, 0);
+   unsigned long flags;
+
+   /* tell the primary we're here */
+   sec_tb_reset = 1;
mb();
 
-   set_dec(tb_ticks_per_jiffy);
-   set_tb(0, 0);
-   last_jiffy_stamp(smp_processor_id()) = 0;
+   /* wait for the primary to set pri_tb_hi/lo */
+   while (sec_tb_reset  2)
+   mb();
 
+   /* set our stuff the same as the primary */
+   local_irq_save(flags);
+   set_dec(1);
+   set_tb(pri_tb_hi, pri_tb_lo);
+   last_jiffy_stamp(smp_processor_id()) = pri_tb_stamp;
+   mb();
+
+   /* tell the primary we're done */
+   sec_tb_reset = 0;
mb();
-   sec_tb_reset = 1;
+   local_irq_restore(flags);
 }
 
-void __init smp_core99_give_timebase(void)
+/* not __init, called in sleep/wakeup code */
+void smp_core99_give_timebase(void)
 {
+   unsigned long flags;
unsigned int t;
 
-   /* Primary processor waits for secondary to have frozen
-* the timebase, resets local TB, and kick timebase again
-*/
-   /* wait for the secondary to have reset its TB before proceeding */
-   for (t = 1000; t  0  !sec_tb_reset; --t)
-   udelay(1000);
-   if (t == 0)
+   /* wait for the secondary to be in take_timebase */
+   for (t = 10; t  0  !sec_tb_reset; --t)
+   udelay(10);
+   if (!sec_tb_reset) {
printk(KERN_WARNING Timeout waiting sync on second CPU\n);
+   return;
+   }
 
-   set_dec(tb_ticks_per_jiffy);
-   set_tb(0, 0);
-   last_jiffy_stamp(smp_processor_id()) = 0;
+   /* freeze the timebase and read it */
+   /* disable interrupts so the timebase is disabled for the
+  shortest possible time */
+   local_irq_save(flags);
+   pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, core99_tb_gpio, 4);
+   pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, core99_tb_gpio, 0);
+   mb();
+   pri_tb_hi = get_tbu();
+   pri_tb_lo = get_tbl();
+   pri_tb_stamp = last_jiffy_stamp(smp_processor_id());
mb();
 
+   /* tell the secondary we're ready */
+   sec_tb_reset = 2;
+   mb();
+
+   /* wait for the secondary to have taken it */
+   for (t = 10; t  0  sec_tb_reset; --t)
+   udelay(10);
+   if (sec_tb_reset)
+   printk(KERN_WARNING Timeout waiting sync(2) on second CPU\n);
+   else
+   smp_tb_synchronized = 1;
+
/* Now, restart the timebase by leaving the GPIO to an open collector */
pmac_call_feature(PMAC_FTR_WRITE_GPIO, NULL, core99_tb_gpio, 0);
 pmac_call_feature(PMAC_FTR_READ_GPIO, NULL, core99_tb_gpio, 0);
-
-   smp_tb_synchronized = 1;
+   local_irq_restore(flags);
 }
 
 
_
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL 

[patch 175/198] IB/mthca: implement RDMA/atomic operations for mem-free mode

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

Add code to support RDMA and atomic send work requests in mem-free mode.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_qp.c |   47 +
 1 files changed, 47 insertions(+)

diff -puN 
drivers/infiniband/hw/mthca/mthca_qp.c~ib-mthca-implement-rdma-atomic-operations-for-mem-free-mode
 drivers/infiniband/hw/mthca/mthca_qp.c
--- 
25/drivers/infiniband/hw/mthca/mthca_qp.c~ib-mthca-implement-rdma-atomic-operations-for-mem-free-mode
   2005-04-12 03:21:45.105279856 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_qp.c  2005-04-12 
03:21:45.109279248 -0700
@@ -1775,6 +1775,53 @@ int mthca_arbel_post_send(struct ib_qp *
size = sizeof (struct mthca_next_seg) / 16;
 
switch (qp-transport) {
+   case RC:
+   switch (wr-opcode) {
+   case IB_WR_ATOMIC_CMP_AND_SWP:
+   case IB_WR_ATOMIC_FETCH_AND_ADD:
+   ((struct mthca_raddr_seg *) wqe)-raddr =
+   cpu_to_be64(wr-wr.atomic.remote_addr);
+   ((struct mthca_raddr_seg *) wqe)-rkey =
+   cpu_to_be32(wr-wr.atomic.rkey);
+   ((struct mthca_raddr_seg *) wqe)-reserved = 0;
+
+   wqe += sizeof (struct mthca_raddr_seg);
+
+   if (wr-opcode == IB_WR_ATOMIC_CMP_AND_SWP) {
+   ((struct mthca_atomic_seg *) 
wqe)-swap_add =
+   cpu_to_be64(wr-wr.atomic.swap);
+   ((struct mthca_atomic_seg *) 
wqe)-compare =
+   
cpu_to_be64(wr-wr.atomic.compare_add);
+   } else {
+   ((struct mthca_atomic_seg *) 
wqe)-swap_add =
+   
cpu_to_be64(wr-wr.atomic.compare_add);
+   ((struct mthca_atomic_seg *) 
wqe)-compare = 0;
+   }
+
+   wqe += sizeof (struct mthca_atomic_seg);
+   size += sizeof (struct mthca_raddr_seg) / 16 +
+   sizeof (struct mthca_atomic_seg);
+   break;
+
+   case IB_WR_RDMA_WRITE:
+   case IB_WR_RDMA_WRITE_WITH_IMM:
+   case IB_WR_RDMA_READ:
+   ((struct mthca_raddr_seg *) wqe)-raddr =
+   cpu_to_be64(wr-wr.rdma.remote_addr);
+   ((struct mthca_raddr_seg *) wqe)-rkey =
+   cpu_to_be32(wr-wr.rdma.rkey);
+   ((struct mthca_raddr_seg *) wqe)-reserved = 0;
+   wqe += sizeof (struct mthca_raddr_seg);
+   size += sizeof (struct mthca_raddr_seg) / 16;
+   break;
+
+   default:
+   /* No extra segments required for sends */
+   break;
+   }
+
+   break;
+
case UD:
memcpy(((struct mthca_arbel_ud_seg *) wqe)-av,
   to_mah(wr-wr.ud.ah)-av, MTHCA_AV_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 166/198] IB/mthca: fix posting sends with immediate data

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

When posting a work request with immediate data, put the immediate data in the
immediate data field of the hardware's work request (rather than overwriting
the flags field).

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_qp.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_qp.c~ib-mthca-fix-posting-sends-with-immediate-data
 drivers/infiniband/hw/mthca/mthca_qp.c
--- 
25/drivers/infiniband/hw/mthca/mthca_qp.c~ib-mthca-fix-posting-sends-with-immediate-data
2005-04-12 03:21:43.055591456 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_qp.c  2005-04-12 
03:21:43.059590848 -0700
@@ -1465,7 +1465,7 @@ int mthca_tavor_post_send(struct ib_qp *
cpu_to_be32(1);
if (wr-opcode == IB_WR_SEND_WITH_IMM ||
wr-opcode == IB_WR_RDMA_WRITE_WITH_IMM)
-   ((struct mthca_next_seg *) wqe)-flags = wr-imm_data;
+   ((struct mthca_next_seg *) wqe)-imm = wr-imm_data;
 
wqe += sizeof (struct mthca_next_seg);
size = sizeof (struct mthca_next_seg) / 16;
@@ -1769,7 +1769,7 @@ int mthca_arbel_post_send(struct ib_qp *
cpu_to_be32(1);
if (wr-opcode == IB_WR_SEND_WITH_IMM ||
wr-opcode == IB_WR_RDMA_WRITE_WITH_IMM)
-   ((struct mthca_next_seg *) wqe)-flags = wr-imm_data;
+   ((struct mthca_next_seg *) wqe)-imm = wr-imm_data;
 
wqe += sizeof (struct mthca_next_seg);
size = sizeof (struct mthca_next_seg) / 16;
_
-
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 163/198] IB/mthca: map MPT/MTT context in mem-free mode

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

In mem-free mode, when allocating memory regions, make sure that the HCA has
context memory mapped to cover the virtual space used for the MPT and MTTs
being used.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_main.c|2 
 25-akpm/drivers/infiniband/hw/mthca/mthca_memfree.c |   32 
 25-akpm/drivers/infiniband/hw/mthca/mthca_memfree.h |4 +
 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c  |   79 +---
 4 files changed, 105 insertions(+), 12 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
 drivers/infiniband/hw/mthca/mthca_main.c
--- 
25/drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
   2005-04-12 03:21:42.388692840 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_main.c2005-04-12 
03:21:42.395691776 -0700
@@ -390,7 +390,7 @@ static int __devinit mthca_init_icm(stru
}
 
mdev-mr_table.mtt_table = mthca_alloc_icm_table(mdev, 
init_hca-mtt_base,
-init_hca-mtt_seg_sz,
+dev_lim-mtt_seg_sz,
 
mdev-limits.num_mtt_segs,
 
mdev-limits.reserved_mtts, 1);
if (!mdev-mr_table.mtt_table) {
diff -puN 
drivers/infiniband/hw/mthca/mthca_memfree.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
 drivers/infiniband/hw/mthca/mthca_memfree.c
--- 
25/drivers/infiniband/hw/mthca/mthca_memfree.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
2005-04-12 03:21:42.389692688 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_memfree.c 2005-04-12 
03:21:42.396691624 -0700
@@ -192,6 +192,38 @@ void mthca_table_put(struct mthca_dev *d
up(table-mutex);
 }
 
+int mthca_table_get_range(struct mthca_dev *dev, struct mthca_icm_table *table,
+ int start, int end)
+{
+   int inc = MTHCA_TABLE_CHUNK_SIZE / table-obj_size;
+   int i, err;
+
+   for (i = start; i = end; i += inc) {
+   err = mthca_table_get(dev, table, i);
+   if (err)
+   goto fail;
+   }
+
+   return 0;
+
+fail:
+   while (i  start) {
+   i -= inc;
+   mthca_table_put(dev, table, i);
+   }
+
+   return err;
+}
+
+void mthca_table_put_range(struct mthca_dev *dev, struct mthca_icm_table 
*table,
+  int start, int end)
+{
+   int i;
+
+   for (i = start; i = end; i += MTHCA_TABLE_CHUNK_SIZE / table-obj_size)
+   mthca_table_put(dev, table, i);
+}
+
 struct mthca_icm_table *mthca_alloc_icm_table(struct mthca_dev *dev,
  u64 virt, int obj_size,
  int nobj, int reserved,
diff -puN 
drivers/infiniband/hw/mthca/mthca_memfree.h~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
 drivers/infiniband/hw/mthca/mthca_memfree.h
--- 
25/drivers/infiniband/hw/mthca/mthca_memfree.h~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
2005-04-12 03:21:42.391692384 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_memfree.h 2005-04-12 
03:21:42.397691472 -0700
@@ -85,6 +85,10 @@ struct mthca_icm_table *mthca_alloc_icm_
 void mthca_free_icm_table(struct mthca_dev *dev, struct mthca_icm_table 
*table);
 int mthca_table_get(struct mthca_dev *dev, struct mthca_icm_table *table, int 
obj);
 void mthca_table_put(struct mthca_dev *dev, struct mthca_icm_table *table, int 
obj);
+int mthca_table_get_range(struct mthca_dev *dev, struct mthca_icm_table *table,
+ int start, int end);
+void mthca_table_put_range(struct mthca_dev *dev, struct mthca_icm_table 
*table,
+  int start, int end);
 
 static inline void mthca_icm_first(struct mthca_icm *icm,
   struct mthca_icm_iter *iter)
diff -puN 
drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
 drivers/infiniband/hw/mthca/mthca_mr.c
--- 
25/drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-map-mpt-mtt-context-in-mem-free-mode
 2005-04-12 03:21:42.392692232 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c  2005-04-12 
03:21:42.398691320 -0700
@@ -38,6 +38,7 @@
 
 #include mthca_dev.h
 #include mthca_cmd.h
+#include mthca_memfree.h
 
 /*
  * Must be packed because mtt_seg is 64 bits but only aligned to 32 bits.
@@ -71,7 +72,7 @@ struct mthca_mpt_entry {
  * through the bitmaps)
  */
 
-static u32 mthca_alloc_mtt(struct mthca_dev *dev, int order)
+static u32 __mthca_alloc_mtt(struct mthca_dev *dev, int order)
 {
int o;
int m;
@@ -105,7 +106,7 @@ static u32 mthca_alloc_mtt(struct mthca_
return seg;
 }
 
-static void 

[patch 164/198] IB/mthca: fill in more device query fields

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

Implement more of the device_query method in mthca.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.c  |2 +
 25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c |   22 +++
 2 files changed, 20 insertions(+), 4 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_cmd.c~ib-mthca-fill-in-more-device-query-fields
 drivers/infiniband/hw/mthca/mthca_cmd.c
--- 
25/drivers/infiniband/hw/mthca/mthca_cmd.c~ib-mthca-fill-in-more-device-query-fields
2005-04-12 03:21:42.632655752 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_cmd.c 2005-04-12 
03:21:42.638654840 -0700
@@ -987,6 +987,8 @@ int mthca_QUERY_DEV_LIM(struct mthca_dev
if (dev-hca_type == ARBEL_NATIVE) {
MTHCA_GET(field, outbox, QUERY_DEV_LIM_RSZ_SRQ_OFFSET);
dev_lim-hca.arbel.resize_srq = field  1;
+   MTHCA_GET(field, outbox, QUERY_DEV_LIM_MAX_SG_RQ_OFFSET);
+   dev_lim-max_sg = min_t(int, field, dev_lim-max_sg);
MTHCA_GET(size, outbox, QUERY_DEV_LIM_MTT_ENTRY_SZ_OFFSET);
dev_lim-mtt_seg_sz = size;
MTHCA_GET(size, outbox, QUERY_DEV_LIM_MPT_ENTRY_SZ_OFFSET);
diff -puN 
drivers/infiniband/hw/mthca/mthca_provider.c~ib-mthca-fill-in-more-device-query-fields
 drivers/infiniband/hw/mthca/mthca_provider.c
--- 
25/drivers/infiniband/hw/mthca/mthca_provider.c~ib-mthca-fill-in-more-device-query-fields
   2005-04-12 03:21:42.634655448 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c2005-04-12 
03:21:42.639654688 -0700
@@ -52,6 +52,8 @@ static int mthca_query_device(struct ib_
if (!in_mad || !out_mad)
goto out;
 
+   memset(props, 0, sizeof props);
+
props-fw_ver  = mdev-fw_ver;
 
memset(in_mad, 0, sizeof *in_mad);
@@ -71,14 +73,26 @@ static int mthca_query_device(struct ib_
goto out;
}
 
-   props-device_cap_flags = mdev-device_cap_flags;
-   props-vendor_id= be32_to_cpup((u32 *) (out_mad-data + 36)) 
+   props-device_cap_flags= mdev-device_cap_flags;
+   props-vendor_id   = be32_to_cpup((u32 *) (out_mad-data + 36)) 

0xff;
-   props-vendor_part_id   = be16_to_cpup((u16 *) (out_mad-data + 30));
-   props-hw_ver   = be16_to_cpup((u16 *) (out_mad-data + 32));
+   props-vendor_part_id  = be16_to_cpup((u16 *) (out_mad-data + 30));
+   props-hw_ver  = be16_to_cpup((u16 *) (out_mad-data + 32));
memcpy(props-sys_image_guid, out_mad-data +  4, 8);
memcpy(props-node_guid,  out_mad-data + 12, 8);
 
+   props-max_mr_size = ~0ull;
+   props-max_qp  = mdev-limits.num_qps - 
mdev-limits.reserved_qps;
+   props-max_qp_wr   = 0x;
+   props-max_sge = mdev-limits.max_sg;
+   props-max_cq  = mdev-limits.num_cqs - 
mdev-limits.reserved_cqs;
+   props-max_cqe = 0x;
+   props-max_mr  = mdev-limits.num_mpts - 
mdev-limits.reserved_mrws;
+   props-max_pd  = mdev-limits.num_pds - 
mdev-limits.reserved_pds;
+   props-max_qp_rd_atom  = 1  mdev-qp_table.rdb_shift;
+   props-max_qp_init_rd_atom = 1  mdev-qp_table.rdb_shift;
+   props-local_ca_ack_delay  = mdev-limits.local_ca_ack_delay;
+
err = 0;
  out:
kfree(in_mad);
_
-
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 183/198] IB/mthca: split MR key munging routines

2005-04-12 Thread akpm

From: Michael S. Tsirkin [EMAIL PROTECTED]

Split Tavor and Arbel/mem-free index-hw key munging routines, so that FMR
implementation can call correct implementation without testing HCA type (which
it already knows).

Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c |   28 +
 1 files changed, 24 insertions(+), 4 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-split-mr-key-munging-routines 
drivers/infiniband/hw/mthca/mthca_mr.c
--- 
25/drivers/infiniband/hw/mthca/mthca_mr.c~ib-mthca-split-mr-key-munging-routines
2005-04-12 03:21:46.923003520 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c  2005-04-12 
03:21:46.927002912 -0700
@@ -198,20 +198,40 @@ static void mthca_free_mtt(struct mthca_
  seg + (1  order) - 1);
 }
 
+static inline u32 tavor_hw_index_to_key(u32 ind)
+{
+   return ind;
+}
+
+static inline u32 tavor_key_to_hw_index(u32 key)
+{
+   return key;
+}
+
+static inline u32 arbel_hw_index_to_key(u32 ind)
+{
+   return (ind  24) | (ind  8);
+}
+
+static inline u32 arbel_key_to_hw_index(u32 key)
+{
+   return (key  24) | (key  8);
+}
+
 static inline u32 hw_index_to_key(struct mthca_dev *dev, u32 ind)
 {
if (dev-hca_type == ARBEL_NATIVE)
-   return (ind  24) | (ind  8);
+   return arbel_hw_index_to_key(ind);
else
-   return ind;
+   return tavor_hw_index_to_key(ind);
 }
 
 static inline u32 key_to_hw_index(struct mthca_dev *dev, u32 key)
 {
if (dev-hca_type == ARBEL_NATIVE)
-   return (key  24) | (key  8);
+   return arbel_key_to_hw_index(key);
else
-   return key;
+   return tavor_key_to_hw_index(key);
 }
 
 int mthca_mr_alloc_notrans(struct mthca_dev *dev, u32 pd,
_
-
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 scsi-misc-2.6 04/04] scsi: remove unnecessary scsi_wait_req_end_io()

2005-04-12 Thread Tejun Heo
04_scsi_reqfn_remove_wait_req_end_io.patch

As all requests are now terminated via scsi midlayer, we don't
need to set end_io for special reqs, remove it.

Note that scsi_kill_requests() still terminates requests using
blk layer.  The path is circular-ref workaround and soon to be
replaced, so ignore it for now.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 scsi_lib.c |   11 ---
 1 files changed, 11 deletions(-)

Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c  2005-04-12 
19:27:55.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c   2005-04-12 19:27:56.0 
+0900
@@ -260,16 +260,6 @@ static void scsi_wait_done(struct scsi_c
complete(req-waiting);
 }
 
-/* This is the end routine we get to if a command was never attached
- * to the request.  Simply complete the request without changing
- * rq_status; this will cause a DRIVER_ERROR. */
-static void scsi_wait_req_end_io(struct request *req)
-{
-   BUG_ON(!req-waiting);
-
-   complete(req-waiting);
-}
-
 void scsi_wait_req(struct scsi_request *sreq, const void *cmnd, void *buffer,
   unsigned bufflen, int timeout, int retries)
 {
@@ -277,7 +267,6 @@ void scsi_wait_req(struct scsi_request *

sreq-sr_request-waiting = wait;
sreq-sr_request-rq_status = RQ_SCSI_BUSY;
-   sreq-sr_request-end_io = scsi_wait_req_end_io;
scsi_do_req(sreq, cmnd, buffer, bufflen, scsi_wait_done,
timeout, retries);
wait_for_completion(wait);

-
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 165/198] IB/mthca: fix calculation of RDB shift

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

Fix calculation of rdb_shift by using original number of QPs, not
their slot in profile[] (which will be rearranged when we sort it).

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_profile.c |3 +--
 1 files changed, 1 insertion(+), 2 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_profile.c~ib-mthca-fix-calculation-of-rdb-shift
 drivers/infiniband/hw/mthca/mthca_profile.c
--- 
25/drivers/infiniband/hw/mthca/mthca_profile.c~ib-mthca-fix-calculation-of-rdb-shift
2005-04-12 03:21:42.849622768 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_profile.c 2005-04-12 
03:21:42.852622312 -0700
@@ -208,8 +208,7 @@ u64 mthca_make_profile(struct mthca_dev 
break;
case MTHCA_RES_RDB:
for (dev-qp_table.rdb_shift = 0;
-profile[MTHCA_RES_QP].num  
dev-qp_table.rdb_shift 
-profile[i].num;
+request-num_qp  dev-qp_table.rdb_shift  
profile[i].num;
 ++dev-qp_table.rdb_shift)
; /* nothing */
dev-qp_table.rdb_base= (u32) profile[i].start;
_
-
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 160/198] IB: Trivial FMR printk cleanup

2005-04-12 Thread akpm

From: Libor Michalek [EMAIL PROTECTED]

Add missing newline in printk.

Signed-off-by: Libor Michalek [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/core/fmr_pool.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/infiniband/core/fmr_pool.c~ib-trivial-fmr-printk-cleanup 
drivers/infiniband/core/fmr_pool.c
--- 25/drivers/infiniband/core/fmr_pool.c~ib-trivial-fmr-printk-cleanup 
2005-04-12 03:21:41.753789360 -0700
+++ 25-akpm/drivers/infiniband/core/fmr_pool.c  2005-04-12 03:21:41.756788904 
-0700
@@ -442,7 +442,7 @@ struct ib_pool_fmr *ib_fmr_pool_map_phys
list_add(fmr-list, pool-free_list);
spin_unlock_irqrestore(pool-pool_lock, flags);
 
-   printk(KERN_WARNING fmr_map returns %d,
+   printk(KERN_WARNING fmr_map returns %d\n,
   result);
 
return ERR_PTR(result);
_
-
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 162/198] IB: Remove incorrect comments

2005-04-12 Thread akpm

From: Hal Rosenstock [EMAIL PROTECTED]

Eliminate unneeded and misleading comments

Signed-off-by: Hal Rosenstock [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/core/agent.c |2 --
 25-akpm/drivers/infiniband/core/mad.c   |1 -
 2 files changed, 3 deletions(-)

diff -puN drivers/infiniband/core/agent.c~ib-remove-incorrect-comments 
drivers/infiniband/core/agent.c
--- 25/drivers/infiniband/core/agent.c~ib-remove-incorrect-comments 
2005-04-12 03:21:42.166726584 -0700
+++ 25-akpm/drivers/infiniband/core/agent.c 2005-04-12 03:21:42.171725824 
-0700
@@ -129,7 +129,6 @@ static int agent_mad_send(struct ib_mad_
goto out;
agent_send_wr-mad = mad_priv;
 
-   /* PCI mapping */
gather_list.addr = dma_map_single(mad_agent-device-dma_device,
  mad_priv-mad,
  sizeof(mad_priv-mad),
@@ -261,7 +260,6 @@ static void agent_send_handler(struct ib
list_del(agent_send_wr-send_list);
spin_unlock_irqrestore(port_priv-send_list_lock, flags);
 
-   /* Unmap PCI */
dma_unmap_single(mad_agent-device-dma_device,
 pci_unmap_addr(agent_send_wr, mapping),
 sizeof(agent_send_wr-mad-mad),
diff -puN drivers/infiniband/core/mad.c~ib-remove-incorrect-comments 
drivers/infiniband/core/mad.c
--- 25/drivers/infiniband/core/mad.c~ib-remove-incorrect-comments   
2005-04-12 03:21:42.168726280 -0700
+++ 25-akpm/drivers/infiniband/core/mad.c   2005-04-12 03:21:42.173725520 
-0700
@@ -2283,7 +2283,6 @@ static void cleanup_recv_queue(struct ib
/* Remove from posted receive MAD list */
list_del(mad_list-list);
 
-   /* Undo PCI mapping */
dma_unmap_single(qp_info-port_priv-device-dma_device,
 pci_unmap_addr(recv-header, mapping),
 sizeof(struct ib_mad_private) -
_
-
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 184/198] IB/mthca: add fast memory region implementation

2005-04-12 Thread akpm

From: Michael S. Tsirkin [EMAIL PROTECTED]

Implement fast memory regions (FMRs), where the driver writes directly into
the HCA's translation tables rather than requiring a firmware command.  For
Tavor, MTTs for FMR are separate from regular MTTs, and are reserved at driver
initialization.  This is done to limit the amount of virtual memory needed to
map the MTTs.  For Arbel, there's no such limitation, and all MTTs and MPTs
may be used for FMR or for regular MR.

Signed-off-by: Michael S. Tsirkin [EMAIL PROTECTED]
Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/hw/mthca/mthca_dev.h  |   25 +
 25-akpm/drivers/infiniband/hw/mthca/mthca_main.c |   17 
 25-akpm/drivers/infiniband/hw/mthca/mthca_mr.c   |  386 ++-
 25-akpm/drivers/infiniband/hw/mthca/mthca_profile.c  |   19 
 25-akpm/drivers/infiniband/hw/mthca/mthca_profile.h  |1 
 25-akpm/drivers/infiniband/hw/mthca/mthca_provider.c |   79 +++
 25-akpm/drivers/infiniband/hw/mthca/mthca_provider.h |   23 +
 7 files changed, 526 insertions(+), 24 deletions(-)

diff -puN 
drivers/infiniband/hw/mthca/mthca_dev.h~ib-mthca-add-fast-memory-region-implementation
 drivers/infiniband/hw/mthca/mthca_dev.h
--- 
25/drivers/infiniband/hw/mthca/mthca_dev.h~ib-mthca-add-fast-memory-region-implementation
   2005-04-12 03:21:47.136970992 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_dev.h 2005-04-12 
03:21:47.147969320 -0700
@@ -61,7 +61,8 @@ enum {
MTHCA_FLAG_SRQ= 1  2,
MTHCA_FLAG_MSI= 1  3,
MTHCA_FLAG_MSI_X  = 1  4,
-   MTHCA_FLAG_NO_LAM = 1  5
+   MTHCA_FLAG_NO_LAM = 1  5,
+   MTHCA_FLAG_FMR= 1  6
 };
 
 enum {
@@ -134,6 +135,7 @@ struct mthca_limits {
int  reserved_eqs;
int  num_mpts;
int  num_mtt_segs;
+   int  fmr_reserved_mtts;
int  reserved_mtts;
int  reserved_mrws;
int  reserved_uars;
@@ -178,10 +180,17 @@ struct mthca_buddy {
 
 struct mthca_mr_table {
struct mthca_alloc  mpt_alloc;
-   struct mthca_buddy  mtt_buddy;
+   struct mthca_buddy  mtt_buddy;
+   struct mthca_buddy *fmr_mtt_buddy;
u64 mtt_base;
+   u64 mpt_base;
struct mthca_icm_table *mtt_table;
struct mthca_icm_table *mpt_table;
+   struct {
+   void __iomem   *mpt_base;
+   void __iomem   *mtt_base;
+   struct mthca_buddy mtt_buddy;
+   } tavor_fmr;
 };
 
 struct mthca_eq_table {
@@ -380,7 +389,17 @@ int mthca_mr_alloc_phys(struct mthca_dev
u64 *buffer_list, int buffer_size_shift,
int list_len, u64 iova, u64 total_size,
u32 access, struct mthca_mr *mr);
-void mthca_free_mr(struct mthca_dev *dev, struct mthca_mr *mr);
+void mthca_free_mr(struct mthca_dev *dev,  struct mthca_mr *mr);
+
+int mthca_fmr_alloc(struct mthca_dev *dev, u32 pd,
+   u32 access, struct mthca_fmr *fmr);
+int mthca_tavor_map_phys_fmr(struct ib_fmr *ibfmr, u64 *page_list,
+int list_len, u64 iova);
+void mthca_tavor_fmr_unmap(struct mthca_dev *dev, struct mthca_fmr *fmr);
+int mthca_arbel_map_phys_fmr(struct ib_fmr *ibfmr, u64 *page_list,
+int list_len, u64 iova);
+void mthca_arbel_fmr_unmap(struct mthca_dev *dev, struct mthca_fmr *fmr);
+int mthca_free_fmr(struct mthca_dev *dev,  struct mthca_fmr *fmr);
 
 int mthca_map_eq_icm(struct mthca_dev *dev, u64 icm_virt);
 void mthca_unmap_eq_icm(struct mthca_dev *dev);
diff -puN 
drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-add-fast-memory-region-implementation
 drivers/infiniband/hw/mthca/mthca_main.c
--- 
25/drivers/infiniband/hw/mthca/mthca_main.c~ib-mthca-add-fast-memory-region-implementation
  2005-04-12 03:21:47.137970840 -0700
+++ 25-akpm/drivers/infiniband/hw/mthca/mthca_main.c2005-04-12 
03:21:47.148969168 -0700
@@ -73,14 +73,15 @@ static const char mthca_version[] __devi
DRV_VERSION  ( DRV_RELDATE )\n;
 
 static struct mthca_profile default_profile = {
-   .num_qp = 1  16,
-   .rdb_per_qp = 4,
-   .num_cq = 1  16,
-   .num_mcg= 1  13,
-   .num_mpt= 1  17,
-   .num_mtt= 1  20,
-   .num_udav   = 1  15,  /* Tavor only */
-   .uarc_size  = 1  18,  /* Arbel only */
+   .num_qp= 1  16,
+   .rdb_per_qp= 4,
+   .num_cq= 1  16,
+   .num_mcg   = 1  13,
+   .num_mpt   = 1  17,
+   .num_mtt   = 1  20,
+   .num_udav  = 1  15,   /* Tavor only */
+   .fmr_reserved_mtts = 1  18,   /* Tavor only */
+   .uarc_size = 1  18,   /* Arbel only */
 };
 
 static int __devinit mthca_tune_pci(struct mthca_dev *mdev)
diff -puN 

[patch 161/198] IB: Fix user MAD registrations with class 0

2005-04-12 Thread akpm

From: Roland Dreier [EMAIL PROTECTED]

Fix handling of MAD agent registrations with mgmt_class == 0.  In this case
ib_umad should pass a NULL registration request to the MAD core rather than a
request with mgmt_class set to 0.

Signed-off-by: Roland Dreier [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/infiniband/core/user_mad.c |   14 --
 1 files changed, 8 insertions(+), 6 deletions(-)

diff -puN 
drivers/infiniband/core/user_mad.c~ib-fix-user-mad-registrations-with-class-0 
drivers/infiniband/core/user_mad.c
--- 
25/drivers/infiniband/core/user_mad.c~ib-fix-user-mad-registrations-with-class-0
2005-04-12 03:21:41.957758352 -0700
+++ 25-akpm/drivers/infiniband/core/user_mad.c  2005-04-12 03:21:41.960757896 
-0700
@@ -389,15 +389,17 @@ static int ib_umad_reg_agent(struct ib_u
goto out;
 
 found:
-   req.mgmt_class = ureq.mgmt_class;
-   req.mgmt_class_version = ureq.mgmt_class_version;
-   memcpy(req.method_mask, ureq.method_mask, sizeof req.method_mask);
-   memcpy(req.oui, ureq.oui, sizeof req.oui);
+   if (ureq.mgmt_class) {
+   req.mgmt_class = ureq.mgmt_class;
+   req.mgmt_class_version = ureq.mgmt_class_version;
+   memcpy(req.method_mask, ureq.method_mask, sizeof 
req.method_mask);
+   memcpy(req.oui, ureq.oui, sizeof req.oui);
+   }
 
agent = ib_register_mad_agent(file-port-ib_dev, file-port-port_num,
  ureq.qpn ? IB_QPT_GSI : IB_QPT_SMI,
- req, 0, send_handler, recv_handler,
- file);
+ ureq.mgmt_class ? req : NULL,
+ 0, send_handler, recv_handler, file);
if (IS_ERR(agent)) {
ret = PTR_ERR(agent);
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/


[patch 150/198] reparent_to_init cleanup

2005-04-12 Thread akpm

From: Coywolf Qi Hunt [EMAIL PROTECTED]

This patch hides reparent_to_init().  reparent_to_init() should only be
called by daemonize().

Signed-off-by: Coywolf Qi Hunt [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/arch/i386/mach-voyager/voyager_thread.c |1 -
 25-akpm/include/linux/sched.h   |1 -
 25-akpm/kernel/exit.c   |2 +-
 3 files changed, 1 insertion(+), 3 deletions(-)

diff -puN arch/i386/mach-voyager/voyager_thread.c~reparent_to_init-cleanup 
arch/i386/mach-voyager/voyager_thread.c
--- 25/arch/i386/mach-voyager/voyager_thread.c~reparent_to_init-cleanup 
2005-04-12 03:21:39.578120112 -0700
+++ 25-akpm/arch/i386/mach-voyager/voyager_thread.c 2005-04-12 
03:21:39.583119352 -0700
@@ -126,7 +126,6 @@ thread(void *unused)
 
kvoyagerd_running = 1;
 
-   reparent_to_init();
daemonize(THREAD_NAME);
 
set_timeout = 0;
diff -puN include/linux/sched.h~reparent_to_init-cleanup include/linux/sched.h
--- 25/include/linux/sched.h~reparent_to_init-cleanup   2005-04-12 
03:21:39.579119960 -0700
+++ 25-akpm/include/linux/sched.h   2005-04-12 03:21:39.585119048 -0700
@@ -1021,7 +1021,6 @@ extern void exit_itimers(struct signal_s
 
 extern NORET_TYPE void do_group_exit(int);
 
-extern void reparent_to_init(void);
 extern void daemonize(const char *, ...);
 extern int allow_signal(int);
 extern int disallow_signal(int);
diff -puN kernel/exit.c~reparent_to_init-cleanup kernel/exit.c
--- 25/kernel/exit.c~reparent_to_init-cleanup   2005-04-12 03:21:39.581119656 
-0700
+++ 25-akpm/kernel/exit.c   2005-04-12 03:21:39.586118896 -0700
@@ -220,7 +220,7 @@ static inline int has_stopped_jobs(int p
  *
  * NOTE that reparent_to_init() gives the caller full capabilities.
  */
-void reparent_to_init(void)
+static inline void reparent_to_init(void)
 {
write_lock_irq(tasklist_lock);
 
_
-
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 145/198] CREDITS update

2005-04-12 Thread akpm

From: Colin Leroy [EMAIL PROTECTED]

Update Colin's credits entry.

Signed-off-by: Colin Leroy [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/CREDITS |3 ++-
 1 files changed, 2 insertions(+), 1 deletion(-)

diff -puN CREDITS~credits-update CREDITS
--- 25/CREDITS~credits-update   2005-04-12 03:21:38.228325312 -0700
+++ 25-akpm/CREDITS 2005-04-12 03:21:38.233324552 -0700
@@ -1958,7 +1958,8 @@ S: Germany
 N: Colin Leroy
 E: [EMAIL PROTECTED]
 W: http://www.geekounet.org/
-D: PowerMac adt7467 fan driver
+D: PowerMac adt746x fan driver
+D: Random fixing of various drivers (macintosh, usb, sound)
 S: Toulouse
 S: France
 
_
-
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 146/198] pci enumeration on ixp2000: overflow in kernel/resource.c

2005-04-12 Thread akpm

From: Lennert Buytenhek [EMAIL PROTECTED]

IXP2000 (ARM-based) platforms use a separate 'struct resource' for PCI MEM
space.  Resource allocation for PCI BARs always fails because the 'root'
resource (the IXP2000 PCI MEM resource) always has the entire address space
(-) free, and find_resource() calculates the size of that
range as -+1=0, so all allocations fail because it thinks
there is no space.

(akpm: pls. double-check)

Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/kernel/resource.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN 
kernel/resource.c~pci-enumeration-on-ixp2000-overflow-in-kernel-resourcec 
kernel/resource.c
--- 
25/kernel/resource.c~pci-enumeration-on-ixp2000-overflow-in-kernel-resourcec
2005-04-12 03:21:38.435293848 -0700
+++ 25-akpm/kernel/resource.c   2005-04-12 03:21:38.438293392 -0700
@@ -266,7 +266,7 @@ static int find_resource(struct resource
new-start = (new-start + align - 1)  ~(align - 1);
if (alignf)
alignf(alignf_data, new, size, align);
-   if (new-start  new-end  new-end - new-start + 1 = size) 
{
+   if (new-start  new-end  new-end - new-start = size - 1) 
{
new-end = new-start + size - 1;
return 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 139/198] hd: eliminate bad section references

2005-04-12 Thread akpm

From: maximilian attems [EMAIL PROTECTED]

Fix hd section references:
make parse_hd_setup() __init

Error: ./drivers/ide/legacy/hd.o .text refers to 0943 R_386_PC32
.init.text

Signed-off-by: maximilian attems [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/ide/legacy/hd.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/ide/legacy/hd.c~hd-eliminate-bad-section-references 
drivers/ide/legacy/hd.c
--- 25/drivers/ide/legacy/hd.c~hd-eliminate-bad-section-references  
2005-04-12 03:21:36.912525344 -0700
+++ 25-akpm/drivers/ide/legacy/hd.c 2005-04-12 03:21:36.916524736 -0700
@@ -851,7 +851,7 @@ Enomem:
goto out;
 }
 
-static int parse_hd_setup (char *line) {
+static int __init parse_hd_setup (char *line) {
int ints[6];
 
(void) get_options(line, ARRAY_SIZE(ints), ints);
_
-
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 138/198] pnpbios: eliminate bad section references

2005-04-12 Thread akpm

From: maximilian attems [EMAIL PROTECTED]

one of the last buildcheck errors on i386, thanks Randy again for double
checking.

Fix pnpbios section references:
make dmi_system_id pnpbios_dmi_table __initdata

Error: ./drivers/pnp/pnpbios/core.o .data refers to 0100 R_386_32
.init.text
Error: ./drivers/pnp/pnpbios/core.o .data refers to 012c R_386_32
.init.text

Signed-off-by: maximilian attems [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/drivers/pnp/pnpbios/core.c |2 +-
 1 files changed, 1 insertion(+), 1 deletion(-)

diff -puN drivers/pnp/pnpbios/core.c~pnpbios-eliminate-bad-section-references 
drivers/pnp/pnpbios/core.c
--- 25/drivers/pnp/pnpbios/core.c~pnpbios-eliminate-bad-section-references  
2005-04-12 03:21:36.702557264 -0700
+++ 25-akpm/drivers/pnp/pnpbios/core.c  2005-04-12 03:21:36.705556808 -0700
@@ -512,7 +512,7 @@ static int __init exploding_pnp_bios(str
return 0;
 }
 
-static struct dmi_system_id pnpbios_dmi_table[] = {
+static struct dmi_system_id pnpbios_dmi_table[] __initdata = {
{   /* PnPBIOS GPF on boot */
.callback = exploding_pnp_bios,
.ident = Higraded P14H,
_
-
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 133/198] kill #ifndef HAVE_ARCH_GET_SIGNAL_TO_DELIVER in signal.c

2005-04-12 Thread akpm

From: Christoph Hellwig [EMAIL PROTECTED]

Now that no architectures defines HAVE_ARCH_GET_SIGNAL_TO_DELIVER anymore
this can go away.  It was a transitional hack only.

Signed-off-by: Andrew Morton [EMAIL PROTECTED]
---

 25-akpm/kernel/signal.c |4 
 1 files changed, 4 deletions(-)

diff -puN 
kernel/signal.c~kill-ifndef-have_arch_get_signal_to_deliver-in-signalc 
kernel/signal.c
--- 25/kernel/signal.c~kill-ifndef-have_arch_get_signal_to_deliver-in-signalc   
2005-04-12 03:21:35.653716712 -0700
+++ 25-akpm/kernel/signal.c 2005-04-12 03:21:35.658715952 -0700
@@ -1649,8 +1649,6 @@ void ptrace_notify(int exit_code)
spin_unlock_irq(current-sighand-siglock);
 }
 
-#ifndef HAVE_ARCH_GET_SIGNAL_TO_DELIVER
-
 static void
 finish_stop(int stop_count)
 {
@@ -1962,8 +1960,6 @@ relock:
return signr;
 }
 
-#endif
-
 EXPORT_SYMBOL(recalc_sigpending);
 EXPORT_SYMBOL_GPL(dequeue_signal);
 EXPORT_SYMBOL(flush_signals);
_
-
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] ppc32: MV643XX ethernet is an option for Pegasos

2005-04-12 Thread Fabio Massimo Di Nitto
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dale Farnsworth wrote:
 On Tue, Apr 12, 2005 at 07:13:04AM +, Benjamin Herrenschmidt wrote:
 
This patch allows Kconfig to build the MV643xx ethernet driver on
Pegasos (CONFIG_PPC_MULTIPLATFORM) and adds what I think is a missing
fix from Dale's batch, that is remove SA_INTERRUPT and add SA_SHIRQ in
there as the interrupt is shared if I understand things correctly.

Signed-off-by: Benjamin Herrenschmidt [EMAIL PROTECTED]
Signed-off-by: Fabio Massimo Di Nitto [EMAIL PROTECTED]
 
 
 This looks identical to the patch I posted to netdev two weeks ago
 as the first of 20 patches for the MV643xx ethernet driver.
 
 See http://oss.sgi.com/archives/netdev/2005-03/msg01644.html and
 http://oss.sgi.com/archives/netdev/2005-03/msg01642.html.

It is possible. I received an old patch from Sven Luther and bounced to
Benjamin rediffed against 2.6.12rc2, but the bits ended to be exactly
the same.

Fabio

PS feel free to claim credits on it. I don't want for sure take over
your work :)

- --
Self-Service law:
The last available dish of the food you have decided to eat, will be
inevitably taken from the person in front of you.
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iQIVAwUBQlumhlA6oBJjVJ+OAQK/NQ/9FLAIyMR+8fnpOygf7PVFSC0bEMZ9GVuk
apCzX79QOjKAOOEaI/oSZEaH6K4/93lnUS1CjUiRYCv43mQ9RIw5cSs+if6TqSUF
UOzRiFIg269BTIvIJVklsGUN+lC0C3Z66VQzWYkS84UJ3gQoHs55IRhccWqVMO2p
L/VrcypZV5yD7OmqfsE7JJ4EYWtg/K3xigz+y7ZkyOfhuKWJdFbtRM+jjm67gMGq
J+IqXgLpN4dMp/C0woVjfE2/mebqiBN2ft6qPCYlgwXKXN7wPKcSodMpK6D64x6T
juvaSn6wgvQWmuRJh9bRBkHBM78eYiGFfBa4Mh8Il2aNrLmxjn8I52/wfq/wXd8j
4sDCnIC6YtNf5dbhK2jY6M9YCBs3SxzJu9O6yCjGGVfp0dpnPLFpbiZnWMAXQGz4
sVA7YCejkUJYMiJY9mlIh7960+V+g+PIBCk7myaOML24bsUp7AfAJtzdqQZqFSau
ZpD0e77prl16F4gOb+pMt+JGVeOWeZqVuhg8GlklFaAHGVBujE9Zb+uKh4ZTeag9
ksxWDZACe/kxNc9rFvBpabNLzK5oi4Tn4LWVRr105c6nLSXwladckUnT3MCSTwHU
yRD5YOerF0Rerh6OyWYw8FoG+vHSfIm6w87QxNSgQMjv6wOhZRVTyukF/A2V42tw
nq3U4qR66hM=
=uGjK
-END PGP SIGNATURE-
-
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 scsi-misc-2.6 01/04] scsi: consolidate error handling out of scsi_init_io() into scsi_prep_fn()

2005-04-12 Thread Tejun Heo
01_scsi_reqfn_consolidate_error_handling.patch

This patch fixes a queue stall bug which occurred when sgtable
allocation failed and device_busy == 0.  When scsi_init_io()
returns BLKPREP_DEFER or BLKPREP_KILL, it's supposed to free
resources itself.  This patch consolidates defer and kill
handling into scsi_prep_fn().

Note that this patch doesn't consolidate state defer/kill
handlings in scsi_prep_fn().  They were omitted as all state
checks will be moved into scsi_reques_fn() by the following
reqfn_reimpl patch.

ret value checking was changed to switch() as in James's
patch.  Also, kill: comment is copied from James's patch.

Signed-off-by: Tejun Heo [EMAIL PROTECTED]

 scsi_lib.c |   46 +++---
 1 files changed, 31 insertions(+), 15 deletions(-)

Index: scsi-reqfn-export/drivers/scsi/scsi_lib.c
===
--- scsi-reqfn-export.orig/drivers/scsi/scsi_lib.c  2005-04-12 
19:27:55.0 +0900
+++ scsi-reqfn-export/drivers/scsi/scsi_lib.c   2005-04-12 19:27:55.0 
+0900
@@ -945,10 +945,8 @@ static int scsi_init_io(struct scsi_cmnd
 * if sg table allocation fails, requeue request later.
 */
sgpnt = scsi_alloc_sgtable(cmd, GFP_ATOMIC);
-   if (unlikely(!sgpnt)) {
-   req-flags |= REQ_SOFTBARRIER;
+   if (unlikely(!sgpnt))
return BLKPREP_DEFER;
-   }
 
cmd-request_buffer = (char *) sgpnt;
cmd-request_bufflen = req-nr_sectors  9;
@@ -975,9 +973,6 @@ static int scsi_init_io(struct scsi_cmnd
printk(KERN_ERR req nr_sec %lu, cur_nr_sec %u\n, req-nr_sectors,
req-current_nr_sectors);
 
-   /* release the command and kill it */
-   scsi_release_buffers(cmd);
-   scsi_put_command(cmd);
return BLKPREP_KILL;
 }
 
@@ -1145,18 +1140,24 @@ static int scsi_prep_fn(struct request_q
 * required).
 */
ret = scsi_init_io(cmd);
-   if (ret)/* BLKPREP_KILL return also releases the 
command */
-   return ret;
+   switch (ret) {
+   case 0:
+   /* Successful initialization. */
+   break;
+   case BLKPREP_DEFER:
+   goto defer;
+   default:
+   /* Unknown return value, fall through. */
+   case BLKPREP_KILL:
+   goto kill;
+   }

/*
 * Initialize the actual SCSI command for this request.
 */
drv = *(struct scsi_driver **)req-rq_disk-private_data;
-   if (unlikely(!drv-init_command(cmd))) {
-   scsi_release_buffers(cmd);
-   scsi_put_command(cmd);
-   return BLKPREP_KILL;
-   }
+   if (unlikely(!drv-init_command(cmd)))
+   goto kill;
}
 
/*
@@ -1166,12 +1167,27 @@ static int scsi_prep_fn(struct request_q
return BLKPREP_OK;
 
  defer:
-   /* If we defer, the elv_next_request() returns NULL, but the
+   /*
+* If we defer, the elv_next_request() returns NULL, but the
 * queue must be restarted, so we plug here if no returning
-* command will automatically do that. */
+* command will automatically do that.  Also, the request may
+* have its cmd allocated, so we set REQ_SOFTBARRIER.
+*/
if (sdev-device_busy == 0)
blk_plug_device(q);
+   req-flags |= REQ_SOFTBARRIER;
return BLKPREP_DEFER;
+
+ kill:
+   /*
+* Here we have to release every resource associated with the
+* request because this will complete at the request level
+* (req-end_io), not the scsi command level, so no scsi
+* routine will get to free the associated resources.
+*/
+   scsi_release_buffers(cmd);
+   scsi_put_command(cmd);
+   return BLKPREP_KILL;
 }
 
 /*

-
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 scsi-misc-2.6 03/04] scsi: reimplement scsi_request_fn()

2005-04-12 Thread Tejun Heo
 Oops, I forgot to mention that reqfn is reformatted mostly as
suggested by Chritoph Hellwig.  Sorry.

On Tue, Apr 12, 2005 at 07:33:03PM +0900, Tejun Heo wrote:
 03_scsi_reqfn_reimplementation.patch
 
   This patch rewrites scsi_request_fn().  scsi_dispatch_cmd() is
   merged into scsi_request_fn().  Goals are
 
   * Remove unnecessary operations (host_lock unlocking/locking,
 recursing into scsi_run_queue(), ...)
   * Consolidate defer/kill paths.
   * Be concise.
 
   The following bugs are fixed.
 
   * All killed requests now get fully prep'ed and pass through
 __scsi_done().  This is the only kill path.
   - scsi_cmnd leak in offline-kill path removed
   - unfinished request bug in
 scsi_dispatch_cmd():SDEV_DEL-kill path removed.
   - commands are never terminated directly from blk
 layer unless they are invalid, so no need to supply
 req-end_io callback for special requests.
   * Timer is added while holding host_lock, after all conditions
 are checked and serial number is assigned.  This guarantees
 that until host_lock is released, the scsi_cmnd pointed to
 by cmd isn't released.  That didn't hold in the original
 code and, theoretically, the original code could access
 already released cmd.
   * For the same reason, if shost-hostt-queuecommand() fails,
 we try to delete the timer before releasing host_lock.
 
   Other changes/notes
 
   * host_lock is acquired and released only once.
 enter (qlocked) - enter loop - dev-prep - switch to hlock -\
 ^ switch to qlock - issue - host-prep -/
   * unnecessary if () on get_device() removed.
   * loop on elv_next_request() instead of blk_queue_plugged().
 We now explicitly break out of loop when we plug and check if
 the queue has been plugged underneath us at the end of loop.
   * All device/host state checks are done in this function and
 done only once while holding qlock/host_lock respectively.
   * Requests which get deferred during dev-prep are never
 removed from request queue, so deferring is achieved by
 simply breaking out of the loop and returning.
   * Failure of blk_queue_start_tag() on tagged queue is a BUG
 now.  This condition should have been catched by
 scsi_dev_queue_ready().
   * req-special == NULL test removed.  This just can't happen,
 and even if it ever happens, scsi_request_fn() will
 deterministically oops.
   * Requests which gets deferred during host-prep are requeued
 using blk_requeue_request().  This is the only requeue path.
 
   Note that scsi_kill_requests() still terminates requests using
   blk layer.  The path is circular-ref workaround and soon to be
   replaced, so ignore it for now.

-- 
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/


  1   2   3   4   5   6   7   >