Re: libata: Fix host-simplex_claimed != ap typo
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
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
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
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
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
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
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 ...
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
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
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
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
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
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
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
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
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
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 ...
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
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
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
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
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
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
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
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
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.
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 ...
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
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
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.
--- [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
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 ...
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]
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
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
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
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
* 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 ...
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
(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
* 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
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()
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
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
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
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
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
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
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/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/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
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/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
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
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
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!
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!
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
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
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
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.
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 ...
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
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.
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
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
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
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
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
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
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
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
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
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 ...
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
* 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'
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
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 ...
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
(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?
* 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
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
* 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
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
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
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
* 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'
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
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
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
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
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
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
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
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
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
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
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
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.
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
