nfsv2 ref leak in 2.6.24?

[Erez Zadok]

I'm testing unionfs on top of nfsv2/3/4, using 2.6.24 as of linus's commit
4fa4d23fa20de67df919030c1216295664866ad7.  A lot of my unionfs regression
tests are failing on nfs2, b/c files that should be deleted, aren't.  It
feels like there may be a ref leak that prevents the files from being
deleted, or maybe an unlink issue.  It doesn't happen in all of my previous
kernels w/ identical unionfs (code 2.6.9--2.6.23).  And in 2.6.24 it happens
only w/ nfs2 -- nfs3/4 are fine.

I'm not sure if this is a client or server issue, and I'm only starting to
dig deeper.  But I thought I'd ask you in case this is a known problem and
you have a fix.  If this is the first you hear of this problem, let me know
and I'll try to narrow it down further.

Thanks,
Erez.
-
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: [NET]: Fix possible dev_deactivate race condition

[David Miller]

From: Herbert Xu <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 13:36:24 +0800

> [NET]: Fix possible dev_deactivate race condition
> 
> The function dev_deactivate is supposed to only return when
> all outstanding transmissions have completed.  Unfortunately
> it is possible for store operations in the driver's transmit
> function to only become visible after dev_deactivate returns.
> 
> This patch fixes this by taking the queue lock after we see
> the end of the queue run.  This ensures that all effects of
> any previous transmit calls are visible.
> 
> If however we detect that there is another queue run occuring,
> then we'll warn about it because this should never happen as
> we have pointed dev->qdisc to noop_qdisc within the same queue
> lock earlier in the functino.
> 
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

Applied, thanks Herbert!
-
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 0/5] Shadow directories

[Al Viro]

On Fri, Oct 19, 2007 at 12:27:16PM +0930, David Newall wrote:

> >Learn to read.  Linux has never allowed that.  Most of the Unix systems
> >do not allow that.
> 
> I did read the claim and it is ambiguous, in that it can reasonably be 
> read to mean that most UNIX systems never allowed such links, which is 
> wrong.  All UNIX systems allowed it until relatively recently.

FVO"relatively recently" exceeding a decade and half.  In any case,
it's _trivial_ to get fs corruption on any system with such links -
play with rename() races a bit and you'll get it.  And yes, it does
include 4.4BSD and quite a chunk of even later history.

Anyway, you are quite welcome to propose a sane locking scheme capable
of dealing with that mess.

As for the posted patch, AFAICS it's FUBAR in handling of .. in such
directories.  Moreover, how are you going to keep that shadow tree
in sync with the main one if somebody starts doing renames in the
latter?  Or mount --move, or...
-
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/

[NET]: Fix possible dev_deactivate race condition

[Herbert Xu]

On Fri, Oct 19, 2007 at 12:20:25PM +0800, Herbert Xu wrote:
>
> In fact this bug exists elsewhere too.  For example, the network
> stack does this in net/sched/sch_generic.c:
> 
> /* Wait for outstanding qdisc_run calls. */
>   while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
>   yield();
> 
> This has the same problem as the current synchronize_irq code.

OK here is the fix for that case.

[NET]: Fix possible dev_deactivate race condition

The function dev_deactivate is supposed to only return when
all outstanding transmissions have completed.  Unfortunately
it is possible for store operations in the driver's transmit
function to only become visible after dev_deactivate returns.

This patch fixes this by taking the queue lock after we see
the end of the queue run.  This ensures that all effects of
any previous transmit calls are visible.

If however we detect that there is another queue run occuring,
then we'll warn about it because this should never happen as
we have pointed dev->qdisc to noop_qdisc within the same queue
lock earlier in the functino.

Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c
index e01d576..b3b7420 100644
--- a/net/sched/sch_generic.c
+++ b/net/sched/sch_generic.c
@@ -556,6 +556,7 @@ void dev_deactivate(struct net_device *dev)
 {
struct Qdisc *qdisc;
struct sk_buff *skb;
+   int running;
 
spin_lock_bh(>queue_lock);
qdisc = dev->qdisc;
@@ -571,12 +572,31 @@ void dev_deactivate(struct net_device *dev)
 
dev_watchdog_down(dev);
 
-   /* Wait for outstanding dev_queue_xmit calls. */
+   /* Wait for outstanding qdisc-less dev_queue_xmit calls. */
synchronize_rcu();
 
/* Wait for outstanding qdisc_run calls. */
-   while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
-   yield();
+   do {
+   while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
+   yield();
+
+   /*
+* Double-check inside queue lock to ensure that all effects
+* of the queue run are visible when we return.
+*/
+   spin_lock_bh(>queue_lock);
+   running = test_bit(__LINK_STATE_QDISC_RUNNING, >state);
+   spin_unlock_bh(>queue_lock);
+
+   /*
+* The running flag should never be set at this point because
+* we've already set dev->qdisc to noop_qdisc *inside* the same
+* pair of spin locks.  That is, if any qdisc_run starts after
+* our initial test it should see the noop_qdisc and then
+* clear the RUNNING bit before dropping the queue lock.  So
+* if it is set here then we've found a bug.
+*/
+   } while (WARN_ON_ONCE(running));
 }
 
 void dev_init_scheduler(struct net_device *dev)
-
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] Make advansys depend on CONFIG_VIRT_TO_BUS

[Andrew Morton]

On Thu, 18 Oct 2007 22:20:17 -0700 Randy Dunlap <[EMAIL PROTECTED]> wrote:

> On Fri, 19 Oct 2007 15:04:31 +1000 Stephen Rothwell wrote:
> 
> > At least for now.
> 
> Please explain "why" in the changelog (what changelog?).
> 
> E.g.:
> so that make allmodconfig on powerpc will have a better chance
> of building.

My version of this patch does that.  I'll be sending it into Linus in an
hour or 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/

[M68KNOMMU]: cleanup m68knommu timer code

[Greg Ungerer]

Reduce the function pointer mess of the m68knommu timer code.
Call direct to the local hardware's timer setup, and expose the local
common timer interrupt handler to the lower level hardware timer.
Ultimately this will save definitions of all these functions across
all the platform code to setup the function pointers (which for
any given m68knommu CPU family member can be only one set of hardware
timer functions).

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---

diffstat (relative to arch/m68knommu):
 kernel/setup.c  |9 -
 kernel/time.c   |   22 --
 platform/5206/config.c  |9 -
 platform/5206e/config.c |   10 --
 platform/520x/config.c  |8 +---
 platform/523x/config.c  |8 
 platform/5249/config.c  |   10 --
 platform/5272/config.c  |   10 --
 platform/527x/config.c  |8 
 platform/528x/config.c  |8 
 platform/5307/config.c  |   10 --
 platform/5307/pit.c |   15 +--
 platform/5307/timers.c  |   19 +++
 platform/532x/config.c  |   10 --
 platform/5407/config.c  |   10 --
 15 files changed, 29 insertions(+), 137 deletions(-)


diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c 
linux-2.6.23.timers/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c  2007-10-10 06:31:38.0 
+1000
+++ linux-2.6.23.timers/arch/m68knommu/kernel/setup.c   2007-10-19 
15:08:24.0 +1000
@@ -287,12 +287,3 @@ struct seq_operations cpuinfo_op = {
.show   = show_cpuinfo,
 };
 
-void arch_gettod(int *year, int *mon, int *day, int *hour,
-int *min, int *sec)
-{
-   if (mach_gettod)
-   mach_gettod(year, mon, day, hour, min, sec);
-   else
-   *year = *mon = *day = *hour = *min = *sec = 0;
-}
-
diff -Naurp linux-2.6.23/arch/m68knommu/kernel/time.c 
linux-2.6.23.timers/arch/m68knommu/kernel/time.c
--- linux-2.6.23/arch/m68knommu/kernel/time.c   2007-10-10 06:31:38.0 
+1000
+++ linux-2.6.23.timers/arch/m68knommu/kernel/time.c2007-10-19 
15:08:24.0 +1000
@@ -27,7 +27,6 @@
 
 #defineTICK_SIZE (tick_nsec / 1000)
 
-
 static inline int set_rtc_mmss(unsigned long nowtime)
 {
if (mach_set_clock_mmss)
@@ -39,15 +38,11 @@ static inline int set_rtc_mmss(unsigned 
  * timer_interrupt() needs to keep up the real-time clock,
  * as well as call the "do_timer()" routine every clocktick
  */
-static irqreturn_t timer_interrupt(int irq, void *dummy)
+irqreturn_t arch_timer_interrupt(int irq, void *dummy)
 {
/* last time the cmos clock got updated */
static long last_rtc_update=0;
 
-   /* may need to kick the hardware timer */
-   if (mach_tick)
- mach_tick();
-
write_seqlock(_lock);
 
do_timer(1);
@@ -103,10 +98,10 @@ void time_init(void)
 {
unsigned int year, mon, day, hour, min, sec;
 
-   extern void arch_gettod(int *year, int *mon, int *day, int *hour,
-   int *min, int *sec);
-
-   arch_gettod(, , , , , );
+   if (mach_gettod)
+   mach_gettod(, , , , , );
+   else
+   year = mon = day = hour = min = sec = 0;
 
if ((year += 1900) < 1970)
year += 100;
@@ -114,7 +109,7 @@ void time_init(void)
xtime.tv_nsec = 0;
wall_to_monotonic.tv_sec = -xtime.tv_sec;
 
-   mach_sched_init(timer_interrupt);
+   hw_timer_init();
 }
 
 /*
@@ -128,7 +123,7 @@ void do_gettimeofday(struct timeval *tv)
 
do {
seq = read_seqbegin_irqsave(_lock, flags);
-   usec = mach_gettimeoffset ? mach_gettimeoffset() : 0;
+   usec = hw_timer_offset();
sec = xtime.tv_sec;
usec += (xtime.tv_nsec / 1000);
} while (read_seqretry_irqrestore(_lock, seq, flags));
@@ -160,8 +155,7 @@ int do_settimeofday(struct timespec *tv)
 * Discover what correction gettimeofday
 * would have done, and then undo it!
 */
-   if (mach_gettimeoffset)
-   nsec -= (mach_gettimeoffset() * 1000);
+   nsec -= (hw_timer_offset() * 1000);
 
wtm_sec  = wall_to_monotonic.tv_sec + (xtime.tv_sec - sec);
wtm_nsec = wall_to_monotonic.tv_nsec + (xtime.tv_nsec - nsec);
diff -Naurp linux-2.6.23/arch/m68knommu/platform/5206/config.c 
linux-2.6.23.timers/arch/m68knommu/platform/5206/config.c
--- linux-2.6.23/arch/m68knommu/platform/5206/config.c  2007-10-10 
06:31:38.0 +1000
+++ linux-2.6.23.timers/arch/m68knommu/platform/5206/config.c   2007-10-19 
15:11:38.0 +1000
@@ -10,13 +10,10 @@
 /***/
 
 #include 
-#include 
 #include 
 #include 
 #include 
-#include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -25,9 +22,6 @@
 
 /***/
 

Re: [PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS

[Randy Dunlap]

On Fri, 19 Oct 2007 15:04:31 +1000 Stephen Rothwell wrote:

> At least for now.

Please explain "why" in the changelog (what changelog?).

E.g.:
so that make allmodconfig on powerpc will have a better chance
of building.

or whatever.

> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
> ---
>  drivers/scsi/Kconfig |1 +
>  1 files changed, 1 insertions(+), 0 deletions(-)
> 
> -- 
> Cheers,
> Stephen Rothwell[EMAIL PROTECTED]
> 
> diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
> index 30905ce..325533c 100644
> --- a/drivers/scsi/Kconfig
> +++ b/drivers/scsi/Kconfig
> @@ -523,6 +523,7 @@ config SCSI_ADVANSYS
>   tristate "AdvanSys SCSI support"
>   depends on SCSI
>   depends on ISA || EISA || PCI
> + depends on VIRT_TO_BUS
>   help
> This is a driver for all SCSI host adapters manufactured by
> AdvanSys. It is documented in the kernel source in


---
~Randy
-
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: OOM notifications

[Chris Friesen]

Ulrich Drepper wrote:


I agree.  Applications shouldn't be expected to be yet more complicated
and have different levels of low memory handling.  You might want to
give a process a second shot at handling SIGDANGER but after that's it's
all about preparation for a shutdown.


I disagree.  From an embedded viewpoint it would be nice to have a 
"please free up memory", then a "we really need memory NOW", then 
finally the kernel oom killer.


The advantage of the middle message is that it allows userspace to do 
smarter things if it wants to (for instance, if there is an overall 
system manager or some such thing, it could do a better job of 
restarting tasks than the kernel oom killer since it knows the relative 
importance of tasks).


Chris
-
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: lock bitops

[Nick Piggin]

I missed an obvious one!

x86 CPUs are defined not to reorder stores past earlier loads, so there is
no hardware memory barrier required to implement a release-consistent store
(all stores are, by definition).

So ditch the generic lock bitops, and implement optimised versions for x86,
which removes the mfence from __clear_bit_unlock (which is already a useful
primitive for SLUB).

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

---
Index: linux-2.6/include/asm-x86/bitops_32.h
===
--- linux-2.6.orig/include/asm-x86/bitops_32.h
+++ linux-2.6/include/asm-x86/bitops_32.h
@@ -76,6 +76,20 @@ static inline void clear_bit(int nr, vol
:"Ir" (nr));
 }
 
+/*
+ * clear_bit_unlock - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and implies release semantics before the memory
+ * operation. It can be used for an unlock.
+ */
+static inline void clear_bit_unlock(unsigned long nr, volatile unsigned long 
*addr)
+{
+   barrier();
+   clear_bit(nr, addr);
+}
+
 static inline void __clear_bit(int nr, volatile unsigned long * addr)
 {
__asm__ __volatile__(
@@ -83,6 +97,25 @@ static inline void __clear_bit(int nr, v
:"+m" (ADDR)
:"Ir" (nr));
 }
+
+/*
+ * __clear_bit_unlock - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * __clear_bit() is non-atomic and implies release semantics before the memory
+ * operation. It can be used for an unlock if no other CPUs can concurrently
+ * modify other bits in the word.
+ *
+ * No memory barrier is required here, because x86 cannot reorder stores past
+ * older loads. Same principle as spin_unlock.
+ */
+static inline void __clear_bit_unlock(unsigned long nr, volatile unsigned long 
*addr)
+{
+   barrier();
+   __clear_bit(nr, addr);
+}
+
 #define smp_mb__before_clear_bit() barrier()
 #define smp_mb__after_clear_bit()  barrier()
 
@@ -142,6 +175,15 @@ static inline int test_and_set_bit(int n
 }
 
 /**
+ * test_and_set_bit_lock - Set a bit and return its old value for lock
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This is the same as test_and_set_bit on x86
+ */
+#define test_and_set_bit_lock test_and_set_bit
+
+/**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
  * @addr: Address to count from
@@ -402,7 +444,6 @@ static inline int fls(int x)
 }
 
 #include 
-#include 
 
 #endif /* __KERNEL__ */
 
Index: linux-2.6/include/asm-x86/bitops_64.h
===
--- linux-2.6.orig/include/asm-x86/bitops_64.h
+++ linux-2.6/include/asm-x86/bitops_64.h
@@ -68,6 +68,20 @@ static __inline__ void clear_bit(int nr,
:"dIr" (nr));
 }
 
+/*
+ * clear_bit_unlock - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * clear_bit() is atomic and implies release semantics before the memory
+ * operation. It can be used for an unlock.
+ */
+static inline void clear_bit_unlock(unsigned long nr, volatile unsigned long 
*addr)
+{
+   barrier();
+   clear_bit(nr, addr);
+}
+
 static __inline__ void __clear_bit(int nr, volatile void * addr)
 {
__asm__ __volatile__(
@@ -76,6 +90,24 @@ static __inline__ void __clear_bit(int n
:"dIr" (nr));
 }
 
+/*
+ * __clear_bit_unlock - Clears a bit in memory
+ * @nr: Bit to clear
+ * @addr: Address to start counting from
+ *
+ * __clear_bit() is non-atomic and implies release semantics before the memory
+ * operation. It can be used for an unlock if no other CPUs can concurrently
+ * modify other bits in the word.
+ *
+ * No memory barrier is required here, because x86 cannot reorder stores past
+ * older loads. Same principle as spin_unlock.
+ */
+static inline void __clear_bit_unlock(unsigned long nr, volatile unsigned long 
*addr)
+{
+   barrier();
+   __clear_bit(nr, addr);
+}
+
 #define smp_mb__before_clear_bit() barrier()
 #define smp_mb__after_clear_bit()  barrier()
 
@@ -133,6 +165,15 @@ static __inline__ int test_and_set_bit(i
 }
 
 /**
+ * test_and_set_bit_lock - Set a bit and return its old value for lock
+ * @nr: Bit to set
+ * @addr: Address to count from
+ *
+ * This is the same as test_and_set_bit on x86
+ */
+#define test_and_set_bit_lock test_and_set_bit
+
+/**
  * __test_and_set_bit - Set a bit and return its old value
  * @nr: Bit to set
  * @addr: Address to count from
@@ -408,7 +449,6 @@ static __inline__ int fls(int x)
 #define ARCH_HAS_FAST_MULTIPLIER 1
 
 #include 
-#include 
 
 #endif /* __KERNEL__ */
 
-
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] Make advansys depend on CONFIG_VIRT_TO_BUS

[David Miller]

From: Stephen Rothwell <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 15:04:31 +1000

> At least for now.
> 
> Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>

Acked-by: David S. Miller <[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: [RFC PATCH 2/4] Rename lock_cpu_hotplug to get_online_cpus

[Gautham R Shenoy]

Hi Nathan, 

> Gautham R Shenoy wrote:
> > On Thu, Oct 18, 2007 at 03:22:21AM -0500, Nathan Lynch wrote:
> > > Gautham R Shenoy wrote:
> > > > Hi Nathan, 
> > > > > Hi Gautham-
> > > > > 
> > > > > Gautham R Shenoy wrote:
> > > > > > Replace all lock_cpu_hotplug/unlock_cpu_hotplug from the kernel and 
> > > > > > use 
> > > > > > get_online_cpus and put_online_cpus instead as it highlights
> > > > > > the refcount semantics in these operations.
> > > > > 
> > > > > Something other than "get_online_cpus", please?  lock_cpu_hotplug()
> > > > > protects cpu_present_map as well as cpu_online_map.  For example, some
> > > > > of the powerpc code modified in this patch is made a bit less clear
> > > > > because it is manipulating cpu_present_map, not cpu_online_map.
> > > > 
> > > > A quick look at the code, and I am wondering why is lock_cpu_hotplug()
> > > > used there in the first place. It doesn't look like we require any 
> > > > protection against cpus coming up/ going down in the code below, 
> > > > since the cpu-hotplug operation doesn't affect the cpu_present_map. 
> > > 
> > > The locking is necessary.  Changes to cpu_online_map and
> > > cpu_present_map must be serialized; otherwise you could end up trying
> > > to online a cpu as it is being removed (i.e. cleared from
> > > cpu_present_map).  Online operations must check that a cpu is present
> > > before bringing it up (kernel/cpu.c):
> > 
> > Fair enough! 
> > 
> > But we are not protecting the cpu_present_map here using
> > lock_cpu_hotplug(), now are we?
> 
> Yes, we are.  In addition to the above, updates to cpu_present_map
> have to be serialized.  pseries_add_processor can be summed up as
> "find the first N unset bits in cpu_present_map and set them".  That's
> not an atomic operation, so some kind of mutual exclusion is needed.
> 

Okay. But other than pseries_add_processor and pseries_remove_processor,
are there any other places where we _change_ the cpu_present_map ?

I agree that we need some kind of synchronization for threads which read
the cpu_present_map. But probably we can use a seperate mutex for that.



> 
> > The lock_cpu_hotplug() here, ensures that no cpu-hotplug operations
> > occur in parallel with a processor add or a processor remove. 
> 
> That's one important effect, but not the only one (see above).
> 
> 
> > IOW, we're still ensuring that the cpu_online_map doesn't change 
> > while we're changing the cpu_present_map. So I don't see why the name
> > get_online_cpus() should be a problem here.
> 
> The naming is a problem IMO for two reasons:
> 
> - lock_cpu_hotplug() protects cpu_present_map as well as
>   cpu_online_map (sigh, I see that Documentation/cpu-hotplug.txt
>   disagrees with me, but my statement holds for powerpc, at least).
> 
> - get_online_cpus() implies reference count semantics (as stated in
>   the changelog) but AFAICT it really has a reference count
>   implementation with read-write locking semantics.
> 
> Hmm, I think there's another problem here.  With your changes, code
> which relies on the mutual exclusion behavior of lock_cpu_hotplug()
> (such as pseries_add/remove_processor) will now be able to run
> concurrently.  Probably those functions should use
> cpu_hotplug_begin/end instead.

One of the primary reasons to move away from the mutex semantics for
cpu-hotplug protection, was that there were a lot of places where
lock_cpu_hotplug() was used for protecting local data structures too,
when they had nothing to do with cpu-hotplug as such, and it resulted 
in a whole mess. It took people quite sometime to sort things out 
with the cpufreq subsystem.

Probably it would be a lot cleaner if we use get_online_cpus() for
protection against cpu-hotplug and use specific mutexes for serializing
accesses to local data structures. Thoughts?

Thanks and Regards
gautham.

-- 
Gautham R Shenoy
Linux Technology Center
IBM India.
"Freedom comes with a price tag of responsibility, which is still a bargain,
because Freedom is priceless!"
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] Make advansys depend on CONFIG_VIRT_TO_BUS

[Stephen Rothwell]

At least for now.

Signed-off-by: Stephen Rothwell <[EMAIL PROTECTED]>
---
 drivers/scsi/Kconfig |1 +
 1 files changed, 1 insertions(+), 0 deletions(-)

-- 
Cheers,
Stephen Rothwell[EMAIL PROTECTED]

diff --git a/drivers/scsi/Kconfig b/drivers/scsi/Kconfig
index 30905ce..325533c 100644
--- a/drivers/scsi/Kconfig
+++ b/drivers/scsi/Kconfig
@@ -523,6 +523,7 @@ config SCSI_ADVANSYS
tristate "AdvanSys SCSI support"
depends on SCSI
depends on ISA || EISA || PCI
+   depends on VIRT_TO_BUS
help
  This is a driver for all SCSI host adapters manufactured by
  AdvanSys. It is documented in the kernel source in
-- 
1.5.3.4

-
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] bluetooth: hidp core debug code wrong argument fix

[Dave Young]

In the debug code of the hidp_queue_report function, the "device" variable does 
not exist, replace it with "session->hid"

Signed-off-by: Dave Young <[EMAIL PROTECTED]> 

---
net/bluetooth/hidp/core.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff -upr linux/net/bluetooth/hidp/core.c linux.new/net/bluetooth/hidp/core.c
--- linux/net/bluetooth/hidp/core.c 2007-10-15 14:05:23.0 +0800
+++ linux.new/net/bluetooth/hidp/core.c 2007-10-15 14:06:38.0 +0800
@@ -247,7 +247,7 @@ static inline int hidp_queue_report(stru
 {
struct sk_buff *skb;
 
-   BT_DBG("session %p hid %p data %p size %d", session, device, data, 
size);
+   BT_DBG("session %p hid %p data %p size %d", session, session->hid, 
data, size);
 
if (!(skb = alloc_skb(size + 1, GFP_ATOMIC))) {
BT_ERR("Can't allocate memory for new frame");
-
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] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

On Fri, 2007-10-19 at 12:48 +0800, Herbert Xu wrote:

> [IRQ]: Fix synchronize_irq races with IRQ handler
> 
> As it is some callers of synchronize_irq rely on memory barriers
> to provide synchronisation against the IRQ handlers.  For example,
> the tg3 driver does
> 
>   tp->irq_sync = 1;
>   smp_mb();
>   synchronize_irq();
> 
> and then in the IRQ handler:
> 
>   if (!tp->irq_sync)
>   netif_rx_schedule(dev, >napi);
> 
> Unfortunately memory barriers only work well when they come in
> pairs.  Because we don't actually have memory barriers on the
> IRQ path, the memory barrier before the synchronize_irq() doesn't
> actually protect us.
> 
> In particular, synchronize_irq() may return followed by the
> result of netif_rx_schedule being made visible.
> 
> This patch (mostly written by Linus) fixes this by using spin
> locks instead of memory barries on the synchronize_irq() path.
> 
> Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

Good for me.

Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Cheers,
Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Fix race between sk_filter reassign and sk_clone()

[David Miller]

From: Olof Johansson <[EMAIL PROTECTED]>
Date: Thu, 18 Oct 2007 21:29:47 -0500

> So, looks like rcu_dereference() returned NULL. I don't know the
> filter code at all, but it seems like it might be a valid case?
> sk_detach_filter() seems to handle a NULL sk_filter, at least.
> 
> 
> So, this needs review by someone who knows the filter, but it fixes the
> problem for me:
> 
> 
> Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

I've applied this for now to my net-2.6 tree, thanks Olof
for tracking this down.

Pavel please take a look at this and let me know if it should
fixed in some other way.

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/

[M68KNOMMU]: fix syscall tracing

[Greg Ungerer]

From: Matt Waddel <[EMAIL PROTECTED]>

Fix the system call code for handling syscall tracing, so strace
and gdbserver work properly.

This fix originally developed by Philippe De Muyter and Stuart Hughes.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/platform/5307/entry.S 
linux-2.6.23-uc0/arch/m68knommu/platform/5307/entry.S
--- linux-2.6.23/arch/m68knommu/platform/5307/entry.S   2007-10-19 
10:30:55.0 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/platform/5307/entry.S   2007-10-19 
10:35:40.0 +1000
@@ -74,7 +74,8 @@ ENTRY(system_call)
movel   %sp,%d2 /* get thread_info pointer */
andl#-THREAD_SIZE,%d2   /* at start of kernel stack */
movel   %d2,%a0
-   movel   %sp,%a0@(THREAD_ESP0)   /* save top of frame */
+   movel   %a0@,%a1/* save top of frame */
+   movel   %sp,%a1@(TASK_THREAD+THREAD_ESP0)
btst#(TIF_SYSCALL_TRACE%8),%a0@(TI_FLAGS+(31-TIF_SYSCALL_TRACE)/8)
bnes1f
 
@@ -83,6 +84,8 @@ ENTRY(system_call)
movel   %d0,%sp@(PT_D0) /* save the return value */
jra ret_from_exception
 1:
+   movel   #-ENOSYS,%d2/* strace needs -ENOSYS in PT_D0 */
+   movel   %d2,PT_D0(%sp)  /* on syscall entry */
subql   #4,%sp
SAVE_SWITCH_STACK
jbsrsyscall_trace
-
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] synchronize_irq needs a barrier

[Nick Piggin]

On Friday 19 October 2007 13:28, Herbert Xu wrote:
> Nick Piggin <[EMAIL PROTECTED]> wrote:
> >> First of all let's agree on some basic assumptions:
> >>
> >> * A pair of spin lock/unlock subsumes the effect of a full mb.
> >
> > Not unless you mean a pair of spin lock/unlock as in
> > 2 spin lock/unlock pairs (4 operations).
> >
> > *X = 10;
> > spin_lock();
> > /* *Y speculatively loaded here */
> > /* store to *X leaves CPU store queue here */
> > spin_unlock();
> > y = *Y;
>
> Good point.
>
> Although in this case we're still safe because in the worst
> cases:
>
> CPU0  CPU1
> irq_sync = 1
> synchronize_irq
>   spin lock
>   load IRQ_INPROGRESS
> irq_sync sync is visible
>   spin unlock
>   spin lock
>   load irq_sync
>   while (IRQ_INPROGRESS)
>   wait
>   return
>   set IRQ_INPROGRESS
>   spin unlock
>   tg3_msi
>   ack IRQ
>   if (irq_sync)
>   return
>   spin lock
>   clear IRQ_INPROGRESS
>   spin unlock
>
> 
>
> CPU0  CPU1
>   spin lock
>   load irq_sync
> irq_sync = 1
> synchronize_irq
>   set IRQ_INPROGRESS
>   spin unlock
>   spin lock
>   load IRQ_INPROGRESS
> irq_sync sync is visible
>   spin unlock
>   while (IRQ_INPROGRESS)
>   wait
>   tg3_msi
>   ack IRQ
>   if (irq_sync)
>   return
>   do work
>   spin lock
>   clear IRQ_INPROGRESS
>   spin unlock
>   return
>
> So because we're using the same lock on both sides, it does
> do the right thing even without the memory barrier.


Yeah, if you've got the lock on both sides there, then I
agree it will be correct.
-
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] synchronize_irq needs a barrier

[Herbert Xu]

On Fri, Oct 19, 2007 at 12:20:25PM +0800, Herbert Xu wrote:
>
> That's why I think this patch is in fact the only one that
> solves all the races in this thread.  The case that it solves
> which the lock/unlock patch does not is the one where action
> flows downwards past the clearing of IRQ_INPROGRESS.  I missed
> this case earlier.

OK, here is the patch again with a changelog:

[IRQ]: Fix synchronize_irq races with IRQ handler

As it is some callers of synchronize_irq rely on memory barriers
to provide synchronisation against the IRQ handlers.  For example,
the tg3 driver does

tp->irq_sync = 1;
smp_mb();
synchronize_irq();

and then in the IRQ handler:

if (!tp->irq_sync)
netif_rx_schedule(dev, >napi);

Unfortunately memory barriers only work well when they come in
pairs.  Because we don't actually have memory barriers on the
IRQ path, the memory barrier before the synchronize_irq() doesn't
actually protect us.

In particular, synchronize_irq() may return followed by the
result of netif_rx_schedule being made visible.

This patch (mostly written by Linus) fixes this by using spin
locks instead of memory barries on the synchronize_irq() path.

Signed-off-by: Herbert Xu <[EMAIL PROTECTED]>

Thanks,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
--
diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 80eab7a..1f31422 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -29,12 +29,28 @@
 void synchronize_irq(unsigned int irq)
 {
struct irq_desc *desc = irq_desc + irq;
+   unsigned int status;
 
if (irq >= NR_IRQS)
return;
 
-   while (desc->status & IRQ_INPROGRESS)
-   cpu_relax();
+   do {
+   unsigned long flags;
+
+   /*
+* Wait until we're out of the critical section.  This might
+* give the wrong answer due to the lack of memory barriers.
+*/
+   while (desc->status & IRQ_INPROGRESS)
+   cpu_relax();
+
+   /* Ok, that indicated we're done: double-check carefully. */
+   spin_lock_irqsave(>lock, flags);
+   status = desc->status;
+   spin_unlock_irqrestore(>lock, flags);
+
+   /* Oops, that failed? */
+   } while (status & IRQ_INPROGRESS);
 }
 EXPORT_SYMBOL(synchronize_irq);
 
-
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: broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[David Miller]

From: Erez Zadok <[EMAIL PROTECTED]>
Date: Fri, 19 Oct 2007 00:33:09 -0400

> Call Trace:
>  [] show_trace_log_lvl+0x1a/0x2f
>  [] show_stack_log_lvl+0x9b/0xa3
>  [] show_registers+0x1b4/0x285
>  [] die+0x100/0x21d
>  [] do_page_fault+0x434/0x515
>  [] error_code+0x6a/0x70
>  [] sock_setsockopt+0x43f/0x494
>  [] sys_setsockopt+0x4f/0x85
>  [] sys_socketcall+0x1cb/0x222
>  [] sysenter_past_esp+0x5f/0x91

This fix from Olof Johnson should fix it.

I'll merge this tonight.

diff --git a/net/core/filter.c b/net/core/filter.c
index 1f0068e..e0a0694 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -447,7 +447,8 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock 
*sk)
rcu_assign_pointer(sk->sk_filter, fp);
rcu_read_unlock_bh();
 
-   sk_filter_delayed_uncharge(sk, old_fp);
+   if (old_fp)
+   sk_filter_delayed_uncharge(sk, old_fp);
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/

[M68KNOMMU]: fix syscall restart handling

[Greg Ungerer]

Fix system call restart handling. We can call directly to the
restart handler, no need to back track through trap that isn't
even implemented on m68knommu.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/kernel/signal.c 
linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c
--- linux-2.6.23/arch/m68knommu/kernel/signal.c 2007-10-19 10:30:55.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/signal.c 2007-10-19 
10:35:40.0 +1000
@@ -781,15 +781,7 @@ asmlinkage int do_signal(sigset_t *oldse
/* Did we come from a system call? */
if (regs->orig_d0 >= 0) {
/* Restart the system call - no handlers present */
-   if (regs->d0 == -ERESTARTNOHAND
-   || regs->d0 == -ERESTARTSYS
-   || regs->d0 == -ERESTARTNOINTR) {
-   regs->d0 = regs->orig_d0;
-   regs->pc -= 2;
-   } else if (regs->d0 == -ERESTART_RESTARTBLOCK) {
-   regs->d0 = __NR_restart_syscall;
-   regs->pc -= 2;
-   }
+   handle_restart(regs, NULL, 0);
}
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/

[M68KNOMMU]: no separate stack region to report at startup

[Greg Ungerer]

There is no separate stack region addresses to print at startup time,
so remove it from the debug listing

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c 
linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c  2007-10-19 10:30:54.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c  2007-10-19 
10:35:38.0 +1000
@@ -188,11 +173,9 @@ void setup_arch(char **cmdline_p)
"BSS=0x%06x-0x%06x\n", (int) &_stext, (int) &_etext,
(int) &_sdata, (int) &_edata,
(int) &_sbss, (int) &_ebss);
-   printk(KERN_DEBUG "KERNEL -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x "
-   "STACK=0x%06x-0x%06x\n",
+   printk(KERN_DEBUG "MEMORY -> ROMFS=0x%06x-0x%06x MEM=0x%06x-0x%06x\n ",
(int) &_ebss, (int) memory_start,
-   (int) memory_start, (int) memory_end,
-   (int) memory_end, (int) _ramend);
+   (int) memory_start, (int) memory_end);
 #endif
 
/* Keep a copy of command line */
-
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] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

