Re: [PATCH] ARM: kdump: Avoid overflow when converting pfn to physaddr

[Liu hua]

On 2014/3/18 18:48, Russell King - ARM Linux wrote:
> On Tue, Mar 18, 2014 at 06:20:42PM +0800, Liu Hua wrote:
>> When we configure CONFIG_LPAE=y, pfn << PAGE_SHIFT will
>> overflow if pfn >= 0x10 in copy_oldmem_page.
>>
>> So use __pfn_to_phys for converting.
> 
> Yes.  The sad thing is that if you grep the kernel for similar things,
> it's littered with this problem.  I'm not sure whether anyone
> particularly "owns" the crash_dump.c file - Mika Westerberg and
> Olaf Hering were the last two to touch it... I guess put this in my
> patch system please.
> 
> Thanks.
> 

Yes, I found this problem in serval places after a quick review. I will
do a check on this.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[GIT PULL] ARM: SoC fixes for 3.14

[Olof Johansson]

Hi Linus,

The following changes since commit 10554647b488f58f2c36c78368e9bab4b93da721:

  Merge tag 'omap-for-v3.14/fixes-dt-rc4' of 
git://git.kernel.org/pub/scm/linux/kernel/git/tmlind/linux-omap into fixes 
(2014-03-08 22:56:31 -0800)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/arm/arm-soc.git 
tags/fixes-for-linus

for you to fetch changes up to f656d46bbb2d3ecdb71c998ccf657dccea8d19a9:

  ARM: at91: fix network interface ordering for sama5d36 (2014-03-11 12:49:10 
-0700)


ARM: SoC fixes for 3.14

Only two patches this time, one to fix ethernet probe order on at91 (better
fix with proper device aliasing will be done for 3.15, this is stop-gap), and
one update to MAINTAINERS due to Freescale moving their repo to kernel.org.


Boris BREZILLON (1):
  ARM: at91: fix network interface ordering for sama5d36

Shawn Guo (1):
  MAINTAINERS: update IMX kernel git tree

 MAINTAINERS | 4 ++--
 arch/arm/boot/dts/sama5d36.dtsi | 2 +-
 2 files changed, 3 insertions(+), 3 deletions(-)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

15995MB available under Linux but 16329MB available under Win 7

[Branimir Maksimovic]

This really puzzles me.

bmaxa@maxa:~$ lspci -v -s 01:00.0
01:00.0 VGA compatible controller: NVIDIA Corporation GF114 [GeForce GTX 
560 Ti] (rev a1) (prog-if 00 [VGA controller])

Subsystem: CardExpert Technology Device 0801
Flags: bus master, fast devsel, latency 0, IRQ 52
Memory at f400 (32-bit, non-prefetchable) [size=32M]
Memory at e800 (64-bit, prefetchable) [size=128M]
Memory at f000 (64-bit, prefetchable) [size=64M]
I/O ports at e000 [size=128]
[virtual] Expansion ROM at f600 [disabled] [size=512K]
Capabilities: 
Kernel driver in use: nvidia

bmaxa@maxa:~$ dmesg | grep Mem
[0.00] Memory: 16358808K/16721316K available (7232K kernel code, 
1106K rwdata, 3456K rodata, 1324K init, 1432K bss, 362508K reserved)


Everything is clear most of reserved RAM goes to VGA mapping?

But, Windows resource monitor and task manager says just around 50MB
hardware reserved?

So I have tried different kernel boot parameters to no avail.
So question is: Does Windows magically maps VGA to upper addresses 
(beyond 16GB)

or simply Windows does not reports all reserved RAM?

When I disable memory remap in BIOS Windows reports 500MB more reserved,
but Linux adds this 500MB to 300MB reserved giving around 800MB.

CPU is i5 3570k, motherboard z77, 16GB of DD3 RAM, AMI BIOS.

Branimir.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V4 1/3] cpufreq: Make sure frequency transitions are serialized

[Viresh Kumar]

On 21 March 2014 23:37, Catalin Marinas  wrote:
> smp_mb() is all about relative ordering. So if you want memory accesses
> in post_transition() to be visible to other observers before
> transition_ongoing = false, you also need to make sure that the readers
> of transition_ongoing have a barrier before subsequent memory accesses.

I don't think this is a requirement in our case. We are just trying to serialize
frequency transitions here and just want to make sure that second one
start after first one is over. And so this query.

> OK, I start to get it. Is there a risk of missing a wake_up event? E.g.
> one thread waking up earlier, noticing that transition is in progress
> and waiting indefinitely?

I don't think so. The only requirement is that second thread wakes up
after this variable is set to false.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tasks stuck in futex code (in 3.14-rc6)

[Davidlohr Bueso]

On Sat, 2014-03-22 at 07:57 +0530, Srikar Dronamraju wrote:
> > > So reverting and applying v3 3/4 and 4/4 patches works for me.
> > 
> > Ok, I verified that the above endds up resulting in the same tree as
> > the minimal patch I sent out, modulo (a) some comments and (b) an
> > #ifdef CONFIG_SMP in futex_get_mm() that doesn't really matter.
> > 
> > So I committed the minimal patch with your tested-by.
> > 
> 
> Just to be sure, I have verified with latest mainline with HEAD having
> commit 08edb33c4 (Merge branch 'drm-fixes' of
> git://people.freedesktop.org/~airlied/linux) which also has the commit
> 11d4616bd0 futex:( revert back to the explicit waiter counting code).

Thanks for double checking.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v3 2/6] iio: pulse: add TI ECAP driver

[Matt Ranostay]

On Wed, Feb 5, 2014 at 11:01 AM, Matt Porter  wrote:
> Adds support for capturing PWM signals using the TI ECAP peripheral.
> This driver supports triggered buffer capture of pulses on multiple
> ECAP instances. In addition, the driver supports configurable polarity
> of the signal to be captured.
>
> Signed-off-by: Matt Porter 

Tested-by: Matt Ranostay 

