Ian (and others), here's a three-patch series that uses the doubly linked list to do your mlock() case hopefully correctly. NOTE! It's untested. The first patch (which is the slightly scary one) is tested to some degree, the two other ones I checked that they compile, but that's it. I'm not going to apply them to my main tree unless they get testing and acks. And as mentioned, I've not done any of the changes that having a vm_prev pointer can allow in other places. Comments? Fixes? ...

Standardize logging messages from printk(KERN_<level> "%s: " fmt , wiphy_name(foo), args); to wiphy_<level>(foo, fmt, args); Signed-off-by: Joe Perches <joe@perches.com> --- net/mac80211/cfg.c | 6 +++--- net/mac80211/debugfs.c | 6 ++++-- net/mac80211/ibss.c | 4 ++-- net/mac80211/iface.c | 6 ++---- net/mac80211/key.c | 14 ++++++-------- net/mac80211/main.c | 15 +++++++-------- net/mac80211/mlme.c | 17 +++++++++-------- ...

Since we don't change the tuple in the original direction, we can save it in ct->tuplehash[IP_CT_DIR_REPLY].hnode.pprev for __nf_conntrack_confirm() use. __hash_conntrack() is split into two steps: ____hash_conntrack() is used to get the raw hash, and __hash_bucket() is used to get the bucket id. In SYN-flood case, early_drop() doesn't need to recompute the hash again. Signed-off-by: Changli Gao <xiaosuo@gmail.com> --- v5: respin it due to the change of 1/2. v4: init rnd when allocating ...

Hi, LTTng 0.224 fixes socket instrumentation in the LTTng git tree: the patch hunk management seems to differ slightly between quilt and git (hunks were at the wrong offset when I rebased with quilt, but there was no fuzz), so only the git tree showed this problem. I guess quilt and git call patch with slightly different parameters. I simply refreshed the patches with quilt and everything is fine now. Mathieu -- Mathieu Desnoyers Operating System Efficiency R&D Consultant EfficiOS ...

This patch converts arm to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - ARM defines its own value for FIOQSIZE, asm-generic/ioctls.h keeps it - The generic version adds support for termiox Cc: Russell King <linux@arm.linux.org.uk> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Jeff Mahoney <jeffm@suse.com> --- arch/arm/include/asm/ioctls.h | 83 ...

This patch converts avr32 to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - The generic version adds support for termiox Cc: Haavard Skinnemoen <hskinnemoen@atmel.com> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Jeff Mahoney <jeffm@suse.com> --- arch/avr32/include/asm/ioctls.h | 86 ---------------------------------------- 1 file changed, 1 insertion(+), 85 ...

This patch converts h8300 to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - H8300 defines its own value for FIOQSIZE, asm-generic/ioctls.h keeps it - The generic version adds TIOCSRS485 and TIOGSRS485, but are unused by any driver available on this architecture. - The generic version adds support for termiox Cc: Yoshinori Sato <ysato@users.sourceforge.jp> Cc: Greg Kroah-Hartman ...

This patch converts m68k to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - m68k defines its own value for FIOQSIZE, asm-generic/ioctls.h keeps it - The generic version adds TIOCSRS485 and TIOCGRS485m which are unused by any driver available on this architecture. - The generic version adds support for termiox Cc: Geert Uytterhoeven <geert@linux-m68k.org> Cc: Roman Zippel ...

Pointless, this was removed by the other architecture, and the same change should be done here, possibly in a separate patch. Arnd --

This patch converts ia64 to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - The generic version adds TIOCSRS485 and TIOCGRS485, which are unused by any driver available on this architecture. - The generic version adds support for termiox Cc: Tony Luck <tony.luck@intel.com> Cc: Fenghua Yu <fenghua.yu@intel.com> Signed-off-by: Jeff Mahoney <jeffm@suse.com> --- ...

This patch converts m32r to use asm-generic/ioctls.h instead of its own version. The differences between the arch-specific version and the generic version are as follows: - The generic version adds TIOCGRS485 and TIOCGRS485, which are unused by any driver available on this architecture. - The generic version adds support for termiox Cc: Hirokazu Takata <takata@linux-m32r.org> Cc: Greg Kroah-Hartman <gregkh@suse.de> Signed-off-by: Jeff Mahoney <jeffm@suse.com> --- ...

CURRENT http://cworthylinux.googlecode.com/files/cworthy-08-20-2010.tar.gz REPOSITORIES http://code.google.com/p/cworthylinux/ http://sourceforge.net/projects/opencworthy/ FIXES - add DOS makefiles and test on DJGPP compiler and DOS - add Windows makefiles and test with Microsoft 7 SDK on Vista - add Pause/Active states to CWGEN packet generator on Linux - add more stats into in cwmon packet generator console on Linux - test on 2.6.35.1 and 2.6.35.2 --

From 9d7067af5b1b157e653c58f2f98553442aa014e5 Mon Sep 17 00:00:00 2001 From: Tracey Dent <Tdent48227@gmail.com> Date: Fri, 20 Aug 2010 10:34:06 -0400 Subject: [PATCH 5/8] Staging: rtl8187se: r8180_hw: fixed alot checkpatch.pl issues Fixed numerous coding style issues using checkpatch.pl Signed-off-by: Tracey Dent <tdent48227@gmail.co, --- drivers/staging/rtl8187se/r8180_hw.h | 432 +++++++++++++++++----------------- 1 files changed, 221 insertions(+), 211 deletions(-) diff --git ...

From d786a0d10b21b4a3b13053f7b89d7c3ed3457c8a Mon Sep 17 00:00:00 2001 From: Tracey Dent <Tdent48227@gmail.com> Date: Fri, 20 Aug 2010 13:18:09 -0400 Subject: [PATCH 7/8] Staging: rtl8187se: r8180_wx: fixed alot of checkpatch.pl issues Fixed numerous coding style issues using checkpatch.pl Signed-off-by: Tracey Dent <tdent48227@yahoo.com> --- drivers/staging/rtl8187se/r8180_wx.c | 722 +++++++++++++++++----------------- 1 files changed, 354 insertions(+), 368 deletions(-) diff --git ...

From 70dfb5566dca4997d5e886280d110715bcd787e5 Mon Sep 17 00:00:00 2001 From: Tracey Dent <Tdent48227@gmail.com> Date: Fri, 20 Aug 2010 09:47:59 -0400 Subject: [PATCH 4/8] Staging: rtl8187se: r8180_dm.h: fixed alot checkpatch.pl issues Fixed numerous coding style issues using checkpatch.pl Signed-off-by: Tracey Dent <tdent48227@gmail.com> --- drivers/staging/rtl8187se/r8180_dm.h | 12 ++++++------ 1 files changed, 6 insertions(+), 6 deletions(-) diff --git ...

I have fixed numerous Linux kernel coding style issues using checkpatch.pl with the help of the video that Greg Kroah-Hartman lecture on about writing and sending your first patch. I corrected 3260 warnings, 236 errors, and deleted 231 lines of unnecessary code which still keeps the code readability. -- Tracey Dent --

From 73dfcd936fcacb6f1dce184e21b177c9fa4797d5 Mon Sep 17 00:00:00 2001 From: Tracey Dent <Tdent48227@gmail.com> Date: Thu, 19 Aug 2010 16:13:48 -0400 Subject: [PATCH 1/8] Staging: rtl8187se: r8180: fixed alot checkpatch.pl issues Fixed numerous coding style issues using checkpatch.pl Signed-off-by: Tracey Dent <tdent48227@gmail.com> --- drivers/staging/rtl8187se/r8180.h | 537 ++++++++++++++++++------------------- 1 files changed, 265 insertions(+), 272 deletions(-) diff --git ...

diff --git a/Makefile b/Makefile index 3cf2397..554683d 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 35 -EXTRAVERSION = .2 +EXTRAVERSION = .3 NAME = Sheep on Meth # *DOCUMENTATION* diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c index 227b044..ce9c6c2 100644 --- a/arch/x86/kernel/cpu/vmware.c +++ b/arch/x86/kernel/cpu/vmware.c @@ -23,6 +23,7 @@ #include <linux/dmi.h> #include <linux/module.h> +#include ...

diff --git a/Makefile b/Makefile index 335df5f..10c5a85 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 34 -EXTRAVERSION = .4 +EXTRAVERSION = .5 NAME = Sheep on Meth # *DOCUMENTATION* diff --git a/arch/x86/kernel/cpu/vmware.c b/arch/x86/kernel/cpu/vmware.c index 562d5f0..e44e02d 100644 --- a/arch/x86/kernel/cpu/vmware.c +++ b/arch/x86/kernel/cpu/vmware.c @@ -23,6 +23,7 @@ #include <linux/dmi.h> #include <linux/module.h> +#include ...

diff --git a/Makefile b/Makefile index 64e538c..ad4d191 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 32 -EXTRAVERSION = .19 +EXTRAVERSION = .20 NAME = Man-Eating Seals of Antiquity # *DOCUMENTATION* diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c index 366b101..899145d 100644 --- a/fs/proc/task_mmu.c +++ b/fs/proc/task_mmu.c @@ -206,6 +206,7 @@ static void show_map_vma(struct seq_file *m, struct vm_area_struct *vma) int flags ...

diff --git a/Makefile b/Makefile index 5382c55..948de60 100644 --- a/Makefile +++ b/Makefile @@ -1,7 +1,7 @@ VERSION = 2 PATCHLEVEL = 6 SUBLEVEL = 27 -EXTRAVERSION = .51 +EXTRAVERSION = .52 NAME = Trembling Tortoise # *DOCUMENTATION* diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c index 3384255..9d3c576 100644 --- a/arch/x86/mm/fault.c +++ b/arch/x86/mm/fault.c @@ -589,6 +589,7 @@ void __kprobes do_page_fault(struct pt_regs *regs, unsigned long error_code) unsigned long ...

Hi Linus, The following changes since commit 763008c4357b73c8d18396dfd8d79dc58fa3f99d: Merge branch 'bugfixes' of git://git.linux-nfs.org/projects/trondmy/nfs-2.6 (2010-08-18 15:45:23 -0700) are available in the git repository at: git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip.git x86-fixes-for-linus Borislav Petkov (1): x86, hotplug: Serialize CPU hotplug to avoid bringup concurrency issues Daniel Kiper (1): x86, apic: Fix apic=debug boot crash H. ...

hvc_console_print() calls the HVC client driver's put_chars() callback to write some characters to the console. If the callback returns 0, that indicates that no characters were written (perhaps the output buffer is full), but hvc_console_print() treats that as an error and discards the rest of the buffer. So change hvc_console_print() to just loop and call put_chars() again if it returns a 0 return code. This change makes hvc_console_print() behave more like hvc_push(), which does check ...

Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- Documentation/RCU/checklist.txt | 23 ++++++++++++++++------- 1 files changed, 16 insertions(+), 7 deletions(-) diff --git a/Documentation/RCU/checklist.txt b/Documentation/RCU/checklist.txt index c7c6788..0c134f8 100644 --- a/Documentation/RCU/checklist.txt +++ b/Documentation/RCU/checklist.txt @@ -218,13 +218,22 @@ over a rather long period of time, but improvements are always welcome! include: a. Keeping a count of ...

