Hello, Is there any way to setup IRQ masks from within a driver? myri10ge currently relies on an external script (writing in /proc/irq/*/smp_affinity) to bind each queue/MSI-X to a different processor. By default, Linux will either: * round-robin the interrupts (killing the benefit of DCA for instance) * put all IRQs on the same CPU (killing much of the benefit of multislices) With more and more drivers using multiqueues, I think we need a nice way to bind MSI-X from within the drivers. I am ...

Thanks Greg/Alan, As for maintaining 2 and a half year old distros that's my job. I think I figured out a way of doing the flow control. I need to wrap the line discipline function pointer disc->ops->receive_buf(tty, char_buf,flag_buf, count); in /drivers/char/tty_io.c for my hso driver anyway I can put in a counter in this wrapper decrementing the buffers full & increment the counter each time I call tty_flip_buffer_push(tty); which I will only do if there are less than 2 buffers busy. If ...

I do need some help to understand what's going on in the VM of the Linux kernel... I wrote a little script which generates a C app with millions of lines of dumb linear running code and a endless loop at the end. I run this app on both PC Linux (swapping enabled) and embedded Linux (Kernel 2.6.24.7, ARM9, swapping disabled). The app shall consume a lot of code pages which are used only once (to run the linear code in it) and then stay in the endless loop and never touch all the other pages in ...

The behavior of linux (in both 2.4.x and 2.6.x) is when the processor sleeps, timeouts on select don't take into account the sleep time, only the run time. For example, this program should pause for 10 minutes -- however if we go into S3 in the middle its pausing for (10 minutes + time in S3) I saw this on both 2.6.20 and 2.6.22... marty -----Original Message----- From: linux-pm-bounces@lists.linux-foundation.org [mailto:linux-pm-bounces@lists.linux-foundation.org] On Behalf Of ...

Then people can no longer assume stuff like queue_work_on() etc.. works. Users of such code might depend on it actually running on the specified cpu. --

Yes. But say you were doing rate monotonic scheduling (as is not uncommonly done on top of SCHED_FIFO) then you could not get 100% cpu utilisation anyway, as RMS has a ~69% utility bound. --

No its not per task. Its per group (and trivially the !group case is one group). All this bandwidth code comes from RT group scheduling. We do that by assigning a bandwidth to each group so that within that bandwidth each group can use RT tasks and have them behave like they should. I don't fully agree with the statement that the most important thing for SCHED_FIFO is to run as long as you want. The most important thing SCHED_FIFO brings us are deterministic scheduling rules. And RT ...

Hi, OK so that's (outside spinlock): BUG_ON(r->entropy_count > r->poolinfo->POOLBITS); in credit_entropy_bits we do (inside spinlock): r->entropy_count += nbits; if (r->entropy_count < 0) { DEBUG_ENT("negative entropy/overflow\n"); r->entropy_count = 0; } else if (r->entropy_count > r->poolinfo->POOLBITS) r->entropy_count = r->poolinfo->POOLBITS; I wonder if we got unlucky and did the: r->entropy_count += nbits - overflowed the entropy_count THEN - another ...

We don't need whole 32 of them, only NR_SOFTIRQS. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- include/linux/interrupt.h | 2 ++ kernel/softirq.c | 2 +- 2 files changed, 3 insertions(+), 1 deletion(-) --- a/include/linux/interrupt.h +++ b/include/linux/interrupt.h @@ -252,6 +252,8 @@ enum HRTIMER_SOFTIRQ, #endif RCU_SOFTIRQ, /* Preferable RCU should always be the last softirq */ + + NR_SOFTIRQS }; /* softirq mask and active fields moved to ...

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- fs/super.c | 7 +------ include/linux/fs.h | 1 - init/main.c | 1 - 3 files changed, 1 insertion(+), 8 deletions(-) --- a/fs/super.c +++ b/fs/super.c @@ -682,7 +682,7 @@ void emergency_remount(void) * filesystems which don't use real block-devices. -- jrs */ -static struct idr unnamed_dev_idr; +static DEFINE_IDR(unnamed_dev_idr); static DEFINE_SPINLOCK(unnamed_dev_lock);/* protects the above */ ...

name and nlen parameters passed to ->strategy hook are unused, remove them. In general ->strategy hook should know what it's doing, and don't do something tricky for which, say, pointer to original userspace array may be needed (name). Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- arch/frv/kernel/pm.c | 6 +++--- arch/mips/lasat/sysctl.c | 17 ++++++++--------- drivers/char/random.c | 2 +- include/linux/sysctl.h | 2 +- ...

Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- fs/super.c | 10 +++++----- 1 file changed, 5 insertions(+), 5 deletions(-) --- a/fs/super.c +++ b/fs/super.c @@ -682,7 +682,7 @@ void emergency_remount(void) * filesystems which don't use real block-devices. -- jrs */ -static DEFINE_IDR(unnamed_dev_idr); +static DEFINE_IDA(unnamed_dev_ida); static DEFINE_SPINLOCK(unnamed_dev_lock);/* protects the above */ int set_anon_super(struct super_block *s, void *data) @@ ...

Yes, looks good. Thanks, Andreas --

Well. Experience and guesswork, mainly. But a useful metric is to look and the /bin/size output before and after the inlining. In this case fs/ext3/ialloc.o's text shrunk 40-odd bytes, which we think is a net benefit due to reduced CPU cache pressure. --

Yep. The frequency of modification of fbc->count is of the order of a tenth or a hundredth of the frequency of precpu_counter_<modification>() calls. But in many cases the frequency of percpu_counter_read() calls is far far less than this. For example, the percpu_counter_read() may only happen when userspace polls a /proc file. --

Cant sleep inside rcu_read_lock(), with CONFIG_PREEMPT_RCU=n, at least. Dunno if it's legal if CONFIG_PREEMPT_RCU=y. Hopefully not - that would be insane. But I've failed to keep up with rcu goings-on recently. --

On Tue, 26 Aug 2008 13:53:41 -0500 The credentials code in linux-next is changing the same code which you're changing, in more-than-trivially-textual ways. I'd suggest a dhowells cc on these changes, as he's also working in this area, and as you touch the keyring code a bit. And, of course, please remove that almost-always-wrong extern-declaration-in-C which checkpatch told you about. init_groups is already declared in include/linux/init_task.h anyway... --

On Thu, 28 Aug 2008 09:24:42 -0700 (PDT) Good point :) The Kconfig system doesn't presently know the name of the module, but that could be added. eg: config BMAC tristate "BMAC (G3 ethernet) support" depends on PPC_PMAC && PPC32 + modulename bmac select CRC32 help Say Y for support of BMAC Ethernet interfaces. These are used on G3 computers. - To compile this driver as a module, choose M here: the module - will be called bmac. Any sane organisation would look ...

On Thu, 28 Aug 2008 10:19:44 +0100 I suspect you to - or every "nth" event - building up a small queue as would occur in normal usage probably isn't a problem. --

That bit of the problem is trivial. Its the rest of the behavioural differences that are more of a nightmare - parity, flow control differences, modem line emulation, being able to hook into things like ldisc change/termios change. Break is about a half hour job. Alan --

No-overcommit is address space accounting alone. It doesn't change actual allocation or management of memory, it simply ensures that there should always be enough space to ensure it can sort itself out without having to OOM something. It's a bit like bank loans - providing I know how much money is available I don't have to do much except for ensure the total loaned is covered. In the overcommit mode we instead run like the US banking system and pray we don't hit a messy OOM (out of money) ...

The load balancer will not notice that a particular CPU is busy I had such a situation at least once in the past (not due run away RT but due a kernel bug) and even with 2 out of 4 CPUs blocked the system was still quite usable. top/kill definitely worked. The system didn't have a desktop, but I didn't notice many problems in shell use. Ok it's just one sample. That said I don't think having such a limit by default is a bad idea actually. Just handling it in the scheduler anyways is ...

The skb timestamp overhead does not add up, it's either on or off. If multiple pings make the router slower it must be something else. -Andi -- ak@linux.intel.com --

Hi Karsten, For some reason i looked at the mISDN timerdev code and noticed some minor issues (which I fixed) and a major one (which I only commented). The major one is a SMP timer race. I think it needs reference counting on the timer object to fix properly. -Andi -- Misc mISDN timerdev fixes - Remove noop VFS stubs. The VFS does that on a NULL pointer anyways. - Fix timer handler prototype to be correct - Comment ugly SMP race I didn't fix. Signed-off-by: Andi Kleen ...