> ---
>  drivers/iio/pulse/Kconfig  |  20 ++
>  drivers/iio/pulse/Makefile |   6 +
>  drivers/iio/pulse/tiecap.c | 491 
> +
>  3 files changed, 517 insertions(+)
>  create mode 100644 drivers/iio/pulse/Kconfig
>  create mode 100644 drivers/iio/pulse/Makefile
>  create mode 100644 drivers/iio/pulse/tiecap.c
>
> diff --git a/drivers/iio/pulse/Kconfig b/drivers/iio/pulse/Kconfig
> new file mode 100644
> index 000..9864d4b
> --- /dev/null
> +++ b/drivers/iio/pulse/Kconfig
> @@ -0,0 +1,20 @@
> +#
> +# Pulse Capture Devices
> +#
> +# When adding new entries keep the list in alphabetical order
> +
> +menu "Pulse Capture Devices"
> +
> +config IIO_TIECAP
> +   tristate "TI ECAP Pulse Capture"
> +   depends on SOC_AM33XX
> +   select IIO_BUFFER
> +   select IIO_TRIGGERED_BUFFER
> +   help
> +If you say yes here you get support for the TI ECAP peripheral
> +in pulse capture mode.
> +
> +This driver can also be built as a module.  If so, the module
> +will be called tiecap
> +
> +endmenu
> diff --git a/drivers/iio/pulse/Makefile b/drivers/iio/pulse/Makefile
> new file mode 100644
> index 000..94d4b00
> --- /dev/null
> +++ b/drivers/iio/pulse/Makefile
> @@ -0,0 +1,6 @@
> +#
> +# Makefile for IIO PWM Capture Devices
> +#
> +
> +# When adding new entries keep the list in alphabetical order
> +obj-$(CONFIG_IIO_TIECAP)   += tiecap.o
> diff --git a/drivers/iio/pulse/tiecap.c b/drivers/iio/pulse/tiecap.c
> new file mode 100644
> index 000..fd96745
> --- /dev/null
> +++ b/drivers/iio/pulse/tiecap.c
> @@ -0,0 +1,491 @@
> +/*
> + * ECAP IIO pulse capture driver
> + *
> + * Copyright (C) 2014 Linaro Limited
> + * Author: Matt Porter 
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License as published by
> + * the Free Software Foundation; either version 2 of the License, or
> + * (at your option) any later version.
> + */
> +
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +#include 
> +
> +#include "../../pwm/pwm-tipwmss.h"
> +
> +/* ECAP regs and bits */
> +#define CAP1   0x08
> +#define CAP2   0x0c
> +#define ECCTL1 0x28
> +#define ECCTL1_RUN_FREEBIT(15)
> +#define ECCTL1_CAPLDEN BIT(8)
> +#define ECCTL1_CAP2POL BIT(2)
> +#define ECCTL1_CTRRST1 BIT(1)
> +#define ECCTL1_CAP1POL BIT(0)
> +#define ECCTL2 0x2a
> +#define ECCTL2_SYNCO_SEL_DIS   BIT(7)
> +#define ECCTL2_TSCTR_FREERUN   BIT(4)
> +#define ECCTL2_REARM   BIT(3)
> +#define ECCTL2_STOP_WRAP_2 BIT(1)
> +#define ECEINT 0x2c
> +#define ECFLG  0x2e
> +#define ECCLR  0x30
> +#define ECINT_CTRCMP   BIT(7)
> +#define ECINT_CTRPRD   BIT(6)
> +#define ECINT_CTROVF   BIT(5)
> +#define ECINT_CEVT4BIT(4)
> +#define ECINT_CEVT3BIT(3)
> +#define ECINT_CEVT2BIT(2)
> +#define ECINT_CEVT1BIT(1)
> +#define ECINT_ALL  (ECINT_CTRCMP | \
> +   ECINT_CTRPRD |  \
> +   ECINT_CTROVF |  \
> +   ECINT_CEVT4 |   \
> +   ECINT_CEVT3 |   \
> +   ECINT_CEVT2 |   \
> +   ECINT_CEVT1)
> +
> +/* ECAP driver flags */
> +#define ECAP_POLARITY_HIGH BIT(1)
> +#define ECAP_ENABLED   BIT(0)
> +
> +struct ecap_context {
> +   u32 cap1;
> +   u32 cap2;
> +   u16 ecctl1;
> +   u16 ecctl2;
> +   u16 eceint;
> +};
> +
> +struct ecap_state {
> +   unsigned long   flags;
> +   unsigned intclk_rate;
> +   void __iomem*regs;
> +   u32 *buf;
> +   struct ecap_context ctx;
> +};
> +
> +#define dev_to_ecap_state(d)   iio_priv(dev_to_iio_dev(d))
> +
> +static const struct iio_chan_spec ecap_channels[] = {
> +   {
> +   .type   = IIO_PULSE,
> +   .info_mask_separate =
> +   BIT(IIO_CHAN_INFO_RAW) | BIT(IIO_CHAN_INFO_SCALE),
> +   .scan_index = 0,
> +   .scan_type = {
> +   .sign   = 'u',
> +   .realbits   = 32,
> +   .storagebits= 32,
> +  

Re: [PATCH v7 2/2] Tracepoint: register/unregister struct tracepoint

[Mathieu Desnoyers]

- Original Message -
> From: "Steven Rostedt" 
> To: "Mathieu Desnoyers" 
> Cc: linux-kernel@vger.kernel.org, "Ingo Molnar" , "Frederic 
> Weisbecker" ,
> "Andrew Morton" , "Frank Ch. Eigler" 
> , "Johannes Berg"
> 
> Sent: Friday, March 21, 2014 3:40:00 PM
> Subject: Re: [PATCH v7 2/2] Tracepoint: register/unregister struct tracepoint
> 
> On Fri, 21 Mar 2014 01:19:02 -0400
> 
> > diff --git a/include/linux/ftrace_event.h b/include/linux/ftrace_event.h
> > index 4e4cc28..1592c1c 100644
> > --- a/include/linux/ftrace_event.h
> > +++ b/include/linux/ftrace_event.h
> > @@ -230,6 +230,7 @@ struct ftrace_event_call {
> > struct list_headlist;
> > struct ftrace_event_class *class;
> > char*name;
> > +   struct tracepoint   *tp;
> 
> 
> This change right here just added 17K to the kernel (on a minimum config):
> 
>text  data bss dec hex filename
> 8425515   2018936 1302528 11746979 b33ea3 vmlinux.orig
> 8424914   2036472 1302528 11763914 b380ca vmlinux
> 
> The two are redundant. Might as well remove .name and then
> use .tp->name for referencing the name of the event.

What should we do about:

kernel/trace/trace_export.c:

struct ftrace_event_call __used event_##call = {\
.name   = #call,\
.event.type = etype,\
.class  = _class_ftrace_##call,   \
.print_fmt  = print,\
.flags  = TRACE_EVENT_FL_IGNORE_ENABLE | 
TRACE_EVENT_FL_USE_CALL_FILTER, \
}; 

when replacing the .name for a .tp->name, it is unclear what the
tracepoint structure should be (is there even one ?).

Thanks,

Mathieu


> 
> -- Steve
> 
> 
> > struct trace_event  event;
> > const char  *print_fmt;
> > struct event_filter *filter;
> 

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3.13 072/149] ACPI / resources: ignore invalid ACPI device resources

[Stefan Lippers-Hollmann]

Hi

On Friday 21 March 2014, Greg Kroah-Hartman wrote:
> 3.13-stable review patch.  If anyone has any objections, please let me know.
> 
> --
> 
> From: Zhang Rui 
> 
> commit b355cee88e3b1a193f0e9a81db810f6f83ad728b upstream.
> 
> ACPI table may export resource entry with 0 length.
> But the current code interprets this kind of resource in a wrong way.
> It will create a resource structure with
> res->end = acpi_resource->start + acpi_resource->len - 1;
> 
> This patch fixes a problem on my machine that a platform device fails
> to be created because one of its ACPI IO resource entry (start = 0,
> end = 0, length = 0) is translated into a generic resource with
> start = 0, end = 0x.
> 
> Signed-off-by: Zhang Rui 
> Signed-off-by: Rafael J. Wysocki 
> Signed-off-by: Greg Kroah-Hartman 
[...]

This patch should probably be dropped from -stable (3.13 and 3.10) for 
the time being, it causes this warning:

pnp 00:01: unknown resource type 4 in _CRS
pnp 00:01: can't evaluate _CRS: 1

on all systems I've tested it on so far (~12 systems of vastly varying 
components and age, covering amd64 and i386).

This also seems to affect others as well:
http://www.spinics.net/lists/linux-acpi/msg49431.html
http://www.spinics.net/lists/linux-acpi/msg49438.html

Regards
Stefan Lippers-Hollmann
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Tasks stuck in futex code (in 3.14-rc6)

[Srikar Dronamraju]

> > So reverting and applying v3 3/4 and 4/4 patches works for me.
> 
> Ok, I verified that the above endds up resulting in the same tree as
> the minimal patch I sent out, modulo (a) some comments and (b) an
> #ifdef CONFIG_SMP in futex_get_mm() that doesn't really matter.
> 
> So I committed the minimal patch with your tested-by.
> 

Just to be sure, I have verified with latest mainline with HEAD having
commit 08edb33c4 (Merge branch 'drm-fixes' of
git://people.freedesktop.org/~airlied/linux) which also has the commit
11d4616bd0 futex:( revert back to the explicit waiter counting code).

-- 
Thanks and Regards
Srikar Dronamraju

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: ACPI and PM material for v3.15-rc1 (current queue)

[Hanjun Guo]

On 2014年03月22日 00:40, Rafael J. Wysocki wrote:

On Friday, March 21, 2014 08:39:39 AM Hanjun Guo wrote:

Hi Rafael,

Hi,


On 2014年03月21日 08:23, Rafael J. Wysocki wrote:

Hi All,

My queue for the first pull request during the upcoming 3.15 merge window
contains the material below.  Following the rule that everything I send
pull requests for should spend at least one day in linux-next, I'm not
going to add any more new commits to it at this point.

Most likely, there will be more ACPI+PM pull request during the 3.15 cycle,
so if I missed something, it still may be possible to get that into that
kernel, but there has to be a good reason for it.

Kind regards,
Rafael


---

Hanjun Guo (2):
ACPI / tables: Replace printk with pr_*
ACPI: Remove duplicate definitions of PREFIX

It seems that you missed some of my patches:
ACPI: Move BAD_MADT_ENTRY() to linux/acpi.h
ACPI / idle: Make idle_boot_override depend on x86 and ia64
ACPI / trivial: Fix the return value type of acpi_processor_eval_pdc()
ACPI / processor: Replace hard-coded "ACPI0007" with
ACPI_PROCESSOR_DEVICE_HID

I think those 4 patches can be merged in 3.15 and you already accepted them.

Yes, I did not include the acpi-processor branch, sorry about that and thanks
for spotting it!

That branch was in linux-next before, though, so I'll push it for 3.15-rc1.


Thanks a lot !
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[RFC][PATCH] perf: Add 'merge-recursive' callchain option

[Sukadev Bhattiprolu]

>From 9ad9432dab2bf4d1c8e6ff9201e88d5ae9f3994a Mon Sep 17 00:00:00 2001
From: Sukadev Bhattiprolu 
Date: Wed, 19 Mar 2014 20:24:22 -0500
Subject: [PATCH 1/1] perf: Add 'merge-recursive' callchain option

Powerpc saves the link register (LR) with each sample to help resolve
callchains for programs involving tail calls. Sometimes the value in the
LR is same as the NIP register. Other times it is not. This results in
callchains samples like these:

3547953334790 0x1ec0 [0x78]: PERF_RECORD_SAMPLE(IP, 2): 4667/4667: 0x80a7be3c58 
period: 1773985 addr: 0
... chain: nr:9
.  0: fe00
.  1: 0080a7be3c58  __random
.  2: 0080a7be3c40  __random
.  3: 0080a7be4270  rand
.  4: 1784  do_my_sprintf
.  5: 19d8  main
.  6: 0080a7bc482c
.  7: 0080a7bc4a34
.  8: 
 ... thread: sprintft:4667
 .. dso: /usr/lib64/libc-2.18.so

67470723107802 0x2f10 [0x78]: PERF_RECORD_SAMPLE(IP, 0x2): 5706/5706: 
0x80a7be3c20 period: 872629 addr: 0
... chain: nr:9
.  0: fe00
.  1: 0080a7be3c20  __random
.  2: 0080a7be4270  rand
.  3: 0080a7be4270  rand
.  4: 1784
.  5: 19d8
.  6: 0080a7bc482c
.  7: 0080a7bc4a34
.  8: 
 ... thread: sprintft:5706
 .. dso: /usr/lib64/libc-2.18.so

67470738362072 0x4cf8 [0x78]: PERF_RECORD_SAMPLE(IP, 0x2): 5706/5706: 
0x80a7be3c14 period: 869774 addr: 0
... chain: nr:9
.  0: fe00
.  1: 0080a7be3c14  __random
.  2: 0080a7be4270  rand
.  3: 0080a7be4270  rand
.  4: 1784  do_my_sprintf
.  5: 19d8  main
.  6: 0080a7bc482c
.  7: 0080a7bc4a34
.  8: 
 ... thread: sprintft:5706
 .. dso: /usr/lib64/libc-2.18.so

In the perf tool, these samples end up on different branches of the RB-Tree
resulting in duplicated arcs in the final call-graph.

15.02%  sprintft  libc-2.18.so   [.] __random
|
--- __random
   |
   |--58.45%-- rand
   |  rand
   |  do_my_sprintf
   |  main
   |  generic_start_main.isra.0
   |  __libc_start_main
   |  0x0
   |
--41.55%-- __random
  rand
  do_my_sprintf
  main
  generic_start_main.isra.0
  __libc_start_main
  0x0

This is an RFC for adding a 'merge-recursive' call-graph option that would
discard the duplicate entries resulting in a more compact call-graph. The
duplicates can be either identical instruction pointer values or IP values
within the same function.

perf report --call-graph=fractal,0.5,callee,function,merge-recursive

15.02%  sprintft  libc-2.18.so   [.] __random
|
---__random
   rand
   do_my_sprintf
   main
   generic_start_main.isra.0
   __libc_start_main
(nil)

This option could also be used to collapse call-graphs of recursive functions.

AFAICT, the existing CCKEY_FUNCTION does not address this case because
the callchain lengths can vary across samples.

Signed-off-by: Sukadev Bhattiprolu 
---
 tools/perf/builtin-report.c |   14 --
 tools/perf/util/callchain.h |1 +
 tools/perf/util/machine.c   |   39 +++
 3 files changed, 52 insertions(+), 2 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index d882b6f..0b68749 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -647,6 +647,16 @@ parse_callchain_opt(const struct option *opt, const char 
*arg, int unset)
callchain_param.key = CCKEY_ADDRESS;
else
return -1;
+
+   tok2 = strtok(NULL, ",");
+   if (!tok2)
+   goto setup;
+
+   if (!strncmp(tok2, "merge-recursive", strlen("merge-recursive")))
+   callchain_param.merge_recursive = 1;
+   else
+   return -1;
+
 setup:
if (callchain_register_param(_param) < 0) {
pr_err("Can't register callchain params\n");
@@ -762,8 +772,8 @@ int cmd_report(int argc, const char **argv, const char 
*prefix __maybe_unused)
   "regex filter to identify parent, see: '--sort parent'"),
OPT_BOOLEAN('x', "exclude-other", _conf.exclude_other,
"Only display entries with parent-match"),
-   OPT_CALLBACK_DEFAULT('g', "call-graph", , 
"output_type,min_percent[,print_limit],call_order",
-"Display callchains using output_type (graph, flat, 
fractal, or none) , min percent threshold, optional 

Fund Donation...

[Adrian Gillian Bayford]

You have received a Fund Donation of 1.5 million GBP From Mr Adrian Gillian 
Bayford. See link for prove: http://www.bbc.co.uk/news/uk-england-19254228 
Please respond to this email with your name, address and phone number.

Thanks
Adrian & Gillian Bayford
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mmc: sdhci: don't read cd-gpio while holding spinlock

[Andrew Bresticker]

On Thu, Mar 20, 2014 at 11:45 PM, Adrian Hunter  wrote:
> On 20.03.2014 20:47, Andrew Bresticker wrote:
>> mmc_request() reads the cd-gpio via mmc_gpio_get_cd(), which can sleep,
>> while holding host->lock.  This may result in the following BUG:
>>
>>   BUG: spinlock wrong CPU on CPU#2, kworker/u8:16/4296
>>   lock: 0xea6b9c80, .magic: dead4ead, .owner: kworker/u8:16/4296, 
>> .owner_cpu: 0
>>   CPU: 2 PID: 4296 Comm: kworker/u8:16 Tainted: G C   3.10.18 #137
>>   Workqueue: kmmcd mmc_rescan
>>   [<8020cf8c>] (unwind_backtrace+0x0/0x118) from [<8020a0c8>] 
>> (show_stack+0x20/0x24)
>>   [<8020a0c8>] (show_stack+0x20/0x24) from [<8075e5b8>] 
>> (dump_stack+0x20/0x28)
>>   [<8075e5b8>] (dump_stack+0x20/0x28) from [<804184a8>] (spin_dump+0x80/0x94)
>>   [<804184a8>] (spin_dump+0x80/0x94) from [<804184e8>] (spin_bug+0x2c/0x30)
>>   [<804184e8>] (spin_bug+0x2c/0x30) from [<80418790>] 
>> (do_raw_spin_unlock+0x94/0xd4)
>>   [<80418790>] (do_raw_spin_unlock+0x94/0xd4) from [<80761a44>] 
>> (_raw_spin_unlock_irqrestore+0x1c/0x24)
>>   [<80761a44>] (_raw_spin_unlock_irqrestore+0x1c/0x24) from [<805ff66c>] 
>> (sdhci_request+0x1c8/0x1d0)
>>   [<805ff66c>] (sdhci_request+0x1c8/0x1d0) from [<805ebb5c>] 
>> (mmc_start_request+0xec/0xf4)
>>   [<805ebb5c>] (mmc_start_request+0xec/0xf4) from [<805ebcbc>] 
>> (mmc_wait_for_req+0x80/0xf4)
>>   ...
>>
>> Read the cd-gpio before acquiring the spinlock instead.
>
> The same problem appears to be in sdhci_card_event() which calls
> sdhci_do_get_cd() under spinlock which then calls mmc_gpio_get_cd()
>
> Will you fix that too?

Yes, will do.

Thanks,
Andrew

>
>
>>
>> Signed-off-by: Andrew Bresticker 
>> ---
>>  drivers/mmc/host/sdhci.c | 2 +-
>>  1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/drivers/mmc/host/sdhci.c b/drivers/mmc/host/sdhci.c
>> index 04a5e25..f2ef978 100644
>> --- a/drivers/mmc/host/sdhci.c
>> +++ b/drivers/mmc/host/sdhci.c
>> @@ -1340,6 +1340,7 @@ static void sdhci_request(struct mmc_host *mmc, struct 
>> mmc_request *mrq)
>>   u32 tuning_opcode;
>>
>>   host = mmc_priv(mmc);
>> + present = mmc_gpio_get_cd(host->mmc);
>>
>>   sdhci_runtime_pm_get(host);
>>
>> @@ -1371,7 +1372,6 @@ static void sdhci_request(struct mmc_host *mmc, struct 
>> mmc_request *mrq)
>>* zero: cd-gpio is used, and card is removed
>>* one: cd-gpio is used, and card is present
>>*/
>> - present = mmc_gpio_get_cd(host->mmc);
>>   if (present < 0) {
>>   /* If polling, assume that the card is always present. */
>>   if (host->quirks & SDHCI_QUIRK_BROKEN_CARD_DETECTION)
>>
>
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

You have received 1.5m pounds as donation see link www.bbc.co.uk/news/uk-england-19254228 send name address and phone number for info

[Adrian Gillian Bayford]

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 08/26] kprobes/x86: Call exception handlers directly from do_int3/do_debug

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:39 +0900
Masami Hiramatsu  wrote:

> To avoid a kernel crash by probing on lockdep code, call
> kprobe_int3_handler and kprobe_debug_handler directly
> from do_int3 and do_debug. Since there is a locking code
> in notify_die, lockdep code can be invoked. And because
> the lockdep involves printk() related things, theoretically,
> we need to prohibit probing on much more code...
> 
> Anyway, most of the int3 handlers in the kernel are already
> called from do_int3 directly, e.g. ftrace_int3_handler,
> poke_int3_handler, kgdb_ll_trap. Actually only
> kprobe_exceptions_notify is on the notifier_call_chain.
> 
> Signed-off-by: Masami Hiramatsu 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: Ananth N Mavinakayanahalli 
> Cc: Andi Kleen 
> Cc: Steven Rostedt 
> Cc: Sasha Levin 
> Cc: Andrew Morton 
> Cc: Seiji Aguchi 
> Cc: Frederic Weisbecker 
> ---
>  arch/x86/include/asm/kprobes.h |2 ++
>  arch/x86/kernel/kprobes/core.c |   24 +++-
>  arch/x86/kernel/traps.c|   10 ++
>  3 files changed, 15 insertions(+), 21 deletions(-)
> 
> diff --git a/arch/x86/include/asm/kprobes.h b/arch/x86/include/asm/kprobes.h
> index 9454c16..53cdfb2 100644
> --- a/arch/x86/include/asm/kprobes.h
> +++ b/arch/x86/include/asm/kprobes.h
> @@ -116,4 +116,6 @@ struct kprobe_ctlblk {
>  extern int kprobe_fault_handler(struct pt_regs *regs, int trapnr);
>  extern int kprobe_exceptions_notify(struct notifier_block *self,
>   unsigned long val, void *data);
> +extern int kprobe_int3_handler(struct pt_regs *regs);
> +extern int kprobe_debug_handler(struct pt_regs *regs);
>  #endif /* _ASM_X86_KPROBES_H */
> diff --git a/arch/x86/kernel/kprobes/core.c b/arch/x86/kernel/kprobes/core.c
> index 4708d6e..566958e 100644
> --- a/arch/x86/kernel/kprobes/core.c
> +++ b/arch/x86/kernel/kprobes/core.c
> @@ -559,7 +559,7 @@ reenter_kprobe(struct kprobe *p, struct pt_regs *regs, 
> struct kprobe_ctlblk *kcb
>   * Interrupts are disabled on entry as trap3 is an interrupt gate and they
>   * remain disabled throughout this function.
>   */
> -static int __kprobes kprobe_handler(struct pt_regs *regs)
> +int __kprobes kprobe_int3_handler(struct pt_regs *regs)
>  {
>   kprobe_opcode_t *addr;
>   struct kprobe *p;
> @@ -857,7 +857,7 @@ no_change:
>   * Interrupts are disabled on entry as trap1 is an interrupt gate and they
>   * remain disabled throughout this function.
>   */
> -static int __kprobes post_kprobe_handler(struct pt_regs *regs)
> +int __kprobes kprobe_debug_handler(struct pt_regs *regs)
>  {
>   struct kprobe *cur = kprobe_running();
>   struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
> @@ -960,22 +960,7 @@ kprobe_exceptions_notify(struct notifier_block *self, 
> unsigned long val, void *d
>   if (args->regs && user_mode_vm(args->regs))
>   return ret;
>  
> - switch (val) {
> - case DIE_INT3:
> - if (kprobe_handler(args->regs))
> - ret = NOTIFY_STOP;
> - break;
> - case DIE_DEBUG:
> - if (post_kprobe_handler(args->regs)) {
> - /*
> -  * Reset the BS bit in dr6 (pointed by args->err) to
> -  * denote completion of processing
> -  */
> - (*(unsigned long *)ERR_PTR(args->err)) &= ~DR_STEP;
> - ret = NOTIFY_STOP;
> - }

The DIE_DEBUG case is removed but not added anyplace else. The change
log doesn't say why this was removed.

-- Steve

> - break;
> - case DIE_GPF:
> + if (val == DIE_GPF) {
>   /*
>* To be potentially processing a kprobe fault and to
>* trust the result from kprobe_running(), we have
> @@ -984,9 +969,6 @@ kprobe_exceptions_notify(struct notifier_block *self, 
> unsigned long val, void *d
>   if (!preemptible() && kprobe_running() &&
>   kprobe_fault_handler(args->regs, args->trapnr))
>   ret = NOTIFY_STOP;
> - break;
> - default:
> - break;
>   }
>   return ret;
>  }
> diff --git a/arch/x86/kernel/traps.c b/arch/x86/kernel/traps.c
> index 57409f6..e5d4a70 100644
> --- a/arch/x86/kernel/traps.c
> +++ b/arch/x86/kernel/traps.c
> @@ -334,6 +334,11 @@ dotraplinkage void __kprobes notrace do_int3(struct 
> pt_regs *regs, long error_co
>   goto exit;
>  #endif /* CONFIG_KGDB_LOW_LEVEL_TRAP */
>  
> +#ifdef CONFIG_KPROBES
> + if (kprobe_int3_handler(regs))
> + return;
> +#endif
> +
>   if (notify_die(DIE_INT3, "int3", regs, error_code, X86_TRAP_BP,
>   SIGTRAP) == NOTIFY_STOP)
>   goto exit;
> @@ -440,6 +445,11 @@ dotraplinkage void __kprobes do_debug(struct pt_regs 
> *regs, long error_code)
>   /* Store the virtualized DR6 value */
>   tsk->thread.debugreg6 = dr6;
>  
> 

Re: [PATCH -tip v8 07/26] [BUGFIX] x86: Prohibit probing on thunk functions and restore

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:32 +0900
Masami Hiramatsu  wrote:

>   thunk_ra trace_hardirqs_on_thunk,trace_hardirqs_on_caller
> diff --git a/arch/x86/lib/thunk_64.S b/arch/x86/lib/thunk_64.S
> index a63efd6..92d9fea 100644
> --- a/arch/x86/lib/thunk_64.S
> +++ b/arch/x86/lib/thunk_64.S
> @@ -8,6 +8,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>   /* rdi: arg1 ... normal C conventions. rax is saved/restored. */
>   .macro THUNK name, func, put_ret_addr_in_rdi=0
> @@ -25,6 +26,7 @@
>   call \func
>   jmp  restore
>   CFI_ENDPROC
> + _ASM_NOKPROBE(\name)
>   .endm
>  
>  #ifdef CONFIG_TRACE_IRQFLAGS
> @@ -43,3 +45,4 @@ restore:
>   RESTORE_ARGS
>   ret
>   CFI_ENDPROC
> + _ASM_NOKPROBE(restore)
> 

Does kallsyms return something for this? I'm curious to what it does.
It might find something that we didn't expect. Do you have debug code
to list out all the black listed items found at boot up?

-- Steve


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] clk: qcom: Consolidate common probe code

[Stephen Boyd]

Most of the probe code is the same between all the different
clock controllers. Consolidate the code into a common.c file.
This makes changes to the common probe parts easier and reduces
chances for bugs.

Signed-off-by: Stephen Boyd 
---
 drivers/clk/qcom/Makefile   |  1 +
 drivers/clk/qcom/common.c   | 99 +
 drivers/clk/qcom/common.h   | 34 ++
 drivers/clk/qcom/gcc-msm8660.c  | 87 +---
 drivers/clk/qcom/gcc-msm8960.c  | 77 +---
 drivers/clk/qcom/gcc-msm8974.c  | 77 +---
 drivers/clk/qcom/mmcc-msm8960.c | 78 +---
 drivers/clk/qcom/mmcc-msm8974.c | 80 +++--
 8 files changed, 196 insertions(+), 337 deletions(-)
 create mode 100644 drivers/clk/qcom/common.c
 create mode 100644 drivers/clk/qcom/common.h

diff --git a/drivers/clk/qcom/Makefile b/drivers/clk/qcom/Makefile
index f60db2ef1aee..689e05bf4f95 100644
--- a/drivers/clk/qcom/Makefile
+++ b/drivers/clk/qcom/Makefile
@@ -1,5 +1,6 @@
 obj-$(CONFIG_COMMON_CLK_QCOM) += clk-qcom.o
 
+clk-qcom-y += common.o
 clk-qcom-y += clk-regmap.o
 clk-qcom-y += clk-pll.o
 clk-qcom-y += clk-rcg.o
diff --git a/drivers/clk/qcom/common.c b/drivers/clk/qcom/common.c
new file mode 100644
index ..86b45fba5f90
--- /dev/null
+++ b/drivers/clk/qcom/common.c
@@ -0,0 +1,99 @@
+/*
+ * Copyright (c) 2013-2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "common.h"
+#include "clk-regmap.h"
+#include "reset.h"
+
+struct qcom_cc {
+   struct qcom_reset_controller reset;
+   struct clk_onecell_data data;
+   struct clk *clks[];
+};
+
+int qcom_cc_probe(struct platform_device *pdev, const struct qcom_cc_desc 
*desc)
+{
+   void __iomem *base;
+   struct resource *res;
+   int i, ret;
+   struct device *dev = >dev;
+   struct clk *clk;
+   struct clk_onecell_data *data;
+   struct clk **clks;
+   struct regmap *regmap;
+   struct qcom_reset_controller *reset;
+   struct qcom_cc *cc;
+   size_t num_clks = desc->num_clks;
+   struct clk_regmap **rclks = desc->clks;
+
+   res = platform_get_resource(pdev, IORESOURCE_MEM, 0);
+   base = devm_ioremap_resource(dev, res);
+   if (IS_ERR(base))
+   return PTR_ERR(base);
+
+   regmap = devm_regmap_init_mmio(dev, base, desc->config);
+   if (IS_ERR(regmap))
+   return PTR_ERR(regmap);
+
+   cc = devm_kzalloc(dev, sizeof(*cc) + sizeof(*clks) * num_clks,
+ GFP_KERNEL);
+   if (!cc)
+   return -ENOMEM;
+
+   clks = cc->clks;
+   data = >data;
+   data->clks = clks;
+   data->clk_num = num_clks;
+
+   for (i = 0; i < num_clks; i++) {
+   if (!rclks[i])
+   continue;
+   clk = devm_clk_register_regmap(dev, rclks[i]);
+   if (IS_ERR(clk))
+   return PTR_ERR(clk);
+   clks[i] = clk;
+   }
+
+   ret = of_clk_add_provider(dev->of_node, of_clk_src_onecell_get, data);
+   if (ret)
+   return ret;
+
+   reset = >reset;
+   reset->rcdev.of_node = dev->of_node;
+   reset->rcdev.ops = _reset_ops;
+   reset->rcdev.owner = dev->driver->owner;
+   reset->rcdev.nr_resets = desc->num_resets;
+   reset->regmap = regmap;
+   reset->reset_map = desc->resets;
+   platform_set_drvdata(pdev, >rcdev);
+
+   ret = reset_controller_register(>rcdev);
+   if (ret)
+   of_clk_del_provider(dev->of_node);
+
+   return ret;
+}
+EXPORT_SYMBOL_GPL(qcom_cc_probe);
+
+void qcom_cc_remove(struct platform_device *pdev)
+{
+   of_clk_del_provider(pdev->dev.of_node);
+   reset_controller_unregister(platform_get_drvdata(pdev));
+}
+EXPORT_SYMBOL_GPL(qcom_cc_remove);
diff --git a/drivers/clk/qcom/common.h b/drivers/clk/qcom/common.h
new file mode 100644
index ..2c3cfc860348
--- /dev/null
+++ b/drivers/clk/qcom/common.h
@@ -0,0 +1,34 @@
+/*
+ * Copyright (c) 2014, The Linux Foundation. All rights reserved.
+ *
+ * This software is licensed under the terms of the GNU General Public
+ * License version 2, as published by the Free Software Foundation, and
+ * may be copied, distributed, and modified under those terms.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but 

Re: [PATCH -tip v8 06/26] [BUGFIX] x86: Prohibit probing on native_set_debugreg/load_idt

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:25 +0900
Masami Hiramatsu  wrote:

> Prohibit probing on native_set_debugreg and native_load_idt.
> Since the kprobes uses do_debug for single stepping,
> functions called from do_debug before notify_die must not
> be probed.
> And also native_load_idt is called from paranoid_exit when
> returning int3, this also must not be probed.
> 
> Signed-off-by: Masami Hiramatsu 
> Cc: Jeremy Fitzhardinge 

Reviewed-by: Steven Rostedt 

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 06/13] x86/efi: Build our own EFI services pointer table

[Roy Franz]

On Tue, Mar 4, 2014 at 5:14 AM, Matt Fleming  wrote:
> From: Matt Fleming 
>
> It's not possible to dereference the EFI System table directly when
> booting a 64-bit kernel on a 32-bit EFI firmware because the size of
> pointers don't match.
>
> In preparation for supporting the above use case, build a list of
> function pointers on boot so that callers don't have to worry about
> converting pointer sizes through multiple levels of indirection.
>
> Signed-off-by: Matt Fleming 
> ---
>  arch/x86/boot/compressed/eboot.c   | 319 
> -
>  arch/x86/boot/compressed/eboot.h   |  16 ++
>  arch/x86/boot/compressed/head_32.S |  48 -
>  arch/x86/boot/compressed/head_64.S |  57 --
>  drivers/firmware/efi/efi-stub-helper.c | 148 ---
>  5 files changed, 377 insertions(+), 211 deletions(-)
>
> diff --git a/arch/x86/boot/compressed/eboot.c 
> b/arch/x86/boot/compressed/eboot.c
> index a7677babf946..42548168bdc3 100644
> --- a/arch/x86/boot/compressed/eboot.c
> +++ b/arch/x86/boot/compressed/eboot.c
> @@ -19,10 +19,145 @@
>
>  static efi_system_table_t *sys_table;
>
> +static struct efi_config *efi_early;
> +
> +#define BOOT_SERVICES(bits)\
> +static void setup_boot_services##bits(struct efi_config *c)\
> +{  \
> +   efi_system_table_##bits##_t *table; \
> +   efi_boot_services_##bits##_t *bt;   \
> +   \
> +   table = (typeof(table))sys_table;   \
> +   \
> +   c->text_output = table->con_out;\
> +   \
> +   bt = (typeof(bt))(unsigned long)(table->boottime);  \
> +   \
> +   c->allocate_pool = bt->allocate_pool;   \
> +   c->allocate_pages = bt->allocate_pages; \
> +   c->get_memory_map = bt->get_memory_map; \
> +   c->free_pool = bt->free_pool;   \
> +   c->free_pages = bt->free_pages; \
> +   c->locate_handle = bt->locate_handle;   \
> +   c->handle_protocol = bt->handle_protocol;   \
> +   c->exit_boot_services = bt->exit_boot_services; \
> +}
> +BOOT_SERVICES(32);
> +BOOT_SERVICES(64);
>
> -#include "../../../../drivers/firmware/efi/efi-stub-helper.c"
> +static void efi_printk(efi_system_table_t *, char *);
> +static void efi_char16_printk(efi_system_table_t *, efi_char16_t *);
> +
> +static efi_status_t
> +efi_file_size(efi_system_table_t *sys_table, void *__fh,
> + efi_char16_t *filename_16, void **handle, u64 *file_sz)
> +{
> +   efi_file_handle_t *h, *fh = __fh;
> +   efi_file_info_t *info;
> +   efi_status_t status;
> +   efi_guid_t info_guid = EFI_FILE_INFO_ID;
> +   u32 info_sz;
> +
> +   status = efi_early->call((unsigned long)fh->open, fh, , filename_16,
> +EFI_FILE_MODE_READ, (u64)0);
> +   if (status != EFI_SUCCESS) {
> +   efi_printk(sys_table, "Failed to open file: ");
> +   efi_char16_printk(sys_table, filename_16);
> +   efi_printk(sys_table, "\n");
> +   return status;
> +   }
> +
> +   *handle = h;
> +
> +   info_sz = 0;
> +   status = efi_early->call((unsigned long)h->get_info, h, _guid,
> +_sz, NULL);
> +   if (status != EFI_BUFFER_TOO_SMALL) {
> +   efi_printk(sys_table, "Failed to get file info size\n");
> +   return status;
> +   }
> +
> +grow:
> +   status = efi_early->call(efi_early->allocate_pool, EFI_LOADER_DATA,
> +info_sz, (void **));
> +   if (status != EFI_SUCCESS) {
> +   efi_printk(sys_table, "Failed to alloc mem for file info\n");
> +   return status;
> +   }
> +
> +   status = efi_early->call((unsigned long)h->get_info, h, _guid,
> +_sz, info);
> +   if (status == EFI_BUFFER_TOO_SMALL) {
> +   efi_early->call(efi_early->free_pool, info);
> +   goto grow;
> +   }
> +
> +   *file_sz = info->file_size;
> +   efi_early->call(efi_early->free_pool, info);
> +
> +   if (status != EFI_SUCCESS)
> +   efi_printk(sys_table, "Failed to get initrd info\n");
> +
> +   return status;
> +}
> +
> +static inline efi_status_t
> +efi_file_read(void *__fh, void *handle, unsigned long *size, void *addr)
> +{
> +   

Re: [PATCH -tip v8 05/26] [BUGFIX] kprobes/x86: Prohibit probing on debug_stack_*

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:18 +0900
Masami Hiramatsu  wrote:

> Prohibit probing on debug_stack_reset and debug_stack_set_zero.
> Since the both functions are called from TRACE_IRQS_ON/OFF_DEBUG
> macros which run in int3 ist entry, probing it may cause a soft
> lockup.
> 
> This happens when the kernel built with CONFIG_DYNAMIC_FTRACE=y
> and CONFIG_TRACE_IRQFLAGS=y.
> 
> Signed-off-by: Masami Hiramatsu 

Reviewed-by: Steven Rostedt 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 04/26] kprobes: Introduce NOKPROBE_SYMBOL() macro for blacklist

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:11 +0900
Masami Hiramatsu  wrote:


> 
> diff --git a/Documentation/kprobes.txt b/Documentation/kprobes.txt
> index 0cfb00f..7062631 100644
> --- a/Documentation/kprobes.txt
> +++ b/Documentation/kprobes.txt
> @@ -22,8 +22,9 @@ Appendix B: The kprobes sysctl interface
>  
>  Kprobes enables you to dynamically break into any kernel routine and
>  collect debugging and performance information non-disruptively. You
> -can trap at almost any kernel code address, specifying a handler
> +can trap at almost any kernel code address(*), specifying a handler
>  routine to be invoked when the breakpoint is hit.
> +(*: at some part of kernel code can not be trapped, see 1.5 Blacklist)

"*: some parts of the kernel code can not be trapped,"

>  
>  There are currently three types of probes: kprobes, jprobes, and
>  kretprobes (also called return probes).  A kprobe can be inserted
> @@ -273,6 +274,19 @@ using one of the following techniques:
>   or
>  - Execute 'sysctl -w debug.kprobes_optimization=n'
>  
> +1.5 Blacklist
> +
> +Kprobes can probe almost of the kernel except itself. This means

s/almost/most/

> +that there are some functions where kprobes cannot probe. Probing
> +(trapping) such functions can cause recursive trap (e.g. double

   cause a recursive trap

> +fault) or at least the nested probe handler never be called.

  "or the nested probe handler may never be called."

> +Kprobes manages such functions as a blacklist.
> +If you want to add a function into the blacklist, you just need
> +to (1) include linux/kprobes.h and (2) use NOKPROBE_SYMBOL() macro
> +to specify a blacklisted function.
> +Kprobes checks given probe address with the blacklist and reject

  "checks the given probe address against the black list and rejects"

> +registering if the given address is in the blacklist.

   registering it, if

> +
>  2. Architectures Supported
>  
>  Kprobes, jprobes, and return probes are implemented on the following
> diff --git a/arch/x86/include/asm/asm.h b/arch/x86/include/asm/asm.h
> index 4582e8e..7730c1c 100644
> --- a/arch/x86/include/asm/asm.h
> +++ b/arch/x86/include/asm/asm.h
> @@ -57,6 +57,12 @@
>   .long (from) - . ;  \
>   .long (to) - . + 0x7ff0 ;   \
>   .popsection
> +
> +# define _ASM_NOKPROBE(entry)\
> + .pushsection "_kprobe_blacklist","aw" ; \
> + _ASM_ALIGN ;\
> + _ASM_PTR (entry);   \
> + .popsection
>  #else
>  # define _ASM_EXTABLE(from,to)   \
>   " .pushsection \"__ex_table\",\"a\"\n"  \
> @@ -71,6 +77,7 @@
>   " .long (" #from ") - .\n"  \
>   " .long (" #to ") - . + 0x7ff0\n"   \
>   " .popsection\n"
> +/* For C file, we already have NOKPROBE_SYMBOL macro */
>  #endif
>  
>  #endif /* _ASM_X86_ASM_H */
> diff --git a/arch/x86/kernel/paravirt.c b/arch/x86/kernel/paravirt.c
> index 1b10af8..4c785fd 100644
> --- a/arch/x86/kernel/paravirt.c
> +++ b/arch/x86/kernel/paravirt.c
> @@ -23,6 +23,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include 
>  #include 
> @@ -389,6 +390,9 @@ __visible struct pv_cpu_ops pv_cpu_ops = {
>   .end_context_switch = paravirt_nop,
>  };
>  
> +/* At this point, native_get_debugreg has real function entry */

  "has a real"

-- Steve

> +NOKPROBE_SYMBOL(native_get_debugreg);
> +
>  struct pv_apic_ops pv_apic_ops = {
>  #ifdef CONFIG_X86_LOCAL_APIC
>   .startup_ipi_hook = paravirt_nop,
> diff --git a/include/asm-generic/vmlinux.lds.h 
> b/include/asm-generic/vmlinux.lds.h
> index bc2121f..81d07d5 100644
> --- a/include/asm-generic/vmlinux.lds.h
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] usb: musb: Fix obex in g_nokia.ko causing kernel panic

[Rabin Vincent]

2014-02-06 20:25 GMT+01:00 Ivaylo Dimitrov :
> From: Felipe Balbi 

This patch, which is present in 3.14-rc4 as 30a70b026 ("usb: musb: fix
obex in g_nokia.ko causing kernel panic"), breaks USB gadget support
on my Pandaboard.  Bisecting points to this commit, reverting it makes
USB gadget support work again.  The problem is that this patch deletes
the call which turns on the PHY.

Config is attached.

> diff --git a/drivers/usb/musb/omap2430.c b/drivers/usb/musb/omap2430.c
> index 2a408cd..8aa59a2 100644
> --- a/drivers/usb/musb/omap2430.c
> +++ b/drivers/usb/musb/omap2430.c
> @@ -659,7 +659,6 @@ static int omap2430_runtime_suspend(struct device *dev)
> OTG_INTERFSEL);
>
> omap2430_low_level_exit(musb);
> -   phy_power_off(musb->phy);
> }
>
> return 0;
> @@ -674,7 +673,6 @@ static int omap2430_runtime_resume(struct device *dev)
> omap2430_low_level_init(musb);
> musb_writel(musb->mregs, OTG_INTERFSEL,
> musb->context.otg_interfsel);
> -   phy_power_on(musb->phy);
> }
>
> return 0;


panda-usb-config.gz
Description: GNU Zip compressed data

reiserfs: kernel BUG at fs/reiserfs/journal.c:1095!

[Sasha Levin]

Hi all,

While fuzzing with trinity inside a KVM tools guest running the latest -next
kernel, I've stumbled on the following:

[  825.014684] kernel BUG at fs/reiserfs/journal.c:1095!
[  825.014783] invalid opcode:  [#1] PREEMPT SMP DEBUG_PAGEALLOC
[  825.014783] Dumping ftrace buffer:
[  825.014783](ftrace buffer empty)
[  825.014783] Modules linked in:
[  825.014783] CPU: 1 PID: 22304 Comm: trinity-c57 Tainted: GW 
3.14.0-rc7-next-20140321-sasha-00018-g0516fe6-dirty #265
[  825.014783] task: 8802ec7bb000 ti: 8802e3bb8000 task.ti: 
8802e3bb8000
[  825.014783] RIP:  flush_commit_list (fs/reiserfs/journal.c:1095)
[  825.014783] RSP: 0018:8802e3bb9d68  EFLAGS: 00010202
[  825.014783] RAX: 0023 RBX: 88003da2b3d8 RCX: 0006
[  825.014783] RDX: c9000b5d RSI: 813f413f RDI: 88007e12cd80
[  825.014783] RBP: 8802e3bb9dd8 R08:  R09: 
[  825.014783] R10: 0001 R11:  R12: 0002
[  825.014783] R13: 8807a4c537e4 R14:  R15: 8807a4c537c8
[  825.014783] FS:  7f60da8fe700() GS:88007ec0() 
knlGS:
[  825.014783] CS:  0010 DS:  ES:  CR0: 8005003b
[  825.014783] CR2: 7f6557d11489 CR3: 0002dde16000 CR4: 06a0
[  825.014783] Stack:
[  825.014783]  8802e3bb9d78 c9000b5d01d8 8802 
8807a4c537f0
[  825.014783]  00010b5d01d8 c9000b5d 8802e3bb9dd8 
88007e12dcb0
[  825.014783]  c9000b5d c9000b5d 880078886c48 
c9000b5d02f8
[  825.014783] Call Trace:
[  825.014783]  do_journal_end.isra.16 (fs/reiserfs/journal.c:4194)
[  825.014783]  ? SyS_tee (fs/sync.c:77)
[  825.014783]  journal_end_sync (fs/reiserfs/journal.c:3429)
[  825.014783]  reiserfs_sync_fs (fs/reiserfs/super.c:77)
[  825.014783]  ? SyS_tee (fs/sync.c:77)
[  825.014783]  ? iterate_supers (fs/super.c:510)
[  825.014783]  sync_fs_one_sb (fs/sync.c:80)
[  825.014783]  iterate_supers (fs/super.c:512)
[  825.014783]  sys_sync (fs/sync.c:109)
[  825.014783]  tracesys (arch/x86/kernel/entry_64.S:749)
[  825.014783] Code: 82 1f ff ff ff 41 8b 47 1c 83 f8 01 74 06 0f 0b 0f 1f 40 00 45 
85 f6 75 5e 48 8b 55 b8 48 8b 42 28 a8 08 0f 84 db 02 00 00 eb 4c <0f> 0b 0f 1f 
80 00 00 00 00 e8 1b 78 f5 ff 48 89 df e8 03 7e 00
[  825.014783] RIP  flush_commit_list (fs/reiserfs/journal.c:1095)
[  825.014783]  RSP 


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[H. Peter Anvin]

On 03/21/2014 05:30 PM, Andi Kleen wrote:
> 
> %  grep -r 'rdmsr' arch/x86/*  | grep -v safe | wc -l
> 285
> 
> I assume it'll keep you all busy for a while.
> 
> [compared to a likely one liner in KVM]
> 

It's not just KVM, though.

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Andi Kleen]

On Fri, Mar 21, 2014 at 05:26:17PM -0700, H. Peter Anvin wrote:
> On 03/21/2014 05:22 PM, Andi Kleen wrote:
> >> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
> >> more of the default, especially for things like this where the error
> >> handling is obvious (doesn't work?  Disable the PMU.)
> > 
> > That would be completely wrong. KVM has a full architectural perfmon PMU,
> > just no model specific extensions like LBR.
> > 
> 
> s/PMU/PMU extension in question/

%  grep -r 'rdmsr' arch/x86/*  | grep -v safe | wc -l
285

I assume it'll keep you all busy for a while.

[compared to a likely one liner in KVM]

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[H. Peter Anvin]

On 03/21/2014 05:22 PM, Andi Kleen wrote:
>> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
>> more of the default, especially for things like this where the error
>> handling is obvious (doesn't work?  Disable the PMU.)
> 
> That would be completely wrong. KVM has a full architectural perfmon PMU,
> just no model specific extensions like LBR.
> 

s/PMU/PMU extension in question/

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Andi Kleen]

> Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
> more of the default, especially for things like this where the error
> handling is obvious (doesn't work?  Disable the PMU.)

That would be completely wrong. KVM has a full architectural perfmon PMU,
just no model specific extensions like LBR.

-Andi


-- 
a...@linux.intel.com -- Speaking for myself only.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC PATCH] UBI: fix rb_tree node comparison in add_map

[Richard Weinberger]

Am 21.03.2014 20:54, schrieb Mike Snitzer:
> The comparisons used in add_vol() shouldn't be identical.  Pretty sure
> the following is correct but it is completely untested.
> 
> Signed-off-by: Mike Snitzer 
> ---
>  drivers/mtd/ubi/fastmap.c |4 ++--
>  1 files changed, 2 insertions(+), 2 deletions(-)
> 
> NOTE: I stumbled upon this code while implementing some rb_tree code
>   (and looking for some existing rb_tree code as a reference).

Thanks a lot for pointing this out!

Acked-by: Richard Weinberger 

Thanks,
//richard
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Use 64-bit DMA addresses for LPAE+VirtIO-MMIO

[Arnd Bergmann]

On Friday 21 March 2014 23:27:24 Catalin Marinas wrote:
> On 21 Mar 2014, at 19:44, Christopher Covington  wrote:
> > On 03/21/2014 12:27 PM, Catalin Marinas wrote:
> >>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
> >>> index 1f8fed9..a62bcc9 100644
> >>> --- a/arch/arm/mm/Kconfig
> >>> +++ b/arch/arm/mm/Kconfig
> >>> @@ -617,6 +617,7 @@ config ARM_LPAE
> >>> bool "Support for the Large Physical Address Extension"
> >>> depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
> >>> !CPU_32v4 && !CPU_32v3
> >>> +   select ARCH_DMA_ADDR_T_64BIT if VIRTIO_MMIO
> >> 
> >> That's the wrong place to enable ARCH_DMA_ADDR_T_64BIT. Do you have a
> >> platform with >32-bit physical address space? If yes, it should be
> >> selected there.
> > 
> > The platforms I'm currently using are models like the Versatile Express
> > RTSM/FVP. I can respin with changes to ARCH_VEXPRESS and ARCH_VIRT instead.
> 
> But do you use RAM beyond 32-bit on such models?

I think the more important question here is what the normal behavior is
for these platforms. I believe in most cases you don't have RAM above
the boundary, so we should not enable the option by default as it can
have noticeable overhead (we'd turn it on all the time if it didn't).

How about one of these two 

a)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9ea4b7b..6e3b6db 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -628,7 +628,9 @@ config ARCH_PHYS_ADDR_T_64BIT
def_bool ARM_LPAE
 
 config ARCH_DMA_ADDR_T_64BIT
-   bool
+   def_bool "Allow DMA to high (>4GB) addresses"
+   depends on ARCH_PHYS_ADDR_T_64BIT
+   default y
help

 config ARM_THUMB
bool "Support Thumb user binaries" if !CPU_THUMBONLY


b)

diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
index 9ea4b7b..4a21b1e 100644
--- a/arch/arm/mm/Kconfig
+++ b/arch/arm/mm/Kconfig
@@ -619,16 +619,28 @@ config ARM_LPAE
help
  Say Y if you have an ARMv7 processor supporting the LPAE page
  table format and you would like to access memory beyond the
- 4GB limit. The resulting kernel image will not run on
- processors without the LPA extension.
+ 4GB limit, or run virtual machines usign KVM.
+ The resulting kernel image will not run on processors without
+ the LPA extension.
 
  If unsure, say N.
 
 config ARCH_PHYS_ADDR_T_64BIT
-   def_bool ARM_LPAE
+   bool "Support more than 4GB of physical address space" if EXPERT
+   depends on ARM_LPAE
+   default y
+   help
+ Say Y if you use LPAE to access RAM or MMIO registers at
+ addresses beyond the low 4GB of address space. If this
+ option is disabled, the kernel will use the LPAE page table
+ format and it can offer KVM support, but will use a slightly
+ more efficient representation of physical memory addresses
+ that restricts access to 32-bit addressable locations.
+
+ If unsure, say Y.
 
 config ARCH_DMA_ADDR_T_64BIT
-   bool
+   def_bool ARCH_PHYS_ADDR_T_64BIT
 
 config ARM_THUMB
bool "Support Thumb user binaries" if !CPU_THUMBONLY



In either case, platforms that need this support can always
'select' it, while a kernel built only for platforms that don't
need it can offer this as a user-selectable option.

Arnd
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add quirk HID_QUIRK_NO_INIT_REPORTS for RNDPLUS touchscreen

[Benjamin Tissoires]

On Fri, Mar 21, 2014 at 6:08 PM, Yufeng Shen  wrote:
>
>
> On Fri, Mar 21, 2014 at 4:58 PM, Benjamin Tissoires
>  wrote:
>>
>> On Fri, Mar 21, 2014 at 3:39 PM, Yufeng Shen  wrote:
>> > There is timeout error during initialization:
>> > kernel: [   14.167086] hid-multitouch 0003:2512:5003.0001:
>> > usb_submit_urb(ctrl) failed: -1
>> > kernel: [   14.167135] hid-multitouch 0003:2512:5003.0001: timeout
>> > initializing reports
>> > kernel: [   14.167407] input: RNDPLUS Co., LTD   PULSEIR TSR4601 as
>> > /devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input14
>> > kernel: [   14.167975] cpufreq_interactive: monitoring input on RNDPLUS
>> > Co., LTD   PULSEIR TSR4601
>> > kernel: [   14.168266] hid-multitouch 0003:2512:5003.0001:
>> > input,hiddev0,hidraw1: USB HID v1.10 Mouse [RNDPLUS Co., LTD   PULSEIR
>> > TSR4601] on usb-:00:1d.0-1.3/input0
>> >
>> > Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.
>>
>> I already asked you to test if HID_QUIRK_NO_INIT_INPUT_REPORTS was
>> working for the same same kind of timeout
>> (https://patchwork.kernel.org/patch/3544281/).
>
>
> The reason I didn't test HID_QUIRK_NO_INIT_INPUT_REPORTS was that I am
> mainly
> working with kernel 3.8/3.10. And HID_QUIRK_NO_INIT_INPUT_REPORTS was not
> present

You should consider working with an upstream kernel when sending patches.

> in the kernel source. Do you have the patch set that I can port to 3.8/3.10
> kernel for testing ?

git blames gives 595e9276ce68791317484ec7f0f9f2e0457c3b34, which is
Linus' tree since 3.12.

Cheers,
Benjamin

>
>
>>
>>
>> So I am asking again: please test HID_QUIRK_NO_INIT_INPUT_REPORTS and
>> if it works, use this quirk instead the one in this patch.
>> This *really* matters because the quirk HID_QUIRK_NO_INIT_REPORTS does
>> not initialize feature reports which contains important information
>> regarding hid-multitouch.
>>
>> Cheers,
>> Benjamin
>>
>> >
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/3] kmemleak: change some global variables to int

[Catalin Marinas]

On Mon, Mar 17, 2014 at 04:09:04AM +, Li Zefan wrote:
> They don't have to be atomic_t, because they are simple boolean
> toggles.
> 
> Signed-off-by: Li Zefan 

A reason for which I had atomic_t was to avoid compiler optimisations
but I don't immediately see how it could go wrong. Assuming that you
have tested it,

Acked-by: Catalin Marinas 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/3] kmemleak: remove redundant code

[Catalin Marinas]

On Mon, Mar 17, 2014 at 04:08:00AM +, Li Zefan wrote:
> - remove kmemleak_padding().
> - remove kmemleak_release().
> 
> Signed-off-by: Li Zefan 

Acked-by: Catalin Marinas 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

mmotm 2014-03-21-16-28 uploaded

[akpm]

The mm-of-the-moment snapshot 2014-03-21-16-28 has been uploaded to

   http://www.ozlabs.org/~akpm/mmotm/

mmotm-readme.txt says

README for mm-of-the-moment:

http://www.ozlabs.org/~akpm/mmotm/

This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
more than once a week.

You will need quilt to apply these patches to the latest Linus release (3.x
or 3.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
http://ozlabs.org/~akpm/mmotm/series

The file broken-out.tar.gz contains two datestamp files: .DATE and
.DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
followed by the base kernel version against which this patch series is to
be applied.

This tree is partially included in linux-next.  To see which patches are
included in linux-next, consult the `series' file.  Only the patches
within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
linux-next.

A git tree which contains the memory management portion of this tree is
maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
by Michal Hocko.  It contains the patches which are between the
"#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
file, http://www.ozlabs.org/~akpm/mmotm/series.


A full copy of the full kernel tree with the linux-next and mmotm patches
already applied is available through git within an hour of the mmotm
release.  Individual mmotm releases are tagged.  The master branch always
points to the latest release, so it's constantly rebasing.

http://git.cmpxchg.org/?p=linux-mmotm.git;a=summary

To develop on top of mmotm git:

  $ git remote add mmotm 
git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
  $ git remote update mmotm
  $ git checkout -b topic mmotm/master
  
  $ git send-email mmotm/master.. [...]

To rebase a branch with older patches to a new mmotm release:

  $ git remote update mmotm
  $ git rebase --onto mmotm/master  topic




The directory http://www.ozlabs.org/~akpm/mmots/ (mm-of-the-second)
contains daily snapshots of the -mm tree.  It is updated more frequently
than mmotm, and is untested.

A git copy of this tree is available at

http://git.cmpxchg.org/?p=linux-mmots.git;a=summary

and use of this tree is similar to
http://git.cmpxchg.org/?p=linux-mmotm.git, described above.


This mmotm tree contains the following patches against 3.14-rc7:
(patches marked "*" will be included in linux-next)

  origin.patch
  arch-alpha-kernel-systblss-remove-debug-check.patch
  i-need-old-gcc.patch
  maintainers-akpm-maintenance.patch
* sh-fix-format-string-bug-in-stack-tracer.patch
* backing_dev-fix-hung-task-on-sync.patch
* backing_dev-fix-hung-task-on-sync-fix.patch
* slub-fix-high-order-page-allocation-problem-with-__gfp_nofail.patch
* bdi-avoid-oops-on-device-removal.patch
* kthread-ensure-locality-of-task_struct-allocations.patch
* arch-x86-mm-kmemcheck-kmemcheckc-use-kstrtoint-instead-of-sscanf.patch
* kmemleak-allow-freeing-internal-objects-after-kmemleak-was-disabled.patch
* kmemleak-remove-redundant-code.patch
* kmemleak-change-some-global-variables-to-int.patch
* arm-use-generic-fixmaph.patch
* fs-cifs-cifsfsc-add-__init-to-cifs_init_inodecache.patch
* fs-freevxfs-vxfs_lookupc-update-function-comment.patch
* fanotify-remove-useless-bypass_perm-check.patch
* fanotify-use-fanotify-event-structure-for-permission-response-processing.patch
* fanotify-convert-access_mutex-to-spinlock.patch
* fanotify-reorganize-loop-in-fanotify_read.patch
* fanotify-move-unrelated-handling-from-copy_event_to_user.patch
* sched_clock-document-4mhz-vs-1mhz-decision.patch
* input-route-kbd-leds-through-the-generic-leds-layer.patch
* genksyms-fix-typeof-handling.patch
* ntfs-logging-clean-up.patch
* score-remove-unused-cpu_score7-kconfig-parameter.patch
* sh-push-extra-copy-of-r0-r2-for-syscall-parameters.patch
* sh-remove-unused-do_fpu_error.patch
* sh-dont-pass-saved-userspace-state-to-exception-handlers.patch
* arch-sh-boards-board-sh7757lcrc-fixup-sdhi-register-size.patch
* sh-sh7757-switch-rspi-clock-to-dev-id-match.patch
* drivers-net-irda-donauboe-convert-to-module_pci_driver.patch
* net-core-rtnetlinkc-copy-paste-error-in-rtnl_bridge_notify.patch
* 
ocfs2-fix-null-pointer-dereference-when-access-dlm_state-before-launching-dlm-thread.patch
* ocfs2-change-ip_unaligned_aio-to-of-type-mutex-from-atomit_t.patch
* ocfs2-remove-unused-variable-uuid_net_key-in-ocfs2_initialize_super.patch
* 
ocfs2-improve-fsync-efficiency-and-fix-deadlock-between-aio_write-and-sync_file.patch
* 
ocfs2-o2net-incorrect-to-terminate-accepting-connections-loop-upon-rejecting-an-invalid-one.patch
* ocfs2-dlm-fix-lock-migration-crash.patch
* ocfs2-dlm-fix-recovery-hung.patch
* ocfs2-add-dlm_recover_callback_support-in-sysfs.patch
* ocfs2-add-dlm_recover_callback_support-in-sysfs-fix.patch
* ocfs2-fix-a-tiny-race-when-running-dirop_fileop_racer.patch
* ocfs2-remove-ocfs2_inode_skip_delete-flag.patch
* 

Re: [PATCH v2 1/3] kmemleak: allow freeing internal objects after kmemleak was disabled

[Catalin Marinas]

Hi Li,

On 17 Mar 2014, at 04:07, Li Zefan  wrote:
> Currently if kmemleak is disabled, the kmemleak objects can never be freed,
> no matter if it's disabled by a user or due to fatal errors.
> 
> Those objects can be a big waste of memory.
> 
>  OBJS ACTIVE  USE OBJ SIZE  SLABS OBJ/SLAB CACHE SIZE NAME
> 1200264 1197433  99%0.30K  46164   26369312K kmemleak_object
> 
> With this patch, internal objects will be freed immediately if kmemleak is
> disabled explicitly by a user. If it's disabled due to a kmemleak error,
> The user will be informed, and then he/she can reclaim memory with:
> 
>   # echo off > /sys/kernel/debug/kmemleak
> 
> v2: use "off" handler instead of "clear" handler to do this, suggested
>by Catalin.

I think there was a slight misunderstanding. My point was about "echo
scan=off” before “echo off”, they can just be squashed into the
same action of the latter.

I would keep the “clear” part separately as per your first patch. I
recall people asked in the past to still be able to analyse the reports
even though kmemleak failed or was disabled.

Thanks,

Catalin--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

[Andrew Morton]

On Sat, 22 Mar 2014 00:21:59 +0100 Fabian Frederick  wrote:

> > What we should do is to fix all these call sites so they can handle
> > memory exhaustion.  That's hard so in the interim they should be using
> > __GFP_NOFAIL.
> > 
> 
> Ok, if even ext4 comments are wrong, things gonna be very difficult :)
> Any sample of a callsite transition done well ?  (git id ?)

grep NOFAIL fs/jbd/*.c
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: Use 64-bit DMA addresses for LPAE+VirtIO-MMIO

[Catalin Marinas]

On 21 Mar 2014, at 19:44, Christopher Covington  wrote:
> On 03/21/2014 12:27 PM, Catalin Marinas wrote:
>> On Wed, Mar 19, 2014 at 05:35:19PM +, Christopher Covington wrote:
>>> On an LPAE system, the physical addresses used by VirtIO-MMIO may
>>> be larger than 32 bits, even if the header and configuration space
>>> addresses fit into 32 bits. For example with the Versatile Express
>>> memory map using 4G memory, the following error occured when trying
>>> to use a VirtIO-MMIO block device.
>>> 
>>> EXT2-fs (vda): error: ext2_check_page: bad entry in directory #2: :
>>> unaligned directory entry - offset=0, inode=3755990991, rec_len=57311,
>>> name_len=223
>>> 
>>> To fix this, select ARCH_DMA_ADDR_T_64BIT when both LPAE and
>>> VIRTIO_MMIO are selected.
>>> 
>>> Signed-off-by: Christopher Covington 
>>> ---
>>> arch/arm/mm/Kconfig | 1 +
>>> 1 file changed, 1 insertion(+)
>>> 
>>> diff --git a/arch/arm/mm/Kconfig b/arch/arm/mm/Kconfig
>>> index 1f8fed9..a62bcc9 100644
>>> --- a/arch/arm/mm/Kconfig
>>> +++ b/arch/arm/mm/Kconfig
>>> @@ -617,6 +617,7 @@ config ARM_LPAE
>>> bool "Support for the Large Physical Address Extension"
>>> depends on MMU && CPU_32v7 && !CPU_32v6 && !CPU_32v5 && \
>>> !CPU_32v4 && !CPU_32v3
>>> +   select ARCH_DMA_ADDR_T_64BIT if VIRTIO_MMIO
>> 
>> That's the wrong place to enable ARCH_DMA_ADDR_T_64BIT. Do you have a
>> platform with >32-bit physical address space? If yes, it should be
>> selected there.
> 
> The platforms I'm currently using are models like the Versatile Express
> RTSM/FVP. I can respin with changes to ARCH_VEXPRESS and ARCH_VIRT instead.

But do you use RAM beyond 32-bit on such models?

Catalin
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [RFC 1/1] fs/reiserfs/journal.c: Remove obsolete __GFP_NOFAIL

[Fabian Frederick]

On Fri, 21 Mar 2014 13:00:55 -0700
Andrew Morton  wrote:

> On Fri, 21 Mar 2014 17:18:30 +0100 Fabian Frederick  wrote:
> 
> > Loop around congestion_wait on allocation failure/alloc_journal_list
> > like already fixed in other FS.
> > 
> > ...
> >
> > --- a/fs/reiserfs/journal.c
> > +++ b/fs/reiserfs/journal.c
> > @@ -2487,8 +2487,13 @@ static int journal_read(struct super_block *sb)
> >  static struct reiserfs_journal_list *alloc_journal_list(struct super_block 
> > *s)
> >  {
> > struct reiserfs_journal_list *jl;
> > -   jl = kzalloc(sizeof(struct reiserfs_journal_list),
> > -GFP_NOFS | __GFP_NOFAIL);
> > +
> > +   do {
> > +   jl = kzalloc(sizeof(struct reiserfs_journal_list), GFP_NOFS);
> > +   if (unlikely(!jl))
> > +   congestion_wait(BLK_RW_ASYNC, HZ/50);
> > +   } while (!jl)
> > +
> 
> Dammit, who has been running around converting __GFP_NOFAIL into
> open-coded congestion_wait() loops?
> 
> The whole point of __GFP_NOFAIL is to centralise this
> wait-for-memory-for-ever operation.  So it is implemented in a common
> (core) place and so that we can easily locate these problematic
> callers.
> 
> This comment in ext4:
> 
>   /*
>* If __GFP_FS is not present, then we may be
>* being called from inside the fs writeback
>* layer, so we MUST NOT fail.  Since
>* __GFP_NOFAIL is going away, we will arrange
>* to retry the allocation ourselves.
>*/
> 
> is exactly wrong.  Yes, we'd like __GFP_NOFAIL to go away, but it
> cannot go away until buggy callsites such as this one are *fixed*. 
> Removing the __GFP_NOFAIL usage simply hides the buggy code from casual
> searchers.
> 
> argh.
> 
> What we should do is to fix all these call sites so they can handle
> memory exhaustion.  That's hard so in the interim they should be using
> __GFP_NOFAIL.
> 

Ok, if even ext4 comments are wrong, things gonna be very difficult :)
Any sample of a callsite transition done well ?  (git id ?)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH] regulator: st-pwm: Convert to get_voltage_sel

[Axel Lin]

Also remove test for selector in st_pwm_regulator_set_voltage_sel, the checking
is already done in .list_voltage.

Signed-off-by: Axel Lin 
---
 drivers/regulator/st-pwm.c | 9 +++--
 1 file changed, 3 insertions(+), 6 deletions(-)

diff --git a/drivers/regulator/st-pwm.c b/drivers/regulator/st-pwm.c
index 6ef569f..e367af1 100644
--- a/drivers/regulator/st-pwm.c
+++ b/drivers/regulator/st-pwm.c
@@ -39,11 +39,11 @@ struct st_pwm_voltages {
unsigned int dutycycle;
 };
 
-static int st_pwm_regulator_get_voltage(struct regulator_dev *dev)
+static int st_pwm_regulator_get_voltage_sel(struct regulator_dev *dev)
 {
struct st_pwm_regulator_data *drvdata = rdev_get_drvdata(dev);
 
-   return drvdata->pdata->duty_cycle_table[drvdata->state].uV;
+   return drvdata->state;
 }
 
 static int st_pwm_regulator_set_voltage_sel(struct regulator_dev *dev,
@@ -53,9 +53,6 @@ static int st_pwm_regulator_set_voltage_sel(struct 
regulator_dev *dev,
int dutycycle;
int ret;
 
-   if (selector >= dev->desc->n_voltages)
-   return -EINVAL;
-
dutycycle = (ST_PWM_REG_PERIOD / 100) *
drvdata->pdata->duty_cycle_table[selector].dutycycle;
 
@@ -92,7 +89,7 @@ static int st_pwm_regulator_list_voltage(struct regulator_dev 
*dev,
 
 static struct regulator_ops st_pwm_regulator_voltage_ops = {
.set_voltage_sel = st_pwm_regulator_set_voltage_sel,
-   .get_voltage = st_pwm_regulator_get_voltage,
+   .get_voltage_sel = st_pwm_regulator_get_voltage_sel,
.list_voltage= st_pwm_regulator_list_voltage,
.map_voltage = regulator_map_voltage_iterate,
 };
-- 
1.8.3.2



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] drivers/video: fix mb862xx_i2c depends issue build failure

[Randy Dunlap]

On 03/21/2014 06:53 AM, Paul Gortmaker wrote:
> On 14-03-21 09:32 AM, Tomi Valkeinen wrote:
>> Hi,
>>
>> On 20/03/14 17:16, Paul Gortmaker wrote:
>>> Any randconfig that sets I2C=m and FB_MB862XX_I2C=y will
>>> encounter a final link failure that looks like this:
>>
>> It compiles fine with I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y.
>>
>>> drivers/built-in.o: In function `mb862xx_i2c_init':
>>> drivers/video/mb862xx/mb862xx-i2c.c:165: undefined reference to 
>>> `i2c_add_adapter'
>>> drivers/built-in.o: In function `mb862xx_i2c_exit':
>>> drivers/video/mb862xx/mb862xx-i2c.c:176: undefined reference to 
>>> `i2c_del_adapter'
>>>
>>> Since FB_MB862XX_I2C is a bool and not tristate, simply
>>> don't offer it at all if core I2C support is not built in.
>>
>> FB_MB862XX_I2C is not a driver, it just adds the i2c support to
>> FB_MB862XX. The relevant thing is whether FB_MB862XX is m or y, so
>> compiling with:
>>
>> I2C=m, FB_MB862XX=y and FB_MB862XX_I2C=y
>>
>> will fail.
> 
> How would you suggest we fix it then?  Perhaps we could simplify the
> Kconfig space and just get rid of FB_MB862XX_I2C entirely?  Is there
> ever a reason why someone would want it turned off when I2C is present?
> 
> Paul.
> --
> 
>>
>>> Reported-by: Jim Davis 
>>> Reported-by: Fengguang Wu 
>>> Signed-off-by: Paul Gortmaker 
>>>
>>> diff --git a/drivers/video/Kconfig b/drivers/video/Kconfig
>>> index dade5b7699bc..aefd1b9a3cbd 100644
>>> --- a/drivers/video/Kconfig
>>> +++ b/drivers/video/Kconfig
>>> @@ -2338,7 +2338,7 @@ endchoice
>>>  
>>>  config FB_MB862XX_I2C
>>> bool "Support I2C bus on MB862XX GDC"
>>> -   depends on FB_MB862XX && I2C
>>> +   depends on FB_MB862XX && I2C=y
>>> default y
>>> help
>>>   Selecting this option adds Coral-P(A)/Lime GDC I2C bus adapter
>>
>> This fix is not correct, as it prevents the following, valid, config:
>>
>> I2C=m, FB_MB862XX=m and FB_MB862XX_I2C=y

If I am following this correctly, this kconfig situation is often handled
by something like

depends on I2C=y || I2C=FB_MB862XX



-- 
~Randy
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 6/7] Cpuidle: Deal with timer expiring in the past

[Len Brown]

Tuukka,
I've reproduced this negative on a 48 thread 2-socket Xeon during boot
(seen it only once, so far).

expected_us gets calculated to be -1, which is truthful, since the
next timer return value was about 500ns in the past
and our math truncates.  This, in turn, confuses the heck out of
menu's prediction of the next event to be
over 500 sec in the future.

I suspect more breakage is lurking, so I'll poke some more...

Len Brown, Intel Open Source Technology Center
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] initramfs: print error and shell out for unsupported content

[Alexander Holler]

Am 21.03.2014 23:55, schrieb Andrew Morton:
> On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler  
> wrote:
> 
>> Am 21.03.2014 22:03, schrieb Andrew Morton:
>>> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler  
>>> wrote:
>>>
 The initramfs generation is broken for file and directory names which 
 contain
 colons or spaces. Print an error and don't try to continue.
>>
>>> It would be better to fix the it-doesnt-work-with-all-filenames bug. 
>>> Any details on that?
>>
>> IMHO not worth the time. The whole process which is curently used is
>> extremly fragile.
>>
>> E.g it's almost guaranteed to fail trying to include arbitrary filenames
>> as dependencies in a Makefile. Besides the one problem I've discoverd
>> with colons, there could be much more things happen, e.g. with filenames
>> which do include other special Makefile characters you all would have to
>> escape correctly.
>>
>> And the problem with spaces isn't as easy to fix as it first does look
>> like. I think it might be easier to write the whole stuff new instead of
>> trying to escape the spaces in various ways needed to end up correctly
>> in the cpio (it first goes through shell code and is then feeded as some
>> list to a C program).
>>
>> And I think that just isn't worth the time. Using find | cpio works just
>> fine to generate a cpio archive and usually an initramfs just contains
>> some megabytes. So it isn't a problem at all to rebuild the complete
>> cpio archive with every call of make, it doesn't need much more than
>> about a second or similiar on almost any machine.
>>
>> And for the records, I indeed had a deeper look, trying to fix it. But,
>> as said, quickly realized that it will need too much effort and doesn't
>> make sense, if it will be doable correctly at all.
>>
> 
> huh, OK.
> 
> Should we check for \t and \n as well?

Hmm, maybe. But usually there aren't filenames wich do contain those
characters, and if you want to break (or exploit) the kernel build
process, there are easier ways. But colons and spaces are more widely
used, e.g. the colons in my initramfs were generated by bluez (look at
/var/lib/bluetooth).

I think the current process is good enough for most stuff one wants to
put into an initramfs, and it has the great feature of the uid/guid
translation.
So just a quick check to avoid the most basic problems should be ok. And
I don't really see a need to check for \t and \n too, because nobody
sane uses them in filenames. But ok, that just would be a few chars more
in the regex for find. ;)

I leave that up to you.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: please fix FUSION (Was: [v3.13][v3.14][Regression] kthread:makekthread_create()killable)

[James Bottomley]

On Fri, 2014-03-21 at 12:32 -0700, Linus Torvalds wrote:
> On Fri, Mar 21, 2014 at 11:34 AM, Oleg Nesterov  wrote:
> >
> > Yes, it seems that it actually needs > 30 secs. It spends most of the time
> > (30.13286 seconds) in [..]
> 
> So how about taking a completely different approach:
> 
>  - just say that waiting for devices in the module init sequence for
> over 30 seconds is really really wrong.
> 
>  - make the damn mptsas driver just register the controller from the
> init sequence, and then do device discovery asynchronously.
> 
> The ATA layer does this correctly: it synchronously finds each host,
> but then it does
> 
> /* perform each probe asynchronously */
> for (i = 0; i < host->n_ports; i++) {
> struct ata_port *ap = host->ports[i];
> async_schedule(async_port_probe, ap);
> }
> 
> and I really think SCSI drivers should do the same if they have this
> kind of "ports can take forever to probe" behavior.
> 
> What would be the equivalent magic to do this for SCSI? Could we just
> make something like scsi_probe_and_add_lun() just always do this, the
> same way ata_host_register() does it?

Well, we do do this asynchronously.  The idea is that the add host only
initialises the actual hardware.  The port probing is supposed to be
done asynchronously (provided the async probe option is enabled in SCSI,
of course).  The way this is supposed to happen is the driver
initialises the hardware and then calls scsi_scan_host().  If the
platform is set up for async scanning, that kicks off all the async
workqueues and returns (or does it all synchronously if async scanning
isn't enabled).

It is possible fusion gets this wrong because the sas driver doesn't
really couple to SCSI's libsas, which is where it would pick up most of
the generic infrastructure for this.  Plus it depends where all the time
is being wasted.  The fusion was the last sas chipset I got the specs
for (under NDA).  It's actually table driven, so if the problem is the
controller taking ages to fill in the tables it might necessitate a
fusion specific fix.  I can see from the driver that it seems to do all
the probing itself instead of relying on probe callbacks from
scsi_scan_host(), so I know what needs to be fixed ... it's less clear
how easy this would be given how monolithic the routine looks.

James


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] initramfs: print error and shell out for unsupported content

[Andrew Morton]

On Fri, 21 Mar 2014 23:49:57 +0100 Alexander Holler  
wrote:

> Am 21.03.2014 22:03, schrieb Andrew Morton:
> > On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler  
> > wrote:
> > 
> >> The initramfs generation is broken for file and directory names which 
> >> contain
> >> colons or spaces. Print an error and don't try to continue.
> 
> > It would be better to fix the it-doesnt-work-with-all-filenames bug. 
> > Any details on that?
> 
> IMHO not worth the time. The whole process which is curently used is
> extremly fragile.
> 
> E.g it's almost guaranteed to fail trying to include arbitrary filenames
> as dependencies in a Makefile. Besides the one problem I've discoverd
> with colons, there could be much more things happen, e.g. with filenames
> which do include other special Makefile characters you all would have to
> escape correctly.
> 
> And the problem with spaces isn't as easy to fix as it first does look
> like. I think it might be easier to write the whole stuff new instead of
> trying to escape the spaces in various ways needed to end up correctly
> in the cpio (it first goes through shell code and is then feeded as some
> list to a C program).
> 
> And I think that just isn't worth the time. Using find | cpio works just
> fine to generate a cpio archive and usually an initramfs just contains
> some megabytes. So it isn't a problem at all to rebuild the complete
> cpio archive with every call of make, it doesn't need much more than
> about a second or similiar on almost any machine.
> 
> And for the records, I indeed had a deeper look, trying to fix it. But,
> as said, quickly realized that it will need too much effort and doesn't
> make sense, if it will be doable correctly at all.
> 

huh, OK.

Should we check for \t and \n as well?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/3] mm/swap: support per memory cgroup swapfiles

[Yu Zhao]

From: Suleiman Souhlal 

This patch adds support for per memory cgroup swap file. The swap file
is marked private in swapon() with a new flag SWAP_FLAG_PRIVATE becasue
only the memory cgroup (and its children) that owns it can use it (in
the case of the children that don't own any swap files, they go up the
hierarchy until someone who has swap file set up is found).

The path of the swap file is set by writing to memory.swapfile. Details
of the API can be found in Documentation/cgroups/memory.txt.

Signed-off-by: Suleiman Souhlal 
Signed-off-by: Yu Zhao 
---
 Documentation/cgroups/memory.txt |  15 +++
 include/linux/memcontrol.h   |   2 +
 include/linux/swap.h |  38 +++---
 mm/memcontrol.c  |  76 
 mm/memory.c  |   3 +-
 mm/shmem.c   |   2 +-
 mm/swap_state.c  |   2 +-
 mm/swapfile.c| 241 ++-
 mm/vmscan.c  |   2 +-
 9 files changed, 331 insertions(+), 50 deletions(-)

diff --git a/Documentation/cgroups/memory.txt b/Documentation/cgroups/memory.txt
index 2622115..48a98ad 100644
--- a/Documentation/cgroups/memory.txt
+++ b/Documentation/cgroups/memory.txt
@@ -72,6 +72,7 @@ Brief summary of control files.
  memory.move_charge_at_immigrate # set/show controls of moving charges
  memory.oom_control # set/show oom controls.
  memory.numa_stat   # show the number of memory usage per numa node
+ memory.swapfile# set/show swap file
 
  memory.kmem.limit_in_bytes  # set/show hard limit for kernel memory
  memory.kmem.usage_in_bytes  # show current kernel memory allocation
@@ -342,6 +343,20 @@ set:
 admin a unified view of memory, and it is also useful for people who just
 want to track kernel memory usage.
 
+2.8 Private swap files
+
+It's possible to configure a cgroup to swap to a particular file by using
+memory.swapfile.
+
+A value of "default" in memory.swapfile indicates that this cgroup should
+use the default, system-wide, swap files. A value of "none" indicates that
+this cgroup should never swap. Other values are interpreted as the path
+to a private swap file.
+
+The swap file has to be created and swapon() has to be done on it with
+SWAP_FLAG_PRIVATE, before it can be used. This flag ensures that the swap
+file is private and does not get used by others.
+
 3. User Interface
 
 0. Configuration
diff --git a/include/linux/memcontrol.h b/include/linux/memcontrol.h
index abd0113..ec4879b 100644
--- a/include/linux/memcontrol.h
+++ b/include/linux/memcontrol.h
@@ -155,6 +155,8 @@ static inline bool task_in_memcg_oom(struct task_struct *p)
 }
 
 bool mem_cgroup_oom_synchronize(bool wait);
+int mem_cgroup_get_page_swap_type(struct page *page);
+void mem_cgroup_remove_swapfile(int type);
 
 #ifdef CONFIG_MEMCG_SWAP
 extern int do_swap_account;
diff --git a/include/linux/swap.h b/include/linux/swap.h
index 46ba0c6..b6a280e 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -23,10 +23,11 @@ struct bio;
 #define SWAP_FLAG_DISCARD  0x1 /* enable discard for swap */
 #define SWAP_FLAG_DISCARD_ONCE 0x2 /* discard swap area at swapon-time */
 #define SWAP_FLAG_DISCARD_PAGES 0x4 /* discard page-clusters after use */
+#define SWAP_FLAG_PRIVATE 0x100/* set if get_swap_page should 
skip */
 
 #define SWAP_FLAGS_VALID   (SWAP_FLAG_PRIO_MASK | SWAP_FLAG_PREFER | \
 SWAP_FLAG_DISCARD | SWAP_FLAG_DISCARD_ONCE | \
-SWAP_FLAG_DISCARD_PAGES)
+SWAP_FLAG_DISCARD_PAGES | SWAP_FLAG_PRIVATE)
 
 static inline int current_is_kswapd(void)
 {
@@ -158,8 +159,14 @@ enum {
SWP_FILE= (1 << 7), /* set after swap_activate success */
SWP_AREA_DISCARD = (1 << 8),/* single-time swap area discards */
SWP_PAGE_DISCARD = (1 << 9),/* freed swap page-cluster discards */
+   SWP_PRIVATE = (1 << 10),/* not for general use */
/* add others here before... */
-   SWP_SCANNING= (1 << 10),/* refcount in scan_swap_map */
+   SWP_SCANNING= (1 << 11),/* refcount in scan_swap_map */
+};
+
+enum {
+   SWAP_TYPE_DEFAULT = -1, /* use default/global/system swap file */
+   SWAP_TYPE_NONE = -2,/* swap is disabled */
 };
 
 #define SWAP_CLUSTER_MAX 32UL
@@ -401,22 +408,19 @@ extern struct page *swapin_readahead(swp_entry_t, gfp_t,
struct vm_area_struct *vma, unsigned long addr);
 
 /* linux/mm/swapfile.c */
-extern atomic_long_t nr_swap_pages;
-extern long total_swap_pages;
-
-/* Swap 50% full? Release swapcache more aggressively.. */
-static inline bool vm_swap_full(void)
-{
-   return atomic_long_read(_swap_pages) * 2 < total_swap_pages;
-}
-
+extern bool vm_swap_full(struct page *page);
+extern atomic_long_t nr_public_swap_pages, 

[PATCH 3/3] swap: Increase the maximum number of swap files to 8192.

[Yu Zhao]

From: Suleiman Souhlal 

Allow up to 8192 swap files on x86_64. Prior to this patch the limit was
30 swap files, which is not enough if we want to use per memory cgroup
swap files on a machine that has thousands of cgroups.

While this change also reduces the number of bits available for swap
offsets in the PTE, it does not actually impose any new restrictions on
the maximum size of swap files, as that is currently limited by the use
of 32bit values in other parts of the swap code.

Signed-off-by: Suleiman Souhlal 
Signed-off-by: Yu Zhao 
---
 arch/x86/include/asm/pgtable_64.h | 63 ++-
 include/linux/swap.h  |  7 +++--
 2 files changed, 54 insertions(+), 16 deletions(-)

diff --git a/arch/x86/include/asm/pgtable_64.h 
b/arch/x86/include/asm/pgtable_64.h
index e22c1db..53a234f 100644
--- a/arch/x86/include/asm/pgtable_64.h
+++ b/arch/x86/include/asm/pgtable_64.h
@@ -142,23 +142,58 @@ static inline int pgd_large(pgd_t pgd) { return 0; }
 #define pte_offset_map(dir, address) pte_offset_kernel((dir), (address))
 #define pte_unmap(pte) ((void)(pte))/* NOP */
 
-/* Encode and de-code a swap entry */
-#if _PAGE_BIT_FILE < _PAGE_BIT_PROTNONE
-#define SWP_TYPE_BITS (_PAGE_BIT_FILE - _PAGE_BIT_PRESENT - 1)
-#define SWP_OFFSET_SHIFT (_PAGE_BIT_PROTNONE + 1)
-#else
-#define SWP_TYPE_BITS (_PAGE_BIT_PROTNONE - _PAGE_BIT_PRESENT - 1)
-#define SWP_OFFSET_SHIFT (_PAGE_BIT_FILE + 1)
-#endif
+/*
+ * Encode and de-code a swap entry
+ * We need to make sure we don't touch the PAGE_PRESENT, PAGE_FILE
+ * and PAGE_CANREAD bits.
+ * All bit ranges below are inclusive.
+ *
+ * Bits 1-5 and 12-19 of the PTE are the type, while bits 20-63 are the offset.
+ *
+ * This enables us to have 8192 different swap types and 44 bit offsets.
+ */
+#define SWP_TYPE_BITS  13
+#define SWP_OFFSET_SHIFT 20
 
 #define MAX_SWAPFILES_CHECK() BUILD_BUG_ON(MAX_SWAPFILES_SHIFT > SWP_TYPE_BITS)
 
-#define __swp_type(x)  (((x).val >> (_PAGE_BIT_PRESENT + 1)) \
-& ((1U << SWP_TYPE_BITS) - 1))
-#define __swp_offset(x)((x).val >> SWP_OFFSET_SHIFT)
-#define __swp_entry(type, offset)  ((swp_entry_t) { \
-((type) << (_PAGE_BIT_PRESENT + 1)) \
-| ((offset) << SWP_OFFSET_SHIFT) })
+#define __HAVE_ARCH_MAX_SWAPFILES_SHIFT
+#define MAX_SWAPFILES_SHIFT13
+
+static inline unsigned long
+___swp_type(unsigned long val)
+{
+   unsigned long type;
+
+   /* Bits 1-5 */
+   type = (val >> 1) & 0x1f;
+   /* Bits 12-19 */
+   type |= (val >> 7) & 0x1fe0;
+
+   return type;
+}
+
+#define __swp_type(x)  (___swp_type((x).val))
+#define __swp_offset(x)((x).val >> SWP_OFFSET_SHIFT)
+
+static inline unsigned long
+___swp_entry(unsigned long type, pgoff_t off)
+{
+   unsigned long e;
+
+   /* Bits 0-4 of type to bits 1-5 of entry */
+   e = (type & 0x1f) << 1;
+   /* Bits 5-12 of type to bits 12-19 of entry */
+   e |= (type & 0x1fe0) << 7;
+   /* off to bits 20-63 */
+   e |= off << SWP_OFFSET_SHIFT;
+
+   return e;
+}
+
+#define __swp_entry(type, offset)  \
+   ((swp_entry_t) { ___swp_entry(type, offset) })
+
 #define __pte_to_swp_entry(pte)((swp_entry_t) { pte_val((pte)) 
})
 #define __swp_entry_to_pte(x)  ((pte_t) { .pte = (x).val })
 
