[PATCH 2/5][GFS2] Use macro instead of explicit check for mandatory locks

[Pavel Emelyanov]

The __MANDATORY_LOCK(inode) macro makes the same check, but
makes the code more readable.

Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>
Cc: Steven Whitehouse <[EMAIL PROTECTED]>

---

 fs/gfs2/ops_file.c |4 ++--
 1 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/fs/gfs2/ops_file.c b/fs/gfs2/ops_file.c
index 94d76ac..7e814f4 100644
--- a/fs/gfs2/ops_file.c
+++ b/fs/gfs2/ops_file.c
@@ -535,7 +535,7 @@ static int gfs2_lock(struct file *file, 
 
if (!(fl->fl_flags & FL_POSIX))
return -ENOLCK;
-   if ((ip->i_inode.i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+   if (__MANDATORY_LOCK(ip->i_inode))
return -ENOLCK;
 
if (sdp->sd_args.ar_localflocks) {
@@ -637,7 +637,7 @@ static int gfs2_flock(struct file *file,
 
if (!(fl->fl_flags & FL_FLOCK))
return -ENOLCK;
-   if ((ip->i_inode.i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+   if (__MANDATORY_LOCK(ip->i_inode))
return -ENOLCK;
 
if (sdp->sd_args.ar_localflocks)

-
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/5] Extended crashkernel command line

[Vivek Goyal]

On Tue, Sep 11, 2007 at 12:01:10PM +0200, Bernhard Walle wrote:
> * Vivek Goyal <[EMAIL PROTECTED]> [2007-09-11 08:15]:
> > 
> > "offset" seems to be optional in the new syntax. What happens if user does
> > not specify offset. I think crash_base will be set to zero and system will
> > try to reserve x amount of memory start at zero? That would fail?
> 
> That's handled in the architecture specific code -- because it's
> different on each architecture and the architecture specific code does
> memory reservation. IA64 already can handle this case (on IA64,
> specifying 0 is the same than leaving out the base address, and that's
> why I wanted to keep that semantics). I think it doesn't also make
> sense on i386/x86_64 to choose 0 as real base address, because the
> value below 1 MB is special for booting ...
> 

Ok. I see IA64 is handling this case. But in current patchset, i386 and
x86_64 will try to reserve memory starting at zero?  So we still got
to handle this case in i386 and x86_64?

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

[PATCH 1/5] Use existing macros for distinguishing mandatory locks

[Pavel Emelyanov]

The combination of S_ISGID bit set and S_IXGRP bit unset is 
used to mark the inode as "mandatory lockable" and there's a 
macro for this check called MANDATORY_LOCK(inode). However, 
fs/locks.c and some filesystems still perform the explicit 
i_mode checking. 

Switch the fs/locks.c to macro making the code shorter and 
more readable.

The __MANDATORY_LOCK() macro is to be used in places where
the IS_MANDLOCK() for superblock is already known to be true.

Signed-off-by: Pavel Emelyanov <[EMAIL PROTECTED]>

---

 fs/locks.c |   14 --
 include/linux/fs.h |4 ++--
 2 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/include/linux/fs.h b/include/linux/fs.h
index 291d40b..035ffda 100644
--- a/include/linux/fs.h
+++ b/include/linux/fs.h
@@ -1488,8 +1488,8 @@ extern int locks_mandatory_area(int, str
  * Candidates for mandatory locking have the setgid bit set
  * but no group execute bit -  an otherwise meaningless combination.
  */
-#define MANDATORY_LOCK(inode) \
-   (IS_MANDLOCK(inode) && ((inode)->i_mode & (S_ISGID | S_IXGRP)) == 
S_ISGID)
+#define __MANDATORY_LOCK(ino) (((ino)->i_mode & (S_ISGID | S_IXGRP)) == 
S_ISGID)
+#define MANDATORY_LOCK(inode) (IS_MANDLOCK(inode) && __MANDATORY_LOCK(inode))
 
 static inline int locks_verify_locked(struct inode *inode)
 {
diff --git a/fs/locks.c b/fs/locks.c
index 0db1a14..f90fe6d 100644
--- a/fs/locks.c
+++ b/fs/locks.c
@@ -1112,7 +1112,7 @@ int locks_mandatory_area(int read_write,
 * If we've been sleeping someone might have
 * changed the permissions behind our back.
 */
-   if ((inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID)
+   if (__MANDATORY_LOCK(inode))
continue;
}
 
@@ -1751,9 +1751,7 @@ int fcntl_setlk(unsigned int fd, struct 
/* Don't allow mandatory locks on files that may be memory mapped
 * and shared.
 */
-   if (IS_MANDLOCK(inode) &&
-   (inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
-   mapping_writably_mapped(filp->f_mapping)) {
+   if (MANDATORY_LOCK(inode) && mapping_writably_mapped(filp->f_mapping)) {
error = -EAGAIN;
goto out;
}
@@ -1877,9 +1875,7 @@ int fcntl_setlk64(unsigned int fd, struc
/* Don't allow mandatory locks on files that may be memory mapped
 * and shared.
 */
-   if (IS_MANDLOCK(inode) &&
-   (inode->i_mode & (S_ISGID | S_IXGRP)) == S_ISGID &&
-   mapping_writably_mapped(filp->f_mapping)) {
+   if (MANDATORY_LOCK(inode) && mapping_writably_mapped(filp->f_mapping)) {
error = -EAGAIN;
goto out;
}
@@ -2073,9 +2069,7 @@ static void lock_get_status(char* out, s
out += sprintf(out, "%6s %s ",
 (fl->fl_flags & FL_ACCESS) ? "ACCESS" : "POSIX ",
 (inode == NULL) ? "*NOINODE*" :
-(IS_MANDLOCK(inode) &&
- (inode->i_mode & (S_IXGRP | S_ISGID)) == S_ISGID) 
?
-"MANDATORY" : "ADVISORY ");
+MANDATORY_LOCK(inode) ? "MANDATORY" : "ADVISORY ");
} else if (IS_FLOCK(fl)) {
if (fl->fl_type & LOCK_MAND) {
out += sprintf(out, "FLOCK  MSNFS ");

-
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] free_irq(): Actually handle DEBUG_SHIRQ

[Maciej W. Rozycki]

 Code used for DEBUG_SHIRQ in free_irq() is unreachable -- the for() loop 
within never terminates otherwise than by return.  This is an obvious fix.

Signed-off-by: Maciej W. Rozycki <[EMAIL PROTECTED]>
---
 Please apply.

 While at it, I have a question about the complementary code within 
request_irq(): when the option in question is enabled, a spurious IRQ is 
posted before internal setup is done by setup_irq().  This includes the 
->depth counter.  Now if the interrupt handler of some driver calls
disable_irq_nosync(), then code in setup_irq() will mess up the state of 
->depth afterwards if this is the first handler being installed (i.e. 
within the "if (!shared)" block).  This is reported later on when 
enable_irq() called by the driver, by means of a message like this:

Unbalanced enable for IRQ 34
WARNING: at kernel/irq/manage.c:158 enable_irq()

Now given DEBUG_SHIRQ is a debug facility, not to be normally used for 
production, is the phenomenon as described considered a design limitation 
we can live with, or is it a bug that qualifies for a fix?

 I can reproduce this problem easily with phylib.

  Maciej

patch-mips-2.6.23-rc5-20070904-debug-shirq-0
diff -up --recursive --new-file 
linux-mips-2.6.23-rc5-20070904.macro/kernel/irq/manage.c 
linux-mips-2.6.23-rc5-20070904/kernel/irq/manage.c
--- linux-mips-2.6.23-rc5-20070904.macro/kernel/irq/manage.c2007-09-04 
04:56:21.0 +
+++ linux-mips-2.6.23-rc5-20070904/kernel/irq/manage.c  2007-09-11 
23:58:59.0 +
@@ -448,7 +448,7 @@ void free_irq(unsigned int irq, void *de
if (action->flags & IRQF_SHARED)
handler = action->handler;
kfree(action);
-   return;
+   break;
}
printk(KERN_ERR "Trying to free already-free IRQ %d\n", irq);
spin_unlock_irqrestore(>lock, flags);
-
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] powerpc: add new required termio functions

[Michael Neuling]

In message <[EMAIL PROTECTED]> you wrote:
> On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:
> 
> > On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > > The "tty: termios locking functions break with new termios type" patch
> > > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > > [...]
> > > I'm guessing other architectures are broken too?
> > 
> > FWIW, the above quoted patch breaks s390 as well.
> 
> Does this fix it?

FYI it does fix powerpc, but I suspect you were asking about s390 here.

Mikey

> 
> diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions 
drivers/char/tty_ioctl.c
> --- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
> +++ a/drivers/char/tty_ioctl.c
> @@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
>   if (L_ICANON(tty))
>   retval = inq_canon(tty);
>   return put_user(retval, (unsigned int __user *) arg);
> +#ifndef TCGETS2
> + case TIOCGLCKTRMIOS:
> + if (kernel_termios_to_user_termios((struct termios __us
er *)arg, real_tty->termios_locked))
> + return -EFAULT;
> + return 0;
> +
> + case TIOCSLCKTRMIOS:
> + if (!capable(CAP_SYS_ADMIN))
> + return -EPERM;
> + if (user_termios_to_kernel_termios(real_tty->termios_lo
cked, (struct termios __user *) arg))
> + return -EFAULT;
> + return 0;
> +#else
>   case TIOCGLCKTRMIOS:
>   if (kernel_termios_to_user_termios_1((struct termios __
user *)arg, real_tty->termios_locked))
>   return -EFAULT;
> @@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
>   if (user_termios_to_kernel_termios_1(real_tty->termios_
locked, (struct termios __user *) arg))
>   return -EFAULT;
>   return 0;
> +#endif
>  
>   case TIOCPKT:
>   {
> _
> 
-
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: SYSFS: need a noncaching read

[Heiko Schocher]

Hello Greg

Am Mittwoch, den 12.09.2007, 03:01 -0700 schrieb Greg KH:
> On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> > On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > > I have developed a device driver and use the sysFS to export some
> > > registers to userspace.
> > 
> > Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> > not to play around with registers from userspace.
> > 
> > > I opened the sysFS File for one register and did some reads from this
> > > File, but I alwas becoming the same value from the register, whats not
> > > OK, because they are changing. So I found out that the sysFS caches
> > > the reads ... :-(
> > 
> > Yes, it does. What you can do is close()ing the file handle between
> > accesses, which makes it work but is slow.
> 
> Do an lseek back to 0 and then re-read, you will get called in your
> driver again.

No thats not true. I thought this too, but if I make a:

seek (fd, 0L, SEEK_SET);

in Userspace, there is no retrigger in the sysFS, my driver is *not*
called again. So I made a own sysfs_seek function, which does retrigger
the driver ...

Is this really wanted in the sysFS, that there is no way to retrigger a
read?

thanks
Heiko
-- 
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany

-
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] pci: fix unterminated pci_device_id lists

[Jeff Garzik]

Kees Cook wrote:

This patch against 2.6.23-rc6 fixes a couple drivers that do not
correctly terminate their pci_device_id lists.  This results in garbage
being spewed into modules.pcimap when the module happens to not have
28 NULL bytes following the table, and/or the last PCI ID is actually
truncated from the table when calculating the modules.alias PCI aliases,
cause those unfortunate device IDs to not auto-load.

Signed-off-by: Kees Cook <[EMAIL PROTECTED]>


ACK


-
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 07/15] Don't return -ENOSYS as extra notes size if spufs is not loaded

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because the SPU coredump code might be built as part of a module (spufs),
> we have a stub which is called by the coredump code, this routine then calls
> into spufs if it's loaded.
> 
> Unfortunately the stub returns -ENOSYS if spufs is not loaded, which is
> interpreted by the coredump code as an extra note size of -38 bytes. This
> leads to a corrupt core dump.
> 
> If spufs is not loaded there will be no SPU ELF notes to write, and so the
> extra notes size will be == 0.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Acked-by: Arnd Bergmann <[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/

[Resend][PATCH -mm] Hibernation: Enter platform hibernation state in a consistent way (rev. 4)

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

Make hibernation_platform_enter() execute the enter-a-sleep-state sequence
instead of the mixed shutdown-with-entering-S4 thing.

Replace the shutting down of devices done by kernel_shutdown_prepare(), before
entering the ACPI S4 sleep state, with suspending them and the shutting down of
sysdevs with calling device_power_down(PMSG_SUSPEND) (just like before entering
S1 or S3, but the target state is now S4).  Also, disable the nonboot CPUs
before entering the sleep state (S4), which generally always is a good idea.

This is known to fix the "double disk spin down during hibernation" on some
machines, eg. HPC nx6325 (ref. http://lkml.org/lkml/2007/8/7/316 and the
following thread).  Moreover, it has been reported to make
/sys/class/rtc/rtc0/wakealarm work correctly with hibernation for some users.
It also generally causes the hibernation state (ACPI S4) to be entered faster.

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 kernel/power/disk.c |   61 +---
 1 file changed, 44 insertions(+), 17 deletions(-)

Index: linux-2.6.23-rc6/kernel/power/disk.c
===
--- linux-2.6.23-rc6.orig/kernel/power/disk.c
+++ linux-2.6.23-rc6/kernel/power/disk.c
@@ -222,21 +222,48 @@ int hibernation_platform_enter(void)
 {
int error;
 
-   if (hibernation_ops) {
-   kernel_shutdown_prepare(SYSTEM_SUSPEND_DISK);
-   /*
-* We have cancelled the power transition by running
-* hibernation_ops->finish() before saving the image, so we
-* should let the firmware know that we're going to enter the
-* sleep state after all
-*/
-   error = hibernation_ops->prepare();
-   sysdev_shutdown();
-   if (!error)
-   error = hibernation_ops->enter();
-   } else {
-   error = -ENOSYS;
+   if (!hibernation_ops)
+   return -ENOSYS;
+
+   /*
+* We have cancelled the power transition by running
+* hibernation_ops->finish() before saving the image, so we should let
+* the firmware know that we're going to enter the sleep state after all
+*/
+   error = hibernation_ops->start();
+   if (error)
+   return error;
+
+   suspend_console();
+   error = device_suspend(PMSG_SUSPEND);
+   if (error)
+   return error;
+
+   error = hibernation_ops->prepare();
+   if (error)
+   goto Resume_devices;
+
+   error = disable_nonboot_cpus();
+   if (error)
+   goto Finish;
+
+   local_irq_disable();
+   error = device_power_down(PMSG_SUSPEND);
+   if (!error) {
+   hibernation_ops->enter();
+   /* We should never get here */
+   while (1);
}
+   local_irq_enable();
+
+   /*
+* We don't need to reenable the nonboot CPUs or resume consoles, since
+* the system is going to be halted anyway.
+*/
+ Finish:
+   hibernation_ops->finish();
+ Resume_devices:
+   device_resume();
return error;
 }
 
@@ -253,14 +280,14 @@ static void power_down(void)
case HIBERNATION_TEST:
case HIBERNATION_TESTPROC:
break;
-   case HIBERNATION_SHUTDOWN:
-   kernel_power_off();
-   break;
case HIBERNATION_REBOOT:
kernel_restart(NULL);
break;
case HIBERNATION_PLATFORM:
hibernation_platform_enter();
+   case HIBERNATION_SHUTDOWN:
+   kernel_power_off();
+   break;
}
kernel_halt();
/*
-
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] powerpc: add new required termio functions

[Andrew Morton]

On Wed, 12 Sep 2007 12:20:32 +0200 Heiko Carstens <[EMAIL PROTECTED]> wrote:

> On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> > The "tty: termios locking functions break with new termios type" patch
> > (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> > [...]
> > I'm guessing other architectures are broken too?
> 
> FWIW, the above quoted patch breaks s390 as well.

Does this fix it?

diff -puN drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions 
drivers/char/tty_ioctl.c
--- a/drivers/char/tty_ioctl.c~powerpc-add-new-required-termio-functions
+++ a/drivers/char/tty_ioctl.c
@@ -795,6 +795,19 @@ int n_tty_ioctl(struct tty_struct * tty,
if (L_ICANON(tty))
retval = inq_canon(tty);
return put_user(retval, (unsigned int __user *) arg);
+#ifndef TCGETS2
+   case TIOCGLCKTRMIOS:
+   if (kernel_termios_to_user_termios((struct termios 
__user *)arg, real_tty->termios_locked))
+   return -EFAULT;
+   return 0;
+
+   case TIOCSLCKTRMIOS:
+   if (!capable(CAP_SYS_ADMIN))
+   return -EPERM;
+   if 
(user_termios_to_kernel_termios(real_tty->termios_locked, (struct termios 
__user *) arg))
+   return -EFAULT;
+   return 0;
+#else
case TIOCGLCKTRMIOS:
if (kernel_termios_to_user_termios_1((struct termios 
__user *)arg, real_tty->termios_locked))
return -EFAULT;
@@ -806,6 +819,7 @@ int n_tty_ioctl(struct tty_struct * tty,
if 
(user_termios_to_kernel_termios_1(real_tty->termios_locked, (struct termios 
__user *) arg))
return -EFAULT;
return 0;
+#endif
 
case TIOCPKT:
{
_

-
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 -mm] ssb: Make pcmciahost depend on PCMCIA=y

[Michael Buesch]

On Wednesday 12 September 2007 12:17:45 Paul Mundt wrote:
> On Wed, Sep 12, 2007 at 12:09:09PM +0200, Michael Buesch wrote:
> > On Wednesday 12 September 2007 04:11:00 Paul Mundt wrote:
> > > SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
> > > build in PCMCIA support or not, as the PCMCIA host code itself is
> > > also only a bool, make SSB_PCMCIAHOST_POSSIBLE depend on PCMCIA=y.
> > > 
> > > Without this, SSB_PCMCIAHOST_POSSIBLE evaluates to y when PCMCIA
> > > is built as a module, which results in link errors due to the
> > > pcmcia_access_configuration_register() accesses, where the symbol
> > > is only defined in a module.
> > > 
> > > --- linux-2.6.23-rc4-mm1.orig/drivers/ssb/Kconfig 2007-09-11 
> > > 15:15:52.0 +0900
> > > +++ linux-2.6.23-rc4-mm1/drivers/ssb/Kconfig  2007-09-12 
> > > 10:51:53.0 +0900
> > > @@ -37,7 +37,7 @@
> > >  
> > >  config SSB_PCMCIAHOST_POSSIBLE
> > >   bool
> > > - depends on SSB && PCMCIA && EXPERIMENTAL
> > > + depends on SSB && PCMCIA=y && EXPERIMENTAL
> > >   default y
> > >  
> > >  config SSB_PCMCIAHOST
> > > 
> > > 
> > 
> > There we go. The usual SELECT dependency hell again...
> > Would changing SSB_PCMCIAHOST_POSSIBLE to tristate also fix it?
> > What would be the sideeffects?
> > 
> I tried that first, if you do that you have to change the default to
> SSB && PCMCIA, and then anything that depends on it also has to be a
> tristate. That worked ok for SSB_PCMCIAHOST, but it didn't work ok for
> the b43 wireless + PCMCIA, which is why I opted for the PCMCIA=y thing
> instead, which makes sure that SSB_PCMCIAHOST can't be enabled if PCMCIA
> is modular.

Ok, so much for "SELECT is easy and it works if used correctly..." :)
Well, let's apply that patch then. It needlessly restricts the
choice to not allow modular pcmcia in that case, though.

-- 
Greetings Michael.
-
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] Move the definition of pr_err() into kernel.h

[Stephen Hemminger]

On Tue, 11 Sep 2007 09:56:05 -0500
Emil Medve <[EMAIL PROTECTED]> wrote:

> Other pr_*() macros are already defined in kernel.h, but pr_err() was defined
> multiple times in several other places
> 
> Signed-off-by: Emil Medve <[EMAIL PROTECTED]>

pr_error seems better than pr_err

Please add the full set:
pr_alert
pr_critical
pr_error
pr_warn
pr_notice


-
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] RTC calibration

[Dag-Erling Smørgrav]

Arne Georg Gleditsch <[EMAIL PROTECTED]> writes:
> Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> > +   case RTC_SPEED_UP:
> > +   err = rtc_speed_up(rtc);
> > +   break;
> > +
> > +   case RTC_SLOW_DOWN:
> > +   err = rtc_speed_up(rtc);
> > +   break;
> This doesn't look quite right.  rtc_slow_down, surely?

Uh, yes.  ENOCOFFEE.

DES
-- 
Dag-Erling Smørgrav
Senior Software Developer
Linpro AS - www.linpro.no
-
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/

[Resend][PATCH -mm] Hibernation: Check if ACPI is enabled during restore in the right place

[Rafael J. Wysocki]

From: Rafael J. Wysocki <[EMAIL PROTECTED]>

The following scenario leads to total confusion of the platform firmware on
some boxes (eg. HPC nx6325):
* Hibernate with ACPI enabled
* Resume passing "acpi=off" to the boot kernel

To prevent this from happening it's necessary to check if ACPI is enabled (and
enable it if that's not the case) _right_ _after_ control has been transfered
from the boot kernel to the image kernel, before device_power_up() is called
(ie. with interrupts disabled).  Enabling ACPI after calling device_power_up()
turns out to be insufficient.

For this reason, introduce new hibernation callback ->leave() that will be
executed before device_power_up() by the restored image kernel.  To make it
work, it also is necessary to move swsusp_suspend() from swsusp.c to disk.c
(it's name is changed to "create_image", which is more up to the point).

Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
 drivers/acpi/sleep/main.c |7 -
 include/linux/suspend.h   |7 +
 kernel/power/disk.c   |   58 +-
 kernel/power/power.h  |1 
 kernel/power/swsusp.c |   33 --
 5 files changed, 70 insertions(+), 36 deletions(-)

Index: linux-2.6.23-rc6/drivers/acpi/sleep/main.c
===
--- linux-2.6.23-rc6.orig/drivers/acpi/sleep/main.c
+++ linux-2.6.23-rc6/drivers/acpi/sleep/main.c
@@ -238,13 +238,17 @@ static int acpi_hibernation_enter(void)
return ACPI_SUCCESS(status) ? 0 : -EFAULT;
 }
 
-static void acpi_hibernation_finish(void)
+static void acpi_hibernation_leave(void)
 {
/*
 * If ACPI is not enabled by the BIOS and the boot kernel, we need to
 * enable it here.
 */
acpi_enable();
+}
+
+static void acpi_hibernation_finish(void)
+{
acpi_leave_sleep_state(ACPI_STATE_S4);
acpi_disable_wakeup_device(ACPI_STATE_S4);
 
@@ -274,6 +278,7 @@ static struct platform_hibernation_ops a
.finish = acpi_hibernation_finish,
.prepare = acpi_hibernation_prepare,
.enter = acpi_hibernation_enter,
+   .leave = acpi_hibernation_leave,
.pre_restore = acpi_hibernation_pre_restore,
.restore_cleanup = acpi_hibernation_restore_cleanup,
 };
Index: linux-2.6.23-rc6/include/linux/suspend.h
===
--- linux-2.6.23-rc6.orig/include/linux/suspend.h
+++ linux-2.6.23-rc6/include/linux/suspend.h
@@ -156,6 +156,12 @@ extern void mark_free_pages(struct zone 
  * Called after the nonboot CPUs have been disabled and all of the low
  * level devices have been shut down (runs with IRQs off).
  *
+ * @leave: Perform the first stage of the cleanup after the system sleep state
+ * indicated by @set_target() has been left.
+ * Called right after the control has been passed from the boot kernel to
+ * the image kernel, before the nonboot CPUs are enabled and before devices
+ * are resumed.  Executed with interrupts disabled.
+ *
  * @pre_restore: Prepare system for the restoration from a hibernation image.
  * Called right after devices have been frozen and before the nonboot
  * CPUs are disabled (runs with IRQs on).
@@ -170,6 +176,7 @@ struct platform_hibernation_ops {
void (*finish)(void);
int (*prepare)(void);
int (*enter)(void);
+   void (*leave)(void);
int (*pre_restore)(void);
void (*restore_cleanup)(void);
 };
Index: linux-2.6.23-rc6/kernel/power/disk.c
===
--- linux-2.6.23-rc6.orig/kernel/power/disk.c
+++ linux-2.6.23-rc6/kernel/power/disk.c
@@ -93,6 +93,17 @@ static int platform_pre_snapshot(int pla
 }
 
 /**
+ * platform_leave - prepare the machine for switching to the normal mode
+ * of operation using the platform driver (called with interrupts disabled)
+ */
+
+static void platform_leave(int platform_mode)
+{
+   if (platform_mode && hibernation_ops)
+   hibernation_ops->leave();
+}
+
+/**
  * platform_finish - switch the machine to the normal mode of operation
  * using the platform driver (must be called after platform_prepare())
  */
@@ -129,6 +140,51 @@ static void platform_restore_cleanup(int
 }
 
 /**
+ * create_image - freeze devices that need to be frozen with interrupts
+ * off, create the hibernation image and thaw those devices.  Control
+ * reappears in this routine after a restore.
+ */
+
+int create_image(int platform_mode)
+{
+   int error;
+
+   error = arch_prepare_suspend();
+   if (error)
+   return error;
+
+   local_irq_disable();
+   /* At this point, device_suspend() has been called, but *not*
+* device_power_down(). We *must* call device_power_down() now.
+* Otherwise, drivers for some devices (e.g. interrupt controllers)
+  

Re: [RFC 0/3] Recursive reclaim (on __PF_MEMALLOC)

[Peter Zijlstra]

On Wed, 2007-09-05 at 05:14 -0700, Christoph Lameter wrote:

> Using the VM to throttle networking is a pretty bad thing because it 
> assumes single critical user of memory. There are other consumers of 
> memory and if you have a load that depends on other things than networking 
> then you should not kill the other things that want memory.

The VM is a _critical_ user of memory. And I dare say it is the _most_
important user. 

Every user of memory relies on the VM, and we only get into trouble if
the VM in turn relies on one of these users. Traditionally that has only
been the block layer, and we special cased that using mempools and
PF_MEMALLOC.

Why do you object to me doing a similar thing for networking?

The problem of circular dependancies on and with the VM is rather
limited to kernel IO subsystems, and we only have a limited amount of
them. 

You talk about something generic, do you mean an approach that is
generic across all these subsystems?

If so, my approach would be it, I can replace mempools as we have them
with the reserve system I introduce.


signature.asc
Description: This is a digitally signed message part

Re: [RFC+PATCH] RTC calibration

[Arne Georg Gleditsch]

Dag-Erling Smørgrav <[EMAIL PROTECTED]> writes:
> + case RTC_SPEED_UP:
> + err = rtc_speed_up(rtc);
> + break;
> +
> + case RTC_SLOW_DOWN:
> + err = rtc_speed_up(rtc);
> + break;

This doesn't look quite right.  rtc_slow_down, surely?

-- 
Arne.
-
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] Union Mount: Readdir approaches

[Al Boldi]

[EMAIL PROTECTED] wrote:
> But if you really want to read or try it, you can get all source files
> from sourceforge. Read http://aufs.sf.net and try,
> $ cvs -d:pserver:[EMAIL PROTECTED]:/cvsroot/aufs login
> (CVS password is empty)
> $ cvs -z3 -d:pserver:[EMAIL PROTECTED]:/cvsroot/aufs co
> aufs

This is way too complicated, but I tried it anyway, only to find it doesn't 
compile:

  CHK include/linux/version.h
  CHK include/linux/utsrelease.h
  CALLscripts/checksyscalls.sh
  CHK include/linux/compile.h
  CC  fs/aufs/dentry.o
fs/aufs/dentry.c:630:1: directives may not be used inside a macro argument
fs/aufs/dentry.c:629:65: unterminated argument list invoking macro "unlikely"
fs/aufs/dentry.c: In function `h_d_revalidate':
fs/aufs/dentry.c:631: `unlikely' undeclared (first use in this function)
fs/aufs/dentry.c:631: (Each undeclared identifier is reported only once
fs/aufs/dentry.c:631: for each function it appears in.)
fs/aufs/dentry.c:635: parse error before ')' token
fs/aufs/dentry.c:571: warning: unused variable `h_plus'
fs/aufs/dentry.c:571: warning: unused variable `is_nfs'
fs/aufs/dentry.c:572: warning: unused variable `p'
fs/aufs/dentry.c:575: warning: unused variable `h_inode'
fs/aufs/dentry.c:575: warning: unused variable `h_cached_inode'
fs/aufs/dentry.c:576: warning: unused variable `h_mode'
fs/aufs/dentry.c:578: warning: unused variable `reval'
fs/aufs/dentry.c:639: label `err' used but not defined
fs/aufs/dentry.c: At top level:
fs/aufs/dentry.c:642: warning: type defaults to `int' in declaration of 
`reval'
fs/aufs/dentry.c:642: warning: initialization makes integer from pointer 
without a cast
fs/aufs/dentry.c:642: warning: data definition has no type or storage class
fs/aufs/dentry.c:643: parse error before "if"
fs/aufs/dentry.c:649: warning: type defaults to `int' in declaration of `err'
fs/aufs/dentry.c:649: `h_dentry' undeclared here (not in a function)
fs/aufs/dentry.c:649: `p' undeclared here (not in a function)
fs/aufs/dentry.c:649: called object is not a function
fs/aufs/dentry.c:649: warning: data definition has no type or storage class
fs/aufs/dentry.c:650: parse error before "if"
fs/aufs/dentry.c:653: warning: type defaults to `int' in declaration of 
`fake_dm_release'
fs/aufs/dentry.c:653: warning: parameter names (without types) in function 
declaration
fs/aufs/dentry.c:653: conflicting types for `fake_dm_release'

...and more...


It would make matters much easier if you could just publish a link to a 
combo-patch against at least the latest stable kernel, like 2.6.22.


Thanks!

--
Al

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

Re: Request for Linux Kernel Mailing List archives

[Andreas Herrmann]

On Wed, Jun 20, 2007 at 12:38:48PM -0400, Hank Leininger wrote:
> On Wed, 20 Jun 2007, H. Peter Anvin wrote:
> >Bj�rn Steinbrink wrote:
> >>
> >>marc.info supports that.
> >>http://marc.info/[EMAIL PROTECTED]
> >Excellent!  Didn't see that documented anywhere.
> 
> You're right, it's not really.  In fact very little is documented.
> You'd have to discover it -- in the message view, the Message-ID is
> actually a self-referential link using the above syntax.
> 
> A few relevant points:
> - - Such links never actually show you the corresponding message.  Instead:
>   - If the message-id is unique, you are sent a 302 redirect to the
> message using the normal MARC message URL (l=foo=123)
>   - If the message-id is not unique (such as crossposting, or deliberate
> attempts to cause collisions) you'll be presented with a list of
> messages, showing date, subject, author, and listname, to choose from.
> - - MARC doesn't currently touch message bodies for spam-obfuscation
>   purposes, but it does for headers, specifically From: and Message-ID:.
>   When MARC generates message-id-based links, they are obfuscated.
>   But it can read in links formed either way.  So, if you copy/paste the
>   target of a Message-ID: link out of MARC, it will look slightly
>   different than if you just made your own http://marc.info/[EMAIL PROTECTED],
>   but either form will work.
> - - We don't use < > surrounding the message-id, but again, will accept
>   URLs formed either way.
> - - We don't have Message-ID's for messages added before Dec, 2003.

Thanks for that usefull info.

Attached is a script containing a quick hack to enable look up of
a message-id at MARC with mutt(ng).

Posted to LKML just in case some other mutt(ng) user subscribed here
finds it useful.


Regards,

Andreas

-- 
Operating | AMD Saxony Limited Liability Company & Co. KG,
  System  | Wilschdorfer Landstr. 101, 01109 Dresden, Germany
 Research | Register Court Dresden: HRA 4896, General Partner authorized
  Center  | to represent: AMD Saxony LLC (Wilmington, Delaware, US)
  (OSRC)  | General Manager of AMD Saxony LLC: Dr. Hans-R. Deppe, Thomas McCoy


show-mail.sh
Description: Bourne shell script

Re: [PATCH] powerpc: add new required termio functions

[Heiko Carstens]

On Wed, Sep 12, 2007 at 12:04:39PM +1000, Michael Neuling wrote:
> The "tty: termios locking functions break with new termios type" patch
> (f629307c857c030d5a3dd777fee37c8bb395e171) breaks the powerpc compile.
> [...]
> I'm guessing other architectures are broken too?

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

Re: [PATCH -mm] ssb: Make pcmciahost depend on PCMCIA=y

[Paul Mundt]

On Wed, Sep 12, 2007 at 12:09:09PM +0200, Michael Buesch wrote:
> On Wednesday 12 September 2007 04:11:00 Paul Mundt wrote:
> > SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
> > build in PCMCIA support or not, as the PCMCIA host code itself is
> > also only a bool, make SSB_PCMCIAHOST_POSSIBLE depend on PCMCIA=y.
> > 
> > Without this, SSB_PCMCIAHOST_POSSIBLE evaluates to y when PCMCIA
> > is built as a module, which results in link errors due to the
> > pcmcia_access_configuration_register() accesses, where the symbol
> > is only defined in a module.
> > 
> > --- linux-2.6.23-rc4-mm1.orig/drivers/ssb/Kconfig   2007-09-11 
> > 15:15:52.0 +0900
> > +++ linux-2.6.23-rc4-mm1/drivers/ssb/Kconfig2007-09-12 
> > 10:51:53.0 +0900
> > @@ -37,7 +37,7 @@
> >  
> >  config SSB_PCMCIAHOST_POSSIBLE
> > bool
> > -   depends on SSB && PCMCIA && EXPERIMENTAL
> > +   depends on SSB && PCMCIA=y && EXPERIMENTAL
> > default y
> >  
> >  config SSB_PCMCIAHOST
> > 
> > 
> 
> There we go. The usual SELECT dependency hell again...
> Would changing SSB_PCMCIAHOST_POSSIBLE to tristate also fix it?
> What would be the sideeffects?
> 
I tried that first, if you do that you have to change the default to
SSB && PCMCIA, and then anything that depends on it also has to be a
tristate. That worked ok for SSB_PCMCIAHOST, but it didn't work ok for
the b43 wireless + PCMCIA, which is why I opted for the PCMCIA=y thing
instead, which makes sure that SSB_PCMCIAHOST can't be enabled if PCMCIA
is modular.
-
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 -mm] ssb: Make pcmciahost depend on PCMCIA=y

[Michael Buesch]

On Wednesday 12 September 2007 04:11:00 Paul Mundt wrote:
> SSB uses a bool (SSB_PCMCIAHOST_POSSIBLE) to determine whether to
> build in PCMCIA support or not, as the PCMCIA host code itself is
> also only a bool, make SSB_PCMCIAHOST_POSSIBLE depend on PCMCIA=y.
> 
> Without this, SSB_PCMCIAHOST_POSSIBLE evaluates to y when PCMCIA
> is built as a module, which results in link errors due to the
> pcmcia_access_configuration_register() accesses, where the symbol
> is only defined in a module.
> 
> Signed-off-by: Paul Mundt <[EMAIL PROTECTED]>
> 
> --
> 
>  drivers/ssb/Kconfig |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> --- linux-2.6.23-rc4-mm1.orig/drivers/ssb/Kconfig 2007-09-11 
> 15:15:52.0 +0900
> +++ linux-2.6.23-rc4-mm1/drivers/ssb/Kconfig  2007-09-12 10:51:53.0 
> +0900
> @@ -37,7 +37,7 @@
>  
>  config SSB_PCMCIAHOST_POSSIBLE
>   bool
> - depends on SSB && PCMCIA && EXPERIMENTAL
> + depends on SSB && PCMCIA=y && EXPERIMENTAL
>   default y
>  
>  config SSB_PCMCIAHOST
> 
> 

There we go. The usual SELECT dependency hell again...
Would changing SSB_PCMCIAHOST_POSSIBLE to tristate also fix it?
What would be the sideeffects?

I think this PCMCIA=y is not good, because it's perfectly
legal to build PCMCIA as module, while SSB and everything
that depends on SSB is also a module.
Would tristate fix that?

-- 
Greetings Michael.
-
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: [-mm PATCH 1/9] Memory controller resource counters (v6)

[Balbir Singh]

Paul Menage wrote:
> Hi Balbir/Pavel,
> 
> As I mentioned to you directly at the kernel summit, I think it might
> be cleaner to integrate resource counters more closely with control
> groups. So rather than controllers such as the memory controller
> having to create their own boilerplate cf_type structures and
> read/write functions, it should be possible to just call a function
> something like
> 
> control_group_add_rescounter(struct cgroup *cg, struct cgroup_subsys *ss,
>  struct res_counter *res,
> const char *name)
> 
> and have it handle all the userspace API. This would simplify the task
> of keeping a consistent userspace API between different controllers
> using the resource counter abstraction.
> 
> Paul
> 

Yes, I remember discussing it with you. I would expect res_counters
definition to be dynamic (to be able to add the guarantee, soft limit,
etc) for expansion in the future. In the future, I would also like
to do hierarchical resource groups, the hierarchy would represent
the current filesystem hierarchy.

-- 
Warm Regards,
Balbir Singh
Linux Technology Center
IBM, ISTL
-
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: SYSFS: need a noncaching read

[Greg KH]

On Wed, Sep 12, 2007 at 07:32:07AM +0200, Robert Schwebel wrote:
> On Tue, Sep 11, 2007 at 11:43:17AM +0200, Heiko Schocher wrote:
> > I have developed a device driver and use the sysFS to export some
> > registers to userspace.
> 
> Uuuh, uggly. Don't do that. Device drivers are there to abstract things,
> not to play around with registers from userspace.
> 
> > I opened the sysFS File for one register and did some reads from this
> > File, but I alwas becoming the same value from the register, whats not
> > OK, because they are changing. So I found out that the sysFS caches
> > the reads ... :-(
> 
> Yes, it does. What you can do is close()ing the file handle between
> accesses, which makes it work but is slow.

Do an lseek back to 0 and then re-read, you will get called in your
driver again.

Not that this is a good thing to do for this kind of thing, as others
have already said.

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/

[PATCH] RDMA/CMA: Use neigh_event_send() to initiate neighbour discovery.

[Steve Wise]

RDMA/CMA: Use neigh_event_send() to initiate neighbour discovery.

Calling arp_send() to initiate neighbour discovery (ND) doesn't do the
full ND protocol.  Namely, it doesn't handle retransmitting the arp
request if it is dropped. The function neigh_event_send() does all this.
Without doing full ND, rdma address resolution fails in the presence of
dropped arp bcast packets.

Signed-off-by: Steve Wise <[EMAIL PROTECTED]>
---

 drivers/infiniband/core/addr.c |3 +--
 1 files changed, 1 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/core/addr.c b/drivers/infiniband/core/addr.c
index c5c33d3..5381c80 100644
--- a/drivers/infiniband/core/addr.c
+++ b/drivers/infiniband/core/addr.c
@@ -161,8 +161,7 @@ static void addr_send_arp(struct sockadd
if (ip_route_output_key(, ))
return;
 
-   arp_send(ARPOP_REQUEST, ETH_P_ARP, rt->rt_gateway, rt->idev->dev,
-rt->rt_src, NULL, rt->idev->dev->dev_addr, NULL);
+   neigh_event_send(rt->u.dst.neighbour, NULL);
ip_rt_put(rt);
 }
 
-
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/

2.6.23-rc4-mm1: kgdboe link errors

[Jiri Slaby]

Hi,

randconfig [1] causes this link errors:
ERROR: "netpoll_cleanup" [drivers/net/kgdboe.ko] undefined!
ERROR: "netpoll_setup" [drivers/net/kgdboe.ko] undefined!
ERROR: "netpoll_parse_options" [drivers/net/kgdboe.ko] undefined!
ERROR: "netpoll_poll" [drivers/net/kgdboe.ko] undefined!
ERROR: "netpoll_send_udp" [drivers/net/kgdboe.ko] undefined!
ERROR: "netpoll_set_trap" [drivers/net/kgdboe.ko] undefined!
make[2]: *** [__modpost] Error 1
make[1]: *** [modules] Error 2
make: *** [all] Error 2

[1] http://www.fi.muni.cz/~xslaby/sklad/1.config

regards,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
-
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/

hci_sock.c build failure

[Andre Haupt]

Hi,

I did a make randconfig and then make C=1.

hci_sock.c fails to build because it doesnt know compat_timeval (i
guess).

find the error message and the config attached.

regards,

Andre
  LD  net/ax25/ax25.o
  LD  net/ax25/built-in.o
  CHECK   net/bluetooth/af_bluetooth.c
  CC  net/bluetooth/af_bluetooth.o
  CHECK   net/bluetooth/hci_core.c
  CC  net/bluetooth/hci_core.o
  CHECK   net/bluetooth/hci_conn.c
  CC  net/bluetooth/hci_conn.o
  CHECK   net/bluetooth/hci_event.c
  CC  net/bluetooth/hci_event.o
  CHECK   net/bluetooth/hci_sock.c
net/bluetooth/hci_sock.c:353:7: error: no member 'tv_sec' in struct 
compat_timeval
net/bluetooth/hci_sock.c:354:7: error: no member 'tv_usec' in struct 
compat_timeval
  CC  net/bluetooth/hci_sock.o
net/bluetooth/hci_sock.c: In function ‘hci_sock_cmsg’:
net/bluetooth/hci_sock.c:352: error: storage size of ‘ctv’ isn’t known
net/bluetooth/hci_sock.c:352: warning: unused variable ‘ctv’
make[2]: *** [net/bluetooth/hci_sock.o] Fehler 1
make[1]: *** [net/bluetooth] Fehler 2
make: *** [net] Fehler 2
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.23-rc6
# Wed Sep 12 09:31:19 2007
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_GENERIC_CMOS_UPDATE=y
CONFIG_CLOCKSOURCE_WATCHDOG=y
CONFIG_GENERIC_CLOCKEVENTS=y
CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_QUICKLIST=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"

#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
# CONFIG_POSIX_MQUEUE is not set
CONFIG_BSD_PROCESS_ACCT=y
CONFIG_BSD_PROCESS_ACCT_V3=y
CONFIG_TASKSTATS=y
# CONFIG_TASK_DELAY_ACCT is not set
# CONFIG_TASK_XACCT is not set
CONFIG_USER_NS=y
CONFIG_AUDIT=y
CONFIG_AUDITSYSCALL=y
# CONFIG_IKCONFIG is not set
CONFIG_LOG_BUF_SHIFT=14
CONFIG_CPUSETS=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_EXTRA_PASS=y
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not set
CONFIG_SLUB=y
# CONFIG_SLOB is not set
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
# CONFIG_MODULE_UNLOAD is not set
# CONFIG_MODVERSIONS is not set
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
CONFIG_LSF=y
# CONFIG_BLK_DEV_BSG is not set

#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=m
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"

#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set
CONFIG_SMP=y
# CONFIG_X86_PC is not set
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
CONFIG_X86_SUMMIT=y
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
CONFIG_X86_CYCLONE_TIMER=y
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
CONFIG_MGEODE_LX=y
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=5
CONFIG_X86_XADD=y
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_USE_3DNOW=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=4
CONFIG_HPET_TIMER=y

Re: [PATCH -mm] fs: define file_fsync() even for CONFIG_BLOCK=n

[Christoph Hellwig]

On Wed, Sep 12, 2007 at 11:06:10AM +0900, Paul Mundt wrote:
> There's nothing that is problematic for file_fsync() with CONFIG_BLOCK=n,
> and it's built in unconditionally anyways, so move the prototype out to
> reflect that. Without this, the unionfs build bails out.

Unionfs should stop using it instead.

-
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: x86 merge - a little feedback

[Christoph Hellwig]

On Tue, Sep 11, 2007 at 10:34:13PM +0200, Adrian Bunk wrote:
> As an example, visws.c is as much non-64bit as it is pre-i686.

Bullshit.  visws were shipped with P3s.

-
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: clockevents: fix resume logic

[Andrew Morton]

On Tue, 11 Sep 2007 23:49:47 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-09-11 at 21:52 +0200, Thomas Gleixner wrote:
> > > C1:  type[C1] promotion[C2] demotion[--] latency[001] 
> > > usage[0010] duration[]
> > >*C2:  type[C2] promotion[--] demotion[C1] latency[001] 
> > > usage[8316] duration[000170717293]
> > 
> > Ok, here we are. The bad one uses C2 which stops the local apic on the
> > VAIO. I suspect we end up in the suspend/resume with going into C2
> > without the broadcast active.
> > 
> > Can you try to get the output of SysRq-Q during the "it needs help from
> > keyboard" period ?
> 
> Summary of the oddities we are seing:
> 
> 1.) disabling local apic timer makes the problem go away
> 2.) disabling nohz and highres makes the problem go away
> 3.) adding the cpuidle patches from the acpi tree makes the problem go
> away

Only the fist cpuidle patch, actually.  I'd have though this was a big hint?

> The obvious conclusion is, that in all other cases we run into a state,
> where the local apic timer is not working.
> 
> 1) we do not use it
> 2) it is used in periodic mode
> 3) the cpu does not enter C2 (which turns the lapic timer off on the
> VAIO)
> 
> While 1) and 3) are understandable, the reason why 2) is working is a
> mystery because the periodic mode is affected by the C state as well.
> 
> Andrew, can you please provide the output of /proc/timer_list when you
> boot the kernel with "nohz=off highres=off", but honestly I do not
> expect a lot of enlightenment from it.

Timer List Version: v0.3
HRTIMER_MAX_CLOCK_BASES: 2
now at 91231842576 nsecs

cpu: 0
 clock 0:
  .index:  0
  .resolution: 4000250 nsecs
  .get_time:   ktime_get_real
  .offset: 0 nsecs
active timers:
 clock 1:
  .index:  1
  .resolution: 4000250 nsecs
  .get_time:   ktime_get
  .offset: 0 nsecs
active timers:
 #0: , hrtimer_wakeup, S:01, do_nanosleep, cpuspeed/1685
 # expires at 91415336182 nsecs [in 183493606 nsecs]
 #1: , it_real_fn, S:01, do_setitimer, ntpd/2182
 # expires at 91859626754 nsecs [in 627784178 nsecs]
 #2: , hrtimer_wakeup, S:01, do_nanosleep, hald-addon-stor/2321
 # expires at 92102929614 nsecs [in 871087038 nsecs]
 #3: , it_real_fn, S:01, do_setitimer, automount/2115
 # expires at 105148251993 nsecs [in 13916409417 nsecs]
 #4: , hrtimer_wakeup, S:01, do_nanosleep, crond/2228
 # expires at 111446499472 nsecs [in 20214656896 nsecs]
 #5: , it_real_fn, S:01, do_setitimer, syslogd/1886
 # expires at 114439083561 nsecs [in 23207240985 nsecs]
 #6: , hrtimer_wakeup, S:01, do_nanosleep, atd/2280
 # expires at 343127174592 nsecs [in 251895332016 nsecs]
 #7: , it_real_fn, S:01, do_setitimer, sendmail/2917
 # expires at 3659006407026 nsecs [in 3567774564450 nsecs]
 #8: , it_real_fn, S:01, do_setitimer, sendmail/2927
 # expires at 3659252445429 nsecs [in 3568020602853 nsecs]
 #9: , it_real_fn, S:01, do_setitimer, anacron/2272
 # expires at 3941983748056 nsecs [in 3850751905480 nsecs]
  .expires_next   : 9223372036854775807 nsecs
  .hres_active: 0
  .nr_events  : 0
  .nohz_mode  : 0
  .idle_tick  : 0 nsecs
  .tick_stopped   : 0
  .idle_jiffies   : 0
  .idle_calls : 0
  .idle_sleeps: 0
  .idle_entrytime : 0 nsecs
  .idle_sleeptime : 0 nsecs
  .last_jiffies   : 0
  .next_jiffies   : 0
  .idle_expires   : 0 nsecs
jiffies: 4294915081


Tick Device: mode: 0
Clock Event Device: pit
 max_delta_ns:   27461866
 min_delta_ns:   12571
 mult:   5124677
 shift:  32
 mode:   2
 next_event: 9223372036854775807 nsecs
 set_next_event: pit_next_event
 set_mode:   init_pit_timer
 event_handler:  tick_handle_periodic_broadcast
tick_broadcast_mask: 0001
tick_broadcast_oneshot_mask: 


Tick Device: mode: 0
Clock Event Device: lapic
 max_delta_ns:   1009158122
 min_delta_ns:   1804
 mult:   35701831
 shift:  32
 mode:   1
 next_event: 0 nsecs
 set_next_event: lapic_next_event
 set_mode:   lapic_timer_setup
 event_handler:  tick_handle_periodic


-
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: clockevents: fix resume logic

[Andrew Morton]

On Tue, 11 Sep 2007 21:52:01 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote:

> On Tue, 2007-09-11 at 11:44 -0700, Andrew Morton wrote:
> > > > there doesn't seem to be a lot of difference in the time handling, 
> > > > except
> > > > there are large changes in when things happen in the bootup sequence.
> > > 
> > > The question is whether the system goes into C2 with the patch applied.
> > > 
> > > Can you please provide the output of /proc/acpi/processor/CPU0/power for
> > > both the bad and the good one ?
> > > 
> > 
> > good:
> > 
> > sony:/home/akpm> cat /proc/acpi/processor/CPU0/power
> > active state:C0
> > max_cstate:  C8
> > bus master activity: 
> > maximum allowed latency: 8000 usec
> > states:
> > C1:  type[C1] promotion[--] demotion[--] latency[001] 
> > usage[] duration[]
> > C2:  type[C2] promotion[--] demotion[--] latency[001] 
> > usage[] duration[]
> > 
> > bad:
> > 
> > sony:/home/akpm> cat /proc/acpi/processor/CPU0/power
> > active state:C2
> > max_cstate:  C8
> > bus master activity: 
> > maximum allowed latency: 8000 usec
> > states:
> > C1:  type[C1] promotion[C2] demotion[--] latency[001] 
> > usage[0010] duration[]
> >*C2:  type[C2] promotion[--] demotion[C1] latency[001] 
> > usage[8316] duration[000170717293]
> 
> Ok, here we are. The bad one uses C2 which stops the local apic on the
> VAIO. I suspect we end up in the suspend/resume with going into C2
> without the broadcast active.
> 
> Can you try to get the output of SysRq-Q during the "it needs help from
> keyboard" period ?
> 

That's a bit tricky because hitting the keyboard is what unsticks things. 
And the video is black after resume-from-RAM (has always been thus) and we
broke netconsole-over-e100-during-resume back in 2.6.21 or thereabouts.



Here: http://userweb.kernel.org/~akpm/x.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/

[PATCH] Fix hci_sock build with CONFIG_COMPAT=n

[S.Çağlar Onur]

Hi;

Commit 66eb50d5c972cc16df2be730497b7f06d75d8132 introduces runtime check of 
CONFIG_COMPAT but without following patch compiliation failed with following 
error;

...
  CC [M]  net/bluetooth/hci_event.o
  CC [M]  net/bluetooth/hci_sock.o
net/bluetooth/hci_sock.c: In function `hci_sock_cmsg':
net/bluetooth/hci_sock.c:352: error: storage size of 'ctv' isn't known
net/bluetooth/hci_sock.c:352: warning: unused variable `ctv'
make[2]: *** [net/bluetooth/hci_sock.o] Hata 1
make[1]: *** [net/bluetooth] Hata 2
make: *** [net] Hata 2

Signed-off-by: S.Çağlar Onur <[EMAIL PROTECTED]>

 net/bluetooth/hci_sock.c |5 -
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
index d16ca8e..1364a90 100644
--- a/net/bluetooth/hci_sock.c
+++ b/net/bluetooth/hci_sock.c
@@ -347,7 +347,7 @@ static inline void hci_sock_cmsg(struct sock *sk, struct 
msghdr *msg, struct sk_
int len;
 
skb_get_timestamp(skb, );
-
+#ifdef CONFIG_COMPAT
if (msg->msg_flags & MSG_CMSG_COMPAT) {
struct compat_timeval ctv;
ctv.tv_sec = tv.tv_sec;
@@ -355,9 +355,12 @@ static inline void hci_sock_cmsg(struct sock *sk, struct 
msghdr *msg, struct sk_
data = 
len = sizeof(ctv);
} else {
+#endif
data = 
len = sizeof(tv);
+#ifdef CONFIG_COMPAT
}
+#endif
 
put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, len, data);
}


Cheers
-- 
S.Çağlar Onur <[EMAIL PROTECTED]>
http://cekirdek.pardus.org.tr/~caglar/

Linux is like living in a teepee. No Windows, no Gates and an Apache in house!
-
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 00/23] per device dirty throttling -v10

[Peter Zijlstra]

On Tue, 2007-09-11 at 22:31 -0400, John Stoffel wrote:

I hope the snipped questions were sufficiently answered in the other
mail. If not, holler :-)

> Peter> 3 is done by also scaling the dirty limit proportional to the
> Peter> current task's recent dirty rate.
> 
> Do you mean task or device here?  I'm just wondering how well this
> works with a bunch of devices with wildly varying speeds.  

Task. What I do is modify the limit like this:

  current_limit = dirty_limit * p(bdi_writeout) * (1 - p(task_dirty)/8)

Where the p() values are [0, 1].

By including the inverse of the task dirty rate one gets that tasks that
are more agressive dirtiers get throttled more aggressively, whereas
tasks that occasionally dirty a page get a little more room.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 08/15] Use spufs_coredump_num_notes everywhere, and don't NULL terminate

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> The spufs_coredump_read array is NULL terminated, and we also store the size.
> We only need one or the other, and storing the size should save a teensy bit
> of memory vs NULL terminating, so do that.

Given that we have another array in there with almost the same contents
and that is NULL terminated, I'd vote for doing it the other way and also
use NULL-termination instead of the count here.

Arnd <><
-
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 09/15] Internal __spufs_get_foo() routines should take a spu_context *

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> The SPUFS attribute get routines take a void * because the generic attribute
> code doesn't know what sort of data it's passing around.
> 
> However our internal __spufs_get_foo() routines can take a spu_context *
> directly, which saves plonking it in and out of a void * again.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

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

Re: [PATCH 11/15] Combine spufs_coredump_calls with spufs_calls

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> Because spufs might be built as a module, we can't have other parts of the
> kernel calling directly into it, we need stub routines that check first if the
> module is loaded.
> 
> Currently we have two structures which hold callbacks for these stubs, the
> syscalls are in spufs_calls and the coredump calls are in 
> spufs_coredump_calls.
> In both cases the logic for registering/unregistering is essentially the same,
> so we can simplify things by combining the two.

Nice cleanup!

> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

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

Re: [PATCH 10/15] Add contents of npc file to SPU coredumps

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>

Acked-by: Arnd Bergmann <[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]selinux: Improving SELinux read/write performance

[Yuichi Nakamura]

Hi. 

Stephen Smalley pointed out possibility of race condition
in off-list discussion.
Stephen Smalley said:
> One other observation about the patch:  it presently leaves open a
> (small) race window in which the file could get relabeled or policy gets
> reloaded between the time of the normal permission check (from
> selinux_inode_permission) and the time you copy the inode SID and policy
> seqno to the file security struct.  In which case you might end up never
> revalidating access upon read/write even though conditions changed since
> the open-time permission check.  Not sure how to cleanly fix in a
> lock-free manner, and adding locks here will only make matters worse.

To fix that, permission has to be checked in selinux_dentry_open.
Therefore, in open, number of permission checks increased.
As shown in benchmark result below, it does not affect open/close 
performance so much.

Following is benchmark result.
* Benchmark
lmbench simple read,write,open/close.

* Before tuning
1) Result for x86(Pentium 4 2.6Ghz), kernel 2.6.22
Base  SELinux  Overhead(%)
Simple read 1.10  1.24 12.3
Simple write1.02  1.14 14.0
open/close  5.97  7.45 24.9
* Base: kernel compiled without SELinux support

2) Result for SH(SH4, SH7751R), kernel 2.6.22
BaseSELinux   Overhead(%)
Simple read 2.395.49  130.5
Simple write2.075.10  146.6
open/close  32.662.8  93.0

* After tuning
1) Result for x86(Pentium 4 2.6Ghz), kernel 2.6.22
Base  SELinux  Overhead(%)
Simple read 1.10  1.13 2.3(Before 12.3)
Simple write1.02  1.0240.6(Before 14.0)
open/close  5.97  7.48 25.3(Before 24.9)
* Base: kernel compiled without SELinux support

2) Result for SH(SH4, SH7751R), kernel 2.6.22
BaseSELinux   Overhead(%)
Simple read 2.392.63  10.4(Before 130.5)
Simple write2.072.34  13.1(Before 146.6)
open/close  32.658.7  80.2(before 93.0)

Next is a patch.

* Description of patch
This patch improves performance of read/write in SELinux.
It improves performance by skipping permission check in 
selinux_file_permission. Permission is only checked when 
sid change or policy load is detected after file open.
To detect sid change, new LSM hook securiy_dentry_open is added.

Signed-off-by: Yuichi Nakamura<[EMAIL PROTECTED]>
---
 fs/open.c |5 
 include/linux/security.h  |   16 ++
 security/dummy.c  |6 +
 security/selinux/avc.c|5 
 security/selinux/hooks.c  |   43 +-
 security/selinux/include/avc.h|2 +
 security/selinux/include/objsec.h |2 +
 7 files changed, 78 insertions(+), 1 deletion(-)
diff -purN -X linux-2.6.22/Documentation/dontdiff 
linux-2.6.22.orig/security/selinux/avc.c linux-2.6.22/security/selinux/avc.c
--- linux-2.6.22.orig/security/selinux/avc.c2007-07-09 08:32:17.0 
+0900
+++ linux-2.6.22/security/selinux/avc.c 2007-09-12 08:24:27.0 +0900
@@ -913,3 +913,8 @@ int avc_has_perm(u32 ssid, u32 tsid, u16
avc_audit(ssid, tsid, tclass, requested, , rc, auditdata);
return rc;
 }
+
+u32 avc_policy_seqno(void)
+{
+   return avc_cache.latest_notif;
+}
diff -purN -X linux-2.6.22/Documentation/dontdiff 
linux-2.6.22.orig/security/selinux/hooks.c linux-2.6.22/security/selinux/hooks.c
--- linux-2.6.22.orig/security/selinux/hooks.c  2007-07-09 08:32:17.0 
+0900
+++ linux-2.6.22/security/selinux/hooks.c   2007-09-12 08:42:49.0 
+0900
@@ -14,6 +14,8 @@
  *  <[EMAIL PROTECTED]>
  *  Copyright (C) 2006 Hewlett-Packard Development Company, L.P.
  * Paul Moore, <[EMAIL PROTECTED]>
+ *  Copyright (C) 2007 Hitachi Software Engineering Co., Ltd.
+ * Yuichi Nakamura <[EMAIL PROTECTED]>
  *
  * This program is free software; you can redistribute it and/or modify
  * it under the terms of the GNU General Public License version 2,
@@ -80,6 +82,7 @@
 
 #define XATTR_SELINUX_SUFFIX "selinux"
 #define XATTR_NAME_SELINUX XATTR_SECURITY_PREFIX XATTR_SELINUX_SUFFIX
+#define ACC_MODE(x) ("\000\004\002\006"[(x)_ACCMODE])
 
 extern unsigned int policydb_loaded_version;
 extern int selinux_nlmsg_lookup(u16 sclass, u16 nlmsg_type, u32 *perm);
@@ -2458,7 +2461,7 @@ static int selinux_inode_listsecurity(st
 
 /* file security operations */
 
-static int selinux_file_permission(struct file *file, int mask)
+static int selinux_revalidate_file_permission(struct file *file, int mask)
 {
int rc;
struct inode *inode = file->f_path.dentry->d_inode;
@@ -2480,6 +2483,25 @@ static int selinux_file_permission(struc
return selinux_netlbl_inode_permission(inode, mask);
 }
 
+static int selinux_file_permission(struct file *file, int mask)
+{
+   struct inode *inode = file->f_path.dentry->d_inode;
+   

Re: [PATCH 15/15] Add DEFINE_SPUFS_ATTRIBUTE()

[Arnd Bergmann]

On Wednesday 12 September 2007, Michael Ellerman wrote:
> On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> > This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> > DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> > routine for us.
> > 
> > Unfortunately we need two get routines (a locked and unlocked version) to
> > support the coredump code. This patch hides one of those (the locked 
> > version)
> > inside the macro foo.

> 
> jk said:
> > "Good god man!"
> 
> Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50% code
> reduction ain't bad :)

Have you looked at the change in object code size? I would expect the
object code to actually become bigger. I also think that it hurts
readability rather than help it.

Maybe a better solution is to change the core dump code to not
require the mutex to be held in the first place. By the time
we get to call the get functions, it should already be in
saved state and no longer be able to get scheduled, so we might
not actually need all the extra tricks with avoiding the
mutex to be taken again.

Arnd <><
-
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 21/23] mm: per device dirty threshold

[Peter Zijlstra]

On Tue, 2007-09-11 at 22:36 -0400, John Stoffel wrote:
> Peter> Scale writeback cache per backing device, proportional to its
> Peter> writeout speed.  By decoupling the BDI dirty thresholds a
> Peter> number of problems we currently have will go away, namely:
> 
> Ah, this clarifies my questions!  Thanks!
> 
> Peter>  - mutual interference starvation (for any number of BDIs);
> Peter>  - deadlocks with stacked BDIs (loop, FUSE and local NFS mounts).
> 
> Peter> It might be that all dirty pages are for a single BDI while
> Peter> other BDIs are idling. By giving each BDI a 'fair' share of the
> Peter> dirty limit, each one can have dirty pages outstanding and make
> Peter> progress.
> 
> Question, can you change (shrink) the limit on a BDI while it has IO
> in flight?  And what will that do to the system?  I.e. if you have one
> device doing IO, so that it has a majority of the dirty limit.  Then
> another device starts IO, and it's a *faster* device, how
> quickly/slowly does the BDI dirty limits change for both the old and
> new device?  

Yes, it can change while in use. A measure of how quickly it can change
is roughly: it can half in a dirty_limit worth of writeout.

What will happen is that those processes doing heavy IO on the slower
device will get throttled more aggressively until its below its new
threshold again - however all the time it will keep on writing at (full)
speed because it will have this backlog to rid itself of, and by doing
that it completes writeouts which ensure it will keep part of the dirty
limit for itself, and thus can always make progress.

You can monitor this by looking at /sys/block/sd*/queue/cache_size while
doing such a thing. It should stabilise quite 'quickly'.

> Peter> A global threshold also creates a deadlock for stacked BDIs;
> Peter> when A writes to B, and A generates enough dirty pages to get
> Peter> throttled, B will never start writeback until the dirty pages
> Peter> go away. Again, by giving each BDI its own 'independent' dirty
> Peter> limit, this problem is avoided.
> 
> Peter> So the problem is to determine how to distribute the total
> Peter> dirty limit across the BDIs fairly and efficiently. A DBI that
> 
> You mean BDI here, not DBI.  

Uhh, yeah, obviously :-)

> Peter> has a large dirty limit but does not have any dirty pages
> Peter> outstanding is a waste.
> 
> Peter> What is done is to keep a floating proportion between the DBIs
> Peter> based on writeback completions. This way faster/more active
> Peter> devices get a larger share than slower/idle devices.
> 
> Does a slower device get a BDI which is calculated to keep it's limit
> under a certain number of seconds of outstanding IO?  This way no
> device can build up more than say 15 seconds of outstanding IO to
> flush at any one time.  

Perhaps already answered above, as long as there is dirty stuff to write
out it will keep completing writes and thus gain a stable share of the
dirty limit.


signature.asc
Description: This is a digitally signed message part

Re: [PATCH 01/15] Extract the file descriptor search logic in SPU coredump code

[Andrew Morton]

On Wed, 12 Sep 2007 18:17:42 +1000 Jeremy Kerr <[EMAIL PROTECTED]> wrote:

> This series looks good to me, thanks for the fixes. I'll do some testing 
> tomorrow but it looks like it'll be fine as-is.
> 
> Andrew - almost all of these are for spufs, the notable exception being:
> 
>  [PATCH 12/15] Cleanup ELF coredump extra notes logic
> 
> which touches the generic elf/coredump path.
> 
> Are you ok for me to merge this to my spufs tree, and upstream via 
> paulus?

Sure.  I'd only get in the way with spufs stuff.
-
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 4/6] Embed zone_id information within the zonelist->zones pointer

[Mel Gorman]

On (12/09/07 16:51), KAMEZAWA Hiroyuki didst pronounce:
> On Tue, 11 Sep 2007 22:31:27 +0100 (IST)
> Mel Gorman <[EMAIL PROTECTED]> wrote:
> 
> > Using two zonelists per node requires very frequent use of zone_idx(). This
> > is costly as it involves a lookup of another structure and a substraction
> > operation. As struct zone is always word aligned and normally cache-line
> > aligned, the pointer values have a number of 0's at the least significant
> > bits of the address.
> > 
> > This patch embeds the zone_id of a zone in the zonelist->zones pointers.
> > The real zone pointer is retrieved using the zonelist_zone() helper 
> > function.
> > The ID of the zone is found using zonelist_zone_idx().  To avoid accidental
> > references, the zones field is renamed to _zones and the type changed to
> > unsigned long.
> > 
> At first, I welcome this patch. thanks!.
> 
> 
> A comment after reading all is, how about defining zonelist as following
> instead of encoding in pointer ?
> ==
> struct zone_pointer {
>   struct zone *zone;
>   int  node_id;  
>   int  zone_idx;
> };
> 
> struct zonelist {
>   struct zone_pointer _zones[MAX_ZONES_PER_ZONELIST + 1];
> };
> 
> #define zonelist_zone(zl)  (zl)->zone
> #define zonelist_zone_idx(zl)  (zl)->zone_idx
> #ifdef CONFIG_NUMA
> #define zonelist_zone_nid(zl)  (zl)->node_id
> #else
> #define zonelist_zone_nid(zl, i)  (0)
> ==
> 

That is an interesting idea. I'll try it out and see what happens.
Thanks

> If we really want to avoid unnecessary access to "zone" while walking 
> zonelist,
> above may do something good.  Cons is this makes sizeof zonlist bigger.
> 

While this is true, it might not affect the size of struct zone because
of padding. One way to find out

-- 
Mel Gorman
Part-time Phd Student  Linux Technology Center
University of Limerick IBM Dublin Software Lab
-
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] Moxa: Fix tiny compiler warning when building withoug CONFIG_PCI

[Jiri Slaby]

Andrew Morton napsal(a):
> On Fri, 17 Aug 2007 00:08:58 +0200 Jesper Juhl <[EMAIL PROTECTED]> wrote:
> 
>> Fix this tiny compiler warning in Moxa driver : 
>>   drivers/char/mxser.c:386: warning: 'mxser_get_PCI_conf' declared 'static' 
>> but never defined
>> when building without CONFIG_PCI.
>>
>>
>> Signed-off-by: Jesper Juhl <[EMAIL PROTECTED]>
>> ---
>>
>>  drivers/char/mxser.c |2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/drivers/char/mxser.c b/drivers/char/mxser.c
>> index 2aee3fe..83b15b5 100644
>> --- a/drivers/char/mxser.c
>> +++ b/drivers/char/mxser.c
>> @@ -383,7 +383,9 @@ static int mxser_init(void);
>>  
>>  /* static void   mxser_poll(unsigned long); */
>>  static int mxser_get_ISA_conf(int, struct mxser_hwconf *);
>> +#ifdef CONFIG_PCI
>>  static int mxser_get_PCI_conf(int, int, int, struct mxser_hwconf *);
>> +#endif
>>  static void mxser_do_softint(struct work_struct *);
>>  static int mxser_open(struct tty_struct *, struct file *);
>>  static void mxser_close(struct tty_struct *, struct file *);
>>
> 
> mxser_get_PCI_conf() is defined before it is used anwyay.  So that
> prototype is a stupid waste of space and just adds problems.
> 
> --- 
> a/drivers/char/mxser.c~mxser-fix-compiler-warning-when-building-withoug-config_pci
> +++ a/drivers/char/mxser.c
> @@ -383,7 +383,6 @@ static int mxser_init(void);
>  
>  /* static void   mxser_poll(unsigned long); */
>  static int mxser_get_ISA_conf(int, struct mxser_hwconf *);
> -static int mxser_get_PCI_conf(int, int, int, struct mxser_hwconf *);
>  static void mxser_do_softint(struct work_struct *);
>  static int mxser_open(struct tty_struct *, struct file *);
>  static void mxser_close(struct tty_struct *, struct file *);

Acked-by: Jiri Slaby <[EMAIL PROTECTED]>

thanks,
-- 
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
-
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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Andrea Arcangeli]

On Tue, Sep 11, 2007 at 05:04:41PM -0700, Christoph Lameter wrote:
> I would think that your approach would be slower since you always have to 
> populate 1 << N ptes when mmapping a file? Plus there is a lot of wastage 

I don't have to populate them, I could just map one at time. The only
reason I want to populate every possible pte that could map that page
(by checking vma ranges) is to _improve_ performance by decreasing the
number of page faults of an order of magnitude. Then with the 62th bit
after NX giving me a 64k tlb, I could decrease the frequency of the
tlb misses too.

> of memory because even a file with one character needs an order N page? So 
> there are less pages available for the same workload.

This is a known issue. The same is true for ppc64 64k. If that really
is an issue, that may need some generic solution with tail packing.

> Then you are breaking mmap assumptions of applications becaused the order 
> N kernel will no longer be able to map 4k pages.  You likely need a new 
> binary format that has pages correctly aligned. I know that we would need 
> one on IA64 if we go beyond the established page sizes.

No you misunderstood the whole design. My patch will be 100% backwards
compatible in all respects. If I could break backwards compatibility
70% of the complexity would go away...
-
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 01/15] Extract the file descriptor search logic in SPU coredump code

[Jeremy Kerr]

Hi Michael,

This series looks good to me, thanks for the fixes. I'll do some testing 
tomorrow but it looks like it'll be fine as-is.

Andrew - almost all of these are for spufs, the notable exception being:

 [PATCH 12/15] Cleanup ELF coredump extra notes logic

which touches the generic elf/coredump path.

Are you ok for me to merge this to my spufs tree, and upstream via 
paulus?

Cheers,


Jeremy
-
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: [Sparc64 BUG] hangup under booting 2.6.22.X whith Sparc64

[David Miller]

From: "Kövedi_Krisztián" <[EMAIL PROTECTED]>
Date: Wed, 12 Sep 2007 09:47:45 +0200

> The patch work fine the kernel booting up without error messages.

Thanks for testing.
-
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 15/15] Add DEFINE_SPUFS_ATTRIBUTE()

[Michael Ellerman]

On Wed, 2007-09-12 at 17:43 +1000, Michael Ellerman wrote:
> This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
> DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
> routine for us.
> 
> Unfortunately we need two get routines (a locked and unlocked version) to
> support the coredump code. This patch hides one of those (the locked version)
> inside the macro foo.
> 
> Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
> ---
>  arch/powerpc/platforms/cell/spufs/file.c |  216 
> +++---
>  1 files changed, 76 insertions(+), 140 deletions(-)


jk said:
> "Good god man!"

Yeah, I'm a bit lukewarm on this one. But the diffstat is nice, 50% code
reduction ain't bad :)

cheers

-- 
Michael Ellerman
OzLabs, IBM Australia Development Lab

wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)

We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person


signature.asc
Description: This is a digitally signed message part

stripping down the kernel-parameters.txt file

[Robert P. J. Day]

  while killing some time between compiles and ridding the
kernel-parameters.txt file of out-of-date or incorrect cruft, it
occurs to me that that file is borderline valueless since it
apparently tries to document every possible boot-time parameter,
including those associated with individual modules.  that's just
silly.

  it would make far more sense if that file restricted itself to just
those parameters that you'd consider fundamental or basic -- those
defined with one of "__setup()" or "early_param()" that would apply to
most users.

  instead, you find stuff like this (a random example):

  bttv.card=  [HW,V4L] bttv (bt848 + bt878 based grabber cards)
  bttv.radio= Most important insmod options are available as
  kernel args too.
  bttv.pll=   See Documentation/video4linux/bttv/Insmod-options
  bttv.tuner= and Documentation/video4linux/bttv/CARDLIST

not to belittle the bttv module but, really, is that information
worthy of being recorded in the top-level parms.txt file?  and if
you're going to be consistent, you'd want to do that for every single
module and its respective throughout the tree, at which the parms.txt
file collapses under its own weight from forever being updated and has
so much information that it's impossible to find the useful stuff.

  i suggest that that file record only the basic boot-time params, and
the documentation for module-specific parameters be moved closer to
the module source itself.  there's no point in that poor file trying
to keep up with all of the module development in the tree.

rday

p.s.  and, while we're at it, folks might like to start replacing
the calls to "__setup()" in their driver code with the newer module
parameters mechanism.  it's just a thought.  :-)


-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

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

Can LVM block I/O and hang a system?

[Maurice Volaski]

A working system begins hanging and it seems to be stuck on I/O 
processes that use ext3 partitions that are running on top of LVM. 
The system is AMD 64-bit running Gentoo. Kernel is Gentoo 2.6.22-r3 
and LVM lvm2-2.02.27. Here is the disk setup:


Boot disk, attached to motherboard via SATA
1) some partitions accessed via ext3 -> hardware partition.
2) some partitions accessed via ext3 -> drbd, which is version 8.0.5, 
-> hardware partition.


External SATA-SCSI RAID, attached to via an LSI Logic card,
3) one partition accessed via ext3 -> drbd -> hardware partition.
4) some partitions accessed via ext3 -> LVM -> drbd -> hardware partition.

On repeated reboots, #1) boots fine, and I can fsck #2) no problem. I 
can also fsck #3, but the fsck processes on #4, which all are trying 
to recover the journals, just seem to not do anything. There is no 
evidence of I/O and there are no errors reported anywhere. The frozen 
fsck processes cannot even be killed and the system ignores the 
shutdown command.


That the hanging fsck processes are all occurring on just the LVM 
partitions seems to imply that LVM is responsible.


drbd had been unattached to its peer during this time, and when I 
reattached it, it had no trouble syncing to the peer. That system, 
which should basically be identical, however, has no trouble running 
running fsck everywhere. I'm not sure, though, if that lets LVM off 
the hook.

--

Maurice Volaski, [EMAIL PROTECTED]
Computing Support, Rose F. Kennedy Center
Albert Einstein College of Medicine of Yeshiva University
-
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: [Sparc64 BUG] hangup under booting 2.6.22.X whith Sparc64

[Kövedi Krisztián]

2007/9/11, David Miller <[EMAIL PROTECTED]>:
>
> I think this patch should fix the problem.
>
> Please give it a try, thanks.
>
> diff --git a/arch/sparc64/kernel/pci.c b/arch/sparc64/kernel/pci.c
> index 139b4cf..e8dac81 100644
> --- a/arch/sparc64/kernel/pci.c
> +++ b/arch/sparc64/kernel/pci.c
> @@ -744,7 +744,7 @@ static void __devinit pci_of_scan_bus(struct pci_pbm_info 
> *pbm,
>  {
> struct device_node *child;
> const u32 *reg;
> -   int reglen, devfn;
> +   int reglen, devfn, prev_devfn;
> struct pci_dev *dev;
>
> if (ofpci_verbose)
> @@ -752,14 +752,25 @@ static void __devinit pci_of_scan_bus(struct 
> pci_pbm_info *pbm,
>node->full_name, bus->number);
>
> child = NULL;
> +   prev_devfn = -1;
> while ((child = of_get_next_child(node, child)) != NULL) {
> if (ofpci_verbose)
> printk("  * %s\n", child->full_name);
> reg = of_get_property(child, "reg", );
> if (reg == NULL || reglen < 20)
> continue;
> +
> devfn = (reg[0] >> 8) & 0xff;
>
> +   /* This is a workaround for some device trees
> +* which list PCI devices twice.  On the V100
> +* for example, device number 3 is listed twice.
> +* Once as "pm" and once again as "lomp".
> +*/
> +   if (devfn == prev_devfn)
> +   continue;
> +   prev_devfn = devfn;
> +
> /* create a new pci_dev for this device */
> dev = of_create_pci_dev(pbm, child, bus, devfn, 0);
> if (!dev)
>

Thanks
The patch work fine the kernel booting up without error messages.


when i patch the kernel become this error message:

patch -p1 < ~/2.6.22.6.patch
patching file arch/sparc64/kernel/pci.c
Hunk #1 FAILED at 744.
Hunk #2 FAILED at 752.
2 out of 2 hunks FAILED -- saving rejects to file arch/sparc64/kernel/pci.c.rej

but i add manual this patch the kernel and it works.
-
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 4/6] Embed zone_id information within the zonelist->zones pointer

[KAMEZAWA Hiroyuki]

On Tue, 11 Sep 2007 22:31:27 +0100 (IST)
Mel Gorman <[EMAIL PROTECTED]> wrote:

> Using two zonelists per node requires very frequent use of zone_idx(). This
> is costly as it involves a lookup of another structure and a substraction
> operation. As struct zone is always word aligned and normally cache-line
> aligned, the pointer values have a number of 0's at the least significant
> bits of the address.
> 
> This patch embeds the zone_id of a zone in the zonelist->zones pointers.
> The real zone pointer is retrieved using the zonelist_zone() helper function.
> The ID of the zone is found using zonelist_zone_idx().  To avoid accidental
> references, the zones field is renamed to _zones and the type changed to
> unsigned long.
> 
At first, I welcome this patch. thanks!.


A comment after reading all is, how about defining zonelist as following
instead of encoding in pointer ?
==
struct zone_pointer {
struct zone *zone;
int  node_id;  
int  zone_idx;
};

struct zonelist {
struct zone_pointer _zones[MAX_ZONES_PER_ZONELIST + 1];
};

#define zonelist_zone(zl)  (zl)->zone
#define zonelist_zone_idx(zl)  (zl)->zone_idx
#ifdef CONFIG_NUMA
#define zonelist_zone_nid(zl)  (zl)->node_id
#else
#define zonelist_zone_nid(zl, i)  (0)
==

If we really want to avoid unnecessary access to "zone" while walking zonelist,
above may do something good.  Cons is this makes sizeof zonlist bigger.

Thanks,
-Kame

-
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 14/15] Respect RLIMIT_CORE in spu coredump code

[Michael Ellerman]

Currently the spu coredump code doesn't respect the ulimit, it should.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |4 
 1 files changed, 4 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index c3b5cd5..b8ab2c6 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -53,8 +53,12 @@ static ssize_t do_coredump_read(int num, struct spu_context 
*ctx, void *buffer,
  */
 static int spufs_dump_write(struct file *file, const void *addr, int nr, 
loff_t *foffset)
 {
+   unsigned long limit = current->signal->rlim[RLIMIT_CORE].rlim_cur;
ssize_t written;
 
+   if (*foffset + nr > limit)
+   return -EIO;
+
written = file->f_op->write(file, addr, nr, >f_pos);
*foffset += written;
 
-- 
1.5.1.3.g7a33b

-
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 15/15] Add DEFINE_SPUFS_ATTRIBUTE()

[Michael Ellerman]

This patch adds DEFINE_SPUFS_ATTRIBUTE(), a wraper around
DEFINE_SIMPLE_ATTRIBUTE which does the specified locking for the get
routine for us.

Unfortunately we need two get routines (a locked and unlocked version) to
support the coredump code. This patch hides one of those (the locked version)
inside the macro foo.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/file.c |  216 +++---
 1 files changed, 76 insertions(+), 140 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index 52f020a..46ec8eb 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1076,6 +1076,36 @@ static const struct file_operations 
spufs_signal2_nosched_fops = {
.mmap = spufs_signal2_mmap,
 };
 
+/*
+ * This is a wrapper around DEFINE_SIMPLE_ATTRIBUTE which does the
+ * work of acquiring (or not) the SPU context before calling through
+ * to the actual get routine. The set routine is called directly.
+ */
+#define SPU_ATTR_NOACQUIRE 0
+#define SPU_ATTR_ACQUIRE   1
+#define SPU_ATTR_ACQUIRE_SAVED 2
+
+#define DEFINE_SPUFS_ATTRIBUTE(__name, __get, __set, __fmt, __acquire) \
+static u64 __##__get(void *data)   \
+{  \
+   struct spu_context *ctx = data; \
+   u64 ret;\
+   \
+   if (__acquire == SPU_ATTR_ACQUIRE) {\
+   spu_acquire(ctx);   \
+   ret = __get(ctx);   \
+   spu_release(ctx);   \
+   } else if (__acquire == SPU_ATTR_ACQUIRE_SAVED) {   \
+   spu_acquire_saved(ctx); \
+   ret = __get(ctx);   \
+   spu_release_saved(ctx); \
+   } else  \
+   ret = __get(ctx);   \
+   \
+   return ret; \
+}  \
+DEFINE_SIMPLE_ATTRIBUTE(__name, __##__get, __set, __fmt);
+
 static void spufs_signal1_type_set(void *data, u64 val)
 {
struct spu_context *ctx = data;
@@ -1085,24 +1115,13 @@ static void spufs_signal1_type_set(void *data, u64 val)
spu_release(ctx);
 }
 
-static u64 __spufs_signal1_type_get(struct spu_context *ctx)
+static u64 spufs_signal1_type_get(struct spu_context *ctx)
 {
return ctx->ops->signal1_type_get(ctx);
 }
+DEFINE_SPUFS_ATTRIBUTE(spufs_signal1_type, spufs_signal1_type_get,
+  spufs_signal1_type_set, "%llu", SPU_ATTR_ACQUIRE);
 
-static u64 spufs_signal1_type_get(void *data)
-{
-   struct spu_context *ctx = data;
-   u64 ret;
-
-   spu_acquire(ctx);
-   ret = __spufs_signal1_type_get(ctx);
-   spu_release(ctx);
-
-   return ret;
-}
-DEFINE_SIMPLE_ATTRIBUTE(spufs_signal1_type, spufs_signal1_type_get,
-   spufs_signal1_type_set, "%llu");
 
 static void spufs_signal2_type_set(void *data, u64 val)
 {
@@ -1113,24 +1132,12 @@ static void spufs_signal2_type_set(void *data, u64 val)
spu_release(ctx);
 }
 
-static u64 __spufs_signal2_type_get(struct spu_context *ctx)
+static u64 spufs_signal2_type_get(struct spu_context *ctx)
 {
return ctx->ops->signal2_type_get(ctx);
 }
-
-static u64 spufs_signal2_type_get(void *data)
-{
-   struct spu_context *ctx = data;
-   u64 ret;
-
-   spu_acquire(ctx);
-   ret = __spufs_signal2_type_get(ctx);
-   spu_release(ctx);
-
-   return ret;
-}
-DEFINE_SIMPLE_ATTRIBUTE(spufs_signal2_type, spufs_signal2_type_get,
-   spufs_signal2_type_set, "%llu");
+DEFINE_SPUFS_ATTRIBUTE(spufs_signal2_type, spufs_signal2_type_get,
+  spufs_signal2_type_set, "%llu", SPU_ATTR_ACQUIRE);
 
 #if SPUFS_MMAP_4K
 static unsigned long spufs_mss_mmap_nopfn(struct vm_area_struct *vma,
@@ -1606,22 +1613,12 @@ static void spufs_npc_set(void *data, u64 val)
spu_release(ctx);
 }
 
-static u64 __spufs_npc_get(struct spu_context *ctx)
+static u64 spufs_npc_get(struct spu_context *ctx)
 {
return ctx->ops->npc_read(ctx);
 }
-
-static u64 spufs_npc_get(void *data)
-{
-   struct spu_context *ctx = data;
-   u64 ret;
-   spu_acquire(ctx);
-   ret = __spufs_npc_get(ctx);
-   spu_release(ctx);
-   return ret;
-}

[PATCH 12/15] Cleanup ELF coredump extra notes logic

[Michael Ellerman]

To start with, arch_notes_size() etc. is a little too ambiguous a name for
my liking, so change the function names to be more explicit.

Calling through macros is ugly, especially with hidden parameters, so don't
do that, call the routines directly.

Use ARCH_HAVE_EXTRA_ELF_NOTES as the only flag, and based on it decide
whether we want the extern declarations or the empty versions.

Since we have empty routines, actually use them in the coredump code to
save a few #ifdefs.

We want to change the handling of foffset so that the write routine updates
foffset as it goes, instead of using file->f_pos (so that writing to a pipe
works). So pass foffset to the write routine, and for now just set it to
file->f_pos at the end of writing.

It should also be possible for the write routine to fail, so change it to
return int and treat a non-zero return as failure.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spu_syscalls.c |   12 +---
 fs/binfmt_elf.c|   14 +++---
 include/asm-powerpc/elf.h  |9 ++---
 include/linux/elf.h|   14 --
 4 files changed, 22 insertions(+), 27 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spu_syscalls.c 
b/arch/powerpc/platforms/cell/spu_syscalls.c
index cf00251..d9b2fd2 100644
--- a/arch/powerpc/platforms/cell/spu_syscalls.c
+++ b/arch/powerpc/platforms/cell/spu_syscalls.c
@@ -21,6 +21,7 @@
  * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
  */
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -109,7 +110,7 @@ asmlinkage long sys_spu_run(int fd, __u32 __user *unpc, 
__u32 __user *ustatus)
return ret;
 }
 
-int arch_notes_size(void)
+int elf_coredump_extra_notes_size(void)
 {
struct spufs_calls *calls;
int ret;
@@ -125,17 +126,22 @@ int arch_notes_size(void)
return ret;
 }
 
-void arch_write_notes(struct file *file)
+int elf_coredump_extra_notes_write(struct file *file, loff_t *foffset)
 {
struct spufs_calls *calls;
 
calls = spufs_calls_get();
if (!calls)
-   return;
+   return 0;
 
calls->coredump_extra_notes_write(file);
 
spufs_calls_put(calls);
+
+   /* Fudge foffset for now */
+   *foffset = file->f_pos;
+
+   return 0;
 }
 
 int register_spu_syscalls(struct spufs_calls *calls)
diff --git a/fs/binfmt_elf.c b/fs/binfmt_elf.c
index 4482a06..b1013f3 100644
--- a/fs/binfmt_elf.c
+++ b/fs/binfmt_elf.c
@@ -1514,9 +1514,6 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)
int thread_status_size = 0;
elf_addr_t *auxv;
unsigned long mm_flags;
-#ifdef ELF_CORE_WRITE_EXTRA_NOTES
-   int extra_notes_size;
-#endif
 
/*
 * We no longer stop all VM operations.
@@ -1645,10 +1642,7 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)

sz += thread_status_size;
 
-#ifdef ELF_CORE_WRITE_EXTRA_NOTES
-   extra_notes_size = ELF_CORE_EXTRA_NOTES_SIZE;
-   sz += extra_notes_size;
-#endif
+   sz += elf_coredump_extra_notes_size();
 
fill_elf_note_phdr(, sz, offset);
offset += sz;
@@ -1698,10 +1692,8 @@ static int elf_core_dump(long signr, struct pt_regs 
*regs, struct file *file)
if (!writenote(notes + i, file, ))
goto end_coredump;
 
-#ifdef ELF_CORE_WRITE_EXTRA_NOTES
-   ELF_CORE_WRITE_EXTRA_NOTES;
-   foffset += extra_notes_size;
-#endif
+   if (elf_coredump_extra_notes_write(file, ))
+   goto end_coredump;
 
/* write out the thread status notes section */
list_for_each(t, _list) {
diff --git a/include/asm-powerpc/elf.h b/include/asm-powerpc/elf.h
index de50799..e42820d 100644
--- a/include/asm-powerpc/elf.h
+++ b/include/asm-powerpc/elf.h
@@ -413,13 +413,8 @@ do {   
\
 /* Notes used in ET_CORE. Note name is "SPU//". */
 #define NT_SPU 1
 
-extern int arch_notes_size(void);
-extern void arch_write_notes(struct file *file);
-
-#define ELF_CORE_EXTRA_NOTES_SIZE arch_notes_size()
-#define ELF_CORE_WRITE_EXTRA_NOTES arch_write_notes(file)
-
 #define ARCH_HAVE_EXTRA_ELF_NOTES
-#endif /* CONFIG_PPC_CELL */
+
+#endif /* CONFIG_SPU_BASE */
 
 #endif /* _ASM_POWERPC_ELF_H */
diff --git a/include/linux/elf.h b/include/linux/elf.h
index 8b17ffe..d2da84a 100644
--- a/include/linux/elf.h
+++ b/include/linux/elf.h
@@ -389,12 +389,14 @@ extern Elf64_Dyn _DYNAMIC [];
 
 #endif
 
+/* Optional callbacks to write extra ELF notes. */
 #ifndef ARCH_HAVE_EXTRA_ELF_NOTES
-static inline int arch_notes_size(void) { return 0; }
-static inline void arch_write_notes(struct file *file) { }
-
-#define ELF_CORE_EXTRA_NOTES_SIZE arch_notes_size()
-#define ELF_CORE_WRITE_EXTRA_NOTES arch_write_notes(file)

[PATCH 13/15] Handle errors in SPU coredump code, and support coredump to a pipe

[Michael Ellerman]

Rework spufs_coredump_extra_notes_write() to check for and return errors.

If we're coredumping to a pipe we can't trust file->f_pos, we need to
maintain the foffset value passed to us. The cleanest way to do this is
to have the low level write routine increment foffset when we've
successfully written.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spu_syscalls.c   |8 +--
 arch/powerpc/platforms/cell/spufs/coredump.c |   89 ++
 arch/powerpc/platforms/cell/spufs/spufs.h|2 +-
 include/asm-powerpc/spu.h|2 +-
 4 files changed, 67 insertions(+), 34 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spu_syscalls.c 
b/arch/powerpc/platforms/cell/spu_syscalls.c
index d9b2fd2..0b69107 100644
--- a/arch/powerpc/platforms/cell/spu_syscalls.c
+++ b/arch/powerpc/platforms/cell/spu_syscalls.c
@@ -129,19 +129,17 @@ int elf_coredump_extra_notes_size(void)
 int elf_coredump_extra_notes_write(struct file *file, loff_t *foffset)
 {
struct spufs_calls *calls;
+   int ret;
 
calls = spufs_calls_get();
if (!calls)
return 0;
 
-   calls->coredump_extra_notes_write(file);
+   ret = calls->coredump_extra_notes_write(file, foffset);
 
spufs_calls_put(calls);
 
-   /* Fudge foffset for now */
-   *foffset = file->f_pos;
-
-   return 0;
+   return ret;
 }
 
 int register_spu_syscalls(struct spufs_calls *calls)
diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 7395350..c3b5cd5 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -51,19 +51,34 @@ static ssize_t do_coredump_read(int num, struct spu_context 
*ctx, void *buffer,
  * These are the only things you should do on a core-file: use only these
  * functions to write out all the necessary info.
  */
-static int spufs_dump_write(struct file *file, const void *addr, int nr)
+static int spufs_dump_write(struct file *file, const void *addr, int nr, 
loff_t *foffset)
 {
-   return file->f_op->write(file, addr, nr, >f_pos) == nr;
+   ssize_t written;
+
+   written = file->f_op->write(file, addr, nr, >f_pos);
+   *foffset += written;
+
+   if (written != nr)
+   return -EIO;
+
+   return 0;
 }
 
-static int spufs_dump_seek(struct file *file, loff_t off)
+static int spufs_dump_align(struct file *file, char *buf, loff_t new_off,
+   loff_t *foffset)
 {
-   if (file->f_op->llseek) {
-   if (file->f_op->llseek(file, off, 0) != off)
-   return 0;
-   } else
-   file->f_pos = off;
-   return 1;
+   int rc, size;
+
+   size = min((loff_t)PAGE_SIZE, new_off - *foffset);
+   memset(buf, 0, size);
+
+   rc = 0;
+   while (rc == 0 && new_off > *foffset) {
+   size = min((loff_t)PAGE_SIZE, new_off - *foffset);
+   rc = spufs_dump_write(file, buf, size, foffset);
+   }
+
+   return rc;
 }
 
 static int spufs_ctx_note_size(struct spu_context *ctx, int dfd)
@@ -141,11 +156,11 @@ int spufs_coredump_extra_notes_size(void)
return size;
 }
 
-static void spufs_arch_write_note(struct spu_context *ctx, int i,
-   struct file *file, int dfd)
+static int spufs_arch_write_note(struct spu_context *ctx, int i,
+ struct file *file, int dfd, loff_t *foffset)
 {
loff_t pos = 0;
-   int sz, rc, total = 0;
+   int sz, rc, nread, total = 0;
const int bufsz = PAGE_SIZE;
char *name;
char fullname[80], *buf;
@@ -153,7 +168,7 @@ static void spufs_arch_write_note(struct spu_context *ctx, 
int i,
 
buf = (void *)get_zeroed_page(GFP_KERNEL);
if (!buf)
-   return;
+   return -ENOMEM;
 
name = spufs_coredump_read[i].name;
sz = spufs_coredump_read[i].size;
@@ -163,40 +178,60 @@ static void spufs_arch_write_note(struct spu_context 
*ctx, int i,
en.n_descsz = sz;
en.n_type = NT_SPU;
 
-   if (!spufs_dump_write(file, , sizeof(en)))
+   rc = spufs_dump_write(file, , sizeof(en), foffset);
+   if (rc)
goto out;
-   if (!spufs_dump_write(file, fullname, en.n_namesz))
+
+   rc = spufs_dump_write(file, fullname, en.n_namesz, foffset);
+   if (rc)
goto out;
-   if (!spufs_dump_seek(file, roundup((unsigned long)file->f_pos, 4)))
+
+   rc = spufs_dump_align(file, buf, roundup(*foffset, 4), foffset);
+   if (rc)
goto out;
 
do {
-   rc = do_coredump_read(i, ctx, buf, bufsz, );
-   if (rc > 0) {
-   if (!spufs_dump_write(file, buf, rc))
+   nread = do_coredump_read(i, ctx, buf, bufsz, );
+   if (nread > 0) {
+   rc = 

[PATCH 10/15] Add contents of npc file to SPU coredumps

[Michael Ellerman]

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/file.c |8 +++-
 1 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index d19220f..52f020a 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1606,12 +1606,17 @@ static void spufs_npc_set(void *data, u64 val)
spu_release(ctx);
 }
 
+static u64 __spufs_npc_get(struct spu_context *ctx)
+{
+   return ctx->ops->npc_read(ctx);
+}
+
 static u64 spufs_npc_get(void *data)
 {
struct spu_context *ctx = data;
u64 ret;
spu_acquire(ctx);
-   ret = ctx->ops->npc_read(ctx);
+   ret = __spufs_npc_get(ctx);
spu_release(ctx);
return ret;
 }
@@ -2242,6 +2247,7 @@ struct spufs_coredump_reader spufs_coredump_read[] = {
{ "proxydma_info", __spufs_proxydma_info_read,
   NULL, sizeof(struct spu_proxydma_info)},
{ "object-id", NULL, __spufs_object_id_get, 19 },
+   { "npc", NULL, __spufs_npc_get, 19 },
 };
 
 int spufs_coredump_num_notes = ARRAY_SIZE(spufs_coredump_read);
-- 
1.5.1.3.g7a33b

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

[PATCH 11/15] Combine spufs_coredump_calls with spufs_calls

[Michael Ellerman]

Because spufs might be built as a module, we can't have other parts of the
kernel calling directly into it, we need stub routines that check first if the
module is loaded.

Currently we have two structures which hold callbacks for these stubs, the
syscalls are in spufs_calls and the coredump calls are in spufs_coredump_calls.
In both cases the logic for registering/unregistering is essentially the same,
so we can simplify things by combining the two.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/Makefile |2 +-
 arch/powerpc/platforms/cell/spu_coredump.c   |   83 --
 arch/powerpc/platforms/cell/spu_syscalls.c   |   30 +
 arch/powerpc/platforms/cell/spufs/coredump.c |   10 +---
 arch/powerpc/platforms/cell/spufs/inode.c|6 --
 arch/powerpc/platforms/cell/spufs/spufs.h|4 +
 arch/powerpc/platforms/cell/spufs/syscalls.c |2 +
 include/asm-powerpc/spu.h|   12 +---
 8 files changed, 41 insertions(+), 108 deletions(-)

diff --git a/arch/powerpc/platforms/cell/Makefile 
b/arch/powerpc/platforms/cell/Makefile
index 40f78e9..61d12f1 100644
--- a/arch/powerpc/platforms/cell/Makefile
+++ b/arch/powerpc/platforms/cell/Makefile
@@ -19,7 +19,7 @@ spu-manage-$(CONFIG_PPC_CELLEB)   += spu_manage.o
 spu-manage-$(CONFIG_PPC_CELL_NATIVE)   += spu_manage.o
 
 obj-$(CONFIG_SPU_BASE) += spu_callbacks.o spu_base.o \
-  spu_coredump.o spu_syscalls.o \
+  spu_syscalls.o \
   $(spu-priv1-y) \
   $(spu-manage-y) \
   spufs/
diff --git a/arch/powerpc/platforms/cell/spu_coredump.c 
b/arch/powerpc/platforms/cell/spu_coredump.c
deleted file mode 100644
index 656a8c5..000
--- a/arch/powerpc/platforms/cell/spu_coredump.c
+++ /dev/null
@@ -1,83 +0,0 @@
-/*
- * SPU core dump code
- *
- * (C) Copyright 2006 IBM Corp.
- *
- * Author: Dwayne Grant McConnell <[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, or (at your option)
- * any later version.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
- */
-
-#include 
-#include 
-#include 
-
-#include 
-
-static struct spu_coredump_calls *spu_coredump_calls;
-static DEFINE_MUTEX(spu_coredump_mutex);
-
-int arch_notes_size(void)
-{
-   int ret;
-
-   mutex_lock(_coredump_mutex);
-
-   if (spu_coredump_calls && try_module_get(spu_coredump_calls->owner)) {
-   ret = spu_coredump_calls->arch_notes_size();
-   module_put(spu_coredump_calls->owner);
-   } else {
-   ret = 0;
-   }
-
-   mutex_unlock(_coredump_mutex);
-
-   return ret;
-}
-
-void arch_write_notes(struct file *file)
-{
-   mutex_lock(_coredump_mutex);
-   if (spu_coredump_calls && try_module_get(spu_coredump_calls->owner)) {
-   spu_coredump_calls->arch_write_notes(file);
-   module_put(spu_coredump_calls->owner);
-   }
-   mutex_unlock(_coredump_mutex);
-}
-
-int register_arch_coredump_calls(struct spu_coredump_calls *calls)
-{
-   int ret = 0;
-
-
-   mutex_lock(_coredump_mutex);
-   if (spu_coredump_calls)
-   ret = -EBUSY;
-   else
-   spu_coredump_calls = calls;
-   mutex_unlock(_coredump_mutex);
-   return ret;
-}
-EXPORT_SYMBOL_GPL(register_arch_coredump_calls);
-
-void unregister_arch_coredump_calls(struct spu_coredump_calls *calls)
-{
-   BUG_ON(spu_coredump_calls != calls);
-
-   mutex_lock(_coredump_mutex);
-   spu_coredump_calls = NULL;
-   mutex_unlock(_coredump_mutex);
-}
-EXPORT_SYMBOL_GPL(unregister_arch_coredump_calls);
diff --git a/arch/powerpc/platforms/cell/spu_syscalls.c 
b/arch/powerpc/platforms/cell/spu_syscalls.c
index 76815c5..cf00251 100644
--- a/arch/powerpc/platforms/cell/spu_syscalls.c
+++ b/arch/powerpc/platforms/cell/spu_syscalls.c
@@ -2,6 +2,7 @@
  * SPU file system -- system call stubs
  *
  * (C) Copyright IBM Deutschland Entwicklung GmbH 2005
+ * (C) Copyright 2006-2007, IBM Corporation
  *
  * Author: Arnd Bergmann <[EMAIL PROTECTED]>
  *
@@ -108,6 +109,35 @@ asmlinkage long sys_spu_run(int fd, __u32 __user *unpc, 
__u32 __user *ustatus)
return ret;
 }
 
+int arch_notes_size(void)
+{
+   struct spufs_calls 

[PATCH 08/15] Use spufs_coredump_num_notes everywhere, and don't NULL terminate

[Michael Ellerman]

The spufs_coredump_read array is NULL terminated, and we also store the size.
We only need one or the other, and storing the size should save a teensy bit
of memory vs NULL terminating, so do that.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |2 +-
 arch/powerpc/platforms/cell/spufs/file.c |3 +--
 2 files changed, 2 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 52d6219..8348d21 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -72,7 +72,7 @@ static int spufs_ctx_note_size(struct spu_context *ctx, int 
dfd)
char *name;
char fullname[80];
 
-   for (i = 0; spufs_coredump_read[i].name; i++) {
+   for (i = 0; i < spufs_coredump_num_notes; i++) {
name = spufs_coredump_read[i].name;
sz = spufs_coredump_read[i].size;
 
diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index 85edbec..220c7fe 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -2250,7 +2250,6 @@ struct spufs_coredump_reader spufs_coredump_read[] = {
{ "proxydma_info", __spufs_proxydma_info_read,
   NULL, sizeof(struct spu_proxydma_info)},
{ "object-id", NULL, __spufs_object_id_get, 19 },
-   { },
 };
-int spufs_coredump_num_notes = ARRAY_SIZE(spufs_coredump_read) - 1;
 
+int spufs_coredump_num_notes = ARRAY_SIZE(spufs_coredump_read);
-- 
1.5.1.3.g7a33b

-
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 09/15] Internal __spufs_get_foo() routines should take a spu_context *

[Michael Ellerman]

The SPUFS attribute get routines take a void * because the generic attribute
code doesn't know what sort of data it's passing around.

However our internal __spufs_get_foo() routines can take a spu_context *
directly, which saves plonking it in and out of a void * again.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/file.c  |   40 +++-
 arch/powerpc/platforms/cell/spufs/spufs.h |2 +-
 2 files changed, 17 insertions(+), 25 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index 220c7fe..d19220f 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -1085,9 +1085,8 @@ static void spufs_signal1_type_set(void *data, u64 val)
spu_release(ctx);
 }
 
-static u64 __spufs_signal1_type_get(void *data)
+static u64 __spufs_signal1_type_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
return ctx->ops->signal1_type_get(ctx);
 }
 
@@ -1097,7 +1096,7 @@ static u64 spufs_signal1_type_get(void *data)
u64 ret;
 
spu_acquire(ctx);
-   ret = __spufs_signal1_type_get(data);
+   ret = __spufs_signal1_type_get(ctx);
spu_release(ctx);
 
return ret;
@@ -1114,9 +1113,8 @@ static void spufs_signal2_type_set(void *data, u64 val)
spu_release(ctx);
 }
 
-static u64 __spufs_signal2_type_get(void *data)
+static u64 __spufs_signal2_type_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
return ctx->ops->signal2_type_get(ctx);
 }
 
@@ -1126,7 +1124,7 @@ static u64 spufs_signal2_type_get(void *data)
u64 ret;
 
spu_acquire(ctx);
-   ret = __spufs_signal2_type_get(data);
+   ret = __spufs_signal2_type_get(ctx);
spu_release(ctx);
 
return ret;
@@ -1629,9 +1627,8 @@ static void spufs_decr_set(void *data, u64 val)
spu_release_saved(ctx);
 }
 
-static u64 __spufs_decr_get(void *data)
+static u64 __spufs_decr_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
struct spu_lscsa *lscsa = ctx->csa.lscsa;
return lscsa->decr.slot[0];
 }
@@ -1641,7 +1638,7 @@ static u64 spufs_decr_get(void *data)
struct spu_context *ctx = data;
u64 ret;
spu_acquire_saved(ctx);
-   ret = __spufs_decr_get(data);
+   ret = __spufs_decr_get(ctx);
spu_release_saved(ctx);
return ret;
 }
@@ -1659,9 +1656,8 @@ static void spufs_decr_status_set(void *data, u64 val)
spu_release_saved(ctx);
 }
 
-static u64 __spufs_decr_status_get(void *data)
+static u64 __spufs_decr_status_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
if (ctx->csa.priv2.mfc_control_RW & MFC_CNTL_DECREMENTER_RUNNING)
return SPU_DECR_STATUS_RUNNING;
else
@@ -1673,7 +1669,7 @@ static u64 spufs_decr_status_get(void *data)
struct spu_context *ctx = data;
u64 ret;
spu_acquire_saved(ctx);
-   ret = __spufs_decr_status_get(data);
+   ret = __spufs_decr_status_get(ctx);
spu_release_saved(ctx);
return ret;
 }
@@ -1689,9 +1685,8 @@ static void spufs_event_mask_set(void *data, u64 val)
spu_release_saved(ctx);
 }
 
-static u64 __spufs_event_mask_get(void *data)
+static u64 __spufs_event_mask_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
struct spu_lscsa *lscsa = ctx->csa.lscsa;
return lscsa->event_mask.slot[0];
 }
@@ -1701,16 +1696,15 @@ static u64 spufs_event_mask_get(void *data)
struct spu_context *ctx = data;
u64 ret;
spu_acquire_saved(ctx);
-   ret = __spufs_event_mask_get(data);
+   ret = __spufs_event_mask_get(ctx);
spu_release_saved(ctx);
return ret;
 }
 DEFINE_SIMPLE_ATTRIBUTE(spufs_event_mask_ops, spufs_event_mask_get,
spufs_event_mask_set, "0x%llx\n")
 
-static u64 __spufs_event_status_get(void *data)
+static u64 __spufs_event_status_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
struct spu_state *state = >csa;
u64 stat;
stat = state->spu_chnlcnt_RW[0];
@@ -1725,7 +1719,7 @@ static u64 spufs_event_status_get(void *data)
u64 ret = 0;
 
spu_acquire_saved(ctx);
-   ret = __spufs_event_status_get(data);
+   ret = __spufs_event_status_get(ctx);
spu_release_saved(ctx);
return ret;
 }
