Re: Temporary lockup on loopback block device

[Miklos Szeredi]

> > > Arguably we just have the wrong backing-device here, and what we should do
> > > is to propagate the real backing device's pointer through up into the
> > > filesystem.  There's machinery for this which things like DM stacks use.
> > > 
> > > I wonder if the post-2.6.23 changes happened to make this problem go away.
> > 
> > The per BDI dirty stuff in 24 should make this work, I just checked and
> > loopback thingies seem to have their own BDI, so all should be well.
> 
> This is not only about loopback (I think the lockup can happen even 
> without loopback) --- the main problem is:
> 
> Why are there over-limit dirty pages that no one is writing?

Please do a sysrq-t, and cat /proc/vmstat during the hang.  Those
will show us what exactly is happening.

I've seen this type of hang many times, and I agree with Peter, that
it's probably about loopback, and is fixed in 2.6.24-rc.

Thanks,
Miklos


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

Re: [RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS

[Paul Mundt]

On Sun, Nov 11, 2007 at 07:48:29AM +0100, Adrian Bunk wrote:
> But the kernel does (at least on some architectures) not link with 
> libgcc or ship other code providing the required libgcc functions.
> 
> Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop 
> (new option in gcc 4.3) as a workaround and I confirmed that it fixes 
> the compilation.
> 
And some architectures do link it in, so the call to libgcc code doesn't
necessarily matter. Perhaps the architectures that don't link in libgcc
can turn this flag on conditionally, it shouldn't be forced on the
architectures that do link it in.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[Rogelio M. Serrano Jr.]

Dr. David Alan Gilbert wrote:
>
>
> Allowing a user to tweak (under constraints) their settings might allow
> them to do something like create two mozilla profiles which are isolated
> from each other, so that the profile they use for general web surfing
> is isolated from the one they use for online banking.
>
>   
Doesnt this allow the user to shoot their own foot? The exact thing
mandatory access control are supposed to prevent?

> Dave
>   


-- 
Democracy is about two wolves and a sheep deciding what to eat for dinner.

begin:vcard
fn:Rogelio M. Serrano Jr
n:M. Serrano Jr;Rogelio
org:SMSG Communications Philippines;Technical Department
adr:;;Republic of the Philippines
email;internet:[EMAIL PROTECTED]
title:Programmer
tel;work:+6327534145
tel;home:+6329527026
tel;cell:+639209202267
x-mozilla-html:FALSE
version:2.1
end:vcard



signature.asc
Description: OpenPGP digital signature

[2.6 patch] net/ipv4/ipvs/: remove unused exports

[Adrian Bunk]

This patch removes the following unused EXPORT_SYMBOL's:
- ip_vs_try_bind_dest
- ip_vs_find_dest

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 net/ipv4/ipvs/ip_vs_conn.c |1 -
 net/ipv4/ipvs/ip_vs_ctl.c  |1 -
 2 files changed, 2 deletions(-)

ad9f400d4f66ea3423f97e609d6ef2572055c603 
diff --git a/net/ipv4/ipvs/ip_vs_conn.c b/net/ipv4/ipvs/ip_vs_conn.c
index b7eeae6..0a9f3c3 100644
--- a/net/ipv4/ipvs/ip_vs_conn.c
+++ b/net/ipv4/ipvs/ip_vs_conn.c
@@ -441,7 +441,6 @@ struct ip_vs_dest *ip_vs_try_bind_dest(struct ip_vs_conn 
*cp)
} else
return NULL;
 }
-EXPORT_SYMBOL(ip_vs_try_bind_dest);
 
 
 /*
diff --git a/net/ipv4/ipvs/ip_vs_ctl.c b/net/ipv4/ipvs/ip_vs_ctl.c
index 3c4d22a..b64cf45 100644
--- a/net/ipv4/ipvs/ip_vs_ctl.c
+++ b/net/ipv4/ipvs/ip_vs_ctl.c
@@ -604,7 +604,6 @@ struct ip_vs_dest *ip_vs_find_dest(__be32 daddr, __be16 
dport,
ip_vs_service_put(svc);
return dest;
 }
-EXPORT_SYMBOL(ip_vs_find_dest);
 
 /*
  *  Lookup dest by {svc,addr,port} in the destination trash.

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

[RFC: 2.6 patch] add -fno-tree-scev-cprop to KBUILD_CFLAGS

[Adrian Bunk]

The gcc from svn that will become gcc 4.3 generates libgcc calls in 
cases like the following (on 32bit architectures):

<--  snip  -->

static inline void timespec_add_ns(struct timespec *a, u64 ns)
{
...
while(ns >= NSEC_PER_SEC) {
ns -= NSEC_PER_SEC;
a->tv_sec++;
}
...

<--  snip  -->

It can make sense to emit assembler code doing division for such C code -
that doesn't seem to be something that would generally be wrong.

But the kernel does (at least on some architectures) not link with 
libgcc or ship other code providing the required libgcc functions.

Richard Guenther suggested in gcc bug #32044 to use -fno-tree-scev-cprop 
(new option in gcc 4.3) as a workaround and I confirmed that it fixes 
the compilation.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
f2357fcb8addd855f1be6ac9fdf4ef3c3ab8256d 
diff --git a/Makefile b/Makefile
index e28dde8..9d8a831 100644
--- a/Makefile
+++ b/Makefile
@@ -527,6 +527,9 @@ KBUILD_CFLAGS += $(call 
cc-option,-Wdeclaration-after-statement,)
 # disable pointer signed / unsigned warnings in gcc 4.0
 KBUILD_CFLAGS += $(call cc-option,-Wno-pointer-sign,)
 
+# workaround to avoid gcc 4.3 emitting libgcc calls (see gcc bug #32044)
+KBUILD_CFLAGS += $(call cc-option,-fno-tree-scev-cprop,)
+
 # Add user supplied CPPFLAGS, AFLAGS and CFLAGS as the last assignments
 # But warn user when we do so
 warn-assign = \

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] sched_fair.c: make sched_nr_latency static

[Adrian Bunk]

sched_nr_latency can now become static.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
fc6c112552b2eb423a29c2b0d100e97db3a47c45 
diff --git a/kernel/sched_fair.c b/kernel/sched_fair.c
index d3c0307..ee00da2 100644
--- a/kernel/sched_fair.c
+++ b/kernel/sched_fair.c
@@ -43,7 +43,7 @@ unsigned int sysctl_sched_min_granularity = 100ULL;
 /*
  * is kept at sysctl_sched_latency / sysctl_sched_min_granularity
  */
-unsigned int sched_nr_latency = 20;
+static unsigned int sched_nr_latency = 20;
 
 /*
  * After fork, child runs first. (default) If set to 0 then

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 patch] remove references to "make dep"

[Adrian Bunk]

"make dep" is no longer required in kernel 2.6, but was still mentioned 
in some places.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---

 arch/arm/mach-imx/Makefile |3 ---
 arch/arm/mach-netx/Makefile|3 ---
 arch/frv/kernel/gdb-stub.c |2 +-
 arch/mips/tx4927/common/Makefile   |4 
 arch/mips/tx4938/common/Makefile   |4 
 arch/mips/tx4938/toshiba_rbtx4938/Makefile |4 
 arch/sh64/kernel/Makefile  |4 
 arch/sh64/lib/Makefile |4 
 arch/sh64/mach-cayman/Makefile |4 
 arch/sh64/mm/Makefile  |4 
 arch/xtensa/mm/Makefile|4 
 arch/xtensa/platform-iss/Makefile  |5 -
 12 files changed, 1 insertion(+), 44 deletions(-)

b7a9343060fc2ea1cf40c731c3eb46bab1d38bae 
diff --git a/arch/arm/mach-imx/Makefile b/arch/arm/mach-imx/Makefile
index 02272aa..88d5e61 100644
--- a/arch/arm/mach-imx/Makefile
+++ b/arch/arm/mach-imx/Makefile
@@ -1,9 +1,6 @@
 #
 # Makefile for the linux kernel.
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
 
 # Object file lists.
 
diff --git a/arch/arm/mach-netx/Makefile b/arch/arm/mach-netx/Makefile
index 18785ff..7ce4ba9 100644
--- a/arch/arm/mach-netx/Makefile
+++ b/arch/arm/mach-netx/Makefile
@@ -1,9 +1,6 @@
 #
 # Makefile for the linux kernel.
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
 
 # Object file lists.
 
diff --git a/arch/frv/kernel/gdb-stub.c b/arch/frv/kernel/gdb-stub.c
index e89cad1..48a0393 100644
--- a/arch/frv/kernel/gdb-stub.c
+++ b/arch/frv/kernel/gdb-stub.c
@@ -87,7 +87,7 @@
  *  Example:
  *$ cd ~/linux
  *$ make menuconfig 
- *$ make dep; make vmlinux
+ *$ make vmlinux
  *
  *  Step 3:
  *  Download the kernel to the remote target and start
diff --git a/arch/mips/tx4927/common/Makefile b/arch/mips/tx4927/common/Makefile
index 1837578..e862961 100644
--- a/arch/mips/tx4927/common/Makefile
+++ b/arch/mips/tx4927/common/Makefile
@@ -1,10 +1,6 @@
 #
 # Makefile for common code for Toshiba TX4927 based systems
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
 
 obj-y  += tx4927_prom.o tx4927_setup.o tx4927_irq.o
 
diff --git a/arch/mips/tx4938/common/Makefile b/arch/mips/tx4938/common/Makefile
index 8352eca..eff3d1d 100644
--- a/arch/mips/tx4938/common/Makefile
+++ b/arch/mips/tx4938/common/Makefile
@@ -1,10 +1,6 @@
 #
 # Makefile for common code for Toshiba TX4927 based systems
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
 
 obj-y  += prom.o setup.o irq.o
 obj-$(CONFIG_KGDB) += dbgio.o
diff --git a/arch/mips/tx4938/toshiba_rbtx4938/Makefile 
b/arch/mips/tx4938/toshiba_rbtx4938/Makefile
index 675bb1c..2316dd7 100644
--- a/arch/mips/tx4938/toshiba_rbtx4938/Makefile
+++ b/arch/mips/tx4938/toshiba_rbtx4938/Makefile
@@ -1,10 +1,6 @@
 #
 # Makefile for common code for Toshiba TX4927 based systems
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
 
 obj-y  += prom.o setup.o irq.o spi_eeprom.o
 
diff --git a/arch/sh64/kernel/Makefile b/arch/sh64/kernel/Makefile
index e3467bd..8443d3b 100644
--- a/arch/sh64/kernel/Makefile
+++ b/arch/sh64/kernel/Makefile
@@ -8,10 +8,6 @@
 #
 # Makefile for the Linux sh64 kernel.
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
 
 extra-y:= head.o init_task.o vmlinux.lds
 
diff --git a/arch/sh64/lib/Makefile b/arch/sh64/lib/Makefile
index 6a4cc3f..754d725 100644
--- a/arch/sh64/lib/Makefile
+++ b/arch/sh64/lib/Makefile
@@ -8,10 +8,6 @@
 #
 # Makefile for the SH-5 specific library files..
 #
-# Note! Dependencies are done automagically by 'make dep', which also
-# removes any old dependencies. DON'T put your own dependencies here
-# unless it's something special (ie not a .c file).
-#
 
 # Panic should really be compiled as PIC
 lib-y  := udelay.o c-checksum.o dbg.o io.o panic.o memcpy.o copy_user_memcpy.o 
\
diff --git a/arch/sh64/mach-cayman/Makefile b/arch/sh64/mach-cayman/Makefile
index 67a2258..847c828 100644
--- a/arch/sh64/mach-cayman/Makefile
+++ b/arch/sh64/mach-cayman/Makefile
@@ -1,10 +1,6 

[RFC: 2.6 patch] MAINTAINERS: remove the MTRR entry

[Adrian Bunk]

I haven't seen Richard doing MTRR related work for quite some time, and 
the "X86 ARCHITECTURE" entry in MAINTAINERS already covers the 
people currently responsible for this code.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
abbbf23fd306fc62d3b13c8e199142b3409d5ebd 
diff --git a/MAINTAINERS b/MAINTAINERS
index 1c7c229..66d60b3 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -2591,13 +2591,6 @@ L:   
https://tango.0pointer.de/mailman/listinfo/s270-linux
 W: http://0pointer.de/lennart/tchibo.html
 S: Maintained
 
-MTRR AND SIMILAR SUPPORT [i386]
-P: Richard Gooch
-M: [EMAIL PROTECTED]
-L: linux-kernel@vger.kernel.org
-W: http://www.atnf.csiro.au/~rgooch/linux/kernel-patches.html
-S: Maintained
-
 MULTIMEDIA CARD (MMC), SECURE DIGITAL (SD) AND SDIO SUBSYSTEM
 P: Pierre Ossman
 M: [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/

[2.6 patch] include/linux/sysctl.h: remove empty #else

[Adrian Bunk]

This patch removes an empty #else.

Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>

---
8e3fb6d59ceb3fbb853c0d74f1aa0a73de90af97 
diff --git a/include/linux/sysctl.h b/include/linux/sysctl.h
index e99171f..4c1694d 100644
--- a/include/linux/sysctl.h
+++ b/include/linux/sysctl.h
@@ -1070,8 +1070,6 @@ struct ctl_table_header *register_sysctl_table(struct 
ctl_table * table);
 void unregister_sysctl_table(struct ctl_table_header * table);
 int sysctl_check_table(struct ctl_table *table);
 
-#else /* __KERNEL__ */
-
 #endif /* __KERNEL__ */
 
 #endif /* _LINUX_SYSCTL_H */

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

Re: [PATCH 2/2] Version 11 (2.6.24-rc2) Smack: Simplified Mandatory Access Control Kernel

[Casey Schaufler]

--- Eric Paris <[EMAIL PROTECTED]> wrote:

> [snip from fs/super.c:vfs_kern_mount() just for reference]
> if (data) {
> secdata = alloc_secdata();
> if (!secdata)
> goto out_mnt;
> 
> error = security_sb_copy_data(type, data, secdata);
> if (error)
> goto out_free_secdata;
> }
> 
> error = type->get_sb(type, flags, name, data, mnt);
> if (error < 0)
> goto out_free_secdata;
> BUG_ON(!mnt->mnt_sb);
> 
> error = security_sb_kern_mount(mnt->mnt_sb, secdata);
> if (error)
> goto out_sb;
> [end snip]
> 
> > +/**
> > + * smack_sb_copy_data - copy mount options data for processing
> > + * @type: file system type
> > + * @orig: where to start
> > + * @smackopts
> > + *
> > + * Returns 0 on success or -ENOMEM on error.
> > + *
> > + * Copy the Smack specific mount options out of the mount
> > + * options list.
> > + */
> > +static int smack_sb_copy_data(struct file_system_type *type, void *orig,
> > + void *smackopts)
> > +{
> > +   char *cp, *commap, *otheropts, *dp;
> > +
> > +   /* Binary mount data: just copy */
> > +   if (type->fs_flags & FS_BINARY_MOUNTDATA) {
> > +   copy_page(smackopts, orig);
> > +   return 0;
> > +   }
> 
> So given NFS, which may have passed you a nfs_mount_data,
> nfs_parsed_mount_data, or a nfs_clone_mount struct one page is going
> to get coppied back out to the VFS.
> > +
> > +   otheropts = (char *)get_zeroed_page(GFP_KERNEL);
> > +   if (otheropts == NULL)
> > +   return -ENOMEM;
> > +
> > +   for (cp = orig, commap = orig; commap != NULL; cp = commap + 1) {
> > +   if (strstr(cp, SMK_FSDEFAULT) == cp)
> > +   dp = smackopts;
> > +   else if (strstr(cp, SMK_FSFLOOR) == cp)
> > +   dp = smackopts;
> > +   else if (strstr(cp, SMK_FSHAT) == cp)
> > +   dp = smackopts;
> > +   else if (strstr(cp, SMK_FSROOT) == cp)
> > +   dp = smackopts;
> > +   else
> > +   dp = otheropts;
> > +
> > +   commap = strchr(cp, ',');
> > +   if (commap != NULL)
> > +   *commap = '\0';
> > +
> > +   if (*dp != '\0')
> > +   strcat(dp, ",");
> > +   strcat(dp, cp);
> > +   }
> > +
> > +   strcpy(orig, otheropts);
> > +   free_page((unsigned long)otheropts);
> > +
> > +   return 0;
> > +}
> > +
> > +/**
> > + * smack_sb_kern_mount - Smack specific mount processing
> > + * @sb: the file system superblock
> > + * @data: the smack mount options
> > + *
> > + * Returns 0 on success, an error code on failure
> > + */
> > +static int smack_sb_kern_mount(struct super_block *sb, void *data)
> > +{
> > +   struct dentry *root = sb->s_root;
> > +   struct inode *inode = root->d_inode;
> > +   struct superblock_smack *sp = sb->s_security;
> > +   struct inode_smack *isp;
> > +   char *op;
> > +   char *commap;
> > +   char *nsp;
> > +
> > +   spin_lock(>smk_sblock);
> > +   if (sp->smk_initialized != 0) {
> > +   spin_unlock(>smk_sblock);
> > +   return 0;
> > +   }
> > +   sp->smk_initialized = 1;
> > +   spin_unlock(>smk_sblock);
> > +
> > +   for (op = data; op != NULL; op = commap) {
> 
> Here you walk this page of binary NFS data looking for your stuff.
> And while I assume its unlikely you find anything you like on this
> page and go wrong, its not impossible.
> 
> SELinux tried to solve this problem right here in its equivalent
> function years ago, but it has since been despised by the FS people
> and now i'm trying to make everyone happy.  I'd love you comment on
> how you plan to support NFS and other filesystems which use
> FS_BINARY_MOUNTDATA)

I think I'd best say that I need to look at what you've got so far
and see how best to make use of it, because my current plan is nowhere
near as good as yours.


Casey Schaufler
[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: Temporary lockup on loopback block device

[Mikulas Patocka]

> > > Arguably we just have the wrong backing-device here, and what we 
> > > should do is to propagate the real backing device's pointer through 
> > > up into the filesystem.  There's machinery for this which things 
> > > like DM stacks use.

Just thinking about the new implementation --- you shouldn't really 
propagate physical block device's backing_device into loopback device.

If you leave it as is (each loop device has it's own backing store), you 
can nicely avoid the long-standing loopback deadlock coming from the fact 
that flushing one page on loopback device can generate several more dirty 
pages on the filesystem.

If you let loopback device and physical device have the same backing 
store, then it can go wild creating more and more dirty pages up to a 
memory exhaustion. If you let them have different backing stores, it can't 
happen --- loopback flushing will just wait until the pages on the 
filesystem are written.

Mikulas

> So I compiled it and I don't see any more lock-ups. The writeback loop 
> doesn't depend on any global page count, so the above scenario can't 
> happen here. Good.
> 
> Mikulas
> 
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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:

[David Miller]

From: Eric Dumazet <[EMAIL PROTECTED]>
Date: Sat, 10 Nov 2007 02:42:42 +0100

> [NET] adds a missing include 
> 
> Signed-off-by: Eric Dumazet <[EMAIL PROTECTED]>

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

Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets

[Adrian Bunk]

On Sat, Nov 10, 2007 at 09:55:06PM +0100, Guillaume Chazarain wrote:
> Hi,
> 
> On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> > The variable K64BIT can now be used to select the
> > value of CONFIG_64BIT.
> 
> Why not calling the environment variable CONFIG_64BIT,
> in preparation of the day when all CONFIG_ variables can
> be passed by environment variables?

What exactly are the use cases where someone would need this?

> Guillaume

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 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

[Adrian Bunk]

On Sat, Nov 10, 2007 at 09:40:38PM +0100, Sam Ravnborg wrote:

> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
>...

I seriously question this would be "the right thing".

32/64bit isn't that special that this and only this option would require
special casing, and the KISS principle of having only one way to specify 
something like this has it's advantages.

>   Sam

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: cd/dvd inaccessible in 2.6.24-rc2

[Will Trives]

Hello Jeff,

Yes it is. I'll keep testing with previous kernels.

Dmesg does look different with 2.6.23 vs 2.6.24-rc2

This is 2.6.23 :

scsi8 : pata_jmicron
scsi9 : pata_jmicron
ata9: PATA max UDMA/100 cmd 0x0001c000 ctl 0x0001c102 bmdma 
0x0001c400 irq 17
ata10: PATA max UDMA/100 cmd 0x0001c200 ctl 0x0001c302 bmdma 
0x0001c408 irq 17
ata9.00: ATAPI: BENQDVD DD DW1640, BSRB, max UDMA/33
ata9.00: configured for UDMA/33
ata9: EH pending after completion, repeating EH (cnt=4)
scsi 8:0:0:0: CD-ROMBENQ DVD DD DW1640BSRB PQ: 0 ANSI: 5


This is 2.6.24-rc2 :

scsi8 : pata_jmicron
scsi9 : pata_jmicron
ata9: PATA max UDMA/100 cmd 0xc000 ctl 0xc100 bmdma 0xc400 irq 17
ata10: PATA max UDMA/100 cmd 0xc200 ctl 0xc300 bmdma 0xc408 irq 17
ata9.00: ATAPI: BENQ DVD DD DW1640, BSRB, max UDMA/33
ata9.00: configured for UDMA/33
scsi 8:0:0:0: CD-ROM BENQ DVD DD DW1640 BSRB PQ: 0 ANSI: 5

Regards,

Will Trives

On Sat, 2007-11-10 at 18:35 -0500, Jeff Garzik wrote:
> Will Trives wrote:
> > Hello,
> > 
> > Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
> > Chipset: Intel P35 + ICH9R 
> > PATA port runs off JMicron controller
> > CD/DVD Device: BENQ DW1640 16X
> > 
> > I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
> > 2.6.23. Basically the drive is detected OK, everything looks ok but as
> > soon as I go to use it errors like this occur:
> 
> Is 2.6.24-rc1 also broken?
> 
>   Jeff
> 
> 

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

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, John Johansen wrote:


On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:

On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:



Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.


the model of being able to add restrictions would still handle this. make
two shell scripts (one to start each browser profile) and set the AA policy
for these scripts to only have access to the appropriate directories.


yes you could do this, though I tend to want it just so I can control
which of my files firefox should be able to touch, without messing
up system policy.


right, I was showing how you could easily create two different firefox 
browsers being able to access different things, and how it could be done 
with user-based policies that tighten restrictions only (which are being 
considered)


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] Fix CONFIG_SMP=n build error on ppc64

[Kamalesh Babulal]

On Sat, Nov 10, 2007 at 02:59:29PM -0600, Olof Johansson wrote:
> [POWERPC] Fix CONFIG_SMP=n build error
> 
> The patch "KVM: fix !SMP build error" change the way smp_call_function()
> actually uses the passed in function names on non-SMP builds. So
> previously it was never caught that the function passed in was never
> actually defined.
> 
> This causes a build error on ppc64_defconfig + CONFIG_SMP=n:
> 
> arch/powerpc/mm/tlb_64.c: In function 'pgtable_free_now':
> arch/powerpc/mm/tlb_64.c:71: error: 'pte_free_smp_sync' undeclared (first use 
> in this function)
> arch/powerpc/mm/tlb_64.c:71: error: (Each undeclared identifier is reported 
> only once
> arch/powerpc/mm/tlb_64.c:71: error: for each function it appears in.)
> 
> So we need to define it even if CONFIG_SMP is off. Either that or ifdef
> out the smp_call_function() call, but that's ugly.
Hi,

Thanks, the patch fixes the build failure.

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

diff --git a/arch/powerpc/mm/tlb_64.c b/arch/powerpc/mm/tlb_64.c
index eafbca5..e2d867c 100644
--- a/arch/powerpc/mm/tlb_64.c
+++ b/arch/powerpc/mm/tlb_64.c
@@ -54,12 +54,10 @@ unsigned long pte_freelist_forced_free;
  ((PAGE_SIZE - sizeof(struct pte_freelist_batch)) \ 
/ sizeof(pgtable_free_t))

-#ifdef CONFIG_SMP
 static void pte_free_smp_sync(void *arg)
 { 
  /* Do nothing, just ensure we sync with all CPUs */
 } 
-#endif

 /* This is only called when we are critically out of memory
  * (and fail to get a page in pte_free_tlb).

-- 
Thanks & Regards,
Kamalesh Babulal,
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: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 03:52:31PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:
>



>
> a question for Crispin,
>   is there a wildcard replacement for username? so that you could grant 
> permission to /home/$user/.mozilla.. and grant each user access to only 
> their own stuff? I realize that in this particular example the underlying 
> DAC will handle it, but I can see other cases where people may want to have 
> users more intermixed (say webserver files or directories for example)
>
A variable no.  But the current iteration does allow specifying permissions
for files that are owned by the user.  The method to do so has been
changed from the current posting and may change again as their is some
debate as to how best express this.

So system policy can express something similar by doing

owner rw @{HOME}/.mozilla,

where @{HOME} is a user side variable that gets expanded into the
locations of the systems home directories.

>> Allowing a user to tweak (under constraints) their settings might allow
>> them to do something like create two mozilla profiles which are isolated
>> from each other, so that the profile they use for general web surfing
>> is isolated from the one they use for online banking.
>
> the model of being able to add restrictions would still handle this. make 
> two shell scripts (one to start each browser profile) and set the AA policy 
> for these scripts to only have access to the appropriate directories.
>
yes you could do this, though I tend to want it just so I can control
which of my files firefox should be able to touch, without messing
up system policy.


pgpkawNwaiQ3a.pgp
Description: PGP signature

Re: [PATCH] time: fix sysfs_show_{available,current}_clocksources() buffer overflow problem

[WANG Cong]

On Sun, Nov 11, 2007 at 11:29:59AM +0800, Miao Xie wrote:
>on 2007-11-8 20:11 WANG Cong wrote:
>>On Thu, Nov 08, 2007 at 07:47:41PM +0800, WANG Cong wrote:
>>>Yes, snprintf is safer than sprintf. But here, the 'count' will be
>>>mis-pointed when snprintf returns no less than PAGE_SIZE (what you called
>>>overflow). So you may also need:
>>>
>>> if (unlikely(count >= PAGE_SIZE))
>>> count = PAGE_SIZE - 1;
>>>
>>>Just a simple guess. ;)
>>
>>Or try scnprintf. ;)
>
>We have discussed this problem. We think that it is better to return the 
>return
>value of kernel directly because this is the specification of the sysfs.
>
>  (Version:2.6.24-rc2,File:Documentation/filesystems/sysfs.txt:198-201):
>  198 - show() methods should return the number of bytes printed into the
>  199   buffer. This is the return value of snprintf().
>  200
>  201 - show() should always use snprintf().
>
>And the function which calls the show() methods uses BUG_ON() to check the
>return value. If the return value is too big,it means something wrong.
>
>If we use scnprintf, we may not know whether the resulting string is 
>truncated
>or not. Maybe A big bug is ignored.
>

Well, i know little about sysfs. So it was just a hint.

Anyway, thanks for your input!


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] improved hacks to allow -rt to run kernbench on POWER

[Benjamin Herrenschmidt]

> Removed this as well, also seemed to work.  Please note, however, that
> this is just running kernbench.  But this did seem to get rid of some
> of the warnings as well.  ;-)  Now only have the xics_startup() warning.
> 
> > Overall, looks fine !
> 
> I bet that there are more gotchas lurking in there somewhere, but in
> the meantime here is the updated patch.
> 
> Signed-off-by: Paul E. McKenney <[EMAIL PROTECTED]>
> ---

Well, I suppose the patch could go in, maybe with some ifdef's around
the bits in _switch_to, there's little point in doing that on non-rt
kernels.

Ben.

>  arch/powerpc/kernel/process.c|   16 
>  arch/powerpc/kernel/prom.c   |2 +-
>  arch/powerpc/mm/tlb_64.c |5 -
>  arch/powerpc/platforms/pseries/eeh.c |2 +-
>  drivers/of/base.c|2 +-
>  include/asm-powerpc/tlb.h|5 -
>  include/asm-powerpc/tlbflush.h   |   15 ++-
>  7 files changed, 37 insertions(+), 10 deletions(-)
> 
> diff -urpNa -X dontdiff linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c 
> linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/process.c
> --- linux-2.6.23.1-rt4/arch/powerpc/kernel/process.c  2007-10-12 
> 09:43:44.0 -0700
> +++ linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/process.c  2007-11-09 
> 13:24:46.0 -0800
> @@ -245,6 +245,8 @@ struct task_struct *__switch_to(struct t
>   struct thread_struct *new_thread, *old_thread;
>   unsigned long flags;
>   struct task_struct *last;
> + struct ppc64_tlb_batch *batch;
> + int hadbatch;
>  
>  #ifdef CONFIG_SMP
>   /* avoid complexity of lazy save/restore of fpu
> @@ -325,6 +327,15 @@ struct task_struct *__switch_to(struct t
>   }
>  #endif
>  
> + batch = &__get_cpu_var(ppc64_tlb_batch);
> + if (batch->active) {
> + hadbatch = 1;
> + if (batch->index) {
> + __flush_tlb_pending(batch);
> + }
> + batch->active = 0;
> + }
> +
>   local_irq_save(flags);
>  
>   account_system_vtime(current);
> @@ -335,6 +346,11 @@ struct task_struct *__switch_to(struct t
>  
>   local_irq_restore(flags);
>  
> + if (hadbatch) {
> + batch = &__get_cpu_var(ppc64_tlb_batch);
> + batch->active = 1;
> + }
> +
>   return last;
>  }
>  
> diff -urpNa -X dontdiff linux-2.6.23.1-rt4/arch/powerpc/kernel/prom.c 
> linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/prom.c
> --- linux-2.6.23.1-rt4/arch/powerpc/kernel/prom.c 2007-10-12 
> 09:43:44.0 -0700
> +++ linux-2.6.23.1-rt4-fix/arch/powerpc/kernel/prom.c 2007-10-28 
> 13:37:23.0 -0700
> @@ -80,7 +80,7 @@ struct boot_param_header *initial_boot_p
>  
>  extern struct device_node *allnodes; /* temporary while merging */
>  
> -extern rwlock_t devtree_lock;/* temporary while merging */
> +extern raw_rwlock_t devtree_lock;/* temporary while merging */
>  
>  /* export that to outside world */
>  struct device_node *of_chosen;
> diff -urpNa -X dontdiff linux-2.6.23.1-rt4/arch/powerpc/mm/tlb_64.c 
> linux-2.6.23.1-rt4-fix/arch/powerpc/mm/tlb_64.c
> --- linux-2.6.23.1-rt4/arch/powerpc/mm/tlb_64.c   2007-10-27 
> 22:20:57.0 -0700
> +++ linux-2.6.23.1-rt4-fix/arch/powerpc/mm/tlb_64.c   2007-11-08 
> 16:49:04.0 -0800
> @@ -133,7 +133,7 @@ void pgtable_free_tlb(struct mmu_gather 
>  void hpte_need_flush(struct mm_struct *mm, unsigned long addr,
>pte_t *ptep, unsigned long pte, int huge)
>  {
> - struct ppc64_tlb_batch *batch = &__get_cpu_var(ppc64_tlb_batch);
> + struct ppc64_tlb_batch *batch = _cpu_var(ppc64_tlb_batch);
>   unsigned long vsid, vaddr;
>   unsigned int psize;
>   real_pte_t rpte;
> @@ -180,6 +180,7 @@ void hpte_need_flush(struct mm_struct *m
>*/
>   if (!batch->active) {
>   flush_hash_page(vaddr, rpte, psize, 0);
> + put_cpu_var(ppc64_tlb_batch);
>   return;
>   }
>  
> @@ -212,12 +213,14 @@ void hpte_need_flush(struct mm_struct *m
>*/
>   if (machine_is(celleb)) {
>   __flush_tlb_pending(batch);
> + put_cpu_var(ppc64_tlb_batch);
>   return;
>   }
>  #endif /* CONFIG_PREEMPT_RT */
>  
>   if (i >= PPC64_TLB_BATCH_NR)
>   __flush_tlb_pending(batch);
> + put_cpu_var(ppc64_tlb_batch);
>  }
>  
>  /*
> diff -urpNa -X dontdiff 
> linux-2.6.23.1-rt4/arch/powerpc/platforms/pseries/eeh.c 
> linux-2.6.23.1-rt4-fix/arch/powerpc/platforms/pseries/eeh.c
> --- linux-2.6.23.1-rt4/arch/powerpc/platforms/pseries/eeh.c   2007-10-12 
> 09:43:44.0 -0700
> +++ linux-2.6.23.1-rt4-fix/arch/powerpc/platforms/pseries/eeh.c   
> 2007-10-28 15:43:54.0 -0700
> @@ -97,7 +97,7 @@ int eeh_subsystem_enabled;
>  EXPORT_SYMBOL(eeh_subsystem_enabled);
>  
>  /* Lock to avoid races due to multiple reports of an error */
> -static DEFINE_SPINLOCK(confirm_error_lock);
> 

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 05:27:51PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Alan Cox wrote:
>
>>> but how can the system know if the directory the user wants to add is
>>> reasonable or not? what if the user says they want to store their
>>> documents in /etc?
>>
>> A more clear example is wanting to wrap a specific tool with temporary
>> rules. Those rules would depend on the exact file being edited at this
>> moment - something root cannot know in advance
>> (although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
>> mv it back might work 8))
>
> the mechanism being desired was that the system administrator would setup a 
> restrictive policy and a user who wanted a more permissive policy would 
> have the ability to make it more permissive.
>
> this sort of thing is a disaster waiting to happen.
>
yep

> however, if App Armor sets things up so that there can be a system policy 
> that users cannot touch, but users can have a secondary policy that layers 
> over the system one to restrict things further it could be safe.
>
> if a sysadmin wants to have 'soft' and 'hard' limits of what a user can do, 
> they could put the 'hard' limits in the system policy (and the users 
> _cannot_ violate these limits), and then set the 'soft' limits in the users 
> default setup (similar to how .profile is set by default). if a user wants 
> to make things less restrictive they could edit or remove the per-user 
> policy, but would still not be able to violate the system policy.
>
> however, while this seems attractive, I'm not sure that madness isn't down 
> the road a little bit. since the users policy would only apply to 
> themselves, you have the situation that (DAC permissions permitting) the 
> files are available to other confined processes becouse they are running as 
> other users. this sort of thing will surprise people if the explinations 
> aren't done very carefully.
>
yes, the devil is in the details.


pgpUZ46iTW7DR.pgp
Description: PGP signature

[PATCH] log2.h: Define order_base_2() macro for convenience.

[Robert P. J. Day]

Given a number of places in the tree that need to calculate this value
explicitly, might as well just create a macro for it.

Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>

---

  run-time tested for the first several values.  note that this macro
is defined strictly in terms of rounding *up* -- i've seen no places
in the tree that require this expression to be rounded down, so i'm
not drawing that distinction.

diff --git a/include/linux/log2.h b/include/linux/log2.h
index c8cf5e8..ed121c0 100644
--- a/include/linux/log2.h
+++ b/include/linux/log2.h
@@ -190,4 +190,20 @@ unsigned long __rounddown_pow_of_two(unsigned long n)
__rounddown_pow_of_two(n)   \
  )

+/**
+ * order_base_2 - calculate the (rounded up) base 2 order of the argument
+ * @n - parameter
+ *
+ * The first few values calculated by this routine:
+ *  ob2(0) = 0
+ *  ob2(1) = 0
+ *  ob2(2) = 1
+ *  ob2(3) = 2
+ *  ob2(4) = 2
+ *  ob2(5) = 3
+ *  ... and so on.
+ */
+
+#define order_base_2(n) ilog2(roundup_pow_of_two(n))
+
 #endif /* _LINUX_LOG2_H */

-- 

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: Temporary lockup on loopback block device

[Mikulas Patocka]

On Sun, 11 Nov 2007, Mikulas Patocka wrote:

> On Sat, 10 Nov 2007, Andrew Morton wrote:
> 
> > On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL 
> > PROTECTED]> wrote:
> > 
> > > Hi
> > > 
> > > I am experiencing a transient lockup in 'D' state with loopback device. 
> > > It 
> > > happens when process writes to a filesystem in loopback with command like
> > > dd if=/dev/zero of=/s/fill bs=4k 
> > > 
> > > CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in 
> > > congestion_wait called from balance_dirty_pages.
> > > 
> > > After about 30 seconds, the lockup is gone and dd resumes, but it locks 
> > > up 
> > > soon again.
> > > 
> > > I added a printk to the balance_dirty_pages
> > > printk("wait: nr_reclaimable %d, nr_writeback %d, dirty_thresh %d, 
> > > pages_written %d, write_chunk %d\n", nr_reclaimable, 
> > > global_page_state(NR_WRITEBACK), dirty_thresh, pages_written, 
> > > write_chunk);
> > > 
> > > and it shows this during the lockup:
> > > 
> > > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > > pages_written 1021, write_chunk 1522
> > > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > > pages_written 1021, write_chunk 1522
> > > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > > pages_written 1021, write_chunk 1522
> > > 
> > > What apparently happens:
> > > 
> > > writeback_inodes syncs inodes only on the given wbc->bdi, however 
> > > balance_dirty_pages checks against global counts of dirty pages. So if 
> > > there's nothing to sync on a given device, but there are other dirty 
> > > pages 
> > > so that the counts are over the limit, it will loop without doing any 
> > > work.
> > > 
> > > To reproduce it, you need totally idle machine (no GUI, etc.) -- if 
> > > something writes to the backing device, it flushes the dirty pages 
> > > generated by the loopback and the lockup is gone. If you add printk, 
> > > don't 
> > > forget to stop klogd, otherwise logging would end the lockup.
> > 
> > erk.
> > 
> > > The hotfix (that I verified to work) is to not set wbc->bdi, so that all 
> > > devices are flushed ... but the code probably needs some redesign (i.e. 
> > > either account per-device and flush per-device, or account-global and 
> > > flush-global).
> > > 
> > > Mikulas
> > > 
> > > 
> > > diff -u -r ../x/linux-2.6.23.1/mm/page-writeback.c mm/page-writeback.c
> > > --- ../x/linux-2.6.23.1/mm/page-writeback.c 2007-10-12 
> > > 18:43:44.0 +0200
> > > +++ mm/page-writeback.c 2007-11-10 20:32:43.0 +0100
> > > @@ -214,7 +214,6 @@
> > > 
> > >   for (;;) {
> > >   struct writeback_control wbc = {
> > > - .bdi= bdi,
> > >   .sync_mode  = WB_SYNC_NONE,
> > >   .older_than_this = NULL,
> > >   .nr_to_write= write_chunk,
> > 
> > Arguably we just have the wrong backing-device here, and what we should do
> > is to propagate the real backing device's pointer through up into the
> > filesystem.  There's machinery for this which things like DM stacks use.
> 
> If you change loopback backing-device, you just turn this nicely 
> reproducible example into a subtle race condition that can happen whenever 
> you use loopback or not. Think, what happens when different process 
> dirties memory:
> 
> You have process "A" that dirtied a lot of pages on device "1" but has not 
> started writing them.
> You have process "B" that is trying to write to device "2", sees dirty 
> page count over limit, but can't do anything about it, because it is only 
> allowed to flush pages on device "2". --- so it endlessly loops.
> 
> If you want to use the current flushing semantics, you just have to audit 
> the whole kernel to make sure that if some process sees over-limit dirty 
> page count, there is another process that is flushing the pages. Currently 
> it is not true, the "dd" process sees over-limit count, but there is 
> no-one writing.
> 
> > I wonder if the post-2.6.23 changes happened to make this problem go away.
> 
> I will try 2.6.24-rc2, but I don't think the root cause of this went away. 
> Maybe you just reduced probability.
> 
> Mikulas

So I compiled it and I don't see any more lock-ups. The writeback loop 
doesn't depend on any global page count, so the above scenario can't 
happen here. Good.

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 06:17:30PM -0800, Casey Schaufler wrote:
> 
> --- Crispin Cowan <[EMAIL PROTECTED]> wrote:
> 
> > Dr. David Alan Gilbert wrote:
> > ...
> >
> > Can you explain why you want a non-privileged user to be able to edit
> > policy? I would like to better understand the problem here.
> > 
> > Note that John Johansen is also interested in allowing non-privileged
> > users to manipulate AppArmor policy, but his view was to only allow a
> > non-privileged user to further tighten the profile on a program. To me,
> > that adds complexity with not much value, but if lots of users want it,
> > then I'm wrong :)
> 
> Now this is getting interesting. It looks to me as if you've implemented
> a mandatory access control scheme that some people would like to be able
> to use as a discretionary access control scheme. This is creepy after
> seeing the MCS implementation in SELinux, which is also a DAC scheme
> wacked out of a MAC scheme. Very interesting indeed.
> 
hehe perhaps.  There are lots of issues involved with doing something
like this and there are more important issues to address first.
I also don't see it so much of a DAC scheme as a user defining a MAC
for their own processes they don't trust.  An application so confined
would not have the ability to change its confinement.


pgpa6YsxZ8sSj.pgp
Description: PGP signature

Re: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 01:28:25PM -0800, [EMAIL PROTECTED] wrote:
> On Sat, 10 Nov 2007, Andi Kleen wrote:
>
>> Crispin Cowan <[EMAIL PROTECTED]> writes:
>>
>> The document should be a good base for a merge.
>>
>>> * A confined process can operate on a file descriptor passed to it
>>>   by an unconfined process, even if it manipulates a file not in the
>>>   confined process's profile. To block this attack, confine the
>>>   process that passed the file descriptor.
>>
>> That is the only thing that tripped me up a bit while reading the 
>> document.
>> Can you expand a bit on the reasons why the fd is not rechecked in
>> the context of the target process? Best do it in a new version of the
>> document.
>
> from prior discussions I understand that the problem is that it's not easy 
> (or nessasarily possible) to figure out the path to the fd, so what do you 
> check?
>
> if the file has been removed there _is_ no path to the fd.
>
> with hard links there could be many paths to the fd, the only way to find 
> them would be to search the entire filesystem.
>
> as a result App Armor has decided not to try and address this, but is 
> documenting it as a limitation.
>
Actually no.  The unconfined fd being passed in is explicitly different
than and fd being passed between two confined processes.  In the
unconfined parent passing an fd into a confined child the fd isn't
reevaluated.  In the case of confined parent to confined child the
the struct file is reevaluated.

As to the implementation issue of revalidation.  The path name to file can
be found as struct file stores both the vfsmnt and dentry.  With that said
there are a couple cases where the pathname can't be found.
- the file has been deleted
- the path has become disconnected.

In short under file revalidation deleted file are given a pass and
disconnected files fail.

For a more in depth explanation look at
http://forgeftp.novell.com//apparmor/LKML_Submission-Oct-07/techdoc.pdf

regards
john



pgpGhNMsSWIF9.pgp
Description: PGP signature

NFSv4 broken in -mm (MMOM "10-Nov-2007 22:46")

[Erez Zadok]

I'm using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
22:46".  Creating dummy f/s and exporting it to localhost, mounting it as
nfsv4, then

# touch foo
touch: setting times of `foo': No such file or directory
# echo > bar
bar: Invalid argument

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

Re: [PATCH] time: fix sysfs_show_{available,current}_clocksources() buffer overflow problem

[Miao Xie]

on 2007-11-8 20:11 WANG Cong wrote:

On Thu, Nov 08, 2007 at 07:47:41PM +0800, WANG Cong wrote:

Yes, snprintf is safer than sprintf. But here, the 'count' will be
mis-pointed when snprintf returns no less than PAGE_SIZE (what you called
overflow). So you may also need:

if (unlikely(count >= PAGE_SIZE))
count = PAGE_SIZE - 1;

Just a simple guess. ;)


Or try scnprintf. ;)


We have discussed this problem. We think that it is better to return the return
value of kernel directly because this is the specification of the sysfs.

  (Version:2.6.24-rc2,File:Documentation/filesystems/sysfs.txt:198-201):
  198 - show() methods should return the number of bytes printed into the
  199   buffer. This is the return value of snprintf().
  200
  201 - show() should always use snprintf().

And the function which calls the show() methods uses BUG_ON() to check the
return value. If the return value is too big,it means something wrong.

If we use scnprintf, we may not know whether the resulting string is truncated
or not. Maybe A big bug is ignored.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[John Johansen]

On Sat, Nov 10, 2007 at 01:24:46PM -0800, Crispin Cowan wrote:
> Andi Kleen wrote:
> > Crispin Cowan <[EMAIL PROTECTED]> writes:
> >
> > The document should be a good base for a merge.
> >
> >   
> >> * A confined process can operate on a file descriptor passed to it
> >>   by an unconfined process, even if it manipulates a file not in the
> >>   confined process's profile. To block this attack, confine the
> >>   process that passed the file descriptor.
> >> 
> >
> > That is the only thing that tripped me up a bit while reading the document.
> > Can you expand a bit on the reasons why the fd is not rechecked in
> > the context of the target process? Best do it in a new version of the
> > document.
> >   
> The reason is a disgusting implementation problem, so instead of going
> into lots of detail, I just disclaimed it.
> 
Well perhaps a little disgusting but it isn't the reason.  We discussed
this on the rewrite with the vfsmnt passed through the vfs.  We could
have changed the implementation but in the end decided to to leave it
in place for the time being.

> The excuse :) is that UNIX/Linux already has an object-capability
> orientation with respect to passing file descriptors around; you can
> pass an FD to a process that doesn't have access to the file, and DAC
> (user ownership & such) won't check it either.
> 
yep, the discussion really did come down to object capability and
unconfined processes.

> This aspect of the semantics is not my favorite, but it is at least
> consistent with the AppArmor view that unconfined processes can do
> absolutely anything and AppArmor won't try to stop them.
> 
and the the other major point surfaces

> The actual reason: FDs that are passed from some other *confined*
> process actually are checked, because the FD has data structures on it
> that we can use to hook for checking. The problem is that an FD from a
> completely unconfined process has no such data structures. To fix this,
> we would have to check access on every single read and write, and that
> would make performance suck.
> 
Not so, we can add that, and I have prototyped code to do so.  The issue
really is about how unconfined processes should interact with confined
processes.

> If there is a clean way to close this issue, I would be interested.
> 
What is considered a clean way to change this has been an on and
off again discussion, its been about 9 months since we last discussed
it so I am not surprised Crispin has paged it out.

The issue really does come down to how to express the interaction of
confined and unconfined tasks in policy.  The discussion always comes
back to object capabilities, unconfined's behavior, and how to
best express it.

> On the other hand, there is a fairly passionate community of Object
> Capability fans who really want access rights to be delegable, and the
> other way to go is to remove all checking on passed FDs.
> 
> There are advantages to going both ways, and I don't believe that
> AppArmor is locked in stone, so either one could be chosen in the
> future. See this interesting thread on LSM
> http://marc.info/?t=11946492933=1=2
> 
No it isn't, the behavior was intended to be revisited when we
had IPC, and or a prototype for expressing which file objects can be
passed.


pgpCgVzBvhSmi.pgp
Description: PGP signature

Re: [RFC 13/13] Char: nozomi, cleanup read and write

[Frank Seidel]

On Samstag 10 November 2007 23:04:41, you (Jiri Slaby) wrote:
> On 11/10/2007 05:15 PM, Adrian Bunk wrote:
> > On Fri, Nov 09, 2007 at 06:51:35PM -0500, Jiri Slaby wrote:
> >> ...
> >> -  if (size_bytes - i == 2) {
> >> +  if (unlikely(size_bytes - i == 2)) {
> >> ...
> > 
> > Please don't add likely/unlikely in drivers unless it brings a 
> > measurable improvement.
> Why? Anyway I think this is the case. The body of the then branch is executed 
> at
> most once, while the else branch each time but last. If you write/read 1002
> bytes, it means 250:1. ...and it's invoked from interrupt too...

I just did some measurements of how often (under real life scenarios like
downloading big files, websurfing, chat and ssh sessions) those pathes are
used.

While in the read_mem32 the unlikekly really seems to be of no use at all (the
switch-case ahead seems to be hit nearly always), the unlikely in the 
write_mem32 seems to be fine.
I compared after each 30 seconds and got median ratio of 1381:1 (for the
likely path) after about 20 minutes, i see a range between 1046:1 and
3511:1. So i wouldn't call it a bad guess from my beginners point of view.

Thanks,
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: patch conflicts (MMOTM "10-Nov-2007 22:46")

[Andrew Morton]

On Sat, 10 Nov 2007 20:04:35 -0500 Erez Zadok <[EMAIL PROTECTED]> wrote:

> Andrew,
> 
> I'm using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
> 22:46".
> 
> 1. I was getting a bunch of patch conflicts, until I realized that this
>latest set of patches was to be applied against 2.6.24-rc2 (your mm.patch
>gave it away :-) The last snapshot was against 2.6.24-rc1.
> 
>What should be the official way in which people using the above URL know
>which base to apply it against: is looking at mm.patch OK?

That would work.

It's usually very obvious, because the first patch is `origin.patch'
(Linus's latest tree against his most-recent-release) and there's no way in
which that patch will apply to the wrong tree.

It just happened that the particular series you grabbed had an empty
origin.patch.

>  If so, then
>I'd like to suggest that you move mm.patch to the very beginning of your
>series file: that way if the first patch causes a conflict, it'd be a
>hint to the person to investigate why, and mm.patch is fairly clear about
>it (moreso than when any other patch will fail to apply).
> 
> 2. A related question: if someone uses the above URL for mm patches, how
>should they report a unique identifier (ala git-describe)?

umm, OK, I'll put a file in there called stamp--mm-dd-hh-mm

> 3. I still have patch conflicts, with this series of patches:
> 
> Applying patch..suppress-aout-library-support-if-config_binfmt_aout.patch
> error: patch failed: arch/m68k/kernel/process.c:316
> error: arch/m68k/kernel/process.c: patch does not apply
> Context reduced to (2/2) to apply fragment at 120
> error: patch failed: fs/binfmt_elf.c:961
> error: fs/binfmt_elf.c: patch does not apply
> error: patch failed: include/linux/Kbuild:17
> error: include/linux/Kbuild: patch does not apply
> 
> I also had to comment out these two due to new or dependent conflicts:
> 
> suppress-aout-library-support-if-config_binfmt_aout-checkpatch-fixes.patch
> make-frame_pointer-default=y.patch

I warned you ;)

> 4. With the above 3 patches not applied, I got a couple of compile errors,
>which I reported separately.

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

Re: [PATCH] make ds1wm driver to check ds1wm_platform_data pointer against NULL

[eric miao]

On Nov 11, 2007 1:08 AM, Evgeniy Polyakov <[EMAIL PROTECTED]> wrote:
> On Fri, Nov 09, 2007 at 05:02:38PM -0800, Andrew Morton ([EMAIL PROTECTED]) 
> wrote:
> > > @@ -351,6 +351,10 @@ static int ds1wm_probe(struct platform_device *pdev)
> > > goto err0;
> > > }
> > > plat = pdev->dev.platform_data;
> > > +   if (!plat) {
> > > +   ret = -ENXIO;
> > > +   goto err0;
> > > +   }
> > > ds1wm_data->bus_shift = plat->bus_shift;
> > > ds1wm_data->pdev = pdev;
> > > ds1wm_data->pdata = plat;
> >
> > I don't understand this change.  Could you please provide some more details
> > regarding what problem it is solving?  How can pdev->dev.platform_data==NULL
> > come about?
>
> If I understood correctly, it is posible to call platform's probe
> callback without previously calling platform_device_add_data() to setup
> platform_data.
>
> But actually I failed to find any user of this platform driver in
> vanilla kernel, so it is hard to say if driver is used properly or not
> by external modules, and thus this change is very likely valid.
>
> --
> Evgeniy Polyakov
>

Yes, that's exactly what this patch meant to prevent. That no use of
this platform driver in vanilla kernel doesn't mean the check is
unnecessary. Actually, from the code of this driver, the platform_data
is mandatory for the driver to work properly.  Well, if an oops is
on purpose when platform_data == NULL, this is, I agree, completely
unnecessary.

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

Re: AppArmor Security Goal

[Casey Schaufler]

--- Crispin Cowan <[EMAIL PROTECTED]> wrote:

> Dr. David Alan Gilbert wrote:
> ...
>
> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.
> 
> Note that John Johansen is also interested in allowing non-privileged
> users to manipulate AppArmor policy, but his view was to only allow a
> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Now this is getting interesting. It looks to me as if you've implemented
a mandatory access control scheme that some people would like to be able
to use as a discretionary access control scheme. This is creepy after
seeing the MCS implementation in SELinux, which is also a DAC scheme
wacked out of a MAC scheme. Very interesting indeed.


Casey Schaufler
[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 1/6] Suppress A.OUT library support if !CONFIG_BINFMT_AOUT [try #5]

[Andrew Morton]

On Fri, 09 Nov 2007 15:34:37 + David Howells <[EMAIL PROTECTED]> wrote:

> --- a/include/linux/Kbuild
> +++ b/include/linux/Kbuild
> @@ -1,3 +1,4 @@
> +# -*- makefile -*-

what's that?

>  header-y += byteorder/
>  header-y += dvb/
>  header-y += hdlc/
> @@ -17,7 +18,9 @@ header-y += usb/
>  
>  header-y += affs_hardblocks.h
>  header-y += aio_abi.h
> +ifeq ($(wildcard 
> include/asm-$(SRCARCH)/a.out.h),include/asm-$(SRCARCH)/a.out.h)
>  header-y += a.out.h
> +endif

Note that because of unexport-asm-pageh.patch I turned the above hunk into

ifeq ($(wildcard include/asm-$(SRCARCH)/a.out.h),include/asm-$(SRCARCH)/a.out.h)
unifdef-y += a.out.h
endif

which seems logical to me.  We'll see how it tests out.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Alan Cox wrote:


but how can the system know if the directory the user wants to add is
reasonable or not? what if the user says they want to store their
documents in /etc?


A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited at this
moment - something root cannot know in advance
(although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
mv it back might work 8))


the mechanism being desired was that the system administrator would setup 
a restrictive policy and a user who wanted a more permissive policy would 
have the ability to make it more permissive.


this sort of thing is a disaster waiting to happen.

however, if App Armor sets things up so that there can be a system policy 
that users cannot touch, but users can have a secondary policy that layers 
over the system one to restrict things further it could be safe.


if a sysadmin wants to have 'soft' and 'hard' limits of what a user can 
do, they could put the 'hard' limits in the system policy (and the users 
_cannot_ violate these limits), and then set the 'soft' limits in the 
users default setup (similar to how .profile is set by default). if a user 
wants to make things less restrictive they could edit or remove the 
per-user policy, but would still not be able to violate the system policy.


however, while this seems attractive, I'm not sure that madness isn't down 
the road a little bit. since the users policy would only apply to 
themselves, you have the situation that (DAC permissions permitting) the 
files are available to other confined processes becouse they are running 
as other users. this sort of thing will surprise people if the 
explinations aren't done very carefully.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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 conflicts (MMOTM "10-Nov-2007 22:46")

[Erez Zadok]

Andrew,

I'm using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
22:46".

1. I was getting a bunch of patch conflicts, until I realized that this
   latest set of patches was to be applied against 2.6.24-rc2 (your mm.patch
   gave it away :-) The last snapshot was against 2.6.24-rc1.

   What should be the official way in which people using the above URL know
   which base to apply it against: is looking at mm.patch OK?  If so, then
   I'd like to suggest that you move mm.patch to the very beginning of your
   series file: that way if the first patch causes a conflict, it'd be a
   hint to the person to investigate why, and mm.patch is fairly clear about
   it (moreso than when any other patch will fail to apply).

2. A related question: if someone uses the above URL for mm patches, how
   should they report a unique identifier (ala git-describe)?

3. I still have patch conflicts, with this series of patches:

Applying patch..suppress-aout-library-support-if-config_binfmt_aout.patch
error: patch failed: arch/m68k/kernel/process.c:316
error: arch/m68k/kernel/process.c: patch does not apply
Context reduced to (2/2) to apply fragment at 120
error: patch failed: fs/binfmt_elf.c:961
error: fs/binfmt_elf.c: patch does not apply
error: patch failed: include/linux/Kbuild:17
error: include/linux/Kbuild: patch does not apply

I also had to comment out these two due to new or dependent conflicts:

suppress-aout-library-support-if-config_binfmt_aout-checkpatch-fixes.patch
make-frame_pointer-default=y.patch

4. With the above 3 patches not applied, I got a couple of compile errors,
   which I reported separately.

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

[PATCH] kernel/capability.c get_task_comm compile error (MMOTM)

[Erez Zadok]

Using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
22:46".

$ make
  CC  kernel/capability.o
kernel/capability.c: In function 'sys_capset':
kernel/capability.c:231: warning: passing argument 1 of 'get_task_comm' from 
incompatible pointer type
kernel/capability.c:231: error: too few arguments to function 'get_task_comm'
make[1]: *** [kernel/capability.o] Error 1
make[1]: Target `__build' not remade because of errors.
make: *** [kernel] Error 2

Small patch below fixes compile error.

Erez.


Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>

diff --git a/kernel/capability.c b/kernel/capability.c
index ea21bbe..8cba9b2 100644
--- a/kernel/capability.c
+++ b/kernel/capability.c
@@ -225,10 +225,11 @@ asmlinkage long sys_capset(cap_user_header_t header, 
const cap_user_data_t data)
switch (version) {
case _LINUX_CAPABILITY_VERSION_1:
if (warned < 5) {
+   char name[sizeof(current->comm)];
warned++;
printk(KERN_INFO
   "warning: process `%s' sets w/ old libcap\n",
-  get_task_comm(current));
+  get_task_comm(name, current));
}
tocopy = _LINUX_CAPABILITY_U32S_1;
break;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] mm/memory.c follow_hugetlb_page compiler error (MMOTM)

