Hi Rusty, I just tested this patch with 2.6.34-rc4 (as both host and guest), it seems to work fine. Thanks, Johannes --

Yep. (sorry about late reply). -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

No problem. I understand the desire to be conservative. --

This is not about lock/inheritance related overrun, right? But simply a task that got its WCET wrong. --

So what happens when we overflow u64? --

Can't this be a regular vararg function? Also, I wonder, would we want to put some information in the sigaction struct to allow the user to distinguish between the various SIGXCPU --

Without ->siglock? This is racy even if dl_task_of(se) == current, but I guess it can be !current. For example, we must never set TIF_SIGPENDING without wake_up_state(). A fatal signal should kill the whole process, etc. Even sigaddset() itself can race with tkill, it is not atomic. Oleg. --

AT91_PMC_MUL is 11 bits (so 0x7ff0000) Is the mask (0xff0000) correct in the above code? It looks like wait_pllblock will be skipped if the MUL field is set to 0x100, 0x200, 0x300, etc. Regards, Andrew Victor --

Commit-ID: ae731f8d0785ccd3380f511bae888933b6562e45 Gitweb: http://git.kernel.org/tip/ae731f8d0785ccd3380f511bae888933b6562e45 Author: Marc Zyngier <maz@misterjones.org> AuthorDate: Mon, 15 Mar 2010 22:56:33 +0000 Committer: Thomas Gleixner <tglx@linutronix.de> CommitDate: Tue, 13 Apr 2010 16:36:39 +0200 genirq: Introduce request_any_context_irq() Now that we enjoy threaded interrupts, we're starting to see irq_chip implementations (wm831x, pca953x) that make use of threaded ...

I'm not dead-set against it, but I am hesitant. My inclination is not to remove any previous userland atomicity guarantees with regard to observable signal state in any form. At least, don't do that in part of a whole cleanup flurry where it is intermixed with lots of changes that really are pure cleanup with absolutely no userland-observable change. If it really helps to fragment what was atomic before, then we can consider it. But let's not be in a hurry. David mentioned that users who ...

