This fixes various gpio-related build errors (mostly potential) reported in part by Russell King and Uwe Kleine-König. Signed-off-by: David Brownell <dbrownell@users.sourceforge.net> --- Refreshed version -- should apply OK on top of the gpio sysfs support include/asm-generic/gpio.h | 6 +++++- include/linux/gpio.h | 3 +++ 2 files changed, 8 insertions(+), 1 deletion(-) --- a/include/asm-generic/gpio.h 2008-05-20 11:46:13.000000000 -0700 +++ ...

A lot of small stuff: 1) Pull in wireless bug fixes from John Linville. 2) Kill CVS keywords from ATM code, from Adrian Bunk and ACK'd by ATM maintainer. 3) skb->truesize not maintained properly my l2tp code, fix from James Chapman. 4) IPSEC can crash on output path due to wrong output routine usage, fix from Herbert Xu. 5) Fix pktgen shutdown race, from Denis Lunev. 6) Zap cli/sti from hysdn driver, and no longer mark broken on SMP. From Mark Asselstine and Andrew ...

Two things going on here: 1) Add a "sysrq y" global register dumping facility that works even when CPUs are stuck with interrupts disabled. I've used this often enough myself, and given it to users to debug problems, that it deserves to be upstream. 2) Patches from Adrian Bunk to delete all the old CVS Id tags, I've been doing them gradually when touching specific files, but it's just as good to kill them all if he's done the work already. Please pull, thanks a ...

Thanks for reporting this. Al already reported it and a fix is in ocfs2.git. We change the name entirely so that grep of user_stack doesn't match it at all. Joel -- "Nobody loves me, Nobody seems to care. Troubles and worries, people, You know I've had my share." Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --

This patch removes the dead CONFIG_TTY_LOG (no kconfig option). Reported-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- arch/um/kernel/exec.c | 12 -- arch/um/os-Linux/Makefile | 3 arch/um/os-Linux/tty_log.c | 217 ------------------------------------- 3 files changed, 232 deletions(-) 531b7c113d8deed217fb800cdd3f610899fbc0d9 diff --git a/arch/um/kernel/exec.c b/arch/um/kernel/exec.c index f5d7f45..598711c 100644 --- ...

Here are some USB patches for your 2.6.25-git tree. They include: - bugfixes - new device ids - removing a device id from one driver and putting it in the correct one. - a new driver, cdc-wdm, for wireless USB modems and phones. This driver is self-contained and should cause no new problems. This is the majority of the diffstat below. Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/gregkh/usb-2.6.git/ All of these patches have been in the -mm tree for a ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/core/hcd.c | 6 +++--- 1 files changed, 3 insertions(+), 3 ...

Here are some patches against your 2.6.26-rc3-git tree. They fix a race condition when device_create is called. At that point in time sysfs files can be created automatically by the class or the driver subsystem, and if those files are opened before the device specific data is set, oopses can happen. This was found and reported for the bdi subsystem by Arthur Jones and he verified that these patches fix the problem. I then went and audited all users of the api and found other places where ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). It fixes the problem in all of the scsi drivers that need it. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Doug Gilbert <dgilbert@interlog.com> Cc: James E.J. Bottomley ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: James Simmons <jsimmons@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/video/display/display-sysfs.c ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Acked-by: Bartlomiej Zolnierkiewicz <bzolnier@gmail.com> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/ide/ide-probe.c ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_drvdata(). Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Anton Vorontsov <cbou@mail.ru> Cc: David Woodhouse <dwmw2@infradead.org> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- ...

There is a race from when a device is created with device_create() and then the drvdata is set with a call to dev_set_drvdata() in which a sysfs file could be open, yet the drvdata will be NULL, causing all sorts of bad things to happen. This patch fixes the problem by using the new function, device_create_vargs(). Many thanks to Arthur Jones <ajones@riverbed.com> for reporting the bug, and testing patches out. Cc: Kay Sievers <kay.sievers@vrfy.org> Cc: Arthur Jones ...

Print out the dev->name only after register_netdev(). If the dev->name is printk()ed out before calling register_netdev() the result will be "eth%d" in the dmesg instead of "eth0". Signed-off-by: Márton Németh <nm127@freemail.hu> --- --- linux-2.6.26-rc3/drivers/net/smc-ultra.c.orig 2008-04-17 04:49:44.000000000 +0200 +++ linux-2.6.26-rc3/drivers/net/smc-ultra.c 2008-05-20 22:04:15.000000000 +0200 @@ -228,9 +228,6 @@ static int __init ultra_probe1(struct ne for (i = 0; i < 6; i++) ...

Michael Halcrow wrote: [snip] Hi, Why not: if (!(req->flags & ECRYPTFS_REQ_ZOMBIE)) dget(req->lower_dentry); mntget(req->lower_mnt); (*req->lower_file) = dentry_open( req->lower_dentry, req->lower_mnt, (O_RDWR | O_LARGEFILE)); req->flags |= ECRYPTFS_REQ_PROCESSED; wake_up_process(req->requesting_task); } --

Hi all, I have linux 2.4.25 on a mips processor. Other than my application, the other processes that are running on the system are udhcpd, dhcpd, mini_dns etc. The applicaiton is quite memory intensive, it has allocated 5 MB of a buffer which acts as a queue and the applicaiton queues and de-queues packets in the queue at frequents intervals. The memory for this buffer is allocated just once when the application starts at the time of boot. So I would assume that there would be quite a lot of ...

Ah, I guess ARM is a bit more critical of chpxchg than x86 is. I'll add a patch for 2.6.24.7-rt9 (which I plan on releasing soon). It will have some minor clean ups. -- Steve --

This came up on the Freescale list. I should have put what I wrote there into my patch descrition: It's the _le versions that have a problem, since we can't get gcc to just use the register indexed mode. It seems like an obvious thing to have a constraint for, but I guess there weren't enough instructions that only come in 'x' versions to bother with it. There is a 'Z' constraint, "Memory operand that is an indexed or indirect from a register", but I tried it and it can use both "rb,ri" ...

What about memory obtained from dma_alloc_coherent()? We still need a sync and a compiler barrier. The current I/O accessors have the former, but not the latter. -Scott --

From: Scott Wood <scottwood@freescale.com> Indeed, and even the GCC manual is clear about this. --

There is the "Z" constraint, which matches either an indirect or an indexed memory address. That should fit here. Andreas. -- Andreas Schwab, SuSE Labs, schwab@suse.de 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." --

We probably want a full "memory" clobber then... Ben. --

It's too bad gas doesn't appear to be smart enough to turn: stwbrx 0, 0(3) -or- stwbr 0, 0(3) into the desired: stwbrx 0, 0, 3 --

It looks like we rely on -fno-strict-aliasing to prevent reordering ordinary memory accesses (such as to DMA descriptors) past the I/O access. It won't prevent reordering of memory reads around an I/O read, though, which could be a problem if the I/O read result determines the validity of the DMA buffer. IMHO, a memory clobber would be better. -Scott --

As far as I could tell, no other arch has a full memory clobber. I can see the argument for changing the Linux model to be stricter and less efficient, but easier to program for. Not that I entirely agree with it. But I don't see a good reason for why powerpc should be different than everything else. --

Hello Steven, Now I started looking at compiling 2.6.24.7-rt8 for ARM, and I found another compile problem... ;-)) This one: CC arch/arm/kernel/process.o arch/arm/kernel/process.c: In function 'cpu_idle': arch/arm/kernel/process.c:175: error: implicit declaration of function 'trace_preempt_exit_idle' arch/arm/kernel/process.c:180: error: implicit declaration of function 'trace_preempt_enter_idle' These function do not appear to exist _anywhere_ in the kernel. So these calls can ...

I observed the following problems with 2.6.26-rcX-gitY: Steady-steady I got segmentation faults. On 2.6.25.4 no problems. I compiled plenty times the newer kernels to find out the reason. I thing the problem is the memory configuration as > 4 GB. In my config file, since earlier kernels, i configured >4 GB. When I use config files with that, then occure the problems, with <4 GB not. It seems that the menuconfig of the new kernels accept only until 4 GB. Another problem with the fore2000 atm ...

-tip testing found the following build failure: LD .tmp_vmlinux1 drivers/built-in.o: In function `generic_set_freq': tuner-xc2028.c:(.text+0xbd896): undefined reference to `request_firmware' tuner-xc2028.c:(.text+0xbdd7a): undefined reference to `release_firmware' drivers/built-in.o: In function `xc_load_fw_and_init_tuner': xc5000.c:(.text+0xc68e6): undefined reference to `request_firmware' xc5000.c:(.text+0xc6abe): undefined reference to `release_firmware' with this ...

From: Harvey Harrison <harvey.harrison@gmail.com> But what you're doing in the first patch is killing performance for some cases. The reason we use the cpu_to_*p() interfaces is to get the other-endian load and store instructions some processors have. What you're doing is undoing all of that work we've done to take advantage of such things. --

From: Harvey Harrison <harvey.harrison@gmail.com> Why are we fiddling with interface names that have been fine for about 10 years? --

From: Harvey Harrison <harvey.harrison@gmail.com> Can you provide some contextual information in the changelog message? Why are the cpu_to_*p() uses going away? Do the normal cpu_to_*() now transparently emit the special other-endian loads and stores some cpus? You should always describe such things in your changelog message so people don't need to ask these kinds of questions. --

If it loses its firmwrare, it'll reattach with the old ID. -- Matthew Garrett | mjg59@srcf.ucam.org --

Uninitialised Apple iSight drivers present with a distinctive USB ID. Once firmware has been uploaded, they disconnect and reconnect with a new ID. At this point they can be driven by the uvcvideo driver. As this is unique to the Apple cameras and not functionality shared by any other UVC devices, it makes sense to provide the firmware loading functionality in a separate driver. This driver will read an isight.fw file extracted from the Apple driver using the tools at ...

您2008想5給21心愛的另ㄧ半ㄧ份21驚5喜2008嗎？ 近5來5看5看，試5試5這5個5喔 ^.^ 珍9珠9貝9殼9項9鍊9禮9盒　～　日9本9九9州9空9運9來9台 網址在這→203.70.179.39/ju←複製這行網址貼上即可 ∴←▽←↓

From: "Greg Steuck" <greg@nest.cx> No, it does not. netfilter-devel@vger.kernel.org is the correct place to discuss this, added to CC:. Perhaps you sent this to plain "netfilter@vger.kernel.org" or the --

I upgraded to 2.6.25.3-18.fc9.x86_64 fedora core 9, now I get this error when I try to login to the box, kill a pr start a python app, or do anything on a regular basis. fork: Resource temporarily unavailable I have over 10GB RAM free, and zero swap spaced used. The box is a dual quad core Intel Xeon 5405 with 16GB RAM. There is no error message in /var/log/messages or dmesg ... how do I identify the problem? thanks! uname -a Linux XXX 2.6.25.3-18.fc9.x86_64 #1 SMP Tue May 13 04:54:47 ...

[Empty message]

I'm attempting to use /proc/lock_stat to gather some information during some benchmarking runs, but what I find happens is as follows: 1. I boot the system - 2.6.26-rc3 kernel + CONFIG_LOCK_STAT=y 2. I can then look at /proc/lock_stat, and it has valid-looking values 3. I wait a while, do some stuff, but when I look at /proc/lock_stat again the values have not changed. 4. If I clear the counters - echo 0 > /proc/lock_stat - the counters never increase, and no information besides the ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/scsi/aacraid/commsup.c | 8 ++++---- drivers/scsi/aic94xx/aic94xx_scb.c | 4 ++-- drivers/scsi/aic94xx/aic94xx_task.c | 8 ++++---- drivers/scsi/stex.c | 2 +- include/scsi/sas.h | 2 +- 5 files changed, 12 insertions(+), 12 deletions(-) diff --git a/drivers/scsi/aacraid/commsup.c b/drivers/scsi/aacraid/commsup.c index 289304a..2dcdaf0 100644 --- ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- fs/affs/bitmap.c | 14 +++++++------- fs/affs/super.c | 2 +- 2 files changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/affs/bitmap.c b/fs/affs/bitmap.c index c4a5ad0..3df7327 100644 --- a/fs/affs/bitmap.c +++ b/fs/affs/bitmap.c @@ -92,14 +92,14 @@ affs_free_block(struct super_block *sb, u32 block) data = (__be32 *)bh->b_data + bit / 32 + 1; /* mark block free */ - tmp = be32_to_cpu(*data); + tmp = ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- fs/ntfs/collate.c | 4 ++-- fs/ntfs/compress.c | 9 ++++----- fs/ntfs/endian.h | 6 +++--- fs/ntfs/mst.c | 2 +- fs/ntfs/super.c | 2 +- 5 files changed, 11 insertions(+), 12 deletions(-) diff --git a/fs/ntfs/collate.c b/fs/ntfs/collate.c index 4a28ab3..d370931 100644 --- a/fs/ntfs/collate.c +++ b/fs/ntfs/collate.c @@ -52,8 +52,8 @@ static int ntfs_collate_ntofs_ulong(ntfs_volume *vol, // FIXME: ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- arch/parisc/lib/iomap.c | 4 ++-- arch/powerpc/sysdev/qe_lib/qe.c | 2 +- arch/sparc64/kernel/unaligned.c | 8 ++++---- arch/sparc64/lib/PeeCeeI.c | 6 +++--- 4 files changed, 10 insertions(+), 10 deletions(-) diff --git a/arch/parisc/lib/iomap.c b/arch/parisc/lib/iomap.c index 9abed07..ac2f0eb 100644 --- a/arch/parisc/lib/iomap.c +++ b/arch/parisc/lib/iomap.c @@ -278,7 +278,7 @@ unsigned int ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- fs/ext3/super.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/fs/ext3/super.c b/fs/ext3/super.c index fe3119a..1dbae0f 100644 --- a/fs/ext3/super.c +++ b/fs/ext3/super.c @@ -2595,8 +2595,8 @@ static int ext3_statfs (struct dentry * dentry, struct kstatfs * buf) buf->f_ffree = percpu_counter_sum_positive(&sbi->s_freeinodes_counter); es->s_free_inodes_count = cpu_to_le32(buf->f_ffree); ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- fs/xfs/xfs_log.c | 4 ++-- fs/xfs/xfs_log_priv.h | 6 +++--- fs/xfs/xfs_log_recover.c | 9 ++++----- fs/xfs/xfs_mount.c | 12 ++++++------ 4 files changed, 15 insertions(+), 16 deletions(-) diff --git a/fs/xfs/xfs_log.c b/fs/xfs/xfs_log.c index afaee30..b90325d 100644 --- a/fs/xfs/xfs_log.c +++ b/fs/xfs/xfs_log.c @@ -1529,7 +1529,7 @@ xlog_sync(xlog_t *log, */ for (i = 0; i < split; i += ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- fs/hfsplus/wrapper.c | 6 +++--- fs/isofs/compress.c | 4 ++-- fs/partitions/acorn.c | 2 +- fs/qnx4/inode.c | 2 +- fs/reiserfs/super.c | 2 +- 5 files changed, 8 insertions(+), 8 deletions(-) diff --git a/fs/hfsplus/wrapper.c b/fs/hfsplus/wrapper.c index 175d08e..0e2fd86 100644 --- a/fs/hfsplus/wrapper.c +++ b/fs/hfsplus/wrapper.c @@ -35,17 +35,17 @@ static int hfsplus_read_mdb(void *bufptr, struct ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/usb/c67x00/c67x00-hcd.c | 4 ++-- drivers/usb/core/devio.c | 12 ++++++------ drivers/usb/gadget/net2280.c | 2 +- drivers/usb/host/ehci.h | 6 ++---- drivers/usb/host/isp116x-hcd.c | 4 ++-- drivers/usb/host/ohci.h | 16 ++++++---------- drivers/usb/host/uhci-hub.c | 6 +++--- drivers/usb/misc/auerswald.c | 2 +- drivers/usb/serial/garmin_gps.c | 9 ++++----- ...

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- drivers/block/cciss.c | 11 +++++------ drivers/block/paride/pd.c | 8 ++++---- drivers/block/ub.c | 4 ++-- 3 files changed, 11 insertions(+), 12 deletions(-) diff --git a/drivers/block/cciss.c b/drivers/block/cciss.c index e336b05..5e5d39a 100644 --- a/drivers/block/cciss.c +++ b/drivers/block/cciss.c @@ -1513,8 +1513,7 @@ static int rebuild_lun_table(ctlr_info_t *h, struct gendisk *del_disk) 0, ...