[Erez Zadok]

Using http://userweb.kernel.org/~akpm/mmotm/ timestamped "10-Nov-2007
22:46". CONFIG_HUGETLB_PAGE not set.

$ make
  CC  mm/memory.o
mm/memory.c:1040:29: error: macro "follow_hugetlb_page" passed 8 arguments, but 
takes just 7
mm/memory.c: In function 'get_user_pages':
mm/memory.c:1039: error: 'follow_hugetlb_page' undeclared (first use in this 
function)
mm/memory.c:1039: error: (Each undeclared identifier is reported only once
mm/memory.c:1039: error: for each function it appears in.)
make[1]: *** [mm/memory.o] Error 1
make: *** [mm] Error 2

Small patch below fixes compile error.

Erez.


Signed-off-by: Erez Zadok <[EMAIL PROTECTED]>

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index bb03660..2496879 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -106,7 +106,7 @@ static inline unsigned long hugetlb_total_pages(void)
return 0;
 }
 
-#define follow_hugetlb_page(m,v,p,vs,a,b,i)({ BUG(); 0; })
+#define follow_hugetlb_page(m,v,p,vs,a,b,i,w)  ({ BUG(); 0; })
 #define follow_huge_addr(mm, addr, write)  ERR_PTR(-EINVAL)
 #define copy_hugetlb_page_range(src, dst, vma) ({ BUG(); 0; })
 #define hugetlb_prefault(mapping, vma) ({ BUG(); 0; })
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Include header required for INT_MAX

[Thomas Koeller]

On Samstag, 10. November 2007, Christoph Hellwig wrote:
> On Sat, Nov 10, 2007 at 03:55:15PM +0100, Thomas Koeller wrote:
> > cdrom.h uses INT_MAX, so it must include kernel.h or
> > limits.h (userspace) for a definition.
>
> Nack, we shoiuld never include userspace headers in kernel headers,
> an even more never add !__KERNEL__ ifdefs.  Just make sure your
> programs include limit.h before including linux/cdrom.h.

I think header files should be complete, and should not use undefined
macros, picking up every random definition that may be in effect when
the header is included, don't you agree? Why not use some other
constant instead of INT_MAX? What improvement does commit
132e4b0a049c39337c535501561b8301c7f2b202 provide? It certainly
breaks existing userspace code.

tk

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

[PATCH 2/2] [e1000 VLAN] Disable vlan hw accel when promiscuous mode

[Joonwoo Park]

IMHO even though netdevice is in the promiscuous mode, we should receive all of 
ingress packets.
This disable the vlan filtering feature when a vlan hw accel configured e1000 
device goes into promiscuous mode.
This make packets visible to sniffers though it's not vlan id of itself.
Any check, comments will be appreciated.
Thanks.

Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]>
---
 drivers/net/e1000/e1000_main.c |   26 --
 1 files changed, 20 insertions(+), 6 deletions(-)

diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c 
index 72deff0..cdd5c84 100644
--- a/drivers/net/e1000/e1000_main.c
+++ b/drivers/net/e1000/e1000_main.c
@@ -2424,7 +2424,7 @@ e1000_set_multi(struct net_device *netdev)
struct e1000_adapter *adapter = netdev_priv(netdev);
struct e1000_hw *hw = >hw;
struct dev_mc_list *mc_ptr;
-   uint32_t rctl;
+   uint32_t rctl, ctrl;
uint32_t hash_value;
int i, rar_entries = E1000_RAR_ENTRIES;
int mta_reg_count = (hw->mac_type == e1000_ich8lan) ?
@@ -2441,14 +2441,25 @@ e1000_set_multi(struct net_device *netdev)
/* Check for Promiscuous and All Multicast modes */
 
rctl = E1000_READ_REG(hw, RCTL);
+   ctrl = E1000_READ_REG(>hw, CTRL);
 
if (netdev->flags & IFF_PROMISC) {
rctl |= (E1000_RCTL_UPE | E1000_RCTL_MPE);
-   } else if (netdev->flags & IFF_ALLMULTI) {
-   rctl |= E1000_RCTL_MPE;
-   rctl &= ~E1000_RCTL_UPE;
+   if (adapter->hw.mac_type != e1000_ich8lan) {
+   if (ctrl & E1000_CTRL_VME)
+   rctl &= ~E1000_RCTL_VFE;
+   }
} else {
-   rctl &= ~(E1000_RCTL_UPE | E1000_RCTL_MPE);
+   if (adapter->hw.mac_type != e1000_ich8lan) {
+   if (ctrl & E1000_CTRL_VME)
+   rctl |= E1000_RCTL_VFE;
+   }
+   if (netdev->flags & IFF_ALLMULTI) {
+   rctl |= E1000_RCTL_MPE;
+   rctl &= ~E1000_RCTL_UPE;
+   } else {
+   rctl &= ~(E1000_RCTL_UPE | E1000_RCTL_MPE);
+   }
}
 
E1000_WRITE_REG(hw, RCTL, rctl);
@@ -4952,7 +4963,10 @@ e1000_vlan_rx_register(struct net_device *netdev, struct 
vlan_group *grp)
if (adapter->hw.mac_type != e1000_ich8lan) {
/* enable VLAN receive filtering */
rctl = E1000_READ_REG(>hw, RCTL);
-   rctl |= E1000_RCTL_VFE;
+   if (netdev->flags & IFF_PROMISC)
+   rctl &= ~E1000_RCTL_VFE;
+   else
+   rctl |= E1000_RCTL_VFE;
rctl &= ~E1000_RCTL_CFIEN;
E1000_WRITE_REG(>hw, RCTL, rctl);
e1000_update_mng_vlan(adapter);
---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] [VLAN] Don't drop an unclassfied vlan packet as PACKET_OTHERHOST