But didn't you really want a "end2end" time stamp in this case, as in really at the end of all kernel/hardware queues on your side. A packet roughly travels this way on a normal NIC before it hits recvmsg() wire -> NIC on die buffers -> NIC RX ring -> interrupt handler -> NAPI or per CPU queue -> softirq socket lookup -> socket queue -> recvmsg These all do their own queuing and all queues can add delays depending on the load. Right now SO_TIMESTAMP is in the interrupt handler, but it's ...

Hi, dito. This also happened to me a couple (4?) months ago, likely on 2.6.24 or 2.6.25. And for me it had the "very nice" effect of not obeying DHCP lease time, with a red-faced IT guy appearing in my door the next morning thusly... ;) From examining it more closely, it was rather obvious that select timeout happened maybe 10 hours later than it should have (with 12h lease time), due to hitting nightly S2R about two hours into the lease time. Annoying, to say the least. I think I then ...

we may actually be doing percpu_counter_add. But that doesn't update fbc->count. Only if the local percpu values cross FBC_BATCH we update fbc->count. If we are modifying fbc->count more frequently than reading fbc->count then i guess we would be contenting of fbc->lock more. -aneesh --

So here I am. Not directly resume hang but may be related. git kernel from ~2 days ago. resume succeeded but dmesg indicated tons of: [51055.352019] Freezing of tasks failed after 20.00 seconds (1 tasks refusing to freeze): [51055.352025] task PC stack pid father [51055.352031] init D 97af68e4 0 1 0 [51055.352038] f7851e9c 00000086 f7848000 97af68e4 00002e6a c8559005 f7851e80 f7848274 [51055.352050] 97c8187b 00002e6a f7851e8c ...

Well, actually it was exactly what I was concerned about ;-) The way I understand the code, it is layered into the hardware specific part and the protocol specific part, which are connected through the interfaces I pointed out. The standard requires that there can only be one protocol handler per physical interface, which is a reasonable limitation. However, what the Linux implementation actually enforces is that there can only be one hardware specific driver built or loaded into the ...

Yes, that's how global and static variables are defined in C. I'm still not convinced that it's actually correct if you call complete() from the other places as well. You have three locations in your code where you call complete() but only one for INIT_COMPLETION. The part that I don't understand (and therefore don't expect other readers to understand) is how the driver guarantees that only one complete() will be called on the completion variable after it has been initialized. What I meant ...

Hi, sched: call resched_task() conditionally from new task wake up path. - During wake up of a new task, task_new_fair() can do a resched_task() on the current task. Later in the code path, check_preempt_curr() also ends up doing the same, which can be avoided. Check if TIF_NEED_RESCHED is already set for the current task. - task_new_fair() does a resched_task() on the current task unconditionally. This can be done only in case when child runs before the parent. Signed-off-by: ...

Sorry for answering late, but here are some comments. Am Samstag, 16. August 2008 schrieb Jeremy Fitzhardinge: Yes, we have seen some real contention if the number of vcpus is much higher Hmm, I currently try to build something with sigp_stop and sigp_start on s390, not sure yet if this interface allows me to do that. At the moment something is wrong in my prototype. --

Sorry, that could've been clearer - I meant wm8731. Obviously if you want to update that too then that would be great but I figured it'd make life easier for you if I were to ensure that one gets merged OK. Which way do you prefer? --

It's in ALSA git, queued for the 2.6.28 merge window. See the topic/asoc branch of: git://git.kernel.org/pub/scm/linux/kernel/git/tiwai/sound-2.6.git for the current ASoC merge queue. The other API changes will all be queued there too. There's quite a bit of churn in ASoC at the minute but additional API changes will be taken care of by whoever does them once your driver is merged so it should save you some work if you're able to get this in OK. Jean might be willing to do ...

no, unfortuately i have no idea. also i should admit that we have problems with atheros hardware in that we don't know when the RX timestamp is taken exactly. this means our IBSS merge can't be 100% exact. but the usual case we need to catch is when the beacon TSF is much higher than the local TSF. true, we need to find a way to support this hardware too... bruno --

This sounds as if this might cause bugs to disappear when debugging gets turned on? Or do I miss anything? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed --

Sorry for being destructive, but 6 years after ALSA went into the kernel we are slightly approaching the point where all applications support ALSA. The application you list on your webpage is UML host sound support, and I'm wondering why you don't fix that instead of working on a cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. ...

Is this option in alsa git tree or in the mainline? I fail to find it in upstream mainline. Yes, I will fix this issue by running checkpatch.pl. And for other API conflicts and I2C interface upgrading stuffs, I will leave them to Cliff. Thanks -Bryan --

Oh, do you mean SSM2602 or WM8731? I also noticed the i2c API updates patch from Jean and I'd like to use the new one Thanks -Bryan --

Nope... the contrary :) Kernel timestamping has nanosec resolution. SO_TIMESTAMP needs a divide (by 1000), while SO_TIMESTAMPNS is native. --

A lot of people I have an immense amount of respect for with vastly differing opinions. There was mention of a user poll so I'll share my .000000002 USD here. I have accepted in my dealings with real-time that it is a special programming paradigm. The developer has much greater control and must exercise it responsibly. From this, I have accepted that I can bring my system to it's knees rather easily if I'm not careful. I agree with Nick and Max that this default behavior should be ...

From: Denys Fedoryshchenko <denys@visp.net.lb> Make a clone of Linus's tree, then pull in the net-2.6 tree. This is always how you should test things especially if you want to make sure you have whatever non-networking bug fixes your machine might require. --

From: Stephen Rothwell <sfr@canb.auug.org.au> I'll try to come up with a fix for this, thanks. --

From: Rick Jones <rick.jones2@hp.com> The SEC isn't mandating anything here, stop framing it that way :-) People simply won't trade with a firm if they find out that trades there are executed out of order. They are simply trying to make things as fair as possible. --

From: Thomas Graf <tgraf@suug.ch> I love patches, send me one :) --

From: Jason Uhlenkott <juhlenko@akamai.com> When expectations equal reality, and then we change reality, that's called breaking things. What might (and I do mean "might") save us is how other systems implement this. A quick check of BSD shows that at least OpenBSD fetches the timestamp inside of the RAW and UDP usrreq handler, which is basically socket receive. Our man pages simply say "reception" as when the timestamp is from, which may also give us some more leeway. From: Jason ...

From: Denys Fedoryshchenko <denys@visp.net.lb> The performance hit hurts, but changing the default to lower resolution after it having been high resolution for 10+ years is a regression and something we really can't do. --

From: Stephen Rothwell <sfr@canb.auug.org.au> I think __builtin_constant_p() is not seeing something it should here. It isn't accepting: -------------------- static inline __attribute__((const)) bool is_power_of_2(unsigned long n) { return (n != 0 && ((n & (n - 1)) == 0)); } -------------------- and thus is_power_of_2(256) as being a constant. If a 'const' inline function being passed a const argument isn't constant, what is! :-) I bet the problem is the fact that ...

From : Rafael J. Wysocki <rjw@sisk.pl> Update rtc-cmos shutdown handling to leave RTC alarms active, resolving http://bugzilla.kernel.org/show_bug.cgi?id=11411 on several boards. There are still some systems where the ACPI event handling doesn't cooperate. (Possibly related to bugid 11312, reporting the spontaneous disabling of RTC events.) Bug 11411 reported that changes to work around some ACPI event issues broke wake-from-S5 handling, as used for DVR applications. (They like to power ...

No. The whole point of immediate dispatch is that those I/Os are extremely latency sensitive (i.e. whole fs can stall waiting or them), so it doesn't matter what the end target is. The faster the storage subsystem, the more important it is to dispatch those Not so much the elevator, but the block layer in general. That is: - capability reporting - barriers and type - discard support - integrity support - maximum number of I/Os that can be in flight before congestion ...

Esteemed kernel hackers, To follow is my third pass at MIPS watch register support. This version has been tested on: * MIPS 4KEc (mips32) with a single set of watch registers watchhi not reporting I, R, and W conditions. * MIPS 4KEc (mips32r2) with four sets of watch registers. * R5000 SGI O2 (mips4 64bit) with no watch register support. The patches are against 2.6.27-rc4 Changes from the previous version: * Agreement from gdb maintainers that the ptrace interface is ...

Probe for watch register characteristics, and report them in /proc/cpuinfo. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/cpu-probe.c | 2 ++ arch/mips/kernel/proc.c | 10 ++++++++-- 2 files changed, 10 insertions(+), 2 deletions(-) diff --git a/arch/mips/kernel/cpu-probe.c b/arch/mips/kernel/cpu-probe.c index 335a6ae..d0d07b8 100644 --- a/arch/mips/kernel/cpu-probe.c +++ b/arch/mips/kernel/cpu-probe.c @@ -21,6 +21,7 @@ #include <asm/fpu.h> #include ...