Dave, ----- Original Message ----- From: "Dave Chinner" <david@fromorbit.com> To: "Janos Haar" <janos.haar@netcenter.hu> Cc: <xiyou.wangcong@gmail.com>; <linux-kernel@vger.kernel.org>; <kamezawa.hiroyu@jp.fujitsu.com>; <linux-mm@kvack.org>; <xfs@oss.sgi.com>; <axboe@kernel.dk> Sent: Tuesday, April 13, 2010 1:34 PM Subject: Re: Kernel crash in xfs_iflush_cluster (was Somebody take a look I think i know now the reason.... My case starting to turn into more and more interesting. (Just ...

A corrupted directory. There have been several different types of So the bad inodes are: $ awk '/corrupt inode/ { print $10 } /dir: inode/ { print $8 }' messages | sort -n -u 474253931 474253936 474253937 474253938 474253939 474253940 474253941 474253943 474253945 474253946 474253947 474253948 474253949 474253950 474253951 673160704 673160708 673160712 673160713 It looks like the bad inodes are confined to two inode clusters. The nature of the errors - bad block mappings ...

There are multiple fields in the inode that are corrupted. I am really surprised that xfs-repair - even an old version - is not Yup, it probably ran off into la-la land chasing corrupted Yes, it could be something like that, too, but the only way to test I haven't heard of any significant memory corruption problems in 2.6.32 or 2.6.33, but it is a possibility given the nature of the corruption. However, I may have only happened once and be completely unreproducable. I'd suggest ...

Commit-ID: 6932bf37bed45ce8ed531928b1b0f98162fe6df6 Gitweb: http://git.kernel.org/tip/6932bf37bed45ce8ed531928b1b0f98162fe6df6 Author: Thomas Gleixner <tglx@linutronix.de> AuthorDate: Fri, 26 Mar 2010 00:06:55 +0000 Committer: Thomas Gleixner <tglx@linutronix.de> CommitDate: Tue, 13 Apr 2010 16:36:40 +0200 genirq: Remove IRQF_DISABLED from core code Remove all code which is related to IRQF_DISABLED from the core kernel code. IRQF_DISABLED still exists as a flag, but becomes a NOOP ...

Applied. --

On Tue, 13 Apr 2010 21:24:53 +0200 The CPU will end up throttling itself, reducing performance to keep within its power budget. The GPU will just end up hanging if it They would be, but these docs are only available under NDA. If you have a sales or technical contact you can use the numbers here to get Yes, I'm happy to have a better test here. Not that it matters *too* much though; we'll allocate more power budget to the CPU, but it will only use it if needed. Allocating it more ...

On Thu, 1 Apr 2010 22:01:59 +0200 (CEST) So... should we merge Chase's patch? --

I've made one small change to it. Checking the atomic .counter variable probably isn't the most portable, and atomic_long_read() should be portable and not add any overhead on sane platforms, so I swapped out the check against .counter with an atomic_long_read(). I'll resend it shortly. -- Chase --

I'm surprised this ack a bit. Rik, do you have any improvement plan about streaming io detection logic? I think the patch have a slightly marginal benefit, it help to <1% scan ratio case. but it have big regression, it cause streaming io (e.g. backup operation) makes tons swap. So, I thought we sould do either, 1) drop this one 2) merge to change stream io detection logic improvement at first, and merge this one at second. Am i missing something? --

And now I've merged this patch into my local vmscan patch queue. After solving streaming io issue, I'll put it to mainline. Thanks. --

Yes, it's not quite easily greppable. Making no seek allowed the I wouldn't bother. If you can actually work on your plan default_llseek should be gone soon enough. --

Dan, if this driver is fine can it be put into the async_tx tree? Andrew already has it in his tree but it shouldn't cause any problems in my limited experience. Linus Walleij --

It is in wireless-next-2.6, queued for 2.6.35. John -- John W. Linville Someday the world will need a hero, and you linville@tuxdriver.com might be all we have. Be ready. --

Acked-by: Johannes Weiner <hannes@cmpxchg.org> --

It now looks like this.. Linus --- From: Linus Torvalds <torvalds@linux-foundation.org> Date: Mon, 12 Apr 2010 12:44:29 -0700 Subject: [PATCH 4/4] anonvma: when setting up page->mapping, we need to pick the _oldest_ anonvma Otherwise we might be mapping in a page in a new mapping, but that page (through the swapcache) would later be mapped into an old mapping too. The page->mapping must be the case that works for everybody, not just the mapping that happened to page it in ...

On Tue, Apr 13, 2010 at 5:23 AM, Linus Torvalds Reviewed-by: Minchan Kim <minchan.kim@gmail.com> -- Kind regards, Minchan Kim --

On Tue, Apr 13, 2010 at 10:08 AM, Linus Torvalds Reviewed-by: Minchan Kim <minchan.kim> It was great hunting and was a chance to learn many things from LKML smart guys. I feel again about OSS's power and great procedure of linux evolution Thanks for everybody. -- Kind regards, Minchan Kim --

From: Linus Torvalds <torvalds@linux-foundation.org> Ok, just finished testing -rc4 - no problems so far. Let's just go out on a limb here and say with a greater certainty that this really got fixed but be smart about it and keep an eye open if it happens again - you never know. Where is the champagne? -- Regards/Gruss, Boris. --

Sorry, Now I'm lost what discuss in this crazy long thread. IIUC, If the page->mapping was freed millisecns ago, following (1) check returen false and we never touch page->mapping literally. Am I missing something? =================================================================== struct anon_vma *page_lock_anon_vma(struct page *page) { struct anon_vma *anon_vma; unsigned long anon_mapping; rcu_read_lock(); anon_mapping = (unsigned long) ...

No you're right, I got my head hopelessly twisted up trying to make page_lock_anon_vma() do something reliable, but there really isn't much that can be done. Luckily most users (with exception of the memory-failure.c one) don't really care and all take steps to verify the page is indeed in any of the vmas it might find. So I've given up on this and will only submit a patch like the below, which hopefully does still make sense... I do think there's a missing barrier in there as well, but ...

Looks like, this doesn't need get/put task_struct, you could just This doesn't look right. We can't trust ->thread_group list even under rcu_read_lock(). The task can exit and __exit_signal() can remove it This is called by create_uprocess(). Who will free t->utask if t has not sure I understand this check. Somehow we should prevent the races with tracehook_report_exit/tracehook_report_exec, but PF_EXITING can't can't we race with clone(CLONE_THREAD) and miss the new thread? ...

Commit-ID: f0e9c4fcefa42b5d28b915768dab81a7fdbbc00c Gitweb: http://git.kernel.org/tip/f0e9c4fcefa42b5d28b915768dab81a7fdbbc00c Author: Randy Dunlap <randy.dunlap@oracle.com> AuthorDate: Wed, 31 Mar 2010 11:30:56 -0700 Committer: Arnaldo Carvalho de Melo <acme@redhat.com> CommitDate: Thu, 8 Apr 2010 11:34:26 -0300 perf bench: fix spello Fix spello in user message. Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>, Cc: Paul Mackerra <paulus@samba.org>s LKML-Reference: ...

Wouldn't it be better to just mask out the AT91_CIDR_EXT bit in at91_cpu_identify()? That bit isn't really useful for "version" information. We'd then just need to modify: #define ARCH_ID_AT91SAM9G10 0x019903a0 #define ARCH_ID_AT91SAM9G45 0x019b05a0 #define ARCH_ID_AT91SAM9G45MRL 0x019b05a2 /* aka 9G45-ES2 & non ES lots */ #define ARCH_ID_AT91SAM9G45ES 0x019b05a1 /* 9G45-ES (Engineering Sample) */ (ie, drop bit AT91_CIDR_EXT) Regards, ...

Rafael --

==== CUT HERE ==== mm,compaction: Move extfrag_index to debugfs extfrag_index can be worked out from userspace but for debugging and tuning compaction, it'd be best for all users to have the same information. This patch moves extfrag_index to debugfs where it is both easier to configure out and remove at some future date. This is a fix to the patch "Export fragmentation index via /proc/extfrag_index". When merged, it'll collide with the patch "Direct compact when a high-order allocation ...

Well, given that is the new shrinker code generating the warnings, reverting/removing that hunk will render the patch useless :0 I'll get you a working 2.6.33 patch tomorrow - it's dinner time now.... Cheers, Dave. -- Dave Chinner david@fromorbit.com --

It is totally starvation, hotplug can not complete. I think it is a kind of DOS attack. --

I can confirm that "make oldconfig" does not fix the problem. Grub appears to load the kernel (at least it does not come back with an error as it otherwise would), cursor in the topleft corner and absolutely no activity. no reaction to ctrl-alt-del or magic keys. For all other kernels I would see at least the "uncompressing kerne.." message, not here. Richard --

it is a clean kernel.org kernel, with early printk and I tried playing with various (no)rhgb noquiet options just to be sure. So this does really appear to be something that happens in the earliest bootstages before uncompressing and can not think how it could be Fedora's fault - it does not get anywhere close to touching the initramd image. The only way I can proceed is try some kind of bisecting.. real bisect won't work as the wlan connection is painfully slow with the only working ...

--

This conflicts with your time-clean-up-warp_clock.patch, below. Shrug, I simply ignored the rejected hunk. From: John Stultz <johnstul@us.ibm.com> warp_clock() currently accesses timekeeping internal state directly, which is unnecessary. Convert it to use the proper timekeeping interfaces. Signed-off-by: John Stultz <johnstul@us.ibm.com> Cc: Thomas Gleixner <tglx@linutronix.de> Cc: Ingo Molnar <mingo@elte.hu> Signed-off-by: Andrew Morton <akpm@linux-foundation.org> --- ...

I strongly suspects that Windows knows that < 1 MB is special, and only ever assigns it upon explicit allocation. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

I'm flattered but nowadays I'm just a maintainer of a modest I think that the highest chance of bringing the right people's attention to this kernel regression would be achieved by filling the official bug-report at https://bugzilla.kernel.org/. Thanks. -- Bartlomiej Zolnierkiewicz --

I sent a patch on March 09, 2010, that should fix it. Please test it. Thanks. --- From: Randy Dunlap <randy.dunlap@oracle.com> When the dt3155 driver is built-in (not as a loadable module), these build errors happen: drivers/staging/dt3155/dt3155_drv.c:1047: error: implicit declaration of function 'request_irq' drivers/staging/dt3155/dt3155_drv.c:1048: error: 'IRQF_SHARED' undeclared (first use in this function) drivers/staging/dt3155/dt3155_drv.c:1048: error: 'IRQF_DISABLED' ...

Pulled, thanks a lot Joerg! Ingo --

This breaks compilation by removing __ALIGN_MASK(). Please fix this up. --

Applied. --

the driver for that device later can not use pci_request_region(). because that region is BUSY already. YH --

Good, that's what we want. ROM probing in this region should really be possible to skip, since the only thing safe is to treat the whole region as special. This is not in any way 32-bit-specific. -hpa --

Yes, > 1 MB in that case, I'm fairly sure. -hpa --

This -v2 text doesn't belong in the changelog. If you need it, it should be in a cover message so it doesn't clutter the permanent git I think this makes sense, but I think it should be in two separate patches. The first would be the pci_bus_alloc_resource() change, which is of interest to all architectures, with a changelog like this: PCI: don't allocate from a BUSY bus resource Drivers typically use pci_request_regions() to reserve the resources they use, but that fails if the ...

looks that file could be dropped. Thanks Yinghai --

Update e820 at first, and later put them resource tree. Reserved that early, will not be allocated to unassigned PCI BAR Signed-off-by: Yinghai Lu <yinghai@kernel.org> Cc: Guenter Roeck <guenter.roeck@ericsson.com> Cc: Andy Isaacson <adi@hexapodia.org> Tested-by: Andy Isaacson <adi@hexapodia.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: H. Peter Anvin <hpa@zytor.com> --- arch/x86/include/asm/setup.h | 1 - arch/x86/kernel/head32.c | 1 - arch/x86/kernel/setup.c ...

Drivers typically use pci_request_regions() to reserve the resources they use, but that fails if the resource is already busy. Therefore, we should ignore busy resources when we're assigning resources to a device. [commit log is from Bjorn] Tested-by: Andy Isaacson <adi@hexapodia.org> Cc: Bjorn Helgaas <bjorn.helgaas@hp.com> Acked-by: Bjorn Helgaas <bjorn.helgaas@hp.com> Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/pci/bus.c | 4 ++++ 1 file changed, 4 ...

should be --

Let me dig up the thread later... this was so long ago my memory might be rusty. -hpa --

OK... why is that handled differently? -hpa --

From: Thomas Müller <thomas@mathtm.de> Indeed you're right, net-2.6 needs it too. Thanks for catching this, I've cherry picked the commit from net-next-2.6 and added it to net-2.6 Thanks again! --

Hi David, Thanks for the info. I didn't know that I had to add an entry on the upper level Makefile. I guess that something like obj-$(CONFIG_USB_IPHETH) += usb/ should be enough? (I got it from the other USB net drivers). I won't be able to work on it today, I've been very busy today and can't I have also in my queue a patch sent from upstream to fix the latest issues pointed out by Roland Dreier, and I need to test it a little bit more. Thanks for your comments and ...

Typed wrong email id last time and mail bounced. So here is another --

^^ period might not be appropriate, if it is, n (not) should -- Three Cheers, Balbir --

* KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> [2010-04-13 15:20:48]: [snip] Because it is an actual name as compared to using <> for to be replaced with the right thing. -- Three Cheers, Balbir --

On Tue, Apr 13, 2010 at 01:45:53PM +0900, KAMEZAWA Hiroyuki wrote: Because I never understood very well, I will ask. Why lock_page_cgroup() should not be called under mapping->tree_lock? Thanks Vivek --

Thanks Balbir. So basically idea is that page_cgroup_lock() does not disable interrupts hence can be interrupted. So don't do lock_page_cgroup() in interrupt context at all otherwise it can lead to various kind of deadlock scenarios. One of those scenarios is lock_page_cgroup() under mapping->tree_lock. That helps. Thanks --

Hmm, but I checked the bonding case (IFF_BONDING), it doesn't hold rtnl_lock. Strange. --

On Tue, 13 Apr 2010 09:52:47 -0700 All this was related to netpoll. And netpoll processing often needs to occur in hard IRQ context. Therefor netpoll stuff and RTNL (which is a mutex), really don't mix well. Keep RTNL for what it was meant for network reconfiguration. Don't turn it into a network special BKL. -- --

Of course you are right that custom instructions can access the Avalon Bus (similar as a DMA-ip's can access it) and thus the memory that is used by Linux, too. But as with DMA this access bypasses the cache and the MMU. The problem this discussion is about is, that the architecture-independent code Linux provides (e.g. in FUTEX Kernel code and in user-land "atomic" macros) defines the memory-words to be accessed in an atomic way just somewhere in the user-land address space and accesses them ...

Good news! After some hours of hacking, damaging a filesystem and nearly smashing my SD card I've found a promising way to implement suspend and resume in viafb based on the first patch of this series. I think this is something that can be done for the next merge window. I'll start a clean implementation after Jon sent an updated patch series (including the Goal basically reached: - likely to work on all IGPs as nothing directly IGP dependent is there - works without ...

One way to make the interrupt assumption official is to use synchronize_sched() rather than synchronize_rcu(). --

We must flush before the pte_lock is released. If not, we end up with this funny situation: - PTE is read-only, hash contains a translation for it - PTE gets cleared & added to the batch, hash not flushed yet - PTE lock released, maybe even VMA fully removed - Other CPU takes a write fault, puts in a new PTE - Hash ends up with duplicates of the vaddr -> arch violation Now we could get out of that one, I suppose, if we had some kind of way to force flush any batch pertaining to a ...

True I guess, but like this we avoid a write, doesn't really matter I Can do, I can add batching similar to the generic code to the Heh, that seems like a real good way to waste a lot of memory fast ;-) --

Hi Jens, Do not see this patch and other IO controller stats patches in for-2.6.35 branch. :) Thanks, Gui --

Defininf some kind of LMB_ERROR would be nicer. Cheers, --

Isn't that more duplication from what's already in there for nid handling ? (Which btw may not be optimal, simply what I'm saying is that all that stuff should be factored). Cheers, --

that is only for some special cases about area that is reserved for fw region. and even there is overlapped area, it the code still can go through when lmb_to_bootmem or create range list for slab. any suggestion for better name? YH --

That is going to only work with one overlap. IE. lmb_free() will not do very well unless it's a one and only match. You should modify it to work in a loop. Besides, lmb_reserve_area_overlap_ok() sucks as a name :-) Cheers, Ben. --

I still find most of your changeset comments to be very very poor, if comprehensible at all. You really MUST make an effort there. Cheers, --

current generic lmb_find_area() is allocating from high to low. x86 32bit seems have problem with that. in this patchset, it is fixed, but not sure if i missed sth. x86 is only use find_area_early() with node area scope, David point that could have problem with cross node mem map. YH --

Acked-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --

Haven't you noticed there's already way too many functions walking the LMBs ? :-) I think the ones doing nid alloc could/should be also rewritten to use one single low level __lmb_find_* no ? Cheers, --

So you unconditionally add access to some lmb specific data structure to generic code ? That isn't going to work very well on archs that don't use lmb. Also, those things should be local to lmb_* anyways. Cheers, --

the whole function #ifdef CONFIG_HAVE_LMB u64 __init find_memory_core_early(int nid, u64 size, u64 align, u64 goal, u64 limit) { int i; /* Need to go over early_node_map to find out good range for node */ for_each_active_range_index_in_nid(i, nid) { u64 addr; u64 ei_start, ei_last; ei_last = early_node_map[i].end_pfn; ei_last <<= PAGE_SHIFT; ...

__alloc_memory_core_early() already include that find_memory_core_early() lines it is merged for CONFIG_NO_BOOTMEM support. I split it out, so lmb_find_area_node() could reuse those lines. YH --

Of course! :-) This thing does need a better changelog though, and maybe a larger comment with check_asym_packing(), explaining why and what we're doing and what we're assuming (that lower cpu number also means lower thread number). --

Right, so I suspect this will indeed break some things. We initially allowed 0 capacity for when a cpu is consumed by an RT task and there simply isn't much capacity left, in that case you really want to try and move load to your sibling cpus if possible. However you're right that this goes awry in your case. One thing to look at is if that 15% increase is indeed representative for the power7 cpu, it having 4 SMT threads seems to suggest there was significant gains, otherwise they'd not ...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 This means I should export the sh_tmu_clocksource_read (currently static) and don't pass for the clocksource code at all. Thanks for your prompt feedback. Best Regards, -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) Comment: Using GnuPG with Mozilla - ...

Hi Jason, I would appreciate if you could add pointers to the Immediate Values benchmarks (or possibly some benchmark information altogether) and a notice that some parts of the design are inspired from Immediate Values in the jump label code. I recognise that you did great work on getting jump label in shape both at the Linux kernel and gcc level, but it's usually appropriate to acknowledge prior work it is based on. Only then can I justify that Immediate Values have been useful in the ...

From: Peter Zijlstra <peterz@infradead.org> From 0c25e9e6cbe7b233bb91d14d0e2c258bf8e6ec83 Mon Sep 17 00:00:00 2001 From: David S. Miller <davem@davemloft.net> Date: Mon, 12 Apr 2010 22:21:52 -0700 Subject: [PATCH 2/2] sparc64: Adjust __raw_local_irq_save() to cooperate in NMIs. If we are in an NMI then doing a plain raw_local_irq_disable() will write PIL_NORMAL_MAX into %pil, which is lower than PIL_NMI, and thus we'll re-enable NMIs and recurse. Doing a simple: %pil = %pil | ...

Ah, ok.. Care to enlighten the curious amongst us as to what exactly you're doing in the sparc code? --

Added to next branch. I also fix mismatch for MMU kernel Thanks. Michal -- Michal Simek, Ing. (M.Eng) w: www.monstr.eu p: +42-0-721842854 Maintainer of Linux kernel 2.6 Microblaze Linux - http://www.monstr.eu/fdt/ Microblaze U-BOOT custodian --

Even in overcommit case, if vcpu threads of one qemu are not scheduled or pulled to the same logical processor, the performance drop is tolerant like Xen's case today. But for KVM, it has to suffer from additional performance loss, since host's scheduler actively pulls these vcpu threads together. Xiantao --

Patch below works for me, but I couldn't test the case when nvidia card is secondary. --- From: Marcin Slusarz <marcin.slusarz@gmail.com> Date: Tue, 13 Apr 2010 09:20:53 +0200 Subject: [PATCH] vga16fb, drm/nouveau: vga16fb->nouveau handoff let vga16fb claim 0xA0000+0x10000 region as its aperture; nouveau does not use it, so we need to lie to kick vga16fb, but only if it's driving the primary card (by checking IORESOURCE_ROM_SHADOW resource flag) Signed-off-by: Marcin Slusarz ...

I don't think that's correct. The "task_xstate" has alignof(struct task_xstate) and there seems to be so GCC attributes that force Yeah, sorry for dragging this issue on. I've been looking at the patch but haven't been able to convince myself that it's correct. Nick, David, Christoph, Matt, could you also please take a look at this? Pekka --

I am not sure I agree with the premises here. ptMalloc and malloc hooks are not related to the issue in my opinion. User space library calls do not change virtual to physical mapping, system calls do. The following sys calls might change virtual to physical mapping: munmap(), mremap(), sbrk(), madvice(). What we need is glibc to provide hooks for these 4 sys calls and the general syscall() when its argument is one of the four mentioned syscalls. To me, that is what is needed, and the ummunotify ...

Yeah, virtual<->physical maps can change through swapping, page migration, memory compaction, huge-page aggregation (the latter two not yet being upstream). Even mlock() doesn't pin virtual<->physical maps. --

My point is that there is no point in optimizing something unless its performance sensitive. And as i recall, mmu_unsync_walk was much more sensitive performance wise than parent walking. Actually, gfn_to_memslot seems more important since its also noticeable on EPT/NPT hosts. --

There is also the advantage of code size reduction. -- error compiling committee.c: too many arguments to function --

Actually, i not run benchmarks to contrast the performance before this patch This patch avoids walk all parents and i think this overload is really unnecessary. It has other tricks in this codepath but i not noticed? :-) Thanks, Xiao --