[Joonwoo Park]

IMHO linux should not drop unclassified vlan packets to pass these to sniffers. 
isn't it?
But, since the __vlan_hwaccel_rx drops unclassified vlan packets, sniffers 
cannot see them.
This make the __vlan_hwaccel_rx receive and process an unclassified vlan packet 
as a PACKET_OTHERHOST.
Any check, comments will be appreciated.
Thanks.

Signed-off-by: Joonwoo Park <[EMAIL PROTECTED]> 
---
 include/linux/if_vlan.h |   61 ++
 1 files changed, 34 insertions(+), 27 deletions(-)

diff --git a/include/linux/if_vlan.h b/include/linux/if_vlan.h
index 976d4b1..e1db5bc 100644
--- a/include/linux/if_vlan.h
+++ b/include/linux/if_vlan.h
@@ -170,21 +170,26 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb,
unsigned short vlan_tag, int polling)
 {
struct net_device_stats *stats;
+   struct net_device *vlan_dev;
 
if (skb_bond_should_drop(skb)) {
dev_kfree_skb_any(skb);
return NET_RX_DROP;
}
 
-   skb->dev = vlan_group_get_device(grp, vlan_tag & VLAN_VID_MASK);
-   if (skb->dev == NULL) {
-   dev_kfree_skb_any(skb);
+   vlan_dev = vlan_group_get_device(grp, vlan_tag & VLAN_VID_MASK);
+   if (vlan_dev == NULL) {
+   if (skb->dev == NULL) {
+   dev_kfree_skb_any(skb);
 
-   /* Not NET_RX_DROP, this is not being dropped
-* due to congestion.
-*/
-   return 0;
-   }
+   /* Not NET_RX_DROP, this is not being dropped
+* due to congestion.
+*/
+   return 0;
+   }
+   skb->pkt_type = PACKET_OTHERHOST;
+   } else
+   skb->dev = vlan_dev;
 
skb->dev->last_rx = jiffies;
 
@@ -192,25 +197,27 @@ static inline int __vlan_hwaccel_rx(struct sk_buff *skb,
stats->rx_packets++;
stats->rx_bytes += skb->len;
 
-   skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tag);
-   switch (skb->pkt_type) {
-   case PACKET_BROADCAST:
-   break;
-
-   case PACKET_MULTICAST:
-   stats->multicast++;
-   break;
-
-   case PACKET_OTHERHOST:
-   /* Our lower layer thinks this is not local, let's make sure.
-* This allows the VLAN to have a different MAC than the 
underlying
-* device, and still route correctly.
-*/
-   if (!compare_ether_addr(eth_hdr(skb)->h_dest,
-   skb->dev->dev_addr))
-   skb->pkt_type = PACKET_HOST;
-   break;
-   };
+   if (vlan_dev) {
+   skb->priority = vlan_get_ingress_priority(skb->dev, vlan_tag);
+   switch (skb->pkt_type) {
+   case PACKET_BROADCAST:
+   break;
+
+   case PACKET_MULTICAST:
+   stats->multicast++;
+   break;
+
+   case PACKET_OTHERHOST:
+   /* Our lower layer thinks this is not local, let's make 
sure.
+* This allows the VLAN to have a different MAC than 
the underlying
+* device, and still route correctly.
+*/
+   if (!compare_ether_addr(eth_hdr(skb)->h_dest,
+   skb->dev->dev_addr))
+   skb->pkt_type = PACKET_HOST;
+   break;
+   };
+   }
 
return (polling ? netif_receive_skb(skb) : netif_rx(skb));
 }
---

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Temporary lockup on loopback block device

[Mikulas Patocka]

> > Arguably we just have the wrong backing-device here, and what we should do
> > is to propagate the real backing device's pointer through up into the
> > filesystem.  There's machinery for this which things like DM stacks use.
> > 
> > I wonder if the post-2.6.23 changes happened to make this problem go away.
> 
> The per BDI dirty stuff in 24 should make this work, I just checked and
> loopback thingies seem to have their own BDI, so all should be well.

This is not only about loopback (I think the lockup can happen even 
without loopback) --- the main problem is:

Why are there over-limit dirty pages that no one is writing?

Mikulas
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Temporary lockup on loopback block device

[Mikulas Patocka]

On Sat, 10 Nov 2007, Andrew Morton wrote:

> On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]> 
> wrote:
> 
> > Hi
> > 
> > I am experiencing a transient lockup in 'D' state with loopback device. It 
> > happens when process writes to a filesystem in loopback with command like
> > dd if=/dev/zero of=/s/fill bs=4k 
> > 
> > CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in 
> > congestion_wait called from balance_dirty_pages.
> > 
> > After about 30 seconds, the lockup is gone and dd resumes, but it locks up 
> > soon again.
> > 
> > I added a printk to the balance_dirty_pages
> > printk("wait: nr_reclaimable %d, nr_writeback %d, dirty_thresh %d, 
> > pages_written %d, write_chunk %d\n", nr_reclaimable, 
> > global_page_state(NR_WRITEBACK), dirty_thresh, pages_written, 
> > write_chunk);
> > 
> > and it shows this during the lockup:
> > 
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > 
> > What apparently happens:
> > 
> > writeback_inodes syncs inodes only on the given wbc->bdi, however 
> > balance_dirty_pages checks against global counts of dirty pages. So if 
> > there's nothing to sync on a given device, but there are other dirty pages 
> > so that the counts are over the limit, it will loop without doing any 
> > work.
> > 
> > To reproduce it, you need totally idle machine (no GUI, etc.) -- if 
> > something writes to the backing device, it flushes the dirty pages 
> > generated by the loopback and the lockup is gone. If you add printk, don't 
> > forget to stop klogd, otherwise logging would end the lockup.
> 
> erk.
> 
> > The hotfix (that I verified to work) is to not set wbc->bdi, so that all 
> > devices are flushed ... but the code probably needs some redesign (i.e. 
> > either account per-device and flush per-device, or account-global and 
> > flush-global).
> > 
> > Mikulas
> > 
> > 
> > diff -u -r ../x/linux-2.6.23.1/mm/page-writeback.c mm/page-writeback.c
> > --- ../x/linux-2.6.23.1/mm/page-writeback.c 2007-10-12 
> > 18:43:44.0 +0200
> > +++ mm/page-writeback.c 2007-11-10 20:32:43.0 +0100
> > @@ -214,7 +214,6 @@
> > 
> > for (;;) {
> > struct writeback_control wbc = {
> > -   .bdi= bdi,
> > .sync_mode  = WB_SYNC_NONE,
> > .older_than_this = NULL,
> > .nr_to_write= write_chunk,
> 
> Arguably we just have the wrong backing-device here, and what we should do
> is to propagate the real backing device's pointer through up into the
> filesystem.  There's machinery for this which things like DM stacks use.

If you change loopback backing-device, you just turn this nicely 
reproducible example into a subtle race condition that can happen whenever 
you use loopback or not. Think, what happens when different process 
dirties memory:

You have process "A" that dirtied a lot of pages on device "1" but has not 
started writing them.
You have process "B" that is trying to write to device "2", sees dirty 
page count over limit, but can't do anything about it, because it is only 
allowed to flush pages on device "2". --- so it endlessly loops.

If you want to use the current flushing semantics, you just have to audit 
the whole kernel to make sure that if some process sees over-limit dirty 
page count, there is another process that is flushing the pages. Currently 
it is not true, the "dd" process sees over-limit count, but there is 
no-one writing.

> I wonder if the post-2.6.23 changes happened to make this problem go away.

I will try 2.6.24-rc2, but I don't think the root cause of this went away. 
Maybe you just reduced probability.

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

Warning: commit message does not conform to UTF-8. (mmotm "10-Nov-2007 22:46")

[Erez Zadok]

Andrew,

I'm getting minor warnings when applying two patches from


It's probably not serious but I wonder if checkpatch catches this.

Applying patch..git-net.patch
Warning: commit message does not conform to UTF-8.
You may want to amend it after fixing the message, or set the config
variable i18n.commitencoding to the encoding your project uses.

Applying patch..mnt_unbindable-fix.patch
Warning: commit message does not conform to UTF-8.
You may want to amend it after fixing the message, or set the config
variable i18n.commitencoding to the encoding your project uses.

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

Re: WARNING: at lib/kref.c:33 kref_get() (-mm 2007-11-06-02-32++)

[Erez Zadok]

In message <[EMAIL PROTECTED]>, Andrew Morton writes:
> On Fri, 9 Nov 2007 21:12:47 -0500 Erez Zadok <[EMAIL PROTECTED]> wrote:
> 
> > Setup: FC6 system with MM snapshot broken-out-2007-11-06-02-32
> 
> That's a bit old.
> 
> > and these two
> > patches added:
> > 
> > r-o-bind-mounts-track-number-of-mount-writer-fix-buggy-loop.patch
> > r-o-bind-mounts-track-number-of-mount-writer-fix-buggy-loop-checkpatch-fixes.patch
> > 
> > Booting the machine, waiting a few minutes (not logging in or doing anything
> > else).  I get:
> > 
> > WARNING: at lib/kref.c:33 kref_get()
> >  [] show_trace_log_lvl+0x12/0x25
> >  [] show_trace+0xd/0x10
> >  [] dump_stack+0x15/0x17
> >  [] kref_get+0x26/0x30
> >  [] kobject_get+0x12/0x17
> >  [] kobject_add+0x97/0x162
> >  [] uids_user_create+0x41/0x5d
> >  [] alloc_uid+0xc9/0x171
> >  [] set_user+0x1f/0x93
> >  [] sys_setuid+0x4b/0xcb
> >  [] sysenter_past_esp+0x5f/0x91
> >  ===
> > 
> > There's no other indication where the setuid(2) came from, perhaps cron?
> > 
> 
> I have a feeling that this was reported before and that Dave and/or Greg
> looked into it.  Were those two patches which Dave sent yesterday applied?

Yes, both of Dave's patches were applied.  I'll give the latest -mm a try
first and see report comes up.

> It might be worth checking my current tree:
> http://userweb.kernel.org/~akpm/mmotm/

The above URL is very useful.  Thanks!

I've got comments on my experience w/ the above URL, but I'll send those as
separate emails shortly.

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

Re: Fw: Buffer overflow in CIFS VFS.

[Przemyslaw Wegrzyn]

Steve French wrote:
> On Nov 10, 2007 7:03 AM, Przemyslaw Wegrzyn <[EMAIL PROTECTED]> wrote:
>   
>> Steve French wrote:
>> 
>>> That might be better, although without memory pools, this would perform
>>> much worse
>>>
>>>   
>> Why ? I don't get your point here.
>> 
> What I meant is that two fixed size memory pools rather variable size
> kmallocs helps performance.  By using two fixed size buffers (small -
> which fits the typical smb request and response, and large which fits
> the maximum size request other than write which is handled via an
> iovec) and taking advantage of memory pools, cifs can always make
> progress even in low memory situations (reducing the likelihood of
> deadlock) and it reduces the number of times that cifs has to do the
> very expensive allocation of 16.5K.  If cifs only used variable size
> request and response buffers, since they are frequently more than one
> page in size we would be forcing the memory manager to find contiguous
> pages which can be very slow.
>   
That was not really my intention to allocate variable size buffers -
it's perfectly Ok for me to have 2 fixed-size pools. What I meant was to
allocate buffers with some kind of header containing buffer size and
type of buffer or whatever needed info. Obviously, you could use
pointers to buffer body all over the code, functions/macros that need to
access the header would move the pointer back by sizeof(header). Then
one could e.g. provide a single function for disposing the buffer, and
no longer care which pool is it allocated from, for the additional
memory cost - the function would look into the header to check that for
you. Hope it's clear now (my English is far from perfect).

Przemyslaw

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cd/dvd inaccessible in 2.6.24-rc2

[Andrew Morton]

On Sat, 10 Nov 2007 23:05:53 + Alan Cox <[EMAIL PROTECTED]> wrote:

> > > ata9.00: qc timeout (cmd 0xa0)
> > > ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > > ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
> > > in
> > >  res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> > > ata9.00: status: { DRDY ERR }
> 
> Could be an IRQ/ACPI regression, and in fact to me it looks more like
> that, than an IDE one.

Drat.  Seems that once we break that sort of thing we never fix it again.

> Probably worth trying the various IRQ routing
> options and seeing if they help.

Yup.

Please, if you have time, bisect it down to the offending commit?

There's info at http://www.kernel.org/doc/local/git-quick.html which should
help.

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

Re: USB storage: corrupted data transfers

[Mark Lord]

Mark Lord wrote:

Mark Lord wrote:

Something may be broken in USB / usb-storage land.

I've got a 2GB USB stick here.
I want to copy it to an image file on my hard drive:

   cat /dev/sdb > usbkey.image1

Make a second copy, with or without unplugging/replugging the stick:

   cat /dev/sdb > usbkey.image2

After doing this, the two copies *differ*.


Here's the information on the specific devices I'm trying this with.

I'm beginning to suspect a faulty stick, or maybe one that just doesn't
work reliably with the way Linux accesses it (?).  The type that fails

...

Yup, bad hardware.  I've got 13 of those sticks here, and 11 are fine.

Move along folks, nothing to see 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/

problems with spi interface & ads 784X under 2.6.23

[dave chung]

on kernel 2.6.23 , with an  Arm AT91rm9200
sometimes when i  "pen-down" on the touch screen,I'm seeing

ads7846 spi0.0: touchscreen, irq 75
input: ADS784x Touchscreen as /devices/platform/atmel_spi.0/spi0.0/input/input0
at91_rtc at91_rtc: rtc core: registered at91_rtc as rtc0



atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
DEactivate 35, mr 000f0011
atmel_spi atmel_spi.0: fifo overrun (0/1 remaining)
atmel_spi atmel_spi.0: timeout waiting for TXEMPTY<7>ads7846 spi0.0:
DEactivate 35, mr 000f0011



it appears to be coming from /drivers/touchscreen/ads7846.c

also even stranger, a cat of  the TS when the pen is down produces:
# cat /dev/ts |hexdump
returns
000 ea9c 34aa 0d64 0007 0001 014a 0001 
010 ea9c 34aa 0dde 0007 0003 0018 1d4c 
020 ea9c 34aa 0e1b 0007    
030 ea9c 34aa 8c84 0008 0001 014a  
040 ea9c 34aa 8cdf 0008 0003 0018  
050 ea9c 34aa 8d1c 0008    
060 ea9d 34aa c9af 0004 0001 014a 0001 
070 ea9d 34aa ca29 0004 0003 0018 1d4c 
080 ea9d 34aa ca66 0004    

when the pen is down , notice that the left column is a sequence of
incrementing words, at "second" intervals , the value of which change
when i turn off the "RTC" compillation in the kernel, but this may be
down to the interrupts.
After consulting the curcuit diagrams , the only "odd" thing i can see
is that the "penirq" is tied to pin  PB11, but it is obviously working
as i only get output when the pen is down

under kernel 2.6.13 the touchscreen actually works fine.
and a cat of it's output is more reasonable.

00 0001 0c39 07e0 be98 0001 0c33 0801 be98
010 0001 0c35 07e2 be98 0001 0c41 07d4 be98
020 0001 0c40 07d0 be98 0001 0c08 0859 be98
030 0001 0c4c 07d1 be98 0001 0c5a 070f be98
040 0001 0c3f 074a be98 0001 0bf3 07e5 be98
050 0001 0c40 07e4 be98 0001 0c40 07f5 be98
060 0001 0c63 07e3 be98 0001 0c3c 07d2 be98
070 0001 0c44 07ce be98 0001 0c3e 07d2 be98
080 0001 0c40 07cf be98 0001 0c56 071f be98

which does actually seem to be representative of reasonalbe screen positions

Dave
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Alan Cox]

> but how can the system know if the directory the user wants to add is 
> reasonable or not? what if the user says they want to store their 
> documents in /etc?

A more clear example is wanting to wrap a specific tool with temporary
rules. Those rules would depend on the exact file being edited at this
moment - something root cannot know in advance
(although with apparmor I guess mv $my_file apparmour_magic.name ; foo;
mv it back might work 8))

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Alan Cox]

> I submit that the AppArmor model is valid, even if it totally failed all
> of David Gilbert's questions (I think AppArmor can actually provide
> about half of what he asked for).

The model looks valid. I have difficulty constructing many scenarios
where its useful but it appears valid providing you can tightly control
file renaming, which is very very questionable.

There are also some very awkward path based issues around shared file
objects (your controlling tty and TIOCSTI for one) that I need to look at
the code for once the VFS stuff is sorted and its likely to get merged.

Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Dr. David Alan Gilbert]

* [EMAIL PROTECTED] ([EMAIL PROTECTED]) wrote:
 That I wrote:
> >If the adminisrator set something up with (2) as the starting point it
> >would seem reasonable for the user to be able to add the ability to edit
> >documents in extra directories for their style of organising documents
> >they work on; but they would be restricted in what they could add
> >so that they couldn't add the ability to write to their settings
> >files.
> 
> but how can the system know if the directory the user wants to add is 
> reasonable or not? what if the user says they want to store their 
> documents in /etc?

I was assuming that in a system where the user can add stuff to
the profile the administrator would be able to either grant or exclude
paths that the user was able to add.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Dr. David Alan Gilbert wrote:


Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.


I think it might depend on how strict the users starting point is;
you could say:
  1 This document editor can read and write any part of the users home
directory other than the . files.

or you could say:
  2 This document editor can read any files but only write to the
'Documents directory'.

If the adminisrator set something up with (2) as the starting point it
would seem reasonable for the user to be able to add the ability to edit
documents in extra directories for their style of organising documents
they work on; but they would be restricted in what they could add
so that they couldn't add the ability to write to their settings
files.


but how can the system know if the directory the user wants to add is 
reasonable or not? what if the user says they want to store their 
documents in /etc?






AppArmor will let you do that; most of the work is in splitting the
application. If you can get e.g. Firefox to use a separate process that
it exec's for editing your preferences, then AppArmor can confine that
helper app with a different policy than Firefox itself, including
granting the helper write permission to the config directory.


Yes, and designing the app so that it's filenames are predictable;
firefox has a fun habit of using randomly named profile directories.


You just glob that directory, so the rule would look like:

/home/*/.mozilla/default/*/prefs.js rw,

if you wanted it to be a generic policy for all users. If you want a
tighter policy for your workstation, then it might look like

/home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,

hard-coding both your username and the random directory name that
Mozilla chose.


a question for Crispin,
  is there a wildcard replacement for username? so that you could grant 
permission to /home/$user/.mozilla.. and grant each user access to 
only their own stuff? I realize that in this particular example the 
underlying DAC will handle it, but I can see other cases where people may 
want to have users more intermixed (say webserver files or directories for 
example)



Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.


the model of being able to add restrictions would still handle this. make 
two shell scripts (one to start each browser profile) and set the AA 
policy for these scripts to only have access to the appropriate 
directories.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cd/dvd inaccessible in 2.6.24-rc2

[Jeff Garzik]

Will Trives wrote:

Hello,

Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
Chipset: Intel P35 + ICH9R 
PATA port runs off JMicron controller

CD/DVD Device: BENQ DW1640 16X

I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
2.6.23. Basically the drive is detected OK, everything looks ok but as
soon as I go to use it errors like this occur:


Is 2.6.24-rc1 also broken?

Jeff



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

Re: [PATCH] drivers/video/s1d13xxxfb.c as module with dbg

[dave chung]

On 11/10/07, Stanislav Brabec <[EMAIL PROTECTED]> wrote:
> Attached patch fixes two compilation problems of s1d13xxxfb.c:
> - Fixes outdated dbg() message to fix compilation error with debugging 
> enabled.
> - Do not read kernel command line options when compiled as module.
>
> Signed-off-by: Stanislav Brabec <[EMAIL PROTECTED]>
>
> --- linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-10-09 22:31:38.0 
> +0200
> +++ linux-2.6.23/drivers/video/s1d13xxxfb.c 2007-11-02 16:48:34.0 
> +0100
> @@ -540,7 +540,7 @@
> int ret = 0;
> u8 revision;
>
> -   dbg("probe called: device is %p\n", dev);
> +   dbg("probe called: device is %p\n", pdev);
>
> printk(KERN_INFO "Epson S1D13XXX FB Driver\n");
>
> @@ -753,8 +753,11 @@
>  static int __init
>  s1d13xxxfb_init(void)
>  {
> +
> +#ifndef MODULE
> if (fb_get_options("s1d13xxxfb", NULL))
> return -ENODEV;
> +#endif
>
> return platform_driver_register(_driver);
>  }
>
>
>
> Stanislav Brabec
> http://www.penguin.cz/~utx
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
>

we also need to look at splitting out the "chip revision", which is
currently hard set, as I have had very good results with this driver
and  chip  S1D13506, which is functionally similar but without the
external clocking and without teh internal ram.
 We also have some build dependancies related to  "CONFIG_FB_S1D13XXX"
and  ics1523 , this chip is not used on the full range of S1D13XXX and
causes errors in the build , for chips such as S1D13506.
potentially we could re-use most of the code, but would need a way to
pass in S1D_CHIP_REV and one or 2 other chip specific data items.

Steve
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cd/dvd inaccessible in 2.6.24-rc2