When using a kernel debugger, a long sojourn in the debugger can get you lots of RCU CPU stall warnings once you resume. This might not be helpful, especially if you are using the system console. This patch therefore allows RCU CPU stall warnings to be suppressed, but only for the duration of the current set of grace periods. This differs from Jason's original patch in that it adds support for tiny RCU and preemptible RCU, and uses a slightly different method for suppressing the RCU CPU stall ...

Combine the duplicate definitions of ULONG_CMP_GE(), ULONG_CMP_LT(), and rcu_preempt_depth() into include/linux/rcupdate.h. Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> --- include/linux/rcupdate.h | 15 +++++++++++++++ include/linux/rcutiny.h | 7 ------- include/linux/rcutree.h | 6 ------ kernel/rcutiny_plugin.h | 4 ---- kernel/rcutree.h | 3 --- 5 files changed, 15 insertions(+), 20 deletions(-) diff --git a/include/linux/rcupdate.h ...

The CONFIG_PREEMPT_RCU kernel configuration parameter was recently re-introduced, but as an indication of the type of RCU (preemptible vs. non-preemptible) instead of as selecting a given implementation. This commit uses CONFIG_PREEMPT_RCU to combine duplicate code from include/linux/rcutiny.h and include/linux/rcutree.h into include/linux/rcupdate.h. This commit also combines a few other pieces of duplicate code that have accumulated. Signed-off-by: Paul E. McKenney ...

fails as in an error, not just a warning? I see this: drivers/video/backlight/88pm860x_bl.c:24:1: warning: "CURRENT_MASK" redefined --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

This patch removes the following section mismatch warning, by moving the function rndis_init() from .init.text to .text. WARNING: vmlinux.o(.text+0x1aeca5a): Section mismatch in reference from the function rndis_bind_config() to the function .init.text:rndis_init() The function rndis_bind_config() references the function __init rndis_init(). This is often because rndis_bind_config lacks a __init annotation or the annotation of rndis_init is wrong. Signed-off-by: Henrik Kretzschmar ...

This patch moves the q40_fix and q40_var structures from .init.data to .devinit.data. This is where now the probe function resides, which only uses them. Signed-off-by: Henrik Kretzschmar <henne@nachtwindheim.de> --- This patch is against Linus tree and is not compile tested. It would be nice if someone with a m68k toolchain could test this and tell if it works like expected. drivers/video/q40fb.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git ...

Good day, My working partner has helped me to send your first payment of US$7,500 to you as instructed by Mr. David Cameron and will keep sending you US$7,500 twice a week until the payment of (US$360,000) is completed within six months and here is the information below: MONEY TRANSFER CONTROL NUMBER (MTCN): 522-905-9427 SENDER'S NAME: Mr. Mark Daniel AMOUNT: US$7,500 To track your funds forward Western Union Money Transfer agent your Full Names and Mobile Number via Email ...

Hi Hari, From: ext Hari Kanigeri <h-kanigeri2@ti.com> Subject: [PATCH] omap:iommu-load cam register before flushing the entry --

The S3C64xx SPI driver requires the machine to call s3c64xx_spi_set_info() to select a few options, including the clock to use for the SPI controller. If this is not done then a NULL will be passed as the clock name for clk_get(), causing an obscure crash. Guard against this and other missing configuration by validating that the clock name has been filled in in the platform data that ets passed in. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- drivers/spi/spi_s3c64xx.c | ...

Since we don't change the tuple in the original direction, we can save it in ct->tuplehash[IP_CT_DIR_REPLY].hnode.pprev for __nf_conntrack_confirm() use. __hash_conntrack() is split into two steps: ____hash_conntrack() is used to get the raw hash, and __hash_bucket() is used to get the bucket id. In SYN-flood case, early_drop() doesn't need to recompute the hash again. Signed-off-by: Changli Gao <xiaosuo@gmail.com> --- v4: init rnd when allocating conntrack. v3: define static variable rnd ...

Sandybridge requires 36bit dma mask, but the current code checks only against i965, thus it gives Oops with i915 probing on 32bit machine: nommu_map_sg: overflow 14a000000+4096 of device mask ffffffff [drm:drm_agp_bind_pages] *ERROR* Failed to bind AGP memory: -12 BUG: unable to handle kernel paging request at fffffff8 IP: [<f7fac57f>] i915_gem_evict_something+0xef/0x230 [i915] ... Signed-off-by: Takashi Iwai <tiwai@suse.de> --- drivers/char/agp/intel-agp.c | 3 ++- 1 ...

Hello, after installing 2.6.36-rc1 my system gets stuck during "Mounting root..." I'm using an initramfs to mount the root fs, because I'm using a stacked setup with md (raid1) -> dm-crypt -> xfs. Strange side effect: sometimes the cursor stops blinking for a few seconds, but then resumes blinking. Each of these blinking stalls are accompanied by a RCU stall message. From the serial console: [ 8.039603] Freeing unused kernel memory: 564k freed [ 8.049070] Write protecting the ...

I'll test tip later today to see if I can reproduce it. Cheers, Don

Sad to say, that won't happen. Both my amd box and nehalem box have to many issues with your master branch. The amd box BUGs in perf_event_nmi_handler on the new code trying to run 'perf top' arch/x86/kernel/cpu/perf_event.c::perf_event_nmi_handler:1250 ((__get_cpu_var(nmi).marked == this_nmi) && The BUG is attached below. I can't figure out why And my Nehalem box won't even boot with the that kernel, not even to console for some reason. Then bisecting revealed that in 2.6.35 ...

Hmm... so to accept a few more SYN packets per second in SYNFLOOD attack, we slow a bit normal operations ? (adding one test on each packet going through conntrack) If yes (I dont think we should, hackers are stronger than you anyway, just face it) v4: __read_mostly on nf_conntrack_rnd What would happen if we let the initialization of nf_conntrack_rnd only in the insertion case (like currently done) ? Only the first packet received on the machine/conntrack might be hashed on a ...

Since we don't change the tuple in the original direction, we can save it in ct->tuplehash[IP_CT_DIR_REPLY].hnode.pprev for __nf_conntrack_confirm() use. __hash_conntrack() is split into two steps: ____hash_conntrack() is used to get the raw hash, and __hash_bucket() is used to get the bucket id. In SYN-flood case, early_drop() doesn't need to recompute the hash again. Signed-off-by: Changli Gao <xiaosuo@gmail.com> --- v3: define static variable rnd out of the function ...

*NAME. *COUNTRY. --

[ executive summary: trying to explain why static variable declarations within the body of functions is bad in kernel code. ] We are talking about a static variable usable only within a single file, I'm talking about good practice to help code review. This is way more important than the potential "encapsulation" benefit of hiding global state (a static variable) within the body of a function. I remember that Andrew Morton has strong opinions about this, and I remember being in complete ...

Commit-ID: 4c1c952e37c7511a52f617ceddbc10c855d45d7b Gitweb: http://git.kernel.org/tip/4c1c952e37c7511a52f617ceddbc10c855d45d7b Author: Arnaldo Carvalho de Melo <acme@redhat.com> AuthorDate: Thu, 12 Aug 2010 12:37:51 -0300 Committer: Arnaldo Carvalho de Melo <acme@redhat.com> CommitDate: Thu, 19 Aug 2010 19:44:18 -0300 perf ui browser: Add routines to compactly specify exit keys This makes the usual idiom for specifying a series of key codes to exit ui_browser__run() for specialized ...

Please pull from: master.kernel.org:/pub/scm/linux/kernel/git/lethal/sh-2.6.git Which contains: Andrew Murray (1): sh: Use __GFP_ZERO for dma_generic_alloc_coherent(). Guennadi Liakhovetski (3): dmaengine: initialise DMA engine before MMC sh: move a debug printk() to a more meaningful location in the clock driver sh: remove bogus highest / lowest logic from clock rate rounding Hitoshi Mitake (1): sh: SH-2007 board support. Kulikov Vasiliy (1): ...

But title....this was [PATCH 3/5]. Sorry. -kame --

I have an idea to remove page_cgroup->page pointer, 8bytes reduction per page. But it will be after this work. == From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Now, addresses of memory cgroup can be calculated by their ID without complex. This patch relplaces pc->mem_cgroup from a pointer to a unsigned short. On 64bit architecture, this offers us more 6bytes room per page_cgroup. Use 2bytes for blkio-cgroup's page tracking. More 4bytes will be used for some light-weight concurrent ...

No changes from v4. == From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> Preparing for adding new status arounf file caches.(dirty, writeback,etc..) Using a unified macro and more generic names. All counters will have the same rule for updating. Signed-off-by: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> --- include/linux/memcontrol.h | 24 ++++++++++++++++++++++ include/linux/page_cgroup.h | 19 ++++++++++++------ mm/memcontrol.c | 46 ...

Added a rb_root_init() function which initialises a rb_root structure as a red-black tree with at most one element. The rationale is that using rb_root_init(root, node) is more straightforward and cleaner then first initialising and empty tree followed by an insert operation. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> --- include/linux/rbtree.h | 11 +++++++++++ 1 files changed, 11 insertions(+), 0 ...

The Contiguous Memory Allocator framework is a set of APIs for allocating physically contiguous chunks of memory. Various chips require contiguous blocks of memory to operate. Those chips include devices such as cameras, hardware video decoders and encoders, etc. The code is highly modular and customisable to suit the needs of various users. Set of regions reserved for CMA can be configured per-platform and it is easy to add custom allocator algorithms if one has such ...

This patch adds a "cma" misc device which lets user space use the CMA API. This device is meant for testing. A testing application is also provided. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> --- drivers/misc/Kconfig | 8 + drivers/misc/Makefile | 1 + drivers/misc/cma-dev.c | 185 ++++++++++++++++++++++++ include/linux/cma.h | 30 ++++ tools/cma/cma-test.c | 373 ...

Added the CMA initialisation code to two Samsung platforms. Signed-off-by: Michal Nazarewicz <m.nazarewicz@samsung.com> Signed-off-by: Kyungmin Park <kyungmin.park@samsung.com> --- arch/arm/mach-s5pv210/mach-aquila.c | 31 +++++++++++++++++++++++++++++++ arch/arm/mach-s5pv210/mach-goni.c | 31 +++++++++++++++++++++++++++++++ 2 files changed, 62 insertions(+), 0 deletions(-) diff --git a/arch/arm/mach-s5pv210/mach-aquila.c b/arch/arm/mach-s5pv210/mach-aquila.c index 0dda801..3561859 ...