Here we hook up the watch exception handler so that it sends SIGTRAP when the hardware watch registers are triggered. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/genex.S | 4 ++++ arch/mips/kernel/traps.c | 14 +++++++++----- 2 files changed, 13 insertions(+), 5 deletions(-) diff --git a/arch/mips/kernel/genex.S b/arch/mips/kernel/genex.S index c6ada98..15a9bde 100644 --- a/arch/mips/kernel/genex.S +++ b/arch/mips/kernel/genex.S @@ -416,7 +416,11 @@ ...

This is the final part of the watch register patch. Here we hook up ptrace so that the user space debugger (gdb), can set and read the registers. Signed-off-by: David Daney <ddaney@avtrex.com> --- arch/mips/kernel/ptrace.c | 97 ++++++++++++++++++++++++++++++++++++++++++- arch/mips/kernel/ptrace32.c | 15 +++++++ include/asm-mips/ptrace.h | 31 ++++++++++++++ 3 files changed, 142 insertions(+), 1 deletions(-) diff --git a/arch/mips/kernel/ptrace.c ...

git net-2.6 based on 2.6.27-rc3. Means very fresh. --

My small IMHO regarding SO_TIMESTAMP. 1)Right now i have 400-500 Mbps passing router. If i will run 5 "pings" ,simultaneous ,under _USER_ privileges(i know ping is suid), instead of free 20% CPU time, i will have 1-2% free CPU time. Sure i know ping is suid program, but it is has been "like this" since long time. By security psychos it will be caled DoS. 2)Usefullness of this option. What is a difference if on almost idle machine timestamp retrieved on higher level or lower level? And ...

Agree. Then maybe to add way to choose, because choice is high resolution vs performance. For example Intel dynamically throttling interrupts on e1000*, and it saves me in this case. They leave also option for users who wants low latency/high troughput. So maybe there must be a way for specific functions who uses get(ns)timeofday to use specific timers (cheap and less precise), by option. Or to limit amount of calls to timer by them. --

I have a 12 drive system running 2.6.18.8 with a 11 drive md array. This array is setup with raid10 and a combination of ext3 and ext2 filesystems. The issue I am having is this. I transfer a 180MB file with scp to the ext3 filesystem. When this is complete, I will then do a sync to make sure it is written to disk. The problem is that it will take 6 MINUTES for the sync to complete. If I do the same thing to the ext2 filesystem, it will take about 6 seconds. I know that 2.6.19 kernel solves my ...

The TEXT_TEXT macro defined in <asm-generic/vmlinux.lds.h> should get this right... but we don't use it. Is there any particular reason for that, or should we.... Signed-off-by: David Woodhouse <David.Woodhouse@intel.com> --- linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S~ 2008-07-13 22:51:29.000000000 +0100 +++ linux-2.6.26.ppc64/arch/powerpc/kernel/vmlinux.lds.S 2008-08-28 15:39:14.000000000 +0100 @@ -35,10 +35,11 @@ SECTIONS ALIGN_FUNCTION(); *(.text.head) _text = ...

That and unless we get a lot of synergy from authors of debuggers and debugging code it is a more general and slower interface for Can we please describe this as the giant syscall approach. Instead of a complete in-kernel solution. There are things like filesystems that should be checkpointed separately, or not checkpointed at all. However there is a large set of processes and process state that always goes together and if you checkpoint a container you always want. So building ...

Reviewed-by: Eric Van Hensbergen <ericvh@gmail.com> --

Ok I will send a new patch on the next days... --

But given you have hardware you can't change would you choose to not run Linux, even with the limitations of non-MMU? Hell no :-) Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com Secure Computing Corporation PHONE: +61 7 3435 2888 825 Stanley St, FAX: +61 7 3891 3630 Woolloongabba, QLD, 4102, Australia WEB: ...

Yep, definitely true for m68knommu in my experience. I haven't had any problems with 4k stacks recently. But yes the workloads do tend to be constrained - and almost never use any of the more exotic Indeed :-) Regards Greg ------------------------------------------------------------------------ Greg Ungerer -- Chief Software Dude EMAIL: gerg@snapgear.com Secure Computing Corporation PHONE: +61 7 3435 2888 825 Stanley St, ...

Why do we need ioctls? For CUSE? In that case, would we need to copy the memory from userspace, into the kernel, and then back out into userspace again? Can't we just have a "pass-through" type fixed ioctl instead? thanks, greg k-h --

Heh, nice, sounds interesting. I'll queue this patch up. thanks, greg k-h --

"traditionally" container_of() is used in #define, not a function call as it is just pointer math that can be done at compile time. thanks, greg k-h --

Independant of that, I can see a number of uses for the CUSE code. One would be emulating /dev/pilot for old palm pilot software that things it wants to talk to a serial port, yet really a libusb userspace program can handle all of the data to the USB device instead. So don't think that just because this userspace-OSS implementation is "not what should be done" that CUSE shouldn't be viable. thanks, greg k-h --

Yes, the old driver had a "control and debug " channel at minor 0, which Hm, that's not good, something's wrong here. Can you enable CONFIG_USB_DEBUG and rebuild the driver and send me the Yeah, I would expect that to work as well. The debug information might Good, how about the capability information? That should be in sysfs as well, does that show the proper values? thanks, greg k-h --

Ok, thanks for letting us know, if they are self-powered, this shouldn't be much of an issue. Let's focus on getting the current driver working again :) thanks, greg k-h --

Yes, but as you "normally" tie the cdev to the module itself, that handles the lifetime rules. Now I really dont' like the current cdev interface, it's a bit too complex as it needed to support the old-style interfaces without any build time changes, but I think your change isn't needed as somehow all the current drivers that support dynamic devices don't need it. Actually, the kobject in cdev shouldn't be an kobject, it's not used for registering with sysfs at all, it should just be a ...

Here's 3 patches that adds USB-IP functionality code to the kernel tree. It is against 2.6.27-rc4, and has been added to the -staging tree. If there are no major objections, I'll also queue it up in the usb tree for submission into 2.6.28. The code is based on Takahiro's great work that has been sitting outside of the kernel for many many years now. Brian Merrell took the most recent version of the code, cleaned it up and sent it to me. I did more cleanup and split the patch into 3 pieces, ...

From: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> This adds the USB IP client driver Brian Merrell cleaned up a lot of this code and submitted it for inclusion. Greg also did a lot of cleanup. Signed-off-by: Brian G. Merrell <bgmerrell@novell.com> Cc: Takahiro Hirofuchi <hirofuchi@users.sourceforge.net> Signed-off-by: Greg Kroah-Hartman <gregkh@suse.de> --- drivers/usb/ip/Kconfig | 10 drivers/usb/ip/Makefile | 3 drivers/usb/ip/vhci.h | 142 ++++ ...

That's an issue with the way the motherboard IRQ lines are wired. There's nothing the kernel can do about it. Normally I wouldn't expect that to make a big difference though.. You'd really have to try a newer kernel first in order to get much help, though. That's a pretty ancient kernel. Quite likely the situation is --

Umm, the gfp bit sounds like a clear 2.6.27 candidate. --

Actually both interfaces are a fscking disaster. The right things to pass is neither and inode nor a file but a struct block_device. Al had all this work done a while and it just needs rebasing to a current tree: http://git.kernel.org/?p=linux/kernel/git/viro/bdev.git;a=summary --

Acked-by: Henrique de Moraes Holschuh <hmh@hmh.eng.br> I have queued it and since it is an one-liner with zero chance of causing problems, I will ask Andi to merge it for 2.6.27. If he doesn't agree, it will be merged for 2.6.28. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh --

I think that's probably another bad example... I would think serial port emulation would be better handled by ptys, and/or a specific serial port emulation module. The big problem with using ptys for serial port emulation is that they currently don't handle BREAK at all. -hpa --

Be careful -- there are some serious dragons there in the presence of multiple threads. -hpa --