@@ -1770,16 +1764,15 @@ static u64 spufs_id_get(void *data)
 }
 DEFINE_SIMPLE_ATTRIBUTE(spufs_id_ops, spufs_id_get, NULL, "0x%llx\n")
 
-static u64 __spufs_object_id_get(void *data)
+static u64 __spufs_object_id_get(struct spu_context *ctx)
 {
-   struct spu_context *ctx = data;
return ctx->object_id;
 }
 
 static u64 spufs_object_id_get(void *data)
 {
/* FIXME: Should there really be no locking here? */
-   return __spufs_object_id_get(data);
+   return 

[PATCH 06/15] Correctly calculate the size of the local-store to dump

[Michael Ellerman]

The routine to dump the local store, __spufs_mem_read(), does not take the
spu_lslr_RW value into account - so we shouldn't check it when we're
calculating the size either.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |   16 ++--
 1 files changed, 2 insertions(+), 14 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index c65b717..52d6219 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -66,11 +66,6 @@ static int spufs_dump_seek(struct file *file, loff_t off)
return 1;
 }
 
-static u64 ctx_ls_size(struct spu_context *ctx)
-{
-   return ctx->csa.priv2.spu_lslr_RW + 1;
-}
-
 static int spufs_ctx_note_size(struct spu_context *ctx, int dfd)
 {
int i, sz, total = 0;
@@ -85,10 +80,7 @@ static int spufs_ctx_note_size(struct spu_context *ctx, int 
dfd)
 
total += sizeof(struct elf_note);
total += roundup(strlen(fullname) + 1, 4);
-   if (!strcmp(name, "mem"))
-   total += roundup(ctx_ls_size(ctx), 4);
-   else
-   total += roundup(sz, 4);
+   total += roundup(sz, 4);
}
 