x86, mem-hotplug: update all PGDs for direct mapping and vmemmap mapping changes on 64bit. When memory hotplug-adding happens for a large enough area that a new PGD entry is needed for the direct mapping, the PGDs of other processes would not get updated. This leads to some CPUs oopsing like below when they have to access the unmapped areas. [ 1139.243192] BUG: soft lockup - CPU#0 stuck for 61s! [bash:6534] [ 1139.243195] Modules linked in: ipv6 autofs4 rfcomm l2cap crc16 bluetooth rfkill ...

Thanks, applied. And sorry for breaking your previous patch. Michal --

How about the names nr_dirty_accumulated and nr_writeback_accumulated? It seems more consistent, for both the interface and code (see below). I'd prefer the name "vmstat" over "writebackstat", and propose to migrate items from /proc/zoneinfo over time. zoneinfo is a terrible interface for scripting. Also, are there meaningful usage of per-node writeback stats? The numbers are naturally per-bdi ones instead. But if we plan to expose them for each bdi, this patch will need to be ...

This may cost cacheline. Thanks, Fengguang --

'nr_entered_writeback' seems ok. but nr_dirtied seems a bit easy confusable with 'nr_dirty'. Can you please choice more clear meaningful name? Otherwise looks good to me. Reviewed-by: KOSAKI Motohiro <kosaki.motohiro@jp.fujitsu.com> --

Patch #1 sets up some helper functions for account_page_dirty Patch #2 sets up some helper functions for account_page_writeback Patch #3 adds writeback visibility in /proc/vmstat Patch #4 add writeback thresholds to /proc/vmstat To help developers and applications gain visibility into writeback behaviour this patch adds two counters to /proc/vmstat. # grep nr_dirtied /proc/vmstat nr_dirtied 3747 # grep nr_entered_writeback /proc/vmstat nr_entered_writeback 3618 These ...

This allows code outside of the mm core to safely manipulate page writeback state and not worry about the other accounting. Not using these routines means that some code will lose track of the accounting and we get bugs. Signed-off-by: Michael Rubin <mrubin@google.com> --- fs/nilfs2/segment.c | 2 +- include/linux/mm.h | 1 + mm/page-writeback.c | 13 ++++++++++++- 3 files changed, 14 insertions(+), 2 deletions(-) diff --git a/fs/nilfs2/segment.c b/fs/nilfs2/segment.c index ...

This allows code outside of the mm core to safely manipulate page state and not worry about the other accounting. Not using these routines means that some code will lose track of the accounting and we get bugs. This has happened once already. Signed-off-by: Michael Rubin <mrubin@google.com> --- fs/ceph/addr.c | 8 +------- mm/page-writeback.c | 1 + 2 files changed, 2 insertions(+), 7 deletions(-) diff --git a/fs/ceph/addr.c b/fs/ceph/addr.c index 5598a0d..420d469 100644 --- ...

From: Johannes Berg <johannes.berg@intel.com> Currently, blinking LEDs can be awkward because it is not guaranteed that all LEDs implement blinking. The trigger that wants it to blink then needs to implement its own timer solution. Rather than require that, make the core always implement LED "blinkability" with a timer implementation in the core. The timer trigger then becomes a very trivial one, and all code using LEDs can rely on them to be able to blink. Signed-off-by: Johannes Berg ...

From: Nicholas Bellinger <nab@linux-iscsi.org> This patch adds support for 4096, 2048 and 1024 byte block_size / sector conversion from incoming struct se_task->task_lba from native TCM SCSI sector size into our the iblock_map_task_SG() caller. This is required as for each TCM struct se_task -> struct bio I/O descriptor will always need to be assuming 512-byte sectors into Linux/Block for submit_bio(), so when iblock_map_task_SG() is called we increment block_lba in 512 byte units from ...

Hi, This patch fixes the return value when the cgroup hierarchy for blkio control groups is deeper than two levels. Right now EINVAL is returned. This patch replaces EINVAL with more appropriate EPERM to align with mkdir system call return values. This was discussed between Vivek and Daniel sometime back. Please consider this patch for inclusion in 2.6.36. Thanks Ciju

Alex Shi found a regression when doing ffsb test. The test has several threads, and each thread creates a small file, write to it and then delete it. ffsb reports about 20% regression and Alex bisected it to 43d2932d88e4. The test will call __mark_inode_dirty 3 times. without this commit, we only take inode_lock one time, while with it, we take the lock 3 times with flags ( I_DIRTY_SYNC,I_DIRTY_PAGES,I_DIRTY). Perf shows the lock contention increased too much. Below proposed patch fixes it. fs ...