Acked-by: David Dillow <dave@thedillows.org> --

Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- crypto/ccm.c | 6 +++--- crypto/crc32c.c | 4 ++-- crypto/lrw.c | 2 +- crypto/michael_mic.c | 4 ++-- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/crypto/ccm.c b/crypto/ccm.c index 7cf7e5a..9fdc2db 100644 --- a/crypto/ccm.c +++ b/crypto/ccm.c @@ -150,11 +150,11 @@ static int format_adata(u8 *adata, unsigned int a) * RFC 3610 and NIST Special Publication 800-38C */ if ...

Acked-by: David Brownell <dbrownell@users.sourceforge.net> ... should make it into 2.6.26-final, but this is evidently --

Please pull the PCI fixes: git pull git://git.kernel.org/pub/scm/linux/kernel/git/jbarnes/pci-2.6.git for-linus We're still tracking down a couple of PCI hotplug regressions (there's a new delay at probe time and drivers fighting over ports), so this won't be the last pull request, but I wanted to get this HP fix upstream. This pull also includes an update for the PCI error list entry in MAINTAINERS; I forgot to update it when linux-pci@ moved. Thanks, Jesse Jesse Barnes (1): PCI: ...

[Michael Halcrow - Tue, May 20, 2008 at 01:27:57PM -0500] | On Tue, May 20, 2008 at 09:03:21PM +0400, Cyrill Gorcunov wrote: | > it seems there is a few potential race window in eCryptFS which I | > was trying to fix but it requires more deeper eCrypFS knowledge that | > have (at least only by understanding eCryptFS in big picture it is | > possible to fix this problem by elegant path). So what is the | > problem - the procedures | > | > ecryptfs_miscdev_poll | > ecryptfs_miscdev_read | > ...

[Michael Halcrow - Tue, May 20, 2008 at 01:27:57PM -0500] | On Tue, May 20, 2008 at 09:03:21PM +0400, Cyrill Gorcunov wrote: | > it seems there is a few potential race window in eCryptFS which I | > was trying to fix but it requires more deeper eCrypFS knowledge that | > have (at least only by understanding eCryptFS in big picture it is | > possible to fix this problem by elegant path). So what is the | > problem - the procedures | > | > ecryptfs_miscdev_poll | > ecryptfs_miscdev_read | > ...

When a small page mapping is created with mmap() reservations are created by default for any memory pages required. When the region is read/write the reservation is increased for every page, no reservation is needed for read-only regions (as they implicitly share the zero page). Reservations are tracked via the VM_ACCOUNT vma flag which is present when the region has reservation backing it. When we convert a region from read-only to read-write new reservations are aquired and VM_ACCOUNT is ...

Looking at this, it's taking the address of the struct lock_class_key as the actual key. Thus, if we tie one of these guys to the structure we're representing, we get lock safety...except that we're talking about i_mutex here, and we want to interact with the VFS's use thereof. Joel -- "There is no sincerer love than the love of food." - George Bernard Shaw Joel Becker Principal Software Developer Oracle E-mail: joel.becker@oracle.com Phone: (650) 506-8127 --

On Tue, 20 May 2008 18:33:20 +0200 I'm... not entirely happy with such a solution ;( there must be a better one. --

Hi all, The following patches fix lockdep warnings resulting from (correct) recursive locking in configfs. Current lockdep annotations for inode mutexes in configfs are lockdep-friendly provided that: 1/ config_groups have at most one level of default groups (see configfs_attach_group()), 2/ config_groups having default groups are never removed (see configfs_detach_prep()). Since lockdep does not handle such correct recursion, the idea is to insert lockdep_off()/lockdep_on() for ...

We're trying to find it. I really appreciate Louis taking the time to approach the issue. His first pass was to add 1 to MUTEX_CHILD for each level of recursion. This has a very tight limit (4 or 5 levels), but probably covers all users that exist and perhaps all that ever will exist. However, it means passing the lockdep annotation level throughout the entire call chain across multiple files. It was definitely less readable. This approach takes a different tack - it's very readable, ...

When destroying a config_group having default groups, lockdep raises a warning because multiple locks of class I_MUTEX_NORMAL are taken in configfs_detach_prep() (the first one being in vfs_rmdir()). However this recursive locking is another instance of I_MUTEX_PARENT -> I_MUTEX_CHILD dependency, which was already checked correct when creating the config_group, and which lockdep cannot handle cleanly because of the variable depth. This patch silences lockdep when destroying default groups by ...

When creating a config_group, the CONFIGFS_USET_DEFAULT flag of default sub-groups is only known after create_default_group() finishes its work, that is after having creating the whole sub-hierarchy. In order to track which lock to hide from lockdep, we need to known whether a config_group is default earlier, that is before creating the sub-hierarchy. This patch adds a def_group flag to configfs_attach_group(), which allows configfs_attach_group to set the CONFIGFS_USET_DEFAULT flag before ...

[Cyrill Gorcunov - Tue, May 20, 2008 at 08:39:28PM +0400] | We should lock/unlock mutexes by a proper way which means | there should not be chains like ABAB but ABBA otherwise the | race window is opened. | | Signed-off-by: Cyrill Gorcunov <gorcunov@gmail.com> | CC: Michael A. Halcrow <mhalcrow@us.ibm.com> | --- | | check_list: [...] | if (list_empty(&daemon->msg_ctx_out_queue)) { NIT ---> | + if (mutex_is_locked(&ecryptfs_daemon_hash_mux)) | ...

您2008想5給21心愛的另ㄧ半ㄧ份21驚5喜2008嗎？ 近31來31看31看，試31試31這31個31喔 ^.^ 珍9珠9貝9殼9項9鍊9禮9盒　～　日9本9九9州9空9運9來9台 網址在這→203.70.179.39/ju←複製這行網址貼上即可 ◇▼↖⊙↑

After patch 2 in this series, a process that successfully calls mmap() for a MAP_PRIVATE mapping will be guaranteed to successfully fault until a process calls fork(). At that point, the next write fault from the parent could fail due to COW if the child still has a reference. We only reserve pages for the parent but a copy must be made to avoid leaking data from the parent to the child after fork(). Reserves could be taken for both parent and child at fork time to guarantee faults but if the ...

This release is mainly a rebase. Ideally, this would be reviewed from the perspective of "is this desirable and useful behaviour for hugepage applications" as well as general correctness. If reactions are positive or there are no objections, I'll attempt a push towards -mm for wider testing. As it is, they are passing basic tests as well as a slightly-modified libhugetlbfs regression test. Changelog since V2 o Rebase to 2.6.26-rc2-mm1 o Document when hugetlb_lock is held for reserve counter ...

testing of the -tip tree found the following module build failure on latest -git: Building modules, stage 2. MODPOST 421 modules ERROR: "dib7000p_attach" [drivers/media/video/cx23885/cx23885.ko] undefined! make[1]: *** [__modpost] Error 1 make: *** [modules] Error 2 with the following config: http://redhat.com/~mingo/misc/config-Tue_May_20_17_13_32_CEST_2008.bad the problem is caused that ./drivers/media/video/cx23885/cx23885-dvb.c depends on a DVB_DIB7000P ...

Add a new fops entry point to allow fasync without BKL. While it's arguably unclear this entry point is called often enough for it really matters it was still relatively easy to do. And there are far less async users in the tree than ioctls so it's likely they can be all converted eventually and then the non unlocked async entry point could be dropped. There was still the problem of the actual flags change being protected against other setters of flags. Instead of using BKL for this use the ...

That's the goal actually to "get stuck with it" and ->fasync going away. -Andi --

I guess my one concern with this mirrors what other people have said: might not it be better to just push the BKL down into the fasync() implementations and avoid adding yet another file operation? A quick grep shows 43 drivers defining fasync() functions - and many of those use the same one. fs/ has a few more. Obnoxious but doable, unless there's something I'm missing? Thanks, jon --

Just uses fasync_helper Signed-off-by: Andi Kleen <ak@linux.intel.com> --- drivers/char/rtc.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/drivers/char/rtc.c =================================================================== --- linux.orig/drivers/char/rtc.c +++ linux/drivers/char/rtc.c @@ -913,7 +913,7 @@ static const struct file_operations rtc_ .ioctl = rtc_ioctl, .open = rtc_open, .release = rtc_release, - .fasync = ...

Mostly saves some code size and cleans up the code after Roland's recent changes. Please ack or nack. -Andi --

See my reply to Arjan. While for complicated stuff pushing down first is better, fasync is not that complicated and I think my strategy with the new entry point, with the old one going away is better in this case. -Andi --

What do you find ugly exactly? The prefix "unlocked_" ? Other than that there is no difference. Duplicated entry points are not great, but they will be going away. -Andi --

- Replace remote_llseek with generic_file_llseek_unlocked (to force compilation failures in all users) - Change all users to either use generic_file_llseek_unlocked directly or take the BKL around. I changed the file systems who don't use the BKL for anything (CIFS, GFS) to call it directly. NCPFS and SMBFS and NFS take the BKL, but explicitely in their own source now. I moved them all over in a single patch to avoid unbisectable sections. Open problem: 32bit kernels can corrupt fpos ...

Doesn't need BKL because it just uses fasync_helper and minor->dev is protected by the file reference count. Cc: airlied@linux.ie Signed-off-by: Andi Kleen <ak@linux.intel.com> --- drivers/char/drm/i810_dma.c | 2 +- drivers/char/drm/i810_drv.c | 2 +- drivers/char/drm/i830_dma.c | 2 +- drivers/char/drm/i830_drv.c | 2 +- drivers/char/drm/i915_drv.c | 2 +- drivers/char/drm/mga_drv.c | 2 +- drivers/char/drm/r128_drv.c | 2 +- ...

Just uses fasync_helper which does its own locking Cc: mpm@selenic.com Signed-off-by: Andi Kleen <ak@linux.intel.com> --- drivers/char/random.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) Index: linux/drivers/char/random.c =================================================================== --- linux.orig/drivers/char/random.c +++ linux/drivers/char/random.c @@ -1121,7 +1121,7 @@ const struct file_operations random_fops .write = random_write, .poll = ...

Not that it matters much, but it was easy. Signed-off-by: Andi Kleen <ak@suse.de> Signed-off-by: Andi Kleen <ak@linux.intel.com> --- fs/bad_inode.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) Index: linux/fs/bad_inode.c =================================================================== --- linux.orig/fs/bad_inode.c +++ linux/fs/bad_inode.c @@ -174,7 +174,7 @@ static const struct file_operations bad_ .release = bad_file_release, .fsync = bad_file_fsync, ...

Hi Ingo, Steven, Thomas, The following series are the scraps from adaptive-locks-v3 that have not yet been pulled into RT. This series applies to 25.4-rt2. For the most part, this is the difference between adaptive-v3 and whats in the upstream tree, with the following exceptions: 1) I have fixed an issue in the "optimize-wakeup" patch that went out in v3. There was a hunk left-over from when we applied adaptive to both spinlocks and mutexes. We have since dropped ...

From: Peter W. Morreale <pmorreale@novell.com> Remove the redundant attempt to get the lock. While it is true that the exit path with this patch adds an un-necessary xchg (in the event the lock is granted without further traversal in the loop) experimentation shows that we almost never encounter this situation. Signed-off-by: Peter W. Morreale <pmorreale@novell.com> Signed-off-by: Gregory Haskins <ghaskins@novell.com> --- kernel/rtmutex.c | 6 ------ 1 files changed, 0 insertions(+), ...

