The message queue system calls that may timeout, mq_timedsend() and mq_timedreceive(), still use the old jiffie-based timer interface. Convert them to hrtimer. The first patch provides the hrtimer infrastructure, the second patch does the actual conversion to hrtimer. Carsten. --

The message queue functions mq_timedsend() and mq_timedreceive() have not yet been converted to use the hrtimer interface. This patch replaces the call to schedule_timeout() by a call to schedule_hrtimeout() and transforms the expiration time from timespec to ktime as required. CC: Andrew Morton <akpm@linux-foundation.org> CC: Arjan van de Veen <arjan@infradead.org> CC: Thomas Gleixner <tglx@linutronix.de> Tested-by: Pradyumna Sampath <pradysam@gmail.com> Signed-off-by: Carsten Emde ...

Hello, received the following BUG with 2.6.33.1: Apr 2 01:05:01 hermes kernel: ------------[ cut here ]------------ Apr 2 01:05:01 hermes kernel: kernel BUG at kernel/workqueue.c:399! Apr 2 01:05:01 hermes kernel: invalid opcode: 0000 [#1] SMP Apr 2 01:05:01 hermes kernel: last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host3/scsi_host/host3/proc_name Apr 2 01:05:01 hermes kernel: CPU 1 Apr 2 01:05:01 hermes kernel: Pid: 28, comm: events/1 Not tainted ...

Usable for lock-breaks and such. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- include/linux/mutex.h | 5 +++++ 1 file changed, 5 insertions(+) Index: linux-2.6/include/linux/mutex.h =================================================================== --- linux-2.6.orig/include/linux/mutex.h +++ linux-2.6/include/linux/mutex.h @@ -118,6 +118,11 @@ static inline int mutex_is_locked(struct return atomic_read(&lock->count) != 1; } +static inline int ...

This patch changes the anon_vma refcount to be 0 when the object is free. It does this by adding 1 ref to being in use in the anon_vma structure (iow. the anon_vma->head list is not empty). This allows a simpler release scheme without having to check both the refcount and the list as well as avoids taking a ref for each entry on the list. We then use this new refcount in the migration code to avoid a long RCU read side section and convert page_lock_anon_vma() over to use refcounts. This ...

We need an anon_vma refcount for preemptible anon_vma->lock as well as memory compaction, so move it out into generic code. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- Index: linux-2.6/include/linux/rmap.h =================================================================== --- linux-2.6.orig/include/linux/rmap.h +++ linux-2.6/include/linux/rmap.h @@ -26,9 +26,7 @@ */ struct anon_vma { spinlock_t lock; /* Serialize access to vma list */ -#ifdef CONFIG_KSM - atomic_t ...

Hi, This (incomplete) patch-set makes part of the mm a lot more preemptible. It converts i_mmap_lock and anon_vma->lock to mutexes. On the way there it also makes mmu_gather preemptible. The main motivation was making mm_take_all_locks() preemptible, since it appears people are nesting hundreds of spinlocks there. The side-effects are that we can finally make mmu_gather preemptible, something which lots of people have wanted to do for a long time. It also gets us anon_vma refcounting ...

Commit-ID: 85257024096a96fc5c00ce59d685f62bbed3ad95 Gitweb: http://git.kernel.org/tip/85257024096a96fc5c00ce59d685f62bbed3ad95 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Tue, 23 Mar 2010 19:30:52 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:30:01 +0200 x86: Move notify_cpu_starting() callback to a later stage Because we need to have cpu identification things done by the time we run CPU_STARTING notifiers. ( This init ordering will ...

Commit-ID: b4cdc5c264b35c67007800dec3928e9547a9d70b Gitweb: http://git.kernel.org/tip/b4cdc5c264b35c67007800dec3928e9547a9d70b Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Tue, 30 Mar 2010 17:00:06 +0200 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:52:04 +0200 perf, x86: Fix up the ANY flag stuff Stephane noticed that the ANY flag was in generic arch code, and Cyrill reported that it broke the P4 code. Solve this by merging ...

Commit-ID: 40b91cd10f000b4c4934e48e2e5c0bec66def144 Gitweb: http://git.kernel.org/tip/40b91cd10f000b4c4934e48e2e5c0bec66def144 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Mon, 29 Mar 2010 16:37:17 +0200 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:52:06 +0200 perf, x86: Add Nehalem programming quirk to Westmere According to the Xeon-5600 errata the Westmere suffers the same PMU programming bug as the original Nehalem did. Signed-off-by: ...

Commit-ID: 65cc8e4859ff29a9ddc989c88557d6059834c2a2 Gitweb: http://git.kernel.org/tip/65cc8e4859ff29a9ddc989c88557d6059834c2a2 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Thu, 25 Mar 2010 21:05:16 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:04 +0200 sched: Optimize task_rq_lock() Now that we hold the rq->lock over set_task_cpu() again, we can do away with most of the TASK_WAKING checks and reduce them again ...

Commit-ID: 371fd7e7a56a5c136d31aa980011bd2f131c3ef5 Gitweb: http://git.kernel.org/tip/371fd7e7a56a5c136d31aa980011bd2f131c3ef5 Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Wed, 24 Mar 2010 16:38:48 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:05 +0200 sched: Add enqueue/dequeue flags In order to reduce the dependency on TASK_WAKING rework the enqueue interface to support a proper flags field. Replace the int wakeup, bool head ...

This is also the needed bit to allow to schedule in the mmu notifier methods by switching from rcu to srcu there. That will make XPMEM happy by allowing all mmu notifier methods to schedule. Considering this may not slowdown the more important fast paths, it seems overall beneficial effort to me. Thanks, Andrea --

Hi Ben, Upstream has fixed several errors pointed out by you and Oliver (thanks for that), but some of them are still pending. I will send patches on top of my last driver submission (if the proper way would be resubmit the whole code, please tell me. Anyway I need to What is not longer needed? The assignment, the whole "else" branch? If Ok, I will just remove both #ifdefs, but why is that? Maybe in previous versions of the kernel the net_device_ops struct was introduced and now I ...

Hi Oliver, Just like with Ben's comments I still have a couple of doubts about your I understand that usb_clear_halt is only needed when the device has transmitted data, and as it is "open" time, we can assume that no transmissions ere made, so we don't need to clear anything (aka: remove Well, I have no clue about this one. I think that upstream developers should take a look into this (Dario, Daniel, could you?) since I don't have the knowledge to decide what to do about it. But I ...

--

Yes, this is what makes me confused. ;) Thanks! --

I hit this when we had a bug in IDR for a few days. Basically sysfs would fail to create new inodes since it uses an IDR and therefore class_create would fail. While we are unlikely to see this fail we may as well handle it instead of oopsing. Signed-off-by: Anton Blanchard <anton@samba.org> --- diff --git a/mm/backing-dev.c b/mm/backing-dev.c index 0e8ca03..f13e067 100644 --- a/mm/backing-dev.c +++ b/mm/backing-dev.c @@ -227,6 +227,9 @@ static struct device_attribute bdi_dev_attrs[] ...

They are indeed. Thanks. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. --

Hi, I've got the following oopsie two times now when hibernating - this means, I don't get it everytime I hibernate but only sometimes, say once in a blue moon. And yeah, I couldn't catch it over serial console so I had to make ugly pictures. By the way, the numbers in the filenames increment as I scroll down the whole oops (yep, it hadn't completely frozen and I still could do Shift->PgUp or Shift->PgDn on the console): http://www.kernel.org/pub/linux/kernel/people/bp/ So, here's what ...

On Fri, Apr 02, 2010 at 11:47:50AM -0400, Jerome Oufella wrote: Please fix your mail client to word wrap paragraphs, I've manually fixed You're asking the wrong question here. The problem here is not that the regulator got stubbed out, the problem is that the sht15 driver is not checking the return value of regulator_get_voltage() and so is trying to use the error code that was returned as a voltage, with predictably poor results. It is this function that the driver needs to check, ...

Thanks. I'd expect that if things are fine in -next you can probably not worry about this either way, but given that Takashi normally sends his pull request very early it probably won't make any difference --

Currently completion of WM831x AUXADC conversions is monitored by checking for convertor enable. Due to the mechanism used to ensure data corruption is avoided when reading AUXADC data there may under heavy I/O be a window where this bit has cleared but the conversion results have not been updated. Data availability is only guaranteed after the AUXADC data interrupt has been asserted. Avoid this by always using the interrupt to detect completion. If the chip IRQ is not set up then we poll the ...

Yes, you could pass a pointer to the value or similar. OTOH that'd mean I'm not sure there's actually much win from this information since we do have cases with things like functionally limited regulators and error conditions which mean that drivers end up having to cope with pretty much all this stuff anyway. But yes, NULL should be just as good as a In this case you don't need the if (voltage) check - the code that uses supply_uV is going to have to cope with it being set to 0 if the ...

The problem we had before was a combo of not clearing PDE and not having the command buffer set up properly. Now we have basically the same problem. The attach is running too early, so the invalidate commands are falling on deaf ears. thanks, -chris --

To catch future potential issues we can add a warning whenever we issue a command before the command buffer is fully initialized. Signed-off-by: Chris Wright <chrisw@sous-sol.org> --- Or not...this is just if you think it's useful ;-) arch/x86/include/asm/amd_iommu_types.h | 1 + arch/x86/kernel/amd_iommu.c | 1 + arch/x86/kernel/amd_iommu_init.c | 5 +++-- 3 files changed, 5 insertions(+), 2 deletions(-) --- a/arch/x86/include/asm/amd_iommu_types.h +++ ...

No, we actually disable the IOMMU panic() crash_exec() machine_crash_shutdown() native_machine_crash_shutdown() Cached DTE only gets you domainID and pt root, so results depend upon Yes, but this is immediately after 2b above. We can't send the invalidate Unlikely to have full unity map, it's typically just for a range, and this is also typically for devices that have interaction w/ BIOS (typical examples are usb/SMM for keyboard and integrated graphics). And the ...

Sure, thanks for catching. Will resend shortly thanks, -chris --

Increasing these values did help quite a bit, though I was still seeing 5000-8000ms at nfs_wait_bit_uninterruptible() [1] and close(). Then again, I also was seeing 'Scheduler waiting for cpu' taking up to 3000ms! I suspect processor throttling, due to exceeding thermal limits. Thanks, Daniel --- ...

From: Cong Wang <amwang@redhat.com> Applied, thanks. --

From: H Hartley Sweeten <hartleys@visionengravers.com> Isn't it intentional? The two consts mark different aspects of the declaration const, both the pointers as well as the contents pointed to. --

From: FUJITA Tomonori <fujita.tomonori@lab.ntt.co.jp> This is a good start, applied to net-next-2.6, thanks! --

From: H Hartley Sweeten <hartleys@visionengravers.com> Perhaps. --

Maybe I should add : kernel: Linux version 2.6.27.25-78.2.56.fc9.i686 (mockbuild@) (gcc version 4.3.0 20080428 (Red Hat 4.3.0-8) (GCC) ) #1 SMP Thu Jun 18 12:47:50 EDT 2009 --

That depends on the CPU. Some CPUs have quite expensive interrupt disablement instructions. FRV does for instance; but fortunately, on the FRV, I can use some of the excessive quantities of conditional registers to pretend that I In some cases, it's actually the best way. On a UP machine, for instance, where they reduce to nothing or where your only atomic instruction is an XCHG equivalent. David --

This is an error.. I should be exporting this in ms. Will send out a patchset with the change once I also address you other comments in a --

Ok. I do understand the motivation for keeping the request related info out of blk-cgroup. Everything except the rq->cmd_flags can be easily done away with. Maybe I'll need to have CFQ send the sync and direction bits as args to the functions that need it. Not ideal coz I would want to avoid calls like these from CFQ into the blkcg code because many CFQ events trigger update for multiple stats (you'll see more with stats in later patchsets) and doing these calls independently for each stat ...

I agree. However we made it to release_one_tty with pids we need to free them, before we free the tty structure itself. My general paranoia would suggest setting the pids to NULL. So that we don't have the chance of a use after free. Eric --

Jeff, this implication looks strange. IMHO Viro's patch just pins this in the cache for mount session, while after your "cleanup" everyone can walk here (including non-privileged users) and do what they want. Um? --

We very definitely need to keep buddies cache affine. Yes, maybe some additional logic is needed, as there is a conflict between load types. A kbuild spreading to the four winds is fine, while netperf jabbering Whoa. It was a simple question, no need to get defensive. You need not provide anything. Forget I even asked, it's not my decision. -Mike --

Return -EINVAL if we don't find the control id. Signed-off-by: Dan Carpenter <error27@gmail.com> diff --git a/drivers/media/video/cx231xx/cx231xx-video.c b/drivers/media/video/cx231xx/cx231xx-video.c index d4f546f..5a74ef8 100644 --- a/drivers/media/video/cx231xx/cx231xx-video.c +++ b/drivers/media/video/cx231xx/cx231xx-video.c @@ -1901,9 +1901,12 @@ static int radio_queryctrl(struct file *file, void *priv, if (c->id < V4L2_CID_BASE || c->id >= V4L2_CID_LASTP1) return -EINVAL; if ...

Return -EINVAL if we don't find the right query control id. Signed-off-by: Dan Carpenter <error27@gmail.com> diff --git a/drivers/media/video/cx88/cx88-video.c b/drivers/media/video/cx88/cx88-video.c index 48c450f..b4c80cb 100644 --- a/drivers/media/video/cx88/cx88-video.c +++ b/drivers/media/video/cx88/cx88-video.c @@ -1537,9 +1537,12 @@ static int radio_queryctrl (struct file *file, void *priv, c->id >= V4L2_CID_LASTP1) return -EINVAL; if (c->id == V4L2_CID_AUDIO_MUTE) { - for ...

Looks good to me. Thanks! Reviewed-by: Wu Fengguang <fengguang.wu@intel.com> --

How large is it? For random reads > read_ahead_kb, ondemand_readahead() will break it into read_ahead_kb sized IOs, while 4kb reads hit the disk (on POSIX_FADV_RANDOM)? That sounds like behavior in pre .34 kernels that is fixed by commit 0141450f66c: I think Yes. When the above block is gone, ondemand_readahead() will be invoked, and the readahead heuristic will find that it's an oversize read (whose size is > 128k) and start 128kb readahead for it. Thanks, --

Perhaps. I generate the tarballs directly from the git.kernel.org trees, so the data is there otherwise the tarballs would not have been created. Does it show up now? Which tree are you looking at? thanks, greg k-h --

I agree, there should not be a difference here for KVM vs. the "normal" version. thanks, greg k-h --

If the default Kconfig values are used with MTD_PHYSMAP_COMPAT you end up with a resource where end < start. This causes __request_resource to return a conflict which then returns an -EBUSY error code. The current physmap.c code just assumes that the platfom_device_register will always succeed. Catch this failure during the physmap_init and propogate the error. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: David Woodhouse <dwmw2@infradead.org> Reported-by: Randy ...

This fixes sparse noise: error: dubious one-bit signed bitfield Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> Cc: Alexander Viro <viro@zeniv.linux.org.uk> --- diff --git a/fs/fs-writeback.c b/fs/fs-writeback.c index 76fc4d5..a25f491 100644 --- a/fs/fs-writeback.c +++ b/fs/fs-writeback.c @@ -41,9 +41,9 @@ struct wb_writeback_args { long nr_pages; struct super_block *sb; enum writeback_sync_modes sync_mode; - int for_kupdate:1; - int range_cyclic:1; - int ...

Noticed during a sparse build. Signed-off-by: H Hartley Sweeten <hsweeten@visionengravers.com> --- diff --git a/kernel/printk.c b/kernel/printk.c index 75077ad..9abc79c 100644 --- a/kernel/printk.c +++ b/kernel/printk.c @@ -1457,7 +1457,7 @@ int kmsg_dump_unregister(struct kmsg_dumper *dumper) } EXPORT_SYMBOL_GPL(kmsg_dump_unregister); -static const char const *kmsg_reasons[] = { +static const char *kmsg_reasons[] = { [KMSG_DUMP_OOPS] = "oops", [KMSG_DUMP_PANIC] = "panic", ...

I traced this down to kernel/resource.c. When __request_resource is finally called, because of the platform_device_register, it ends up returning a conflict due to: resource_size_t start = new->start; resource_size_t end = new->end; struct resource *tmp, **p; if (end < start) return root; This ends up causing an -EBUSY error code. The patch below should be correct to fix this. I changed the commit message a bit. --- mtd/maps/physmap: catch failure to register ...

Padata must guarantee that even though the work may occur in parallel, anyone submitting work to it in serial must observe the result strictly in the order that they were submitted. Cheers, -- Visit Openswan at http://www.openswan.org/ Email: Herbert Xu ~{PmV>HI~} <herbert@gondor.apana.org.au> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt --

Hello, ----- Original Message ----- From: "Américo Wang" <xiyou.wangcong@gmail.com> To: "Janos Haar" <janos.haar@netcenter.hu> Cc: <linux-kernel@vger.kernel.org>; "KAMEZAWA Hiroyuki" <kamezawa.hiroyu@jp.fujitsu.com>; <linux-mm@kvack.org>; <xfs@oss.sgi.com>; "Jens Axboe" <axboe@kernel.dk> Sent: Thursday, April 01, 2010 12:37 PM Today i have got this again, exactly the same. (if somebody wants the log, just ask) There is a cut: Apr 1 18:50:02 alfa kernel: possible SYN flooding on ...

Thanks for the response. Please do let me know if you have any questions about the kdb patches. I can repost the series with the minor changes and base it off the pending kgdb-fixes pull request. Thanks, Jason. --

The kernel debugger should turn off kernel tracing any time the debugger is active and restore it on resume. Signed-off-by: Jason Wessel <jason.wessel@windriver.com> Reviewed-by: Steven Rostedt <rostedt@goodmis.org> --- kernel/kgdb.c | 8 ++++++++ 1 files changed, 8 insertions(+), 0 deletions(-) diff --git a/kernel/kgdb.c b/kernel/kgdb.c index 7a56dc9..27e7bb5 100644 --- a/kernel/kgdb.c +++ b/kernel/kgdb.c @@ -1365,6 +1365,7 @@ static int kgdb_cpu_enter(struct kgdb_state *ks, struct ...

This is a kgdb architectural change to have all the cpus (master or slave) enter the same function. A cpu that hits an exception (wants to be the master cpu) will call kgdb_handle_exception() from the trap handler and then invoke a kgdb_roundup_cpu() to synchronize the other cpus and bring them into the kgdb_handle_exception() as well. A slave cpu will enter kgdb_handle_exception() from the kgdb_nmicallback() and set the exception state to note that the processor is a slave. Previously ...

So this part might be overkill, but I don't actually have the hardware, schematics or reference manuals to ascertain what is going on. The other changes in this patch should be correct because we really do want Will originally proposed a patch for cpu_relax: http://lists.infradead.org/pipermail/linux-arm-kernel/2010-March/011076.html --- The patch --- +#if __LINUX_ARM_ARCH__ == 6 +#define cpu_relax() smp_mb() +#else #define cpu_relax() barrier() +#endif --- Russell had this ...

It is revised now and pushed. Regression testing on the HW I have has passed as well now. For the series the pull looks like: drivers/misc/kgdbts.c | 6 ++ kernel/kgdb.c | 205 +++++++++++++++++++++++++------------------------ 2 files changed, 109 insertions(+), 102 deletions(-) Thanks, Jason. --- From: Jason Wessel <jason.wessel@windriver.com> Subject: [PATCH] kgdb: use atomic_inc and atomic_dec instead of atomic_set Memory barriers should be used for the kgdb ...

On Fri, Apr 2, 2010 at 8:23 AM, Linus Walleij Thank you. I am working on it full time. This submission was solely as a preview, the code needs to be optimized, polished and tested, though I don't anticipate much changes in the API. By when should I submit the final version? Yes, drivers/dma/pl330.c could be one DMA API driver. Another may implement S3C DMA API and reside in arch/arm/plat-samsung/ or wherever the S3C PL080 driver is atm. So, DMA API driver is the frontend that makes use of ...

On Mon, 29 Mar 2010 19:29:57 +0100 Well I'm not sure such over-engineering would be "grand", but it does seem like overkill for the devices you're covering here. At any rate, the patch is in my linux-next tree, so it'll head to Linus next merge cycle unless some big new objections arise. -- Jesse Barnes, Intel Open Source Technology Center --

The test case was 128kb random reads. So should still be within the normal read_ahead_kb. I suspect the reporter would not have noticed if the issue size was as large as read_ahead_kb even if the request size Could explain why I'm not reproducing when doing a quick test on the laptop. It is an older kernel. So it could be that I'm just imaging the issue on the current kernel, I don't have hard data to back it up on that version. So disregard the patch for now, part-sequential behaviour ...

Thanks Anton, applied. -- Jens Axboe --

Hi, Working on drivers/hwmon/sht15.c, I noticed it would return bogus temperatures in my case, where CONFIG_REGULATOR is not set. This is due to the following section in drivers/hwmon/sht15.c: /* If a regulator is available, query what the supply voltage actually is!*/ data->reg = regulator_get(data->dev, "vcc"); if (!IS_ERR(data->reg)) { ... Looking at consumer.h, it appears that regulator_get() returns a pointer to its second argument when CONFIG_REGULATOR is ...

Hi, I have just hit this problem. Haven't bisected it yet, and going through shortlog doesn't ring any bell immediately, so I am sending this out in case it rings a bell for someone right away. Calling s2disk -r /dev/sdb4 suspends without any issues on 2.6.34-rc2, and resume is also fine. With 2.6.34-rc3 I get s2disk: Could not use the resume device (try swapon -a). Reason: No such device Relevant part of s2disk strace: mount("none", "/proc/2449", "tmpfs", 0, NULL) = ...

[ adding some appropriate CCs ] -- Jiri Kosina SUSE Labs, Novell Inc. --

hi, this patch adds ftrace events for graph tracer, so the graph output could be shared within other tracers. wbr, jirka Signed-off-by: Jiri Olsa <jolsa@redhat.com> --- kernel/trace/trace_functions_graph.c | 28 +++++++++++++++++++++++++++- 1 files changed, 27 insertions(+), 1 deletions(-) diff --git a/kernel/trace/trace_functions_graph.c b/kernel/trace/trace_functions_graph.c index e6989d9..75aa144 100644 --- a/kernel/trace/trace_functions_graph.c +++ ...

hi, when I was using irqsoff tracer, I thought it could be any use to see the disabled IRQs flow output same way as function graph output. The graph output is enabled by setting new 'display-graph' trace option of irqsoff tracer. wbr, jirka Signed-off-by: Jiri Olsa <jolsa@redhat.com> --- include/linux/ftrace.h | 15 ++- kernel/trace/trace.c | 35 +++-- kernel/trace/trace.h | 21 +++ kernel/trace/trace_functions_graph.c | 15 ...

Ok, good to know this fixes the problem. One issue: If the initialization of the domains fails the iommu hardware needs to be disabled again in the free path. Thanks, Joerg --

From: Julia Lawall <julia@diku.dk> dlpar_free_cc_nodes frees its argument, so dlpar_online_cpu should not be called on the same value. Skip over the call to dlpar_online_cpu by jumping directly to out. A simplified version of the semantic patch that finds this problem is as follows: (http://coccinelle.lip6.fr/) // <smpl> @@ expression E,E2; @@ dlpar_free_cc_nodes(E) ... ( E = E2 | * E ) // </smpl> Signed-off-by: Julia Lawall <julia@diku.dk> --- ...

This patch adds support to hwmon:applesmc for the iMac9,1. Without this the default settings for applesmc and iMac are to set the machine to use only nine temperature sensors, with this patch you get all fourteen of them. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- drivers/hwmon/applesmc.c | 9 +++++++++ 1 files changed, 9 insertions(+), 0 deletions(-) diff --git a/drivers/hwmon/applesmc.c b/drivers/hwmon/applesmc.c index c1605b5..6ab3e78 100644 --- ...

On Thu, 1 Apr 2010 18:36:41 +0100 if (rc) newpage->mapping = NULL; else if (safe_to_remap) remove_migrateion_ptes(page, newpage); Is better. Old code cleared newpage->mapping if rc!=0. Thanks, -Kame --

Hi Christopher, Sorry for the delay. Here finally come my comments on your code. I'm only commenting on the i2c side of things. This name is unfortunate. "client data" usually refers to run-time state data of an i2c client. For configuration data, we rather use the This is already included in the i2c client struct itself, so you This is incorrect. What goes in device ID tables is _device_ names, nor _driver_ names. It might be the same string, but you don't want to use You don't ...

Hi Mark, Sorry for playing the devil's advocate here, but deciding that 0V is an error is pretty arbitrary, and deciding that a negative voltage value is an error is just as arbitrary. Just because these are not common cases, doesn't mean they can't happen today or tomorrow for very specific setups. I'd rather see a more robust way to notifier the OK, I get it. This indeed rules out ERR_PTR(-ENODEV). But what about NULL? IS_ERR() doesn't catch NULL, so this wouldn't affect the ...

Applied, thanks. --

Ok, will queue the new ones. Thanks, --

I think your attached two patches are perfectly unrelated your problem. "mm: Add min_free_order_shift tunable." seems makes zero sense. I don't think this patch need to be merge. but "mm: Check if any page in a pageblock is reserved before marking it MIGRATE_RESERVE" treat strange hardware correctly, I think. If Mel ack this, I hope merge it. --

Very nice, thank you. Acked-by: Lai Jiangshan <laijs@cn.fujitsu.com> --

`make CONFIG_NILFS2_FS=m M=fs/nilfs2/` will give the following warnings: fs/nilfs2/btree.c: In function ‘nilfs_btree_propagate’: fs/nilfs2/btree.c:1882: warning: ‘maxlevel’ may be used uninitialized in this function fs/nilfs2/btree.c:1882: note: ‘maxlevel’ was declared here Set maxlevel = 0 to fix it. Signed-off-by: Li Hong <lihong.hi@gmail.com> --- fs/nilfs2/btree.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c index ...

nilfs_btree_release_path() and nilfs_btree_free_path() are bound into each other tightly. Make them into one procedure to clearify the logic and avoid some misusages. Signed-off-by: Li Hong <lihong.hi@gmail.com> --- fs/nilfs2/btree.c | 22 +++++----------------- 1 files changed, 5 insertions(+), 17 deletions(-) diff --git a/fs/nilfs2/btree.c b/fs/nilfs2/btree.c index bb31ab3..fa4b123 100644 --- a/fs/nilfs2/btree.c +++ b/fs/nilfs2/btree.c @@ -93,18 +93,14 @@ out: return path; } ...

I fixed the reported checkpatch.pl problems except for a bunch of long lines and some printk:s. I also removed versioning comments. Signed-off-by: Lars Lindley <lindley@coyote.org> --- drivers/staging/winbond/wbusb.c | 187 +++++++++++++++++--------------------- 1 files changed, 84 insertions(+), 103 deletions(-) diff --git a/drivers/staging/winbond/wbusb.c b/drivers/staging/winbond/wbusb.c index 3482eec..d7694e6 100644 --- a/drivers/staging/winbond/wbusb.c +++ ...

Thanks, I'll try it. But I doubt that it will fix the problem. There were no changes in hibernate_asm_32.S between 2.6.30 and 2.6.31. -- Ondrej Zary --

Commit-ID: 4bdde044dc36ac7b01f7502394d52619af9d1927 Gitweb: http://git.kernel.org/tip/4bdde044dc36ac7b01f7502394d52619af9d1927 Author: Li Zefan <lizf@cn.fujitsu.com> AuthorDate: Wed, 24 Mar 2010 10:58:05 +0800 Committer: Steven Rostedt <rostedt@goodmis.org> CommitDate: Wed, 31 Mar 2010 22:56:54 -0400 tracing: Convert some signal events to DEFINE_TRACE Use DECLARE_EVENT_CLASS to remove duplicate code: text data bss dec hex filename 23639 6084 8 29731 ...

Commit-ID: ae832d1e03ac9bf09fb8a07fb37908ab40c7cd0e Gitweb: http://git.kernel.org/tip/ae832d1e03ac9bf09fb8a07fb37908ab40c7cd0e Author: Li Zefan <lizf@cn.fujitsu.com> AuthorDate: Wed, 24 Mar 2010 10:57:43 +0800 Committer: Steven Rostedt <rostedt@goodmis.org> CommitDate: Wed, 31 Mar 2010 22:56:58 -0400 tracing: Remove side effect from module tracepoints that caused a GPF Remove the @refcnt argument, because it has side-effects, and arguments with side-effects are not skipped by the ...

Commit-ID: 25c2d55c00c6097e6792ebf21e31342f23b9b768 Gitweb: http://git.kernel.org/tip/25c2d55c00c6097e6792ebf21e31342f23b9b768 Author: Li Zefan <lizf@cn.fujitsu.com> AuthorDate: Wed, 24 Mar 2010 13:17:50 +0800 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:01 +0200 sched: Remove USER_SCHED from documentation USER_SCHED has been removed, so update the documentation accordingly. Signed-off-by: Li Zefan <lizf@cn.fujitsu.com> Signed-off-by: Peter Zijlstra ...

That's right. I should be able to get rid of a cmov, which kind of counts as two instructions in EV6 scheduling. So I should send a patch to reduce this to the first 100 (128) bits? Thanks guys, Matt --

It is no coincidence that the 802.11 subsystem now has had no regressions for 2.6.33 and 2.6.34 (thanks to Rafael for keeping track of these). I don't think its that we haven't been doing a lot of development, instead I think a lot of it has to do with the fact that we have been aggressively engaged with stable after we were slapped about this at our last wireless summit. There's a few patches which I realize still do fall through the crack or due to time we haven't yet backported. I have been ...

True, it can't in itself but it is a bug to free a locked page. As PageAnon is cleared by the page allocator (see comments in page_remove_rmap) and we have taken a reference to this page when isolating for migration, I still Sure. Thanks -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Seems reasonable. This will be checked on every major loop in the This is a lot less clear. GFP_NOFAIL is rare so this is basically saying that all threads with a fatal signal pending can ignore watermarks. This is dangerous because if 1000 threads get killed, there is a possibility of deadlocking the system. Why not obey the watermarks and just not retry the loop later and fail I'm ok with the should_alloc_retry() change but am a lot less ok with ignoring watermarks just because a ...

rmap_walk_anon() was triggering errors in memory compaction that look like use-after-free errors. The problem is that between the page being isolated from the LRU and rcu_read_lock() being taken, the mapcount of the page dropped to 0 and the anon_vma gets freed. This can happen during memory compaction if pages being migrated belong to a process that exits before migration completes. Hence, the use-after-free race looks like 1. Page isolated for migration 2. Process exits 3. ...

This patch is the core of a mechanism which compacts memory in a zone by relocating movable pages towards the end of the zone. A single compaction run involves a migration scanner and a free scanner. Both scanners operate on pageblock-sized areas in the zone. The migration scanner starts at the bottom of the zone and searches for all movable pages within each area, isolating them onto a private list called migratelist. The free scanner starts at the top of the zone and searches for ...

Fragmentation index is a value that makes sense when an allocation of a given size would fail. The index indicates whether an allocation failure is due to a lack of memory (values towards 0) or due to external fragmentation (value towards 1). For the most part, the huge page size will be the size of interest but not necessarily so it is exported on a per-order and per-zone basis via /proc/extfrag_index Signed-off-by: Mel Gorman <mel@csn.ul.ie> Reviewed-by: Minchan Kim ...

Unusable free space index is a measure of external fragmentation that takes the allocation size into account. For the most part, the huge page size will be the size of interest but not necessarily so it is exported on a per-order and per-zone basis via /proc/unusable_index. The index is a value between 0 and 1. It can be expressed as a percentage by multiplying by 100 as documented in Documentation/filesystems/proc.txt. Signed-off-by: Mel Gorman <mel@csn.ul.ie> Reviewed-by: Minchan Kim ...

For clarity of review, KSM and page migration have separate refcounts on the anon_vma. While clear, this is a waste of memory. This patch gets KSM and page migration to share their toys in a spirit of harmony. Signed-off-by: Mel Gorman <mel@csn.ul.ie> Reviewed-by: Minchan Kim <minchan.kim@gmail.com> Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> Reviewed-by: Christoph Lameter <cl@linux-foundation.org> Reviewed-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- ...

Ordinarily when a high-order allocation fails, direct reclaim is entered to free pages to satisfy the allocation. With this patch, it is determined if an allocation failed due to external fragmentation instead of low memory and if so, the calling process will compact until a suitable page is freed. Compaction by moving pages in memory is considerably cheaper than paging out to disk and works where there are locked pages or no swap. If compaction fails to free a page of a suitable size, then ...

The fragmentation index may indicate that a failure is due to external fragmentation but after a compaction run completes, it is still possible for an allocation to fail. There are two obvious reasons as to why o Page migration cannot move all pages so fragmentation remains o A suitable page may exist but watermarks are not met In the event of compaction followed by an allocation failure, this patch defers further compaction in the zone for a period of time. The zone that is deferred is ...

Hi Ingo, Before introducing new patches, I'd like to push some bugfixes. (I'll update previous series and post again.) Thank you, --- Masami Hiramatsu (4): [BUGFIX][RESEND] perf probe: Fix to close dwarf when failing to analyze it [BUGFIX] perf probe: Correct error message for non-structure type [BUGFIX] perf probe: Fix not to return non-matched file [BUGFIX] perf probe: Fix --line syntax help and document tools/perf/Documentation/perf-probe.txt | 2 +- ...

Fix cu_find_realpath() not to return the last file path if that is not matched to input pattern. Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> --- tools/perf/util/probe-finder.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff ...

Fix to close libdw routine when failing to analyze it in find_perf_probe_point(). Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> Cc: Ingo Molnar <mingo@elte.hu> Cc: Paul Mackerras <paulus@samba.org> Cc: Arnaldo Carvalho de Melo <acme@redhat.com> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Mike Galbraith <efault@gmx.de> Cc: Frederic Weisbecker <fweisbec@gmail.com> --- tools/perf/util/probe-finder.c | 6 ++++-- 1 files changed, 4 insertions(+), 2 deletions(-) diff --git ...

Commit-ID: 085ea739adf107b5a5d131f3625e517ff4a5181e Gitweb: http://git.kernel.org/tip/085ea739adf107b5a5d131f3625e517ff4a5181e Author: Masami Hiramatsu <mhiramat@redhat.com> AuthorDate: Fri, 2 Apr 2010 12:50:39 -0400 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:35:42 +0200 perf probe: Fix --line syntax help and document Just fix typos. --line option accepts ':START-END' syntax, not ':START:END'. Signed-off-by: Masami Hiramatsu <mhiramat@redhat.com> Cc: ...

Commit-ID: 12e5a7ae475ccb2733d740ffb95d9ca0a18392da Gitweb: http://git.kernel.org/tip/12e5a7ae475ccb2733d740ffb95d9ca0a18392da Author: Masami Hiramatsu <mhiramat@redhat.com> AuthorDate: Fri, 2 Apr 2010 12:50:53 -0400 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:35:43 +0200 perf probe: Correct error message for non-structure type perf probe outputs incorrect error message when it is called with non-existent field on a non-data structure local ...

It's not enough. There are normal caller. I expected some bogus driver of out-of-mainline uses page directly without enough review. Is your kernel working well except this bug? Do you see same oops call trace(about page-allocator) whenever kernel panic happens? I mean if something not page-allocadtor breaks memory, you can see other symptoms. so we can doubt others(H/W, other subsystem). -- Kind regards, Minchan Kim --

page lock can't prevent anon_vma free. I like this. Kame. How about your opinion? How about changing comment? "In this case, swapcache page still " Also, I want to change "safe_to_remap" to "remap_swapcache". I think it's just problem related to swapcache page. So I want to represent it explicitly although we can know it's swapcache by code. -- Kind regards, Minchan Kim --

Instead of adding yet another ugly #ifdef please hide these details properly, by making enable_IR_x2apic() and default_setup_apic_routing() a NOP on !SMP. Thanks, Ingo --

Sure, why not, every instruction counts :-) Note, if you do it then please also include a disassembly of the area that changed, so that we document the effect. Ingo --

Ok, fair enough, i'll queue up this fix. The best structure would be to integrate these init details into the APIC driver methods and make UP-IOAPIC nothing particularly special. Thanks, Ingo --

just wondering, is the boot crash related to the earlier version of this patch fixed in this version? If yes, what was the root cause? Thanks, Ingo --

No. What i mean is that with your patch, a debugging session would go like this: < kernel crashes > # reboot #1 < admin logs in and scratches head > < admin consults kernel hackers and enables lbr_debug=1 in /etc/grub.conf > < admin reboots > # reboot #2 < kernel crashes again > # reboot #3 With the sysctl we'd have one reboot less: < kernel crashes > # reboot ...

Hi. The updates aren't available on git.kernel.org yet. Something wrong with the mirroring perhaps? Regards, Nigel --

I'll test this out this weekend, thanks Chris! --

1. To support instantaneous report for SCSU device change by periodic polling 2. In arcmsr_iop_xfer(), inform AP of F/W's deadlock state to prevent endless waiting 3. To block the coming SCSI command while the driver is handling bus reset 4. To support HW reset in bus reset error handler Signed-off-by: Nick Cheng< nick.cheng@areca.com.tw > --- diff -Naurp --ignore-blank-lines --ignore-all-space --ignore-space-change arcmsr/arcmsr_attr.c arcmsr.1.20.00.15-81103/arcmsr_attr.c --- ...

That's what I thought, *if* the attackers can inject crafted Ethernet frames onto your local network. (i.e., they need a crafted Ethernet frame, not just crafted packet contents.) --

I am sorry, I forgot it needs Reported-by: Catalin Marinas <catalin.marinas@arm.com> --

In this case, I don't think this is needed. We are doing free_tty_struct()->kfree(tty) right after put_pid()s, nobody can use these pointers or we have another bug. Most probably this patch is correct (but perhaps it is not the best fix). Every time tty does put_pid() it should also clear the pointer. But I am not sure I grepped enough. Oleg. --

Yes, probably we can free them earlier. But I am very nervous about this change, I tried to defer put_pid() as much as possible, in case something else uses ->prgp/session before free_tty_struct(). Oleg. --

release_one_tty(tty) can be called when tty still has a reference to pgrp/session. In this case we leak the pid. The patch needs the ack from someone who understand tty magic. Signed-off-by: Oleg Nesterov <oleg@redhat.com> --- drivers/char/tty_io.c | 2 ++ 1 file changed, 2 insertions(+) --- TTT/drivers/char/tty_io.c~TTY_PID_LEAK 2010-03-17 16:00:59.000000000 +0100 +++ TTT/drivers/char/tty_io.c 2010-04-02 17:23:07.000000000 +0200 @@ -1423,6 +1423,8 @@ static void ...

So. Please see the COMPLETELY UNTESTED patches I am sending. They need your review, or feel free to redo these fixes. 4/4 is a bit off-topic. Also, please note the "This patch is not enough" comment in 3/4. Oleg. --

select_bad_process() checks PF_EXITING to detect the task which is going to release its memory, but the logic is very wrong. - a single process P with the dead group leader disables select_bad_process() completely, it will always return ERR_PTR() while P can live forever - if the PF_EXITING task has already released its ->mm it doesn't make sense to expect it is goiing to free more memory (except task_struct/etc) Change the code to ignore the PF_EXITING tasks without ...

It doesn't make sense to call thread_group_cputime() under task_lock(), we can drop this lock right after we read get_mm_rss() and save the value in the local variable. Note: probably it makes more sense to use sum_exec_runtime instead of utime + stime, it is much more precise. A task can eat a lot of CPU time, but its Xtime can be zero. Signed-off-by: Oleg Nesterov <oleg@redhat.com> --- mm/oom_kill.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) --- ...

then "|| !chosen" can be killed. with this patch !chosen <=> !*ppoints, and since points > 0 if (points > *ppoints) { is enough. Oleg. --

Commit-ID: 897f0b3c3ff40b443c84e271bef19bd6ae885195 Gitweb: http://git.kernel.org/tip/897f0b3c3ff40b443c84e271bef19bd6ae885195 Author: Oleg Nesterov <oleg@redhat.com> AuthorDate: Mon, 15 Mar 2010 10:10:03 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:01 +0200 sched: Kill the broken and deadlockable cpuset_lock/cpuset_cpus_allowed_locked code This patch just states the fact the cpusets/cpuhotplug interaction is broken and removes the deadlockable ...

Commit-ID: c1804d547dc098363443667609c272d1e4d15ee8 Gitweb: http://git.kernel.org/tip/c1804d547dc098363443667609c272d1e4d15ee8 Author: Oleg Nesterov <oleg@redhat.com> AuthorDate: Mon, 15 Mar 2010 10:10:14 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:02 +0200 sched: move_task_off_dead_cpu(): Remove retry logic The previous patch preserved the retry logic, but it looks unneeded. __migrate_task() can only fail if we raced with migration after we ...

Commit-ID: 6a1bdc1b577ebcb65f6603c57f8347309bc4ab13 Gitweb: http://git.kernel.org/tip/6a1bdc1b577ebcb65f6603c57f8347309bc4ab13 Author: Oleg Nesterov <oleg@redhat.com> AuthorDate: Mon, 15 Mar 2010 10:10:23 +0100 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 20:12:03 +0200 sched: _cpu_down(): Don't play with current->cpus_allowed _cpu_down() changes the current task's affinity and then recovers it at the end. The problems are well known: we can't restore ...

It seems that the problem does not reproduce at all now. Unfortunately I do not have the images I have built on 2010-03-29 08:46 and building from a fresh ae6be51ed01d6c4aaf249a207b4434bc7785853b does not reproduce the problem. It is most likely the specific .config I used at the time (which I do not have anymore). Also I have been doing other builds on the same system, so maybe it was just a stale module or smth. FWIW the problem does not reproduce with 2.6.34-rc3 at all too (on the very ...

Apologies, my question was unclear. I was asking how you test patches to RCU in general, not thing in particular. OK, so if no rcutorture, then I wonder where the extra-long RCU read-side What you measured is what you measured, don't get me wrong. I am just wondering how 10% of the scheduling-clock interrupts managed to hit RCU read-side critical sections. OK. If you were running CONFIG_TREE_RCU, and if 10% of the execution time was in preemption-disabled regions in the kernel, ...

The fact that it can be done in kernel -- anything can -- but whether it should. I'd very much like to keep the 'crazy stuff' in userspace. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

stable? I'd say thats way too intrusive for -stable... -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

Applied, thanks! --

The problem with all this per-cpu loadavg is that it would require a steady tick on each cpu to age this loadavg, which is quite in contradiction with power savings as they rather like the nohz feature. No idea yet on what to do about that. --

On Thu, 1 Apr 2010 14:46:14 -0700 Quite. The hardware I had at my disposal only supported 32-bit descriptors and I didn't want to write code that I had no way of The only performance impact that might occur is if you try to transfer to/from an address above 4 GiB, at which point you need a bounce buffer and an extra memory copy. (I believe the kernel does this by default if the driver doesn't It's been quite some time since I looked at the driver, but I seem to recall that adding 64-bit ...

2.6.34-rc2 kernel: Boot up on a common PC, then: modprobe physmap ; rmmod physmap and bang. [ 127.836202] calling init_mtd+0x0/0x88 [mtd] @ 3566 [ 127.841742] initcall init_mtd+0x0/0x88 [mtd] returned 0 after 514 usecs [ 127.863465] calling physmap_init+0x0/0x49 [physmap] @ 3566 [ 127.869454] physmap-flash.0: failed to claim resource 0 [ 127.874760] initcall physmap_init+0x0/0x49 [physmap] returned 0 after 5450 usecs [ 150.353495] BUG: unable to handle kernel NULL pointer dereference ...

Looks good to me. Thanks. --- ~Randy --

Acked-by: David Rientjes <rientjes@google.com> --

I'm not ignoring your arguments, I think you're ignoring what I'm responding to. I prefer to keep oom_badness() to be a positive range as it always has been (and /proc/pid/oom_score has always used an unsigned qualifier), so I disagree that we need to change oom_badness() to return anything other than 0 for such tasks. We need to filter them explicitly in select_bad_process() instead, so please do this there. --

Just have it return 0, meaning never kill, and then ensure "chosen" is never set for an oom_badness() of 0, even if we don't have another task to kill. That's how Documentation/filesystems/proc.txt describes it anyway. --

Commit-ID: 51591e31dcb3716f03f962e26ec36a029aa46340 Gitweb: http://git.kernel.org/tip/51591e31dcb3716f03f962e26ec36a029aa46340 Author: David Rientjes <rientjes@google.com> AuthorDate: Thu, 25 Mar 2010 15:39:27 -0700 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:09:31 +0200 x86: Increase CONFIG_NODES_SHIFT max to 10 Some larger systems require more than 512 nodes, so increase the maximum CONFIG_NODES_SHIFT to 10 for a new max of 1024 nodes. This was tested ...

Thanks. Please also send the contents of /proc/acpi/wakeup. Rafael --

The change that exposed this issue was elsewhere in the x86 arch code. I don't know where exactly, but we surely didn't need the above patch before. Rafael --

It seems that swap_type_of() returns error code for your swap device. I'd put a couple of debug printks in there to see what happens. Rafael --

Commit-ID: a098f4484bc7dae23f5b62360954007b99b64600 Gitweb: http://git.kernel.org/tip/a098f4484bc7dae23f5b62360954007b99b64600 Author: Robert Richter <robert.richter@amd.com> AuthorDate: Tue, 30 Mar 2010 11:28:21 +0200 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 2 Apr 2010 19:52:03 +0200 perf, x86: implement ARCH_PERFMON_EVENTSEL bit masks ARCH_PERFMON_EVENTSEL bit masks are often used in the kernel. This patch adds macros for the bit masks and removes local defines. ...

With 2.6.34-rc3 boot on a Power5 box : loop: module loaded BUG: key 6b6b6b6b6b6b6b6b not in .data! ------------[ cut here ]------------ Badness at kernel/lockdep.c:2706 NIP: c00000000010a0a8 LR: c00000000010a08c CTR: c0000000000704a4 REGS: c0000001096d76f0 TRAP: 0700 Not tainted (2.6.34-rc3) MSR: 8000000000029032 <EE,ME,CE,IR,DR> CR: 28000082 XER: 00000009 TASK = c0000001fa6f8000[1] 'swapper' THREAD: c0000001096d4000 CPU: 12 GPR00: 0000000000000000 c0000001096d7970 c000000001322e38 ...

Hi Todd, Mark's review is fairly complete. Please address his concerns, and I'll merge this patchset. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Hi Mark, Patch applied to my for-linus branch, thanks. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Hi Tejun, The davinci MFD driver is sitting in Mark's tree, so I guess he should take this patch. Mark, feel free to add my: Acked-by: Samuel Ortiz <sameo@linux.intel.com> to this patch. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Hi Dan, Patch applied, many thanks. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Even we revert the commit, the patch still has its benefit, as it increases calculation precision, right? Thanks, Shaohua --

On Fri, 2 Apr 2010 15:30:10 +0800 How do you deal with the DoS problem of hostile user space app posting huge number of receives and never getting anything. --

The crash was related to "[PATCH 3/4] [tip:x86/mm] NX protection for kernel data" and is fixed by "[PATCH 1/4] [tip:x86/mm] Correcting improper large page preservation". The root cause was improper large page split handling in try_preserve_large_page(): in some circumstances it would erroneously preserve large page and apply incompatible page attributes to the memory area outside of the original "change attribute" request. The crash we found was triggered as follows: 1. kernel is mapped with ...

What is the advantage of this approach compared to PCI-passthrough of the host NIC to the guest? Does this require pinning of the entire guest memory? Or only the send/receive buffers? Thanks --

The ohci_ prefix is only used in function names of fw_card_driver hooks. There are two exceptions which I carelessly added. Signed-off-by: Stefan Richter <stefanr@s5r6.in-berlin.de> --- drivers/firewire/ohci.c | 18 +++++++++--------- 1 file changed, 9 insertions(+), 9 deletions(-) Index: b/drivers/firewire/ohci.c =================================================================== --- a/drivers/firewire/ohci.c +++ b/drivers/firewire/ohci.c @@ -2299,7 +2299,7 @@ static const struct ...

Yes, wait_for_completion() is probably the better way to do the The try-again loop it to handle a corner case that appears with the trylock. Well, the idea behind that was to maintain a cpumask the user wishes to use for parallelization. The cpumask that is actually used, is the logical and between user's cpumask and the cpu_active_mask. The reason for maintaining such a cpumask was to keep the user supplied cpumask untouched on hotplug events. If a cpu goes down and then up again ...

Mike, Apart from this small tweak that you added in wake_up() path there is no extra logic that keeps buddies together for long. As I was saying, fork/exec balance starts apart and in the partial loaded case (i.e., when # of running tasks <= # of sockets or # of total cores) the default load balancer policy also tries to distribute the load equally among sockets/cores (for peak cache/memory controller bw etc). While the wakeup() may keep the buddies on SMT siblings, next load balancing ...

Jan responded to me in private that this was indeed an initrd issue and this patch is working fine to him. Thomas/Peter/Ingo: please consider this patch for urgent tree. thanks, suresh --

Okay. I will get this info out to the list Monday. Briefly, I'm using identical hardware (server), identical NICs, same drivers, connected to same switch, and using udpping, hackbench, and an internall written app to test latency. Without exception the evolution has looked like the following. 2.6.16.60 latencies for system and network are fast. Meaning hackbench and udpping win, and win by quite a bit. 2.6.27.19 was awful. 2.6.32.1 and 2.6.331. were better for networking (with some ...

2 patches related to page_alloc.c were applied. Does anyone see a connection between the 2 patches and the panic? NOTE: the full patches are attached. diff --git a/mm/page_alloc.c b/mm/page_alloc.c index a596bfd..34a29e2 100644 --- a/mm/page_alloc.c +++ b/mm/page_alloc.c @@ -2551,6 +2551,20 @@ static inline unsigned long wait_table_bits(unsigned long size) #define LONG_ALIGN(x) (((x)+(sizeof(long))-1)&~((sizeof(long))-1)) /* + * Check if a pageblock contains reserved pages + ...

Hi, kamezawa hiroyu Thanks for the hint! Hi, Minchan Kim Sorry. Not exactly sure your idea about <grep "page handling">. Below is a result of $ grep -n -r "list_del(&page->lru)" * in our src ...

So we better let the possible stack overruns unaddressed ? Thanks, tglx --

Hello, Ingo. Can you please pull from the following git tree into sched/core to receive cpuhog patches? git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git cpuhog Both sched/core and the patches remained the same from the second take[2]. Rusty Russell acked stop_machine changes and Oleg likes the changes. Peter agrees with the mechanics but is unhappy with the naming and suggests using stop_cpu/machine() names instead. Currently, visible API is * hog_one_cpu() * ...

This is the second posting of the TPS6507x driver set. I have incorporated Mark Brown's feedback and retested. Patches 3 and 5 have been combined so there are only 4 patches in the series now. The TPS6507x family of Texas Instruments power management ICs (pmic) are multi-function chips that include voltage regulation and touch screen controller capabilities. This patch set adds a TPS6507x multi-function device driver and change the TPS6507x regulator driver to use the TPS6507x MFD driver ...

Other sub-drivers for the TPS6507x chip will need to use register definition so move it out of the source file and into a header file. Signed-off-by: Todd Fischer <todd.fischer@ridgerun.com> --- drivers/regulator/tps6507x-regulator.c | 60 +-------------- include/linux/mfd/tps6507x.h | 134 ++++++++++++++++++++++++++++++++ 2 files changed, 135 insertions(+), 59 deletions(-) create mode 100644 include/linux/mfd/tps6507x.h diff --git a/drivers/regulator/tps6507x-regulator.c ...

Move from using tps or tsp6507x to tps6057x_pmic in a consistent manner. Signed-off-by: Todd Fischer <todd.fischer@ridgerun.com> --- drivers/regulator/tps6507x-regulator.c | 172 ++++++++++++++++---------------- 1 files changed, 87 insertions(+), 85 deletions(-) diff --git a/drivers/regulator/tps6507x-regulator.c b/drivers/regulator/tps6507x-regulator.c index becf652..86f2e05 100644 --- a/drivers/regulator/tps6507x-regulator.c +++ b/drivers/regulator/tps6507x-regulator.c @@ -103,7 +103,7 ...

I think this is likely due to the new scalable anon_vma linking by Rik. Nothing else I can imagine should have introduced anything like it. Rik: the picures have the information, but you need to look at several to see both the oops and the backtrace. Here's a condensed version: shrink_all_memory -> do_try_to_free_pages -> shrink_zone -> shrink_inactive_list -> shrink_page_list -> page_referenced where page_referenced() oopses due ...

I always agreed that it was not a memory barrier. In fact, the commit that extended on the "volatile-considered-harmful" patch from you has this quote from me in the commit logs: Linus sayeth: : I don't think it was ever the intention that it would be seen as anything : but a compiler barrier, although it is obviously implied that it might : well perform some per-architecture actions that have "memory barrier-like" : semantics. : : After all, the ...

Hmm. Isn't this missing a From: Clemens Ladisch <clemens@ladisch.de> too? Or was the original patch yours? Linus --

Hmm. Maybe we should have cleared this in tty_release() already. We already do some of the session clearing there (but we clear the session in the _tasks_ associated with the tty, not the tty session pointer). I think the patch is simpler than worrying about the much more complex release logic. So I think I actually prefer this patch over something that tries to be clever in tty_release. We might even push it into "free_tty_struct()", although I think that the only ...

Russell is wrong. Yes, originally it was about P4's overheating. But let me repeat: the fact is, this _is_ valid kernel code: kernel/sched.c- while (task_is_waking(p)) kernel/sched.c: cpu_relax(); (where that "task_is_waking()" is simply doing two regular reads, and expects another CPU to be changing them). This has _nothing_ to do with memory barriers, or with overheating. The fact that maybe some ARM6 cache coherency implementation is pure and utter sh*t and never ...

Yeah, this patch I have no issues with. Now your changelog makes no sense any more. Linus --

This is a fix to the signed/unsigned field handling in the Python scripting engine, based on a patch from Roel Kluin. Basically, Python wants to use a PyInt (which is internally a long) if it can i.e. if the value will fit into that type. If not, it stores it into a PyLong, which isn't actually a long, but an arbitrary-precision integer variable. The code below is similar to to what Python does internally, and it seems to work as expected on the x86 and x86_64 sytems I tested it ...

Adds special treatment for stdin - if the user specifies '-i -' to perf trace, the intent is that the event stream be read from stdin rather than from a disk file. The actual handling of the '-' filename is done by the session; this just adds a signal handler to stop reporting, and turns off interference by the pager. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> --- tools/perf/builtin-trace.c | 12 +++++++++++- 1 files changed, 11 insertions(+), 1 deletions(-) diff --git ...

Adds special treatment for stdout - if the user specifies '-o -' to perf record, the intent is that the event stream be written to stdout rather than to a disk file. Also, redirect stdout of forked child to stderr - in pipe mode, stdout of the forked child interferes with the stdout perf stream, so redirect it to stderr where it can still be seen but won't be mixed in with the perf output. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> --- tools/perf/builtin-record.c | 18 ...

Bypasses the attr perf header code and replaces it with a synthesized event and processing function that accomplishes the same thing, used when reading/writing perf data to/from a pipe. Making the attrs into events allows them to be streamed over a pipe along with the rest of the header data (in later patches). It also paves the way to allowing events to be added and removed from perf sessions dynamically. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> --- tools/perf/builtin-record.c | ...

Currently, live mode is invoked by explicitly invoking the record and report sides and connecting them with a pipe e.g. $ perf trace record rwtop -o - | perf trace report rwtop 5 -i - In terms of usability, it's not that bad, but it does require the user to type and remember more than necessary. This patch allows the user to accomplish the same thing without specifying the separate record/report steps or the pipe. So the same command as above can be accomplished more simply as: $ perf ...

A couple of scripts, one in Python and the other in Perl, that demonstrate 'live mode' tracing. For each, the output of the perf event stream is fed continuously to the script, which continuously aggregates the data and reports the current results every 3 seconds, or at the optionally specified interval. After the current results are displayed, the aggregations are cleared and the cycle begins anew. To run the scripts, simply pipe the output of the 'perf trace record' step as input to the ...

Bypasses the event type perf header code and replaces it with a synthesized event and processing function that accomplishes the same thing, used when reading/writing perf data to/from a pipe. Signed-off-by: Tom Zanussi <tzanussi@gmail.com> --- tools/perf/builtin-record.c | 7 +++++ tools/perf/builtin-report.c | 1 + tools/perf/builtin-trace.c | 1 + tools/perf/util/event.h | 14 +++++++++ tools/perf/util/header.c | 62 ++++++++++++++++++++++++++++++++++++++----- ...

Ok, so now we do enable_iommu() before we attach devices and flush DTE and domain PDE, IO TLB. That makes sense. Following is just for my education purposes. Trying to understand better the impact of in-flight DMAs. So IIUC, in kudmp context following seems to be sequence of events. 1. kernel crashes, we leave IOMMU enabled. 2. boot into capture kernel and we call enable_iommus(). This function first disables iommu, sets up new device table and enables iommus again. a. So during ...

Hi Divyesh, Can we have any request based information limited to cfq and not put that in blkio-cgroup. The reason being that I am expecting that some kind of max bw policy interface will not necessarily be implemented at CFQ level. We might have to implement it at higher level so that it can work with all dm/md devices. If that's the case, then it might very well be either a bio based interface also. So just keeping that possibility in mind, can we keep blk-cgroup as generic as possible ...

Made necessary by 6992f5334995af474c2b58d010d08bc597f0f2fe. Prevents further "key xxx not in .data" bug-reports. Although some attributes could probably be converted to static ones, this is left for people having hardware to test. Found by this semantic patch: @ init @ type T; identifier A; @@ T { ... struct device_attribute A; ... }; @ main extends init @ expression E; statement S; identifier err; T *name; @@ ...

The idea is simple, just to pin the guest VM user space and then let host NIC driver has the chance to directly DMA to it. The patches are based on vhost-net backend driver. We add a device which provides proto_ops as sendmsg/recvmsg to vhost-net to send/recv directly to/from the NIC driver. KVM guest who use the vhost-net backend may bind any ethX interface in the host side to get copyless data transfer thru guest virtio-net frontend. The scenario is like this: The guest virtio-net driver ...

From: Xin Xiaohui <xiaohui.xin@intel.com> The vhost-net backend now only supports synchronous send/recv operations. The patch provides multiple submits and asynchronous notifications. This is needed for zero-copy case. Signed-off-by: Xin Xiaohui <xiaohui.xin@intel.com> --- drivers/vhost/net.c | 189 +++++++++++++++++++++++++++++++++++++++++++++++-- drivers/vhost/vhost.h | 10 +++ 2 files changed, 192 insertions(+), 7 deletions(-) diff --git a/drivers/vhost/net.c ...

elv is defined as char elv[ELV_NAME_MAX + strlen("-iosched")]; so if name length > sizeof(elv), the name length must already bigger than ELV_NAME_MAX elevator_get is used in elevator_init, so if elevator_init is passing a super long name, why not just return -EINVAL? In this patch, if we pass a super long name, we're still trying to cut it and request_module an invalid name, right? --