This patch introduces the new user-space API, <ncr.h>. Quick overview: * open("/dev/crypto") to get a FD, which acts as a namespace for key and session identifiers. * ioctl(NCRIO_KEY_INIT) to allocate a key object; then generate the key material inside the kernel, load a plaintext key, unwrap a key, or derive a key. Similarly the key material can be copied out of the kernel or wrapped. * ioctl(NCRIO_SESSION_INIT) to allocate a crypto session (to encrypt, decrypt, hash, sign, ...

Main entry points: NCR_GET_INPUT_ARGS: Read a fixed struct and any attached attributes from userspace NCR_GET_INPUT_ARGS_NO_OUTPUT: Same as above, and inform the users the kernel will attach no additional attributes. NCR_OUT_INIT/ncr_out_free: Allocate and free a context that allows operation handlers to return attributes to userspace. ncr_out_finish: Write the attributes from the context to userspace. Split like this so that only NCR_OUT_INIT (in future "ncr.c") deals ...

This encapsulates allocation/deallocation of all necessary objects, dealing with the asynchronous nature of ablkcipher/ahash. Long term, I'm not quite sure this layer makes sense; For now, it provides a truly simple API for internal callers in libtomcrypt, at least. --- crypto/userspace/Makefile | 2 +- crypto/userspace/cryptodev_cipher.c | 339 +++++++++++++++++++++++++++++++++++ crypto/userspace/cryptodev_main.c | 13 ++ 3 files changed, 353 insertions(+), 1 ...

This includes: - ncr_session_init - ncr_session_update - ncr_session_final - ncr_session_once The ncr_session_*_from_nla() functions are separate from the main session code because they belong into ncr.c along with other code that deals directly with user-space data structures and handles CONFIG_COMPAT. --- crypto/userspace/ncr-sessions.c | 953 +++++++++++++++++++++++++++++++++++++++ crypto/userspace/ncr.c | 86 ++++ 2 files changed, 1039 insertions(+), 0 deletions(-) diff ...

This includes: - ncr_key_init - ncr_key_deinit - ncr_key_export (as plaintext) - ncr_key_import - ncr_key_generate - ncr_key_generate_pair - ncr_key_derive - ncr_key_get_info and supporting infrastructure. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-key.c | 689 ++++++++++++++++++++++++++++++++++++++++++++ 2 files changed, 690 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-key.c diff --git a/crypto/userspace/Makefile ...

This includes: - ncr_key_wrap - ncr_key_unwrap - ncr_key_storage_wrap - ncr_key_storage_unwrap --- crypto/userspace/Makefile | 5 +- crypto/userspace/ncr-key-storage.c | 136 +++++++ crypto/userspace/ncr-key-wrap.c | 763 ++++++++++++++++++++++++++++++++++++ crypto/userspace/ncr.c | 29 ++ 4 files changed, 931 insertions(+), 2 deletions(-) create mode 100644 crypto/userspace/ncr-key-storage.c create mode 100644 crypto/userspace/ncr-key-wrap.c create mode ...

Add basic Diffie-Hellman implementation, because it is not provided by libtomcrypt. Finally, add an algorithm-independent pubkey interface that encapsulates the separate pubkey algorithm implementations. --- crypto/userspace/Makefile | 2 +- crypto/userspace/ncr-dh.c | 282 +++++++++++++++++++ crypto/userspace/ncr-pk.c | 659 +++++++++++++++++++++++++++++++++++++++++++++ 3 files changed, 942 insertions(+), 1 deletions(-) create mode 100644 crypto/userspace/ncr-dh.c create mode 100644 ...

No use postponing it any more I'm afraid. (Reviewing this in detail is probably premature, we are considering replacing the implementation by something based on libgcrypt, which is more actively maintained and has been probably more thorouhgly examined for vulnerabilities.) --- crypto/userspace/Makefile | 31 ++- crypto/userspace/libtommath/LICENSE | 4 + crypto/userspace/libtommath/bn_error.c | 47 +++ ...

Why not using fixed-size fit-all members? struct ncr_session_input_data { __u64 data; /* user pointer, cast to/from u64 */ __u32 data_size; /* or __u64? */ }; struct ncr_session_output_buffer { __u64 buffer; __u64 result_size_ptr; /* can't this be a direct output member? */ __u32 buffer_size; /* or __u64? */ }; And then get rid of all the COMAPT code paths. -- Stefan Richter -=====-==-=- =--- =-=-- http://arcgraph.de/sr/ --

--- crypto/Kconfig | 5 +++++ crypto/Makefile | 2 ++ crypto/userspace/Makefile | 1 + 3 files changed, 8 insertions(+), 0 deletions(-) create mode 100644 crypto/userspace/Makefile diff --git a/crypto/Kconfig b/crypto/Kconfig index 81c185a..022768a 100644 --- a/crypto/Kconfig +++ b/crypto/Kconfig @@ -31,6 +31,11 @@ config CRYPTO_FIPS this is. Note that CRYPTO_ANSI_CPRNG is requred if this option is selected +config CRYPTO_USERSPACE + tristate ...

--- crypto/userspace/cryptodev_main.c | 87 +++++++++++++++++++++++++++++++++++++ 1 files changed, 87 insertions(+), 0 deletions(-) diff --git a/crypto/userspace/cryptodev_main.c b/crypto/userspace/cryptodev_main.c index c6419f4..a6712db 100644 --- a/crypto/userspace/cryptodev_main.c +++ b/crypto/userspace/cryptodev_main.c @@ -1,3 +1,46 @@ +/* + * Driver for /dev/crypto device (aka CryptoDev) + * + * Copyright (c) 2004 Michal Ludvig <mludvig@logix.net.nz>, SuSE Labs + * Copyright (c) ...

What's the goal of exporting the kernel crypto routines to userspace, as opposed to just simply doing the crypto in userspace? Is it to access hardware crypto accelerators? (1) I wasn't aware the kernel crypto routines actually used crypto accelerators, and (2) more often than not, by the time you take into account the time to move the crypto context as well as the data into kernel space and back out, and after you take into account price/performance, most hardware crypto accellerators have ...

Please add (another) 'c' entry to Documentation/ioctl/ioctl-number.txt. --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

Your email id has won 2,500,000.00 Pounds Name... Country... Age... --

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

Hi Linus, Good boy :) Patch applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ --

On reset, VMCB TSC should be set to zero. Instead, code was setting tsc_offset to zero, which passes through the underlying TSC. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/svm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 8d7ae20..74e4522 100644 --- a/arch/x86/kvm/svm.c +++ b/arch/x86/kvm/svm.c @@ -781,7 +781,7 @@ static void init_vmcb(struct vcpu_svm *svm) control->iopm_base_pa = ...

Also, ensure that the storing of the offset and the reading of the TSC are never preempted by taking a spinlock. While the lock is overkill now, it is useful later in this patch series. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/svm.c | 6 ++++-- arch/x86/kvm/vmx.c | 13 ++++++------- arch/x86/kvm/x86.c | 18 ++++++++++++++++++ arch/x86/kvm/x86.h | 2 ++ 5 ...

Fair enough. --

If creating an SMP guest with unstable host TSC, issue a warning Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/x86.c | 4 ++++ 1 files changed, 4 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 3420f25..5e3b10e 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -5457,6 +5457,10 @@ void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu) struct kvm_vcpu *kvm_arch_vcpu_create(struct kvm *kvm, unsigned int id) ...

If there are active VCPUs which are marked as belonging to a particular hardware CPU, request a clock sync for them when enabling hardware; the TSC could be desynchronized on a newly arriving CPU, and we need to recompute guests system time relative to boot after a suspend event. This covers both cases. Note that it is acceptable to take the spinlock, as either no other tasks will be running and no locks held (BSP after resume), or other tasks will be guaranteed to drop the lock relatively ...

This is one of the things I believe should be applied right now. Maybe we want a cut version of this patch, that exposes this API while adjusting KVM_SET_CLOCK / KVM_GET_CLOCK to get in early rather than late? --

Isn't 5 way too long for this case? --

Add a kernel call to get the number of nanoseconds since boot. This is generally useful enough to make it a generic call. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- include/linux/time.h | 1 + kernel/time/timekeeping.c | 27 +++++++++++++++++++++++++++ 2 files changed, 28 insertions(+), 0 deletions(-) diff --git a/include/linux/time.h b/include/linux/time.h index ea3559f..5d04108 100644 --- a/include/linux/time.h +++ b/include/linux/time.h @@ -145,6 +145,7 @@ ...

The new interface was suggested several times, so I'm proposing it. I'm indifferent to putting it the kernel API or making it internal to KVM. KVM doesn't want to deal with conversions to / from ktime_t; this code uses a lot (too much) math, and it's easy to get wrong when splitting sec / nsec fields. So s64 seems a natural type for ns values. I realize it's not entirely consistent with the kernel API, but s64 I don't think so... boottime is internal to getboottime, and it's just ...

Separate step to prepare for next change. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/x86.c | 12 ++++++------ include/linux/kvm_host.h | 2 +- 2 files changed, 7 insertions(+), 7 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index d715ec0..ac0b2d9 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -838,7 +838,7 @@ static void kvm_write_wall_clock(struct kvm *kvm, gpa_t wall_clock) /* * The guest calculates current ...

Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/x86.c | 10 ++++++++++ 1 files changed, 10 insertions(+), 0 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index 718bed9..517daf3 100644 --- a/arch/x86/kvm/x86.c +++ b/arch/x86/kvm/x86.c @@ -898,6 +898,7 @@ static void kvm_get_time_scale(uint32_t scaled_khz, uint32_t base_khz, } static DEFINE_PER_CPU(unsigned long, cpu_tsc_khz); +unsigned long max_tsc_khz; static inline int ...

This can probably be merged right now. --

Now that we have trapping and catchup mode, based off guest virtual TSC khz, we can accomodate writes to unstable TSCs by doing computation in guest HZ rather than the transient host HZ. Instead of a large window of approximate elapsed time, we use a narrower (1 second) window of delta time between the guest TSC and system time. With this change, guests no longer exhibit pathological behavior during guest initiatied TSC recalibration. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- ...

We must also handle the reverse condition; TSC can't go backwards when trapping, and it's possible that bad hardware offsetting makes this problem visible when entering trapping mode. This is accomodated by adding a 'bump' field to the computed TSC; it's not pleasant but it works. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/include/asm/kvm_host.h | 2 + arch/x86/kvm/x86.c | 58 +++++++++++++++++++++++++++++++++++--- 2 files changed, 55 insertions(+), 5 ...

This function is basically almost completely totally useless. N.B. The hardware_enable code is not redundant; we could have an old VCPU thread hanging around that was not rescheduled during a CPU hotremove / hotadd event. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/x86.c | 15 +++++---------- 1 files changed, 5 insertions(+), 10 deletions(-) diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c index a7fa24e..23d5138 100644 --- a/arch/x86/kvm/x86.c +++ ...

This is not enough. We still can have bugs arriving from the difference in resolution between the underlying clock and the tsc. What we're doing here, is to pass a reliable flag, to a non-reliable guest tsc. We can only trust the guest kvmclock to be tsc-stable if the host is using tsc clocksource as well. Since the stable bit have to be read from the guest at every clock read, we can just use it, and drop it if the host changes its clocksource. An alternative for the reliable tsc case, ...

wrap this into a struct? --

Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/x86.c | 12 ++++++++++++ 2 files changed, 15 insertions(+), 0 deletions(-) diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h index 638cae5..3a54cc1 100644 --- a/arch/x86/include/asm/kvm_host.h +++ b/arch/x86/include/asm/kvm_host.h @@ -403,6 +403,9 @@ struct kvm_arch { u64 last_tsc_nsec; u64 last_tsc_offset; u64 ...

The math in kvm_get_time_scale relies on the fact that NSEC_PER_SEC < 2^32. To use the same function to compute arbitrary time scales, we must extend the first reduction step to shrink the base rate to a 32-bit value, and possibly reduce the scaled rate into a 32-bit as well. Note we must take care to avoid an arithmetic overflow when scaling up the tps32 value (this could not happen with the fixed scaled value of NSEC_PER_SEC, but can happen with scaled rates above 2^31. Signed-off-by: ...

Kernel time, which advances in discrete steps may progress much slower than TSC. As a result, when kvmclock is adjusted to a new base, the apparent time to the guest, which runs at a much higher, nsec scaled rate based on the current TSC, may have already been observed to have a larger value (kernel_ns + scaled tsc) than the value to which we are setting it (kernel_ns + 0). We must instead compute the clock as potentially observed by the guest for kernel_ns to make sure it does not go ...

Attempt to synchronize TSCs which are reset to the same value. In the case of a reliable hardware TSC, we can just re-use the same offset, but on non-reliable hardware, we can get closer by adjusting the offset to match the elapsed time. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/include/asm/kvm_host.h | 3 +++ arch/x86/kvm/x86.c | 31 ++++++++++++++++++++++++++++++- 2 files changed, 33 insertions(+), 1 deletions(-) diff --git ...

The VMCB is reset whenever we receive a startup IPI, so Linux is setting TSC back to zero happens very late in the boot process and destabilizing the TSC. Instead, just set TSC to zero once at VCPU creation time. Why the separate patch? So git-bisect is your friend. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/svm.c | 2 +- 1 files changed, 1 insertions(+), 1 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 74e4522..e8bfe8e 100644 --- ...

Ok, not a big loose, I agree. Btw, I suggest we start merging some of those simple and self-contained patches, before the series grows too big. Makes it easier for everyone to review the real important stuff. --

Change svm / vmx to be the same internally and write TSC offset instead of bare TSC in helper functions. Isolated as a single patch to contain code movement. Signed-off-by: Zachary Amsden <zamsden@redhat.com> --- arch/x86/kvm/svm.c | 29 ++++++++++++++++------------- arch/x86/kvm/vmx.c | 11 +++++------ 2 files changed, 21 insertions(+), 19 deletions(-) diff --git a/arch/x86/kvm/svm.c b/arch/x86/kvm/svm.c index 7a2feb9..4cb8822 100644 --- a/arch/x86/kvm/svm.c +++ ...

These patches add support for newer tablets to the wacom w8001 serial driver. The first patch simply adds the support for the Pen/Eraser tool and the stylus button. The second patch detects touch-capable tablets and discard their packets. Touch packets are interleaved with pen packets and their length depends on the sensor model. Detect these packets and discard them silently. The third patch adds MT slot support for two-finger touch devices. Patches tested on a 2 finger touch device but ...

Really, how that early termination could happen? I'm just wondering because I don't see that.. The code just mindlessly copies tags regardless of how target flags are set so that's why I'd think that any stale copied flags just don't matter... Honza -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

--

Hi, I've reviewed the patch and it looks good. I'll put the patches to testing on my machine and also uptade Andrew's radix-tree test suite to catch these types of bugs and run it just to be sure. Anyway, for now: Acked-by: Jan Kara <jack@suse.cz> -- Jan Kara <jack@suse.cz> SUSE Labs, CR --

From: Dave Chinner <dchinner@redhat.com> Commit f446daaea9d4a420d16c606f755f3689dcb2d0ce ("mm: implement writeback livelock avoidance using page tagging") introduced a new radix tree tag, increasing the number of tags in each node from 2 to 3. It did not, however, fix up the code in radix_tree_node_rcu_free() that cleans up after radix_tree_shrink() and hence could leave stray tags set in the new tag array. The result is that the livelock avoidance code added in the the above commit would ...

Applied, thanks. --

Tablets that support touch input may report different sized packages, depending on the touch sensor in the tablet. For now, discard the packages until we report them as touch input proper. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> --- drivers/input/touchscreen/wacom_w8001.c | 88 ++++++++++++++++++++++++++++++- 1 files changed, 86 insertions(+), 2 deletions(-) diff --git a/drivers/input/touchscreen/wacom_w8001.c b/drivers/input/touchscreen/wacom_w8001.c index ...

Some serial wacom devices support two-finger touch. Test for this during init and parse the touch packets accordingly. Touch packets are processed using Protocol B (MT Slots). Note: there are several wacom versions that do touch but not two-finger touch. These are not catered for here, touch events for these are simply discarded. Signed-off-by: Peter Hutterer <peter.hutterer@who-t.net> CC: Henrik Rydberg <rydberg@euromail.se> --- drivers/input/touchscreen/wacom_w8001.c | 99 ...

Good point. I'll do more homework. Thanks for the reminding! Thanks, Fengguang --

Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

Hi Dmitry, After merging the final tree, today's linux-next build (i386 defconfig) failed like this: In file included from drivers/gpu/drm/i915/i915_irq.c:29: include/linux/sysrq.h:45: error: expected declaration specifiers or '...' before 'bool' Caused by commit a821bafce37b26499e2bfbf2e6b96b0636efc014 ("Input: sysrq - drop tty argument form handle_sysrq()") from the input tree which (despite not mentioning this) changed an "int" argument to "bool" but neglected to include ...

--

Pulled, thanks a lot Arnaldo! Ingo --

From: Arnaldo Carvalho de Melo <acme@redhat.com> This makes the usual idiom for specifying a series of key codes to exit ui_browser__run() for specialized processing (search, annotate, etc) or plain exiting the browser more compact. It also abstracts away some more libnewt operations. At some point we'll also replace NEWT_KEY_foo with something that can be mapped to NEWT or, say, gtk. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra ...

From: Arnaldo Carvalho de Melo <acme@redhat.com> Browsers don't have to deal with absolute coordinates, just using (row, column) and leaving the rest to ui_browser is better and removes one more UI backend detail from the browsers. Also shorten the percent_color setting idiom, removing some more direct libslang calls. Cc: Frederic Weisbecker <fweisbec@gmail.com> Cc: Mike Galbraith <efault@gmx.de> Cc: Peter Zijlstra <peterz@infradead.org> Cc: Stephane Eranian ...

Yes, it does fix my issue. I will note that a patch is available on the Bug report. Thanks, Larry --

From: Larry Finger <Larry.Finger@lwfinger.net> Fix is already upstream: http://git.kernel.org/tip/07a7795ca2e6e66d00b184efb46bd0e23d90d3fe Can you verify it fixes your issue too please? Thanks. -- Regards/Gruss, Boris. Advanced Micro Devices GmbH Einsteinring 24, 85609 Dornach General Managers: Alberto Bozzo, Andrew Bowd Registration: Dornach, Gemeinde Aschheim, Landkreis Muenchen Registergericht Muenchen, HRB Nr. 43632 --

pdata is dereferenced earlier than tested for being NULL. Thus move the dereference of "pdata" below the check for NULL. Signed-off-by: Axel Lin <axel.lin@gmail.com> --- drivers/regulator/wm8994-regulator.c | 8 ++++---- 1 files changed, 4 insertions(+), 4 deletions(-) diff --git a/drivers/regulator/wm8994-regulator.c b/drivers/regulator/wm8994-regulator.c index 03713bc..3ecc81f 100644 --- a/drivers/regulator/wm8994-regulator.c +++ b/drivers/regulator/wm8994-regulator.c @@ -202,15 ...

ARRAY_SIZE() isn't actually a dereference, it's evaluated at compile time.--

pdata is dereferenced earlier than tested for being NULL. Thus move the dereference of "pdata" below the check for NULL. Signed-off-by: Axel Lin <axel.lin@gmail.com> --- drivers/regulator/wm831x-dcdc.c | 36 ++++++++++++++++++++++++------------ 1 files changed, 24 insertions(+), 12 deletions(-) diff --git a/drivers/regulator/wm831x-dcdc.c b/drivers/regulator/wm831x-dcdc.c index dbfaf59..ed66fac 100644 --- a/drivers/regulator/wm831x-dcdc.c +++ b/drivers/regulator/wm831x-dcdc.c @@ -501,14 ...

File system UUID is made available to application via /proc/<pid>/mountinfo Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/ext4/super.c | 2 ++ 1 files changed, 2 insertions(+), 0 deletions(-) diff --git a/fs/ext4/super.c b/fs/ext4/super.c index 2614774..b46a78c 100644 --- a/fs/ext4/super.c +++ b/fs/ext4/super.c @@ -2941,6 +2941,8 @@ static int ext4_fill_super(struct super_block *sb, void *data, int silent) ...

This enables to use faccessat to get the access check details from a file descriptor pointing to the file. This can be used with open_by_handle syscall that returns a file descriptor. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/open.c | 29 +++++++++++++++++++++-------- 1 files changed, 21 insertions(+), 8 deletions(-) diff --git a/fs/open.c b/fs/open.c index 7abdcba..f907b50 100644 --- a/fs/open.c +++ b/fs/open.c @@ -288,9 +288,10 @@ ...

Add sys_name_to_handle_at and sys_open_by_handle_at syscalls for x86_64 Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- arch/x86/ia32/ia32entry.S | 2 ++ arch/x86/include/asm/unistd_64.h | 5 +++++ fs/compat.c | 11 +++++++++++ 3 files changed, 18 insertions(+), 0 deletions(-) diff --git a/arch/x86/ia32/ia32entry.S b/arch/x86/ia32/ia32entry.S index b86feab..d93cd0d 100644 --- a/arch/x86/ia32/ia32entry.S +++ ...

This patch adds sys_name_to_handle_at and sys_open_by_handle_at syscalls to x86_32 Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- arch/x86/include/asm/unistd_32.h | 5 ++++- arch/x86/kernel/syscall_table_32.S | 2 ++ 2 files changed, 6 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/unistd_32.h b/arch/x86/include/asm/unistd_32.h index b766a5e..62e35b7 100644 --- a/arch/x86/include/asm/unistd_32.h +++ ...

On Fri, 20 Aug 2010 04:32:13 -0400 Again, you have made an assertion without justifying it. I disagree, I think it is perfectly valid. The function would still return an error in every case that it previously returned an error, because in every previous case the fd would not have referred to a symlink so the new version will have nothing to perform a readlink on when NULL is passed. The error would probably be EINVAL rather than EFAULT but even that difference could be avoided if it was ...

The exportfs encode handle function should return the minimum required handle size. This helps user to find out the handle size by passing 0 handle size in the first step and then redoing to the call again with the returned handle size value. Acked-by: Serge Hallyn <serue@us.ibm.com> Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/btrfs/export.c | 8 ++++++-- fs/exportfs/expfs.c | 9 +++++++-- fs/fat/inode.c | 4 +++- ...

The syscall also return mount id which can be used to lookup file system specific information such as uuid in /proc/<pid>/mountinfo Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/open.c | 129 ++++++++++++++++++++++++++++++++++++++++++++++ include/linux/exportfs.h | 3 + include/linux/fs.h | 8 +++ include/linux/syscalls.h | 5 ++- 4 files changed, 144 insertions(+), 1 deletions(-) diff --git a/fs/open.c b/fs/open.c index ...

Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- include/asm-generic/unistd.h | 6 +++++- 1 files changed, 5 insertions(+), 1 deletions(-) diff --git a/include/asm-generic/unistd.h b/include/asm-generic/unistd.h index b969770..8e7bd87 100644 --- a/include/asm-generic/unistd.h +++ b/include/asm-generic/unistd.h @@ -646,9 +646,13 @@ __SYSCALL(__NR_prlimit64, sys_prlimit64) __SYSCALL(__NR_fanotify_init, sys_fanotify_init) #define __NR_fanotify_mark 263 ...

This enables to use linkat to create hardlinks from a file descriptor pointing to the file. This can be used with open_by_handle syscall that returns a file descriptor. Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com> --- fs/namei.c | 36 ++++++++++++++++++++++++++---------- 1 files changed, 26 insertions(+), 10 deletions(-) diff --git a/fs/namei.c b/fs/namei.c index 2c79363..fd9febc 100644 --- a/fs/namei.c +++ b/fs/namei.c @@ -2627,7 +2627,7 @@ int vfs_link(struct ...

If we don't do this, we will need new syscalls for doing stat, readlink and link on symlinks that take file handle as the argument. If that is ok, I can redo the patch series accordingly. -aneesh --

You are welcome to review the codepaths around pathname resolution for assumptions of presense of ->follow_link() and friends; there _are_ subtle cases and dumping your "opened symlinks" in there is far from a trivial change. Note that it affects more than just the starting points of lookups; /proc/*/fd/* stuff is also involved. BTW, speaking of NULL pathname, linkat() variant that allows creating a link to an opened file is also a very dubious thing; at the very least, you get non-trivial ...

It is not just readlink that we would need. We would require sys_handle_readlink, sys_handle_stat64, sys_handle_link, sys_handle_chown, sys_handle_setxattr, sys_handle_getxattr, sys_handle_listxattr, sys_handle_removexattr, sys_handle_utimes, compat_sys_handle_utimes I have most of the changes done, so if we are ok adding all these new syscalls i can post the patch series. -aneesh --

On Fri, 20 Aug 2010 15:25:29 +0200 Interesting - thanks. OK, adjust my argument to reference signalfd, timerfs and pollfd. I haven't looked at that code before - "anon_inode_getfd" gives you an fd on an inode for which (stat.st_mode & S_IFMT) == 0 Cool! They have no format at all :-) NeilBrown --

Hi all. I'm currently looking for a job or contract work, and really keen to focus on contributing to the effort to improve kernel power management. I'd like to stay in Australia or New Zealand, but will happily move to another city (I'm in Geelong, near Melbourne) at the moment. Regards, Nigel --

From: Dave Hansen <dave@linux.vnet.ibm.com> [PATCH 2/4 v2] kvm: rename x86 kvm->arch.n_alloc_mmu_pages Again, I think this is a poor choice of names. This value truly means, "the number of pages which _may_ be allocated". But, reading the value, "n_alloc_mmu_pages", I'm unable to think of anything it should mean other than "the number of allocated mmu pages", which is dead wrong. It's really the high watermark, so let's give it a name to match: nr_max_mmu_pages. This change will make ...

From: Dave Hansen <dave@linux.vnet.ibm.com> [PATCH 3/4 v2] kvm: replace x86 kvm n_free_mmu_pages with n_used_mmu_pages I think doing this makes the code much more readable. That's borne out by the fact that this patch removes code. "used" also happens to be the number that we need to return back to the slab code when our shrinker gets called. Keeping this value as opposed to free makes the next patch simpler. So, 'struct kvm' is kzalloc()'d. 'struct kvm_arch' is a structure member (and ...

The following series is the four patches Dave Hansen had queued for test as mentioned last week in the thread: "[PATCH] kvm: make mmu_shrink() fit shrinker's requirement" Last week just before leaving for vacation Dave had noted in that thread that these four were ready to merge based on our perf team's testing finally having wrapped up. But it turns out he hadn't actually posted them after refactoring in response to comments back in June... I'm covering for him in his absence and had ...

Hi, This patch series contains the work I did for memorystick subsystem. I resend slightly cleaned up driver for my card reader in patch #2 patch #1 and #3 are new and add support for Legacy MemorySticks (<= 128MB) Everything works and more or less tested. Best regards, Maxim Levitsky --

Signed-off-by: Maxim Levitsky <maximlevitsky@gmail.com> --- MAINTAINERS | 5 + drivers/memstick/host/Kconfig | 13 + drivers/memstick/host/Makefile | 1 + drivers/memstick/host/r592.c | 889 ++++++++++++++++++++++++++++++++++++++++ drivers/memstick/host/r592.h | 177 ++++++++ 5 files changed, 1085 insertions(+), 0 deletions(-) create mode 100644 drivers/memstick/host/r592.c create mode 100644 drivers/memstick/host/r592.h diff --git a/MAINTAINERS ...

Hmmmm, Ok.. Then I will defer to mnc's judgement here about what level of integration of LIO-Target for protocol and PDU defs for what he currently handles with Open-iSCSI. Mike, do you have any more thoughts here..? I am pretty sure there are more important items to focus on inside from this particuarly time-consuming and tedious cleanup, but am happy to start a smaller cleanup of drivers/target/lio-target/iscsi_protocol.h for starters.. Also, LIO-Target is still using an internal ...

Ah yes the ibm vscsi driver. Well for that part I suppose we will need a seperate tcm_ibmvscsi fabric module moving forward. This is where that python script I mentioned when tcm_lpfc, tcm_qla2xxx, tcm_mvsas where originally posted that would generates a new functioning configfs skeleton with NOP I/O path handlers from a handful of user input. Anyways, something like this would really come in handy for making ibm vscsi go, and plus it makes life easier for me too. I will try to get ...

On Fri, 20 Aug 2010 03:02:40 -0700 I think that James meant that we have only one scsi target implementation and we need to replace the current in-kernel target mode driver. So I don't think that we can merge TCM core without its ibm vscsi driver. I might be wrong though. --

On Thu, 19 Aug 2010 15:45:47 -0700 It's up to Mike but it looks hacky to me. struct iscsi_pdu is defined in the exact way as the spec does. I don't think that iscsi_proto.h conversion is a must for the mainline inclusion. I prefer to let it alone for now. --

On Fri, Aug 20, 2010 at 5:41 AM, tip-bot for Daniel Kiper Do you have any report on real hardware? that could not happen on real hardware. --

As Rik said, /proc/sys is not a suitable place. Frankly speaking I've worked on writeback for years and never felt the need to add these counters. What I often do is: $ vmmon -d 1 nr_writeback nr_dirty nr_unstable nr_writeback nr_dirty nr_unstable 68738 0 39568 66051 0 42255 63406 0 44900 60643 0 47663 57954 ...

Sorry, here is the mentioned vmmon source file. The full ext3-tools package is here: http://userweb.kernel.org/~akpm/stuff/ext3-tools.tar.gz Thanks, Fengguang --

It's redundant to have _pages in the names. /proc/vmstat has the tradition to use nr_dirty instead of nr_pages_dirty. They do look like useful counters to export, especially when we do 2.6.36-rc1 will need this: global_dirty_limits(v + NR_DIRTY_THRESHOLD, v + NR_DIRTY_BG_THRESHOLD); Thanks, --

s/account_pages_writeback/account_page_writeback/ I'd recommend to separate the changes into two patches. It's actually a bug fix to export account_pages_dirty() for ceph, That 'if' is not necessary. account_page_dirtied() already has one. The extra 'if' is not an optimization either, because the ceph fs is The 'if' test and *mapping parameter looks unnecessary at least for now. The only place a mapping has BDI_CAP_NO_ACCT_WB but not BDI_CAP_NO_WRITEBACK is fuse, which does its own ...

The patch fixes it for me. Thanks. --Benjamin Gilbert --

Great, it's in my queue to go to Linus in a day or so. thanks for testing. greg k-h --

Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

Reviewed-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

Acked-by: Rik van Riel <riel@redhat.com> -- All rights reversed --

I think Greg generally includes all upstream commits marked with a -stable tag - except if it wont apply cleanly, in which case he mails for a backport. It of course has to fit in the regular stable release cycle, so the patches dont propagate instantaneously. Thanks, Ingo --

-- ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com --

It depends. Imagine your frame grabber has built-in RAM buffer on board just as the frame buffer RAM on graphics cards, defined in BAR. You can use dma_declare_coherent_memory()/dma_release_declared_memory() in your driver and then use dma_alloc_coherent()/dma_free_coherent() to allocate dma buffers from it and falling back transparently to system RAM Yes, just to preallocate not coherent, but rather contiguous memory for latter usage. I do not know why dma_pool API doesn't work for frame ...

On Thu, 19 Aug 2010 18:18:35 +0300 I think that drivers/base/dma-coherent.c is for architectures to implement dma_alloc_coherent(). So using it for drivers doesn't look What you guys exactly want to do? If you just want to pre-allocate coherent memory for latter usage, why dma_pool API (mm/dmapool.c) doesn't work? --

Ok, so, we've got two solutions to this problem submitted on the same day;) Following this thread: http://marc.info/?t=128128236400002&r=1&w=2 on the ARM Linux kernel ML, I submitted a patch series http://thread.gmane.org/gmane.linux.ports.sh.devel/8595 with a couple of fixes and improvements, the actual new API and a use example. My approach is slightly different, in that instead of requiring drivers to issue two calls - one to reserve RAM (usually dma_alloc_coherent()) and one to ...

Thank you for correction. I suppose you mean I missed CONFIG_TREE_PREEMPT_RCU, right? As far as my grepping, other rcu implementation and spinlock use preempt_disable(). In other word, Can I assume usual distro user don't hit this issue? Thanks. --

Hi, Just checking.. Anton, can you please queue up this 2/2 patch too to keep them together? Here's my ack: Acked-by: Tony Lindgren <tony@atomide.com> --

Sure thing, applied. Thanks! -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

"Bogosity" in question is quite real and proposed "fix" actually makes the things even worse. At least gcc bothers to optimize the division in there... Basically, sparse warns about pointer subtractions that divide by constants that are not powers of two. Which _does_ have non-trivial price, even with optimizations done by gcc. Posted patch is complete crap, since all it does is a) confuse sparse into not noticing the operation b) confuse gcc into not trying to optimize the thing, which ...

I'm not sure the price is so high. I googled around and came across http://mdfs.net/Docs/Comp/ARM/Cookbook/cook3 (section 3.3). Dividing by 2^n, (2^n + 2^m) or (2^n - 2^m) can be done using a small series of adds and subtractions (important on ARM as it had no divide instruction at the time). Most structures are going to be of one of these sizes ... and in particular, struct page is 56 bytes in my config, which is 64 - 8. Maybe sparse needs to be taught that dividing by 2^n [+-] 2^m is ...

Again, please use a more modern kernel version, and then, please show the exact diff (in 'diff -u' format) that you made. thanks, greg k-h --

Greg, Sorry for including quotations in my email. Oliver, I see the superfluous data with usbmon also. I have changed the pl2303_write(), according to my need.I enabled the RTS line before the data transmission and after a delay of 5ms ,disabled the RTS lines for my MCM device to respond. Thanks, Raju --

Acked-by: Liam Girdwood <lrg@slimlogic.co.uk> -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk --

No. This code should *NOT* use the VFS guts, TYVM. The whole fscking point is that this puppy is a sequence of plain vanilla syscalls, ideally run simply in userland thread. We used to have a magical mystery shite in there and it had been a huge PITA. --

Applied. Thanks Liam -- Freelance Developer, SlimLogic Ltd ASoC and Voltage Regulator Maintainer. http://www.slimlogic.co.uk --

Overall we need to keep state integrity for hot-removed CPU and shared core sensor. Without fixing this issue, we end up with inconsistent system info. As for usage scenario, I can think of some: 1. Power saving. Management application may offline some threads or all thread siblings to save power. Image all of HT is disabled during run-time, less power is consumed with less performance. 2. RAS. A bad thread may be offlined which its sibling is still running. This Yes, I agree with you on ...

Thanks! The performance results you've posted so far IMO more than justifies its inclusion. Ingo --

I naively hacked something together and it did seem to work, but I I sent a contrived test program in my other mail. The actual use is to mlock a buffer on the stack in order to pass it to a Xen hypercall. The contract with the hypervisor is that the pages passed to the hypercall must be mapped. Ian. -- Ian Campbell Current Noise: Dinosaur Jr. - Green Mind We can defeat gravity. The problem is the paperwork involved. --

I've had to convert normal linked lists to a dual linked list for a project of mine in the past, and for the same reason I could not use the lists how we use them in Linux. However I found an interesting tradeoff which consists in having only the ->prev list circular but keep the ->next one null- terminated. In the end, the API is not much different. A few tests just on the ->next pointer at some places, but you can still use ->prev everywhere to find the list tail, for inserting and ...

Well, yes and no. This would make it have semantic differences, if you were to unmap the lower part of the stack. I could imagine some crazy program wanting to basically return the stack pages to the system after doing heavy recursion. IOW, they could do - use lots of stack because we're recursing 1000 levels deep - know that we used lots of stack, so after returning do something like stack = &local variable; align stack down by two pages munmap down from there to give ...

You mean something like the below? Should I look at refreshing that thing (yes, that's a 2007 patch)? --- Subject: mm: replace vm_next with a list_head Date: 19 Jul 2007 Replace the vma list with a proper list_head. Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl> --- arch/alpha/kernel/osf_sys.c | 2 arch/arm/mm/mmap.c | 2 arch/frv/mm/elf-fdpic.c | 4 - arch/i386/mm/hugetlbpage.c | 2 arch/ia64/kernel/sys_ia64.c ...

On Fri, Aug 20, 2010 at 8:54 AM, Linus Torvalds Actually, thinking some more about it, that may not be a good idea. Why? Simply because we may want to merge the vma's back together if you do munlock. And it won't (and mustn't) merge if the vm_flags differ in VM_GROWSDOWN. So I do think we want to keep VM_GROWSDOWN (and VM_GROWSUP on PA-RISC) even across a vma split. Of course, we could set a flag whether the vma really does have a guard page or not. That said, it does strike me as ...

It should be a pretty straightforward search-and-replace. And almost all of it would be real cleanups. And it would be trivial to change the loops like for (vma = mm->mmap; vma; vma = vma->vm_next) into basically just list_for_each_entry(vma, &mm->mmap, vm_list) I'm not convinced a tunable is really the right thing, but in this case it might be acceptable, since you really are doing something rather specific and odd. Changing the VM to use doubly-linked lists I'd really ...

Yeah. I looked at exactly something like that. With the same name for vma_next() - except I just passed down 'mm' to it too. Your patch takes it from vma->mm and then you have a few places do the whole Interesting. I generated about half the patch, and then decided that it's not worth it. But the fact that apparently you did the same thing in 2007 means that maybe there really _is_ a pent-up demand for doing this dang thing. I do note that I also did a patch that just added "vm_prev", and ...

Commit-ID: b847b94fe2caff0f28a99af6353e9a27282e771a Gitweb: http://git.kernel.org/tip/b847b94fe2caff0f28a99af6353e9a27282e771a Author: Peter Zijlstra <a.p.zijlstra@chello.nl> AuthorDate: Fri, 20 Aug 2010 11:49:15 +0200 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 20 Aug 2010 15:00:06 +0200 watchdog: Don't throttle the watchdog Stephane reported that when the machine locks up, the regular ticks, which are responsible to resetting the throttle count, stop too. Hence the ...

It would be more descriptive to say "remove the __GFP_WAIT bit". The change looks reasonable _in itself_, since we always prefer to avoid unnecessary waits for kswapd. So --

I thought I'd send that as a separate patch, but yes, that is my intention next. Cheers Trond --

That's pretty much the idea, really. However, I don't think you can localize the change without making invalid assumptions of the behavior of lower primitives, which given that changes are in progress will cause serious problems. The issue here is that the e820 allocator (which is about to be axed, but its successor will need to support similar operations) has a few parameters that it takes in: (start, end, size, alignment). It will return a block at address (addr) fulfilling the ...

Hi, [PATCH] mtd: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT [PATCH v2 0/2] Deprecate ECCGETLAYOUT [PATCH v2 1/2] mtd: nand: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT [PATCH v2 2/2] mtd: nand: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT [PATCH v3 1/2] mtd: Expand nand_ecc_layout, deprecate ioctl ECCGETLAYOUT [PATCH v3 2/2] (I can't find this in my inbox, by the way) I'd like to see the info about what's updated in v2, v3 when revised. By the way. Two ...

Looks good to me; there is still a bit of padding at the end: qsize_t i_reserved_quota; /* 864 8 */ struct list_head i_completed_io_list; /* 872 16 */ spinlock_t i_completed_io_lock; /* 888 4 */ /* XXX 4 bytes hole, try to pack */ /* --- cacheline 14 boundary (896 bytes) --- */ ext4_io_end_t * cur_aio_dio; /* 896 8 */ tid_t ...

I think Linux has too many syscalls. Significant part these interfaces On the other, hand properly designed fs-based interface requires less modification of userspeace to use it. Acctually, you can use most of fs-based intefaces directly from shell. No need in libc modifications and utilities to use it from shell or other script language. Yes, sysfs is not the best place for it, but... -- Kirill A. Shutemov --

What is the difference between a syscall and a filesystem interface? They are both things that we can not change in the future and need to be preserved and documented. You just answered your own question. Please don't make it in sysfs, make it a syscall as it does not fit into sysfs. thanks, greg "constantly fighting to keep /sys/ from being like /proc/" k-h --

Either is OK for me. I'll turn a replacement patch into a delta so I can see what changed, but that takes just a few seconds. --

On Fri, Aug 20, 2010 at 10:32 AM, Andy Shevchenko Sigh. Wrong name again, sorry. -- With Best Regards, Andy Shevchenko --

Conversion from struct device to struct mmc_card is used more than in one place. Due to this it's better to have public macro for such thing. Signed-off-by: Andy Shevchenko <ext-andriy.shevchenko@nokia.com> Cc: Adrian Hunter <adrian.hunter@nokia.com> Cc: linux-mmc@vger.kernel.org Cc: Andrew Morton <akpm@linux-foundation.org> --- drivers/mmc/card/mmc_test.c | 4 +--- drivers/mmc/core/bus.c | 15 +++++++-------- drivers/mmc/core/bus.h | 2 +- include/linux/mmc/card.h | ...

Based on above, remove the rest firmware exports. Thanks! -- Signed-off-by: WANG Cong <amwang@redhat.com>

Fix: using smp_processor_id() in preemptible thermal_throttle_add_dev. We know the cpu number when calling thermal_throttle_add_dev, so we can remove smp_processor_id call in thermal_throttle_add_dev by supplying the cpu number as argument. Signed-off-by: Sergey Senozhatsky <sergey.senozhatsky@gmail.com> --- diff --git a/arch/x86/kernel/cpu/mcheck/therm_throt.c b/arch/x86/kernel/cpu/mcheck/therm_throt.c index c2a8b26..bcd8499 100644 --- a/arch/x86/kernel/cpu/mcheck/therm_throt.c +++ ...

Hi Mario, Could you attach or upload the DSDT of S12 somewhere I can reach? I check DSDT for S10-3 and B550, return value of _CFG is fixed. [Ref: http://people.ubuntu.com/~ikepanhc/DSDTs] you may use "sudo cp /sys/firmware/acpi/tables/DSDT ." and "sudo iasl -d /sys/firmware/acpi/tables/DSDT" to decode it. bluetooth device shall disappear after disable from EC. But if can not be enabled when you use rfkill of hci0, it only disable PHY. The driver and MAC is still there. The rfkill of ...

Right. I'll update the patches. --

Btw., some 'perf list' thoughts. We could do a: perf list --help rapl:watts Which gives the user some idea what an event does. Also, short descriptive line in perf list output would be nice: $ perf list List of pre-defined events (to be used in -e): cpu-cycles OR cycles [Hardware event] # CPU cycles instructions [Hardware event] # instructions executed ... rapl:watts ...

Right, record, list, probe, top are on the UI (not just T-UI, see latest efforts on decoupling from newt/slang) hit-list :) Moving from one to the other seamlessly like today is possible for report and annotate is the goal. Now that the UI browser code is more robust and generic that should happen faster, I think. - Arnaldo --

The old limit of number of minor numbers per mmcblk device was hardcoded at 8. This isn't enough for some of the more elaborate partitioning schemes, for example those used by Chrome OS. Since there might be a bunch of systems out there with static /dev contents that relies on the old numbering scheme, let's make it a build-time option with the default set to the previous 8. Also provide a boot/modprobe-time parameter to override the config default: mmcblk.perdev_minors. Signed-off-by: ...

hi Randy: yes, it does! Thanks a lot! runcoderen -- /**************************************** http://runcoderen.wordpress.com/ ****************************************/ --

You won't find a function in kernel/module.c that looks like it has the name "sys_init_module". Instead, the function is defined by using a macro, and it looks like this: /* This is where the real work happens */ SYSCALL_DEFINE3(init_module, void __user *, umod, unsigned long, len, const char __user *, uargs) { The use of SYSCALL_DEFINEx(func_name, args) is a fairly recent change (well, January, 2009) that may be the reason why you think that there has been a change. ...

Other architectures who support cmpxchg and atomic_long can use that directly. Signed-off-by: Benjamin Herrenschmidt <benh@kernel.crashing.org> --- arch/powerpc/include/asm/rwsem.h | 184 +---------------------------------- include/asm-generic/rwsem-cmpxchg.h | 183 ++++++++++++++++++++++++++++++++++ 2 files changed, 184 insertions(+), 183 deletions(-) create mode 100644 include/asm-generic/rwsem-cmpxchg.h diff --git a/arch/powerpc/include/asm/rwsem.h ...

#ifdef __KERNEL__ is only relevant for exported headers. For kernel only headers like this is does not make sense, but it does not harm. Sam --

Hans, Peter? What's the status of this? Should I just take the revert from Rafael? Ping? Linus --

I have a fix from Hans queued up in x86/urgent and it will be in the next push of the fixes queue, which I am planning to send you today. http://git.kernel.org/tip/07a7795ca2e6e66d00b184efb46bd0e23d90d3fe -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

Hi Philippe, Thanks, applied to the m68knommu git tree. Regards -- ------------------------------------------------------------------------ Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com SnapGear Group, McAfee PHONE: +61 7 3435 2888 8 Gardner Close FAX: +61 7 3217 5323 Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com --

Applied, thanks. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ --

Hi Mattias, Thanks for the patch, but I'd prefer to see it split into 3 separate ones, for mfd, rtc and regulator. And then have the relevant maintaines cc'ed with those patches. Cheers, Samuel. -- Intel Open Source Technology Centre http://oss.intel.com/ --

Hello, May be because I copied csum_ipv6_magic() code from Regards -- Julian Anastasov <ja@ssi.bg> --

On Wed, 18 Aug 2010 12:19:51 +0530 What was the rationale for duplicating the Pss value here, rather than say Rss or whatever? Really, the value is just a boolean due to kernel internal details but we should try to put something sensible and meaningful in there if it isn't just "1" or "0". As it stands, people will look at the /proc/pid/smaps output, then at proc.txt and will come away all confused. btw, we forgot to document Pss (of all things!) in Documentation/filesystems/proc.txt. --

do you mean this one? [PATCH] acpi: fix apei related table size checking Signed-off-by: Yinghai Lu <yinghai@kernel.org> --- drivers/acpi/apei/einj.c | 3 ++- drivers/acpi/apei/erst.c | 3 ++- 2 files changed, 4 insertions(+), 2 deletions(-) Index: linux-2.6/drivers/acpi/apei/einj.c =================================================================== --- linux-2.6.orig/drivers/acpi/apei/einj.c +++ linux-2.6/drivers/acpi/apei/einj.c @@ -426,7 +426,8 @@ ...

Hi Rabin, I applied Wolfram's patch. If he wants to change this name, he can send an additional patch later on. Thanks for the patch and the review. Cheers, -- Intel Open Source Technology Centre http://oss.intel.com/ --

Sorry, I hadn't updated my for-next branch. It's pushed to kernel.org now. Thanks- sage --

In fact I never run 'perf report' specifying '-g', have you tried it IIRC I tried this on perf/urgent and on perf/core, the former should be what is Linus tree. Lemme try again, right, just checked out from torvalds/master and running it as: $ perf report Probably because of what I said above, i.e. I still have to try 'perf record -g flat' on the TUI, lets see... Running it as: $ perf report -g flat,0,0 This is ...

It changes the alignment of all applicable objects to 1 which means that the compiler cannot assume _any_ aligment. Thus on STRICT_ALIGNMENT targets it has to use more expensive access methods to avoid generating unaligned loads and stores (unless it can infer proper alignment from the context). You can add an aligned attribute to raise the assumed alignment again. Of course, this can only work correctly if the actual alignment of the Neither x86 nor x86-64 are STRICT_ALIGNMENT ...

That won't buy you much wrt. alignment though, due to the packed attribute. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." --

Andreas suggested (I accidentally dropped the list when I ask him) I use natural alignment and explicit padding rather than ((packed)) I'm open to the idea but I want to make it idiot proof (aka I won't screw it up later) My best offhand idea would be to do something like so: Expose this to userspace: struct fanotify_event_metadata { __u32 event_len; __u32 vers; __s32 fd; __u64 mask; __s64 pid; }; Wrap this in #ifdef KERNEL struct ...