I usually use 'get blame' to look into source, and not noticed reverted patches, i'll pay more attention on those. Below code still confused me: | vcpu->arch.mmu.base_role.cr4_pge = (cr4& X86_CR4_PGE)&&!tdp_enabled; And i found the commit 87778d60ee: | KVM: MMU: Segregate mmu pages created with different cr4.pge settings | | Don't allow a vcpu with cr4.pge cleared to use a shadow page created with | cr4.pge set; this might cause a cr3 switch not to sync ptes that ...

ULONG_MAX is not 22 digits always. The fix is to not rely on simple_strtoul() I guess it's time to finally remove it. :-( Also, it's better to copy_from user stuff once. A what? --

It seems that all proc code assumes that the input buffer will Hmm, right, it should be memchr(v, c, len). Thanks! --

Hello. Adding Sean Hefty and Roland Dreier as drivers/infiniband/core/cma.c maintainer. I don't like above change. Above change makes local port assignment from "likely-succeed" (succeeds if one port is available from thousands of ports) to "unlikely-succeed" (fail if randomly chosen port is already in use). We should repeat for all ranges specified in /proc/sys/net/ipv4/ip_local_port_range . cma_alloc_any_port() and cma_alloc_port() are almost identical. Thus, I think we can call ...

Looks okay to me, but as mention in the other review I would introduce the comment flags first and then add the flags to blkdev_issue_flush, not the other way around. --