diff --git a/include/linux/swap.h b/include/linux/swap.h
index b6a280e..5e500f8 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -12,6 +12,7 @@
 #include 
 #include 
 #include 
+#include 
 
 struct notifier_block;
 
@@ -42,7 +43,9 @@ static inline int current_is_kswapd(void)
  * on 32-bit-pgoff_t architectures.  And that assumes that the architecture 
packs
  * the type/offset into the pte as 5/27 as well.
  */
+#ifndef __HAVE_ARCH_MAX_SWAPFILES_SHIFT
 #define MAX_SWAPFILES_SHIFT5
+#endif
 
 /*
  * Use some of the swap files numbers for other purposes. This
@@ -221,8 +224,8 @@ struct percpu_cluster {
 struct swap_info_struct {
unsigned long   flags;  /* SWP_USED etc: see above */
signed shortprio;   /* swap priority of this type */
-   signed char type;   /* strange name for an index */
-   signed char next;   /* next type on the swap list */
+   int type;   /* strange name for an index */
+   int next;   /* next type on the swap list */
unsigned intmax;/* extent of the swap_map */
unsigned char *swap_map;/* vmalloc'ed array of usage counts */
struct swap_cluster_info *cluster_info; /* cluster info. Only for SSD */
-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  

Re: [PATCH v2] initramfs: print error and shell out for unsupported content