[Jeff Garzik]

Alan Cox wrote:

ata9.00: qc timeout (cmd 0xa0)
ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
in
 res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
ata9.00: status: { DRDY ERR }


Could be an IRQ/ACPI regression, and in fact to me it looks more like
that, than an IDE one. Probably worth trying the various IRQ routing
options and seeing if they help.



Agreed, though the output is indeed signalling an error...  IMO the EH 
should handle the error if the device is signalling an error, upon 
timeout, rather than just going ahead and resetting the device.


Its similar to where ATA devices on PCI SFF controllers signal DMA error 
via timeout, where EH must inspect BMDMA Status register to determine if 
it's a DMA error signalled by hardware, or something that requires 
additional autopsy.


EH for ATAPI is quite different from EH for ATA, so there may be some 
areas where we don't handle things the right way for ATAPI.


Decoding the error message we have:

cdb 0x5a ==
MODE SENSE(10)
status 0x51 ==
DRDY
command-specific flag (aka SERV, in !overlap case)
CHK (check condition, aka error)
error 0x54 ==
ABRT (command aborted or command parameter invalid)
sense key 0x5 (illegal request)
ireason 0x3 ==
the hardcoded values (bits 0 and 1) remain hardcoded, all good

Since BSY is not set in the Status register, and given the other 
information derived from the decoded values, it looks like the device is 
otherwise happy and ready to accept additional commands.


It appears to have chewed on an ATAPI command, spit it out, but failed 
to send a completion interrupt.


So its an open question whether it's a device not completing this 
errored-out command, or whether its IRQ/ACPI stuff infecting libata.


Jeff


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

Re: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >   
> >> I don't get the problem: if you want your web browser to be able to
> >> access where you commonly store your documents, then give it that
> >> permission. The above rule says that your web browser doesn't get to go
> >> change AppArmor policy on its own.
> >> 
> > But can I as a non-privileged user say which directories I want it to
> > be able to access?
> >   
> No, you have to be privileged (root) to edit security policy and to
> reload policy.

OK, that's what I thought you were saying.

> I mostly don't see this as a serious limitation, because almost everyone
> has their own workstation, and thus has root on that workstation. There
> are 2 major exceptions:
> 
> * Schools, where the "workstations" are thin client X terminals and
>   everyone is logged into a giant shared machine. Sorry, AppArmor is
>   not a good choice for that environment, but it is a pretty scarce
>   environment.
> * Enterprises, where workers get their own workstation, but they
>   don't get root. Well, the reason the worker doesn't get root is
>   the enterprise doesn't trust them with it, and so not letting them
>   edit security policy is probably a good idea.

I don't actually see your distinction here between those two environments;
why does it matter if there is one non-priveliged user or many?

> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.

I think it might depend on how strict the users starting point is;
you could say:
   1 This document editor can read and write any part of the users home
 directory other than the . files.

or you could say:
   2 This document editor can read any files but only write to the
 'Documents directory'.

If the adminisrator set something up with (2) as the starting point it
would seem reasonable for the user to be able to add the ability to edit
documents in extra directories for their style of organising documents
they work on; but they would be restricted in what they could add
so that they couldn't add the ability to write to their settings
files.

> Note that John Johansen is also interested in allowing non-privileged
> users to manipulate AppArmor policy, but his view was to only allow a
> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Well that would correspond to case (1) above; where the global settings
by an administrator were fairly open and then it was up to the user to
restrict programs more if they knew they always stored their documents
in one place; I was working on the basis of allowing applications
access to very little until you said it was alright - since most users
wouldn't actually bother up setting up more restrictive access.


> How to usefully confine an office suite like OpenOffice is current work
> at Mercenary Linux. We think we have a solution that is just AppArmor
> policy, without having to do any feature enhancements.

That solution might answer my questions anyway.



> >> AppArmor will let you do that; most of the work is in splitting the
> >> application. If you can get e.g. Firefox to use a separate process that
> >> it exec's for editing your preferences, then AppArmor can confine that
> >> helper app with a different policy than Firefox itself, including
> >> granting the helper write permission to the config directory.
> >> 
> > Yes, and designing the app so that it's filenames are predictable;
> > firefox has a fun habit of using randomly named profile directories.
> >   
> You just glob that directory, so the rule would look like:
> 
> /home/*/.mozilla/default/*/prefs.js rw,
> 
> if you wanted it to be a generic policy for all users. If you want a
> tighter policy for your workstation, then it might look like
> 
> /home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,
> 
> hard-coding both your username and the random directory name that
> Mozilla chose.

Allowing a user to tweak (under constraints) their settings might allow
them to do something like create two mozilla profiles which are isolated
from each other, so that the profile they use for general web surfing
is isolated from the one they use for online banking.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG]: Crash with CONFIG_FAIR_CGROUP_SCHED=y

[sukadev]

