Re: libata: Fix host-simplex_claimed != ap typo

2007-03-08 Thread Jeff Garzik

Alan Cox wrote:

On Thu, 08 Mar 2007 23:17:00 +0900
OGAWA Hirofumi [EMAIL PROTECTED] wrote:


Hi,

the following patch is needed to boot my laptop using pata_ali.ko, at least.
Please apply.


NAK - correct fix is to check !=  != NULL. The correct fix was posted
to the list earlier by Vojtech.


You mean Petr Vandrovec I presume?

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: Linux v2.6.20-rc5

2007-03-08 Thread Jeff Chua

On 3/8/07, albcamus [EMAIL PROTECTED] wrote:

I guess that it is because 'paravirt_ops' was exported as GPL symbol, whereas
the vmware module doen't declare any license.

I tried to add the following line:

MODULE_LICENSE(GPL);

into vmmon.tar and vmnet.tar under /usr/lib/vmare/modules/source/,
then it works.



I'll try that. Thanks. Here's what I did, but don't know whether it's
the right approach (but, at least vmware still works) ...

Thanks,
Jeff.


--- vmware/vmmon-only/include/driver-config.h.org   2007-01-26
10:46:01 +0800
+++ vmware/vmmon-only/include/driver-config.h   2006-11-14 05:06:18 +0800
@@ -19,7 +19,8 @@
#include includeCheck.h

#include linux/autoconf.h
+#undef CONFIG_PARAVIRT
#include compat_version.h

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


Re: libata: Fix host-simplex_claimed != ap typo

2007-03-08 Thread Alan Cox
On Thu, 08 Mar 2007 10:18:24 -0500
Jeff Garzik [EMAIL PROTECTED] wrote:

 Alan Cox wrote:
  On Thu, 08 Mar 2007 23:17:00 +0900
  OGAWA Hirofumi [EMAIL PROTECTED] wrote:
  
  Hi,
 
  the following patch is needed to boot my laptop using pata_ali.ko, at 
  least.
  Please apply.
  
  NAK - correct fix is to check !=  != NULL. The correct fix was posted
  to the list earlier by Vojtech.
 
 You mean Petr Vandrovec I presume?

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


Re: 2.6.21-rc3-mm1