Looks okayish to me, but it really needs: a) a useful patch description b) patches that introduce actual users Also why does the function have a __ prefix in the name? --

This is a very awkward stayle to define flags. There really should be no need for the __-prefixed version. While you're using them for test/set_bit and co there's no reason to use these atomic bitops here. --

NE020 supports 4 SGEs. I don't know enough about SDP to know why it is using this calculation for # of send_sge: This is not a firmware problem. Chien --

No, but SDP uses FMRs. I don't think it will run without FMR support. --

Hi Thomas, In fact this was my intended Subject line... The current subject line was a copy and paste accident! Due to the fact that my online mailer eats mails Removing this already solved the bug message. I fixed all other bugs as well and attached the updated file. Thanks a lot -- Stefan Agner ---------------------------------------------------------------- This message was sent using IMP, the Internet Messaging Program.

Some more ideas to nail this down would be to boot the machine with mem=4096M and mem=2048M to see whether this makes any difference. Also, I think it would be interesting to know whether the patch below helps. As the real reason seems entirely obfuscated, there's unfortunately need for some trial error approach. Pedro, as you're the only one who can actually reproduce the problem, do you see any chance to do that? Thanks, Daniel diff --git a/sound/usb/caiaq/audio.c ...

This means that userspace could access any register in the same page. Usually this is done only with read-only pages and with devices that are designed for this so that all accessible registers are 'safe'. Regards, Clemens --

I've only two comments: and this one as well? --

No need to resend them (unless Peter eyes found something I missed). --

Ahh.. I see this now with CONFIG_DEBUG_CFQ_IOSCHED not set. blkiocg_set_empty_start_time() should be within the #ifdef block/cfq-iosched.c: In function 'cfq_forced_dispatch': block/cfq-iosched.c:2234: error: too few arguments to function 'cfq_slice_expired' Another compile error after fixing this was due to the merge from mainline. cfq_slice_expired() now has an extra argument. Fixed that too. Will send a patch with the 2 fixes in a bit. Sorry for the --

I hand applied that one hunk, and committed it. But... block/blk-cgroup.c:271: error: redefinition of ?blkiocg_set_start_empty_time? block/blk-cgroup.h:208: note: previous definition of ?blkiocg_set_start_empty_time? was here block/blk-cgroup.c: In function ?blkiocg_set_start_empty_time?: block/blk-cgroup.c:291: error: implicit declaration of function ?blkio_blkg_empty? block/blk-cgroup.c:292: error: ?struct blkio_group_stats? has no member named ?start_empty_time? block/blk-cgroup.c:293: ...

Yeah, I don't think SAP did that, significantly to matter. Possibly Yep, I'm not against it. "industry standard benchmark" numbers would be great. I do think we need to be really careful with semantics though. The API's been around for long enough that it is going to have been (ab)used in every way possible :) --

Do you mean within a single sop array doing all three of these? I don't know if the sort is going to leave the three operations on semaphore 5 in the same order (it probably won't). But I could change that by having it include the slot in the original sop array in the sorting. That way if we have duplicate semnums in the array, they will end up in the same position relative to each other in the sorted result. (ewwww ;) -chris --

I don't see anything in the docs about the FIFO order. I could add an extra sort on sequence number pretty easily, but is the starvation case Yeah, that's why my patches include code to handle userland sending duplicate semids. Zach's simpler API is cooking too, but if I can get this done without insane complexity it helps with more than just the post/wait oracle workload. -chris --

Sure, I'd hope that your benchmark from last time around is faster now. -chris --

Detecting the dups just keeps me from deadlocking. I'm locking each individual semaphore in sequence, so if userland does something strange and sends two updates to the same semaphore, the code detects that and Since I'm avoiding the ipc lock while operating on the array, it'll help any workload that hits on two or more semaphores in the array at I'm not in a hurry to overhaul a part of the kernel that has been stable for a long time. But it really needs some love I think. I'll have ...

I added this patch to next branch and I will keep it there for now. 1. I agree that we need several patches like this. 2. The improvement could be there and likely it is but 3% improvement could be caused for different reason. 3. There is necessary to measure it on several hw design and cache configurations to be sure that your expectation is correct. 4. The best will be to monitoring cache behavior but currently there is no any tool which could easily help us with it. I will talk to ...

The pushdown can be in a separate tree that can be merged independently, just the final patch removing it in do_new_mount needs to wait for everything else to get merged first. We have some other patches, in particular the one that makes CONFIG_BKL modular that have to wait for other patches and should probably just be applied separately rather than merged from a bisectable git tree. Arnd --

Looking at this - probably we should protect by this lock also setting of a feature in ext2_xattr_update_super_block(). It's an unrelated bugfix but Why exactly do you have in the above? Probably because of consistent view of mount options? You should comment about that in the changelo and Could you please fold in ext2_commit_super? It's used only here and it's name looks a bit scary to be called under the spinlock... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

* C99 knows about USHRT_MAX/SHRT_MAX/SHRT_MIN, not USHORT_MAX/SHORT_MAX/SHORT_MIN. * Make SHRT_MIN of type s16, not int, for consistency. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> --- drivers/scsi/fcoe/fcoe.c | 2 +- drivers/scsi/mpt2sas/mpt2sas_base.c | 2 +- drivers/scsi/mpt2sas/mpt2sas_config.c | 2 +- drivers/vhost/vhost.c | 2 +- fs/nfs/super.c | 4 ++-- fs/nfsd/nfsctl.c | 4 ++-- ...

OK, I see. How about arch_irq_entry/exit() ? This way, if we need to do something similar on another arch at the architecture-level, we can use the same names. Thanks, -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS Inc. http://www.efficios.com --

Linus, So do you expect the existing ab4500 also to be merged into abx500? regards, Srinidhi --

From: Dave Chinner <dchinner@redhat.com> When we enter direct reclaim we may have used an arbitrary amount of stack space, and hence enterring the filesystem to do writeback can then lead to stack overruns. This problem was recently encountered x86_64 systems with 8k stacks running XFS with simple storage configurations. Writeback from direct reclaim also adversely affects background writeback. The background flusher threads should already be taking care of cleaning dirty pages, and direct ...

It's already known that the VM requesting specific pages be cleaned and reclaimed is a bad IO pattern but unfortunately it is still required by lumpy reclaim. This change would appear to break that although I haven't tested it to be 100% sure. Even without high-order considerations, this patch would appear to make fairly large changes to how direct reclaim behaves. It would no longer wait on page writeback for example so direct reclaim will return sooner than it did potentially going OOM if ...