return total;
@@ -164,11 +156,7 @@ static void spufs_arch_write_note(struct spu_context *ctx, 
int i,
return;
 
name = spufs_coredump_read[i].name;
-
-   if (!strcmp(name, "mem"))
-   sz = ctx_ls_size(ctx);
-   else
-   sz = spufs_coredump_read[i].size;
+   sz = spufs_coredump_read[i].size;
 
sprintf(fullname, "SPU/%d/%s", dfd, name);
en.n_namesz = strlen(fullname) + 1;
-- 
1.5.1.3.g7a33b

-
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 07/15] Don't return -ENOSYS as extra notes size if spufs is not loaded

[Michael Ellerman]

Because the SPU coredump code might be built as part of a module (spufs),
we have a stub which is called by the coredump code, this routine then calls
into spufs if it's loaded.

Unfortunately the stub returns -ENOSYS if spufs is not loaded, which is
interpreted by the coredump code as an extra note size of -38 bytes. This
leads to a corrupt core dump.

If spufs is not loaded there will be no SPU ELF notes to write, and so the
extra notes size will be == 0.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spu_coredump.c |8 ++--
 1 files changed, 6 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spu_coredump.c 
b/arch/powerpc/platforms/cell/spu_coredump.c
index 4fd37ff..656a8c5 100644
--- a/arch/powerpc/platforms/cell/spu_coredump.c
+++ b/arch/powerpc/platforms/cell/spu_coredump.c
@@ -31,15 +31,19 @@ static DEFINE_MUTEX(spu_coredump_mutex);
 
 int arch_notes_size(void)
 {
-   long ret;
+   int ret;
 
-   ret = -ENOSYS;
mutex_lock(_coredump_mutex);
+
if (spu_coredump_calls && try_module_get(spu_coredump_calls->owner)) {
ret = spu_coredump_calls->arch_notes_size();
module_put(spu_coredump_calls->owner);
+   } else {
+   ret = 0;
}
+
mutex_unlock(_coredump_mutex);
+
return ret;
 }
 