Why? Because there is a lot of complexity in the tty layer, and there is no point in replicating the entire tty layer with all its ioctls through a fragile user-space emulator. For cases like this, a pty is easier (your daemon opens /dev/ptmx, and then symlinks the appropriate Indeed. It would be nice to fix, because it would make implementing serial ports as ptys+userspace a much more capable replacement. It's not trivial, though, because the interpretation of the BREAK has to be ...

My thinking is that if we run into a region which is reserved in e820 but points to a real BAR, we would want to keep that BAR pinned, since a legitimate BIOS might use this mechanism to indicate that the device implemented by that BAR is used by SMM or ACPI. If not, in most cases we will only have wasted some address space. The sucky case, of course, would be an uninitialized BAR pointing into unusable address space which happens to be reserved in e820. This seems very difficult to ...

Hi all, I have just committed to tip:x86/cpu the following patch series: H. Peter Anvin (3): x86: generate names for /proc/cpuinfo from <asm/cpufeature.h> x86: cpufeature: add Intel features from CPUID and AVX specs x86: <asm/cpufeature.h>: clean up overlong lines, whitespace The combined patch is below. This changes the CPU feature naming code so that all that information comes from <asm-x86/cpufeature.h>. In the past we have had a number of problems with ...

Issuing the following: git pull git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git result in the following output: remote: Counting objects: 354, done. remote: Compressing objects: 100% (220/220), done. remote: Total 354 (delta 173), reused 278 (delta 134) Receiving objects: 100% (354/354), 603.00 KiB | 10 KiB/s, done. Resolving deltas: 100% (173/173), done. * non-commit: keep a72c497614f3fec7453b826b33ab0303c3c087fc ...

You could always pull net-2.6 to Linus' tree by yourself. ...And about the workflow, net-2.6 isn't rebased, instead Linus just pulls it in to his tree. -- i. --

REF: http://article.gmane.org/gmane.linux.kernel/725293 (thread start) I regret to report that: - Upgraded to kernel 2.6.26-1-amd64 (Debian/unstable 2.6.26-3) $ grep -Ei 'iommu|agp' /boot/config-2.6.26-1-amd64 CONFIG_GART_IOMMU=y CONFIG_CALGARY_IOMMU=y CONFIG_CALGARY_IOMMU_ENABLED_BY_DEFAULT=y CONFIG_IOMMU_HELPER=y CONFIG_AGP=y CONFIG_AGP_AMD64=y CONFIG_AGP_INTEL=m CONFIG_AGP_SIS=m CONFIG_AGP_VIA=m # CONFIG_IOMMU_DEBUG is not set - Rebooted without 'iommu' parameter. dmesg: [ ...

Yeah, this has me confused now too. I remember specifically asking if the other PCHs needed to be added to this list when the last patch was applied. What happened? Can you give us some more background here, Seth? The changelog should definitely include an explanation of why the IDs need to be changed (i.e. why the old commit was wrong). Thanks, -- Jesse Barnes, Intel Open Source Technology Center --

I would agree, except the bug is introduced by a patch in the 2.6.28 series :-) -- Jens Axboe --

Doh right, we of course can't block inside a RCU section. Then bitmap.c:write_sb_page() wants fixing: rcu_read_lock(); rdev_for_each_rcu(...) md_super_write(...) bio_alloc(GFP_NOIO, 1); Neil? -- Jens Axboe --

That was my initial thought as well, but the problem there is that you cannot prealloc > 1 bio without matching it with a submit_bio() as well, or you'd violate the bio_alloc() restriction on having the previous in flight before allocating a new one. -- Jens Axboe --

Woops, that kmalloc() is nasty. Thanks a lot, applied to for-2.6.28. -- Jens Axboe --

Yes, that was my plan, but without knowing how _SPECIAL is used, it's a bit tricky. Is there a comment somewhere which describes who sets it and when? From a quick look, it seems it's set on newly added user pages which aren't COWed. Can they be shared file-backed pages? It's only used in a couple of places, so giving it a longer name wouldn't cost much. _PAGE_USER_UNCOUNTED? But ugh, a lot of cross-arch churnpatch to do it. J --

The WWAN radio control has been working well for over three years, and is no longer experimental. Signed-off-by: Jeremy Fitzhardinge <jeremy@goop.org> --- Documentation/laptops/thinkpad-acpi.txt | 11 +++-------- drivers/misc/thinkpad_acpi.c | 1 - 2 files changed, 3 insertions(+), 9 deletions(-) =================================================================== --- a/Documentation/laptops/thinkpad-acpi.txt +++ b/Documentation/laptops/thinkpad-acpi.txt @@ -44,7 +44,7 @@ ...

The CPA test code uses _PAGE_UNUSED1, so make sure its obvious. Signed-off-by: Jeremy Fitzhardinge <jeremy.fitzhardinge@citrix.com> --- arch/x86/mm/pageattr-test.c | 6 +++--- include/asm-x86/pgtable.h | 2 ++ 2 files changed, 5 insertions(+), 3 deletions(-) =================================================================== --- a/arch/x86/mm/pageattr-test.c +++ b/arch/x86/mm/pageattr-test.c @@ -32,7 +32,7 @@ GPS = (1<<30) }; -#define ...

In what sense? Do you think I am trying to direct as much bugs as possible linux-kernel malinglist is focused on vanilla kernel development. i.e. all the bugs that are present in the current version of the code are very welcome to be reported here. SLES10 is based on 2.6.16 kernel, which has little interest for vanilla kernel developers. The bug you might be seeing could be caused by some SLES-specific patch (which is not probable, there are not many out-of-tree patches really), could ...

I've worked with systems where SO_TIMESTAMP has been used for H.323 videoconferencing systems to synchronize audio and video where remote systems' timestamps on the protocol streams proved to be inaccurate (based off of different, unsynchronized clocks). I can't see any other realistic use of this, but trying to get timestamps for quasi-realtime protocols may be an important use case - and in that case, you want the time when it hits the interface, NOT when it hits the socket. What ...

Linus only pulled the PF_SUPERPRIV fix once the sys_capset change was removed from the patch. It really does need to be a bugfix at this stage. - James -- James Morris <jmorris@namei.org> --

Applied to git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6#next -- James Morris <jmorris@namei.org> --

Hi Trond, I've tested the new patch with the test sequence mentioned in the original customer bug report, and it seems to work. Joe --

Is there any chance that the cached permissions are shared amoung multiple open(2)'s of the same file? If sharing happens then we really need to cache all of MAY_EXEC | MAY_WRITE | MAY_READ, rather than just that subset asked for by the open(2) that happens to be the one filling in the cache. In any case, I've rewritten the patch per the above suggestion, and in doing so noted an embarrasing bug in the original posting, one that happened to touch all the values that it needed to, by ...

Hi Yinghai - sorry, I've been away from my email for a few days. I know you resolved most of the problems, but a quirk patch to get rid of the BAR all together would be a good idea. I'll send something out following the US holiday. Jordan -- Jordan Crouse Systems Software Development Engineer Advanced Micro Devices, Inc. --

