Introduces a few of the system call inspection functions for ARM. The current motivation is checkpoint restart, but the general interface requirements are met, making it possible for a debugger or tracer to obtain information about the system call status of another process. The patch is in part based on the following proposal from Roland McGrath: https://patchwork.kernel.org/patch/32101/ Compared to other architectures, the code to implement syscall_get_nr is somewhat comprehensive. However, ...

Implements architecture specific requirements for checkpoint/restart on ARM. The changes touch almost only c/r related code. Most of the work is done in arch/arm/checkpoint.c, which implements checkpointing of the CPU and necessary fields on the thread_info struct. The following restrictions are enforced: ---------------------------------------- The CPU architecture (given by cpu_architecture()) is checkpointed and verified against the CPU architecture on restart. We require that the restart ...

Hi Greg, Today's linux-next build (x86_64 allmodconfig) produced this warning: drivers/usb/serial/ti_usb_3410_5052.c: In function 'ti_download_firmware': drivers/usb/serial/ti_usb_3410_5052.c:1738: warning: format '%d' expects type 'int', but argument 5 has type 'size_t' Introduced by commit cdc04834ce70343aa6f87c5332ec66c35d968967 ("USB: ti_usb_3410_5052: adding multitech dialup fax/modem devices"). -- Cheers, Stephen Rothwell ...

On Tue, 27 Apr 2010 09:23:46 +1000 I'll fix that tomorrow and send it to Greg --