Hi Linus Walleij, We will update your comments ASAP. Thanks, Ohtake(OKISEMI) ----- Original Message ----- From: "Linus Walleij" <linus.ml.walleij@gmail.com> To: "Masayuki Ohtak" <masa-korg@dsn.okisemi.com> Cc: <meego-dev@meego.com>; "LKML" <linux-kernel@vger.kernel.org>; "David Brownell" <dbrownell@users.sourceforge.net>; <spi-devel-general@lists.sourceforge.net>; <qi.wang@intel.com>; <yong.y.wang@intel.com>; <andrew.chih.howe.khor@intel.com>; <arjan@linux.intel.com>; <gregkh@suse.de>; ...

Applied, Thanks Suresh! --

Ok. Updated patch appended. Thanks. --- From: Suresh Siddha <suresh.b.siddha@intel.com> Subject: sched: move sched_avg_update() to update_cpu_load() Currently sched_avg_update() (which updates rt_avg stats in the rq) is getting called from scale_rt_power() (in the load balance context) which doesn't take rq->lock. Fix it by moving the sched_avg_update() to more appropriate update_cpu_load() where the CFS load gets updated aswell. Signed-off-by: Suresh Siddha ...

Commit-ID: cd7240c0b900eb6d690ccee088a6c9b46dae815a Gitweb: http://git.kernel.org/tip/cd7240c0b900eb6d690ccee088a6c9b46dae815a Author: Suresh Siddha <suresh.b.siddha@intel.com> AuthorDate: Thu, 19 Aug 2010 17:03:38 -0700 Committer: Ingo Molnar <mingo@elte.hu> CommitDate: Fri, 20 Aug 2010 14:59:02 +0200 x86, tsc, sched: Recompute cyc2ns_offset's during resume from sleep states TSC's get reset after suspend/resume (even on cpu's with invariant TSC which runs at a constant rate across ...