> What may happen is that action can either float upwards to give
> 
>   spin_lock
>   action
>   set IRQ_INPROGRESS
>   spin_unlock
> 
>   spin_lock
>   clear IRQ_INPROGRESS
>   spin_unlock
> 
> or it can float downwards to give
> 
>   spin_lock
>   set IRQ_INPROGRESS
>   spin_unlock
> 
>   spin_lock
>   clear IRQ_INPROGRESS
>   action
>   spin_unlock
> 

Well, we are generally safer here. That is, unless action is a store,
it will not pass spin_lock, at least not on powerpc afaik.

In fact, if action, as it is in our case, is something like

if (foo)
return;

We cant execute the store inside spin_lock() without having loaded
foo, there is an implicit dependency here.

But anyway, Linus patch fixes that too if it was a problem. Now if
we grep for while (test_bit and while (!test_bit I'm sure we'll find
other similar surprises.

That's also one of the reasons why I _love_ nick patches that add a
proper lock/unlock API on bits, because at least those who are doing
those hand-made pseudo-locks with bitops to save space will be
getting a proper lock/unlock API, no more excuse.

The network stack is doing more fancy things so it's harder (though I
wonder sometimes if it's really worth the risks taken for not using
spinlocks... maybe).

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: broken PCNET32 in 2.6.24 requires experimental PCNET32_NAPI?

[Erez Zadok]

In message <[EMAIL PROTECTED]>, Jeff Garzik writes:
> Erez Zadok wrote:
> > I'm using Linus's git tree as of commit
> > d85714d81cc0408daddb68c10f7fd69eafe7c213.  I built that kernel under vmware
> > workstation 6.0.1 which emulates a pcnet32 nic.  When I only turn on
> > CONFIG_PCNET32, my network interface doesn't seem to come up fully: my dhcp
> > server sees a request, offers an IP addr, but the VM running 2.6.24 doesn't
> > pick up the response.  Manually configuring the eth0 and pinging yields
> > similar results: no replies come back.  The same VM has lots of other
> > kernels on it, all of which work fine (so it's not an iptables/selinux
> > problem, or the like).
> > 
> > If, however, I turn on the EXPERIMENTAL feature CONFIG_PCNET32_NAPI, then
> > the driver works again.  So, is this NAPI feature now a required one or did
> > the base driver somehow got broken?  I've not investigated this further.
> 
> Fixes were posted by the maintainer, and pushed to Linus, yesterday...
> 
>   Jeff

Thanks.  Now, with more patches that Linus committed, I get a different oops
when I try to configure the interface (ifup eth0).  I'm using:

CONFIG_PCNET32=m

And I tried with and without CONFIG_PCNET32_NAPI.

Cheers,
Erez.

--

pcnet32: PCnet/PCI II 79C970A at 0x1080, 00 0c 29 f0 e5 15 assigned IRQ 9.
eth0: registered as PCnet/PCI II 79C970A
pcnet32: 1 cards_found.
EXT3 FS on hda1, internal journal
Adding 522104k swap on /dev/hda2.  Priority:-1 extents:1 across:522104k
eth0: link up
BUG: unable to handle kernel NULL pointer dereference at virtual address
0004
printing eip: c022f03d *pde =  
Oops:  [#1] DEBUG_PAGEALLOC
Modules linked in: pcnet32
CPU:0
EIP:0060:[]Not tainted VLI
EFLAGS: 00010246   (2.6.23-unionfs2-2.6.24-rc0-pre #7)
EIP is at sk_filter_delayed_uncharge+0x1/0x22
eax: c1d21bf0   ebx:    ecx: c022f1a7   edx: 
esi: c1ffdf70   edi: c1d21bf0   ebp: c3e13f04   esp: c3e13ed4
ds: 007b   es: 007b   fs:   gs: 0033  ss: 0068
Process dhclient (pid: 1221, ti=c3e12000 task=c1edf5b0 task.ti=c3e12000)
Stack: c3e13f04 c022f1ff 0002 0001 c022f1a7 0068 c1ffdf80
0058 
    c1d21bf0 c3e13f2c c4435d90 c3e13f50 c021ea1b c17a08e0
c3d121c0 
   36947065 c3d8ae28 001a 000b 000b c1ff0800 000b
80070600 
Call Trace:
 [] show_trace_log_lvl+0x1a/0x2f
 [] show_stack_log_lvl+0x9b/0xa3
 [] show_registers+0x1b4/0x285
 [] die+0x100/0x21d
 [] do_page_fault+0x434/0x515
 [] error_code+0x6a/0x70
 [] sock_setsockopt+0x43f/0x494
 [] sys_setsockopt+0x4f/0x85
 [] sys_socketcall+0x1cb/0x222
 [] sysenter_past_esp+0x5f/0x91
 ===
Code: 18 01 39 d0 7d 19 43 4e 39 d3 0f 8c 3d fe ff ff 0f b7 44 d1 f8 31 d2
83 e0 
07 83 f8 06 74 05 ba ea ff ff ff 5b 89 d0 5e 5d c3 55 <8b> 4a 04 89 e5 8d 0c
cd 1
0 00 00 00 29 88 b8 00 00 00 8d 42 08 
EIP: [] sk_filter_delayed_uncharge+0x1/0x22 SS:ESP 0068:c3e13ed4

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

[M68KNOMMU]: remove use of undefined symbols in setup.c

[Greg Ungerer]

Remove use of undefined symbols CONFIG_TELOS, CONFIG_M68EZ328ADS
and CONFIG_ALMA_ANS.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/kernel/setup.c 
linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c
--- linux-2.6.23/arch/m68knommu/kernel/setup.c  2007-10-19 10:30:54.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/kernel/setup.c  2007-10-19 
10:35:38.0 +1000
@@ -151,27 +148,15 @@ void setup_arch(char **cmdline_p)
 #ifdef CONFIG_ELITE
printk(KERN_INFO "Modified for M5206eLITE by Rob Scott, [EMAIL 
PROTECTED]");
 #endif
-#ifdef CONFIG_TELOS
-   printk(KERN_INFO "Modified for Omnia ToolVox by James D. Schettine, 
[EMAIL PROTECTED]");
-#endif
 #endif
printk(KERN_INFO "Flat model support (C) 1998,1999 Kenneth Albanowski, 
D. Jeff Dionne\n");
 
 #if defined( CONFIG_PILOT ) && defined( CONFIG_M68328 )
printk(KERN_INFO "TRG SuperPilot FLASH card support <[EMAIL 
PROTECTED]>\n");
 #endif
-
 #if defined( CONFIG_PILOT ) && defined( CONFIG_M68EZ328 )
printk(KERN_INFO "PalmV support by Lineo Inc. <[EMAIL PROTECTED]>\n");
 #endif
-
-#ifdef CONFIG_M68EZ328ADS
-   printk(KERN_INFO "M68EZ328ADS board support (C) 1999 Vladimir Gurevich 
<[EMAIL PROTECTED]>\n");
-#endif
-
-#ifdef CONFIG_ALMA_ANS
-   printk(KERN_INFO "Alma Electronics board support (C) 1999 Vladimir 
Gurevich <[EMAIL PROTECTED]>\n");
-#endif
 #if defined (CONFIG_M68360)
printk(KERN_INFO "QUICC port done by SED Systems <[EMAIL 
PROTECTED]>,\n");
printk(KERN_INFO "based on 2.0.38 port by Lineo Inc. <[EMAIL 
PROTECTED]>.\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/

[M68KNOMMU]: add make support for Savant/Rosie1 board

[Greg Ungerer]

From: Wilson Callan <[EMAIL PROTECTED]>

Add make support for the Savant/Rosie1 board.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/Makefile 
linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile2007-10-19 10:30:58.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/Makefile2007-10-19 10:35:41.0 
+1000
@@ -48,6 +48,7 @@ board-$(CONFIG_SNEHA) := SNEHA
 board-$(CONFIG_M5208EVB)   := M5208EVB
 board-$(CONFIG_MOD5272):= MOD5272
 board-$(CONFIG_AVNET)   := AVNET
+board-$(CONFIG_SAVANT) := SAVANT
 BOARD := $(board-y)
 
 model-$(CONFIG_RAMKERNEL)  := ram
-
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/

[M68KNOMMU]: add config support for Savant/Rosie1 board

[Greg Ungerer]

From: Wilson Callan <[EMAIL PROTECTED]>

Add configure support for the Savant/Rosie1 board.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/Kconfig 
linux-2.6.23-uc0/arch/m68knommu/Kconfig
--- linux-2.6.23/arch/m68knommu/Kconfig 2007-10-19 10:30:57.0 +1000
+++ linux-2.6.23-uc0/arch/m68knommu/Kconfig 2007-10-19 10:35:41.0 
+1000
@@ -451,6 +451,12 @@ config MOD5272
help
  Support for the Netburner MOD-5272 board.
 
+config SAVANTrosie1
+   bool "Savant Rosie1 board support"
+   depends on M523x
+   help
+ Support for the Savant Rosie1 board.
+
 config ROMFS_FROM_ROM
bool "ROMFS image not RAM resident"
depends on (NETtel || SNAPGEAR)
@@ -492,7 +498,12 @@ config SNEHA
 bool
default y
depends on CPU16B
-   
+
+config SAVANT
+   bool
+   default y
+   depends on SAVANTrosie1
+
 config AVNET
bool
default y
-
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] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

On Fri, 2007-10-19 at 12:20 +0800, Herbert Xu wrote:
> 
> That's why I think this patch is in fact the only one that
> solves all the races in this thread.  The case that it solves
> which the lock/unlock patch does not is the one where action
> flows downwards past the clearing of IRQ_INPROGRESS.  I missed
> this case earlier.
> 
> In fact this bug exists elsewhere too.  For example, the network
> stack does this in net/sched/sch_generic.c:
> 
> /* Wait for outstanding qdisc_run calls. */
> while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
> yield();
> 
> This has the same problem as the current synchronize_irq code.

The network stack always made be nervous with it's bitops use as locks.
Any loop of test_bit() alone as a synchronisation method, without locks
or barriers is, imho, inherently buggy.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

> The whole lock/set IRQ_INPROGRESS/unlock path can then only happen
> before the locked section above, in which case we see and wait nicely
> and all is good, or after, in which case the store to foo will be
> visible to the IRQ handler as it will be ordered with the unlock in the
> code above.

Note that napi_synchronize needs a slightly different treatement.

Here, the situation boils down to:

one CPU does:

foo = 1;
while(test_bit(bar))
barrier();

and the other:

if (!test_and_set_bit(bar)) {
read & use foo
smp_mb__before_clear_bit();
clear_bit(bar);
}

The good thing here is that read & use foo is part of the critical
section (I hate hand-made locks ...) defined by bar which makes
things somewhat easier than the synchronize_irq() case.

I think a simple smp_mb(); here after foo = 1; is enough, which means
basically just having an smp_mp(); inside napi_synchronize(), before
the test_bit(). Or do I miss something ?

Cheers,
Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

In function sysctl_check_lookup: undef ref to sysctl_head_next

[Avuton Olrich]

Good Day,

My randconfig just caught an error on:
kernel/built-in.o: In function `sysctl_check_lookup':
sysctl_check.c:(.text+0x17db1): undefined reference to `sysctl_head_next'
sysctl_check.c:(.text+0x17dc7): undefined reference to `sysctl_head_finish'

Git bisect was unsuccessful due to too many unrelated errors trying to
track down the issue. I also couldn't track down the offending
function. Any idea of the issue?

Against this config: http://avuton.googlepages.com/sysctl-head-next.config

git master: 4fa4d23fa20de67df919030c1216295664866ad7

Thanks,
-- 
avuton
--
 Anyone who quotes me in their sig is an idiot. -- Rusty Russell.
-
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] synchronize_irq needs a barrier

[Herbert Xu]

On Thu, Oct 18, 2007 at 08:26:45PM -0700, Linus Torvalds wrote:
> 
> 
> On Thu, 18 Oct 2007, Linus Torvalds wrote:
> >
> > I *think* it should work with something like
> > 
> > for (;;) {
> > smp_rmb();
> > if (!spin_is_locked(>lock)) {
> > smp_rmb();
> > if (!(desc->status & IRQ_INPROGRESS)
> > break;
> > }
> > cpu_relax();
> > }
> 
> I'm starting to doubt this. 
> 
> One of the issues is that we still need the smp_mb() in front of the loop 
> (because we want to serialize the loop with any writes in the caller).

Right.  I think if we accept the definition of a spin lock/unlock
that Nick outlined earlier, then we can see that on the IRQ path
there simply isn't a memory barrier between the changing of the
status field and the execution of the action:

spin_lock
set IRQ_INPROGRESS
spin_unlock

action

spin_lock
clear IRQ_INPROGRESS
spin_unlock

What may happen is that action can either float upwards to give

spin_lock
action
set IRQ_INPROGRESS
spin_unlock

spin_lock
clear IRQ_INPROGRESS
spin_unlock

or it can float downwards to give

spin_lock
set IRQ_INPROGRESS
spin_unlock

spin_lock
clear IRQ_INPROGRESS
action
spin_unlock

As a result we can add as many barriers as we want on the slow
(synchronize_irq) path and it just won't do any good (not unless
we add some barriers on the IRQ path == fast path).

What we do have on the right though is the fact in some ways
action behaves as if it's inside the spin lock even though it's
not.  In particular, action cannot float up past the first spin
lock nor can it float down past the last spin unlock.

> See commit fa490cfd15d7ce0900097cc4e60cfd7a76381138 and ponder. Maybe we 
> should take the same approach here, and do something like
> 
>   repeat:
>   /* Optimistic, no-locking loop */
>   while (desc->status & IRQ_INPROGRESS)
>   cpu_relax();
> 
>   /* Ok, that indicated we're done: double-check carefully */
>   spin_lock_irqsave(>lock, flags);
>   status = desc->status;
>   spin_unlock_irqrestore(>lock, flags);
> 
>   /* Oops, that failed? */
>   if (status & IRQ_INPROGRESS)
>   goto repeat;

That's why I think this patch is in fact the only one that
solves all the races in this thread.  The case that it solves
which the lock/unlock patch does not is the one where action
flows downwards past the clearing of IRQ_INPROGRESS.  I missed
this case earlier.

In fact this bug exists elsewhere too.  For example, the network
stack does this in net/sched/sch_generic.c:

/* Wait for outstanding qdisc_run calls. */
while (test_bit(__LINK_STATE_QDISC_RUNNING, >state))
yield();

This has the same problem as the current synchronize_irq code.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

> 
>   repeat:
>   /* Optimistic, no-locking loop */
>   while (desc->status & IRQ_INPROGRESS)
>   cpu_relax();
> 
>   /* Ok, that indicated we're done: double-check carefully */
>   spin_lock_irqsave(>lock, flags);
>   status = desc->status;
>   spin_unlock_irqrestore(>lock, flags);
> 
>   /* Oops, that failed? */
>   if (status & IRQ_INPROGRESS)
>   goto repeat;
> 
> Hmm?

Paulus and I convinced ourselves that this would work. If we call our
variable that gets set before synchronize_irq and read in the IRQ
handler "foo", we get to:

- writing foo can travel down at most to just before the unlock in the
code above

- reading foo can travel up out of the IRQ handler at most just after
the lock in the code that sets IRQ_INPROGRESS.

The whole lock/set IRQ_INPROGRESS/unlock path can then only happen
before the locked section above, in which case we see and wait nicely
and all is good, or after, in which case the store to foo will be
visible to the IRQ handler as it will be ordered with the unlock in the
code above.

Pfiew !

So Acked-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

Thanks !

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[M68KNOMMU]: define __clear_user macro

[Greg Ungerer]

From: Matt Waddel <[EMAIL PROTECTED]>

Define __clear_user macro, consistent with other architectures.
fs/signalfd.c won't compile without it.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/include/asm-m68knommu/uaccess.h 
linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h
--- linux-2.6.23/include/asm-m68knommu/uaccess.h2007-10-19 
10:21:31.0 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/uaccess.h2007-10-19 
10:32:28.0 +1000
@@ -170,10 +170,12 @@ static inline long strnlen_user(const ch
  */
 
 static inline unsigned long
-clear_user(void *to, unsigned long n)
+__clear_user(void *to, unsigned long n)
 {
memset(to, 0, n);
return 0;
 }
 
+#defineclear_user(to,n)__clear_user(to,n)
+
 #endif /* _M68KNOMMU_UACCESS_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/

[GIT PULL] m32r: updates to add missing syscalls

[Hirokazu Takata]

Hello, Linus,

Please pull from:
  git://www.linux-m32r.org/git/takata/linux-2.6_dev.git for-linus

This patchset adds missing m32r syscalls for 2.6.23 kernel.

It has been included in 2.6.23-mm1 kernel and tested for a while.

-- Takata

Hirokazu Takata (3):
  m32r: Add missing syscalls
  m32r: Ignore warnings for unused syscalls
  m32r: Update sys_rt_sigsuspend

 arch/m32r/kernel/signal.c|   17 --
 arch/m32r/kernel/syscall_table.S |   40 +++
 include/asm-m32r/thread_info.h   |   11 --
 include/asm-m32r/unistd.h|   66 +-
 4 files changed, 120 insertions(+), 14 deletions(-)

[Log messages and full diffs follow]

commit 1ae487048901ada4c49b6e88cee6a1b15a477b17
Author: Hirokazu Takata <[EMAIL PROTECTED]>
Date:   Wed Sep 12 17:51:35 2007 +0900

m32r: Update sys_rt_sigsuspend

Update sys_rt_sigsuspend() of arch/m32r/signal.c.
This modification is derived from generic one of kernel/signal.c.

Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>

diff --git a/arch/m32r/kernel/signal.c b/arch/m32r/kernel/signal.c
index 916faf6..650a6a1 100644
--- a/arch/m32r/kernel/signal.c
+++ b/arch/m32r/kernel/signal.c
@@ -36,7 +36,7 @@ sys_rt_sigsuspend(sigset_t __user *unewset, size_t sigsetsize,
  unsigned long r2, unsigned long r3, unsigned long r4,
  unsigned long r5, unsigned long r6, struct pt_regs *regs)
 {
-   sigset_t saveset, newset;
+   sigset_t newset;
 
/* XXX: Don't preclude handling different sized sigset_t's.  */
if (sigsetsize != sizeof(sigset_t))
@@ -44,21 +44,18 @@ sys_rt_sigsuspend(sigset_t __user *unewset, size_t 
sigsetsize,
 
if (copy_from_user(, unewset, sizeof(newset)))
return -EFAULT;
-   sigdelsetmask(, ~_BLOCKABLE);
+   sigdelsetmask(, sigmask(SIGKILL)|sigmask(SIGSTOP));
 
spin_lock_irq(>sighand->siglock);
-   saveset = current->blocked;
+   current->saved_sigmask = current->blocked;
current->blocked = newset;
recalc_sigpending();
spin_unlock_irq(>sighand->siglock);
 
-   regs->r0 = -EINTR;
-   while (1) {
-   current->state = TASK_INTERRUPTIBLE;
-   schedule();
-   if (do_signal(regs, ))
-   return regs->r0;
-   }
+   current->state = TASK_INTERRUPTIBLE;
+   schedule();
+   set_thread_flag(TIF_RESTORE_SIGMASK);
+   return -ERESTARTNOHAND;
 }
 
 asmlinkage int
diff --git a/include/asm-m32r/thread_info.h b/include/asm-m32r/thread_info.h
index c039820..1effcd0 100644
--- a/include/asm-m32r/thread_info.h
+++ b/include/asm-m32r/thread_info.h
@@ -149,16 +149,21 @@ static inline unsigned int get_thread_fault_code(void)
 #define TIF_NEED_RESCHED   2   /* rescheduling necessary */
 #define TIF_SINGLESTEP 3   /* restore singlestep on return to user 
mode */
 #define TIF_IRET   4   /* return with iret */
-#define TIF_POLLING_NRFLAG 16  /* true if poll_idle() is polling 
TIF_NEED_RESCHED */
-   /* 31..28 fault code */
-#define TIF_MEMDIE 17
+#define TIF_RESTORE_SIGMASK8   /* restore signal mask in do_signal() */
+#define TIF_USEDFPU16  /* FPU was used by this task this 
quantum (SMP) */
+#define TIF_POLLING_NRFLAG 17  /* true if poll_idle() is polling 
TIF_NEED_RESCHED */
+#define TIF_MEMDIE 18  /* OOM killer killed process */
+#define TIF_FREEZE 19  /* is freezing for suspend */
 
 #define _TIF_SYSCALL_TRACE (1<
Date:   Thu Sep 13 18:31:34 2007 +0900

m32r: Ignore warnings for unused syscalls

checksyscalls.sh reports warnings for missing syscalls.
But, on m32r, some legacy syscalls were removed elaborately.

This patch kills warnings for obsolete syscalls, which are
no longer used in the m32r kernel.

Signed-off-by: Hirokazu Takata <[EMAIL PROTECTED]>

diff --git a/include/asm-m32r/unistd.h b/include/asm-m32r/unistd.h
index d202aa9..f467eac 100644
--- a/include/asm-m32r/unistd.h
+++ b/include/asm-m32r/unistd.h
@@ -351,6 +351,30 @@
 #define __ARCH_WANT_SYS_OLDUMOUNT
 #define __ARCH_WANT_SYS_RT_SIGACTION
 
+#define __IGNORE_lchown
+#define __IGNORE_setuid
+#define __IGNORE_getuid
+#define __IGNORE_setgid
+#define __IGNORE_getgid
+#define __IGNORE_geteuid
+#define __IGNORE_getegid
+#define __IGNORE_fcntl
+#define __IGNORE_setreuid
+#define __IGNORE_setregid
+#define __IGNORE_getrlimit
+#define __IGNORE_getgroups
+#define __IGNORE_setgroups
+#define __IGNORE_select
+#define __IGNORE_mmap
+#define __IGNORE_fchown
+#define __IGNORE_setfsuid
+#define __IGNORE_setfsgid
+#define __IGNORE_setresuid
+#define __IGNORE_getresuid
+#define __IGNORE_setresgid
+#define __IGNORE_getresgid
+#define __IGNORE_chown
+
 /*
  * "Conditional" syscalls
  *

commit 46e3cc575f3c6284d9bbcda78ab6462b3a22dce3
Author: 

Re: [PATCH 1/5] Use wake_up_locked() in eventpoll

[Arjan van de Ven]

On Thu, 18 Oct 2007 18:25:58 -0400
Matthew Wilcox <[EMAIL PROTECTED]> wrote:

Have you tested this patch with LOCKDEP enabled? eventpoll is... tricky
in what it does with waitqueues and locks and some of this stuff is
there, afaik, to deal with that. You're now changing this ... call me
chicken :)
-
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/

[M68KNOMMU]: remove use of undefined symbol CONFIG_DISKtel (more)

[Greg Ungerer]

Remove use of undefined symbol CONFIG_DISKtel.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/include/asm-m68knommu/system.h 
linux-2.6.23-uc0/include/asm-m68knommu/system.h
--- linux-2.6.23/include/asm-m68knommu/system.h 2007-10-19 10:21:31.0 
+1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/system.h 2007-10-19 
10:32:28.0 +1000
@@ -253,8 +253,7 @@ cmpxchg(volatile int *p, int old, int ne
 ");\
 })
 #elif defined(CONFIG_NETtel) || defined(CONFIG_eLIA) || \
-  defined(CONFIG_DISKtel) || defined(CONFIG_SECUREEDGEMP3) || \
-  defined(CONFIG_CLEOPATRA)
+  defined(CONFIG_SECUREEDGEMP3) || defined(CONFIG_CLEOPATRA)
 #define HARD_RESET_NOW() ({\
 asm("  \
movew #0x2700, %sr; \
-
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/

[M68KNOMMU]: local module/elf definitions

[Greg Ungerer]

Up to now m68knommu has been using the asm-m68k/module.h instead of
defining its own. There are recent changes there that we don't need
(fixups specifically). We don't need much support here so it makes
sense to have an m68knommu specific one now.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/include/asm-m68knommu/module.h 
linux-2.6.23-uc0/include/asm-m68knommu/module.h
--- linux-2.6.23/include/asm-m68knommu/module.h 2007-10-19 10:21:30.0 
+1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/module.h 2007-10-19 
10:32:26.0 +1000
@@ -1 +1,11 @@
-#include 
+#ifndef ASM_M68KNOMMU_MODULE_H
+#define ASM_M68KNOMMU_MODULE_H
+
+struct mod_arch_specific {
+};
+
+#define Elf_Shdr Elf32_Shdr
+#define Elf_Sym Elf32_Sym
+#define Elf_Ehdr Elf32_Ehdr
+
+#endif /* ASM_M68KNOMMU_MODULE_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/

[M68KNOMMU]: remove use of undefined symbol CONFIG_DISKtel

[Greg Ungerer]

Remove use of undefined symbol CONFIG_DISKtel.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/include/asm-m68knommu/mcfuart.h 
linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h
--- linux-2.6.23/include/asm-m68knommu/mcfuart.h2007-10-19 
10:21:30.0 +1000
+++ linux-2.6.23-uc0/include/asm-m68knommu/mcfuart.h2007-10-19 
10:32:26.0 +1000
@@ -12,7 +12,6 @@
 #definemcfuart_h
 //
 
-
 /*
  * Define the base address of the UARTS within the MBAR address
  * space.
@@ -33,7 +32,7 @@
 #define MCFUART_BASE2  0x240   /* Base address of UART2 */
 #define MCFUART_BASE3  0x280   /* Base address of UART3 */
 #elif defined(CONFIG_M5249) || defined(CONFIG_M5307) || defined(CONFIG_M5407)
-#if defined(CONFIG_NETtel) || defined(CONFIG_DISKtel) || 
defined(CONFIG_SECUREEDGEMP3)
+#if defined(CONFIG_NETtel) || defined(CONFIG_SECUREEDGEMP3)
 #define MCFUART_BASE1  0x200   /* Base address of UART1 */
 #define MCFUART_BASE2  0x1c0   /* Base address of UART2 */
 #else
-
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 / HP6XX] : Add Timer values into HD64461.h

[Paul Mundt]

On Thu, Oct 18, 2007 at 09:39:04PM -0700, Kristoffer Ericson wrote:
> This patch adds HD64461 Timer adresses & registers to the HD64461
> header file (/include/asm-sh/hd64461.h).  The timers (TMU0 & TMU1) can
> hold 16bit values and auto loads the counter constant when it reaches
> zero. Upon reaching zero it generates an interrupt.
> 
> Signed-off-by: Kristoffer Ericson <[EMAIL PROTECTED]>
> 
There's nothing that uses these, so why are you adding them? If you plan
on hooking these up in the hd64461 or TMU code, submit these definitions
along with the code that uses them.
-
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/

[M68KNOMMU]: improve code formating FEC driver

[Greg Ungerer]

From: Philippe De Muyter <[EMAIL PROTECTED]>

Indent all the `else' the same way.
Remove some unecesary white space.

Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c  2007-10-19 10:25:49.0 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c  2007-10-19 10:34:22.0 +1000
@@ -753,13 +753,11 @@ mii_queue(struct net_device *dev, int re
if (mii_head) {
mii_tail->mii_next = mip;
mii_tail = mip;
-   }
-   else {
+   } else {
mii_head = mii_tail = mip;
fep->hwp->fec_mii_data = regval;
}
-   }
-   else {
+   } else {
retval = 1;
}
 
@@ -794,7 +789,6 @@ static void mii_parse_sr(uint mii_reg, s
status |= PHY_STAT_FAULT;
if (mii_reg & 0x0020)
status |= PHY_STAT_ANC;
-
*s = status;
 }
 
@@ -1241,7 +1235,6 @@ mii_link_interrupt(int irq, void * dev_i
 #endif
 
 #if defined(CONFIG_M5272)
-
 /*
  * Code specific to Coldfire 5272 setup.
  */
@@ -2022,8 +2015,7 @@ static void mii_relink(struct work_struc
& (PHY_STAT_100FDX | PHY_STAT_10FDX))
duplex = 1;
fec_restart(dev, duplex);
-   }
-   else
+   } else
fec_stop(dev);
 
 #if 0
@@ -2121,8 +2113,7 @@ mii_discover_phy(uint mii_reg, struct ne
fep->phy_id = phytype << 16;
mii_queue(dev, mk_mii_read(MII_REG_PHYIR2),
mii_discover_phy3);
-   }
-   else {
+   } else {
fep->phy_addr++;
mii_queue(dev, mk_mii_read(MII_REG_PHYIR1),
mii_discover_phy);
@@ -2584,8 +2575,7 @@ fec_restart(struct net_device *dev, int 
if (duplex) {
fecp->fec_r_cntrl = OPT_FRAME_SIZE | 0x04;/* MII enable */
fecp->fec_x_cntrl = 0x04; /* FD enable */
-   }
-   else {
+   } else {
/* MII enable|No Rcv on Xmit */
fecp->fec_r_cntrl = OPT_FRAME_SIZE | 0x06;
fecp->fec_x_cntrl = 0x00;
-
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/

[M68KNOMMU]: improve mii_do_cmd code in FEC driver

[Greg Ungerer]

From: Philippe De Muyter <[EMAIL PROTECTED]>

Improve the readability of mii_do_cmd().

Signed-off-by: Philippe De Muyter <[EMAIL PROTECTED]>
Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/drivers/net/fec.c linux-2.6.23-uc0/drivers/net/fec.c
--- linux-2.6.23/drivers/net/fec.c  2007-10-19 10:25:49.0 +1000
+++ linux-2.6.23-uc0/drivers/net/fec.c  2007-10-19 10:34:22.0 +1000
@@ -770,14 +768,11 @@ mii_queue(struct net_device *dev, int re
 
 static void mii_do_cmd(struct net_device *dev, const phy_cmd_t *c)
 {
-   int k;
-
if(!c)
return;
 
-   for(k = 0; (c+k)->mii_data != mk_mii_end; k++) {
-   mii_queue(dev, (c+k)->mii_data, (c+k)->funct);
-   }
+   for (; c->mii_data != mk_mii_end; c++)
+   mii_queue(dev, c->mii_data, c->funct);
 }
 
 static void mii_parse_sr(uint mii_reg, struct net_device *dev)
-
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] [kexec-tools] Pass vmcoreinfo's address and size

[Simon Horman]

On Thu, Oct 18, 2007 at 06:14:07PM +0900, [EMAIL PROTECTED] wrote:
> 
> Hi Simon,
> 
> On Thu, 18 Oct 2007 14:37:41 +0900, Simon Horman <[EMAIL PROTECTED]> wrote:
> > On Wed, Oct 17, 2007 at 02:16:19PM +0900, Ken'ichi Ohmichi wrote:
> > > 
> > > Hi Simon,
> > > 
> > > Simon Horman wrote:
> > > > On Wed, Aug 22, 2007 at 09:13:39PM +0900, Ken'ichi Ohmichi wrote:
> > > >> [2/3] [kexec-tools] Pass vmcoreinfo's address and size
> > > >> The patch is for kexec-tools-testing-20070330.
> > > >> (http://www.kernel.org/pub/linux/kernel/people/horms/kexec-tools/)
> > > >> kexec command gets the address and size of the vmcoreinfo data from
> > > >> /sys/kernel/vmcoreinfo, and passes them to the second kernel through
> > > >> ELF header of /proc/vmcore. When the second kernel is booting, the
> > > >> kernel gets them from the ELF header and creates vmcoreinfo's PT_NOTE
> > > >> segment into /proc/vmcore.
> > > > 
> > > > Sorry for the long delay, I completely missed this patch.
> > > > 
> > > > The kexec-tools change seems ok to me. What is the status of
> > > > the kernel portion of the change?
> > > 
> > > The kernel portion is merged into linux-2.6.23-mm1.
> > > According to Andrew's mail "-mm merge plans for 2.6.24",  its status is
> > > "The infamous misc.  Will re-review and will merge basically all of them".
> > > 
> > > http://www.ussg.iu.edu/hypermail/linux/kernel/0710.0/0313.html
> > > 
> > > 
> > > > Do you still want the kexec-tools portion applied?
> > > 
> > > Yes, I hope so.
> > 
> > Thanks, applied :-)
> 
> Thank you for applying ;-)
> 
> But it has the compatibility problem that the kexec command fails on
> kernels which don't have /sys/kernel/vmcoreinfo:
> 
>  # ls /sys/kernel/
>  debug  kexec_crash_loaded  kexec_loaded  security  uevent_helper 
>  uevent_seqnum
>  #
>  (There is not /sys/kernel/vmcoreinfo.)
> 
>  #
>  # kexec -p --args-linux vmlinuz --initrd=initrd.img
>  Could not open "/sys/kernel/vmcoreinfo": No such file or directory
>  #
> 
> To fix the problem, could you please apply the attached patch ?
> The fixed part is the same as the patch in the following mail.

Thanks, applied.
-
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: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards

[Kenji Kaneshige]

Mark Lord さんは書きました:
> Kenji Kaneshige wrote:
>>
>>  - When the card is inserted *after* modprobing pciehp, the card
>>is *not* automatically powered on/detected. So it is very
>>natural that the card, which had been inserted before modprobing
>>pciehp, is not automatically enabled at the pciehp modprobe time.
> 
> 
> Not true.  Once pciehp is loaded, it automatically detects and handles
> inserted and removed cards just fine.  Until after the next suspend/resume.
> 

This is because your slot is surprise remove capable. On my slot,
which is not surprise remove capable, the card is not enabled
even after pciehp is loaded.

Thanks,
Kenji Kaneshige


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

nVidia HPET force enable - merge requirements? (resend)

[Carlos Corbacho]

(Resend with CC's fixed)

Back in April, Mikko posted a patch to force enable the HPET on some nVidia 
chipsets:

v2:
http://lkml.org/lkml/2007/4/16/46

v3:
http://lkml.org/lkml/2007/4/17/354

What would need to be done to this patch to get it into x86 now (besides i386/ 
x86_64 -> x86 conversion), given that:

A) There is now a force_hpet boot parameter in the x86 tree (mm branch) 
(rather than relying on the solution in the earlier patches of a config 
option).

B) On the other hand, the force-quirk's are going into quirks.c, whilst 
Mikko's patch requires PCI scanning in early_quirks.c (could the PCI scanning 
be done in early_quirks.c and the actual HPET enabling handled in quirks.c 
later - or if not, could this early quirk play be made to obey the force_hpet 
boot option)?

-Carlos
-- 
E-Mail: [EMAIL PROTECTED]
Web: strangeworlds.co.uk
GPG Key ID: 0x23EE722D
-
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] synchronize_irq needs a barrier

[Herbert Xu]

Nick Piggin <[EMAIL PROTECTED]> wrote:
> 
>> First of all let's agree on some basic assumptions:
>>
>> * A pair of spin lock/unlock subsumes the effect of a full mb.
> 
> Not unless you mean a pair of spin lock/unlock as in
> 2 spin lock/unlock pairs (4 operations).
> 
> *X = 10;
> spin_lock();
> /* *Y speculatively loaded here */
> /* store to *X leaves CPU store queue here */
> spin_unlock();
> y = *Y;

Good point.

Although in this case we're still safe because in the worst
cases:

CPU0CPU1
irq_sync = 1
synchronize_irq
spin lock
load IRQ_INPROGRESS
irq_sync sync is visible
spin unlock
spin lock
load irq_sync
while (IRQ_INPROGRESS)
wait
return
set IRQ_INPROGRESS
spin unlock
tg3_msi
ack IRQ
if (irq_sync)
return
spin lock
clear IRQ_INPROGRESS
spin unlock



CPU0CPU1
spin lock
load irq_sync
irq_sync = 1
synchronize_irq
set IRQ_INPROGRESS
spin unlock
spin lock
load IRQ_INPROGRESS
irq_sync sync is visible
spin unlock
while (IRQ_INPROGRESS)
wait
tg3_msi
ack IRQ
if (irq_sync)
return
do work
spin lock
clear IRQ_INPROGRESS
spin unlock
return

So because we're using the same lock on both sides, it does
do the right thing even without the memory barrier.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
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] synchronize_irq needs a barrier

[Linus Torvalds]

On Thu, 18 Oct 2007, Linus Torvalds wrote:
>
> I *think* it should work with something like
> 
>   for (;;) {
>   smp_rmb();
>   if (!spin_is_locked(>lock)) {
>   smp_rmb();
>   if (!(desc->status & IRQ_INPROGRESS)
>   break;
>   }
>   cpu_relax();
>   }

I'm starting to doubt this. 

One of the issues is that we still need the smp_mb() in front of the loop 
(because we want to serialize the loop with any writes in the caller).

The other issue is that I don't think it's enough that we saw the 
descriptor lock unlocked, and then the IRQ_INPROGRESS bit clear. It might 
have been unlocked *while* the IRQ was in progress, but the interrupt 
handler is now in its last throes, and re-takes the spinlock and clears 
the IRQ_INPROGRESS thing. But we're not actually happy until we've seen 
the IRQ_INPROGRESS bit clear and the spinlock has been released *again*.

So those two tests should actually be the other way around: we want to see 
the IRQ_INPROGRESS bit clear first.

It's all just too damn subtle and clever. Something like this should not 
need to be that subtle. 

Maybe the rigth thing to do is to not rely on *any* ordering what-so-ever, 
and just make the rule be: "if you look at the IRQ_INPROGRESS bit, you'd 
better hold the descriptor spinlock", and not have any subtle ordering 
issues at all.

But that makes us have a loop with getting/releasing the lock all the 
time, and then we get back to horrid issues with cacheline bouncing and 
unfairness of cache accesses across cores (ie look at the issues we had 
with the runqueue starvation in wait_task_inactive()).

Those were fixed by starting out with the non-locked and totally unsafe 
versions, but then having one last "check with lock held, and repeat only 
if that says things went south". 

See commit fa490cfd15d7ce0900097cc4e60cfd7a76381138 and ponder. Maybe we 
should take the same approach here, and do something like

repeat:
/* Optimistic, no-locking loop */
while (desc->status & IRQ_INPROGRESS)
cpu_relax();

/* Ok, that indicated we're done: double-check carefully */
spin_lock_irqsave(>lock, flags);
status = desc->status;
spin_unlock_irqrestore(>lock, flags);

/* Oops, that failed? */
if (status & IRQ_INPROGRESS)
goto repeat;

Hmm?

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

[IA64] Reduce __clear_bit_unlock overhead

[Christoph Lameter]

On Fri, 19 Oct 2007, Nick Piggin wrote:

> I'm not sure, I had an idea it was relatively expensive on ia64,
> but I didn't really test with a good workload (a microbenchmark
> probably isn't that good because it won't generate too much out
> of order memory traffic that needs to be fenced).

Its expensive on IA64. Is it any less expensive on x86?

> > Where can I find your patchset? I looked through lkml but did not see it.
> 
> Infrastructure in -mm, starting at bitops-introduce-lock-ops.patch.
> bit_spin_lock-use-lock-bitops.patch and ia64-lock-bitops.patch are
> ones to look at.

ia64-lock-bitops.patch defines:

static __inline__ void
clear_bit_unlock (int nr, volatile void *addr)
{
   __u32 mask, old, new;
   volatile __u32 *m;
   CMPXCHG_BUGCHECK_DECL

   m = (volatile __u32 *) addr + (nr >> 5);
   mask = ~(1 << (nr & 31));
   do {
   CMPXCHG_BUGCHECK(m);
   old = *m;
   new = old & mask;
   } while (cmpxchg_rel(m, old, new) != old);
}

/**
 * __clear_bit_unlock - Non-atomically clear a bit with release
 *
 * This is like clear_bit_unlock, but the implementation may use a non-atomic
 * store (this one uses an atomic, however).
 */
#define __clear_bit_unlock clear_bit_unlock


A non atomic store is a misaligned store on IA64. That is not 
relevant here. The data is properly aligned. I guess it was intended to
refer to the cmpxchg.

How about this patch? [Works fine on IA64 simulator...]




IA64: Slim down __clear_bit_unlock

__clear_bit_unlock does not need to perform atomic operations on the variable.
Avoid a cmpxchg and simply do a store with release semantics. Add a barrier to
be safe that the compiler does not do funky things.

Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

---
 include/asm-ia64/bitops.h |   12 
 1 file changed, 12 insertions(+)

Index: linux-2.6.23-mm1/include/asm-ia64/bitops.h
===
--- linux-2.6.23-mm1.orig/include/asm-ia64/bitops.h 2007-10-18 
19:37:22.0 -0700
+++ linux-2.6.23-mm1/include/asm-ia64/bitops.h  2007-10-18 19:50:22.0 
-0700
@@ -124,10 +124,21 @@ clear_bit_unlock (int nr, volatile void 
 /**
  * __clear_bit_unlock - Non-atomically clear a bit with release
  *
- * This is like clear_bit_unlock, but the implementation may use a non-atomic
- * store (this one uses an atomic, however).
+ * This is like clear_bit_unlock, but the implementation uses a store
+ * with release semantics. See also __raw_spin_unlock().
  */
-#define __clear_bit_unlock clear_bit_unlock
+static __inline__ void
+__clear_bit_unlock (int nr, volatile void *addr)
+{
+   __u32 mask, new;
+   volatile __u32 *m;
+
+   m = (volatile __u32 *) addr + (nr >> 5);
+   mask = ~(1 << (nr & 31));
+   new = *m & mask;
+   barrier();
+   asm volatile ("st4.rel.nta [%0] = %1\n\t" :: "r"(m), "r"(new));
+}
 
 /**
  * __clear_bit - Clears a bit in memory (non-atomic version)
-
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.22.5] irq X: nobody cared but X is successfully used by libata

[Tejun Heo]

On 26/08/07, Paul Rolland <[EMAIL PROTECTED]> wrote:

My machine (an ASUS P5W-DH-Deluxe, Core2, 4Go RAM, 3 SATA and 2IDE) is
reporting a :
irq 23: nobody cared (try booting with the "irqpoll" option)
together with a Call Trace, but :
 - irqpoll is present on the command line,
 - the irq is reported to be used by libata,
 - the irqpoll option is mandatory if I want _some_ of my SATA disks to be
   accessible.

I've attached a file with :
 - dmesg,
 - cat /proc/interrupts
 - lspci
 - lspci -vvv
 - my .config

I've tried mounting and accessing all the disks, and it works.
The last weird thing : though reported as used by libata, the irq 23 counter
seems to be fixed at 21, though I've mounted and accessed all the
disks !


Does this still happen with 2.6.23?  If so, please post boot log.  Thanks.

--
tejun
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards

[Mark Lord]

Kenji Kaneshige wrote:


 - When the card is inserted *after* modprobing pciehp, the card
   is *not* automatically powered on/detected. So it is very
   natural that the card, which had been inserted before modprobing
   pciehp, is not automatically enabled at the pciehp modprobe time.



Not true.  Once pciehp is loaded, it automatically detects and handles
inserted and removed cards just fine.  Until after the next suspend/resume.

Cheers
-
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] synchronize_irq needs a barrier

[Linus Torvalds]

On Fri, 19 Oct 2007, Herbert Xu wrote:
>
> In other words I think this patch is great :)

Hey, I appreciate it, but I do think that the "spinlock only to 
immediately unlock it again" is pretty horrid.

I'm convinced that there should be some way to do this without actually 
taking the lock. I *think* it should work with something like

for (;;) {
smp_rmb();
if (!spin_is_locked(>lock)) {
smp_rmb();
if (!(desc->status & IRQ_INPROGRESS)
break;
}
cpu_relax();
}

instead. Which basically requires that we see the descriptor lock being 
not held, before we see the IRQ_INPROGRESS bit being clear. Put another 
way: it loops until it sees the lock having been released, and the 
IRQ_INPROGRESS bit being clear after that.

The above requires no serializing instructions on x86, which is a good 
goal (now that smp_rmb() is just a compiler barrier). And it doesn't 
actually have to bounce any cachelines.

And it doesn't have that ugly "get lock only to release it", which just 
makes me go "Eww!".

But it's a bit subtler. It basically depends on the fact that 
spin_unlock() obviously has to make sure that there is a release barrier 
in the unlock, so any writes done (to the IRQ_INPROGRESS bit) within the 
locked region *must* be visible before the spinlock itself has been 
released.

So somebody should:
 - use another pair of eyes and brains to back me up on this.
 - write up some coherent changelog entry, using the emails that have 
   passed back and forth.
 - actually turn the above into a tested patch with a comment.

And I'm pushing for that "somebody" being somebody else than me ;)

Linus
-
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 0/5] Shadow directories

[David Newall]

Al Viro wrote:

On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
  
considerations of this whole scheme. Linux, like most Unix systems, 
has never allowed hard links to directories for a number of reasons;
  
The claim is wrong.  UNIX systems have traditionally allowed the 
superuser to create hard links to directories.  See link(2) for 2.10BSD 
. 
Having got that wrong throws doubt on the argument; perhaps a path can 
simultaneously be a file and a directory.



Learn to read.  Linux has never allowed that.  Most of the Unix systems
do not allow that.


I did read the claim and it is ambiguous, in that it can reasonably be 
read to mean that most UNIX systems never allowed such links, which is 
wrong.  All UNIX systems allowed it until relatively recently.

-
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] sata_nv,ahci: add the ahci legacy mode support to sata_nv

[Jeff Garzik]

peer chen wrote:

I hope one of the following patches can be merged to 2.6.24.
==
http://lkml.org/lkml/2007/10/8/93
http://lkml.org/lkml/2007/9/25/20


Unfortunately I do not feel like this is the right course of action.

Experience from Intel platforms tells us that our users get very unhappy 
when their silicon supports AHCI mode, but they are forced into using a 
less-performant mode.  A popular example is an  OEM whose BIOS 
had no method whatsoever for enabling AHCI -- didn't even program the 
PCI BAR -- even though tests showed the AHCI mode worked just fine when 
manually programmed.


AHCI is more likely to provide a /stable/ Serial ATA experience, because 
the silicon deals primarily with sending and receiving FIS's, and not 
much else.  In constrast, experience has shown the legacy IDE interface 
to be a less reliable method of SATA support.  And certainly AHCI is 
much, much faster with less per-command overhead.


Given that AHCI is both faster and more stable, I feel it is the best 
policy to enable AHCI when the hardware supports it, regardless of PCI 
class code (IDE, SATA, or RAID).




Yes, I agree to set the 'swncq' as default for 2.6.24, after all, for
our server customers, stability is far more important than the new
feature no matter the problem is caused by drive or controller.


Agreed.  Done!

Jeff




-
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] synchronize_irq needs a barrier

[Nick Piggin]

On Friday 19 October 2007 12:32, Herbert Xu wrote:

> First of all let's agree on some basic assumptions:
>
> * A pair of spin lock/unlock subsumes the effect of a full mb.

Not unless you mean a pair of spin lock/unlock as in
2 spin lock/unlock pairs (4 operations).

*X = 10;
spin_lock();
/* *Y speculatively loaded here */
/* store to *X leaves CPU store queue here */
spin_unlock();
y = *Y;

> * A spin lock in general only equates to (SS/SL/LL).
> * A spin unlock in general only equates to (SS/LS).

I don't use the sparc barriers, so they don't come naturally to
me ;)

I think both loads and stores can pass into the critical section
by having the spin_lock pass earlier ops, or by having spin_unlock
be passed by later ones.


> In particular, a load after a spin unlock may pass before the
> spin unlock.
>
> Here is the race (with tg3 as the only example that I know of).
> The driver attempts to quiesce interrupts such that after the
> call to synchronize_irq it is intended that no further IRQ
> handler calls for that device will do any work besides acking
> the IRQ.
>
> Here is how it does it:
>
> CPU0  CPU1
>   spin lock
>   load irq_sync
> irq_sync = 1
> smp_mb
> synchronize_irq()
>   while (IRQ_INPROGRESS)
>   wait
>   return
>   set IRQ_INPROGRESS
>   spin unlock
>   tg3_msi
>   ack IRQ
>   if (irq_sync)
>   return
>   do work
>
> The problem here is that load of irq_sync in the handler has
> passed above the setting of IRQ_INPROGRESS.
>
> Linus's patch fixes it because this becomes:
>
> CPU0  CPU1
>   spin lock
>   load irq_sync
> irq_sync = 1
> smp_mb
> synchronize_irq
>   set IRQ_INPROGRESS
>   spin unlock
>   spin lock
>   spin unlock
>   tg3_msi
>   ack IRQ
>   if (irq_sync)
>   return
>   do work
>   while (IRQ_INPROGRESS)
>   wait
>   spin lock
>   clear IRQ_INPROGRESS
>   spin unlock
>   return
>
> Even though we still do the work on the right we will now notice
> the INPROGRESS flag on the left and wait.
>
> It's hard to fix this in the drivers because they'd either have
> to access the desc lock or add a full mb to the fast path on the
> right.
>
> Once this goes in we can also remove the smp_mb from tg3.c.  BTW,
> a lot of drivers (including the fusion example Ben quoted) call
> synchronize_irq before free_irq.  This is unnecessary because
> the latter already calls it anyway.
>
> Cheers,
-
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: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

[Mike Galbraith]

On Thu, 2007-10-18 at 23:33 +0100, Samuel Thibault wrote:
> Hi,
> 
> Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit :
> > The winner of a very long git bisect session:
> > 
> > unicode diacritics support
> 
> Uh, I fail to see how that could have an impact, I've again checked the
> boundaries, it looks fine, please people have a look.

I too was reluctant to believe the bisect result.  But...

> Could you try something odd?  On your tree that has the change reverted,
> please try the attached patch, which makes the array the same size at it
> would be with the change, possibly triggering bugs in completely other
> parts of the kernel.

That didn't break my box.  However, removing your test patch and
re-applying the revert I generated between git tree and working tree
brought it right back.  With the below applied, diff says there is no
difference between working tree and git tree (except for
vsyscall_32.lds, which is a generated file kbuild leaves lying around).
Per gitk, the git repository is at
d85714d81cc0408daddb68c10f7fd69eafe7c213

diff -uprNX /root/dontdiff git/linux-2.6/drivers/acorn/char/defkeymap-l7200.c 
linux-2.6.23.git/drivers/acorn/char/defkeymap-l7200.c
--- git/linux-2.6/drivers/acorn/char/defkeymap-l7200.c  2007-10-18 
18:55:53.0 +0200
+++ linux-2.6.23.git/drivers/acorn/char/defkeymap-l7200.c   2007-10-18 
19:02:12.0 +0200
@@ -346,7 +346,7 @@ char *func_table[MAX_NR_FUNC] = {
0,
 };
 
-struct kbdiacruc accent_table[MAX_DIACR] = {
+struct kbdiacr accent_table[MAX_DIACR] = {
{'`', 'A', '\300'}, {'`', 'a', '\340'},
{'\'', 'A', '\301'},{'\'', 'a', '\341'},
{'^', 'A', '\302'}, {'^', 'a', '\342'},
diff -uprNX /root/dontdiff git/linux-2.6/drivers/char/consolemap.c 
linux-2.6.23.git/drivers/char/consolemap.c
--- git/linux-2.6/drivers/char/consolemap.c 2007-10-18 18:55:53.0 
+0200
+++ linux-2.6.23.git/drivers/char/consolemap.c  2007-10-18 19:02:12.0 
+0200
@@ -669,29 +669,19 @@ void con_protect_unimap(struct vc_data *
p->readonly = rdonly;
 }
 
-/*
- * Always use USER_MAP. These functions are used by the keyboard,
- * which shouldn't be affected by G0/G1 switching, etc.
- * If the user map still contains default values, i.e. the
- * direct-to-font mapping, then assume user is using Latin1.
- */
 /* may be called during an interrupt */
 u32 conv_8bit_to_uni(unsigned char c)
 {
+   /*
+* Always use USER_MAP. This function is used by the keyboard,
+* which shouldn't be affected by G0/G1 switching, etc.
+* If the user map still contains default values, i.e. the
+* direct-to-font mapping, then assume user is using Latin1.
+*/
unsigned short uni = translations[USER_MAP][c];
return uni == (0xf000 | c) ? c : uni;
 }
 
-int conv_uni_to_8bit(u32 uni)
-{
-   int c;
-   for (c = 0; c < 0x100; c++)
-   if (translations[USER_MAP][c] == uni ||
-  (translations[USER_MAP][c] == (c | 0xf000) && uni == c))
-   return c;
-   return -1;
-}
-
 int
 conv_uni_to_pc(struct vc_data *conp, long ucs) 
 {
diff -uprNX /root/dontdiff git/linux-2.6/drivers/char/keyboard.c 
linux-2.6.23.git/drivers/char/keyboard.c
--- git/linux-2.6/drivers/char/keyboard.c   2007-10-18 18:55:53.0 
+0200
+++ linux-2.6.23.git/drivers/char/keyboard.c2007-10-18 19:02:19.0 
+0200
@@ -38,7 +38,6 @@
 #include 
 #include 
 #include 
-#include 
 #include 
 #include 
 #include 
@@ -404,12 +403,9 @@ static unsigned int handle_diacr(struct 
return d;
 
if (kbd->kbdmode == VC_UNICODE)
-   to_utf8(vc, d);
-   else {
-   int c = conv_uni_to_8bit(d);
-   if (c != -1)
-   put_queue(vc, c);
-   }
+   to_utf8(vc, conv_8bit_to_uni(d));
+   else if (d < 0x100)
+   put_queue(vc, d);
 
return ch;
 }
@@ -421,12 +417,9 @@ static void fn_enter(struct vc_data *vc)
 {
if (diacr) {
if (kbd->kbdmode == VC_UNICODE)
-   to_utf8(vc, diacr);
-   else {
-   int c = conv_uni_to_8bit(diacr);
-   if (c != -1)
-   put_queue(vc, c);
-   }
+   to_utf8(vc, conv_8bit_to_uni(diacr));
+   else if (diacr < 0x100)
+   put_queue(vc, diacr);
diacr = 0;
}
put_queue(vc, 13);
@@ -634,12 +627,9 @@ static void k_unicode(struct vc_data *vc
return;
}
if (kbd->kbdmode == VC_UNICODE)
-   to_utf8(vc, value);
-   else {
-   int c = conv_uni_to_8bit(value);
-   if (c != -1)
-   put_queue(vc, c);
-   }
+   to_utf8(vc, conv_8bit_to_uni(value));
+   else if (value < 0x100)
+   put_queue(vc, 

Re: [Pcihpd-discuss] [PATCH 1/3] pciehp: hotplug: deal with pre-inserted ExpressCards

[Kenji Kaneshige]

If a PCIe ExpressCard34 is inserted into the slot *before*
I modprobe pciehp (with pciehp_force=1), then the card is not
detected nor enabled.  The patch provided here fixes that.


Could you give me answers against the following questions?

 (1) Did you try "echo 1 > /sys/bus/pci/slots/XXX/power"?
 (XXX is the slot number to which your card had been inserted)
 (2) If the answer against (1) is yes, did "echo 1 > ..." work?



After 1. inserting the card, and then 2. modprobing pciehp,
the value of /sys/bus/pci/slots/XXX/power is already "1".


According to pciehp_debug output from you, your slot doesn't
have software programmable power controller. So your hardware
automatically power on the slot. I think this is why the value
of "power" file is already "1". (But I'm not sure if it is
correct, especially because your firmware doesn't have _OSC.)

On the other hand, my slot has software programmable power
controller. So the value of "power" file is "0" in this case. 



But, yes, doing "echo 1" into it does trigger card detection
and things work afterwards.  This doesn't really help,
because it doesn't happen automatically, unless the kernel patch
is applied.


 (6) I think your slot is surprise removable. Is it correct?


Yes, it's an externally accessible ExpressCard slot on a notebook,
which is intended to be fully hotpluggable by surprise or otherwise.


Ok. I think your patch is trying to solve the following two
problems. Right?

 - When the card is inserted *after* modprobing pciehp, the card
   is automatically enabled (pciehp tries to automatically enable
   slot when the card is inserted if the slot is surprise remove
   capable). But if the card is inserted *before* modprobing
   pciehp, the card is not automatically enabled even after
   modprobing pciehp.

 - When the card is inserted *before* modprobing pciehp, the card
   is automatically powered on by hardware, but it is not detected
   by OS. That is, "power" file tells the card is working, but it
   is not working actually. It is strange.

But those are not problems on the slot which is not surprise remove
capable and has software programmable power controller because:

 - When the card is inserted *after* modprobing pciehp, the card
   is *not* automatically powered on/detected. So it is very
   natural that the card, which had been inserted before modprobing
   pciehp, is not automatically enabled at the pciehp modprobe time.

 - When the card is inserted *before* modprobing pciehp, the card
   is not automatically powered on by hardware if the slot has
   sortware programmable power controller. So there is no
   contradiction.

I think your patch has a bad effect to this kind of slots. So I
think your patch needs additional checks to see if the slot should
be enabled or not.

And you need to test your patch on PCIe Native hotplug capable
hardware:)

Thanks,
Kenji Kaneshige





-
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] synchronize_irq needs a barrier

[Herbert Xu]

On Thu, Oct 18, 2007 at 04:39:59PM -0700, Linus Torvalds wrote:
>
> Basic notion: the only thing that serializes the IRQ_INPROGRESS flag is 
> the descriptor lock. And we don't have to (or even want to!) hold it while 
> waiting for the thing, but we want to *have*held*it* in between whatever 
> we're synchronizing with.

Thinking about this again and checking code I have come to the
conclusion that

1) There is a race (in some drivers) even with the full mb.
2) Linus's patch fixes it.
3) It's difficult to fix it elegantly in the driver.

In other words I think this patch is great :)

First of all let's agree on some basic assumptions:

* A pair of spin lock/unlock subsumes the effect of a full mb.
* A spin lock in general only equates to (SS/SL/LL).
* A spin unlock in general only equates to (SS/LS).

In particular, a load after a spin unlock may pass before the
spin unlock.

Here is the race (with tg3 as the only example that I know of).
The driver attempts to quiesce interrupts such that after the
call to synchronize_irq it is intended that no further IRQ
handler calls for that device will do any work besides acking
the IRQ.

Here is how it does it:

CPU0CPU1
spin lock
load irq_sync
irq_sync = 1
smp_mb
synchronize_irq()
while (IRQ_INPROGRESS)
wait
return
set IRQ_INPROGRESS
spin unlock
tg3_msi
ack IRQ
if (irq_sync)
return
do work

The problem here is that load of irq_sync in the handler has
passed above the setting of IRQ_INPROGRESS.

Linus's patch fixes it because this becomes:

CPU0CPU1
spin lock
load irq_sync
irq_sync = 1
smp_mb
synchronize_irq
set IRQ_INPROGRESS
spin unlock
spin lock
spin unlock
tg3_msi
ack IRQ
if (irq_sync)
return
do work
while (IRQ_INPROGRESS)
wait
spin lock
clear IRQ_INPROGRESS
spin unlock
return

Even though we still do the work on the right we will now notice
the INPROGRESS flag on the left and wait.

It's hard to fix this in the drivers because they'd either have
to access the desc lock or add a full mb to the fast path on the
right.

Once this goes in we can also remove the smp_mb from tg3.c.  BTW,
a lot of drivers (including the fusion example Ben quoted) call
synchronize_irq before free_irq.  This is unnecessary because
the latter already calls it anyway.

Cheers,
-- 
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/4] Fix race between sk_filter reassign and sk_clone()

[Olof Johansson]

On Wed, Oct 17, 2007 at 09:23:02PM -0700, David Miller wrote:
[...]
> > The same problem exists for detaching filter (SO_DETACH_FILTER).
> > 
> > The proposed fix consists of 3 preparation patches and the fix itself.
> > 
> > Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
> 
> Looks good, applied.
> 
> Thanks for fixing this bug Pavel!

Looks like this might be causing problems, at least for me on ppc. This
happened during a normal boot, right around first interface config/dhcp
run..

cpu 0x0: Vector: 300 (Data Access) at [c147b820]
pc: c0435e5c: .sk_filter_delayed_uncharge+0x1c/0x60
lr: c04360d0: .sk_attach_filter+0x170/0x180
sp: c147baa0
   msr: 90009032
   dar: 4
 dsisr: 4000
  current = 0xc4780fa0
  paca= 0xc0650480
pid   = 1295, comm = dhclient3
0:mon> t
[c147bb20] c04360d0 .sk_attach_filter+0x170/0x180
[c147bbd0] c0418988 .sock_setsockopt+0x788/0x7f0
[c147bcb0] c0438a74 .compat_sys_setsockopt+0x4e4/0x5a0
[c147bd90] c043955c .compat_sys_socketcall+0x25c/0x2b0
[c147be30] c0007508 syscall_exit+0x0/0x40
--- Exception: c01 (System Call) at 0ff618d8
SP (fffdf040) is in userspace
0:mon> 

I.e. null pointer deref at sk_filter_delayed_uncharge+0x1c:

0:mon> di $.sk_filter_delayed_uncharge
c0435e40  7c0802a6  mflrr0
c0435e44  fbc1fff0  std r30,-16(r1)
c0435e48  7c8b2378  mr  r11,r4
c0435e4c  ebc2cdd0  ld  r30,-12848(r2)
c0435e50  f8010010  std r0,16(r1)
c0435e54  f821ff81  stdur1,-128(r1)
c0435e58  380300a4  addir0,r3,164
c0435e5c  81240004  lwz r9,4(r4)

That's the deref of fp:

static void sk_filter_delayed_uncharge(struct sock *sk, struct sk_filter *fp)
{
unsigned int size = sk_filter_len(fp);
...

That is called from sk_attach_filter():

...
rcu_read_lock_bh();
old_fp = rcu_dereference(sk->sk_filter);
rcu_assign_pointer(sk->sk_filter, fp);
rcu_read_unlock_bh();

sk_filter_delayed_uncharge(sk, old_fp);
return 0;
...

So, looks like rcu_dereference() returned NULL. I don't know the
filter code at all, but it seems like it might be a valid case?
sk_detach_filter() seems to handle a NULL sk_filter, at least.


So, this needs review by someone who knows the filter, but it fixes the
problem for me:


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

diff --git a/net/core/filter.c b/net/core/filter.c
index 1f0068e..e0a0694 100644
--- a/net/core/filter.c
+++ b/net/core/filter.c
@@ -447,7 +447,8 @@ int sk_attach_filter(struct sock_fprog *fprog, struct sock 
*sk)
rcu_assign_pointer(sk->sk_filter, fp);
rcu_read_unlock_bh();
 
-   sk_filter_delayed_uncharge(sk, old_fp);
+   if (old_fp)
+   sk_filter_delayed_uncharge(sk, old_fp);
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/

Re: SLUB: Avoid atomic operation for slab_unlock

[Nick Piggin]

On Friday 19 October 2007 12:01, Christoph Lameter wrote:
> On Fri, 19 Oct 2007, Nick Piggin wrote:
> > > Yes that is what I attempted to do with the write barrier. To my
> > > knowledge there are no reads that could bleed out and I wanted to avoid
> > > a full fence instruction there.
> >
> > Oh, OK. Bit risky ;) You might be right, but anyway I think it
> > should be just as fast with the optimised bit_unlock on most
> > architectures.
>
> How expensive is the fence? An store with release semantics would be safer
> and okay for IA64.

I'm not sure, I had an idea it was relatively expensive on ia64,
but I didn't really test with a good workload (a microbenchmark
probably isn't that good because it won't generate too much out
of order memory traffic that needs to be fenced).


> > Which reminds me, it would be interesting to test the ia64
> > implementation I did. For the non-atomic unlock, I'm actually
> > doing an atomic operation there so that it can use the release
> > barrier rather than the mf. Maybe it's faster the other way around
> > though? Will be useful to test with something that isn't a trivial
> > loop, so the slub case would be a good benchmark.
>
> Lets avoid mf (too expensive) and just use a store with release semantics.

OK, that's what I've done at the moment.


> Where can I find your patchset? I looked through lkml but did not see it.

Infrastructure in -mm, starting at bitops-introduce-lock-ops.patch.
bit_spin_lock-use-lock-bitops.patch and ia64-lock-bitops.patch are
ones to look at.

The rest of the patches I have queued here, apart from the SLUB patch,
I guess aren't so interesting to you (they don't do anything fancy
like convert to non-atomic unlocks, just switch things like page and
buffer locks to use new bitops).
-
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/2] ext2: Avoid rec_len overflow with 64KB block size