[Alexander Holler]

Am 21.03.2014 22:03, schrieb Andrew Morton:
> On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler  
> wrote:
> 
>> The initramfs generation is broken for file and directory names which contain
>> colons or spaces. Print an error and don't try to continue.

> It would be better to fix the it-doesnt-work-with-all-filenames bug. 
> Any details on that?

IMHO not worth the time. The whole process which is curently used is
extremly fragile.

E.g it's almost guaranteed to fail trying to include arbitrary filenames
as dependencies in a Makefile. Besides the one problem I've discoverd
with colons, there could be much more things happen, e.g. with filenames
which do include other special Makefile characters you all would have to
escape correctly.

And the problem with spaces isn't as easy to fix as it first does look
like. I think it might be easier to write the whole stuff new instead of
trying to escape the spaces in various ways needed to end up correctly
in the cpio (it first goes through shell code and is then feeded as some
list to a C program).

And I think that just isn't worth the time. Using find | cpio works just
fine to generate a cpio archive and usually an initramfs just contains
some megabytes. So it isn't a problem at all to rebuild the complete
cpio archive with every call of make, it doesn't need much more than
about a second or similiar on almost any machine.

And for the records, I indeed had a deeper look, trying to fix it. But,
as said, quickly realized that it will need too much effort and doesn't
make sense, if it will be doable correctly at all.

Regards,

Alexander Holler
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/3] Per cgroup swap file support

[Yu Zhao]

This series of patches adds support to configure a cgroup to swap to a
particular file by using control file memory.swapfile.

A value of "default" in memory.swapfile indicates that this cgroup should
use the default, system-wide, swap files. A value of "none" indicates that
this cgroup should never swap. Other values are interpreted as the path
to a private swap file that can only be used by the owner (and its children).

The swap file has to be created and swapon() has to be done on it with
SWAP_FLAG_PRIVATE, before it can be used. This flag ensures that the swap
file is private and does not get used by others.

Jamie Liu (1):
  swap: do not store private swap files on swap_list

Suleiman Souhlal (2):
  mm/swap: support per memory cgroup swapfiles
  swap: Increase the maximum number of swap files to 8192.

 Documentation/cgroups/memory.txt  |  15 ++
 arch/x86/include/asm/pgtable_64.h |  63 ++--
 include/linux/memcontrol.h|   2 +
 include/linux/swap.h  |  45 +++---
 mm/memcontrol.c   |  76 ++
 mm/memory.c   |   3 +-
 mm/shmem.c|   2 +-
 mm/swap_state.c   |   2 +-
 mm/swapfile.c | 307 +++---
 mm/vmscan.c   |   2 +-
 10 files changed, 423 insertions(+), 94 deletions(-)

-- 
1.9.1.423.g4596e3a

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/3] swap: do not store private swap files on swap_list

[Yu Zhao]

From: Jamie Liu 

swap_list is used by get_swap_page() to find public swap files to swap
to; in the case that there are many private swap files and few public
swap files, get_swap_page() may waste time iterating through private
swap files it can't swap to. Change _enable_swap_info() to not insert
private swap files onto swap_list; this improves the performance of
get_swap_page() in such cases, at the cost of making
swap_store_swap_device() and swapoff() minutely slower (both of which
are non-critical).

Signed-off-by: Jamie Liu 
Signed-off-by: Yu Zhao 
---
 mm/swapfile.c | 84 +--
 1 file changed, 47 insertions(+), 37 deletions(-)

diff --git a/mm/swapfile.c b/mm/swapfile.c
index 18a8eee..27e147b 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -712,14 +712,14 @@ int swap_store_swap_device(const char *buf, int *_type)
 