Do you have an updated version of your patch that applies to OK, indeed it never autosuspends... I guess this is this due to the keyboard and the mice being on the same usb port and as the kbd part Well reaching this line the touchpad is idling (hasn't been touched+no button was pressed) - I somehow wanted to force it to suspend in this My fault. I was still rmmod'ing appletouch before suspending. It works perfectly + reliably the way it is. Thanks, Soeren --

Hi Linus, Please pull the i2c subsystem fixes for Linux 2.6.27 from: git://jdelvare.pck.nerim.net/jdelvare-2.6 i2c-for-linus drivers/i2c/i2c-core.c | 18 ++++++++++-------- include/linux/i2c.h | 12 ++++++++++++ 2 files changed, 22 insertions(+), 8 deletions(-) --------------- Jean Delvare (2): i2c: Add missing kerneldoc descriptions i2c: Prevent log spam on some DVB adapters Marc Pignat (1): i2c: Fix device_init_wakeup place Thanks, -- Jean ...

So basically, you (Intel) have no clue what IDs will be used, and instead of waiting until you have the information, you prefer to add a bunch of device IDs to the Linux kernel, most of which will never exist? This is making the kernel code bigger and slower. Not by much, but still... That's bad engineering, really. Especially if you don't clean up afterwards, as happens to be the case for the ICH10. I compared the ICH10 datasheet with the IDs we have in the kernel and only 3 of the 6 defined ...

This is messy. I'm discarding this patch from my i2c tree for the time being. When things have settled on the pci_ids.h front, I'll look into applying it again. Note that your patch is still missing a chunk to Documentation/i2c/busses/i2c-i801. Originally I added it myself but if you are going to resend the same patch with different IDs every now and then, please add it on your side too, so that I don't have to fix it manually every time. -- Jean Delvare --

I've just installed this version. Here's what I see so far : The driver inserts well and when I connect my device it shows /dev/usbtmc0 with major 180 and minor 176. It only creates one device (Stefan's driver created two) but I'm not sure if that has changed for a reason so just let you know. When I disconnect my device, usbtmc0 will not be destroyed. After connecting the device a couple of times I have a lot of /dev/usbtmc.. files. I would expect the following to work : echo ...

Thank you, Adam! Yes, libhugetlbfs user increased in these days. --

Now, hugepage's vma has VM_RESERVED flag because it cannot be swapped. and VM_RESERVED vma isn't core dumped because its flag often be used for kernel internal vma (e.g. vmalloc, sound related). So, hugepage is never dumped and it indicate hugepages's program can't be debugged easily. In these days, demand on making use of hugepage is increasing. IMO, native support for coredump of hugepage is useful. I think VM_RESERVED default dumping bahavior is good, then I'd like to add ...

Yes, this bug didn't come up to the surface since p9_create_twrite is not even being called anywhere in v9fs. I tripped over it when using 9p Yes, but then that makes the "check for error in return value" in p9_create_twrite useless since memmove is not going to return an error in any case. Going with the existing convention however, I think the bufoverflow check is unnecessary in p9_put_data and so is the check for error on return. I'll resubmit a patch. --

Hi, everyone, Please review our new version of the iSCSI Initiator drivers for Chelsio S3 adapters. We have updated the code with the feedbacks received, including getting rid of most of the __GFP_NOFAIL allocation. The cxgb3i driver provides iscsi acceleration (PDU digest offload and payload direct-placement) to the open-iscsi initiator. It accesses the hardware through the cxgb3 module. The accelerated iscsi traffic uses a private IP address which is unknown to the OS. netdev list, please ...

[PATCH 2/4 2.6.28] cxgb3 - handle ARP replies for private iSCSI IP address From: Karen Xie <kxie@chelsio.com> The accelerated iSCSI traffic uses a private IP address unknown to the OS. The driver has to reply to ARP requests dedicated to the private IP address. Signed-off-by: Divy Le Ray <divy@chelsio.com> --- drivers/net/cxgb3/sge.c | 72 ++++++++++++++++++++++++++++++++++++++++++++--- 1 files changed, 67 insertions(+), 5 deletions(-) diff --git a/drivers/net/cxgb3/sge.c ...

Yep, these are hard. Which method is your favorite? My original purpose was to fix a bug as I described. This bug and the problem that offering big enough array for a huge cgroup are orthogonal! Could you consider/test that is it a bug as I described(and is it as critical as I described, maybe I was too nervous)? And this is also a problem: opening a cgroup.tasks twice or will waste a lot of _physical_ memory. Thanks! Lai --

We have to include the contents of /lib/firmware directory when building the RPM package, otherwise the build will fail because of unpackaged files. Signed-off-by: Luiz Fernando N. Capitulino <lcapitulino@mandriva.com.br> --- scripts/package/mkspec | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/scripts/package/mkspec b/scripts/package/mkspec index ffd61fe..4f5d8cd 100755 --- a/scripts/package/mkspec +++ b/scripts/package/mkspec @@ -92,5 +92,6 @@ echo "%files" ...

Some of Freescale SoC chips have a QE or CPM co-processor which supports full speed USB. The driver adds device mode support of both QE and CPM USB controller to Linux USB gadget. The driver is tested with MPC8360 and MPC8272, and should work with other models having QE/CPM given minor tweaks. Signed-off-by: Xie Xiaobo <X.Xie@freescale.com> Signed-off-by: Li Yang <leoli@freescale.com> --- This is the second submission of the driver. This version addressed: Comments from Anton Vorontsov. A ...

Thanks for the pointer, I'll take a look at it! --

I don't care about your work around, I was replying due to your insane comments about considering removing IBSS merge support because your Atheros hardware supports IBSS merge, please consider a proper work around instead for hardware which does not support this. Luis --

Ah, OK. Thanks for the clarification. Andre --=20 The only person who always got his work done by Friday was Robinson Crusoe

Hello, Todays -git spits out these wanings during boot, caused by Commit abf5439370491dd6fbb4fe1a7939680d2a9bc9d4 ( block: move cmdfilter from gendisk to request_queue ): Using physmap partition information Creating 3 MTD partitions on "physmap-flash": 0x00000000-0x01c00000 : "User FS" 0x01c00000-0x01c40000 : "booter" kobject (8511c410): tried to init an initialized object, something is seriously wrong. Call Trace: [<8036644c>] dump_stack+0x8/0x34 [<8021f050>] ...

Please lets not break affinity :). I'm going to submit patches (soonish) that convert drivers/etc to use cancel_work_sync()/flush_work() instead of flush_scheduled_work(). That takes care of the "machine getting stuck because workqueue thread is starved" case. Max --

Well, I was pretty sure the firmware did this for us. I can recheck that later. In any case, I will accept patches that are _well_ _tested_ to workaround this issue. I don't have the time work work on IBSS by myself. My pile already is big enough. :) --

looks good, its running without error on the non-rt kernel. Signed-off-by: mark gross <mgross@linux.intel.com> FWIW I'll send this as patch to Andrew in a moment. --

On the contrary: playing VM games is going to be slow. I think this approach is best suited for generic ioctl support because it simplifies the kernel part. I'd hate to add all that complexity to the kernel if not absolutely necessary. Miklos --

I don't understand. No new vulnerabilities are introduced, since it would just use existing infrastructure. Why is it better if the kernel does the copying of memory regions instructed by the userspace filesystem, than if the userspace filesystem does that copying itself? I feel they are totally equivalent, except that the latter needs more complexity in the kernel. Miklos --

OK, it should map /proc/pid/task/tid/mem. Or rather /proc/tid/task/tid/mem, as the pid (tgid) of the caller is not currently passed to the filesystem. Miklos --

OK, I grant this one. But then it's easy to protect against by getting a ref on the task (or just the task ID, I don't know if that's The same stupid mistakes can be done by giving the wrong instructions to the kernel about what to modify, thus thrashing the calling I don't see the difference. You have to be careful either way, it's not possible to do ioctls safely as the rest of fuse unfortunately. This obviously also means, that it's impossible to run the filesystem as an unprivileged ...

Wrong. Even if the system has multiple CPUs, and even if just a single CPU is fully utilized by an RT task, without the rt-limit the system will still lock up in practice due to various other factors: workqueues and tasks being 'stuck' on CPUs that host an RT hog. While there's obviously CPU time available on other CPUs, you cannot run 'top', the desktop will freeze, work flows of the system can be stuck, etc, etc.. With the rt limit in place, it's all pretty smooth and debuggable. ...

ok, i've propagated those commits to auto-x86-next as well, so that linux-next is fixed too. Ingo --

Linus, Please pull the latest core-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git core-fixes-for-linus Thanks, Ingo ------------------> Joe Korty (2): lockstat: fix numerical output rounding error lockstat: repair erronous contention statistics Steve VanDeBogart (1): exit signals: use of uninitialized field notify_count Zhu Yi (1): lockdep: fix invalid list_del_rcu in zap_class kernel/exit.c ...

applied to tip/x86/core, thanks Yinghai! Ingo --

applied to tip/core/printk, thanks Joe. Ingo --

i fully agree with that principle, i just messed up implementing it. 'Sticky resources' tried to be exactly the kind of 'untrusted, possibly wrong' resources, which should not prevent existing PCI resources from being registered - they would at most prevent new PCI resources from being allocated over them. (the free space is large enough for us to take the small/untrusted hint from the BIOS where not to allocate to) I missed the possibility of a sticky resource not being wide enough ...

good idea - applied to tip/sched/devel - thanks Joe. Ingo --

i've created a new, -git based topic for this: tip/tracing/stack-tracer, applied your new stacktrace plugin and started testing it. Ingo --

Here we have the problem of overlap i outlined earlier: if there's a partial overlap at this stage (as i think it can happen in the hpet case on David's box), we wont insert the E820_RESERVED resource. The hpet hang will be solved, because we dont reprogram the BAR, but we now keep the formerly e820-reserved area as 'free' - which the PCI code could allocate new resources into - which could cause other problems (hangs, non-working devices, etc.) down the line. Which most likely wont ...

we can certainly include and test Frédéric's patch in tip/tracing/ftrace - i'll wait for v2 as i guess he will implement the modifications suggested by you? Ingo --

very nice patch! I've split your patch into two, and applied the kernel/resource.c and include/linux/ioresource.h core bits to the tip/core/resources topic branch - see the first patch below. (i renamed the new API to check_sticky_resource()) Then i've merged this topic branch into irq/sparseirq and applied the x86 bits that use this new facility to irq/sparseirq [on which it has many dependencies, io_apic.c and apic.c got unified, etc.]. See the second patch below. Especially the ...