[Mingming Cao]

On Wed, 2007-10-17 at 21:09 -0700, Andrew Morton wrote:
> On Thu, 11 Oct 2007 13:18:49 +0200 Jan Kara <[EMAIL PROTECTED]> wrote:
> 
> > With 64KB blocksize, a directory entry can have size 64KB which does not fit
> > into 16 bits we have for entry lenght. So we store 0x instead and 
> > convert
> > value when read from / written to disk.
> 
> btw, this changes ext2's on-disk format.
> 
Just to clarify this is only changes the directory entries format on
ext2/3/4 fs with 64k block size. But currently without kernel changes
ext2/3/4 does not support 64 block size.

> a) is the ext2 format documented anywhere?  If so, that document will
>need updating.
> 

The e2fsprogs needs to be changed to sync up with this change.

Ted has a paper a while back to show ext2 disk format 
http://web.mit.edu/tytso/www/linux/ext2intro.html

The Documentation/filesystems/ext2.txt doesn't have the ext2 format
documented. That document is out-dated need to be reviewed and cleaned
up.
 
> b) what happens when an old ext2 driver tries to read and/or write this
>directory entry?  Do we need a compat flag for it?
> 
> c) what happens when old and new ext3 or ext4 try to read/write this
>directory entry?
> 

Without the first patch in this series: ext2 large blocksize support
patches, it fails to mount a ext2 filesystem with 64k block size. 