mapping = victim->f_mapping;
spin_lock(_lock);
-   for (type = swap_list.head; type >= 0; type = swap_info[type]->next) {
+   for (type = 0; type < nr_swapfiles; type++) {
si = swap_info[type];
if ((si->flags & SWP_WRITEOK) == SWP_WRITEOK) {
if (si->swap_file->f_mapping == mapping)
break;
}
}
-   if (type < 0) {
+   if (type == nr_swapfiles) {
err = -EINVAL;
} else {
err = 0;
@@ -803,10 +803,7 @@ swp_entry_t get_swap_page(struct page *page)
spin_unlock(>lock);
continue;
}
-   if (si->flags & SWP_PRIVATE) {
-   spin_unlock(>lock);
-   continue;
-   }
+   BUG_ON(si->flags & SWP_PRIVATE);
 
swap_list.next = next;
 
@@ -957,11 +954,12 @@ static unsigned char swap_entry_free(struct 
swap_info_struct *p,
p->lowest_bit = offset;
if (offset > p->highest_bit)
p->highest_bit = offset;
-   set_highest_priority_index(p->type);
if (p->flags & SWP_PRIVATE)
atomic_long_inc(_private_swap_pages);
-   else
+   else {
atomic_long_inc(_public_swap_pages);
+   set_highest_priority_index(p->type);
+   }
p->inuse_pages--;
frontswap_invalidate_page(p->type, offset);
if (p->flags & SWP_BLKDEV) {
@@ -1899,6 +1897,8 @@ static void _enable_swap_info(struct swap_info_struct *p, 
int prio,
 
if (prio >= 0)
p->prio = prio;
+   else if (p->flags & SWP_PRIVATE)
+   p->prio = 0;
else
p->prio = --least_priority;
p->swap_map = swap_map;
@@ -1910,19 +1910,19 @@ static void _enable_swap_info(struct swap_info_struct 
*p, int prio,
} else {
atomic_long_add(p->pages, _public_swap_pages);
total_public_swap_pages += p->pages;
+   /* insert swap space into swap_list: */
+   prev = -1;
+   for (i = swap_list.head; i >= 0; i = swap_info[i]->next) {
+   if (p->prio >= swap_info[i]->prio)
+   break;
+   prev = i;
+   }
+   p->next = i;
+   if (prev < 0)
+   swap_list.head = swap_list.next = p->type;
+   else
+   swap_info[prev]->next = p->type;
}
-   /* insert swap space into swap_list: */
-   prev = -1;
-   for (i = swap_list.head; i >= 0; i = swap_info[i]->next) {
-   if (p->prio >= swap_info[i]->prio)
-   break;
-   prev = i;
-   }
-   p->next = i;
-   if (prev < 0)
-   swap_list.head = swap_list.next = p->type;
-   else
-   swap_info[prev]->next = p->type;
 }
 
 static void enable_swap_info(struct swap_info_struct *p, int prio,
@@ -1978,15 +1978,25 @@ SYSCALL_DEFINE1(swapoff, const char __user *, 
specialfile)
mapping = victim->f_mapping;
prev = -1;
spin_lock(_lock);
-   for (type = swap_list.head; type >= 0; type = swap_info[type]->next) {
+   for (type = 0; type < nr_swapfiles; type++) {
p = swap_info[type];
if (p->flags & SWP_WRITEOK) {
-   if (p->swap_file->f_mapping == mapping)
+   if (p->swap_file->f_mapping == mapping) {
+   /* Private swapfiles aren't in swap_list */
+   if (p->flags & SWP_PRIVATE)
+   break;
+   /* Find type's predecessor in swap_list */
+   for (i = swap_list.head; i >= 0;
+i = 

Re: [PATCH resend] serial_core: Fix pm imbalance on unbind

[Peter Hurley]

Hi Geert,

On 03/21/2014 09:23 AM, Geert Uytterhoeven wrote:

Hi Peter,

On Fri, Mar 21, 2014 at 2:06 PM, Peter Hurley  wrote:

@@ -2681,10 +2683,12 @@ int uart_remove_one_port(struct uart_driver *drv,
struct uart_port *uport)
 }

 /*
-* If the port is used as a console, unregister it
+* If the port is used as a console, unregister it, and power it
down
  */
-   if (uart_console(uport))
+   if (uart_console(uport)) {
 unregister_console(uport->cons);
+   uart_change_pm(state, UART_PM_STATE_OFF);


Won't this power off the port while tty consoles may still be open?


I didn't see that actually happening.


Ok, but I still think this isn't right. See below.


I think the right thing here is to unregister_console then set uport->cons =
NULL

[uport->cons is properly reassigned when/if a port is re-added via
uart_add_one_port()).]


But indeed, for concistency/symmetry uport->state and uport->cons
should be resend, but that's something separate.


I don't see this as being a "looks good" problem; I see this as being
"what's the right way to teardown a uart device that's going away when
a tty console is running on it", and there are too many problems with
uart_remove_one_port() doing:

 state->uart_port = NULL

to keep with that solution.


Then, uart_close() will power off the port when all ttys using the port have
been closed.


uart_close() won't get that far, so uart_change_pm() won't be called.


And this is the central problem: uart_close() must complete normally
if a tty console is still running on a device.

For example, if uart_shutdown() isn't getting called, then who's freeing
the ring buffer page?



See also https://lkml.org/lkml/2014/3/10/651, and my workaround for the
crash https://lkml.org/lkml/2014/3/17/231.


See my comments to the v2 patch there.

Regards,
Peter Hurley
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: numa: Recheck for transhuge pages under lock during protection changes

[Sasha Levin]

On 03/21/2014 06:06 PM, Andrew Morton wrote:

On Wed, 19 Mar 2014 14:38:32 + Mel Gorman  wrote:


>On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:

> >On 03/12/2014 06:36 AM, Mel Gorman wrote:

> > >Andrew, this should go with the patches
> > >mmnuma-reorganize-change_pmd_range.patch
> > >mmnuma-reorganize-change_pmd_range-fix.patch
> > >move-mmu-notifier-call-from-change_protection-to-change_pmd_range.patch
> > >in mmotm please.
> > >
> > >Thanks.
> > >
> > >---8<---
> > >From: Mel Gorman
> > >Subject: [PATCH] mm: numa: Recheck for transhuge pages under lock during 
protection changes
> > >
> > >Sasha Levin reported the following bug using trinity

> >
> >I'm seeing a different issue with this patch. A NULL ptr deref occurs in the
> >pte_offset_map_lock() macro right before the new recheck code:
> >

>
>This on top?
>
>I tried testing it but got all sorts of carnage that trinity throw up
>in the mix and ordinary testing does not trigger the race. I've no idea
>which of the current mess of trinity-exposed bugs you've encountered and
>got fixed already.
>

Where are we at with this one?


Looking good here, haven't seen any of the issues reported in this thread.


Thanks,
Sasha
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] clk: berlin: add support for berlin plls

[Sebastian Hesselbarth]

On 03/21/2014 11:22 PM, Alexandre Belloni wrote:

On 21/03/2014 at 22:22:33 +0100, Sebastian Hesselbarth wrote :

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

This drivers allows to provide DT clocks for the cpu and system PLLs found on
Marvell Berlin SoCs.


Alexandre,

as mentioned on IRC, I now had a closer look on it. Some minor
remarks below. Sorry, I didn't mention them earlier.


To clarify things, I'll just resend patch 1 and you are ready to take
2-5, fixing up the remaining comments as soon as Mike takes it ?


Yes, no need to resend 2-5. Just keep on incrementing version on 1/5.
If you send a v3 for patch 1, I can also prepare a topic branch that
we refer to until Mike either takes the single patch or pulls the topic
branch.

I'll work it out with Mike, but for a single patch, I guess he'll
take it through his tree.

As we target this all for v3.16, I'll get back to this, as soon as I
have proper branches on v3.15-rc1 and possibly also managed it to have
a for-next branch that gets pulled into linux-next.

Sebastian

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: numa: Recheck for transhuge pages under lock during protection changes

[Rik van Riel]

On 03/19/2014 10:38 AM, Mel Gorman wrote:
> On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:
>> On 03/12/2014 06:36 AM, Mel Gorman wrote:
>>> Andrew, this should go with the patches
>>> mmnuma-reorganize-change_pmd_range.patch
>>> mmnuma-reorganize-change_pmd_range-fix.patch
>>> move-mmu-notifier-call-from-change_protection-to-change_pmd_range.patch
>>> in mmotm please.
>>>
>>> Thanks.
>>>
>>> ---8<---
>>> From: Mel Gorman
>>> Subject: [PATCH] mm: numa: Recheck for transhuge pages under lock during 
>>> protection changes
>>>
>>> Sasha Levin reported the following bug using trinity
>>
>> I'm seeing a different issue with this patch. A NULL ptr deref occurs in the
>> pte_offset_map_lock() macro right before the new recheck code:
>>
> 
> This on top?
> 
> I tried testing it but got all sorts of carnage that trinity throw up
> in the mix and ordinary testing does not trigger the race. I've no idea
> which of the current mess of trinity-exposed bugs you've encountered and
> got fixed already.

Eeeep indeed.  If we re-test the transhuge status, we need to
take the pmd lock, and not the potentially non-existent pte
lock.

Good catch.

> ---8<---
> From: Mel Gorman 
> Subject: [PATCH] mm: numa: Recheck for transhuge pages under lock during 
> protection changes -fix
> 
> Signed-off-by: Mel Gorman 

Reviewed-by: Rik van Riel 

> ---
>  mm/mprotect.c | 40 ++--
>  1 file changed, 30 insertions(+), 10 deletions(-)
> 
> diff --git a/mm/mprotect.c b/mm/mprotect.c
> index 66973db..c43d557 100644
> --- a/mm/mprotect.c
> +++ b/mm/mprotect.c
> @@ -36,6 +36,34 @@ static inline pgprot_t pgprot_modify(pgprot_t oldprot, 
> pgprot_t newprot)
>  }
>  #endif
>  
> +/*
> + * For a prot_numa update we only hold mmap_sem for read so there is a
> + * potential race with faulting where a pmd was temporarily none. This
> + * function checks for a transhuge pmd under the appropriate lock. It
> + * returns a pte if it was successfully locked or NULL if it raced with
> + * a transhuge insertion.
> + */
> +static pte_t *lock_pte_protection(struct vm_area_struct *vma, pmd_t *pmd,
> + unsigned long addr, int prot_numa, spinlock_t **ptl)
> +{
> + pte_t *pte;
> + spinlock_t *pmdl;
> +
> + /* !prot_numa is protected by mmap_sem held for write */
> + if (!prot_numa)
> + return pte_offset_map_lock(vma->vm_mm, pmd, addr, ptl);
> +
> + pmdl = pmd_lock(vma->vm_mm, pmd);
> + if (unlikely(pmd_trans_huge(*pmd) || pmd_none(*pmd))) {
> + spin_unlock(pmdl);
> + return NULL;
> + }
> +
> + pte = pte_offset_map_lock(vma->vm_mm, pmd, addr, ptl);
> + spin_unlock(pmdl);
> + return pte;
> +}
> +
>  static unsigned long change_pte_range(struct vm_area_struct *vma, pmd_t *pmd,
>   unsigned long addr, unsigned long end, pgprot_t newprot,
>   int dirty_accountable, int prot_numa)
> @@ -45,17 +73,9 @@ static unsigned long change_pte_range(struct 
> vm_area_struct *vma, pmd_t *pmd,
>   spinlock_t *ptl;
>   unsigned long pages = 0;
>  
> - pte = pte_offset_map_lock(mm, pmd, addr, );
> -
> - /*
> -  * For a prot_numa update we only hold mmap_sem for read so there is a
> -  * potential race with faulting where a pmd was temporarily none so
> -  * recheck it under the lock and bail if we race
> -  */
> - if (prot_numa && unlikely(pmd_trans_huge(*pmd))) {
> - pte_unmap_unlock(pte, ptl);
> + pte = lock_pte_protection(vma, pmd, addr, prot_numa, );
> + if (!pte)
>   return 0;
> - }
>  
>   arch_enter_lazy_mmu_mode();
>   do {
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 
> 


-- 
All rights reversed
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] clk: berlin: add support for berlin plls

[Alexandre Belloni]

On 21/03/2014 at 22:22:33 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >This drivers allows to provide DT clocks for the cpu and system PLLs found on
> >Marvell Berlin SoCs.
> 
> Alexandre,
> 
> as mentioned on IRC, I now had a closer look on it. Some minor
> remarks below. Sorry, I didn't mention them earlier.
> 

To clarify things, I'll just resend patch 1 and you are ready to take
2-5, fixing up the remaining comments as soon as Mike takes it ?


-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH V2] fix some coding style in drivers/staging/iio, and a break missing.

[Jonathan Cameron]

Please separate the missing break fix into its own patch.  That will want to go 
in as a fix. The tree it will go through is therefore different from the rest 
of this patch which
 can take a slower path into the kernel tree.

Jonathan

On March 21, 2014 12:45:51 PM GMT+00:00, Jimmy Li  wrote:
>Signed-off-by: Jimmy Li
>---
> drivers/staging/iio/accel/sca3000_core.c |3 ++-
> drivers/staging/iio/adc/ad7192.c |3 ++-
> drivers/staging/iio/adc/ad7606_core.c|2 +-
> drivers/staging/iio/adc/ad7816.c |6 +++---
> drivers/staging/iio/adc/mxs-lradc.c  |6 --
> drivers/staging/iio/addac/adt7316.c  |3 +--
>drivers/staging/iio/frequency/ad5930.c   |   23 +++
> drivers/staging/iio/frequency/ad9850.c   |2 +-
> drivers/staging/iio/light/isl29018.c |   10 ++
> drivers/staging/iio/light/tsl2583.c  |2 +-
> drivers/staging/iio/light/tsl2x7x_core.c |   12 ++--
> drivers/staging/iio/meter/ade7854-i2c.c  |3 ++-
> drivers/staging/iio/resolver/ad2s1200.c  |1 +
> 13 files changed, 45 insertions(+), 31 deletions(-)
>
>diff --git a/drivers/staging/iio/accel/sca3000_core.c
>b/drivers/staging/iio/accel/sca3000_core.c
>index ed30e32..c099294 100644
>--- a/drivers/staging/iio/accel/sca3000_core.c
>+++ b/drivers/staging/iio/accel/sca3000_core.c
>@@ -506,7 +506,8 @@ static int sca3000_read_raw(struct iio_dev
>*indio_dev,
>   mutex_unlock(>lock);
>   return ret;
>   }
>-  *val = ((st->rx[0] & 0x3F) << 3) | ((st->rx[1] & 0xE0) 
>>> 5);
>+  *val = ((st->rx[0] & 0x3F) << 3) |
>+  ((st->rx[1] & 0xE0) >> 5);
>   }
>   mutex_unlock(>lock);
>   return IIO_VAL_INT;
>diff --git a/drivers/staging/iio/adc/ad7192.c
>b/drivers/staging/iio/adc/ad7192.c
>index 83bb44b..d1f9790 100644
>--- a/drivers/staging/iio/adc/ad7192.c
>+++ b/drivers/staging/iio/adc/ad7192.c
>@@ -223,7 +223,8 @@ static int ad7192_setup(struct ad7192_state *st,
>   id &= AD7192_ID_MASK;
> 
>   if (id != st->devid)
>-  dev_warn(>sd.spi->dev, "device ID query failed (0x%X)\n", 
>id);
>+  dev_warn(>sd.spi->dev,
>+  "device ID query failed (0x%X)\n", id);
> 
>   switch (pdata->clock_source_sel) {
>   case AD7192_CLK_EXT_MCLK1_2:
>diff --git a/drivers/staging/iio/adc/ad7606_core.c
>b/drivers/staging/iio/adc/ad7606_core.c
>index f0f05f1..bf2c801 100644
>--- a/drivers/staging/iio/adc/ad7606_core.c
>+++ b/drivers/staging/iio/adc/ad7606_core.c
>@@ -140,7 +140,7 @@ static ssize_t ad7606_store_range(struct device
>*dev,
>   return count;
> }
> 
>-static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR, \
>+static IIO_DEVICE_ATTR(in_voltage_range, S_IRUGO | S_IWUSR,
>  ad7606_show_range, ad7606_store_range, 0);
> static IIO_CONST_ATTR(in_voltage_range_available, "5000 1");
> 
>diff --git a/drivers/staging/iio/adc/ad7816.c
>b/drivers/staging/iio/adc/ad7816.c
>index 2369cf2..ec86c01 100644
>--- a/drivers/staging/iio/adc/ad7816.c
>+++ b/drivers/staging/iio/adc/ad7816.c
>@@ -153,7 +153,8 @@ static ssize_t ad7816_show_available_modes(struct
>device *dev,
>   return sprintf(buf, "full\npower-save\n");
> }
> 
>-static IIO_DEVICE_ATTR(available_modes, S_IRUGO,
>ad7816_show_available_modes, NULL, 0);
>+static IIO_DEVICE_ATTR(available_modes, S_IRUGO,
>+  ad7816_show_available_modes, NULL, 0);
> 
> static ssize_t ad7816_show_channel(struct device *dev,
>   struct device_attribute *attr,
>@@ -442,6 +443,5 @@ static struct spi_driver ad7816_driver = {
> module_spi_driver(ad7816_driver);
> 
> MODULE_AUTHOR("Sonic Zhang ");
>-MODULE_DESCRIPTION("Analog Devices AD7816/7/8 digital"
>-  " temperature sensor driver");
>+MODULE_DESCRIPTION("Analog Devices AD7816/7/8 digital temperature
>sensor driver");
> MODULE_LICENSE("GPL v2");
>diff --git a/drivers/staging/iio/adc/mxs-lradc.c
>b/drivers/staging/iio/adc/mxs-lradc.c
>index 11fb952..84f7177 100644
>--- a/drivers/staging/iio/adc/mxs-lradc.c
>+++ b/drivers/staging/iio/adc/mxs-lradc.c
>@@ -462,7 +462,8 @@ static void mxs_lradc_setup_ts_channel(struct
>mxs_lradc *lradc, unsigned ch)
>* SoC's delay unit and start the conversion later
>* and automatically.
>*/
>-  mxs_lradc_reg_wrt(lradc, LRADC_DELAY_TRIGGER(0) | /* don't trigger
>ADC */
>+  mxs_lradc_reg_wrt(lradc,
>+  LRADC_DELAY_TRIGGER(0) | /* don't trigger ADC */
>   LRADC_DELAY_TRIGGER_DELAYS(1 << 3) | /* trigger DELAY unit#3 */
>   LRADC_DELAY_KICK |
>   LRADC_DELAY_DELAY(lradc->settling_delay),
>@@ -520,7 +521,8 @@ static void mxs_lradc_setup_ts_pressure(struct
>mxs_lradc *lradc, unsigned ch1,
>* SoC's delay unit and start the conversion later
>* and automatically.
>*/
>-  

[PATCH] NFC: pn533: Fix device leak

[Alexey Khoroshilov]

pn533_probe() calls usb_get_dev(), but there is no usb_put_dev()
in pn533_disconnect(). The patch adds one.

Found by Linux Driver Verification project (linuxtesting.org).

Signed-off-by: Alexey Khoroshilov 
---
 drivers/nfc/pn533.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/nfc/pn533.c b/drivers/nfc/pn533.c
index cf1a87bb74f8..fed19d5473bb 100644
--- a/drivers/nfc/pn533.c
+++ b/drivers/nfc/pn533.c
@@ -3301,6 +3301,7 @@ static void pn533_disconnect(struct usb_interface 
*interface)
 
usb_free_urb(dev->in_urb);
usb_free_urb(dev->out_urb);
+   usb_put_dev(dev->udev);
kfree(dev);
 
nfc_info(>dev, "NXP PN533 NFC device disconnected\n");
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] clk: berlin: add berlin clocks DT bindings documentation

[Alexandre Belloni]

On 21/03/2014 at 22:31:09 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >Document the device tree bindings for the PLLs found on the Marvell Berlin 
> >SoCs.
> >
> >Cc: devicet...@vger.kernel.org
> 
> You forgot to add Mark Rutland's Reviewed-by. He didn't mentioned it
> explicitly but his "Otherwise this looks fine to me" on v1, is as good
> as a Reviewed-by. But, no need to resend, I'll fix it up.
> 

Ok, I would have preferred an explicit one ;)

> Also, everything above the '---' will be part of your commit log. While
> the Signed-off-by and Reviewed-by should be in there, Cc's really don't
> need to.
> 

Ok, it seemed common practice to put it in the commit log:

$ git log | grep "Cc:" | wc -l
157126

But I'll do as you suggest from now. Actually, I didn't know you could
do like that.

> You can add another '---' to separate commit message and some stuff
> you want to have early in you email with:
> 
> Blablabla commit message.
> 
> Signed-off-by: ...
> Reviewed-by: ...
> ---
> Changelog:
> - blabla
> 
> Cc: cc-me-recipient
> ...
> ---
>.../devicetree/bindings/clock/berlin-clock.txt | 29
> ++
>1 file changed, 29 insertions(+)
>create mode 100644
> Documentation/devicetree/bindings/clock/berlin-clock.txt
> 
>  diff --git
> a/Documentation/devicetree/bindings/clock/berlin-clock.txt
> b/Documentation/devicetree/bindings/clock/berlin-clock.txt
> ...
> 
> >Signed-off-by: Alexandre Belloni 
> >---
> >  .../devicetree/bindings/clock/berlin-clock.txt | 29 
> > ++
> >  1 file changed, 29 insertions(+)
> >  create mode 100644 Documentation/devicetree/bindings/clock/berlin-clock.txt
> >
> >diff --git a/Documentation/devicetree/bindings/clock/berlin-clock.txt 
> >b/Documentation/devicetree/bindings/clock/berlin-clock.txt
> >new file mode 100644
> >index ..49b7860bffb8
> >--- /dev/null
> >+++ b/Documentation/devicetree/bindings/clock/berlin-clock.txt
> >@@ -0,0 +1,29 @@
> >+Device Tree Clock bindings for Marvell Berlin clocks
> >+
> >+This binding uses the common clock binding[1].
> >+
> >+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
> >+
> >+Required properties:
> >+- compatible: shall be one of the following:
> >+"marvell,berlin2-pll",
> >+"marvell,berlin2q-pll":
> >+CPU PLL and System PLL
> >+- reg: Address and length of the clock register set.
> >+- #clock-cells: from common clock binding; shall be set to 0.
> >+- clocks: from common clock binding
> >+
> >+smclk: sysmgr-clock {
> >+compatible = "fixed-clock";
> >+#clock-cells = <0>;
> >+clock-frequency = <2500>;
> >+};
> >+
> >+cpupll: cpupll@ea003c {
> >+compatible = "marvell,berlin2-pll";
> >+clocks = <>;
> >+#clock-cells = <0>;
> >+reg = <0xea003c 0x8>;
> >+};
> >+
> >+
> >
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: socfpga: add gpio pieces

[delicious quinoa]

On Fri, Mar 21, 2014 at 1:14 PM, delicious quinoa
 wrote:
> On Thu, Mar 20, 2014 at 2:55 PM, Sebastian Andrzej Siewior
>  wrote:
>> The cycloneV has three gpio controllers, each one with 29 gpios. This patch
>> adds the three controller with the gpio driver which is now sitting the
>> gpio tree.
>>
>> Cc: devicet...@vger.kernel.org
>> Signed-off-by: Sebastian Andrzej Siewior 
>> ---
>>  arch/arm/boot/dts/socfpga.dtsi | 60 
>> ++
>>  1 file changed, 60 insertions(+)
>>
>> diff --git a/arch/arm/boot/dts/socfpga.dtsi b/arch/arm/boot/dts/socfpga.dtsi
>> index 537f1a5..c3a97e1 100644
>> --- a/arch/arm/boot/dts/socfpga.dtsi
>> +++ b/arch/arm/boot/dts/socfpga.dtsi
>> @@ -463,6 +463,66 @@
>> status = "disabled";
>> };
>>
>> +   gpio@ff708000 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   compatible = "snps,dw-apb-gpio";
>> +   reg = <0xff708000 0x1000>;
>> +   clocks = <_base_clk>;
>> +   status = "disabled";
>> +
>> +   gpio0: gpio-controller@0 {
>> +   compatible = "snps,dw-apb-gpio-port";
>> +   gpio-controller;
>> +   #gpio-cells = <1>;
>
> #gpio-cells = <2>;
>
> I applied this patch, fixed the gpio-cells, tested on a cyclone5 soc
> devkit, and see that it breaks the interrupts.  Did you test this?
>
> Alan
>
>> +   snps,nr-gpios = <29>;
>> +   reg = <0>;
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   interrupts = <0 164 4>;
>> +   };
>> +   };
>> +
>> +   gpio@ff709000 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   compatible = "snps,dw-apb-gpio";
>> +   reg = <0xff709000 0x1000>;
>> +   clocks = <_base_clk>;
>> +   status = "disabled";
>> +
>> +   gpio1: gpio-controller@0 {
>> +   compatible = "snps,dw-apb-gpio-port";
>> +   gpio-controller;
>> +   #gpio-cells = <1>;
>> +   snps,nr-gpios = <29>;
>> +   reg = <0>;
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   interrupts = <0 165 4>;
>> +   };
>> +   };
>> +
>> +   gpio@ff70a000 {
>> +   #address-cells = <1>;
>> +   #size-cells = <0>;
>> +   compatible = "snps,dw-apb-gpio";
>> +   reg = <0xff70a000 0x1000>;
>> +   clocks = <_base_clk>;
>> +   status = "disabled";
>> +
>> +   gpio2: gpio-controller@0 {
>> +   compatible = "snps,dw-apb-gpio-port";
>> +   gpio-controller;
>> +   #gpio-cells = <1>;
>> +   snps,nr-gpios = <29>;

snps,nr-gpios = <27>;

As noted on other thread, gpio2 is 27 wide, despite what the
documentation says.  When I made that change and remove your other two
patches the gpios worked for me on a cyclone5 devkit board.

So if you fix the "#gpio-cells = <2>;" for all 3 gpios and fix
"snps,nr-gpios = <27>;" for gpio2, then this one patch looks good to
me.  With these changes,

Acked-by: Alan Tull 

Alan Tull
aka
delicous quinoa


>> +   reg = <0>;
>> +   interrupt-controller;
>> +   #interrupt-cells = <2>;
>> +   interrupts = <0 166 4>;
>> +   };
>> +   };
>> +
>> L2: l2-cache@fffef000 {
>> compatible = "arm,pl310-cache";
>> reg = <0xfffef000 0x1000>;
>> --
>> 1.9.1
>>
>> --
>> To unsubscribe from this list: send the line "unsubscribe devicetree" in
>> the body of a message to majord...@vger.kernel.org
>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/5] ARM: berlin/dt: add cpupll and syspll support to BG2CD

[Alexandre Belloni]

On 21/03/2014 at 22:35:26 +0100, Sebastian Hesselbarth wrote :
> On 03/21/2014 09:08 PM, Alexandre Belloni wrote:
> >The Berlin BG2CD has two supported PLLs: CPU PLL and System PLL, add those to
> >the SoC device tree.
> >
> >This also moves the remaining clocks from the clocks container node to the 
> >root.
> >
> >Signed-off-by: Alexandre Belloni 
> >---
> >  arch/arm/boot/dts/berlin2cd.dtsi | 48 
> > ++--
> >  1 file changed, 31 insertions(+), 17 deletions(-)
> >
> >diff --git a/arch/arm/boot/dts/berlin2cd.dtsi 
> >b/arch/arm/boot/dts/berlin2cd.dtsi
> >index 094968c27533..bd4e9dd4867e 100644
> >--- a/arch/arm/boot/dts/berlin2cd.dtsi
> >+++ b/arch/arm/boot/dts/berlin2cd.dtsi
> >@@ -30,24 +30,24 @@
> [...]
> >@@ -76,7 +76,21 @@
> > compatible = "arm,cortex-a9-twd-timer";
> > reg = <0xad0600 0x20>;
> > interrupts = ;
> >-clocks = <>;
> >+clocks = <>;
> >+};
> >+
> >+syspll: syspll@ea0014 {
> >+compatible = "marvell,berlin2-pll";
> >+clocks = <>;
> >+#clock-cells = <0>;
> >+reg = <0xf7ea0014 8>;
> 
> nit: I prefer hex numbers all over for reg properties. berlin2q already
> has them, and I'll fixup this and the one below myself.
> 

Indeed, I did fix that for bg2q and documentation and forgot bg2 and
bg2cd.

> >+};
> >+
> >+cpupll: cpupll@ea003c {
> >+compatible = "marvell,berlin2-pll";
> >+clocks = <>;
> >+#clock-cells = <0>;
> >+reg = <0xf7ea003c 8>;
> 
> ditto.
> 
> Sebastian
> 
> > };
> >
> > apb@e8 {
> >
> 

-- 
Alexandre Belloni, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] mm: numa: Recheck for transhuge pages under lock during protection changes

[Andrew Morton]

On Wed, 19 Mar 2014 14:38:32 + Mel Gorman  wrote:

> On Fri, Mar 14, 2014 at 11:15:37PM -0400, Sasha Levin wrote:
> > On 03/12/2014 06:36 AM, Mel Gorman wrote:
> > >Andrew, this should go with the patches
> > >mmnuma-reorganize-change_pmd_range.patch
> > >mmnuma-reorganize-change_pmd_range-fix.patch
> > >move-mmu-notifier-call-from-change_protection-to-change_pmd_range.patch
> > >in mmotm please.
> > >
> > >Thanks.
> > >
> > >---8<---
> > >From: Mel Gorman
> > >Subject: [PATCH] mm: numa: Recheck for transhuge pages under lock during 
> > >protection changes
> > >
> > >Sasha Levin reported the following bug using trinity
> > 
> > I'm seeing a different issue with this patch. A NULL ptr deref occurs in the
> > pte_offset_map_lock() macro right before the new recheck code:
> > 
> 
> This on top?
> 
> I tried testing it but got all sorts of carnage that trinity throw up
> in the mix and ordinary testing does not trigger the race. I've no idea
> which of the current mess of trinity-exposed bugs you've encountered and
> got fixed already.
> 

Where are we at with this one?


With this patch I'm now sitting on

mmnuma-reorganize-change_pmd_range.patch
mmnuma-reorganize-change_pmd_range-fix.patch
mm-numa-recheck-for-transhuge-pages-under-lock-during-protection-changes.patch
mm-numa-recheck-for-transhuge-pages-under-lock-during-protection-changes-fix.patch
move-mmu-notifier-call-from-change_protection-to-change_pmd_range.patch

Where the first four are prep work for the fifth.

move-mmu-notifier-call-from-change_protection-to-change_pmd_range.patch
is a performance optimisation for KVM guests.  Should I drop all five,
try again next time?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 3/3] ARM: dts: socfpga: add gpio pieces

[delicious quinoa]

On Fri, Mar 21, 2014 at 2:10 PM, Sebastian Andrzej Siewior
 wrote:
> On 03/21/2014 06:24 PM, Gerhard Sittig wrote:
>> On Thu, Mar 20, 2014 at 20:55 +0100, Sebastian Andrzej Siewior wrote:
>>>
>>> The cycloneV has three gpio controllers, each one with 29 gpios. This patch
>>> adds the three controller with the gpio driver which is now sitting the
>>> gpio tree.
>>
>> The third bank should have 27 pins, only the first two have 29.
>
> It is not a bank it is a complete controller. Why 27 pins? The
> reference manual says that there register 0...28.

Hi Sebastian,

The ref manual is wrong.  It is 27.  The last two aren't pinned out.

Alan Tull
aka
delicious quinoa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 03/26] kprobes: Prohibit probing on .entry.text code

[Steven Rostedt]

On Wed, 05 Mar 2014 20:59:04 +0900
Masami Hiramatsu  wrote:


>  struct kprobe_insn_cache {
>   struct mutex mutex;
> diff --git a/kernel/kprobes.c b/kernel/kprobes.c
> index ceeadfc..5b5ac76 100644
> --- a/kernel/kprobes.c
> +++ b/kernel/kprobes.c
> @@ -96,9 +96,6 @@ static raw_spinlock_t *kretprobe_table_lock_ptr(unsigned 
> long hash)
>  static struct kprobe_blackpoint kprobe_blacklist[] = {
>   {"preempt_schedule",},
>   {"native_get_debugreg",},
> - {"irq_entries_start",},
> - {"common_interrupt",},
> - {"mcount",},/* mcount can be called from everywhere */

Is mcount in the entry.text section? Also, what about ftrace_caller and
friends.

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PULL REQUEST for Rafael] PM / devfreq: pull request

[Rafael J. Wysocki]

On Friday, March 21, 2014 11:34:49 AM MyungJoo Ham wrote:
> 
> Dear Rafael,

Hi,
 
> Here goes bugfix devfreq patch.
> 
> Recent patchset of device-tree support / exynos driver updates is omitted in 
> this pull request
> as there could be further updates on the patchset.

OK, pulled, but only because this is a fix.

For new material, please do not send pull requests after -rc6 in the current
cycle.  That is, a pull request with new material for 3.15 should have been
send around 2 weeks ago.


> The following changes since commit dcb99fd9b08cfe1afe426af4d8d3cbc429190f15:
> 
>   Linux 3.14-rc7 (2014-03-16 18:51:24 -0700)
> 
> are available in the git repository at:
> 
>   git://git.kernel.org/pub/scm/linux/kernel/git/mzx/devfreq.git for-rafael
> 
> for you to fetch changes up to e35d35a1c0b3a7317d77e03e686a4a205cdd4eed:
> 
>   PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs 
> (2014-03-21 11:16:30 +0900)
> 
> 
> Pull request for Rafael. Bugfix only.
> (recence changes of DT/Exynos drivers need further work)
> 
> 
> Saravana Kannan (1):
>   PM / devfreq: Rewrite devfreq_update_status() to fix multiple bugs
> 
>  drivers/devfreq/devfreq.c | 31 ---
>  1 file changed, 20 insertions(+), 11 deletions(-)
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pm" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> 

-- 
I speak only for myself.
Rafael J. Wysocki, Intel Open Source Technology Center.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[H. Peter Anvin]

On 03/21/2014 02:48 PM, Andi Kleen wrote:
> "H. Peter Anvin"  writes:
>>
>> That's why at least to some extent The Right Thing is not to try to
>> pretend to be a CPU you don't even know how to emulate.
>>
>> But again, that has its own issues, too, mostly with userspace
>> optimization, and making the Linux code more resilient wouldn't hurt.
>> In that sense #GP(0) is *much* better than 0: it unambiguously gives an
>> error to work with.
> 
> That means we could just throw rdmsr() away and it would be completely
> replaced with rdmsr_safe(). But then that will likely cause all kinds
> of problems with how to handle these errors and where and how to handle
> these exceptions.
> 
> I much prefer just to fix KVM. I cannot think of any case
> where 0 would cause a major issue.
> 
> After all it's virtualization not "rewrite complete kernel for it"
> 

Actually, Ingo, Borislav and I have been discussing making rdmsr_safe()
more of the default, especially for things like this where the error
handling is obvious (doesn't work?  Disable the PMU.)

-hpa


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Andi Kleen]

"H. Peter Anvin"  writes:
>
> That's why at least to some extent The Right Thing is not to try to
> pretend to be a CPU you don't even know how to emulate.
>
> But again, that has its own issues, too, mostly with userspace
> optimization, and making the Linux code more resilient wouldn't hurt.
> In that sense #GP(0) is *much* better than 0: it unambiguously gives an
> error to work with.

That means we could just throw rdmsr() away and it would be completely
replaced with rdmsr_safe(). But then that will likely cause all kinds
of problems with how to handle these errors and where and how to handle
these exceptions.

I much prefer just to fix KVM. I cannot think of any case
where 0 would cause a major issue.

After all it's virtualization not "rewrite complete kernel for it"

-Andi

-- 
a...@linux.intel.com -- Speaking for myself only
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 2/2] ARM: multi_v7_defconfig: Select CONFIG_MACH_BERLIN_BG2Q

[Sebastian Hesselbarth]

On 03/21/2014 08:39 PM, Alexandre Belloni wrote:

Now that we support Berlin BG2Q, select CONFIG_MACH_BERLIN_BG2Q so that we can
boot BG2Q based boards like the BG2Q DMP.

Signed-off-by: Alexandre Belloni 


Applied to berlin/soc, Thanks!


---
  arch/arm/configs/multi_v7_defconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index ee6982976d66..8b09b72fb688 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -15,6 +15,7 @@ CONFIG_ARCH_BCM_MOBILE=y
  CONFIG_ARCH_BERLIN=y
  CONFIG_MACH_BERLIN_BG2=y
  CONFIG_MACH_BERLIN_BG2CD=y
+CONFIG_MACH_BERLIN_BG2Q=y
  CONFIG_GPIO_PCA953X=y
  CONFIG_ARCH_HIGHBANK=y
  CONFIG_ARCH_HI3xxx=y



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 1/2] ARM: berlin: add MACH_BERLIN_BG2Q symbol

[Sebastian Hesselbarth]

On 03/21/2014 08:39 PM, Alexandre Belloni wrote:

Now that we start supporting the Marvell Berlin BG2Q, add a symbol allowing to
differentiate that SoC from the other SoCs of the Berlin family.

Signed-off-by: Alexandre Belloni 


Applied to berlin/defconfig, Thanks!


---
  arch/arm/mach-berlin/Kconfig | 7 +++
  1 file changed, 7 insertions(+)

diff --git a/arch/arm/mach-berlin/Kconfig b/arch/arm/mach-berlin/Kconfig
index 7a02d222c378..0ff6f5877076 100644
--- a/arch/arm/mach-berlin/Kconfig
+++ b/arch/arm/mach-berlin/Kconfig
@@ -24,6 +24,13 @@ config MACH_BERLIN_BG2CD
select CPU_V7
select HAVE_ARM_TWD if SMP

+config MACH_BERLIN_BG2Q
+   bool "Marvell Armada 1500 Pro (BG2-Q)"
+   select CACHE_L2X0
+   select CPU_V7
+   select HAVE_ARM_TWD if SMP
+   select HAVE_SMP
+
  endmenu

  endif



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 02/26] kprobes/x86: Allow to handle reentered kprobe on singlestepping

[Steven Rostedt]

On Wed, 05 Mar 2014 20:58:57 +0900
Masami Hiramatsu  wrote:

> Since the NMI handlers(e.g. perf) can interrupt in the
> single stepping (or preparing the single stepping, do_debug
> etc.), we should consider a kprobe is hit in the NMI
> handler. Even in that case, the kprobe is allowed to be
> reentered as same as the kprobes hit in kprobe handlers
> (KPROBE_HIT_ACTIVE or KPROBE_HIT_SSDONE).
> The real issue will happen when a kprobe hit while another
> reentered kprobe is processing (KPROBE_REENTER), because
> we already consumed a saved-area for the previous kprobe.
> 
> Signed-off-by: Masami Hiramatsu 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 

Reviewed-by: Steven Rostedt 

-- Steve
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[H. Peter Anvin]

On 03/21/2014 02:37 PM, Andi Kleen wrote:
> On Fri, Mar 21, 2014 at 01:46:04PM -0700, H. Peter Anvin wrote:
>> Not really.  That is equally braindamaged.  The problem is that KVM is 
>> telling the host that our is something it simply cannot be.
> 
> Well it has to pick something. It's unlikely it will ever implement 100% of 
> that particular CPU.
> 0 is the best you can get in many cases.
> 
> Also I thought Xen did return 0.
> 

That's why at least to some extent The Right Thing is not to try to
pretend to be a CPU you don't even know how to emulate.

But again, that has its own issues, too, mostly with userspace
optimization, and making the Linux code more resilient wouldn't hurt.
In that sense #GP(0) is *much* better than 0: it unambiguously gives an
error to work with.

However, labeling it a bug in Linux is silly.

-hpa

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] usb/xhci: fix compilation warning when !CONFIG_PCI && !CONFIG_PM

[David Cohen]

Hi Mathias,

On Tue, Feb 18, 2014 at 11:04:12AM -0800, David Cohen wrote:
> On Tue, Feb 18, 2014 at 12:47:41PM -0600, Felipe Balbi wrote:
> > On Tue, Feb 18, 2014 at 10:00:30AM -0800, David Cohen wrote:
> > > Hi Sarah,
> > > 
> > > On Mon, Jan 06, 2014 at 07:02:19PM -0800, David Cohen wrote:
> > > > When CONFIG_PCI and CONFIG_PM are not selected, xhci.c gets this
> > > > warning:
> > > > drivers/usb/host/xhci.c:409:13: warning: ‘xhci_msix_sync_irqs’ defined
> > > > but not used [-Wunused-function]
> > > > 
> > > > It happens due to lack of __maybe_unused flag on xhci_msix_sync_irqs()
> > > > function in case of !CONFIG_PCI.
> > > > 
> > > > Signed-off-by: David Cohen 
> > > > ---
> > > 
> > > Ping :)
> > > Any comments here?
> > > 
> > > Br, David
> > > 
> > > > 
> > > > Change v1 -> v2:
> > > >  - xhci_msix_sync_irqs() already uses __maybe_unused flag when 
> > > > CONFIG_PCI is
> > > >set. Proper solution is to add same flag when !CONFIG_PCI instead of 
> > > > define
> > > >function as inline.
> > > > 
> > > >  drivers/usb/host/xhci.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > > 
> > > > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > > > index 4265b48856f6..ed6b717b8ee1 100644
> > > > --- a/drivers/usb/host/xhci.c
> > > > +++ b/drivers/usb/host/xhci.c
> > > > @@ -406,7 +406,7 @@ static void xhci_cleanup_msix(struct xhci_hcd *xhci)
> > > >  {
> > > >  }
> > > >  
> > > > -static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > > > +static void __maybe_unused xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > 
> > bellow is likely a better fix. Usually stubs are marked inline, rather
> > than getting an unused attribute:
> 
> Thanks for commenting. That would be actually the v1 of my patch :)
> I changed after I see the proper function has __maybe_unused flag.
> 
> But I'm fine with Sarah picking any of the patch's versions.

Guess you're handling the review of this trivial patch now :)
Comments are very welcome.

Br, David

> 
> Br, David
> 
> > 
> > diff --git a/drivers/usb/host/xhci.c b/drivers/usb/host/xhci.c
> > index 3712359..8f1a6d5 100644
> > --- a/drivers/usb/host/xhci.c
> > +++ b/drivers/usb/host/xhci.c
> > @@ -404,16 +404,16 @@ static int xhci_try_enable_msi(struct usb_hcd *hcd)
> >  
> >  #else
> >  
> > -static int xhci_try_enable_msi(struct usb_hcd *hcd)
> > +static inline int xhci_try_enable_msi(struct usb_hcd *hcd)
> >  {
> > return 0;
> >  }
> >  
> > -static void xhci_cleanup_msix(struct xhci_hcd *xhci)
> > +static inline void xhci_cleanup_msix(struct xhci_hcd *xhci)
> >  {
> >  }
> >  
> > -static void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> > +static inline void xhci_msix_sync_irqs(struct xhci_hcd *xhci)
> >  {
> >  }
> >  
> > 
> > -- 
> > balbi
> 
> 
> 
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH -tip v8 01/26] [BUGFIX]kprobes/x86: Fix page-fault handling logic

[Steven Rostedt]

On Wed, 05 Mar 2014 20:58:50 +0900
Masami Hiramatsu  wrote:

> Current kprobes in-kernel page fault handler doesn't
> expect that its single-stepping can be interrupted by
> an NMI handler which may cause a page fault(e.g. perf
> with callback tracing).
> In that case, the page-fault handled by kprobes and it
> misunderstands the page-fault has been caused by the
> single-stepping code and tries to recover IP address
> to probed address.
> But the truth is the page-fault has been caused by the
> NMI handler, and do_page_fault failes to handle real
> page fault because the IP address is modified and
> causes Kernel BUGs like below.
> 
>  
>  [ 2264.726905] BUG: unable to handle kernel NULL pointer
>  dereference at 0020
> [ 2264.727190] IP: [] copy_user_generic_string+0x0/0x40
> [ 2264.727380] PGD cbcd067 PUD cbcc067 PMD 0
> [ 2264.727529] Oops:  [#1] SMP
> [ 2264.727683] Modules linked in: ipt_MASQUERADE bnep bluetooth 6lowpan_iphc 
> iptable_nat nf_nat_ipv4 nf_nat aesni_intel aes_x86_64 ablk_helper cryptd lrw 
> gf128mul glue_helper virtio_balloon snd_hda_intel snd_hda_codec snd_hwdep
> [ 2264.728391] CPU: 1 PID: 25094 Comm: perf Not tainted 3.14.0-rc1.badprobe+ 
> #24
> [ 2264.728592] Hardware name: Bochs Bochs, BIOS Bochs 01/01/2011
> [ 2264.728747] task: 88003db9c210 ti: 88000caac000 task.ti: 
> 88000caac000
> [ 2264.728950] RIP: 0010:[]  [] 
> copy_user_generic_string+0x0/0x40
> [ 2264.729163] RSP: 0018:88003fd06bd0  EFLAGS: 00010246
> [ 2264.729291] RAX:  RBX: 88003fd06bf8 RCX: 
> 0002
> [ 2264.729472] RDX:  RSI: 0020 RDI: 
> 88003fd06bf8
> [ 2264.729661] RBP: 88003fd06bd8 R08: 0030 R09: 
> 
> [ 2264.729789] R10: 001e R11: 0015 R12: 
> 88000caadfd8
> [ 2264.729789] R13: 88003d76bc00 R14: 88003db9c210 R15: 
> 0020
> [ 2264.729789] FS:  7f398bbcc780() GS:88003fd0() 
> knlGS:
> [ 2264.729789] CS:  0010 DS:  ES:  CR0: 80050033
> [ 2264.729789] CR2: 0020 CR3: 204f2000 CR4: 
> 07e0
> [ 2264.729789] Stack:
> [ 2264.729789]  813c5fd4 88003fd06c30 810183b0 
> 88003d76bc00
> [ 2264.729789]  88003fd06ef8   
> 88003d76bc00
> [ 2264.729789]  000c 00052ce0 88000956f800 
> 88000caadf58
> [ 2264.729789] Call Trace:
> [ 2264.729789]  
> [ 2264.729789]  [] ? copy_from_user_nmi+0x64/0x70
> [ 2264.729789]  [] perf_callchain_user+0xc0/0x220
> [ 2264.729789]  [] perf_callchain+0x1c4/0x210
> [ 2264.729789]  [] perf_prepare_sample+0x253/0x320
> [ 2264.729789]  [] __perf_event_overflow+0xe7/0x230
> [ 2264.729789]  [] ? x86_perf_event_set_period+0xe8/0x150
> [ 2264.729789]  [] perf_event_overflow+0x14/0x20
> [ 2264.729789]  [] intel_pmu_handle_irq+0x1cd/0x400
> [ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
> [ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
> [ 2264.729789]  [] perf_event_nmi_handler+0x2b/0x50
> [ 2264.729789]  [] nmi_handle+0x88/0x180
> [ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
> [ 2264.729789]  [] default_do_nmi+0x4a/0x140
> [ 2264.729789]  [] do_nmi+0xa8/0xe0
> [ 2264.729789]  [] end_repeat_nmi+0x1e/0x2e
> [ 2264.729789]  [] ? copy_user_generic_unrolled+0xc0/0xc0
> [ 2264.729789]  [] ? skip_prefixes+0x1c/0x40
> [ 2264.729789]  [] ? bad_get_user+0x17/0x17
> [ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
> [ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
> [ 2264.729789]  [] ? ftrace_regs_caller+0x81/0xcd
> [ 2264.729789]  <>
> [ 2264.729789]  <#DB>  [] ? 
> copy_user_generic_unrolled+0xc0/0xc0
> [ 2264.729789]  [] ? copy_user_generic_string+0x1/0x40
> [ 2264.729789]  [] ? ftrace_cmp_recs+0x1/0x30
> [ 2264.729789]  [] ? inat_get_opcode_attribute+0x5/0x20
> [ 2264.729789]  [] ? inat_get_opcode_attribute+0x5/0x20
> [ 2264.729789]  [] ? skip_prefixes+0x1c/0x40
> [ 2264.729789]  [] resume_execution+0x37/0x1d0
> [ 2264.729789]  [] kprobe_debug_handler+0x3f/0xe0
> [ 2264.729789]  [] do_debug+0x7f/0x1d0
> [ 2264.729789]  [] debug+0x3a/0x50
> [ 2264.729789]  <>
> [ 2264.729789]  [] ? seq_read+0x88/0x390
> [ 2264.729789]  [] ? security_file_permission+0x84/0xa0
> [ 2264.729789]  [] proc_reg_read+0x3d/0x80
> [ 2264.729789]  [] vfs_read+0x9b/0x160
> [ 2264.729789]  [] SyS_read+0x49/0xa0
> [ 2264.729789]  [] system_call_fastpath+0x16/0x1b
> [ 2264.729789] Code: c9 75 ee 21 d2 74 10 89 d1 8a 06 88 07 48 ff c6 48 ff c7 
> ff
>  c9 75 f2 31 c0 0f 1f 00 c3 66 66 66 66 66 2e 0f 1f 84 00 00 00 00 00  1f 
> 00
>  83 fa 08 72 27 89 f9 83 e1 07 74 15 83 e9 08 f7 d9 29
> [ 2264.729789] RIP  [] copy_user_generic_string+0x0/0x40
> [ 2264.729789]  RSP 
> [ 2264.729789] CR2: 0020
> [ 2264.729789] ---[ end trace 533fc16b4cc45447 ]---
> [ 2264.729789] Kernel panic - not syncing: Fatal exception in interrupt
> [ 2264.729789] Kernel Offset: 0x0 

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[Andi Kleen]

On Fri, Mar 21, 2014 at 01:46:04PM -0700, H. Peter Anvin wrote:
> Not really.  That is equally braindamaged.  The problem is that KVM is 
> telling the host that our is something it simply cannot be.

Well it has to pick something. It's unlikely it will ever implement 100% of 
that particular CPU.
0 is the best you can get in many cases.

Also I thought Xen did return 0.

-Andi
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 5/5] ARM: berlin/dt: add cpupll and syspll support to BG2

[Sebastian Hesselbarth]

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

The Berlin BG2 has two supported PLLs: CPU PLL and System PLL, add those to the
SoC device tree.

This also moves the remaining clocks from the clocks container node to the root.

Signed-off-by: Alexandre Belloni 
---
  arch/arm/boot/dts/berlin2.dtsi | 48 +++---
  1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2.dtsi b/arch/arm/boot/dts/berlin2.dtsi
index 56a1af2f1052..6c080eb6242a 100644
--- a/arch/arm/boot/dts/berlin2.dtsi
+++ b/arch/arm/boot/dts/berlin2.dtsi

[...]

@@ -83,7 +83,21 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
interrupts = ;
-   clocks = <>;
+   clocks = <>;
+   };
+
+   syspll: syspll@ea0014 {
+   compatible = "marvell,berlin2-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xea0014 8>;
+   };
+
+   cpupll: cpupll@ea003c {
+   compatible = "marvell,berlin2-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xea003c 8>;


Same comment about hex numbers and I'll also fix it up.

Sebastian


};

apb@e8 {



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 4/5] ARM: berlin/dt: add cpupll and syspll support to BG2CD

[Sebastian Hesselbarth]

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

The Berlin BG2CD has two supported PLLs: CPU PLL and System PLL, add those to
the SoC device tree.

This also moves the remaining clocks from the clocks container node to the root.

Signed-off-by: Alexandre Belloni 
---
  arch/arm/boot/dts/berlin2cd.dtsi | 48 ++--
  1 file changed, 31 insertions(+), 17 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2cd.dtsi b/arch/arm/boot/dts/berlin2cd.dtsi
index 094968c27533..bd4e9dd4867e 100644
--- a/arch/arm/boot/dts/berlin2cd.dtsi
+++ b/arch/arm/boot/dts/berlin2cd.dtsi
@@ -30,24 +30,24 @@

[...]

@@ -76,7 +76,21 @@
compatible = "arm,cortex-a9-twd-timer";
reg = <0xad0600 0x20>;
interrupts = ;
-   clocks = <>;
+   clocks = <>;
+   };
+
+   syspll: syspll@ea0014 {
+   compatible = "marvell,berlin2-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xf7ea0014 8>;


nit: I prefer hex numbers all over for reg properties. berlin2q already
has them, and I'll fixup this and the one below myself.


+   };
+
+   cpupll: cpupll@ea003c {
+   compatible = "marvell,berlin2-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xf7ea003c 8>;


ditto.

Sebastian


};

apb@e8 {



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 3/5] ARM: berlin/dt: add cpupll and syspll support to BG2Q

[Sebastian Hesselbarth]

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

The Berlin BG2Q has two supported PLLs: CPU PLL and System PLL, add those to the
SoC device tree.

Note that support for the AVPLL is not yet available.


Above should not be part of the commit message, no need to resend.
I can fix it up.

Sebastian


Signed-off-by: Alexandre Belloni 
---
  arch/arm/boot/dts/berlin2q.dtsi | 22 +++---
  1 file changed, 15 insertions(+), 7 deletions(-)

diff --git a/arch/arm/boot/dts/berlin2q.dtsi b/arch/arm/boot/dts/berlin2q.dtsi
index 07452a7483fa..5925e6a16749 100644
--- a/arch/arm/boot/dts/berlin2q.dtsi
+++ b/arch/arm/boot/dts/berlin2q.dtsi
@@ -59,16 +59,10 @@
clock-frequency = <1>;
};

-   cpuclk: cpu-clock {
-   compatible = "fixed-clock";
-   #clock-cells = <0>;
-   clock-frequency = <12>;
-   };
-
twdclk: twdclk {
compatible = "fixed-factor-clock";
#clock-cells = <0>;
-   clocks = <>;
+   clocks = <>;
clock-mult = <1>;
clock-div = <3>;
};
@@ -101,6 +95,20 @@
#interrupt-cells = <3>;
};

+   cpupll: cpupll@dd0170 {
+   compatible = "marvell,berlin2q-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xdd0170 0x8>;
+   };
+
+   syspll: syspll@ea0030 {
+   compatible = "marvell,berlin2q-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xea0030 0x8>;
+   };
+
apb@e8 {
compatible = "simple-bus";
#address-cells = <1>;



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 2/5] clk: berlin: add berlin clocks DT bindings documentation

[Sebastian Hesselbarth]

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

Document the device tree bindings for the PLLs found on the Marvell Berlin SoCs.

Cc: devicet...@vger.kernel.org


You forgot to add Mark Rutland's Reviewed-by. He didn't mentioned it
explicitly but his "Otherwise this looks fine to me" on v1, is as good
as a Reviewed-by. But, no need to resend, I'll fix it up.

Also, everything above the '---' will be part of your commit log. While
the Signed-off-by and Reviewed-by should be in there, Cc's really don't
need to.

You can add another '---' to separate commit message and some stuff
you want to have early in you email with:

Blablabla commit message.

Signed-off-by: ...
Reviewed-by: ...
---
Changelog:
- blabla

Cc: cc-me-recipient
...
---
   .../devicetree/bindings/clock/berlin-clock.txt | 29 
++

   1 file changed, 29 insertions(+)
   create mode 100644 
Documentation/devicetree/bindings/clock/berlin-clock.txt


 diff --git a/Documentation/devicetree/bindings/clock/berlin-clock.txt 
b/Documentation/devicetree/bindings/clock/berlin-clock.txt

...


Signed-off-by: Alexandre Belloni 
---
  .../devicetree/bindings/clock/berlin-clock.txt | 29 ++
  1 file changed, 29 insertions(+)
  create mode 100644 Documentation/devicetree/bindings/clock/berlin-clock.txt

diff --git a/Documentation/devicetree/bindings/clock/berlin-clock.txt 
b/Documentation/devicetree/bindings/clock/berlin-clock.txt
new file mode 100644
index ..49b7860bffb8
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/berlin-clock.txt
@@ -0,0 +1,29 @@
+Device Tree Clock bindings for Marvell Berlin clocks
+
+This binding uses the common clock binding[1].
+
+[1] Documentation/devicetree/bindings/clock/clock-bindings.txt
+
+Required properties:
+- compatible: shall be one of the following:
+   "marvell,berlin2-pll",
+   "marvell,berlin2q-pll":
+   CPU PLL and System PLL
+- reg: Address and length of the clock register set.
+- #clock-cells: from common clock binding; shall be set to 0.
+- clocks: from common clock binding
+
+smclk: sysmgr-clock {
+   compatible = "fixed-clock";
+   #clock-cells = <0>;
+   clock-frequency = <2500>;
+};
+
+cpupll: cpupll@ea003c {
+   compatible = "marvell,berlin2-pll";
+   clocks = <>;
+   #clock-cells = <0>;
+   reg = <0xea003c 0x8>;
+};
+
+



--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] ARM: i.MX6: update KSZ9031 phy fixup

[Eric Bénard]

Hi Hubert,

Le Fri, 21 Mar 2014 18:08:07 +0100,
Hubert Chaumette  a écrit :

> 
> Update KSZ9031RN phy fixup for Congatec conga-QEVAL and conga-QMX6 combo :
> set RGMII GTX_CLK and RX_CLK pad skew to +0.96ns.
> 
> Signed-off-by: Hubert Chaumette 
> ---
>  arch/arm/mach-imx/mach-imx6q.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/arch/arm/mach-imx/mach-imx6q.c b/arch/arm/mach-imx/mach-imx6q.c
> index 76e5db4..db307c2 100644
> --- a/arch/arm/mach-imx/mach-imx6q.c
> +++ b/arch/arm/mach-imx/mach-imx6q.c
> @@ -77,6 +77,9 @@ static int ksz9031rn_phy_fixup(struct phy_device *dev)
>   mmd_write_reg(dev, 2, 5, 0);
>   mmd_write_reg(dev, 2, 8, 0x003ff);
>  
> + /* For Congatec conga-QMX6 board */
> + mmd_write_reg(dev, 0x02, 0x06, 0x);
> +
>   return 0;
>  }
>  
that's board specific (the needed delay depends on the routing delay on
the PCB), so this should not go in a generic file.

Eric
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2 1/5] clk: berlin: add support for berlin plls

[Sebastian Hesselbarth]

On 03/21/2014 09:08 PM, Alexandre Belloni wrote:

This drivers allows to provide DT clocks for the cpu and system PLLs found on
Marvell Berlin SoCs.


Alexandre,

as mentioned on IRC, I now had a closer look on it. Some minor
remarks below. Sorry, I didn't mention them earlier.


Signed-off-by: Alexandre Belloni 
---

[...]

--- /dev/null
+++ b/drivers/clk/berlin/pll-berlin2.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2014 Marvell Technology Group Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "common.h"
+
+static const u8 vcodiv_berlin2[] = {10, 15, 20, 25, 30, 40, 50, 60, 80,
+   1, 1, 1, 1, 1, 1, 1};


As there are already zeroes in vcodiv_berlin2q below, we should rather
make the above

static const u8 vcodiv_berlin2[16] = {10, 15, 20, 25, 30, 40, 50, 60, 80};

And check for vcodiv == 0 in berlin_pll_recalc_rate below.


+static struct berlin_pllmap berlin_pll_map = {
+   .vcodiv = vcodiv_berlin2,
+   .fbdiv_mask = 0x1FF,
+   .fbdiv_shift = 6,
+   .rfdiv_mask = 0x1F,
+   .rfdiv_shift = 1,
+   .divsel_mask = 0xF,
+   .divsel_shift = 7,
+   .mult = 10,
+};
+
+static void __init berlin2_pll_setup(struct device_node *np)
+{
+   berlin_pll_setup(np, _pll_map);
+}
+CLK_OF_DECLARE(berlin2q_pll, "marvell,berlin2-pll", berlin2_pll_setup);


s/berlin2q_pll/berlin2_pll


+


Remove empty line above.


diff --git a/drivers/clk/berlin/pll-berlin2q.c 
b/drivers/clk/berlin/pll-berlin2q.c
new file mode 100644
index ..0a2e9968cc09
--- /dev/null
+++ b/drivers/clk/berlin/pll-berlin2q.c
@@ -0,0 +1,42 @@
+/*
+ * Copyright (c) 2014 Marvell Technology Group Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+
+#include "common.h"
+
+static const u8 vcodiv_berlin2q[] = {1, 0, 2, 0, 3, 4, 0, 6, 8,
+1, 1, 1, 1, 1, 1, 1};


Same comment as for vcodiv_berlin2.


+static struct berlin_pllmap berlin2q_pll_map = {
+   .vcodiv = vcodiv_berlin2q,
+   .fbdiv_mask = 0x1FF,
+   .fbdiv_shift = 7,
+   .rfdiv_mask = 0x1F,
+   .rfdiv_shift = 2,
+   .divsel_mask = 0xF,
+   .divsel_shift = 9,
+   .mult = 1,
+};
+
+static void __init berlin2q_pll_setup(struct device_node *np)
+{
+   berlin_pll_setup(np, _pll_map);
+}
+CLK_OF_DECLARE(berlin2q_pll, "marvell,berlin2q-pll", berlin2q_pll_setup);
+


Remove empty line above.


diff --git a/drivers/clk/berlin/pll.c b/drivers/clk/berlin/pll.c
new file mode 100644
index ..264c48d6e797
--- /dev/null
+++ b/drivers/clk/berlin/pll.c
@@ -0,0 +1,107 @@
+/*
+ * Copyright (c) 2014 Marvell Technology Group Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify it
+ * under the terms and conditions of the GNU General Public License,
+ * version 2, as published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope it will be useful, but WITHOUT
+ * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or
+ * FITNESS FOR A PARTICULAR PURPOSE.  See the GNU General Public License for
+ * more details.
+ *
+ * You should have received a copy of the GNU General Public License along with
+ * this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "common.h"
+
+struct berlin_pll {
+   struct clk_hw   hw;
+   void __iomem*base;
+   struct berlin_pllmap*map;
+};
+
+#define to_berlin_pll(hw)  container_of(hw, struct berlin_pll, hw)
+
+#define PLL_CTRL0  0x00
+#define PLL_CTRL1  0x04
+
+static inline u32 berlin_pll_read(struct berlin_pll *pll, unsigned long offset)
+{
+   return readl_relaxed(pll->base + offset);
+}
+
+/*
+ * The output frequency 

[PATCH 3/5] vrange: Add page purging logic & SIGBUS trap

[John Stultz]

This patch adds the hooks in the vmscan logic to discard volatile pages
and mark their pte as purged. With this, volatile pages will be purged
under pressure, and their ptes swap entry's marked. If the purged pages
are accessed before being marked non-volatile, we catch this and send a
SIGBUS.

This is a simplified implementation that uses logic from Minchan's earlier
efforts, so credit to Minchan for his work.

Cc: Andrew Morton 
Cc: Android Kernel Team 
Cc: Johannes Weiner 
Cc: Robert Love 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Rik van Riel 
Cc: Dmitry Adamushko 
Cc: Neil Brown 
Cc: Andrea Arcangeli 
Cc: Mike Hommey 
Cc: Taras Glek 
Cc: Jan Kara 
Cc: KOSAKI Motohiro 
Cc: Michel Lespinasse 
Cc: Minchan Kim 
Cc: linux...@kvack.org 
Signed-off-by: John Stultz 
---
 include/linux/vrange.h |   2 +
 mm/internal.h  |   2 -
 mm/memory.c|  21 +
 mm/rmap.c  |   5 +++
 mm/vmscan.c|  12 ++
 mm/vrange.c| 114 +
 6 files changed, 154 insertions(+), 2 deletions(-)

diff --git a/include/linux/vrange.h b/include/linux/vrange.h
index 986fa85..d93ad21 100644
--- a/include/linux/vrange.h
+++ b/include/linux/vrange.h
@@ -8,4 +8,6 @@
 #define VRANGE_VOLATILE 1
 #define VRANGE_VALID_FLAGS (0) /* Don't yet support any flags */
 
+extern int discard_vpage(struct page *page);
+
 #endif /* _LINUX_VRANGE_H */
diff --git a/mm/internal.h b/mm/internal.h
index 29e1e76..ea66bf9 100644
--- a/mm/internal.h
+++ b/mm/internal.h
@@ -225,10 +225,8 @@ static inline void mlock_migrate_page(struct page 
*newpage, struct page *page)
 
 extern pmd_t maybe_pmd_mkwrite(pmd_t pmd, struct vm_area_struct *vma);
 
-#ifdef CONFIG_TRANSPARENT_HUGEPAGE
 extern unsigned long vma_address(struct page *page,
 struct vm_area_struct *vma);
