This patch adds the Intel Ibex Peak (PCH) SMBus Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6/drivers/i2c/busses/Kconfig.orig 2008-08-27 12:11:03.000000000 -0700 +++ linux-2.6/drivers/i2c/busses/Kconfig 2008-08-27 12:11:24.000000000 -0700 @@ -97,6 +97,7 @@ ICH9 Tolapai ICH10 + PCH This driver can also be built as a module. If so, the module will be called i2c-i801. --- ...

This patch adds the Intel Ibex Peak (PCH) SATA RAID Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6/drivers/ata/ahci.c.orig 2008-08-27 11:48:10.000000000 -0700 +++ linux-2.6/drivers/ata/ahci.c 2008-08-27 11:49:23.000000000 -0700 @@ -487,7 +487,9 @@ { PCI_VDEVICE(INTEL, 0x3a05), board_ahci }, /* ICH10 */ { PCI_VDEVICE(INTEL, 0x3a25), board_ahci }, /* ICH10 */ { PCI_VDEVICE(INTEL, 0x3b24), board_ahci }, /* PCH RAID */ + { PCI_VDEVICE(INTEL, ...

This patch updates the Intel Ibex Peak (PCH) IDE mode SATA Controller DeviceIDs. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6/drivers/ata/ata_piix.c.orig 2008-08-27 11:32:28.000000000 -0700 +++ linux-2.6/drivers/ata/ata_piix.c 2008-08-27 11:47:59.000000000 -0700 @@ -278,12 +278,15 @@ /* SATA Controller IDE (PCH) */ { 0x8086, 0x3b20, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ich8_sata }, /* SATA Controller IDE (PCH) */ + { 0x8086, 0x3b21, PCI_ANY_ID, PCI_ANY_ID, 0, 0, ...

/proc/acpi/ibm/wan stopped appearing for me at some point recently (bluetooth is still there). I guess this has something to do with the RFKILL changes, but I haven't looked at them in detail. I guess my question is: is this expected, and what's the "proper" way to control the WWAN radio now? Thanks, J --

Actually, that may be it. I think I used to load it as a module, and modprobe.conf set experimental=1, but I don't have an equivalent on the kernel command line. I think I'll submit a patch to remove the need for experimental; it's been working fine for me for 3 years now. J --

The checks for ensuring that the array indices are inside the range were flipped. Reported-by: Adrian Bunk <bunk@kernel.org> Signed-off-by: Adrian Bunk <bunk@kernel.org> --- 1743b2c1c483c8f1e5c6f706b8937136359f5aeb diff --git a/drivers/isdn/mISDN/dsp_cmx.c b/drivers/isdn/mISDN/dsp_cmx.c index e92b1ba..c2f51cc 100644 --- a/drivers/isdn/mISDN/dsp_cmx.c +++ b/drivers/isdn/mISDN/dsp_cmx.c @@ -452,10 +452,10 @@ one_member: if (finddsp->features.pcm_id == dsp->features.pcm_id) { if ...

Add the missing XCR0(XFEATURE_ENABLED_MASK) restore during resume. Reported-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> --- diff --git a/arch/x86/power/cpu_32.c b/arch/x86/power/cpu_32.c index d3e083d..274d060 100644 --- a/arch/x86/power/cpu_32.c +++ b/arch/x86/power/cpu_32.c @@ -11,6 +11,7 @@ #include <linux/suspend.h> #include <asm/mtrr.h> #include <asm/mce.h> +#include <asm/xcr.h> static struct saved_context ...

> There isn't. It's gcc being buggy and inconsistent. Thanks, I'll file a gcc bug I guess. - R. --

Not any. Ones that do not fit into range of int but do fit into the range of unsigned are. Really, folks, it's not _that_ hard: Type sequence: int, unsigned int, long, unsigned long, long long, unsigned long long. With U suffix => don't bother with signed types Without U suffix, decimal => don't bother with _un_signed types With L suffix => don't bother with anything earlier than long With LL suffix => don't bother with anything earlier than long long Pick the first type that covers your ...

There isn't. It's gcc being buggy and inconsistent. --

Noticed by sparse: block/blk-softirq.c:156:12: warning: symbol 'blk_softirq_init' was not declared. Should it be static? block/genhd.c:583:28: warning: function 'bdget_disk' with external linkage has definition block/genhd.c:659:17: warning: incorrect type in argument 1 (different base types) block/genhd.c:659:17: expected unsigned int [unsigned] [usertype] size block/genhd.c:659:17: got restricted gfp_t block/genhd.c:659:29: warning: incorrect type in argument 2 (different base ...

Increase the range of various posix message queue limits. Posix gives the message queue user the ability to 'trade off' the maximum size of messages with the number of possible messages that can be 'in flight'. Linux currently makes this trade off more restrictive than it needs to be. In particular, the maximum message size today can be made no smaller than 8192. This greatly restricts those applications that would like to have the ability to post large numbers of very small ...

IMO all char-device registration/deregistration routines should use a I don't feel competent to start writing such a file. Greg, what do you think? Maybe all that's needed to get going is to "borrow" some of the material in LDD3. :-) Alan Stern --

This is an example of what I was discussing with Oliver. In all likelihood you simply don't need usbtmc_mutex, and using it will cause a lockdep violation. That's why so many of the other USB class drivers don't have an You must never acquire a lock in your open method if it will be held But you don't call usb_unregister_dev() during disconnect. An oversight? Alan Stern --

Well, as the USB chapter in LDD3 "borrowed" heavily from the comments in the usb code itself, that would only be fair :) That chapter needs to be reworked. The authors and Oreilly and I are currently talking about how to do this all in a framework that makes sense (the current one of a book every few years that quickly gets out of date doesn't make sense.) thanks, greg k-h --

Yes, once you add the call to usb_deregister_dev. You mean that the open/disconnect locking rule applies only to drivers that call usb_register_dev, i.e, drivers using the USB major. Right? I agree that it deserves to be mentioned in the documentation somewhere. Where would be a good place? None of the existing files in Documentation/usb seem appropriate. Alan Stern --

Here's an updated version of the usbtmc driver, with all of the different issues that have been raised, hopefully addressed. thanks, greg k-h ---------- From: Greg Kroah-Hartman <gregkh@suse.de> Subject: USB: add USB test and measurement class driver This driver was originaly written by Stefan Kopp, but massively reworked by Greg for submission. Thanks to Felipe Balbi <me@felipebalbi.com> for lots of work in cleaning up this driver. Thanks to Oliver Neukum <oliver@neukum.org> for ...

After returning from my holidays, I proceeded to test 2.6.27-rc4. 2.6.26 works fine, but 2.6.27-rc4 gives me lots of: Aug 27 18:03:10 middle kernel: in_atomic():1, irqs_disabled():0 Aug 27 18:03:10 middle kernel: Pid: 1185, comm: md2_raid1 Not tainted 2.6.27-rc4 #2 Aug 27 18:03:10 middle kernel: Aug 27 18:03:10 middle kernel: Call Trace: Aug 27 18:03:10 middle kernel: [<ffffffff802303fb>] __might_sleep+0xdb/0x100 Aug 27 18:03:10 middle kernel: [<ffffffff802734a9>] ...

Different workloads give different results. Yours sounds CPU-intensive. Kernel builds here run at 50-60% of native with skas0, low 80's with skas3, and ~86% with skas4. Jeff -- Work email - jdike at linux dot intel dot com --

That stuff, as you can see by the "old" in the URL, is old. SKAS3 is still a significant performance boost. Jeff -- Work email - jdike at linux dot intel dot com --

Export the throttling statistics collected for each task through /proc/PID/io-throttle-stat: - total number of delayed I/O request - total amount of time in jiffies spent to wait for the delayed requests Signed-off-by: Andrea Righi <righi.andrea@gmail.com> --- fs/proc/base.c | 15 +++++++++++++++ 1 files changed, 15 insertions(+), 0 deletions(-) diff --git a/fs/proc/base.c b/fs/proc/base.c index 01ed610..9983730 100644 --- a/fs/proc/base.c +++ b/fs/proc/base.c @@ -54,6 +54,7 @@ ...

This is the core io-throttle kernel infrastructure. It creates the basic interfaces to cgroups and implements the I/O measurement and throttling functions. Signed-off-by: Andrea Righi <righi.andrea@gmail.com> --- block/Makefile | 2 + block/blk-io-throttle.c | 672 +++++++++++++++++++++++++++++++++++++++ include/linux/blk-io-throttle.h | 72 +++++ include/linux/cgroup_subsys.h | 6 + init/Kconfig | 10 + 5 files changed, 762 ...

Documentation of the block device I/O controller: description, usage, advantages and design. Signed-off-by: Andrea Righi <righi.andrea@gmail.com> --- Documentation/controllers/io-throttle.txt | 377 +++++++++++++++++++++++++++++ 1 files changed, 377 insertions(+), 0 deletions(-) create mode 100644 Documentation/controllers/io-throttle.txt diff --git a/Documentation/controllers/io-throttle.txt b/Documentation/controllers/io-throttle.txt new file mode 100644 index 0000000..09df0af --- ...

This makes the new implementation of the byteorder helpers match the old in how it degraded when an arch-defined version was not available: 1) swab() - look for arch defined - if not, use generic c version 2) swabp() - look for arch-defined - if not, deref pointer and use swab() 3) swabs() - look for arch defined - if not, use swabp Signed-off-by: Harvey Harrison <harvey.harrison@gmail.com> --- David, I hope this has covered the last of your objections...also note that once ...

On Wed, 27 Aug 2008 23:01:52 +0200 percpu_counter_read() was irq-safe. That changes here. Needs careful review, changelogging and, preferably, runtime checks. But perhaps they should be inside some CONFIG_thing which won't normally be done in production. otoh, percpu_counter_read() is in fact a rare operation, so a bit of overhead probably won't matter. (write-often, read-rarely is the whole point. This patch's changelog's assertion that "Since fbc->count is read more frequently and ...

fbc->count is of type s64. The change was introduced by 0216bfcffe424a5473daa4da47440881b36c1f4 which changed the type from long to s64. Moving to s64 also means on 32 bit architectures we can get wrong values on fbc->count. Since fbc->count is read more frequently and updated rarely use seqlocks. This should reduce the impact of locking in the read path for 32bit arch. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> CC: Peter Zijlstra <a.p.zijlstra@chello.nl> CC: Andrew ...

Shrink the printk timestamp field. Keep the printk timestamp from occupying more of the scarce, 80-column console line space than it really needs. We eliminate the excessive whitespace the field added to the line, and reduce timestamp precision from six digits (usecs) to three digits (msecs). msecs seems adequate for the purpose of tracking boot sequence timing issues. Signed-off-by: Joe Korty <joe.korty@ccur.com> Index: ...

That certainly is the better approach. Joe --

It's also very useful while the system is running. We've had problems with systems where the HDD or libata was "hiccuping" and stalling the entire system for 30 seconds; our logs were useless, as syslog was timestamping with the timestamp *after* the stall ended (as that was when it received the message), and dmesg had no timestamps. In this case, our problem ran away and hid when we turned on printk timestamps, but if it recurred, we'd want the timestamps available to let us work out which ...

It'd be nicer if this were optional - syslog typically only logs at second resolution and not all systems are going to have logfiles. --

Optionally suppress printk timestamping after system boot. A new config option is introduced, which if selected suppresses printk timestamping after the boot sequence is completed. Signed-off-by: Joe Korty <joe.korty@ccur.com> Index: 2.6.27-rc4-git4/kernel/printk.c =================================================================== --- 2.6.27-rc4-git4.orig/kernel/printk.c 2008-08-27 09:37:52.000000000 -0400 +++ 2.6.27-rc4-git4/kernel/printk.c 2008-08-27 12:35:14.000000000 -0400 @@ ...

According to the ACPI-WMI spec, event blocks may provide a function call for enabling/disabling them. This patch adds support for making these calls when registering or removing notifications. Without this, my Dell firmware provides no data in the event notification. Signed-off-by: Matthew Garrett <mjg@redhat.com> --- diff --git a/drivers/acpi/wmi.c b/drivers/acpi/wmi.c index c33b1c6..c7f735f 100644 --- a/drivers/acpi/wmi.c +++ b/drivers/acpi/wmi.c @@ -217,6 +217,35 @@ static bool ...

Make poll_idle() behave more like the other idle methods. Currently, poll_idle() returns immediately. The other idle methods all wait indefinately for some condition to come true before returning. poll_idle should emulate these other methods and also wait for a return condition, in this case, for need_resched() to become 'true'. Without this delay the idle loop spends all of its time in the outer loop that calls poll_idle. This outer loop, these days, does real work, some of it under rcu ...

The map_to_7segment.h provides generic 7segment LED mappings and is designed to be used by other drivers. Moving it to common area will make it more usable. Signed-off-by: Atsushi Nemoto <anemo@mba.ocn.ne.jp> --- This is renaming patch. I can send no-rename patch if requested. drivers/input/misc/yealink.c | 2 +- .../input/misc => include/linux}/map_to_7segment.h | 2 -- 2 files changed, 1 insertions(+), 3 deletions(-) rename {drivers/input/misc => ...

Forcedeth: increase max_interrupt_work This eliminates the following often-generated warning from my 64 bit Opteron SMP test stand: eth0: too many iterations (6) in nv_nic_irq According to the web, the problem is that the forcedeth driver has a too-low value for max_interrupt_work. Grepping the kernel I see that forcedeth has the second lowest value of all ethernet drivers (ie, 6). Most are in the 20-40 range. So this patch increases this a bit, from 6 to 15 (at 15 forcedeth becomes ...

Hi. I seem to be getting these more frequently on 2.6.26.1 16 core Sun X4600 amd64 with 60GB memory. [75586.058734] INFO: task gvim:13618 blocked for more than 120 seconds. [75586.058787] "echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message. [75586.058831] efam_xapianin D ffff81010721e280 0 13618 27917 [75586.058835] ffff8109384afd78 0000000000000086 ffff8109384afd40 ffffffff8044c886 [75586.058838] ffffffff8061e280 ffffffff8061e280 ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Ummm... I'll check. I'm not sure exactly how Stephen wanted to play this. David --

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

What do we get from copy-on-write credentials ? I've never seen credentials of any kind showing in profiles so why do we need this ? Alan --

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

These patches build on patch 9e2b2dc4133f65272a6d3c5dcb2ce63f8a87cae9 (CRED: Introduce credential access wrappers) to wrap most of the accesses to a task's credentials, whether by the task itself or by another task. Not all are wrapped: under certain circumstances it is preferable or necessary to deal with some accesses in other ways. These will be dealt with by patches that aren't in this set but are in linux-next. The wrappings are there to make the implementation of copy-on-write ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

OK. Feel free to push this with the rest of them, if you haven't already, with my blessing. r, Kyle --

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

-- David Kleikamp IBM Linux Technology Center --

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Wrap access to task credentials so that they can be separated more easily from the task_struct during the introduction of COW creds. Change most current->(|e|s|fs)[ug]id to current_(|e|s|fs)[ug]id(). Change some task->e?[ug]id to task_e?[ug]id(). In some places it makes more sense to use RCU directly rather than a convenient wrapper; these will be addressed by later patches. Signed-off-by: David Howells <dhowells@redhat.com> Reviewed-by: James Morris <jmorris@namei.org> Acked-by: Serge ...

Acked-by: Mark Fasheh <mfasheh@suse.com> -- Mark Fasheh --

/dev/modem is a symlink to be created by the management tool of your distribution. The kernel is not involved. As for lspci, it lists pci devices. Your modem is isa. Everything seems the be as it should be from a kernel viewpoint. Regards Oliver --

> On Tue, 2008-08-26 at 15:09 -0400, John Blackwood wrote: > > > Hi Peter, > > > > > > When sysctl_sched_rt_runtime is set to something other than -1 and the > > > CONFIG_RT_GROUP_SCHED kernel parameter is NOT enabled, we get into a state > > > where we see one or more CPUs idling forvever even though there are > > > real-time > > > tasks in their rt runqueue that are able to run (no longer throttled). > > > > > > The sequence is: > > > > > > - A real-time task is running ...

From: Jeff Garzik <jeff@garzik.org> Pulled, thanks a lot Jeff. --

Hi all, for some setups (eg dmraid or multipathing) the in-kernel partition scan is pointless; the (block) partitions won't be used anywhere. Instead the system will be using kpartx-generated device-mapper devices. Worse, on some setups (RAID0 dmraid or active/passive multipath devices) the in-kernel partition scan will generate plenty of I/O errors as the partitions table might not be accessible or invalid for this device. This patch implements a new kernel command-line option ...

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- sound/core/pcm_native.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/sound/core/pcm_native.c b/sound/core/pcm_native.c index c49b9d9..cb202a1 100644 --- a/sound/core/pcm_native.c +++ b/sound/core/pcm_native.c @@ -3391,6 +3391,12 @@ out: } #endif /* CONFIG_SND_SUPPORT_OLD_API */ +unsigned long ...

On Wed, Aug 27, 2008 at 05:39:26PM +0800, Bryan Wu wrote: This looks basically good, thanks - I've picked up a few things below but they are mostly either minor or reflect the fact that the patch looks like it's been developed against current release kernels but Current kernels have a Kconfig option SND_SOC_ALL_CODECS which should have your codec added - this allows codec drivers to be built without Please convert these to use the standard pr_ macros (or ideally the dev_ Please keep the ...

Hi folks, It's very happy to release this ASOC Blackfin ports. Please review our drivers and feel free to ask us update it. In this patchset, we post ASOC Blackfin supports, SSM2602 audio codec driver and other 2 ALSA/ASOC patches. Thanks a lot -Bryan --

From: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Cliff Cai <cliff.cai@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- include/linux/i2c-id.h | 1 + sound/soc/codecs/Kconfig | 3 + sound/soc/codecs/Makefile | 2 + sound/soc/codecs/ssm2602.c | 837 ++++++++++++++++++++++++++++++++++++++++++++ sound/soc/codecs/ssm2602.h | 132 +++++++ 5 files changed, 975 insertions(+), 0 deletions(-) create mode 100644 sound/soc/codecs/ssm2602.c create mode 100644 ...

I just want to run an exectable with limited capabilities and assumed the following approach would work fine: 1) fork process 2) in child 2.1 set current capabilities (eip) using cap_set_proc 2.2 execve the executable. But it frigging does not work! Just before the execve, the result of cap_to_text is = cap_net_bind_service+eip but, in the execve executable, the result is suddenly = cap_net_bind_service+i Why does the execve clear the effective and permitted ...

eth0: RTL8169 at 0xe04ee000, 00:1e:68:a0:07:b5, XID 24a00000 IRQ 17 --

Ok, that's obviously not good. I checked the Realtek driver for 8101E (version r8101-1.009.00) and while it doesn't do any 8-bit writes to register 0x82 it does perform 32-bit writes to register 0x80 (EPHYAR) to communicate with the PHY. I have no idea what that 8-bit write does except it breaks the chipset in my LG P300... How does the kernel identify your chipset upon driver load? (grep for XID) //Marcus -- ---------------------------------------+-------------------------- Marcus ...

Add maintainers for VIA UniChrome(Pro)/Chrome9 Framebuffer driver Signed-off-by: Joseph Chan <josephchan@via.com.tw> Signed-off-by: Scott Fang <ScottFang@viatech.com.cn> --- a/MAINTAINERS 2008-08-27 16:41:42.000000000 +0800 +++ b/MAINTAINERS 2008-08-27 16:56:36.000000000 +0800 @@ -4441,6 +4441,14 @@ L: i2c@lm-sensors.org S: Maintained +VIA UNICHROME(PRO)/CHROME9 FRAMEBUFFER DRIVER +P: Joseph Chan +M: JosephChan@via.com.tw +P: Scott ...

Confirmed. However now I'm getting device-mapper errors on 'cryptsetup create': dmesg: ... device-mapper: core: bdget failed in dm_suspend device-mapper: ioctl: device doesn't appear to be in the dev hash table. ... cryptsetup: ... Command failed: device-mapper: resume ioctl failed: Invalid argument ... next-20080826 is fine BTW it also seems that certain people need some encouragement to fix the nasty warning first reported by Randy two weeks ...

Hi all, Changes since next-20080826: Linus' tree lost its build fix patch. The arm tree lost its conflict. The ide tree lost if build fix patch. The kvm tree lost a conflict. The rr tree gained a build fix patch. The block tree gained a conflict against each of the test and ide trees. The creds tree gained a conflict against Linus' tree. The sparseirq tree losta its build fix patch. I have also applied the following patches for known problems: ftrace: protect the ...

Hello, SOUND_OSS_CORE should be turned on if ALSA OSS emul is turned on or arch-um hostsound is turned on, both of which can be enabled regardless Ah.. right. Moving. Thanks. -- tejun --

At Wed, 27 Aug 2008 11:37:44 +0200, Yes, sorry, I didn't cite clearly. I meant only the last line. sound/oss/dmasound/Kconfig is included and evaluated outside the block "if SOUND_PRIME". Thus, CONFIG_SOUND_OSS_CORE won't be enabled for drivers in sound/oss/dmasound. My suggestion is to move that line source sound/oss/dmasound/Kconfig into the "if SOUND_PRIME" block first, then apply your patch. Anyway, there are some other minor issues in sound/Kconfig, for example, why "if !M68K" is ...

At Wed, 27 Aug 2008 10:19:35 +0200, This seems missing from the scope. This alias should be in #ifdef CONFIG_SOUND_OSS_CORE. The module doesn't provide that major without CONFIG_SOUND_OSS_CORE. Takashi --

sound/sound_core.c implements soundcore.ko contains two parts - sound_class which is shared by both ALSA and OSS and device redirection support for OSS. It's always compiled when any sound support is enabled although it's necessary only when OSS (the actual one or emulation) is enabled. This is slightly wasteful and as device redirection always registers character device region for major 14, it prevents alternative implementation. This patch introduces a new config SOUND_OSS_CORE which is ...

Hi Linus, Lets try this again. I pulled out the b0rken xen patch and the scsi command table addition, since the latter can easily wait for 2.6.28 (and in 2.6.27, users can just change the table after boot). So please pull the revised collection from the below git url, thanks! git://git.kernel.dk/linux-2.6-block.git for-linus Adel Gadllah (1): block: clean up cmdfilter sysfs interface FUJITA Tomonori (5): block: move cmdfilter from gendisk to request_queue sg: ...

which will make some archs quite unhappy iirc, see those arm and ia64 bugs I caused the other day. --

hm, i'm not sure i like the whole direction - this reintroduces printk_clock in essence. how about initializing cpu_clock() sooner, so that printk timestamps start ticking as soon as possible? Ingo --

On Wed, Aug 27, 2008 at 12:40 AM, Benjamin Herrenschmidt i should split it into two patches. that patch include two patch second part is doing map to scratch memory. but memory near TOP of MEMORY and TOP of MEMORY2, could have the same problem. YH --

Nice! Could this be the root cause of those skb corruptions and e1000 crashes you've been reporting? So the _usual_ setup accidentally protects us from these prefetch induced failures. I think your patch is fine for the iommu bits, but the reserve_last_page() thing should be done in a cleaner way. Cannot we just reserve it all at the e820 stage, before passing that RAM to the bootmem allocator? Also, what is the guarantee that 4K of a space is enough to stop all prefetching across ...

good spotting! Applied to tip/core/urgent, thanks. Ingo --

Hi Bruce, I do not think it is a good idea to do multiplication every time we need MTD device size. It is unnecessarily large overhead in terms of speed and code size. Did you consider a possibility of just making mtd->size 64 bit? Or using eraseblock:offset pairs instead of absolute address? -- Best regards, Artem Bityutskiy (Битюцкий Артём) --

It seems like the device size is always going to have some zeros in the least significant bits. Maybe a 32-bit size plus a shift is enough? That could be a lot more efficient than a 64-bit size and avoid penalizing most users who don't need >32-bit size chips. --

I'm still reluctant to change size to a 64-bit value. There's a vague recolection of early conversations on the list that there would be little acceptance for that. And that probably has to do with the ongoing conversation about ABI changes. What I could do to eliminate the multiplication is introduce the same concept that the NAND layer uses, shift values. After all, erasesize should always be a power of 2, making that a power of 2 multiplication which can be done via shifts. By ...

Artem, This patch set is against the mainline, 2.6.27-rc3. At the time I posted the patch I was only a day or two out from pulling the latest from Linus' tree. It's now a couple of weeks out of date I think. Bruce --

From: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Sonic Zhang <sonic.zhang@analog.com> Signed-off-by: Bryan Wu <cooloney@kernel.org> --- drivers/ata/pata_bf54x.c | 29 ++++++++++++++++++++++++----- 1 files changed, 24 insertions(+), 5 deletions(-) diff --git a/drivers/ata/pata_bf54x.c b/drivers/ata/pata_bf54x.c index d393290..60f4872 100644 --- a/drivers/ata/pata_bf54x.c +++ b/drivers/ata/pata_bf54x.c @@ -1632,6 +1632,8 @@ static int __devinit bfin_atapi_probe(struct ...

applied --

On Wed, Aug 27, 2008 at 2:10 PM, Marcel Holtmann I just repeat myself again, for the current series except the scanning cleaning patches these patches are must. This particular patch is there just because the hidden AP connectivity fixes were stacked above it. There is a central problem here, since I cannot really adjust driver development progress from obvious reason with Linux merging window. Upstream kernel is unfortunately not the only customer I report to. So actually stable versions ...

What is happening that IBSS station should adopt TSF of the oldest station i.e. with highest TSF. This is also leader of the IBSS (this is not spec definition just local jargon) Adaptation mean we adjust to the same clock if (beacon_timestamp > rx_timestamp) merge beacon_timestamp (what STA advertise in the beacon ) is bigger then time reception of the beacon according our local TSF. If this is true then there is merging meaing we call reset_tsf, remove all the stations form the ...

I don't think I contaminate upstream I'm just trying to fix bugs so I'm not sure why you are so militant, you cut out form my email sentences like 'Yes' and 'Understood' Is this personal ? Tomas --

From: Johannes Berg <johannes@sipsolutions.net> Absolutely. --

I did a quick review of the offending patch queue. And some of them should go in since they are fixing real bugs (as far as I can tell from a quick review). Others have to clearly wait for the next merge window. Thomas, please go through the list of patches and pick the real bug fixes. The cleanup patches can't go in since they are after the merge window. And being one of the offenders why Dave got flamed by Linus, there is no way to get these through. And my big offender was a regression ...

I think it would be an advantage for you to develop in wireless-testing and use wireless-2.6 and probably additionally some internal trees as stable trees. Like everybody else does it. The advantage is simple: You get more people testing your code. --

Don't get excited, this was a cynical remarks rather then anything else. I understand all the aspects of this. Upstream problems are not bigger then down here, Without offense you also see your world from your selfish perspective. Tomas --

On Wed, Aug 27, 2008 at 4:30 AM, John W. Linville PCI cleanup patch is badly named. It fixes PCI registers sizes and ads one forgotten hw workaround I called it cleanup because it went through all PCI accesses we have in the driver. Scan cleanup was requested because of dependencies but it's harmless, we can rebase the patches prefer not it's just waste of time. Afther massive ath9k merge I didn't see it was a conceptual problem. Thanks Tomas --

I'm not sure what you are taking about, we did post patches to wireless-testing, the driver for 5000 HW is working in 2.6.27-rc4 I personally use it every day. I'm sending bug fixes, like this seris of patches is direct answer to bugs that were discovered very We fixed bugs in wireless-testing/mac80211 that were there for months just because we are only one that do any comprehensive validation. I don't want insult anyone and I really exaggeration here but sometimes I have feeling that more ...

I never worked that way I've published immediately what I had. I don't know where did you get this impression If I didn't publish something it's just too reasons. The code was made dirty and I didn't like design myself (for example our 11h implementation), even though it's publicly available. or just simply didn't have time because I have to satisfy first thous who pays my check ( everybody to feed their children after all:) ) (e.g. rfkill fixes) Almost every driver has it's own development ...

From: "Tomas Winkler" <tomasw@gmail.com> But think about this from the other perspective. When you queue up tons of things, especially in infrastructure level code such as mac80211, and on top of it you do your work on the stable branch and do not do you work against the development tree, guess what happens? You show up with accumulated piles of non-trivial patches for people to review. And then you'll get upset when they suggest that things be implemented differently. It's all because ...

Hi Andi, Before starting i would like to point out the 'philosophy' behind the idea. Exceptions(special cases) make for entropy and hence complexity. Generalization keeps uniformity and hences Order and Ease. We can't escape 'entropy' when emulating something that it is actually not, nevertheless we can minimize it by introducing as least and as localized changes as possible. My idea congregates only determining changes at the lowest level(driver), unlike the respectable LOOP driver which ...

The Kconfig option for HID_COMPAT should read "lose", not "loose". Signed-off-by: Alex Chiang <achiang@hp.com> --- diff --git a/drivers/hid/Kconfig b/drivers/hid/Kconfig index 4319af3..46337a2 100644 --- a/drivers/hid/Kconfig +++ b/drivers/hid/Kconfig @@ -78,7 +78,7 @@ config HID_COMPAT support of module loading through aliases and also old module-init-tools which can't handle hid bus, choose Y here. Otherwise say N. If you say N and your userspace is old enough, the ...

This may or may not be due to a Fedora patch. Motherboard: ASRock 4Core1600Twins-P35 Ifconfig: eth0 Link encap:Ethernet HWaddr 00:19:66:XX:XX:XX inet addr:192.168.XX.XX Bcast:192.168.XX.XX Mask:255.255.255.0 inet6 addr: fe80::219:66ff:fe64:1c68/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:609519 errors:0 dropped:424695074957 overruns:0 frame:0 TX packets:307400 errors:0 dropped:0 ...

On Mon, 25 Aug 2008 16:50:28 +0530 The linux-ext4 list is not an appropriate place for discussing a The problem of atomically handling 64-bit quantities on 32-bit machines is by no means unique to percpu_counters. We sorta-solved it for i_size and we continue to sorta-not-solve it for loff_t and surely there are other places which already sorta-solve it and which will be sorta-solved in the future. All of which tells us that we need a real solution, at a lower level. We already have a ...

You should have read this bit of the self-test printout: [ 0.004000] 133 out of 218 testcases failed, as expected. | there was no unexpected failure. A real test-case failure is displayed as: 'FAILED', and you'll get a verbose printout about the unexpected no, that messes up the kernel. Kconfig.debug is a separate, unique yes. It shows the kinds of bugs we dont find when PROVE_LOCKING is disabled. It also shows that the test-cases are working as expected. Ingo --

[ 0.000999] | Locking API testsuite: [ 0.000999] ---------------------------------------------------------------------------- [ 0.000999] | spin |wlock |rlock |mutex | wsem | rsem | [ 0.000999] -------------------------------------------------------------------------- [ 0.000999] A-A deadlock:failed|failed| ok |failed|failed|failed| [ 0.000999] A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| [ ...

Ah, thanks, for some reason I thought that this wasn't needed with the kref code, but you are correct. Hm, in looking at the usb driver tree, there are lots of drivers in there with that problem :) Now fixed up in this driver. thanks, greg k-h --

now fixed. thanks a lot for the review. greg k-h --

Now fixed. It's fun talking to yourself... greg k-h --

That's great. How about a basic "the driver works or not" type testing of what we have already? After that, we can work on autosuspend support. thanks, greg k-h --

Unfortunately the issues are not trivial. 1. USBTMC_SIZE_IOBUFFER use 2048. 4096 means a multipage allocation 2. usbtmc_open race with disconnect already mailed about 3. read/write and, if you convert to unlocked_ioctl, need protection against reentry 4. read, write & ioctl need protection against using a rebound interface you add a mutex, that you need for (3) anyway to the descriptor and protected by this mutex you set the interface and device pointers to null in disconnect and ...

So? What difference does this really matter at normal USB speeds? thanks, greg k-h --

Sure, it's not a real big deal, if this driver doesn't use the kmalloc-4096 slab cache, someone else will :) I'll go change it. thanks, greg k-h --

This is a race condition. CPU A CPU B open() usb_find_interface() disconnect() kref_put() usbtmc_delete() kfree() kref_get() You can write to free memory. You must use a static mutex for mutual exclusion between open() and disconnect() Regards Oliver --

Looks good to me, feel free to add an: Acked-by: Greg Kroah-Hartman <gregkh@suse.de> to it. greg k-h --

That has to be done somewhere in your board specific file, e.g. for ARM boards in arch/arm/mach-xxx/board-something.c - the same place where you Seems right. --

Applied the commit below to tip/core/urgent, thanks. Roland/Oleg, do you concur with the fix? nice find btw. - are you running Valgrind on UML? Ingo --

applied to tip/x86/cleanups, thanks! Ingo --

applied to tip/x86/uv, thanks! Ingo --

Doesn't htonl() resolve to this for a constant argument? Following through the definitions, it certainly looks like it ought to: <linux/byteorder/generic.h> #undef htonl #define ___htonl(x) __cpu_to_be32(x) <linux/byteorder/little_endian.h> #define __cpu_to_be32(x) ((__force __be32)__swab32((x))) <linux/byteorder/swab.h> # define __swab32(x) \ (__builtin_constant_p((__u32)(x)) ? \ ___constant_swab32((x)) : \ __fswab32((x))) at least for GCC with optimisation ...

Which is I think the single most biggest mistake of this whole endevour. Why not have it out on lkml where people can actually see? --

Please point out specific areas, and I'm sure there will be a reasonable explanation why they turned out this way. As for whether "struct utrace" should be a member of vs. pointed-to from task_struct, it may come down to the perceived need to avoid penalizing every thread with a hundred-odd bytes extra, whether or not Among others, utrace is an enablement layer for systemtap user-space probing, through another subsequent part that implements a kprobes-like API for user-space tasks. All ...

Another one: kernel BUG at kernel/utrace.c:2275! invalid opcode: 0000 [1] PREEMPT SMP DEBUG_PAGEALLOC last sysfs file: /sys/kernel/slab/utrace_attached_engine/objects CPU 0 Modules linked in: xt_state iptable_filter ipt_MASQUERADE iptable_nat nf_nat nf_conntrack_ipv4 nf_conntrack ip_tables xt_tcpudp ip6table_filter ip6_tables x_tables ipv6 sr_mod cdrom Pid: 5118, comm: exe Tainted: G W 2.6.27-rc4-next-20080827-utrace #5 RIP: 0010:[<ffffffff802608ef>] [<ffffffff802608ef>] ...

Yes, that's your price for avoiding more races, more code, more races, more tricky code and ultimately more ways to fsckup. God, you're in the very tricky Unix subsystem only a few people know intimately, and what we see? utrace code is just as tricky. When you're confident that interaction with engines part is fine, all stupid bugs were fixed, go change struct utrace to pointer. Now it can very well be a lie to say less memory is used because slab allocator There are no chickens and no ...

And overwritten poison if run in parallel with while true; do killall -9 expl_ptratt killall -9 exe done ============================================================================= BUG utrace: Poison overwritten ----------------------------------------------------------------------------- INFO: 0xffff88017c31e7b0-0xffff88017c31e7f0. First byte 0x6c instead of 0x6b INFO: Allocated in utrace_attach_task+0x1f4/0x3d0 age=13 cpu=1 pid=5377 INFO: Freed in utrace_free+0x16/0x20 age=5 ...

num_opens wasn't protected by driver_lock, so we made num_opens/is_open atomic_t. But an int seems too much for just a flag (as Serge pointed), and the code would be cleaner if we make only this line atomic, by using test_and_set_bit(). Thanks Alan. I'll rewrite it. Rajiv --

I wonder if you ever tested my vmap rework patches with this issue? It seems somewhat x86 specific and also not conceptually so clean to use kmap_atomic_pfn for this. vmap may not be used by all architectures but I think it might be able to cover some of them. As I said, there are some other possible improvements that can be made to my vmap rewrite if performance isn't good enough, but I simply have not seen numbers... Thanks, Nick --

On Wed, Aug 27, 2008 at 4:37 AM, Geert Uytterhoeven Acked-by: Magnus Damm <damm@igel.co.jp> --

Very good spotting, Thanks! However I think the patch isn't quite good, as highest_prio is only available on SMP || RT_GROUP_SCHED. Furthermore, on !RT_GROUP_SCHED any RT task will be higher than current, so we can do the below, do you agree? --- diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c index 94daace..f672aee 100644 --- a/kernel/sched_rt.c +++ b/kernel/sched_rt.c @@ -199,6 +199,8 @@ static inline struct rt_rq *group_rt_rq(struct sched_rt_entity *rt_se) static inline void ...

From: Al Viro <viro@ZenIV.linux.org.uk> Applied, thanks everyone. --

Ugh. My patch removes the ability to pass caps to another task under all circumstances because to do otherwise means that I have to make the kernel use RCU locking for a task to access its own creds. If you want this, I'll have to redo all my later patches. David --

We don't have the time left for developing the few missing pieces and properly integrating file capabilities into our products (use in various packages, support in rpm, system management, manuals, release notes), and so I would My main concern is accidental granting of capabilities because of admin unawareness / lack of tool support. This could be taken care of by not Well, the other difference is that with CONFIG_SECURITY_FILE_CAPABILITIES=y you currently lose the ability to pass on ...

Do you mean 'permanent' rather than 'pertinent'? David --

Is it worth calling synchronize_rcu() in commit_creds() to make sure that the old memory will have been freed if possible? Admittedly that'll slow setuid() and co. down, but it should avoid that problem. David --

On Wed, 27 Aug 2008 17:13:24 +0100 That gets foul in another way - bounding the worst case RCU memory utilisation if someone is sitting doing things like while(1) change_credentials(); --

Hi Jens, That is good news. With the proliferation of intelligent disk controllers and SSDs, the disk profiling approach seems to be the right controller-specific auto-tuning feature, not a new functionality of the generic elevator layer. Is this interpretation correct? Would it make sense in some cases to change elevators automatically depending on the characteristics of the underlying device instead (e.g. we might not need any of the extra features CFQ provides, for example)? I would ...

I see. Thank you for the explanations. Linux developers made things in the right way by removing redundant machine type verification. The bug is in U-Boot which passes the wrong mach type when compiled for the at91rm9200dk board. Many thanks for your quick answer. Claudio -- Ing. Claudio Scordino Software Engineer, PhD Tel. +39-050-5492050 http://retis.sssup.it/~scordino/ Evidence Srl Embedded Real-Time Solutions http://www.evidence.eu.com --

On Tue, 26 Aug 2008 17:51:46 +0800 Acked-by: Krzysztof Helt <krzysztof.h1@wp.pl> ---------------------------------------------------------------------- --

Hi Arjan, On Thu, 28 Aug 2008 00:33:08 +1000 Stephen Rothwell <sfr@canb.auug.org.au> = But, of course, that version didn't have the necessary extra dereference of the function address ... And the later debug patch did not check the address at register time, only at notify time. The later trace also looks to be early in the boot. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Hi Arjan, On Wed, 27 Aug 2008 06:48:06 -0700 Arjan van de Ven <arjan@linux.intel.com>= The original reported trace was during setup_system which is very early in the boot. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

This is during the bootup Welcome to yaboot version 1.3.12 Enter "help" to get some basic usage information boot: autotest Please wait, loading kernel... Elf64 kernel loaded... Loading ramdisk... ramdisk loaded at 02700000, size: 846 Kbytes OF stdout device is: /vdevice/vty@30000000 Hypertas detected, assuming LPAR ! command line: root=/dev/sda6 console=hvc0 IDENT=1219851195 memory layout at init: alloc_bottom : 00000000027d4000 alloc_top : 0000000008000000 alloc_top_hi : ...

Actually, I had a plan to write such a patch: [RFC PATCH] cgroup,cpuset: use alternative malloc instead of kmalloc The main idea is: when allocate size >= PAGE_SIZE, vmalloc will be used instead. This will reduce the stress when continuous pages are few. Alternative malloc is used for cgroup_tasks_open() and update_tasks_nodemask(). And vmalloc can malloc larger memory than kmalloc, is vmalloc() enough? If not, I think using an array of pages is the best choice. [There are several ...

I never submitted them since yours were better for x86. But I can dust them off and post -Greg

I've no idea; SMP on ARM as far as I've been involved has been silent for well over a year with very little visible interest from anyone. That's situation normal for things that "just work" though. -- Russell King Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: --

Its not that 1 is magically "ok". Its simply that newidle balancing hurts latency, and 1 is the minimum to pull to reasonably reduce the critical section. I already check if we NEEDS_RESCHED before taking the rq->lock in newidle, so waiting for one task to pull is the first opportunity I have to end the section as quickly as possible. It would be nice if I could just keep going if I could detect whether there was=20 Im not sure I follow your point, but if I do note that the RT ...

Although I guess we could prefetch it... But OTOH I don't know exactly what Intel CPUs do with prefetch -- I don't think they have a prefetchw. Right. My reasoning said that if our critical sections are short enough, *and not subject to starvation*, then we should not really need it, and at any rate often it is just luck if it helps because in other cases we might be taking the lock under an irq save region so it wouldn't help Hmm, you might have a good point there. Greg? BTW. I ...

Aah, we don't do CONFIG_GENERIC_LOCKBREAK anymore? Does it make sense to make this _double_lock_balance() thing depend on that too? --

Indeed. This does get to the heart of the problem: contention against I submitted some patches related to this a while back. The gist of it is that the presence of ticketlocks for a given config *should* defeat the preemptible version of the generic spinlocks or there is no point.=20 Let me see if I can dig it up. -Greg

Yeah, that could work, but hmm it might cause 2 cache coherency transactions anyway even in the fastpath, so it might even be slower than just unlocking Hmm, and also on x86 with ticket locks we don't spin with preempt or interrupts enabled any more (although we still do of course on other architectures) --

I think both are starting to show more and more SMP machines, so yes, eventually we'll want ticket locks for them too. That said, I'm not aware of anyone working on it - I suppose we could poke the regular arch maintainers.. Ralf, Russell ? --

Ok, I understand what you are saying now, and that makes sense. -Greg

As an aside: I have an implementation of C-based ticket lock replacements for raw_spinlock_t that I could post. I never posted them because I mostly care about x86 and Nick's solution is superior there since its hand-tuned asm. But mine could be used in places that have not yet written arch support but need FIFO. I basically have it as a config option to enable "generic fifo spinlocks" or something like that. -Greg

Not for me though -- the names should be sorted alphabetically as this is how the reader will look for the right one (assuming they do not get fed up and resort to `grep'). There is virtually no chance to notice this one among the plethora of chip variations supported. Maciej --

On Wed, 27 Aug 2008 13:22:05 -0400 Acked-by: Alessandro Zummo <a.zummo@towertech.it> -- Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it --

Add support for M41T65 Real Time Clock chip Signed-off-by: Steven A. Falco <sfalco@harris.com> --- Fair enough. Here is a sorted version. drivers/rtc/Kconfig | 14 +++++++------- drivers/rtc/rtc-m41t80.c | 43 +++++++++++++++++++++++++++++++++---------- 2 files changed, 40 insertions(+), 17 deletions(-) diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig index 4949dc4..c7586bc 100644 --- a/drivers/rtc/Kconfig +++ b/drivers/rtc/Kconfig @@ -220,22 +220,22 @@ config ...

You've had a good idea to spell out M41T65 in full -- it makes it more prominent. Thanks. Maciej --

--

Since this is a boolean parameter I don't know? What if I change the name to enable_minmax. And actually use the "bool" module parameter I probably don't need both? I kinda treat the variables tied to module Not that I have heard of. I thought it was lacking some hardware that The choice I made here was to wait for the timer to fire rather than to delete it. I think it is easier to just wait for it than to delete it and try to get things back in order. Though since this is in a module exit ...

For every user who uses an old laptop as a home server, or has a "best MIPS64 box", there are maybe five million users with a 0-3 year old x86 computer (they don't know that it's really a "box"). Let's optimize for the common case, please. -- error compiling committee.c: too many arguments to function --

I'd not count of this. When you relegate laptop to "quiet home server" role, the mechanical stresses suddenly stop, and I'd expect it to survive for long long years. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Yes I see. But the signal handler for SIGSYS can fisrt do sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any other syscall. With this patch PT_SELF is cleared on any signal. This doesn't look right. Let's suppose that another signal comes in parallel with SIGSYS. It is very possible that the handler for that another signal will be Ah, I forgot to read the changelog, sorry. Oleg. --

1. insert the lapic, ioapic, mmconf mmio address into resource tree at first... 2. later when we fail to request_resource for one BAR res of pci dev, call check_resource(.., res) to see if could find some res with the same range and the sticky flag. if so will insert BAR resource for the device forcibly. not sure. actually we should rely on BIOS to allocate ioport/mmio for us. and only do some minor adjust to BAR that is obvious wrong. so have list for gap seems overkilling. for Hotplug, ...

Do you think I should modify something or use a way to make it better? (Added Pekka Paalanen in Cc since it concerns an idea from his mmiotrace's documentation)... --

sukadev@us.ibm.com [sukadev@us.ibm.com] wrote: | I was able to repro the problem without the patchset and could not | reproduce with the patchset. But just had a quick question while | reviewing the patches. | | Oleg Nesterov [oleg@tv-sign.ru] wrote: | | We don't change pid_ns->child_reaper when the main thread of the | | subnamespace init exits. As Robert Rex <robert.rex@exasol.com> | | pointed out this is wrong. | | | | Yes, the re-parenting itself works correctly, but if the ...

Yes. BTW, your original patch (which introduced zap_pid_ns()) was correct ;) The code was broken later, during the s/->pid/vpid/ conversion. The group_dead check _is_ sufficient (and correct) for zap_pid_ns(), but we all missed the simple fact: if we continue to re-parent to some task, it must have the valid ->nsproxy->pid_ns. Thanks to Robert again. Oleg. --

Oleg Nesterov [oleg@tv-sign.ru] wrote: | We don't change pid_ns->child_reaper when the main thread of the | subnamespace init exits. As Robert Rex <robert.rex@exasol.com> | pointed out this is wrong. | | Yes, the re-parenting itself works correctly, but if the reparented | task exits it needs ->parent->nsproxy->pid_ns in do_notify_parent(), | and if the main thread is zombie its ->nsproxy was already cleared | by exit_task_namespaces(). | | Introduce the new function, find_new_reaper(), ...

Oleg Nesterov [oleg@tv-sign.ru] wrote: | zap_pid_ns_processes() sets pid_ns->child_reaper = NULL, this is wrong. | | Yes, we have already killed all tasks in this namespace, and sys_wait4() | doesn't see any child. But this doesn't mean ->children list is empty, | we may have EXIT_DEAD tasks which are not visible to do_wait(). In that | case the subsequent forget_original_parent() will crash the kernel because | it will try to re-parent these tasks to the NULL reaper. | | Even if there are no ...

Oleg Nesterov [oleg@tv-sign.ru] wrote: | de_thread() checks if the old leader was the ->child_reaper, this is not | possible any longer. With the previous patch ->group_leader itself will | change ->child_reaper on exit. | | >From now find_new_reaper() is the only function (apart from initialization) | which plays with ->child_reaper. | | Signed-off-by: Oleg Nesterov <oleg@tv-sign.ru> Acked-by: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com> --

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

--

> As far as features are concerned, please suggest me what could be done with /dev/loop0 and not for /dev/vblk? Serious question? cryptoloop, offsets are the big ticket items, i'm sure there are more. -Andi --

AFAYK it adds at least one new feature: partition tables. --

It's like saying: FAT -- isn't that obsolete by now? Wrong question. You lose. -Andi --

Hi Andi, Before starting i would like to point out the 'philosophy' behind the idea. Exceptions(special cases) make for entropy and hence complexity. Generalization keeps uniformity and hences Order and Ease. We can't escape 'entropy' when emulating something that it is actually not, nevertheless we can minimize it by introducing as least and as localized changes as possible. My idea congregates only determining changes at the lowest level(driver), unlike the respectable LOOP driver which ...

No, I am aware of that, and on i386 IRQ stacks are only used with 4kB stacks. CONFIG_DEBUG_STACKOVERFLOW should give you the same information, and if How many platforms use 4kB stacks on sh? Only 1 out of 34 defconfigs uses it. arm or powerpc aren't exactly lesser maintained architectures. 4kB has shown to be a hard to achieve limit. After more than 4 years in mainline being available on i386 there are still cases where 4kB are not enough. IMHO there seems to currently be a ...

From: Nick Piggin <nickpiggin@yahoo.com.au> It's almost certainly from the cross-call dispatch call chain. As just one example, just to do a TLB flush mm->cpu_vm_mask probably gets passed around as an aggregate two or three times on the way down to the APIC programming code on x86. That's two or three 512 byte copies on the stack :) Look at the sparc64 SMP code for how I solved the problem there. --

Anybody doing this, don't forget to actually use "inode" instead of all those dereferences: struct inode *inode = filp->f_path.dentry->d_inode; --

It is, but the idea that small embedded systems go through a 'all components are known, drivers are known, test and if it passes it's Sounds reasonable, but it's vetoed for anticipated time and cost, compared with backporting on demand. Fair enough, since 2.6.current doesn't support ARM no-MMU last I heard ('soon'?). On the other hand, the 2.6 anti-fragmentation patches, including latest SLUB stuff, ironically meant to help big machines, sound really appealing for my current problem and ...

Falling prices are no reason to increase the amount of available RAM (or other hardware). Especially if you (intend to) build >1E5 devices - where every Euro counts. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services --

Yes, you may have several products on the same hardware with somewhat differing requirements (or not). But that is much less than a general That sounds reasonable (and I never meant maintaining the old system infinitely. Actually once the thing is shipped it usually enters deep ACK. But that also depends on amount local changes (and sorry, but not Basically their problem. Yes, "they" actually think they get a Linux system where they can do everything and it simply works. Oh, that's ...

Well, I alrady reverted it, but if you actually fix unlocked_ioctl() to have the same calling convention as regular ioctl() then a lot of the noise from ioctl conversion goes away, and all that remains is literally just the BKL part. Btw, why is unlocked_ioctl returning "long"? Does anybody depend on that too? That's another difference between the "unlocked" and the traditional version.. As to the "x86 cases", I think you should try to hit them all. Doing a "git grep ...

I have some simple devices (network access/routers) with 8MB of RAM, at power up not really being configured to do anything running 25 processes. (Heck there is over 10 kernel processes running!). Configure some interfaces and services and that will easily push past 40. I'd be happy with a 160k saving :-) The init memory being freed at the end of the kernel boot is 88k, 4k stacks could save more than ...

My main point is: - getting 4kB stacks working reliably is a hard task - having an eye on gcc increasing the stack usage, and fixing it if required, is relatively easy If we should be able to do better at getting (and keeping) 4kB stacks working, then coping with possible inlining problems caused by gcc 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 ...

Out of the architectures you've mentioned for 4k stacks, they also tend to do IRQ stacks, which is something you seem to have overlooked. In addition to that, debugging the runaway stack users on 4k tends to be easier anyways since you end up blowing the stack a lot sooner. On sh we've had pretty good luck with it, though most of our users are using fairly deterministic workloads and continually profiling the footprint. Anything that runs away or uses an insane amount of stack space needs to be ...

5% is a pretty nasty performance hit... what sort of benchmarks are we talking about here? I just made some pretty crazy changes to the VM to get "only" around 5 or so % performance improvement in some workloads. What places are making heavy use of cpumasks that causes such a slowdown? Hopefully callers can mostly be improved so they don't need to use cpumasks for common cases. Until then, it would be kind of sad for a distro to ship a generic x86 kernel and lose 5% performance because ...

[Empty message]

But not many embedded Linux arches support 4K stacks like Adrian pointed out earlier. So the same (lot of man power requirement) would apply to Linux. Sure it will be good - but how reasonable it is to attempt it and how reliably it will work under all conceived loads - those are the questions. Thanks Parag --

Yup, you're right. Linus --

but was shared with interrupts; so out of the 6Kb left, you had still really only 4Kb for user context stack --

Being more careful.. This: git grep 'unlocked_ioctl.*=' | sed 's/^.*=[ ]*\([_a-zA-Z0-9]*\).*$/\1/' | uniq | wc says that ther are 160 distinct cases. I'm not sure it catches everything exactly, but it will be reasonably close, at least. I wonder if I could essentially automate something to do the conversion.. Linus --

Umm. Neither is 8k stacks. Nobody "proved" anything. But yes, some subsystems have insanely deep call chains. And yes, things like the VFS recursion (for symlinks) makes that deeper yet for filesystems, although only on the lookup path. And that is exactly the kind of thing that can exacerbate the problem of the compiler artificially making for a bigger stack footprint of a function (*). For things like the VFS layer, right now we allow a nesting level of 8, I think. If I remember ...

On Tue, 2008-08-26 at 22:16 -0400, Parag Warudkar wrote: "The industry as a whole" doesn't exist on that low level. You can't compare the laptop and/or desktop computer market (where one may buy today hardware that runs in 3 years with the next generation/release of the OS and applications) with the e.g. "WLAN router" market where - from the commercial point of view - every Euro counts (and where the requirements for the lifetime of the device are long frozen before the That doesn't help as ...

Why not just revert the offending change and try again during the next merge window, assuming someone has figured out an acceptable way to handle this mess by then? -- Peter Osterlund - petero2@telia.com http://web.telia.com/~u89404340 --

Umm. How long? 4kB used to be the _only_ choice. And no, there weren't even irq stacks. So that 4kB was not just the whole kernel call-chain, it was also all the irq nesting above it. And yes, we've gotten much worse over time, and no, I can't really suggest going back to that in general. The code bloat has certainly been accompanied by a stack bloat too. But part of it is definitely gcc. Some versions of gcc used to be absolutely _horrid_ when it came to stack usage, especially ...

From some tests the size increase seems to become bigger for smaller kernels, but I don't have any really good data. An interesting question is why most of our architectures for embedded devices only offer bigger stacks: The only architectures offering a 4kB stacks option are: - m68knommu - sh - 32bit x86 The following architectures that are used in embedded devices always use 8kB stacks (or bigger) in your tree: - arm - avr32 - blackfin - cris - frv - h8300 - m32r - ...

So you really need to run all 25 processes on that 8Mb box? (For reference even the NGW100 development board comes with 16Mb RAM). Even if you do need those all 25 processes on the 8Mb box, fixing the memory usage of those user space hogs is lot better than trying to save 160Kb in kernel stacks. Last I looked, user space wasn't particularly frugal with memory usage. Parag --

XFS may never have been usable, but the rest, sure. And you seem to be making this whole argument an excuse to SUCK, adn an excuse to let gcc crap even more on our stack space. Why? Why aren't you saying that we should be able to do better? Instead, you seem to asking us to do even worse than we do now? Linus --

> You have a good point that aiming at 4kB makes 8kB a very safe choice. Not really no - we use separate IRQ stacks in 4K but not 8K mode on x86-32. That means you've actually got no more space if you are unlucky with the timing of events. The 8K mode is merely harder to debug. If 4K stacks really are not safe then x86-32 really really needs to switch to using IRQ stacks in 8K stack mode as well. Alan --

On x86-32 with 8K stacks your IRQ paths share them so that is even harder to prove (not that you can prove any of them) and the bugs are more obscure and random. --

I put both of these resource size fixes into my linux-next branch, thanks. Jesse --

Hrm, given the harder line Linus has taken against "regression only" patches lately, it can probably wait another release cycle. After all, it's been un-documented since pre-git history anyway. ;) Thanks. /ac --

Documentation updates and new stand-alone drivers are ok at all times :) thanks, greg k-h --

Acked-by: Randy Dunlap <randy.dunlap@oracle.com> Thanks.. ~Randy --

applied --

Well, in my posting I noted that the mtd-utils were broken because of this but I didn't really have any idea as to how to fix things. I can see why it would be a big no-no to change this. Do you have any suggestions on There was a LOT of interest in this over the last few months while I was working on it, but a very suprising silence has developed since I posted I started with the MTD list and then also posted to lkml when I realized I had forgotten to CC it. Thanks. Bruce --

Artem, I see your point. Ioctls are going away after all. So we should have something like: /sys/class/mtd/mtd0/ --

On Tue, 26 Aug 2008 23:20:46 -0700 I don't know where that stupid story keeps coming from. Ioctl is alive and well and there are more not less of them. There are lots of things you *cannot* do with sysfs, including synchronization and handling many kinds of changes to objects that can appear and disappear. Ditto there are problems with getting a consistent snapshot via sysfs because you can't atomically read multiple fields. So please stop this 'ioctls are going away' stuff, its ...

If the (lack of) sysfs stuff is standing between us and a nice >4GiB mtd I for one would think that a set of 64-bit ioctls would be a reasonable halfway house. /Ricard -- Ricard Wolf Wanderlöf ricardw(at)axis.com Axis Communications AB, Lund, Sweden www.axis.com Phone +46 46 272 2016 Fax +46 46 13 61 30 --

Now there's something I hadn't thought of. Thanks, I'll look into doing it that way. --

sysfs makes adding new attributes easier, yes. But once added you cannot remove the attribute again - ever. Which means that either way you need to tread carefully and think twice before making a rash Could be useful, I don't mind you sending a patch. However, does this means that MEMGETINFO64 or some other ioctl should not be done? Should flash_erase open, read and close 8 seperate files instead of doing a single ioctl? And should our support for large devices wait for the sysfs support ...

On the other hand we'll stay with half-solutions forever if we allow them. -- Best Regards, Artem Bityutskiy (Артём Битюцкий) --

Having started this mess, I'll throw my half euros worth in :). While I agree that sysfs is the right way to go, I'm not going to be able to pull it off. Not withstanding my total lack of knowledge about sysfs, I've been very fortunate in that I've been doing all of this work on company time. Due to project constraints, that company time is coming to an end. I could eek out another week or two and get a set of 64- bit ioctls, but I will not be able to spend a couple more months ...

The plus of sysfs I see is that I can add more files to expose more information in sysfs, while I can not change MEMGETINFO ioctl. E.g., I need to expose sub-page size to user-space, and I cannot do this with I would like to make udev creating MTD devices, instead of creating them by hands. Adding MTD to LDM would anyway introduce corresponding sysfs files, right? This means we would have one more interface anyway. -- Best regards, Artem Bityutskiy (Битюцкий Артём) --

They certainly can, but should they? There may be some reason to prefer sysfs that should be self-evident - except that I'm a bit thick and seem to need it spelled out. Or maybe I've just become disillusioned with the practice of replacing crappy interfaces (ioctl here) with other crappy interfaces (sysfs here) and having to support both for all eternity. sysctl, ioctl, proc, sysfs, debugfs, netlink, ... - individually they all suck in their own peculiar way. But together they create a mess ...

When this happens then new incoming packets will be lost anyways because there will be no new packets fed back into the RX ring because their allocation will either stall or fail too. I don't think time stamps of dropped packets are very useful ;-) -Andi -- ak@linux.intel.com --

From: Andi Kleen <andi@firstfloor.org> They want the timestamps, but they want it to match when the packet arrived at their system as closely as is reasonably possible. Socket based solutions don't do that, because we can be sleeping on GFP_KERNEL memory or similar with the socket locked, and thus not be able to set the timestamp until the task wakes up and processes the backlog. --

No, moving the time stamps into the socket decreases latency for all packets that don't need time stamps. And they likely have some packets which don't need time stamps too. As a secondary effect if they use a RT kernel it might be also beneficial to do the (depending on the platform) costly time stamp in the lower priority socket context than in the high priority interrupt thread. -Andi --

Doing the expensive timestamping in a possibly delayed thread (ie some milliseconds after hardware notification) is wrong/useless. Better use plain xtime instead of getnstimeofday() in this case. We could provide a sysctl setting so that admin can chose between precise timestamps (current behavior) or fast but low resolution timestamping (xtime based) --

I and also other people had some patches to move the time stamp measuring into the socket. This way the time stamping didn't need to be enabled on all packets, only on those that actually end up at a socket that requires the time stamp. Unfortunately DaveM didn't like it because some bank wanted different semantics, see the discussion in http://thread.gmane.org/gmane.linux.network/91679 Perhaps you can find out which bank it was and send them a bill for your CPU time ;-) -Andi -- ...

From: Andi Kleen <andi@firstfloor.org> This is a much different kind of delay compared to sleeping for seconds or longer on the socket lock while a GFP_KERNEL allocation is being satisfied by swapping tons of crap out to disk. Your socket solution is not a workable scheme. --

We had this discussion earlier, please review the thread I linked to. Note that interrupts can be arbitarily delayed too (both by cli and by interrupt mitigation), even on a non RT kernel. If you want exact notification (packet arriving at your NIC's buffers) you need NIC hardware support (and more and more NICs have it[1]). If you do it in software then even the interrupt is at the end of a long queue with a pretty much arbitary delay. Doing it in socket context is just one queue ...

Those banks really want to crank down on latency - to the point they start disabling interrupt coalescing. I bet they'd toss anything out they could to shave another microsecond. rick jones --

Ah, since that part of the discussion wasn't in the quoted text I assumed you were talking about the disabling of interrupt coalescing. --

On Wed, 27 Aug 2008 22:47:50 +0200 Thomas is right. The ABI was established incrementally and does not use pure nested format. The original format was just one structure, then as additional features were added, additional attributes were added. --

Please learn to use you enter key. Thank you. For the last time, the message format *CANNOT* be changed, the ABI has to be stable. I didn't change the ABI, I _restored the ABI to the original state after it was broken by the initial nla_parse_nested_compat() implementation which contained a bug. It's actually trivial to figure this out in 5 minutes using git-whatchanged, not sure why you didn't do it. 1092cb219774a82b1f16781aec7b8d4ec727c981 [NETLINK]: attr: add nested compat attribute ...

Which might not be so good from a powertop viewpoint, since grace periods only take a few milliseconds, and powertop likes to keep CPUs sleeping for seconds. But one could designate a set of CPUs that scanned nearby counters -- carefully chosed WRT the system in question One could keep an index of already-scanned counters, which would You still have to scan all of the leaves... Though you can divide the work over a set of CPUs, again, as long as those CPUs are chosen so as to balance ...

Good point... #ifdef READER_LIKES_DOCUMENTATION_URLS_IN_COMMENTS * Documentation/RCU * http://lwn.net/Articles/262464/ (What is RCU, Fundamentally?) * http://lwn.net/Articles/263130/ (What is RCU's Usage?) * http://lwn.net/Articles/264090/ (What is RCU's API? + references) #else * Documentation/RCU #endif Of course, the C preprocessor would just remove the whole comment Documentation/RCU/whatisRCU.txt does in fact contain the three URLs listed above. And there is always ...

No. || will always return 1 or 0. You only need the !! if you want to directly return the boolean value of a potentially 64-bit pointer. - Josh Triplett --

I've been painstakingly debugging the issue with suspend to ram and ftraced. The 2.6.28 code does not have this issue, but since the mcount recording is not going to be in 27, this must be solved for the ftrace daemon version. The resume from suspend to ram would reboot because it was triple faulting. Debugging further, I found that calling the mcount function itself was not an issue, but it would fault when it incremented preempt_count. preempt_count is on the tasks info structure that ...

You can add my: Tested-by: Marcin Slusarz <marcin.slusarz@gmail.com> Thanks! Marcin --

Actually, it's not that compilers often optimize bitfields really badly. It's also that bitfields are a total f*cking disaster when it comes to endianness. As you found out. Bitfields are fine if you don't actually care about the underlying format, and want gcc to just randomly assign bits, and want things to be convenient in that situation. But _if_ you care about the underlying format, then inevitably the bitfield costs will be much higher than just using bit operations on ...

Oh, I don't disagree. It's probably a good idea. I'm just worried of the potential impact on existing code written around the current behaviour. We have 23 calls to set_irq_chained_handler in arch/powerpc, and I need to audit them all. Luckily, we mostly don't have startup() callbacks. (... some time later ...) It looks good. Of course, we'll have to test at one point, but at this stage, I think powerpc is happy with the change. Interestingly enough, I can see a case where we would ...

It's true there are out-of-tree proofs-of-concept for in-kernel c/r, but on the other hand it is nice seeing where Oren's code is going. Based on the patchsets you and he have been sending, the impression I've gotten was that Oren was fleshing out the longer-term tree, while you were working on the upstream-acceptable minimal patchset. That seems like a good model to me. (Was I wrong about either of your intents?) It does mean that much of Oren's patchset may end up having to be re-written ...

ENOSYS? Louis --=20 Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de Coesmes http://www.kerlabs.com/ 35700 Rennes

Or EOPNOTSUPP - but that's documented as a network error ("Operation not supported on transport endpoint"). J --

AFAICS, all hash implementations work like this (I'm referring to pid hashes and compat_ioctl hashes for instance). The only common code is the hash functions, which Oren seems to have used. Radix trees may be an alternative, given that object tags are sequentially generated in some way. I have no idea about the simplicity we can gain thou= gh. Louis --=20 Dr Louis Rilling Kerlabs Skype: louis.rilling Batiment Germanium Phone: (+33|0) 6 80 89 08 23 80 avenue des Buttes de ...

Brain not functioning, yet. Thanks. -- Dave --

I disagree. It's more than "allocate memory", it's: "give me some room on the buffer". When we don't care about downtime (like now), it's enough to kmalloc a temporary buffer and flush (write to the FD) immediately. But when we will care about downtime, "the buffer" will be memory in kernel where the entire checkpoint image data will be kept while the container is frozen (memory contents need only be marked copy-on-write, not explicitly buffered). In this setting, cr_kwrite() will not ...

Is this still a problem? Is this related to other Bluetooth suspend/resume regressions in 2.6.27? Alan Stern --

It should get into 2.6.27, and probably 26.stable ... assuming that it checks out properly. A somewhat cruftier version resolved Stefan's problem, but I'd rather not merge that one. Hmm, I'll ask Stefan to confirm this version. - Dave --

That patch was only intended to address the issue of bogus error If it's like the other case, I'd hope this patch would solve it. Note that you also seem to be having hardware or firmware issues with the peripheral you're connecting ... this won't change that stuff at all. - Dave ================ SNIP! From: David Brownell <dbrownell@users.sourceforge.net> As noted by Stefan Neis <Stefan.Neis@kobil.com>, we had a recent regression with EHCI periodic transfers, in some (seemingly ...

With this got the oops again when compiling in guest. Reboot afterwards With second patch i get the early oops after "freeing smp". Seems no way to get the guest bootet normaly (ony with replace-paravirt). So the changes from the other mail took more effect IMHO. Gerhard --

The idea is to add this to printk after the severity: printk(KERN_ERR FW_BUG "This is not our fault\n"); If a Firmware issue should be hidden, because it is work-arounded, but you still want to see something popping up e.g. for info only: printk(KERN_INFO FW_INFO "This is done stupid, we can handle it, but it should better be avoided in future\n"); or on the Linuxfirmwarekit to tell vendors that they did something stupid or wrong without bothering the user: printk(KERN_INFO FW_BUG "This is ...

... Ehh, this is not against ACPI test but latest Linus .27-rcX tree. I hope/think it should still patch in both. While this is fairly simple code, be aware that it's only compile tested. Thomas --

Even simplier, using FW_BUG define. I agree that the first implementation was over-designed, I somehow liked the printk_fw_err() and printk_fw_info() more, looked somehow more consistent with: #define pr_info(fmt, arg...) \ printk(KERN_INFO fmt, ##arg) (and others). Hmm, it shouldn't really matter. I wonder whether it works out that messages are hidden to the ordinary user with printk(KERN_INFO FW_BUG...). Something that vendors get an idea that they should not do this, but hiding ...

The periodic mode uses a reload value which is calculated during system startup and never touched again. At this point we do not have the full timekeeping infrastructure working and your test code uses the working infrastructure as reference. In high resolution timer mode we reprogramm the local apic timer for the next hrtimer instance which is enqueued. We calculate the delta against the system time and then convert it to the local apic counter value. But yes, it's surprising that the ...

Yep. It is not a bad tradeoff. You pay with some extra seeks when the filesystem is freshly mounted but gain a lot of simplicity in garbage collection. More questions. I believe the first two answer are no, but would like to be sure. Do you support compression? Do you do wear leveling or scrubbing? How does garbage collection work? In particular, when the filesystem runs out of free space, do you depend on the userspace daemon to make some policy decisions or can the kernel make ...

does this list change if you consider the fact that there may be a raid array or some more complex structure for the block device instead of a simple single disk partition? since I am suggesting re-thinking the filesystem <-> elevator interface, is there anything you need to have the elevator tell the filesystem? (I'm thinking that this may be the path for the filesystem to learn things about the block device that's under it, is it a raid array, a solid-state drive, etc) --

Probably but it'll be really ugly. You need to stick your nose into the innards of struct tty_struct and check the space left in the current flip buffer entry. What you do if it is full is another question. Alan. --

Hi, We have a problem with the hso driver serial ports. The problem is a little complex but I hope I can explain it adequetely. If you are unfamiliar with USB URBS are basically buffers we give to usb hardware to recieve or transmit packets to a USB device. The problem manifests itself when our hardware guys at option have a userland diagnostics program going & on a system under heavy load, the tty layers buffers belonging to our emulated serial port fill up because the userland program gets ...

Hi all, In kernels prior to 2.6.16 it appears to me have no mechanism for finding out if the tty recieve buffers are full. This is important for me in implementing flow control in the hso serial driver I'm developing I don't want to lose characters. The snippet from allesandro rubini's book doesn't will just blindly flip buffers & overrun if data is pushed in too quickly into the tty layer. for (i = 0; i < data_size; ++i) { if (tty->flip.count >= ...

Right. But also it assumes desktop/general purpose server thing. There may not even be any user interface to be unresponsive. Or it may be something implemented with a userspace driven scheduling system. Or an event loop in a single process. --

12k's not to shabby. I put this in linux-next, thanks Thomas. Jesse --

applied --

On Fri, 22 Aug 2008 10:40:30 +0200 I have nothing else in my queue, so Andrew, as I suspect you have other things going to Linus, if you could please include this one as well. :) Acked-by: Pierre Ossman <drzeus@drzeus.cx> Rgds -- -- Pierre Ossman Linux kernel, MMC maintainer http://www.kernel.org rdesktop, core developer http://www.rdesktop.org WARNING: This correspondence is being monitored by the Swedish government. Make sure your server uses ...

Applied to linux-next, thanks Rafael. Jesse --

Applied to linux-next, thanks. Jesse --

On Wed, 27 Aug 2008 08:39:15 +0200 really it isn't; dereference_function_descriptor is a fall through and huh? the consensus was that the config needed to go ... nothing changed on that front. I agree absolutely with not introducing config options please do not add new unlikely()'s to the kernel.. not on non-hotpaths at least --

Set the heartbeat trigger to the led you care about. Should be doable You still did not cc LED developers. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

It's just a side effect of having far too much BIOS code in the kernel. These basic MTRRs should be set up by the BIOS and when the kernel starts to think it knows better it ultimatively ends up being far more platform dependent than it should be. -Andi --

Yes, it's dab36ad8d50dc9424dfc4926f62aaf9bd52dcf13. Sven --

Perhaps it would be more useful to suggest to vendors/ BIOS writers what they should use here instead? -Carlos -- E-Mail: carlos@strangeworlds.co.uk Web: strangeworlds.co.uk GPG Key ID: 0x23EE722D --

Any progress? Alan Stern --

Ok, thanks. I look forward to playing around with it when you publish Yes that sounds correct, thanks for the refresher. -serge --

I know we discussed before about whether a propagated mount from a non-user mount to a user mount should end up being owned by the user or not. I don't recall (and am not checking the code at the moment as your tree is sitting elsewhere) whether we mark the propagated tree with the right nosuid and nodev flags, or whether we call it a user mount or not. -serge --