[PATCH 1/2] ext2:  Support large blocksize up to PAGESIZE
http://lkml.org/lkml/2007/10/1/361

So the old ext2/3/4 driver will not get access the directory entry with
64k block size format changes.


Regards,

Mingming

> -
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html

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

[M68KNOMMU]: fix make archclean

[Greg Ungerer]

Remove build reference to arch/m68knommu/boot directory, it doesn't
exist.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/Makefile 
linux-2.6.23-uc0/arch/m68knommu/Makefile
--- linux-2.6.23/arch/m68knommu/Makefile2007-10-19 10:30:58.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/Makefile2007-10-19 10:35:41.0 
+1000
@@ -117,4 +118,4 @@ core-y  += arch/m68knommu/kernel/ \
 libs-y += arch/m68knommu/lib/
 
 archclean:
-   $(Q)$(MAKE) $(clean)=arch/m68knommu/boot
+
-
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: SLUB: Avoid atomic operation for slab_unlock

[Christoph Lameter]

On Fri, 19 Oct 2007, Nick Piggin wrote:

> > Yes that is what I attempted to do with the write barrier. To my knowledge
> > there are no reads that could bleed out and I wanted to avoid a full fence
> > instruction there.
> 
> Oh, OK. Bit risky ;) You might be right, but anyway I think it
> should be just as fast with the optimised bit_unlock on most
> architectures.