AFAICT it still waits for pages under writeback in exactly the same manner it does now. shrink_page_list() does the following completely separately to the sc->may_writepage flag: 666 may_enter_fs = (sc->gfp_mask & __GFP_FS) || 667 (PageSwapCache(page) && (sc->gfp_mask & __GFP_IO)); 668 669 if (PageWriteback(page)) { 670 /* 671 * Synchronous reclaim is performed in two passes, ...

Depends. For raw effectiveness, I run a series of performance-related benchmarks with a final test that o Starts a number of parallel compiles that in combination are 1.25 times of physical memory in total size o Sleep three minutes o Start allocating huge pages recording the latency required for each one o Record overall success rate and graph latency over time Right, so it'll still wait on writeback but won't kick it off. That would still be a fairly significant change in behaviour ...

From: Dave Chinner <dchinner@redhat.com> The current shrinker implementation requires the registered callback to have global state to work from. This makes it difficult to shrink caches that are not global (e.g. per-filesystem caches). Add a context argument to the shrinker callback so that it can easily be used in such situations. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- arch/x86/kvm/mmu.c | 2 +- drivers/gpu/drm/i915/i915_gem.c | 2 +- fs/dcache.c ...

From: Dave Chinner <dchinner@redhat.com> On low memory boxes or those with highmem, kernel can OOM when the application scans large numbers of inodes. In this case, the XFS background inode reclaim scan run by xfssyncd does not run soon enough to free clean, reclaimable inodes. Add a per-filesystem shrinker to XFS to run inode reclaim so that it is expedited when memory is low and hence prevent OOM conditions from being hit. Signed-off-by: Dave Chinner <dchinner@redhat.com> --- ...

It's been two weeks rather than the usual one, because we've been hunting a really annoying VM regression that not a lot of people seem to have seen, but I didn't want to release an -rc4 with it. So we had the choice of either reverting all the anon-vma scalability improvements, or finding out exactly what caused the regression and fixing it. And we got pretty close to the point where I was going to just revert it all. Absolutely _huge_ kudos to Borislav Petkov who reported the ...

Recently, most company start use >=2.6.31 kernels to replace redhat kernels. But the config "Filter access to /dev/mem" is "default n", that allows kernel rootkit using /dev/mem again. it could access all kernel memory default. Most administrator don't known the "Filter access to /dev/mem" is "defult N", when he compiles the kernel, it's easily to be attacked by rootkit. Signed-off-by: Zhitong Wang <zhitong.wangzt@alibaba-inc.com> --- arch/x86/Kconfig.debug | 3 ++- ...

On Tue, 13 Apr 2010 13:42:07 +0900 Nice catch. but...I want to make all kind of complicated things under prepare/end migration. (And I want to avoid changes in migrate.c...) Considering some racy condistions, I wonder memcg_update_file_mapped() itself still need fixes.. So, how about this ? We already added FILE_MAPPED flags, then, make use of it. == At migrating mapped file, events happens in following sequence. 1. allocate a new page. 2. get memcg of an old page. 3. charge ...

We're up to 2.6.34-rc4 upstream but we hadn't released a respective compat-wireless stable [1] tarball yet. I finally got some time so just posted one up [2], this gives us the 2.6.34-rc4 wireless subsystem, bluetooth subsystem and new wireless/bluetooth drivers compilable and installed on older kernels. Please report any issues ASAP. For details on changes you can refer to the ChangeLog-2.6.34-rc4-wireless [3]. I only did a quick build test against 2.6.31 and it seems to compile fine :), more ...

Hi "Frédéric, After merging the bkl-procfs tree, today's linux-next build (powerpc ppc64_defconfig) failed like this: net/sunrpc/cache.c: In function 'cache_ioctl_procfs': net/sunrpc/cache.c:1355: error: implicit declaration of function 'lock_kernel' net/sunrpc/cache.c:1359: error: implicit declaration of function 'unlock_kernel' Caused by commit 64ef834551d7696f54553d7608eba80a5a800e77 ("procfs: Push down the bkl from ioctl"). Forgot to include linux/smp_lock.h? ...

This is a patch to the comedidev.h file that fixes up two macros do - while loop and a space before tabs warnings found by the checkpatch.pl tool. Signed-off-by: Gustavo Silva <silvagustavo@users.sourceforge.net> --- drivers/staging/comedi/comedidev.h | 11 ++++++----- 1 files changed, 6 insertions(+), 5 deletions(-) diff --git a/drivers/staging/comedi/comedidev.h b/drivers/staging/comedi/comedidev.h index ebdccfd..1b0d84b 100644 --- a/drivers/staging/comedi/comedidev.h +++ ...

This is indeed introduced by this commit. I have reproduced the issue in a powerpc machine, and I will provide a fix soon. Jing -----Original Message----- From: Stephen Rothwell [mailto:sfr@canb.auug.org.au] Sent: Monday, April 12, 2010 11:21 PM To: James Bottomley Cc: linux-next@vger.kernel.org; linux-kernel@vger.kernel.org; Jing Huang Subject: linux-next: build warnings after merge of the final tree (scsi tree related) Hi James, After merging the final tree, today's linux-next build ...

Hi all, Changes since 20100412: New trees: bkl-core bkl-procfs Removed tree: reiserfs-bkl (end of life - at maintainer's request) Dropped trees: tmio-mmc (long unresolved conflicts and unable to fetch) hwlat (at the maintainer's request) bkl-procfs (build problem) My fixes tree contains: a patch for a pktcdvd build error from Arnd Bergmann The v4l-dvb tree still has its build failure, so I used the version from next-20100409. The bkl-procfs tree gained a build failure, so I ...

Here is the document for blkio.weight_device Signed-off-by: Gui Jianfeng <guijianfeng@cn.fujitsu.com> Acked-by: Vivek Goyal <vgoyal@redhat.com> --- Documentation/cgroups/blkio-controller.txt | 31 +++++++++++++++++++++++++++- 1 files changed, 30 insertions(+), 1 deletions(-) diff --git a/Documentation/cgroups/blkio-controller.txt b/Documentation/cgroups/blkio-controller.txt index db054ea..a4ce8fe 100644 --- a/Documentation/cgroups/blkio-controller.txt +++ ...

Applied -- Jens Axboe --

Hello, I saw the very interesting presentation of Greg at the last FOSDEM where he explained how to write a patch of the kernel. During his presentation, he presented the script checkpatch.pl which checks the coding style of a patch / file. For a while, I have been looking for such script which can check the compliance of a source code against a coding policy. Obviously, the coding style of my project is not exactly the same as he Kernel one. Therefor, I would like to know if there ...

From: "Ian Munsie" <imunsie@au1.ibm.com> Thanks for finding and fixing this bug. --

Hello, I have a line discpline driver for a custom protocol over an UART. This driver implements the following callbacks: open/close, receive_buf/write_wakeup. So far, I have an ugly hack, which opens the /dev/tty<N> in the kernel, and directly uses the f_op and unlocked_ioctl functions to do the ldisc number to TTY device binding: [snip] struct file *f; filp_open("/dev/ttyS1", 0, 0); f->f_op->unlocked_ioctl(f, TCFLSH, 0x2); memset(&tio, 0, sizeof(tio)); tio.c_cflag = ...

The networking developers generally do not listen to linux-kernel To reach them submit your posting with netdev@vger.kernel.org on the CC: list. Thanks. --

Disable the processor clock when the CPU is idle. This saves much more power than merely entering 'Wait for Interrupt' mode. Since JTAG-debugging doesn't work when the processor clock is switched off, make it conditional on CONFIG_DEBUG_KERNEL. Signed-off-by: Anders Larsen <al@alarsen.net> Cc: Andrew Victor <avictor.za@gmail.com> --- KernelVersion: 2.6.33 arch/arm/mach-at91/include/mach/system.h | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) Index: ...

This fixes a regression introduced in Linux 2.6.2 where mice that sporadically produce bad parity go crazy and start jumping around and clicking randomly, which never happens in any version of Windows running on the same hardware. The bugzilla bug is https://bugzilla.kernel.org/show_bug.cgi?id=6105 The patch works by always accumulating a full PS/2 packet, then ignoring the packet if any byte had a bad checksum. A month of testing it against an affected mouse has revealed it works perfectly ...

Of note is the fix for the wireless regression reported last week, a fix for virtio net crashes with DEBUG_SG enabled, and some minor bug cures in other drivers. I tried to cure a loopback TCP checksumming anomaly with dataless packets, but couldn't get it right the first time so reverted. It's a harmless issue (we check checksums of ACKs over loopback) and we've had it forever, but such things should be toyed with in our -next trees not here... I merged in your tree to resolve some ...

Does Microblaze MMU Linux support Futex ? Does Microblaze MMU Linux support SMP ? Thanks -Michael --

Hi, Is there any function in the Linux kernel that control the charging/discharging of the battery to provide better lifespan ? (add some years to its life ?) For Laptops, it is better to extract the battery from the Laptop when the computer will be on power for a long period. I ask if the kernel can do such control without the user intention and in an automatic way. Some BIOS provide to the user to select whether to block the battery charging to 50% to make it stand for more time. And ...

This is a re-submission of a previous patch to the adv_pci_dio.c file that fixes up over 80 character warnings found by the checkpatch.pl tool Signed-off-by: Maurice Dawson <mauricedawson2699@googlemail.com> --- drivers/staging/comedi/drivers/adv_pci_dio.c | 124 ++++++++++++------------- 1 files changed, 60 insertions(+), 64 deletions(-) diff --git a/drivers/staging/comedi/drivers/adv_pci_dio.c b/drivers/staging/comedi/drivers/adv_pci_dio.c index b768ea5..3238e1a 100644 --- ...

This patchset contains SCST core together with documentation. Where possible, it was divided based on functionality grouping, in other cases it was divided by per file basis. Vlad --

This patch contains declarations of all externally visible SCST constants, types and functions prototypes. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- scst.h | 3169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ scst_const.h | 330 ++++++ 2 files changed, 3499 insertions(+) diff -uprN orig/linux-2.6.33/include/scst/scst_const.h linux-2.6.33/include/scst/scst_const.h --- orig/linux-2.6.33/include/scst/scst_const.h +++ ...

This patch contains file scst_targ.c. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- scst_targ.c | 5712 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 5712 insertions(+) diff -uprN orig/linux-2.6.33/drivers/scst/scst_targ.c linux-2.6.33/drivers/scst/scst_targ.c --- orig/linux-2.6.33/drivers/scst/scst_targ.c +++ linux-2.6.33/drivers/scst/scst_targ.c @@ -0,0 +1,5712 @@ +/* + * scst_targ.c + * + * Copyright (C) 2004 - 2010 Vladislav Bolkhovitin ...

This patch contains SCST SGV cache. SGV cache is a memory management subsystem in SCST. More info about it you can find in the documentation in this patch. P.S. Solaris COMSTAR also has similar facility. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- Documentation/scst/sgv_cache.txt | 224 ++++ drivers/scst/scst_mem.c | 1788 +++++++++++++++++++++++++++++++++++++++ drivers/scst/scst_mem.h | 150 +++ include/scst/scst_sgv.h | 97 ++ 4 files changed, ...

This patch contains SCST debugging support routines. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- drivers/scst/scst_debug.c | 136 ++++++++++++++++++++++ include/scst/scst_debug.h | 276 ++++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 412 insertions(+) diff -uprN orig/linux-2.6.33/include/scst/scst_debug.h linux-2.6.33/include/scst/scst_debug.h --- orig/linux-2.6.33/include/scst/scst_debug.h +++ linux-2.6.33/include/scst/scst_debug.h @@ -0,0 +1,276 @@ +/* + * ...

This patch contains SCST sysfs rules. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- SysfsRules | 795 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 795 insertions(+) diff -uprN orig/linux-2.6.33/Documentation/scst/SysfsRules linux-2.6.33/Documentation/scst/SysfsRules --- orig/linux-2.6.33/Documentation/scst/SysfsRules +++ linux-2.6.33/Documentation/scst/SysfsRules @@ -0,0 +1,795 @@ + SCST SYSFS interface ...

This patch contains file scst_sysfs.c. Signed-off-by: Daniel Henrique Debonzi <debonzi@linux.vnet.ibm.com> Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- scst_sysfs.c | 3884 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3884 insertions(+) diff -uprN orig/linux-2.6.33/drivers/scst/scst_sysfs.c linux-2.6.33/drivers/scst/scst_sysfs.c --- orig/linux-2.6.33/drivers/scst/scst_sysfs.c +++ linux-2.6.33/drivers/scst/scst_sysfs.c @@ -0,0 +1,3884 @@ +/* + * ...

This patch contains SCST dev handlers' Makefile. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- Makefile | 13 +++++++++++++ 1 file changed, 13 insertions(+) diff -uprN orig/linux-2.6.33/drivers/scst/dev_handlers/Makefile linux-2.6.33/drivers/scst/dev_handlers/Makefile --- orig/linux-2.6.33/drivers/scst/dev_handlers/Makefile +++ linux-2.6.33/drivers/scst/dev_handlers/Makefile @@ -0,0 +1,13 @@ +ccflags-y += -Iinclude/scst -Wno-unused-parameter + +obj-m := scst_cdrom.o ...

This patchset contains external patches SCST necessary to integrate SCST into the Linux kernel tree as well as provide for it necessary additional functionality. Vlad --

This patch contains changes in drivers/Kconfig and drivers/Makefile to integrate SCST into the Linux kernel tree. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- Kconfig | 2 ++ Makefile | 1 + 2 files changed, 3 insertions(+) diff -upkr -X linux-2.6.33/Documentation/dontdiff linux-2.6.33/drivers/Kconfig linux-2.6.33/drivers/Kconfig --- orig/linux-2.6.33/drivers/Kconfig 01:51:29.000000000 +0400 +++ linux-2.6.33/drivers/Kconfig 14:14:46.000000000 +0400 @@ -24,6 +24,8 @@ ...

This patch contains iSCSI-SCST's Makefile and Kconfig. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- Kconfig | 25 +++++++++++++++++++++++++ Makefile | 6 ++++++ 2 files changed, 31 insertions(+) diff -uprN orig/linux-2.6.33/drivers/scst/iscsi-scst/Makefile linux-2.6.33/drivers/scst/iscsi-scst/Makefile --- orig/linux-2.6.33/drivers/scst/iscsi-scst/Makefile +++ linux-2.6.33/drivers/scst/iscsi-scst/Makefile @@ -0,0 +1,6 @@ +EXTRA_CFLAGS += -Iinclude/scst + +iscsi-scst-y ...

This patch contains iSCSI-SCST's README file. Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- README.iscsi | 585 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 585 insertions(+) diff -uprN orig/linux-2.6.33/Documentation/scst/README.iscsi linux-2.6.33/Documentation/scst/README.iscsi --- orig/linux-2.6.33/Documentation/scst/README.iscsi +++ linux-2.6.33/Documentation/scst/README.iscsi @@ -0,0 +1,585 @@ +iSCSI SCST target ...

This patch contains SCST InfiniBand SRP target driver. This driver work directly on top of InfiniBand stack and SCST. It was originally developed by Vu Pham/Mellanox, currently Bart Van Assche is maintaining and improving it. Signed-off-by: Vu Pham <vu@mellanox.com> Signed-off-by: Bart Van Assche <bart.vanassche@gmail.com> Signed-off-by: Vladislav Bolkhovitin <vst@vlnb.net> --- Kconfig | 12 Makefile | 4 ib_dm_mad.h | 139 ++ ib_srpt.c | 3202 ...

You mean that sometimes DFAR doesn't have the true ip origin of the exception? May be you can check the trapped regs to find the instruction pointer Ah, indeed if you need to abstract out various ARM versions, that's quite sensitive. Ah indeed you really need to protect against recursion. But I'm unclear about the difference between Supervisor and System. May be System means the common kernel ring? And you enter into Supervisor when an exception triggers? Do these ...

Hi Frederic, Many thanks for taking a look at the these patches, I appreciate the feedback. It looks like you've understood it correctly. Actually, I have a disclaimer of my own; I'm using a new mail client in the hope By unpredictable I mean that the value in the DFAR is not defined to correspond to the causative address in any way. This isn't the case for a standard data abort, but it is in the case of a watchpoint I know, it makes life a lot harder for us. The most annoying thing is ...

Acked-by: Herbert Xu <herbert@gondor.apana.org.au> Thanks, -- 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 --

The following situation was observed in the field: tap1 sends packets, tap2 does not consume them, as a result tap1 can not be closed. This happens because tun/tap devices can hang on to skbs undefinitely. As noted by Herbert, possible solutions include a timeout followed by a copy/change of ownership of the skb, or always copying/changing ownership if we're going into a hostile device. This patch implements the second approach. Note: one issue still remaining is that since skbs keep ...

I think if that's a real issue, you have to apply traffic shaping to the untrusted nodes. The existing flow-control scheme was fragile anyway as you had to translate packet lengths on TX side to packet counts on RX. Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux --

We do not get unkillable processes, at least with sockets I was thinking about (TCP/UDP ones). Maybe tun sockets can behave the same ? Herbert Acked your patch, so I guess its OK, but I think it can be dangerous. Anyway my feeling is that we try to add various mechanisms to keep a hostile user flooding another one. For example, UDP got memory accounting quite recently, and we added socket backlog limits very recently. It was considered not needed few years ago. --

And whatever's done should ideally work for tap to IP and IP to IP sockets as well, not just tap to tap. -- MST --

This was sent in error, please ignore. --

Alan, Any comments on these patches ? The INTERNET now has a personality. YOURS! See your Yahoo! Homepage. http://in.yahoo.com/ --

Sorry for writing confusing changelog. I means if node == -1 alloc_slab_page always calls alloc_pages. So we don't need redundant check. -- Kind regards, Minchan Kim --

Well, numa_node_id() is implemented as #ifndef numa_node_id #define numa_node_id() (cpu_to_node(raw_smp_processor_id())) #endif and the mapping table on x86 at least is based on possible CPUs in init_cpu_to_node() leaves the mapping as 0 if the APIC is bad or the numa node is reported in apicid_to_node as -1. It would appear on power that the node will be 0 for possible CPUs as well. Hence, I believe this to be safe but a confirmation from Tejun would be nice. I would continue ...

alloc_pages_node is called with cpu_to_node(cpu). I think cpu_to_node(cpu) never returns -1. (But I am not sure we need double check.) So we can use alloc_pages_exact_node instead of alloc_pages_node. It could avoid comparison and branch as 6484eb3e2a81807722 tried. Cc: Tejun Heo <tj@kernel.org> Cc: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Minchan Kim <minchan.kim@gmail.com> --- mm/percpu.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git ...

if node_state is N_HIGH_MEMORY, node doesn't have -1. It means node's validity check is unnecessary. So we can use alloc_pages_exact_node instead of alloc_pages_node. It could avoid comparison and branch as 6484eb3e2a81807722 tried. Cc: Christoph Lameter <cl@linux-foundation.org> Signed-off-by: Minchan Kim <minchan.kim@gmail.com> --- mm/sparse-vmemmap.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/mm/sparse-vmemmap.c b/mm/sparse-vmemmap.c index 392b9bb..7710ebc ...

alloc_pages_exact_node naming makes some people misleading. They considered it following as. "This function will allocate pages from node which I wanted exactly". But it can allocate pages from fallback list if page allocator can't find free page from node user wanted. So let's comment this NOTE. Actually I wanted to change naming with better. ex) alloc_pages_explict_node. But I changed my mind since the comment would be enough. If anybody suggests better name, I will do with ...

Are you certain? What about __kmalloc -> slab_alloc (passed -1 as a node from __kmalloc) -> __slab_alloc -> new_slab -> allocate_slab -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

It's a little tough to read. How about /* * Use this instead of alloc_pages_node when the caller knows * exactly which node they need (as opposed to passing in -1 * for current). Fallback to other nodes will still occur * unless __GFP_THISNODE is specified. */ -- Mel Gorman Part-time Phd Student Linux Technology Center University of Limerick IBM Dublin Software Lab --

Slub changes need to go through its maintainer, Pekka Enberg <penberg@cs.helsinki.fi>. --

Each patch in this series seems to be independent and can be applied seperately, so it's probably not necessary to make them incremental. --

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> This patch adds the device platform registration for enabling USB host functionality on the OTG port on Freescale MX51 Babbage HW. This file makes platform specific calls to initialize the USB HW. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/mach-mx5/Makefile | 2 +- arch/arm/mach-mx5/board-mx51_babbage.c | 4 ++ arch/arm/mach-mx5/usb_dr.c | 57 ...

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> This patch adds the device platform registration for enabling USB host functionality on the Host1 port on Freescale MX51 Babbage HW. This file makes platform specific calls to initialize the USB HW. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/mach-mx5/Makefile | 2 +- arch/arm/mach-mx5/board-mx51_babbage.c | 2 + arch/arm/mach-mx5/usb_h1.c | 90 ...

This is also board specific, and nothing you should assume for all boards. Other implementations may do this differntly, which is why What's the reason for having the _ext variants that are just wrapers? --

That should be split in two patches - one for common code and one for --

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> This patch is part of enabling USB for Freescale MX51 Babbage HW. This patch updates the iomux pins for USB, and gpio line for reset the USB hub on the MX51 Babbage HW. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/plat-mxc/ehci.c | 4 +++ arch/arm/plat-mxc/include/mach/iomux-mx51.h | 33 ++++++++++++++++---------- 2 files changed, 24 insertions(+), 13 ...

This needs a cpu_is_mx5() condition. For now that's just nit-picking, but once another platform is added, the statement will return where it shouldn't. Daniel --

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> Update /plat-mxc/gpio.c to support Freescale's MX51 Babbage HW. This patch applies to 2.6.34-rc4. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/mach-mx5/board-mx51_babbage.c | 5 +++- arch/arm/mach-mx5/devices.c | 33 ++++++++++++++++++++++++++++++- arch/arm/plat-mxc/gpio.c | 32 +++++++++++++++++++++++++----- 3 files changed, 61 insertions(+), 9 deletions(-) diff --git ...

-----Original Message----- From: Daniel Mack [mailto:daniel@caiaq.de] Sent: Tuesday, April 13, 2010 11:46 AM To: Nguyen Dinh-R00091 Cc: linux-kernel@vger.kernel.org; amit.kucheria@canonical.com; linux@arm.linux.org.uk; s.hauer@pengutronix.de; grant.likely@secretlab.ca; Herring Robert-RA7055; linux-arm-kernel@lists.infradead.org; bryan.wu@canonical.com; valentin.longchamp@epfl.ch Subject: Re: [PATCH 2.6.34-rc4 1/8] mx5: Add registration of GPIOs for MX51 Babbage board. First, I'm glad ...

Hi, I was doing some leaktests with our applications and couldn't really figure out any memory leak (neither with valgrind). Although top shows up that the application has an increased memory usage. The sample applications: #include <stdio.h> #include <unistd.h> #include <pthread.h> #include <stdlib.h> void *threadfunc(void *opaque) { return NULL; }; int main() { pthread_t thread; while(1) { pthread_create(&thread, NULL, threadfunc, ...

From: Rob Landley <rob@landley.net> Add somaxconn to Documentation/sysctl/net.txt Signed-off-by: Rob Landley <rob@landley.net> --- Documentation/sysctl/net.txt | 6 ++++++ 1 file changed, 6 insertions(+) diff --git a/Documentation/sysctl/net.txt b/Documentation/sysctl/net.txt index df38ef0..2740085 100644 --- a/Documentation/sysctl/net.txt +++ b/Documentation/sysctl/net.txt @@ -90,6 +90,12 @@ optmem_max Maximum ancillary buffer size allowed per socket. Ancillary data is a ...

Dunno. I just got a question on the busybox mailing list: http://lists.busybox.net/pipermail/busybox/2010-April/072090.html Looked in Documentation to see what /proc/sys/net/core/somaxconn actually _did_, found it was undocumented, grepped the kernel source for somaxconn, found just one chunk of code actually using it, replied to the guy's question: http://lists.busybox.net/pipermail/busybox/2010-April/072096.html And then tweaked the documentation with what I'd found, and sent in ...

[1.] ZTE MF 330 as modem, not as usb 2.0 hub -------------------------------------------- [2.] Since 2.6.27-r7 there is support for this pcmcia data card by usbserial module. In option.c file there isn't correct ID for ZTE MF 330 modem. I assume that for somebody is correct but not for me and possibly other. -------------------------------------------- [3.] usbserial.ko, option.ko, zte mf 330 -------------------------------------------- [4.] Linux version 2.6.33-gentoo (root@pd-mainframe) ...

From: Dinh Nguyen <Dinh.Nguyen@freescale.com> Need to include <asm/div64.h> for do_div calls. Signed-off-by: Dinh Nguyen <Dinh.Nguyen@freescale.com> --- arch/arm/mach-mx5/clock-mx51.c | 1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-mx5/clock-mx51.c b/arch/arm/mach-mx5/clock-mx51.c index 8f85f73..1ee6ce4 100644 --- a/arch/arm/mach-mx5/clock-mx51.c +++ b/arch/arm/mach-mx5/clock-mx51.c @@ -16,6 +16,7 @@ #include <linux/io.h> #include ...

Fix the compilation warning in powerpc. The same change also fixes endian issue we found in powerpc test. This patch has been tested in x86 and powerpc platform. it is created using scsi-misc-2.6. Signed-off-by: Jing Huang <huangj@brocade.com> --- drivers/scsi/bfa/bfa_os_inc.h | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/scsi/bfa/bfa_os_inc.h b/drivers/scsi/bfa/bfa_os_inc.h index 4eb1330..bd1cd3e 100644 --- a/drivers/scsi/bfa/bfa_os_inc.h +++ ...

I think I will split this up into the following set of patches: - rename the functions and add a macro for the old names - rename all in-kernel usages - rename the staging tree usages - remove the macros the first patch can go in to Linus's tree now, to make it easier for the 2nd and 3rd patches to live in linux-next easier as we might need to look at the usages in other development trees before we can add the last one. Sound good? thanks, greg k-h --

Commit 48b32a3553a54740d236b79a90f20147a25875e3 introduced a problem that causes corruption when extended attributes are replaced with a smaller value. The issue is that the reiserfs_setattr to shrink the xattr file was moved from before the write to after the write. The root issue has always been in the reiserfs xattr code, but was papered over by the fact that in the shrink case, the file would just be expanded again while the xattr was written. The end result is that the last 8 ...

this gets funny with employers chaning etc ;) Signed-off-by: Arjan van de Ven <arjan@redhat.com> [defunct email] Acked-by: Arjan van de Ven <arjan@linux.intel.com> --