It is redundant to wake the grantee task if it is already running, and the call to wake_up_process is relatively expensive. If we can safely skip it we can measurably improve the performance of the adaptive-locks. Credit goes to Peter Morreale for the general idea. Signed-off-by: Gregory Haskins <ghaskins@novell.com> Signed-off-by: Peter Morreale <pmorreale@novell.com> --- kernel/rtmutex.c | 45 ++++++++++++++++++++++++++++++++++++++++----- 1 files changed, 40 insertions(+), 5 ...

Yes, it should have been mechanic, but I guess I was not careful I don't think I can split it into 20 changes, but I should be able to split it into 3 or so, and make them trivial enough to be bug free. (In fact, there were only about 20 lines of "real" changes in in this huge changelog). I'll produce better patches. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

I'm implementing suspend/resume for Xen at the moment. It's all going well, but I'm getting this WARN_ON: ------------[ cut here ]------------ WARNING: at /home/jeremy/hg/xen/paravirt/linux/kernel/hrtimer.c:635 hres_timers_resume+0x33/0x56() Modules linked in: Pid: 1397, comm: kstopmachine Tainted: G W 2.6.26-rc2-sched-devel.git #94 [<c102e87d>] warn_on_slowpath+0x41/0x5d [<c10477a1>] ? clockevents_program_event+0x105/0x10d [<c1047dd3>] ? tick_resume+0x5c/0x61 [<c100145d>] ? ...

Working on it. --

That worked. Console output is sane again. --

Thanks!! That worked. Now I just have to get highmem support... --

I'm hoping to see some patches related to these fixes :) - k --

And if I disable NAPI I get this one instead: Bringing up the eth1 interface...Unable to handle kernel paging request for data at address 0x00000000 Faulting instruction address: 0xc019706c Oops: Kernel access of bad area, sig: 11 [#1] PREEMPT Innovative Systems ApMax Modules linked in: NIP: c019706c LR: c0196d84 CTR: c0198790 REGS: ef2c3cb0 TRAP: 0300 Not tainted (2.6.25.4-rt1) MSR: 00009032 <EE,ME,IR,DR> CR: 42004222 XER: 00000000 DAR: 00000000, DSISR: 20000000 TASK = ef2ac590[114] ...

Hello Nadia, Regarding your: [PATCH 1/8] Scaling msgmni to the amount of lowmem http://article.gmane.org/gmane.linux.kernel/637849/ which I see has made its way in 2.6.26-rc Your patch has the following change: -#define MSGPOOL (MSGMNI*MSGMNB/1024) /* size in kilobytes of message pool */ +#define MSGPOOL (MSGMNI * MSGMNB) /* size in bytes of message pool */ Since this constitutes a kernel-userland interface change, so please do CC me, so that I can change the man pages if ...

[Fixing the bad list address in my initial mail: CC += linux-mm@kvack.org] On the one hand, I'd be inclined to leave things as they were pre 2.6.26. On the other hand, I believe that on other systems that have the limit, msgpool is a limit in bytes. (But documentation of these details on other systems is very thin on the ground.) I wonder if anyone else has some knowledge here? -- Michael Kerrisk Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/ Found a bug? ...

On Tue, May 20, 2008 at 04:27:17PM +0200, Pavel Machek wrote: > +static inline int aperture_valid(u64 aper_base, u32 aper_size, u32 min_size) > +{ > + if (!aper_base) > + return 0; > + > + if (aper_base + aper_size > 0x100000000ULL) { > + printk(KERN_ERR "Aperture beyond 4GB. Ignoring.\n"); > + return 0; > + } > + if (e820_any_mapped(aper_base, aper_base + aper_size, E820_RAM)) { > + printk(KERN_ERR "Aperture pointing to e820 RAM. Ignoring.\n"); > + return 0; > + } > ...

On Tue, May 20, 2008 at 05:32:15PM +0200, Pavel Machek wrote: > > Instead of making this an inline, we could add it to the agpgart code > > and export it, and have the gart-iommu code call it. > > You can't build the IOMMU code without agpgart anyway, and having this inlined > > in both places seems a bit wasteful. > > Additionally, it would mean not having a function in a header file, > > which always strikes me as a wrong thing to do. > > Can you elaborate? Yes, it would be nicer if ...

Hi Steven, If you need an ARM cross compiler, you can for example use ptxdist to setup an OSELAS.Toolchain: http://www.pengutronix.de/oselas/toolchain/index_en.html The current well tested revisions are based on 4.1.2, but -trunk does also contain (work-in-progress) top-of-tree versions. rsc -- Dipl.-Ing. Robert Schwebel | http://www.pengutronix.de Pengutronix - Linux Solutions for Science and Industry Handelsregister: Amtsgericht Hildesheim, HRA 2686 Hannoversche Str. ...

No idea right off the bat. But I may be needing to set up a ARM crosscompiler. Unless Thomas would like to take a look into this. Thomas? -- Steve --

CCing lkml Thanks. I agree that is a good place. But, here CONFIG_GENERIC_CMOS_UPDATE is defined and an i2c clock also, and my rtc clock is not updated. I see kernel/time/ntp.c::sync_cmos_clock calling arch/powerpc/kernel/time.c::update_persistent_clock, where ppc_md.set_rtc_time is NULL. Who is supposed to initialize ppc_md.set_rtc_time to use an i2c clock and when in the boot process may that happen ? Or alternatively, should update_persistent_clock not be part of the ...

From: Arjan van de Ven <arjan@linux.intel.com> Subject: [PATCH] Replace a printk + WARN_ON() to a WARN() Replace a printk+WARN_ON() by a WARN(); this increases the chance of the string making it into the bugreport (eg it goes inside the ---[ cute here ]--- section) Signed-off-by: Arjan van de Ven <arjan@linux.intel.com> --- kernel/irq/manage.c | 4 +--- 1 files changed, 1 insertions(+), 3 deletions(-) diff --git a/kernel/irq/manage.c b/kernel/irq/manage.c index 46d6611..e296f67 ...

Isn't that superflous, as mempool_create() -> kmalloc(..., __GFP_WAIT) ends up spewing that warning anyway? -- Jens Axboe --

On Tue, 20 May 2008 21:29:59 +0200 It's largely superfluous given the way in which Arjan implemented it. One situation which we regularly hit is: foo() { ... if (some_unlikely_condition()) do_something_which_sleeps(); ... } and then we go and call that code under spinlock and ship it out, when of course a handful of testers hit the unlikely condition. The solution to that is to add a might_sleep() _outside_ the test of some_unlikely_condition(). ie: --- ...

On Tue, 20 May 2008 12:45:56 -0700 the sata_nv driver calls this from an invalid context ... and spews a ton of warnings as a result... made me think this is a common mistake to make. I'd love to make it do your version instead, but I was afraid it would trigger too often.... --

It looks like some problem with interrupt routing. At least with some of the PIIX chips I recall there was some limitation about how the IDE interrupts had to be used for DMA to be operational. For PIO modes there were no restrictions. Do you have chip-level documentation for your board? Maciej --

<stern@rowland.harvard.edu>, Greg KH <greg@kroah.com> Bcc: Subject: Re: [Bug #10630] USB devices plugged into dock are not discoverred until reload of ehci-hcd Reply-To: In-Reply-To: <200805201327.34678.oliver@neukum.org> X-echelon: NSA, CIA, CI5, MI5, FBI, KGB, BIS, Plutonium, Bin Laden, bomb Hm, without USB_SUSPEND it works. So what next, considered fixed or any further investigation is needed? -- Lukáš Hejtmánek --

seems to be working, device is detected. Thanks. Please, push the patch. -- Lukáš Hejtmánek --

It is by no means fixed! Now we find out what exactly doesn't work. Please apply this patch and provide "dmesg -c" before you plug in the device and after that. Regards Oliver --- --- linux-2.6.25/drivers/usb/host/ehci-hcd.c 2008-05-20 10:07:45.585199135 +0200 +++ alt/drivers/usb/host/ehci-hcd.c 2008-05-20 11:11:53.614580823 +0200 @@ -712,11 +712,15 @@ static irqreturn_t ehci_irq (struct usb_ unsigned i = HCS_N_PORTS (ehci->hcs_params); pcd_status = status; ...

Hi All, There has one MV64460 on my board, which includes 2 PCI bridges. PIIX4 is on slot 3 of PCI1. But now, IDE driver reported it's timeouted on DMA operation. Thanks in advance for your suggestions. Resources of PIIX4 function 1 ===================== 0001:00:03.1: idx=0 flags=0x20000110 start=0x00000000 end=0x00000007 0001:00:03.1: idx=1 flags=0x20000110 start=0x00000000 end=0x00000000 0001:00:03.1: idx=2 flags=0x20000110 start=0x00000000 end=0x00000007 0001:00:03.1: idx=3 ...

Hi, This patch is for cleaning up the code of the cgroup memory subsystem to remove a lot of "#ifdef"s. Signed-off-by: Hirokazu Takahashi <taka@valinux.co.jp> diff -dupr linux-2.6.26-rc2.cg1/mm/memcontrol.c linux-2.6.26-rc2/mm/memcontrol.c --- linux-2.6.26-rc2.cg1/mm/memcontrol.c 2008-05-19 12:33:32.000000000 +0900 +++ linux-2.6.26-rc2/mm/memcontrol.c 2008-05-19 12:34:16.000000000 +0900 @@ -228,6 +228,47 @@ struct mem_cgroup *mem_cgroup_from_task( struct mem_cgroup, css); } ...

Hi all, With this series of patches, you can determine the owners of any type of I/Os. I ported the previous version to linux-2.6.26-rc2-mm1. This makes dm-ioband -- I/O bandwidth controller -- be able to control the Block I/O bandwidths even when it accepts delayed write requests. Dm-ioband can find the owner cgroup of each request. It is also possible that OpenVz team and NEC Uchida-san team working on the CFQ scheduler use this functionality to control asynchronous I/Os with a little ...

Um, why? What stops you from reverting the offending commit? Without further info, I'd assume the feature was removed on policy grounds. I.e. it's not nice to be effectively patching the BIOS yourself, and vendors have fixed most of their BIOS's / linux is slightly more tolerant to broken ones. I don't know whats wrong with reading files from the initrd. Alan --

Gabriel --

looks good - thanks Avi - i've added your patch to the -tip tree. I have opened a separate topic for it: tip/safe-poison-pointers. (because it affects other architectures as well) Ingo --

Don't make it exactly 0xffffc10000000000 but 0xffffc10000000000 + 0x1000000 or so, otherwise list_entry() users which subtract offsets would still end up in user space and there might be actually something in there by default. -Andi --

Looks right, and mmap_min_addr is in mainline, just with a value of zero. So, it looks like the right thing to do is read the value of /proc/sys/vm/mmap_min_addr and start bottom there. Jeff -- Work email - jdike at linux dot intel dot com --

Yup. Can you try three things: check the maps file for any arbitrary process (i.e. /proc/$$/maps) and see if there's anything mapped at 0 gdb UML, stop it at that mmap, check its maps file and see if there's anything mapped at 0 send me a pointer to the patches that Ubuntu has applied on top of the stock kernel - I'm suspicious that they special-cased page zero in order to ensure that NULL pointer dereferences cause faults. You can test this last theory by initializing bottom to 4096 ...

Hi, I've just recently pulled the latest GIT and compiled UML, however, when I run it a message appears saying "Locating the top of the address space... Address 0x0 no good?" and the program exits. After some digging, it appears that page_ok is returning false when checking 'bottom', in os_get_task_size (arch/um/os-Linux/sys-i386/task_size.c:96). After running through GDB, it seems that in line 31 of that file is where the segfault occurs: n = *address; i.e. when trying to read from ...

Okay, then instead of putting a NULL in the "hint" to mmap() try something else (0x1000?). That may help. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The information transmitted in this message is confidential and may be privileged. Any review, retransmission, dissemination, or other use of this information by persons or ...

The segfaults are on purpose - it will trap SIGSEGV and longjmp out of the handler and mark the affected address as not-usable. Jeff -- Work email - jdike at linux dot intel dot com --

Here's the new patch, with that size correction in. Does this look okay? --- From: Tom Spink <tspink@gmail.com> Date: Wed, 21 May 2008 00:53:54 +0100 Subject: [PATCH] Read the minimum mmap address from proc This patch makes os_get_task_size read the minimum mmap address from the proc entry on the host system, if available. If not, it resorts to manually searching for the minimum mmap address by incrementally testing pages from zero onwards. Because the bottom of the address space ...

We're operating from userspace here. In any case, this hasn't happened with any kernel I've seen, but I'm suspicious that Ubuntu has started treating page zero specially. Jeff -- Work email - jdike at linux dot intel dot com --

Does this mean that I cannot mmap() address zero in the kernel anymore? I should be able (in the kernel) read anything, and then mmap() it to something usable in user-space. If address zero is now artifically trapped there are problems being created for no good reason at all. Cheers, Dick Johnson Penguin : Linux version 2.6.22.1 on an i686 machine (5588.29 BogoMips). My book : http://www.AbominableFirebug.com/ _ **************************************************************** The ...

Linus, Please pull from the 'merge' branch of git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge to get a collection of small fixes and a defconfig update for powerpc, plus an update to MAINTAINERS for the Cell port. Thanks, Paul. MAINTAINERS | 23 ++- arch/powerpc/boot/.gitignore | 8 - arch/powerpc/boot/Makefile | 6 + arch/powerpc/boot/dts/mpc8377_mds.dts | 18 ++ ...

From: Heiko Carstens <heiko.carstens@de.ibm.com> Trying to add memory via add_memory() from within an initcall function results in bootmem alloc of 163840 bytes failed! Kernel panic - not syncing: Out of memory This is caused by zone_wait_table_init() which uses system_state to decide if it should use the bootmem allocator or not. When initcalls are handled the system_state is still SYSTEM_BOOTING but the bootmem allocator doesn't work anymore. So the allocation will fail. To fix this ...

On Tue, May 20, 2008 at 07:51:32PM +0900, Magnus Damm wrote: Uwe Kleine-Koenig already submitted such a framework: http://lkml.org/lkml/2008/5/20/94 It's his third version, and it looks good. I presume you didn't know about his work. The main difference is that he leaves interrupt handling to platform code. That might look strange (it did to me first), but it has the advantage that you can put hardware dependent stuff in your board support (which depends on hardware anyway). Could you ...

These patches implement a reusable UIO platform driver. This driver can be used to export hardware to user space, as long as the device is a) memory mapped and b) equipped with an unique IRQ. The uio_platform driver gets all information through platform data, including address window information and IRQ number. The driver also supports assigning a contiguous piece of memory to each instance. This may be useful when the exported hardware blocks can bus master but requires physically contiguous ...