On Thu, 19 Aug 2010 11:12:08 +0300 I suspect this was fixed by commit 602586a83b719df0fbd94196a1359ed35aeb2df3 Author: Hugh Dickins <hughd@google.com> AuthorDate: Tue Aug 17 15:23:56 2010 -0700 Commit: Linus Torvalds <torvalds@linux-foundation.org> CommitDate: Tue Aug 17 18:33:11 2010 -0700 shmem: put_super must percpu_counter_destroy --

Ok, so here is my patch that syncs the touch_*_watchdog back in line with the old semantics. Hopefully this will undo any harm I caused. ------------cut -->--------------------------- From b372e821c804982438db090db6b4a2f753c78091 Mon Sep 17 00:00:00 2001 From: Don Zickus <dzickus@redhat.com> Date: Thu, 19 Aug 2010 22:48:26 -0400 Subject: [PATCH] [lockup detector] sync touch_*_watchdog back to old semantics During my rewrite, the semantics of touch_nmi_watchdog ...

Yes it is by design. I was using watchdog_enabled as a global state variable. As soon as one cpu was enabled, I would set the bit. But only I wasn't tracking it on a per cpu basis. I didn't see a need to. The watchdog should globally be on/off across the system. If a system comes up and one of the cpus could not bring the watchdog online for some reason, then that is a problem. If a cpu-hotunplug+cpu-hotplug fixes it, all the better. :-) Also, if I wanted to track it per cpu, there ...