This patch has been around for a long time in Fedora and Red Hat Enterprise Linux kernels and it may be useful for others. The nonint_oldconfig target will fail and print the unset config options while loose_nonint_oldconfig will simply let the config option unset. They're useful in distro kernel packages where the config files are built using a combination of smaller config files. The patch's author AFAIK is Arjan van de Ven. Arjan, please add a Signed-off-by if you're the original ...

+loose_nonint_oldconfig: $(obj)/conf + $< -B $(Kconfig) ... + case 'B': + input_mode = dont_ask_dont_tell; I would prefer a fixed value, like 86. or 11. or a useful printf text message. -- ~Randy --

This patch has been around for a long time in Fedora and Red Hat Enterprise Linux kernels and it may be useful for others. The nonint_oldconfig target will fail and print the unset config options while loose_nonint_oldconfig will simply let the config option unset. They're useful in distro kernel packages where the config files are built using a combination of smaller config files. Arjan van de Ven wrote the initial nonint_config and Roland McGrath added ...

Hi, I am not certain whether the stacktrace I received is just intentional to attract developer eyes or whether this is actually a false alarm: mounting USB mass storage device media always takes a long while. This is a P4-M laptop with Kouwell 7004 FW/USB2.0 PCMCIA card. Comments? Thanks, martin pcmcia_socket pcmcia_socket1: pccard: CardBus card inserted into slot 1 pci 0000:07:00.0: reg 14: [mem 0x00000000-0x000000ff] pci 0000:07:00.0: reg 20: [io 0xfce0-0xfcff] pci 0000:07:00.0: ...