-#endif
 #else /* !CONFIG_MMU */
 static inline int mlocked_vma_newpage(struct vm_area_struct *v, struct page *p)
 {
diff --git a/mm/memory.c b/mm/memory.c
index 22dfa61..db5f4da 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -60,6 +60,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -3643,6 +3644,8 @@ static int handle_pte_fault(struct mm_struct *mm,
 
entry = *pte;
if (!pte_present(entry)) {
+   swp_entry_t vrange_entry;
+retry:
if (pte_none(entry)) {
if (vma->vm_ops) {
if (likely(vma->vm_ops->fault))
@@ -3652,6 +3655,24 @@ static int handle_pte_fault(struct mm_struct *mm,
return do_anonymous_page(mm, vma, address,
 pte, pmd, flags);
}
+
+   vrange_entry = pte_to_swp_entry(entry);
+   if (unlikely(is_vpurged_entry(vrange_entry))) {
+   if (vma->vm_flags & VM_VOLATILE)
+   return VM_FAULT_SIGBUS;
+
+   /* zap pte */
+   ptl = pte_lockptr(mm, pmd);
+   spin_lock(ptl);
+   if (unlikely(!pte_same(*pte, entry)))
+   goto unlock;
+   flush_cache_page(vma, address, pte_pfn(*pte));
+   ptep_clear_flush(vma, address, pte);
+   pte_unmap_unlock(pte, ptl);
+   goto retry;
+   }
+
+
if (pte_file(entry))
return do_nonlinear_fault(mm, vma, address,
pte, pmd, flags, entry);
diff --git a/mm/rmap.c b/mm/rmap.c
index d9d4231..2b6f079 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -728,6 +728,11 @@ int page_referenced_one(struct page *page, struct 
vm_area_struct *vma,
referenced++;
}
pte_unmap_unlock(pte, ptl);
+   if (vma->vm_flags & VM_VOLATILE) {
+   pra->mapcount = 0;
+   pra->vm_flags |= VM_VOLATILE;
+   return SWAP_FAIL;
+   }
}
 
if (referenced) {
diff --git a/mm/vmscan.c b/mm/vmscan.c
index a9c74b4..34f159a 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -43,6 +43,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include 
 #include 
@@ -683,6 +684,7 @@ enum page_references {
PAGEREF_RECLAIM,
PAGEREF_RECLAIM_CLEAN,
PAGEREF_KEEP,
+   PAGEREF_DISCARD,
PAGEREF_ACTIVATE,
 };
 
@@ -703,6 +705,13 @@ static enum page_references page_check_references(struct 
page *page,
if (vm_flags & VM_LOCKED)
return PAGEREF_RECLAIM;
 
+   /*
+* If volatile page is reached on LRU's tail, we discard the
+* page without considering recycle the page.
+*/
+   if (vm_flags & VM_VOLATILE)
+   return PAGEREF_DISCARD;
+
if (referenced_ptes) {
if 

[PATCH 4/5] vrange: Set affected pages referenced when marking volatile

[John Stultz]

One issue that some potential users were concerned about, was that
they wanted to ensure that all the pages from one volatile range
were purged before we purge pages from a different volatile range.
This would prevent the case where they have 4 large objects, and
the system purges one page from each object, casuing all of the
objects to have to be re-created.

The counter-point to this case, is when an application is using the
SIGBUS semantics to continue to access pages after they have been
marked volatile. In that case, the desire was that the most recently
touched pages be purged last, and only the "cold" pages be purged
from the specified range.

Instead of adding option flags for the various usage model (at least
initially), one way of getting a solutoin for both uses would be to
have the act of marking pages as volatile in effect mark the pages
as accessed. Since all of the pages in the range would be marked
together, they would be of the same "age" and would (approximately)
be purged together. Further, if any pages in the range were accessed
after being marked volatile, they would be moved to the end of the
lru and be purged later.

This patch provides this solution by walking the pages in the range
and setting them accessed when set volatile.

This does have a performance impact, as we have to touch each page
when setting them volatile. Additionally, while setting all the
pages to the same age solves the basic problem, there is still an
open question of: What age all the pages should be set to?

One could consider them all recently accessed, which would put them
at the end of the active lru. Or one could possibly move them all to
the end of the inactive lru, making them more likely to be purged
sooner.

Another possibility would be to not affect the pages at all when
marking them as volatile, and allow applications to use madvise
prior to marking any pages as volatile to age them together, if
that behavior was needed. In that case this patch would be
unnecessary.

Thoughts on the best approach would be greatly appreciated.


Cc: Andrew Morton 
Cc: Android Kernel Team 
Cc: Johannes Weiner 
Cc: Robert Love 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Rik van Riel 
Cc: Dmitry Adamushko 
Cc: Neil Brown 
Cc: Andrea Arcangeli 
Cc: Mike Hommey 
Cc: Taras Glek 
Cc: Jan Kara 
Cc: KOSAKI Motohiro 
Cc: Michel Lespinasse 
Cc: Minchan Kim 
Cc: linux...@kvack.org 
Signed-off-by: John Stultz 
---
 mm/vrange.c | 71 +
 1 file changed, 71 insertions(+)

diff --git a/mm/vrange.c b/mm/vrange.c
index 28ceb6f..9be8f45 100644
--- a/mm/vrange.c
+++ b/mm/vrange.c
@@ -79,6 +79,73 @@ static int vrange_check_purged(struct mm_struct *mm,
 
 }
 
+
+/**
+ * vrange_mark_accessed_pte - Marks pte pages in range accessed
+ *
+ * Iterates over the ptes in the pmd and marks the coresponding page
+ * as accessed. This ensures all the pages in the range are of the
+ * same "age", so that when pages are purged, we will most likely purge
+ * them together.
+ */
+static int vrange_mark_accessed_pte(pmd_t *pmd, unsigned long addr,
+   unsigned long end, struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk->private;
+   pte_t *pte;
+   spinlock_t *ptl;
+
+   if (pmd_trans_huge(*pmd))
+   return 0;
+   if (pmd_trans_unstable(pmd))
+   return 0;
+
+   pte = pte_offset_map_lock(walk->mm, pmd, addr, );
+   for (; addr != end; pte++, addr += PAGE_SIZE) {
+   if (pte_present(*pte)) {
+   struct page *page;
+
+   page = vm_normal_page(vma, addr, *pte);
+   if (IS_ERR_OR_NULL(page))
+   break;
+   get_page(page);
+   /*
+* XXX - So here we may want to do something
+* else other then marking the page accessed.
+* Setting them to all be the same "age" ensures
+* they are pruged together, but its not clear
+* what that "age" should be.
+*/
+   mark_page_accessed(page);
+   put_page(page);
+   }
+   }
+   pte_unmap_unlock(pte - 1, ptl);
+   cond_resched();
+
+   return 0;
+}
+
+
+/**
+ * vrange_mark_range_accessed - Sets up a mm_walk to mark pages accessed
+ *
+ * Sets up and calls wa_page_range() to mark affected pages as accessed.
+ */
+static void vrange_mark_range_accessed(struct vm_area_struct *vma,
+   unsigned long start,
+   unsigned long end)
+{
+   struct mm_walk vrange_walk = {
+   .pmd_entry = vrange_mark_accessed_pte,
+   .mm = vma->vm_mm,
+   .private = vma,
+   };
+
+   walk_page_range(start, 

[PATCH 5/5] vmscan: Age anonymous memory even when swap is off.

[John Stultz]

Currently we don't shrink/scan the anonymous lrus when swap is off.
This is problematic for volatile range purging on swapless systems/

This patch naievely changes the vmscan code to continue scanning
and shrinking the lrus even when there is no swap.

It obviously has performance issues.

Thoughts on how best to implement this would be appreciated.

Cc: Andrew Morton 
Cc: Android Kernel Team 
Cc: Johannes Weiner 
Cc: Robert Love 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Rik van Riel 
Cc: Dmitry Adamushko 
Cc: Neil Brown 
Cc: Andrea Arcangeli 
Cc: Mike Hommey 
Cc: Taras Glek 
Cc: Jan Kara 
Cc: KOSAKI Motohiro 
Cc: Michel Lespinasse 
Cc: Minchan Kim 
Cc: linux...@kvack.org 
Signed-off-by: John Stultz 
---
 mm/vmscan.c | 26 --
 1 file changed, 4 insertions(+), 22 deletions(-)

diff --git a/mm/vmscan.c b/mm/vmscan.c
index 34f159a..07b0a8c 100644
--- a/mm/vmscan.c
+++ b/mm/vmscan.c
@@ -155,9 +155,8 @@ static unsigned long zone_reclaimable_pages(struct zone 
*zone)
nr = zone_page_state(zone, NR_ACTIVE_FILE) +
 zone_page_state(zone, NR_INACTIVE_FILE);
 
-   if (get_nr_swap_pages() > 0)
-   nr += zone_page_state(zone, NR_ACTIVE_ANON) +
- zone_page_state(zone, NR_INACTIVE_ANON);
+   nr += zone_page_state(zone, NR_ACTIVE_ANON) +
+ zone_page_state(zone, NR_INACTIVE_ANON);
 
return nr;
 }
@@ -1764,13 +1763,6 @@ static int inactive_anon_is_low_global(struct zone *zone)
  */
 static int inactive_anon_is_low(struct lruvec *lruvec)
 {
-   /*
-* If we don't have swap space, anonymous page deactivation
-* is pointless.
-*/
-   if (!total_swap_pages)
-   return 0;
-
if (!mem_cgroup_disabled())
return mem_cgroup_inactive_anon_is_low(lruvec);
 
@@ -1880,12 +1872,6 @@ static void get_scan_count(struct lruvec *lruvec, struct 
scan_control *sc,
if (!global_reclaim(sc))
force_scan = true;
 
-   /* If we have no swap space, do not bother scanning anon pages. */
-   if (!sc->may_swap || (get_nr_swap_pages() <= 0)) {
-   scan_balance = SCAN_FILE;
-   goto out;
-   }
-
/*
 * Global reclaim will swap to prevent OOM even with no
 * swappiness, but memcg users want to use this knob to
@@ -2048,7 +2034,6 @@ static void shrink_lruvec(struct lruvec *lruvec, struct 
scan_control *sc)
if (nr[lru]) {
nr_to_scan = min(nr[lru], SWAP_CLUSTER_MAX);
nr[lru] -= nr_to_scan;
-
nr_reclaimed += shrink_list(lru, nr_to_scan,
lruvec, sc);
}
@@ -2181,8 +2166,8 @@ static inline bool should_continue_reclaim(struct zone 
*zone,
 */
pages_for_compaction = (2UL << sc->order);
inactive_lru_pages = zone_page_state(zone, NR_INACTIVE_FILE);
-   if (get_nr_swap_pages() > 0)
-   inactive_lru_pages += zone_page_state(zone, NR_INACTIVE_ANON);
+   inactive_lru_pages += zone_page_state(zone, NR_INACTIVE_ANON);
+
if (sc->nr_reclaimed < pages_for_compaction &&
inactive_lru_pages > pages_for_compaction)
return true;
@@ -2726,9 +2711,6 @@ static void age_active_anon(struct zone *zone, struct 
scan_control *sc)
 {
struct mem_cgroup *memcg;
 
-   if (!total_swap_pages)
-   return;
-
memcg = mem_cgroup_iter(NULL, NULL, NULL);
do {
struct lruvec *lruvec = mem_cgroup_zone_lruvec(zone, memcg);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 2/5] vrange: Add purged page detection on setting memory non-volatile

[John Stultz]

Users of volatile ranges will need to know if memory was discarded.
This patch adds the purged state tracking required to inform userland
when it marks memory as non-volatile that some memory in that range
was purged and needs to be regenerated.

This simplified implementation which uses some of the logic from
Minchan's earlier efforts, so credit to Minchan for his work.

Cc: Andrew Morton 
Cc: Android Kernel Team 
Cc: Johannes Weiner 
Cc: Robert Love 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Rik van Riel 
Cc: Dmitry Adamushko 
Cc: Neil Brown 
Cc: Andrea Arcangeli 
Cc: Mike Hommey 
Cc: Taras Glek 
Cc: Jan Kara 
Cc: KOSAKI Motohiro 
Cc: Michel Lespinasse 
Cc: Minchan Kim 
Cc: linux...@kvack.org 
Signed-off-by: John Stultz 
---
 include/linux/swap.h| 15 --
 include/linux/swapops.h | 10 +++
 include/linux/vrange.h  |  3 ++
 mm/vrange.c | 75 +
 4 files changed, 101 insertions(+), 2 deletions(-)

diff --git a/include/linux/swap.h b/include/linux/swap.h
index 46ba0c6..18c12f9 100644
--- a/include/linux/swap.h
+++ b/include/linux/swap.h
@@ -70,8 +70,19 @@ static inline int current_is_kswapd(void)
 #define SWP_HWPOISON_NUM 0
 #endif
 
-#define MAX_SWAPFILES \
-   ((1 << MAX_SWAPFILES_SHIFT) - SWP_MIGRATION_NUM - SWP_HWPOISON_NUM)
+
+/*
+ * Purged volatile range pages
+ */
+#define SWP_VRANGE_PURGED_NUM 1
+#define SWP_VRANGE_PURGED (MAX_SWAPFILES + SWP_HWPOISON_NUM + 
SWP_MIGRATION_NUM)
+
+
+#define MAX_SWAPFILES ((1 << MAX_SWAPFILES_SHIFT)  \
+   - SWP_MIGRATION_NUM \
+   - SWP_HWPOISON_NUM  \
+   - SWP_VRANGE_PURGED_NUM \
+   )
 
 /*
  * Magic header for a swap area. The first part of the union is
diff --git a/include/linux/swapops.h b/include/linux/swapops.h
index c0f7526..84f43d9 100644
--- a/include/linux/swapops.h
+++ b/include/linux/swapops.h
@@ -161,6 +161,16 @@ static inline int is_write_migration_entry(swp_entry_t 
entry)
 
 #endif
 
+static inline swp_entry_t make_vpurged_entry(void)
+{
+   return swp_entry(SWP_VRANGE_PURGED, 0);
+}
+
+static inline int is_vpurged_entry(swp_entry_t entry)
+{
+   return swp_type(entry) == SWP_VRANGE_PURGED;
+}
+
 #ifdef CONFIG_MEMORY_FAILURE
 /*
  * Support for hardware poisoned pages
diff --git a/include/linux/vrange.h b/include/linux/vrange.h
index 6e5331e..986fa85 100644
--- a/include/linux/vrange.h
+++ b/include/linux/vrange.h
@@ -1,6 +1,9 @@
 #ifndef _LINUX_VRANGE_H
 #define _LINUX_VRANGE_H
 
+#include 
+#include 
+
 #define VRANGE_NONVOLATILE 0
 #define VRANGE_VOLATILE 1
 #define VRANGE_VALID_FLAGS (0) /* Don't yet support any flags */
diff --git a/mm/vrange.c b/mm/vrange.c
index 2f8e2ce..1ff3cbd 100644
--- a/mm/vrange.c
+++ b/mm/vrange.c
@@ -8,6 +8,76 @@
 #include 
 #include "internal.h"
 
+struct vrange_walker {
+   struct vm_area_struct *vma;
+   int page_was_purged;
+};
+
+
+/**
+ * vrange_check_purged_pte - Checks ptes for purged pages
+ *
+ * Iterates over the ptes in the pmd checking if they have
+ * purged swap entries.
+ *
+ * Sets the vrange_walker.pages_purged to 1 if any were purged.
+ */
+static int vrange_check_purged_pte(pmd_t *pmd, unsigned long addr,
+   unsigned long end, struct mm_walk *walk)
+{
+   struct vrange_walker *vw = walk->private;
+   pte_t *pte;
+   spinlock_t *ptl;
+
+   if (pmd_trans_huge(*pmd))
+   return 0;
+   if (pmd_trans_unstable(pmd))
+   return 0;
+
+   pte = pte_offset_map_lock(walk->mm, pmd, addr, );
+   for (; addr != end; pte++, addr += PAGE_SIZE) {
+   if (!pte_present(*pte)) {
+   swp_entry_t vrange_entry = pte_to_swp_entry(*pte);
+
+   if (unlikely(is_vpurged_entry(vrange_entry))) {
+   vw->page_was_purged = 1;
+   break;
+   }
+   }
+   }
+   pte_unmap_unlock(pte - 1, ptl);
+   cond_resched();
+
+   return 0;
+}
+
+
+/**
+ * vrange_check_purged - Sets up a mm_walk to check for purged pages
+ *
+ * Sets up and calls wa_page_range() to check for purge pages.
+ *
+ * Returns 1 if pages in the range were purged, 0 otherwise.
+ */
+static int vrange_check_purged(struct mm_struct *mm,
+struct vm_area_struct *vma,
+unsigned long start,
+unsigned long end)
+{
+   struct vrange_walker vw;
+   struct mm_walk vrange_walk = {
+   .pmd_entry = vrange_check_purged_pte,
+   .mm = vma->vm_mm,
+   .private = ,
+   };
+   vw.page_was_purged = 0;
+   vw.vma = vma;
+
+   walk_page_range(start, end, _walk);
+
+   return vw.page_was_purged;
+
+}
 
 /**
  * do_vrange - Marks or clears VMAs in the 

[PATCH 1/5] vrange: Add vrange syscall and handle splitting/merging and marking vmas

[John Stultz]

This patch introduces the vrange() syscall, which allows for specifying
ranges of memory as volatile, and able to be discarded by the system.

This initial patch simply adds the syscall, and the vma handling,
splitting and merging the vmas as needed, and marking them with
VM_VOLATILE.

No purging or discarding of volatile ranges is done at this point.

Example man page:

NAME
vrange - Mark or unmark range of memory as volatile

SYNOPSIS
ssize_t vrange(unsigned_long start, size_t length,
 unsigned_long mode, unsigned_long flags,
 int *purged);

DESCRIPTION
Applications can use vrange(2) to advise kernel that pages of
anonymous mapping in the given VM area can be reclaimed without
swapping (or can no longer be reclaimed without swapping).
The idea is that application can help kernel with page reclaim
under memory pressure by specifying data it can easily regenerate
and thus kernel can discard the data if needed.

mode:
VRANGE_VOLATILE
Informs the kernel that the VM can discard in pages in
the specified range when under memory pressure.
VRANGE_NONVOLATILE
Informs the kernel that the VM can no longer discard pages
in this range.

flags: Currently no flags are supported.

purged: Pointer to an integer which will return 1 if
mode == VRANGE_NONVOLATILE and any page in the affected range
was purged. If purged returns zero during a mode ==
VRANGE_NONVOLATILE call, it means all of the pages in the range
are intact.

If a process accesses volatile memory which has been purged, and
was not set as non volatile via a VRANGE_NONVOLATILE call, it
will recieve a SIGBUS.

RETURN VALUE
On success vrange returns the number of bytes marked or unmarked.
Similar to write(), it may return fewer bytes then specified
if it ran into a problem.

When using VRANGE_NON_VOLATILE, if the return value is smaller
then the specified length, then the value specified by the purged
pointer will be set to 1 if any of the pages specified in the
return value as successfully marked non-volatile had been purged.

If an error is returned, no changes were made.

ERRORS
EINVAL This error can occur for the following reasons:
* The value length is negative or not page size units.
* addr is not page-aligned
* mode not a valid value.
* flags is not a valid value.

ENOMEM Not enough memory

ENOMEM Addresses in the specified range are not currently mapped,
   or are outside the address space of the process.

EFAULT Purged pointer is invalid

This a simplified implementation which reuses some of the logic
from Minchan's earlier efforts. So credit to Minchan for his work.

Cc: Andrew Morton 
Cc: Android Kernel Team 
Cc: Johannes Weiner 
Cc: Robert Love 
Cc: Mel Gorman 
Cc: Hugh Dickins 
Cc: Dave Hansen 
Cc: Rik van Riel 
Cc: Dmitry Adamushko 
Cc: Neil Brown 
Cc: Andrea Arcangeli 
Cc: Mike Hommey 
Cc: Taras Glek 
Cc: Jan Kara 
Cc: KOSAKI Motohiro 
Cc: Michel Lespinasse 
Cc: Minchan Kim 
Cc: linux...@kvack.org 
Signed-off-by: John Stultz 
---
 arch/x86/syscalls/syscall_64.tbl |   1 +
 include/linux/mm.h   |   1 +
 include/linux/vrange.h   |   8 ++
 mm/Makefile  |   2 +-
 mm/vrange.c  | 173 +++
 5 files changed, 184 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/vrange.h
 create mode 100644 mm/vrange.c

diff --git a/arch/x86/syscalls/syscall_64.tbl b/arch/x86/syscalls/syscall_64.tbl
index a12bddc..7ae3940 100644
--- a/arch/x86/syscalls/syscall_64.tbl
+++ b/arch/x86/syscalls/syscall_64.tbl
@@ -322,6 +322,7 @@
 313common  finit_modulesys_finit_module
 314common  sched_setattr   sys_sched_setattr
 315common  sched_getattr   sys_sched_getattr
+316common  vrange  sys_vrange
 
 #
 # x32-specific system call numbers start at 512 to avoid cache impact
diff --git a/include/linux/mm.h b/include/linux/mm.h
index c1b7414..a1f11da 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -117,6 +117,7 @@ extern unsigned int kobjsize(const void *objp);
 #define VM_IO   0x4000 /* Memory mapped I/O or similar */
 
/* Used by sys_madvise() */
+#define VM_VOLATILE0x1000  /* VMA is volatile */
 #define VM_SEQ_READ0x8000  /* App will access data sequentially */
 #define VM_RAND_READ   0x0001  /* App will not benefit from clustered 
reads */
 
diff --git a/include/linux/vrange.h b/include/linux/vrange.h
new file mode 100644
index 000..6e5331e
--- /dev/null
+++ b/include/linux/vrange.h

[PATCH 0/5] Volatile Ranges (v12) & LSF-MM discussion fodder

[John Stultz]

Just wanted to send out an updated patch set that includes changes from
some of the reviews. Hopefully folks will have some time to look them
over prior to the LSF-MM discussion on volatile ranges on Tuesday (see
below for LSF-MM discussion points to think about).

New changes are:

o Added flags argument to the syscall, which is unused, but per
  https://lwn.net/Articles/585415/ seems like a good idea.
o Minor vma traversing cleanups suggested by Jan
o Return an error when trying to mark unmapped regions
o First pass implementation of marking pages referenced when
  they are marked volatile, so the pages in a range are set to
  the same "age" and will be approximately purged together.
  This behavior is still open for discussion.
o Very naive implementation of anonymous page aging on swapless
  systems. This has clear performance issues, as we burn time
  overly scanning anonymous pages, but provides something
  concrete upon which to discuss what the best way would be to
  solve this.
o Other minor code cleanups

The first three patches are still the core functionality, which
I'd really like further review on. The last two patches in this
series are more discussion starters, and are less serious.


Potential discussion items for LSF-MM to think about:

o How to increase reviewer interest?
- Lots of interest from application world
o Page aging semantics when marking volatile.
- Should marking volatile be the same as accessing pages?
- Should volatile ranges be put on end of inactive lru?
- Should we just punt this and have applications combine madvise()
  use with vrange() to specify range age?
o Volatile page & purged page accounting
- Volatility is stored in per-process vma, not page
- vmstats are page based, how do we deal w/ COWed pages?
o Aging anonymous memory on swapless systems
- Any thoughts on improving over naive method?
- Better volatile page accounting might help?
- Do we need a separate volatile LRU?
o Shared volatility on tmpfs/shm/memfd (required for ashmem)
- Johannes idea for clearing dirty bits?
- vma-like structure on the address space?

thanks
-john


Volatile ranges provides a method for userland to inform the kernel that
a range of memory is safe to discard (ie: can be regenerated) but
userspace may want to try access it in the future.  It can be thought of
as similar to MADV_DONTNEED, but that the actual freeing of the memory
is delayed and only done under memory pressure, and the user can try to
cancel the action and be able to quickly access any unpurged pages. The
idea originated from Android's ashmem, but I've since learned that other
OSes provide similar functionality.

This functionality allows for a number of interesting uses. One such
example is: Userland caches that have kernel triggered eviction under
memory pressure. This allows for the kernel to "rightsize" userspace
caches for current system-wide workload. Things like image bitmap
caches, or rendered HTML in a hidden browser tab, where the data is
not visible and can be regenerated if needed, are good examples.

Both Chrome and Firefox already make use of volatile ranges via the
ashmem interface:
https://hg.mozilla.org/releases/mozilla-b2g28_v1_3t/rev/a32c32b24a34

https://chromium.googlesource.com/chromium/src/base/+/47617a69b9a57796935e03d78931bd01b4806e70/memory/discardable_memory_allocator_android.cc


There are two basic ways volatile ranges can be used:

Explicit marking method:
1) Userland marks a range of memory that can be regenerated if necessary
as volatile
2) Before accessing the memory again, userland marks the memory as
nonvolatile, and the kernel will provide notification if any pages in the
range has been purged.

Optimistic method:
1) Userland marks a large range of data as volatile
2) Userland continues to access the data as it needs.
3) If userland accesses a page that has been purged, the kernel will
send a SIGBUS
4) Userspace can trap the SIGBUS, mark the affected pages as
non-volatile, and refill the data as needed before continuing on


You can read more about the history of volatile ranges here (~reverse
chronological order):
https://lwn.net/Articles/590991/
http://permalink.gmane.org/gmane.linux.kernel.mm/98848
http://permalink.gmane.org/gmane.linux.kernel.mm/98676
https://lwn.net/Articles/522135/
https://lwn.net/Kernel/Index/#Volatile_ranges


Continuing from the last release, this revision is reduced in scope
when compared to earlier attempts. I've only focused on handled
volatility on anonymous memory, and we're storing the volatility in
the VMA.  This may have performance implications compared with the earlier
approach, but it does simplify the approach. I'm open to expanding
functionality via flags arugments, but for now I'm wanting to keep focus
on what the right default behavior should be and keep the use cases
restricted to help get reviewer interest.

Further, the page 

Re: [PATCH 9/9] powerpc/pm: support deep sleep feature on T1040

[Scott Wood]

On Fri, 2014-03-21 at 09:21 +, David Laight wrote:
> From: Scott Wood [mailto:scottw...@freescale.com]
> > On Thu, 2014-03-20 at 11:59 +, David Laight wrote:
> > > I tried to work out what the 'twi, isync' instructions were for (in 
> > > in_le32()).
> > > The best I could come up with was to ensure a synchronous bus-fault.
> > > But bus faults are probably only expected during device probing - not
> > > normal operation, and the instructions will have a significant cost.
> > >
> > > Additionally in_le32() and out_le32() both start with a 'sync' 
> > > instruction.
> > > In many cases that isn't needed either - an explicit iosync() can be
> > > used after groups of instructions.
> > 
> > The idea is that it's better to be maximally safe by default, and let
> > performance critical sections be optimized using raw accessors and
> > explicit synchronization if needed, than to have hard-to-debug bugs due
> > to missing/wrong sync.  A lot of I/O is slow enough that the performance
> > impact doesn't really matter, but the brain-time cost of getting the
> > sync right is still there.
> 
> Hmmm
> 
> That might be an excuse for the 'sync', but not the twi and isync.

That might be true if I/O is always cache inhibited and guarded, in
which case I think we can rely on that to ensure that the load has
completed before we do things like wrtee or rfi.  In any case, I'd want
to hear Ben's explanation.

> I was setting up a dma request (for the ppc 83xx PCIe bridge) and
> was doing back to back little-endian writes into memory.
> I had difficulty finding and including header files containing
> the definitions for byteswapped accesses I needed.
> arch/powerpc/include/asm/swab.h contains some - but I couldn't
> work out how to get it included (apart from giving the full path).
> 
> In any case you need to understand when synchronisation is
> required - otherwise you will get it wrong.
> Especially since non-byteswapped accesses are done by direct
> access.

Yes, it's bad that rawness combines the lack of byteswapping with the
lack of synchronization.  Ideally the raw accessors would also come in
big and little endian form, plus a native endian form if it's really
needed.

-Scott


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 1/8] x86: move FIX_EARLYCON_MEM kconfig into x86

[Rob Herring]

From: Rob Herring 

In preparation to support FIX_EARLYCON_MEM on other arches, make the
option per arch.

Signed-off-by: Rob Herring 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
---
 arch/x86/Kconfig| 3 +++
 drivers/tty/serial/8250/Kconfig | 5 -
 2 files changed, 3 insertions(+), 5 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 9c0a657..600046c 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -261,6 +261,9 @@ config ARCH_HWEIGHT_CFLAGS
 config ARCH_SUPPORTS_UPROBES
def_bool y
 
+config FIX_EARLYCON_MEM
+   def_bool y
+
 source "init/Kconfig"
 source "kernel/Kconfig.freezer"
 
diff --git a/drivers/tty/serial/8250/Kconfig b/drivers/tty/serial/8250/Kconfig
index 2332991..91f1d83 100644
--- a/drivers/tty/serial/8250/Kconfig
+++ b/drivers/tty/serial/8250/Kconfig
@@ -90,11 +90,6 @@ config SERIAL_8250_CONSOLE
 
  If unsure, say N.
 
-config FIX_EARLYCON_MEM
-   bool
-   depends on X86
-   default y
-
 config SERIAL_8250_GSC
tristate
depends on SERIAL_8250 && GSC
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 0/8] Generic serial earlycon

[Rob Herring]

From: Rob Herring 

This started out as an attempt to add arm64's earlyprintk support to ARM
in order to get an earlier, runtime setup console on multi-platform
kernels. The first issue was needing the fixmap support which
conveniently Mark Salter was working on and is mostly in place now. Like
many things on ARM and arm64 now, it then became where do I put the now
common, shared code. After digging more into various early console/printk
support, it turns out the 8250_early.c setup code was the best starting
point. 

This is based on Mark Salter's fixmap support currently in linux-next.
This is tested on arm64 and ARM with pl011 and 8250. The ARM support
also requires fixmap and fixed mapping support which are not yet in place.
I have some patches in my tree to support fixmap, but they need some more
work. Fortunately, once fixmap is in place, it is just a Kconfig option
to enable earlycon support on ARM. A git tree is available here[1].

Based on this series, I would like to add support for doing earlycon
setup using DT.

Rob

[1] git://git.kernel.org/pub/scm/linux/kernel/git/robh/linux.git earlycon

Rob Herring (8):
  x86: move FIX_EARLYCON_MEM kconfig into x86
  arm64: add FIXMAP_PAGE_NOCACHE definition
  arm64: enable FIX_EARLYCON_MEM kconfig
  tty/serial: add generic serial earlycon
  tty/serial: convert 8250 to generic earlycon
  tty/serial: pl011: add generic earlycon support
  tty/serial: add arm64 semihosting earlycon
  arm64: remove arch specific earlyprintk

 Documentation/kernel-parameters.txt|   6 +-
 arch/arm64/Kconfig |   3 +
 arch/arm64/Kconfig.debug   |   9 --
 arch/arm64/include/asm/fixmap.h|   3 +-
 arch/arm64/kernel/Makefile |   1 -
 arch/arm64/kernel/early_printk.c   | 158 -
 arch/x86/Kconfig   |   3 +
 drivers/tty/serial/8250/8250_early.c   | 138 +++--
 drivers/tty/serial/8250/Kconfig|   5 -
 drivers/tty/serial/Kconfig |  24 -
 drivers/tty/serial/Makefile|   3 +
 drivers/tty/serial/amba-pl011.c|  30 +-
 drivers/tty/serial/earlycon-arm-semihost.c |  44 
 drivers/tty/serial/earlycon.c  | 148 +++
 include/linux/serial_core.h|  16 +++
 15 files changed, 287 insertions(+), 304 deletions(-)
 delete mode 100644 arch/arm64/kernel/early_printk.c
 create mode 100644 drivers/tty/serial/earlycon-arm-semihost.c
 create mode 100644 drivers/tty/serial/earlycon.c

-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 5/8] tty/serial: convert 8250 to generic earlycon

[Rob Herring]

From: Rob Herring 

With the generic earlycon infrastructure in place, convert the 8250
early console to use it.

Signed-off-by: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
---
 drivers/tty/serial/8250/8250_early.c | 138 ---
 1 file changed, 15 insertions(+), 123 deletions(-)

diff --git a/drivers/tty/serial/8250/8250_early.c 
b/drivers/tty/serial/8250/8250_early.c
index c100d63..e83c9db 100644
--- a/drivers/tty/serial/8250/8250_early.c
+++ b/drivers/tty/serial/8250/8250_early.c
@@ -35,18 +35,8 @@
 #include 
 #include 
 #include 
-#ifdef CONFIG_FIX_EARLYCON_MEM
-#include 
-#include 
-#endif
 