How expensive is the fence? An store with release semantics would be safer 
and okay for IA64.
 
> Which reminds me, it would be interesting to test the ia64
> implementation I did. For the non-atomic unlock, I'm actually
> doing an atomic operation there so that it can use the release
> barrier rather than the mf. Maybe it's faster the other way around
> though? Will be useful to test with something that isn't a trivial
> loop, so the slub case would be a good benchmark.

Lets avoid mf (too expensive) and just use a store with release semantics.

Where can I find your patchset? I looked through lkml but did not see 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: SLUB: Avoid atomic operation for slab_unlock

[Nick Piggin]

On Friday 19 October 2007 11:21, Christoph Lameter wrote:
> On Fri, 19 Oct 2007, Nick Piggin wrote:
> > Ah, thanks, but can we just use my earlier patch that does the
> > proper __bit_spin_unlock which is provided by
> > bit_spin_lock-use-lock-bitops.patch
>
> Ok.
>
> > This primitive should have a better chance at being correct, and
> > also potentially be more optimised for each architecture (it
> > only has to provide release consistency).
>
> Yes that is what I attempted to do with the write barrier. To my knowledge
> there are no reads that could bleed out and I wanted to avoid a full fence
> instruction there.

Oh, OK. Bit risky ;) You might be right, but anyway I think it
should be just as fast with the optimised bit_unlock on most
architectures.

Which reminds me, it would be interesting to test the ia64
implementation I did. For the non-atomic unlock, I'm actually
doing an atomic operation there so that it can use the release
barrier rather than the mf. Maybe it's faster the other way around
though? Will be useful to test with something that isn't a trivial
loop, so the slub case would be a good benchmark.

-
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 v2] [2/2] powerpc: Switch to generic WARN_ON()/BUG_ON()

[Olof Johansson]

[POWERPC] Switch to generic WARN_ON()/BUG_ON()

Not using the ppc-specific WARN_ON/BUG_ON constructs actually saves about
4K text on a ppc64_defconfig. The main reason seems to be that prepping
the arguments to the conditional trap instructions is more work than
just doing a compare and branch.

Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

Index: k.org/include/asm-powerpc/bug.h
===
--- k.org.orig/include/asm-powerpc/bug.h
+++ k.org/include/asm-powerpc/bug.h
@@ -54,12 +54,6 @@
".previous\n"
 #endif
 
-/*
- * BUG_ON() and WARN_ON() do their best to cooperate with compile-time
- * optimisations. However depending on the complexity of the condition
- * some compiler versions may not produce optimal results.
- */
-
 #define BUG() do { \
__asm__ __volatile__(   \
"1: twi 31,0,0\n"   \
@@ -69,20 +63,6 @@
for(;;) ;   \
 } while (0)
 
-#define BUG_ON(x) do { \
-   if (__builtin_constant_p(x)) {  \
-   if (x)  \
-   BUG();  \
-   } else {\
-   __asm__ __volatile__(   \
-   "1: "PPC_TLNEI" %4,0\n" \
-   _EMIT_BUG_ENTRY \
-   : : "i" (__FILE__), "i" (__LINE__), "i" (0),\
- "i" (sizeof(struct bug_entry)),   \
- "r" ((__force long)(x))); \
-   }   \
-} while (0)
-
 #define __WARN() do {  \
__asm__ __volatile__(   \
"1: twi 31,0,0\n"   \
@@ -92,23 +72,6 @@
  "i" (sizeof(struct bug_entry)));  \
 } while (0)
 
-#define WARN_ON(x) ({  \
-   int __ret_warn_on = !!(x);  \
-   if (__builtin_constant_p(__ret_warn_on)) {  \
-   if (__ret_warn_on)  \
-   __WARN();   \
-   } else {\
-   __asm__ __volatile__(   \
-   "1: "PPC_TLNEI" %4,0\n" \
-   _EMIT_BUG_ENTRY \
-   : : "i" (__FILE__), "i" (__LINE__), \
- "i" (BUGFLAG_WARNING),\
- "i" (sizeof(struct bug_entry)),   \
- "r" (__ret_warn_on)); \
-   }   \
-   unlikely(__ret_warn_on);\
-})
-
 #endif /* __ASSEMBLY __ */
 #endif /* CONFIG_BUG */
 
-
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 v2] [1/2] bug.h: Remove HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.*

[Olof Johansson]

No need to have the HAVE_ARCH_BUG.* / HAVE_ARCH_WARN.* defines, when
the generic implementation can just use #ifndef on the macros themselves.

Also, introduce __WARN() in the generic case, so the generic WARN_ON()
can use arch-specific code for when the condition is true.

Built on powerpc, i386, sh and sparc64.


Signed-off-by: Olof Johansson <[EMAIL PROTECTED]>

Index: k.org/include/asm-generic/bug.h
===
--- k.org.orig/include/asm-generic/bug.h
+++ k.org/include/asm-generic/bug.h
@@ -20,39 +20,44 @@ struct bug_entry {
 #define BUGFLAG_WARNING(1<<0)
 #endif /* CONFIG_GENERIC_BUG */
 
-#ifndef HAVE_ARCH_BUG
+#ifndef BUG
 #define BUG() do { \
printk("BUG: failure at %s:%d/%s()!\n", __FILE__, __LINE__, 
__FUNCTION__); \
panic("BUG!"); \
 } while (0)
 #endif
 
-#ifndef HAVE_ARCH_BUG_ON
+#ifndef BUG_ON
 #define BUG_ON(condition) do { if (unlikely(condition)) BUG(); } while(0)
 #endif
 
-#ifndef HAVE_ARCH_WARN_ON
+#ifndef __WARN
+#define __WARN() do {  \
+   printk("WARNING: at %s:%d %s()\n", __FILE__,\
+   __LINE__, __FUNCTION__);\
+   dump_stack();   \
+} while (0)
+#endif
+
+#ifndef WARN_ON
 #define WARN_ON(condition) ({  \
int __ret_warn_on = !!(condition);  \
-   if (unlikely(__ret_warn_on)) {  \
-   printk("WARNING: at %s:%d %s()\n", __FILE__,\
-   __LINE__, __FUNCTION__);\
-   dump_stack();   \
-   }   \
+   if (unlikely(__ret_warn_on))\
+   __WARN();   \
unlikely(__ret_warn_on);\
 })
 #endif
 
 #else /* !CONFIG_BUG */
-#ifndef HAVE_ARCH_BUG
+#ifndef BUG
 #define BUG()
 #endif
 
-#ifndef HAVE_ARCH_BUG_ON
+#ifndef BUG_ON
 #define BUG_ON(condition) do { if (condition) ; } while(0)
 #endif
 
-#ifndef HAVE_ARCH_WARN_ON
+#ifndef WARN_ON
 #define WARN_ON(condition) ({  \
int __ret_warn_on = !!(condition);  \
unlikely(__ret_warn_on);\
Index: k.org/include/asm-parisc/bug.h
===
--- k.org.orig/include/asm-parisc/bug.h
+++ k.org/include/asm-parisc/bug.h
@@ -7,8 +7,6 @@
  */
 
 #ifdef CONFIG_BUG
-#define HAVE_ARCH_BUG
-#define HAVE_ARCH_WARN_ON
 
 /* the break instruction is used as BUG() marker.  */
 #definePARISC_BUG_BREAK_ASM"break 0x1f, 0x1fff"
Index: k.org/include/asm-powerpc/bug.h
===
--- k.org.orig/include/asm-powerpc/bug.h
+++ k.org/include/asm-powerpc/bug.h
@@ -109,9 +109,6 @@
unlikely(__ret_warn_on);\
 })
 
-#define HAVE_ARCH_BUG
-#define HAVE_ARCH_BUG_ON
-#define HAVE_ARCH_WARN_ON
 #endif /* __ASSEMBLY __ */
 #endif /* CONFIG_BUG */
 
Index: k.org/include/asm-sh/bug.h
===
--- k.org.orig/include/asm-sh/bug.h
+++ k.org/include/asm-sh/bug.h
@@ -4,8 +4,6 @@
 #define TRAPA_BUG_OPCODE   0xc33e  /* trapa #0x3e */
 
 #ifdef CONFIG_BUG
-#define HAVE_ARCH_BUG
-#define HAVE_ARCH_WARN_ON
 
 /**
  * _EMIT_BUG_ENTRY
Index: k.org/include/asm-alpha/bug.h
===
--- k.org.orig/include/asm-alpha/bug.h
+++ k.org/include/asm-alpha/bug.h
@@ -10,7 +10,6 @@
   __asm__ __volatile__("call_pal %0  # bugchk\n\t"".long %1\n\t.8byte %2" \
   : : "i" (PAL_bugchk), "i"(__LINE__), "i"(__FILE__))
 
-#define HAVE_ARCH_BUG
 #endif
 
 #include 
Index: k.org/include/asm-arm/bug.h
===
--- k.org.orig/include/asm-arm/bug.h
+++ k.org/include/asm-arm/bug.h
@@ -16,7 +16,6 @@ extern void __bug(const char *file, int 
 
 #endif
 
-#define HAVE_ARCH_BUG
 #endif
 
 #include 
Index: k.org/include/asm-avr32/bug.h
===
--- k.org.orig/include/asm-avr32/bug.h
+++ k.org/include/asm-avr32/bug.h
@@ -63,9 +63,6 @@
unlikely(__ret_warn_on);\
})
 
-#define HAVE_ARCH_BUG
-#define HAVE_ARCH_WARN_ON
-
 #endif /* CONFIG_BUG */
 
 #include 