As far as lockdep is concerned, we are not in an RCU read-side critical Very strange indeed. One question -- is it possible that your kernel does not match your source code? I freely admit that it is extremely unlikely that such a mismatch would happen to land on an rcu_dereference(), but... Another unlikely possibility is that an interrupt occurred between the rcu_read_lock() and the rcu_dereference(), and that this interrupt Color me confused!!! --

This patch implements code to handle ibs interrupts. If ibs data is available a raw perf_event data sample is created and sent back to the userland. Currently only the data is stored only in the raw data, but this could be extended in a later patch by generating generic event data such as the rip from the ibs sampling data. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/include/asm/msr-index.h | 3 ++ arch/x86/kernel/cpu/perf_event_amd.c | 65 ...

There are some pmu events such as Intel BTS or AMD IBS that do not fit in the generic or fixed performance counter scheme. The upper bits starting at bit 48 of the 64 bit counter mask are reserved for such events and can be used to handle them. The events can be identified by its index in the bit mask. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/include/asm/perf_event.h | 3 ++- arch/x86/kernel/cpu/perf_event.c | 6 +++--- ...

This implements the perf nmi handler for ibs interrupts. The code was copied from oprofile and should be merged somewhen. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/kernel/cpu/perf_event.c | 10 ++++ arch/x86/kernel/cpu/perf_event_amd.c | 87 ++++++++++++++++++++++++++++++++++ 2 files changed, 97 insertions(+), 0 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index a42d033..8f9674f 100644 --- ...