From: Alan Ott <alan@signal11.us> Make hidraw not stick an extra byte on the beginning of an IN transfer when a HID device contains multiple reports. Signed-off-by: Alan Ott <alan@signal11.us> --- In drivers/hid/hid-core.c, hid_report_raw_event() does the following to pass the raw data to hidraw: if (hid->claimed & HID_CLAIMED_HIDRAW) { /* numbered reports need to be passed with the report num */ if (report_enum->numbered) ...

I don't think it's sufficient, actually. We regularly see machines where devices point into e820_reserved memory above 1 MB - because it's a platform device or because firmware (e.g. smm) is touching the device. I think Bjorn's fix is great for .34, but longer term I think we need to structure the code to actually handle reserved regions differently from occupied/forbidden regions. -- Sent from my Android phone with K-9 Mail. Please excuse my brevity.

Properly done, these aren't separate cases at all. The E820 interface as specified doesn't reserve the address space below 1 MB, because it is legacy space -- which is another way of saying "everyone already knows to reserve it." The Right Thing[TM] to do is simply to modify the data output by E820 to reserve all non-memory space below 1 MB; this can (and should) be done in platform-specific initialization code to allow overrides. Once that is done, both your (2) and (3) cases are nothing ...

After digging around a lot, I believe the following two patches are the best way to close the race that allows a migration PTE to be left behind triggering a BUG check in migration_entry_to_page(). Patch one alters has fork() wait for migration to complete. Patch two has vma_adjust() acquire the anon_vma lock it is aware of and makes rmap_walk() aware that different VMAs can be encountered during the walk. I dropped the use of the seq counter because there were still races in place. For ...

So patch 1 is for aa.git too, and patch 2 is only for mainline with the new anon-vma changes (patch 2 not needed in current aa.git, and if I apply it, it'll deadlock so...) right? split_huge_page is somewhat simpler and more strict in its checking than migrate.c in this respect, and yes patch 2 will also need to be extended to cover split_huge_page the moment I stop backing out the new anon-vma code (but it won't be any different, whatever works for migrate will also work for split_huge_page ...

From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> From: KAMEZAWA Hiroyuki <kamezawa.hiroyu@jp.fujitsu.com> At page migration, we replace pte with migration_entry, which has similar format as swap_entry and replace it with real pfn at the end of migration. But there is a race with fork()'s copy_page_range(). Assume page migraion on CPU A and fork in CPU B. On CPU A, a page of a process is under migration. On CPU B, a page's pte is under copy. CPUA CPU ...

Alan, The st_recv is a global pointer to a function, and changes only once in lifetime of the driver (after a function called download_firmware). This can be easily avoided by having a flag in my st_tty_recieve function, as in if (test_bit(FIRMWARE_DOWNLOADED, st_gdata->st_state) /* * if fw download is in progress then route incoming data * to KIM for validation */ st_int_recv(data, count); else kim_recv(data, count); ...

Hi, I've been following the Transparent Hugepage patch set over the last few weeks and have been experimenting with leveraging the functionality in VMware's Linux virtualization software (eg: Workstation, Player). The initial results have been extremely positive. We have a standardized VM workload that we use to demonstrate the difference that large page support makes - it's a Linux VM running the SPECjbb benchmark in a JVM that has itself been configured to use large pages through hugetlbfs - as ...

New targets are added (coccicheck-<mode>) to call the spatch front-end in the 'scripts' directory with the <mode> argument. Four modes are defined: report, patch, context, and org. 'report' mode generates a list in the following format: file:line:column-column: message 'patch' mode proposes a generic fix, when possible. 'context' mode highlights lines of interest and their context in a diff-like style. 'org' mode generates a report in the Org mode format of Emacs. Three semantic ...

The purpose of this semantic patch is to remove useless casts, as mentioned in the Linux documentation. See Chapter 14 in Documentation/CodingStyle for more information. Signed-off-by: Nicolas Palix <npalix@diku.dk> --- scripts/smpl/drop_kmalloc_cast.cocci | 74 ++++++++++++++++++++++++++++++++++ 1 files changed, 74 insertions(+), 0 deletions(-) create mode 100644 scripts/smpl/drop_kmalloc_cast.cocci diff --git a/scripts/smpl/drop_kmalloc_cast.cocci ...

This semantic patch replaces explicit computations of resource size by a call to resource_size. Signed-off-by: Nicolas Palix <npalix@diku.dk> --- scripts/smpl/resource_size.cocci | 101 ++++++++++++++++++++++++++++++++++++++ 1 files changed, 101 insertions(+), 0 deletions(-) create mode 100644 scripts/smpl/resource_size.cocci diff --git a/scripts/smpl/resource_size.cocci b/scripts/smpl/resource_size.cocci new file mode 100644 index 0000000..e5e24ac --- /dev/null +++ ...

--

When using remake, which is based on gnumake, if you invoke an example build as shown below, the build will become silent due to the top level make file incorrectly guessing that the end user wants a silent build because an argument that contained an "s" was used. remake --no-extended-errors Fix up the top level Makefile to use filter with a list of options that mean silent with the various revisions of gnumake, instead of findstring. Signed-off-by: Jason Wessel ...

That could be the answer. Clearly this should be handled by the arch-specific boot/setup code. I don't know enough about it, but other people do. Alan Stern --

This is an RFC patch set that also affects kprobes and perf. At the Linux Collaboration Summit, I talked with Mathieu and others about lowering the footprint of trace events. I spent all of last week trying to get the size as small as I could. Currently, each TRACE_EVENT() macro adds 1 - 5K per tracepoint. I got various results by adding a TRACE_EVENT() with the compiler, depending on config options that did not seem related. The new tracepoint I added would add between 1 and 5K, but I did ...

From: Steven Rostedt <srostedt@redhat.com> Now that the trace_event structure is embedded in the ftrace_event_call structure, there is no need for the ftrace_event_call id field. The id field is the same as the trace_event type field. Removing the id and re-arranging the structure brings down the tracepoint footprint by another 5K. text data bss dec hex filename 5788186 1337252 9351592 16477030 fb6b66 vmlinux.orig 5761154 1268356 9351592 16381102 ...

From: Steven Rostedt <srostedt@redhat.com> This patch allows data to be passed to the tracepoint callbacks if the tracepoint was created to do so. If a tracepoint is defined with: DECLARE_TRACE_DATA(name, proto, args) Then a registered function can also register data to be passed to the tracepoint as such: DECLARE_TRACE_DATA(mytracepoint, TP_PROTO(int status), TP_ARGS(status)); /* In the C file */ DEFINE_TRACE(mytracepoint, TP_PROTO(int status), TP_ARGS(status)); ...

From: Steven Rostedt <srostedt@redhat.com> Currently, every event has its own trace_event structure. This is fine since the structure is needed anyway. But the print function structure (trace_event_functions) is now separate. Since the output of the trace event is done by the class (with the exception of events defined by DEFINE_EVENT_PRINT), it makes sense to have the class define the print functions that all events in the class can use. This makes a bigger deal with the syscall events since ...

From: Steven Rostedt <srostedt@redhat.com> The raw_init function pointer in the event is used to initialize various kinds of events. The type of initialization needed is usually classed to the kind of event it is. Two events with the same class will always have the same initialization function, so it makes sense to move this to the class structure. Perhaps even making a special system structure would work since the initialization is the same for all events within a system. But since ...

From: Steven Rostedt <srostedt@redhat.com> Switch the TRACE_EVENT() macros to use DECLARE_TRACE_DATA(). This patch is done to prove that the DATA macros work. If any regressions were to surface, then this patch would help a git bisect to localize the area. Once again this patch increases the size of the kernel. text data bss dec hex filename 5788186 1337252 9351592 16477030 fb6b66 vmlinux.orig 5792282 1333796 9351592 16477670 ...

I was going to say the same thing. For ease of use, I recommend using a "SCSI eject" to trigger the mode change. That way, Linux users who don't have the usb-modeswitch program installed can get the same effect by running eject. Alan Stern --

Series looks good to me, nice job. greg k-h --

Need sleep... Can't even remember the name of the iio list. Sorry all. Rather than reposting the whole series, I'll send a copy there as well with a note to cc lkml and try and ensure anything of more general interest does get sent on. --

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/light/tsl2563.c | 12 ++++++++++++ 1 files changed, 12 insertions(+), 0 deletions(-) diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c index 911c898..da3d51c 100644 --- a/drivers/staging/iio/light/tsl2563.c +++ b/drivers/staging/iio/light/tsl2563.c @@ -598,12 +598,24 @@ static DEVICE_ATTR(calib0, S_IRUGO | S_IWUSR, static DEVICE_ATTR(calib1, S_IRUGO | S_IWUSR, ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/Documentation/iio_utils.h | 277 ++++++++++++-------- .../iio/Documentation/lis3l02dqbuffersimple.c | 237 +++++++++++------ 2 files changed, 314 insertions(+), 200 deletions(-) diff --git a/drivers/staging/iio/Documentation/iio_utils.h b/drivers/staging/iio/Documentation/iio_utils.h index d24006a..a4555e6 100644 --- a/drivers/staging/iio/Documentation/iio_utils.h +++ ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/adc/Kconfig | 12 ++- drivers/staging/iio/adc/max1363_core.c | 143 ++++++++++++++++++++++++++++++-- drivers/staging/iio/adc/max1363_ring.c | 23 ++++-- 3 files changed, 161 insertions(+), 17 deletions(-) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index afc8318..0835fbc 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -10,11 +10,13 @@ ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/adc/Kconfig | 4 +- drivers/staging/iio/adc/max1363_core.c | 216 +++++++++++++++++++++++++++++++- 2 files changed, 218 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/adc/Kconfig b/drivers/staging/iio/adc/Kconfig index 101ea4b..afc8318 100644 --- a/drivers/staging/iio/adc/Kconfig +++ b/drivers/staging/iio/adc/Kconfig @@ -12,7 +12,9 @@ config MAX1363 Say yes here to build support for many ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/light/tsl2563.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/staging/iio/light/tsl2563.c b/drivers/staging/iio/light/tsl2563.c index 1ba4aa3..911c898 100644 --- a/drivers/staging/iio/light/tsl2563.c +++ b/drivers/staging/iio/light/tsl2563.c @@ -592,7 +592,7 @@ static ssize_t tsl2563_calib1_store(struct device *dev, * once I understand what they mean */ static DEVICE_ATTR(adc0, ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/accel/lis3l02dq_ring.c | 2 +- drivers/staging/iio/accel/sca3000_core.c | 2 +- drivers/staging/iio/adc/max1363_ring.c | 2 +- drivers/staging/iio/industrialio-ring.c | 48 +++++++--------------------- drivers/staging/iio/ring_generic.h | 2 +- 5 files changed, 16 insertions(+), 40 deletions(-) diff --git a/drivers/staging/iio/accel/lis3l02dq_ring.c ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/Documentation/iio_utils.h | 31 ++++++++++++++++++++++++- 1 files changed, 30 insertions(+), 1 deletions(-) diff --git a/drivers/staging/iio/Documentation/iio_utils.h b/drivers/staging/iio/Documentation/iio_utils.h index 74d3124..d24006a 100644 --- a/drivers/staging/iio/Documentation/iio_utils.h +++ b/drivers/staging/iio/Documentation/iio_utils.h @@ -47,7 +47,7 @@ inline char *find_ring_subelement(const char ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/industrialio-core.c | 25 ++++++++++++------------- 1 files changed, 12 insertions(+), 13 deletions(-) diff --git a/drivers/staging/iio/industrialio-core.c b/drivers/staging/iio/industrialio-core.c index c19a080..3df23be 100644 --- a/drivers/staging/iio/industrialio-core.c +++ b/drivers/staging/iio/industrialio-core.c @@ -676,16 +676,14 @@ static int iio_device_register_eventset(struct iio_dev *dev_info) ...

Signed-off-by: Jonathan Cameron <jic23@cam.ac.uk> --- drivers/staging/iio/accel/accel.h | 8 +- drivers/staging/iio/accel/kxsd9.c | 88 ++++++++------ drivers/staging/iio/accel/lis3l02dq.h | 4 - drivers/staging/iio/accel/lis3l02dq_core.c | 175 ++++++++++++++------------- drivers/staging/iio/accel/lis3l02dq_ring.c | 8 +- drivers/staging/iio/accel/sca3000.h | 2 + drivers/staging/iio/accel/sca3000_core.c | 172 +++++++++++++-------------- ...

idr_find() doesn't allocate, idr_get_new_above() does. Assuming idr_find() never fails for an id if idr_get_new_above() successfully allocated that id, I don't think we can reach that line with pdesc being NULL: - There are two gotos leading to free_sd - #2 is after a block that allocates pdesc - #1 is in an if (!gpio_flags) block - We exit early if ((desc->flags & GPIO_TRIGGER_MASK) == gpio_flags) - Therefore (desc->flags & GPIO_TRIGGER_MASK) must be != 0 to reach #1 - Trigger flags are ...

On Tue, 27 Apr 2010 01:05:15 +0200 heh, thanks. I figured that something like that might be going on but couldn't be bothered picking through it all. That being said, the above sequence of steps is awfully (and unusually) intricate and is hence hard to preserve and could get broken at some future time. --

I had exactly the same problem (on an HP computer with an Intel chipset). As far as anyone could figure out, it is caused by a bug in the BIOS. It's not entirely clear that this is the complete answer, but nothing else turned up. See http://bugzilla.kernel.org/show_bug.cgi?id=15385 for the complete record. The best solution I could find was to boot with "idle=halt" on the command line. You might check to see if any BIOS updates are available. Alan Stern --

Hi Ingo, Please pull from: git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux-2.6 perf - Arnaldo Masami Hiramatsu (4): perf tools: Initialize dso->node member in dso__new perf probe: Fix to use symtab only if no debuginfo perf probe: Fix to exit callback soon after finding too many probe points perf probe: Add --max-probes option Stefan Hajnoczi (1): perf tools: Fix libdw-dev package name in error message tools/perf/Documentation/perf-probe.txt | 3 ++ ...

Hello, I'm trying to debug oops on resume from suspend-to-RAM on Asus P4P800-VM mainboard. It crashes with invalid opcode (see below). The kernel is 2.6.32-trunk from Debian but the same problem is present with vanilla kernels - both newer and older (but screen remains blank most of the time, only keyboard LEDs blink indicating an oops). What can cause this problem? 8.000339 invalid opcode: 0000 [#1] SMP 8.003529 last sysfs file: /sys/power/state 8.004265 Modules linked ...

When combined with function graph tracing the ftrace function profiler also prints the average run time of functions. While this gives us some good information, it doesn't tell us anything about the variance of the run times of the function. This change prints out the s^2 sample standard deviation alongside the average. This change adds one entry to the profile record structure. This increases the memory footprint of the function profiler by 1/3 on a 32-bit system, and by 1/5 on a 64-bit system ...

From: Deepak Saxena <dsaxena@laptop.org> This patch adds minimal support for suspend/resume of the VIA framebuffer device. It requires a version of OFW that restores the video mode. This patch is OLPC-specific as the proper upstream solution is to move the VIA video path to using the kernel modesetting infrastructure and doing a proper save/restore in the kernel. [jc: extensive changes for 2.6.34 merge] Signed-off-by: Deepak Saxena <dsaxena@laptop.org> --- drivers/video/via/viafbdev.c | ...

viafb: fix hardware acceleration for suspend & resume This patch splits the acceleration initialization in two parts: The first is only called during probe and is used to allocate resources. The second part is also called on resume to reinitalize the 2D engine. This should fix all acceleration issues after resume most notable an "invisible" cursor and as we do nothing special it is reasonable to assume that it works on all supported IGPs. Signed-off-by: Florian Tobias Schandinat ...

Hi, This is the last series I've sent, with comments from you merged. The first 5 patches are the same, only with the suggested fixes. I am leaving documentation out, since the basics won't change, and we're still discussing the details. Patch 6 is new, and is the guest side of the skipping updates avi asked for. I haven't yet done any HV work on this (specially because I am not convinced exactly where it is safe to do). Let me know what you think. Thanks Glauber Costa (6): ...

This patch removes one padding byte and transform it into a flags field. New versions of guests using pvclock will query these flags upon each read. Flags, however, will only be interpreted when the guest decides to. It uses the pvclock_valid_flags function to signal that a specific set of flags should be taken into consideration. Which flags are valid are usually devised via HV negotiation. Signed-off-by: Glauber Costa <glommer@redhat.com> CC: Jeremy Fitzhardinge <jeremy@goop.org> --- ...

We now added a new set of clock-related msrs in replacement of the old ones. In theory, we could just try to use them and get a return value indicating they do not exist, due to our use of kvm_write_msr_save. However, kvm clock registration happens very early, and if we ever try to write to a non-existant MSR, we raise a lethal #GP, since our idt handlers are not in place yet. So this patch tests for a cpuid feature exported by the host to decide which set of msrs are ...

Avi pointed out a while ago that those MSRs falls into the pentium PMU range. So the idea here is to add new ones, and after a while, deprecate the old ones. Signed-off-by: Glauber Costa <glommer@redhat.com> --- arch/x86/include/asm/kvm_para.h | 4 ++++ arch/x86/kvm/x86.c | 7 ++++++- 2 files changed, 10 insertions(+), 1 deletions(-) diff --git a/arch/x86/include/asm/kvm_para.h b/arch/x86/include/asm/kvm_para.h index ffae142..9734808 100644 --- ...

Hello, there's a different behaviour between 2.6.33.3 and 2.6.34-rc5 observed at a ThinkPad T400 with intel graphic GM45 . If it is docked and the lid is closed (1440x900) and an external DVI monitor (1650x1080) is connected at the docking station - the dmesg of 2.6.33.3 gives: Console: switching to colour frame buffer device 210x65 whereas 2.6.34 gives: Console: switching to colour frame buffer device 180x56 Furthermore X differs in the fact, that 2.6.33.3 sets the external monitor to ...

On Mon, 26 Apr 2010 16:44:41 +0100 I don't think I understand that description. Are you saying that the patch switches things from the first example output into the second case? Is the fix needed in -stable? --

The request_key() system call and request_key_and_link() should make a link from an existing key to the destination keyring (if supplied), not just from a new key to the destination keyring. This can be tested by: ring=`keyctl newring fred @s` keyctl request2 user debug:a a keyctl request user debug:a $ring keyctl list $ring If it says: keyring is empty then it didn't work. If it shows something like: 1 key in keyring: 1070462727: --alswrv 0 0 user: ...

diff --git a/Documentation/i2c/busses/i2c-i801 b/Documentation/i2c/busses/i2c-i801 index 81c0c59..e1bb5b2 100644 --- a/Documentation/i2c/busses/i2c-i801 +++ b/Documentation/i2c/busses/i2c-i801 @@ -15,7 +15,8 @@ Supported adapters: * Intel 82801I (ICH9) * Intel EP80579 (Tolapai) * Intel 82801JI (ICH10) - * Intel PCH + * Intel 3400/5 Series (PCH) + * Intel Cougar Point (PCH) Datasheets: Publicly available at the Intel website Authors: diff --git a/Makefile ...

I'm announcing the release of the 2.6.32.12 kernel. All users of the 2.6.32 kernel series should upgrade. Many thanks to maximilian attems for all of his hard work in digging out patches from the various vendor kernel trees for this release. It is much appreciated. The updated 2.6.32.y git tree can be found at: git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.32.y.git and can be browsed at the normal kernel.org git web browser: ...

From: Christoph Egger <siccegge@cs.fau.de> The checks for CONFIG_MMU at this location are duplicated as all the code is located inside a #ifndef CONFIG_MMU block. So the first conditional block will always be included while the second never will. Signed-off-by: Christoph Egger <siccegge@stud.informatik.uni-erlangen.de> Signed-off-by: David Howells <dhowells@redhat.com> --- fs/binfmt_elf_fdpic.c | 7 ------- 1 files changed, 0 insertions(+), 7 deletions(-) diff --git ...

From: Dmitry Eremin-Solenikov <dbaryshkov@gmail.com> Applied, and queued up for -stable too, thanks guys. --

(adding Cc: lkml, quoting in full) I got a FW643 card a few days ago and can test that one. Also, I have a JMicron JMB381 native PCIe 1394a controller. The latter is a less ideal test specimen since it is buggy already without MSI (soon stops to operate if one dares to mix isochronous and asynchronous I/O; sometimes also if there is a bus reset at an inconvenient time). From lspci: 04:00.0 FireWire (IEEE 1394): Agere Systems FW643 PCI Express1394b Controller (PHY/Link) (rev 07) ...

elfutils-dev is wrong, elfutils-devel is right, at least for Fedora. % repoquery -ql elfutils-devel.x86_64 /usr/include/dwarf.h /usr/include/elfutils /usr/include/elfutils/elf-knowledge.h /usr/include/elfutils/libasm.h /usr/include/elfutils/libdw.h /usr/include/elfutils/libdwfl.h /usr/include/elfutils/libebl.h /usr/include/elfutils/version.h /usr/lib64/libasm.so /usr/lib64/libdw.so /usr/lib64/libebl.a

Thanks, applied --

When one regulator supplies another allow the relationship to be specified using names rather than struct regulators, in a similar manner to that allowed for consumer supplies. This allows static configuration at compile time, reducing the need for dynamic init code. Also change the references to LINE supply to be system supply since line is sometimes used for actual supplies and therefore potentially confusing. Signed-off-by: Mark Brown <broonie@opensource.wolfsonmicro.com> --- ...

Hi all! As part of the VAMOS[0] research project at the University of Erlangen we are looking at multiple integrity errors in linux' configuration system. The following patch removes a unnecessary conditional. Inside a block making sure CONFIG_64 isn't set the option is checked again and based on that some parts are (not) included. As the outer check already makes sure CONFIG_64 isn't set here both checks are unnecessary so this patch removes them. Please keep me informed of this patch ...

Hi all! As part of the VAMOS[0] research project at the University of Erlangen we are looking at multiple integrity errors in linux' configuration system. The following patch removes a unnecessary conditional. Inside a block making sure CONFIG_MMU isn't set the option is checked again and based on that some parts are (not) included. As the outer check already makes sure CONFIG_MMU isn't set here both checks are unnecessary so this patch removes them. Please keep me informed of this ...

I have not seen any more e-mail on this. How is it going? Is there any chance of rolling in some corrections for the SCHED_SPORADIC treatment? In particular, could we have a DO_NOT_RUN priority, that is guaranteed to prevent a task from running at all? For more detail, see http://ww2.cs.fsu.edu/~stanovic/papers/rtas10.pdf . Ted --

One limitation of SIGSTOP is that the last time I instrumented it in detail, which admittedly was several years ago, every process you send the message to has to run long enough to receive the message. We were in the the position of sending it to fairly large groups of processes, partly through laziness in code structure, but when I looked at the time lines I was appalled to see a large number of context switches for *very* short execution intervals. All were associated with receiving the ...

Why are you using two configurations on this device instead of one configuration with two interfaces? Interfaces are not allowed to share endpoints within one configuration, so they can be used simultaniously. Daniel --

If you do that, the configuration which is chosen eventually purely Maybe Windows just selects the interface it has a driver for already? On the other hand, that would be giving a hint of some sort of intelligence, which I can't believe either as their USB stack is totally screwed. Not a single detail in its implementation seems to make any Yeah, great technology. Even if you install the driver (which you have to do even for USB sticks), you'll be prompted for the same action again once you ...

These are the notorious mode switching devices. In Windows, they obviously install a special storage driver doing one specific action on each following plugging. This action - some storage or control command - will "flip" the device, making it "disconnect" and returning as a completely different composite device. Storage commands used for this procedure range from "SCSI rezero" over "passthrough" to "SCSI eject", or involve vendor specific stuff. Josua Dietze --

From: Yulia Vilensky <vilensky@compulab.co.il> v2 changes: * add ds278x_platform_data * address Anton comments v3 changes: * use ds278x_get_temp for both ds2782 and ds2786 * update math as per Ryan comments Signed-off-by: Yulia Vilensky <vilensky@compulab.co.il> Signed-off-by: Mike Rapoport <mike@compulab.co.il> --- drivers/power/Kconfig | 4 +- drivers/power/ds2782_battery.c | 184 +++++++++++++++++++++++++++++----------- include/linux/ds2782_battery.h | 8 ++ 3 ...

-- Sincerely Yours, Mike. --

From: Serge E. Hallyn <serue@us.ibm.com> Change the credentials documentation to make it clear that the RCU read lock must be explicitly held when accessing credentials pointers in some other task than current. Holding a spinlock does not implicitly hold the RCU read lock. Signed-off-by: Serge Hallyn <serue@us.ibm.com> Reviewed-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com> Signed-off-by: David Howells <dhowells@redhat.com> --- Documentation/credentials.txt | 14 +++++--------- 1 ...

Hi All, I'am trying to implement zero copy in USBIP while sending / receiving usbip packets. I started it with send path. The device which I used is mass storage. I'am using linux kernel 2.6.15. After virtualization, once the file copy starts from device to pc each usbip packet carries payload of 64K. I'am allocating this 64K buffer through __get_free_pages() (with order 4) and assigning the buffer pointer to urb. After completion of URB i'am trying to send this buffer page by page by ...

From: Fabien Chouteau <fabien.chouteau@barco.com> This patch adds handling of the "Start/Stop Unit" SCSI request to simulate media ejection. Signed-off-by: Fabien Chouteau <fabien.chouteau@barco.com> --- drivers/usb/gadget/f_mass_storage.c | 48 ++++++++++++++++++++++++++++++++-- 1 files changed, 45 insertions(+), 3 deletions(-) diff --git a/drivers/usb/gadget/f_mass_storage.c b/drivers/usb/gadget/f_mass_storage.c index f4911c0..c3e5dbb 100644 --- ...

Let me try sending this patcha again... David --

Should help Alpha as well. Acked-by: Matt Turner <mattst88@gmail.com> --

Eric, Brice, what is the point of issuing wbinvd() on all CPUs here if clflush isn't available, but using clflush() (if available) only on the current CPU? Thanks, Jan --

Remove redundant gpio_request: The GPIO used as trigger IRQ, is also requested as gpio, but actually never read. Use platform resource facility to get IRQs numbers and flags. Make sure this driver can be used with any system IRQ, not necessarily limited to GPIO-IRQs. Use dev_err(dev...) and friends instead of printk(KERN_ERR...) Signed-off-by: Michael Hennerich <Michael.Hennerich@analog.com> Acked-by: Jonathan Cameron <jic23@cam.ac.uk> drivers/staging/iio/trigger/iio-trig-gpio.c | 127 ...

Hi, This is my first post to the group, please excuse me, If I unknowingly miss to follow writing ethics. Proposal/Need: I was working on providing accurate process usage support, and writing a kernel module, I configured cpu-core-unhalted-event and configured LVT (local vector table) with NMI (non-maskable interrupt), and surprisingly Oprofile stopped working, Then I realized, that set_nmi_call back just overwrites nmi_callback function pointer. My proposal/idea/thinking is; have a ...

Here is the rest of the security branch with minor whitespace fixes with using (L)indent. Signed-off-by: Justin P. Mattock <justinmattock@gmail.com> --- security/keys/process_keys.c | 12 ++++++------ security/keys/request_key.c | 4 ++-- security/keys/request_key_auth.c | 5 ++--- security/lsm_audit.c | 1 - security/security.c | 6 +++--- security/selinux/hooks.c | 4 ++-- security/selinux/selinuxfs.c | 10 +++++----- ...

Thanks Barry. Ironically I rewrote this example yesterday to match the new abi (though I hadn't noticed the documentation error!). Still worth merging this as it may be a little while before everyone is happy with that patch set. Will hopefully post a new revision of that later today. --

This appears to be another symptom of the bug you located in your earlier testing, so either Eric Biederman sends a patch or I improvise. And thank you again for all your testing, Miles!!! Thanx, Paul --

I created a Bugzilla entry at https://bugzilla.kernel.org/show_bug.cgi?id=15857 for your bug report, please add your address to the CC list in there, thanks! -- Maciej Rutecki http://www.maciek.unixy.pl --

Using line continuations like this is incorrect. There are many uses like this in your proposed patch. It adds the initial whitespace on the continued line to the string constant. Except for macro definitions, linux doesn't generally use line continuations. There's no attempt to keep line numbers consistent across multiple versions. cheers, Joe --

Dear Mr. Neukum, The _open and _release functions are already serialized with mutex in fb layer. So that mutex could be removed but in my opinion this job should be done in a separate patch (like I have done some time ago for nvidiafb driver). Now I would want suggest to remove BKL here only. Ciao, Alessio --

Dear Mr. Bergmann, It is what effectively I'm trying to do! The first part of this work is already present in USB subsystem maintainer tree (aka greg) at: http://www.kernel.org/pub/linux/kernel/people/gregkh/gregkh-2.6/patches/usb/usb-sisusb... Ciao, Alessio --

Dear Mr. Bergmann, You are right. Simply I made the above-mentioned patch when BKL pushdown not yet reach _open function. :-) Ciao, Alessio --

IPI is needed when rmap_write_protect() changes mappings form writable to read-only, so while we sync all gfn's unsync page, only one IPI is needed. And, another problem is we call ramp_write_protect()/flush-local-tlb many times when sync gfn's unsync page, the same problem is in mmu_sync_children() function, could you allow me to improve it after this patchset? :-) --

Will fix it in v3, thanks --

Ugh, what I meant was shift = PAGE_SHIFT - (PT_LEVEL_BITS - PT64_LEVEL_BITS) * level; offset = q << shift so, pte_gpa = (sp->gfn << PAGE_SHIFT) + offset + (spte - sp->spt) * sizeof(pt_element_t) No magic numbers please. Note it could work without the 'if (PTTYPE == 32)'. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. --

The filesystem is supposed to serialise truncate vs write races. i.e. the truncate will occur either before the write is executed or after it has completed, not while it is running. Cheers, Dave. -- Dave Chinner david@fromorbit.com --

2010/4/26 Erwan Velu <erwanaliasr1@gmail.com>: Looks like the current code isn't taking care of a possible changing of IFF_BROADCAST. I can find some code in net/core/dev.c to handle MULTICAST or PROMISC but nothing for BROADCAST. Looks like I need then to add a .ndo_change_rx_flags function to manage this changes. Does someone confirm this is the way to go ? --

I think the superIO code is more 'evolved' than 'designed'. It's something people nailed bits onto in passing rather than structured elegantly. Do what you think is right IMHO. Alan --

AFAIK there is still nobody using it, but lsof should use it, and /proc/<pid>/task/<tid>/fd/ too. I haven't checked the code, but as it is now, it doesn't spot files open by a thread which does share its father's --

Yep you got it right. Sébastien and I have been also in contact about the new API and he has already given some feedback on an initial version of the framework. Br, Carlos --

I found the following discussion of the sched_clock() implementation trade-offs very informative: http://lkml.org/lkml/2010/4/15/299 It mentions clocksource_calc_mult_shift() which was added in 2.6.33, however I had some difficulties understanding the meaning of the minsec parameter, especially since all existing callers use a value of 4. But when using minsec = 365*24*60*60 (1 year) it results in the shift value of 8. It seems clocksource_cyc2ns() is used in ...

On Mon, Apr 26, 2010 at 6:49 PM, KAMEZAWA Hiroyuki Yes. Andrea pointed it out. I didn't followed the thread whole yet but It seems Mel and Andrea want to restore anon_vma's atomicity like old than one by one healing. -- Kind regards, Minchan Kim --

On Mon, 26 Apr 2010 08:49:01 +0900 Ok, reproduced. Here is status in my test + printk(). * A race doesn't seem to happen if swap=off. I need to swapon to cause the bug. * Before unmap, mapcount=1, SwapCache for anonymous memory. old page's flag was SWAPCACHE, Active, Uptodate, Referenced, Locked. * After remap, mapcount=0, return code=0. new page's flag after remap was SwapCache, Active, Dirty, Uptodate, Referenced. (Hmm, dirty bit can be added by ...

Hi, Mel. Actually, I can't understand why we need to hold lock of vma->anon_vma->lock? I think seqcounter is enough. I looked at your scenarion. More exactly, your scenario about unmap is following as. 1. VMA A-Lower - VMA A-Upper (include hole) 2. VMA A-Lower - VMA hole - VMA A-Upper(except hole) 3. VMA A-Lower - hole is remove at last - VMA A-Upper. I mean VMA A-upper is already linkeded at vma list through __insert_vm_struct atomically(by seqcounter). So rmap can find proper ...

On Mon, Apr 26, 2010 at 6:28 PM, KAMEZAWA Hiroyuki FYI, Do you have a swapon/off bomb test? When I saw your mail, I feel it might be culprit. http://lkml.org/lkml/2010/4/22/762. It is just guessing. I don't have a time to look into, now. -- Kind regards, Minchan Kim --

I haven't tried a swapon/off test but that patch is certainly important and closes an important race. A fork-heavy test will routinely hit the problem and applying the patch makes it very difficult to reproduce the problem. I've added it to my stack while I continue trying to pin down when the VMA-changes make a difference. I'm relooking at the seq counter approach. It appears to very rare the logic is actually triggered so reproducing is a problem. I'm still not convinced that just locking ...

Agreed, we could/should do much better. Agreed, I'm sure that it is frustrating to the contributors. Agreed about Linus taking it either way. :) -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

Yeah, I think that it should be in procfs. It's not strictly closed to new files. (IOW, I'm sure that we can find a bunch of recent files I don't think that we want to make debugfs required to get decent tuning info/stats from the kernel. That's all. -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

OK, thanks for the info. Sounds good (i.e., it is debug info). -- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** --

Thanks, Valdis. I encountered this error and thought I fixed it before submitting the series. Apparently I submitted a stale patch. Attached patch fixes the problem. Lee ======================================== Fix to numa-introduce-numa_mem_id-effective-local-memory-node-id.patch in mmotm 100422-1638 Add missing parenthesis to !NUMA stub cpu_to_mem() definition Signed-off-by: Lee Schermerhorn <lee.schermerhorn@hp.com> include/asm-generic/topology.h | 2 +- 1 file ...

It's queued up, thanks. -- Jens Axboe --

This patch is causing kernel panic on boot on Magny Cours CPU here (cpu family 16, model 9, stepping 1). Please see screenshot from the paniced kernel on http://www.jikos.cz/jikos/junk/screenshot.jpg (sorry for bad quality of this screenshot, it was captured only from the IPMI/HTTP console so far, I will try to grab something better tomorrow) Also this screenshot probably doesn't show the complete picture -- see the "end trace" marker on the very first line. I will try to have ...

blkiocg_add_blkio_group() also calls cgroup_path(), which also needs to be called within rcu_read_lock, so I think Vivek's patch is better than the one you posted in another mail thread. --

Thanks Paul. I sent this patch to Jens also, thinking he will apply to his tree. Looks like he has not applied it yet though. Jens, is it ok if this patch gets merged through paul's tree or should it go through blk tree? Thanks Vivek --

I am also happy to go either way. I guess you can go ahead with pulling it in. Thanks Vivek --

Thanks Paul. Where can I get your tree to clone from? I can test the changes. I can't find it on kernel.org. Thanks Vivek --

They don't seem to have gained much ground in the FIVE YEARS since the patch was first posted to Linux, have they? Maybe it's because memory-to-memory copy using a CPU is so fast (especially for page-ish quantities of data) and is a small percentage of CPU utilization these days? --

Ok. I agree it is silly to go through the block layer and end up Incremental development is fine, especially for ramzswap where the APIs are all internal. I'm more worried about external interfaces, these stick around a lot longer and if not done right they're a pain forever. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. --

Well if you are saying that your primary objection to the frontswap synchronous API is that it is exposed to modules via some EXPORT_SYMBOLs, we can certainly fix that, at least unless/until there are other pseudo-RAM devices that can use it. Would that resolve your concerns? --

No, we cannot issue discard bio at this place since swap_lock spinlock is held. Thanks, Nitin --

That last trace is just saying that the NFSv4 reboot recovery code is crashing (which is hardly surprising if the memory management is hosed). The initial bisection makes little sense to me: it is basically blaming a page allocation problem on a change to the NFSv4 mount code. The only way I can see that possibly happen is if you are hitting a stack overflow. So 2 questions: - Are you able to reproduce the bug when using NFSv3 instead? - Have you tried running with stack tracing ...

Sure. In addition to what you did above, please do mount -t debugfs none /sys/kernel/debug and then cat the contents of the pseudofile at /sys/kernel/debug/tracing/stack_trace Please do this more or less immediately after you've finished mounting the NFSv4 client. Does your server have the 'crossmnt' or 'nohide' flags set, or does it use the 'refer' export option anywhere? If so, then we might have to test further, since those may trigger the NFSv4 submount feature. Cheers ...

The spacing is all over the place, I'm afraid. Can you send it again? For example, the vertical bars in the right-hand column don't align: | [spin_lock(&key_serial_lock)] |[mutex_lock(&key_user_keyr..mutex)] | | || | atomic_read() == 0 || | |{ rb_ease(&key->serial_node,) } || | | || | [spin_unlock(&key_serial_lock)] |find_keyring_by_name() | | ...

Hi, David. Sorry, I missed your last mail. On Mon, 26 Apr 2010 11:57:36 +0100 So, I applied your commets and rewrite your patch. Here you are: --- From: Toshiyuki Okajima <toshi.okajima@jp.fujitsu.com> Subject: [PATCH] KEYS: find_keyring_by_name() can gain access to a freed keyring find_keyring_by_name() can gain access to a keyring that has had its reference count reduced to zero, and is thus ready to be freed. This then allows the dead keyring to be brought back into use whilst it ...

On Mon, Apr 26, 2010 at 08:44:36AM +1200, Ryan Mallon wrote: Please don't, this is an unneeded churn. I'd won't bother with renaming Kconfig symbol as well (and btw, that renaming will break oldconfig, so I strongly suggest not to do it). So, your current approch of changing the description and help text is OK. Thanks, -- Anton Vorontsov email: cbouatmailru@gmail.com irc://irc.freenode.net/bd2 --

On Thu, 22 Apr 2010 02:55:58 +0200 (CEST) You had the wrong address for linux-mm. Perhaps that explains the lack That's nuts - we shouldn't have entered page reclaim at all with 20% of memory on the freelist. --

No it's fine, I have added it. Thanks! -- Jens Axboe --

Acked-by: Serge Hallyn <serue@us.ibm.com> thanks, -serge --

-- Masami Hiramatsu e-mail: mhiramat@redhat.com --

"more precise"? Wouldn't it be "more expressive", i.e. with more information (parameter list with types, return type, location of parameters, etc), because what is common to both have the same value, --

Subject: [Patch 1/1] init: Provide a kernel start parameter to increase pid_max v3 From: Hedi Berriche <hedi@sgi.com> On a system with a substantial number of processors, the early default pid_max of 32k will not be enough. A system with 1664 CPU's, there are 25163 processes started before the login prompt. It's estimated that with 2048 CPU's we will pass the 32k limit. With 4096, we'll reach that limit very early during the boot cycle, and processes would stall waiting for an available ...

The locking for the anon_vma_chain->same_vma list is essentially the same as what was used before in mmap and anon_vma_prepare. Either the mmap_sem is held for write, or the mmap_sem is held for reading and the page_table_lock is held. What exactly is the problem that migration is seeing? -- All rights reversed --

split_huge_page has the exact same requirements, except it is more strict and it will stop zap_page_range and count that the same number of pmds it marked as splitting are found again later. Also note migration has the same "ordering" requirements for anon_vma_link during fork, new vmas have to be appended at the end or migration will choke (not going into the details of why, but I can if you want). This should be safe in new anon-vma code as I already pointed out this requirement to Rik ...

Yes, I really don't want to issue bytes to a serial port that isn't known to be initialized; it could take a *very* long time even if the port is actually present, and if the port *isn't* present it could hang the kernel. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. --

On Mon, Apr 26, 2010 at 5:05 PM, Guenter Roeck Peter? --

Sounds good to me. Peter, would that get your approval ? Guenter --

Mostly, the regression exists on Nehalem machines. I suspect it's related to A quick testing doesn't show any help. I did a new testing. After the machine boots, I hot remove 8 hyper-threading cpu which means last 8 are just cores. The regression between 2.6.33 and 2.6.34-rc becomes small. My opinion is we needn't revert the patch, but still keep an eye on it when testing other new RC kernel releases. One reason is volanoMark and netperf have no such regression. Is it ok? Yanmin --

Hi, On Mon, Apr 26, 2010 at 9:59 AM, Zhang, Yanmin Yanmin, do we see a lot of remote frees for your hackbench run? IIRC, it's the "deactivate_remote_frees" stat when CONFIG_SLAB_STATS is enabled. Pekka --

Hello, .34-rc5-git7 kernel: [12887.906682] pktgen 2.72: Packet Generator for packet performance testing. kernel: [12938.998730] ------------[ cut here ]------------ kernel: [12938.998741] WARNING: at net/sched/sch_generic.c:256 dev_watchdog+0xc1/0x129() kernel: [12938.998745] Hardware name: F3JC kernel: [12938.998748] NETDEV WATCHDOG: eth0 (r8169): transmit queue 0 timed out kernel: [12938.998751] Modules linked in: pktgen usb_storage ipv6 snd_hwdep snd_hda_codec_si3054 ...

Hello, Pekka. If my hypothesis is the case, I don't think dirtying or not would matter. It's about two cpus sharing a cache line which usually is a bad idea but in this case happens to be a good idea because the two I think it's probably gonna be an over-engineering effort. W/ percpu allocator the rest of the cacheline would likely be occupied by another percpu item for the cpu, so it's not really wasted. It's just used differently. It would be good if we have a way to better ...

Yes, but that does not require a negative value to get right. None of the code relies on negative nr_to_write values to do anything correctly, and all the termination checks are for wbc->nr_to-write <= 0. And the tracing shows it behaves correctly when wbc->nr_to_write = 0 on return. Requiring a negative number is not documented in any of the comments, write_cache_pages() does not return a negative number, etc, so I can't see why you think this is ext4 added a "bump" to wbc->nr_to_write, ...

About 500MB/s sure. ;) Seriously though, the problem that lead to us adding this multiplication was that writeback was not feeding XFS 1024 pages at a time - we were getting much less than this (somewhere in the order of 32-64 pages at a time. With the fixes I posted, in every circumstance I can see we are the correct number of pages (1024 pages or what is left over from the last inode) being passed into ->writepages, and writeback is back to full speed without needing this crutch. Indeed, ...

I guess, the assumption that vfree() will free pages which are allocated by custom code, and not by vmalloc(), is not true. The attached changes seem to fix the issue for me. The custom page array mangling was introduced by David as an optimization with commit 6e03a201bbe8137487f340d26aa662110e324b20 and this should be checked, and if needed be fixed. Cheers, Kay diff --git a/drivers/base/firmware_class.c b/drivers/base/firmware_class.c index 985da11..fe4e872 100644 --- ...

I downloaded the latest kvm.git tree and compilation is ok, including both enabling FTRACE and disabling FTRACE. Yanmin --

On Sun, Apr 18, 2010 at 11:59:49AM -0700, Arjan van de Ven wrote: > There have been various reports of the ondemand governor causing some > serious performance issues, one of the latest ones from Andrew. > There are several fundamental issues with ondemand (being worked on), > but the report from Andrew can be fixed relatively easily. > > The fundamental issue is that ondemand will go to a (too) low CPU > frequency for workloads that alternatingly disk and CPU bound... given the ...

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

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

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

What about the issue Pavel reported and Willy confirmed (regression on older hardware)? Best, Dominik --

On Sun, 25 Apr 2010 17:56:09 +0200 Two bugs, actually...I wouldn't expect things to work with the wrong port, but neither should it crash. The crash is fixed in the second series (where I added checks to ensure that the adapter was active) so I'll probably leave it as-is in between. The port number needs to be fixed, though, thanks for catching that. jon --

Otherwise we hit a BUG_ON in bdi_queue_work(). Signed-off-by: Joern Engel <joern@logfs.org> --- drivers/mtd/mtdcore.c | 17 ++++++++++++++++- 1 files changed, 16 insertions(+), 1 deletions(-) diff --git a/drivers/mtd/mtdcore.c b/drivers/mtd/mtdcore.c index cb4858b..8dd3e46 100644 --- a/drivers/mtd/mtdcore.c +++ b/drivers/mtd/mtdcore.c @@ -299,7 +299,7 @@ static struct device_type mtd_devtype = { int add_mtd_device(struct mtd_info *mtd) { - int i; + int i, err; if ...

Do the bdi_register() here as well. -- Jens Axboe --

It is worse still. Using mtd->backing_dev_info results in kernel BUG at fs/fs-writeback.c:157 which is BUG_ON(!work->seen); in bdi_queue_work(). Logfs is affected and I bet jffs2 is as well. So much for dwmw2 or me actually testing the fix. :( I did a hexdump to see what sb->s_bdi actually contained and the result was this: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ................ 00 00 00 00 00 00 00 00 00 00 ...

Took a quick look, and you want bdi_setup_and_register() for the three bdis listed in mtdbdi.c in mtdcore.c:init_mtd(). Or manual bdi_init() and bdi_register(). I'll take a look post-dinner. Either is workable, but since the flags are already setup, the latter may be cleaner. -- Jens Axboe --

I can kill that hunk, no problem. -- Jens Axboe --

On Sat, Apr 24, 2010 at 10:36:48PM +0200, Corrado Zoccolo wrote: Hi Corrado, I ran these patches and I did not see any improvement. I think the reason being that no cooperative queue merging took place and we did not have any data for throughput with coop flag on. #cat /sys/block/dm-3/queue/iosched/bandwidth 230 753 0 I think we need to implement something similiar to hw_tag detection logic where we allow dispatches from multiple sync-idle queues at a time and try to observe the BW. ...

Btw, I hope you took the second version, that had the two additional fixes from Arnd (and my expansion of his fix to au1550_ac97.c). Looking at the arch code, I doubt there are any big architecture-specific things. But there could easily be some other drivers like au1550_ac97.c that only get enabled on certain architectures and missed the grepping for some reason. That said, because of Arnd's fix, I did end up grepping for 'file_operations' and old-style gcc initializers (ie ...

The scheduler will be helped most by getting rid of the BKL altogether. We are in reaching distance of that now ... Once that state is achived we can just get rid of the BKL and mass-push per-driver mutexes into those remaining drivers - in a possibly scripted way. Something like: foo-driver.c DEFINE_MUTEX(foo_mutex); foo_ioctl() { mutex_lock(&foo_mutex); ... mutex_unlock(&foo_mutex); } foo_open() ...

I wouldn't mind that. But we've not found people to do it so far, so... Anyway, I spent some time automating the ioctl -> bkl_ioctl conversion. The following is the end result. Comments? Regardless of _what_ we do, renaming 'ioctl' to 'bkl_ioctl' is a good thing. It means that we can reliably grep for these usages, whether it is then to later introduce a CONFIG_BKL or if it is to get rid of the bkl_ioctl entirely. NOTE! This has gone through a "allmodconfig" (with staging ...

Yeah, those v4l2_file_operations were annoying. I didn't notice at first, so my first automated script renamed all of them too (because I had just Yes, but that - along with the sound drivers, that also have their own ioctl interface that gets driven under the BKL - are independent patches. Your patch did one of the au1550_ac97 'struct file_operations', but missed another one. I had missed both, because they had that crazy old-style initializer, and didn't trigger a compile on ...

Thanks! I've queued it for the next merge window in git://git.kernel.org/pub/scm/linux/kernel/git/frederic/random-tracing.git bkl/ioctl --

Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/scsi/3w-9xxx.c | 10 +++++++--- drivers/scsi/3w-sas.c | 7 +++++-- drivers/scsi/3w-xxxx.c | 10 +++++++--- drivers/scsi/aacraid/linit.c | 11 ++++++++--- drivers/scsi/dpt_i2o.c | 20 +++++++++++++++++--- drivers/scsi/gdth.c | 20 +++++++++++++++----- drivers/scsi/megaraid.c | 20 +++++++++++++++++--- drivers/scsi/megaraid/megaraid_mm.c ...

This is half the work of getting rid of the BKL in the ioctl file operation, the rest in arch/ and fs/ still needs to be done, maybe two more hours of work (for someone else than me ;-)). Pushdown is straightforward. In many cases, it's rather obvious that the BKL is not needed at all, but let's not mix the removal with the pushdown. Arnd Bergmann (6): dvb: push down BKL into ioctl functions scsi: push down BKL into ioctl functions isdn: push down BKL into ioctl functions staging: ...

v4l drivers may still use a locked ioctl method, but we now always export an unlocked_ioctl and lock ourselves, so that the ->ioctl file operation can get removed. Signed-off-by: Arnd Bergmann <arnd@arndb.de> --- drivers/media/video/v4l2-dev.c | 17 ++++++++++++++--- 1 files changed, 14 insertions(+), 3 deletions(-) diff --git a/drivers/media/video/v4l2-dev.c b/drivers/media/video/v4l2-dev.c index 7090699..3606694 100644 --- a/drivers/media/video/v4l2-dev.c +++ ...

Ok, thanks. --

I finally looked at it and here is what I found. # ./reboot Restarting system. Machine restart... Machine shutdown... Stack: 4f3ffdc8: 48004aec 00000008 4f3ffdd0: 00000000 00000001 4f3e0150 00000001 4f3ffdec 48004b14 481dc68c 48241318 4f3ffdf0: ffffffff 00001099 00003fff 482f49cc 4801f518 481dc6a4 48241318 ffffffff 4f3ffe10: 00001083 00003fff 482f49cc 48020150 481e3048 00000000 000001a2 00000000 4f3ffe30: 00000000 00000000 28121969 48006b38 48240dc0 481d549c 481d53a8 ...

-- Jens Axboe --

Ok, will appear in several hours. I have to repeat full testing --

Cool (I'm looking at -next) Alan --

You still need a context of some kind as I said before to avoid thse globals and single device limits. And all the other issues - no explanation of the locking etc don't seem to have been touched either. I don't really see how I am supposed to review this stuff when the locking and flow control assumptions are completely opaque Alan --

On Mon, 26 Apr 2010 14:44:50 -0700 I was thinking if we made it a special resource type we'd have to change any platform drivers to use it; i.e. it wouldn't be IORESOURCE_MEM or IORESOURCE_IO but IORESOURCE_DRAGONS. That way it wouldn't be part of the normal resource space. But that's definitely overkill. I think Bjorn's fix is sufficient. -- Jesse Barnes, Intel Open Source Technology Center --

On Fri, 23 Apr 2010 16:30:33 -0700 I was going to congratulate Yinghai on writing good changelogs, but then I saw Bjorn actually wrote these ones for him. :) At any rate they looks good: Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> -- Jesse Barnes, Intel Open Source Technology Center --

Works for me. dmesg at https://bugzilla.kernel.org/attachment.cgi?id=26150 -andy --

I'm a little concerned that those patches are a sledgehammer approach. Previously, IORESOURCE_BUSY has basically been used for mutual exclusion between drivers that would otherwise claim the same resource. It hasn't been used to guide resource assignment in the PCI/PNP/etc core. Maybe it's a good idea to also use IORESOURCE_BUSY there, but I'm not sure. Right now it feels like undesirable overloading to me. I think it also leads to at least one problem: Guenter's machine has no VGA but ...

With current linus's tree, there is some difference between mmio > 1M and MMIO < 1M. Actually it does not care about E820_RESERVED for > 1M range, because it doesn't have _BUSY. For < 1M range, a. MMIO is not with E820_RESERVED, the device driver will work. b. MMIO is with E820_RESERVED, the device driver can not reserve it's mmio later. because that MMIO could have parent resource with "reserved" name and _BUSY flag My patch -v3 will break a. but my patch -v4 patch will make it ...

Let's distinguish between what we need for .34 -- we need something minimal and as soon as possible at this stage -- and concentrate on getting the right thing to happen going forward. -hpa --

Moorestown has a similar situation where one of the PCI devices have a BAR below 1MB. Moorestown also has the option not to have VGA. --

the two regressions from the reporters: BIOS put 0xa0000-0xb0000, 0xc0000- 0xd0000 with E820_RESERVED. BIOS ACPI _CRS keep 0xa0000-0xb0000, 0xc0000-0xd0000 as part resources for peer root bus: BUS 0. kernel insert 0xa0000-0xb0000 into resource tree with _BUSY in e820_reserve_resources() at first. last pci bus scan code, will insert 0xa0000-0xb0000, and it is under previous reserved entry. later pci_assign_unassign code, will use bus 0 resources directly, and don't care if the parent's ...

for memo, sending out -v5 --

Update e820 at first, and later put them resource tree. Reserved that early, will not be allocated to unassigned PCI BAR -v5: same as -v3 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 - ...

The problem is that the fix I did has been rejected by the upstream VM guys, and the stable rules are that fixes have to be in mainline before they can be put in a stable release. So, until we get a fix Yet there's only been one report of the problem. While that doesn't make it any less serious, I don't think the problem you're reporting is as widespread as you are making it out to be. We'll get the fix done and upstream, and then it will go back to the stable kernel. You could always ...

Again, no success. Just to make sure that I didn't screw anything. I have used just the following patch on top of the clean rc5 (your patch has failed with some rejects but I guess that the following should do the same): commit 65eafe4a504e3bb2c13b4feb8590dc52e7439baa Author: Rafael J. Wysocki <rjw@sisk.pl> Date: Sun Apr 25 04:35:42 2010 +0200 diff --git a/drivers/acpi/acpica/evgpeblk.c b/drivers/acpi/acpica/evgpeblk.c index fef7219..b6e1e0c 100644 --- ...

Thanks for testing. Did you try the second thing, ie. try to comment out the acpi_enable_gpe() in drivers/acpi/wakeup.c:acpi_wakeup_device_init() and retest (if you haven't done that already)? Rafael --

Hi I've quick reviewed your patch. but unfortunately I can't write my We certainly need no knob. because typical desktop users use various application, various workload. then, the knob doesn't help them. Probably, I've missed previous discussion. I'm going to find your previous mail. --

Briefly - We had discussed non desktop scenarios where like a day load that builds up the working set to 50% and a nightly backup job which then is unable to use that protected 50% when sequentially reading a lot of disks and due to that doesn't finish before morning. The knob should help those people that know their system would suffer from this or similar cases to e.g. set the protected ratio smaller or even to zero if wanted. As mentioned before, being able to gain back those ...

I already replied. http://lkml.org/lkml/2010/4/21/420 Eric --

Eric Dumazet traced these down to a commit from Eric Biederman. If I don't hear from Eric Biederman in a few days, I will attempt a patch, but it would be more likely to be correct coming from someone with a better understanding of the code. ;-) Thanx, Paul --