Serge E. Hallyn [EMAIL PROTECTED] wrote:
| Quoting Srivatsa Vaddagiri ([EMAIL PROTECTED]):
| > On Fri, Nov 09, 2007 at 09:45:21AM +0100, Dmitry Adamushko wrote:
| > > Humm... the 'current' is not kept within the tree but
| > > current->se.on_rq is supposed to be '1' ,
| > > so the old code looks ok to me (at least for the 'leaf' elements).
| > 
| > You are damned right! Sorry my mistake with the previous analysis and
| > (as I now find out) testing :(
| > 
| > There are couple of problems discovered by Suka's test:
| > 
| > - The test requires the cgroup filesystem to be mounted with
| >   atleast the cpu and ns options (i.e both namespace and cpu 
| >   controllers are active in the same hierarchy). 
| > 
| > # mkdir /dev/cpuctl
| > # mount -t cgroup -ocpu,ns none cpuctl
| > (or simply)
| > # mount -t cgroup none cpuctl -> Will activate all controllers
| >  in same hierarchy.
| > 
| > - The test invokes clone() with CLONE_NEWNS set. This causes a a new child
| >   to be created, also a new group 
(do_fork->copy_namespaces->ns_cgroup_clone->
| >   cgroup_clone) and the child is attached to the new group (cgroup_clone->
| >   attach_task->sched_move_task). At this point in time, the child's 
scheduler 
| >   related fields are uninitialized (including its on_rq field, which it has
| >   inherited from parent). As a result sched_move_task thinks its on
| >   runqueue, when it isn't.
| > 
| >   As a solution to this problem, I moved sched_fork() call, which
| >   initializes scheduler related fields on a new task, before
| >   copy_namespaces(). I am not sure though whether moving up will
| >   cause other side-effects. Do you see any issue?
| > 
| > - The second problem exposed by this test is that task_new_fair()
| >   assumes that parent and child will be part of the same group (which 
| >   needn't be as this test shows). As a result, cfs_rq->curr can be NULL
| >   for the child.
| > 
| >   The solution is to test for curr pointer being NULL in
| >   task_new_fair().
| > 
| > 
| > With the patch below, I could run ns_exec() fine w/o a crash.
| > 
| > Suka, can you verify whether this patch fixes your problem?
| 
| Works on my machine.  Thanks!

And mine too.  Thanks,


| 
| > --
| > 
| > Fix copy_namespace() <-> sched_fork() dependency in do_fork, by moving
| > up sched_fork().
| > 
| > Also introduce a NULL pointer check for 'curr' in task_new_fair().
| > 
| > Signed-off-by : Srivatsa Vaddagiri <[EMAIL PROTECTED]>
| 
| Tested-by: Serge Hallyn <[EMAIL PROTECTED]>
Tested-by: Sukadev Bhattiprolu <[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: AppArmor Security Goal

[Crispin Cowan]

Alan Cox wrote:
>> Can you explain why you want a non-privileged user to be able to edit
>> policy? I would like to better understand the problem here.
>> 
> Because root doesn't trust users who in turn may not trust apps they run
> or wish to control things. I don't see a problem with that viewpoint in
> terms of forbidding things providing the user (or process tree) does not
> get to undo rules merely add more restrictions.
>   
Do you mean that the OS privilege of "uid 0" does not trust
non-privileged users? Or you mean that the human in charge of root on
the box does not trust the human who owns the account "alice" on the box?

In the case of the former, this is exactly why AppArmor does not let
non-privileged users edit security policy. SELinux, SMACK, LIDS, etc.
also all treat manipulating policy as privileged.

In the case of the latter, my main claim is that such circumstances are
rare, because most users have their own personal workstation. Of course
there are exceptions where people are using a multi-user host, and I'm
not saying that there is anything wrong with that, just that AppArmor is
not particularly good at supporting that environment.

I know that multi-user machines is the classic UNIX environment, but
that model has slowly faded away and is little used any more, so
AppArmor made a trade-off for simplicity at the expense of supporting
this use case.

User-extensible security policy is a hard problem, and AppArmor does not
attempt to solve it.

>> non-privileged user to further tighten the profile on a program. To me,
>> that adds complexity with not much value, but if lots of users want it,
>> then I'm wrong :)
>> 
> Assuming you have any value in the first place, which is another topic, I
> can see value for this in all the security models.
>   
There is value in most features, and the question is whether the feature
pays its freight, does the value exceed the cost? AppArmor is
particularly sensitive to cost/benefit ratios, because much of
AppArmor's value is its simplicity, so there is a naturally high barrier
to adding complicating features to AppArmor.

All of this is valid discussion for how AppArmor might be improved, but
is far, far removed from the dual question that Arjan posed:

* Is the model valid? Not "is it exactly what I want?" but merely
  "is it non-silly, such that clearly it provides value to some users?"
* Does the code live up to the model?

I submit that the AppArmor model is valid, even if it totally failed all
of David Gilbert's questions (I think AppArmor can actually provide
about half of what he asked for).

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cd/dvd inaccessible in 2.6.24-rc2

[Alan Cox]

On Sat, 10 Nov 2007 14:49:23 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:

> On Sat, 10 Nov 2007 15:27:11 +1100 Will Trives <[EMAIL PROTECTED]> wrote:
> 
> > 
> > Hello,
> > 
> > Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
> > Chipset: Intel P35 + ICH9R 
> > PATA port runs off JMicron controller
> > CD/DVD Device: BENQ DW1640 16X
> > 
> > I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
> > 2.6.23. Basically the drive is detected OK, everything looks ok but as
> > soon as I go to use it errors like this occur:

Guess what - jmicron hasn't changed in this tree for ages 8(

> > ata9.00: qc timeout (cmd 0xa0)
> > ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> > ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
> > in
> >  res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> > ata9.00: status: { DRDY ERR }

Could be an IRQ/ACPI regression, and in fact to me it looks more like
that, than an IDE one. Probably worth trying the various IRQ routing
options and seeing if they help.


Alan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] NFS: Fix the ustat() regression

[Kumar Gala]

From: Trond Myklebust <[EMAIL PROTECTED]>

Since 2.6.18, the superblock sb->s_root has been a dummy dentry with a
dummy inode. This breaks ustat(), which actually uses sb->s_root in a
vfstat() call.

Fix this by making the s_root a dummy alias to the directory inode that was
used when creating the superblock.

Signed-off-by: Trond Myklebust <[EMAIL PROTECTED]>
Signed-off-by: Kumar Gala <[EMAIL PROTECTED]>
---
 fs/nfs/getroot.c |   81 ++
 1 files changed, 27 insertions(+), 54 deletions(-)

diff --git a/fs/nfs/getroot.c b/fs/nfs/getroot.c
index 522e5ad..0ee4384 100644
--- a/fs/nfs/getroot.c
+++ b/fs/nfs/getroot.c
@@ -43,6 +43,25 @@
 #define NFSDBG_FACILITYNFSDBG_CLIENT

 /*
+ * Set the superblock root dentry.
+ * Note that this function frees the inode in case of error.
+ */
+static int nfs_superblock_set_dummy_root(struct super_block *sb, struct inode 
*inode)
+{
+   /* The mntroot acts as the dummy root dentry for this superblock */
+   if (sb->s_root == NULL) {
+   sb->s_root = d_alloc_root(inode);
+   if (sb->s_root == NULL) {
+   iput(inode);
+   return -ENOMEM;
+   }
+   /* Circumvent igrab(): we know the inode is not being freed */
+   atomic_inc(>i_count);
+   }
+   return 0;
+}
+
+/*
  * get an NFS2/NFS3 root dentry from the root filehandle
  */
 struct dentry *nfs_get_root(struct super_block *sb, struct nfs_fh *mntfh)
@@ -54,33 +73,6 @@ struct dentry *nfs_get_root(struct super_block *sb, struct 
nfs_fh *mntfh)
struct inode *inode;
int error;

-   /* create a dummy root dentry with dummy inode for this superblock */
-   if (!sb->s_root) {
-   struct nfs_fh dummyfh;
-   struct dentry *root;
-   struct inode *iroot;
-
-   memset(, 0, sizeof(dummyfh));
-   memset(, 0, sizeof(fattr));
-   nfs_fattr_init();
-   fattr.valid = NFS_ATTR_FATTR;
-   fattr.type = NFDIR;
-   fattr.mode = S_IFDIR | S_IRUSR | S_IWUSR;
-   fattr.nlink = 2;
-
-   iroot = nfs_fhget(sb, , );
-   if (IS_ERR(iroot))
-   return ERR_PTR(PTR_ERR(iroot));
-
-   root = d_alloc_root(iroot);
-   if (!root) {
-   iput(iroot);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   sb->s_root = root;
-   }
-
/* get the actual root for this mount */
fsinfo.fattr = 

@@ -96,6 +88,10 @@ struct dentry *nfs_get_root(struct super_block *sb, struct 
nfs_fh *mntfh)
return ERR_PTR(PTR_ERR(inode));
}

+   error = nfs_superblock_set_dummy_root(sb, inode);
+   if (error != 0)
+   return ERR_PTR(error);
+
/* root dentries normally start off anonymous and get spliced in later
 * if the dentry tree reaches them; however if the dentry already
 * exists, we'll pick it up at this point and use it as the root
@@ -241,33 +237,6 @@ struct dentry *nfs4_get_root(struct super_block *sb, 
struct nfs_fh *mntfh)

dprintk("--> nfs4_get_root()\n");

-   /* create a dummy root dentry with dummy inode for this superblock */
-   if (!sb->s_root) {
-   struct nfs_fh dummyfh;
-   struct dentry *root;
-   struct inode *iroot;
-
-   memset(, 0, sizeof(dummyfh));
-   memset(, 0, sizeof(fattr));
-   nfs_fattr_init();
-   fattr.valid = NFS_ATTR_FATTR;
-   fattr.type = NFDIR;
-   fattr.mode = S_IFDIR | S_IRUSR | S_IWUSR;
-   fattr.nlink = 2;
-
-   iroot = nfs_fhget(sb, , );
-   if (IS_ERR(iroot))
-   return ERR_PTR(PTR_ERR(iroot));
-
-   root = d_alloc_root(iroot);
-   if (!root) {
-   iput(iroot);
-   return ERR_PTR(-ENOMEM);
-   }
-
-   sb->s_root = root;
-   }
-
/* get the info about the server and filesystem */
error = nfs4_server_capabilities(server, mntfh);
if (error < 0) {
@@ -289,6 +258,10 @@ struct dentry *nfs4_get_root(struct super_block *sb, 
struct nfs_fh *mntfh)
return ERR_PTR(PTR_ERR(inode));
}

+   error = nfs_superblock_set_dummy_root(sb, inode);
+   if (error != 0)
+   return ERR_PTR(error);
+
/* root dentries normally start off anonymous and get spliced in later
 * if the dentry tree reaches them; however if the dentry already
 * exists, we'll pick it up at this point and use it as the root
-- 
1.5.3.4

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  

Re: Temporary lockup on loopback block device

[Peter Zijlstra]

On Sat, 2007-11-10 at 14:54 -0800, Andrew Morton wrote:
> On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]> 
> wrote:
> 
> > Hi
> > 
> > I am experiencing a transient lockup in 'D' state with loopback device. It 
> > happens when process writes to a filesystem in loopback with command like
> > dd if=/dev/zero of=/s/fill bs=4k 
> > 
> > CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in 
> > congestion_wait called from balance_dirty_pages.
> > 
> > After about 30 seconds, the lockup is gone and dd resumes, but it locks up 
> > soon again.
> > 
> > I added a printk to the balance_dirty_pages
> > printk("wait: nr_reclaimable %d, nr_writeback %d, dirty_thresh %d, 
> > pages_written %d, write_chunk %d\n", nr_reclaimable, 
> > global_page_state(NR_WRITEBACK), dirty_thresh, pages_written, 
> > write_chunk);
> > 
> > and it shows this during the lockup:
> > 
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> > pages_written 1021, write_chunk 1522
> > 
> > What apparently happens:
> > 
> > writeback_inodes syncs inodes only on the given wbc->bdi, however 
> > balance_dirty_pages checks against global counts of dirty pages. So if 
> > there's nothing to sync on a given device, but there are other dirty pages 
> > so that the counts are over the limit, it will loop without doing any 
> > work.
> > 
> > To reproduce it, you need totally idle machine (no GUI, etc.) -- if 
> > something writes to the backing device, it flushes the dirty pages 
> > generated by the loopback and the lockup is gone. If you add printk, don't 
> > forget to stop klogd, otherwise logging would end the lockup.
> 
> erk.

known issue.

> > The hotfix (that I verified to work) is to not set wbc->bdi, so that all 
> > devices are flushed ... but the code probably needs some redesign (i.e. 
> > either account per-device and flush per-device, or account-global and 
> > flush-global).

.24 will have the per-device solution.

> > 
> > diff -u -r ../x/linux-2.6.23.1/mm/page-writeback.c mm/page-writeback.c
> > --- ../x/linux-2.6.23.1/mm/page-writeback.c 2007-10-12 
> > 18:43:44.0 +0200
> > +++ mm/page-writeback.c 2007-11-10 20:32:43.0 +0100
> > @@ -214,7 +214,6 @@
> > 
> > for (;;) {
> > struct writeback_control wbc = {
> > -   .bdi= bdi,
> > .sync_mode  = WB_SYNC_NONE,
> > .older_than_this = NULL,
> > .nr_to_write= write_chunk,
> 
> Arguably we just have the wrong backing-device here, and what we should do
> is to propagate the real backing device's pointer through up into the
> filesystem.  There's machinery for this which things like DM stacks use.
> 
> I wonder if the post-2.6.23 changes happened to make this problem go away.

The per BDI dirty stuff in 24 should make this work, I just checked and
loopback thingies seem to have their own BDI, so all should be 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: AppArmor Security Goal

[Alan Cox]

> Can you explain why you want a non-privileged user to be able to edit
> policy? I would like to better understand the problem here.

Because root doesn't trust users who in turn may not trust apps they run
or wish to control things. I don't see a problem with that viewpoint in
terms of forbidding things providing the user (or process tree) does not
get to undo rules merely add more restrictions.

> non-privileged user to further tighten the profile on a program. To me,
> that adds complexity with not much value, but if lots of users want it,
> then I'm wrong :)

Assuming you have any value in the first place, which is another topic, I
can see value for this in all the security models.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Temporary lockup on loopback block device

[Andrew Morton]

On Sat, 10 Nov 2007 20:51:31 +0100 (CET) Mikulas Patocka <[EMAIL PROTECTED]> 
wrote:

> Hi
> 
> I am experiencing a transient lockup in 'D' state with loopback device. It 
> happens when process writes to a filesystem in loopback with command like
> dd if=/dev/zero of=/s/fill bs=4k 
> 
> CPU is idle, disk is idle too, yet the dd process is waiting in 'D' in 
> congestion_wait called from balance_dirty_pages.
> 
> After about 30 seconds, the lockup is gone and dd resumes, but it locks up 
> soon again.
> 
> I added a printk to the balance_dirty_pages
> printk("wait: nr_reclaimable %d, nr_writeback %d, dirty_thresh %d, 
> pages_written %d, write_chunk %d\n", nr_reclaimable, 
> global_page_state(NR_WRITEBACK), dirty_thresh, pages_written, 
> write_chunk);
> 
> and it shows this during the lockup:
> 
> wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> pages_written 1021, write_chunk 1522
> wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> pages_written 1021, write_chunk 1522
> wait: nr_reclaimable 3099, nr_writeback 0, dirty_thresh 2985, 
> pages_written 1021, write_chunk 1522
> 
> What apparently happens:
> 
> writeback_inodes syncs inodes only on the given wbc->bdi, however 
> balance_dirty_pages checks against global counts of dirty pages. So if 
> there's nothing to sync on a given device, but there are other dirty pages 
> so that the counts are over the limit, it will loop without doing any 
> work.
> 
> To reproduce it, you need totally idle machine (no GUI, etc.) -- if 
> something writes to the backing device, it flushes the dirty pages 
> generated by the loopback and the lockup is gone. If you add printk, don't 
> forget to stop klogd, otherwise logging would end the lockup.

erk.

> The hotfix (that I verified to work) is to not set wbc->bdi, so that all 
> devices are flushed ... but the code probably needs some redesign (i.e. 
> either account per-device and flush per-device, or account-global and 
> flush-global).
> 
> Mikulas
> 
> 
> diff -u -r ../x/linux-2.6.23.1/mm/page-writeback.c mm/page-writeback.c
> --- ../x/linux-2.6.23.1/mm/page-writeback.c 2007-10-12 18:43:44.0 
> +0200
> +++ mm/page-writeback.c 2007-11-10 20:32:43.0 +0100
> @@ -214,7 +214,6 @@
> 
>   for (;;) {
>   struct writeback_control wbc = {
> - .bdi= bdi,
>   .sync_mode  = WB_SYNC_NONE,
>   .older_than_this = NULL,
>   .nr_to_write= write_chunk,

Arguably we just have the wrong backing-device here, and what we should do
is to propagate the real backing device's pointer through up into the
filesystem.  There's machinery for this which things like DM stacks use.

I wonder if the post-2.6.23 changes happened to make this problem 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: WARNING: at lib/kref.c:33 kref_get() (-mm 2007-11-06-02-32++)

[Andrew Morton]

On Fri, 9 Nov 2007 21:12:47 -0500 Erez Zadok <[EMAIL PROTECTED]> wrote:

> Setup: FC6 system with MM snapshot broken-out-2007-11-06-02-32

That's a bit old.

> and these two
> patches added:
> 
> r-o-bind-mounts-track-number-of-mount-writer-fix-buggy-loop.patch
> r-o-bind-mounts-track-number-of-mount-writer-fix-buggy-loop-checkpatch-fixes.patch
> 
> Booting the machine, waiting a few minutes (not logging in or doing anything
> else).  I get:
> 
> WARNING: at lib/kref.c:33 kref_get()
>  [] show_trace_log_lvl+0x12/0x25
>  [] show_trace+0xd/0x10
>  [] dump_stack+0x15/0x17
>  [] kref_get+0x26/0x30
>  [] kobject_get+0x12/0x17
>  [] kobject_add+0x97/0x162
>  [] uids_user_create+0x41/0x5d
>  [] alloc_uid+0xc9/0x171
>  [] set_user+0x1f/0x93
>  [] sys_setuid+0x4b/0xcb
>  [] sysenter_past_esp+0x5f/0x91
>  ===
> 
> There's no other indication where the setuid(2) came from, perhaps cron?
> 

I have a feeling that this was reported before and that Dave and/or Greg
looked into it.  Were those two patches which Dave sent yesterday applied?

It might be worth checking my current tree:
http://userweb.kernel.org/~akpm/mmotm/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: cd/dvd inaccessible in 2.6.24-rc2

[Andrew Morton]

On Sat, 10 Nov 2007 15:27:11 +1100 Will Trives <[EMAIL PROTECTED]> wrote:

> 
> Hello,
> 
> Motherboard: Gigabyte GA-P35-DS4 (rev. 1.1)
> Chipset: Intel P35 + ICH9R 
> PATA port runs off JMicron controller
> CD/DVD Device: BENQ DW1640 16X
> 
> I cannot access my dvd burner under 2.6.24-rc2, I have no problems under
> 2.6.23. Basically the drive is detected OK, everything looks ok but as
> soon as I go to use it errors like this occur:
> 
> 
> ata9.00: qc timeout (cmd 0xa0)
> ata9.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
> ata9.00: cmd a0/00:00:00:02:00/00:00:00:00:00/a0 tag 0 cdb 0x5a data 2
> in
>  res 51/54:03:00:02:00/00:00:00:00:00/a0 Emask 0x5 (timeout)
> ata9.00: status: { DRDY ERR }
> ata9: soft resetting link
> ata9.00: revalidation failed (errno=-2)
> ata9: failed to recover some devices, retrying in 5 secs
> ata9: soft resetting link
> ata9.00: qc timeout (cmd 0xa1)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata9.00: revalidation failed (errno=-5)
> ata9: failed to recover some devices, retrying in 5 secs
> ata9: soft resetting link
> ata9.00: qc timeout (cmd 0xa1)
> ata9.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> ata9.00: revalidation failed (errno=-5)
> ata9.00: disabled
> ata9: soft resetting link
> ata9: EH complete
> 
> The drive is locked up after the first attempt to access it occurs, the
> tray cannot be ejected. 
> 
> 
> dmesg output
> 
> http://paste.ubuntu-nl.org/43948/
> 
> kernel .config
> 
> http://paste.ubuntu-nl.org/43944/
> 
> lspci -vvv
> 
> http://paste.ubuntu-nl.org/43950/
> 

Thanks for letting us know.

Added linux-ide Cc.

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

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

[Sam Ravnborg]

On Sat, Nov 10, 2007 at 02:33:02PM -0800, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 21:40:38 +0100 Sam Ravnborg wrote:
> 
> > As discussed in another thread the right thing is to add a generic solution
> > to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> > 
> > First step was to teach kconfig how to force 64BIT to a specific value.
> > The x86 Kconfig file needed a small twist to use 64BIT as the symbol
> > to seelct 32 or 64 bit.
> > Then it was simple to add backward compatibility ARCH= settings.
> > 
> > The patchset is not yet pushed out - I will await a bit feedback first.
> > 
> > Shortlog and diffstat.
> >   kconfig: factor out code in confdata.c
> >   kconfig: use $K64BIT to set 64BIT with all*config targets
> >   x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig
> >   kconfig: document make K64BIT=y in README
> >   x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit
> 
> Hi Sam,
> Looks good to me and should satisfy our habits^w usages models.
> 
> The one minor question is the environment variable name (K64BIT or
> something else, like Guillaume brought up).  Personally I don't
> care how it's spelled.  IOW, K64BIT is sufficient, but if there is a
> goal to be able to place any CONFIG_symbol on the command line or
> as an env. variable, they might as well all be named with CONFIG_*.

The K64BIT varibale came up because it is more unique than CONFIG_64BIT.
Google turned up less than 20 hits[1] on K64BIT but 14900 on CONFIG_64BIT.
And I dunno if some people source their .config or other crazy stuff.

And then K64BIT was easier to type...
But if we assume this is internal stuff only then we could go
for the longer version and I will then suggest to prefix
the CONFIG_ symbol with K like in KCONFIG_64BIT which
has no hits with google right now!

I do not see this extended to 'any' CONFIG_ symbol
but maybe the 4 most important ones.
[64BIT, SMP, PREEMPT, ?]

[1] before my posting - now we are up to ~80.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Crispin Cowan]

Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
>   
>> I don't get the problem: if you want your web browser to be able to
>> access where you commonly store your documents, then give it that
>> permission. The above rule says that your web browser doesn't get to go
>> change AppArmor policy on its own.
>> 
> But can I as a non-privileged user say which directories I want it to
> be able to access?
>   
No, you have to be privileged (root) to edit security policy and to
reload policy.

I mostly don't see this as a serious limitation, because almost everyone
has their own workstation, and thus has root on that workstation. There
are 2 major exceptions:

* Schools, where the "workstations" are thin client X terminals and
  everyone is logged into a giant shared machine. Sorry, AppArmor is
  not a good choice for that environment, but it is a pretty scarce
  environment.
* Enterprises, where workers get their own workstation, but they
  don't get root. Well, the reason the worker doesn't get root is
  the enterprise doesn't trust them with it, and so not letting them
  edit security policy is probably a good idea.

Can you explain why you want a non-privileged user to be able to edit
policy? I would like to better understand the problem here.

Note that John Johansen is also interested in allowing non-privileged
users to manipulate AppArmor policy, but his view was to only allow a
non-privileged user to further tighten the profile on a program. To me,
that adds complexity with not much value, but if lots of users want it,
then I'm wrong :)

>> I have serious doubts about the utility of restricting a text editor.
>> You nominally want to be able to edit any file on the system, so
>> confining it would be fairly meaningless.
>> 
> Text editor probably true; but I'm thinking here more of OpenOffice
> and the like; there have been plenty of document carried malware in the
> past.
>   
How to usefully confine an office suite like OpenOffice is current work
at Mercenary Linux. We think we have a solution that is just AppArmor
policy, without having to do any feature enhancements.

>>> Similarly I'd like to be able to split applications so that
>>> the 'preferences' editing facilities are done by separate
>>> envrionments so that there is no way that a fault in parsing
>>> external data could edit the config (e.g. change home page or
>>> proxy in a browser or default document in an editor).  
>>>   
>> AppArmor will let you do that; most of the work is in splitting the
>> application. If you can get e.g. Firefox to use a separate process that
>> it exec's for editing your preferences, then AppArmor can confine that
>> helper app with a different policy than Firefox itself, including
>> granting the helper write permission to the config directory.
>> 
> Yes, and designing the app so that it's filenames are predictable;
> firefox has a fun habit of using randomly named profile directories.
>   
You just glob that directory, so the rule would look like:

/home/*/.mozilla/default/*/prefs.js rw,

if you wanted it to be a generic policy for all users. If you want a
tighter policy for your workstation, then it might look like

/home/dagilbert/.mozilla/default/somemozillarandomstring/prefs.js rw,

hard-coding both your username and the random directory name that
Mozilla chose.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:



> * Manipulating AppArmor policy requires being both root privileged
>   and not being confined by AppArmor, thus there is explicitly no
>   capability for non-privileged users to change AppArmor policy.

It's a pity that there is no way to do this; it would be nice to restrict
web browsers, document editors etc but allow them
to access the places you commonly store documents etc.

Similarly I'd like to be able to split applications so that
the 'preferences' editing facilities are done by separate
envrionments so that there is no way that a fault in parsing
external data could edit the config (e.g. change home page or
proxy in a browser or default document in an editor).

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

[Randy Dunlap]

On Sat, 10 Nov 2007 21:40:38 +0100 Sam Ravnborg wrote:

> As discussed in another thread the right thing is to add a generic solution
> to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.
> 
> First step was to teach kconfig how to force 64BIT to a specific value.
> The x86 Kconfig file needed a small twist to use 64BIT as the symbol
> to seelct 32 or 64 bit.
> Then it was simple to add backward compatibility ARCH= settings.
> 
> The patchset is not yet pushed out - I will await a bit feedback first.
> 
> Shortlog and diffstat.
>   kconfig: factor out code in confdata.c
>   kconfig: use $K64BIT to set 64BIT with all*config targets
>   x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig
>   kconfig: document make K64BIT=y in README
>   x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit

Hi Sam,
Looks good to me and should satisfy our habits^w usages models.

The one minor question is the environment variable name (K64BIT or
something else, like Guillaume brought up).  Personally I don't
care how it's spelled.  IOW, K64BIT is sufficient, but if there is a
goal to be able to place any CONFIG_symbol on the command line or
as an env. variable, they might as well all be named with CONFIG_*.

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

Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets

[Sam Ravnborg]

On Sat, Nov 10, 2007 at 02:16:19PM -0800, Randy Dunlap wrote:
> On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:
> 
> > The variable K64BIT can now be used to select the
> > value of CONFIG_64BIT.
> > 
> > This is for example useful for powerpc to generate
> > allmodconfig for both bit sizes - like this:
> > make ARCH=powerpc K64BIT=y
> > make ARCH=powerpc K64BIT=n
> > 
> > To use this the Kconfig file must use "64BIT" as the
> > config value to select between 32 and 64 bit.
> > 
> > Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> > ---
> >  scripts/kconfig/conf.c  |1 +
> >  scripts/kconfig/confdata.c  |   27 +++
> >  scripts/kconfig/lkc_proto.h |1 +
> >  3 files changed, 29 insertions(+), 0 deletions(-)
> > 
> > diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> > index a38787a..c6bee85 100644
> > --- a/scripts/kconfig/conf.c
> > +++ b/scripts/kconfig/conf.c
> > @@ -591,6 +591,7 @@ int main(int ac, char **av)
> > conf_read_simple(name, S_DEF_USER);
> > else if (!stat("all.config", ))
> > conf_read_simple("all.config", S_DEF_USER);
> > +   conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
> > break;
> > default:
> > break;
> > diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> > index e0f402f..0cb7555 100644
> > --- a/scripts/kconfig/confdata.c
> > +++ b/scripts/kconfig/confdata.c
> > @@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int 
> > def, int def_flags, char *p)
> > return 0;
> >  }
> >  
> > +/* Read an environment variable and assign the vaule to the symbol */
> 
>   value
> 
> > +int conf_set_env_sym(const char *env, const char *symname, int def)
> > +{
> > +   struct symbol *sym;
> > +   char *p;
> > +   int def_flags;
> > +
> > +   p = getenv(env);
> > +   if (p) {
> > +   char warning[100];
> > +   sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> > +   conf_filename = warning;
> 
> What's with  and  here?  I don't see how
> they are used in this function or in the caller of this function.

Added to allow conf_warning to print out something usefull.
Like in the following example:

make K64BIT=randy allnoconfig

Environment variable (K64BIT = "randy"):0:warning: symbol value 'randy' invalid 
for 64BIT


This could look better - but I preferred this version for the
less readable:
(null):0:warning: symbol value 'randy' invalid for 64BIT

Thanks for the other inputs. I am correcting them in
my local patch-set. Before resubmit I willawait further comments.

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: dib7000m_i2c_enumeration() is unused

[Patrick Boettcher]

Hi all,

This is another story of "the chip-vendor provides driver support and is 
waiting for device to hit the market". 

DiBcom knows that there are devices out there that are using the dib7000m 
in way that they need the dib7000m_i2c_enumeration to work properly. But 
it is impossible to know the devices in advance. This function is there 
for the case a user or developper needs it to add support for his board.

Patrick.

--
  Mail: [EMAIL PROTECTED]
  WWW:  http://www.wi-bw.tfh-wildau.de/~pboettch/




On Mon, 5 Nov 2007, Adrian Bunk wrote:

> dib7000m_i2c_enumeration() is currently unused, but although I don't 
> understand the code I have a gut feeling it should have been used in 
> dib0700_devices.c. Is this correct?
> 
> 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: AppArmor Security Goal

[Dr. David Alan Gilbert]

* Crispin Cowan ([EMAIL PROTECTED]) wrote:
> Dr. David Alan Gilbert wrote:
> > * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> >  >> * Manipulating AppArmor policy requires being both root privileged
> >>   and not being confined by AppArmor, thus there is explicitly no
> >>   capability for non-privileged users to change AppArmor policy.
> >> 
> > It's a pity that there is no way to do this; it would be nice to restrict
> > web browsers, document editors etc but allow them
> > to access the places you commonly store documents etc.
> >   
> I don't get the problem: if you want your web browser to be able to
> access where you commonly store your documents, then give it that
> permission. The above rule says that your web browser doesn't get to go
> change AppArmor policy on its own.

But can I as a non-privileged user say which directories I want it to
be able to access?

> I have serious doubts about the utility of restricting a text editor.
> You nominally want to be able to edit any file on the system, so
> confining it would be fairly meaningless.

Text editor probably true; but I'm thinking here more of OpenOffice
and the like; there have been plenty of document carried malware in the
past.

> > Similarly I'd like to be able to split applications so that
> > the 'preferences' editing facilities are done by separate
> > envrionments so that there is no way that a fault in parsing
> > external data could edit the config (e.g. change home page or
> > proxy in a browser or default document in an editor).
> >   
> AppArmor will let you do that; most of the work is in splitting the
> application. If you can get e.g. Firefox to use a separate process that
> it exec's for editing your preferences, then AppArmor can confine that
> helper app with a different policy than Firefox itself, including
> granting the helper write permission to the config directory.

Yes, and designing the app so that it's filenames are predictable;
firefox has a fun habit of using randomly named profile directories.

Dave
-- 
 -Open up your eyes, open up your mind, open up your code ---   
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy  \ 
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC & HPPA | In Hex /
 \ _|_ http://www.treblig.org   |___/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: document make K64BIT=y in README

[Randy Dunlap]

On Sat, 10 Nov 2007 21:43:28 +0100 Sam Ravnborg wrote:

> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> ---
>  README |2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
> 
> diff --git a/README b/README
> index 159912c..6622ba1 100644
> --- a/README
> +++ b/README
> @@ -194,6 +194,8 @@ CONFIGURING the kernel:
> "make *config" checks for a file named "all{yes/mod/no/random}.config"
> for symbol values that are to be forced.  If this file is not found,
> it checks for a file named "all.config" to contain forced values.
> +   Finally it checks the environment variable K64BIT and set the config

and if found, sets
  the config symbol "64BIT" ...


> +   symbol "64BIT" to the value of the K64BIT variable.
> 
>   NOTES on "make config":
>   - having unnecessary drivers will make the kernel bigger, and can
> -- 

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

Re: [PATCH] x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig

[Randy Dunlap]

On Sat, 10 Nov 2007 21:43:27 +0100 Sam Ravnborg wrote:

> This change allow us to use the new syntax:
> make K64BIT={n,y} to select between 32 and 64 bit.
> 
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> ---
>  arch/x86/Kconfig |   26 --
>  1 files changed, 8 insertions(+), 18 deletions(-)
> 
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 153c26c..0d86611 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1,34 +1,24 @@
>  # x86 configuration
>  
>  # Select 32 or 64 bit
> -choice
> - bool "Select 32 or 64 bit"
> - default X86_32
> +config 64BIT
> + bool "64 Bit kernel"

bool "64-bit kernel"

> + default n
> + help
> +   Say yes to build a 64 bit kernel - formerly known as x86_64

 64-bit

> +   Say no to build a 32 bit kernel - formerly known as i386

32-bit

>  
>  config X86_32
> - bool "32 bit (former ARCH=i386)"
> - help
> -   This is Linux's home port.  Linux was originally native to the Intel
> -   386, and runs on all the later x86 processors including the Intel
> -   486, 586, Pentiums, and various instruction-set-compatible chips by
> -   AMD, Cyrix, and others.
> + def_bool !64BIT
>  
>  config X86_64
> - bool "64 bit (former ARCH=x86_64)"
> - help
> -   Port to the x86-64 architecture. x86-64 is a 64-bit extension to the
> -   classical 32-bit x86 architecture. For details see
> -   .
> -endchoice
> + def_bool 64BIT
>  
>  ### Arch settings
>  config X86
>   bool
>   default y
>  
> -config 64BIT
> - def_bool X86_64
> -
>  config GENERIC_TIME
>   bool
>   default y
> -- 


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

Re: [PATCH] kconfig: use $K64BIT to set 64BIT with all*config targets

[Randy Dunlap]

On Sat, 10 Nov 2007 21:43:26 +0100 Sam Ravnborg wrote:

> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.
> 
> This is for example useful for powerpc to generate
> allmodconfig for both bit sizes - like this:
> make ARCH=powerpc K64BIT=y
> make ARCH=powerpc K64BIT=n
> 
> To use this the Kconfig file must use "64BIT" as the
> config value to select between 32 and 64 bit.
> 
> Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
> ---
>  scripts/kconfig/conf.c  |1 +
>  scripts/kconfig/confdata.c  |   27 +++
>  scripts/kconfig/lkc_proto.h |1 +
>  3 files changed, 29 insertions(+), 0 deletions(-)
> 
> diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
> index a38787a..c6bee85 100644
> --- a/scripts/kconfig/conf.c
> +++ b/scripts/kconfig/conf.c
> @@ -591,6 +591,7 @@ int main(int ac, char **av)
>   conf_read_simple(name, S_DEF_USER);
>   else if (!stat("all.config", ))
>   conf_read_simple("all.config", S_DEF_USER);
> + conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
>   break;
>   default:
>   break;
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index e0f402f..0cb7555 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int def, 
> int def_flags, char *p)
>   return 0;
>  }
>  
> +/* Read an environment variable and assign the vaule to the symbol */

  value

> +int conf_set_env_sym(const char *env, const char *symname, int def)
> +{
> + struct symbol *sym;
> + char *p;
> + int def_flags;
> +
> + p = getenv(env);
> + if (p) {
> + char warning[100];
> + sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
> + conf_filename = warning;

What's with  and  here?  I don't see how
they are used in this function or in the caller of this function.

> + def_flags = SYMBOL_DEF << def;
> + if (def == S_DEF_USER) {
> + sym = sym_find(symname);
> + if (!sym)
> + return 1;
> + } else {
> + sym = sym_lookup(symname, 0);
> + if (sym->type == S_UNKNOWN)
> + sym->type = S_OTHER;
> + }
> + conf_set_sym_val(sym, def, def_flags, p);
> + }
> + return 0;
> +}
> +
>  int conf_read_simple(const char *name, int def)
>  {
>   FILE *in = NULL;

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

Re: AppArmor Security Goal

[Crispin Cowan]

Dr. David Alan Gilbert wrote:
> * Crispin Cowan ([EMAIL PROTECTED]) wrote:
> > * Manipulating AppArmor policy requires being both root privileged
>>   and not being confined by AppArmor, thus there is explicitly no
>>   capability for non-privileged users to change AppArmor policy.
>> 
> It's a pity that there is no way to do this; it would be nice to restrict
> web browsers, document editors etc but allow them
> to access the places you commonly store documents etc.
>   
I don't get the problem: if you want your web browser to be able to
access where you commonly store your documents, then give it that
permission. The above rule says that your web browser doesn't get to go
change AppArmor policy on its own.

I have serious doubts about the utility of restricting a text editor.
You nominally want to be able to edit any file on the system, so
confining it would be fairly meaningless.

> Similarly I'd like to be able to split applications so that
> the 'preferences' editing facilities are done by separate
> envrionments so that there is no way that a fault in parsing
> external data could edit the config (e.g. change home page or
> proxy in a browser or default document in an editor).
>   
AppArmor will let you do that; most of the work is in splitting the
application. If you can get e.g. Firefox to use a separate process that
it exec's for editing your preferences, then AppArmor can confine that
helper app with a different policy than Firefox itself, including
granting the helper write permission to the config directory.

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] virtio config_ops refactoring

[Anthony Liguori]

Rusty Russell wrote:

On Saturday 10 November 2007 10:45:38 Anthony Liguori wrote:
  

The problem is the ABI.  We can either require that PCI configuration
values are accessed with natural instructions, or it makes very little
sense to use the PCI configuration space for virtio configuration
information.



To me it seems logical and simplest to allow any accesses, lay out your 
structure and emulate it in the obvious way.
  


Okay, I've got some updates that I'm going to send out now to the PCI 
virtio driver but I'll also change it to switch over to a memory 
layout.  It's not the best PCI ABI but I can certainly live with it.


You can put the configuration information somewhere else, but the PCI config 
space seems the logical place.
  


If we're treating the PCI config space as an opaque memory blob, instead 
of as distinct registers, I think it makes more sense to just put it in 
memory.  In the backend, I have to treat it as a memory blob anyway and 
using the PCI config space just means that I have to write all the 
various PIO handlers for the different access sizes.  It's much more 
elegant in my mind just to have the driver provide some memory that the 
host fills out.


Thanks for all the review,

Anthony Liguori


Either virtio config looks like a shared memory area (as lguest
currently implements it), or it looks like hardware registers (like
virtio-pci implements it).  After thinking about it for a while, I don't
think the two can be reconciled.  There are subtle differences between
the two that can't be hidden in the virtio interface.  For instance, in
the PCI model, you get notified when values are read/written whereas in
the lguest model, you don't and need explicit status bits.



No.  You need those status bits even if you have your register model, 
otherwise you can't tell when the configuration as a whole is stable.  
Consider the feature bits.  Worse, consider extending the feature bits beyond 
32 bits.


(We will have to deal with dynamic configuration changes in future; I was 
planning on using some status bits.  But it's pretty clear that it's going to 
require an explicit ack of some form.)


Hope that clarifies,
Rusty.

  


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

Re: [RFC 13/13] Char: nozomi, cleanup read and write

[Jiri Slaby]

On 11/10/2007 05:15 PM, Adrian Bunk wrote:
> On Fri, Nov 09, 2007 at 06:51:35PM -0500, Jiri Slaby wrote:
>> ...
>> --- a/drivers/char/nozomi.c
>> +++ b/drivers/char/nozomi.c
>> ...
>> -if (size_bytes - i == 2) {
>> +if (unlikely(size_bytes - i == 2)) {
>> ...
> 
> Please don't add likely/unlikely in drivers unless it brings a 
> measurable improvement.

Why? Anyway I think this is the case. The body of the then branch is executed at
most once, while the else branch each time but last. If you write/read 1002
bytes, it means 250:1. ...and it's invoked from interrupt too...

regards,
-- 
Jiri Slaby ([EMAIL PROTECTED])
Faculty of Informatics, Masaryk 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/

[git patches] net driver fixes

[Jeff Garzik]

Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git 
upstream-linus

to receive the following updates:

 MAINTAINERS  |   10 ++-
 drivers/net/Kconfig  |2 +-
 drivers/net/bonding/bond_main.c  |1 +
 drivers/net/bonding/bond_sysfs.c |4 +-
 drivers/net/pasemi_mac.c |   18 -
 drivers/net/qla3xxx.c|   42 +--
 drivers/net/qla3xxx.h|1 +
 drivers/net/r8169.c  |   26 ++-
 drivers/net/sky2.c   |  116 ++
 drivers/net/sky2.h   |3 +-
 drivers/net/smc91x.h |   15 
 drivers/net/wireless/Kconfig |2 +-
 drivers/net/wireless/b43/Kconfig |   10 ++-
 drivers/net/wireless/b43/debugfs.c   |2 +-
 drivers/net/wireless/b43/main.c  |   19 +++---
 drivers/net/wireless/b43/pcmcia.c|   52 +-
 drivers/net/wireless/b43/rfkill.c|  115 +
 drivers/net/wireless/b43/rfkill.h|   14 +---
 drivers/net/wireless/b43legacy/debugfs.c |2 +-
 drivers/net/wireless/b43legacy/main.c|   21 +++---
 drivers/net/wireless/hostap/hostap_pci.c |6 +-
 drivers/net/wireless/ipw2100.c   |4 +-
 drivers/net/wireless/libertas/cmd.c  |   10 ++-
 drivers/net/wireless/libertas/if_cs.c|7 ++-
 drivers/net/wireless/libertas/if_sdio.c  |4 +-
 drivers/net/wireless/rt2x00/rt2x00mac.c  |8 ++
 26 files changed, 285 insertions(+), 229 deletions(-)

Ciaran McCreesh (1):
  r8169: add PCI ID for the 8168 in the Abit Fatal1ty F-190HD motherboard

Francois Romieu (2):
  r8169: do not enable the TBI for the 8168 and the 81x0
  r8169: prevent bit sign expansion error in mdio_write

Holger Schurig (1):
  libertas: fixes for slow hardware

Ivo van Doorn (1):
  rt2x00: Block adhoc & master mode

Jay Vosburgh (2):
  bonding: fix rtnl locking merge error
  bonding: don't validate address at device open

John W. Linville (1):
  hermes: clarify Intel reference in Kconfig help

Magnus Damm (1):
  ax88796: add superh to kconfig dependencies

Marcelo Tosatti (1):
  libertas: properly account for queue commands

Mark Lord (2):
  r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (partly)
  r8169: revert 7da97ec96a0934319c7fbedd3d38baf533e20640 (bis repetita)

Michael Buesch (7):
  b43: pcmcia-host initialization bugfixes
  b43: Fix rfkill callback deadlock
  b43: debugfs SHM read buffer overrun fix
  b43: Rewrite and fix rfkill init
  b43: properly request pcmcia IRQ
  b43legacy: Fix sparse warning
  b43: Fix kconfig dependencies for rfkill and leds

Olof Johansson (2):
  pasemi_mac: Don't set replace-source-address descriptor bits
  pasemi_mac: Fix CRC checks

Pierre Ossman (1):
  libertas: make if_sdio align packets

Randy Dunlap (1):
  hostap: fix section mismatch warning

Roel Kluin (1):
  ipw2100: fix postfix decrement errors

Ron Mercer (2):
  qla3xxx: bugfix: Move link state machine into a worker thread
  qla3xxx: bugfix: Fix bad logical operation in link state machine.

Stefano Brivio (4):
  b43legacy: fix possible buffer overrun in debugfs
  b43legacy: add me as maintainer and fix URLs
  b43: fix shared IRQ race condition
  b43legacy: fix shared IRQ race condition

Stephen Hemminger (9):
  sky2: enable PCI config writes
  sky2: status ring race fix
  sky2: longer PHY delay
  sky2: dont change LED after autoneg
  sky2: remove unneeded mask update
  sky2: handle advanced error recovery config issues
  sky2: version 1.20
  sky2: netpoll on port 0 only
  sky2: new pci id's

eric miao (1):
  add support for smc91x ethernet interface on zylonite

diff --git a/MAINTAINERS b/MAINTAINERS
index 1c7c229..6a97027 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -787,23 +787,25 @@ B43 WIRELESS DRIVER
 P: Michael Buesch
 M: [EMAIL PROTECTED]
 P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
 S: Maintained
 
 B43LEGACY WIRELESS DRIVER
 P: Larry Finger
 M: [EMAIL PROTECTED]
+P: Stefano Brivio
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
-W: http://bcm43xx.berlios.de/
+W: http://linuxwireless.org/en/users/Drivers/b43
 S: Maintained
 
 BCM43XX WIRELESS DRIVER (SOFTMAC BASED VERSION)
 P: Larry Finger
 M: [EMAIL PROTECTED]
 P: Stefano Brivio
-M: [EMAIL PROTECTED]
+M: [EMAIL PROTECTED]
 L: [EMAIL PROTECTED]
 W: http://bcm43xx.berlios.de/
 S: Maintained
diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig
index cb581eb..bf8890e 100644
--- a/drivers/net/Kconfig
+++ 

Re: USB storage: corrupted data transfers

[Mark Lord]

Mark Lord wrote:

Something may be broken in USB / usb-storage land.

I've got a 2GB USB stick here.
I want to copy it to an image file on my hard drive:

   cat /dev/sdb > usbkey.image1

Make a second copy, with or without unplugging/replugging the stick:

   cat /dev/sdb > usbkey.image2

After doing this, the two copies *differ*.


Here's the information on the specific devices I'm trying this with.

I'm beginning to suspect a faulty stick, or maybe one that just doesn't
work reliably with the way Linux accesses it (?).  The type that fails
(I have several of that model here) also gives some errors from "lsusb -v"
(see below for details).

I have another completely different brand/model of 2GB stick here
that has now been confirmed to NOT have any such issues.

Perhaps the USB experts here could comment on the differences
in information they report from lsusb --> maybe it's somethere there
that makes one of them fail, and the other one work?

First, the BAD one:

Bus 001 Device 084: ID 1307:0163  
Device Descriptor:

 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass0 (Defined at Interface level)
 bDeviceSubClass 0 
 bDeviceProtocol 0 
 bMaxPacketSize064
 idVendor   0x1307 
 idProduct  0x0163 
 bcdDevice1.00

 iManufacturer   1 USB 2.0
 iProduct2 Flash Disk
 iSerial 3 465743a79ca017
 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   39
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0 
   bmAttributes 0x80

 (Bus Powered)
   MaxPower   80mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   3
 bInterfaceClass 8 Mass Storage
 bInterfaceSubClass  6 SCSI
 bInterfaceProtocol 80 Bulk (Zip)
 iInterface  0 
 Endpoint Descriptor:

   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x01  EP 1 OUT
   bmAttributes2
 Transfer TypeBulk
 Synch Type   None
 Usage Type   Data
   wMaxPacketSize 0x0200  1x 512 bytes
   bInterval   1
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x82  EP 2 IN
   bmAttributes2
 Transfer TypeBulk
 Synch Type   None
 Usage Type   Data
   wMaxPacketSize 0x0200  1x 512 bytes
   bInterval   1
 Endpoint Descriptor:
   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x83  EP 3 IN
   bmAttributes3
 Transfer TypeInterrupt
 Synch Type   None
 Usage Type   Data
   wMaxPacketSize 0x0040  1x 64 bytes
   bInterval   8
Device Qualifier (for other device speed):
 bLength10
 bDescriptorType 6
 bcdUSB   2.00
 bDeviceClass0 (Defined at Interface level)
 bDeviceSubClass 0 
 bDeviceProtocol 0 
 bMaxPacketSize064

 bNumConfigurations  1

can't get debug descriptor: Connection timed out
cannot read device status, Connection timed out (110)



Now, the GOOD one:

Bus 001 Device 087: ID 1005:b113 Apacer Technology, Inc. Handy Steno 2.0 (256MB)
Device Descriptor:
 bLength18
 bDescriptorType 1
 bcdUSB   2.00
 bDeviceClass0 (Defined at Interface level)
 bDeviceSubClass 0 
 bDeviceProtocol 0 
 bMaxPacketSize064

 idVendor   0x1005 Apacer Technology, Inc.
 idProduct  0xb113 Handy Steno 2.0 (256MB)
 bcdDevice1.00
 iManufacturer   1 
 iProduct2 USB FLASH DRIVE 
 iSerial 3 1962140002E9

 bNumConfigurations  1
 Configuration Descriptor:
   bLength 9
   bDescriptorType 2
   wTotalLength   32
   bNumInterfaces  1
   bConfigurationValue 1
   iConfiguration  0 
   bmAttributes 0x80

 (Bus Powered)
   MaxPower  200mA
   Interface Descriptor:
 bLength 9
 bDescriptorType 4
 bInterfaceNumber0
 bAlternateSetting   0
 bNumEndpoints   2
 bInterfaceClass 8 Mass Storage
 bInterfaceSubClass  6 SCSI
 bInterfaceProtocol 80 Bulk (Zip)
 iInterface  0 
 Endpoint Descriptor:

   bLength 7
   bDescriptorType 5
   bEndpointAddress 0x81  EP 1 IN
   

Re: [PATCH 0/11 v3] enable "make ARCH=x86"

[Theodore Tso]

On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote:
> In fact, we should be able to get rid of ARCH entirely;  CONFIG_ options 
> have the huge advantage that they're saved in a file, and you don't have to 
> type them on every make run. The only option that I can't see us getting 
> rid of easily is HOSTCC, since it is used before config is run, but 
> probably something clever can be done there, too.

Yes, please!  One of the more annoying things is forgetting the
ARCH=um when rebuilding UML.  It would be awfully nice if ARCH was set
via a CONFIG_ option and was persistent.

- Ted
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Crispin Cowan]

Andi Kleen wrote:
> Crispin Cowan <[EMAIL PROTECTED]> writes:
>
> The document should be a good base for a merge.
>
>   
>> * A confined process can operate on a file descriptor passed to it
>>   by an unconfined process, even if it manipulates a file not in the
>>   confined process's profile. To block this attack, confine the
>>   process that passed the file descriptor.
>> 
>
> That is the only thing that tripped me up a bit while reading the document.
> Can you expand a bit on the reasons why the fd is not rechecked in
> the context of the target process? Best do it in a new version of the
> document.
>   
The reason is a disgusting implementation problem, so instead of going
into lots of detail, I just disclaimed it.

The excuse :) is that UNIX/Linux already has an object-capability
orientation with respect to passing file descriptors around; you can
pass an FD to a process that doesn't have access to the file, and DAC
(user ownership & such) won't check it either.

This aspect of the semantics is not my favorite, but it is at least
consistent with the AppArmor view that unconfined processes can do
absolutely anything and AppArmor won't try to stop them.

The actual reason: FDs that are passed from some other *confined*
process actually are checked, because the FD has data structures on it
that we can use to hook for checking. The problem is that an FD from a
completely unconfined process has no such data structures. To fix this,
we would have to check access on every single read and write, and that
would make performance suck.

If there is a clean way to close this issue, I would be interested.

On the other hand, there is a fairly passionate community of Object
Capability fans who really want access rights to be delegable, and the
other way to go is to remove all checking on passed FDs.

There are advantages to going both ways, and I don't believe that
AppArmor is locked in stone, so either one could be chosen in the
future. See this interesting thread on LSM
http://marc.info/?t=11946492933=1=2

Crispin

-- 
Crispin Cowan, Ph.D.   http://crispincowan.com/~crispin
CEO, Mercenary Linux   http://mercenarylinux.com/
   Itanium. Vista. GPLv3. Complexity at work

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

Re: [Linux-usb-users] USB storage: corrupted data transfers

[Alan Stern]

On Sat, 10 Nov 2007, Mark Lord wrote:

> Something may be broken in USB / usb-storage land.
> 
> I've got a 2GB USB stick here.
> I want to copy it to an image file on my hard drive:
> 
> cat /dev/sdb > usbkey.image1
> 
> Make a second copy, with or without unplugging/replugging the stick:
> 
> cat /dev/sdb > usbkey.image2
> 
> After doing this, the two copies *differ*.
> 
> So I wrote a little program to compare them and determine *how* they differ,
> and the result is very interesting.
> 
> Periodically, or or the other file has 8192 *zero* bytes inserted
> in place of it's data.   Not replacing it's data, just inserted
> into the stream, causing the real data (which follows) to be offset by 8192.

That's strange.  It happens periodically, you say?  What's the period?

> If one skips over the inserted 8192 bytes in the file, the data from that 
> point
> onward matches the other file, until another 8192 zeros are encountered.
> 
> The total sizes of the two image files match each other,
> but that's probably just due to the logic in the 'cat' program.
> 
> I wonder where those extraneous pairs of zero pages are coming from?

Me too.  It seems rather unlikely that they are coming from the USB
device or the transport, since at that level everything is addressed in
terms of sector numbers.  I don't see how 16 extra sectors could just
get inserted.  More believable would be a problem in the block layer,
the filesystem, or the application.

> This makes USB drives somewhat unreliable for backups and the like,
> which unfortunately is exactly what just about everybody uses them for.

Or it makes all drives somewhat unreliable, depending on just where the 
problem is.

> This (so far) is with 2.6.23.1 (w/slab allocater), and 2.6.24-rc2,
> on two different machines (both Intel based, but different chipset, CPU, RAM, 
> ...).
> 
> I suspect not all brands/models of USB sticks would give the same results,
> but it is rather worrisome that it happens at all.

You could try doing a more specific test.  Write a program to access
the block device sector-by-sector and store a distinct recognizable
byte pattern to each sector.  (Maybe just repeat the 4-byte sector 
number over and over.)  Then write another program to read the
data back and see what bytes ended up in which sectors.

At the same time, use the usbmon facility (see
Documentation/usb/usbmon.txt) to record exactly what data gets sent
to/from the stick.  That should at least be sufficient to determine the
problem is in the stick itself, in the SCSI/USB layers, or someplace
higher up.

Alan Stern

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[david]

On Sat, 10 Nov 2007, Andi Kleen wrote:


Crispin Cowan <[EMAIL PROTECTED]> writes:

The document should be a good base for a merge.


* A confined process can operate on a file descriptor passed to it
  by an unconfined process, even if it manipulates a file not in the
  confined process's profile. To block this attack, confine the
  process that passed the file descriptor.


That is the only thing that tripped me up a bit while reading the document.
Can you expand a bit on the reasons why the fd is not rechecked in
the context of the target process? Best do it in a new version of the
document.


from prior discussions I understand that the problem is that it's not easy 
(or nessasarily possible) to figure out the path to the fd, so what do you 
check?


if the file has been removed there _is_ no path to the fd.

with hard links there could be many paths to the fd, the only way to find 
them would be to search the entire filesystem.


as a result App Armor has decided not to try and address this, but is 
documenting it as a limitation.


David Lang
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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.24-rc2 STD with s2disk fails to activate suspended system after loading

[Chris Friedhoff]

please cc me, I'm not not subscribed to LKML

Hello,

with kernel 2.6.24-rc2 STD with s2disk suspends the system to disk, but
when I start the system and the suspended systemimage is loaded, it
fails to "activate" this suspended systemimage and continues after some
time with following the normal boot sequence.

I can sucessfully STD the system with the following sequence
  echo platform > /sys/power/disk
  echo disk > /sys/power/state
and when I start the laptop the suspended system is sucessfully
restored.

Both behaviors are reliable reproducable.

googling for >"Freezing of tasks failed" swapper< brought
"Nigel Cunningham - PID namespaces break initrd+hibernate combination?"
http://lkml.org/lkml/2007/11/4/140

dmesg output:
<>
RAMDISK: ext2 filesystem found at block 0
RAMDISK: Loading 2000KiB [1 disk] into ram disk... done.
EXT2-fs warning: mounting unchecked fs, running e2fsck is recommended
VFS: Mounted root (ext2 filesystem).
swsusp: Marking nosave pages: 0009f000 - 0010
swsusp: Basic memory bitmaps created
Clocksource tsc unstable (delta = -128791628 ns)
Syncing filesystems ... done.
Freezing user space processes ... (elapsed 0.00 seconds) done.
Freezing remaining freezable tasks ... 
Freezing of tasks failed after 20.00 seconds (1 tasks refusing to
freeze): taskPC stack   pid father
swapper   S c1835a88 0 1  0
    0046 c0118c80 c1835a88 0004 0001 c011e875
0286 c01025a6   c1835b64   c1835a90
0001     007b  c1835a90
c0118c80 Call Trace:
 [] default_wake_function+0x0/0x10
 [] do_wait+0x335/0xac0
 [] kernel_thread+0x96/0xb0
 [] default_wake_function+0x0/0x10
 [] sys_wait4+0x31/0x40
 [] initrd_load+0x1b3/0x3a0
 [] prepare_namespace+0x98/0x1b0
 [] sys_access+0x1f/0x30
 [] kernel_init+0x166/0x260
 [] ret_from_fork+0x6/0x1c
 [] kernel_init+0x0/0x260
 [] kernel_init+0x0/0x260
 [] kernel_thread_helper+0x7/0x18
 ===
kthreadd  S 038f 0 2  0
    0046 c0487790 038f c183ff1c  c012d81b
c012d7b0   c0104b8f    
  
Call Trace:
 [] kthreadd+0x6b/0xd0
 [] kthreadd+0x0/0xd0
 [] kernel_thread_helper+0x7/0x18
 ===
ksoftirqd/0   S  0 3  2
    0046 fffc  c0120f00  c0120f7a
c012d782 c012d740   c0104b8f c183ff3c  
   
Call Trace:
 [] ksoftirqd+0x0/0x80
 [] ksoftirqd+0x7a/0x80
 [] kthread+0x42/0x70
 [] kthread+0x0/0x70
 [] kernel_thread_helper+0x7/0x18

<>


Chris Friedhoff
[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/

USB storage: corrupted data transfers

[Mark Lord]

Something may be broken in USB / usb-storage land.

I've got a 2GB USB stick here.
I want to copy it to an image file on my hard drive:

   cat /dev/sdb > usbkey.image1

Make a second copy, with or without unplugging/replugging the stick:

   cat /dev/sdb > usbkey.image2

After doing this, the two copies *differ*.

So I wrote a little program to compare them and determine *how* they differ,
and the result is very interesting.

Periodically, or or the other file has 8192 *zero* bytes inserted
in place of it's data.   Not replacing it's data, just inserted
into the stream, causing the real data (which follows) to be offset by 8192.

If one skips over the inserted 8192 bytes in the file, the data from that point
onward matches the other file, until another 8192 zeros are encountered.

The total sizes of the two image files match each other,
but that's probably just due to the logic in the 'cat' program.

I wonder where those extraneous pairs of zero pages are coming from?

This makes USB drives somewhat unreliable for backups and the like,
which unfortunately is exactly what just about everybody uses them for.

This (so far) is with 2.6.23.1 (w/slab allocater), and 2.6.24-rc2,
on two different machines (both Intel based, but different chipset, CPU, RAM, 
...).

I suspect not all brands/models of USB sticks would give the same results,
but it is rather worrisome that it happens at all.

Mm  
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: AppArmor Security Goal

[Andi Kleen]

Crispin Cowan <[EMAIL PROTECTED]> writes:

The document should be a good base for a merge.

> * A confined process can operate on a file descriptor passed to it
>   by an unconfined process, even if it manipulates a file not in the
>   confined process's profile. To block this attack, confine the
>   process that passed the file descriptor.

That is the only thing that tripped me up a bit while reading the document.
Can you expand a bit on the reasons why the fd is not rechecked in
the context of the target process? Best do it in a new version of the
document.

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

[PATCH] [POWERPC] Fix CONFIG_SMP=n build error on ppc64

[Olof Johansson]

[POWERPC] Fix CONFIG_SMP=n build error

The patch "KVM: fix !SMP build error" change the way smp_call_function()
actually uses the passed in function names on non-SMP builds. So
previously it was never caught that the function passed in was never
actually defined.

This causes a build error on ppc64_defconfig + CONFIG_SMP=n:

arch/powerpc/mm/tlb_64.c: In function 'pgtable_free_now':
arch/powerpc/mm/tlb_64.c:71: error: 'pte_free_smp_sync' undeclared (first use 
in this function)
arch/powerpc/mm/tlb_64.c:71: error: (Each undeclared identifier is reported 
only once
arch/powerpc/mm/tlb_64.c:71: error: for each function it appears in.)

So we need to define it even if CONFIG_SMP is off. Either that or ifdef
out the smp_call_function() call, but that's ugly.


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

diff --git a/arch/powerpc/mm/tlb_64.c b/arch/powerpc/mm/tlb_64.c
index eafbca5..e2d867c 100644
--- a/arch/powerpc/mm/tlb_64.c
+++ b/arch/powerpc/mm/tlb_64.c
@@ -54,12 +54,10 @@ unsigned long pte_freelist_forced_free;
((PAGE_SIZE - sizeof(struct pte_freelist_batch)) \
  / sizeof(pgtable_free_t))
 
-#ifdef CONFIG_SMP
 static void pte_free_smp_sync(void *arg)
 {
/* Do nothing, just ensure we sync with all CPUs */
 }
-#endif
 
 /* This is only called when we are critically out of memory
  * (and fail to get a page in pte_free_tlb).
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: use $K64BIT to set 64BIT with all*config targets

[Guillaume Chazarain]

Hi,

On 11/10/07, Sam Ravnborg <[EMAIL PROTECTED]> wrote:
> The variable K64BIT can now be used to select the
> value of CONFIG_64BIT.

Why not calling the environment variable CONFIG_64BIT,
in preparation of the day when all CONFIG_ variables can
be passed by environment variables?

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

Re: [PATCH 0/11 v3] enable "make ARCH=x86"

[Sam Ravnborg]

On Sat, Nov 10, 2007 at 12:35:01PM -0800, H. Peter Anvin wrote:
> 
> HOWEVER, I think the right thing for allyesconfig, allmodconfig, 
> randconfig, etc. is to be able to override specific variables.  Right 
> now, one has to use indirection via a file, which is a bit clumsy; it 
> would be better if one could do "make allyesconfig CONFIG_X86_64=y" or 
> somesuch.

See patch-set I just sent out :-)

> 
> In fact, we should be able to get rid of ARCH entirely;  CONFIG_ options 
> have the huge advantage that they're saved in a file, and you don't have 
> to type them on every make run. The only option that I can't see us 
> getting rid of easily is HOSTCC, since it is used before config is run, 
> but probably something clever can be done there, too.

My long term plan is to enable the above.
I had planned to do a lot for 2.6.25 but all this x86 stuff have eaten
too much time. And I have plenty of kbuild stuff in my
inbox awaiting some attention...

Sam
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: document make K64BIT=y in README

[Sam Ravnborg]

Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
 README |2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/README b/README
index 159912c..6622ba1 100644
--- a/README
+++ b/README
@@ -194,6 +194,8 @@ CONFIGURING the kernel:
"make *config" checks for a file named "all{yes/mod/no/random}.config"
for symbol values that are to be forced.  If this file is not found,
it checks for a file named "all.config" to contain forced values.
+   Finally it checks the environment variable K64BIT and set the config
+   symbol "64BIT" to the value of the K64BIT variable.

NOTES on "make config":
- having unnecessary drivers will make the kernel bigger, and can
-- 
1.5.3.4.1157.g0e74-dirty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: use $K64BIT to set 64BIT with all*config targets

[Sam Ravnborg]

The variable K64BIT can now be used to select the
value of CONFIG_64BIT.

This is for example useful for powerpc to generate
allmodconfig for both bit sizes - like this:
make ARCH=powerpc K64BIT=y
make ARCH=powerpc K64BIT=n

To use this the Kconfig file must use "64BIT" as the
config value to select between 32 and 64 bit.

Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
 scripts/kconfig/conf.c  |1 +
 scripts/kconfig/confdata.c  |   27 +++
 scripts/kconfig/lkc_proto.h |1 +
 3 files changed, 29 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/conf.c b/scripts/kconfig/conf.c
index a38787a..c6bee85 100644
--- a/scripts/kconfig/conf.c
+++ b/scripts/kconfig/conf.c
@@ -591,6 +591,7 @@ int main(int ac, char **av)
conf_read_simple(name, S_DEF_USER);
else if (!stat("all.config", ))
conf_read_simple("all.config", S_DEF_USER);
+   conf_set_env_sym("K64BIT", "64BIT", S_DEF_USER);
break;
default:
break;
diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index e0f402f..0cb7555 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -145,6 +145,33 @@ static int conf_set_sym_val(struct symbol *sym, int def, 
int def_flags, char *p)
return 0;
 }
 
+/* Read an environment variable and assign the vaule to the symbol */
+int conf_set_env_sym(const char *env, const char *symname, int def)
+{
+   struct symbol *sym;
+   char *p;
+   int def_flags;
+
+   p = getenv(env);
+   if (p) {
+   char warning[100];
+   sprintf(warning, "Environment variable (%s = \"%s\")", env, p);
+   conf_filename = warning;
+   def_flags = SYMBOL_DEF << def;
+   if (def == S_DEF_USER) {
+   sym = sym_find(symname);
+   if (!sym)
+   return 1;
+   } else {
+   sym = sym_lookup(symname, 0);
+   if (sym->type == S_UNKNOWN)
+   sym->type = S_OTHER;
+   }
+   conf_set_sym_val(sym, def, def_flags, p);
+   }
+   return 0;
+}
+
 int conf_read_simple(const char *name, int def)
 {
FILE *in = NULL;
diff --git a/scripts/kconfig/lkc_proto.h b/scripts/kconfig/lkc_proto.h
index 4d09f6d..dca294e 100644
--- a/scripts/kconfig/lkc_proto.h
+++ b/scripts/kconfig/lkc_proto.h
@@ -1,6 +1,7 @@
 
 /* confdata.c */
 P(conf_parse,void,(const char *name));
+P(conf_set_env_sym,int,(const char *envname, const char *symname, int def));
 P(conf_read,int,(const char *name));
 P(conf_read_simple,int,(const char *name, int));
 P(conf_write,int,(const char *name));
-- 
1.5.3.4.1157.g0e74-dirty

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

[PATCH] x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit

[Sam Ravnborg]

Using the newly added infrastructure is is now simple
to add addition ARCH= symbols to select between 32 and 64 bit.
Do this for x86.

Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
 Makefile |   16 +---
 arch/x86/Makefile|   10 +++---
 scripts/kconfig/Makefile |2 +-
 3 files changed, 21 insertions(+), 7 deletions(-)

diff --git a/Makefile b/Makefile
index 902082b..5efee80 100644
--- a/Makefile
+++ b/Makefile
@@ -165,8 +165,7 @@ export srctree objtree VPATH TOPDIR
 # then ARCH is assigned, getting whatever value it gets normally, and 
 # SUBARCH is subsequently ignored.
 
-SUBARCH := $(shell uname -m | sed -e s/i.86/x86/ -e s/x86_64/x86/\
- -e s/sun4u/sparc64/\
+SUBARCH := $(shell uname -m | sed -e s/i.86/i386/ -e s/sun4u/sparc64/ \
  -e s/arm.*/arm/ -e s/sa110/arm/ \
  -e s/s390x/s390/ -e s/parisc64/parisc/ \
  -e s/ppc.*/powerpc/ -e s/mips.*/mips/ \
@@ -198,8 +197,19 @@ CROSS_COMPILE  ?=
 UTS_MACHINE:= $(ARCH)
 SRCARCH:= $(ARCH)
 
+ifeq ($(ARCH),i386)
+K64BIT := n
+SRCARCH   := x86
+endif
+ifeq ($(ARCH),x86_64)
+K64BIT := y
+SRCARCH := x86
+endif
+export K64BIT
+
+
 # Sanity check the specified ARCH
-ifeq ($(wildcard $(srctree)/arch/$(ARCH)/Kconfig),)
+ifeq ($(wildcard $(srctree)/arch/$(SRCARCH)/Kconfig),)
 $(error "ERROR: ARCH ($(ARCH)) does not exist (for i386 and x86_64 use 
ARCH=x86)")
 endif
 
diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index ee94224..feba761 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -1,9 +1,13 @@
 # Unified Makefile for i386 and x86_64
 
 # select i386 defconfig file as default config
-KBUILD_DEFCONFIG := i386_defconfig
-
-# # No need to remake these files
+ifeq ($(ARCH),x86)
+KBUILD_DEFCONFIG := i386_defconfig
+else
+KBUILD_DEFCONFIG := $(ARCH)_defconfig
+endif
+
+# No need to remake these files
 $(srctree)/arch/x86/Makefile%: ;
 
 ifeq ($(CONFIG_X86_32),y)
diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 3c9db07..1ad6f7f 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -4,7 +4,7 @@
 
 PHONY += oldconfig xconfig gconfig menuconfig config silentoldconfig 
update-po-config
 
-Kconfig := arch/$(ARCH)/Kconfig
+Kconfig := arch/$(SRCARCH)/Kconfig
 
 xconfig: $(obj)/qconf
$< $(Kconfig)
-- 
1.5.3.4.1157.g0e74-dirty

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

[PATCH] x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig

[Sam Ravnborg]

This change allow us to use the new syntax:
make K64BIT={n,y} to select between 32 and 64 bit.

Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
---
 arch/x86/Kconfig |   26 --
 1 files changed, 8 insertions(+), 18 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 153c26c..0d86611 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1,34 +1,24 @@
 # x86 configuration
 
 # Select 32 or 64 bit
-choice
-   bool "Select 32 or 64 bit"
-   default X86_32
+config 64BIT
+   bool "64 Bit kernel"
+   default n
+   help
+ Say yes to build a 64 bit kernel - formerly known as x86_64
+ Say no to build a 32 bit kernel - formerly known as i386
 
 config X86_32
-   bool "32 bit (former ARCH=i386)"
-   help
- This is Linux's home port.  Linux was originally native to the Intel
- 386, and runs on all the later x86 processors including the Intel
- 486, 586, Pentiums, and various instruction-set-compatible chips by
- AMD, Cyrix, and others.
+   def_bool !64BIT
 
 config X86_64
-   bool "64 bit (former ARCH=x86_64)"
-   help
- Port to the x86-64 architecture. x86-64 is a 64-bit extension to the
- classical 32-bit x86 architecture. For details see
- .
-endchoice
+   def_bool 64BIT
 
 ### Arch settings
 config X86
bool
default y
 
-config 64BIT
-   def_bool X86_64
-
 config GENERIC_TIME
bool
default y
-- 
1.5.3.4.1157.g0e74-dirty

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] kconfig: factor out code in confdata.c

[Sam Ravnborg]

This patch introduce no functional changes.

Signed-off-by: Sam Ravnborg <[EMAIL PROTECTED]>
Cc: Roman Zippel <[EMAIL PROTECTED]>
---
 scripts/kconfig/confdata.c |  119 +++
 1 files changed, 64 insertions(+), 55 deletions(-)

diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
index b2913e9..e0f402f 100644
--- a/scripts/kconfig/confdata.c
+++ b/scripts/kconfig/confdata.c
@@ -83,6 +83,68 @@ char *conf_get_default_confname(void)
return name;
 }
 
+static int conf_set_sym_val(struct symbol *sym, int def, int def_flags, char 
*p)
+{
+   char *p2;
+
+   switch (sym->type) {
+   case S_TRISTATE:
+   if (p[0] == 'm') {
+   sym->def[def].tri = mod;
+   sym->flags |= def_flags;
+   break;
+   }
+   case S_BOOLEAN:
+   if (p[0] == 'y') {
+   sym->def[def].tri = yes;
+   sym->flags |= def_flags;
+   break;
+   }
+   if (p[0] == 'n') {
+   sym->def[def].tri = no;
+   sym->flags |= def_flags;
+   break;
+   }
+   conf_warning("symbol value '%s' invalid for %s", p, sym->name);
+   break;
+   case S_OTHER:
+   if (*p != '"') {
+   for (p2 = p; *p2 && !isspace(*p2); p2++)
+   ;
+   sym->type = S_STRING;
+   goto done;
+   }
+   case S_STRING:
+   if (*p++ != '"')
+   break;
+   for (p2 = p; (p2 = strpbrk(p2, "\"\\")); p2++) {
+   if (*p2 == '"') {
+   *p2 = 0;
+   break;
+   }
+   memmove(p2, p2 + 1, strlen(p2));
+   }
+   if (!p2) {
+   conf_warning("invalid string found");
+   return 1;
+   }
+   case S_INT:
+   case S_HEX:
+   done:
+   if (sym_string_valid(sym, p)) {
+   sym->def[def].val = strdup(p);
+   sym->flags |= def_flags;
+   } else {
+   conf_warning("symbol value '%s' invalid for %s", p, 
sym->name);
+   return 1;
+   }
+   break;
+   default:
+   ;
+   }
+   return 0;
+}
+
 int conf_read_simple(const char *name, int def)
 {
FILE *in = NULL;
@@ -213,61 +275,8 @@ load:
conf_warning("trying to reassign symbol %s", 
sym->name);
break;
}
-   switch (sym->type) {
-   case S_TRISTATE:
-   if (p[0] == 'm') {
-   sym->def[def].tri = mod;
-   sym->flags |= def_flags;
-   break;
-   }
-   case S_BOOLEAN:
-   if (p[0] == 'y') {
-   sym->def[def].tri = yes;
-   sym->flags |= def_flags;
-   break;
-   }
-   if (p[0] == 'n') {
-   sym->def[def].tri = no;
-   sym->flags |= def_flags;
-   break;
-   }
-   conf_warning("symbol value '%s' invalid for 
%s", p, sym->name);
-   break;
-   case S_OTHER:
-   if (*p != '"') {
-   for (p2 = p; *p2 && !isspace(*p2); p2++)
-   ;
-   sym->type = S_STRING;
-   goto done;
-   }
-   case S_STRING:
-   if (*p++ != '"')
-   break;
-   for (p2 = p; (p2 = strpbrk(p2, "\"\\")); p2++) {
-   if (*p2 == '"') {
-   *p2 = 0;
-   break;
-   }
-   memmove(p2, p2 + 1, strlen(p2));
-   }
-   if (!p2) {
-   conf_warning("invalid string found");
-   continue;
-   }
- 

[PATCH 0/5] introduce K64BIT=y and backward compatibility ARCH={i386,x86_64} for x86

[Sam Ravnborg]

As discussed in another thread the right thing is to add a generic solution
to select between 32 and 64 bit - useable for powerpc, s390, ppc et al.

First step was to teach kconfig how to force 64BIT to a specific value.
The x86 Kconfig file needed a small twist to use 64BIT as the symbol
to seelct 32 or 64 bit.
Then it was simple to add backward compatibility ARCH= settings.

The patchset is not yet pushed out - I will await a bit feedback first.

Shortlog and diffstat.
  kconfig: factor out code in confdata.c
  kconfig: use $K64BIT to set 64BIT with all*config targets
  x86: Use CONFIG_64BIT to select between 32 and 64 bit in Kconfig
  kconfig: document make K64BIT=y in README
  x86: introduce ARCH=i386,ARCH=x86_64 to select 32/64 bit


 Makefile|   16 -
 README  |2 +
 arch/x86/Kconfig|   26 +++-
 arch/x86/Makefile   |   10 ++-
 scripts/kconfig/Makefile|2 +-
 scripts/kconfig/conf.c  |1 +
 scripts/kconfig/confdata.c  |  146 +++
 scripts/kconfig/lkc_proto.h |1 +
 8 files changed, 124 insertions(+), 80 deletions(-)

The majority of the diffstat is the code refactoring of confdata.c
The rest is simple changes.

Patches follows...
Patches are on top of the patchset to introduce "make ARCH=x86"

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

Re: [PATCH 0/11 v3] enable "make ARCH=x86"

[H. Peter Anvin]

Paul Mundt wrote:

Indeed, that's what I was intending on keeping around as a convention,
and simply overloading SRCARCH for the sh64 case. i386/x86_64 potentially
has the same issue though, and if the intent is to have a single ARCH for
both of them, I don't see how that would possibly work without
sacrificing randconfig.. unless the intended x86 convention is that one
compiler will happily handle both i386 and x86_64 without any difficulty?


Well, that *is* the normal thing on x86.

HOWEVER, I think the right thing for allyesconfig, allmodconfig, 
randconfig, etc. is to be able to override specific variables.  Right 
now, one has to use indirection via a file, which is a bit clumsy; it 
would be better if one could do "make allyesconfig CONFIG_X86_64=y" or 
somesuch.


In fact, we should be able to get rid of ARCH entirely;  CONFIG_ options 
have the huge advantage that they're saved in a file, and you don't have 
to type them on every make run. The only option that I can't see us 
getting rid of easily is HOSTCC, since it is used before config is run, 
but probably something clever can be done there, too.


-hpa
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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] fix up perfmon to build on -mm

[Andi Kleen]

Greg KH <[EMAIL PROTECTED]> writes:

[dropped perfmon list because gmane messed it up and it's apparently
closed anyways]

> Is there any way to just provide a basic framework that everyone can
> agree on and then add on more stuff as time goes on?  Do we have to have
> every different processor/arch with support to start with?

I think the real problem are not the architectures (the processor
adaption layer is usually relatively straight forward IIRC), but the
excessive functionality implemented by the user interface.

It would be really good to extract a core perfmon and start with
that and then add stuff as it makes sense.

e.g. core perfmon could be something simple like just support
to context switch state and initialize counters in a basic way 
and perhaps get counter numbers for RDPMC in ring3 on x86[1]

Next step could be basic event on overflow/underflow support.

Then more features as they make sense, with clear rationale
what they're good for and proper step by step patches. 

-Andi

[1] On x86 we urgently need a replacement to RDTSC for counting
cycles.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Laptop's HDD

[Stephen Clark]

Maciej W. Rozycki wrote:


On Sun, 4 Nov 2007, Alberto Gonzalez wrote:

 

The problem comes from a very high rate of load/unload cycles of the heads 
that reaches the 300.000-600.000 limit in 2-3 years (with smartmontools it 
can checked it with "smartctl -A /dev/sda")  . There are reports of HDD dying 
even earlier for this problem [2]
   



I use:

# hdparm -B 255 /dev/hda

to get rid of the problem with an ATA disk where I do not care that much 
about power consumption.  I do not know what the equivalent for a SATA 
disk would be, but chances are it will be easier to track it down with the 
reference above.


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

 

My laptop harddrive is only a little over a year old and it has a cycle 
count of 193 Load_Cycle_Count0x0012   021   021   000
Old_age   Always   -   795931


it was going up a few counts everytime I ran the smartctl -A command. It 
quit incrementing after

I did the hdparm -B 255 command.

--

"They that give up essential liberty to obtain temporary safety, 
deserve neither liberty nor safety."  (Ben Franklin)


"The course of history shows that as a government grows, liberty 
decreases."  (Thomas Jefferson)




-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message 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: Module init call vs symbols exporting race?

[Andi Kleen]

Jan Glauber <[EMAIL PROTECTED]> writes:

> I've seen a symbol-resolving race on s390. The qeth module uses symbols
> from qdio and although the loading order seems correct and the qdio
> symbols should be available the following error appears:

FWIW i see such messages all the time with usb serial on my workstation too.
It's not new.

For some reason it never makes it to the log file though, i only see
it flashing by on the console.

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