applied it to tip/tracing/urgent - thanks Rafael! Ingo --

Linus, Please pull the latest sched-fixes-for-linus git tree from: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git sched-fixes-for-linus Thanks, Ingo ------------------> John Blackwood (1): sched: fix sched_rt_rq_enqueue() resched idle Peter Zijlstra (1): sched: rt-bandwidth accounting fix kernel/sched_rt.c | 13 +++++++------ 1 files changed, 7 insertions(+), 6 deletions(-) diff --git a/kernel/sched_rt.c b/kernel/sched_rt.c index ...

yeah, agreed, this is a reasonable suggestion. Peter, do you agree? Ingo --

agreed. Ingo --

A documented WMI interface is easier to use than an entirely custom documented interface, and reduces the amount of work the vendor has to do in Windows. To be honest, I think it's the sort of thing we should be encouraging. -- Matthew Garrett | mjg59@srcf.ucam.org --

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Sorry to get to this late. I very much prefer this patch over the resuscitation of the cap_set_pg() code. [I would also like to advocate we combine it with making CONFIG_SECURITY_FILE_CAPABILITIES=y the default config option.] Cheers Andrew Serge E. Hallyn wrote: | In any case, how about the following patch? | | If it is ok with everyone, then I'll rewrite the intro and send it | out separately. | | thanks, | -serge | |>From ...

Thanks, forwarding to mailing lists. Since you are in a better position to test (already have the installation and configuration set up) I'm not going to try to reproduce this until you tried 2.6.26. Thanks, Miklos --

BTW. this is funny that you just decide you can somehow "weaken" my technical arguments because of some of my personal attribute you believe about me. You don't know why I am arguing? I'll put it very simply one more time. - This behaviour has changed the kernel's userspace API in a way that can break existing applications. That is my primary point. If you think it gets somehow weaker because you don't think I have ever locked up my workstation with an RT task, then I give up arguing ...

;) Well yes as you know I'm not actively doing much scheduler work for a while now. Luckily there are a lot of really good people who probably do a better job on it than me anyway, so on the whole I'm quite happy with it. But ironically that's also why I hadn't raised my concerns earlier... I simply was not aware of the change. So I wish I had participated in the To address this concern: no, it is not tpc ;) Actually I don't know a thing about how tpc except what scant information can ...