-- 
1.5.1.3.g7a33b

-
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 05/15] Write some SPU coredump values as ASCII

[Michael Ellerman]

Unfortunately GDB expects some of the SPU coredump values to be identical
in format to what is found in spufs. This means we need to dump some of
the values as ASCII strings, not the actual values.

Because we don't know what the values will be, we always print the values
with the format "0x%.16lx", that way we know the result will be 19 bytes.

do_coredump_read() doesn't take a __user buffer, so remove the annotation,
and because we know that it's safe to just snprintf() directly to it.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |8 +---
 arch/powerpc/platforms/cell/spufs/file.c |   14 +++---
 2 files changed, 12 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 21283f6..c65b717 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -31,7 +31,7 @@
 
 #include "spufs.h"
 
-static ssize_t do_coredump_read(int num, struct spu_context *ctx, void __user 
*buffer,
+static ssize_t do_coredump_read(int num, struct spu_context *ctx, void *buffer,
size_t size, loff_t *off)
 {
u64 data;
@@ -41,8 +41,10 @@ static ssize_t do_coredump_read(int num, struct spu_context 
*ctx, void __user *b
return spufs_coredump_read[num].read(ctx, buffer, size, off);
 
data = spufs_coredump_read[num].get(ctx);
-   ret = copy_to_user(buffer, , 8);
-   return ret ? -EFAULT : 8;
+   ret = snprintf(buffer, size, "0x%.16lx", data);
+   if (ret >= size)
+   return size;
+   return ++ret; /* count trailing NULL */
 }
 
 /*
diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index 18ddde8..85edbec 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -2233,16 +2233,16 @@ struct tree_descr spufs_dir_nosched_contents[] = {
 struct spufs_coredump_reader spufs_coredump_read[] = {
{ "regs", __spufs_regs_read, NULL, sizeof(struct spu_reg128[128])},
{ "fpcr", __spufs_fpcr_read, NULL, sizeof(struct spu_reg128) },
-   { "lslr", NULL, __spufs_lslr_get, 11 },
-   { "decr", NULL, __spufs_decr_get, 11 },
-   { "decr_status", NULL, __spufs_decr_status_get, 11 },
+   { "lslr", NULL, __spufs_lslr_get, 19 },
+   { "decr", NULL, __spufs_decr_get, 19 },
+   { "decr_status", NULL, __spufs_decr_status_get, 19 },
{ "mem", __spufs_mem_read, NULL, LS_SIZE, },
{ "signal1", __spufs_signal1_read, NULL, sizeof(u32) },
-   { "signal1_type", NULL, __spufs_signal1_type_get, 2 },
+   { "signal1_type", NULL, __spufs_signal1_type_get, 19 },
{ "signal2", __spufs_signal2_read, NULL, sizeof(u32) },
-   { "signal2_type", NULL, __spufs_signal2_type_get, 2 },
-   { "event_mask", NULL, __spufs_event_mask_get, 8 },
-   { "event_status", NULL, __spufs_event_status_get, 8 },
+   { "signal2_type", NULL, __spufs_signal2_type_get, 19 },
+   { "event_mask", NULL, __spufs_event_mask_get, 19 },
+   { "event_status", NULL, __spufs_event_status_get, 19 },
{ "mbox_info", __spufs_mbox_info_read, NULL, sizeof(u32) },
{ "ibox_info", __spufs_ibox_info_read, NULL, sizeof(u32) },
{ "wbox_info", __spufs_wbox_info_read, NULL, 4 * sizeof(u32)},
-- 
1.5.1.3.g7a33b

-
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 04/15] Use computed sizes/#defines rather than literals in SPU coredump code

[Michael Ellerman]

The spufs_coredump_reader array contains the size of the data that will be
returned by the read routine. Currently these are specified as literals, and
though some are obvious, sizeof(u32) == 4, others are not, 69 * 8 ==  ???

Instead, use sizeof() whatever type is returned by each routine, or in
the case of spufs_mem_read() the #define LS_SIZE.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/file.c |   21 +++--
 1 files changed, 11 insertions(+), 10 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/file.c 
b/arch/powerpc/platforms/cell/spufs/file.c
index a4a8770..18ddde8 100644
--- a/arch/powerpc/platforms/cell/spufs/file.c
+++ b/arch/powerpc/platforms/cell/spufs/file.c
@@ -2231,23 +2231,24 @@ struct tree_descr spufs_dir_nosched_contents[] = {
 };
 
 struct spufs_coredump_reader spufs_coredump_read[] = {
-   { "regs", __spufs_regs_read, NULL, 128 * 16 },
-   { "fpcr", __spufs_fpcr_read, NULL, 16 },
+   { "regs", __spufs_regs_read, NULL, sizeof(struct spu_reg128[128])},
+   { "fpcr", __spufs_fpcr_read, NULL, sizeof(struct spu_reg128) },
{ "lslr", NULL, __spufs_lslr_get, 11 },
{ "decr", NULL, __spufs_decr_get, 11 },
{ "decr_status", NULL, __spufs_decr_status_get, 11 },
-   { "mem", __spufs_mem_read, NULL, 256 * 1024, },
-   { "signal1", __spufs_signal1_read, NULL, 4 },
+   { "mem", __spufs_mem_read, NULL, LS_SIZE, },
+   { "signal1", __spufs_signal1_read, NULL, sizeof(u32) },
{ "signal1_type", NULL, __spufs_signal1_type_get, 2 },
-   { "signal2", __spufs_signal2_read, NULL, 4 },
+   { "signal2", __spufs_signal2_read, NULL, sizeof(u32) },
{ "signal2_type", NULL, __spufs_signal2_type_get, 2 },
{ "event_mask", NULL, __spufs_event_mask_get, 8 },
{ "event_status", NULL, __spufs_event_status_get, 8 },
-   { "mbox_info", __spufs_mbox_info_read, NULL, 4 },
-   { "ibox_info", __spufs_ibox_info_read, NULL, 4 },
-   { "wbox_info", __spufs_wbox_info_read, NULL, 16 },
-   { "dma_info", __spufs_dma_info_read, NULL, 69 * 8 },
-   { "proxydma_info", __spufs_proxydma_info_read, NULL, 35 * 8 },
+   { "mbox_info", __spufs_mbox_info_read, NULL, sizeof(u32) },
+   { "ibox_info", __spufs_ibox_info_read, NULL, sizeof(u32) },
+   { "wbox_info", __spufs_wbox_info_read, NULL, 4 * sizeof(u32)},
+   { "dma_info", __spufs_dma_info_read, NULL, sizeof(struct spu_dma_info)},
+   { "proxydma_info", __spufs_proxydma_info_read,
+  NULL, sizeof(struct spu_proxydma_info)},
{ "object-id", NULL, __spufs_object_id_get, 19 },
{ },
 };
-- 
1.5.1.3.g7a33b

-
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 01/15] Extract the file descriptor search logic in SPU coredump code

[Michael Ellerman]

Extract the logic for searching through the file descriptors for spu contexts
into a separate routine, coredump_next_context(), so we can use it elsewhere
in future. In the process we flatten the for loop, and move the NOSCHED test
into coredump_next_context().

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |   58 +-
 1 files changed, 38 insertions(+), 20 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 5e31799..99f8e0b 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -109,16 +109,11 @@ static int spufs_ctx_note_size(struct spufs_ctx_info 
*ctx_info)
return total;
 }
 
-static int spufs_add_one_context(struct file *file, int dfd)
+static int spufs_add_one_context(struct spu_context *ctx, int dfd)
 {
-   struct spu_context *ctx;
struct spufs_ctx_info *ctx_info;
int size;
 
-   ctx = SPUFS_I(file->f_dentry->d_inode)->i_ctx;
-   if (ctx->flags & SPU_CREATE_NOSCHED)
-   return 0;
-
ctx_info = kzalloc(sizeof(*ctx_info), GFP_KERNEL);
if (unlikely(!ctx_info))
return -ENOMEM;
@@ -142,22 +137,45 @@ static int spufs_add_one_context(struct file *file, int 
dfd)
  * internal functionality to dump them without needing to actually
  * open the files.
  */
-static int spufs_arch_notes_size(void)
+static struct spu_context *coredump_next_context(int *fd)
 {
struct fdtable *fdt = files_fdtable(current->files);
-   int size = 0, fd;
-
-   for (fd = 0; fd < fdt->max_fds; fd++) {
-   if (FD_ISSET(fd, fdt->open_fds)) {
-   struct file *file = fcheck(fd);
-
-   if (file && file->f_op == _context_fops) {
-   int rval = spufs_add_one_context(file, fd);
-   if (rval < 0)
-   break;
-   size += rval;
-   }
-   }
+   struct file *file;
+   struct spu_context *ctx = NULL;
+
+   for (; *fd < fdt->max_fds; (*fd)++) {
+   if (!FD_ISSET(*fd, fdt->open_fds))
+   continue;
+
+   file = fcheck(*fd);
+
+   if (!file || file->f_op != _context_fops)
+   continue;
+
+   ctx = SPUFS_I(file->f_dentry->d_inode)->i_ctx;
+   if (ctx->flags & SPU_CREATE_NOSCHED)
+   continue;
+
+   /* start searching the next fd next time we're called */
+   (*fd)++;
+   break;
+   }
+
+   return ctx;
+}
+
+static int spufs_arch_notes_size(void)
+{
+   struct spu_context *ctx;
+   int size = 0, rc, fd;
+
+   fd = 0;
+   while ((ctx = coredump_next_context()) != NULL) {
+   rc = spufs_add_one_context(ctx, fd);
+   if (rc < 0)
+   break;
+
+   size += rc;
}
 
return size;
-- 
1.5.1.3.g7a33b

-
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 02/15] Remove ctx_info and ctx_info_list

[Michael Ellerman]

Remove the ctx_info struct entirely, and also the ctx_info_list. This fixes
a race where two processes can clobber each other's ctx_info structs.

Instead of using the list, we just repeat the search through the file
descriptor table.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |   79 ++---
 1 files changed, 19 insertions(+), 60 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 99f8e0b..6663669 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -31,15 +31,6 @@
 
 #include "spufs.h"
 
-struct spufs_ctx_info {
-   struct list_head list;
-   int dfd;
-   int memsize; /* in bytes */
-   struct spu_context *ctx;
-};
-
-static LIST_HEAD(ctx_info_list);
-
 static ssize_t do_coredump_read(int num, struct spu_context *ctx, void __user 
*buffer,
size_t size, loff_t *off)
 {
@@ -73,25 +64,17 @@ static int spufs_dump_seek(struct file *file, loff_t off)
return 1;
 }
 
-static void spufs_fill_memsize(struct spufs_ctx_info *ctx_info)
+static u64 ctx_ls_size(struct spu_context *ctx)
 {
-   struct spu_context *ctx;
-   unsigned long long lslr;
-
-   ctx = ctx_info->ctx;
-   lslr = ctx->csa.priv2.spu_lslr_RW;
-   ctx_info->memsize = lslr + 1;
+   return ctx->csa.priv2.spu_lslr_RW + 1;
 }
 
-static int spufs_ctx_note_size(struct spufs_ctx_info *ctx_info)
+static int spufs_ctx_note_size(struct spu_context *ctx, int dfd)
 {
-   int dfd, memsize, i, sz, total = 0;
+   int i, sz, total = 0;
char *name;
char fullname[80];
 
-   dfd = ctx_info->dfd;
-   memsize = ctx_info->memsize;
-
for (i = 0; spufs_coredump_read[i].name; i++) {
name = spufs_coredump_read[i].name;
sz = spufs_coredump_read[i].size;
@@ -101,7 +84,7 @@ static int spufs_ctx_note_size(struct spufs_ctx_info 
*ctx_info)
total += sizeof(struct elf_note);
total += roundup(strlen(fullname) + 1, 4);
if (!strcmp(name, "mem"))
-   total += roundup(memsize, 4);
+   total += roundup(ctx_ls_size(ctx), 4);
else
total += roundup(sz, 4);
}
@@ -109,25 +92,6 @@ static int spufs_ctx_note_size(struct spufs_ctx_info 
*ctx_info)
return total;
 }
 
-static int spufs_add_one_context(struct spu_context *ctx, int dfd)
-{
-   struct spufs_ctx_info *ctx_info;
-   int size;
-
-   ctx_info = kzalloc(sizeof(*ctx_info), GFP_KERNEL);
-   if (unlikely(!ctx_info))
-   return -ENOMEM;
-
-   ctx_info->dfd = dfd;
-   ctx_info->ctx = ctx;
-
-   spufs_fill_memsize(ctx_info);
-
-   size = spufs_ctx_note_size(ctx_info);
-   list_add(_info->list, _info_list);
-   return size;
-}
-
 /*
  * The additional architecture-specific notes for Cell are various
  * context files in the spu context.
@@ -171,7 +135,7 @@ static int spufs_arch_notes_size(void)
 
fd = 0;
while ((ctx = coredump_next_context()) != NULL) {
-   rc = spufs_add_one_context(ctx, fd);
+   rc = spufs_ctx_note_size(ctx, fd);
if (rc < 0)
break;
 
@@ -181,12 +145,11 @@ static int spufs_arch_notes_size(void)
return size;
 }
 
-static void spufs_arch_write_note(struct spufs_ctx_info *ctx_info, int i,
-   struct file *file)
+static void spufs_arch_write_note(struct spu_context *ctx, int i,
+   struct file *file, int dfd)
 {
-   struct spu_context *ctx;
loff_t pos = 0;
-   int sz, dfd, rc, total = 0;
+   int sz, rc, total = 0;
const int bufsz = PAGE_SIZE;
char *name;
char fullname[80], *buf;
@@ -196,18 +159,13 @@ static void spufs_arch_write_note(struct spufs_ctx_info 
*ctx_info, int i,
if (!buf)
return;
 
-   dfd = ctx_info->dfd;
name = spufs_coredump_read[i].name;
 
if (!strcmp(name, "mem"))
-   sz = ctx_info->memsize;
+   sz = ctx_ls_size(ctx);
else
sz = spufs_coredump_read[i].size;
 
-   ctx = ctx_info->ctx;
-   if (!ctx)
-   goto out;
-
sprintf(fullname, "SPU/%d/%s", dfd, name);
en.n_namesz = strlen(fullname) + 1;
en.n_descsz = sz;
@@ -237,16 +195,17 @@ out:
 
 static void spufs_arch_write_notes(struct file *file)
 {
-   int j;
-   struct spufs_ctx_info *ctx_info, *next;
+   struct spu_context *ctx;
+   int fd, j;
+
+   fd = 0;
+   while ((ctx = coredump_next_context()) != NULL) {
+   spu_acquire_saved(ctx);
 
-   list_for_each_entry_safe(ctx_info, next, _info_list, list) {
-   spu_acquire_saved(ctx_info->ctx);

[PATCH 03/15] Call spu_acquire_saved() before calculating the SPU note sizes

[Michael Ellerman]

It makes sense to stop the SPU processes as soon as possible. Also if we
dont acquire_saved() I think there's a possibility that the value in
csa.priv2.spu_lslr_RW won't be accurate.

Signed-off-by: Michael Ellerman <[EMAIL PROTECTED]>
---
 arch/powerpc/platforms/cell/spufs/coredump.c |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/platforms/cell/spufs/coredump.c 
b/arch/powerpc/platforms/cell/spufs/coredump.c
index 6663669..21283f6 100644
--- a/arch/powerpc/platforms/cell/spufs/coredump.c
+++ b/arch/powerpc/platforms/cell/spufs/coredump.c
@@ -135,7 +135,9 @@ static int spufs_arch_notes_size(void)
 
fd = 0;
while ((ctx = coredump_next_context()) != NULL) {
+   spu_acquire_saved(ctx);
rc = spufs_ctx_note_size(ctx, fd);
+   spu_release_saved(ctx);
if (rc < 0)
break;
 
-- 
1.5.1.3.g7a33b

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

[PATCH 1/2] dgrs: remove from build, config, and maintainer list

[Nathanael Nerode]

From: Nathanael Nerode

Stop building and configuring driver for Digi RightSwitch, which was 
never actually sold to anyone, and remove it from MAINTAINERS.

In response to an investigation into the firmware of the "Digi Rightswitch" 
driver, Andres Salomon discovered:
>
> Dear Andres:
>
> After further research, we found that this product was killed in place
> and never reached the market.  We would like to request that this not be
> included.  

Since the product never reached market, clearly nobody is using this orphaned 
driver.

Signed-off-by: Nathanael Nerode <[EMAIL PROTECTED]>

---

This is patch 1 of 2 for removing the "Digi Rightswitch" (dgrs).

Patch 2 would be the patch to remove the actual files.  However, that would
be around 400K, which doesn't seem suitable for a mailing list -- and this 
length seems quite unnecessary, given that it would consist solely of full-file 
deletions.  I'm not quite sure what to do about this.  Please advise.

These are the files to be deleted:
./Documentation/networking/dgrs.txt
./drivers/net/dgrs.c
./drivers/net/dgrs.h
./drivers/net/dgrs_asstruct.h
./drivers/net/dgrs_bcomm.h
./drivers/net/dgrs_es4h.h
./drivers/net/dgrs_ether.h
./drivers/net/dgrs_firmware.c (this is the very large one)
./drivers/net/dgrs_i82596.h
./drivers/net/dgrs_plx9060.h

diff -upr linux-2.6.22.6/drivers/net/Kconfig 
linux-2.6-deleted/drivers/net/Kconfig
--- linux-2.6.22.6/drivers/net/Kconfig  2007-08-31 02:21:01.0 -0400
+++ linux-2.6-deleted/drivers/net/Kconfig   2007-09-12 03:28:11.0 
-0400
@@ -1447,21 +1447,6 @@ config TC35815
depends on NET_PCI && PCI && MIPS
select MII
 
-config DGRS
-   tristate "Digi Intl. RightSwitch SE-X support"
-   depends on NET_PCI && (PCI || EISA)
-   ---help---
- This is support for the Digi International RightSwitch series of
- PCI/EISA Ethernet switch cards. These include the SE-4 and the SE-6
- models.  If you have a network card of this type, say Y and read the
- Ethernet-HOWTO, available from
- .  More specific
- information is contained in .
-
- To compile this driver as a module, choose M here and read
- .  The module
- will be called dgrs.
-
 config EEPRO100
tristate "EtherExpressPro/100 support (eepro100, original Becker 
driver)"
depends on NET_PCI && PCI
diff -upr linux-2.6.22.6/drivers/net/Makefile 
linux-2.6-deleted/drivers/net/Makefile
--- linux-2.6.22.6/drivers/net/Makefile 2007-08-31 02:21:01.0 -0400
+++ linux-2.6-deleted/drivers/net/Makefile  2007-09-12 03:28:31.0 
-0400
@@ -38,7 +38,6 @@ obj-$(CONFIG_CASSINI) += cassini.o
 obj-$(CONFIG_MACE) += mace.o
 obj-$(CONFIG_BMAC) += bmac.o
 
-obj-$(CONFIG_DGRS) += dgrs.o
 obj-$(CONFIG_VORTEX) += 3c59x.o
 obj-$(CONFIG_TYPHOON) += typhoon.o
 obj-$(CONFIG_NE2K_PCI) += ne2k-pci.o 8390.o
diff -upr linux-2.6.22.6/MAINTAINERS linux-2.6-deleted/MAINTAINERS
--- linux-2.6.22.6/MAINTAINERS  2007-08-31 02:21:01.0 -0400
+++ linux-2.6-deleted/MAINTAINERS   2007-09-12 03:27:26.0 -0400
@@ -1234,12 +1234,6 @@ L:   [EMAIL PROTECTED]
 W: http://www.digi.com
 S: Orphaned
 
-DIGI RIGHTSWITCH NETWORK DRIVER
-P: Rick Richardson
-L: [EMAIL PROTECTED]
-W: http://www.digi.com
-S: Orphaned
-
 DIRECTORY NOTIFICATION
 P: Stephen Rothwell
 M: [EMAIL PROTECTED]

-- 
Nathanael Nerode  <[EMAIL PROTECTED]>

[Insert famous quote here]
-
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: [-mm patch] kernel/kexec.c: make code static

[Ken'ichi Ohmichi]

Hi Adrian, Maneesh,

Maneesh Soni wrote:
> On Mon, Sep 10, 2007 at 02:20:40PM +0200, Adrian Bunk wrote:
>> On Mon, Sep 10, 2007 at 11:55:49AM +0900, Ken'ichi Ohmichi wrote:
>>> Hi Adrian,
>>>
>>>
>>> 2007/09/09 22:25:16 +0200, Adrian Bunk <[EMAIL PROTECTED]> wrote:
 On Fri, Aug 31, 2007 at 09:58:22PM -0700, Andrew Morton wrote:
> ...
> Changes since 2.6.23-rc3-mm1:
> ...
> +add-vmcoreinfo.patch
> ...
>  misc
> ...
 This patch makes the following needlessly global code static:
 - vmcoreinfo_data[]
 - vmcoreinfo_size
 - vmcoreinfo_append_str()
>>> The kernel compiling fails with your patch because architecture-specific
>>> function should access the above data/function:
>>>
>>> # make
>>> [snip]
>>> arch/ia64/kernel/machine_kexec.c: In function 'arch_crash_save_vmcoreinfo':
>>> arch/ia64/kernel/machine_kexec.c:134: error: implicit declaration of 
function 'SYMBOL'
>>> arch/ia64/kernel/machine_kexec.c:135: error: implicit declaration of 
function 'LENGTH'
>>> arch/ia64/kernel/machine_kexec.c:139: error: implicit declaration of 
function 'SIZE'
>>> arch/ia64/kernel/machine_kexec.c:139: error: 'node_memblk_s' undeclared 
(first use in this function)
>>> arch/ia64/kernel/machine_kexec.c:139: error: (Each undeclared identifier is 
reported only once
>>> arch/ia64/kernel/machine_kexec.c:139: error: for each function it appears 
in.)
>>> arch/ia64/kernel/machine_kexec.c:140: error: implicit declaration of 
function 'OFFSET'
>>> arch/ia64/kernel/machine_kexec.c:140: error: 'start_paddr' undeclared 
(first use in this function)
>>> arch/ia64/kernel/machine_kexec.c:141: error: 'size' undeclared (first use 
in this function)
>>> arch/ia64/kernel/machine_kexec.c:144: error: implicit declaration of 
function 'CONFIG'
>>> arch/ia64/kernel/machine_kexec.c:144: error: 'PGTABLE_3' undeclared (first 
use in this function)
>>> make[1]: *** [arch/ia64/kernel/machine_kexec.o] Error 1
>>> make: *** [arch/ia64/kernel] Error 2
>>> #
>> Thanks, I missed this.
>>
>> That's 80% my fault and 20% the fault of the usage of generic names 
SYMBOL/SIZE/OFFSET/LENGTH/CONFIG making it impossible to grep for them (and namespace 
conflicts quite possible).

I understand your motivation. It is better to change these names as you said.


>> Can we get these #define's properly prefixed (e.g. KEXEC_SYMBOL etc.) so 
that other people will not repeat my mistake and namespace conflicts will be 
prevented?
>>
>
> CRASH_DUMP_ or VMCORE_ should be a better prefix as the dump filtering
> functionality not directly related to kexec.

I think that VMCOREINFO_ is a better prefix, because these macros are for
writing the information to the vmcoreinfo data.


Thanks
Ken'ichi Ohmichi
-
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] pci: fix unterminated pci_device_id lists

[Kees Cook]

This patch against 2.6.23-rc6 fixes a couple drivers that do not
correctly terminate their pci_device_id lists.  This results in garbage
being spewed into modules.pcimap when the module happens to not have
28 NULL bytes following the table, and/or the last PCI ID is actually
truncated from the table when calculating the modules.alias PCI aliases,
cause those unfortunate device IDs to not auto-load.

Signed-off-by: Kees Cook <[EMAIL PROTECTED]>
---
For example, cafe_nand...

drivers/mtd/nand/cafe_nand.c:
static struct pci_device_id cafe_nand_tbl[] = {
{ 0x11ab, 0x4100, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_MEMORY_FLASH << 8, 
0x0 }
};

# should have 1 PCI alias, but we have none
$ modinfo cafe_nand | grep alias | wc -l
0

# should have 1 PCI map, but we have lots of trash
$ grep cafe_nand /lib/modules/$(uname -r)/modules.pcimap
modules.pcimap:cafe_nand0x11ab 0x4100 0x 0x 
0x00050100 0x0000 0x0
modules.pcimap:cafe_nand0x696d6974 0x676e 0x 0x 
0x 0x 0x0
modules.pcimap:cafe_nand0x0003 0x 0x 0x 
0x 0x 0x0
modules.pcimap:cafe_nand0x0004 0x 0x 0x 
0x63656863 0x6363656b 0x0
modules.pcimap:cafe_nand0x65640067 0x00677562 0x70696b73 0x00746262 
0x64657375 0x4200616d 0x0
modules.pcimap:cafe_nand0x00bc 0x 0x 0x 
0x 0x 0x0

It may make sense to patch module-init-tools to correctly yell about
mismatches, as it has all the details when examining the ELF.

Note also, then p54 driver (in p54/prism54pci.c, not in mainline yet) suffers
from the same problem.


 linux-2.6.23-rc6/drivers/char/ipmi/ipmi_si_intf.c |3 ++-
 linux-2.6.23-rc6/drivers/mtd/nand/cafe_nand.c |3 ++-
 2 files changed, 4 insertions(+), 2 deletions(-)
---
diff -uNrp linux-2.6.23-rc6~/drivers/char/ipmi/ipmi_si_intf.c 
linux-2.6.23-rc6/drivers/char/ipmi/ipmi_si_intf.c
--- linux-2.6.23-rc6~/drivers/char/ipmi/ipmi_si_intf.c  2007-09-11 
23:17:13.0 -0700
+++ linux-2.6.23-rc6/drivers/char/ipmi/ipmi_si_intf.c   2007-09-11 
23:21:51.0 -0700
@@ -2215,7 +2215,8 @@ static int ipmi_pci_resume(struct pci_de
 
 static struct pci_device_id ipmi_pci_devices[] = {
{ PCI_DEVICE(PCI_HP_VENDOR_ID, PCI_MMC_DEVICE_ID) },
-   { PCI_DEVICE_CLASS(PCI_ERMC_CLASSCODE, PCI_ERMC_CLASSCODE_MASK) }
+   { PCI_DEVICE_CLASS(PCI_ERMC_CLASSCODE, PCI_ERMC_CLASSCODE_MASK) },
+   { 0, }
 };
 MODULE_DEVICE_TABLE(pci, ipmi_pci_devices);
 
diff -uNrp linux-2.6.23-rc6~/drivers/mtd/nand/cafe_nand.c 
linux-2.6.23-rc6/drivers/mtd/nand/cafe_nand.c
--- linux-2.6.23-rc6~/drivers/mtd/nand/cafe_nand.c  2007-07-08 
16:32:17.0 -0700
+++ linux-2.6.23-rc6/drivers/mtd/nand/cafe_nand.c   2007-09-11 
23:22:11.0 -0700
@@ -816,7 +816,8 @@ static void __devexit cafe_nand_remove(s
 }
 
 static struct pci_device_id cafe_nand_tbl[] = {
-   { 0x11ab, 0x4100, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_MEMORY_FLASH << 8, 
0x0 }
+   { 0x11ab, 0x4100, PCI_ANY_ID, PCI_ANY_ID, PCI_CLASS_MEMORY_FLASH << 8, 
0x0 },
+   { 0, }
 };
 
 MODULE_DEVICE_TABLE(pci, cafe_nand_tbl);




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

Re: Kernel Panic on 2.6.23-rc5 (solved)

[Daniel Exner]

Hi!

Michal Piotrowski:
> On 06/09/07, Daniel Exner <[EMAIL PROTECTED]> wrote:
> > I'm not really sure if this is a regression or if I simply hit a hardware
> > problem.
> > After some time of work (mostly hours sometimes minutes) my system will
> > freeze including Blinking LED's and unresponsiveness on SysRQ, but I
> > finally got this using netconsole:
> >
> > CPU 0: Machine Check Exception: 0004
> > Bank 4: b2070f0f
> > Kernel panic - not syncing: CPU context corrupt
> It is a hardware problem.
You where right. I switched the power suply (first guess of hardware guy ;)
The Box is now up 2 days 9hrs and no kp so far :)

I really should use sensord to show undervoltages in syslog..

> You may want to use mcelog ftp://ftp.x86-64.org/pub/linux/tools/mcelog/
This is a nice tool, but why is it only available for x86_64 ?
The MCE reporting facility is in place in x86, too.

Anyway I only send this mail to say: Not Kernel's fault. 

-- 
Greetings
Daniel Exner
-
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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Nick Piggin]

On Wednesday 12 September 2007 11:49, David Chinner wrote:
> On Tue, Sep 11, 2007 at 04:00:17PM +1000, Nick Piggin wrote:
> > > > OTOH, I'm not sure how much buy-in there was from the filesystems
> > > > guys. Particularly Christoph H and XFS (which is strange because they
> > > > already do vmapping in places).
> > >
> > > I think they use vmapping because they have to, not because they want
> > > to. They might be a lot happier with fsblock if it used contiguous
> > > pages for large blocks whenever possible - I don't know for sure. The
> > > metadata accessors they might be unhappy with because it's inconvenient
> > > but as Christoph Hellwig pointed out at VM/FS, the filesystems who
> > > really care will convert.
> >
> > Sure, they would rather not to. But there are also a lot of ways you can
> > improve vmap more than what XFS does (or probably what darwin does)
> > (more persistence for cached objects, and batched invalidates for
> > example).
>
> XFS already has persistence across the object life time (which can be many
> tens of seconds for a frequently used buffer)

But you don't do a very good job. When you go above 64 cached mappings,
you purge _all_ of them. fsblock's vmap cache can have a much higher number
(if you want), and purging can just unmap a batch which is decided by a simple
LRU (thus important metadata gets saved).


> and it also does batched 
> unmapping of objects as well.

It also could do a lot better at unmapping. Currently you're just calling
vunmap a lot of times in sequence. That still requires global IPIs and TLB
flushing every time.

This simple patch should easily be able to reduce that number by 2 or 3
orders of magnitude (maybe more on big systems).
http://www.mail-archive.com/[EMAIL PROTECTED]/msg03956.html

vmap area locking and data structures could also be made a lot better
quite easily, I suspect.


> > There are also a lot of trivial things you can do to make a lot of those
> > accesses not require vmaps (and less trivial things, but even such things
> > as binary searches over multiple pages should be quite possible with a
> > bit of logic).
>
> Yes, we already do the many of these things (via xfs_buf_offset()), but
> that is not good enough for something like a memcpy that spans multiple
> pages in a large block (think btree block compaction, splits and
> recombines).

fsblock_memcpy(fsblock *src, int soff, fsblock *dst, int doff, int size); ?


> IOWs, we already play these vmap harm-minimisation games in the places
> where we can, but still the overhead is high and something we'd prefer
> to be able to avoid.

I don't think you've looked nearly far enough with all this low hanging
fruit.

I just gave 4 things which combined might easily reduce xfs vmap overhead
by several orders of magnitude, all without changing much code at all.
-
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: Socket-related problem in x86_64 Kernel (2.6.16.53-0.8-smp)?

[Ulrich Windl]

On 11 Sep 2007 at 17:04, Al Viro wrote:

> On Tue, Sep 11, 2007 at 05:54:38PM +0200, Ulrich Windl wrote:
> 
> > If not, any clues on debugging/tracing? There's a 
> > /usr/src/linux/Documentation/oops-tracing.txt, but no "segfault-tracing".
> 
> That would be because it has fsck-all to do with the kernel.  Get the
> coredump, then use gdb to deal with it.

Ok, but why is the message there at all? I think in Windows/XP the offending 
code 
and the registers are shown in such occasions. I'd say either drop the message, 
or 
improve it. It's also difficult to find the code after the program is gone due 
to 
mapping of shared libraries. I managed to get a core dump of the application 
however, and I did modify some code. I'll report once I have results.

Maybe it's "mea culpa" for my program, but powersaved and slapd are still to be 
examined.

Regards,
Ulrich

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

Re: [announce] CFS-devel, performance improvements

[Mike Galbraith]

On Tue, 2007-09-11 at 22:04 +0200, Ingo Molnar wrote:
> fresh back from the Kernel Summit, Peter Zijlstra and me are pleased to 
> announce the latest iteration of the CFS scheduler development tree. Our 
> main focus has been on simplifications and performance - and as part of 
> that we've also picked up some ideas from Roman Zippel's 'Really Fair 
> Scheduler' patch as well and integrated them into CFS. We'd like to ask 
> people go give these patches a good workout, especially with an eye on 
> any interactivity regressions.

Initial test-drive looks good here, but I do see a regression.  First
the good news.

fairtest2 is perfect, more perfect than ever seen before in fact.  Mixed
interval sleepers/hog looks fine as well (can't say perfect due to
startup differences with the various proggies, but cpu% looks perfect).
Amarok song switch time under hefty kbuild load is fine as well.  I
haven't done heavy multimedia testing yet, but will give it a more
thorough workout later (errands).

The regression:  I see some GUI lurch, easily reproducible by running a
make -j5 and moving the mouse in a circle... perceptible (100ms or so)
lurches not present in rc5. 

-Mike

-
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: [BUGFIX] x86_64: NX bit handling in change_page_attr

[Huang, Ying]

On Tue, 2007-09-11 at 20:23 -0700, Andrew Morton wrote:
> On Fri, 17 Aug 2007 13:28:38 +0800 "Huang, Ying" <[EMAIL PROTECTED]> wrote:
> 
> > This patch fixes a bug of change_page_attr/change_page_attr_addr on
> > Intel x86_64 CPU. After changing page attribute to be executable with
> > these functions, the page remains un-executable on Intel x86_64
> > CPU. Because on Intel x86_64 CPU, only if the "NX" bits of all four
> > level page tables are cleared, the corresponding page is executable
> > (refer to section 4.13.2 of Intel 64 and IA-32 Architectures Software
> > Developer's Manual). So, the bug is fixed through clearing the "NX"
> > bit of PMD when splitting the huge PMD.
> > 
> > Signed-off-by: Huang Ying <[EMAIL PROTECTED]>
> > 
> > ---
> > 
> > Index: linux-2.6.23-rc2-mm2/arch/x86_64/mm/pageattr.c
> > ===
> > --- linux-2.6.23-rc2-mm2.orig/arch/x86_64/mm/pageattr.c 2007-08-17 
> > 12:50:25.0 +0800
> > +++ linux-2.6.23-rc2-mm2/arch/x86_64/mm/pageattr.c  2007-08-17 
> > 12:50:48.0 +0800
> > @@ -147,6 +147,7 @@
> > split = split_large_page(address, prot, ref_prot2);
> > if (!split)
> > return -ENOMEM;
> > +   pgprot_val(ref_prot2) &= ~_PAGE_NX;
> > set_pte(kpte, mk_pte(split, ref_prot2));
> > kpte_page = split;
> > }
> 
> What happened with this?  Still valid?

I am waiting for reviewing or merging. And I think it is still valid.

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

Re: Problem charging blackberry 8700c with berry_charge (2.6.22.6)

[Matt LaPlante]

On Mon, 10 Sep 2007 23:35:02 -0700
Greg KH <[EMAIL PROTECTED]> wrote:

> 
> > Sep  9 13:49:01 prizm kernel: [  584.407498] drivers/usb/core/inode.c: 
> > creating file '003'
> > Sep  9 13:49:01 prizm kernel: [  584.407509] hub 5-0:1.0: state 7 ports 8 
> > chg  evt 0004
> > Sep  9 13:49:01 prizm kernel: [  584.407520] hub 1-0:1.0: state 7 ports 2 
> > chg  evt 0004
> > Sep  9 13:49:03 prizm kernel: [  586.405512] usb 1-2: usb auto-suspend
> > Sep  9 13:49:03 prizm kernel: [  586.421471] hub 5-0:1.0: hub_suspend
> > Sep  9 13:49:03 prizm kernel: [  586.421481] ehci_hcd :00:10.4: suspend 
> > root hub
> > Sep  9 13:49:03 prizm kernel: [  586.421496] usb usb5: usb auto-suspend
> > Sep  9 13:49:05 prizm kernel: [  588.421351] hub 1-0:1.0: hub_suspend
> > Sep  9 13:49:05 prizm kernel: [  588.421361] usb usb1: suspend_rh
> > Sep  9 13:49:05 prizm kernel: [  588.421481] usb usb1: usb auto-suspend
> 
> Ah, oh wait, now we just turned the power off.
> 
> Try disabling CONFIG_USB_SUSPEND and see if that fixes this issue.  Or
> you can manually turn the power back on to your blackberry by writing to
> the autosuspend file for the usb device in sysfs, but that can be a
> pain.
> 
> Let me know if just changing that config option works for you.
> 

And now for the dramatic conclusion...

To begin, I have no access to the original machine at the moment, as I'm now 
out of that area for a couple weeks.  I built a similar kernel (same version) 
on another box that I have at my current location.  The new machine is 
different hardware, so some kernel re-configuring was required, but I kept with 
the same USB settings (and similar overall design).  Interestingly, this 
machine didn't reproduce the "magic command failed" error, but it did fail very 
similarly to the original at charging the device.  I disabled 
CONFIG_USB_SUSPEND as suggested, and lo and behold, it now charges the berry.  
Looks like an excellent diagnosis to me, doctor.  

Thanks! :)

> thanks,
> 
> greg k-h

-- 
Matt
-
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: hci_sock.c build failure

[Coly Li]

Coly Li 写道:
 David Miller 写道:
 From: Greg KH [EMAIL PROTECTED]
 Date: Wed, 12 Sep 2007 05:02:53 -0700

 It's not even a randconfig issue, my build dies too (this is Linus's
 current tree.)

 Time to poke through the 10 bluetooth patches that were just added...
 I'll push the following fix to Linus.

 From 1da97f83a843f92678b614fcaebdb3e4ebd6c9dd Mon Sep 17 00:00:00 2001
 From: David S. Miller [EMAIL PROTECTED](none)
 Date: Wed, 12 Sep 2007 14:10:58 +0200
 Subject: [PATCH] [BLUETOOTH]: Fix non-COMPAT build of hci_sock.c

 Signed-off-by: David S. Miller [EMAIL PROTECTED]
 ---
  net/bluetooth/hci_sock.c |7 ---
  1 files changed, 4 insertions(+), 3 deletions(-)

 diff --git a/net/bluetooth/hci_sock.c b/net/bluetooth/hci_sock.c
 index d16ca8e..5ccea5f 100644
 --- a/net/bluetooth/hci_sock.c
 +++ b/net/bluetooth/hci_sock.c
 @@ -348,16 +348,17 @@ static inline void hci_sock_cmsg(struct sock *sk, 
 struct msghdr *msg, struct sk_
  
  skb_get_timestamp(skb, tv);
  
 +data = tv;
 +len = sizeof(tv);
 +#ifdef CONFIG_COMPAT
  if (msg-msg_flags  MSG_CMSG_COMPAT) {
  struct compat_timeval ctv;
  ctv.tv_sec = tv.tv_sec;
  ctv.tv_usec = tv.tv_usec;
  data = ctv;
  len = sizeof(ctv);
 should we consider the condition that msg-msg_flags  MSG_CMSG_COMPAT comes 
 to true when
 CONFIG_COMPAT is not defined ?
Sorry, once CONFIG_COMPAT is not defined, msg-msg_flags  MSG_CMSG_COMPAT will 
never come to true.
forget my comments.

 
 -} else {
 -data = tv;
 -len = sizeof(tv);
  }
 +#endif
  
  put_cmsg(msg, SOL_HCI, HCI_CMSG_TSTAMP, len, data);
  }
 

-
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: [00/41] Large Blocksize Support V7 (adds memmap support)

[Martin J. Bligh]

Christoph Lameter wrote:

On Tue, 11 Sep 2007, Nick Piggin wrote:


But that's not my place to say, and I'm actually not arguing that high
order pagecache does not have uses (especially as a practical,
shorter-term solution which is unintrusive to filesystems).

So no, I don't think I'm really going against the basics of what we agreed
in Cambridge. But it sounds like it's still being billed as first-order
support right off the bat here.


Well its seems that we have different interpretations of what was agreed 
on. My understanding was that the large blocksize patchset was okay 
provided that I supply an acceptable mmap implementation and put a 
warning in.


I think all we agreed on was that both patches needed significant work
and would need to be judged after they were completed ;-)

There was talk of putting Christoph's approach in more-or-less as-is
as a very specialized and limited application ... but I don't think
we concluded anything for the more general and long-term case apart
from this is hard ;-)

M.
-
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] Scheduler Profiling - Use Immediate Values

[Andi Kleen]

 The idea is not to hide the unlikely, but to leave the opportunity to
 make this primitive evolve in something that won't depend on a load
 immediate and only require patching of a jump, given the appropriate gcc
 support (yet to come).

If that ever happens the code can be still changed. But i don't think
it's a good idea to uglify the code for something that if it 
ever exists will be a long time away.

Besides if gcc supports it I assume the gcc support could 
also be written in a way that makes it possible to hide it inside
a standard if ()

-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: 2.6.23-rc6-git1 -- termios *_1 compile failures on powerpc

[Josh Boyer]

On 9/12/07, Andy Whitcroft [EMAIL PROTECTED] wrote:
 The following commit just hit mainline and all my powerpc test boxes are
 failing during compilation:

 commit f629307c857c030d5a3dd777fee37c8bb395e171
 tty: termios locking functions break with new termios type

I think this is already being discussed on the linuxppc-dev list.

josh
-
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.23-rc5: possible irq lock inversion dependency detected

[David Miller]

From: Herbert Xu [EMAIL PROTECTED]
Date: Tue, 11 Sep 2007 20:43:27 +0800

 On Tue, Sep 11, 2007 at 08:01:46AM -0400, jamal wrote:
 
  [NET_SCHED] protect action config/dump from irqs
 
 Looks good! Thanks Jamal.

Applied, I'll try to push this in some time soon.
-
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: stripping down the kernel-parameters.txt file

[Rogan Dawes]

Robert P. J. Day wrote:

p.s.  by basic, i mean those boot-time parms defined by either
__setup() or early_param().  which means that module writers
should, as much as possible, stop using those macros to define
command-line parameters for their modules.  that would go a long way
to restoring some order, and allowing for some decent and readable
documentation.


Are you forgetting that modules can often be compiled into the bzImage, 
too, making them genuine boot-time params?


Rogan

-
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 08/12] IB/ehca: Replace get_paca()-paca_index by the more portable smp_processor_id()

[Joachim Fenkes]

On Tuesday 11 September 2007 16:51, Nathan Lynch wrote:

  -  get_paca()-paca_index, __FUNCTION__, \
  +  smp_processor_id(), __FUNCTION__, \
 
 I think I see these macros used in preemptible code (e.g. ehca_probe),
 where smp_processor_id() will print a warning when
 CONFIG_DEBUG_PREEMPT=y.  Probably better to use raw_smp_processor_id.

You're right, man. The processor id doesn't need to be preemption-safe in this
context, so that would be a bogus warning. Thanks for pointing this out. I'll
post a new version of this patch.

Joachim

-
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 08/12] IB/ehca: Replace get_paca()-paca_index by the more portable raw_smp_processor_id()

[Joachim Fenkes]

We can use raw_smp_processor_id() here because the processor ID is only used
for debug output and may therefore be preemption-unsafe.

Signed-off-by: Joachim Fenkes [EMAIL PROTECTED]
---

This is the same patch, but with smp_processor_id() replaced by
raw_smp_processor_id(), as kindly pointed out to me by Nathan. Thanks!

 drivers/infiniband/hw/ehca/ehca_tools.h |   14 +++---
 1 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_tools.h 
b/drivers/infiniband/hw/ehca/ehca_tools.h
index f9b264b..4a8346a 100644
--- a/drivers/infiniband/hw/ehca/ehca_tools.h
+++ b/drivers/infiniband/hw/ehca/ehca_tools.h
@@ -73,37 +73,37 @@ extern int ehca_debug_level;
if (unlikely(ehca_debug_level)) \
dev_printk(KERN_DEBUG, (ib_dev)-dma_device, \
   PU%04x EHCA_DBG:%s  format \n, \
-  get_paca()-paca_index, __FUNCTION__, \
+  raw_smp_processor_id(), __FUNCTION__, \
   ## arg); \
} while (0)
 
 #define ehca_info(ib_dev, format, arg...) \
dev_info((ib_dev)-dma_device, PU%04x EHCA_INFO:%s  format \n, \
-get_paca()-paca_index, __FUNCTION__, ## arg)
+raw_smp_processor_id(), __FUNCTION__, ## arg)
 
 #define ehca_warn(ib_dev, format, arg...) \
dev_warn((ib_dev)-dma_device, PU%04x EHCA_WARN:%s  format \n, \
-get_paca()-paca_index, __FUNCTION__, ## arg)
+raw_smp_processor_id(), __FUNCTION__, ## arg)
 
 #define ehca_err(ib_dev, format, arg...) \
dev_err((ib_dev)-dma_device, PU%04x EHCA_ERR:%s  format \n, \
-   get_paca()-paca_index, __FUNCTION__, ## arg)
+   raw_smp_processor_id(), __FUNCTION__, ## arg)
 
 /* use this one only if no ib_dev available */
 #define ehca_gen_dbg(format, arg...) \
do { \
if (unlikely(ehca_debug_level)) \
printk(KERN_DEBUG PU%04x EHCA_DBG:%s  format \n, \
-  get_paca()-paca_index, __FUNCTION__, ## arg); \
+  raw_smp_processor_id(), __FUNCTION__, ## arg); \
} while (0)
 
 #define ehca_gen_warn(format, arg...) \
printk(KERN_INFO PU%04x EHCA_WARN:%s  format \n, \
-  get_paca()-paca_index, __FUNCTION__, ## arg)
+  raw_smp_processor_id(), __FUNCTION__, ## arg)
 
 #define ehca_gen_err(format, arg...) \
printk(KERN_ERR PU%04x EHCA_ERR:%s  format \n, \
-  get_paca()-paca_index, __FUNCTION__, ## arg)
+  raw_smp_processor_id(), __FUNCTION__, ## arg)
 
 /**
  * ehca_dmp - printk a memory block, whose length is n*8 bytes.
-- 
1.5.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: stripping down the kernel-parameters.txt file

[Robert P. J. Day]

On Wed, 12 Sep 2007, Rogan Dawes wrote:

 Robert P. J. Day wrote:
  p.s.  by basic, i mean those boot-time parms defined by either
  __setup() or early_param().  which means that module writers
  should, as much as possible, stop using those macros to define
  command-line parameters for their modules.  that would go a long
  way to restoring some order, and allowing for some decent and
  readable documentation.

 Are you forgetting that modules can often be compiled into the
 bzImage, too, making them genuine boot-time params?

sarcasm
really?  no way.  get outta town.
/sarcasm

  sorry, but there was no way i could resist that.  :-)  *of course* i
realize that.  *all* of those things (__setup, early_param, actual
module params) are potential entries on the kernel line at boot time,
depending on your particular configuration.

  all i'm suggesting is that there is an obvious distinction between
those that are defined using __setup() or early_param(), and those
that are actual module parameters.  and that it would make more sense
to keep them separate, even if only separating them within the same
text file.

  in the end, there should be a nice, *short* reference for what i
like to call basic kernel parms (defined by __setup() or
early_param()), while anyone who wants to learn about any
module-specific parms should then have to go look up the info for that
given module, that's all.

  as a trivial starting point, this would involve nothing more than
shifting current content around in kernel-parameters.txt, putting the
basic stuff at the top, and the module-specific stuff after that.
heck, that would even give module authors the chance to add a line or
two of module description if they wanted.  how does life get any
better than that?

rday
-- 

Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://crashcourse.ca

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

Re: [PATCH net-2.6.24] cxgb3 - napi update

[David Miller]

From: Divy Le Ray [EMAIL PROTECTED]
Date: Sun, 09 Sep 2007 00:09:17 -0700

 From: Divy Le Ray [EMAIL PROTECTED]
 
 Embed napi_struct directly into sge_qset.
 Use napi_schedule/napi_complete.
 
 Signed-off-by: Divy Le Ray [EMAIL PROTECTED]

Patch applied, thanks a lot!
-
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] [patch] sunrpc: make closing of old temporary sockets work (was: problems with lockd in 2.6.22.6)

[Wolfgang Walter]

Am Mittwoch, 12. September 2007 15:37 schrieb J. Bruce Fields:
 On Wed, Sep 12, 2007 at 02:07:10PM +0200, Wolfgang Walter wrote:
  as already described old temporary sockets (client is gone) of lockd
  aren't closed after some time. So, with enough clients and some time
  gone, there are 80 open dangling sockets and you start getting messages
  of the form:
 
  lockd: too many open TCP sockets, consider increasing the number of nfsd
  threads.

 Thanks for working on this problem!

  If I understand the code then the intention was that the server closes
  temporary sockets after about 6 to 12 minutes:
 
  a timer is started which calls svc_age_temp_sockets every 6 minutes.
 
  svc_age_temp_sockets:
  if a socket is marked OLD it gets closed.
  sockets which are not marked as OLD are marked OLD
 
  every time the sockets receives something OLD is cleared.
 
  But svc_age_temp_sockets never closes any socket though because it only
  closes sockets with svsk-sk_inuse == 0. This seems to be a bug.
 
  Here is a patch against 2.6.22.6 which changes the test to
  svsk-sk_inuse = 0 which was probably meant. The patched kernel runs
  fine here. Unused sockets get closed (after 6 to 12 minutes)

 So the fact that this changes the behavior means that sk_inuse is taking
 on negative values.  This can't be right--how can something like
 svc_sock_put() (which does an atomic_dec_and_test) work in that case?

You probably misread the code.

if (atomic_read(svsk-sk_inuse) || test_bit(SK_BUSY, svsk-sk_flags))
continue;

This means: any socket where svsk-sk_inuse != 0 or SK_BUSY is set is ignored
by svc_age_temp_sockets: no attempt is made to close the svc.

This seems to be wrong: if svsk-sk_inuse is zero only if svc_delete_socket
has been called for it and will be deleted anyway (probably it is already
closed then).

But the intention of svc_age_temp_sockets is to close open temporary
sockets where no traffic has been received for more than 6 minutes. These
sockets have svsk-sk_inuse = 1.

My patch does exactly this:

instead of

skip sockets which are not already deleted or which are busy

to

skip sockets which are already deleted or which are busy


 I wish I had time today to figure out what's going on in this case.  But
 from a quick through svsock.c for sk_inuse, it looks odd; I'm suspicious
 of anything without the stereotyped behavior--initializing to one,
 atomic_inc()ing whenever someone takes a reference, and
 atomic_dec_and_test()ing whenever someone drops it


Then svc_tcp_accept would be wrong, too (it closes sockets the same way just
without testing for sk_inuse and SK_BUSY).

I think this works because as long as a socket is in sv_tempsocks or
sv_permsocks svsk-sk_inuse can never reach zero. As svc_age_temp_sockets locks
the list nobody can bring svsk-sk_inuse to zero as long as
svc_age_temp_sockets holds the lock. As svc_age_temp_sockets calls
atomic_inc(svsk-sk_inuse) when holding the lock there is no
problem. (the same is true for svc_tcp_accept).

This is the reason why I doubt that this check for svsk-sk_inuse in
svc_age_temp_sockets is usefull at all. It should be always false.

Regards,
-- 
Wolfgang Walter
Studentenwerk München
Anstalt des öffentlichen Rechts
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [patch 2/6] Linux Kernel Markers - Add kconfig menus for the marker code

[Mathieu Desnoyers]

* Randy Dunlap ([EMAIL PROTECTED]) wrote:
 On Thu, 06 Sep 2007 16:07:35 -0400 Mathieu Desnoyers wrote:
 
 [snip]
 
  This patch:
  
  Add Kconfig menus for the marker code.
  
  [EMAIL PROTECTED]: Never ever select MODULES]
  Signed-off-by: Mathieu Desnoyers [EMAIL PROTECTED]
  Reviewed-by: Christoph Hellwig [EMAIL PROTECTED]
  Reviewed-by: Frank Ch. Eigler [EMAIL PROTECTED]
  CC: Adrian Bunk [EMAIL PROTECTED]
  ---
  
   arch/alpha/Kconfig   |2 ++
   arch/arm/Kconfig |2 ++
   arch/avr32/Kconfig.debug |7 +++
   arch/cris/Kconfig|2 ++
   arch/frv/Kconfig |2 ++
   arch/h8300/Kconfig   |2 ++
   arch/i386/Kconfig|2 ++
   arch/ia64/Kconfig|2 ++
   arch/m32r/Kconfig|2 ++
   arch/m68k/Kconfig|2 ++
   arch/m68knommu/Kconfig   |2 ++
   arch/mips/Kconfig|2 ++
   arch/parisc/Kconfig  |2 ++
   arch/powerpc/Kconfig |2 ++
   arch/ppc/Kconfig |2 ++
   arch/s390/Kconfig|2 ++
   arch/sh/Kconfig  |2 ++
   arch/sh64/Kconfig|2 ++
   arch/sparc/Kconfig   |2 ++
   arch/sparc64/Kconfig |2 ++
   arch/um/Kconfig  |2 ++
   arch/v850/Kconfig|2 ++
   arch/x86_64/Kconfig  |2 ++
   arch/xtensa/Kconfig  |2 ++
   kernel/Kconfig.marker|7 +++
   kernel/Makefile  |1 +
   26 files changed, 61 insertions(+)
  
  Index: linux-2.6-lttng/arch/alpha/Kconfig
  ===
  --- linux-2.6-lttng.orig/arch/alpha/Kconfig 2007-09-04 12:14:48.0 
  -0400
  +++ linux-2.6-lttng/arch/alpha/Kconfig  2007-09-04 12:16:57.0 
  -0400
  @@ -646,6 +646,8 @@ config SRM_ENV
   
   source fs/Kconfig.binfmt
   
  +source kernel/Kconfig.marker
  +
   endmenu
   
   source net/Kconfig
  Index: linux-2.6-lttng/kernel/Kconfig.marker
  ===
  --- /dev/null   1970-01-01 00:00:00.0 +
  +++ linux-2.6-lttng/kernel/Kconfig.marker   2007-09-04 12:16:57.0 
  -0400
  @@ -0,0 +1,7 @@
  +# Code markers configuration
  +
  +config MARKERS
  +   bool Activate markers
  +   help
  + Place an empty function call at each marker site. Can be
  + dynamically changed for a probe function.
  Index: linux-2.6-lttng/arch/avr32/Kconfig.debug
  ===
  --- linux-2.6-lttng.orig/arch/avr32/Kconfig.debug   2007-09-04 
  12:14:49.0 -0400
  +++ linux-2.6-lttng/arch/avr32/Kconfig.debug2007-09-04 
  12:16:57.0 -0400
  @@ -6,6 +6,9 @@ config TRACE_IRQFLAGS_SUPPORT
   
   source lib/Kconfig.debug
   
  +menu Instrumentation Support
  +   depends on EXPERIMENTAL
  +
   config KPROBES
  bool Kprobes
  depends on DEBUG_KERNEL
  @@ -16,4 +19,8 @@ config KPROBES
 for kernel debugging, non-intrusive instrumentation and testing.
 If in doubt, say N.
   
  +source kernel/Kconfig.marker
  +
  +endmenu
  +
   endmenu
 
 It seems sad that this patch sources Kconfig.marker, a 7-line file,
 20-something times.  Yes, you (we) don't want to put those 7 lines
 into 20-something different files, so sourcing is the right thing.
 
 However, what you did for avr32 seems more on the right track to me:
 make _one_ Instrumentation support menu that includes PROFILING,
 OPROFILE, KPROBES, and MARKERS and then use (source) that in all
 of the arches.
 

Ok, it will be in my next post.

Mathieu

 ---
 ~Randy
 *** Remember to use Documentation/SubmitChecklist when testing your code ***

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

[PATCH] update checkpatch.pl to version 0.10

[Andy Whitcroft]

This version brings a number of new checks, and a number of bug
fixes.  Of note:

  - better categorisation and space checks for dual use unary/binary
operators
  - warn on deprecated use of {SPIN,RW}_LOCK_UNLOCKED
  - check if/for/while with trailing ';' for hanging statements
  - detect DOS line endings
  - detect redundant casts for kalloc()

Andy Whitcroft (18):
  Version: 0.10
  asmlinkage is also a storage type
  pull out inline specifiers
  allow only some operators before a unary operator
  parenthesised values may span line ends
  add additional attribute matching
  handle sparse annotations within pointer type space checks
  support alternative function definition syntax for typedefs
  check if/for/while with trailing ';' for hanging statements
  fix output format for case checks
  deprecate SPIN_LOCK_UNLOCKED and RW_LOCK_UNLOCKED
  allow complex macros with bracketing braces
  detect and report DOS line endings
  fastcall is a valid function attribute
  bracket spacing is ok for 'for'
  categorise operators into unary/binary/definitions
  add heuristic to pick up on unannotated types
  remove spurious warnings from cat_vet

Dave Jones (1):
  Make checkpatch warn about pointless casting of kalloc returns.

Signed-off-by: Andy Whitcroft [EMAIL PROTECTED]
---
 scripts/checkpatch.pl |  254 +---
 1 files changed, 196 insertions(+), 58 deletions(-)
diff --git a/scripts/checkpatch.pl b/scripts/checkpatch.pl
index dae7d30..59ad83c 100755
--- a/scripts/checkpatch.pl
+++ b/scripts/checkpatch.pl
@@ -9,7 +9,7 @@ use strict;
 my $P = $0;
 $P =~ [EMAIL PROTECTED]/@@g;
 
-my $V = '0.09';
+my $V = '0.10';
 
 use Getopt::Long qw(:config no_auto_abbrev);
 
@@ -212,6 +212,11 @@ sub ctx_block_level {
 
return ctx_block_get($linenr, $remain, 0, '{', '}', 0);
 }
+sub ctx_statement_level {
+   my ($linenr, $remain, $off) = @_;
+
+   return ctx_block_get($linenr, $remain, 0, '(', ')', $off);
+}
 
 sub ctx_locate_comment {
my ($first_line, $end_line) = @_;
@@ -255,13 +260,42 @@ sub ctx_has_comment {
return ($cmt ne '');
 }
 
+sub ctx_expr_before {
+   my ($line) = @_;
+
+   ##print CHECK$line\n;
+
+   my $pos = length($line) - 1;
+   my $count = 0;
+   my $c;
+
+   for (; $pos = 0; $pos--) {
+   $c = substr($line, $pos, 1);
+   ##print CHECK: c$c count$count\n;
+   if ($c eq ')') {
+   $count++;
+   } elsif ($c eq '(') {
+   last if (--$count == 0);
+   }
+   }
+
+   ##print CHECK: result . substr($line, 0, $pos) . \n;
+
+   return substr($line, 0, $pos);
+}
+
 sub cat_vet {
my ($vet) = @_;
+   my ($res, $coded);
 
-   $vet =~ s/\t/^I/;
-   $vet =~ s/$/\$/;
+   $res = '';
+   while ($vet =~ /([^[:cntrl:]]*)([[:cntrl:]])/g) {
+   $coded = sprintf(^%c, unpack('C', $2) + 64);
+   $res .= $1 . $coded;
+   }
+   $res =~ s/$/\$/;
 
-   return $vet;
+   return $res;
 }
 
 my @report = ();
@@ -310,8 +344,17 @@ sub process {
my $first_line = 0;
 
my $Ident   = qr{[A-Za-z\d_]+};
-   my $Storage = qr{extern|static};
-   my $Sparse  = 
qr{__user|__kernel|__force|__iomem|__must_check|__init_refok};
+   my $Storage = qr{extern|static|asmlinkage};
+   my $Sparse  = qr{
+   __user|
+   __kernel|
+   __force|
+   __iomem|
+   __must_check|
+   __init_refok|
+   fastcall
+   }x;
+   my $Inline  = qr{inline|__always_inline|noinline};
my $NonptrType  = qr{
\b
(?:const\s+)?
@@ -345,11 +388,18 @@ sub process {
(?:\s+$Sparse)*
  }x;
my $Declare = qr{(?:$Storage\s+)?$Type};
-   my $Attribute   = qr{const|__read_mostly|__init|__initdata|__meminit};
-
+   my $Attribute   = qr{
+   const|
+   __read_mostly|
+   __(?:mem|cpu|dev|)(?:initdata|init)
+ }x;
my $Member  = qr{-$Ident|\.$Ident|\[[^]]*\]};
my $Lval= qr{$Ident(?:$Member)*};
 
+   # Possible bare types.
+   my @bare = ();
+   my $Bare = $NonptrType;
+
# Pre-scan the patch looking for any __setup documentation.
my @setup_docs = ();
my $setup_docs = 0;
@@ -477,7 +527,11 @@ sub process {
next if ($realfile !~ /\.(h|c|s|S|pl|sh)$/);
 
 #trailing whitespace
-   if ($line =~ /^\+.*\S\s+$/ || $line =~ /^\+\s+$/) {
+   

Define termios_1 functions for powerpc, s390, avr32 and frv

[Paul Mackerras]

Commit f629307c857c030d5a3dd777fee37c8bb395e171 introduced uses of
kernel_termios_to_user_termios_1 and user_termios_to_kernel_termios_1
on all architectures.  However, powerpc, s390, avr32 and frv don't
currently define those functions since their termios struct didn't
need to be changed when the arbitrary baud rate stuff was added, and
thus the kernel won't currently build on those architectures.

This adds definitions of kernel_termios_to_user_termios_1 and
user_termios_to_kernel_termios_1 to include/asm-generic/termios.h
which are identical to kernel_termios_to_user_termios and
user_termios_to_kernel_termios respectively.  The definitions are the
same because the old termios and new termios are in fact the same
on these architectures (which are the same ones that use
asm-generic/termios.h).

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

Linus, this seems a bit cleaner than putting ifdefs in
drivers/char/tty_ioctl.c, and it fixes the compile error on powerpc.
Your choice whether to use this patch or Tony's.

diff --git a/include/asm-generic/termios.h b/include/asm-generic/termios.h
index 3769e6b..33dca30 100644
--- a/include/asm-generic/termios.h
+++ b/include/asm-generic/termios.h
@@ -63,6 +63,8 @@ static inline int kernel_termios_to_user_termio(struct termio 
__user *termio,
 
 #define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, 
sizeof(struct termios))
 #define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct 
termios))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, 
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, 
sizeof(struct termios))
 
 #endif /* __ARCH_TERMIO_GETPUT */
 
-
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: Possible hang inside interrupt handler on sata_promise.

[Mikael Pettersson]

Robin Holt writes:
  
  I have been experiencing hangs on a newly setup machine.  Unfortunately,
  it appears to be hanging inside the interrupt handler as sysrq and
  caps-lock led seem to stop working when the event occurs.  I am guessing
  it is related to the sata_promise driver, but that is only a guess as
  I don't get much for output.  I am running the debian unstable kernel
  (2.6.22-1-686), but the problem also occurs with the debian stable kernel
  (2.6.18-4-686).  I do need to boot with the acpi=off option, but am
  not sure if that is related.  Unfortunately, I do not know much about
  troubleshooting i386 when problems occur inside the interrupt handlers.

This is the first I've heard of a problem like this.
Since you boot with acpi=off and sysrq stops working,
I really have to suspect a mainboard interrupt problem.

  What can I do to help troubleshoot this problem.

Unless the mainboard in question is known to be a totally
lost cause for ACPI, the first step should be to get ACPI
working.

If it's an older mainboard it might not need ACPI,
but then you should build and boot an ACPI-free kernel.
(I wouldn't trust acpi=off to be equivalent to CONFIG_ACPI=n.)

If the mainboard has an I/O-APIC then you should make sure
that the kernel can find and use it.

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

Lossy interrupts on x86_64

[Jesse Barnes]

I just narrowed down a weird problem where I was losing more than 50% of 
my vblank interrupts to what seems to be the hires timers patch.  Stock 
2.6.23-rc5 works fine, but the latest (171) kernel from rawhide drops 
most of my interrupts unless I also have another interrupt source 
running (e.g. if I hold down a key or move the mouse I get the expected 
number of vblank interrupts, otherwise I get between 3 and 30 instead 
of the expected 60 per second).

Any ideas?  It seems like it might be bad APIC programming, but I 
haven't gone through those mods to look for suspects...

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

Re: Kernel Panic - 2.6.23-rc4-mm1 ia64 - was Re: Update: [Automatic] NUMA replicated pagecache ...

[Andy Whitcroft]

On Wed, Sep 12, 2007 at 11:09:47AM -0400, Lee Schermerhorn wrote:

  Interesting, I don't see a memory controller function in the stack
  trace, but I'll double check to see if I can find some silly race
  condition in there.
 
 right.  I noticed that after I sent the mail.  
 
 Also, config available at:
 http://free.linux.hp.com/~lts/Temp/config-2.6.23-rc4-mm1-gwydyr-nomemcont

Be interested to know the outcome of any bisect you do.  Given its
tripping in reclaim.

What size of box is this?  Wondering if we have anything big enough to
test with.

-apw
-
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/RFC] doc: about email clients for Linux kernel patches

[Adrian Bunk]

On Wed, Sep 12, 2007 at 08:02:29AM -0700, Randy Dunlap wrote:
 Adrian Bunk wrote:
 On Wed, Sep 12, 2007 at 01:24:13PM +0800, WANG Cong wrote:
 On Tue, Sep 11, 2007 at 08:29:26PM +0200, Adrian Bunk wrote:
 On Tue, Sep 11, 2007 at 10:16:44AM -0700, Randy Dunlap wrote:
 ...
 +~~
 +Mutt (TUI)
 +
 +Plenty of Linux developers use mutt, so it must work pretty well.
 +
 +Are there any special config options that are needed??
 ...
 It should work with default settings.

 I can't agree with this.

 It took me lots of time to configure mutt to work well for me in the 
 first
 time. Just default settings are far _not_ enough, especially for us
 non-english-speakers. One common setting is the encoding, of course, lkml
 prefers UTF-8, so I must set my mutt with `set 
 send_charset=us-ascii:utf-8`.
 This makes sense, but it's not really a mutt specific issue and problems 
 because mutt prefers iso-8859-1 over UTF-8 by default are
 quite rare.
 Manuals of mutt told me to add subscribe linux-kernel@vger.kernel.org 
 if I
 subscribed lkml, but in fact, we'd better _not_ add this, or it will drop
 myself from cc list.

 Or other things like these.
 ...
 Whether or not people want to get personal copies of answers to mailing
 list posts is a religious issue being second only to the vi-emacs 
 wars...
 But as far as I understand it, this documentation is intended to help 
 people to get sending patches right (no line wrap etc.), not as a generic 
 documentation for mail clients.

 Definitely.
 and to reduce the amount of repetition that we have to do.

 I'll add a bit about it not being complete s/w package config info.

One point from this email that might be appropriate for the
General Preferences section of your document would be to suggest 
configuring the MUA to send text encoded as UTF-8, something like:

The kernel source code is encoded in UTF-8, and if you configure your 
email client to send emails UTF-8 encoded you avoid some possible 
charset problems.

 thanks,
 ~Randy

cu
Adrian

-- 

   Is there not promise of rain? Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
   Only a promise, Lao Er said.
   Pearl S. Buck - Dragon Seed

-
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] ehca_irq: Misc cpuinit section annotations and #ifdef cleanups

[Joachim Fenkes]

On Thursday 23 August 2007 01:28, Satyam Sharma wrote:
 
 * Replace {un}register_cpu_notifier with {un}register_hotcpu_notifier
   thereby losing a couple of #ifdef HOTPLUG_CPU pairs.
 * Move comp_pool_callback_nb declaration to below that of callback
   function so that initialization of .notifier_call and .priority can
   occur at build time itself and not runtime.
 * Mark the notifier_block (and callback function, and another static
   function used by it) as __cpuinit{data} for the sake of consistency
   and remove enclosing #ifdef. (This may increase size for modular
   build of this module, however, because these are no longer dropped
   unconditionally now.)
 
 Signed-off-by: Satyam Sharma [EMAIL PROTECTED]

Looks okay to me.

Acked-by: Joachim Fenkes [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: OOPS in __copy_user_zeroing_intel

[Michal Piotrowski]

Hi Chris,

On 11/09/2007, Chris Friesen [EMAIL PROTECTED] wrote:

 Hi all,

 We're running a modified 2.6.10 on a dual-Xeon system.  We've had a
 number of instances where we've seen oopses in the pipe code.  I've
 included the most recent one below.  This bug left us with a hung
 process as the pipe code bailed out while pipe_writev() was holding a
 sema, and another process was blocked waiting for the sema.

 Is anyone aware of bugs that were fixed in the pipe code since 2.6.10?

Eh, this is a pretty ancient kernel.

You may want to use one of the long time support kernel 2.6.16.x or 2.6.20.x.


 Thanks,

 Chris


 Unable to handle kernel paging request at virtual address 450004a2
   printing eip:
 c028fb7a
 *pde = 2a716001
 Kcore timestamp : 1188871029.530900
 Kcore HighResolution timestamp : 2B7FA3FD52C48
 Oops: 0002 [#1]
 SMP
 Modules linked in: fuse tipc pmemfs bond2 bond1 bond0 fault
 ipmi_watchdog vmc vMCstub ipmibus ipmi_serial ipmi_devintf ipmi_msghandler

 CPU:3
 EIP:0060:[c028fb7a]Not tainted VLI
 EFLAGS: 00010206   (2.6.10-pne)
 EIP is at __copy_user_zeroing_intel+0x28/0xac
 eax: 20202020   ebx: 0049   ecx: 0049   edx: 74656e69
 esi: b7e2c000   edi: 450004a2   ebp: f04f9eac   esp: f04f9ea4
 ds: 007b   es: 007b   ss: 0068
 Process grep (pid: 28955, threadinfo=f04f8000 task=f0420c70)
 Stack: b7e2c000 450004a2 f04f9ec8 c028fcd0 450004a2 b7e2c000 0049
 
 450004a2 f04f9ee8 c028fd67 450004a2 b7e2c000 0049 f04f9f48
 0049
 babbb0bb f04f9f30 c01733c6 450004a2 b7e2c000 0049 ea309ddc
 8ecc000e
 450004a2 babbb0bb f04f8000 0049 0001 0049 
 f72d83f0
 c01735f6 ea37b180 f04f9f94 f04f9f50 c0173629 ea37b180 f04f9f48
 0001
 f04f9f94 b7e2c000 0049 f04f9f7c c0167af3 ea37b180 b7e2c000
 0049
 f04f9f94 0003 0b00 ea37b180 0001 fff7 f04f9fbc
 c0167c4c
 ea37b180 b7e2c000 0049 f04f9f94   
 0107
 4900  b7e2c000 0001 0049 b7e2c000 f04f8000
 c0102554
 0001 b7e2c000 0049 0049 b7e2c000 bfffe4d8 0004
 007b
 007b 0004 e410 0073 0246 bfffe4a4 007b
 Call Trace:
   [c010340f] show_stack+0x80/0x96
   [c01035a2] show_registers+0x15d/0x1d6
   [c0103900] die+0x106/0x194
   [c0112602] do_page_fault+0x594/0x8e9
   [c01030bb] error_code+0x2b/0x30
   [c028fcd0] __copy_from_user_ll+0x62/0x70
   [c028fd67] copy_from_user+0x3f/0x68
   [c01733c6] pipe_writev+0x107/0x337
   [c0173629] pipe_write+0x33/0x35
   [c0167af3] vfs_write+0xe0/0x11e
   [c0167c4c] sys_write+0x77/0xa4
   [c0102554] no_dpa_vsyscall_enter+0x8/0x1b
 Code: c8 5d c3 55 89 e5 83 ec 08 89 34 24 89 7c 24 04 8b 75 0c 8b 7d 08
 8b 4d 10 8b 46 20 83 f9 43 76 04 8b 46 40 90 8b 46 00 8b 56 04 89 47
 00 89 57 04 8b 46 08 8b 56 0c 89 47 08 89 57 0c 8b 46 10

 fuse tipc pmemfs bond2 bond1 bond0 fault ipmi_watchdog vmc vMCstub
 ipmibus ipmi_serial ipmi_devintf ipmi_msghandler

Regards,
Michal

-- 
LOG
http://www.stardust.webpages.pl/log/
-
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/

2.6.22.6: still seeing section mismatch warnings

[Frank van Maarseveen]

I'm still seeing the warnings below (2.6.22 started off with lots of
section mismatch warning) but I have no idea if it is safe to ignore
these:

WARNING: arch/i386/kernel/built-in.o(.text+0xea62): Section mismatch: reference 
to .init.data:trampoline_end (between 'setup_trampoline' and 
'cpu_coregroup_map')
WARNING: arch/i386/kernel/built-in.o(.text+0xea67): Section mismatch: reference 
to .init.data:trampoline_data (between 'setup_trampoline' and 
'cpu_coregroup_map')
WARNING: arch/i386/kernel/built-in.o(.text+0xea79): Section mismatch: reference 
to .init.data:trampoline_data (between 'setup_trampoline' and 
'cpu_coregroup_map')
WARNING: arch/i386/kernel/built-in.o(.exit.text+0x26): Section mismatch: 
reference to .init.text: (between 'cache_remove_dev' and 'ffh_cstate_exit')
WARNING: arch/i386/kernel/built-in.o(.data+0xee0): Section mismatch: reference 
to .init.text: (between 'thermal_throttle_cpu_notifier' and 'mce_work')
WARNING: kernel/built-in.o(.text+0x1b415): Section mismatch: reference to 
.init.text: (between 'kthreadd' and 'init_waitqueue_head')


gcc version 3.4.6 (Debian 3.4.6-5)

-- 
Frank
-
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: hci_sock.c build failure

[Marcel Holtmann]

Hi Dave,

  It's not even a randconfig issue, my build dies too (this is Linus's
  current tree.)
  
  Time to poke through the 10 bluetooth patches that were just added...
 
 I'll push the following fix to Linus.

the patch looks absolutely fine to me. You can put an Acked-by line to
it. Sorry for breaking the build. I tested it on so many architectures,
but it seems I always had CONFIG_COMPAT enabled. Seems I am running out
of i386/32-bit only systems.

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/

Building a kernel-source RPM (not a kernel RPM)?

[Dan Stromberg]

I sent this to kernel newbies first, and while I got one response there,
it answered a different question than the one I was asking...

I'm on a SuSE system.

I'm working on automating the install of said system, but it needs a
Linus kernel - 2.6.21.7 specifically, and it needs kernel source too so
that we can build modules in the field as needed.

I see you can make an rpm of a bootable kernel with make rpm.

Is there a streamlined way of building a corresponding kernel-source
RPM?  Or do people pretty much all just dump the source in /usr/src, and
manually update symlinks as needed?  If the latter, what symlinks need
to be updated?


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

2.6.23-rc6-git1 i386/allmodconfig broke

[Jan Dittmer]

Since -rc6:

- i386/allmodconfig: broke
CC [M]  net/bluetooth/hci_core.o
CC [M]  net/bluetooth/hci_conn.o
CC [M]  net/bluetooth/hci_event.o
CC [M]  net/bluetooth/hci_sock.o
  net/bluetooth/hci_sock.c: In function 'hci_sock_cmsg':
  net/bluetooth/hci_sock.c:352: error: storage size of 'ctv' isn't known
  net/bluetooth/hci_sock.c:352: warning: unused variable 'ctv'
  make[3]: *** [net/bluetooth/hci_sock.o] Error 1
  make[2]: *** [net/bluetooth] Error 2
  make[1]: *** [net] Error 2
  make: *** [_all] Error 2



Nice, that post rc6 patches aren't even tested with one of the most
common archs and configs :-(

Jan
-
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: Lossy interrupts on x86_64

[Jesse Barnes]

On Wednesday, September 12, 2007, Randy Dunlap wrote:
 On Wed, 12 Sep 2007 08:33:15 -0700 Jesse Barnes wrote:
  I just narrowed down a weird problem where I was losing more than
  50% of my vblank interrupts to what seems to be the hires timers
  patch.  Stock 2.6.23-rc5 works fine, but the latest (171) kernel
  from rawhide drops most of my interrupts unless I also have another
  interrupt source running (e.g. if I hold down a key or move the
  mouse I get the expected number of vblank interrupts, otherwise I
  get between 3 and 30 instead of the expected 60 per second).
 
  Any ideas?  It seems like it might be bad APIC programming, but I
  haven't gone through those mods to look for suspects...

 Also tickless?  (NO_HZ ?)

 I think I've seen some emails about tickless and keystrokes being
 needed to cause interrupts... but I'm not postive about it.

 but you said any ideas

Yeah, there's NO_HZ in the rawhide kernel too, but I'm getting timer
ticks normally afaict, it's just vblank interrupts that get lost...

/proc/interrupts on this machine (from NO_HZ, hires kernel):

[EMAIL PROTECTED] ~]$ cat /proc/interrupts
   CPU0   CPU1
  0: 290050 289541   IO-APIC-edge  timer
  1:   3862   3956   IO-APIC-edge  i8042
  8:  0  0   IO-APIC-edge  rtc0
  9:   1632   1643   IO-APIC-fasteoi   acpi
 12: 183662 183926   IO-APIC-edge  i8042
 14:  20626  20717   IO-APIC-edge  libata
 15:  0  0   IO-APIC-edge  libata
 16:  46812  46825   IO-APIC-fasteoi   yenta, uhci_hcd:usb3, [EMAIL 
PROTECTED]::00:02.0
 17:  63715  63653   IO-APIC-fasteoi   uhci_hcd:usb4, HDA Intel, 
firewire_ohci, iwl4965
 18:  0  0   IO-APIC-fasteoi   uhci_hcd:usb5
 19: 52 36   IO-APIC-fasteoi   ehci_hcd:usb7
 20: 43 46   IO-APIC-fasteoi   uhci_hcd:usb1
 21:  0  0   IO-APIC-fasteoi   uhci_hcd:usb2
 22:  2  1   IO-APIC-fasteoi   ehci_hcd:usb6
2297:937944   PCI-MSI-edge  eth0
2298:  12392  12402   PCI-MSI-edge  ahci
NMI:  0  0
LOC: 290913 335027
ERR:  0


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

[2.6.23-rc6] i386 build breakage on current git

[Jeff Garzik]

Platform i386 seems to be missing struct compat_timeval, which causes 
the i386 allmodconfig build to break in current -git:


net/bluetooth/hci_sock.c: In function ‘hci_sock_cmsg’:
net/bluetooth/hci_sock.c:352: error: storage size of ‘ctv’ isn’t known
net/bluetooth/hci_sock.c:352: warning: unused variable ‘ctv’
make[2]: *** [net/bluetooth/hci_sock.o] Error 1

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