As inode creation is protected by sysfs_mutex, ilookup5_nowait() always either fails to find at all or finds one which is fully initialized, so using ilookup5_nowait() or ilookup5() doesn't make any difference. Switch to ilookup5() as it's planned to be removed. This change also makes lookup return value handling a bit simpler. This change was suggested by Al Viro. Signed-off-by: Tejun Heo <tj@kernel.org> Cc: Al Viro <viro@hera.kernel.org> --- Greg, can you please put this for 2.6.28? ...

Hello, I rebased my changes to MAINTAINERS to Linus' current HEAD. In the meantime I'm not convinced anymore that restoring the alphabetic ordering is still worth the effort[1] because I work on decentralizing the info contained in that file. But I still think that merging P and M is sensible. So I changed the order of my commits to have the alphabetic order commit the topmost one. So now there are two branches, maintainers and maintainers-fixes that only differ in that one ...

I made this patch using bits and pieces from various other "ipw2200 injection patches". I can not take credit for the content, as I basically just changed the line numbers in the .diff files. However I applied this patch to the version of ipw2200 included in kernel 2.6.27-rc6 (i believe it's ipw2200-1.2.2) and it worked like a charm. Previously I was unable to inject wifi packets using aireplay-ng due to this error: "ARP linktype is set to 1 (Ethernet) - expected ARPHRD_IEEE80211 ...

Hallo, wollte Dir nur kurz mitteilen, dass dies die allerletzte Chance ist, Deine 800 Euro abzuholen. Jetzt oder nie: http://www.Bar-Bonus.net/ Viele liebe Grüsse, die Alex (, die gerade von Geschäftsreise in Köln schreibt) --

Hi, Linus, please pull from: master.kernel.org:/pub/scm/linux/kernel/git/bart/ide-2.6.git/ to receive the following updates: Documentation/ioctl/cdrom.txt | 4 ++-- drivers/ide/Kconfig | 14 ++++++++++++++ drivers/ide/ide-tape.c | 10 +++++----- drivers/ide/mips/swarm.c | 1 + 4 files changed, 22 insertions(+), 7 deletions(-) Borislav Petkov (1): ide-tape: fix vendor strings Márton Németh (1): cdrom: update ioctl ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11543 Subject : kernel panic: softlockup in tick_periodic() ??? Submitter : Joshua Hoblitt <j_kernel@hoblitt.com> Date : 2008-09-11 16:46 (17 days old) References : ...

config"?To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11512 Subject : sort-of regression due to "kconfig: speed up all*config + randconfig" Submitter : Alexey Dobriyan ...

[Empty message]

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11224 Subject : Only three cores found on quad-core machine. Submitter : Dave Jones <davej@redhat.com> Date : 2008-08-01 18:15 (58 days old) References : ...

nfigs?To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11230 Subject : Kconfig no longer outputs a .config with freshly updated defconfigs Submitter : Josh Boyer ...

6.28?To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11308 Subject : tbench regression on each kernel release from 2.6.22 -> 2.6.28 Submitter : Christoph Lameter ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11215 Subject : INFO: possible recursive locking detected ps2_command Submitter : Zdenek Kabelac <zdenek.kabelac@gmail.com> Date : 2008-07-31 9:41 (59 days old) References : ...

0x14/0x16?To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11380 Subject : lockdep warning: cpu_add_remove_lock at:cpu_maps_update_begin+0x14/0x16 Submitter : Ingo Molnar ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11476 Subject : failure to associate after resume from suspend to ram Submitter : Michael S. Tsirkin <m.s.tsirkin@gmail.com> Date : 2008-09-01 13:33 (27 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11340 Subject : LTP overnight run resulted in unusable box Submitter : Alexey Dobriyan <adobriyan@gmail.com> Date : 2008-08-13 9:24 (46 days old) References : ...

[Empty message]

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11207 Subject : VolanoMark regression with 2.6.27-rc1 Submitter : Zhang, Yanmin <yanmin_zhang@linux.intel.com> Date : 2008-07-31 3:20 (59 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11407 Subject : suspend: unable to handle kernel paging request Submitter : Vegard Nossum <vegard.nossum@gmail.com> Date : 2008-08-21 17:28 (38 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11608 Subject : 2.6.27-rc6 BUG: unable to handle kernel paging request Submitter : John Daiker <daikerjohn@gmail.com> Date : 2008-09-16 23:00 (12 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11550 Subject : pnp: Huge number of "io resource overlap" messages Submitter : Frans Pop <elendil@planet.nl> Date : 2008-09-09 10:50 (19 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11549 Subject : 2.6.27-rc5 acpi: EC Storm error message on bootup Submitter : <jmerkey@wolfmountaingroup.com> Date : 2008-09-02 21:27 (26 days old) References : ...

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11404 Subject : BUG: in 2.6.23-rc3-git7 in do_cciss_intr Submitter : rdunlap <randy.dunlap@oracle.com> Date : 2008-08-21 5:52 (38 days old) References : ...

OK, I dropped it from the list. Thanks, Rafael --

Some of the follow-up messages are borked because of a bug in my script. Sorry for that, the script has been fixed already. Thanks, Rafael --

This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11654 Subject : Devices enabled in /proc/acpi/wakeup do not wake up any more Submitter : Tino Keitel <tino.keitel@gmx.de> Date : 2008-09-22 20:29 (6 days old) References : ...

35?To: Linux Kernel Mailing List <linux-kernel@vger.kernel.org> This message has been generated automatically as a part of a report of recent regressions. The following bug entry is on the current list of known regressions from 2.6.26. Please verify if it still should be listed and let me know (either way). Bug-Entry : http://bugzilla.kernel.org/show_bug.cgi?id=11272 Subject : BUG: parport_serial in 2.6.27-rc1 for NetMos Technology PCI 9835 Submitter : Jaswinder Singh ...

Hi, On two of my servers (some Dell poweredge 1850 and 2850), booting a 2.6.26 debian kernel while at the same time looking at the serial console, nothing is printed after the following snippet: ... Linux agpgart interface v0.103 Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A ???????????????????????????????????????????????????????????????????????????????????????????????????????????????????????? The serial ...

On Sat, 27 Sep 2008 18:43:59 +0300 this doesn't seem to be much different from the way the DRM code deals with ioctls. Or the V4L code. Personally I hate that code though..... There is a fine balance here; between driver writers screwing something up they shouldn't be doing in the first place and us being able to clearly see what the code is doing; your patch kinda hides some key elements of the ioctl path... I'm afraid it gives a false sense of security though. Not having to deal with one ...

ioctls (as traditionally implemented) are very brittle; one cannot add a field to the argument structure without breaking the ABI. In many cases, this is a good thing as the ABI was not designed for extension. In other cases, however, it makes sense to design an ABI with extension in mind. This patch provides a new ioctl_dispatch_extensible(), which is designed to cope with evolving interfaces: - the ioctl number is matched only by its number and type, allowing size and direction to ...

ioctl handler writers currently have the following tasks: - allocate a buffer for the data, either in memory or on the heap, depending on the buffer size - handle errors - copy the data from userspace - handle errors - actually perform the intended operation - copy data back to userspace - handle errors - free the buffer, in case it was allocated on the heap This patch provides a dispatch_ioctl() helper, which will do all of these things for the caller, except for performing the ...

The read fail ratio is sensitive to the delay between the first byte written and the first byte read; apparently the sensors cannot be rushed. Increasing the minimum wait time, without changing the total wait time, improves the fail ratio from a 8% chance that any of the sensors fails in one read, down to 0.4%, on a Macbook Air. On a Macbook Pro 3,1, the effect is even more apparent. By reducing the number of status polls, the ratio is further improved to below 0.1%. Finally, increasing the total ...

Update the driver's introductory comments. Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> --- drivers/net/atlx/atl1.c | 10 +++------- 1 files changed, 3 insertions(+), 7 deletions(-) diff --git a/drivers/net/atlx/atl1.c b/drivers/net/atlx/atl1.c index 5f157e0..3cf59a7 100644 --- a/drivers/net/atlx/atl1.c +++ b/drivers/net/atlx/atl1.c @@ -24,16 +24,12 @@ * file called COPYING. * * Contact Information: - * Xiong Huang <xiong_huang@attansic.com> - * Attansic Technology ...

Remove the EXPERIMENTAL label from the atl1 driver and change the vendor name to include Attansic's successor, Atheros. We'll leave Attansic in the name since Attansic's PCI ID (1969) is encoded in the PCI config and is what users encounter on their systems. Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> --- drivers/net/Kconfig | 7 ++++--- 1 files changed, 4 insertions(+), 3 deletions(-) diff --git a/drivers/net/Kconfig b/drivers/net/Kconfig index 4a11296..1c8addf 100644 --- ...

NETIF_F_LLTX is deprecated. Remove private TX locking from the driver and remove the NETIF_F_LLTX feature flag. Signed-off-by: Jay Cliburn <jacliburn@bellsouth.net> --- drivers/net/atlx/atl1.c | 18 +----------------- 1 files changed, 1 insertions(+), 17 deletions(-) diff --git a/drivers/net/atlx/atl1.c b/drivers/net/atlx/atl1.c index e00a986..5f157e0 100644 --- a/drivers/net/atlx/atl1.c +++ b/drivers/net/atlx/atl1.c @@ -2109,7 +2109,6 @@ static u16 atl1_tpd_avail(struct atl1_tpd_ring ...

As I told Martin, I was thinking about taking an axe and moving stuff around in relay. Which I just did. This patch reimplements relay with a linked list of pages. Provides read/write wrappers which should be used to read or write from the buffers. It's the core of a layered approach to the design requirements expressed by Martin and discussed earlier. It does not provide _any_ sort of locking on buffer data. Locking should be done by the caller. Given that we might think of very lightweight ...

I can confirm this - he posted to alsa-devel saying that in response to Acked-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --

Hello, Linus, Please pull m32r updates from the following tree: git://www.linux-m32r.org/git/takata/linux-2.6_dev.git linux-m32r Thank you. -- Takata --- Adrian Bunk (5): m32r: remove the unused NOHIGHMEM option m32r: don't offer CONFIG_ISA m32r: export empty_zero_page m32r: export __ndelay m32r/kernel/: cleanups --- arch/m32r/Kconfig | 10 +--------- arch/m32r/kernel/entry.S | 2 +- arch/m32r/kernel/head.S | 1 - ...

Reserve bus range for SR-IOV at device scanning stage. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: Alex Chiang <achiang@hp.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Roland Dreier <rdreier@cisco.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> --- drivers/pci/iov.c | 24 ++++++++++++++++++++++++ drivers/pci/pci.h | 5 +++++ drivers/pci/probe.c | 3 +++ ...

Add Alternative Routing-ID Interpretation (ARI) support. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: Alex Chiang <achiang@hp.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Roland Dreier <rdreier@cisco.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> --- drivers/pci/pci.c | 31 +++++++++++++++++++++++++++++++ drivers/pci/pci.h | 12 ++++++++++++ ...

Export some functions and move some macros from c file to header file. Cc: Jesse Barnes <jbarnes@virtuousgeek.org> Cc: Randy Dunlap <randy.dunlap@oracle.com> Cc: Grant Grundler <grundler@parisc-linux.org> Cc: Alex Chiang <achiang@hp.com> Cc: Matthew Wilcox <matthew@wil.cx> Cc: Roland Dreier <rdreier@cisco.com> Cc: Greg KH <greg@kroah.com> Signed-off-by: Yu Zhao <yu.zhao@intel.com> --- drivers/pci/pci-sysfs.c | 10 ++++---- drivers/pci/pci.c | 2 +- drivers/pci/pci.h | ...

sounds great, i think some Infiniband HBAs have this capability; they even= =20 suggested using on Xen for faster (no hypervisor intervention) communicatio= n=20 between DomU's on the same box. (and transparently to out of the box, of=20 course) does it need an IOMMU (VT-d), or the whole magic is done by the PCI device? =2D-=20 Javier

fix hpa's t61 with 4g ram change layout from (n - 1)*chunksize + chunk_size - NC to n*chunksize - NC Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/mtrr/main.c | 81 ++++++++++++++++++---------------------- 1 file changed, 38 insertions(+), 43 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ ...

ok. Ingo --

change back chunksize max to 2g otherwise will get strange layout in 2G ram system like 0 - 4g WB, 2040M - 2048M UC, 2048M - 4G NC instead of 0 - 2g WB, 2040M - 2048M UC Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/mtrr/main.c | 8 ++++---- 1 file changed, 4 insertions(+), 4 deletions(-) Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- ...

Remove sub-buffers from relay. This patch removes the concept of sub-buffers from relay - everything now just operates on pages. relay_open() was also changed accordingly; instead of specifying buffer sizes in terms of sub-buffer sizes and numbers, the buffer size is specfied in pages. There's also a new param that specifies how often to wake up consumers, in terms of every n pages produced. If 0 is given for this param, consumers are never woken up. --- block/blktrace.c | 7 +- ...

Clean up remaining padding-related junk. Removes the rest of the padding-related junk. Also simplifies the subbuf_start callback a bit. --- block/blktrace.c | 5 +++-- include/linux/relay.h | 12 ++---------- kernel/relay.c | 20 ++++---------------- virt/kvm/kvm_trace.c | 7 ++++--- 4 files changed, 13 insertions(+), 31 deletions(-) diff --git a/block/blktrace.c b/block/blktrace.c index 150c5f7..271b7b7 100644 --- a/block/blktrace.c +++ b/block/blktrace.c @@ ...

Replace relay_reserve/relay_write with non-padded versions. The old versions of relay_reserve/relay_write would write/reserve an event only if the whole thing could fit in the remaining space of the current sub-buffer; if it couldn't it would add padding to the current sub-buffer and reserve in the next. The new versions don't add padding but use up all the space in a sub-buffer and write the remainder in the next sub-buffer. They won't however write a partial event - if there's not enough ...

Add reserved param to switch-subbuf, in preparation for non-pad write/reserve. Because a write/reserve can now cross sub-buffer boundaries, we use the length returned as a remainder for the new sub-buffer, and use the reserved param to return a pointer to the reserved space, or NULL if it couldn't be reserved. This patch also changes write/reserve to preserve their current behavior despite that change. This all goes away in a future patch, but is here now so things don't break. --- ...

Make the relay sub-buffer switch code replaceable. With this patch, tracers now have complete control over the relay write (or reserve) path if they choose to do so, by implementing their own version of the sub-buffer switch function (switch_subbuf()), in addition to their own local write/reserve functions. Tracers who choose not to do so automatically default to the normal behavior. --- include/linux/relay.h | 23 ++++++++++++++++++----- kernel/relay.c | 13 ++++++++----- 2 ...

Here's the current relay cleanup patchset. 1-2 make the write path completely replaceable. 3 adds flags along with some related cleanup. 4-8 remove the padding in several stages. The new patches in this set are: 9 simplifies the callbacks - now that we have flags, the subbuf_start callback is much simpler, has been combined with notify_consumers and has been renamed new_subbuf. Because part of the simplification has been to handle buffer-full conditions and count lost events ...

fix hpa's t61 with 4g ram 1. add mtrr_cleanup_debug to print out more info about layout 2. change layout from (n - 1)*chunksize + chunk_size - NC to n*chunksize - NC 3. change back chunksize to 2g otherwise will get strange layout in 2G ram system like 0 - 4g WB, 2040M - 2048M UC, 2048M - 4G NC instead of 0 - 2g WB, 2040M - 2048M UC Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/cpu/mtrr/main.c | 72 ...

I just triggered this with just modprobe kvm_intel ; rmmod kvm kvm_intel Dave ================================= [ INFO: inconsistent lock state ] 2.6.26.3-29.fc9.x86_64.debug #1 --------------------------------- inconsistent {hardirq-on-W} -> {in-hardirq-W} usage. Xorg/2680 [HC1[1]:SC0[0]:HE0:SE1] takes: (kvm_lock){+-..}, at: [<ffffffffa0463ad6>] decache_vcpus_on_cpu+0x20/0xbd [kvm] {hardirq-on-W} state was registered at: [<ffffffff81058ead>] __lock_acquire+0x62f/0xd89 ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Acked-by: Andrew G. Morgan <morgan@kernel.org> Cheers -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3bX0+bHCR3gb8jsRApVqAKCuFmvJTlIiAYxXW5W3JNncFYmmrQCfa95h Ik/MLVnpPtZdmuInkJSOof4= =3aYe -----END PGP SIGNATURE----- --

This one makes sense on its own, applied to: git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next - James -- James Morris <jmorris@namei.org> --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Serge, I have to say I'm a bit confused by this one. Specifically, the cap_get_target_pid() change. In your 5/6 patch, you say this change ("the previous patch") makes the kernel bigger? Is this because of the cap_get_target_pid() changes? Since you are fighting to reduce space, if it bloats the code does the cap_get_target_pid() part of the change make sense? Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 ...

Yes I think it does. Yes my goal was to decrease the kernel size, but having cleaner code - and getting rid of dead codepaths - is more important. It may be hard to tell by looking at the patch, but I think the end-result is really far better. thanks, -serge --

Yes, I did do that in a patch on top of all of these. It increased the kernel size by 8 (or was it 16) bytes :) I assume that was because now there were more references to 'current' which is inlined? So I should be able to fix that by saving current() away at the top of the fn. Will try that. thanks, --

Two error conditions at the top of get_file_caps() call bprm_clear_caps(). However, the bprm capabilities have not yet been set at this point. Remove those calls (saving another 16 bytes on vmlinux). Signed-off-by: Serge E. Hallyn <serue@us.ibm.com> --- security/commoncap.c | 8 ++------ 1 files changed, 2 insertions(+), 6 deletions(-) diff --git a/security/commoncap.c b/security/commoncap.c index e5afb7c..43bba7a 100644 --- a/security/commoncap.c +++ b/security/commoncap.c @@ ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 [...snip...] Cheers Andrew -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFI3bW9+bHCR3gb8jsRAoD6AKCdF8HNGdT8MPqWUBqrf8+BXGEyZwCfZc2T +/hD1+FB2fTLae+vEbKpWX0= =NerD -----END PGP SIGNATURE----- --

Following is a set of file capabilities cleanups. The first two patches are a repost of my previous patches which introduce a no_file_caps boot option, and remove the CONFIG_SECURITY_FILE_CAPABILITIES config option. The rest of the patches both clean up some of the capabilities code and reduce the kernel size (since enabling file capabilities grew it). Andrew Morgan, if you have a moment, please do take a close look and make sure I'm not doing anything stupid/wrong in the ...

The whole bio_integrity() definition is inside an #ifdef CONFIG_BLK_DEV_INTEGRITY, there's no need for the conditional code. Signed-off-by: Alberto Bertogli <albertito@blitiri.com.ar> --- include/linux/bio.h | 9 +-------- 1 files changed, 1 insertions(+), 8 deletions(-) diff --git a/include/linux/bio.h b/include/linux/bio.h index 0933a14..57f9532 100644 --- a/include/linux/bio.h +++ b/include/linux/bio.h @@ -458,14 +458,7 @@ static inline char *__bio_kmap_irq(struct bio *bio, unsigned ...

Uhm, no, they're defined by the _hypervisor_. -hpa --

I don't, realistically, think we can phase them out for a very long time, and then it's usually a "why bother". What we want to do is Agreed. However, that's obviously beyond our immediate control. -hpa --

Hi Jeremy, Please see my comments below. Avoiding existing leaves, Microsoft's Hypervisor is using levels 0x40000000 - 0x40000005. The first 2 are standard levels and the rest of them are Microsoft The unused (reserved) value is set to zero right now, whenever a need is For power management, the trend, even on native hardware, is toward a constant rate TSC. So, I don't see this is a big concern; after all a virtual cpu should be able to virtualize the TSC as constant rate even when ...

This is great, obviously... although we'll have to deal with legacy methods for a while if not indefinitely (just as we have to for This should be broken out into a separate file in cpu/*, because we I would call this "vmware_tsc_freq()" because it is a VMWare-defined interface... you can't just poke at 0x40000010 and assume it is using the VMWare definition. In order for *that* to be safe, you'd have to have well-defined ranges for different virtualization vendors where each of ...

Obviously the hypervisor implements such features, and the features available/exposed are up to the hypervisor. My point is that the kernel community can define such generic hypervisor features for Linux because the Linux kernel code needs to be modified anyway. Otherwise, each VMM vender could start changing the kernel in a random fashion. Or nothing happens... Today each hypervisor already defines and implements such features (or API), and they would need some kind of translation layer to support ...

So we already have a pci_iomap() which takes a 'max' argument. If you make 'max' -1, don't you get this same behaviour? -- Matthew Wilcox Intel Open Source Technology Centre "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." --

GREAT! --

Awesome...simply, awesome! I hereby nominate Atheros for this year's "Most Improved Open Source Corporate Citizen" award! :-) Great job, Luis! John -- John W. Linville Linux should be at the core linville@tuxdriver.com of your literate lifestyle. --

sending a message out for every READ/WRITE seems like it will generate a LOT of messages, and very few will be ones that anyone cares about. one of the nice things about the TALPA approach was that there was an ability to notify only on a change of state (i.e. when a file that had been scanned was changed) this could do a similar thing, but I think it would be a much more expensive process to do it all in userspace. David Lang --

On read there isn't much point anyway, on write if you simply send one, save an event counter number and don't send another until the last one is cleared it all works well. When the last event is cleared if another event has occurred then the event counter will have changed so you know to send one immediately, if the app doesn't want to receive them for a while it can just hang onto the event for a minute or two before clearing it. --

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= efi_call_virt<n> and efi_call_phys<n> is the API instead of efi_call<n>. And please put the implementation without CONFIG_EFI defined out of #ifdef CONFIG_X86_32 <...> #else <...> #endif Best Regards, Huang Ying

Just playing with the kernel :-) Sometimes the "insane" things to do will turn up real errors in the code. This one is in the borderlands, but I thought it wouldn't hurt to post the results in either case. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 --

To reinstate the paragraph from the O.P. you snipped: >> I'm not sure it's really a very good idea to do this in the first >> place, but should something give a warning or prevent a user from >> doing it? I think you are both right, it is a bad thing to do, it does seem to lock up, and something should prevent a user from doing that. But it may be easier to fix the lockup than get the "prevent" right, there appears to be a loop there. Just a simple questions to the O.P.: what were you ...

No problem, I have one other option: ignoring and sleep again before receiving another entries. I can do another patch this week end to implement that. The third patch only concerns the boot tracer. It relays to other output functions. Just tell me if you agree with the ignoring... Thanks ! --

Where is that? This is an issue because if we can get negative dentries the other dentry operations are wrong as well.n We hold the directory mutex in real_lookup before calling i_op->lookup. So lookups should be serialized. proc_sys_lookup always either succeeds and calls d_add with a valid inode or fails and returns an error code in which case real_lookup puts the dentry before it is hashed. We hold the directory mutex in readdir before calling file->f_op->readdir. Deep inside ...

What kernel? I have seen all those XFS oops/stack traces before. With the last pull request to linus for 2.6.27-rc7, all known causes of the btree corruption reported in your log messages should be fixed. I guess you'll have to wait for 2.6.27-rc8 or 2.6.28 for them.... FWIW, next time you have XFS issues, please make it clear in the subject line and cc xfs@oss.sgi.com. Cheers, Dave. -- Dave Chinner david@fromorbit.com --

(Please Cc: netdev@vger.kernel.org) Lin Tan <tammy000@gmail.com> : I would not bet that the irq handler does not race with el3_close() in the first place. Could you dig it ? -- Ueimor --

[Empty message]

OK, good. J --

We use it to ioremap things like the BIOS... --

the existing sanity check checks to see if the kernel thinks if the memory is usable for its own use, eg it uses the e820 table, the same one we use for feeding all memory into the page allocator. reserved and other similar types is not what ioremap complains about --

--

This ought to be fixed already. -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. --

It would probably be better to use something else than 'rb_', because that prefix is already used by the red-black trees, and exported as such (eg "rb_next()" etc). But at least as long as it's static, it's probably not _too_ noticeable if the rest of the names don't overlap. We _do_ include <linux/rbtree.h> almost everywhere, since we use those things in the VM, in timers etc, so it comes in through pretty much all headers. Linus --

For kicks I just added #include <linux/rbtree.h> and it still passed. I don't think we'll be adding new functions to rbtree.h, so it may be fine to stay with the rb_ prefix. -- Steve --

[ Changes since version 8: Two major bug fixes! - Had mix of referencing the pages link list with both page->lru and buffer_page->list. Perhaps they luckily were lined up. But I have no idea why this didn't totally crash my box. - Missed a write stamp update that would cause funny times ] From: Steven Rostedt <srostedt@redhat.com> Subject: Unified trace buffer This is a unified tracing buffer that implements a ring buffer that hopefully everyone will ...

Thanks for the explanation. I'll change buffer->cpus to be set to nr_cpu_ids. -- Steve --

One problem though, it's *theoretically* possible for num_possible to be less than nr_cpu_ids and a cpu index may extend past the end of your allocated array. This would happen if the cpu indices are allocated some other way than as each cpu is discovered. For example, a system might want a group of cpus in one section (say by node, or socket) and then a hole in the cpu_possible_map until the next group. nr_cpu_ids is guaranteed to be the highest possible cpu + 1. Cheers, Mike --

small nitpicking review, nothing structural yet: hm, should not be raw, at least initially. I am 95% sure we'll see lockups, we always did when we iterated ftrace's buffer implementation please use consistent vertical whitespaces. Above, in the struct ring_buffer definition, you can add another tab to most of the vars - that will also make the '**buffers' line look nice. same for all structs across this file. In my experience, a 50% vertical please name it ...

[ Changes since v7: - added the size of data in the page into the page frame. Suggested by Martin Bligh and Mathieu Desnoyers - Converted all static functions to be named with a rb_ prefix. This may conflict with rbtree functions in the future, but if this does happen, we will need to rename the functions in this file. The rb_ prefixed functions here are all static, so it only affects this code. Thanks to Arnaldo Carvalho de Melo. - Added some ...

that's really not a hard limit, but yeah. oh, btw., that's a spelling mistake: s/extend/extend ? Ingo --

[Empty message]

assuming it's reported to the gcc folks too, do you have any objections against including this in tip/x86/signal? The 1% improvement in lmbench is quite nice. Ingo --

Is the dynamic debug printk work going upstream with the next merge window? If yes then I'll wait until it hit Linus tree and update my patch. -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

Urgs, you are after a sort of definition what the differences is between a warning, an error, an alert, etc is, aren't you? -- blue skies, Martin. "Reality continues to ruin my life." - Calvin. --

not a problem really - it's not really complex or intrusive, we just want to make sure all unnecessary duplication is eliminated. Ingo --

hm, right now i can see a lot of problems with that approach - the buffers are partly per tracer and partly global. the new trace-ringbuffer design Steve is working on would abstract away this complication - then we could make tracers truly independent entities. Ingo --

dont worry about that aspect too much, the ring buffer API will be a transparent replacement, so try to iterate whatever is there at the moment towards perfection :) Ingo --

applied these patches to tip/x86/iommu: 0114267: x86/iommu: use __GFP_ZERO instead of memset for GART 3610f21: x86/iommu: convert GART need_flush to bool 237a622: x86/iommu: make GART driver checkpatch clean thanks Joerg! Fujita, do they look fine to you too? Ingo --

also merged into the original patch --

ok, figure it out, the problem was that your change depended on tip/timers/hpet-percpu. sorted it out. Ingo --

[Ingo Molnar - Sat, Sep 27, 2008 at 08:53:06PM +0200] | ... A bit offtopic...well...completely offtopic I would say :) Ingo maybe you have any PCI specs? I've asked several people for this. Peter adviced to ask HW vendors but I don't have friends who has access to a such docs. Evgeniy Polyakov promised to ask someone but I think there will not be success too :(. I'll ask Maciej too later since now he seems to be quite busy. - Cyrill - --

Looks good to me Acked-by: Balbir Singh <balbir@linux.vnet.ibm.com> provided we push in the lockless ones too :) -- Balbir --

On Fri, 26 Sep 2008 19:43:09 +0900 This helps some, but causes other troubles. (But I know what it is.) I'll add lock_page_cgroup() to charge side and see what happens. Thanks, --

On Fri, 26 Sep 2008 14:54:22 +0900 Try to illustrate what is trouble more precisely. in do_swap_page(), page is charged when SwapCache lookup ends. Here, - charged when page is not mapped. - not charged when page is mapped. set_pte() etc...are done under appropriate lock. On the other side, when a task exits, zap_pte_range() is called. It calls page_remove_rmap(). Case A) Following is race. Thread A Thread B do_swap_page() ...

I'm not so keen on that particular overloading, but I can understand why it might be wanted on systems which have a happy one-to-one mapping between GPIOs and pins. If you do that, be ready to provide a pinmux-only interface Yeah. Better to test-and-set the flag and then request, and backout if it fails, than the other way. Just who wrote that crap in the first place? Sigh. (Notice it's done that way already in the code path handling implicit requesting ... ) I'll send an updated ...

Applied to async_tx.git/next. -- Dan --

that has some marginal use: it shows that we are past the really basic system setup code, we decompressed the kernel and entered protected mode with boot paging enabled. we had bugs in the past where we'd hang/crash after GRUB starts us and before we reach this printk. OTOH ... forcing it upon all users is strong. Feel free to send another patch that removes it. Ingo --

(Cc: added. Mail-Followup-To is evil.) --

Mathieu seems to disagree, it would be good if he can share some specifics so we can work on resolving those. --

Just a note. The current ring buffering system that I'm proposing keeps its own time stamp counter (currently sched_clock) that will most likely be updated later. I'm trying to keep this ring buffer system as dumb as possible. It does not even implement the merge sort. That's up to the tracer to handle. There's nothing stopping the trace from adding some atomic counter to each event to help it sort. So yes, the tracer can implement anything it wants on top of the ring buffer ...

ah, i see what you mean. I think that's an orthogonal property. Well, it's important in some cases, not that important in other cases. Historically we've been flip-flopping on that issue in ftrace, whether it should be coherent by default or not. We had at least three of four variations of global synchronization. (one was an atomic generation counter, another variant a global lock) Eventually people noticed the overhead and asked for it to be faster. If all you do is to trace ...

Looks good to me, and seems to work fine here. Thanks for the patch. Greg, can you pick up the patch below? Thanks, Kay From: Drew Moseley <dmoseley@mvista.com> Subject: PNP: create device attributes via default device attributes This creates the attributes before the uevent is sent. Signed-off-by: Drew Moseley <dmoseley@mvista.com> Acked-by: Kay Sievers <kay.sievers@vrfy.org> --- diff --git a/drivers/pnp/base.h b/drivers/pnp/base.h index 9fd7bb9..3532984 100644 --- ...

I'm not sure what you have in mind, but I agree with Amit that conceptually pvdma should be called after the guest's "native" dma_ops have done their thing. This is not just for nommu, consider a guest that is using an (emulated) hardware IOMMU, or that wants to use swiotlb. We can't replicate their functionality in the pv_dma_ops layer, we have to let them run first and then pass deal with whatever That's a very good question. The host will need to be aware of a device's DMA capabilities in ...

On Wednesday 24 September 2008, Sergei Shtylyov wrote: applied --

[Empty message]

No, but just did, EC storm issue is gone, but thats all that is gone, still same hang after second resume No ec storm message after first resume ether, now no error messages at all in dmesg.... Best regards, Maxim Levitsky --

hm, these seem to be fixed already, via: | commit 9a7e0b180da21885988d47558671cf580279f9d6 | Author: Peter Zijlstra <a.p.zijlstra@chello.nl> | Date: Tue Aug 19 12:33:06 2008 +0200 | | sched: rt-bandwidth fixes is all in tip/master. (or is perhaps the direction of your patch wrong?) Ingo --

applied to tip/irq/sparseirq - and added your Acked-by. Thanks guys! Ingo --

very weird. Would be very nice to figure it out. and in tip/master we dont have the 'ftraced' kernel-patching kernel thread anymore, so ftrace should be passive by all means. OTOH, what does 'truning on dftrace' exactly mean? Just enabling it in the .config, or also activating it via /debug/tracing/current_tracer? Ingo --

I hate trips where my email box becomes filled. I skip over a lot of emails that I should not have. I think I added a way to do this. Hmm, I think it was in -rt that I added it, and have not gotten around to sending you the updates. Yes, we need an easy way to disable the tracer. I think we have ftrace_disable() function. Perhaps that only disables tracing that checks the tracing_disabled variable. Anyway, I made sure the new ring_buffer code has an easy way to disable it. -- ...

Thanks Greg, but I'm afraid that still gives me the error: ppdev0: registered pardevice sysctl table check failed: /dev/parport/parport0/devices/ppdev0/timeslice Sysctl already exists Pid: 7104, comm: hpijs Not tainted 2.6.27-rc7 #21 Call Trace: [<ffffffff8024d2ac>] set_fail+0x48/0x53 [<ffffffff8024d7a1>] sysctl_check_table+0x4ea/0x531 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531 [<ffffffff8024d7ba>] sysctl_check_table+0x503/0x531 [<ffffffff8024d7ba>] ...

[Empty message]

No problem at all. Works correctly (applied on top of current git). I don't see any unexpected changes in the dmesg output, so: Tested-by: Frans Pop <elendil@planet.nl> Cheers, FJP --

Hi, ...my patch just modified the code to also set ->capacity64 in places which previously were modifying ->blocks and/or ->bs_factor (since ->capacity64 replaced open-coded ->blocks * ->bs_factor calculation), so I think that the above problem is as an orthogonal issue and it is the best to address it in separate pre- or post- patch (could you please take care of it?). I did it ide_floppy_capacity()-way to match ide_disk_capacity() and ease the merge (probably ide_gd_capacity() can ...

could you please send whatever .c changes you have already, so that we can have a look at how the end result will look like? Doesnt have to build, i'm just curious about how it looks like in practice, semantically. Ingo --

OK, so apologies, but this has been a long thread, and maybe we could use a summary of the symptoms and the results so far. I think you said 2.6.24 or .25 was the last you're *positive* was good? --b. --