They'll tend to be device pages. XIP filesystem mappings can set it too. They won't be set on anonymous pages, or on normally mmap()ed pagecache pages (although best not to take the latter as a strict rule because Right. But they could nearly have clashed without ever being set on kernel ptes -- if we ever _tested_ kernel ptes for that bit (gup.c has other safeguards that should keep us away from kernel pages, but it could in theory be implemented on x86 by only testing _PTE_SPECIAL if we ...

Would it make sense to make a new option for these socket timestamps and encourage some apps move over to it? --

Weighed against register save/restore, compiler barrier, and function call cost of uninlined. These can add up to 10s of cycles per call I've seen, so if it is called several times between each icache miss it can easily be worth inlining. Basically, measurement is required, and if it isn't important enough to measure policy tends to default to uninline if that saves space. --

It is actually possible (with fairly little work, last time I looked, maybe it is already integrated in the kernel) to avoid all this kind of thing from isolated CPUs. But even then, note that the types of programs using the CPU for long periods are obviously not going to be run on an average desktop system. So the responsiveness argument is laughable. Responsive as defined how? And in relation to what type of systems? --

I've implemented a sort of spin local, queueing MCS lock that uses per-cpu nodes that can be shared by multiple locks. I guess it is preferable to remove global locks, but some don't seem to be going anywhere soon. The only issue is that only one set of nodes can be actively used for a lock at once, so if we want to nest these locks, we have to use different sets for each one. This shouldn't be much of a problem because we don't have too many "big" locks, and yet fewer ones that are nested in ...

Sorry, can't understand the text above :( OK, let's suppose the application does ptrace(PTRACE_SELF_ON); ... syscall(); This "syscall()" above should trigger the handler for SIGSYS. But what if another signal (with handler) comes in between? In that case handle_signal() clears PT_SELF/TIF_SYSCALL_TRACE, this syscall() (or any other) doesn't send SIGSYS. Oleg. --

The attached patch is reported to make the problem go away for a user of btusb. He might be able to use it for narrowing down causes. Regards Oliver

I am afraid this is not true. Regards Oliver /** * scsi_block_when_processing_errors - Prevent cmds from being queued. * @sdev: Device on which we are performing recovery. * * Description: * We block until the host is out of error recovery, and then check to * see whether the host or the device is offline. * * Return value: * 0 when dev was taken offline by error recovery. 1 OK to proceed. */ int scsi_block_when_processing_errors(struct scsi_device ...

Well, they have to handle other commands while bus has problems, anyway, right? So I'm not creating any _new_ problems for them. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Yes, you need upcoming filesystem capabilities. Binary may not inherit capabilities unless filesystem flags permit that. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Hi Alexey, Uhm, I'm not sure how that would work out. I mean, we'd need to see if parts of the loaded byte are used or not... Doesn't sound practical or too pretty. Pekka --

Why not do something like this (as suggested by Ingo, I think)? Yeah, the macro should go into kmemcheck.h but I don't have a tree handy... Pekka Index: linux-2.6/include/linux/bitfield.h =================================================================== --- /dev/null +++ linux-2.6/include/linux/bitfield.h @@ -0,0 +1,10 @@ +#ifndef __LINUX_BITFIELD_H +#define __LINUX_BITFIELD_H + +#ifdef CONFIG_KMEMCHECK +#define KMEMCHECK_BIT_FIELD(field) do { field = 0; } while ...

If the tracing application catches all signals before delivering them to the instrumented original handler there is no problem, the catching code can reset PTRACE_SELF_ON before calling the instrumented application's original handler. The instrumented code will then bounce as expected. I see this more like a security, the "bouncing" feature is only enabled until next syscall or signal, never more. This instrumentation method allows with this little patch to do all the syscall and signal ...

On Thu, 28 Aug 2008 11:04:36 +0100 I think making it more modular would be nice, but I'm not really working Yes, but the atmosphere is that if there are no users in-tree, the feature gets kicked, out-of-tree users or no. That's the reason mmiotrace went in-tree in the first place. So, to get that stuff exported, we might need in-tree users, I believe. Thanks. -- Pekka Paalanen http://www.iki.fi/pq/ --

The earliest time the application could have been expected to start processing the request. Until it hits the socket, it might as well be somewhere in the cloud. By that reasoning of course, one could argue that a gettimeofday() call immediately following recv() would suffice. Earlier in the thread mention was made of financial services types. If someone has knowledge of the (probably) arcane rules under which they must operate it would be great to hear more. Does some entity like the ...

Has the request "hit the trading system" when it hits the NIC, or when it hits the application executing the trade? If the SEC calls for when it hits the NIC, then none of what is done today is really accurate/correct and one would need to start using NIC HW timestamps, synchronized with the host and the other NICs in the system no? The way things are today, there really isn't much guarantee that hitting NIC 1 before NIC 2 will result in a driver-generated timestamp for the NIC 1 ...

Hm, cifsd. It is kind of known to have problems. How reproducible is this? Rafael --

Hello list, This is pretty long -- I sure hope this is the right place to ask these :) First of all, I have a board with a NAND flash device, to which I have a 8k-wide PCI interface. I've been wondering about these: 1. I would prefer if the block layer always passed me 8k long segments, even though the hard sector size is 2k. I tried using blk_queue_hardsect_size() and set it to 8k, but for some reason I get a panic. Is it possible that hardsect cannot be larger than PAGE_SIZE (makes some ...

My biggest concern about adding a limit to FIFO is that an RT developer would spend weeks trying to debug their system wondering why their planned CPU RT hog, is being preempted by a non-RT task. For this, if this time limit does kick in, we should at the very least print something out to let the user know this happened. After all, this is more of a safety net anyway, and if we are hitting the limit, the user should be notified. Perhaps even tell the user that if this behaviour is expected, ...

I guess the reason that this is getting so much noise over other default policies, is that this default policy is changing a well known definition: The meaning of FIFO. By making the default policy limit the time an RT task runs, we have, in essence, changed a user API. Applications that expect to be able to run uninterrupted by SCHED_OTHER tasks, will now break. No one is arguing that this new feature is not useful. The argument is, should the kernel set the default policy of an old ...

Perhaps we should default it to 1sec, that way it would be hit more often, and educate the users of this now feature. -- Steve --

The fact that it actually limits a SCHED_FIFO task group, over a single task thread does bother me a little. But that said, I and others have made our complaints known, and will forever be documented in the halls of the Internet abyss. Thus, the verdict has been laid. Seems the default shall be something other than infinite. I will now remain silent. -- Steve --

How can you say "m" to something that is not a tristate? -Scott --

Ok, sorry, of course that makes sense. I was just confused about where the patch was originally heading. Would it be appropriate to put the capset neutering patch in your security-testing tree, James, or does that feed straight into linux-next? thanks, -serge --

Sorry, will do with the rebase. Thanks, Andrew. -serge --

Add a no_file_caps boot option when file capabilities are compiled into the kernel (CONFIG_SECURITY_FILE_CAPABILITIES=y). This allows distributions to ship a kernel with file capabilities compiled in, without forcing users to use (and understand and trust) them. When no_file_caps is specified at boot, then when a process executes a file, any file capabilities stored with that file will not be used in the calculation of the process' new capability sets. This means that booting with the ...

I'm not sure what's "messy," given that I changed what was required to be changed, then added the new IDs. These IDs are as follows: LPC Controller: 3b00-3b1f (final ID set in Firmware, but 32 possibilities) SMBus: 3b30 In terms of the irq stuff, I'm adding only the LPC Controller IDs there. There are just a lot of them. Normally we have a handful of IDs, but in this case the list is longer. I suppose what "messy" means is, I should have kept the existing defines and only added the new? ...

This patch adds the Intel Ibex Peak (PCH) SMBus Controller DeviceIDs. Changes are reflected in i2c-i801.c in response to updates to pci_ids.h. The SMBus Controller is now referred to as PCI_DEVICE_ID_INTEL_PCH_SMBUS, a change to the old naming convention of PCI_DEVICE_ID_INTEL_PCH_x. Signed-off-by: Seth Heasley <seth.heasley@intel.com> --- linux-2.6/Documentation/i2c/busses/i2c-i801.orig 2008-08-28 10:11:27.000000000 -0700 +++ linux-2.6/Documentation/i2c/busses/i2c-i801 2008-08-28 ...

Hi Dave, Linus' tree fails to build for sparc32 allmodconfig: kernel/relay.c:701: undefined reference to `smp_call_function_single' This is because it has CONFIG_SMP but not CONFIG_USE_GENERIC_SMP_HELPERS. I am not sure what to do about this. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

Hi Bart, On Wed, 27 Aug 2008 16:57:18 +0200 "Bartlomiej Zolnierkiewicz" <bzolnier@gm= Thanks for finding this, I will apply it to today's linux-next. --=20 Cheers, Stephen Rothwell sfr@canb.auug.org.au http://www.canb.auug.org.au/~sfr/

On Fri, 22 Aug 2008 04:57:40 +0300 What kernel version is this? There was a fix to AF_PACKET about a year ago to reduce this. --

I started this discussion last week with an apparent bug in the new CFS. As it turns out, it was not a bug, it was an feature, a (undocumented?) feature. In the world of embeded device and real time programming it is not a hard job to compile the kernel right for the desired usage und fix the startup script to use the desired policy. Getting back the old behaviour would be nice and in my opinion the right way, because the new one breaks with POSIX. But I have a working solution and that is ...

This was done deliberately. The relevant standards state that a USB device can have no more than one peripheral interface. Now, I don't claim to fully support this decision. But there is a reason behind it; it's not just a case of bad design. Alan Stern --

the BIOS supports raid0, but the sata disks are running standalone as /dev/sda /dev/sdb etc. installing a recent kernel is not that easy, as the required upgrade of udev will break the initscripts and a lot of installed services and even the functionality of the KDE desktop. Installing a recent distro is not desirable as they resemble me only of a Open Source Vista distro, where it takes months to clean up the unwanted garbage and bloat inside. Its preposterous that a upgrade to a recent ...

Hi, I have a couple of AMD64 machines with onboard sound devices running and they all have one thing in common : flaky sound when one is doing some heavy disk I/O on the SATA disks. Interesting enough /proc/interrupts shows that libata is using the same IRQ as the sound devices : model name : AMD Athlon(tm) 64 X2 Dual Core Processor 6000+ stepping : 3 cpu MHz : 3014.679 cache size : 1024 KB # cat /proc/interrupts CPU0 CPU1 0: ...

So we remove nla_parsed_nested_compat() just to add it again under a different name since netem is still going to use that piece of code. That certainly makes sense. Fixing prio and rr in stable is a one liner. --

At Thu, 28 Aug 2008 11:14:35 +0100, For me, it's easier when they come from you all together ;) I still postponed to merge Jean's latest patches. Care to check that don't conflict your work and send them together? thanks, Takashi --

kobject_uevent_env() uses envp_ext[] as verbatim format string which can cause problems ranging from unexpectedly mangled string to oops if a string in envp_ext[] contains substring which can be interpreted as format. Fix it. Signed-off-by: Tejun Heo <tj@kernel.org> --- lib/kobject_uevent.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/lib/kobject_uevent.c b/lib/kobject_uevent.c index 3f91472..ca215bc 100644 --- a/lib/kobject_uevent.c +++ ...

Add cdev->release() so that cdev can be considered in more involved object lifetime management. cdev_alloc() used a separate ktype for auto-free release(). This patch converts it to use cdev->release() so that there's no need for separate ktype and cdev_init() can be used for auto-free variant too. Signed-off-by: Tejun Heo <tj@kernel.org> --- This one is also for CUSE. Oops, forgot lkml. Resending. Thanks. fs/char_dev.c | 30 +++++++++++++----------------- ...

Add include protectors to include/linux/fuse.h and fs/fuse/fuse_i.h. Signed-off-by: Tejun Heo <tj@kernel.org> --- fs/fuse/fuse_i.h | 5 +++++ include/linux/fuse.h | 5 +++++ 2 files changed, 10 insertions(+), 0 deletions(-) diff --git a/fs/fuse/fuse_i.h b/fs/fuse/fuse_i.h index 3a87607..e2b3b72 100644 --- a/fs/fuse/fuse_i.h +++ b/fs/fuse/fuse_i.h @@ -6,6 +6,9 @@ See the file COPYING. */ +#ifndef __FS_FUSE_I_H +#define __FS_FUSE_I_H + #include <linux/fuse.h> ...

This patchset extends FUSE such that it supports more file operations and is consisted of the following seven patches. 0001-FUSE-add-include-protectors.patch 0002-FUSE-pass-nonblock-flag-to-client.patch 0003-FUSE-implement-nonseekable-open.patch 0004-FUSE-implement-direct-lseek-support.patch 0005-FUSE-implement-ioctl-support.patch 0006-FUSE-implement-unsolicited-notification.patch 0007-FUSE-implement-poll-support.patch The added features will be used primarily for CUSE but can ...

Ah.... funky. If this retry thing is too repulsive, I guess the best alternative would be directly accessing caller's memory as Miklos suggested. Thanks. -- tejun --

If you're worried about the double copying due to performance reasons, what we can do is implementing userspace to userspace copying. I just took easier path of copying twice as u-u copy can't be done using the existing FUSE mechanics, but frankly, at this point, I think that would be an premature optimization. -- tejun --

I'm no security expert but it feels pretty dangerous to me. First of all, there are cases where the calling process can exit before the userland FUSE is finished with an operation, so it might not be always possible for the FUSE client to tell the PID it got is the correct one. Another thing is that as it currently stands, the kernel side FUSE implementation forms a nice safety net taking responsibility of most security concerns and insulating the mistakes the client may make. Letting ...

Well, as cdev can be referenced from userspace, ->release is required for most purposes. The reason why devices have been getting by without it is because most chardevs are created on module load and destroyed on module unload and in the meantime cdev refcount virtually equals module refcnt, but I'm fairly sure we have cases where cdev can be destroyed for other reasons then module unloading and it's very likely those cases are buggy in the current code (backing structure gone bug cdev ...

Hmmm.... I've never actually audited the code so... it could be that no The problem is not the device to talk to CUSE (/dev/cuse as in /dev/fuse), for which module refcount and device refcount match fine. But the whole point of CUSE is allowing CUSE clients to create arbitrary character devices, so in addition to /dev/cuse which clients use to talk to CUSE, CUSE hosts character devices for its clients and they come and go dynamically and thus requires proper lifetime ...

add_uevent_var() appends the specified variable whether the new entry has duplicate key or not. This patch makes add_uevent_var() to override the existing entry if an entry with the same key is added later. This will be used by CUSE (character device in userland) to fake hotplug events. Signed-off-by: Tejun Heo <tj@kernel.org> --- lib/kobject_uevent.c | 33 ++++++++++++++++++++++----------- 1 files changed, 22 insertions(+), 11 deletions(-) diff --git a/lib/kobject_uevent.c ...

Export the following symbols for CUSE. fuse_conn_put() fuse_conn_get() fuse_get_root_inode() fuse_super_operations fuse_send_init() fuse_flush() fuse_fsync() fuse_direct_io() fuse_file_lock() fuse_file_flock() fuse_file_llseek() fuse_file_ioctl() fuse_file_compat_ioctl() fuse_file_poll() Signed-off-by: Tejun Heo <tj@kernel.org> --- fs/fuse/dev.c | 9 ++++++++- fs/fuse/file.c | 30 ++++++++++++++++++++---------- fs/fuse/fuse_i.h | 29 +++++++++++++++++++++++++++++ ...

Ah.. right, but taking cdev refcount out of the picture requires adding 'severing' operation on cdev f_ops, which certainly is doable but isn't it just cleaner to make cdev follow the usual lifetime management rules? An object which is referenced counted requires ->release if it's gonna be used in any non-simplistic way. Thanks. -- tejun --

If you're worried about the double copying due to performance reasons, what we can do is implementing userspace to userspace copying. I just took easier path of copying twice as u-u copy can't be done using the existing FUSE mechanics. -- tejun --

Allow clients to implement private lseek. The feature is negotiated using FUSE_DIRECT_LSEEK flag during INIT. If the client doesn't request direct lseek, the original implicit lseek is used. Signed-off-by: Tejun Heo <tj@kernel.org> --- fs/fuse/file.c | 52 ++++++++++++++++++++++++++++++++++++++++++------- fs/fuse/fuse_i.h | 3 ++ fs/fuse/inode.c | 4 ++- include/linux/fuse.h | 14 +++++++++++++ 4 files changed, 64 insertions(+), 9 deletions(-) diff --git ...

CUSE enables implementing character devices in userspace. With recent additions of nonblock, lseek, ioctl and poll support, FUSE already has most of what's necessary to implement character devices. All CUSE has to do is bonding all those components - FUSE, chardev and the driver model - nicely. Due to the number of different objects involved and many ways an instance can fail, object lifetime rules are a tad bit complex. Please take a look at the comment on top of fs/fuse/cuse.c ...

Add fuse_ prefix to request_send*() and get_root_inode() as some of those functions will be exported for CUSE. With or without CUSE export, having the function names scoped is a good idea for debuggability. Signed-off-by: Tejun Heo <tj@kernel.org> --- fs/fuse/dev.c | 23 ++++++++++++----------- fs/fuse/dir.c | 34 +++++++++++++++++----------------- fs/fuse/file.c | 30 +++++++++++++++--------------- fs/fuse/fuse_i.h | 9 +++++---- fs/fuse/inode.c | 12 ++++++------ 5 ...

On Thu, Aug 28, 2008 at 4:30 AM, Luis R. Rodriguez So how do set TSF from the beacon, I'm asking because there is currently no interface from mac80211 to driver do that. Thanks Tomas --

As far as I can see, THIS IS TOTALLY BROKEN. There's a reason why we add the broken resources LATE. There's a reason we _have_ to add them late. Trying to come up with these braindamaged schemes to avoid doing it right is wrong. Don't do it. The reason? Those bogus resources that the BIOS reports are simply NOT TRUSTWORTHY. They may actually be in all the wrong places, including covering a resource half-way, or crossing two real resources. Yes, it's rare. But it happens. Which ...

Another week (my weeks do seem to be eight days, don't they? Very odd), another -rc. The dirstat pretty much says it all: 43.0% arch/arm/configs/ 43.9% arch/arm/ 25.5% arch/powerpc/configs/ 26.8% arch/powerpc/ 73.9% arch/ 4.4% drivers/usb/musb/ 5.4% drivers/usb/ 4.0% drivers/watchdog/ 16.0% drivers/ 3.5% fs/ yeah, the bulk of it is all config updates, and with arm and powerpc leading the pack. But seriously, while the config updates amount to about ...

Looks ok by me. Now it just needs testing ;) Does it actually fix the HPET regression on that odd machine (without the special hacks to recognize HPET explicitly)? Linus --

The kernel has always done a certain amount of "default policy". What do you think things like "swappiness" etc are? Or things like oevrcommit settings? They're all policies, and there is always a default one. So in that sense the kernel always has - and fundamentally _must_ - set some kind of policy. And the default policy should generally be the one that makes sense for most people. Quite frankly, if it's an issue where all normal distros would basically be expected to set a ...

They can use their own devices. There is a section about if you provide your own device, document it, etc.: 2 Vendor specific ACPI implementations ... 2. If new devices or functions are introduced, document how to use them. A short specification or a request for comments (RFC) can form the basis of a new standard which follows your needs. But yes, it could be pointed out clearer. I'll look closer at it when I touch it the next time. Text snippets/suggestions are also ...

Well, because that's not the what the POSIX draft specification (and the rest of the Unix industry who were striving to meet the US Department of Defense's "B2 by '92" initiative) ended up implementing. The reason for that was to avoid bugs where a program that wasn't expecting to be setuid (or just written by a stupid progammer) exec's some program which wasn't expecting to have root privileges then bad things happen. The classic example of this was running the mail program, which was ...

Hi! (ingoring the fact your opinion may be influenced by SUSE/Novell) Are you saying that SUSE/Novell added bugs regarding NFS4 that are not present in the vanilla kernel, or are you saying that the vanilla kernel may have fixed NFSv4 bugs that SUSE/Novell did not fix? Why shouldn't anybody be interested in the fact that there are problems? Regards, Ulrich --

It looks like that would work. Seems that sig->count == 0 && sig->group_exit_task != NULL can never be true. If it does work, a lot of initialization in copy_signal() can be removed and it would reduce the chances that a similar problem would be reintroduced. I would submit a patch, but I'm not sure how to trigger those code paths in order to test it. -- Steve --

Ok, that's constructive :-P Can we skip the type and always assume that it should be __u8/uint8_t? I read somewhere that bitfields should anyway always be 1 byte wide if the bitfield should be "portable". Would it help (to make this less horrible) to omit the type declaration and have just the bitfield members as arguments to the macro? Thanks, Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest ...

On Wed, Aug 27, 2008 at 12:14 AM, Daniel J Blueman Hm. Is this with my first patch + the one in the e-mail you replied to? It was intended to be a delta patch on top of my first one. That would be the one in http://marc.info/?l=linux-kernel&m=121946972307110&w=4 plus the one in http://marc.info/?l=linux-kernel&m=121969394110327&w=1 Thanks for testing and sorry for the confusion. (Maybe I just confused myself. Please let me know either way.) Vegard -- "The animistic ...

I think we have different opinions of what exactly constitutes "horrible" :-P Your suggestion would have made sense if I was a company of 10 developers who could import all of valgrind source code (including opcode decoder and instruction emulator) into the kernel. But I only writing kmemcheck in my free time, so this will never happen. Or.. at least I will not do it. Of course, kmemcheck, valgrind/memcheck, and indeed the kernel itself are all open source, so anybody could do it. In the ...

It's not just "must be evaluated at compile time"; it's "must be C constant expressions", which is much stricter. And no, in the case quoted above __constant_ form is not needed. Just use htonl()... --

On Thu, Aug 28, 2008 at 1:40 PM, Linus Torvalds David, can you test attached patch? also you may try to revert the old patch. YH

On Thu, Aug 28, 2008 at 1:05 PM, Linus Torvalds ok, will move e820_reserve_resource_late to pcibios_resource_survey(), so it is called vi pci_subsys_init before pnp_system_init YH --

so could let BAR res register at first, or even pnp? Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/kernel/e820.c | 20 ++++++++++++++++++-- arch/x86/pci/i386.c | 3 +++ include/asm-x86/e820.h | 1 + 3 files changed, 22 insertions(+), 2 deletions(-) Index: linux-2.6/arch/x86/kernel/e820.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820.c +++ linux-2.6/arch/x86/kernel/e820.c @@ -1271,13 +1271,15 @@ ...

to be aligned to numaq, summit Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> --- arch/x86/es7000/Makefile | 5 arch/x86/es7000/es7000.h | 114 ------------- arch/x86/es7000/es7000plat.c | 262 ------------------------------- arch/x86/kernel/Makefile | 1 arch/x86/kernel/es7000_32.c | 345 +++++++++++++++++++++++++++++++++++++++++ arch/x86/mach-generic/Makefile | 1 6 files changed, 346 insertions(+), 382 deletions(-) Index: ...