2007-03-08 Thread John W. Linville
On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote:

 - The wireless changes in here need a lot of testers, please.  It is major
   rework.
 
   Of course the config files got all changed around so `make oldconfig'
   breaks everything.  I was able to get ipw2200 working after some fumbling,
   but perhaps John can tell people what has been changed in there?  What has
   happened, from a big picture perspective?

Specifically regarding 'make oldconfig', it is mostly a clean-up
to make a distinction between 802.11 wireless LANs and pre-standard
wireless LANs.  Here is the commit message:

commit 1a9e0dd0bd60474465e0b0f1bca774d8c042d879
Author: Johannes Berg [EMAIL PROTECTED]
Date:   Sat Mar 3 13:06:15 2007 +0100

[PATCH] rework wireless Kconfig

This patch
 * kills NET_RADIO
 * adds a new Wireless LAN menu
 * adds two new options WLAN_PRE80211 and WLAN_80211 that drivers
   depend on
 * makes WIRELESS_EXT visible (to avoid the arguments we had in
   commit c1783454a31e05b94774951b0b5d1eb9075ebfb4)
 * changes everything that depended on NET_RADIO to select 
WIRELESS_EXT
   and to depend on WLAN_PRE80211 or WLAN_80211

By removing NET_RADIO, these changes pave the way to making wireless
extensions optional when cfg80211 can fully take over for some 
drivers
and you don't have any older drivers that still require wext.

Honestly, I'm tempted to add the pre-802.11 stuff to the features
removal list.  I wonder if any of it still actually works...

As to the larger question of what is happening w/ wireless in -mm,
I'll add a few words for those who don't know.

As the commit referenced earlier suggests, work is underway on a
new configuration regime for wireless LANs.  This should result in
a cleaner API for driver and userland tool developers, and hopefully
better matches the expected semantics for wireless LAN configuration.
An optional sub-component of that is a compatibility layer for
existing WEXT-based tools, so there should be no need for a wireless
tools flag day.  Still, hopefully this enables better wireless
configuration/management tools in the future.

In addition, we are adding a new component: mac80211.  This component
implements the higher-layer wireless MAC functionality for those
cards that don't do it in hardware or firmware, as is true for many
new cards.  Traditionally cards with this type of design needed
drivers to implement this functionality themselves.  This resulted
in wretched duplication of effort, varying use of kernel APIs,
and inconsistent support for features of the 802.11 standards.
Providing this infrastructure in the kernel should both reduce the
effort needed to support new hardware and homogenize the user interface
and feature support of the resulting drivers.

The existing ieee80211softmac component provides a small part of the
capabilities of mac80211.  But it is viewed as incomplete and crippled
by its ties to the ieee80211 component, which is really intended more
as a support library for the ipw2x00 drivers rather than a complete
802.11 stack.  Those drivers which depended on ieee80211softmac
have been ported to work w/ mac80211.  And several more drivers have
been added, including adm8211, prism54 (softmac versions, including
USB), and rtl8187, with iwlwifi (IPW3945), rtl-8180/8185, and others
coming soon -- stay tuned!

So, things are getting better: better hardware support, better
wireless capabilities, and better tool enablement.  But it is a big
hunk of changes.  So, please do give this code a try!

Thanks,

John

P.S.  If you are afraid of -mm and are a Fedora or RHEL5 user, please
try either the rawhide kernel or my test kernels here:

http://people.redhat.com/linville/kernels/fc7/
http://people.redhat.com/linville/kernels/fc6/
http://people.redhat.com/linville/kernels/rhel5/

-- 
John W. Linville
[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: Problem with freezable workqueues

2007-03-08 Thread Johannes Berg
On Tue, 2007-03-06 at 21:31 +0100, Rafael J. Wysocki wrote:

 For now, we have decided to make the workqueues nonfreezable (the patch for
 that has already been merged, AFAICT).

It isn't in 2.6.21-rc3.

  I wanted to adapt the BUG_ON(block IO not from suspend code) 
  patch from suspend2 but haven't gotten around to it yet.
 
 That might be a good idea for other reasons too, but I'd prefer WARN_ON()
 instead of BUG_ON() when you're at it. ;-)

I won't be able to do that for quite a while... It's just on my future
projects that would be nice list :P

johannes


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


Re: [ANNOUNCE] RSDL completely fair starvation free interactive cpu scheduler

2007-03-08 Thread Tim Tassonis

Hi Con

Just also wanted to throw in my less than two cents: I applied the patch 
and also have the very strong subjective impression that my system 
feels much more responsive than with stock 2.6.20.


Thanks for the great work.

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


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Michal Piotrowski
Takashi Iwai napisał(a):
 At Wed, 07 Mar 2007 23:22:36 +0100,
 Michal Piotrowski wrote:
 Hi Takashi,

 Takashi Iwai napisał(a):
 At Wed, 7 Mar 2007 11:50:24 -0800,
 Andrew Morton wrote:
 On Wed, 7 Mar 2007 20:41:30 +0100 Michal Piotrowski [EMAIL PROTECTED] 
 wrote:

 831466f4ad2b5fe23dff77edbe6a7c244435e973 is first bad commit
 commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
 Author: Randy Cushman [EMAIL PROTECTED]
 Date:   Tue Dec 19 18:42:16 2006 +0100

 [ALSA] ac97 - fix microphone and line_in selection logic

 This patch fixes the Microphone and LINE_IN select logic for
 Analog Devices surround codecs with shared jacks.  The existing
 code can never utilize the shared jacks for Microphone and LINE_IN
 due to the reversed jack selection logic.  The patched code
 correctly selects the shared jack for input if the 'Channel Mode'
 selector does not specify that the jack is to be used for output.
 Specifically, in '2ch' mode the Center/LFE jack is used for
 microphone input and the Surround jack is used for LINE_IN,
 in '4ch' mode the Center/LFE jack is used for microphone input
 and the Surround jack is used for output, and in '6ch' mode
 both jacks are used for output.

 Signed-off-by: Randy Cushman [EMAIL PROTECTED]
 Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
 Signed-off-by: Jaroslav Kysela [EMAIL PROTECTED]

 Is 2.6.21-rc3 similarly broken?
 Yes.

 OK.  Can you please confirm that applying the below fixes 2.6.21-rc3?

 If so, I'll queue it up for application in a week or two if there is no
 progress on this.
 [sorry for the late interrupt - I'm just back from a vacation]

 Could you postpone reverting for a while?
 I guess this possible regression is limited only to a certain type of
 ac97 codec chip.  The patch applied there was a fix for many codec
 chips.

 Which codec chip are you using specifically?  Please check
 /proc/asound/card0/codec97#0/* file(s).
 0-0/0: Analog Devices AD1985
 
 OK, that's good to know.
 
  control.43 {
  comment.access 'read write'
  comment.type BOOLEAN
  comment.count 1
  iface MIXER
  name 'Spread Front to Surround and Center/LFE'
  value true
  }
 
 So, you're playing two-channel samples and get no output from surround
 and CLFE?

Yes.

 Or, does it happen if you play a real 5.1 channel file?
 (for example, try speaker-test -c6)

It doesn't work for me on both kernels.

 
 Also, it'd be helpful if you compare
 /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
 patch.  This reveals which register bits differ actually.

a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
--- a2.txt  2007-03-08 16:36:47.0 +0100
+++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 16:36:49.447083597 
+0100
@@ -56,8 +56,8 @@
 0:6e = 
 0:70 = 
 0:72 = 0004
-0:74 = 1001
-0:76 = 64a4
+0:74 = 1201
+0:76 = 7ca4
 0:78 = 000c
 0:7a = 
 0:7c = 4144


2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

speaker-test -c6

speaker-test 1.0.13

Playback device is default
Stream parameters are 48000Hz, S16_LE, 6 channels
Using 16 octaves of pink noise
Rate set to 48000Hz (requested 48000Hz)
Buffer size range from 2048 to 16384
Period size range from 1024 to 1024
Using max buffer size 16384
Periods = 4
was set period_size = 1024
was set buffer_size = 16384
 0 - Front Left
 4 - Center
 1 - Front Right
 3 - Rear Right
 2 - Rear Left
 5 - LFE

0, 1 works
4, 3, 2, 5 doesn't work

/proc/asound/card0/codec97#0/ac97#0-0

0-0/0: Analog Devices AD1985

PCI Subsys Vendor: 0x1043
PCI Subsys Device: 0x80f3

Revision : 0x03
Compat. Class: 0x00
Subsys. Vendor ID: 0x
Subsys. ID   : 0x

Capabilities : -headphone out-
DAC resolution   : 20-bit
ADC resolution   : 16-bit
3D enhancement   : No 3D Stereo Enhancement

Current setup
Mic gain : +20dB [+20dB]
POP path : pre 3D
Sim. stereo  : off
3D enhancement   : off
Loudness : off
Mono output  : MIX
Mic select   : Mic1
ADC/DAC loopback : off
Double rate slots: 10/11
Extended ID  : codec=0 rev=0 AMAP LDAC SDAC CDAC DSA=0 SPDIF DRA VRA
Extended status  : SPCV LDAC SDAC CDAC SPDIF=10/11 VRA
PCM front DAC: 48000Hz
PCM Surr DAC : 48000Hz
PCM LFE DAC  : 48000Hz
PCM ADC  : 48000Hz
SPDIF Control: Consumer PCM Category=0x2 Generation=1 Rate=48kHz

Gain Inverted  Buffer delay  Location
Master Out   :   0.0 dBV-  16/fs Rear I/O Panel
AUX Out  :   0.0 dBV-  16/fs Rear I/O Panel
Center/LFE Out   :   0.0 dBV-  16/fs Rear I/O Panel
Mic 1:   0.0 dBV-  16/fs Rear I/O Panel
Mic 2:   0.0 dBV-  16/fs Rear I/O Panel
Line In  :   0.0 dBV-  16/fs Rear I/O Panel




Re: [patch 2/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Davide Libenzi
On Thu, 8 Mar 2007, David M. Lloyd wrote:

 On Wed, 2007-03-07 at 17:21 -0800, Davide Libenzi wrote:
  int signalfd_dequeue(int fd, siginfo_t *info, long timeo);
  
  The fd parameter must ba a signalfd file descriptor. The info parameter
  is a pointer to the siginfo that will receive the dequeued signal, and
  timeo is a timeout in milliseconds, or -1 for infinite.
  The signalfd_dequeue function returns 0 if successfull.
 
 Does this support non-blocking mode?  It doesn't seem to at my level of
 understanding anyway.  If I use this with EPOLLET for example, I'd
 expect to get a single EPOLLIN when a signal arrives, which would
 indicate to me that I must call signalfd_dequeue() in a loop until I get
 EAGAIN in order to be sure I've consumed all the outstanding signals so
 that the edge-triggered notification can be re-armed.

This patch, if you get a POLLIN, you have a signal to read for sure (well, 
unless you another thread/task reads it before you - but that's just 
somthing you have to take care). There is not explicit check for 
O_NONBLOCK now, but a zero timeout would do exactly the same thing.


- Davide


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] tty: Revised diff for the i386/x86_64 arbitary speed support

2007-03-08 Thread Alan Cox
Adding some more test cases found a bug in the definition of IBSHIFT. At
the moment we have no hardware support for split baud rates but this
showed up once I did testing of that...

Replaces the previous diff.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/ioctls.h 
linux-2.6.21-rc2-mm2/include/asm-i386/ioctls.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/ioctls.h  2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/ioctls.h  2007-03-08 
16:39:26.0 +
@@ -47,6 +47,10 @@
 #define TIOCSBRK   0x5427  /* BSD compatibility */
 #define TIOCCBRK   0x5428  /* BSD compatibility */
 #define TIOCGSID   0x5429  /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2   _IOW('T',0x2C, struct termios2)
+#define TCSETSF2   _IOW('T',0x2D, struct termios2)
 #define TIOCGPTN   _IOR('T',0x30, unsigned int) /* Get Pty Number (of 
pty-mux device) */
 #define TIOCSPTLCK _IOW('T',0x31, int)  /* Lock/unlock Pty */
 
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termbits.h 
linux-2.6.21-rc2-mm2/include/asm-i386/termbits.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termbits.h2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/termbits.h2007-03-08 
16:38:55.0 +
@@ -17,6 +17,17 @@
cc_t c_cc[NCCS];/* control characters */
 };
 
+struct termios2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_line;/* line discipline */
+   cc_t c_cc[NCCS];/* control characters */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 struct ktermios {
tcflag_t c_iflag;   /* input mode flags */
tcflag_t c_oflag;   /* output mode flags */
@@ -129,6 +140,7 @@
 #define HUPCL  0002000
 #define CLOCAL 0004000
 #define CBAUDEX 001
+#define   BOTHER  001
 #defineB57600 0010001
 #define   B115200 0010002
 #define   B230400 0010003
@@ -148,6 +160,8 @@
 #define CMSPAR   0100  /* mark or space (stick) parity */
 #define CRTSCTS  0200  /* flow control */
 
+#define IBSHIFT  16/* Shift from CBAUD to CIBAUD */
+
 /* c_lflag bits */
 #define ISIG   001
 #define ICANON 002
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termios.h 
linux-2.6.21-rc2-mm2/include/asm-i386/termios.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termios.h 2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/termios.h 2007-03-06 
17:00:58.0 +
@@ -81,8 +81,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
 })
 
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, 
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct 
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, 
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct 
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, 
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, 
sizeof(struct termios))
 
 #endif /* __KERNEL__ */
 
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-x86_64/termbits.h 
linux-2.6.21-rc2-mm2/include/asm-x86_64/termbits.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-x86_64/termbits.h  2007-03-06 
23:06:37.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-x86_64/termbits.h  2007-03-08 
16:39:06.0 +
@@ -160,7 +160,7 @@
 #define CMSPAR   0100  /* mark or space (stick) parity */
 #define CRTSCTS  0200  /* flow control */
 
-#define IBSHIFT  8 /* Shift from CBAUD to CIBAUD */
+#define IBSHIFT  16/* Shift from CBAUD to CIBAUD */
 
 /* c_lflag bits */
 #define ISIG   001
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Problem with libata-pata, ATAPI DVD reader and a copy-protected audio cd

2007-03-08 Thread GhePeU
Il giorno gio, 08/03/2007 alle 14.35 +0100, GhePeU ha scritto:
  
 
 Well, it happened again, with a different cd, and this time I never
 started the player: hal/g-v-m tried to access the CD and now my driver
 is in PIO2 mode and pretty much unusable. Is there a way to fix this
 without rebooting?
 
 Giacomo

I examined this cd and it is not copy-protected. It is an Enhanced
CD and it works without issues with another os or with Linux with the
old ide driver.

Giacomo

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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][Patch 0/6] integrity service framework and provider

2007-03-08 Thread Mimi Zohar
This is a request for comments for updates to the integrity service
framework, previously accepted into -mm, and EVM a new integrity service
provider.  A new LSM module called Integrity Based Access Control(IBAC),
a consumer of the integrity framework API, will be posted separately to 
the LSM mailing list.

A corresponding userspace utility package is available at 
http://www.research.ibm.com/gsal/tcpa

Patch 1/6 integrity:new hooks
Patch 2/6 integrity:fs hook placement
Patch 3/6 integrity:EVM as an integrity service provider
Patch 4/6 integrity:IMA integrity_measure() support
Patch 5/6 integrity:mtime patch for mmap files
Patch 6/6 integrity:TPM internal kernel interface


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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][Patch 1/6] integrity: new hooks

2007-03-08 Thread Mimi Zohar
This patch adds integrity hooks used to implement an integrity service
provider and updates the previously submitted dummy provider to
support these new hooks.

Index: linux-2.6.21-rc3-mm2/security/integrity_dummy.c
===
--- linux-2.6.21-rc3-mm2.orig/security/integrity_dummy.c
+++ linux-2.6.21-rc3-mm2/security/integrity_dummy.c
@@ -3,7 +3,7 @@
  *
  * Instantiate integrity subsystem
  *
- * Copyright (C) 2005,2006 IBM Corporation
+ * Copyright (C) 2005,2006,2007 IBM Corporation
  * Author: Mimi Zohar [EMAIL PROTECTED]
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -62,9 +62,78 @@ static void dummy_measure(struct dentry 
return;
 }
 
+static int dummy_inode_alloc_integrity(struct inode *inode)
+{
+   return 0;
+}
+
+static void dummy_inode_free_integrity(struct inode *inode)
+{
+   return;
+}
+
+static void dummy_inode_init_integrity(struct inode *inode, struct inode *dir,
+ char **name, void **value, size_t * len)
+{
+   return;
+}
+
+static void dummy_file_free_integrity(struct file *file)
+{
+   return;
+}
+
+static int dummy_inode_setxattr(struct dentry *dentry, char *name, void *value,
+   size_t size, int flags)
+{
+   if (!strncmp(name, XATTR_SECURITY_PREFIX,
+sizeof(XATTR_SECURITY_PREFIX) - 1) 
+   !capable(CAP_SYS_ADMIN))
+   return -EPERM;
+   return 0;
+}
+
+static void dummy_inode_post_setxattr(struct dentry *dentry, char *name)
+{
+}
+
+static void dummy_d_instantiate(struct dentry *dentry, struct inode *inode)
+{
+   return;
+}
+
 struct integrity_operations dummy_integrity_ops = {
.verify_metadata = dummy_verify_metadata,
.verify_data = dummy_verify_data,
-   .measure = dummy_measure
+   .measure = dummy_measure,
+   .inode_setxattr = dummy_inode_setxattr,
+   .inode_post_setxattr = dummy_inode_post_setxattr,
+   .inode_alloc_integrity = dummy_inode_alloc_integrity,
+   .inode_init_integrity = dummy_inode_init_integrity,
+   .inode_free_integrity = dummy_inode_free_integrity,
+   .file_free_integrity = dummy_file_free_integrity,
+   .d_instantiate = dummy_d_instantiate
 };
 
+#define set_to_dummy_if_null(ops, function)\
+   do {\
+   if (!ops-function) {   \
+   ops-function = dummy_##function;   \
+   printk(KERN_INFO Had to override the  #function \
+security operation with the dummy one.\n);\
+   }   \
+   } while (0)
+
+void integrity_fixup_ops(struct integrity_operations *ops)
+{
+   set_to_dummy_if_null(ops, verify_metadata);
+   set_to_dummy_if_null(ops, verify_data);
+   set_to_dummy_if_null(ops, measure);
+   set_to_dummy_if_null(ops, inode_setxattr);
+   set_to_dummy_if_null(ops, inode_post_setxattr);
+   set_to_dummy_if_null(ops, inode_alloc_integrity);
+   set_to_dummy_if_null(ops, inode_init_integrity);
+   set_to_dummy_if_null(ops, inode_free_integrity);
+   set_to_dummy_if_null(ops, file_free_integrity);
+   set_to_dummy_if_null(ops, d_instantiate);
+}
Index: linux-2.6.21-rc3-mm2/security/integrity_dummy.h
===
--- linux-2.6.21-rc3-mm2.orig/security/integrity_dummy.h
+++ linux-2.6.21-rc3-mm2/security/integrity_dummy.h
@@ -1,7 +1,7 @@
 /*
  * integrity_dummy.h
  *
- * Copyright (C) 2005,2006 IBM Corporation
+ * Copyright (C) 2005,2006,2007 IBM Corporation
  * Author: Mimi Zohar [EMAIL PROTECTED]
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -10,3 +10,4 @@
  */
 
 extern struct integrity_operations dummy_integrity_ops;
+extern void integrity_fixup_ops(struct integrity_operations *ops);
Index: linux-2.6.21-rc3-mm2/include/linux/integrity.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/integrity.h
+++ linux-2.6.21-rc3-mm2/include/linux/integrity.h
@@ -1,7 +1,7 @@
 /*
  * integrity.h
  *
- * Copyright (C) 2005,2006 IBM Corporation
+ * Copyright (C) 2005,2006,2007 IBM Corporation
  * Author: Mimi Zohar [EMAIL PROTECTED]
  *
  *  This program is free software; you can redistribute it and/or modify
@@ -45,6 +45,45 @@
  * @filename either contains the full pathname/short file name.
  * @mask contains the filename permission status(i.e. read, write, append).
  *
+ * @inode_setxattr:
+ * Check permission before permitting an integrity extended attribute
+ * to be set.
+ * @value identified by @name for @dentry.
+ * Return 0 if permission is granted.
+ *
+ * @inode_post_setxattr:
+ * Update 

[RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Mimi Zohar
This patch places calls to the new integrity hooks in the appropriate
places in the fs directory. It is not meant in any way to be viewed
as a complete set, but used as a basis for an initial discussion.

Index: linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/ext3/xattr_security.c
+++ linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
@@ -10,6 +10,7 @@
 #include linux/ext3_jbd.h
 #include linux/ext3_fs.h
 #include linux/security.h
+#include linux/integrity.h
 #include xattr.h
 
 static size_t
@@ -58,12 +59,19 @@ ext3_init_security(handle_t *handle, str
 
err = security_inode_init_security(inode, dir, name, value, len);
if (err) {
+   /* Even if creation of the security xattr fails, must
+* indicate this is a new inode. */
+   integrity_inode_init_integrity(inode, dir, NULL, NULL, NULL);
if (err == -EOPNOTSUPP)
return 0;
return err;
}
err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
name, value, len, 0);
+
+   integrity_inode_init_integrity(inode, dir, name, value, len);
+   err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
+   name, value, len, 0);
kfree(name);
kfree(value);
return err;
Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
+++ linux-2.6.21-rc3-mm2/include/linux/fs.h
@@ -591,6 +591,9 @@ struct inode {
 #ifdef CONFIG_SECURITY
void*i_security;
 #endif
+#ifdef CONFIG_INTEGRITY
+   void*i_integrity;
+#endif
void*i_private; /* fs or device private pointer */
 };
 
Index: linux-2.6.21-rc3-mm2/fs/dcache.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/dcache.c
+++ linux-2.6.21-rc3-mm2/fs/dcache.c
@@ -29,6 +29,7 @@
 #include linux/file.h
 #include asm/uaccess.h
 #include linux/security.h
+#include linux/integrity.h
 #include linux/seqlock.h
 #include linux/swap.h
 #include linux/bootmem.h
@@ -986,6 +987,7 @@ void d_instantiate(struct dentry *entry,
entry-d_inode = inode;
fsnotify_d_instantiate(entry, inode);
spin_unlock(dcache_lock);
+   integrity_d_instantiate(entry, inode);
security_d_instantiate(entry, inode);
 }
 
@@ -1050,6 +1052,7 @@ struct dentry *d_instantiate_unique(stru
spin_unlock(dcache_lock);
 
if (!result) {
+   integrity_d_instantiate(entry, inode);
security_d_instantiate(entry, inode);
return NULL;
}
@@ -1187,6 +1190,7 @@ struct dentry *d_splice_alias(struct ino
BUG_ON(!(new-d_flags  DCACHE_DISCONNECTED));
fsnotify_d_instantiate(new, inode);
spin_unlock(dcache_lock);
+   integrity_d_instantiate(new, inode);
security_d_instantiate(new, inode);
d_rehash(dentry);
d_move(new, dentry);
@@ -1197,6 +1201,7 @@ struct dentry *d_splice_alias(struct ino
dentry-d_inode = inode;
fsnotify_d_instantiate(dentry, inode);
spin_unlock(dcache_lock);
+   integrity_d_instantiate(dentry, inode);
security_d_instantiate(dentry, inode);
d_rehash(dentry);
}
@@ -1748,6 +1753,7 @@ found:
spin_unlock(dcache_lock);
 out_nolock:
if (actual == dentry) {
+   integrity_d_instantiate(dentry, inode);
security_d_instantiate(dentry, inode);
return NULL;
}
Index: linux-2.6.21-rc3-mm2/fs/file_table.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/file_table.c
+++ linux-2.6.21-rc3-mm2/fs/file_table.c
@@ -13,6 +13,7 @@
 #include linux/smp_lock.h
 #include linux/fs.h
 #include linux/security.h
+#include linux/integrity.h
 #include linux/eventpoll.h
 #include linux/rcupdate.h
 #include linux/mount.h
@@ -169,6 +170,7 @@ void fastcall __fput(struct file *file)
if (file-f_op  file-f_op-release)
file-f_op-release(inode, file);
security_file_free(file);
+   integrity_file_free(file);
if (unlikely(S_ISCHR(inode-i_mode)  inode-i_cdev != NULL))
cdev_put(inode-i_cdev);
fops_put(file-f_op);
@@ -240,6 +242,7 @@ void put_filp(struct file *file)
 {
if (atomic_dec_and_test(file-f_count)) {
security_file_free(file);
+   integrity_file_free(file);
file_kill(file);

[RFC][Patch 3/6] integrity: EVM as an integrity service provider

2007-03-08 Thread Mimi Zohar
This is a re-release of EVM as an integrity service provider.  The
initial EVM release was as an LSM module. It has been substantially
rewritten to provide support for the new integrity service framework
API, which permits applications, such as LSM modules, to verify the
integrity of the metadata and data of a file.

EVM maintains an HMAC-sha1 associated with each file across an
extensible set of extended attributes, ensuring that the extended
attributes are protected against integrity attacks. The HMAC-sha1 is
stored as an extended attribute security.evm.hmac.  EVM depends on the
Kernel Key Retention System to provide it with the kernel master key
for the HMAC operation.  The kernel master key is loaded onto the
root's keyring by 'loadkernkey', which either uses the TPM sealed
secrect key, if available, or a password requested from the console.

The integrity measurement of the file data, stored in the extended
attribute security.evm.hash (md5) or security.evm.sha1, is protected
by the HMAC. EVM maintains the integrity measurement of the file data,
unless the file is defined as either FIXED or NOHASH. 

The integrity service framework API defines three calls:
integrity_verify_metadata(), integrity_verify_data(), and
integrity_measure().  For integrity_verify_metadata(), EVM determines
whether or not the HMAC calculated for the set of extended attributes
matches the HMAC stored as an extended attribute; for
integrity_verify_data(), EVM determines whether or not the integrity
measurement of the file data matches the value stored as an extended
attribute; and for integrity_measure(), if IMA is configured and
enabled, EVM passes the integrity measurement to it.

Index: linux-2.6.21-rc3-mm2/security/evm/evm_config.c
===
--- /dev/null
+++ linux-2.6.21-rc3-mm2/security/evm/evm_config.c
@@ -0,0 +1,129 @@
+/*
+ * EVM - Extended Verification Module
+ *
+ * Copyright (C) 2005,2006,2007 IBM Corporation
+ * Author: Mimi Zohar [EMAIL PROTECTED]
+ *Kylene Hall [EMAIL PROTECTED]
+ *
+ *  This program is free software; you can redistribute it and/or modify
+ *  it under the terms of the GNU General Public License as published by
+ *  the Free Software Foundation, version 2 of the License.
+ */
+
+#include linux/module.h
+#include linux/kernel.h
+#include evm.h
+
+/*
+ * Configuration data
+ */
+struct evm_xattr_config *evm_config_xattrdata;
+int evm_config_xattrnum = 0;   /* number of extended attributes */
+
+/*
+ * inode-i_integrity information
+ */
+void display_config(const char *name)
+{
+   struct evm_xattr_config *config_p;
+
+   for_each_xattr(config_p, evm_config_xattrdata, evm_config_xattrnum)
+   printk(KERN_INFO %s: %s\n, name, config_p-xattr_name);
+}
+
+/*
+ * Initialize the Extended Verification module
+ */
+int evm_init_config(struct evm_xattr_config *evm_data, int evm_datasize)
+{
+   ssize_t error = 0;
+
+   if (evm_datasize  0) {
+   evm_config_xattrdata = evm_data;
+   evm_config_xattrnum = evm_datasize;
+   display_config(__FUNCTION__);
+
+   } else {
+   printk(KERN_INFO %s: config file definition missing\n,
+  __FUNCTION__);
+   return -EINVAL;
+   }
+   return error;
+}
+
+static char *get_tag(char *buf_start, char *buf_end, char delimiter,
+int *taglen)
+{
+   char *bufp = buf_start;
+   char *tag;
+
+   /* Get start of tag */
+   while (bufp  buf_end) {
+   if (*bufp == ' ')   /* skip blanks */
+   while ((*bufp == ' ')  (bufp++  buf_end)) ;
+   else if (*bufp == '#') {/* skip comment */
+   while ((*bufp != '\n')  (bufp++  buf_end)) ;
+   bufp++;
+   } else if (*bufp == '\n')   /* skip newline */
+   bufp++;
+   else if (*bufp == '\t') /* skip tabs */
+   bufp++;
+   else
+   break;
+   }
+   if (bufp  buf_end)
+   tag = bufp;
+   else
+   return NULL;
+
+   /* Get tag */
+   *taglen = 0;
+   while ((bufp  buf_end)  (*taglen == 0)) {
+   if ((*bufp == delimiter) || (*bufp == '\n'))
+   *taglen = bufp - tag;
+   bufp++;
+   }
+   if (*taglen == 0)   /* Didn't find end delimiter */
+   *taglen = bufp - tag;
+   return tag;
+}
+
+struct evm_xattr_config *evm_parse_config(char *data, unsigned long datalen,
+ int *xattrnum)
+{
+   char *datap, *dataend, *tag;
+   int num_xattr = 0;
+   struct evm_xattr_config *config_xattrdata = NULL, *config_p;
+   int taglen;
+
+   /* Get number of extended attribute definitions */
+   datap = data;
+   dataend = data + datalen;
+
+   while ((tag = 

[RFC][Patch 4/6] integrity: IMA integrity_measure() support

2007-03-08 Thread Mimi Zohar
This is a re-release of Integrity Measurement Architecture(IMA) as a
method of providing support for the integrity service framework API
integrity_measure() call. When integrity_measure() is called, IMA
submits the measurement (hash) of the file to the TPM chip, for
inclusion in one of the chip's Platform Configuration Registers (PCR).
IMA also keeps a list of all file names and hashes that have been
submitted to the TPM, which can be viewed through securityfs. By
separately requesting a TPM_Quote from the chip, an application can
get a chip-signed value of the PCR, which, along with the list of
measurements from IMA, can be used to attest, or prove to a third
party, the validity of the hash list.  (The tpm-3.2.1 package includes
example TPM applications for creating keys, and performing the
TPM_Quote operation.) 

IMA can be included or excluded in the kernel configuration. If
included in the kernel, IMA can also be enabled or disabled on the
kernel command line with evm_enable_ima=0.

Index: linux-2.6.21-rc3-mm2/security/evm/Kconfig
===
--- linux-2.6.21-rc3-mm2.orig/security/evm/Kconfig
+++ linux-2.6.21-rc3-mm2/security/evm/Kconfig
@@ -15,3 +15,4 @@ config INTEGRITY_EVM
 
  If you are unsure how to answer this question, answer N.
 
+source security/evm/ima/Kconfig
Index: linux-2.6.21-rc3-mm2/security/evm/Makefile
===
--- linux-2.6.21-rc3-mm2.orig/security/evm/Makefile
+++ linux-2.6.21-rc3-mm2/security/evm/Makefile
@@ -3,3 +3,6 @@ obj-$(CONFIG_INTEGRITY_EVM) += evm.o
 
 evm-y := evm_main.o evm_config.o evm_crypto.o evm_secfs.o
 
+ifeq ($(CONFIG_IMA_MEASURE), y)
+evm-y += ima/ima_fs.o ima/ima_queue.o ima/ima_init.o ima/ima_main.o
+endif
Index: linux-2.6.21-rc3-mm2/security/evm/evm_integrity.h
===
--- /dev/null
+++ linux-2.6.21-rc3-mm2/security/evm/evm_integrity.h
@@ -0,0 +1,49 @@
+/*
+ * These functions enable EVM to be compiled with/without IMA.
+ * The configuration parameter evm_enable_ima enables/disables
+ * at runtime.
+ */
+
+#include ima/ima_evm.h
+
+extern unsigned int evm_enable_ima;
+
+#ifdef CONFIG_IMA_MEASURE
+static inline int evm_ima_init(void)
+{
+   if (evm_enable_ima)
+   return ima_init();
+}
+
+static inline void evm_ima_measure(const unsigned char *name, int hash_len,
+  char *hash)
+{
+   if (evm_enable_ima)
+   ima_measure(name, hash_len, hash);
+}
+
+static inline void evm_ima_cleanup(void)
+{
+   if (evm_enable_ima)
+   ima_cleanup();
+   evm_enable_ima = 0;
+}
+
+#else
+static inline int evm_ima_init(void)
+{
+   evm_enable_ima = 0;
+   return 0;
+}
+
+static inline void evm_ima_measure(const unsigned char *name, int hash_len,
+  char *hash)
+{
+   return;
+}
+
+static inline void evm_ima_cleanup(void)
+{
+   evm_enable_ima = 0;
+}
+#endif
Index: linux-2.6.21-rc3-mm2/security/evm/evm_secfs.c
===
--- linux-2.6.21-rc3-mm2.orig/security/evm/evm_secfs.c
+++ linux-2.6.21-rc3-mm2/security/evm/evm_secfs.c
@@ -20,7 +20,7 @@
 extern int evm_initialized;
 
 static struct dentry *evm_secdir, *evm_config;
-static struct dentry *evm_dir, *evm_cache, *evm_crypto, *evm_xattr;
+static struct dentry *evm_dir, *evm_cache, *evm_crypto, *evm_xattr, *evm_ima;
 
 static int evm_open_debug(struct inode *inode, struct file *file)
 {
@@ -62,6 +62,10 @@ static ssize_t evm_read_debug(struct fil
len = sprintf(page, evm_debug: crypto: %s\n,
  ((evm_debug  EVM_CRYPTO) == EVM_CRYPTO)
  ? ON : OFF);
+   else if (strcmp(file-private_data, ima) == 0)
+   len = sprintf(page, evm_debug: ima: %s\n,
+ ((evm_debug  EVM_IMA) == EVM_IMA)
+ ? ON : OFF);
else
len = sprintf(page, unknown evm_debug option\n);
 
@@ -87,6 +91,9 @@ static ssize_t evm_write_debug(struct fi
else if (strcmp(file-private_data, crypto) == 0)
evm_debug = (flag == '0') ? evm_debug  ~EVM_CRYPTO :
evm_debug | EVM_CRYPTO;
+   else if (strcmp(file-private_data, ima) == 0)
+   evm_debug = (flag == '0') ? evm_debug  ~EVM_IMA :
+   evm_debug | EVM_IMA;
return buflen;
 }
 
@@ -169,12 +176,20 @@ int __init evm_init_secfs(void)
if (!evm_crypto || IS_ERR(evm_crypto))
goto out_del_cache;
 
+   evm_ima = debugfs_create_file(ima, S_IRUSR | S_IRGRP, evm_dir,
+ ima, evm_debug_ops);
+   if (!evm_ima || IS_ERR(evm_ima))
+   goto out_del_crypto;
+
evm_xattr = debugfs_create_file(xattr, S_IRUSR | S_IRGRP, evm_dir,
   

[RFC][Patch 6/6] integrity: TPM internal kernel interface

2007-03-08 Thread Mimi Zohar
Index: linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
===
--- linux-2.6.21-rc3-mm2.orig/drivers/char/tpm/tpm.c
+++ linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
@@ -1,5 +1,5 @@
 /*
- * Copyright (C) 2004 IBM Corporation
+ * Copyright (C) 2004,2007 IBM Corporation
  *
  * Authors:
  * Leendert van Doorn [EMAIL PROTECTED]
@@ -25,6 +25,12 @@
 
 #include linux/poll.h
 #include linux/spinlock.h
+#include linux/mm.h
+#include linux/slab.h
+#include linux/string.h
+#include linux/crypto.h
+#include linux/fs.h
+#include asm/scatterlist.h
 #include tpm.h
 
 enum tpm_const {
@@ -47,6 +53,8 @@ enum tpm_duration {
 static LIST_HEAD(tpm_chip_list);
 static DEFINE_SPINLOCK(driver_lock);
 static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
+#define TPM_CHIP_NUM_MASK   0x
+#define TPM_CHIP_TYPE_SHIFT 16
 
 /*
  * Array with one entry per ordinal defining the maximum amount
@@ -363,7 +371,7 @@ EXPORT_SYMBOL_GPL(tpm_calc_ordinal_durat
 /*
  * Internal kernel interface to transmit TPM commands
  */
-static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
+ssize_t tpm_transmit(struct tpm_chip *chip, char *buf,
size_t bufsiz)
 {
ssize_t rc;
@@ -422,6 +430,7 @@ out:
up(chip-tpm_mutex);
return rc;
 }
+EXPORT_SYMBOL_GPL(tpm_transmit);
 
 #define TPM_DIGEST_SIZE 20
 #define TPM_ERROR_SIZE 10
@@ -665,6 +674,7 @@ ssize_t tpm_show_temp_deactivated(struct
 }
 EXPORT_SYMBOL_GPL(tpm_show_temp_deactivated);
 
+#define READ_PCR_RESULT_SIZE 30
 static const u8 pcrread[] = {
0, 193, /* TPM_TAG_RQU_COMMAND */
0, 0, 0, 14,/* length */
@@ -713,6 +723,93 @@ out:
 }
 EXPORT_SYMBOL_GPL(tpm_show_pcrs);
 
+static struct tpm_chip* tpm_chip_lookup(int chip_num, int chip_typ)
+{
+struct tpm_chip *pos;
+
+spin_lock(driver_lock);
+list_for_each_entry(pos, tpm_chip_list, list)
+if ((chip_num == TPM_ANY_NUM ||
+pos-dev_num == chip_num ) 
+(chip_typ == TPM_ANY_TYPE)){
+spin_unlock(driver_lock);
+return pos;
+}
+
+spin_unlock(driver_lock);
+return NULL;
+}
+
+/*
+ * Return 0 on success.  On error pass along error code.
+ * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
+ * Lower 2 bytes equal tpm idx # or AN
+ * res_buf must fit a TPM_PCR (20 bytes) or NULL if you don't care
+ */
+int tpm_pcr_read( u32 chip_id, int pcr_idx, u8* res_buf, int res_buf_size )
+{
+u8 data[READ_PCR_RESULT_SIZE];
+int rc;
+__be32 index;
+int chip_num = chip_id  TPM_CHIP_NUM_MASK;
+struct tpm_chip* chip;
+
+if ( res_buf  res_buf_size  TPM_DIGEST_SIZE )
+return -ENOSPC;
+
+if ( (chip = tpm_chip_lookup( chip_num,
+chip_id  TPM_CHIP_TYPE_SHIFT ) ) == NULL )
+return -ENODEV;
+
+memcpy(data, pcrread, sizeof(pcrread));
+index = cpu_to_be32(pcr_idx);
+memcpy(data + 10, index, 4);
+if ((rc = tpm_transmit(chip, data, sizeof(data)))  0 )
+rc = be32_to_cpu(*((u32*)(data+6)));
+
+if ( rc == 0  res_buf )
+memcpy(res_buf, data+10, TPM_DIGEST_SIZE);
+
+return rc;
+
+}
+EXPORT_SYMBOL_GPL(tpm_pcr_read);
+
+#define EXTEND_PCR_SIZE 34
+static const u8 pcrextend[] = {
+0, 193, /* TPM_TAG_RQU_COMMAND */
+0, 0, 0, 34,/* length */
+0, 0, 0, 20,/* TPM_ORD_Extend */
+0, 0, 0, 0  /* PCR index */
+};
+
+/*
+ * Return 0 on success.  On error pass along error code.
+ * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
+ * Lower 2 bytes equal tpm idx # or ANY
+ */
+int tpm_pcr_extend(u32 chip_id, int pcr_idx, const u8* hash)
+{
+u8 data[EXTEND_PCR_SIZE];
+int rc;
+__be32 index;
+int chip_num = chip_id  TPM_CHIP_NUM_MASK;
+struct tpm_chip* chip;
+
+if ( (chip = tpm_chip_lookup( chip_num,
+chip_id  TPM_CHIP_TYPE_SHIFT )) == NULL )
+return -ENODEV;
+
+memcpy(data, pcrextend, sizeof(pcrextend));
+index = cpu_to_be32(pcr_idx);
+memcpy(data + 10, index, 4);
+memcpy( data + 14, hash, TPM_DIGEST_SIZE );
+if ((rc = tpm_transmit(chip, data, sizeof(data)))  0 )
+rc = be32_to_cpu(*((u32*)(data+6)));
+return rc;
+}
+EXPORT_SYMBOL_GPL(tpm_pcr_extend);
+
 #define  READ_PUBEK_RESULT_SIZE 314
 static const u8 readpubek[] = {
0, 193, /* TPM_TAG_RQU_COMMAND */
@@ -944,13 +1041,13 @@ int tpm_release(struct inode *inode, str
 
spin_lock(driver_lock);
file-private_data = NULL;
+   spin_unlock(driver_lock);
chip-num_opens--;
del_singleshot_timer_sync(chip-user_read_timer);

[RFC][Patch 5/6] integrity: mtime patch for mmap files

2007-03-08 Thread Mimi Zohar
This is a minimal subset of Peter Staubach's July patch, updated to
apply to the latest kernel. The subset was chosen to demonstrate that
mmaped files are hashed and hmac properly by EVM after being modified
when a file's mtime is updated correctly.

Index: linux-2.6.21-rc3-mm2/fs/inode.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/inode.c
+++ linux-2.6.21-rc3-mm2/fs/inode.c
@@ -1209,8 +1209,8 @@ void touch_atime(struct vfsmount *mnt, s
 EXPORT_SYMBOL(touch_atime);
 
 /**
- * file_update_time-   update mtime and ctime time
- * @file: file accessed
+ * inode_update_time   -   update mtime and ctime time
+ * @inode: file accessed
  *
  * Update the mtime and ctime members of an inode and mark the inode
  * for writeback.  Note that this function is meant exclusively for
@@ -1220,9 +1220,8 @@ EXPORT_SYMBOL(touch_atime);
  * timestamps are handled by the server.
  */
 
-void file_update_time(struct file *file)
+void inode_update_time(struct inode *inode)
 {
-   struct inode *inode = file-f_path.dentry-d_inode;
struct timespec now;
int sync_it = 0;
 
@@ -1246,7 +1245,7 @@ void file_update_time(struct file *file)
mark_inode_dirty_sync(inode);
 }
 
-EXPORT_SYMBOL(file_update_time);
+EXPORT_SYMBOL(inode_update_time);
 
 int inode_needs_sync(struct inode *inode)
 {
Index: linux-2.6.21-rc3-mm2/fs/fs-writeback.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/fs-writeback.c
+++ linux-2.6.21-rc3-mm2/fs/fs-writeback.c
@@ -167,6 +167,9 @@ __sync_single_inode(struct inode *inode,
 
spin_unlock(inode_lock);
 
+   if (test_and_clear_bit(AS_MCTIME, mapping-flags))
+   inode_update_time(inode);
+
ret = do_writepages(mapping, wbc);
 
/* Don't write the inode if only I_DIRTY_PAGES was set */
Index: linux-2.6.21-rc3-mm2/fs/buffer.c
===
--- linux-2.6.21-rc3-mm2.orig/fs/buffer.c
+++ linux-2.6.21-rc3-mm2/fs/buffer.c
@@ -734,8 +734,11 @@ int __set_page_dirty_buffers(struct page
}
spin_unlock(mapping-private_lock);
 
-   if (TestSetPageDirty(page))
+   if (TestSetPageDirty(page)) {
+   if (page_mapped(page))
+   set_bit(AS_MCTIME, mapping-flags);
return 0;
+   }
 
write_lock_irq(mapping-tree_lock);
if (page-mapping) {/* Race with truncate? */
@@ -749,6 +752,8 @@ int __set_page_dirty_buffers(struct page
}
write_unlock_irq(mapping-tree_lock);
__mark_inode_dirty(mapping-host, I_DIRTY_PAGES);
+   if (page_mapped(page))
+   set_bit(AS_MCTIME, mapping-flags);
return 1;
 }
 EXPORT_SYMBOL(__set_page_dirty_buffers);
Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
+++ linux-2.6.21-rc3-mm2/include/linux/fs.h
@@ -1944,7 +1944,12 @@ extern int buffer_migrate_page(struct ad
 extern int inode_change_ok(struct inode *, struct iattr *);
 extern int __must_check inode_setattr(struct inode *, struct iattr *);
 
-extern void file_update_time(struct file *file);
+extern void inode_update_time(struct inode *);
+
+static inline void file_update_time(struct file *file)
+{
+   inode_update_time(file-f_dentry-d_inode);
+}
 
 static inline ino_t parent_ino(struct dentry *dentry)
 {
Index: linux-2.6.21-rc3-mm2/include/linux/pagemap.h
===
--- linux-2.6.21-rc3-mm2.orig/include/linux/pagemap.h
+++ linux-2.6.21-rc3-mm2/include/linux/pagemap.h
@@ -17,8 +17,9 @@
  * Bits in mapping-flags.  The lower __GFP_BITS_SHIFT bits are the page
  * allocation mode flags.
  */
-#defineAS_EIO  (__GFP_BITS_SHIFT + 0)  /* IO error on async 
write */
+#define AS_EIO (__GFP_BITS_SHIFT + 0)  /* IO error on async write */
 #define AS_ENOSPC  (__GFP_BITS_SHIFT + 1)  /* ENOSPC on async write */
+#define AS_MCTIME  (__GFP_BITS_SHIFT + 2)  /* need m/ctime change */
 
 static inline void mapping_set_error(struct address_space *mapping, int error)
 {
Index: linux-2.6.21-rc3-mm2/mm/page-writeback.c
===
--- linux-2.6.21-rc3-mm2.orig/mm/page-writeback.c
+++ linux-2.6.21-rc3-mm2/mm/page-writeback.c
@@ -815,8 +815,10 @@ int __set_page_dirty_no_writeback(struct
  */
 int __set_page_dirty_nobuffers(struct page *page)
 {
+   struct address_space *mapping = page_mapping(page);
+   int ret = 0;
+
if (!TestSetPageDirty(page)) {
-   struct address_space *mapping = page_mapping(page);
struct address_space *mapping2;
 
if (!mapping)
@@ -840,9 +842,11 @@ int __set_page_dirty_nobuffers(struct pa
/* !PageAnon  

Re: [patch] epoll use a single inode ...

2007-03-08 Thread Linus Torvalds


On Thu, 8 Mar 2007, Eric Dumazet wrote:
 
 Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
 CC: Christoph Hellwig [EMAIL PROTECTED]
 CC: Linus Torvalds [EMAIL PROTECTED]

Acked-by: Linus Torvalds [EMAIL PROTECTED]

Except you should fix the subject line when you send it out to Andrew ;)

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


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread Arjan van de Ven
On Thu, 2007-03-08 at 09:00 +, Christoph Hellwig wrote:
 On Thu, Mar 08, 2007 at 03:18:04AM +0100, Roman Zippel wrote:
  Hi,
  
  On Tuesday 06 March 2007 10:29, Christoph Hellwig wrote:
  
   PAGE_SIZE should not be available at all.  Please use getpagesize()
   instead.
  
  While I agree, NBPG is a bit of a problem, although it's only needed for 
  aout 
  coredumps AFAICT, but still needed to compile e.g. gdb.
 
 So we should export this one with an arbitrary value (on multiple page
 size architectures) and a warning, maybe even an __deprecated attached to
 it.

if we think the kernel should export this one, we could do

#ifndef __KERNEL__
#define PAGE_SIZE getpagesize()
#endif


-- 
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via 
http://www.linuxfirmwarekit.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: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Takashi Iwai
At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
 
 Takashi Iwai napisał(a):
  At Wed, 07 Mar 2007 23:22:36 +0100,
  Michal Piotrowski wrote:
  Hi Takashi,
 
  Takashi Iwai napisał(a):
  At Wed, 7 Mar 2007 11:50:24 -0800,
  Andrew Morton wrote:
  On Wed, 7 Mar 2007 20:41:30 +0100 Michal Piotrowski [EMAIL 
  PROTECTED] wrote:
 
  831466f4ad2b5fe23dff77edbe6a7c244435e973 is first bad commit
  commit 831466f4ad2b5fe23dff77edbe6a7c244435e973
  Author: Randy Cushman [EMAIL PROTECTED]
  Date:   Tue Dec 19 18:42:16 2006 +0100
 
  [ALSA] ac97 - fix microphone and line_in selection logic
 
  This patch fixes the Microphone and LINE_IN select logic for
  Analog Devices surround codecs with shared jacks.  The existing
  code can never utilize the shared jacks for Microphone and LINE_IN
  due to the reversed jack selection logic.  The patched code
  correctly selects the shared jack for input if the 'Channel Mode'
  selector does not specify that the jack is to be used for output.
  Specifically, in '2ch' mode the Center/LFE jack is used for
  microphone input and the Surround jack is used for LINE_IN,
  in '4ch' mode the Center/LFE jack is used for microphone input
  and the Surround jack is used for output, and in '6ch' mode
  both jacks are used for output.
 
  Signed-off-by: Randy Cushman [EMAIL PROTECTED]
  Signed-off-by: Takashi Iwai [EMAIL PROTECTED]
  Signed-off-by: Jaroslav Kysela [EMAIL PROTECTED]
 
  Is 2.6.21-rc3 similarly broken?
  Yes.
 
  OK.  Can you please confirm that applying the below fixes 2.6.21-rc3?
 
  If so, I'll queue it up for application in a week or two if there is no
  progress on this.
  [sorry for the late interrupt - I'm just back from a vacation]
 
  Could you postpone reverting for a while?
  I guess this possible regression is limited only to a certain type of
  ac97 codec chip.  The patch applied there was a fix for many codec
  chips.
 
  Which codec chip are you using specifically?  Please check
  /proc/asound/card0/codec97#0/* file(s).
  0-0/0: Analog Devices AD1985
  
  OK, that's good to know.
  
 control.43 {
 comment.access 'read write'
 comment.type BOOLEAN
 comment.count 1
 iface MIXER
 name 'Spread Front to Surround and Center/LFE'
 value true
 }
  
  So, you're playing two-channel samples and get no output from surround
  and CLFE?
 
 Yes.
 
  Or, does it happen if you play a real 5.1 channel file?
  (for example, try speaker-test -c6)
 
 It doesn't work for me on both kernels.

Pass -Dplug:surround51 to speaker-test in addition.


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


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Takashi Iwai
At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
 
  Also, it'd be helpful if you compare
  /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
  patch.  This reveals which register bits differ actually.
 
 a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

Just to make sure: it means that a2.txt is a working one and the
anoter is non-working, right?


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


Re: Radeon xpress 200m and radeonfb kinda work

2007-03-08 Thread Chuck Ebbert
johan henriksson wrote:
 As you can see in the patch I have disabled Dynamic Clock PM
 since it makes my card freak out (Don't know why :(  ).
 Is there a reason why the default_dynclk parameter only is available
 when radeonfb is built as a module or should it be added to radeonfb_setup?

I don't have a clue how that works; I just merged your patch
into a Fedora test kernel and it worked. (And it looks a lot
nicer than vesafb.)

Our X driver guru says the patch is OK and Xpress 200M is
the same as normal Radeon for 2D so framebuffer should be OK.

So we can add this to the patch:

Tested-by: Chuck Ebbert [EMAIL PROTECTED]

Please repost it as a reply-to-all and add a decent description
and a signed-off-by per this document:

http://www.zip.com.au/~akpm/linux/patches/stuff/tpp.txt
Hi!

I have gotten the radeon xpress 200m (the version without dedicated vmem)
to work with radeonfb.
The attached patch (against linux-2.6.20.1) works for me.
Since I don't have any docs for the card I am unsure if the patch is 100% 
correct.
Can someone else with a 200m try it out?
(I have tested it by enabling  fbcon and radeonfb in the kernel  and
added video=radeonfb to lilo. This gave me a nice 1280x800 console :) )

/Johan Henriksson

Please CC, I'm not on the list.



diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff 
linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h 
linux-2.6.20.1/drivers/video/aty/ati_ids.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/ati_ids.h  Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/ati_ids.h  Tue Mar  6 00:31:16 2007
@@ -209,4 +209,4 @@
 #define PCI_CHIP_R423_5D57  0x5D57
 #define PCI_CHIP_RS350_7834 0x7834
 #define PCI_CHIP_RS350_7835 0x7835
-
+#define PCI_CHIP_RS480_5955 0x5955
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff 
linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c 
linux-2.6.20.1/drivers/video/aty/radeon_base.c
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeon_base.c  Tue Feb 20 
07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeon_base.c  Tue Mar  6 00:31:19 2007
@@ -100,6 +100,8 @@
{ PCI_VENDOR_ID_ATI, id, PCI_ANY_ID, PCI_ANY_ID, 0, 0, (flags) | 
(CHIP_FAMILY_##family) }
 
 static struct pci_device_id radeonfb_pci_table[] = {
+/* Radeon Xpress 200m */
+   CHIP_DEF(PCI_CHIP_RS480_5955,   RS480,  CHIP_HAS_CRTC2 | CHIP_IS_IGP | 
CHIP_IS_MOBILITY),
/* Mobility M6 */
CHIP_DEF(PCI_CHIP_RADEON_LY,RV100,  CHIP_HAS_CRTC2 | 
CHIP_IS_MOBILITY),
CHIP_DEF(PCI_CHIP_RADEON_LZ,RV100,  CHIP_HAS_CRTC2 | 
CHIP_IS_MOBILITY),
@@ -1990,7 +1992,8 @@ static void radeon_identify_vram(struct 
/* framebuffer size */
 if ((rinfo-family == CHIP_FAMILY_RS100) ||
 (rinfo-family == CHIP_FAMILY_RS200) ||
-(rinfo-family == CHIP_FAMILY_RS300)) {
+(rinfo-family == CHIP_FAMILY_RS300) ||
+   (rinfo-family == CHIP_FAMILY_RS480) ) {
   u32 tom = INREG(NB_TOM);
   tmp = tom  16) - (tom  0x) + 1)  6) * 1024);
@@ -2329,7 +2332,7 @@ static int __devinit radeonfb_pci_regist
/* -2 is special: means  ON on mobility chips and do not
 * change on others
 */
-   radeonfb_pm_init(rinfo, rinfo-is_mobility ? 1 : -1, 
ignore_devlist, force_sleep);
+   radeonfb_pm_init(rinfo, -1,ignore_devlist, 
force_sleep);//rinfo-is_mobility ? 1 : -1);
} else
radeonfb_pm_init(rinfo, default_dynclk, ignore_devlist, 
force_sleep);
diff -uprN -X linux-2.6.20.1-vanilla/Documentation/dontdiff 
linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h 
linux-2.6.20.1/drivers/video/aty/radeonfb.h
--- linux-2.6.20.1-vanilla/drivers/video/aty/radeonfb.h Tue Feb 20 07:34:32 2007
+++ linux-2.6.20.1/drivers/video/aty/radeonfb.h Tue Mar  6 00:31:16 2007
@@ -48,6 +48,7 @@ enum radeon_family {
CHIP_FAMILY_RV350,
CHIP_FAMILY_RV380,/* RV370/RV380/M22/M24 */
CHIP_FAMILY_R420, /* R420/R423/M18 */
+   CHIP_FAMILY_RS480,
CHIP_FAMILY_LAST,
 };
 
@@ -64,7 +65,8 @@ enum radeon_family {
((rinfo)-family == CHIP_FAMILY_RV350) || \
((rinfo)-family == CHIP_FAMILY_R350)  || \
((rinfo)-family == CHIP_FAMILY_RV380) || \
-   ((rinfo)-family == CHIP_FAMILY_R420))
+   ((rinfo)-family == CHIP_FAMILY_R420)  || \
+   ((rinfo)-family == CHIP_FAMILY_RS480) )
 
 /*
  * Chip flags


Re: refcounting drivers' data structures used in sysfs buffers

2007-03-08 Thread Alan Stern
On Thu, 8 Mar 2007, Oliver Neukum wrote:

 Hi,
 
 after a lightning bolt from high above I've been looking into refcounting
 the data structures drivers use to provide the data used to refill sysfs
 buffers. I've come to the following conclusion.
 
 1. struct sysfs_buffer must have a struct kref * and probably a destructor
 pointer
 2. drivers must be able to pass these pointers through an extended
 device_create_file()
 3. Drivers must use refcounting if they want to use attributes
 4. read/write/poll must do refcounting
 
 I am not sure where to store the pointers. struct sysfs_dirent() looks
 like the obvious choice. Comments?

Can you explain the reasoning that led to these conclusions?  And what 
exactly was your lightning bolt?

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: Problem with libata-pata, ATAPI DVD reader and a copy-protected audio cd

2007-03-08 Thread Alan Cox
 Well, it happened again, with a different cd, and this time I never
 started the player: hal/g-v-m tried to access the CD and now my driver
 is in PIO2 mode and pretty much unusable. Is there a way to fix this
 without rebooting?

Hard to tell. If it happens again then a dmesg after it misbehaves and
an lspci -vxx might provide enough information to begin to debug it.

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: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread Christoph Hellwig
On Thu, Mar 08, 2007 at 07:53:49AM -0800, Arjan van de Ven wrote:
PAGE_SIZE should not be available at all.  Please use getpagesize()
instead.
   
   While I agree, NBPG is a bit of a problem, although it's only needed for 
   aout 
   coredumps AFAICT, but still needed to compile e.g. gdb.
  
  So we should export this one with an arbitrary value (on multiple page
  size architectures) and a warning, maybe even an __deprecated attached to
  it.
 
 if we think the kernel should export this one, we could do
 
 #ifndef __KERNEL__
 #define PAGE_SIZE getpagesize()
 #endif

No, no no.  We should never export PAGE_SIZE.  We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
not depending on PAGE_SIZE.

I've Cc'ed the gdb list on whether they have any comments on this
issue.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Takashi Iwai
At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
 
  Also, it'd be helpful if you compare
  /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
  patch.  This reveals which register bits differ actually.
 
 a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973
 
 diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
 --- a2.txt  2007-03-08 16:36:47.0 +0100
 +++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 16:36:49.447083597 
 +0100
 @@ -56,8 +56,8 @@
  0:6e = 
  0:70 = 
  0:72 = 0004
 -0:74 = 1001
 -0:76 = 64a4
 +0:74 = 1201
 +0:76 = 7ca4
  0:78 = 000c
  0:7a = 
  0:7c = 4144

OK, some wrong bits there.  Could you try the patch below?


Takashi

diff -r 6888d4cd251d sound/pci/ac97/ac97_patch.c
--- a/sound/pci/ac97/ac97_patch.c   Thu Mar 08 12:53:55 2007 +0100
+++ b/sound/pci/ac97/ac97_patch.c   Thu Mar 08 17:10:52 2007 +0100
@@ -1950,9 +1950,9 @@ static void ad1888_update_jacks(struct s
 static void ad1888_update_jacks(struct snd_ac97 *ac97)
 {
unsigned short val = 0;
-   if (! is_shared_linein(ac97))
+   if (is_shared_linein(ac97))
val |= (1  12);
-   if (! is_shared_micin(ac97))
+   if (is_shared_micin(ac97))
val |= (1  11);
/* shared Line-In */
snd_ac97_update_bits(ac97, AC97_AD_MISC, (1  11) | (1  12), val);
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] PPC: Correct apparently misspelled XMON preprocessor directive.

2007-03-08 Thread Robert P. J. Day

  Correct the apparent misspelling of XMON to CONFIG_XMON.

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

---

  i'm only *guessing* that this is a typo, given that the file
arch/powerpc/Kconfig.debug defines the XMON config variable.


diff --git a/arch/powerpc/platforms/chrp/setup.c 
b/arch/powerpc/platforms/chrp/setup.c
index 117c9a0..1edce72 100644
--- a/arch/powerpc/platforms/chrp/setup.c
+++ b/arch/powerpc/platforms/chrp/setup.c
@@ -427,7 +427,7 @@ static void __init chrp_find_openpic(void)
of_node_put(np);
 }

-#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(XMON)
+#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(CONFIG_XMON)
 static struct irqaction xmon_irqaction = {
.handler = xmon_irq,
.mask = CPU_MASK_NONE,
@@ -493,7 +493,7 @@ static void __init chrp_find_8259(void)

 void __init chrp_init_IRQ(void)
 {
-#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(XMON)
+#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(CONFIG_XMON)
struct device_node *kbd;
 #endif
chrp_find_openpic();
@@ -510,7 +510,7 @@ void __init chrp_init_IRQ(void)
if (_chrp_type == _CHRP_Pegasos)
ppc_md.get_irq= i8259_irq;

-#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(XMON)
+#if defined(CONFIG_VT)  defined(CONFIG_INPUT_ADBHID)  defined(CONFIG_XMON)
/* see if there is a keyboard in the device tree
   with a parent of type adb */
for (kbd = find_devices(keyboard); kbd; kbd = kbd-next)

-- 

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

http://fsdev.net/wiki/index.php?title=Main_Page

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


Re: [patch 2/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Linus Torvalds


On Thu, 8 Mar 2007, Davide Libenzi wrote:
 
 This patch, if you get a POLLIN, you have a signal to read for sure (well, 
 unless you another thread/task reads it before you - but that's just 
 somthing you have to take care). There is not explicit check for 
 O_NONBLOCK now, but a zero timeout would do exactly the same thing.

You missed David's worry, I think.

Not only is POLLIN potentially an edge event (depending on the interface 
you use to fetch it), but even as a level-triggered one you generally want 
to read as much as possible per POLLIN event, and go back to the event 
loop only when you get EAGAIN.

So that's in addition to the read/signal race with other 
threads/processes.

You solved it by having a separate system call, but since it's a regular 
file descriptor, why have a new system call at all, and not just make it 
be a read()? In which case you definitely want O_NONBLOCK support.

The UNIX philosophy is often quoted as everything is a file, but that 
really means everything is a stream of bytes.

In Windows, you have 15 different versions of read() with sockets and 
files and pipes all having strange special cases and special system calls. 
That's not the UNIX way. It should be just a read(), and then people can 
use general libraries and treat all sources the same.

For example, the main select/poll/epoll loop may be the one doing all the 
reading, and then pass off full buffers only to the individual per-fd 
action routines. And that kind of model really very fundamentally wants 
an fd to be an fd to be an fd - not some file descriptors need 
'read_from_sigfd()', and some file descriptors need 'read()', and some 
file descriptors need 'recvmsg()' etc.

So I think you should get rid of signalfd_dequeue(), and just replace it 
with a read() function.

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


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Michal Piotrowski

On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:

At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:

  Also, it'd be helpful if you compare
  /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
  patch.  This reveals which register bits differ actually.

 a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

Just to make sure: it means that a2.txt is a working one and the
anoter is non-working, right?


Right.




Takashi



Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: Problem with libata-pata, ATAPI DVD reader and a copy-protected audio cd

2007-03-08 Thread GhePeU
Il giorno gio, 08/03/2007 alle 17.07 +, Alan Cox ha scritto:
  Well, it happened again, with a different cd, and this time I never
  started the player: hal/g-v-m tried to access the CD and now my driver
  is in PIO2 mode and pretty much unusable. Is there a way to fix this
  without rebooting?
 
 Hard to tell. If it happens again then a dmesg after it misbehaves and
 an lspci -vxx might provide enough information to begin to debug it.
 
 Alan

I posted these informations in my first message, however:

This is the output related to my controllers during the boot:

SCSI subsystem initialized
libata version 2.00 loaded.
sata_nv :00:07.0: version 3.2
sata_nv :00:07.0: Using ADMA mode
ata1: SATA max UDMA/133 cmd 0xF0804480 ctl 0xF08044A0 bmdma 0xD400 irq
16
ata2: SATA max UDMA/133 cmd 0xF0804580 ctl 0xF08045A0 bmdma 0xD408 irq
16
scsi0 : sata_nv
ata1: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata1.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 31/32)
ata1.00: ata1: dev 0 multi count 16
ata1.00: configured for UDMA/133
scsi 0:0:0:0: Direct-Access ATA  WDC WD1600JS-22N 10.0 PQ: 0
ANSI: 5
ata1: bounce limit 0x, segment boundary 0x, hw
segs 61
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB)
sda: Write Protect is off
sda: Mode Sense: 00 3a 00 00
SCSI device sda: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sda: sda1 sda2  sda5 sda6 sda7 sda8 sda9 
sd 0:0:0:0: Attached scsi disk sda
sd 0:0:0:0: Attached scsi generic sg0 type 0
sata_nv :00:08.0: Using ADMA mode
ata3: SATA max UDMA/133 cmd 0xF0806480 ctl 0xF08064A0 bmdma 0xC000 irq
17
ata4: SATA max UDMA/133 cmd 0xF0806580 ctl 0xF08065A0 bmdma 0xC008 irq
17
scsi2 : sata_nv
ata3: SATA link down (SStatus 0 SControl 300)
scsi3 : sata_nv
ata4: SATA link down (SStatus 0 SControl 300)
pata_amd :00:06.0: version 0.2.7
ata5: PATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0xE800 irq 14
ata6: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xE808 irq 15
scsi4 : pata_amd
ata5.00: ATA-6, max UDMA/100, 156301488 sectors: LBA 
ata5.00: ata5: dev 0 multi count 16
ata5.01: ATA-5, max UDMA/133, 78177792 sectors: LBA 
ata5.01: ata5: dev 1 multi count 16
ata5.00: configured for UDMA/100
ata5.01: configured for UDMA/133
scsi5 : pata_amd
ata6.00: ATAPI, max UDMA/66
ata6.01: ATAPI, max UDMA/33
ata6.00: configured for UDMA/66
ata6.01: configured for UDMA/33
scsi 4:0:0:0: Direct-Access ATA  WDC WD800JB-00FM 13.0 PQ: 0
ANSI: 5
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sdb: 156301488 512-byte hdwr sectors (80026 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sdb: sdb1 sdb2  sdb5 sdb6 sdb7 sdb8 
sd 4:0:0:0: Attached scsi disk sdb
sd 4:0:0:0: Attached scsi generic sg1 type 0
scsi 4:0:1:0: Direct-Access ATA  MAXTOR 6L040J2   A93. PQ: 0
ANSI: 5
SCSI device sdc: 78177792 512-byte hdwr sectors (40027 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
SCSI device sdc: 78177792 512-byte hdwr sectors (40027 MB)
sdc: Write Protect is off
sdc: Mode Sense: 00 3a 00 00
SCSI device sdc: write cache: enabled, read cache: enabled, doesn't
support DPO or FUA
sdc: sdc1
sd 4:0:1:0: Attached scsi disk sdc
sd 4:0:1:0: Attached scsi generic sg2 type 0
scsi 5:0:0:0: CD-ROMPIONEER  DVD-RW  DVR-111D 1.23 PQ: 0
ANSI: 5
sr0: scsi3-mmc drive: 40x/40x writer cd/rw xa/form2 cdda tray
Uniform CD-ROM driver Revision: 3.20
sr 5:0:0:0: Attached scsi CD-ROM sr0
sr 5:0:0:0: Attached scsi generic sg3 type 5
scsi 5:0:1:0: CD-ROMTOSHIBA  DVD-ROM SD-M1612 1806 PQ: 0
ANSI: 5
sr1: scsi3-mmc drive: 40x/48x cd/rw xa/form2 cdda tray
sr 5:0:1:0: Attached scsi CD-ROM sr1
sr 5:0:1:0: Attached scsi generic sg4 type 5



This is the dmesg output due to the error. This is with the Enhanced CD:

ata6.01: qc timeout (cmd 0xa0)
ata6.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata6.01: (BMDMA stat 0x65)
ata6.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x28 data
16384 in
 res 51/51:03:00:00:00/00:00:00:00:00/b0 Emask 0x5 (timeout)
ata6: soft resetting port
ata6.00: configured for UDMA/66
ata6.01: configured for UDMA/33
ata6: EH complete
ata6.01: qc timeout (cmd 0xa0)
ata6.01: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata6.01: (BMDMA stat 0x65)
ata6.01: cmd a0/01:00:00:00:00/00:00:00:00:00/b0 tag 0 cdb 0x28 data
16384 in
 res 51/51:03:00:00:00/00:00:00:00:00/b0 Emask 0x5 (timeout)
ata6: soft 

Re: Request change in behaviour of capability inheritance.

2007-03-08 Thread Casey Schaufler

--- [EMAIL PROTECTED] wrote:

 I think that the current behaviour of capability
 inheritance across exec()
 is not optimal.
 
 The current behaviour consists in all effective and
 permitted capabilities
 are cleared across a exec(). This is because it
 seems to be intended that
 in the future the executable files have a set of
 allowed and forced
 capabilities.

File based capabilities are the same
effective, permitted, and inheritable
sets that the process has. Unless the
thinking has shifted over the last couple
weeks (it happens from time to time)
the inheritable set is what you're
missing.



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: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Takashi Iwai
At Thu, 8 Mar 2007 17:26:48 +0100,
Michal Piotrowski wrote:
 
 On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:
  At Thu, 08 Mar 2007 16:42:26 +0100,
  Michal Piotrowski wrote:
  
   Takashi Iwai napisał(a):
Or, does it happen if you play a real 5.1 channel file?
(for example, try speaker-test -c6)
  
   It doesn't work for me on both kernels.
 
  Pass -Dplug:surround51 to speaker-test in addition.
 
 It still doesn't work (at least on clean 2.6.21-rc3).

That's expected.  But it should work with the fixed kernel.
Let me know if it still doesn't work with the patched kernel.


thanks,

Takashi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Davide Libenzi
On Thu, 8 Mar 2007, Linus Torvalds wrote:

 You missed David's worry, I think.
 
 Not only is POLLIN potentially an edge event (depending on the interface 
 you use to fetch it), but even as a level-triggered one you generally want 
 to read as much as possible per POLLIN event, and go back to the event 
 loop only when you get EAGAIN.
 
 So that's in addition to the read/signal race with other 
 threads/processes.
 
 You solved it by having a separate system call, but since it's a regular 
 file descriptor, why have a new system call at all, and not just make it 
 be a read()? In which case you definitely want O_NONBLOCK support.
 
 The UNIX philosophy is often quoted as everything is a file, but that 
 really means everything is a stream of bytes.
 
 In Windows, you have 15 different versions of read() with sockets and 
 files and pipes all having strange special cases and special system calls. 
 That's not the UNIX way. It should be just a read(), and then people can 
 use general libraries and treat all sources the same.
 
 For example, the main select/poll/epoll loop may be the one doing all the 
 reading, and then pass off full buffers only to the individual per-fd 
 action routines. And that kind of model really very fundamentally wants 
 an fd to be an fd to be an fd - not some file descriptors need 
 'read_from_sigfd()', and some file descriptors need 'read()', and some 
 file descriptors need 'recvmsg()' etc.
 
 So I think you should get rid of signalfd_dequeue(), and just replace it 
 with a read() function.

The reason for the special function, was not to provide a non-blocking 
behaviour with zero timeout (that just a side effect), but to read the 
siginfo. I was all about using read(2) (and v1 used it), but when you have 
to transfer complex structures over it, it becomes hell. How do you 
cleanly compat over a f_op-read callback for example?



- Davide


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


Networking Question [ot]

2007-03-08 Thread Marc Perkel
This may be a little off topic but I know there's
people here that can give me a quick answer.

I'm running Fedora Core 6 and I have two blocks of IP
addresses on eth0.

69.50.231.0/28
69.50.231.128/26

Do I need to set some kind of static route so that IPs
in one set can talk to the other? If so - how do I do
that?

Thanks in advance.



 

Food fight? Enjoy some healthy debate 
in the Yahoo! Answers Food  Drink QA.
http://answers.yahoo.com/dir/?link=listsid=396545367
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: 2.6.21-rc3-mm1

2007-03-08 Thread Dave Jones
On Thu, Mar 08, 2007 at 09:50:43AM -0500, John W. Linville wrote:
  On Wed, Mar 07, 2007 at 08:18:39PM -0800, Andrew Morton wrote:
   By removing NET_RADIO, these changes pave the way to making wireless
   extensions optional when cfg80211 can fully take over for some 
  drivers
   and you don't have any older drivers that still require wext.
  
  Honestly, I'm tempted to add the pre-802.11 stuff to the features
  removal list.  I wonder if any of it still actually works...

FWIW, I've built these drivers in Fedora for aeons, and never had a single
bug filed against them. Either they're perfect, or no-one has that junk
any more.  I should turn them off for a build and see if anyone complains :)

Dave

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


Re: Kernel threads

2007-03-08 Thread Oleg Nesterov
Andrew Morton wrote:

  On Tue, 6 Mar 2007 11:03:48 -0500 linux-os \(Dick Johnson\) [EMAIL 
  PROTECTED] wrote:
 
  In linux-2.6.16.24, there is a problem with kernel threads
  and the aic79xx.c driver.
 
  When nash is executing /initrd/linuxrc in the initial RAM disk
  during boot, it will be installing drivers. One driver, aic79xx.c
  creates some kernel threads that will exit after the initialization
  procedure. Actually the number of tasks depends upon the number
  of disks found as the driver spawns these tasks so initialization
  can occur in the background. The kernel tasks have been 'parented'
  to init. This may be fine for the real init, but nash and other
  shells receive the SIGCHLD signal and think that the fork()/exec()
  they have executed is complete. This makes nash insert drivers
  when the needed previous ones have not yet initialized. Also, when
  booting a shell, the signals from the exiting kernel tasks confuse
  it.

 ug.  I've always disliked the kernel's dependence upon init to reap exitted
 kernel threads.  It Just Seems Wrong.

Yes. It is ugly to kick init to reap the kernel thread. I was going to
do this change a long ago, but I don't have time to do even a minimal
testing now.

reparent_to_init() expects that thread_group_empty() == true anyway,
we can set -exit_signal = -1 and make this thread invisible to init.

Roland, what do you think?

Oleg.

--- WQ/kernel/exit.c~rti2007-02-18 22:56:49.0 +0300
+++ WQ/kernel/exit.c2007-03-08 19:26:39.0 +0300
@@ -276,8 +276,8 @@ static void reparent_to_init(void)
current-parent = child_reaper(current);
add_parent(current);
 
-   /* Set the exit signal to SIGCHLD so we signal init on exit */
-   current-exit_signal = SIGCHLD;
+   /* make the task autoreap */
+   current-exit_signal = -1;
 
if (!has_rt_policy(current)  (task_nice(current)  0))
set_user_nice(current, 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/


[QUESTION] outl and writel endianity

2007-03-08 Thread Jiri Slaby

Hi.

If I use outl everything seems to be OK. Is there any difference in endianity 
between outl and writel (or iowrite32, which calls writel, I guess).


When I do
outl(val, p-ibase + 4*off);
everyhting is OK, but when I do
writel(val, p-iaddr + off);
bad value is written unless I use cpu_to_be32(val) (or swap32).

this is what p struct contains:
u32 __iomem *iaddr;
unsigned long ibase;
and this, how it is initialized:
p-ibase = pci_resource_start(pdev, 2);
p-iaddr = pci_iomap(pdev, 2, 0);

What's the proper use of this? iowrite32be seems to work too.

thanks,
--
http://www.fi.muni.cz/~xslaby/Jiri Slaby
faculty of informatics, masaryk university, brno, cz
e-mail: jirislaby gmail com, gpg pubkey fingerprint:
B674 9967 0407 CE62 ACC8  22A0 32CC 55C3 39D4 7A7E
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][Patch 1/6] integrity: new hooks

2007-03-08 Thread Chris Wright
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
 +static int dummy_inode_setxattr(struct dentry *dentry, char *name, void 
 *value,
 + size_t size, int flags)
 +{
 + if (!strncmp(name, XATTR_SECURITY_PREFIX,
 +  sizeof(XATTR_SECURITY_PREFIX) - 1) 
 + !capable(CAP_SYS_ADMIN))
 + return -EPERM;
 + return 0;
 +}

Hold on, what is all this?  Duplication of all of this code is a no go.

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


Re: [patch 2/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Michael K. Edwards

On 3/8/07, Davide Libenzi davidel@xmailserver.org wrote:

The reason for the special function, was not to provide a non-blocking
behaviour with zero timeout (that just a side effect), but to read the
siginfo. I was all about using read(2) (and v1 used it), but when you have
to transfer complex structures over it, it becomes hell. How do you
cleanly compat over a f_op-read callback for example?


Make it a netlink socket and fetch your structures using recvmsg().
siginfo_t belongs in ancillary data.

The UNIX philosophy is everything's a file.  The Berkeley philosophy
is everything's a socket, except for files, which are feeble
mini-sockets.  I'd go with the Berkeley crowd here.

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


Re: [PATCH] chaostables

2007-03-08 Thread Jan Engelhardt


(I suspect a mailserver issue on my side, since I did not receive the 
replies from Alan or Patrick. But lkml.org has them, so I will be 
replying to both them there.)

On Mar 8 2007 09:55, James Morris wrote:
On Thu, 8 Mar 2007, Alan Cox wrote:

 Any chance of tweaking the name - it's just there is/was a chaosnet 
 protocol/network system and you don't want people to assume that 
 since its a chaosfilter its for chaosnet ?

That's exactly what I thought it was from the subject line.

Suggest something. (And then convince everyone who already set 
chaostables in stone to use the new name, namely search engines, 
bloggers, LWN, openwrt.) I don't think anyone seriously uses chaosnet 
nowadays. And just because there is a quicktables project does not 
mean there is a quick protocol filter.

Also note that the word 'chaostables' does not even appear in the patch, 
though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
can safely assume that CHAOS does what it says - make fun of nmap.


 Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
 @@ -0,0 +1,184 @@
 +
 +static unsigned int xt_chaos_target(struct sk_buff **pskb,
 +const struct net_device *in, const struct net_device *out,
 +unsigned int hooknum, const struct xt_target *target, const void 
 *targinfo)
 +{
 +/* Equivalent to:
 + * -A chaos -m statistic --mode random --probability \
 + * $reject_percentage -j REJECT --reject-with host-unreach;
 + * -A chaos -m statistic --mode random --probability \
 + * $delude_percentage -j DELUDE;
 + * -A chaos -j DROP;
 + */

What does this do that can't be done by simply adding those individual 
rules?

It wraps it all up, reducing the overall number of rules and user 
chains required in the filtering tables to implement the wanted logic. 
Reducing the number of filtering rules also reduces the time process a 
packet. These two are, in my opinion, a good thing.

Take xt_portscan as an example, which would require a minimum of 23 
filtering rules (which cannot reproduce the module's action in its 
fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
a single packet, repeatedly checking for -p tcp, i.e. calling into 
xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
are never examined in xt_portscan.


 Index: linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?

Looking only at TCP,
REJECT sends a RST for any packet (if requested), or ICMP otherwise.
DELUDE sends a SYN-ACK on SYN, otherwise RST.
(And TARPIT, for reference, keeps the connection open anytime. Its code
is also quite a replication of REJECT.)

If you think it is better to merge the respond-with-SYNACK into REJECT 
rather than having DELUDE, say so.


 Index: linux-2.6.21-rc3/net/netfilter/xt_portscan.c
 ===
 --- /dev/null
 +++ linux-2.6.21-rc3/net/netfilter/xt_portscan.c

We already have the psd match for years, but decided against merging it.

On what basis? As far as I flew over psd's code, it uses a heuristic 
like how often did that client recently connect for match decision. 
(P2P clients randomly port knocking, anyone?) I would not think of that 
as a reliable way to tell portscans either. However, half-open TCP 
connect for example is a more clear action to define a portscan.



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


Re: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Chris Wright
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
 + integrity_d_instantiate(entry, inode);
   security_d_instantiate(entry, inode);

 + integrity_d_instantiate(entry, inode);
   security_d_instantiate(entry, inode);

   spin_unlock(dcache_lock);
 + integrity_d_instantiate(new, inode);
   security_d_instantiate(new, inode);
   d_rehash(dentry);

   d_move(new, dentry);
 + integrity_d_instantiate(dentry, inode);
   security_d_instantiate(dentry, inode);
   d_rehash(dentry);

   if (actual == dentry) {
 + integrity_d_instantiate(dentry, inode);
   security_d_instantiate(dentry, inode);


   file-f_op-release(inode, file);
   security_file_free(file);
 + integrity_file_free(file);


   security_file_free(file);
 + integrity_file_free(file);


   if (security_inode_alloc(inode)) {
...
 + if (integrity_inode_alloc(inode)) {
 + if (inode-i_sb-s_op-destroy_inode)
 + inode-i_sb-s_op-destroy_inode(inode);

   security_inode_free(inode);
 + integrity_inode_free(inode);

   error = security_inode_setxattr(dentry, name, value, size, flags);
   if (error)
   goto out;
 +
 + error = integrity_inode_setxattr(dentry, name, value, size, flags);

   fsnotify_xattr(dentry);
 + integrity_inode_post_setxattr(dentry, name);
   security_inode_post_setxattr(dentry, name, value,

I know there's some slightly different goals, but this just doesn't make
sense.  Need to get back to defining and expressing just the differences.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


swsusp: platform notifications not properly undone in case of error

2007-03-08 Thread Pavel Machek
Hi!


Using IPI No-Shortcut mode
swsusp: Resume From Partition /dev/sda1
PM: Checking swsusp image.
swsusp: Signature found, resuming
PM: Preparing processes for restore.
Stopping tasks ... done.
PM: Reading swsusp image.
Loading image data pages (125285 pages) ... 3swsusp: Resume
mismatch: version
Read 501140 kbytes in 0.01 seconds (50114.00 MB/s)
swsusp: Error -1 resuming
PM: Restore failed, recovering.
Restarting tasks ... done.
PM: Resume from disk failed.
md: Autodetecting RAID arrays.

...and machine boots, but moon icon keeps blinking.
Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) 
http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [Patch 1/2] add for_each_substring() and match_substring()

2007-03-08 Thread Bastian Blank
On Tue, Mar 06, 2007 at 08:19:23PM +0100, Martin Peschke wrote:
 +char *match_to(const char *cs, const char *ct)
 +{
 + char *delim = strpbrk(cs, ct);
 + if (delim)
 + return delim;
 + else if (*cs != '\0')
 + return (char *)(cs + strlen(cs));

This disallows the use of match_to with a real constant char array,
please remove the const from the prototyp.

Bastian

-- 
Get back to your stations!
We're beaming down to the planet, sir.
-- Kirk and Mr. Leslie, This Side of Paradise,
   stardate 3417.3
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread Daniel Jacobowitz
On Thu, Mar 08, 2007 at 04:08:52PM +, Christoph Hellwig wrote:
 No, no no.  We should never export PAGE_SIZE.  We might export NBPG
 as deprecated symbol for gdb if it really needs it, but that should
 happen only on a.out systems, and it it should be a true constant,
 not depending on PAGE_SIZE.
 
 I've Cc'ed the gdb list on whether they have any comments on this
 issue.

Sounds reasonable.  I do not believe that GDB has any dependence on
PAGE_SIZE; bfd (i.e. both gdb and binutils) use NBPG on a large number
of systems.  Looks like i386, alpha, m68k, s390, vax - but don't quote
me on that, I had to guess from the configure script.

-- 
Daniel Jacobowitz
CodeSourcery
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] tty: Turn on arbitary baud rate ioctls for i386 platform

2007-03-08 Thread Alan Cox
Adds the needed TCGETS2/TCSETS2 ioctl calls, structures, defines and the
like. Tested against the test suite and passes. Other platforms should need
roughly the same change.

Signed-off-by: Alan Cox [EMAIL PROTECTED]

diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/ioctls.h 
linux-2.6.21-rc2-mm2/include/asm-i386/ioctls.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/ioctls.h  2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/ioctls.h  2007-03-08 
13:24:39.816743656 +
@@ -47,6 +47,10 @@
 #define TIOCSBRK   0x5427  /* BSD compatibility */
 #define TIOCCBRK   0x5428  /* BSD compatibility */
 #define TIOCGSID   0x5429  /* Return the session ID of FD */
+#define TCGETS2_IOR('T',0x2A, struct termios2)
+#define TCSETS2_IOW('T',0x2B, struct termios2)
+#define TCSETSW2   _IOW('T',0x2C, struct termios2)
+#define TCSETSF2   _IOW('T',0x2D, struct termios2)
 #define TIOCGPTN   _IOR('T',0x30, unsigned int) /* Get Pty Number (of 
pty-mux device) */
 #define TIOCSPTLCK _IOW('T',0x31, int)  /* Lock/unlock Pty */
 
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termbits.h 
linux-2.6.21-rc2-mm2/include/asm-i386/termbits.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termbits.h2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/termbits.h2007-03-07 
15:45:32.0 +
@@ -17,6 +17,17 @@
cc_t c_cc[NCCS];/* control characters */
 };
 
+struct termios2 {
+   tcflag_t c_iflag;   /* input mode flags */
+   tcflag_t c_oflag;   /* output mode flags */
+   tcflag_t c_cflag;   /* control mode flags */
+   tcflag_t c_lflag;   /* local mode flags */
+   cc_t c_line;/* line discipline */
+   cc_t c_cc[NCCS];/* control characters */
+   speed_t c_ispeed;   /* input speed */
+   speed_t c_ospeed;   /* output speed */
+};
+
 struct ktermios {
tcflag_t c_iflag;   /* input mode flags */
tcflag_t c_oflag;   /* output mode flags */
@@ -129,6 +140,7 @@
 #define HUPCL  0002000
 #define CLOCAL 0004000
 #define CBAUDEX 001
+#define   BOTHER  001
 #defineB57600 0010001
 #define   B115200 0010002
 #define   B230400 0010003
diff -u --new-file --recursive --exclude-from /usr/src/exclude 
linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termios.h 
linux-2.6.21-rc2-mm2/include/asm-i386/termios.h
--- linux.vanilla-2.6.21-rc2-mm2/include/asm-i386/termios.h 2007-03-06 
23:06:31.0 +
+++ linux-2.6.21-rc2-mm2/include/asm-i386/termios.h 2007-03-06 
17:00:58.0 +
@@ -81,8 +81,10 @@
copy_to_user((termio)-c_cc, (termios)-c_cc, NCC); \
 })
 
-#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, 
sizeof(struct termios))
-#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct 
termios))
+#define user_termios_to_kernel_termios(k, u) copy_from_user(k, u, 
sizeof(struct termios2))
+#define kernel_termios_to_user_termios(u, k) copy_to_user(u, k, sizeof(struct 
termios2))
+#define user_termios_to_kernel_termios_1(k, u) copy_from_user(k, u, 
sizeof(struct termios))
+#define kernel_termios_to_user_termios_1(u, k) copy_to_user(u, k, 
sizeof(struct termios))
 
 #endif /* __KERNEL__ */
 
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Robin Getz
On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
 2007/3/7, Robin Getz [EMAIL PROTECTED]:
  Right - so the question is where to manage the default state? I was
  thinking in the resource might be a good idea, but there isn't really a
  good place for it. (You could re-use some bits if flags, but I think that
  would not be a good idea).

 /proc/tty/driver/uartN/settings?


That would let you change things are run time, but the problem is at boot 
time. A default setting needs to be set, so when things initialize, and proc 
does not exist yet, it is still set properly...

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Russell King
On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
 On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
  2007/3/7, Robin Getz [EMAIL PROTECTED]:
   Right - so the question is where to manage the default state? I was
   thinking in the resource might be a good idea, but there isn't really a
   good place for it. (You could re-use some bits if flags, but I think that
   would not be a good idea).
 
  /proc/tty/driver/uartN/settings?
 
 
 That would let you change things are run time, but the problem is at boot 
 time. A default setting needs to be set, so when things initialize, and proc 
 does not exist yet, it is still set properly...

I disagree.  proc does not exist yet - the only time that applies is
long before userspace as active.

As I've said already, having a console on the same port as your application
program is just asking for trouble.  All bets are off - the kernel _will_
corrupt your data stream in random places.

Don't do it - it will _NEVER_ be reliable.

Never, ever, mix kernel consoles with application serial ports.

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Carl-Daniel Hailfinger
Hi,

On 08.03.2007 14:48, Russell King wrote:
 As I've said already, having a console on the same port as your application
 program is just asking for trouble.  All bets are off - the kernel _will_
 corrupt your data stream in random places.
 
 Don't do it - it will _NEVER_ be reliable.
 
 Never, ever, mix kernel consoles with application serial ports.

Unless you want two machines to monitor each other via serial console and
each of them has only one serial port. It's not perfect, but it works well
enough despite all claims to the contrary.

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Russell King
On Thu, Mar 08, 2007 at 03:16:08PM +0100, Carl-Daniel Hailfinger wrote:
 Hi,
 
 On 08.03.2007 14:48, Russell King wrote:
  As I've said already, having a console on the same port as your application
  program is just asking for trouble.  All bets are off - the kernel _will_
  corrupt your data stream in random places.
  
  Don't do it - it will _NEVER_ be reliable.
  
  Never, ever, mix kernel consoles with application serial ports.
 
 Unless you want two machines to monitor each other via serial console and
 each of them has only one serial port. It's not perfect, but it works well
 enough despite all claims to the contrary.

That's fine - you're not sending application specific data which could
be corrupted by an inopportune kernel message.

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Oleksiy Kebkal

2007/3/8, Russell King [EMAIL PROTECTED]:

On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
 On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
  2007/3/7, Robin Getz [EMAIL PROTECTED]:
   Right - so the question is where to manage the default state? I was
   thinking in the resource might be a good idea, but there isn't really a
   good place for it. (You could re-use some bits if flags, but I think that
   would not be a good idea).
 
  /proc/tty/driver/uartN/settings?
 

 That would let you change things are run time, but the problem is at boot
 time. A default setting needs to be set, so when things initialize, and proc
 does not exist yet, it is still set properly...

I disagree.  proc does not exist yet - the only time that applies is
long before userspace as active.

As I've said already, having a console on the same port as your application
program is just asking for trouble.  All bets are off - the kernel _will_
corrupt your data stream in random places.

Don't do it - it will _NEVER_ be reliable.

Never, ever, mix kernel consoles with application serial ports.


Ok. I understand now one of the sources of misunderstanding. I don't
want to mix console and application serial port. It was a question,
Myke Frisinger initially asked. I would switch on/off console
depending on some external control action if possible...

The other problem is how to open serial port with correct settings
_after_ booting. In this case /proc could be applicable, isn't it?

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Oleksiy Kebkal

2007/3/8, Russell King [EMAIL PROTECTED]:

On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
 On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
  2007/3/7, Robin Getz [EMAIL PROTECTED]:
   Right - so the question is where to manage the default state? I was
   thinking in the resource might be a good idea, but there isn't really a
   good place for it. (You could re-use some bits if flags, but I think that
   would not be a good idea).
 
  /proc/tty/driver/uartN/settings?
 

 That would let you change things are run time, but the problem is at boot
 time. A default setting needs to be set, so when things initialize, and proc
 does not exist yet, it is still set properly...

I disagree.  proc does not exist yet - the only time that applies is
long before userspace as active.

As I've said already, having a console on the same port as your application
program is just asking for trouble.  All bets are off - the kernel _will_
corrupt your data stream in random places.

Don't do it - it will _NEVER_ be reliable.

Never, ever, mix kernel consoles with application serial ports.

--
Russell King
 Linux kernel2.6 ARM Linux   - http://www.arm.linux.org.uk/
 maintainer of:




--
EvoLogics GmbH
Blumenstraße 49, 10243 Berlin

FE Labor Bionik
Ackerstraße 76, 13355 Berlin

Tel.: + 49- (0) 30- 46 06 82 26
Fax:  + 49- (0) 30- 46 06 82 15

[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: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Russell King
On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
 2007/3/8, Russell King [EMAIL PROTECTED]:
 On Thu, Mar 08, 2007 at 08:44:31AM -0500, Robin Getz wrote:
  On Wed 7 Mar 2007 16:30, Oleksiy Kebkal pondered:
   2007/3/7, Robin Getz [EMAIL PROTECTED]:
Right - so the question is where to manage the default state? I was
thinking in the resource might be a good idea, but there isn't 
 really a
good place for it. (You could re-use some bits if flags, but I think 
 that
would not be a good idea).
  
   /proc/tty/driver/uartN/settings?
  
 
  That would let you change things are run time, but the problem is at boot
  time. A default setting needs to be set, so when things initialize, and 
 proc
  does not exist yet, it is still set properly...
 
 I disagree.  proc does not exist yet - the only time that applies is
 long before userspace as active.
 
 As I've said already, having a console on the same port as your application
 program is just asking for trouble.  All bets are off - the kernel _will_
 corrupt your data stream in random places.
 
 Don't do it - it will _NEVER_ be reliable.
 
 Never, ever, mix kernel consoles with application serial ports.
 
 Ok. I understand now one of the sources of misunderstanding. I don't
 want to mix console and application serial port.

It's not a misunderstanding if you realise that email is threaded and
you _follow_ the individual threads.  Robin has a similar concern to
you but _additionally_ wants something that you don't.

So really to remove the confusion from this discussion you should
avoid trying to correct replies to Robin's emails.

 The other problem is how to open serial port with correct settings
 _after_ booting. In this case /proc could be applicable, isn't it?

Doubt it with todays opinions about /proc contents.  Probably more
appropriate in sysfs, if someone can be bothered to do the work
required to properly integrate tty and sysfs.

Don't look at me; I'm not doing very much with serial anymore.

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


Re: should RTS init in serial core be tied to CRTSCTS

2007-03-08 Thread Oleksiy Kebkal

2007/3/8, Russell King [EMAIL PROTECTED]:

On Thu, Mar 08, 2007 at 03:23:49PM +0100, Oleksiy Kebkal wrote:
 Ok. I understand now one of the sources of misunderstanding. I don't
 want to mix console and application serial port.

It's not a misunderstanding if you realise that email is threaded and
you _follow_ the individual threads.  Robin has a similar concern to
you but _additionally_ wants something that you don't.

So really to remove the confusion from this discussion you should
avoid trying to correct replies to Robin's emails.


On some stages it was very close... Anyway, sorry...


 The other problem is how to open serial port with correct settings
 _after_ booting. In this case /proc could be applicable, isn't it?

Doubt it with todays opinions about /proc contents.  Probably more
appropriate in sysfs, if someone can be bothered to do the work
required to properly integrate tty and sysfs.

Don't look at me; I'm not doing very much with serial anymore.


I don't. :) Surely I'm not experienced kernel developer, but I would
like to do it. :)
The only purpose of my remarks and questions was to find the best
origin of force
to solve this problem. And all remarks in this thread are very valuable for me.

-Oleksiy
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] tty: Turn on arbitary baud rate ioctls for i386 platform

2007-03-08 Thread Arjan van de Ven
On Thu, 2007-03-08 at 14:44 +, Alan Cox wrote:
 Adds the needed TCGETS2/TCSETS2 ioctl calls, structures, defines and the
 like. Tested against the test suite and passes. Other platforms should need
 roughly the same change.


should this then really be in include/asm/* ? If everyone needs the same
change I'd think it should go into include/linux/* somewhere.
(if the answer is the old ioctls were arch specific... maybe the new
ones can fix that defect ;)


-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] tty: Turn on arbitary baud rate ioctls for i386 platform

2007-03-08 Thread Andreas Schwab
Arjan van de Ven [EMAIL PROTECTED] writes:

 should this then really be in include/asm/* ? If everyone needs the same
 change I'd think it should go into include/linux/* somewhere.

How about asm-generic/ioctls.h?  asm/ioctls.h is one of the few ABI
headers for glibc.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] tty: Turn on arbitary baud rate ioctls for i386 platform

2007-03-08 Thread Alan Cox
On Thu, 08 Mar 2007 06:39:47 -0800
Arjan van de Ven [EMAIL PROTECTED] wrote:

 On Thu, 2007-03-08 at 14:44 +, Alan Cox wrote:
  Adds the needed TCGETS2/TCSETS2 ioctl calls, structures, defines and the
  like. Tested against the test suite and passes. Other platforms should need
  roughly the same change.
 
 
 should this then really be in include/asm/* ? If everyone needs the same
 change I'd think it should go into include/linux/* somewhere.

It should be in include/asm. There are a whole range of different
variations of the structures and ioctl numbering in use on different
platforms so it does not trivially unify alas.

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: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-08 Thread Srivatsa Vaddagiri
On Thu, Mar 08, 2007 at 01:50:01PM +1300, Sam Vilain wrote:
 7. resource namespaces

It should be. Imagine giving 20% bandwidth to a user X. X wants to
divide this bandwidth further between multi-media (10%), kernel
compilation (5%) and rest (5%). So,

 Is the subservient namespace's resource usage counting against ours too?

Yes, the resource usage of children should be accounted when capping
parent resource usage.

 Can we dynamically alter the subservient namespace's resource allocations?

Should be possible yes. That lets user X completely manage his
allocation among whatever sub-groups he creates.

 So let's bring this back to your patches. If they are providing
 visibility of ns_proxy, then it should be called namesfs or some such.

The patches should give visibility to both nsproxy objects (by showing
what tasks share the same nsproxy objects and letting tasks move across
nsproxy objects if allowed) and the resource control objects pointed to
by nsproxy (struct cpuset, struct cpu_limit, struct rss_limit etc).

 It doesn't really matter if processes disappear from namespace
 aggregates, because that's what's really happening anyway. The only
 problem is that if you try to freeze a namespace that has visibility of
 things at this level, you might not be able to reconstruct the
 filesystem in the same way. This may or may not be considered a problem,
 but open filehandles and directory handles etc surviving a freeze/thaw
 is part of what we're trying to achieve. Then again, perhaps some
 visibility is better than none for the time being.
 
 If they are restricted entirely to resource control, then don't use the
 nsproxy directly - use the structure or structures which hang off the
 nsproxy (or even task_struct) related to resource control.

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


Re: [PATCH 0/2] resource control file system - aka containers on top of nsproxy!

2007-03-08 Thread Srivatsa Vaddagiri
On Wed, Mar 07, 2007 at 04:16:00PM -0700, Eric W. Biederman wrote:
 I think implementation wise this tends to make sense.
 However it should have nothing to do with semantics.
 
 If we have a lot of independent resource controllers.  Placing the
 pointer to their data structures directly in nsproxy instead of in
 task_struct sounds like a reasonable idea 

Thats what the rcfs patches do.

 but it should not be user visible.

What do you mean by this? We do want the user to be able to manipulate
the resource parameters (which are normally present in the data
structures/resource objects pointed to by nsproxy -
nsproxy-ctlr_data[])

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


Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4

2007-03-08 Thread Christoph Lameter
On Thu, 8 Mar 2007, Mel Gorman wrote:

 On x86_64, it completed successfully and looked reliable. There was a 5%
 performance loss on kernbench and aim9 figures were way down. However, with
 slub_debug enabled, I would expect that so it's not a fair comparison
 performance wise. I'll rerun the tests without debug and see what it looks
 like if you're interested and do not think it's too early to worry about
 performance instead of clarity. This is what I have for bl6-13 (machine
 appears on test.kernel.org so additional details are there).

No its good to start worrying about performance now. There are still some 
performance issues to be ironed out in particular on NUMA. I am not sure
f.e. how the reduction of partial lists affect performance.

 IA64 (machine not visible on TKO) curiously did not exhibit the same problems
 on kernbench for Total CPU time which is very unexpected but you can see the
 System CPU times. The AIM9 figures were a bit of an upset but again, I blame
 slub_debug being enabled

This was a single node box? Note that the 16kb page size has a major 
impact on SLUB performance. On IA64 slub will use only 1/4th the locking 
overhead as on 4kb platforms.

 (as an aside, the succes rates for high-order allocations are lower with SLUB.
 Again, I blame slub_debug. I know that enabling SLAB_DEBUG has similar effects
 because of red-zoning and the like)

We have some additional patches here that reduce the max order for some 
allocs. I believe the task_struct gets to be an order 2 alloc with V4,

 Now, the bad news. This exploded on ppc64. It started going wrong early in the
 boot process and got worse. I haven't looked closely as to why yet as there is
 other stuff on my plate but I've included a console log that might be some use
 to you. If you think you have a fix for it, feel free to send it on and I'll
 give it a test.

Hmmm... Looks like something is zapping an object. Try to rerun with 
a kernel compiled with CONFIG_SLAB_DEBUG. I would expect similar results.

 Brought up 4 CPUs
 Node 0 CPUs: 0-3
 mm/memory.c:111: bad pud c50e4480.
 could not vmalloc 20971520 bytes for cache!

Hmmm... a bad pud? I need to look at how the puds are managed on power.

 migration_cost=0,1000
 *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab

An object was overwritten with zeros after it was freed.

 RTAS daemon started
 RTAS: event: 1, Type: Platform Error, Severity: 2
 audit: initializing netlink socket (disabled)
 audit(1173335571.256:1): initialized
 Total HugeTLB memory allocated, 0
 VFS: Disk quotas dquot_6.5.1
 Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
 JFS: nTxBlock = 8192, nTxLock = 65536
 SELinux:  Registering netfilter hooks
 io scheduler noop registered
 io scheduler anticipatory registered (default)
 io scheduler deadline registered
 io scheduler cfq registered
 pci_hotplug: PCI Hot Plug PCI Core version: 0.5
 rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
 rpaphp: Slot [:00:02.2](PCI location=U7879.001.DQD0T7T-P1-C4) registered
 vio_register_driver: driver hvc_console registering
 [ cut here ]
 Badness at mm/slub.c:1701

Someone did a kmalloc(0, ...). Zero sized allocation are not flagged
by SLAB but SLUB does.

 Call Trace:
 [C506B730] [C0011188] .show_stack+0x6c/0x1a0 (unreliable)
 [C506B7D0] [C01EE9F4] .report_bug+0x94/0xe8
 [C506B860] [C038C85C] .program_check_exception+0x16c/0x5f4
 [C506B930] [C00046F4] program_check_common+0xf4/0x100
 --- Exception: 700 at .get_slab+0xbc/0x18c
 LR = .__kmalloc+0x28/0x104
 [C506BC20] [C506BCC0] 0xc506bcc0 (unreliable)
 [C506BCD0] [C00CE2EC] .__kmalloc+0x28/0x104
 [C506BD60] [C022E724] .tty_register_driver+0x5c/0x23c
 [C506BE10] [C0477910] .hvsi_init+0x154/0x1b4
 [C506BEC0] [C0451B7C] .init+0x1c4/0x2f8
 [C506BF90] [C00275D0] .kernel_thread+0x4c/0x68
 mm/memory.c:111: bad pud c5762900.
 mm/memory.c:111: bad pud c5762480.
 [ cut here ]
 kernel BUG at mm/mmap.c:1999!

More page table trouble.

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


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Michal Piotrowski

On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:

At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:

  Also, it'd be helpful if you compare
  /proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
  patch.  This reveals which register bits differ actually.

 a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

 diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
 --- a2.txt  2007-03-08 16:36:47.0 +0100
 +++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 16:36:49.447083597 
+0100
 @@ -56,8 +56,8 @@
  0:6e = 
  0:70 = 
  0:72 = 0004
 -0:74 = 1001
 -0:76 = 64a4
 +0:74 = 1201
 +0:76 = 7ca4
  0:78 = 000c
  0:7a = 
  0:7c = 4144

OK, some wrong bits there.  Could you try the patch below?


Problem fixed. Thanks!

(speaker-test -c6 -Dplug:surround51 is still broken)

Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Takashi Iwai
At Thu, 8 Mar 2007 17:52:43 +0100,
Michal Piotrowski wrote:
 
 On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:
  At Thu, 08 Mar 2007 16:42:26 +0100,
  Michal Piotrowski wrote:
  
Also, it'd be helpful if you compare
/proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
patch.  This reveals which register bits differ actually.
  
   a2.txt is form 2.6.21-rc3 witchout 
   831466f4ad2b5fe23dff77edbe6a7c244435e973
  
   diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
   --- a2.txt  2007-03-08 16:36:47.0 +0100
   +++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 
   16:36:49.447083597 +0100
   @@ -56,8 +56,8 @@
0:6e = 
0:70 = 
0:72 = 0004
   -0:74 = 1001
   -0:76 = 64a4
   +0:74 = 1201
   +0:76 = 7ca4
0:78 = 000c
0:7a = 
0:7c = 4144
 
  OK, some wrong bits there.  Could you try the patch below?
 
 Problem fixed. Thanks!
 
 (speaker-test -c6 -Dplug:surround51 is still broken)

Hm, how about turning off Spread Front To... control and run
speaker-test?


Takashi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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] VFS : Delay the dentry name generation on sockets and pipes.

2007-03-08 Thread Eric Dumazet
Hi Andrew

Could you please put this final version in mm for testing ?

Thank's to all contributors.

[PATCH] VFS : Delay the dentry name generation on sockets and pipes.

1) Introduces a new method in 'struct dentry_operations'. This method called 
d_dname() might be called from d_path() to build a pathname 
for special filesystems. It is called without locks.

Future patches (if we succeed in having one common dentry for all 
pipes/sockets) may need to change prototype of this method, but we now use :
char *d_dname(struct dentry *dentry, char *buffer, int buflen);


2) Use this new method for sockets : No more sprintf() at socket creation. 
This is delayed up to the moment someone does an access to /proc/pid/fd/...

3) Use this new method for pipes : No more sprintf() at pipe creation. This is 
delayed up to the moment someone does an access to /proc/pid/fd/...

A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a 
*nice* speedup on my Pentium(M) 1.6 Ghz :

3.090 s instead of 3.450 s

Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Acked-by: Linus Torvalds [EMAIL PROTECTED]

 Documentation/filesystems/Locking |2 ++
 Documentation/filesystems/vfs.txt |   12 +++-
 fs/dcache.c   |   10 ++
 fs/pipe.c |   15 +--
 include/linux/dcache.h|1 +
 net/socket.c  |   17 ++---
 6 files changed, 43 insertions(+), 14 deletions(-)

--- linux-2.6.21-rc3/include/linux/dcache.h 2007-03-07 17:23:55.0 
+0100
+++ linux-2.6.21-rc3-ed/include/linux/dcache.h  2007-03-08 11:57:41.0 
+0100
@@ -133,6 +133,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)(struct dentry *, char *, int);
 };
 
 /* the dentry parameter passed to d_hash and d_compare is the parent
--- linux-2.6.21-rc3/Documentation/filesystems/vfs.txt  2007-03-08 
10:14:38.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/vfs.txt   2007-03-08 
12:08:56.0 +0100
@@ -827,7 +827,7 @@ This describes how a filesystem can over
 operations. Dentries and the dcache are the domain of the VFS and the
 individual filesystem implementations. Device drivers have no business
 here. These methods may be set to NULL, as they are either optional or
-the VFS uses a default. As of kernel 2.6.13, the following members are
+the VFS uses a default. As of kernel 2.6.22, the following members are
 defined:
 
 struct dentry_operations {
@@ -837,6 +837,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)(struct dentry *, char *, int);
 };
 
   d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -859,6 +860,15 @@ struct dentry_operations {
VFS calls iput(). If you define this method, you must call
iput() yourself
 
+  d_dname: called when the pathname of a dentry should be generated.
+   Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
+   pathname generation. (Instead of doing it when dentry is created,
+   its done only when the path is needed.). Real filesystems probably
+   dont want to use it, because their dentries are present in global
+   dcache hash, so their hash should be an invariant. As no lock is
+   held, d_dname() should not try to modify the dentry itself, unless
+   appropriate SMP safety is used.
+
 Each dentry has a pointer to its parent dentry, as well as a hash list
 of child dentries. Child dentries are basically like files in a
 directory.
--- linux-2.6.21-rc3/Documentation/filesystems/Locking  2007-03-08 
10:29:04.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/Locking   2007-03-08 
12:08:56.0 +0100
@@ -15,6 +15,7 @@ prototypes:
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
 
 locking rules:
none have BKL
@@ -25,6 +26,7 @@ d_compare:no  yes no  
no 
 d_delete:  yes no  yes no
 d_release: no  no  no  yes
 d_iput:no  no  no  yes
+d_dname:   no  no  no  no
 
 --- inode_operations --- 
 prototypes:
--- linux-2.6.21-rc3/fs/dcache.c2007-03-07 17:23:55.0 +0100
+++ linux-2.6.21-rc3-ed/fs/dcache.c 2007-03-08 17:47:04.0 +0100
@@ -1823,6 +1823,16 @@ char * d_path(struct dentry *dentry, str

Re: [patch] epoll use a single inode ...

2007-03-08 Thread Valdis . Kletnieks
On Thu, 08 Mar 2007 08:24:04 +0100, Eric Dumazet said:

 But what is the cost of the conditional branch you added in prefetch(x) ?
 
 if (!x) return;
 
 (correctly predicted or not, but do powerPC have a BTB ?)
 
 About the NULL 'potential problem', maybe we could use a dummy nil (but 
 mapped) object, and use its address in lists, ie compare for nil instead of 
 NULL. This would avoid :
 
 - The conditional test in some prefetch() implementations
 - The potential TLB problem with the NULL value.

You avoid those two, but add the very high likelyhood that a statement of the
form 'if (!x) {}' will creep back in and bug out.  I doubt that changing
the form of a basic C idiom to save a few cycles is worth it, especially when
the (!x) form can be tested without a memory fetch, but (x != nil) may require
fetching 'nil' (remember - the x86 is a very popular chipset, but register
starved - if the loop is any size at all, 'nil' may require a reload each
time around, costing you the win you thought you had


pgpWRgqXbzEAw.pgp
Description: PGP signature


Re: [RFC][Patch 1/6] integrity: new hooks

2007-03-08 Thread Serge E. Hallyn
Quoting Chris Wright ([EMAIL PROTECTED]):
 * Mimi Zohar ([EMAIL PROTECTED]) wrote:
  +static int dummy_inode_setxattr(struct dentry *dentry, char *name, void 
  *value,
  +   size_t size, int flags)
  +{
  +   if (!strncmp(name, XATTR_SECURITY_PREFIX,
  +sizeof(XATTR_SECURITY_PREFIX) - 1) 
  +   !capable(CAP_SYS_ADMIN))
  +   return -EPERM;
  +   return 0;
  +}
 
 Hold on, what is all this?  Duplication of all of this code is a no go.

It's unfortunate, agreed, but

use of LSM as an integrity framework was also a no-go.

Options?

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


Re: Request change in behaviour of capability inheritance.

2007-03-08 Thread rgarcia
I was reading the capabilities(7) man page. I agree with you about the
language. What I am requesting is that for any file without extra
attributes, the inheritable and effective set should be full.

Ramon

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


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Michal Piotrowski

On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:

At Thu, 8 Mar 2007 17:52:43 +0100,
Michal Piotrowski wrote:

 On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:
  At Thu, 08 Mar 2007 16:42:26 +0100,
  Michal Piotrowski wrote:
  
Also, it'd be helpful if you compare
/proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
patch.  This reveals which register bits differ actually.
  
   a2.txt is form 2.6.21-rc3 witchout 
831466f4ad2b5fe23dff77edbe6a7c244435e973
  
   diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
   --- a2.txt  2007-03-08 16:36:47.0 +0100
   +++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 
16:36:49.447083597 +0100
   @@ -56,8 +56,8 @@
0:6e = 
0:70 = 
0:72 = 0004
   -0:74 = 1001
   -0:76 = 64a4
   +0:74 = 1201
   +0:76 = 7ca4
0:78 = 000c
0:7a = 
0:7c = 4144
 
  OK, some wrong bits there.  Could you try the patch below?

 Problem fixed. Thanks!

 (speaker-test -c6 -Dplug:surround51 is still broken)

Hm, how about turning off Spread Front To... control and run
speaker-test?


Now I've got:
rear left as center
rear right as LFE

:)




Takashi



Regards,
Michal

--
Michal K. K. Piotrowski
LTG - Linux Testers Group (PL)
(http://www.stardust.webpages.pl/ltg/)
LTG - Linux Testers Group (EN)
(http://www.stardust.webpages.pl/linux_testers_group_en/)
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: mm snapshot broken-out-2007-03-05-02-22.tar.gz uploaded

2007-03-08 Thread Randy Cushman

Takashi Iwai wrote:

At Thu, 8 Mar 2007 17:52:43 +0100,
Michal Piotrowski wrote:
  

On 08/03/07, Takashi Iwai [EMAIL PROTECTED] wrote:


At Thu, 08 Mar 2007 16:42:26 +0100,
Michal Piotrowski wrote:
  

Also, it'd be helpful if you compare
/proc/asound/card0/codec97#0/ac97#0-0+regs file before and after the
patch.  This reveals which register bits differ actually.
  

a2.txt is form 2.6.21-rc3 witchout 831466f4ad2b5fe23dff77edbe6a7c244435e973

diff -uprN a2.txt /proc/asound/card0/codec97#0/ac97#0-0+regs
--- a2.txt  2007-03-08 16:36:47.0 +0100
+++ /proc/asound/card0/codec97#0/ac97#0-0+regs  2007-03-08 16:36:49.447083597 
+0100
@@ -56,8 +56,8 @@
 0:6e = 
 0:70 = 
 0:72 = 0004
-0:74 = 1001
-0:76 = 64a4
+0:74 = 1201
+0:76 = 7ca4
 0:78 = 000c
 0:7a = 
 0:7c = 4144


OK, some wrong bits there.  Could you try the patch below?
  

Problem fixed. Thanks!

(speaker-test -c6 -Dplug:surround51 is still broken)



Hm, how about turning off Spread Front To... control and run
speaker-test?


Takashi


  

Michal and Takashi,

I've been researching your issue this morning.  I just noticed that your 
exchange had ensued.


I configured my AD1986-based system as closely as I could to match your 
AD1985 mixer settings.  In doing so, I experienced results similar to 
what I'm assuming you described:  Only front channel sound came out of 
the surround and c/lfe jacks.


Here is what I had to change to get the appropriate multichannel sound:

1) The command speaker-test -c6 does not work on my system.  I have to 
use speaker-test -Dsurround51 -c6  (Perhaps this is related to running 
an old version of speaker-test.)


2) I disabled Spread Front to Surround and Center/LFE

The explanation for 2) is this:  There can be only one source for each 
of the Surround and Center/LFE jacks active at one time.  When Spread 
Front to Surround and Center/LFE is disabled, the surround channels go 
to the the jacks; when this control is enabled, ONLY the front channels 
go to the surround and c/lfe jacks.


Considering the register values Michal provided and Takashi's patch:

The logic of the code is as follows:  (Slightly simplifying,) functions 
is_shared_linein() and is_shared_micin() return TRUE if the mixer is 
configured for shared jacks AND NOT for 6 channel mode.  In this case it 
is appropriate to

set these bits (LODIS and CLDIS).

Please double-check your mixer settings.  I added a byte to a structure, 
so the mixer settings can get messed up switching between alsa-kernel 
versions.


I don't understand why the other bit (OMS, 0x74 bit D9) is set.  This 
may have been an oversight on my part.


I am modifying alsa-kernel to run as an AD1985 on my system, to try to 
check these bits.


Randy Cushman


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


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread H. Peter Anvin

Christoph Hellwig wrote:

No, no no.  We should never export PAGE_SIZE.  We might export NBPG
as deprecated symbol for gdb if it really needs it, but that should
happen only on a.out systems, and it it should be a true constant,
not depending on PAGE_SIZE.

I've Cc'ed the gdb list on whether they have any comments on this
issue.


By the way, it's a massive snafu that the swap area magic number is 
dependent on PAGE_SIZE.  There is absolutely no good reason for that.


-hp
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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] chaostables

2007-03-08 Thread Alan Cox
 Also note that the word 'chaostables' does not even appear in the patch, 
 though xt_CHAOS does. Since we know that {xt,ipt}_[A-Z]+ are targets, we 
 can safely assume that CHAOS does what it says - make fun of nmap.

entropy ?
randomness

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


Re: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Serge E. Hallyn
Quoting Chris Wright ([EMAIL PROTECTED]):
 * Mimi Zohar ([EMAIL PROTECTED]) wrote:
  +   integrity_d_instantiate(entry, inode);
  security_d_instantiate(entry, inode);
 
  +   integrity_d_instantiate(entry, inode);
  security_d_instantiate(entry, inode);
 
  spin_unlock(dcache_lock);
  +   integrity_d_instantiate(new, inode);
  security_d_instantiate(new, inode);
  d_rehash(dentry);
 
  d_move(new, dentry);
  +   integrity_d_instantiate(dentry, inode);
  security_d_instantiate(dentry, inode);
  d_rehash(dentry);
 
  if (actual == dentry) {
  +   integrity_d_instantiate(dentry, inode);
  security_d_instantiate(dentry, inode);
 
 
  file-f_op-release(inode, file);
  security_file_free(file);
  +   integrity_file_free(file);
 
 
  security_file_free(file);
  +   integrity_file_free(file);
 
 
  if (security_inode_alloc(inode)) {
 ...
  +   if (integrity_inode_alloc(inode)) {
  +   if (inode-i_sb-s_op-destroy_inode)
  +   inode-i_sb-s_op-destroy_inode(inode);
 
  security_inode_free(inode);
  +   integrity_inode_free(inode);
 
  error = security_inode_setxattr(dentry, name, value, size, flags);
  if (error)
  goto out;
  +
  +   error = integrity_inode_setxattr(dentry, name, value, size, flags);
 
  fsnotify_xattr(dentry);
  +   integrity_inode_post_setxattr(dentry, name);
  security_inode_post_setxattr(dentry, name, value,
 
 I know there's some slightly different goals, but this just doesn't make
 sense.  Need to get back to defining and expressing just the differences.

Are you objecting only to the duplication at the callsites, so that an
fsnotify-type of consolidation of security and integrity hooks would be
ok?  Or are you complaining that the security_inode_setxattr and
integrity_inode_setxattr hooks are too similar anyway, and integrity
modules should just use some lsm hooks for anything which will be
authoritative?

(I could see an argument that integirty subsystem should be purely for
measuring and hence its hooks should never return a value.  Only hitch
there is that if integrity subsystem hits ENOMEM it should be able to
refuse the action...)

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


Re: irq nobody cared issue on 2.6.2x

2007-03-08 Thread Mws
On Wednesday 07 March 2007, Linus Torvalds wrote:
 
 On Wed, 7 Mar 2007, Mws wrote:
 
  if you would be so kind to provide me some infos,
  
  how i would be able to track the problem down _and_ maybe how to fix it.
 
 The first step is to figure out as exactly as possible _when_ it started 
 happening.
 
  please find two snippets of dmesg after booting 2.6.21-rc3-git 
  (2.6.20-1 has got the same results) 
 
 So is 2.6.19 good? 2.6.20-rc1? -rc2?

went down to 2.6.17 - earlier is lacking due to correctly booting my machine.

 If you're a git user (or even just marginally interested in learning), the 
 best thing to do is to find some good kernel (the more recent, the better, 
 but the keyword is *some* kernel that works well), and a bad kernel (the 
 older the better, just to avoid unnecessary work, but again, you can just 
 take the most recent too), and then just use git bisect.
 
 If you bisect it down to one particular commit, that will help us a lot, 
 but even if you only bisect it down by booting a handful of kernels (say, 
 5-6), it will already have cut things down a lot, and probably more easily 
 and efficiently than if you just downloaded daily snapshots and tried to 
 narrow it down that way.
 
   Linus
i started to bring in a load of printk's into v4l dvb repository to find out 
what exactly 
is causing the interrupt to appear and why it is not handled.

the bug is reproducible by insmod/rmmod dvb_ttpci over and over.
yesterday late night i tried a bit too much and my machine freezed as a whole.

even kernel sysrq didn't work anymore.

i found some point, that after fireware load the interrupt is fired again.

will check if there is a solution to create a workaround and try to fix it 
afterwards.

it does NOT appear on a different computer same card. i think it is a problem
in combination chipset - card - bios dunno by now, but will find out.

thanks for your information, linus.

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


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread Christoph Hellwig
On Thu, Mar 08, 2007 at 09:05:48AM -0800, H. Peter Anvin wrote:
 Christoph Hellwig wrote:
 No, no no.  We should never export PAGE_SIZE.  We might export NBPG
 as deprecated symbol for gdb if it really needs it, but that should
 happen only on a.out systems, and it it should be a true constant,
 not depending on PAGE_SIZE.
 
 I've Cc'ed the gdb list on whether they have any comments on this
 issue.
 
 By the way, it's a massive snafu that the swap area magic number is 
 dependent on PAGE_SIZE.  There is absolutely no good reason for that.

Yeah, now that you mention it I remember having problems with that
in the past.  We should probably create a new swap format that avoids
this problem.  I'll put it on my ever growing todo list.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [RFC][Patch 6/6] integrity: TPM internal kernel interface

2007-03-08 Thread Chris Wright
Other than the nits below, this looks like the right idea.

* Mimi Zohar ([EMAIL PROTECTED]) wrote:
 Index: linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/drivers/char/tpm/tpm.c
 +++ linux-2.6.21-rc3-mm2/drivers/char/tpm/tpm.c
 @@ -1,5 +1,5 @@
  /*
 - * Copyright (C) 2004 IBM Corporation
 + * Copyright (C) 2004,2007 IBM Corporation
   *
   * Authors:
   * Leendert van Doorn [EMAIL PROTECTED]
 @@ -25,6 +25,12 @@
  
  #include linux/poll.h
  #include linux/spinlock.h
 +#include linux/mm.h
 +#include linux/slab.h
 +#include linux/string.h
 +#include linux/crypto.h
 +#include linux/fs.h
 +#include asm/scatterlist.h
  #include tpm.h
  
  enum tpm_const {
 @@ -47,6 +53,8 @@ enum tpm_duration {
  static LIST_HEAD(tpm_chip_list);
  static DEFINE_SPINLOCK(driver_lock);
  static DECLARE_BITMAP(dev_mask, TPM_NUM_DEVICES);
 +#define TPM_CHIP_NUM_MASK   0x
 +#define TPM_CHIP_TYPE_SHIFT 16
  
  /*
   * Array with one entry per ordinal defining the maximum amount
 @@ -363,7 +371,7 @@ EXPORT_SYMBOL_GPL(tpm_calc_ordinal_durat
  /*
   * Internal kernel interface to transmit TPM commands
   */
 -static ssize_t tpm_transmit(struct tpm_chip *chip, const char *buf,
 +ssize_t tpm_transmit(struct tpm_chip *chip, char *buf,
   size_t bufsiz)
  {
   ssize_t rc;
 @@ -422,6 +430,7 @@ out:
   up(chip-tpm_mutex);
   return rc;
  }
 +EXPORT_SYMBOL_GPL(tpm_transmit);
  
  #define TPM_DIGEST_SIZE 20
  #define TPM_ERROR_SIZE 10
 @@ -665,6 +674,7 @@ ssize_t tpm_show_temp_deactivated(struct
  }
  EXPORT_SYMBOL_GPL(tpm_show_temp_deactivated);
  
 +#define READ_PCR_RESULT_SIZE 30

Is this the same value that's used as a magic number in places
like tpm_gen_interrupt and tpm_show_pcrs?  Be nice to convert
that as well to eliminate some magic (my quick review of TPM
specs came up empty, so I could be off the mark).

  static const u8 pcrread[] = {
   0, 193, /* TPM_TAG_RQU_COMMAND */
   0, 0, 0, 14,/* length */
 @@ -713,6 +723,93 @@ out:
  }
  EXPORT_SYMBOL_GPL(tpm_show_pcrs);
  
 +static struct tpm_chip* tpm_chip_lookup(int chip_num, int chip_typ)
 +{
 +struct tpm_chip *pos;
 +
 +spin_lock(driver_lock);
 +list_for_each_entry(pos, tpm_chip_list, list)
 +if ((chip_num == TPM_ANY_NUM ||
 +pos-dev_num == chip_num ) 
 +(chip_typ == TPM_ANY_TYPE)){
 +spin_unlock(driver_lock);
 +return pos;
 +}
 +
 +spin_unlock(driver_lock);

I guess this is OK, since TPM chips aren't hotpluggable, but
typically this type of interface would refcount the device
it finds before returning it to caller.

 +return NULL;
 +}
 +
 +/*
 + * Return 0 on success.  On error pass along error code.
 + * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
 + * Lower 2 bytes equal tpm idx # or AN
 + * res_buf must fit a TPM_PCR (20 bytes) or NULL if you don't care
 + */

Proper kerneldoc for exported functions please.

 +int tpm_pcr_read( u32 chip_id, int pcr_idx, u8* res_buf, int res_buf_size )
 +{
 +u8 data[READ_PCR_RESULT_SIZE];
 +int rc;
 +__be32 index;
 +int chip_num = chip_id  TPM_CHIP_NUM_MASK;
 +struct tpm_chip* chip;
 +
 +if ( res_buf  res_buf_size  TPM_DIGEST_SIZE )
 +return -ENOSPC;

CodingStyle [extra spaces around '(' and ')'],  if (foo)...
Tabs not spaces.

 +
 +if ( (chip = tpm_chip_lookup( chip_num,
 +chip_id  TPM_CHIP_TYPE_SHIFT ) ) == NULL )

chip = tpm_chip_lookup(chip_num, chip_id  TPM_CHIP_TYPE_SHIFT);
if (!chip)

 +return -ENODEV;
 +
 +memcpy(data, pcrread, sizeof(pcrread));
 +index = cpu_to_be32(pcr_idx);
 +memcpy(data + 10, index, 4);
 +if ((rc = tpm_transmit(chip, data, sizeof(data)))  0 )
 +rc = be32_to_cpu(*((u32*)(data+6)));
 +

Shouldn't this be a helper? (there's other pcr reads going on internally)
And similar CodingStyle comment...

 +if ( rc == 0  res_buf )
 +memcpy(res_buf, data+10, TPM_DIGEST_SIZE);
 +
 +return rc;
 +
 +}
 +EXPORT_SYMBOL_GPL(tpm_pcr_read);
 +
 +#define EXTEND_PCR_SIZE 34
 +static const u8 pcrextend[] = {
 +0, 193, /* TPM_TAG_RQU_COMMAND */
 +0, 0, 0, 34,/* length */
 +0, 0, 0, 20,/* TPM_ORD_Extend */
 +0, 0, 0, 0  /* PCR index */
 +};
 +
 +/*
 + * Return 0 on success.  On error pass along error code.
 + * chip_id Upper 2 bytes equal ANY, HW_ONLY or SW_ONLY
 + * Lower 2 bytes equal tpm idx # or ANY
 + */
 +int tpm_pcr_extend(u32 chip_id, int pcr_idx, const u8* hash)
 +{
 +u8 data[EXTEND_PCR_SIZE];
 +int rc;
 +__be32 index;
 +int chip_num = chip_id  

Re: [PATCH] chaostables

2007-03-08 Thread Patrick McHardy
Jan Engelhardt wrote:
Index: linux-2.6.21-rc3/net/netfilter/xt_CHAOS.c
+/* Equivalent to:
+ * -A chaos -m statistic --mode random --probability \
+ * $reject_percentage -j REJECT --reject-with host-unreach;
+ * -A chaos -m statistic --mode random --probability \
+ * $delude_percentage -j DELUDE;
+ * -A chaos -j DROP;
+ */

What does this do that can't be done by simply adding those individual 
rules?
 
 
 It wraps it all up, reducing the overall number of rules and user 
 chains required in the filtering tables to implement the wanted logic. 
 Reducing the number of filtering rules also reduces the time process a 
 packet. These two are, in my opinion, a good thing.


By that argument we could just codify every ruleset and put it in the
kernel. Its three simple rules. There is no chance I'm going to take
this part.

 Take xt_portscan as an example, which would require a minimum of 23 
 filtering rules (which cannot reproduce the module's action in its 
 fullest). 23 rules means we will be looping a bit in ipt_do_table() for 
 a single packet, repeatedly checking for -p tcp, i.e. calling into 
 xt_tcpudp, checking for port ranges and perhaps other TCP fields that 
 are never examined in xt_portscan.


I'm guessing xt_portscan tries to detect and match on portscans, but
its not obvious why it looks at and changes skb-mark and nfct-ctmark,
so I suggest you start by explaining what it really does.

+++ linux-2.6.21-rc3/net/netfilter/xt_DELUDE.c

Looks like a copy of the REJECT target. What does it do,
why can't you use REJECT?
 
 
 Looking only at TCP,
 REJECT sends a RST for any packet (if requested), or ICMP otherwise.
 DELUDE sends a SYN-ACK on SYN, otherwise RST.
 (And TARPIT, for reference, keeps the connection open anytime. Its code
 is also quite a replication of REJECT.)
 
 If you think it is better to merge the respond-with-SYNACK into REJECT 
 rather than having DELUDE, say so.


I'd rather not add hacks to mildly annoy people anywhere.

We already have the psd match for years, but decided against merging it.
 
 
 On what basis? As far as I flew over psd's code, it uses a heuristic 
 like how often did that client recently connect for match decision. 
 (P2P clients randomly port knocking, anyone?) I would not think of that 
 as a reliable way to tell portscans either. However, half-open TCP 
 connect for example is a more clear action to define a portscan.


The question is what we gain by being able to detect portscans.
So far my opinion is thats its close to nothing. Besides that,
it should be possible to do this by using the recent match.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [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/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Linus Torvalds


On Thu, 8 Mar 2007, Davide Libenzi wrote:
 
 The reason for the special function, was not to provide a non-blocking 
 behaviour with zero timeout (that just a side effect), but to read the 
 siginfo. I was all about using read(2) (and v1 used it), but when you have 
 to transfer complex structures over it, it becomes hell. How do you 
 cleanly compat over a f_op-read callback for example?

I agree that it gets a bit interesting, and one option might be that the 
read() interface just gets the signal number and the minimal siginfo 
information, which is, after all, what 99% of all apps actually care
about.

But siginfo_t is really a *horrible* structure. Nobody sane should ever 
use siginfo_t, and the designer of that thing was so high on LSD that it's 
not even funny. Re-using fields in a union? Values that depend on other 
bits in the thing in random manners? 

In other words, I bet that we could just make it a *lot* better by making 
the read structure be:

 - 16 4-byte fields (fixed 64-byte packet), where each field is an 
   uint32_t (we could even do it in network byte order if we care and if 
   you want to just pipe the information from one machine to another, but 
   that sounds a bit excessive ;)

 - Just put the fields people actually use at fixed offsets: si_signo, 
   si_errno, si_pid, si_uid, si_band, si_fd.

 - that still leaves room for the other cases if anybody ever wants them 
   (but I doubt it - things like si_addr are really only useful for 
   synchronous signals that are actually done as *signals*, since you 
   cannot defer a SIGBUS/SIGSEGV/SIGILL *anyway*).

So I bet 99% of users actually just want si_signo, while some small subset 
might want the SIGCHLD info and some of the special cases (eg we migth 
want to add si_addr as a 64-bit thing just because the USB stack sends a 
SI_ASYNCIO thing for completed URB's, so a libusb might want it, but 
that's probably the only such user).

And it would be *cleaner* than the mess that is siginfo_t..

(I realize that siginfo_t is ugly because it built up over time, using the 
same buffer for many different things. I'm just saying that we can 
probably do better by *not* using it, and just laying things out in a 
cleaner manner to begin with, which also solves any compatibility issues)

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


Re: [RFC][Patch 1/6] integrity: new hooks

2007-03-08 Thread Chris Wright
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
 It's unfortunate, agreed, but
 use of LSM as an integrity framework was also a no-go.
 
 Options?

There's too much dup because stuff like above is just access control
not integrity measurement.  Need to break off the parts that really
are different.  But I don't have a great option offhand, I recognize
the complication.

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


Re: [PATCH] x86_64 RESTORE_CONTEXT missing '\n'

2007-03-08 Thread Andi Kleen
On Wednesday 07 March 2007 21:45, Dave Jiang wrote:
 
 The RESTORE_CONTEXT macro is missing the '\n' at the end. It was removed in 
 the
 previous patch that touched system.h. It causes compile failure if any
 inline asm is added after the macro. Discovered this when playing with
 kgdb.

We went through this several times. kgdb has no business to poke 
into kernel private macros like this and it shouldn't do that. 
So fixing kgdb to not require touching the context switch is the right
change.

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


Possible struct pid leak from tty_io.c

2007-03-08 Thread Catalin Marinas

Hi Eric,

I'm trying to track down a kmemleak report (on an ARM platform) which
seems to have appeared with commit
ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
TTY layer at all, is it possible that the above commit missed a
put_pid() call on some path?

The /sbin/init application calls sys_clone() a few times but only one
leak is reported (see below). Looking at the reported pid object (at
0xc7c14500), count is 2 and nr is 296 but no process with pid 296
exists any more.

unreferenced object 0xc7c14500 (size 36):
 comm init, pid 245, jiffies 4294939289
 backtrace:
   [c0070c18] kmem_cache_alloc
   [c003a528] alloc_pid
   [c0026468] do_fork
   [c00153b0] sys_clone
   [c0010f80] ret_fast_syscall

Thanks.

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


Re: [patch 2/5] signalfd v2 - signalfd core ...

2007-03-08 Thread Linus Torvalds


On Thu, 8 Mar 2007, Michael K. Edwards wrote:
 
 Make it a netlink socket and fetch your structures using recvmsg().
 siginfo_t belongs in ancillary data.

Gaah. That interface is horrible.

 The UNIX philosophy is everything's a file.  The Berkeley philosophy
 is everything's a socket, except for files, which are feeble
 mini-sockets.  I'd go with the Berkeley crowd here.

No, the berkeley crowd is totally out to lunch.

I might agree with you *if* you could actually do recvmsg() on arbitrary 
file descriptors, but you cannot. 

We could fix that in Linux, of course, but the fact is, recvmsg() is 
*not* a superset of read(). In general, it's a *subset*, exactly because 
very few file descriptors support it.

So the normal way to read from a file descriptor (and the *only* way in 
any generic select loop) is to use read(). That's the only thing that 
works for everything. And we shouldn't break that.

The sad part is that there really is no reason why the BSD crowd couldn't 
have done recvmsg() as an extended read with per-system call flags, 
which would have made things like O_NONBLOCK etc unnecessary, because you 
could do it just with MSG_DONTWAIT..

So anybody who would go with the Berkeley crowd really shows a lot of 
bad taste, I'm afraid. The Berkeley crowd really messed up here, and it's 
so long ago that I don't think there is any point in us trying to fix it 
any more.

(But if somebody makes recvmgs a general VFS interface and makes it just 
work for everything, I'd probably take the patch as a cleanup. I really 
think it should have been a struct file_operations thing rather than 
being a socket-only thing.. But since you couldn't portably use it 
anyway, the thing is pretty moot)

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


Re: Linux v2.6.21-rc3

2007-03-08 Thread Alistair John Strachan
(Dropped LKML, whoops.)

On Wednesday 07 March 2007 04:59, you wrote:
 We've finally hopefully started to put a dent in the regressions,
 especially the suspend/resume problems introduced since 2.6.20.

 So 2.6.21-rc3 is out there now, and there's some hope that it will work
 more widely than -rc1 and -rc2 did. Please do give it a good testing, and
 update Adrian and the mailing list (and me) about any regressions
 (hopefully many more of the it's fixed now than other kinds, but all
 regressions are interesting).

Robert and Jeff already know about these, but I thought I'd send out a
reminder.

ata2: EH in ADMA mode, notifier 0x0 notifier_error 0x0 gen_ctl 0x1501000 
status 0x500 next cpb count 0x0 next cpb idx 0x0
ata2: CPB 0: ctl_flags 0xd, resp_flags 0x1
ata2.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x2 frozen
ata2.00: cmd 35/00:30:b5:c1:8f/00:01:01:00:00/e0 tag 0 cdb 0x0 data 155648 out
 res 40/00:00:01:4f:c2/00:00:00:00:00/00 Emask 0x4 (timeout)
ata2: soft resetting port
ata2: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
ata2.00: configured for UDMA/133
ata2: EH complete
SCSI device sdb: 488397168 512-byte hdwr sectors (250059 MB)
sdb: Write Protect is off
sdb: Mode Sense: 00 3a 00 00
SCSI device sdb: write cache: enabled, read cache: enabled, doesn't support 
DPO or FUA

They didn't happen (or didn't happen as frequently) in 2.6.20; it's a serious
bug. Happened in -rc2 and -rc3. A patch from Robert reverting
721449bf0d51213fe3abf0ac3e3561ef9ea7827a seems to make them go away.

-- 
Cheers,
Alistair.

Final year Computer Science undergraduate.
1F2 55 South Clerk Street, Edinburgh, UK.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [rfc][patch] futex: restartable futex_wait?

2007-03-08 Thread Ingo Molnar

* Nick Piggin [EMAIL PROTECTED] wrote:

 Hi Ingo,
 
 I'm seeing an LTP test fail for ltp test sigaction_16_24. Basically, 
 it tests whether the SA_RESTART flag works for the sem_wait operation.
 
 I see sem_wait is implemented with futex_wait, so I wonder whether we 
 can make it restartable? Am I going about it the right way? (Seems to 
 fix the testcase here).

i think that's quite right. I'm wondering why this never came up before? 
But your fix is not complete i think:

 + restart-arg2 = time;
 + return -ERESTART_RESTARTBLOCK;
 + }

'time' here is relative, so the restarted syscall will do a /full/ wait 
again.

maybe we should rather convert futex timed-waits to hrtimers? Thomas?

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


Re: SATA resume slowness, e1000 MSI warning

2007-03-08 Thread Eric W. Biederman
Jeff Garzik [EMAIL PROTECTED] writes:

 Eric W. Biederman wrote:
 Until I get the best scenario I can come up with is a tg3 hardware bug
 that doesn't renable the pci-X capability after a restore of power state.


 Speaking of tg3, make sure you are aware that the number of calls to 
 save-state
 functions may not match the number of calls to the restore-state functions.
 ISTR seeing some memleak bugs in PCI related to this.

Thanks that looks like the problem, multiple calls to save before one
call to restore when you have a pci-x capability would easily trigger
this problem.  I just surveyed a bunch of the pci_save_state and
pci_restore_state users and this appears to be a common idiom not just
a tg3 thing

It looks like when code was added to save/restore the msi capability
was added to pci_save/restore_state that an assumption was added that
pci_save_state and pci_restore state were only used for suspend and
only used in pairs.  There is even a partial bug fix that removed the
worst of the symptoms of that assumption from the msi code but failed
to recognize the core problem.

Now that we have code to work with pcie and pcix capabilities as well
as msi this problem is much easier to hit.

All of pci_save_state and pci_restore_state is going to have to be
restructured to fix this, and it is late in the game.  Ugh.
Oh well, better to fix it now 

At least I get my answer about if what pci_save_state is doing
is reasonable. It is not.  pci_save_state no longer supports being
used in conjunction with hardware reset and has become a
suspend/resume specific function.

Now I'm off to wite some patches to fix this.

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: [RFC][Patch 5/6] integrity: mtime patch for mmap files

2007-03-08 Thread Chris Wright
* Mimi Zohar ([EMAIL PROTECTED]) wrote:
 This is a minimal subset of Peter Staubach's July patch, updated to
 apply to the latest kernel. The subset was chosen to demonstrate that
 mmaped files are hashed and hmac properly by EVM after being modified
 when a file's mtime is updated correctly.

Would make sense to Cc Peter on fsdevel on this.

 Index: linux-2.6.21-rc3-mm2/fs/inode.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/inode.c
 +++ linux-2.6.21-rc3-mm2/fs/inode.c
 @@ -1209,8 +1209,8 @@ void touch_atime(struct vfsmount *mnt, s
  EXPORT_SYMBOL(touch_atime);
  
  /**
 - *   file_update_time-   update mtime and ctime time
 - *   @file: file accessed
 + *   inode_update_time   -   update mtime and ctime time
 + *   @inode: file accessed
   *
   *   Update the mtime and ctime members of an inode and mark the inode
   *   for writeback.  Note that this function is meant exclusively for
 @@ -1220,9 +1220,8 @@ EXPORT_SYMBOL(touch_atime);
   *   timestamps are handled by the server.
   */
  
 -void file_update_time(struct file *file)
 +void inode_update_time(struct inode *inode)
  {
 - struct inode *inode = file-f_path.dentry-d_inode;
   struct timespec now;
   int sync_it = 0;
  
 @@ -1246,7 +1245,7 @@ void file_update_time(struct file *file)
   mark_inode_dirty_sync(inode);
  }
  
 -EXPORT_SYMBOL(file_update_time);
 +EXPORT_SYMBOL(inode_update_time);
  
  int inode_needs_sync(struct inode *inode)
  {
 Index: linux-2.6.21-rc3-mm2/fs/fs-writeback.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/fs-writeback.c
 +++ linux-2.6.21-rc3-mm2/fs/fs-writeback.c
 @@ -167,6 +167,9 @@ __sync_single_inode(struct inode *inode,
  
   spin_unlock(inode_lock);
  
 + if (test_and_clear_bit(AS_MCTIME, mapping-flags))
 + inode_update_time(inode);
 +
   ret = do_writepages(mapping, wbc);
  
   /* Don't write the inode if only I_DIRTY_PAGES was set */
 Index: linux-2.6.21-rc3-mm2/fs/buffer.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/buffer.c
 +++ linux-2.6.21-rc3-mm2/fs/buffer.c
 @@ -734,8 +734,11 @@ int __set_page_dirty_buffers(struct page
   }
   spin_unlock(mapping-private_lock);
  
 - if (TestSetPageDirty(page))
 + if (TestSetPageDirty(page)) {
 + if (page_mapped(page))
 + set_bit(AS_MCTIME, mapping-flags);
   return 0;
 + }
  
   write_lock_irq(mapping-tree_lock);
   if (page-mapping) {/* Race with truncate? */
 @@ -749,6 +752,8 @@ int __set_page_dirty_buffers(struct page
   }
   write_unlock_irq(mapping-tree_lock);
   __mark_inode_dirty(mapping-host, I_DIRTY_PAGES);
 + if (page_mapped(page))
 + set_bit(AS_MCTIME, mapping-flags);
   return 1;
  }
  EXPORT_SYMBOL(__set_page_dirty_buffers);
 Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
 ===
 --- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
 +++ linux-2.6.21-rc3-mm2/include/linux/fs.h
 @@ -1944,7 +1944,12 @@ extern int buffer_migrate_page(struct ad
  extern int inode_change_ok(struct inode *, struct iattr *);
  extern int __must_check inode_setattr(struct inode *, struct iattr *);
  
 -extern void file_update_time(struct file *file);
 +extern void inode_update_time(struct inode *);
 +
 +static inline void file_update_time(struct file *file)
 +{
 + inode_update_time(file-f_dentry-d_inode);

s/f_dentry/f_path.dentry/

 +}
  
  static inline ino_t parent_ino(struct dentry *dentry)
  {
 Index: linux-2.6.21-rc3-mm2/include/linux/pagemap.h
 ===
 --- linux-2.6.21-rc3-mm2.orig/include/linux/pagemap.h
 +++ linux-2.6.21-rc3-mm2/include/linux/pagemap.h
 @@ -17,8 +17,9 @@
   * Bits in mapping-flags.  The lower __GFP_BITS_SHIFT bits are the page
   * allocation mode flags.
   */
 -#define  AS_EIO  (__GFP_BITS_SHIFT + 0)  /* IO error on async 
 write */
 +#define AS_EIO   (__GFP_BITS_SHIFT + 0)  /* IO error on async 
 write */
  #define AS_ENOSPC(__GFP_BITS_SHIFT + 1)  /* ENOSPC on async write */
 +#define AS_MCTIME(__GFP_BITS_SHIFT + 2)  /* need m/ctime change */
  
  static inline void mapping_set_error(struct address_space *mapping, int 
 error)
  {
 Index: linux-2.6.21-rc3-mm2/mm/page-writeback.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/mm/page-writeback.c
 +++ linux-2.6.21-rc3-mm2/mm/page-writeback.c
 @@ -815,8 +815,10 @@ int __set_page_dirty_no_writeback(struct
   */
  int __set_page_dirty_nobuffers(struct page *page)
  {
 + struct address_space *mapping = page_mapping(page);
 + int ret = 0;
 +
   if (!TestSetPageDirty(page)) {
 - struct address_space *mapping = page_mapping(page);

brand new lists in: radiology, surgery, orthapedics, cardiology, anesthesiology, pediatrics

2007-03-08 Thread Audra A Carlson


7 new databases for the medical profession just released!

-- All New American Nurses Database: Over 59,000 nurses complete with 
addresses, phone and fax numbers
All data is in Excel format and sortable by 30 specialties. MSA and CMSA fields 
also included.
**Special Price Until March 15 $299**

-- All New Radiologist Database :34,763 records for the USA  **Price 
Until March 15 $199**
-- All New Database of Surgeons :39,517 records for the USA  **Price 
Until March 15 $199**
-- All New Orthapedics Database :24,145 records for the USA  **Price 
Until March 15 $199**
-- All New Database of Cardiologists:24,577 records for the USA  **Price 
Until March 15 $199**
-- All New Database of Anesthesiologists:38,155 records for the USA  **Price 
Until March 15 $199**
-- All New Pediatrics Database : 60,684 records for the USA  **Price 
Until March 15 $249**

For more information or to place an order please call 206-600-5313 or for 
faster service send an
email to [EMAIL PROTECTED]

Please accept our sincerest apologies if you did not request this email and 
rest assured that
by sending us an email with unlist in the subject heading we will never 
contact you again.


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


EXT3-fs warning (device sdd2): dx_probe: Unrecognised inode hash code 232

2007-03-08 Thread Jan De Luyck
Hello,

Running 2.6.19.1 on AMD64.

While copying some files on an ext3 partition, I got this in the logs:

EXT3-fs warning (device sdd2): dx_probe: Unrecognised inode hash code 232
Assertion failure in dx_probe() at fs/ext3/namei.c:384: dx_get_limit(entries) 
== dx_root_limit(dir, root-info.info_length)
--- [cut here ] - [please bite here ] -
Kernel BUG at fs/ext3/namei.c:384
invalid opcode:  [1] PREEMPT SMP
CPU 0
Modules linked in: xt_multiport iptable_filter ip_tables x_tables binfmt_misc 
fuse parport_pc lp parport thermal fan button nls_iso8859_15 ntfs kqemu(P) 
tcp_diag inet_diag w83627ehf i2c_isa cpufreq_ondemand powernow_k8 freq_table 
processor snd_hda_intel snd_hda_codec snd_pcm evdev snd_timer psmouse snd 
pcspkr floppy ehci_hcd soundcore snd_page_alloc usbcore k8temp hwmon ohci1394 
ieee1394 forcedeth i2c_nforce2 i2c_core sg sr_mod cdrom
Pid: 4018, comm: find Tainted: P  2.6.19.5 #1
RIP: 0010:[802efe2b]  [802efe2b] dx_probe+0x18b/0x320
RSP: 0018:81006b789d28  EFLAGS: 00010292
RAX: 0081 RBX: 810066f07018 RCX: c100
RDX: 81006b788000 RSI: 81006b5c62c0 RDI: 
RBP:  R08: 81006b788000 R09: 0001
R10:  R11: 80212a20 R12: 810066e6f8e8
R13:  R14:  R15: 810066f06730
FS:  2ae8c9f5c6d0() GS:80586000() knlGS:
CS:  0010 DS:  ES:  CR0: 8005003b
CR2: 2af535db8086 CR3: 6b7b2000 CR4: 06e0
Process find (pid: 4018, threadinfo 81006b788000, task 81006b5c62c0)
Stack:  81006b789dd4 81006b789d88 81007f79d750 810066e6acc0
  810066f06730 810066f06730 
 81007efca580 802f13ab 810066e6ace8 7ff98780
Call Trace:
 [802f13ab] ext3_htree_fill_tree+0xab/0x1e0
 [802e8d69] ext3_readdir+0x1a9/0x530
 [802359b3] vfs_readdir+0x73/0xc0
 [802bea1f] sys_getdents64+0x7f/0xd0
 [802607fe] system_call+0x7e/0x83
 [2ae8c9dad41a]


Code: 0f 0b 68 f0 0c 48 80 c2 80 01 48 8b 54 24 08 48 89 54 24 10
RIP  [802efe2b] dx_probe+0x18b/0x320
 RSP 81006b789d28

Yeah, I know it's tainted - just wanted to hear if anyone saw this one before. 
System seems to be fine otherwise, I'll run a fsck on the filesystem lateron.

Jan

-- 
Common sense is instinct, and enough of it is genius.
-- Josh Billings
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/


Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4

2007-03-08 Thread Mel Gorman
On (08/03/07 08:48), Christoph Lameter didst pronounce:
 On Thu, 8 Mar 2007, Mel Gorman wrote:
 
  On x86_64, it completed successfully and looked reliable. There was a 5%
  performance loss on kernbench and aim9 figures were way down. However, with
  slub_debug enabled, I would expect that so it's not a fair comparison
  performance wise. I'll rerun the tests without debug and see what it looks
  like if you're interested and do not think it's too early to worry about
  performance instead of clarity. This is what I have for bl6-13 (machine
  appears on test.kernel.org so additional details are there).
 
 No its good to start worrying about performance now. There are still some 
 performance issues to be ironed out in particular on NUMA. I am not sure
 f.e. how the reduction of partial lists affect performance.
 

Ok, I've sent off a bunch of tests - two of which are on NUMA (numaq and
x86_64). It'll take them a long time to complete though as there is a
lot of testing going on right now.

  IA64 (machine not visible on TKO) curiously did not exhibit the same 
  problems
  on kernbench for Total CPU time which is very unexpected but you can see the
  System CPU times. The AIM9 figures were a bit of an upset but again, I blame
  slub_debug being enabled
 
 This was a single node box?

Yes, memory looks like this;

Zone PFN ranges:
  DMA  1024 -   262144
  Normal 262144 -   262144
Movable zone start PFN for each node
early_node_map[3] active PFN ranges
0: 1024 -30719
0:32768 -65413
0:65440 -65505
On node 0 totalpages: 62405
Node 0 memmap at 0xe1126000 size 3670016 first pfn 0xe1134000
  DMA zone: 220 pages used for memmap
  DMA zone: 0 pages reserved
  DMA zone: 62185 pages, LIFO batch:7
  Normal zone: 0 pages used for memmap
  Movable zone: 0 pages used for memmap

 Note that the 16kb page size has a major 
 impact on SLUB performance. On IA64 slub will use only 1/4th the locking 
 overhead as on 4kb platforms.
 

It'll be interesting to see the kernbench tests then with debugging
disabled.

  (as an aside, the succes rates for high-order allocations are lower with 
  SLUB.
  Again, I blame slub_debug. I know that enabling SLAB_DEBUG has similar 
  effects
  because of red-zoning and the like)
 
 We have some additional patches here that reduce the max order for some 
 allocs. I believe the task_struct gets to be an order 2 alloc with V4,
 

Should make a difference for slab fragmentation

  Now, the bad news. This exploded on ppc64. It started going wrong early in 
  the
  boot process and got worse. I haven't looked closely as to why yet as there 
  is
  other stuff on my plate but I've included a console log that might be some 
  use
  to you. If you think you have a fix for it, feel free to send it on and I'll
  give it a test.
 
 Hmmm... Looks like something is zapping an object. Try to rerun with 
 a kernel compiled with CONFIG_SLAB_DEBUG. I would expect similar results.
 

I've queued up a few tests. One completed as I wrote this and it didn't
explode with SLAB_DEBUG set. Maybe the others will be different. I'll
kick it around for a bit.

It could be a real bug that slab is just not catuching.

  Brought up 4 CPUs
  Node 0 CPUs: 0-3
  mm/memory.c:111: bad pud c50e4480.
  could not vmalloc 20971520 bytes for cache!
 
 Hmmm... a bad pud? I need to look at how the puds are managed on power.
 
  migration_cost=0,1000
  *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab
 
 An object was overwritten with zeros after it was freed.

  RTAS daemon started
  RTAS: event: 1, Type: Platform Error, Severity: 2
  audit: initializing netlink socket (disabled)
  audit(1173335571.256:1): initialized
  Total HugeTLB memory allocated, 0
  VFS: Disk quotas dquot_6.5.1
  Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
  JFS: nTxBlock = 8192, nTxLock = 65536
  SELinux:  Registering netfilter hooks
  io scheduler noop registered
  io scheduler anticipatory registered (default)
  io scheduler deadline registered
  io scheduler cfq registered
  pci_hotplug: PCI Hot Plug PCI Core version: 0.5
  rpaphp: RPA HOT Plug PCI Controller Driver version: 0.1
  rpaphp: Slot [:00:02.2](PCI location=U7879.001.DQD0T7T-P1-C4) registered
  vio_register_driver: driver hvc_console registering
  [ cut here ]
  Badness at mm/slub.c:1701
 
 Someone did a kmalloc(0, ...). Zero sized allocation are not flagged
 by SLAB but SLUB does.
 

I'll chase up what's happening here. It will be reproducable independent
of SLUB by adding a similar check.

  Call Trace:
  [C506B730] [C0011188] .show_stack+0x6c/0x1a0 (unreliable)
  [C506B7D0] [C01EE9F4] .report_bug+0x94/0xe8
  [C506B860] [C038C85C] .program_check_exception+0x16c/0x5f4
  [C506B930] [C00046F4] program_check_common+0xf4/0x100
  --- Exception: 700 at .get_slab+0xbc/0x18c
  LR = .__kmalloc+0x28/0x104
  

Re: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Chris Wright
* Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
 Are you objecting only to the duplication at the callsites, so that an
 fsnotify-type of consolidation of security and integrity hooks would be
 ok?  Or are you complaining that the security_inode_setxattr and
 integrity_inode_setxattr hooks are too similar anyway, and integrity
 modules should just use some lsm hooks for anything which will be
 authoritative?

It's duplication of callsites with many identical implementations
that's the problem.

 (I could see an argument that integirty subsystem should be purely for
 measuring and hence its hooks should never return a value.  Only hitch
 there is that if integrity subsystem hits ENOMEM it should be able to
 refuse the action...)

Right, that's what I was expecting to see, just the measurement
infrastructure.

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


Re: [PATCH] x86_64 RESTORE_CONTEXT missing '\n'

2007-03-08 Thread Dave Jiang
Andi Kleen wrote:
 On Wednesday 07 March 2007 21:45, Dave Jiang wrote:
 The RESTORE_CONTEXT macro is missing the '\n' at the end. It was removed in 
 the
 previous patch that touched system.h. It causes compile failure if any
 inline asm is added after the macro. Discovered this when playing with
 kgdb.
 
 We went through this several times. kgdb has no business to poke 
 into kernel private macros like this and it shouldn't do that. 
 So fixing kgdb to not require touching the context switch is the right
 change.
 
 -Andi

In spite of kgdb, shouldn't it have that \n anyways in case some other code
gets added in the future after the macro? Or are you saying that there should
never be any code ever after that macro?

-- 

--
Dave Jiang
Software Engineer
MontaVista Software, Inc.
http://www.mvista.com
--

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


Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4

2007-03-08 Thread Christoph Lameter
On Thu, 8 Mar 2007, Mel Gorman wrote:

 Brought up 4 CPUs
 Node 0 CPUs: 0-3
 mm/memory.c:111: bad pud c50e4480.

Lower bits must be clear right? Looks like the pud was released
and then reused for a 64 byte cache or so. This is likely a freelist 
pointer that slub put there after allocating the page for the 64 byte 
cache. Then we tried to use the pud.

 migration_cost=0,1000
 *** SLUB: Redzone Inactive check fails in [EMAIL PROTECTED] Slab
 c0756090
 offset=240 flags=50c7 inuse=3 freelist=c50de0f0
   Bytes b4 c50de0e0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 Object c50de0f0:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 Object c50de100:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 Object c50de110:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
 Object c50de120:  00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
 
Redzone c50de130:  00 00 00 00 00 00 00 00
  FreePointer c50de138: 

Data overwritten after free or after slab was allocated. So this may be 
the same issue. pud was zapped after it was freed destroying the poison 
of another object in the 64 byte cache.

Hmmm.. Maybe I should put the pad checks before the object checks. 
That way we detect that the whole slab was corrupted and do not flag just 
a single object.

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


Re: 2.6.21-rc3-mm1

2007-03-08 Thread Valdis . Kletnieks
On Wed, 07 Mar 2007 20:18:39 PST, Andrew Morton said:
   
 ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc3/2.6.21-rc3-mm1/

Mostly working for me.

 - The wireless changes in here need a lot of testers, please.  It is major
   rework.

Working on it - the new MAC80211 stack landed in the -mm tree, but the matching
iwlwifi driver for the Intel 3945ABG is still out-of-tree and acting wonky
for me.  The card comes up, 'iwlist scanning' sees 4 access points, but it
won't associate.  Not sure what I borked up.


pgp5svZo4Kh3r.pgp
Description: PGP signature


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread Anton Blanchard

 By the way, it's a massive snafu that the swap area magic number is 
 dependent on PAGE_SIZE.  There is absolutely no good reason for that.

Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.

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


Re: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Serge E. Hallyn
Quoting Chris Wright ([EMAIL PROTECTED]):
 * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
  Are you objecting only to the duplication at the callsites, so that an
  fsnotify-type of consolidation of security and integrity hooks would be
  ok?  Or are you complaining that the security_inode_setxattr and
  integrity_inode_setxattr hooks are too similar anyway, and integrity
  modules should just use some lsm hooks for anything which will be
  authoritative?
 
 It's duplication of callsites with many identical implementations
 that's the problem.

Yes it's ugly...

But I guess it gets a point across :)

  (I could see an argument that integirty subsystem should be purely for
  measuring and hence its hooks should never return a value.  Only hitch
  there is that if integrity subsystem hits ENOMEM it should be able to
  refuse the action...)
 
 Right, that's what I was expecting to see, just the measurement
 infrastructure.

So what you are saying is EVM would stay an LSM, with a cooperating
integrity subsystem *just* doing measurements?

That's kind of what i was expecting too, however that doesn't fit as
well with the idea that an integrity subsystem prevents the need for lsm
stacking.  I think the idea was that evm would still be able to enforce
integrity of selinux xattrs without it stack with selinux.  So I can see
where this approach came from.

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


Re: PAGE_SIZE Availability Inconsistency

2007-03-08 Thread H. Peter Anvin

Anton Blanchard wrote:
By the way, it's a massive snafu that the swap area magic number is 
dependent on PAGE_SIZE.  There is absolutely no good reason for that.


Agreed, its been a big problem booting between 4kB and 64kB kernels on
ppc64.


The easiest way to fix this would be to always park the swap magic at 
the offset of the smallest page size in use, which is 4K.  This is 
analogous how the offset for the ext2/3 superblock got fixed at 1K -- 
for 1K blocks, it's the second block, but for larger blocks, it's part 
of the first block.  If we fix the offset of the swap magic at 4096 
minus the offset that's already there, it will always fall in the first 
page regardless of page size.


-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: Possible struct pid leak from tty_io.c

2007-03-08 Thread Eric W. Biederman
Catalin Marinas [EMAIL PROTECTED] writes:

 Hi Eric,

 I'm trying to track down a kmemleak report (on an ARM platform) which
 seems to have appeared with commit
 ab521dc0f8e117fd808d3e425216864d60390500. As I'm not familiar with the
 TTY layer at all, is it possible that the above commit missed a
 put_pid() call on some path?

I won't arbitrarily rule a missing put_pid out.  I have been know to
goof up upon occasion.

I just did a quick look to see what kmemleak is.  A conservative
tracing leak detector sounds interesting.  Except for all of the list
heads which lead to container_of calls I don't know of anything in the
struct pid implementation that would be difficult for it to work with.
Well that and there is some rcu access protection which can delay the
free by a bit.

 The /sbin/init application calls sys_clone() a few times but only one
 leak is reported (see below). Looking at the reported pid object (at
 0xc7c14500), count is 2 and nr is 296 but no process with pid 296
 exists any more.

It could still be a valid session or a process group id.
If you examine the struct pid you can test for this be examining all
of the list heads it keeps.  If there is something on any of the
lists that would account a count of 1.  How we have a count of 2
I don't have enough information to guess.

Core tty layer handling stops having an remembering pids when the
session or process group exits so it is relatively safe from pid wrap
around issues without my changes and should make the kind of thing you
are reporting very unlikely in a correctly functioning system.

In most any other layer we cache pids indefinitely and a situation
where we have a pointer to a struct pid with a ref count of 1 long
after the process goes away is expected.  In this case it is better
to hold a reference to a struct pid so we don't do the wrong thing
when pid wrap around occurs then to hold a reference to an entire
task_struct and lock that in place.

I don't understand your situation enough to guess what is going wrong
yet.  Hopefully I have given you enough information to get started.


 unreferenced object 0xc7c14500 (size 36):
  comm init, pid 245, jiffies 4294939289
  backtrace:
[c0070c18] kmem_cache_alloc
[c003a528] alloc_pid
[c0026468] do_fork
[c00153b0] sys_clone
[c0010f80] ret_fast_syscall

I think this is the path that all pid structures come from so
unfortunately that doesn't help tracing this problem down.

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: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Dmitriy Monakhov
Mimi Zohar [EMAIL PROTECTED] writes:

 This patch places calls to the new integrity hooks in the appropriate
 places in the fs directory. It is not meant in any way to be viewed
 as a complete set, but used as a basis for an initial discussion.

 Index: linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/ext3/xattr_security.c
 +++ linux-2.6.21-rc3-mm2/fs/ext3/xattr_security.c
 @@ -10,6 +10,7 @@
  #include linux/ext3_jbd.h
  #include linux/ext3_fs.h
  #include linux/security.h
 +#include linux/integrity.h
  #include xattr.h
  
  static size_t
 @@ -58,12 +59,19 @@ ext3_init_security(handle_t *handle, str
  
   err = security_inode_init_security(inode, dir, name, value, len);
   if (err) {
 + /* Even if creation of the security xattr fails, must
 +  * indicate this is a new inode. */
 + integrity_inode_init_integrity(inode, dir, NULL, NULL, NULL);
   if (err == -EOPNOTSUPP)
   return 0;
   return err;
   }
 block begin
   err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
   name, value, len, 0);
 +
 + integrity_inode_init_integrity(inode, dir, name, value, len);
 + err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
 + name, value, len, 0);
 block end
May be i've missed something, but i don't get last block.
Why you call ext3_xattr_set_handle() twise?, 
or you just mistyped and  it has to look like this:
block_begin

+   integrity_inode_init_integrity(inode, dir, name, value, len);
err = ext3_xattr_set_handle(handle, inode, EXT3_XATTR_INDEX_SECURITY,
name, value, len, 0);
block_end
   kfree(name);
   kfree(value);
   return err;
 Index: linux-2.6.21-rc3-mm2/include/linux/fs.h
 ===
 --- linux-2.6.21-rc3-mm2.orig/include/linux/fs.h
 +++ linux-2.6.21-rc3-mm2/include/linux/fs.h
 @@ -591,6 +591,9 @@ struct inode {
  #ifdef CONFIG_SECURITY
   void*i_security;
  #endif
 +#ifdef CONFIG_INTEGRITY
 + void*i_integrity;
 +#endif
   void*i_private; /* fs or device private pointer */
  };
  
 Index: linux-2.6.21-rc3-mm2/fs/dcache.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/dcache.c
 +++ linux-2.6.21-rc3-mm2/fs/dcache.c
 @@ -29,6 +29,7 @@
  #include linux/file.h
  #include asm/uaccess.h
  #include linux/security.h
 +#include linux/integrity.h
  #include linux/seqlock.h
  #include linux/swap.h
  #include linux/bootmem.h
 @@ -986,6 +987,7 @@ void d_instantiate(struct dentry *entry,
   entry-d_inode = inode;
   fsnotify_d_instantiate(entry, inode);
   spin_unlock(dcache_lock);
 + integrity_d_instantiate(entry, inode);
   security_d_instantiate(entry, inode);
  }
  
 @@ -1050,6 +1052,7 @@ struct dentry *d_instantiate_unique(stru
   spin_unlock(dcache_lock);
  
   if (!result) {
 + integrity_d_instantiate(entry, inode);
   security_d_instantiate(entry, inode);
   return NULL;
   }
 @@ -1187,6 +1190,7 @@ struct dentry *d_splice_alias(struct ino
   BUG_ON(!(new-d_flags  DCACHE_DISCONNECTED));
   fsnotify_d_instantiate(new, inode);
   spin_unlock(dcache_lock);
 + integrity_d_instantiate(new, inode);
   security_d_instantiate(new, inode);
   d_rehash(dentry);
   d_move(new, dentry);
 @@ -1197,6 +1201,7 @@ struct dentry *d_splice_alias(struct ino
   dentry-d_inode = inode;
   fsnotify_d_instantiate(dentry, inode);
   spin_unlock(dcache_lock);
 + integrity_d_instantiate(dentry, inode);
   security_d_instantiate(dentry, inode);
   d_rehash(dentry);
   }
 @@ -1748,6 +1753,7 @@ found:
   spin_unlock(dcache_lock);
  out_nolock:
   if (actual == dentry) {
 + integrity_d_instantiate(dentry, inode);
   security_d_instantiate(dentry, inode);
   return NULL;
   }
 Index: linux-2.6.21-rc3-mm2/fs/file_table.c
 ===
 --- linux-2.6.21-rc3-mm2.orig/fs/file_table.c
 +++ linux-2.6.21-rc3-mm2/fs/file_table.c
 @@ -13,6 +13,7 @@
  #include linux/smp_lock.h
  #include linux/fs.h
  #include linux/security.h
 +#include linux/integrity.h
  #include linux/eventpoll.h
  #include linux/rcupdate.h
  #include linux/mount.h
 @@ -169,6 +170,7 @@ void fastcall __fput(struct file *file)
   if (file-f_op  file-f_op-release)
   file-f_op-release(inode, file);
 

Re: [SLUB 0/3] SLUB: The unqueued slab allocator V4

2007-03-08 Thread Christoph Lameter
On Thu, 8 Mar 2007, Mel Gorman wrote:

  Note that the 16kb page size has a major 
  impact on SLUB performance. On IA64 slub will use only 1/4th the locking 
  overhead as on 4kb platforms.
 It'll be interesting to see the kernbench tests then with debugging
 disabled.

You can get a similar effect on 4kb platforms by specifying slub_min_order=2 on 
bootup.
This means that we have to rely on your patches to allow higher order 
allocs to work reliably though. The higher the order of slub the less 
locking overhead. So the better your patches deal with fragmentation the 
more we can reduce locking overhead in slub.

-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message 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 PATCH] repost I/OAT fixes

2007-03-08 Thread Christopher Leech
I/OAT fixes and missing documentation.

Please pull from,
git://lost.foo-projects.org/~cleech/linux-2.6#master

--

Andrew Morton (1):
  I/OAT: warning fix

Chris Leech (6):
  ioatdma: Push pending transactions to hardware more frequently
  ioatdma: Remove the wrappers around read(bwl)/write(bwl) in ioatdma
  ioatdma: Remove the use of writeq from the ioatdma driver
  I/OAT: Add documentation for the tcp_dma_copybreak sysctl
  I/OAT: Add entries to MAINTAINERS for the DMA memcpy subsystem and ioatdma
  I/OAT: Only offload copies for TCP when there will be a context switch

Dan Aloni (1):
  I/OAT: fix I/OAT for kexec

Jeff Garzik (1):
  drivers/dma: handle sysfs errors


 Documentation/networking/ip-sysctl.txt |6 +
 MAINTAINERS|   12 +++
 drivers/dma/dmaengine.c|   22 +-
 drivers/dma/ioatdma.c  |   81 --
 drivers/dma/ioatdma_io.h   |  118 -
 net/ipv4/tcp.c |   26 +--
 6 files changed, 100 insertions(+), 165 deletions(-)

commit 3ac82a51550c649c67f42f218e5d1ccc4e865685
Author: Dan Aloni [EMAIL PROTECTED]
Date:   Thu Mar 8 09:57:36 2007 -0800

I/OAT: fix I/OAT for kexec

Under kexec, I/OAT initialization breaks over busy resources because the
previous kernel did not release them.

I'm not sure this fix can be considered a complete one but it works for me.
 I guess something similar to the *_remove method should occur there..

Signed-off-by: Dan Aloni [EMAIL PROTECTED]
Signed-off-by: Chris Leech [EMAIL PROTECTED]
Signed-off-by: Andrew Morton [EMAIL PROTECTED]

diff --git a/drivers/dma/ioatdma.c b/drivers/dma/ioatdma.c
index cbf93ca..1d259e5 100644
--- a/drivers/dma/ioatdma.c
+++ b/drivers/dma/ioatdma.c
@@ -41,6 +41,7 @@
 
 /* internal functions */
 static int __devinit ioat_probe(struct pci_dev *pdev, const struct 
pci_device_id *ent);
+static void ioat_shutdown(struct pci_dev *pdev);
 static void __devexit ioat_remove(struct pci_dev *pdev);
 
 static int enumerate_dma_channels(struct ioat_device *device)
@@ -557,6 +558,7 @@ static struct pci_driver ioat_pci_drv = {
.name   = ioatdma,
.id_table = ioat_pci_tbl,
.probe  = ioat_probe,
+   .shutdown = ioat_shutdown,
.remove = __devexit_p(ioat_remove),
 };
 
@@ -781,9 +783,20 @@ err_request_regions:
 err_set_dma_mask:
pci_disable_device(pdev);
 err_enable_device:
+
+   printk(KERN_ERR Intel(R) I/OAT DMA Engine initialization failed\n);
+
return err;
 }
 
+static void ioat_shutdown(struct pci_dev *pdev)
+{
+   struct ioat_device *device;
+   device = pci_get_drvdata(pdev);
+
+   dma_async_device_unregister(device-common);
+}
+
 static void __devexit ioat_remove(struct pci_dev *pdev)
 {
struct ioat_device *device;

commit 1fa77931067fac6fb2fa01008854da9c77cdcd87
Author: Andrew Morton [EMAIL PROTECTED]
Date:   Thu Mar 8 09:57:36 2007 -0800

I/OAT: warning fix
net/ipv4/tcp.c: In function 'tcp_recvmsg':
net/ipv4/tcp.c:: warning: unused variable 'available'

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

diff --git a/net/ipv4/tcp.c b/net/ipv4/tcp.c
index 5ccd5e1..69c525d 100644
--- a/net/ipv4/tcp.c
+++ b/net/ipv4/tcp.c
@@ -1110,7 +1110,6 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, 
struct msghdr *msg,
long timeo;
struct task_struct *user_recv = NULL;
int copied_early = 0;
-   int available = 0;
struct sk_buff *skb;
 
lock_sock(sk);
@@ -1139,15 +1138,22 @@ int tcp_recvmsg(struct kiocb *iocb, struct sock *sk, 
struct msghdr *msg,
tp-ucopy.dma_chan = NULL;
preempt_disable();
skb = skb_peek_tail(sk-sk_receive_queue);
-   if (skb)
-   available = TCP_SKB_CB(skb)-seq + skb-len - (*seq);
-   if ((available  target) 
-   (len  sysctl_tcp_dma_copybreak)  !(flags  MSG_PEEK) 
-   !sysctl_tcp_low_latency  __get_cpu_var(softnet_data).net_dma) {
-   preempt_enable_no_resched();
-   tp-ucopy.pinned_list = dma_pin_iovec_pages(msg-msg_iov, len);
-   } else
-   preempt_enable_no_resched();
+   {
+   int available = 0;
+
+   if (skb)
+   available = TCP_SKB_CB(skb)-seq + skb-len - (*seq);
+   if ((available  target) 
+   (len  sysctl_tcp_dma_copybreak)  !(flags  MSG_PEEK) 
+   !sysctl_tcp_low_latency 
+   __get_cpu_var(softnet_data).net_dma) {
+   preempt_enable_no_resched();
+   tp-ucopy.pinned_list =
+   dma_pin_iovec_pages(msg-msg_iov, len);
+   } else {
+   preempt_enable_no_resched();
+   }
+   }
 #endif
 
do {


Re: [RFC][Patch 2/6] integrity: fs hook placement

2007-03-08 Thread Mimi Zohar
On Thu, 2007-03-08 at 09:40 -0800, Chris Wright wrote:
 * Serge E. Hallyn ([EMAIL PROTECTED]) wrote:
  Are you objecting only to the duplication at the callsites, so that an
  fsnotify-type of consolidation of security and integrity hooks would be
  ok?  Or are you complaining that the security_inode_setxattr and
  integrity_inode_setxattr hooks are too similar anyway, and integrity
  modules should just use some lsm hooks for anything which will be
  authoritative?
 
 It's duplication of callsites with many identical implementations
 that's the problem.

  (I could see an argument that integirty subsystem should be purely for
  measuring and hence its hooks should never return a value.  Only hitch
  there is that if integrity subsystem hits ENOMEM it should be able to
  refuse the action...)
 
 Right, that's what I was expecting to see, just the measurement
 infrastructure.

There are a total of 10 Linux Integrity Module(LIM) hooks. Seven of
which parallel the LSM hooks, out of the ~150 LSM hooks.  3 of the LIM
hooks are for initializing, allocating, and freeing the inode-
i_integrity, used for caching integrity information.  As the integrity
information is stored as extended attributes, 2 hooks are for catching
changes to the extended attributes, one is for updating the extended
attributes when the file closes, and d_instantiate is used for
initialization.  Is this excessive?  How else would you design
integrity, without using the LSM hooks?

Mimi Zohar


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


/dev/null implementation question

2007-03-08 Thread Michael Nitschinger
Hello,

I asked myself how /dev/null is implemented in C, but i didn't find anything in 
the documentation or generally on the internet. It would be great if someone 
could tell me where i can find the source for this device or how it is 
implemented, because it's really hard for me to crawl through the whole 
sourcetree.

thanks in advance, kind regards
Michael Nitschinger

(p.s.: it would be great if you can Cc me in your answers because i am not 
subscribed to the mailinglist! 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/


[PATCH] VFS : Delay the dentry name generation on sockets and pipes.

2007-03-08 Thread Eric Dumazet
Hi Andrew

I am sorry, my previous patch had a /proc/*/fd/ in a comment, so the */ closed 
the comment and fs/dcache.c could not compile.

Could you please put this 'final-final' version in mm for testing ?

Thank's to all contributors, sorry for the noise.

[PATCH] VFS : Delay the dentry name generation on sockets and pipes.

1) Introduces a new method in 'struct dentry_operations'. This method called 
d_dname() might be called from d_path() to build a pathname 
for special filesystems. It is called without locks.

Future patches (if we succeed in having one common dentry for all 
pipes/sockets) may need to change prototype of this method, but we now use :
char *d_dname(struct dentry *dentry, char *buffer, int buflen);


2) Use this new method for sockets : No more sprintf() at socket creation. 
This is delayed up to the moment someone does an access to /proc/pid/fd/...

3) Use this new method for pipes : No more sprintf() at pipe creation. This is 
delayed up to the moment someone does an access to /proc/pid/fd/...

A benchmark consisting of 1.000.000 calls to pipe()/close()/close() gives a 
*nice* speedup on my Pentium(M) 1.6 Ghz :

3.090 s instead of 3.450 s

Signed-off-by: Eric Dumazet [EMAIL PROTECTED]
Acked-by: Christoph Hellwig [EMAIL PROTECTED]
Acked-by: Linus Torvalds [EMAIL PROTECTED]

 Documentation/filesystems/Locking |    2 ++
 Documentation/filesystems/vfs.txt |   12 +++-
 fs/dcache.c                       |   10 ++
 fs/pipe.c                         |   15 +--
 include/linux/dcache.h            |    1 +
 net/socket.c                      |   17 ++---
 6 files changed, 43 insertions(+), 14 deletions(-)
--- linux-2.6.21-rc3/include/linux/dcache.h 2007-03-07 17:23:55.0 
+0100
+++ linux-2.6.21-rc3-ed/include/linux/dcache.h  2007-03-08 11:57:41.0 
+0100
@@ -133,6 +133,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)(struct dentry *, char *, int);
 };
 
 /* the dentry parameter passed to d_hash and d_compare is the parent
--- linux-2.6.21-rc3/Documentation/filesystems/vfs.txt  2007-03-08 
10:14:38.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/vfs.txt   2007-03-08 
12:08:56.0 +0100
@@ -827,7 +827,7 @@ This describes how a filesystem can over
 operations. Dentries and the dcache are the domain of the VFS and the
 individual filesystem implementations. Device drivers have no business
 here. These methods may be set to NULL, as they are either optional or
-the VFS uses a default. As of kernel 2.6.13, the following members are
+the VFS uses a default. As of kernel 2.6.22, the following members are
 defined:
 
 struct dentry_operations {
@@ -837,6 +837,7 @@ struct dentry_operations {
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)(struct dentry *, char *, int);
 };
 
   d_revalidate: called when the VFS needs to revalidate a dentry. This
@@ -859,6 +860,15 @@ struct dentry_operations {
VFS calls iput(). If you define this method, you must call
iput() yourself
 
+  d_dname: called when the pathname of a dentry should be generated.
+   Usefull for some pseudo filesystems (sockfs, pipefs, ...) to delay
+   pathname generation. (Instead of doing it when dentry is created,
+   its done only when the path is needed.). Real filesystems probably
+   dont want to use it, because their dentries are present in global
+   dcache hash, so their hash should be an invariant. As no lock is
+   held, d_dname() should not try to modify the dentry itself, unless
+   appropriate SMP safety is used.
+
 Each dentry has a pointer to its parent dentry, as well as a hash list
 of child dentries. Child dentries are basically like files in a
 directory.
--- linux-2.6.21-rc3/Documentation/filesystems/Locking  2007-03-08 
10:29:04.0 +0100
+++ linux-2.6.21-rc3-ed/Documentation/filesystems/Locking   2007-03-08 
12:08:56.0 +0100
@@ -15,6 +15,7 @@ prototypes:
int (*d_delete)(struct dentry *);
void (*d_release)(struct dentry *);
void (*d_iput)(struct dentry *, struct inode *);
+   char *(*d_dname)((struct dentry *dentry, char *buffer, int buflen);
 
 locking rules:
none have BKL
@@ -25,6 +26,7 @@ d_compare:no  yes no  
no 
 d_delete:  yes no  yes no
 d_release: no  no  no  yes
 d_iput:no  no  no  yes
+d_dname:   no  no  no  no
 
 --- inode_operations --- 
 prototypes:
--- linux-2.6.21-rc3/fs/dcache.c2007-03-07 

  1   2   3   4   5   6   >