This patch implements a reusable UIO platform driver. Only memory mapped hardware devices with unique IRQs are supported. Signed-off-by: Magnus Damm <damm@igel.co.jp> --- Tested using the VEU on a SuperH sh7722. drivers/uio/Kconfig | 10 ++ drivers/uio/Makefile | 1 drivers/uio/uio_platform.c | 161 ++++++++++++++++++++++++++++++++++++++++++ include/linux/uio_platform.h | 10 ++ 4 files changed, 182 insertions(+) --- 0001/drivers/uio/Kconfig +++ ...

Hi Stephen, The next-20080520 kernel build fails on powerpc, when build the randconfig with build error message CC arch/powerpc/kernel/prom_init.o CALL arch/powerpc/kernel/prom_init_check.sh Error: External symbol 'kernstart_addr' referenced from prom_init.c make[1]: *** [prom_init_check] Error 1 make: *** [arch/powerpc/kernel] Error 2 -- Thanks & Regards, Kamalesh Babulal, Linux Technology Center, IBM, ISTL.

When booting 2.6.26-rc3 on a multi-node x86_32 numa system we are seeing panics when trying node local allocations: BUG: unable to handle kernel NULL pointer dereference at 0000034c IP: [<c1042507>] get_page_from_freelist+0x4a/0x18e *pdpt = 00000000013a7001 *pde = 0000000000000000 Oops: 0000 [#1] SMP Modules linked in: Pid: 0, comm: swapper Not tainted (2.6.26-rc3-00003-g5abc28d #82) EIP: 0060:[<c1042507>] EFLAGS: 00010282 CPU: 0 EIP is at get_page_from_freelist+0x4a/0x18e EAX: ...

Hi Jonathan, Bad idea. Grouping drivers by connectivity is almost always the wrong thing to do, as it means that different persons will maintain them and they have all chances to diverge. You really want to group drivers by functionality. On top of that, I am busy enough maintaining the i2c core and bus drivers without having more i2c device drivers added to my Probably not the wisest choice, if nothing else, because the hwmon maintainer is already overloaded. And I don't think that these ...

FWIW: I have this device talking to a PIC-18 and pushing the results over the serial port. WRT linux support, I can't think of a generalized way to create a driver that would be able to be used with this device in Linux. You need to know witch IRQ line the DR line is connected too, and if you are bit-banging the SPI data off the thing, then you need to know which GPIO's of the host CPU you'll be using. If you have SPI hardware then you need to know where to pull the data from. The problem ...

When allocating the pgdat's for numa nodes on x86_32 we attempt to place them in the numa remap space for that node. However should the node not have any remap space allocated (such as due to having non-ram pages in the remap location in the node) then we will incorrectly place the pgdat at zero. Check we have remap available, falling back to node 0 memory where we do not. Signed-off-by: Andy Whitcroft <apw@shadowen.org> Acked-by: Mel Gorman <mel@csn.ul.ie> --- arch/x86/mm/discontig_32.c ...

applied to -tip, thanks Andy. Ingo --

kobject: '<NULL>' (ffffffffa0104050): is not initialized, yet kobject_put() is being called. ------------[ cut here ]------------ WARNING: at /home/den/src/linux-netns26/lib/kobject.c:583 kobject_put+0x53/0x55() Modules linked in: ipv6 nfsd lockd nfs_acl auth_rpcgss sunrpc exportfs ide_cd_mod cdrom button [last unloaded: pktgen] comm: rmmod Tainted: G W 2.6.26-rc3 #585 Call Trace: [<ffffffff802359ab>] warn_on_slowpath+0x58/0x7a [<ffffffff80236aca>] ? printk+0x67/0x69 ...

fl_insert and fl_remove are not used right now in the kernel. Remove them. Signed-off-by: Denis V. Lunev <den@openvz.org> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Alexander Viro <viro@zeniv.linux.org.uk> Cc: linux-fsdevel <linux-fsdevel@vger.kernel.org> --- fs/locks.c | 6 ------ include/linux/fs.h | 2 -- 2 files changed, 0 insertions(+), 8 deletions(-) diff --git a/fs/locks.c b/fs/locks.c index 11dbf08..dce8c74 100644 --- a/fs/locks.c +++ b/fs/locks.c @@ -561,9 +561,6 @@ ...

From: "Denis V. Lunev" <den@openvz.org> Patch applied, thanks a lot Denis! --

The following courruption can happen during pktgen stop: list_del corruption. prev->next should be ffff81007e8a5e70, but was 6b6b6b6b6b6b6b6b kernel BUG at lib/list_debug.c:67! :pktgen:pktgen_thread_worker+0x374/0x10b0 ? autoremove_wake_function+0x0/0x40 ? _spin_unlock_irqrestore+0x42/0x80 ? :pktgen:pktgen_thread_worker+0x0/0x10b0 kthread+0x4d/0x80 child_rip+0xa/0x12 ? restore_args+0x0/0x30 ? kthread+0x0/0x80 ? child_rip+0x0/0x12 RIP ...

From: Bob Peterson <rpeterso@redhat.com> This patch fixes a GFS2 filesystem consistency error reported from function do_strip. The problem was caused by a timing window that allowed two vfs inodes to be created in memory that point to the same file. The problem is fixed by making the vfs's iget_test, iget_set mechanism check and set a new bit in the in-core gfs2_inode structure while the vfs inode spin_lock is held. Signed-off-by: Bob Peterson <rpeterso@redhat.com> Signed-off-by: Steven ...

Hi, Here is a set of three patches which constitute the current set of fixes for GFS2. They are all fairly minor changes, but useful nonetheless, Steve. --

From: Andrew Price <andy@andrewprice.me.uk> This fixes bz 444829 where allocating a new block caused gfs2 file systems to report 0 bytes used in df. It was caused by a broken cast from an unsigned int in gfs2_block_alloc() to a negative s64 in gfs2_statfs_change(). This patch casts the unsigned int to an s64 before the unary minus is applied. Signed-off-by: Andrew Price <andy@andrewprice.me.uk> Signed-off-by: Steven Whitehouse <swhiteho@redhat.com> diff --git a/fs/gfs2/rgrp.c ...

[Please first apply the patch 1/3 before this] To please lockdep here we use class_reclassify to change the lock class of sg_sysfs_class Signed-off-by: Dave Young <hidave.darkstar@gmail.com> --- drivers/scsi/sg.c | 2 ++ 1 file changed, 2 insertions(+) --- linux/drivers/scsi/sg.c 2008-05-19 12:41:05.000000000 +0800 +++ linux.new/drivers/scsi/sg.c 2008-05-19 14:08:19.000000000 +0800 @@ -1579,6 +1579,8 @@ init_sg(void) rc = PTR_ERR(sg_sysfs_class); goto err_out; ...

On Tue, May 20, 2008 at 6:02 PM, Andrew Morton I agree. There's wellmeant lockdep warnings for some safe code logic every some time. Yes, this macro violates the lockdep class-based rules, but it can act My wrong, thanks. Regards dave --

That's what I suggested (in a thread you were cc'd on, but probably aren't reading). I don't like this reclassify thing either. -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step." --

Well what are these lockdep warnings? Normally such a warning means that we have a locking bug. I _assume_ that you've determined that the warnings are false-positives? The warning which Mariusz Kozlowski discovered ("Subject: Re: 2.6.26-rc2-mm1: possible circular locking dependency detected") was triggered by the "class semaphore to mutex" conversion and it looks like a real bug to me. Would your patch prevent warnings such as that one from being available to us? --

On Tue, 20 May 2008 11:36:41 -0600 rofl. All pertinent information should be in a patch's changelog. Then this Well that sounds reasonable. I'm not sure that we should introduce generic-looking helper infrastructure to do it, however. Anyway I'll happily sit back and let you guys and Greg sort this one out ;) --

From: "Rami Rosen" <ramirose@gmail.com> I think it is better to delete this code. It is impossible for anyone to build test it without making source modifications, therefore it will continute to break over and over again over time. --

您2008想5給20心愛的另ㄧ半ㄧ份20驚5喜2008嗎？ 近27來27看27看，試27試27這27個27喔 ^.^ 珍34珠34貝34殼34項34鍊34禮34盒　～　日34本34九34州34空34運34來34台 網址在這→203.70.179.39/ju←複製這行網址貼上即可 ▽⊕⊕∵◆

the only delta between the 8 patches you posted here and tip/x86/ptemask topic is the comment below - so we are indeed on the safe side. Ingo -----------------> diff --git a/include/asm-x86/pgtable.h b/include/asm-x86/pgtable.h index 21fed4f..97c271b 100644 --- a/include/asm-x86/pgtable.h +++ b/include/asm-x86/pgtable.h @@ -57,6 +57,7 @@ #define _KERNPG_TABLE (_PAGE_PRESENT | _PAGE_RW | _PAGE_ACCESSED | \ _PAGE_DIRTY) +/* Set of bits not changed in pte_modify */ #define ...

The thing is, making _PAGE_FOO be a signed long in no way guarantees any appropriately sized masks. Why? Because 'long' mixes with 'unsigned long' and in the C type system, unsigned is stronger than signed. As a result, if you depend on sign-extension of things like a binary 'not' operation, you're always going to have cases where it simply doesn't work, just because you happen to mix it up with other things that may have type 'unsigned long' (or, on 32-bit, 'unsigned int' which ...

[ Repost due to screwed up mail headers. ] Hi all, Here's a series to rationalize the use of PTE_MASK and remove some amount of ad-hocery. This gist of the series is: 1. Fix the definition of PTE_MASK so that its equally applicable in all pagetable modes 2. Use it consistently I haven't tried to address the *_bad() stuff, other than to convert pmd_bad_* to use PTE_MASK. This series has had some testing in the x86.git tree, and hasn't shown any problems. Each patch is more or ...

Use PTE_MASK to extract mfn from pte. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/xen/page.h | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/include/asm-x86/xen/page.h b/include/asm-x86/xen/page.h --- a/include/asm-x86/xen/page.h +++ b/include/asm-x86/xen/page.h @@ -127,7 +127,7 @@ static inline unsigned long pte_mfn(pte_t pte) { - return (pte.pte & ~_PAGE_NX) >> PAGE_SHIFT; + return (pte.pte & PTE_MASK) >> ...

--- include/asm-x86/pgtable_32.h | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/include/asm-x86/pgtable_32.h b/include/asm-x86/pgtable_32.h --- a/include/asm-x86/pgtable_32.h +++ b/include/asm-x86/pgtable_32.h @@ -88,7 +88,7 @@ /* To avoid harmful races, pmd_none(x) should check only the lower when PAE */ #define pmd_none(x) (!(unsigned long)pmd_val((x))) #define pmd_present(x) (pmd_val((x)) & _PAGE_PRESENT) -#define pmd_bad(x) ((pmd_val(x) & (~PAGE_MASK & ...

Put the definitions of __(VIRTUAL|PHYSICAL)_MASK before their uses. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/page.h | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/include/asm-x86/page.h b/include/asm-x86/page.h --- a/include/asm-x86/page.h +++ b/include/asm-x86/page.h @@ -9,6 +9,9 @@ #define PAGE_MASK (~(PAGE_SIZE-1)) #ifdef __KERNEL__ + +#define __PHYSICAL_MASK ((phys_addr_t)(1ULL << ...

Define PTE_MASK so that it contains a meaningful value for all x86 pagetable configurations. Previously it was defined as a "long" which means that it was too short to cover a 32-bit PAE pte entry. It is now defined as a pteval_t, which is an integer type long enough to contain a full pte (or pmd, pud, pgd). Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- include/asm-x86/page.h | 13 +++++++++---- 1 file changed, 9 insertions(+), 4 deletions(-) diff --git ...

yep, this has been problem-free in x86.git and then in -tip, we had a separate x86/ptemask topic for it that we originally intended for v2.6.27, and we dont mind to see it upstream now ;-) Ingo --

Does anyone have a better idea ? == Currently, cgroup's seq_file interface just supports single_open. This patch allows arbitrary seq_ops if passed. For example, "status per cpu, status per node" can be very big in general and they tend to use its own start/next/stop ops. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- include/linux/cgroup.h | 9 +++++++++ kernel/cgroup.c | 32 +++++++++++++++++++++++++++++--- 2 files changed, 38 insertions(+), 3 ...

Add a documentation for memory resource controller's files. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Index: mm-2.6.26-rc2-mm1/Documentation/controllers/memory_files.txt =================================================================== --- /dev/null +++ mm-2.6.26-rc2-mm1/Documentation/controllers/memory_files.txt @@ -0,0 +1,76 @@ +Files under memory resource controller and its resource counter. +(See controllers/memory.txt about memory resource ...

Acked-by: Pavel Emelyanov <xemul@openvz.org> --

On Tue, May 20, 2008 at 2:08 AM, KAMEZAWA Hiroyuki As a way of printing plain text files, it seems fine. My concern is that it means that cgroups no longer has any idea about the typing of the data being returned, which will make it harder to integrate with a binary stats API. You'd end up having to have a separate reporting method for the same data to use it. That's why the "read_map" function specifically doesn't take a seq_file, but instead takes a key/value callback abstraction, which ...

From: Michael Hennerich <michael.hennerich@analog.com> remove duplicate code. Signed-off-by: Michael Hennerich <michael.hennerich@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/mtd/devices/m25p80.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/drivers/mtd/devices/m25p80.c b/drivers/mtd/devices/m25p80.c index b10649b..7f89b54 100644 --- a/drivers/mtd/devices/m25p80.c +++ b/drivers/mtd/devices/m25p80.c @@ -122,8 +122,6 @@ static int ...

Comparing with 2.6.26-rc1, hackbench has about 30% regression with 2.6.26-rc2 on my tulsa machine which is a netburst architecure hyper-threading x86_64. Command line to test: #hackbench 100 process 2000 With 2.6.26-rc1, it takes 30 seconds. But with 2.6.26-rc2/rc3, it takes 40 seconds. Bisect located below patch: 46151122e0a2e80e5a6b2889f595e371fe2b600d is first bad commit commit 46151122e0a2e80e5a6b2889f595e371fe2b600d Author: Mike Galbraith <efault@gmx.de> Date: Thu May 8 17:00:42 ...

Nope, I keep the patches separate and then fold them prior to sending to Linus. I marked this as for-2.6.26 as it's clearly non-injurious to existing stuff. should probably be using CONFIG_foo but that might not work if it's to be preprocessed by userspace. I didn't look. Plus that'd be off-topic. --

Does the problem arise due to the change of inclusion order of asm/serial.h (from after 8250.h to before 8250.h) ? -- ------------------------------------------------------------------------ Javier Herrero EMAIL: jherrero@hvsistemas.com HV Sistemas S.L. PHONE: +34 949 336 806 Los Charcones, 17A FAX: +34 949 336 792 19170 El Casar - Guadalajara - Spain WEB: http://www.hvsistemas.com --

The above commit contains the following patch: | --- a/drivers/serial/8250.c | +++ b/drivers/serial/8250.c | @@ -43,6 +43,7 @@ | | #include <asm/io.h> | #include <asm/irq.h> | +#include <asm/serial.h> | | #include "8250.h" | | @@ -92,8 +93,6 @@ static unsigned int nr_uarts = CONFIG_SERIAL_8250_RUNTIME_UARTS; | */ | #define CONFIG_HUB6 1 | | -#include <asm/serial.h> | - | /* | * SERIAL_PORT_DFNS tells us about built-in ports that have no | * standard enumeration ...

Yes. It was placed where it was because of the dependencies of asm/serial.h on the code between the two places. The alternative solution is to get rid of the CONFIG_* compatibility and update those asm/serial.h which reference the old symbols. However, that's a larger patch. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --

The list macros use LIST_POISON1 and LIST_POISON2 as undereferencable pointers in order to trap erronous use of freed list_heads. Unfortunately userspace can arrange for those pointers to actually be dereferencable, potentially turning an oops to an expolit. To avoid this allow architectures (currently x86_64 only) to override the default values for these pointers with truly-undereferncable values. This is easy on x86_64 as the virtual address space is smaller than the range spanned by pointer ...

On Mon, 2008-05-19 at 14:44 -0700, bugme-daemon@bugzilla.kernel.org I know. The problem was that I didn't know if this was due to the drm, video, acpi or x86... so it seems that is quite restricted now. To resume (see http://bugzilla.kernel.org/show_bug.cgi?id=10620 ) - VT switching is broken after gnome has started (acceleration?) - the symptom is that the X VT stays black, which just the cursor (and sometime some residual bit of the panel) shown. - it happens almost all the time with ...

We are pleased to announce the 2.6.24.7-rt8 tree, which can be downloaded from the location: http://rt.et.redhat.com/download/ Information on the RT patch can be found at: http://rt.wiki.kernel.org/index.php/Main_Page Changes since 2.6.24.7-rt7 - Read Write locks with multiple readers (Steven Rostedt) The previous versions of the RT tree would serialize the RW locks for all readers to allow for priority inheritance to take place. This change allows for multiple readers but ...

you don't need to set that bit again... YH --

Yes, that would be nicer. As to the alias; "nopat" hasn't been in a released kernel yet so should be okay to do away with? It's not like it's in Documentation/kernel-parameters.txt or anything... ;-/ Rene. --

On Tue, May 20, 2008 at 03:42:49PM -0700, H. Peter Anvin wrote: > > Yes, that would be nicer. As to the alias; "nopat" hasn't been in a > > released kernel yet so should be okay to do away with? It's not like > > it's in Documentation/kernel-parameters.txt or anything... ;-/ > > > > OK, just double-checked... since it's not in Linus we can still change > it, and as so I'd suggest the pat= option. Not boot-tested, but it compiles for me.. I also folded in the 'debugpat' ...

Dave Jones writes: > On Mon, May 19, 2008 at 10:53:58PM -0700, Yinghai Lu wrote: > > > you don't need to set that bit again... > > > > prevoious !test_cpu_cap(..) already get out. > > > * Add an enablepat boot parameter, useful for testing CPUs not yet > added to the whitelist. > * Don't try to enable PAT if it was never enabled in the first place. > > Signed-off-by: Dave Jones <davej@redhat.com> > > diff --git a/Documentation/kernel-parameters.txt ...

* Add an enablepat boot parameter, useful for testing CPUs not yet added to the whitelist. * Don't try to enable PAT if it was never enabled in the first place. Signed-off-by: Dave Jones <davej@redhat.com> diff --git a/Documentation/kernel-parameters.txt b/Documentation/kernel-parameters.txt index 72c07a0..e179c22 100644 --- a/Documentation/kernel-parameters.txt +++ b/Documentation/kernel-parameters.txt @@ -236,6 +236,10 @@ and is between 256 and 4096 characters. It is defined in the ...

From conversation with Centaur engineers, both the newer generations of the VIA C7, and their future CPUs support PAT, with no known errata. Signed-off-by: Dave Jones <davej@redhat.com> diff --git a/arch/x86/kernel/cpu/addon_cpuid_features.c b/arch/x86/kernel/cpu/addon_cpuid_features.c index c2e1ce3..638a3a6 100644 --- a/arch/x86/kernel/cpu/addon_cpuid_features.c +++ b/arch/x86/kernel/cpu/addon_cpuid_features.c @@ -62,6 +81,10 @@ void __cpuinit validate_pat_support(struct cpuinfo_x86 *c) ...

I'd really like to avoid divergences between the 32-bit and 64-bit code if they can be avoided at this point. These codes need to be unified, not further split. -hpa --

On Tue, May 20, 2008 at 07:46:57AM -0700, H. Peter Anvin wrote: > Dave Jones wrote: > > There were no 64bit Transmeta CPUs made (and it'd be something of > > a surprise if they started any time soon). To the best of my knowledge, > > no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta. > > By removing this code, we can also eliminate calling cpuid 0x80000007 twice. > > > > Signed-off-by: Dave Jones <davej@redhat.com> > > I'd really like to avoid divergences between ...

On Tue, May 20, 2008 at 12:09:35AM -0400, Dave Jones wrote: > There were no 64bit Transmeta CPUs made (and it'd be something of > a surprise if they started any time soon). To the best of my knowledge, > no CPU vendor cloned the 80860000 cpuid space claimed by Transmeta. > By removing this code, we can also eliminate calling cpuid 0x80000007 twice. argh, after reading this a dozen times, I send it, and then notice a typo. That should be ' eliminate calling cpuid 0x80000000 ...

*Shrug* ... it seems like pointless churn to code that really needs to die to me. -hpa --

There's nothing magic. It turns out that the system call interface is sufficient to virtualize an entire system, and UML is an existence proof of that. The major mappings are: system calls -> ptrace memory -> mmap, munmap, mprotect interrupts -> signals This paragraph is very unclear to me... Jeff -- Work email - jdike at linux dot intel dot com --

Hi all, We recently upgrade kernel from 2.6.17.4 to 2.6.22.15 on our products. In our some test, the disk I/O shot as well as CPU utilization, which starving our some other critical process. For the sake of curiosity, I ran bonnie++ on both kernels, following are the result: ## ###############Linux 2.6.17 #1 SMP Tue May 6 ################################## Version 1.03c ------Sequential Output------ --Sequential Input- --Random- -Per Chr- --Block-- -Rewrite- -Per ...

Checkout the attached files. Sorry for the delay - I was away from the Thanks for your time, Plamen=20 --=20 Plamen Petrov, network & system administrator Filial - Silistra RU "Angel Kantchev" http://fs.ru.acad.bg/ -------------------------------- this message is UTF8 encoded=20 _ ___ _____ ------------------------------------------ This message was sent by the mail server at fs.ru.acad.bg using the web interface: https://fs.ru.acad.bg/s/m/webmail E-mail ...

hallo list, steven rostedt asked me to pass this problem to this list, so here it goes. when running make in the alsa-driver source i get this error: ..... make[1]: Entering directory `/usr/src/linux-2.6.25' CC [M] /home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/hwdep.o CC [M] /home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/memory_wrapper.o CC [M] /home/nowhiskey/software/nove/alsa/alsa-driver-1.0.16/acore/memalloc.o CC [M] ...

From: Geoff Levand <geoffrey.levand@am.sony.com> I'm not against this patch, but I'm pretty sure it's not necessary. Isn't memory hotplug already synchronized at a higher level? If not, it should be. --

Add a spinlock to struct lmb to enforce concurrency in lmb_add(), lmb_remove(), lmb_analyze(), lmb_find(), and lmb_dump_all(). This locking is needed for SMP systems that access the lmb structure during hot memory add and remove operations after secondary cpus have been started. Signed-off-by: Geoff Levand <geoffrey.levand@am.sony.com> --- v2: o Add locking to lmb_find(). include/linux/lmb.h | 1 lib/lmb.c | 62 ++++++++++++++++++++++++++++++++++++++++------------ 2 ...

I actually did that in the next patch, but I have been looking a bit deeper into this and it might not be such a good idea. That, or there is a bug in pci-dma_64.c. In arch/x86/kernel/pci-dma_64.c , dma_alloc_coherent() adds __GFP_NORETRY to the gfp flags before it calls __get_free_pages (through dma_alloc_pages). That means dma_alloc_coherent() -> __get_free_pages() can fail quite easily on x86_64 with GFP_KERNEL. If in __get_free_pages() try_to_free_pages() fails once, ...

I bought a system with intel DG965RY motherboard year ago, and still no support for its O/B sensors in linux. Can I ask again, when you expect it to be released. At least intel should release documents how to access the QST sensors. I know that HECI is first step for that, but it is not enought to read those sensors. I Really hope there are good news, Best regards, Maxim Levitsky --

We have addressed more issues raised on lkml after initial submission, especially the legacy device support issue which was removed in this patch. The Intel Management Engine Interface (aka HECI: Host Embedded Controller Interface ) enables communication between the host OS and the Management Engine firmware. MEI is bi-directional, and either the host or Intel AMT firmware can initiate transactions. The core hardware architecture of Intel Active Management Technology (Intel AMT) is resident ...

On Mon, 19 May 2008 20:11:54 -0400 What a lot of code. It'd be nice if the changelog were to describe the proposed and all-important kernel<->userspace interface, please. From a five-second peek it looks like a miscdev with ioctls? Ah, and there's read and write too. What is the payload for those system calls, and the meanings of their return values, etc, etc? Does it make sense for this driver to be available on all architectures? --

A partial list follows - let me know if you are aware of more (or even better open bugs in the project bugzilla on samba.org) Note that some of the backlevel server support issues aren't handled by smbfs either (and are hard due to protocol limitations). Guenter Kukkukk had been tracking some of the issues with better backlevel support (mostly for OS/2 and Win9x servers) so he might have more information, but the obvious holes that come to mind are: a) utimes to backlevel (lanman) ...

dropping smbfs in 2.6.27 will conflict with - legacy servers like - win9x/me - OS/2 - even todays sold "samba NAS boxes (2.x.x)" (!!!) - other old legacy servers like MSDOS/IBMDOS Cifs vfs - the successor of smbfs - was _initially_ designed to only support the "NT LM 0.12" and "POSIX 2" SMB/CIFS network dialects - NO legacy support at all. I really can't talk about "FUSE client" - the burden is on cifs vfs ... to also support legacy servers. Steve French ...

I fully agree, I thought the same thing when I did the patches. I remember that Wim had a git tree doing this, which is still active at http://git.kernel.org/?p=linux/kernel/git/wim/linux-2.6-watchdog-experimental.git;a=co... Unfortunately, it hasn't seen much activitity over the last two years, and the number of watchdog drivers seems to have exploded: I count 67 of them, including some outside of drivers/watchdog. Wim, was there anything ...

Are you planning this as a transitional method for converting drivers, or are you aware of any driver that All the ioctl numbers are compatible, so it would be good to register the watchdog ioctl function as compat_ioctl as well. Once all drivers are using the common abstraction, we can also kill their COMPATIBLE_IOCTL() entries in There are a few watchdog drivers living outside of drivers/watchdog/, I could find: * arch/um/drivers/harddog_kern.c * drivers/char/ipmi/ipmi_watchdog.c * ...

Some watchdogs have no stop method so you need to allow for that (it Should have been done by the driver anyway - so this is a WARN check Races register - plus you don't need to check these cases Also there is a problem with module locking as you don't lock down the driver module as your fops are owned by the watchdog_dev. I'd actually been thinking along the same lines but not paid attention to your tree (was a bit busy without poking watchdog). The patch below is actually quite ...

<snip> I have just tested this, and it breaks jackd horribly, no matter the settings, jack ALWAYS underruns. --

Also, could you try 2.6.24.7-rt7. Thanks, -- Steve --

Forgive me to ask a stupid question. Why using the 24 mainline kernel, the time is less than using the rt-patched kernel? -----Original Message----- From: linux-kernel-owner@vger.kernel.org [mailto:linux-kernel-owner@vger.kernel.org] On Behalf Of Steven Rostedt Sent: 2008年5月20日 7:44 To: Kasper Sandberg Cc: LKML; RT; Ingo Molnar; Thomas Gleixner Subject: Re: 2.6.25.4-rt2 Well, the BKL is still a semaphore in 25. For my hackbench runs, I have: [root@bxrhel51 c]# cat ...

Hi, [ It seems that you may be new to the lists, so I will let you know, please do not top post. It is appropriate to either bottom post or better yet, inline reply. See http://en.wikipedia.org/wiki/Posting_style ] I'm not sure where you read that. With the introduction of high-resolution timers, the HZ value isn't that important anymore. Things that might use select or poll as timeouts will still be at the HZ frequency, but other code that uses proper timer API will still react ...

Thanks very much for your explanation At the very beginning I thought the Hackbench was a latency tools, so I was very surprised to see such result. But there's another question. When I choose the Complete Preemption -Real Time configuration, it's recommended to choose Timer Frequency ---> 1000Mhz to improve the cpu performance, does it mean cpu will cost much more during the thread context switch? Or I should choose 100Mhz in order to decrease the thread context switch and get a better ...

Acked-by: Jan Kara <jack@suse.cz> -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

Acked-by: Chas Williams <chas@cmf.nrl.navy.mil> --

*Groan* you're right. Blitering idiots... they only present __i386__ and whatever *exact* CPU you have -march= for, which of course is a *CHANGING SET* (just __i486__, __i586__ and __i686__ isn't enough... they seem to also have __core2__, __k8__ and $DEITY knows what else.) The only sensible way to handle that would be to centralize that knowledge in a header file. -hpa --

The worst thing is how many CONFIG_'s they currently leak to userspace. And e.g. the versions in the x86 header are therefore not the fastest cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

This is a valid point. This should be __i486__ for userspace, which is gcc's way to tell you if you're compiling with -march=i486. -hpa --

In these two cases I only moved code. And I actually moved the other code and git just decided to move the code that stayed instead since it creates less changed lines... cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

umm, you also changed the declarations of profile_tick() and profile_hits() but not of create_prof_cpu_mask(). Oh well, I'll do it. --

--

Yeah, I updated it last night to add this patch, a couple of other trivial patches (Lindent-type) that were sent to me, and I would put the proc ptrace one there as well, since it's touching core/smack/etc... That needs coordination w/ any follow-on. thanks, -chris --

It's used in reversing the bits in a byte value as well, which your patch breaks (see the bitrev8 users) Harvey --

Thanks for reviewing Harvey :-) It is a static function, so you cant use it from outside of this Why store those things if stuffs can be done in smoother and cleaner (using less memeory ofcourse) way! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --

Thanks Benoit for giving me such a precious advice. But sorry, I dont have any benchmarking system in my hand(how can i have? i am just a student, not a professional). So if you do me a favour and kindly do it for me, please :-) Anyway thanks again. Soumya -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean. --

Thanks for giving a reply Akinobu :-) I forgot that bitrev8() is static in header file. Sorry for that. Below is my new patch considering this. Cant it be applicable? Please review it. I know that my bitrev8() takes more instructions than that of yours. But we have to think about faster access of cpu cache over that of memory cache(which your bit_rev_table uses). Thanks anyway ;-) ---Inline Attachment--- --- a/include/linux/bitrev.h 2008-04-17 08:19:44.000000000 +0530 +++ ...

On Tue, May 20, 2008 at 5:25 PM, Soumyadip Das Mahapatra I didn't review your patch, sorry. But I'm pretty sure that your patch won't be considered unless you provide benchmarks with numbers for different CPU/architecture. Ideally you should provide a script to test the correctness and the performance of your change that anyone could run on his computer. regards, Benoit --

As long as this fixes the hang on dock removal, this looks good to me. Acked-by: Matthew Garrett <mjg@redhat.com> -- Matthew Garrett | mjg59@srcf.ucam.org --

I think we want to do the _EJ0 checking before this, otherwise we'll generate two uevents for the same removal on some hardware. Otherwise, looks good. -- Matthew Garrett | mjg59@srcf.ucam.org --

Ok, it seems we're currently doing the same work two times. I've also got a patch for this. Already tested, so please have a look if this would also match your requirements: Handle bay devices in dock stations * Differentiate between bay devices in dock stations and others: - When an ACPI_NOTIFY_EJECT_REQUEST appears, just signal uevent to userspace (that is when the optional eject button on a bay device is pressed/pulled) giving the possibility to unmount file systems and to ...

(please don't top-post) L-PCM is linear PCM, which is the sample format used by practically _every_ sound card. IEC 60958 is AES/EBU, which is essentially S/PDIF, which uses linear PCM samples. IEC 61937 specifies how to transport compressed streams over S/PDIF, by pretending the data stream is a sequence of linear PCM samples. All of this is supported by ALSA. Regards, Clemens --

Can you supply me your .config file? I am sure it is just a matter of enabling the correct option there. Yours, Abel. --

Ok, so we have X in the mix. Can you try if it happens if you disable Intel framebuffer driver? Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

I'm trying to work in sensible testable stages. Whats brewing at the moment is thoughts tty_get() and tty_put() but I don't have a bootable usable tree for that yet and there is work to be done. --

A lot depends on what else Alan is brewing up. I only have a single tty-related patch at present (remove-is_tty.patch) and a handful of possibly-related char driver patches (proper-extern-for-mwave_s_mdd.patch, if-0-hpet_unregister.patch and riscom8-remove-redundant-null-pointer-test.patch). But if a great mountain of tty- and/or char-related patches is forthcoming, that mountain will probably have a depencency upon your tree. And that's OK too, as long as you don't go and bugger up ...

Is there any more information about this? Items in a structure should be aligned to the alignment required by their type. Usually sizeof(x) == alignof(x), but not always. I guess in this case the structures are used as a cross-platform binary on disk representation, and so the alignment of the build host must match the alignment of the target? Maybe it would be better to include the alignment attribute in the definition of kernel_ulong_t? --

Hi Alan, Thanks for doing this. Acked-by: Florian Fainelli <florian.fainelli@telecomint.eu> --

He definitely knows which country, but indeed not exactly where :-) So I'll survive. My wive and children however, do know where I live and they want to be able to move end of this summer, so it's obvious what to choose :-) Greetings, Wim. --

This runs afoul of git-watchdog and/or itco_wdt-ich9do-support.patch Hunk #1 succeeded at 66 (offset 1 line). Hunk #3 FAILED at 139. Hunk #4 FAILED at 158. Hunk #5 FAILED at 201. Hunk #6 FAILED at 222. Hunk #7 FAILED at 246. Hunk #8 succeeded at 374 (offset 12 lines). Hunk #9 FAILED at 429. Hunk #10 FAILED at 458. Hunk #11 FAILED at 472. Hunk #12 FAILED at 480. Hunk #13 FAILED at 489. Hunk #14 FAILED at 518. Hunk #15 FAILED at 534. Hunk #16 FAILED at 588. Hunk #17 succeeded at 454 ...

Strictly "AMD64_" is not the correct prefix, because these registers are generic standard AGP3 registers. -Andi --

I spotted this while I was coding, and I was careful not to let it get added to the list... If the ->init routine fails, the superblock hasn't even been added to the list yet. The patch moves this line: list_add_tail(&s->s_list, &super_blocks); I had something similar earlier, but I thought it started to look slightly messy when I discovered that dropping the spinlock would lead to a racey ->init... but I hadn't thought of putting the mutex outside the spinlock; the mutex ...

You can't take a mutex while holding a spinlock -- what if you had to sleep to acquire the mutex? I imagine you also don't want to hold a spinlock while calling the ->init or ->exit -- what if the fs wants to sleep in there (eg allocate memory with GFP_KERNEL). -- Intel are signing my paycheques ... these opinions are still mine "Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde ...

Well, just for the reason I mentioned, I saw the posting about XFS starting threads (when compiled into the kernel), but there's no use of an XFS filesystem at all - there was a suggestion that something like this be tried, so I thought I'd give it a go. Thanks for replying! -- Regards, Tom Spink --

Hi Tom, I spotted one definite bug; on failure, you leave the superblock on the super_blocks list. Your locking may well be correct, but it has the hallmarks of being "a bit tricky" and a bit tricky means potentially buggy. How about doing the nesting the other way round, ie take the mutex first, then the spinlock? The code needs a bit of tweaking because you don't want to put the superblock on any list where it can be found until it's fully sget is a little more complex ... the ...

Hi Guys, Thanks for looking! So I've had another go - this time taking the superblock approach, and hopefully I've got the locking right too. Let me know what you think (or if I'm still barking up the wrong tree)! --- From: Tom Spink <tspink@gmail.com> Date: Tue, 20 May 2008 16:04:51 +0100 Subject: [PATCH] Introduce on-demand filesystem initialisation This patch adds on-demand filesystem initialisation capabilities to the VFS, whereby an init routine will be executed on first use of a ...

Now that every line using a within() has to be changed anyway, it could Well, between the unsigned long and the void * version, there's not that much of a difference in the number of casts. So here goes #3: -- From: Peter Oberparleiter <peter.oberparleiter@de.ibm.com> This patch consolidates a number of different implementations of the within() function which checks whether an address is within a specified address range. Apart from parameter typing, existing implementations can be ...

The kernel's use of unsigned long to represent pointers sometimes makes sense, but often gets us into a mess. It's OK in bootup code which fiddles with memory map layout because there is no reason why such code will ever dereference any of the addresses. But I don't think we can assume this usage pattern when creating a kernel-wide facility in kernel.h. So yes, I do think that an address-comparison tool like this should And you've had to add a great pile of casts anwyay? --

Hi Thomas, It was not intentional, I missed it sneaking in. It seems to be gone again today. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

I'm using ext3. Jiri's patch fixes the my problem. Seems the problem I didn't notice same thing on 2.6.26-rc2, is it necessary for me to test on it? Regards dave --

Hi Neil, We're much closer. The events_cleared is symmetric on both the failed and active member of the raid1. But there have been some instances where the md thread hits a deadlock during my testing. What follows is the backtrace and live crash info: md0_raid1 D 000002c4b6483a7f 0 11249 2 (L-TLB) ffff81005747dce0 0000000000000046 0000000000000000 ffff8100454c53c0 000000000000000a ffff810048fbd0c0 000000000000000a ffff810048fbd0c0 ffff81007f853840 000000000000148e ...

Right. Or two ioctls against each other unless one sleepers, or against random other parts of the kernel which still use the BKL - eg fasync, Exactly. Alan --

This is a known mac80211 bug. The fix (might not be the final one) is here: http://marc.info/?l=linux-wireless&m=121120929012836&w=2 Thanks, -yi --

--

Yes, but IMHO we should do that in a future patch. That patch will touch every rfkill driver, so I'd rather we do that later. IMHO it is best to get the most important stuff merged, first... Then, in that future patch, we change the API, fix all in-tree drivers using that API, and update the documentation to match the new API. For now, we update the documentation to match the current API. What do you think? -- "One disk to rule them all, One disk to find them. One disk to bring ...

--

Wasn't it the plan to send the current hardware state as rfkill registration argument, so we can force drivers to send a valid state to rfkill? Ivo --

--

I don't quite agree here. The SW_RFKILL_ALL key is the one send by thinkpad-acpi, what makes that key so special that is has to be handled differently then a key that only controls a single radio type? All keys should have the same rules when it is pressed, so either all keys should --

From: Harvey Harrison <harvey.harrison@gmail.com> Good idea, I'll revert, Denis can you generate a new patch? Thanks. --

From: Denis Cheng <crquan@gmail.com> Applied, thanks. --

Hello. Good. I have long ago noticed that DMA is started too early in ide-floppy which is known to cobfuse some chips (like PDC20246) and was going to do a May be too early still... ide-cd does this after writing the command packet. WBR, Sergei --

Makes sense. I'll send out v3. Is there a similar range on i386? -- error compiling committee.c: too many arguments to function --

I found some workaround (define the variable only on archs that want it, While I agree with you, I defer to Ingo on this. -- error compiling committee.c: too many arguments to function --

Don't think so. Address space is too precious here. What you could probably do is to unmap one fixed page in some range that is always split to 4K pages anyways and use that. Perhaps somewhere in the 640k-1MB range. But if you're unlucky this might require a variable, not a constant. -Andi --

"Security hole unless arch maintainer does _foo_" sounds scary. Especially when i386 is hard to fix... (And very nice catch, btw). Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

I guess a fixmap would work for this. But then the offsets added to that page would need to be limited to 4K. -- error compiling committee.c: too many arguments to function --

On Tue, May 20, 2008 at 11:28 AM, Andrew Morton Good idea, thanks! Could you update the patch, please? --

Thanks, Rafael --

done. http://bugzilla.kernel.org/show_bug.cgi?id=10630 -- Lukáš Hejtmánek --

Aha. Thanks. Please recompile without CONFIG_USB_SUSPEND Regards Oliver --

This patch appears to fix it: The Orion EHCI root hub does have a built-in Transaction Translator. Signed-off-by: Lennert Buytenhek <buytenh@marvell.com> Index: linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c =================================================================== --- linux-2.6.26-rc3.orig/drivers/usb/host/ehci-orion.c +++ linux-2.6.26-rc3/drivers/usb/host/ehci-orion.c @@ -115,6 +115,8 @@ static int ehci_orion_setup(struct usb_h if (retval) return retval; ...

A similar change is needed in other bus-glue files. I have put together a patch to take care of them all; it will be posted later today. Alan Stern --

I'm guessing that this has a version of the ARC/TDI/whoever-now-owns-it IP, on a PCI bus? But without the integrated TT option? If this is on a PCI bus, then try removing the ehci-pci.c line added by that patch, see if that helps. - Dave --

No, this is not on a PCI bus -- this is the on-chip EHCI controller of the Marvell Orion ARM SoC (ehci-orion.c.) I have honestly no idea whether the IP is in-house or third-party. --

On Mon, May 19, 2008 at 6:24 PM, Ciaran McCreesh seems acpi pnp resource cause some problem.... please try attached patch and send out /proc/mtrr YH

On Mon, 19 May 2008 19:48:38 -0700 The patch doesn't help I'm afraid. /proc/mtrr is: reg00: base=3D0x100000000 (4096MB), size=3D 512MB: write-back, count=3D1 reg01: base=3D0x00000000 ( 0MB), size=3D2048MB: write-back, count=3D1 reg02: base=3D0x80000000 (2048MB), size=3D1024MB: write-back, count=3D1 reg03: base=3D0xc0000000 (3072MB), size=3D 256MB: write-back, count=3D1 reg04: base=3D0xd0000000 (3328MB), size=3D 128MB: write-back, count=3D1 Thanks, --=20 Ciaran McCreesh

On Mon, May 19, 2008 at 8:16 PM, Ciaran McCreesh sorry, please send /proc/iomem after check request_resource and insert resource... it seems if you insert or request one small one, and request big one, then only have big one, but if you insert the big one, the small one will because big one's child... so at that case, could be pnp res return from acpi (dsdt) is bigger than e820 region... so it seems the offending patch just reveal problem cause by pnp code. YH --

On Mon, 19 May 2008 18:22:00 -0700 00000000-0009ffff : pnp 00:09 000f0000-000fffff : pnp 00:09 00100000-d7feffff : pnp 00:09 d7ff0000-d7ffffff : pnp 00:09 d8000000-dfffffff : PCI Bus 0000:01 d8000000-dfffffff : 0000:01:05.0 e0000000-efffffff : PCI MMCONFIG 0 e0000000-efffffff : pnp 00:08 fdb00000-fdbfffff : PCI Bus 0000:03 fdc00000-fdcfffff : PCI Bus 0000:03 fdcff000-fdcff0ff : 0000:03:05.0 fdcff000-fdcff0ff : 8139too fdd00000-fddfffff : PCI Bus 0000:02 fdd00000-fdd1ffff : ...

Hi Arjan, Sorry for a late answer. I'm currently travelling on a short vacations. On Sat, 17 May 2008 13:20:50 -0700 I have a trivial patch to fix this already. I'll add it soon to my tree and The fix looks sane. I prefer to just remove the lock call from bttv, instead of calling __videobuf_mmap_setup() and make this symbol global. The better is to avoid locking inside the drivers, except during the interrupts, and inside videbuf code. This is what we're doing on the other ...

Yes, other patches are not bugfixes. Probably this fix is not "urgent" too, the race is very old and nobody complained. Oleg. --

No, this will not work.. next time you open the device you won't have IRQ anymore. You need the opposite of outb_p(DEVICE_ENABLE, HTCPEN_PORT_INIT); here. -- Dmitry --

You need to close the device. Making evdev a module and unloading it If you can't find the way to disable device then you need to revert to the old way, with enabling it in _probe() and freein irq in _remove(), you just need to make sure that you free_irq() first and then call input_unregister_device(). Also, like Andrey said, we might consider using DMI table so we dont poke IO ports on random boxes. Oh, and one more thing, you need to reserve the IO ports your driver is using with ...

Finding a way to disable it was easy :-) Thanks Andrey for the suggestion of using DMI table, see the patch below. Should I keep the old device detection using IO port stuff or just dmi_check_system() should be fine? > Oh, and one more thing, you need to > reserve the IO ports your driver is using with request_region. Thanks, I implemented this too in the patch below, but I have a problem: I can successfully reserve 0x250-0x251, but 0x68 and 0x6c are already reserved by the ...

On Mon, 19 May 2008 23:19:37 -0700 Hmm, size * sizeof(struct page) is multiple of PAGE_SIZE in many case. Becasue "size" is always alinged to (1 << MAX_ORDER -1) (I believe...). ex.) In x86 case, (1 << (MAX_ORDER(11) - 1)) * 4 (sizeof(long)) = (1 << 12) = PAGE_SIZE. But not sure on other archs with various params. I think above fix is correct. Thanks, -Kame --

I have filed a patch to fix HAL to use the canonical SIOCGIWNAME at https://bugs.freedesktop.org/show_bug.cgi?id=3D16037. Any further objections to this patch? johannes

.. and in addition to that, perhaps something like this too? Making the actual _PAGE_XYZ bits be of the proper type makes using bitops and negation on them automatically DTRT, so that we don't need those insane casts in pte_mkclean() and friends. Again, totally untested, but we really should just get the types right, instead of getting them wrogn and then messing around with various silly and incorrect work-arounds for the fact that we got them wrong. And while it's untested - if ...

That's pretty close to the core of my patches (just reposted), which have been cooking in x86.git for a week or so. One thing I'd take from your patch is something like your __PHYSICAL_LOW_BITS definition, since its a bit clearer than what I did. (I haven't updated my patch before posting just because I wanted J --

Well, Andrew has applied this patch to the -mm tree now and after a bit of thinking I have made up my mind and decided we should keep the patch. This is an I2C device which means it will always only be explicitly requested by platform code. This is an opportunity for the platform to express the will and the way to use the century bit. I'll cook-up a follow-on patch as soon as the SWARM bits propagate to upstream, to add a set of flags that will let platforms specify the desired way the ...

Not if I can help it, no. I just couldn't work out from the git docs how to do it otherwise when working with kernel.org and bare trees. <snip> That worked beautifully. Thanks a lot. Stephen: There is now a trivial-2.6.git tree at git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git with a 'next' branch that you can pull into linux-next, please. git://git.kernel.org/pub/scm/linux/kernel/git/juhl/trivial-2.6.git next Once we hit a merge window I'll rename the 'next' ...

On Tue, May 20, 2008 at 9:26 AM, Guennadi Liakhovetski Yes! There really are!!! One case I've been told of is an SPI bridge Hmmm, yeah, I suppose it is possible; but if it is internal to the bus controller then it can also be handled internally by the bus controller driver and probably won't need to be reflected in the It also needs to describe layouts which require SPI transfers in a particular order. For example, if you're doing 2 SPI messages (M1 and M2) to 2 different SPI devices ...

ISTR fsync() on ext3 did not always force a commit, if in-place data writes did not change any metadata. Has this been fixed in ext4 but not ext3 then? Does WRITE_BARRIER always cause a flush? It does not have to according to Documentation/block/barrier.txt. There are caveats about tagged queuing "not yet implemented" in the text, but can we rely on that? The documentation is older than the current implementation; those caveats might no longer apply. -- Jamie --

I think that might still be true, but I'm still looking through it (in the background...) I tried blktrace to see what was going on but I'm not sure what an "NB" in the RWBS field means, anyone know? -Eric --

Except when it crosses an MD disk boundary. Then it's really likely. We could also ask if there's _any_ possibility, when they are a merged single I/O, of them not getting written in the expected order? What about when FUA is set, does that imply any order? But it's all moot: Checksumming is the way forward here, no doubt. Checksumming makes the multi-sector write "atomic or corrupt". That's the same expectation as a commit sector provides by itself, but generalised to the whole journal ...

Eric already knows this now, but for the benefit of anyone else that may be curious - it's an empty (data-less) barrier. 'N' is basically 'no data' (eg not a read nor a write) and 'B' is barrier. -- Jens Axboe --

Last time I looked, the database write + fsync case did not result in a journal commit in some cases, and therefore no blkdev_issue_flush(). The problem was one of correctness. Has this been fixed? A database had no way to issue a hard disk barrier in these cases without doing weird stuff like forcing metadata changes prior to fsync (e.g. toggling permissions bits), which causes an intolerable two disk seeks per fsync. That is _way_ expensive. There is also no way in ext3 to _just_ ...

That is a great optimisation to make the filesystem safe against power fails without barriers. Upon replay, the filesystem is consistent. But does it break fsync()? Consistency isn't enough for fsync(). Returning from fsync() means "this data is committed now". -- Jamie --

That would be great, I'd like to confirm that my machine isn't the only one on the planet so easily broken ;) I was also able to trigger corruptions on XFS (one run out of two), so it is unlikely I'm seeing bugs in the ext3 replay or logging code. -chris --

Hi Chris, Just to clarify, was this test with barriers on or off for XFS? I'm wondering if it was with barriers on, then we have a reproducible bug in log replay. Or whether you were just confirming the problems with barriers off on another filesystem. Thanks muchly, Tim. --

I think you're right, but it's hard to be sure. One of the problems with barrier-implemented-as-flush-all is that it flushes data=ordered data, even when that's not wanted, and there can be a lot of data in the disk's write cache, spread over many seeks. Then it's good to delay barrier-flushes to batch metadata commits, but good to issue the barrier-flushes prior to large batches of data=ordered data, so the latter can be survive in the disk write cache for seek optimisations with later ...

On Monday 19 May 2008, Timothy Shimmin wrote: Barriers were off on xfs, the corruptions were not xfs' fault. -chris --

Oh. That's really unclear from the opening paragraph of barrier.txt, which _defines_ what I/O barriers are for, and does not mention flushing: I/O barrier requests are used to guarantee ordering around the barrier requests. Unless you're crazy enough to use disk drives for implementing synchronization constructs (wow, sounds interesting...), the ordering is meaningful only for write requests for things like journal checkpoints. All requests queued before a barrier request ...

Jens and I talked about tossing the barriers completely and just doing FUA for all metadata writes. For drives with NCQ, we'll get something close to optimal because the higher layer elevators are already doing most of the hard work. Either way, you do want the flush to cover all the data=ordered writes, at least all the ordered writes from the transaction you're about to commit. Telling the difference between data=ordered from an old transaction or from the running transaction gets ...

I haven't read the code and don't use MacOS myself. From its fcntl() man page: Note that while fsync() will flush all data from the host to the drive (i.e. the "permanent storage device"), the drive itself may not physically write the data to the platters for quite some time and it may be written in an out-of-order sequence. Specifically, if the drive loses power or the OS crashes, the application may find that only some or none of their data was written. The ...

On Wed, 21 May 2008 01:23:09 +0530 Well I was just putting it out there for consideration. Yes, I think the whole idea of consuming the "trace_*" namespace in this patchset was ill-advised. Also, I don't know how to move forward with the whole feature - I haven't seen a lot of interest from others and I haven't seen much discussion of how this feature differs from all the other tracing things which have been floating about. And even if the proposed patches presently offer unique and ...

Manage atmel_lcdfb FIFO underflow rework Resetting the LCD and DMA allows to fix screen shifting after a FIFO underflow. It follows reset sequence from errata "LCD Screen Shifting After a Reset". Reworked following Andrew Morton comments. Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com> --- This error may append in latency sensitive cases : slow clock, Ok incremental patch follows. Tell me if you prefer that I send a reworked one. Ok, I try to adapt this comment in the ...

I did manage to steal another complete set of RAM and swapped it in, with no change. This still doesn't rule out potential issues with the MB (slots or controller); I've got a spare board coming in in the next week. In the mean time, I've been busy bisecting this one down. Unfortunately, it takes a good hour or two of heavy load to trigger sometimes, and I've got a good 15000 or so commits to get through, so it could still be a while. I haven't been keeping any traces from these, even if I ...

Hmm, you probably want to skip all lines that are edge-triggered. Otherwise you may have problems with sharing. Drivers for devices used with these edge-triggered lines may have special provisions to permit sharing in a crafted way in special arrangements (cf. the 8250 serial or the IDE driver), but that may not work in a generic way with a different driver in the scenario. And the polarity may be wrong too -- edge-triggered lines are often active-high, because it's fine with them. This ...

Would oprofile[0] help to see what jfsCommit is doing here? C. [0] http://oprofile.sf.net -- make bzImage, not war --

Hey Dave, Thanks for following up on this... The previous kernel that I was running was 2.6.18.1... From CentOS 5.1. It appears that the thread eating up that much CPU isn't a continuous happening, only when there's a fair amount of activity going on. It's hard to nail down exactly when it happens, but the next time it does, I'll definitely let you all know! I haven't been able to reboot this machine, as it's a production unit, but if I do get the chance, I'll do so. It seems to ...

I just sent Linus the pull request for this fix; should be upstream soon. Thanks, Jesse --

Tested, works as expected, thanks. Acked-by: Arnaldo Carvalho de Melo <acme@redhat.com> - Arnaldo --

I figured it was something like that, so I didn't look too deep into it, and decided that it was best just not to trace it. -- Steve --

Hi Michael, I really appreciate this. It's been a few years since I did any real PPC The -pg flag makes calls to the mcount code. I didn't look too deeply, but at least in my first prototypes the early boot up code would crash when calling mcount. I found that simply keeping them from calling mcount made things OK. Perhaps I'm just hiding the problem, but the tracing wont I tried hard to make most of the complex logic stay in generic code. What dynamic ftrace does is at start up the ...

Looks good to me, feel free to add an: Acked-by: Greg Kroah-Hartman <gregkh@suse.de> to it. David, are you going to take this through your tree? thanks, greg k-h --

OK, here is an actually-compiled patch with proper description and s-o-b. Comments? ----- driver core: Suppress sysfs warnings for device_rename(). Renaming network devices to an already existing name is not something we want sysfs to print a scary warning for, since the callers can deal with this correctly. So let's introduce sysfs_create_link_nowarn() which gets rid of the common warning. Signed-off-by: Cornelia Huck <cornelia.huck@de.ibm.com> --- drivers/base/core.c | 17 ...

After further troubleshooting it turns out that the message above was a bit of a red herring. I moved the PCIe modem card from one PCIe slot to another so that it would be on a different IRQ (one that wasn't shared with the network, ATA, and USB). The message above does not occur now, however, the hard lock is back... and this time with no kernel messages at all. So, I'm back to square one again... I've got: nmi_watchdog=1 idle=poll nohz=off ... and still I get the hard lockup ...

Right, unless Alan or Wim are confident enough that removing the BKL won't break the drivers (more than they are today). Almost all of the open functions go along the lines of int open(struct file *f, struct inode *i) { if (wd_is_open) return -EBUSY; wd_is_open = 1; start_wd(); return nonseekable_open(f, i); } nonseekable_open doesn't need the BKL by itself, and the wd_is_open variable is protected by the misc_mtx mutex. I can't see any scenario in which start_wd() would ...

please drop the coreb.c changes from your patch -mike --

The existence of a spinlock is a good sign. But, until somebody has looked at the code and verified that said lock is really protecting everything, it's best to leave the BKL protection (which has always been there, just at a higher level) in place. jon --

this open func already has a spinlock protecting it. doesnt that mean we dont need the bkl in it ? -mike --

if the spinlock doesnt do what it's advertising (preventing mutual access), then the BKL is needed. if there's some UP behavior i'm not aware of, then the BKL is needed. otherwise, the BKL is not needed in this driver. i should prob rewrite this driver anyways ... the open code could easily be replaced with some atomic funcs. -mike --

OK found the problem, it was my fault after all :) Dave, this patch needs to go into stable too. [IPSEC]: Use the correct ip_local_out function Because the IPsec output function xfrm_output_resume does its own dst_output call it should always call __ip_local_output instead of ip_local_output as the latter may invoke dst_output directly. Otherwise the return values from nf_hook and dst_output may clash as they both use the value 1 but for different purposes. When that clash occurs this ...

Hello, This lockdep warning is seen when I remove pcmcia wifi card from the slot. Doesn't happen every time. It's x86_32. ======================================================= [ INFO: possible circular locking dependency detected ] 2.6.26-rc2-mm1 #2 ------------------------------------------------------- pccardd/1037 is trying to acquire lock: (rtnl_mutex){--..}, at: [<c02870f1>] rtnl_lock+0x14/0x16 but task is already holding lock: (&socket->skt_mutex){--..}, at: [<c02608ba>] ...

Maybe related to: http://bugzilla.kernel.org/show_bug.cgi?id=10620 ? Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ley. Si Ud. ha recibido ...

OK: fixed in v2.6.26-rc3-119-g8033c6e, which includes the above patches. Thanks to all. Romano -- Sorry for the disclaimer --- ¡I cannot stop it! -- La presente comunicación tiene carácter confidencial y es para el exclusivo uso del destinatario indicado en la misma. Si Ud. no es el destinatario indicado, le informamos que cualquier forma de distribución, reproducción o uso de esta comunicación y/o de la información contenida en la misma están estrictamente prohibidos por la ...

have you checked in /proc/$(pidof stty)/fd/ to see if stty is bound to any particular file descriptor ? Maybe you'll find the source of the blocking operation here. You can find a unix socket attached to another process, it may be a tty, a pipe, or even a device (eg: /dev/random when there is no entropy left). Same for "su" BTW. Regards, willy --

I doubt that Debian is to blame here. I get the same with native gdb-6.8 and native coreutils-6.10: # /usr/local/stow/gdb-6.8/bin/gdb ./stty 11944 GNU gdb 6.8 Copyright (C) 2008 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as ...

Suresh Siddha writes: > On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote: > > > But we can > > >use some what similar magic, if the fxsave/fxrstor give away > > >some of the fields at the end of fxsave image (today it is reserved > > >and ignored during fxsave/fxrstor) for software use. > > >We can then use these fields at the end of fpstate, to indicate the presence of > > >xstate. But this requires some architecture changes like giving > > >away this space for SW use. ...

Andi Kleen writes: > Suresh Siddha wrote: > > On Mon, May 19, 2008 at 04:52:01PM +0200, Mikael Pettersson wrote: > >>> But we can > >>> use some what similar magic, if the fxsave/fxrstor give away > >>> some of the fields at the end of fxsave image (today it is reserved > >>> and ignored during fxsave/fxrstor) for software use. > >>> We can then use these fields at the end of fpstate, to indicate the presence of > >>> xstate. But this requires some architecture changes like giving > ...

This issue of not-zeroing, is present in only 64bit kernels and for 64bit apps, right? 64bit app signal handling uses only rt_frame, so we can add an uc_flag for them and for 32bit apps, kernel was always zero'ing the reserved bits at the end of _fpstate. In short, for non-rt frames, they can check the reserved bits at the end of fpstate frame and for rt-frames (perhaps even for 32bit rt frame handling) apps can check for uc_flag aswell, for extended state presence. Is this good ...

OK, so that's not a usable path unless we can find some area in the existing data set to put a flag. Groan. -hpa --

H. Peter Anvin writes: > Mikael Pettersson wrote: > > > > > > Are they always zeroed in earlier CPUs though? If not that wouldn't > > > work 100% reliably because whatever cookie you put in could have been > > > there before by chance. > > > > I wrote a test program (fill an area with zeroes, fxsave, inspect > > reserved fields, then fill it with ones, fxsave, inspect again), > > and all processors appear to just not write anything to the reserved > > fields after the last xmm ...

Ok. CPU folks are planning to make some of the bytes at the end of fxsave image, SW usable. We can use some of these fields, to represent the extended state presence with a cookie, save area size, mask of the state stored. If needed, we can include the start address of the fpstate pointer (also as part of the cookie), so that we can detect the situation, where apps are just memcopying sizeof(struct _fpstate) from the fpstate pointer (but not aware of the extended state). we don't need any ...

Ok, just pushed the norom patch to linux-next. I'll test it out, but it would be good if you could try the tree out out on one of the problem machines too. Thanks, Jesse --

This is fine. I would also like to see the pci=norom option added as-is with the thought that we may improve later by either modifying pci=norom to exclude devices that need memory mapped to their expansion ROMs or by adding another option (pci=minrom ?) Works for me. Thanks. Gary -- Gary Hade System x Enablement IBM Linux Technology Center 503-578-4503 IBM T/L: 775-4503 garyhade@us.ibm.com http://www.ibm.com/linux/ltc --

I'm not advocating that, but having swap on reclaim does not hurt anyone, this is essentially the same, but with different underlying storage. System will do that anyway sooner or later during usual writeback, which in turn can be a result of the same reclaim... -- Evgeniy Polyakov --

And actually having tiny operations under inode_lock is the last thing to worry about when we are about to start writing pages to disk because memory is so fragmented that we need to move things around. That is the simplest from the typing viewpoint, one can also do something like that: struct address_space *mapping = page->mapping; struct backing_dev_info *bdi = mapping->backing_dev_info; struct writeback_control wbc = { .bdi = bdi, .sync_mode = WB_SYNC_ALL, /* likly we want to wait... ...

It's more than efficiency. There are lots and lots of things we cannot do in direct-reclaim context. a) Can't lock pages (well we kinda sorta could, but generally code will just trylock) b) Cannot rely on the inode or the address_space being present in memory after we have unlocked the page. c) Cannot run iput(). Or at least, we couldn't five or six years ago. afaik nobody has investigated whether the situation is now better or worse. d) lots of deadlock scenarios - ...

Which is the exact implementation of filemap_fdatawrite_range(mapping, start, end); Cheers, Dave. -- Dave Chinner Principal Engineer SGI Australian Software Group --

Is this a problem you can reproduce every time? Basically what line 5 of the test does is to write a value into the register struct to rewind the PC after hitting a breakpoint such that the instruction will be executed again. This is stored in memory which will be used for a context switch back to the process. The test also replaces the original instruction in memory. In this case the memory write failed. This will certainly be fatal to the operation of the kernel and stability would be ...

Hi Dave, ... but calling another one? Can't be correct. Which raises a question: you didn't test your patch, did you? I'm also surprised how you managed to mess this up, given that all you had to do was to move already The rest looks OK. I'll fix the patch myself and add it to my i2c tree now. -- Jean Delvare --

XFS is 64-bit, but file sizes are of type off_t or loff_t, and are therefore _signed_. 0x7fffffffffffffff is therefore indeed the maximum allowed file size for a 64-bit filesystem. Trond --

If you fork a kernel thread, you lose error handling, too. Think -EIO when writing back bitmaps... (Hmm, you'd have to use O_SYNC to see that, so this is probably minor). I guess doing freeing asynchronously would be okay in the 'close' case... Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Oh, so the BTE transfer is purely for fault isolation. I was thinking you guys might have sufficient control of the hardware to be able to do it at the level of CPU memory operations, but if it is some limitation of ia64, then I guess that's a problem. How do you do fault isolation of userspace XPMEM accesses? --

I was wrong about that. I thought it was safe to do an uncached write, but it turns out any processor write is uncontained and the MCA that surfaces would be fatal. Likewise for the uncached read. --

The MCA handler can see the fault was either in userspace (processor priviledge level I believe) or in the early kernel entry where it is saving registers. When it sees that condition, it kills the users process. While in kernel space, there is no equivalent of the saving user state that forces the processor stall. --

I don't have results from a run handy with over 64 threads with the patched kernel for the contended case. But from what I've seen, the closer the number of test threads is to the number of actual cores, not SMT threads, the more noisy the test gets. I think this is reasonable/expected and that there's nothing magic about 63 or 64 threads. We've been having network issues in the lab where this big box is. If/when I can get access long enough, I'll do a series of runs including past ...

Indeed, thanks a lot for taking some of your time to pass the tests! Actually there are 2 numbers that bother me: those for the contended loops on the patched kernel (63 and 64 threads) - the last 2 numbers in the rightmost column. Did you have the opportunity to run that same test for 128 threads: this is just for me to check whether 64 is not the #of threads we are starting to slow down from. Thanks, Nadia --

Andrew, is it OK for you if ubifs-2.6.git will have some patches which ubi-2.6.git also contains. Will your -mm system handle this? -- Best Regards, Artem Bityutskiy (Артём Битюцкий) --

Yes. YH --

Yesm they should never had done that anyway. The module support does it's own version checking already. --

Hi - Sorry, I misspoke - this check is intended not to cross-check kernel-devel and the kernel itself, but the debuginfo or similar data that is given to describe target of a systemtap script. I guess for new enough kernels we'll just do that using buildid hash codes. By the way, there do appear to be a few suspect in-tree users of utsname() without uts_sem locking (usb/storage/usb.c, cifs/connect.c, char/random.cc, fs/lockd/clntproc.c, ...). If these need to be fixed, then wouldn't ...

On Mon, 19 May 2008 23:44:53 -0400 the audit subsystem already does all of this... why not use that?? copying twice does mean that if the user wants, he can cheat you. He can, in another thread, change the string under you. So say you're doing this for anti-virus purposes, he can make you scan one file and open another. The audit subsystem was carefully designed to avoid this trap... how about using that? --

On Mon, 19 May 2008 23:24:48 -0400 now that -mm has a WARN(condition, printk arguments), could we make this use it? The advantage (apart from smaller C code) is that it puts the printk inside the ---[ cut here ]--- which makes it more likely that reporters (and kerneloops.org) get the actual text.... --

On Tue, May 20, 2008 at 08:12:41AM -0700, Linus Torvalds wrote: > So no, lists aren't "special" in any inherent way, they are just special > in these kinds of "incidentally, a lot of random data structure corruption > has traditionally shown up in lists, because there are so many of them". It's also been _really_ useful for showing up random bit flips in bad hardware. "hey, if that bit had been a 1, this pointer would have looked valid and we wouldn't have oopsed" has led to quite a ...

On Tue, May 20, 2008 at 07:14:58AM -0700, Arjan van de Ven wrote: > On Mon, 19 May 2008 23:24:48 -0400 > Dave Jones <davej@redhat.com> wrote: > > > printk(KERN_ERR "list_add corruption. next->prev > > should be " "prev (%p), but was %p. (next=%p).\n", > > prev, next->prev, next); > > - BUG(); > > + WARN_ON(1); > > } > > > now that -mm has a WARN(condition, printk arguments), could we make > this use it? The advantage (apart from smaller C code) is that it puts > ...

It's not that list corruptions are special, but: - *any* corruption is very interesting, and the earlier we find it the better - we have a lot of lists in the kernel, so testing pointers is actually likely to find stuff. - and lists are something we can *test* for corruption That third one is important. Most random pointers we can't sanely test because they don't have trivial and important patterns. The second one is relevant too: some of the pointers that we *could* test ...

On Tue, 20 May 2008 07:54:10 -0700 (PDT) Dave...what Linus said ;) would be nice to get WARN() into mainline soon... ;) --

On Fri, May 2, 2008 at 5:16 PM, Bart Van Assche This patch is now obsolete and has been replaced by a new patch -- see also http://lkml.org/lkml/2008/5/20/32. Bart. --

No, sorry. I'm not sure if it should go to configfs, or if sysfs should be improved. But "something" should be done, because we will be stuck with this interface for a long while. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

ick. So we got caught partway through constification and we need to patch it up with a cast. --

<snip> None the less I've added the patch to Trivial. It's the Linux *kernel* after all, not the Linux kernal. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

I've added this one to the trivial tree. Thanks Nick. -- Jesper Juhl <jesper.juhl@gmail.com> Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html Plain text mails only, please http://www.expita.com/nomime.html --

Signed-off-by: Uwe Kleine-König <Uwe.Kleine-Koenig@digi.com> --- drivers/uio/Kconfig | 7 +++ drivers/uio/Makefile | 1 + drivers/uio/uio_pdrv.c | 118 ++++++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 126 insertions(+), 0 deletions(-) create mode 100644 drivers/uio/uio_pdrv.c diff --git a/drivers/uio/Kconfig b/drivers/uio/Kconfig index 78e139c..2e9079d 100644 --- a/drivers/uio/Kconfig +++ b/drivers/uio/Kconfig @@ -26,6 +26,13 @@ config UIO_CIF To compile ...

--

Updated patch to use existing GFP_KERNEL mask to indicating synchornous wait in journal_try_to_free_buffers() to resolve the race with journal_commit_transaction(). JBD: fix race between journal_try_to_free_buffers() and jbd commit transaction From: Mingming Cao <cmm@us.ibm.com> journal_try_to_free_buffers() could race with jbd commit transaction when the later is holding the buffer reference while waiting for the data buffer to flush to disk. If the caller of journal_try_to_free_buffers() ...

So something like this, then? diff --git a/fs/splice.c b/fs/splice.c index 7815003..e08a2f5 100644 --- a/fs/splice.c +++ b/fs/splice.c @@ -58,8 +58,8 @@ static int page_cache_pipe_buf_steal(struct pipe_inode_info *pipe, */ wait_on_page_writeback(page); - if (PagePrivate(page)) - try_to_release_page(page, GFP_KERNEL); + if (PagePrivate(page) && !try_to_release_page(page, GFP_KERNEL)) + goto out_unlock; /* * If we succeeded in removing the mapping, set LRU ...

What is actually the point of entering the function with j_state_lock held and also keeping it after return? It should be enough to take it This comment seems a bit misleading to me - I'd rather write there: @gfp_mask: we use the mask to detect how hard should we try to release buffers. If __GFP_WAIT and __GFP_FS is set, we wait for commit code to I think this test is wrong - it should rather be something like (ret == 0 && (gfp_mask & GFP_KERNEL == GFP_KERNEL)) - or even expand the test ...