Index: k.org/include/asm-frv/bug.h
===
--- k.org.orig/include/asm-frv/bug.h
+++ k.org/include/asm-frv/bug.h
@@ -32,7 +32,6 @@ do {   

[M68KNOMMU]: updated defconfig

[Greg Ungerer]

Updated defconfig with new options for m68knommu.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/arch/m68knommu/defconfig 
linux-2.6.23-uc0/arch/m68knommu/defconfig
--- linux-2.6.23/arch/m68knommu/defconfig   2007-10-19 10:30:58.0 
+1000
+++ linux-2.6.23-uc0/arch/m68knommu/defconfig   2007-10-19 10:35:41.0 
+1000
@@ -1,41 +1,48 @@
 #
 # Automatically generated make config: don't edit
-# Linux kernel version: 2.6.17
-# Tue Jun 27 12:57:06 2006
+# Linux kernel version: 2.6.23
+# Thu Oct 18 13:17:38 2007
 #
 CONFIG_M68K=y
 # CONFIG_MMU is not set
 # CONFIG_FPU is not set
+CONFIG_ZONE_DMA=y
 CONFIG_RWSEM_GENERIC_SPINLOCK=y
 # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
+# CONFIG_ARCH_HAS_ILOG2_U32 is not set
+# CONFIG_ARCH_HAS_ILOG2_U64 is not set
 CONFIG_GENERIC_FIND_NEXT_BIT=y
 CONFIG_GENERIC_HWEIGHT=y
+CONFIG_GENERIC_HARDIRQS=y
 CONFIG_GENERIC_CALIBRATE_DELAY=y
 CONFIG_TIME_LOW_RES=y
+CONFIG_NO_IOPORT=y
+CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
 
 #
-# Code maturity level options
+# General setup
 #
 CONFIG_EXPERIMENTAL=y
 CONFIG_BROKEN_ON_SMP=y
 CONFIG_INIT_ENV_ARG_LIMIT=32
-
-#
-# General setup
-#
 CONFIG_LOCALVERSION=""
 CONFIG_LOCALVERSION_AUTO=y
 # CONFIG_SYSVIPC is not set
 # CONFIG_POSIX_MQUEUE is not set
 # CONFIG_BSD_PROCESS_ACCT is not set
-# CONFIG_SYSCTL is not set
+# CONFIG_TASKSTATS is not set
+# CONFIG_USER_NS is not set
 # CONFIG_AUDIT is not set
 # CONFIG_IKCONFIG is not set
+CONFIG_LOG_BUF_SHIFT=14
+# CONFIG_SYSFS_DEPRECATED is not set
 # CONFIG_RELAY is not set
-CONFIG_INITRAMFS_SOURCE=""
-CONFIG_UID16=y
+# CONFIG_BLK_DEV_INITRD is not set
 # CONFIG_CC_OPTIMIZE_FOR_SIZE is not set
+CONFIG_SYSCTL=y
 CONFIG_EMBEDDED=y
+CONFIG_UID16=y
+CONFIG_SYSCTL_SYSCALL=y
 # CONFIG_KALLSYMS is not set
 # CONFIG_HOTPLUG is not set
 CONFIG_PRINTK=y
@@ -44,20 +51,25 @@ CONFIG_ELF_CORE=y
 CONFIG_BASE_FULL=y
 # CONFIG_FUTEX is not set
 # CONFIG_EPOLL is not set
+# CONFIG_SIGNALFD is not set
+# CONFIG_EVENTFD is not set
+# CONFIG_VM_EVENT_COUNTERS is not set
 CONFIG_SLAB=y
+# CONFIG_SLUB is not set
+# CONFIG_SLOB is not set
 CONFIG_TINY_SHMEM=y
 CONFIG_BASE_SMALL=0
-# CONFIG_SLOB is not set
-
-#
-# Loadable module support
-#
-# CONFIG_MODULES is not set
-
-#
-# Block layer
-#
+CONFIG_MODULES=y
+CONFIG_MODULE_UNLOAD=y
+# CONFIG_MODULE_FORCE_UNLOAD is not set
+# CONFIG_MODVERSIONS is not set
+# CONFIG_MODULE_SRCVERSION_ALL is not set
+# CONFIG_KMOD is not set
+CONFIG_BLOCK=y
+# CONFIG_LBD is not set
 # CONFIG_BLK_DEV_IO_TRACE is not set
+# CONFIG_LSF is not set
+# CONFIG_BLK_DEV_BSG is not set
 
 #
 # IO Schedulers
@@ -99,6 +111,7 @@ CONFIG_CLOCK_DIV=1
 #
 # Platform
 #
+# CONFIG_UC5272 is not set
 CONFIG_M5272C3=y
 # CONFIG_COBRA5272 is not set
 # CONFIG_CANCam is not set
@@ -107,7 +120,6 @@ CONFIG_M5272C3=y
 # CONFIG_CPU16B is not set
 # CONFIG_MOD5272 is not set
 CONFIG_FREESCALE=y
-# CONFIG_LARGE_ALLOCS is not set
 CONFIG_4KSTACKS=y
 
 #
@@ -121,6 +133,11 @@ CONFIG_RAMAUTOBIT=y
 # CONFIG_RAM8BIT is not set
 # CONFIG_RAM16BIT is not set
 # CONFIG_RAM32BIT is not set
+
+#
+# ROM configuration
+#
+# CONFIG_ROM is not set
 CONFIG_RAMKERNEL=y
 # CONFIG_ROMKERNEL is not set
 CONFIG_SELECT_MEMORY_MODEL=y
@@ -131,20 +148,19 @@ CONFIG_FLATMEM=y
 CONFIG_FLAT_NODE_MEM_MAP=y
 # CONFIG_SPARSEMEM_STATIC is not set
 CONFIG_SPLIT_PTLOCK_CPUS=4
+# CONFIG_RESOURCES_64BIT is not set
+CONFIG_ZONE_DMA_FLAG=1
+CONFIG_VIRT_TO_BUS=y
 
 #
 # Bus options (PCI, PCMCIA, EISA, MCA, ISA)
 #
 # CONFIG_PCI is not set
+# CONFIG_ARCH_SUPPORTS_MSI is not set
 
 #
 # PCCARD (PCMCIA/CardBus) support
 #
-# CONFIG_PCCARD is not set
-
-#
-# PCI Hotplug Support
-#
 
 #
 # Executable file formats
@@ -168,7 +184,6 @@ CONFIG_NET=y
 #
 # Networking options
 #
-# CONFIG_NETDEBUG is not set
 CONFIG_PACKET=y
 # CONFIG_PACKET_MMAP is not set
 CONFIG_UNIX=y
@@ -187,27 +202,21 @@ CONFIG_IP_FIB_HASH=y
 # CONFIG_INET_IPCOMP is not set
 # CONFIG_INET_XFRM_TUNNEL is not set
 # CONFIG_INET_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_TRANSPORT is not set
+# CONFIG_INET_XFRM_MODE_TUNNEL is not set
+# CONFIG_INET_XFRM_MODE_BEET is not set
 # CONFIG_INET_DIAG is not set
 # CONFIG_TCP_CONG_ADVANCED is not set
-CONFIG_TCP_CONG_BIC=y
+CONFIG_TCP_CONG_CUBIC=y
+CONFIG_DEFAULT_TCP_CONG="cubic"
+# CONFIG_TCP_MD5SIG is not set
 # CONFIG_IPV6 is not set
 # CONFIG_INET6_XFRM_TUNNEL is not set
 # CONFIG_INET6_TUNNEL is not set
+# CONFIG_NETWORK_SECMARK is not set
 # CONFIG_NETFILTER is not set
-
-#
-# DCCP Configuration (EXPERIMENTAL)
-#
 # CONFIG_IP_DCCP is not set
-
-#
-# SCTP Configuration (EXPERIMENTAL)
-#
 # CONFIG_IP_SCTP is not set
-
-#
-# TIPC Configuration (EXPERIMENTAL)
-#
 # CONFIG_TIPC is not set
 # CONFIG_ATM is not set
 # CONFIG_BRIDGE is not set
@@ -218,7 +227,6 @@ CONFIG_TCP_CONG_BIC=y
 # CONFIG_ATALK is not set
 # CONFIG_X25 is not set
 # CONFIG_LAPB is not set
-# CONFIG_NET_DIVERT is not set
 # CONFIG_ECONET is not set
 # CONFIG_WAN_ROUTER is not set
 
@@ -234,7 +242,17 @@ 

[M68KNOMMU]: new style ColdFire UART driver

[Greg Ungerer]

A new style serial driver for the Freescale ColdFire UART to replace
the old style one currently in the tree (drivers/serial/mcfserial.c).

Currently this UART is only found in the ColdFire CPU family of parts
(thus I prefixed this patch [M68KNOMMU]).

This has been around for a long while now, tested on all available
platforms.

Signed-off-by: Greg Ungerer <[EMAIL PROTECTED]>
---


diff -Naurp linux-2.6.23/drivers/serial/mcf.c 
linux-2.6.23-uc0/drivers/serial/mcf.c
--- linux-2.6.23/drivers/serial/mcf.c   1970-01-01 10:00:00.0 +1000
+++ linux-2.6.23-uc0/drivers/serial/mcf.c   2007-10-19 11:23:15.0 
+1000
@@ -0,0 +1,653 @@
+//
+
+/*
+ * mcf.c -- Freescale ColdFire UART driver
+ *
+ * (C) Copyright 2003-2007, Greg Ungerer <[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.
+ */
+
+//
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+//
+
+/*
+ * Some boards implement the DTR/DCD lines using GPIO lines, most
+ * don't. Dummy out the access macros for those that don't. Those
+ * that do should define these macros somewhere in there board
+ * specific inlude files.
+ */
+#if !defined(mcf_getppdcd)
+#definemcf_getppdcd(p) (1)
+#endif
+#if !defined(mcf_getppdtr)
+#definemcf_getppdtr(p) (1)
+#endif
+#if !defined(mcf_setppdtr)
+#definemcf_setppdtr(p, v)  do { } while (0)
+#endif
+
+//
+
+/*
+ * Local per-uart structure.
+ */
+struct mcf_uart {
+   struct uart_portport;
+   unsigned intsigs;   /* Local copy of line sigs */
+   unsigned char   imr;/* Local IMR mirror */
+};
+
+//
+
+static unsigned int mcf_tx_empty(struct uart_port *port)
+{
+   return (readb(port->membase + MCFUART_USR) & MCFUART_USR_TXEMPTY) ?
+   TIOCSER_TEMT : 0;
+}
+
+//
+
+static unsigned int mcf_get_mctrl(struct uart_port *port)
+{
+   struct mcf_uart *pp = (struct mcf_uart *) port;
+   unsigned long flags;
+   unsigned int sigs;
+
+   spin_lock_irqsave(>lock, flags);
+   sigs = (readb(port->membase + MCFUART_UIPR) & MCFUART_UIPR_CTS) ?
+   0 : TIOCM_CTS;
+   sigs |= (pp->sigs & TIOCM_RTS);
+   sigs |= (mcf_getppdcd(port->line) ? TIOCM_CD : 0);
+   sigs |= (mcf_getppdtr(port->line) ? TIOCM_DTR : 0);
+   spin_unlock_irqrestore(>lock, flags);
+   return sigs;
+}
+
+//
+
+static void mcf_set_mctrl(struct uart_port *port, unsigned int sigs)
+{
+   struct mcf_uart *pp = (struct mcf_uart *) port;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   pp->sigs = sigs;
+   mcf_setppdtr(port->line, (sigs & TIOCM_DTR));
+   if (sigs & TIOCM_RTS)
+   writeb(MCFUART_UOP_RTS, port->membase + MCFUART_UOP1);
+   else
+   writeb(MCFUART_UOP_RTS, port->membase + MCFUART_UOP0);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_start_tx(struct uart_port *port)
+{
+   struct mcf_uart *pp = (struct mcf_uart *) port;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   pp->imr |= MCFUART_UIR_TXREADY;
+   writeb(pp->imr, port->membase + MCFUART_UIMR);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_stop_tx(struct uart_port *port)
+{
+   struct mcf_uart *pp = (struct mcf_uart *) port;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   pp->imr &= ~MCFUART_UIR_TXREADY;
+   writeb(pp->imr, port->membase + MCFUART_UIMR);
+   spin_unlock_irqrestore(>lock, flags);
+}
+
+//
+
+static void mcf_stop_rx(struct uart_port *port)
+{
+   struct mcf_uart *pp = (struct mcf_uart *) port;
+   unsigned long flags;
+
+   spin_lock_irqsave(>lock, flags);
+   pp->imr &= ~MCFUART_UIR_RXREADY;
+   writeb(pp->imr, port->membase + MCFUART_UIMR);
+   spin_unlock_irqrestore(>lock, flags);
+}

Re: BUG in: Driver core: convert block from raw kobjects to core devices

[Kay Sievers]

On Thu, 2007-10-18 at 16:08 -0400, Alan Stern wrote:
> On Thu, 18 Oct 2007, Kay Sievers wrote:
> 
> > On Thu, 2007-10-18 at 15:23 -0400, Alan Stern wrote:
> > > This patch (as1004) fixes a refcounting bug in the development version
> > > of the block-device core.
> > > 
> > > Signed-off-by: Alan Stern <[EMAIL PROTECTED]>
> > > 
> > > ---
> > > 
> > > Kay, you have got to start testing your patches better!
> > 
> > That leaves references around for SCSI target devices. There must be a
> > bug somewhere else, if the patch isn't correct.
> > 
> > > Finding and
> > > fixing refcount errors is _not_ one of my favorite ways to pass the
> > > time.  For example, you could see what happens when you insert and
> > > unplug a USB flash disk a few times.
> > 
> > What do you see with the original version?
> 
> Note that a USB drive is treated as a SCSI device.
> 
> With the original code, I see the following sequence of events when 
> add_disk() is first called.  Values in parentheses are 
> atomic_read(disk->dev.kobj.kref.refcount) after each stage runs:
> 
>   Entry to add_disk   (1)
>   Call to register_disk
>   device_add  (3)
>   CONFIG_SYSFS_DEPRECATED is not set
>   Call disk_sysfs_add_subdirs
>   add disk->holder_dir(4)
>   add disk->slave_dir (5)
>   Return to register_disk
>   get_capacity(5)
>   bdget_disk  (5)
>   blkdev_get (partitions) (8)
>   blkdev_put  (7)
>   Return to add_disk
>   blk_register_queue  (9)
> 
> You can see how many references each stage takes.  Now here's the
> equivalent list for del_gendisk():
> 
>   Entry to del_gendisk(9)
>   invalidate_ and delete_partition loop   (7)
>   invalidate_partition 0  (7)
>   Call unlink_gendisk
>   blk_unregister_queue(5)
>   Return to del_gendisk
>   unregister disk->holder_dir (4)
>   unregister disk->slave_dir  (3)
>   CONFIG_SYSFS_DEPRECATED is not set
>   device_del  (1)
>   put_device  (0) -- oops!
> 
> Matching things up we have:
> 
>   device_add/device_del   2 refs
>   reg/unreg subdirs   2 refs
>   subpartitions   2 refs
>   reg/unreg block queue   2 refs
> 
> This accounts for everything in del_gendisk except the final
> put_device.  Evidently it doesn't belong there.  There's no matching 
> get_device in add_disk or register_disk.

Hmm, do you have kobject debugging enabled? Do you ever see something
like: "kobject sdb: cleaning up" when you remove the put_device()?

Kay

-
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: SLUB: Avoid atomic operation for slab_unlock

[Christoph Lameter]

On Fri, 19 Oct 2007, Nick Piggin wrote:

> Ah, thanks, but can we just use my earlier patch that does the
> proper __bit_spin_unlock which is provided by
> bit_spin_lock-use-lock-bitops.patch

Ok.

> This primitive should have a better chance at being correct, and
> also potentially be more optimised for each architecture (it
> only has to provide release consistency).

Yes that is what I attempted to do with the write barrier. To my knowledge 
there are no reads that could bleed out and I wanted to avoid a full fence 
instruction there.

> I have attached the patch here just for reference, but actually
> I am submitting it properly as part of a patch series today, now
> that the base bit lock patches have been sent upstream.

Good. Andrew: Drop my patch when this goes in.
-
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: PDA Suspend SA1100

[eric miao]

On 10/19/07, Kristoffer Ericson <[EMAIL PROTECTED]> wrote:
> Greetings,
>
> I've been trying to implement proper suspend on my jornada 720 machine. But 
> as far as I can see it never reaches
> the sa11x0_suspend code.
>
> I've linked power button event to produce APM_SUSPEND and I can see that it 
> says "Stopping TASKS ==". It then
> blanks screen but keeps LCD powerd. I know it goes into resume again since 
> removing backlight code in resume function
> effectivly turns off the LCD.
>
> Im assuming that it tries to suspend but fails at some point and tries to 
> return into normal operations?
> Exactly what is needed to get the suspend procedure happy? Does every driver 
> need to have suspend/resume code?

I don't think so. Unless a driver feels it necessary to take some
action, no suspend/resume
will not cause the whole system to fail. However,

1) if any driver suspend code returns error, the whole procedure will stop
2) and instable wake-up source (like glitch on wake-up GPIO pin) or
incorrect setting (like
wake up from RTC but set the interval to be 0) will also cause the
immediate resume

check "sa11x0_suspend" print out won't work since the console has already been
suspended, try DISABLE_CONSOLE_SUSPEND or other ways

- eric

>
> Best wishes
> Kristoffer Ericson
> -
> 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/

Re: [patch 1/3] Add BSS to resource tree

[Jeremy Fitzhardinge]

Sam Ravnborg wrote:
> And I recall that extern char sym[] is considered correct by binutils 
> people - but I'm not 100% sure and google did not give me an appropriate hit.

Yes, I generally prefer char[] - but only because gcc irritatingly
rejects void []...

J
-
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 -mm] ASIC3 driver

[Samuel Ortiz]

On Fri, Oct 19, 2007 at 12:15:47AM +0200, Thomas Gleixner wrote:
> On Thu, 18 Oct 2007, Andrew Morton wrote:
> > > +
> > > +#include 
> > > +#include 
> > > +#include 
> > 
> > Please see the large comment at the top of linux/irq.h.  I believe this
> > driver will fial to compile on at least arm.
> > 
> > We really should fix this.
> 
> drivers are fine with: #include 
> 
> If they need linux/irq.h, then they do probably something really
> nasty.
The asic3 adds irqs to a board, through GPIOs. Is that a valid case ?

Cheers,
Samuel.

 
>   tglx

-
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] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

> So how about something like this (untested! not necessarily very well 
> thought through either!)
> 
> Basic notion: the only thing that serializes the IRQ_INPROGRESS flag is 
> the descriptor lock. And we don't have to (or even want to!) hold it while 
> waiting for the thing, but we want to *have*held*it* in between whatever 
> we're synchronizing with.
> 
> The internal irq handler functions already held the lock when they did 
> whatever they need to serialize - and they are possibly performance 
> critical too - so they use the "internal" function that doesn't get the 
> lock unnecessarily again.

That may do the trick as the read can't cross the spin_lock (it can
cross spin_unlock but not lock). Advantage over adding a barrier to
handle_IRQ_event() is that it keeps the overhead to the slow path
(synchronize_irq).

Note that I didn't actually experience a problem here. I just came upon
that by accident while thinking about a similar issue I have with
napi_synchronize().

Looks good to me on a first glance (unfortunately a bit ugly but heh).

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: kswapd0 inefficient?

[Nick Piggin]

On Friday 19 October 2007 08:05, Richard Jelinek wrote:
> Hello guys,
>
> I'm not subscribed to this list, so if you find this question valid
> enough to answer it, please cc me. Thanks.
>
> This is what the top-output looks like on my machine after having
> copied about 550GB of data from a twofish256 crypted disk to a raid
> array:
> --
> Mem:   8178452k total,  8132180k used,46272k free,  2743480k buffers
> Swap:0k total,0k used,0k free,  4563032k cached
>
>   PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
>  5954 root   0 -20 000 R   62  0.0  96:42.61 loop0
>  6014 root  18   0 23744  19m  484 R   20  0.2  25:45.31 cp
>   255 root  10  -5 000 S8  0.0  10:21.82 kswapd0
>  6011 root  10  -5 000 D6  0.0   4:15.66 kjournald
> ...yadda yadda...
> --
>
> And what do we see here? We see loop0 and cp eating up some
> time. That's ok for me considered the work they do. kjournald is also
> ok for me, but I ask myself: why the heck has kswapd0 crunched 10+
> minutes of CPU time?
>
> I mean what does kswapd0 do?
> http://www.linuxforums.org/forum/linux-kernel/65380-what-does-kswapd0-do.ht
>ml
>
> And I have no swap - right? So it should just shut up - IMHO. Or am I
> missing something?

kswapd also reclaims pagecache, not just anonymous memory. It runs
in response to memory pressure and if it wasn't around, then all
your apps requesting memory would have to do basically the same
amount of work themselves.
-
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: GEODE: update GPIO API to support setting multiple GPIOs at once

[Jordan Crouse]

On 18/10/07 15:27 -0400, Andres Salomon wrote:
> The existing Geode GPIO API only allows for updating one GPIO at once.  There
> are instances where users want to update multiple GPIOs at once.  With the
> current API, they are given two choices; either ignore the GPIO API:
> 
>   outl(0xc000, gpio_base + GPIO_OUTPUT_VAL);
>   outl(0xc000, gpio_base + GPIO_OUTPUT_ENABLE);
> 
> Alternatively, call each GPIO update separately:
> 
>   geode_gpio_set(14, GPIO_OUTPUT_VAL);
>   geode_gpio_set(15, GPIO_OUTPUT_VAL);
>   geode_gpio_set(14, GPIO_OUTPUT_ENABLE);
>   geode_gpio_set(15, GPIO_OUTPUT_ENABLE);
> 
> Neither are desirable.  This patch changes the GPIO API to allow for setting
> of multiple GPIOs at once; rather than being passed an integer, we pass
> a bitmask and provide a translation function.  The above code would now
> look like this:
> 
>   geode_gpio_set(geode_gpio(14)|geode_gpio(15), GPIO_OUTPUT_VAL);
>   geode_gpio_set(geode_gpio(14)|geode_gpio(15), GPIO_OUTPUT_ENABLE);
> 
> Since there are no upstream users of the GPIO API yet (afaik), best to
> change this now.  This also adds a bit of sanity checking; it is no
> longer possible to use a GPIO above 28.
> 
> 
> Note the semantics of geode_gpio_isset() have changed:
> geode_gpio_isset(geode_gpio(3)|geode_gpio(4), ...)
> will only return true iff both GPIOs are set. 
> 
> Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>

Acked-by: Jordan Crouse <[EMAIL PROTECTED]>

> diff --git a/arch/x86/kernel/geode_32.c b/arch/x86/kernel/geode_32.c
> index f12d8c5..9c7f7d3 100644
> --- a/arch/x86/kernel/geode_32.c
> +++ b/arch/x86/kernel/geode_32.c
> @@ -1,6 +1,7 @@
>  /*
>   * AMD Geode southbridge support code
>   * Copyright (C) 2006, Advanced Micro Devices, Inc.
> + * Copyright (C) 2007, Andres Salomon <[EMAIL PROTECTED]>
>   *
>   * 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
> @@ -51,45 +52,62 @@ EXPORT_SYMBOL_GPL(geode_get_dev_base);
>  
>  /* === GPIO API === */
>  
> -void geode_gpio_set(unsigned int gpio, unsigned int reg)
> +void geode_gpio_set(u32 gpio, unsigned int reg)
>  {
>   u32 base = geode_get_dev_base(GEODE_DEV_GPIO);
>  
>   if (!base)
>   return;
>  
> - if (gpio < 16)
> - outl(1 << gpio, base + reg);
> - else
> - outl(1 << (gpio - 16), base + 0x80 + reg);
> + /* low bank register */
> + if (gpio & 0x)
> + outl(gpio & 0x, base + reg);
> + /* high bank register */
> + gpio >>= 16;
> + if (gpio)
> + outl(gpio, base + 0x80 + reg);
>  }
>  EXPORT_SYMBOL_GPL(geode_gpio_set);
>  
> -void geode_gpio_clear(unsigned int gpio, unsigned int reg)
> +void geode_gpio_clear(u32 gpio, unsigned int reg)
>  {
>   u32 base = geode_get_dev_base(GEODE_DEV_GPIO);
>  
>   if (!base)
>   return;
>  
> - if (gpio < 16)
> - outl(1 << (gpio + 16), base + reg);
> - else
> - outl(1 << gpio, base + 0x80 + reg);
> + /* low bank register */
> + if (gpio & 0x)
> + outl((gpio & 0x) << 16, base + reg);
> + /* high bank register */
> + gpio &= (0x << 16);
> + if (gpio)
> + outl(gpio, base + 0x80 + reg);
>  }
>  EXPORT_SYMBOL_GPL(geode_gpio_clear);
>  
> -int geode_gpio_isset(unsigned int gpio, unsigned int reg)
> +int geode_gpio_isset(u32 gpio, unsigned int reg)
>  {
>   u32 base = geode_get_dev_base(GEODE_DEV_GPIO);
> + u32 val;
>  
>   if (!base)
>   return 0;
>  
> - if (gpio < 16)
> - return (inl(base + reg) & (1 << gpio)) ? 1 : 0;
> - else
> - return (inl(base + 0x80 + reg) & (1 << (gpio - 16))) ? 1 : 0;
> + /* low bank register */
> + if (gpio & 0x) {
> + val = inl(base + reg) & (gpio & 0x);
> + if ((gpio & 0x) == val)
> + return 1;
> + }
> + /* high bank register */
> + gpio >>= 16;
> + if (gpio) {
> + val = inl(base + 0x80 + reg) & gpio;
> + if (gpio == val)
> + return 1;
> + }
> + return 0;
>  }
>  EXPORT_SYMBOL_GPL(geode_gpio_isset);
>  
> diff --git a/include/asm-x86/geode.h b/include/asm-x86/geode.h
> index d948988..593d3ec 100644
> --- a/include/asm-x86/geode.h
> +++ b/include/asm-x86/geode.h
> @@ -119,9 +119,15 @@ extern int geode_get_dev_base(unsigned int dev);
>  #define GPIO_MAP_Z   0xE8
>  #define GPIO_MAP_W   0xEC
>  
> -extern void geode_gpio_set(unsigned int, unsigned int);
> -extern void geode_gpio_clear(unsigned int, unsigned int);
> -extern int geode_gpio_isset(unsigned int, unsigned int);
> +static inline u32 geode_gpio(unsigned int nr)
> +{
> + BUG_ON(nr > 28);
> + return 1 << nr;
> +}
> +
> +extern void geode_gpio_set(u32, unsigned int);
> +extern void geode_gpio_clear(u32, unsigned int);
> +extern int 

Re: GEODE: use symbolic constant in cs5536 reboot fixup

[Jordan Crouse]

On 18/10/07 15:26 -0400, Andres Salomon wrote:
> Simple cosmetic update for the cs5536 reboot fixup; define the MSR that's used
> for rebooting in geode.h, and use the define.
> 
> Signed-off-by: Andres Salomon <[EMAIL PROTECTED]>

Acked-by: Jordan Crouse <[EMAIL PROTECTED]>