Thanks but I'm running this on an ARM netbook which doesn't have /sys/bus/pnp. -- Neil -- Sent by an employee of the Qualcomm Innovation Center, Inc. The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum. --

I was thinking that we might be better off using the "durable writes" term more since it is well documented (at least in the database world, where it is the "D" Should we mention that users can also disable the write cache on the target device? It might also be worth mentioning that storage needs to be properly configured - i.e., an internal hardware RAID card with battery backing needs can expose itself as a writethrough cache *only if* it actually has control over all of the backend ...

sata_lies.txt? Ok, maybe writeback_cache.txt? -chris --

Grant Likely <grant.likely@secretlab.ca> writes: Heh, now I feel like we're going around in circles. Remember, I never wanted to create add a new bus_type. Someone else [ahem] suggested Yes, I'm working on the devres approach to that now, as is Magnus for IMHO, simply overriding the few dev_pm_ops methods was the cleanest and simplest. Since we seem to be in agreement now that the a new bus may not the right abstraction for this (since we want it to be completely transparent to the ...

You can also try to use RTC wakealarm to run suspend/resume in a tight loop. Rafael --

Well, doing 20 suspends in a row from a script should not be too bad. -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html --

That's what the dmapi callouts that are intendeded to do just about the same as fanotify always did. I'm pretty sure I brought this up earlier in the discussion. --

In reference to (2), I don't even understand what an fd is that can't be used for anything. I'll let Al or Christoph respond if they feel like it, but it sounds crazy to me. You want to just magic up some struct file and attach a struct path to it even though dentry_open() failed? So you can do what with it? On a more realistic note, I'm not opposed to (1), however, your arguments would lead one to reject inotify as the IN_OVERFLOW or oom conditions will result in silently lost events or ...

I meant a process that gets killed or simply exits while there are outstanding perm events. Nothing in the code would wake up the processes blocked on the perm event; they will simply be stuck forever. (They cannot even be killed with SIGKILL.) This is easy to reproduce with a listener that is killed while processing a perm event: just run the fanotify example [1] with the new -s option and hit ^C while it is sleeping. Bonus points would be awarded to make a process blocked on a ...

I've never said the fd can't be used for anything. The idea would be to allow the file to be stat()ed, to poke around in /proc/fd/ in the hope to get a somewhat useful pathname out, or to use something like xstat() on the fd one day (David Howells is going to be looking into that). It would be a good thing to be able to use the same mechanisms for Nonsense. An overflow event obviously is not associated with any one file, so that would be the (only) case where you should get an event that ...

I remember you bringing this up. The persistent handles require CAP_DAC_READ_SEARCH for using open_by_handle() to prevent an unprivileged process from forging handles and bypassing directory permission checks. This would be okay for users of fanotify which can listen to all events in their namespace (and which requires CAP_SYS_ADMIN anyway). I don't see how open_by_handle() could be made safe to use by arbitrary processes; I don't think we can make the handles cryptographically ...

What kind of integration do you mean? I see three levels: 1. Integration on API level meaning that some kind of existing API is used instead of new cma_*() calls. CMA adds notion of devices and memory types which is new to all the other APIs (coherent has notion of devices but that's not enough). This basically means that no existing API can be used for CMA. On the other hand, removing notion of devices and memory types would defeat the whole purpose of CMA thus ...

On Fri, 20 Aug 2010 08:38:10 +0200 Have you even tried to search 'blk_kmalloc' on google? I wrote 4k to 40k? I'm not sure. But If I see something like the following, I suspect that there is a better way to integrate this into the existing infrastructure. mm/cma-best-fit.c | 407 +++++++++++++++ --

You can create something similar to the existing API for memory allocator. For example, blk_kmalloc/blk_alloc_pages was proposed as memory allocator API with notion of an address range for allocated memory. It wasn't merged for other reasons though. I don't mean that this is necessary for the inclusion (I'm not the person to ack or nack this). I just expect the similarity of memory Well, why can't we do the above before the inclusion? Anyway, I think that comments from mm people would ...

Because they are insufficient. Either that or I don't understand gfp_t. With CMA, platform can define many memory types. For instance, if there are two memory bans there can be two memory types for the two banks. For at least one of the device I'm in contact with, another type for it's firmware is also needed. Two things: I'd prefer a "cma" prefix rather then "dev" and I think it should be "pages", right? Then, size should be given in pages rather then bytes. I'll try to look at it ...

I tested this patch and Robert's on an AMD box and Nehalem box. Both worked as intended. However I did notice that whenever the AMD box detected handled >1, it was shortly followed by an unknown_nmi that was properly eaten with Robert's logic. Whereas on the Nehalem box I saw a lot of 'handled > 1' messages but very very few of them were followed by an unknown_nmi message (and those messages that did come were properly eaten). Maybe that is just the differences in the cpu designs. Of ...

Only if there's any remaining set bits in the overflow status reg, right? But if we want to be paranoid, we should also check if the event that generated the overflow actually had the INT flag enabled, I guess ;-) --

I've got two patches queued, one from Robert (with a slight modification, which removes a goto) and one from myself converting the intel and p4 irq handler. They're available at: programming.kicks-ass.net/sekrit/patches.tar.bz2 I did add Tested-by tags, although I suspect its not the exact same bits Don tested.. --

Might not this be the case of AAN93 erratum, which says the following | The processor can be configured to issue a PMI (performance monitor interrupt) | upon overflow of the IA32_FIXED_CTR0 MSR (309H). A single PMI should be observed on | overflow of IA32_FIXED_CTR0, however multiple PMIs are observed when this | erratum occurs. Just a thought. -- Cyrill --

Easy enough. Cheers, Don --

it's not working so well, i'm getting: Uhhuh. NMI received for unknown reason 00 on CPU 9. Do you have a strange power saving mode enabled? Dazed and confused, but trying to continue on a nehalem box, after a perf top and perf stat run. Thanks, Ingo --

My Ack if needed --

Indeed, Rafael and Alan Stern are working to make pm_qos do what the Android guys need, which could (very roughly) be thought of as extending the jitter/fuzz such that it meets Android's requirements. Thanx, Paul --

%s %c %p %u %g 11 12345678901234567890123456789012345678 %t" > \ /proc/sys/kernel/core_pattern This is okay because the strings is less than CORENAME_MAX_SIZE. "cat /proc/sys/kernel/core_pattern" shows the whole string. but after we run core_pattern_pipe_test in man page, we found last parameter was truncated like below: argc[10]=<12807486> The root cause is core_pattern allows % specifiers, which need to be replaced during parse time, but the replace may expand the strings to ...

That is true for all current CPUs, but is not guaranteed for the future. -hpa --

I think architecturally it's not safe to assume 2 siblings per core on x86 although so far HT implementations have been having 2 siblings per core. Linux kernel doesn't assume 2 siblings per core during initialization (please check arch/x86/kernel/smpboot.c). This is right way to handle potential non 2 sibling case in the future. Thanks. -Fenghua --

Hi, Tested on AP4EVB (sh7372) with SDHC and MMC cards - no regression. Tested-by: Arnd Hannemann <arnd@arndnet.de> --

Hi Ian, Any update on this? I'd like to see this patch upstream since it unbreaks SDIO support for platforms with SDHI controllers. I have a BCM4318-based SDIO card that I can send with snail mail from Japan if anyone is interested in testing on non-SDHI platforms. Thanks, / magnus --

Thanks, Arnd! Andrew, is there anything you need to (re)pick-up this patch? At the current point this patch has: Signed-off-by: Yusuke Goda <yusuke.goda.sx@renesas.com> Acked-by: Magnus Damm <damm@opensource.se> Tested-by: Arnd Hannemann <arnd@arndnet.de> Ian Molton also gave his "Acked-by" in a different email thread, please see below: Thanks for the help everyone and sorry about the confused state of things. / magnus --

After a few days of running 2.6.35.2 without problem, I got the same huge slowness for a few tens of seconds yesterday. Did not have time to run perf (and the system was almost unresponsive), but I will try to do so if the problem occurs again. Anyway, even if less frequent than during the -rcs, and as nothing had been commited to fix it before final, the problem is still there... It seems that the problem occurs after some CPU intensive tasks have been run for some time (ie compiling a ...

We can add: Christoph, Is this patch handled by you as part of your patch series or should I include it in "Trivial" or "AT91" patch series? -- Nicolas Ferre --