The perfctr setup calls are in the corresponding .hw_config() functions now. This makes it possible to introduce config functions for other pmu events that are not perfctr specific. Also, all of a sudden the code looks much nicer. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/kernel/cpu/perf_event.c | 9 ++------- arch/x86/kernel/cpu/perf_event_p4.c | 2 +- 2 files changed, 3 insertions(+), 8 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event.c ...

This patch implements IBS for perf_event. It extends the AMD pmu to handle model specific IBS events. With the attr.model_spec bit set we can setup hardware events others than generic performance counters. A special PMU 64 bit config value can be passed through the perf_event interface. The concept of PMU model-specific arguments was practiced already in Perfmon2. The type of event (8 bits) is determinded from the config value too, bit 32-39 are reserved for this. There are two types of IBS ...

To reuse this function for events with different enable bit masks, this mask is part of the function's argument list now. The function will be used later to control ibs events too. Signed-off-by: Robert Richter <robert.richter@amd.com> --- arch/x86/kernel/cpu/perf_event.c | 9 +++++---- arch/x86/kernel/cpu/perf_event_intel.c | 5 +++-- 2 files changed, 8 insertions(+), 6 deletions(-) diff --git a/arch/x86/kernel/cpu/perf_event.c b/arch/x86/kernel/cpu/perf_event.c index ...

This patch introduces a flag to mark events as model specific. The flag can be used to setup hardware events other than generic performance counters by passing special config data to the pmu. The data can be interpreted different from generic events and can be used for other purposes. The concept of PMU model-specific arguments was practiced already in Perfmon2. Perfmon2 provides an interface to pass model specific config values to the pmu and receive event specific samples back. ...

Hey Rakesh, I guess we are trying to move away from the pci mapping functions move to the dma ones. On your next submission, could you fix those up too? --

During the last filesystem sync prior to rebooting, UBI/UBIFS typically schedules a flash erase operation. It is important to ensure that this operation completes before restarting the system, for the following reasons: 1) Some systems do not toggle the flash reset pin upon rebooting, so if the flash is stuck in erase/program mode the bootloader will not come back up. This is especially likely on NOR flash devices since the erase time can be 1-2 seconds. 2) While UBI is able to recover ...

On Wed, 31 Mar 2010 08:48:24 -0400 What you describe here is an utter catastrophe. Strangely, your email appears to not have come out on the linux-kernel So something between 2.6.32.3 and 2.6.32.8 inclusive rebroke the kernel. That's useful info. Looking at the changelogs, the only thing I can immediately see in the which seems unlikely. I'm seeing just one device-mapper change whcih went in over that Which filesystem are you using there? --

It looks to me bdi is waiting for writeback task to finish, yet the processes are frozen, so this never happens, and hang. And I can confirm this always happens. Without MMC_UNSAFE_RESUME, this happens when suspending where the mmc core tries to remove the card. With MMC_UNSAFE_RESUME, this happens when resume if the card removed during suspend. Though the root cause looks to me lies in the del_gendisk() not safe to be called within suspend context, and a clean fix might be somewhere ...

Hello, Since 2.6.34-rc*, I have a regression on alsa which prevents the sound to be played correctly. When playing, the music goes too fast, skipping some parts. Typically, it's very easy to reproduce by doing: time mplayer -endpos 30 sound-file-which-lasts-more-than-thirty-sec.mp3 If the wall clock is less than 30s, you have the bug. With my intel-hda (AD1981), it's reliably reproducible: it gives ~27s, instead of the normal ~31s. After bisection, it turns out that it is ...

Hello I was thinking about adding a LCD to my PC so I thought that the panel.c driver which just went to 2.6.34 would be helpful. The problem is there is no documentation. I can get quite detailed documentation for at least some LCDs that are sold around here but there is not enough documentation for the driver to determine if the LCD in question would be compatible with the driver and with which protocol. Detailed explanation of the parameters would be appreciated. For example, there are ...

There's a period of 10 ticks where calc_load_tasks is updated by all the cpus for the load avg. Usually all the cpus do this during the first tick. If any cpus go idle, calc_load_tasks is decremented accordingly. However, if they wake up calc_load_tasks is not incremented. Thus, if cpus go idle during the 10 tick period, calc_load_tasks may be decremented to a non-representative value. This issue can lead to systems having a load avg of exactly 0, even though the real load avg could theoretically ...

This adds the rbd under fs/ceph. The rados block device is based on the drivers/block/osdblk.c. It allows mapping of rados (ther ceph block layer) objects over a block device. Each device has a metadata object, and data is being striped across different objects. Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net> --- fs/ceph/Makefile | 3 +- fs/ceph/rbd.c | 1224 ++++++++++++++++++++++++++++++++++++++++++++++++++++++ fs/ceph/rbd.h | 8 + fs/ceph/super.c | 8 + 4 files ...

Removed some functions' static declarations, separated mount operation to __open_session and open_root_dentry for clients that don't need the latter (rbd). Added other helper functions that will be used later in the rbd. Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net> --- fs/ceph/file.c | 46 ++++++++++++++++ fs/ceph/osd_client.h | 1 + fs/ceph/super.c | 142 ++++++++++++++++++++++++++++++++++++++----------- fs/ceph/super.h | 29 +++++++++-- 4 files changed, 182 ...

This is essential, as for the rados block device we'll need to run in different contexts that would need flags that are other than GFP_NOFS. Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net> --- fs/ceph/caps.c | 2 +- fs/ceph/file.c | 10 +++++----- fs/ceph/mds_client.c | 11 ++++++----- fs/ceph/messenger.c | 10 +++++----- fs/ceph/messenger.h | 2 +- fs/ceph/mon_client.c | 15 ++++++++------- fs/ceph/msgpool.c | 4 ++-- fs/ceph/osd_client.c | 8 ...

This capability is being added so that we wouldn't need to copy the data from the rados block device. Signed-off-by: Yehuda Sadeh <yehuda@hq.newdream.net> --- fs/ceph/messenger.c | 175 +++++++++++++++++++++++++++++++++++++++++-------- fs/ceph/messenger.h | 3 + fs/ceph/osd_client.c | 14 ++++- fs/ceph/osd_client.h | 4 +- 4 files changed, 164 insertions(+), 32 deletions(-) diff --git a/fs/ceph/messenger.c b/fs/ceph/messenger.c index b6cff8e..3f77210 100644 --- ...