> diff --git a/arch/x86/kernel/reboot_fixups_32.c 
> b/arch/x86/kernel/reboot_fixups_32.c
> index 8b30b26..1a07bbe 100644
> --- a/arch/x86/kernel/reboot_fixups_32.c
> +++ b/arch/x86/kernel/reboot_fixups_32.c
> @@ -12,6 +12,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  static void cs5530a_warm_reset(struct pci_dev *dev)
>  {
> @@ -24,11 +25,8 @@ static void cs5530a_warm_reset(struct pci_dev *dev)
>  
>  static void cs5536_warm_reset(struct pci_dev *dev)
>  {
> - /*
> -  * 6.6.2.12 Soft Reset (DIVIL_SOFT_RESET)
> -  * writing 1 to the LSB of this MSR causes a hard reset.
> -  */
> - wrmsrl(0x51400017, 1ULL);
> + /* writing 1 to the LSB of this MSR causes a hard reset */
> + wrmsrl(MSR_DIVIL_SOFT_RESET, 1ULL);
>   udelay(50); /* shouldn't get here but be safe and spin a while */
>  }
>  
> diff --git a/include/asm-x86/geode.h b/include/asm-x86/geode.h
> index d948988..771af33 100644
> --- a/include/asm-x86/geode.h
> +++ b/include/asm-x86/geode.h
> @@ -38,6 +38,8 @@ extern int geode_get_dev_base(unsigned int dev);
>  #define MSR_LBAR_ACPI0x514E
>  #define MSR_LBAR_PMS 0x514F
>  
> +#define MSR_DIVIL_SOFT_RESET 0x51400017
> +
>  #define MSR_PIC_YSEL_LOW 0x51400020
>  #define MSR_PIC_YSEL_HIGH0x51400021
>  #define MSR_PIC_ZSEL_LOW 0x51400022
> 
> 

-- 
Jordan Crouse
Systems Software Development Engineer 
Advanced Micro Devices, Inc.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: SLUB: Avoid atomic operation for slab_unlock

[Nick Piggin]

[sorry, I read and replied to my inbox before mailing lists...
please ignore the last mail on this patch, and reply to this
one which is properly threaded]

On Friday 19 October 2007 08:15, Christoph Lameter wrote:
> Currently page flags are only modified in SLUB under page lock. This means
> that we do not need an atomic operation to release the lock since there
> is nothing we can race against that is modifying page flags. We can simply
> clear the bit without the use of an atomic operation and make sure that
> this change becomes visible after the other changes to slab metadata
> through a memory barrier.
>
> The performance of slab_free() increases 10-15% (SMP configuration doing
> a long series of remote frees).

Ah, thanks, but can we just use my earlier patch that does the
proper __bit_spin_unlock which is provided by
bit_spin_lock-use-lock-bitops.patch

This primitive should have a better chance at being correct, and
also potentially be more optimised for each architecture (it
only has to provide release consistency).

I have attached the patch here just for reference, but actually
I am submitting it properly as part of a patch series today, now
that the base bit lock patches have been sent upstream.


>  mm/slub.c |   15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff -puN mm/slub.c~slub-avoid-atomic-operation-for-slab_unlock mm/slub.c
> --- a/mm/slub.c~slub-avoid-atomic-operation-for-slab_unlock
> +++ a/mm/slub.c
> @@ -1181,9 +1181,22 @@ static __always_inline void slab_lock(st
>   bit_spin_lock(PG_locked, >flags);
>  }
>
> +/*
> + * Slab unlock version that avoids having to use atomic operations
> + * (echos some of the code of bit_spin_unlock!)
> + */
>  static __always_inline void slab_unlock(struct page *page)
>  {
> - bit_spin_unlock(PG_locked, >flags);
> +#ifdef CONFIG_SMP
> + unsigned long flags;
> +
> + flags = page->flags & ~(1 << PG_locked);
> +
> + smp_wmb();
> + page->flags = flags;
> +#endif
> + preempt_enable();
> + __release(bitlock);
>  }

This looks wrong, because it would allow the store unlocking
flags to pass a load within the critical section.

stores aren't allowed to pass loads in x86 (only vice versa),
so you might have been confused by looking at x86's spinlocks
into thinking this will work. However on powerpc and sparc, I
don't think it gives you the right types of barriers.

Slub can use the non-atomic version to unlock because other flags will not
get modified with the lock held.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

---
 mm/slub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -1185,7 +1185,7 @@ static __always_inline void slab_lock(st
 
 static __always_inline void slab_unlock(struct page *page)
 {
-	bit_spin_unlock(PG_locked, >flags);
+	__bit_spin_unlock(PG_locked, >flags);
 }
 
 static __always_inline int slab_trylock(struct page *page)

Re: + slub-avoid-atomic-operation-for-slab_unlock.patch added to -mm tree

[Nick Piggin]

On Friday 19 October 2007 08:31, [EMAIL PROTECTED] wrote:

> --
> Subject: SLUB: avoid atomic operation for slab_unlock
> From: Christoph Lameter <[EMAIL PROTECTED]>
>
> Currently page flags are only modified in SLUB under page lock.  This means
> that we do not need an atomic operation to release the lock since there is
> nothing we can race against that is modifying page flags.  We can simply
> clear the bit without the use of an atomic operation and make sure that
> this change becomes visible after the other changes to slab metadata
> through a memory barrier.
>
> The performance of slab_free() increases 10-15% (SMP configuration doing
> a long series of remote frees).

Ah, thanks, but can we just use my earlier patch that does the
proper __bit_spin_unlock which is provided by
bit_spin_lock-use-lock-bitops.patch

This primitive should have a better chance at being correct, and
also potentially be more optimised for each architecture (it
only has to provide release consistency).

I have attached the patch here just for reference, but actually
I am submitting it properly as part of a patch series today, now
that the base bit lock patches have been sent upstream.


>  mm/slub.c |   15 ++-
>  1 file changed, 14 insertions(+), 1 deletion(-)
>
> diff -puN mm/slub.c~slub-avoid-atomic-operation-for-slab_unlock mm/slub.c
> --- a/mm/slub.c~slub-avoid-atomic-operation-for-slab_unlock
> +++ a/mm/slub.c
> @@ -1181,9 +1181,22 @@ static __always_inline void slab_lock(st
>   bit_spin_lock(PG_locked, >flags);
>  }
>
> +/*
> + * Slab unlock version that avoids having to use atomic operations
> + * (echos some of the code of bit_spin_unlock!)
> + */
>  static __always_inline void slab_unlock(struct page *page)
>  {
> - bit_spin_unlock(PG_locked, >flags);
> +#ifdef CONFIG_SMP
> + unsigned long flags;
> +
> + flags = page->flags & ~(1 << PG_locked);
> +
> + smp_wmb();
> + page->flags = flags;
> +#endif
> + preempt_enable();
> + __release(bitlock);
>  }

This looks wrong, because it would allow the store unlocking
flags to pass a load within the critical section.

stores aren't allowed to pass loads in x86 (only vice versa),
so you might have been confused by looking at x86's spinlocks
into thinking this will work. However on powerpc and sparc, I
don't think it gives you the right types of barriers.
Slub can use the non-atomic version to unlock because other flags will not
get modified with the lock held.

Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>

---
 mm/slub.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Index: linux-2.6/mm/slub.c
===
--- linux-2.6.orig/mm/slub.c
+++ linux-2.6/mm/slub.c
@@ -1185,7 +1185,7 @@ static __always_inline void slab_lock(st
 
 static __always_inline void slab_unlock(struct page *page)
 {
-	bit_spin_unlock(PG_locked, >flags);
+	__bit_spin_unlock(PG_locked, >flags);
 }
 
 static __always_inline int slab_trylock(struct page *page)

Re: [PATCH] synchronize_irq needs a barrier

[Linus Torvalds]

On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
> 
> I agree and you can see that in fact, we don't have enough barrier on
> the other side since spin_unlock doesn't prevent subsequent loads from
> crossing a previous store...
> 
> I wonder if that's worth trying to address, adding a barrier in
> handle_IRQ_event for example, or we can continue ignoring the barrier
> and let some drivers do their own fixes in fancy ways.

So how about something like this (untested! not necessarily very well 
thought through either!)

Basic notion: the only thing that serializes the IRQ_INPROGRESS flag is 
the descriptor lock. And we don't have to (or even want to!) hold it while 
waiting for the thing, but we want to *have*held*it* in between whatever 
we're synchronizing with.

The internal irq handler functions already held the lock when they did 
whatever they need to serialize - and they are possibly performance 
critical too - so they use the "internal" function that doesn't get the 
lock unnecessarily again.

Hmm? 

Linus

---
 kernel/irq/manage.c |   22 ++
 1 files changed, 18 insertions(+), 4 deletions(-)

diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c
index 80eab7a..f3e9575 100644
--- a/kernel/irq/manage.c
+++ b/kernel/irq/manage.c
@@ -14,6 +14,18 @@
 
 #include "internals.h"
 
+/*
+ * Internally wait for IRQ_INPROGRESS to go away on other CPU's,
+ * after having serialized with the descriptor lock.
+ */
+static inline void do_synchronize_irq(struct irq_desc *desc)
+{
+#ifdef CONFIG_SMP
+   while (desc->status & IRQ_INPROGRESS)
+   cpu_relax();
+#endif
+}
+
 #ifdef CONFIG_SMP
 
 /**
@@ -28,13 +40,15 @@
  */
 void synchronize_irq(unsigned int irq)
 {
+   unsigned long flags;
struct irq_desc *desc = irq_desc + irq;
 
if (irq >= NR_IRQS)
return;
 
-   while (desc->status & IRQ_INPROGRESS)
-   cpu_relax();
+   spin_lock_irqsave(>lock, flags);
+   spin_unlock_irqrestore(>lock, flags);
+   do_synchronize_irq(desc);
 }
 EXPORT_SYMBOL(synchronize_irq);
 
@@ -129,7 +143,7 @@ void disable_irq(unsigned int irq)
 
disable_irq_nosync(irq);
if (desc->action)
-   synchronize_irq(irq);
+   do_synchronize_irq(desc);
 }
 EXPORT_SYMBOL(disable_irq);
 
@@ -443,7 +457,7 @@ void free_irq(unsigned int irq, void *dev_id)
unregister_handler_proc(irq, action);
 
/* Make sure it's not being used on another CPU */
-   synchronize_irq(irq);
+   do_synchronize_irq(desc);
 #ifdef CONFIG_DEBUG_SHIRQ
/*
 * It's a shared IRQ -- the driver ought to be
-
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/

PDA Suspend SA1100

[Kristoffer Ericson]

Greetings,

I've been trying to implement proper suspend on my jornada 720 machine. But as 
far as I can see it never reaches
the sa11x0_suspend code.

I've linked power button event to produce APM_SUSPEND and I can see that it 
says "Stopping TASKS ==". It then
blanks screen but keeps LCD powerd. I know it goes into resume again since 
removing backlight code in resume function
effectivly turns off the LCD.

Im assuming that it tries to suspend but fails at some point and tries to 
return into normal operations?
Exactly what is needed to get the suspend procedure happy? Does every driver 
need to have suspend/resume code?

Best wishes
Kristoffer Ericson
-
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] hash: Add explicit u32 and u64 versions of hash

[Matthew Wilcox]

The 32-bit version is more efficient (and apparently gives better hash
results than the 64-bit version), so users who are only hashing a 32-bit
quantity can now opt to use the 32-bit version explicitly, rather than
promoting to a long.

Signed-off-by: Matthew Wilcox <[EMAIL PROTECTED]>
---
 include/linux/hash.h |   42 +++---
 1 files changed, 27 insertions(+), 15 deletions(-)

diff --git a/include/linux/hash.h b/include/linux/hash.h
index acf17bb..06d25c1 100644
--- a/include/linux/hash.h
+++ b/include/linux/hash.h
@@ -1,6 +1,6 @@
 #ifndef _LINUX_HASH_H
 #define _LINUX_HASH_H
-/* Fast hashing routine for a long.
+/* Fast hashing routine for ints,  longs and pointers.
(C) 2002 William Lee Irwin III, IBM */
 
 /*
@@ -13,23 +13,30 @@
  * them can use shifts and additions instead of multiplications for
  * machines where multiplications are slow.
  */
-#if BITS_PER_LONG == 32
+
+#include 
+
 /* 2^31 + 2^29 - 2^25 + 2^22 - 2^19 - 2^16 + 1 */
-#define GOLDEN_RATIO_PRIME 0x9e370001UL
-#elif BITS_PER_LONG == 64
+#define GOLDEN_RATIO_PRIME_32 0x9e370001UL
 /*  2^63 + 2^61 - 2^57 + 2^54 - 2^51 - 2^18 + 1 */
-#define GOLDEN_RATIO_PRIME 0x9e37fffc0001UL
+#define GOLDEN_RATIO_PRIME_64 0x9e37fffc0001UL
+
+#if BITS_PER_LONG == 32
+#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_PRIME_32
+#define hash_long(val, bits) hash_32(val, bits)
+#elif BITS_PER_LONG == 64
+#define hash_long(val, bits) hash_64(val, bits)
+#define GOLDEN_RATIO_PRIME GOLDEN_RATIO_PRIME_64
 #else
-#error Define GOLDEN_RATIO_PRIME for your wordsize.
+#error Wordsize not 32 or 64
 #endif
 
-static inline unsigned long hash_long(unsigned long val, unsigned int bits)
+static inline u64 hash_64(u64 val, unsigned int bits)
 {
-   unsigned long hash = val;
+   u64 hash = val;
 
-#if BITS_PER_LONG == 64
/*  Sigh, gcc can't optimise this alone like it does for 32 bits. */
-   unsigned long n = hash;
+   u64 n = hash;
n <<= 18;
hash -= n;
n <<= 33;
@@ -42,15 +49,20 @@ static inline unsigned long hash_long(unsigned long val, 
unsigned int bits)
hash += n;
n <<= 2;
hash += n;
-#else
+
+   /* High bits are more random, so use them. */
+   return hash >> (64 - bits);
+}
+
+static inline u32 hash_32(u32 val, unsigned int bits)
+{
/* On some cpus multiply is faster, on others gcc will do shifts */
-   hash *= GOLDEN_RATIO_PRIME;
-#endif
+   u32 hash = val * GOLDEN_RATIO_PRIME_32;
 
/* High bits are more random, so use them. */
-   return hash >> (BITS_PER_LONG - bits);
+   return hash >> (32 - bits);
 }
-   
+
 static inline unsigned long hash_ptr(void *ptr, unsigned int bits)
 {
return hash_long((unsigned long)ptr, bits);
-- 
1.4.4.2

-
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: [NFS] Kernel Oops in NFS

[Trond Myklebust]

On Thu, 2007-10-18 at 16:01 -0500, [EMAIL PROTECTED] wrote:
> > We've come across an Oops, in what appears to NFS.
> > 
> > 2.6.22.6 vanilla + realtime-lsm
> > RHEL4 over PXE/NFS_ROOT
> > 
> > 
> > Oct  9 14:26:13 WS15 gdm(pam_unix)[6038]: session opened for 
> > user mockj by (uid=0) Oct  9 14:26:48 WS15 gconfd 
> > (mockj-7583): starting (version 2.8.1), pid
> > 7583 user 'mockj'
> > Oct  9 14:26:48 WS15 kernel: BUG: unable to handle kernel 
> > NULL pointer dereference at virtual address 0004 Oct  9 
> > 14:26:48 WS15 kernel:  printing eip:
> > Oct  9 14:26:48 WS15 kernel: c01a9fb8
> > Oct  9 14:26:48 WS15 kernel: *pde = c691d067 Oct  9 14:26:48 
> > WS15 kernel: Oops:  [#1] Oct  9 14:26:48 WS15 kernel: 
> > PREEMPT SMP Oct  9 14:26:48 WS15 kernel: Modules linked in: 
> > lm85 w83781d hwmon_vid hwmon ipv6 parport_pc lp parport 
> > autofs4 tulip dm_mirror dm_mod button battery ac mct_u232 
> > usbserial uhci_hcd ehci_hcd nvidia(P) e7xxx_edac edac_mc 
> > rng_core i2c_i801 i2c_core aic79xx scsi_transport_spi 
> > ata_piix libata scsi_mod snd_intel8x0 snd_ac97_codec ac97_bus 
> > snd_pcm_oss snd_mixer_oss snd_pcm snd_page_alloc 
> > snd_seq_dummy snd_seq_oss snd_seq_midi_event snd_seq 
> > snd_timer snd_seq_device snd soundcore realtime commoncap
> > Oct  9 14:26:48 WS15 kernel: CPU:0
> > Oct  9 14:26:48 WS15 kernel: EIP:0060:[]Tainted: P
> > VLI
> > Oct  9 14:26:48 WS15 kernel: EFLAGS: 00210246   (2.6.22-6.0.WSsmp #1)
> > Oct  9 14:26:48 WS15 kernel: EIP is at nfs_lookup+0x11b/0x26a
> > Oct  9 14:26:48 WS15 kernel: eax:    ebx: c0367600   ecx:
> >    edx: 
> > Oct  9 14:26:48 WS15 kernel: esi:    edi:    ebp:
> >    esp: f63b5d44
> > Oct  9 14:26:48 WS15 kernel: ds: 007b   es: 007b   fs: 00d8  gs: 0033
> > ss: 0068
> > Oct  9 14:26:48 WS15 kernel: Process gconfd-2 (pid: 7583, 
> > ti=f63b4000 task=f6273070 task.ti=f63b4000) Oct  9 14:26:48 
> > WS15 kernel: Stack: f63b5d60 f63b5d98 f63b5d9c 7fff
> > f63b5ed8 f63ef118 f63f5e8c f63b0002 
> > Oct  9 14:26:48 WS15 kernel:f63db21c  
> > c014843e 
> > 000e 0001 0001 81c0 
> > Oct  9 14:26:48 WS15 kernel:0002 1459 
> > 00c9 0271
> >  2000 0008 
> > Oct  9 14:26:48 WS15 kernel: Call Trace:
> > Oct  9 14:26:48 WS15 kernel:  [] 
> > write_cache_pages+0x235/0x285 Oct  9 14:26:48 WS15 kernel:  
> > [] nfs_flush_one+0x0/0xe5 Oct  9 14:26:48 WS15 
> > kernel:  [] mapping_tagged+0x2b/0x32 Oct  9 
> > 14:26:48 WS15 kernel:  [] d_alloc+0x15e/0x166 Oct  
> > 9 14:26:48 WS15 kernel:  [] 
> > lookup_one_len+0xc5/0xe0 Oct  9 14:26:48 WS15 kernel:  
> > [] nfs_sillyrename+0x12b/0x253 Oct  9 14:26:48 WS15 
> > kernel:  [] nfs_permission+0x0/0x147 Oct  9 
> > 14:26:48 WS15 kernel:  [] nfs_unlink+0x81/0xfc Oct  
> > 9 14:26:48 WS15 kernel:  [] may_delete+0x55/0x10a 
> > Oct  9 14:26:48 WS15 kernel:  [] 
> > vfs_unlink+0xa1/0xc5 Oct  9 14:26:48 WS15 kernel:  
> > [] do_unlinkat+0x95/0xf5 Oct  9 14:26:48 WS15 
> > kernel:  [] do_syscall_trace+0x15c/0x19d Oct  9 
> > 14:26:48 WS15 kernel:  [] syscall_call+0x7/0xb Oct  
> > 9 14:26:48 WS15 kernel:  [] 
> > cache_make_upcall+0x40/0x129 Oct  9 14:26:48 WS15 kernel:  
> > === Oct  9 14:26:48 WS15 kernel: Code: 24 
> > 14 8b 00 83 c2 20 8b 58 38 8d 44
> > 24 1c 89 04 24 8b 44 24 18 ff 53 20 83 f8 fe 0f 84 93 00 00 
> > 00 85 c0 89
> > c5 0f 88 3d 01 00 00 <8b> 76 04 8b 54 24 18 89 74 24 10 8b 82 
> > a4 00 00 00 8b 54 24 64 Oct  9 14:26:48 WS15 kernel: EIP: 
> > [] nfs_lookup+0x11b/0x26a SS:ESP 0068:f63b5d4
> > 
> > We haven't seen any negative side-effects other than users 
> > seeing this in Kwrited quite often.  We've yet to update to 
> > 2.6.22.9, however we've examined the change logs and patches 
> > associated with NFS between then and now, and don't see 
> > anything appropriate for the errors we're receiving.  Let me 
> > know if you need anything else for this...
> 
> I was just checking to see if there's anything that I'm missing here, in
> regards to never hearing a single thing back about this.
> 
> - Jason Mock

Well... Your Oops did have the 'tainted' flag set, but in this case I
believe that the issue is already known. Please try

  
http://client.linux-nfs.org/Linux-2.6.x/2.6.22/linux-2.6.22-010-fix_nfs_reval_fsid.dif

Trond

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] I/OAT: Add support for version 2 of ioatdma device

[Shannon Nelson]

Add support for version 2 of the ioatdma device.  This device handles
the descriptor chain and DCA services slightly differently:
 - Instead of moving the dma descriptors between a busy and an idle chain,
   this new version uses a single circular chain so that we don't have
   rewrite the next_descriptor pointers as we add new requests, and the
   device doesn't need to re-read the last descriptor.
 - The new device has the DCA tags defined internally instead of needing
   them defined statically.

Signed-off-by: Shannon Nelson <[EMAIL PROTECTED]>
---

 drivers/dma/ioat.c  |   11 +
 drivers/dma/ioat_dca.c  |  164 +++
 drivers/dma/ioat_dma.c  |  578 ---
 drivers/dma/ioatdma.h   |   32 +-
 drivers/dma/ioatdma_hw.h|   33 ++
 drivers/dma/ioatdma_registers.h |  106 ++-
 include/linux/pci_ids.h |1 
 7 files changed, 780 insertions(+), 145 deletions(-)

diff --git a/drivers/dma/ioat.c b/drivers/dma/ioat.c
index f204c39..16e0fd8 100644
--- a/drivers/dma/ioat.c
+++ b/drivers/dma/ioat.c
@@ -39,10 +39,14 @@ MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Intel Corporation");
 
 static struct pci_device_id ioat_pci_tbl[] = {
+   /* I/OAT v1 platforms */
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT) },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_CNB)  },
{ PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SCNB) },
{ PCI_DEVICE(PCI_VENDOR_ID_UNISYS, PCI_DEVICE_ID_UNISYS_DMA_DIRECTOR) },
+
+   /* I/OAT v2 platforms */
+   { PCI_DEVICE(PCI_VENDOR_ID_INTEL, PCI_DEVICE_ID_INTEL_IOAT_SNB) },
{ 0, }
 };
 
@@ -74,10 +78,17 @@ static int ioat_setup_functionality(struct pci_dev *pdev, 
void __iomem *iobase)
if (device->dma && ioat_dca_enabled)
device->dca = ioat_dca_init(pdev, iobase);
break;
+   case IOAT_VER_2_0:
+   device->dma = ioat_dma_probe(pdev, iobase);
+   if (device->dma && ioat_dca_enabled)
+   device->dca = ioat2_dca_init(pdev, iobase);
+   break;
default:
err = -ENODEV;
break;
}
+   if (!device->dma)
+   err = -ENODEV;
return err;
 }
 
diff --git a/drivers/dma/ioat_dca.c b/drivers/dma/ioat_dca.c
index ba98571..0fa8a98 100644
--- a/drivers/dma/ioat_dca.c
+++ b/drivers/dma/ioat_dca.c
@@ -261,3 +261,167 @@ struct dca_provider *ioat_dca_init(struct pci_dev *pdev, 
void __iomem *iobase)
return dca;
 }
 