-struct early_serial8250_device {
-   struct uart_port port;
-   char options[16];   /* e.g., 115200n8 */
-   unsigned int baud;
-};
-
-static struct early_serial8250_device early_device;
+static struct earlycon_device *early_device;
 
 unsigned int __weak __init serial8250_early_in(struct uart_port *port, int 
offset)
 {
@@ -100,7 +90,7 @@ static void __init serial_putc(struct uart_port *port, int c)
 static void __init early_serial8250_write(struct console *console,
const char *s, unsigned int count)
 {
-   struct uart_port *port = _device.port;
+   struct uart_port *port = _device->port;
unsigned int ier;
 
/* Save the IER and disable interrupts */
@@ -129,7 +119,7 @@ static unsigned int __init probe_baud(struct uart_port 
*port)
return (port->uartclk / 16) / quot;
 }
 
-static void __init init_port(struct early_serial8250_device *device)
+static void __init init_port(struct earlycon_device *device)
 {
struct uart_port *port = >port;
unsigned int divisor;
@@ -148,128 +138,32 @@ static void __init init_port(struct 
early_serial8250_device *device)
serial8250_early_out(port, UART_LCR, c & ~UART_LCR_DLAB);
 }
 
-static int __init parse_options(struct early_serial8250_device *device,
-   char *options)
-{
-   struct uart_port *port = >port;
-   int mmio, mmio32, length;
-
-   if (!options)
-   return -ENODEV;
-
-   port->uartclk = BASE_BAUD * 16;
-
-   mmio = !strncmp(options, "mmio,", 5);
-   mmio32 = !strncmp(options, "mmio32,", 7);
-   if (mmio || mmio32) {
-   port->iotype = (mmio ? UPIO_MEM : UPIO_MEM32);
-   port->mapbase = simple_strtoul(options + (mmio ? 5 : 7),
-  , 0);
-   if (mmio32)
-   port->regshift = 2;
-#ifdef CONFIG_FIX_EARLYCON_MEM
-   set_fixmap_nocache(FIX_EARLYCON_MEM_BASE,
-   port->mapbase & PAGE_MASK);
-   port->membase =
-   (void __iomem *)__fix_to_virt(FIX_EARLYCON_MEM_BASE);
-   port->membase += port->mapbase & ~PAGE_MASK;
-#else
-   port->membase = ioremap_nocache(port->mapbase, 64);
-   if (!port->membase) {
-   printk(KERN_ERR "%s: Couldn't ioremap 0x%llx\n",
-   __func__,
-  (unsigned long long) port->mapbase);
-   return -ENOMEM;
-   }
-#endif
-   } else if (!strncmp(options, "io,", 3)) {
-   port->iotype = UPIO_PORT;
-   port->iobase = simple_strtoul(options + 3, , 0);
-   mmio = 0;
-   } else
-   return -EINVAL;
-
-   options = strchr(options, ',');
-   if (options) {
-   options++;
-   device->baud = simple_strtoul(options, NULL, 0);
-   length = min(strcspn(options, " ") + 1,
-(size_t)(sizeof(device->options)));
-   strlcpy(device->options, options, length);
-   } else {
-   device->baud = probe_baud(port);
-   snprintf(device->options, sizeof(device->options), "%u",
-   device->baud);
-   }
-
-   if (mmio || mmio32)
-   printk(KERN_INFO
-  "Early serial console at MMIO%s 0x%llx (options '%s')\n",
-   mmio32 ? "32" : "",
-   (unsigned long long)port->mapbase,
-   device->options);
-   else
-   printk(KERN_INFO
- "Early serial console at I/O port 0x%lx (options '%s')\n",
-   port->iobase,
-   device->options);
-
-   return 0;
-}
-
-static struct console early_serial8250_console __initdata = {
-   .name   = "uart",
-   .write  = early_serial8250_write,
-   .flags  = CON_PRINTBUFFER | CON_BOOT,
-   .index  = -1,
-};
-
-static int __init early_serial8250_setup(char *options)
+static int __init early_serial8250_setup(struct earlycon_device *device,
+const char *options)
 {
-   struct 

[PATCH 6/8] tty/serial: pl011: add generic earlycon support

[Rob Herring]

From: Rob Herring 

Add earlycon support for the pl011 serial port. This allows enabling
the pl011 for console when early_params are processed. This is based
on the arm64 earlyprintk support and is intended to replace it.

Signed-off-by: Rob Herring 
Cc: Russell King 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
---
 Documentation/kernel-parameters.txt |  5 +++--
 drivers/tty/serial/amba-pl011.c | 30 +-
 2 files changed, 32 insertions(+), 3 deletions(-)

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 5ce8b7a..81bdd52 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -887,8 +887,9 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
uart[8250],io,[,options]
uart[8250],mmio,[,options]
uart[8250],mmio32,[,options]
-   Start an early, polled-mode console on the 8250/16550
-   UART at the specified I/O port or MMIO address.
+   pl011,
+   Start an early, polled-mode console on a serial port
+   at the specified I/O port or MMIO address. 8250
MMIO inter-register address stride is either 8-bit
(mmio) or 32-bit (mmio32).
The options are the same as for ttyS, above.
diff --git a/drivers/tty/serial/amba-pl011.c b/drivers/tty/serial/amba-pl011.c
index d4eda24..4227c0a 100644
--- a/drivers/tty/serial/amba-pl011.c
+++ b/drivers/tty/serial/amba-pl011.c
@@ -303,7 +303,7 @@ static void pl011_dma_probe_initcall(struct device *dev, 
struct uart_amba_port *
 
/* Optionally make use of an RX channel as well */
chan = dma_request_slave_channel(dev, "rx");
-   
+
if (!chan && plat->dma_rx_param) {
chan = dma_request_channel(mask, plat->dma_filter, 
plat->dma_rx_param);
 
@@ -2045,6 +2045,34 @@ static struct console amba_console = {
 };
 
 #define AMBA_CONSOLE   (_console)
+
+static void pl011_putc(struct uart_port *port, int c)
+{
+   while (readl(port->membase + UART01x_FR) & UART01x_FR_TXFF)
+   ;
+   writeb(c, port->membase + UART01x_DR);
+   while (readl(port->membase + UART01x_FR) & UART01x_FR_BUSY)
+   ;
+}
+
+static void pl011_early_write(struct console *con, const char *s, unsigned n)
+{
+   struct earlycon_device *dev = con->data;
+
+   uart_console_write(>port, s, n, pl011_putc);
+}
+
+static int __init pl011_early_console_setup(struct earlycon_device *device,
+   const char *opt)
+{
+   if (!device->port.membase)
+   return -ENODEV;
+
+   device->con->write = pl011_early_write;
+   return 0;
+}
+EARLYCON_DECLARE(pl011, pl011_early_console_setup);
+
 #else
 #define AMBA_CONSOLE   NULL
 #endif
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 8/8] arm64: remove arch specific earlyprintk

[Rob Herring]

From: Rob Herring 

Now that we have equivalent earlycon support, arm64's earlyprintk code
can be removed.

Signed-off-by: Rob Herring 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Kconfig.debug |   9 ---
 arch/arm64/kernel/Makefile   |   1 -
 arch/arm64/kernel/early_printk.c | 158 ---
 3 files changed, 168 deletions(-)
 delete mode 100644 arch/arm64/kernel/early_printk.c

diff --git a/arch/arm64/Kconfig.debug b/arch/arm64/Kconfig.debug
index 835c5597..7d7fb6f 100644
--- a/arch/arm64/Kconfig.debug
+++ b/arch/arm64/Kconfig.debug
@@ -6,15 +6,6 @@ config FRAME_POINTER
bool
default y
 
-config EARLY_PRINTK
-   bool "Early printk support"
-   default y
-   help
- Say Y here if you want to have an early console using the
- earlyprintk=[,][,] kernel parameter. It
- is assumed that the early console device has been initialised
- by the boot loader prior to starting the Linux kernel.
-
 config PID_IN_CONTEXTIDR
bool "Write the current PID to the CONTEXTIDR register"
help
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 7d811d9..7a6fce5 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,7 +18,6 @@ arm64-obj-$(CONFIG_SMP)   += smp.o 
smp_spin_table.o topology.o
 arm64-obj-$(CONFIG_PERF_EVENTS)+= perf_regs.o
 arm64-obj-$(CONFIG_HW_PERF_EVENTS) += perf_event.o
 arm64-obj-$(CONFIG_HAVE_HW_BREAKPOINT) += hw_breakpoint.o
-arm64-obj-$(CONFIG_EARLY_PRINTK)   += early_printk.o
 arm64-obj-$(CONFIG_ARM64_CPU_SUSPEND)  += sleep.o suspend.o
 arm64-obj-$(CONFIG_JUMP_LABEL) += jump_label.o
 arm64-obj-$(CONFIG_KGDB)   += kgdb.o
diff --git a/arch/arm64/kernel/early_printk.c b/arch/arm64/kernel/early_printk.c
deleted file mode 100644
index ffbbdde..000
--- a/arch/arm64/kernel/early_printk.c
+++ /dev/null
@@ -1,158 +0,0 @@
-/*
- * Earlyprintk support.
- *
- * Copyright (C) 2012 ARM Ltd.
- * Author: Catalin Marinas 
- *
- * This program is free software: you can redistribute it and/or modify
- * it under the terms of the GNU General Public License version 2 as
- * published by the Free Software Foundation.
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU General Public License for more details.
- *
- * You should have received a copy of the GNU General Public License
- * along with this program.  If not, see .
- */
-#include 
-#include 
-#include 
-#include 
-#include 
-#include 
-
-#include 
-#include 
-
-#include 
-
-static void __iomem *early_base;
-static void (*printch)(char ch);
-
-/*
- * PL011 single character TX.
- */
-static void pl011_printch(char ch)
-{
-   while (readl_relaxed(early_base + UART01x_FR) & UART01x_FR_TXFF)
-   ;
-   writeb_relaxed(ch, early_base + UART01x_DR);
-   while (readl_relaxed(early_base + UART01x_FR) & UART01x_FR_BUSY)
-   ;
-}
-
-/*
- * Semihosting-based debug console
- */
-static void smh_printch(char ch)
-{
-   asm volatile("mov  x1, %0\n"
-"mov  x0, #3\n"
-"hlt  0xf000\n"
-: : "r" () : "x0", "x1", "memory");
-}
-
-/*
- * 8250/16550 (8-bit aligned registers) single character TX.
- */
-static void uart8250_8bit_printch(char ch)
-{
-   while (!(readb_relaxed(early_base + UART_LSR) & UART_LSR_THRE))
-   ;
-   writeb_relaxed(ch, early_base + UART_TX);
-}
-
-/*
- * 8250/16550 (32-bit aligned registers) single character TX.
- */
-static void uart8250_32bit_printch(char ch)
-{
-   while (!(readl_relaxed(early_base + (UART_LSR << 2)) & UART_LSR_THRE))
-   ;
-   writel_relaxed(ch, early_base + (UART_TX << 2));
-}
-
-struct earlycon_match {
-   const char *name;
-   void (*printch)(char ch);
-};
-
-static const struct earlycon_match earlycon_match[] __initconst = {
-   { .name = "pl011", .printch = pl011_printch, },
-   { .name = "smh", .printch = smh_printch, },
-   { .name = "uart8250-8bit", .printch = uart8250_8bit_printch, },
-   { .name = "uart8250-32bit", .printch = uart8250_32bit_printch, },
-   {}
-};
-
-static void early_write(struct console *con, const char *s, unsigned n)
-{
-   while (n-- > 0) {
-   if (*s == '\n')
-   printch('\r');
-   printch(*s);
-   s++;
-   }
-}
-
-static struct console early_console_dev = {
-   .name = "earlycon",
-   .write =early_write,
-   .flags =CON_PRINTBUFFER | CON_BOOT,
-   .index =-1,
-};
-
-/*
- * Parse earlyprintk=... parameter in the format:
- *
- *   [,][,]
- *
- * and register the early console. It is assumed that the UART has been
- * 

[PATCH 2/8] arm64: add FIXMAP_PAGE_NOCACHE definition

[Rob Herring]

From: Rob Herring 

Similar to ioremap and ioremap_nocache, we want the same definition for
both using PROT_DEVICE_nGnRE.

Signed-off-by: Rob Herring 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/include/asm/fixmap.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/include/asm/fixmap.h b/arch/arm64/include/asm/fixmap.h
index 5f7bfe6..68eab3c 100644
--- a/arch/arm64/include/asm/fixmap.h
+++ b/arch/arm64/include/asm/fixmap.h
@@ -54,7 +54,8 @@ enum fixed_addresses {
 #define FIXADDR_SIZE   (__end_of_permanent_fixed_addresses << PAGE_SHIFT)
 #define FIXADDR_START  (FIXADDR_TOP - FIXADDR_SIZE)
 
-#define FIXMAP_PAGE_IO __pgprot(PROT_DEVICE_nGnRE)
+#define FIXMAP_PAGE_IO __pgprot(PROT_DEVICE_nGnRE)
+#define FIXMAP_PAGE_NOCACHE__pgprot(PROT_DEVICE_nGnRE)
 
 extern void __early_set_fixmap(enum fixed_addresses idx,
   phys_addr_t phys, pgprot_t flags);
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 3/8] arm64: enable FIX_EARLYCON_MEM kconfig

[Rob Herring]

From: Rob Herring 

In order to support earlycon on arm64, we need to enable earlycon fixmap
support.

Signed-off-by: Rob Herring 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index e2424f9..a839444 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -112,6 +112,9 @@ config IOMMU_HELPER
 config KERNEL_MODE_NEON
def_bool y
 
+config FIX_EARLYCON_MEM
+   def_bool y
+
 source "init/Kconfig"
 
 source "kernel/Kconfig.freezer"
-- 
1.8.3.2

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[PATCH 4/8] tty/serial: add generic serial earlycon

[Rob Herring]

From: Rob Herring 

This introduces generic earlycon infrastructure for serial devices
based on the 8250 earlycon. This allows for supporting earlycon option
with other serial devices. The earlycon output is enabled at the time
early_params are processed.

Only architectures that have fixmap support or have functional ioremap
when early_params are processed are supported. This is the same
restriction that the 8250 driver had.

Signed-off-by: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
---
 drivers/tty/serial/Kconfig|   7 ++
 drivers/tty/serial/Makefile   |   2 +
 drivers/tty/serial/earlycon.c | 148 ++
 include/linux/serial_core.h   |  16 +
 4 files changed, 173 insertions(+)
 create mode 100644 drivers/tty/serial/earlycon.c

diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 2e6d8dd..1685189 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -7,6 +7,13 @@ if TTY
 menu "Serial drivers"
depends on HAS_IOMEM
 
+config SERIAL_EARLYCON
+   bool "Early console for serial ports"
+   help
+ Support for early consoles with the earlycon parameter. This enables
+ the console before standard serial driver is probed. The console is
+ enabled when early_param is processed.
+
 source "drivers/tty/serial/8250/Kconfig"
 
 comment "Non-8250 serial port support"
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 3680854..8af1415 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -5,6 +5,8 @@
 obj-$(CONFIG_SERIAL_CORE) += serial_core.o
 obj-$(CONFIG_SERIAL_21285) += 21285.o
 
+obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
+
 # These Sparc drivers have to appear before others such as 8250
 # which share ttySx minor node space.  Otherwise console device
 # names change and other unplesantries.
diff --git a/drivers/tty/serial/earlycon.c b/drivers/tty/serial/earlycon.c
new file mode 100644
index 000..241757a
--- /dev/null
+++ b/drivers/tty/serial/earlycon.c
@@ -0,0 +1,148 @@
+/*
+ * Copyright (C) 2014 Linaro Ltd.
+ * Author: Rob Herring 
+ *
+ * Based on 8250 earlycon:
+ * (c) Copyright 2004 Hewlett-Packard Development Company, L.P.
+ * Bjorn Helgaas 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ */
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include 
+#include 
+
+static struct console early_con = {
+   .name = "earlycon",
+   .flags =CON_PRINTBUFFER | CON_BOOT,
+   .index =-1,
+};
+
+static struct earlycon_device early_console_dev = {
+   .con = _con,
+};
+
+static void __iomem * __init earlycon_map(unsigned long paddr, size_t size)
+{
+   void __iomem *base;
+#ifdef CONFIG_FIX_EARLYCON_MEM
+   set_fixmap_nocache(FIX_EARLYCON_MEM_BASE, paddr & PAGE_MASK);
+   base = (void __iomem *)__fix_to_virt(FIX_EARLYCON_MEM_BASE);
+   base += paddr & ~PAGE_MASK;
+#else
+   base = ioremap_nocache(paddr, size);
+#endif
+   if (!base)
+   pr_err("%s: Couldn't map 0x%llx\n", __func__,
+  (unsigned long long)paddr);
+
+   return base;
+}
+
+static int __init parse_options(struct earlycon_device *device,
+   char *options)
+{
+   struct uart_port *port = >port;
+   int mmio, mmio32, length, ret;
+   unsigned long addr;
+
+   if (!options)
+   return -ENODEV;
+
+   mmio = !strncmp(options, "mmio,", 5);
+   mmio32 = !strncmp(options, "mmio32,", 7);
+   if (mmio || mmio32) {
+   port->iotype = (mmio ? UPIO_MEM : UPIO_MEM32);
+   options += mmio ? 5 : 7;
+   ret = kstrtoul(options, 0, );
+   if (ret)
+   return ret;
+   port->mapbase = addr;
+   if (mmio32)
+   port->regshift = 2;
+   } else if (!strncmp(options, "io,", 3)) {
+   port->iotype = UPIO_PORT;
+   options += 3;
+   ret = kstrtoul(options, 0, );
+   if (ret)
+   return ret;
+   port->iobase = addr;
+   mmio = 0;
+   } else if (!strncmp(options, "0x", 2)) {
+   port->iotype = UPIO_MEM;
+   ret = kstrtoul(options, 0, );
+   if (ret)
+   return ret;
+   port->mapbase = addr;
+   } else {
+   return -EINVAL;
+   }
+
+   if (port->mapbase)
+   port->membase = earlycon_map(port->mapbase, 64);
+
+   port->uartclk = BASE_BAUD * 16;
+
+   options = strchr(options, ',');
+   if (options) {
+   options++;
+   ret = kstrtouint(options, 0, >baud);
+   if (ret)
+   return ret;
+   

[PATCH 7/8] tty/serial: add arm64 semihosting earlycon

[Rob Herring]

From: Rob Herring 

Add earlycon support for the arm64 semihosting debug serial interface.
This allows enabling a debug console when early_params are processed.
This is based on the arm64 earlyprintk smh support and is intended to
replace it.

This is named arm rather than arm64 in hopes it will be used for both,
but only arm64 is supported ATM.

Signed-off-by: Rob Herring 
Cc: Greg Kroah-Hartman 
Cc: Jiri Slaby 
---
 Documentation/kernel-parameters.txt|  1 +
 drivers/tty/serial/Kconfig | 17 +---
 drivers/tty/serial/Makefile|  1 +
 drivers/tty/serial/earlycon-arm-semihost.c | 44 ++
 4 files changed, 59 insertions(+), 4 deletions(-)
 create mode 100644 drivers/tty/serial/earlycon-arm-semihost.c

diff --git a/Documentation/kernel-parameters.txt 
b/Documentation/kernel-parameters.txt
index 81bdd52..e96e2ba 100644
--- a/Documentation/kernel-parameters.txt
+++ b/Documentation/kernel-parameters.txt
@@ -888,6 +888,7 @@ bytes respectively. Such letter suffixes can also be 
entirely omitted.
uart[8250],mmio,[,options]
uart[8250],mmio32,[,options]
pl011,
+   smh
Start an early, polled-mode console on a serial port
at the specified I/O port or MMIO address. 8250
MMIO inter-register address stride is either 8-bit
diff --git a/drivers/tty/serial/Kconfig b/drivers/tty/serial/Kconfig
index 1685189..8b8f40e 100644
--- a/drivers/tty/serial/Kconfig
+++ b/drivers/tty/serial/Kconfig
@@ -14,6 +14,15 @@ config SERIAL_EARLYCON
  the console before standard serial driver is probed. The console is
  enabled when early_param is processed.
 
+config SERIAL_EARLYCON_ARM_SEMIHOST
+   bool "Early console using ARM64 semihosting"
+   depends on ARM64
+   help
+ Support for early debug console using ARM64 semihosting. This enables
+ the console before standard serial driver is probed. This is enabled
+ with "earlycon=smh" on the kernel command line. The console is
+ enabled when early_param is processed.
+
 source "drivers/tty/serial/8250/Kconfig"
 
 comment "Non-8250 serial port support"
@@ -230,7 +239,7 @@ config SERIAL_SAMSUNG_UARTS
help
  Select the number of available UART ports for the Samsung S3C
  serial driver
-   
+
 config SERIAL_SAMSUNG_DEBUG
bool "Samsung SoC serial debug"
depends on SERIAL_SAMSUNG && DEBUG_LL
@@ -666,8 +675,8 @@ config PDC_CONSOLE
depends on PARISC && !SERIAL_MUX && VT
default n
help
- Saying Y here will enable the software based PDC console to be 
- used as the system console.  This is useful for machines in 
+ Saying Y here will enable the software based PDC console to be
+ used as the system console.  This is useful for machines in
  which the hardware based console has not been written yet.  The
  following steps must be competed to use the PDC console:
 
@@ -858,7 +867,7 @@ config SERIAL_CPM
depends on CPM2 || 8xx
select SERIAL_CORE
help
- This driver supports the SCC and SMC serial ports on Motorola 
+ This driver supports the SCC and SMC serial ports on Motorola
  embedded PowerPC that contain a CPM1 (8xx) or CPM2 (8xxx)
 
 config SERIAL_CPM_CONSOLE
diff --git a/drivers/tty/serial/Makefile b/drivers/tty/serial/Makefile
index 8af1415..9965b65 100644
--- a/drivers/tty/serial/Makefile
+++ b/drivers/tty/serial/Makefile
@@ -6,6 +6,7 @@ obj-$(CONFIG_SERIAL_CORE) += serial_core.o
 obj-$(CONFIG_SERIAL_21285) += 21285.o
 
 obj-$(CONFIG_SERIAL_EARLYCON) += earlycon.o
+obj-$(CONFIG_SERIAL_EARLYCON_ARM_SEMIHOST) += earlycon-arm-semihost.o
 
 # These Sparc drivers have to appear before others such as 8250
 # which share ttySx minor node space.  Otherwise console device
diff --git a/drivers/tty/serial/earlycon-arm-semihost.c 
b/drivers/tty/serial/earlycon-arm-semihost.c
new file mode 100644
index 000..fecec9a
--- /dev/null
+++ b/drivers/tty/serial/earlycon-arm-semihost.c
@@ -0,0 +1,44 @@
+/*
+ * Copyright (C) 2012 ARM Ltd.
+ * Author: Catalin Marinas 
+ *
+ * This program is free software: you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#include 
+#include 
+#include 
+#include 
+
+/*
+ * Semihosting-based debug console
+ */
+static void smh_putc(struct uart_port *port, int c)
+{

[PATCH] media: em28xx-video - change em28xx_scaler_set() to use em28xx_reg_len()

[Shuah Khan]

Change em28xx_scaler_set() to use em28xx_reg_len() to get register
lengths for EM28XX_R30_HSCALELOW and EM28XX_R32_VSCALELOW registers,
instead of hard-coding the length. Moved em28xx_reg_len() definition
for it to be visible to em28xx_scaler_set().

Signed-off-by: Shuah Khan 
---
 drivers/media/usb/em28xx/em28xx-video.c |   29 -
 1 file changed, 16 insertions(+), 13 deletions(-)

diff --git a/drivers/media/usb/em28xx/em28xx-video.c 
b/drivers/media/usb/em28xx/em28xx-video.c
index 19af6b3..f8a91de 100644
--- a/drivers/media/usb/em28xx/em28xx-video.c
+++ b/drivers/media/usb/em28xx/em28xx-video.c
@@ -272,6 +272,18 @@ static void em28xx_capture_area_set(struct em28xx *dev, u8 
hstart, u8 vstart,
}
 }
 
+static int em28xx_reg_len(int reg)
+{
+   switch (reg) {
+   case EM28XX_R40_AC97LSB:
+   case EM28XX_R30_HSCALELOW:
+   case EM28XX_R32_VSCALELOW:
+   return 2;
+   default:
+   return 1;
+   }
+}
+
 static int em28xx_scaler_set(struct em28xx *dev, u16 h, u16 v)
 {
u8 mode;
@@ -284,11 +296,13 @@ static int em28xx_scaler_set(struct em28xx *dev, u16 h, 
u16 v)
 
buf[0] = h;
buf[1] = h >> 8;
-   em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf, 2);
+   em28xx_write_regs(dev, EM28XX_R30_HSCALELOW, (char *)buf,
+ em28xx_reg_len(EM28XX_R30_HSCALELOW));
 
buf[0] = v;
buf[1] = v >> 8;
-   em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf, 2);
+   em28xx_write_regs(dev, EM28XX_R32_VSCALELOW, (char *)buf,
+ em28xx_reg_len(EM28XX_R32_VSCALELOW));
/* it seems that both H and V scalers must be active
   to work correctly */
mode = (h || v) ? 0x30 : 0x00;
@@ -1583,17 +1597,6 @@ static int vidioc_g_chip_info(struct file *file, void 
*priv,
return 0;
 }
 
-static int em28xx_reg_len(int reg)
-{
-   switch (reg) {
-   case EM28XX_R40_AC97LSB:
-   case EM28XX_R30_HSCALELOW:
-   case EM28XX_R32_VSCALELOW:
-   return 2;
-   default:
-   return 1;
-   }
-}
 
 static int vidioc_g_register(struct file *file, void *priv,
 struct v4l2_dbg_register *reg)
-- 
1.7.10.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH v2] initramfs: print error and shell out for unsupported content

[Andrew Morton]

On Thu, 20 Mar 2014 23:00:45 +0100 Alexander Holler  
wrote:

> The initramfs generation is broken for file and directory names which contain
> colons or spaces. Print an error and don't try to continue.
> 
> Tests:
> 
> cd linux
> make defconfig
> echo 'CONFIG_BLK_DEV_INITRD=y' >> .config
> echo 'CONFIG_INITRAMFS_ROOT_UID=0' >>.config
> echo 'CONFIG_INITRAMFS_ROOT_GID=0' >>.config
> echo 'CONFIG_INITRAMFS_COMPRESSION_NONE=y' >>.config
> echo 'CONFIG_INITRAMFS_SOURCE="/tmp/bugroot"' >>.config
> 
> Problem with colons:
> 
> mkdir -p /tmp/bugroot/a:b
> make -j4 bzImage # no error
> make bzImage # try again, oops
> 
> Problem with spaces:
> 
> mkdir -p /tmp/bugroot/a\ b
> make -j4 bzImage # no error
> zcat usr/initramfs_data.cpio.gz | cpio --extract --list # oops, no content
> 
> ...
>
> --- a/scripts/gen_initramfs_list.sh
> +++ b/scripts/gen_initramfs_list.sh
> @@ -171,6 +171,18 @@ dir_filelist() {
>   ${dep_list}header "$1"
>  
>   srcdir=$(echo "$1" | sed -e 's://*:/:g')
> +
> + # Files and directories with spaces and colons are unsupported.
> + local unsupported=$(find "${srcdir}" -regex '.*\(:\| \).*')
> + if [ ! -z "${unsupported}" ]; then
> + printf "ERROR: Unable to handle files/directories with " >&2
> + printf "unsupported characters (spaces and colons).\n" >&2
> + printf "Please use other ways to generate a cpio-archive. " >&2
> + printf "Unsupported files and directories are:\n" >&2
> + printf "$unsupported\n" >&2
> + exit 1
> + fi
> +

It would be better to fix the it-doesnt-work-with-all-filenames bug. 
Any details on that?

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH] Add quirk HID_QUIRK_NO_INIT_REPORTS for RNDPLUS touchscreen

[Benjamin Tissoires]

On Fri, Mar 21, 2014 at 3:39 PM, Yufeng Shen  wrote:
> There is timeout error during initialization:
> kernel: [   14.167086] hid-multitouch 0003:2512:5003.0001: 
> usb_submit_urb(ctrl) failed: -1
> kernel: [   14.167135] hid-multitouch 0003:2512:5003.0001: timeout 
> initializing reports
> kernel: [   14.167407] input: RNDPLUS Co., LTD   PULSEIR TSR4601 as 
> /devices/pci:00/:00:1d.0/usb2/2-1/2-1.3/2-1.3:1.0/input/input14
> kernel: [   14.167975] cpufreq_interactive: monitoring input on RNDPLUS Co., 
> LTD   PULSEIR TSR4601
> kernel: [   14.168266] hid-multitouch 0003:2512:5003.0001: 
> input,hiddev0,hidraw1: USB HID v1.10 Mouse [RNDPLUS Co., LTD   PULSEIR 
> TSR4601] on usb-:00:1d.0-1.3/input0
>
> Adding quirk HID_QUIRK_NO_INIT_REPORTS can solve the problem.

I already asked you to test if HID_QUIRK_NO_INIT_INPUT_REPORTS was
working for the same same kind of timeout
(https://patchwork.kernel.org/patch/3544281/).

So I am asking again: please test HID_QUIRK_NO_INIT_INPUT_REPORTS and
if it works, use this quirk instead the one in this patch.
This *really* matters because the quirk HID_QUIRK_NO_INIT_REPORTS does
not initialize feature reports which contains important information
regarding hid-multitouch.

Cheers,
Benjamin

>
> Signed-off-by: Yufeng Shen 
> ---
>  drivers/hid/hid-ids.h   | 5 +
>  drivers/hid/usbhid/hid-quirks.c | 3 +++
>  2 files changed, 8 insertions(+)
>
> diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
> index f9304cb..772f937 100644
> --- a/drivers/hid/hid-ids.h
> +++ b/drivers/hid/hid-ids.h
> @@ -442,6 +442,11 @@
>  #define USB_DEVICE_ID_IDEACOM_IDC6650  0x6650
>  #define USB_DEVICE_ID_IDEACOM_IDC6651  0x6651
>
> +#define USB_VENDOR_ID_IDSPULSE  0x2512
> +#define USB_DEVICE_ID_IDSPULSE_EVIR10x5003
> +#define USB_DEVICE_ID_IDSPULSE_EVIR20x5004
> +#define USB_DEVICE_ID_IDSPULSE_EVIR30x5005
> +
>  #define USB_VENDOR_ID_ILITEK   0x222a
>  #define USB_DEVICE_ID_ILITEK_MULTITOUCH0x0001
>
> diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
> index 0db9a67..e59ad07 100644
> --- a/drivers/hid/usbhid/hid-quirks.c
> +++ b/drivers/hid/usbhid/hid-quirks.c
> @@ -72,6 +72,9 @@ static const struct hid_blacklist {
> { USB_VENDOR_ID_ELO, USB_DEVICE_ID_ELO_TS2700, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_FORMOSA, USB_DEVICE_ID_FORMOSA_IR_RECEIVER, 
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_FREESCALE, USB_DEVICE_ID_FREESCALE_MX28, 
> HID_QUIRK_NOGET },
> +   { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR1, 
> HID_QUIRK_NO_INIT_REPORTS },
> +   { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR2, 
> HID_QUIRK_NO_INIT_REPORTS },
> +   { USB_VENDOR_ID_IDSPULSE, USB_DEVICE_ID_IDSPULSE_EVIR3, 
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_MGE, USB_DEVICE_ID_MGE_UPS, HID_QUIRK_NOGET },
> { USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GX680R_LED_PANEL, 
> HID_QUIRK_NO_INIT_REPORTS },
> { USB_VENDOR_ID_NOVATEK, USB_DEVICE_ID_NOVATEK_MOUSE, 
> HID_QUIRK_NO_INIT_REPORTS },
> --
> 1.9.1.423.g4596e3a
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: GPF in intel_pmu_lbr_reset() with qemu -cpu host

[H. Peter Anvin]

Not really.  That is equally braindamaged.  The problem is that KVM is telling 
the host that our is something it simply cannot be.

On March 21, 2014 12:29:38 PM PDT, Andi Kleen  wrote:
>On Fri, Mar 21, 2014 at 06:42:40PM +0100, Peter Wu wrote:
>> Hi,
>> 
>> While trying to run QEMU with `-enable-kvm -host cpu`, I get a GPF in
>> intel_pmu_lbr_reset():
>
>Same problem as the RAPL problem earlier. KVM is lying to the guest 
>that it is a host CPU, but not implementing all MSRs the host
>CPU supports.
>
>KVM should really return 0 on unknown MSRs not #GP
>
>-Andi

-- 
Sent from my mobile phone.  Please pardon brevity and lack of formatting.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [PATCH 8/9] PCI: Ignore BAR contents when firmware left decoding disabled

[Bjorn Helgaas]

On Fri, Mar 21, 2014 at 2:25 PM, Sasha Levin  wrote:
> On 03/21/2014 04:07 PM, Bjorn Helgaas wrote:
>>
>> I think I figured out what the problem is.  In virtio_pci__init(), we
>> allocate some address space with pci_get_io_space_block(), save its
>> address in vpci->mmio_addr, and hook that address space up to
>> virtio_pci__io_mmio_callback with kvm__register_mmio().
>>
>> But when we update the BAR value in pci__config_wr(), the address
>> space mapping is never updated.  I think this means that virtio-pci
>> can't tolerate its devices being moved by the OS.
>>
>> In my opinion, this is a bug in linux-kvm.  We've managed to avoid
>> triggering this bug by preventing Linux from moving the BAR (either by
>> me reverting my patch, or by Sasha's linux-kvm change [1]).  But it's
>> not very robust to assume that the OS will never change the BAR, so
>> it's quite possible that you'll trip over this again in the future.
>
>
> The purpose of KVM tool is to implement as much as possible of the KVM
> interface and the virtio spec so that we'll have a good development/testing
> environment with a very simple to understand codebase.
>
> The issue you've mentioned is the "evil" side of the KVM tool. It never
> tried (or claimed) to implement anything close to legacy hardware
> interfaces. This means, for example, that it doesn't run any BIOS, there's
> very lacking APIC support and the kernel is just injected into the virtual
> RAM and gets run from there.
>
> It also means that we went into the PCI spec deep enough to get the code
> to work with the kernel. The only reason we implemented MSI interrupts
> for example is because they provide improved performance with KVM, not
> because we were trying to get a complete implementation of the PCI spec.
>
> So yes, the PCI implementation in the KVM tool is lacking and what we
> have there might be broken by making the kernel conform more closely
> to the spec, but we are always happy to adapt and improve our code to
> work with any changes in the kernel.
>
> To sum it up, If you'll end up adding a change to the kernel that is
> valid according to the spec but breaks the KVM tool we'll just go ahead
> and fix the tool. You really don't need to worry about breaking it.

That makes sense, and I'm glad I had a chance to get acquainted with
the KVM tool.  If I get another problem report related to it, I'll try
to remember that I don't need to worry about breaking it :)

Bjorn
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: [BUG -next] "mm: per-thread vma caching fix 5" breaks s390

[Tony Luck]

Problem is no longer present in next-20140321.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: PROBLEM: Fatal Machine Check >= 3.13.5-101.fc19.x86_64

[Tony Luck]

On Fri, Mar 21, 2014 at 1:13 PM, Borislav Petkov  wrote:
> Provided the decode is correct and I'm reading it right, this looks
> like the cores get to livelock for some reason without any forward
> progress. The MCEs signal that there hasn't been any instruction retired
> in relatively long time, thus a stall.

Agreed. There are some bus level errors (low 16 bits of STATUS 0x0800)
and some timeout (low bits 0x0400)

> You say, this happens when gnome starts. Does it also happen if you
> don't start gnome, i.e. don't start X at all? Try booting into a
> runlevel without graphics.
>
> Tony, any other ideas?

My best guess is graphics? driver making wild access to some i/o regs that
never respond.  If booting without graphics works, then that adds some
weight to the theory.

Other useful tests would be to check upstream kernels 3.12, 3.13 to
see if something is odd in the Fedora additions. And 3.14-rc7 to see
if it is already fixed upstream.

If upstream 3.12 works and 3.13 breaks (and not fixed in 3.14-rc7) ...
then bisecting between 3.12 and 3.13 would be helpful.

-Tony
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/