+
+static int ioat2_dca_add_requester(struct dca_provider *dca, struct device 
*dev)
+{
+   struct ioat_dca_priv *ioatdca = dca_priv(dca);
+   struct pci_dev *pdev;
+   int i;
+   u16 id;
+   u16 global_req_table;
+
+   /* This implementation only supports PCI-Express */
+   if (dev->bus != _bus_type)
+   return -ENODEV;
+   pdev = to_pci_dev(dev);
+   id = dcaid_from_pcidev(pdev);
+
+   if (ioatdca->requester_count == ioatdca->max_requesters)
+   return -ENODEV;
+
+   for (i = 0; i < ioatdca->max_requesters; i++) {
+   if (ioatdca->req_slots[i].pdev == NULL) {
+   /* found an empty slot */
+   ioatdca->requester_count++;
+   ioatdca->req_slots[i].pdev = pdev;
+   ioatdca->req_slots[i].rid = id;
+   global_req_table =
+ readw(ioatdca->dca_base + IOAT_DCA_GREQID_OFFSET);
+   writel(id | IOAT_DCA_GREQID_VALID,
+  ioatdca->iobase + global_req_table + (i * 4));
+   return i;
+   }
+   }
+   /* Error, ioatdma->requester_count is out of whack */
+   return -EFAULT;
+}
+
+static int ioat2_dca_remove_requester(struct dca_provider *dca,
+ struct device *dev)
+{
+   struct ioat_dca_priv *ioatdca = dca_priv(dca);
+   struct pci_dev *pdev;
+   int i;
+   u16 global_req_table;
+
+   /* This implementation only supports PCI-Express */
+   if (dev->bus != _bus_type)
+   return -ENODEV;
+   pdev = to_pci_dev(dev);
+
+   for (i = 0; i < ioatdca->max_requesters; i++) {
+   if (ioatdca->req_slots[i].pdev == pdev) {
+   global_req_table =
+ readw(ioatdca->dca_base + IOAT_DCA_GREQID_OFFSET);
+   writel(0, ioatdca->iobase + global_req_table + (i * 4));
+   ioatdca->req_slots[i].pdev = NULL;
+   ioatdca->req_slots[i].rid = 0;
+   ioatdca->requester_count--;
+   return i;
+   }
+   }
+   return -ENODEV;
+}
+
+static u8 ioat2_dca_get_tag(struct dca_provider *dca, int cpu)
+{
+   u8 tag;
+
+   tag = 

Re: [PATCH] synchronize_irq needs a barrier

[Benjamin Herrenschmidt]

On Thu, 2007-10-18 at 15:52 -0700, Linus Torvalds wrote:
> 
> On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
> > 
> > The barrier would guarantee that ioc->active (and in fact the write to
> > the chip too above) are globally visible
> 
> No, it doesn't really guarantee that.
> 
> The thing is, there is no such thing as "globally visible".
> 
> There is a "ordering of visibility wrt CPU's", but it's not global, it's 
> quite potentially per-CPU. So a barrier on one CPU doesn't guarantee 
> anything at all without a barrier on the *other* CPU.
> 
> That said, the interrupt handling itself contains various barriers on the 
> CPU's that receive interrupts, thanks to the spinlocking. But I do agree 
> with Herbert that adding a "smb_mb()" is certainly in no way "obviously 
> correct", because it doesn't talk about what the other side does wrt 
> barriers and that word in memory.

I agree and you can see that in fact, we don't have enough barrier on
the other side since spin_unlock doesn't prevent subsequent loads from
crossing a previous store...

I wonder if that's worth trying to address, adding a barrier in
handle_IRQ_event for example, or we can continue ignoring the barrier
and let some drivers do their own fixes in fancy ways.

Ben.


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: latest checkpatch

[Andi Kleen]

Avi Kivity <[EMAIL PROTECTED]> writes:

> This is more useful operating on an entire file, so the script can see
> all the context.
>
> A 'gcc -Windentation-contradicts-codeflow -Werror' would be nice.

I had a tool long ago on the Amiga which did exactly that. It double checked
that the indentation matched the code flow and flagged any differences. 
It was a dumb tool -- not a full C parser; but worked just fine. I got
it from some free software floppy disk. Unfortunately I forgot the
name and was never able to find it again.

These days emacs can do it for me though, but doing it in batch would
be nicer.
 
-Andi
-
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: schedstat needs a diet

[Mathieu Desnoyers]

* Ken Chen ([EMAIL PROTECTED]) wrote:
> On 10/18/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> > Good question indeed. How large is this memory footprint exactly ? If it
> > is as small as you say, I suspect that the real issue could be that
> > these variable are accessed by the scheduler critical paths and
> > therefore trash the caches.
> 
> Maybe my wording was ambiguous, I meant to reduce cache line pollution
> when accessing these schedstat fields.
> 
> With unsigned long, on x86_64, schedstat consumes 288 bytes for each
> sched_domain and 128 bytes in struct rq.  On a extremely small system
> that has a couple of CPU sockets with one level of numa node, there
> will be 704 bytes per CPU for schedstat.  Given the sparseness of
> them, we are probably talking about 11-12 cache line eviction on
> several heavily used scheduler functions.  Reduce cache line pollution
> is the primary goal, actual memory consumption isn't really a concern.
> 

Generally speaking, if such cache trashing is an issue, why don't we
make sure that each task struct member is declared in this structure
following its access frequency ? (except for #ifdef blocks, which should
stay together) It could then statistically save a lot of cachelines.

Or is it already the case ? It doesn't look like it when I see:

struct list_head ptrace_list;

Just beside the 

struct mm_struct *mm, *active_mm;

pointers.

Mathieu

-- 
Mathieu Desnoyers
Computer Engineering Ph.D. Student, Ecole Polytechnique de Montreal
OpenPGP key fingerprint: 8CD5 52C3 8E3C 4140 715F  BA06 3F25 A8FE 3BAE 9A68
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

RE: RocketPort Linux driver errors on module reload

[Nick Thompson]

>-Original Message-
>From: Jiri Slaby [mailto:[EMAIL PROTECTED]
>Sent: Thursday, October 18, 2007 5:08 PM
>To: Nick Thompson
>Cc: Jiri Slaby; linux-kernel@vger.kernel.org; Ferenc Wagner
>Subject: Re: RocketPort Linux driver errors on module reload
>
>
>>On 10/17/2007 09:48 PM, Nick Thompson wrote:
>>  Thanks a lot for the feedback, it's very much appreciated. Like I said, 
>> there is an  >>active project here at Comtrol to get 3.08 beta up to 
>> Linux kernel coding standards, once   >>that gets somewhere near done, a 
>> patch will be forthcoming.
>
>And the last question, when do you expect/estimate this would happen?
>
>thanks,
>-- 
>Jiri Slaby ([EMAIL PROTECTED])
>Faculty of Informatics, Masaryk University

Jiri,
 To be honest, it would be hard to estimate at this point. I've discussed it 
with one of our software engineers, but we do not know how long it will be at 
this point, as there is a lot of work to do to get it up to kernel coding 
standards. I will definitely keep the list up to date.

Regards,

Nick

Nick Thompson
Technical Support Specialist [EMAIL PROTECTED]
Comtrol Corporation ftp://ftp.comtrol.com
6655 Wedgwood Rd. Ste 120 http://www.comtrol.com
Maple Grove, MN. 55311 Sales: (800)GO-ROCKET
-
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: schedstat needs a diet

[Ken Chen]

On 10/18/07, Mathieu Desnoyers <[EMAIL PROTECTED]> wrote:
> Good question indeed. How large is this memory footprint exactly ? If it
> is as small as you say, I suspect that the real issue could be that
> these variable are accessed by the scheduler critical paths and
> therefore trash the caches.

Maybe my wording was ambiguous, I meant to reduce cache line pollution
when accessing these schedstat fields.

With unsigned long, on x86_64, schedstat consumes 288 bytes for each
sched_domain and 128 bytes in struct rq.  On a extremely small system
that has a couple of CPU sockets with one level of numa node, there
will be 704 bytes per CPU for schedstat.  Given the sparseness of
them, we are probably talking about 11-12 cache line eviction on
several heavily used scheduler functions.  Reduce cache line pollution
is the primary goal, actual memory consumption isn't really a concern.

- Ken
-
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] synchronize_irq needs a barrier

[Linus Torvalds]

On Fri, 19 Oct 2007, Benjamin Herrenschmidt wrote:
> 
> The barrier would guarantee that ioc->active (and in fact the write to
> the chip too above) are globally visible

No, it doesn't really guarantee that.

The thing is, there is no such thing as "globally visible".

There is a "ordering of visibility wrt CPU's", but it's not global, it's 
quite potentially per-CPU. So a barrier on one CPU doesn't guarantee 
anything at all without a barrier on the *other* CPU.

That said, the interrupt handling itself contains various barriers on the 
CPU's that receive interrupts, thanks to the spinlocking. But I do agree 
with Herbert that adding a "smb_mb()" is certainly in no way "obviously 
correct", because it doesn't talk about what the other side does wrt 
barriers and that word in memory.

Linus
-
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: [linux-usb-devel] usb+sysfs: duplicate filename 'bInterfaceNumber'

[Greg KH]

On Wed, Oct 17, 2007 at 10:48:52AM -0400, Alan Stern wrote:
> On Tue, 16 Oct 2007, Matthew Dharm wrote:
> 
> > On Tue, Oct 16, 2007 at 02:04:43PM -0400, Alan Stern wrote:
> > > On Tue, 16 Oct 2007, Matthew Dharm wrote:
> > > 
> > > > I haven't looked at this code at all, but neither approach feels right 
> > > > to
> > > > me.
> > > > 
> > > > How does this work at all?  Even if you load a driver later, wouldn't it
> > > > call usb_set_interface(), which would call usb_create_sysfs_intf_files()
> > > > and hit the same issue?
> > > 
> > > usb_set_interface() is smart enough to remove the old interface files
> > > before creating new ones, since it expects them to exist already.  
> > > Hence there's no problem in that scenario.
> > > 
> > > But usb_set_configuration doesn't expect there to be any pre-existing
> > > interface files, because there isn't even an interface until the
> > > registration is performed.
> > 
> > And I'm guessing that you can't call usb_create_sysfs_intf_files() until
> > registration is performed, right?
> 
> Right.
> 
> > > The most important reason has to do with the endpoint pseudo-devices.  
> > > Different altsettings can have different endpoints, so those have to be
> > > removed and re-created whenever the altsetting changes.
> > 
> > Right, altsettings.  I forgot about those.  I only ever think in terms of
> > multiple configurations.
> > 
> > *grumble*
> > 
> > If usb_set_interface() has to be smart enough to remove existing files
> > first already, then I guess it's reasonably symmetric to have
> > usb_set_configuration() have the same smarts.  Maybe they can share some
> > common code, even.
> 
> It's not a big deal to remove the files first.  In fact, here's a patch 
> to do it.  Dave, see if this doesn't fix your problem.  I don't like it 
> much because it does an unnecessary remove/create cycle, but that's 
> better than doing something wrong.
> 
> It's slightly odd that the sysfs core logs an error when you try to 
> create the same file twice but it doesn't when you try to remove a 
> non-existent file (or try to remove an existing file twice).  Oh 
> well...

I used to have the 'remove a non-existant file' warning, but that just
triggered _way_ too many responses :)


> Index: usb-2.6/drivers/usb/core/message.c
> ===
> --- usb-2.6.orig/drivers/usb/core/message.c
> +++ usb-2.6/drivers/usb/core/message.c
> @@ -1643,7 +1643,13 @@ free_interfaces:
>   intf->dev.bus_id, ret);
>   continue;
>   }
> - usb_create_sysfs_intf_files (intf);
> +
> + /* The driver's probe method can call usb_set_interface(),
> +  * which would mean the interface's sysfs files are already
> +  * created.  Just in case, we'll remove them first.
> +  */
> + usb_remove_sysfs_intf_files(intf);
> + usb_create_sysfs_intf_files(intf);
>   }

If this fixes the problem, care to resend it with a signed-off-by:?

Yeah, it's not the nicest solution, but I can't think of any other one
either right now :(

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: [bisected][mismerge?] Re: [microcode] 2.6.23.git pulled this morning oopses loading P4 microcode

[Samuel Thibault]

Hi,

Mike Galbraith, le Thu 18 Oct 2007 19:56:38 +0200, a écrit :
> The winner of a very long git bisect session:
> 
> unicode diacritics support

Uh, I fail to see how that could have an impact, I've again checked the
boundaries, it looks fine, please people have a look.

Could you try something odd?  On your tree that has the change reverted,
please try the attached patch, which makes the array the same size at it
would be with the change, possibly triggering bugs in completely other
parts of the kernel.

Samuel
--- defkeymap.c_shipped.old 2007-10-18 22:44:59.0 +
+++ defkeymap.c_shipped 2007-10-18 22:44:43.0 +
@@ -222,7 +222,7 @@
NULL,
 };
 
-struct kbdiacr accent_table[MAX_DIACR] = {
+struct kbdiacr accent_table[(MAX_DIACR*3*4-MAX_DIACR*3)/3] = {
{'`', 'A', '\300'}, {'`', 'a', '\340'},
{'\'', 'A', '\301'},{'\'', 'a', '\341'},
{'^', 'A', '\302'}, {'^', 'a', '\342'},

Re: [PATCH 2/3] ide: Fix siimage driver accessing beyond array boundary

[Bartlomiej Zolnierkiewicz]

On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> 
> On Thu, 2007-10-18 at 16:02 +0400, Sergei Shtylyov wrote:
> > Benjamin Herrenschmidt wrote:
> > 
> > > The siimage use an incorrect construct to access the other drive
> > > of a pair, causing it to access beyond an array boundary on non-0
> > > interfaces. This fixes it by using the new ide_get_paired_drive()
> > > hepler instead.
> > 
> > > Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> > 
> > Please update the driver version in the driver's heading comment. 
> > Otherwise
> > 
> > Acked-by: Sergei Shtylyov <[EMAIL PROTECTED]>
> 
> I don't believe much in driver versions in tree... the kernel version is
> what matter... Bart, what's your stance there ?

Similar opinion here but sometimes driver versions are useful, i.e.:

* during development or while debugging regressions to distinguish
  real changes (which have to update driver version) from the core
  changes and trivial cleanups (which don't do this)

* bugreports with partial dmesg info (hmm, doesn't matter for IDE
  currently since we don't print this info - patches are welcomed)

* maybe some other that I forgot :)

I updated siimage driver version in separate commit
(no need to do it for cs5535 since it lacks driver version).

Thanks,
Bart
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ide: Fix cs5535 driver accessing beyond array boundary

[Bartlomiej Zolnierkiewicz]

On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> The cs5535 use an incorrect construct to access the other drive
> of a pair, causing it to access beyond an array boundary on non-0
> interfaces. This fixes it by using the new ide_get_paired_drive()
> hepler instead.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

applied with patch description fixes

> ---
> 
>  drivers/ide/pci/cs5535.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-work/drivers/ide/pci/cs5535.c
> ===
> --- linux-work.orig/drivers/ide/pci/cs5535.c  2007-10-18 10:43:39.0 
> +1000
> +++ linux-work/drivers/ide/pci/cs5535.c   2007-10-18 10:44:00.0 
> +1000
> @@ -84,7 +84,7 @@ static void cs5535_set_speed(ide_drive_t
>  
>   /* Set the PIO timings */
>   if ((speed & XFER_MODE) == XFER_PIO) {
> - ide_drive_t *pair = >hwif->drives[drive->dn ^ 1];
> + ide_drive_t *pair = ide_get_paired_drive(drive);
>   u8 cmd, pioa;
>  
>   cmd = pioa = speed - XFER_PIO_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/

Re: [PATCH 2/3] ide: Fix siimage driver accessing beyond array boundary

[Bartlomiej Zolnierkiewicz]

On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> The siimage use an incorrect construct to access the other drive
> of a pair, causing it to access beyond an array boundary on non-0
> interfaces. This fixes it by using the new ide_get_paired_drive()
> hepler instead.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

applied with patch description fixes

> ---
> 
>  drivers/ide/pci/siimage.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> Index: linux-work/drivers/ide/pci/siimage.c
> ===
> --- linux-work.orig/drivers/ide/pci/siimage.c 2007-10-18 10:42:56.0 
> +1000
> +++ linux-work/drivers/ide/pci/siimage.c  2007-10-18 10:43:09.0 
> +1000
> @@ -180,7 +180,7 @@ static void sil_set_pio_mode(ide_drive_t
>   const u16 data_speed[]  = { 0x328a, 0x2283, 0x1104, 0x10c3, 0x10c1 };
>  
>   ide_hwif_t *hwif= HWIF(drive);
> - ide_drive_t *pair   = >drives[drive->dn ^ 1];
> + ide_drive_t *pair   = ide_get_paired_drive(drive);
>   u32 speedt  = 0;
>   u16 speedp  = 0;
>   unsigned long addr  = siimage_seldev(drive, 0x04);
-
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] ide: Add ide_get_paired_drive() helper

[Bartlomiej Zolnierkiewicz]

On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> This adds a helper to get to the "other" drive on a pair connected
> to a given hwif.
> 
> Signed-off-by: Benjamin Herrenschmidt <[EMAIL PROTECTED]>

applied

-stable team: please include this patch series in 2.6.23.2

> ---
> 
> Note: You may want to use the 1 - select.b.unit construct instead,
> as you prefer, I just used what was there and fixed it.
> 
>  include/linux/ide.h |7 +++
>  1 file changed, 7 insertions(+)
> 
> Index: linux-work/include/linux/ide.h
> ===
> --- linux-work.orig/include/linux/ide.h   2007-10-18 10:41:42.0 
> +1000
> +++ linux-work/include/linux/ide.h2007-10-18 10:42:40.0 +1000
> @@ -1454,4 +1454,11 @@ static inline int hwif_to_node(ide_hwif_
>   return dev ? pcibus_to_node(dev->bus) : -1;
>  }
>  
> +static inline ide_drive_t *ide_get_paired_drive(ide_drive_t *drive)
> +{
> + ide_hwif_t *hwif= HWIF(drive);
> +
> + return >drives[(drive->dn ^ 1) & 1];
> +}
> +
>  #endif /* _IDE_H */
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/3] ide: Fix use of paired device

[Bartlomiej Zolnierkiewicz]

On Thursday 18 October 2007, Benjamin Herrenschmidt wrote:
> At least 2 drivers (siimage and cs5535) have a bug where they use
> the construct:
> 
>   ide_drive_t *pair   = >drives[drive->dn ^ 1];
> 
> To access the other drive in a master/slave pair. This is bogus
> because drive->dn is not the unit number, but the global drive
> number, thus can be 2 & 3 for ide1, 4 & 5 for ide2 etc...
> 
> This causes the driver to access beyond the drive array into lalaland
> for any other interface than ide0 and in some case, actually crash :-)
> 
> These 3 patches fix those by introducing a ide_get_paired_drive()
> helper that does the right thing and then using it.
> 
> Please apply to 2.6.24 if no objection.

Thanks for debugging and fixing this!

All three patches applied.

Bart
-
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: RocketPort Linux driver errors on module reload

[Ferenc Wagner]

Jiri Slaby <[EMAIL PROTECTED]> writes:

> I meant the creating of a git repository with only the module would be the
> easiest possible and most comfortable way for you :). Otherwise I can post 
> you a
> patch serie.

We can go either way, as you prefer.
 
> On 10/18/2007 11:53 PM, Ferenc Wagner wrote:
> 
>> I expected an improper way to have some disadvantages at least. :)
>
> Yes, if you have pci hotpluggable motherboard :). Pci probing (the new method)
> allows you adding/probing pci devices on the fly, not only when the module is
> loading.

Thanks for the explanation.  Maybe one day the E15k-s in the basement
will make pretty good serial port concentrators.

> I did such switches in drivers several times yet, but I can't assure you, 
> that I
> won't make any mistake, but this driver seems not to need too many changes.
> Maybe functionality regressions would occur rather than instability of system.

All right.

> Anyway I would rather wait for the changes from comtrol to not break their
> upcoming patches (if they post them in some short term) and then do these 
> changes.

Ah, I didn't know you were in contact with them.  Till now I only got
a notice that my request had been forwarded to another continent with
the Linux developer. :)  Sure, let's wait for the answer.
-- 
Regards,
Feri.
-
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] Add BSS to resource tree

[Andi Kleen]

On Thu, Oct 18, 2007 at 03:37:51PM -0700, Andrew Morton wrote:
> On Fri, 19 Oct 2007 00:18:13 +0200
> Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> 
> > And I recall that extern char sym[] is considered correct by binutils 
> > people - but I'm not 100% sure and google did not give me an appropriate 
> > hit.
> 
> An ancient memory tells me that these things are traditionally
> declared as plain old int:
> 
> extern int start;
> extern int edata;

int is probably one of the less useful types. Typical operation is computing
the difference between two symbols in bytes.  without cast would give
you a useless scaled size.

-Andi

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

kswapd0 inefficient?

[Richard Jelinek]

Hello guys,

I'm not subscribed to this list, so if you find this question valid
enough to answer it, please cc me. Thanks.

This is what the top-output looks like on my machine after having
copied about 550GB of data from a twofish256 crypted disk to a raid
array:
--
Mem:   8178452k total,  8132180k used,46272k free,  2743480k buffers
Swap:0k total,0k used,0k free,  4563032k cached

  PID USER  PR  NI  VIRT  RES  SHR S %CPU %MEMTIME+  COMMAND
 5954 root   0 -20 000 R   62  0.0  96:42.61 loop0
 6014 root  18   0 23744  19m  484 R   20  0.2  25:45.31 cp
  255 root  10  -5 000 S8  0.0  10:21.82 kswapd0
 6011 root  10  -5 000 D6  0.0   4:15.66 kjournald
...yadda yadda...
--

And what do we see here? We see loop0 and cp eating up some
time. That's ok for me considered the work they do. kjournald is also
ok for me, but I ask myself: why the heck has kswapd0 crunched 10+
minutes of CPU time?

I mean what does kswapd0 do?
http://www.linuxforums.org/forum/linux-kernel/65380-what-does-kswapd0-do.html

And I have no swap - right? So it should just shut up - IMHO. Or am I
missing something?


kind regards,
 Marcel
-
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] Map volume and brightness events on thinkpads

[Henrique de Moraes Holschuh]

On Thu, 18 Oct 2007, Dmitry Torokhov wrote:
> On 10/17/07, Henrique de Moraes Holschuh <[EMAIL PROTECTED]> wrote:
> > Still, I was
> > thinking about it, and a doubt came to mind: would it cause problems for a
> > bitmap to share the function for EV_foo and EV_foo notifications?
> 
> Not sure if I follow... Are you talking about bringing KEY_*_NOTIFY
> into EV_KEY "namespace"? Could you elaborate?

Suppose we define a "EV_* is a notify event" bit to set in the event type
field of an input event.

Now, any type of event can be a notify event or a normal event, depending on
wether this bit is set.

However, the input layer keeps track of which events of a given type can be
sent by an input device using bitmaps, for every type of event.  And this
bitmap now would mean "input device may issue a normal event or a notify
event", not just "input device may issue a normal event".

I am not sure if that would cause trouble?

-- 
  "One disk to rule them all, One disk to find them. One disk to bring
  them all and in the darkness grind them. In the Land of Redmond
  where the shadows lie." -- The Silicon Valley Tarot
  Henrique Holschuh
-
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] Add BSS to resource tree

[Andrew Morton]

On Fri, 19 Oct 2007 00:18:13 +0200
Sam Ravnborg <[EMAIL PROTECTED]> wrote:

> And I recall that extern char sym[] is considered correct by binutils 
> people - but I'm not 100% sure and google did not give me an appropriate hit.

An ancient memory tells me that these things are traditionally
declared as plain old int:

extern int start;
extern int edata;

etc.

However
http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650=man=/usr/share/catman/p_man/cat3/standard/_rt_symbol_table_size.z
disagrees with me.

http://www.psych.upenn.edu/~saul/parasite/man/man3/end.3.html agrees with me

http://docsrv.sco.com:507/en/man/html.S/end.S.html agrees with me

http://www.rocketaware.com/man/man3/end.3.htm agrees with me

http://bama.ua.edu/cgi-bin/man-cgi?etext+3C agrees with me


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] bug.h: Introduce HAVE_ARCH_WARN

[Olof Johansson]

On Thu, Oct 18, 2007 at 03:17:52PM -0700, Andrew Morton wrote:
> On Thu, 11 Oct 2007 12:12:11 -0500
> Olof Johansson <[EMAIL PROTECTED]> wrote:
> 
> > HAVE_ARCH_WARN is used to determine if an arch already has a __WARN()
> > macro, or if a generic one is needed.
> > 
> > With this, some of the arch-specific WARN_ON() implementations can be
> > made common instead (see follow-up patch for powerpc).
> > 
> 
> Those HAVE_ARCH_foo things are unpleasant.
[...]
> Can't we just do #ifndef __WARN?

Yep, good idea. I'll respin.


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