[PATCH v4.9] PM / OPP: Update voltage in case freq == old_freq

2018-07-02 Thread Viresh Kumar
From: Waldemar Rymarkiewicz 

Original commit c5c2a97b3ac7 ("PM / OPP: Update voltage in case freq ==
old_freq").

This commit fixes a rare but possible case when the clk rate is updated
without update of the regulator voltage.

At boot up, CPUfreq checks if the system is running at the right freq. This
is a sanity check in case a bootloader set clk rate that is outside of freq
table present with cpufreq core. In such cases system can be unstable so
better to change it to a freq that is preset in freq-table.

The CPUfreq takes next freq that is >= policy->cur and this is our
target_freq that needs to be set now.

dev_pm_opp_set_rate(dev, target_freq) checks the target_freq and the
old_freq (a current rate). If these are equal it returns early. If not,
it searches for OPP (old_opp) that fits best to old_freq (not listed in
the table) and updates old_freq (!).

Here, we can end up with old_freq = old_opp.rate = target_freq, which
is not handled in _generic_set_opp_regulator(). It's supposed to update
voltage only when freq > old_freq  || freq > old_freq.

if (freq > old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
[...]
if (freq < old_freq) {
ret = _set_opp_voltage(dev, reg, new_supply);
if (ret)

It results in, no voltage update while clk rate is updated.

Example:
freq-table = {
1000MHz   1.15V
 666MHZ   1.10V
 333MHz   1.05V
}
boot-up-freq= 800MHz   # not listed in freq-table
freq = target_freq  = 1GHz
old_freq= 800Mhz
old_opp = _find_freq_ceil(opp_table, _freq);  #(old_freq is modified!)
old_freq= 1GHz

Fixes: 6a0712f6f199 ("PM / OPP: Add dev_pm_opp_set_rate()")
Cc: 4.6+  # v4.6+
Signed-off-by: Waldemar Rymarkiewicz 
Signed-off-by: Viresh Kumar 
---
Sending it for stable kernels from 4.6 until 4.9.

 drivers/base/power/opp/core.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/base/power/opp/core.c b/drivers/base/power/opp/core.c
index 4c7c6da7a989..0580cbe5bd1c 100644
--- a/drivers/base/power/opp/core.c
+++ b/drivers/base/power/opp/core.c
@@ -642,7 +642,7 @@ int dev_pm_opp_set_rate(struct device *dev, unsigned long 
target_freq)
rcu_read_unlock();
 
/* Scaling up? Scale voltage before frequency */
-   if (freq > old_freq) {
+   if (freq >= old_freq) {
ret = _set_opp_voltage(dev, reg, u_volt, u_volt_min,
   u_volt_max);
if (ret)
-- 
2.18.0.rc1.242.g61856ae69a2c



Re: [PATCH 0/5] ARM: dts: dra7/am7xx: USB fixes and enhancements

2018-07-02 Thread Roger Quadros
Hi Tony,

On 29/05/18 12:00, Roger Quadros wrote:
> Hi Tony,
> 
> These are some fixes and enhancements for USB ports on dra7 and am57xx-idk 
> EVMs.
> If OK, please queue these for v4.18. Thanks.
> 

Gentle reminder.
Could you please pick the first patch for 2018-rc, and the rest for -next. 
Thanks.

> Roger Quadros (5):
>   ARM: dts: dra7: Disable metastability workaround for USB2
>   ARM: dts: am57xx-idk: Enable dual role for USB2 port
>   ARM: dts: dra7-evm: Add extcon to USB2 port
>   ARM: dts: dra71-evm: Add VBUS GPIO to USB1/USB2 extcon
>   ARM: dts: dra76-evm: Add VBUS GPIO to USB1/USB2 extcon
> 
>  arch/arm/boot/dts/am571x-idk.dts |  4 
>  arch/arm/boot/dts/am572x-idk-common.dtsi |  4 
>  arch/arm/boot/dts/am57xx-idk-common.dtsi |  7 ++-
>  arch/arm/boot/dts/dra7-evm-common.dtsi   | 10 ++
>  arch/arm/boot/dts/dra7-evm.dts   |  9 -
>  arch/arm/boot/dts/dra7.dtsi  |  2 +-
>  arch/arm/boot/dts/dra71-evm.dts  |  8 
>  arch/arm/boot/dts/dra72-evm-common.dtsi  |  1 +
>  arch/arm/boot/dts/dra76-evm.dts  |  8 
>  9 files changed, 34 insertions(+), 19 deletions(-)
> 

-- 
cheers,
-roger

Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki


Re: [PATCH] ACPI/PPTT: use ACPI ID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set

2018-07-02 Thread Rafael J. Wysocki
On Fri, Jun 29, 2018 at 6:17 PM, Sudeep Holla  wrote:
> Currently we use the ACPI processor ID only for the leaf/processor nodes
> as the specification states it must match the value of ACPI processor ID
> field in the processor’s entry in the MADT.
>
> However, if a PPTT structure represents processors group, it match a
> processor container UID in the namespace and ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
> flag describe whether the ACPI processor ID is valid.
>
> Lets use UID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set to be
> consistent instead of using table offset as it's currently done for non
> leaf nodes.
>
> Cc: "Rafael J. Wysocki" 
> Signed-off-by: Sudeep Holla 
> ---
>  drivers/acpi/pptt.c | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
>
> Hi,
>
> There's ongoing discussion on assigning ID based in OS using simple
> counters. It can never be consistent with firmware's view. So if the
> firmware provides valid UID for non-processors node, we must use it.

OK

Do you regard this as a fix for the recently merged PPTT material?  If
so, I should apply it as a fix for 4.18.

Thanks,
Rafael


Re: [PATCH 1/3] staging: rtl8192u: Use __func__ instead of hardcoded string - Style

2018-07-02 Thread Greg KH
On Mon, Jul 02, 2018 at 09:59:34AM +0100, John Whitmore wrote:
> I'll fix that up and re-submit 

Please do not top-post, or send html email, as the mailing lists will
reject it (as you saw...)

greg k-h


Re: [PATCH][next] gnss: make struct ubx_gserial_ops static

2018-07-02 Thread Johan Hovold
On Sat, Jun 30, 2018 at 12:22:46PM +0100, Colin King wrote:
> From: Colin Ian King 
> 
> The structure ubx_gserial_ops is local to the source and does not need
> to be in global scope, so make it static.
> 
> Cleans up sparse warning:
> symbol 'ubx_gserial_ops' was not declared. Should it be static?
> 
> Signed-off-by: Colin Ian King 

This was reported by the kbuild test robot and an automated RFC patch
submitted was a while back.

I prefer this man-generated one with a proper commit message, so:

Acked-by: Johan Hovold 

> ---
>  drivers/gnss/ubx.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/gnss/ubx.c b/drivers/gnss/ubx.c
> index 902b6854b7db..12568aebb7f6 100644
> --- a/drivers/gnss/ubx.c
> +++ b/drivers/gnss/ubx.c
> @@ -59,7 +59,7 @@ static int ubx_set_power(struct gnss_serial *gserial,
>   return -EINVAL;
>  }
>  
> -const struct gnss_serial_ops ubx_gserial_ops = {
> +static const struct gnss_serial_ops ubx_gserial_ops = {
>   .set_power = ubx_set_power,
>  };

Thanks,
Johan


Re: [PATCH] mm: be more informative in OOM task list

2018-07-02 Thread Michal Hocko
On Sun 01-07-18 13:09:40, Rodrigo Freire wrote:
> The default page memory unit of OOM task dump events might not be
> intuitive for the non-initiated when debugging OOM events. Add
> a small printk prior to the task dump informing that the memory
> units are actually memory _pages_.

Does this really help? I understand the the oom report might be not the
easiest thing to grasp but wouldn't it be much better to actually add
documentation with clarification of each part of it?

> Signed-off-by: Rodrigo Freire 
> ---
>  mm/oom_kill.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/mm/oom_kill.c b/mm/oom_kill.c
> index 84081e7..b4d9557 100644
> --- a/mm/oom_kill.c
> +++ b/mm/oom_kill.c
> @@ -392,6 +392,7 @@ static void dump_tasks(struct mem_cgroup *memcg, const 
> nodemask_t *nodemask)
>   struct task_struct *p;
>   struct task_struct *task;
>  
> + pr_info("Tasks state (memory values in pages):\n");
>   pr_info("[ pid ]   uid  tgid total_vm  rss pgtables_bytes swapents 
> oom_score_adj name\n");
>   rcu_read_lock();
>   for_each_process(p) {
> -- 
> 1.8.3.1

-- 
Michal Hocko
SUSE Labs


Re: WARNING in input_alloc_absinfo

2018-07-02 Thread Dmitry Vyukov
On Fri, Jun 29, 2018 at 11:59 PM,   wrote:
> On Monday, June 25, 2018 at 5:43:02 AM UTC-7, Dmitry Vyukov wrote:
>>
>> On Tue, Jun 19, 2018 at 8:51 PM, Dmitry Torokhov
>>  wrote:
>> > On Thu, Jun 14, 2018 at 05:47:03AM -0700, syzbot wrote:
>> >> Hello,
>> >>
>> >> syzbot found the following crash on:
>> >>
>> >> HEAD commit:d2d741e5d189 kmsan: add initialization for shmem pages
>> >> git tree:   https://github.com/google/kmsan.git/master
>> >> console output:
>> >> https://syzkaller.appspot.com/x/log.txt?x=1775bae780
>> >> kernel config:
>> >> https://syzkaller.appspot.com/x/.config?x=48f9de3384bcd0f
>> >> dashboard link:
>> >> https://syzkaller.appspot.com/bug?extid=c382812c78d98ecd9fb8
>> >> compiler:   clang version 7.0.0 (trunk 329391)
>> >> syzkaller
>> >> repro:https://syzkaller.appspot.com/x/repro.syz?x=13b31ae780
>> >> C reproducer:
>> >> https://syzkaller.appspot.com/x/repro.c?x=1733255b80
>> >>
>> >> IMPORTANT: if you fix the bug, please add the following tag to the
>> >> commit:
>> >> Reported-by: syzbot+c38281...@syzkaller.appspotmail.com
>> >>
>> >> RBP: 006cb018 R08: 0001 R09: 7ffe93080031
>> >> R10:  R11: 0246 R12: 0004
>> >> R13:  R14:  R15: 
>> >> [ cut here ]
>> >> input_alloc_absinfo(): kcalloc() failed?
>> >> WARNING: CPU: 1 PID: 4498 at drivers/input/input.c:487
>> >> input_alloc_absinfo+0x183/0x190 drivers/input/input.c:487
>> >> Kernel panic - not syncing: panic_on_warn set ...
>> >
>> > Hmm, so there is not really a problem as far as I am concerned. We do
>> > generate a warning if we can't allocate memory for absinfo,  as this is
>> > really unexpected, but the case is handled properly by the callers so
>> > there is no reason for us to go belly up here.
>>
>> Note to myself: ping this bug when "include/asm-generic/bug.h: clarify
>> valid uses of WARN()" is fully merged.
>
>
> No, this warning will still be there even after the "clarifying" patch is
> merged. It does not check user inputs, it warns that the system is so low on
> memory that we could not allocate measly amount needed for absinfo. Treat it
> as you treat OOM warnings from kmalloc() itself.

Hi Dmitry,

kmalloc does not produce WARNING on OOM. The rule is not only about
invalid inputs, it's also about any transient conditions and "WARNING
only for kernel bugs".

To put this in larger context, being able to distinguish kernel bugs
from non-bugs is a very important and practically useful capability,
which in particular enables systematic testing, but also makes things
simpler for all kernel users. There must be a very significant reason
to abandon this capability. What is that reason in this case?

I also don't understand what is so special about this case. If we want
user message for kmalloc failures, kmalloc is the right place for such
warning, rather than a random call site out of thousands. Consider,
the allocation failure can happen on the very next or previous kmalloc
call, and user won't be warned. The rest of the kernel (including the
rest of input sybsystem) does not warn on allocation failures, so that
looks like what we need to do here as well. Or, if there is something
very special about this particular kmalloc call site, something that
makes it different from thousands of other call sites, why don't you
want to replace it with pr_err which would both give the diagnostics
but also not block systematic testing? Which looks like a win-win to
me.

Thanks


Re: [PATCH] Add renameat2 function [BZ #17662]

2018-07-02 Thread Florian Weimer

On 07/02/2018 10:46 AM, Yury Norov wrote:


Is my understanding correct that glibc community finds 
inappropriate for their use, and prefer to re-introduce (duplicate)
its functionality locally? I think it's wrong. The right way to go
is to make kernel headers comfortable for users instead of ignoring
it.


In some cases, we already use UAPI headers ( is an 
example), but it is not always possible.



Are you OK to switch to kernel RENAME_* definitions if they will be
located in separated small file? Like in the patch below.

Signed-off-by: Yury Norov 
---
  include/uapi/linux/fs.h |  4 +---
  include/uapi/linux/rename.h | 12 
  2 files changed, 13 insertions(+), 3 deletions(-)
  create mode 100644 include/uapi/linux/rename.h

diff --git a/include/uapi/linux/fs.h b/include/uapi/linux/fs.h
index c27576d471c2..46c03ea31a76 100644
--- a/include/uapi/linux/fs.h
+++ b/include/uapi/linux/fs.h
@@ -44,9 +44,7 @@
  #define SEEK_HOLE 4   /* seek to the next hole */
  #define SEEK_MAX  SEEK_HOLE
  
-#define RENAME_NOREPLACE	(1 << 0)	/* Don't overwrite target */

-#define RENAME_EXCHANGE(1 << 1)  /* Exchange source and dest */
-#define RENAME_WHITEOUT(1 << 2)  /* Whiteout source */
+#include 
  
  struct file_clone_range {

__s64 src_fd;
diff --git a/include/uapi/linux/rename.h b/include/uapi/linux/rename.h
new file mode 100644
index ..7178f0565657
--- /dev/null
+++ b/include/uapi/linux/rename.h
@@ -0,0 +1,12 @@
+/* SPDX-License-Identifier: GPL-2.0 WITH Linux-syscall-note */
+#ifndef _UAPI_LINUX_RENAME_H
+#define _UAPI_LINUX_RENAME_H
+
+/*
+ * Definitions for rename syscall family.
+ */
+#define RENAME_NOREPLACE   (1 << 0)  /* Don't overwrite target */
+#define RENAME_EXCHANGE(1 << 1)  /* Exchange source and dest */
+#define RENAME_WHITEOUT(1 << 2)  /* Whiteout source */
+
+#endif /* _UAPI_LINUX_RENAME_H */


This would help.

We would need to provide definitions for compatibility with older kernel 
headers locally, but on newer kernels, we could use the UAPI header file.


Thanks,
Florian


Re: 4.18.0-rc1-next-20180619 boot failed on beagle board x15

2018-07-02 Thread Tony Lindgren
Hi,

* Roger Quadros  [180621 14:56]:
> On 21/06/18 17:31, Samuel Morris wrote:
> > On Thu, Jun 21, 2018 at 3:58 AM, Roger Quadros  wrote:
> >> +Rafael
> >>
> >> On 20/06/18 18:30, Samuel Morris wrote:
> >>> On Wed, Jun 20, 2018 at 8:58 AM, Roger Quadros  wrote:
> >>>> Tony,
> >>>>
> >>>> On 20/06/18 13:29, Tony Lindgren wrote:
> >>>>> Hi,
> >>>>>
> >>>>> * Naresh Kamboju  [180620 05:55]:
> >>>>>> Linux next (4.18.0-rc1-next-20180619) boot failed on beagle board x15.
> >>>>>
> >>>>> Bisect points to commit aece27a2f01b ("ata: ahci_platform: allow 
> >>>>> disabling of
> >>>>> hotplug to save power").
> >>>>>
> >>>>> Reverting the patch makes things work again. Any ideas what
> >>>>> might be going wrong here? Things clearly idle but then there
> >>>>> seems to be some register access with clocks disabled.

So this issue is still happening as of next-20180702. Can you guys
please revert the commit above while working on a better solution?

Regards,

Tony


答复: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not integer,incompatible for ancient android devices

2018-07-02 Thread Gaoming (ming, consumer BG)
I got it. You hate make_ext4fs, and me too.
You don't like to merge this patch in upstream e2fsprogs to resolve the bug of 
make_ext4fs.

Of course we will fix the bug on our ancient devices, we have to .
If this problem fixed or this patch merges in latest e2fsprogs, we will 
backport the latest e2fsprogs.
If not, we have no motivation to backport it.

I don't know whether other android devices suffer this problem.

If someone else come to complain this problem, you should consider to fix it.

Best wishes.

Ming


-邮件原件-
发件人: Theodore Y. Ts'o [mailto:ty...@mit.edu] 
发送时间: 2018年6月30日 21:04
收件人: Gaoming (ming, consumer BG)
抄送: linux-e...@vger.kernel.org; linux-kernel@vger.kernel.org; Liqingchao 
(sorp); Shenchen (harry); miaoxie (A); yangfei (D); Renlipeng (OS driver)
主题: Re: 答复: 答复: 答复: 答复: [PATCH] ext4: e2fsprogs: fix inode bitmap num not 
integer,incompatible for ancient android devices

On Sat, Jun 30, 2018 at 01:26:43AM +, Gaoming (ming, consumer BG) wrote:
> Yes, it is caused by using 1024 blocksize.
> It is historical problem, and I have to admit that's not good idea.  I don't 
> know why somebody choose it some years before. 
> It has been corrected two years before or more early. But some ancient 
> devices exist. 
> It is not user data, no need to do file-based encryption. It is a small 
> partition for some use.
> 
> However, 1024 is legal though not good, somebody may use it. 
> And we should fix it.

So you understand my position --- the reason why I've been pushing so
hard is I'm trying to figure out how big of a problem this is.
Specifically speaking, is this a Huawei-specific problem, or something
across the entire Android ecosystem.  I *thought* I had fixed most of
the disaster back in 2011.  There have periodic headaches where
testers would discover problems where android handsets get bricked
after doing a factory reset that I had tracked down to make_ext4fs,
and the existence of make_ext4fs is not something I agreed to, and
have been fighting for years.  So I've been cleaning up after
make_ext4fs for a while, even though it's not my responsiblity.  (For
one thing my work responsibilities are for data center servers at
Google, *not* Android; for another, no one asked *me* before they came
up with the abomination which is make_ext4fs.)

So I don't feel particularly, or personally, responsible for bugs
caused by make_ext4fs, because if it had been up to me, it would have
never existed in the first place.

If it's only in ancient Huawei devices, I don't see a strong reason to
support his in upstream e2fsprogs.  Are you really going to be
backporting the latest e2fsprogs into these ancient Huawei devices?
In my experience, the Android team has a hard enough time getting
their Android partners to backport kernel fixes for severe security
bugs into old Android devices --- never mind versions of e2fsprogs.

If not, what's the point?

Regards,

- Ted


hrtimer become inaccurate with RT patch

2018-07-02 Thread gengdongjiu
Hi Thomas/Anna/John,

  Recently I found that the hrtimer become inaccurate when there is a RT
process runs on the same cpu core, and the kernel has applied preempt_rt
patch.
  The Linux kernel version is v4.1.46, and the preempt_rt patch is
patch-4.1.46-rt52.patch.
  I know that in the preempt_rt environment the interrupt handlers no
longer run in interrupt context but in process context, so that RT
process will not be interrupt. But if the hrtimer is also runs in
process context the timer is useless when it's inaccurate. so I want to
consult you whether this is expected behavior? whether is reasonable to move 
the timer IRQ
handling to a thread?

  Check the patch-4.1.46-rt52.patch will found in function
'hrtimer_interrupt' the modify below:

@@ -1296,7 +1539,10 @@ retry:
if (basenow.tv64 < hrtimer_get_softexpires_tv64(timer))
break;

-   __run_hrtimer(timer, );
+   if (!hrtimer_rt_defer(timer))
+   __run_hrtimer(timer, );
+   else
+   raise = 1;
}
}
/* Reevaluate the clock bases for the next expiry */

@@ -1357,6 +1603,9 @@ retry:
tick_program_event(expires_next, 1);
printk_once(KERN_WARNING "hrtimer: interrupt took %llu ns\n",
ktime_to_ns(delta));
+out:
+   if (raise)
+   raise_softirq_irqoff(HRTIMER_SOFTIRQ);
 }

I think this is why hrtimer is run as a thread, I tried to set
hrtimer.irqsafe to 1, but the timer still seemed not right. Could anyone
give some advise? Thanks.



Re: [PATCH v3 1/2] ubi: provide a way to skip CRC checks

2018-07-02 Thread Artem Bityutskiy
On Mon, 2018-07-02 at 09:51 +0200, Boris Brezillon wrote:
> Well, I thought checking the CRC just after updating the volume made
> sense, just to make sure things were written correctly on the medium.
> Let's add a comment explaining why we keep the check here, unless you
> see a strong reason to get rid of this check in the update path.

I am fine with this, thanks.


[tip:timers/core] posix-timers: Sanitize overrun handling

2018-07-02 Thread tip-bot for Thomas Gleixner
Commit-ID:  78c9c4dfbf8c04883941445a195276bb4bb92c76
Gitweb: https://git.kernel.org/tip/78c9c4dfbf8c04883941445a195276bb4bb92c76
Author: Thomas Gleixner 
AuthorDate: Tue, 26 Jun 2018 15:21:32 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 2 Jul 2018 11:33:25 +0200

posix-timers: Sanitize overrun handling

The posix timer overrun handling is broken because the forwarding functions
can return a huge number of overruns which does not fit in an int. As a
consequence timer_getoverrun(2) and siginfo::si_overrun can turn into
random number generators.

The k_clock::timer_forward() callbacks return a 64 bit value now. Make
k_itimer::ti_overrun[_last] 64bit as well, so the kernel internal
accounting is correct. 3Remove the temporary (int) casts.

Add a helper function which clamps the overrun value returned to user space
via timer_getoverrun(2) or siginfo::si_overrun limited to a positive value
between 0 and INT_MAX. INT_MAX is an indicator for user space that the
overrun value has been clamped.

Reported-by: Team OWL337 
Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Cc: Peter Zijlstra 
Cc: Michael Kerrisk 
Link: https://lkml.kernel.org/r/20180626132705.018623...@linutronix.de

---
 include/linux/posix-timers.h   |  4 ++--
 kernel/time/posix-cpu-timers.c |  2 +-
 kernel/time/posix-timers.c | 31 ---
 3 files changed, 23 insertions(+), 14 deletions(-)

diff --git a/include/linux/posix-timers.h b/include/linux/posix-timers.h
index c85704fcdbd2..ee7e987ea1b4 100644
--- a/include/linux/posix-timers.h
+++ b/include/linux/posix-timers.h
@@ -95,8 +95,8 @@ struct k_itimer {
clockid_t   it_clock;
timer_t it_id;
int it_active;
-   int it_overrun;
-   int it_overrun_last;
+   s64 it_overrun;
+   s64 it_overrun_last;
int it_requeue_pending;
int it_sigev_notify;
ktime_t it_interval;
diff --git a/kernel/time/posix-cpu-timers.c b/kernel/time/posix-cpu-timers.c
index 5a6251ac6f7a..562cc3891b57 100644
--- a/kernel/time/posix-cpu-timers.c
+++ b/kernel/time/posix-cpu-timers.c
@@ -85,7 +85,7 @@ static void bump_cpu_timer(struct k_itimer *timer, u64 now)
continue;
 
timer->it.cpu.expires += incr;
-   timer->it_overrun += 1 << i;
+   timer->it_overrun += 1LL << i;
delta -= incr;
}
 }
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index db1d65963a57..3ac7295306dc 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -283,6 +283,17 @@ static __init int init_posix_timers(void)
 }
 __initcall(init_posix_timers);
 
+/*
+ * The siginfo si_overrun field and the return value of timer_getoverrun(2)
+ * are of type int. Clamp the overrun value to INT_MAX
+ */
+static inline int timer_overrun_to_int(struct k_itimer *timr, int baseval)
+{
+   s64 sum = timr->it_overrun_last + (s64)baseval;
+
+   return sum > (s64)INT_MAX ? INT_MAX : (int)sum;
+}
+
 static void common_hrtimer_rearm(struct k_itimer *timr)
 {
struct hrtimer *timer = >it.real.timer;
@@ -290,9 +301,8 @@ static void common_hrtimer_rearm(struct k_itimer *timr)
if (!timr->it_interval)
return;
 
-   timr->it_overrun += (unsigned int) hrtimer_forward(timer,
-   timer->base->get_time(),
-   timr->it_interval);
+   timr->it_overrun += hrtimer_forward(timer, timer->base->get_time(),
+   timr->it_interval);
hrtimer_restart(timer);
 }
 
@@ -321,10 +331,10 @@ void posixtimer_rearm(struct siginfo *info)
 
timr->it_active = 1;
timr->it_overrun_last = timr->it_overrun;
-   timr->it_overrun = -1;
+   timr->it_overrun = -1LL;
++timr->it_requeue_pending;
 
-   info->si_overrun += timr->it_overrun_last;
+   info->si_overrun = timer_overrun_to_int(timr, info->si_overrun);
}
 
unlock_timer(timr, flags);
@@ -418,9 +428,8 @@ static enum hrtimer_restart posix_timer_fn(struct hrtimer 
*timer)
now = ktime_add(now, kj);
}
 #endif
-   timr->it_overrun += (unsigned int)
-   hrtimer_forward(timer, now,
-   timr->it_interval);
+   timr->it_overrun += hrtimer_forward(timer, now,
+   timr->it_interval);
ret = HRTIMER_RESTART;
++timr->it_requeue_pending;
timr->it_active = 1;
@@ -524,7 +533,7 @@ static int 

[tip:timers/core] alarmtimer: Prevent overflow for relative nanosleep

2018-07-02 Thread tip-bot for Thomas Gleixner
Commit-ID:  5f936e19cc0ef97dbe3a56e9498922ad5ba1edef
Gitweb: https://git.kernel.org/tip/5f936e19cc0ef97dbe3a56e9498922ad5ba1edef
Author: Thomas Gleixner 
AuthorDate: Mon, 2 Jul 2018 09:34:29 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 2 Jul 2018 11:33:26 +0200

alarmtimer: Prevent overflow for relative nanosleep

Air Icy reported:

  UBSAN: Undefined behaviour in kernel/time/alarmtimer.c:811:7
  signed integer overflow:
  1529859276030040771 + 9223372036854775807 cannot be represented in type 'long 
long int'
  Call Trace:
   alarm_timer_nsleep+0x44c/0x510 kernel/time/alarmtimer.c:811
   __do_sys_clock_nanosleep kernel/time/posix-timers.c:1235 [inline]
   __se_sys_clock_nanosleep kernel/time/posix-timers.c:1213 [inline]
   __x64_sys_clock_nanosleep+0x326/0x4e0 kernel/time/posix-timers.c:1213
   do_syscall_64+0xb8/0x3a0 arch/x86/entry/common.c:290

alarm_timer_nsleep() uses ktime_add() to add the current time and the
relative expiry value. ktime_add() has no sanity checks so the addition
can overflow when the relative timeout is large enough.

Use ktime_add_safe() which has the necessary sanity checks in place and
limits the result to the valid range.

Fixes: 9a7adcf5c6de ("timers: Posix interface for alarm-timers")
Reported-by: Team OWL337 
Signed-off-by: Thomas Gleixner 
Cc: John Stultz 
Link: 
https://lkml.kernel.org/r/alpine.deb.2.21.1807020926360.1...@nanos.tec.linutronix.de

---
 kernel/time/alarmtimer.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 78a3cc555823..fa5de5e8de61 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -808,7 +808,8 @@ static int alarm_timer_nsleep(const clockid_t which_clock, 
int flags,
/* Convert (if necessary) to absolute time */
if (flags != TIMER_ABSTIME) {
ktime_t now = alarm_bases[type].gettime();
-   exp = ktime_add(now, exp);
+
+   exp = ktime_add_safe(now, exp);
}
 
ret = alarmtimer_do_nsleep(, exp, type);


[tip:timers/core] posix-timers: Make forward callback return s64

2018-07-02 Thread tip-bot for Thomas Gleixner
Commit-ID:  6fec64e1c92d5c715c6d0f50786daa7708266bde
Gitweb: https://git.kernel.org/tip/6fec64e1c92d5c715c6d0f50786daa7708266bde
Author: Thomas Gleixner 
AuthorDate: Tue, 26 Jun 2018 15:21:31 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 2 Jul 2018 11:33:25 +0200

posix-timers: Make forward callback return s64

The posix timer ti_overrun handling is broken because the forwarding
functions can return a huge number of overruns which does not fit in an
int. As a consequence timer_getoverrun(2) and siginfo::si_overrun can turn
into random number generators.

As a first step to address that let the timer_forward() callbacks return
the full 64 bit value.

Cast it to (int) temporarily until k_itimer::ti_overrun is converted to
64bit and the conversion to user space visible values is sanitized.

Reported-by: Team OWL337 
Signed-off-by: Thomas Gleixner 
Acked-by: John Stultz 
Cc: Peter Zijlstra 
Cc: Michael Kerrisk 
Link: https://lkml.kernel.org/r/20180626132704.922098...@linutronix.de

---
 kernel/time/alarmtimer.c   | 4 ++--
 kernel/time/posix-timers.c | 6 +++---
 kernel/time/posix-timers.h | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/kernel/time/alarmtimer.c b/kernel/time/alarmtimer.c
index 639321bf2e39..78a3cc555823 100644
--- a/kernel/time/alarmtimer.c
+++ b/kernel/time/alarmtimer.c
@@ -581,11 +581,11 @@ static void alarm_timer_rearm(struct k_itimer *timr)
  * @timr:  Pointer to the posixtimer data struct
  * @now:   Current time to forward the timer against
  */
-static int alarm_timer_forward(struct k_itimer *timr, ktime_t now)
+static s64 alarm_timer_forward(struct k_itimer *timr, ktime_t now)
 {
struct alarm *alarm = >it.alarm.alarmtimer;
 
-   return (int) alarm_forward(alarm, timr->it_interval, now);
+   return alarm_forward(alarm, timr->it_interval, now);
 }
 
 /**
diff --git a/kernel/time/posix-timers.c b/kernel/time/posix-timers.c
index 80d59333c76e..db1d65963a57 100644
--- a/kernel/time/posix-timers.c
+++ b/kernel/time/posix-timers.c
@@ -645,11 +645,11 @@ static ktime_t common_hrtimer_remaining(struct k_itimer 
*timr, ktime_t now)
return __hrtimer_expires_remaining_adjusted(timer, now);
 }
 
-static int common_hrtimer_forward(struct k_itimer *timr, ktime_t now)
+static s64 common_hrtimer_forward(struct k_itimer *timr, ktime_t now)
 {
struct hrtimer *timer = >it.real.timer;
 
-   return (int)hrtimer_forward(timer, now, timr->it_interval);
+   return hrtimer_forward(timer, now, timr->it_interval);
 }
 
 /*
@@ -702,7 +702,7 @@ void common_timer_get(struct k_itimer *timr, struct 
itimerspec64 *cur_setting)
 * expiry time forward by intervals, so expiry is > now.
 */
if (iv && (timr->it_requeue_pending & REQUEUE_PENDING || sig_none))
-   timr->it_overrun += kc->timer_forward(timr, now);
+   timr->it_overrun += (int)kc->timer_forward(timr, now);
 
remaining = kc->timer_remaining(timr, now);
/* Return 0 only, when the timer is expired and not pending */
diff --git a/kernel/time/posix-timers.h b/kernel/time/posix-timers.h
index 151e28f5bf30..ddb21145211a 100644
--- a/kernel/time/posix-timers.h
+++ b/kernel/time/posix-timers.h
@@ -19,7 +19,7 @@ struct k_clock {
void(*timer_get)(struct k_itimer *timr,
 struct itimerspec64 *cur_setting);
void(*timer_rearm)(struct k_itimer *timr);
-   int (*timer_forward)(struct k_itimer *timr, ktime_t now);
+   s64 (*timer_forward)(struct k_itimer *timr, ktime_t now);
ktime_t (*timer_remaining)(struct k_itimer *timr, ktime_t now);
int (*timer_try_to_cancel)(struct k_itimer *timr);
void(*timer_arm)(struct k_itimer *timr, ktime_t expires,


Re: [PATCH] memcg, oom: move out_of_memory back to the charge path

2018-07-02 Thread Michal Hocko
On Fri 29-06-18 11:59:04, Greg Thelen wrote:
> Michal Hocko  wrote:
> 
> > On Thu 28-06-18 16:19:07, Greg Thelen wrote:
> >> Michal Hocko  wrote:
> > [...]
> >> > +if (mem_cgroup_out_of_memory(memcg, mask, order))
> >> > +return OOM_SUCCESS;
> >> > +
> >> > +WARN(1,"Memory cgroup charge failed because of no reclaimable 
> >> > memory! "
> >> > +"This looks like a misconfiguration or a kernel bug.");
> >> 
> >> I'm not sure here if the warning should here or so strongly worded.  It
> >> seems like the current task could be oom reaped with MMF_OOM_SKIP and
> >> thus mem_cgroup_out_of_memory() will return false.  So there's nothing
> >> alarming in that case.
> >
> > If the task is reaped then its charges should be released as well and
> > that means that we should get below the limit. Sure there is some room
> > for races but this should be still unlikely. Maybe I am just
> > underestimating though.
> >
> > What would you suggest instead?
> 
> I suggest checking MMF_OOM_SKIP or deleting the warning.

So what do you do when you have MMF_OOM_SKIP task? Do not warn? Checking
for all the tasks would be quite expensive and remembering that from the
task selection not nice either. Why do you think it would help much?

I feel strongly that we have to warn when bypassing the charge limit
during the corner case because it can lead to unexpected behavior and
users should be aware of this fact. I am open to the wording or some
optimizations. I would prefer the latter on top with a clear description
how it helped in a particular case though. I would rather not over
optimize now without any story to back it.
-- 
Michal Hocko
SUSE Labs


Re: [PATCH 5/5] ASoC: es7134: add support for the es7154

2018-07-02 Thread Mark Brown
On Fri, Jun 29, 2018 at 05:09:24PM +0200, Jerome Brunet wrote:

>   { .compatible = "everest,es7134", .data = _chip },
>   { .compatible = "everest,es7144", .data = _chip },
> + { .compatible = "everest,es7154", .data = _chip },
>   { }

This needs to be added to the DT documentation.


signature.asc
Description: PGP signature


Re: [PATCH v2 12/29] venus: add common capability parser

2018-07-02 Thread Tomasz Figa
On Mon, Jul 2, 2018 at 6:59 PM Stanimir Varbanov
 wrote:
>
> Hi Tomasz,
>
> On 07/02/2018 12:23 PM, Tomasz Figa wrote:
> > On Thu, May 31, 2018 at 4:06 PM Tomasz Figa  wrote:
> >>
> >> On Thu, May 31, 2018 at 1:21 AM Stanimir Varbanov
> >>  wrote:
> >>>
> >>> Hi Tomasz,
> >>>
> >>> On 05/24/2018 05:16 PM, Tomasz Figa wrote:
>  Hi Stanimir,
> 
>  On Tue, May 15, 2018 at 5:08 PM Stanimir Varbanov <
> > [snip]
> 
> > +   break;
> > +   }
> > +
> > +   word++;
> > +   words_count--;
> 
>  If data is at |word + 1|, shouldn’t we increment |word| by |1 + |data
>  size||?
> >>>
> >>> yes, that could be possible but the firmware packets are with variable
> >>> data length and don't want to make the code so complex.
> >>>
> >>> The idea is to search for HFI_PROPERTY_PARAM* key numbers. Yes it is not
> >>> optimal but this enumeration is happen only once during driver probe.
> >>>
> >>
> >> Hmm, do we have a guarantee that we will never find a value that
> >> matches HFI_PROPERTY_PARAM*, but would be actually just some data
> >> inside the payload?
> >
> > Ping?
>
> OK, you are right there is guarantee that we not mixing keywords and

Did the auto-correction engine in my head got this correctly as "no
guarantee"? :)

> data. I can make parse_* functions to return how words they consumed and
> increment 'word' pointer with consumed words.

Yes, that or maybe just returning the pointer to the first word after
consumed data. Most of the looping functions already seem to have this
value, so it would have to be just returned. (vs having to subtract
from the start pointer)

Best regards,
Tomasz


Re: [PATCH 3/5] ASoC: es7134: update DT binding with new compatible and supplies

2018-07-02 Thread Jerome Brunet
On Mon, 2018-07-02 at 11:04 +0100, Mark Brown wrote:
> On Fri, Jun 29, 2018 at 05:09:22PM +0200, Jerome Brunet wrote:
> > Update the documentation to add support for the es7154 and
> > optional power supplies phandles.
> > +Optional properties:
> > +- VDD-supply: regulator phandle for the VDD supply
> > +- AVDD-supply: regulator phandle for the AVDD supply
> 
> Unless the device is able to work with a power supply missing (which
> doesn't seem entirely credible) supply properties should never be
> optional.

Sure the device cannot work without its physical supplies.
I'll resubmit




[PATCH] iio: dac: remove redundant pointer chip_info and spi_dev_id

2018-07-02 Thread Colin King
From: Colin Ian King 

Pointers chip_info and spi_dev_id are being assigned but are never used
hence they are redundant and can be removed.

Cleans up clang warning:
warning: variable 'chip_info' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 drivers/iio/dac/ltc2632.c | 5 -
 1 file changed, 5 deletions(-)

diff --git a/drivers/iio/dac/ltc2632.c b/drivers/iio/dac/ltc2632.c
index cca278eaa138..28e9b7656b20 100644
--- a/drivers/iio/dac/ltc2632.c
+++ b/drivers/iio/dac/ltc2632.c
@@ -87,12 +87,7 @@ static int ltc2632_read_raw(struct iio_dev *indio_dev,
int *val2,
long m)
 {
-   struct ltc2632_chip_info *chip_info;
-
const struct ltc2632_state *st = iio_priv(indio_dev);
-   const struct spi_device_id *spi_dev_id = spi_get_device_id(st->spi_dev);
-
-   chip_info = (struct ltc2632_chip_info *)spi_dev_id->driver_data;
 
switch (m) {
case IIO_CHAN_INFO_SCALE:
-- 
2.17.1



Re: hrtimer become inaccurate with RT patch

2018-07-02 Thread Sebastian Andrzej Siewior
On 2018-07-02 17:34:34 [+0800], gengdongjiu wrote:
>   The Linux kernel version is v4.1.46, and the preempt_rt patch is
> patch-4.1.46-rt52.patch.

the 4.1 series is no longer supported (neither RT wise nor non-RT,
https://www.kernel.org/category/releases.html). I suggest to move away.
If you notice this problem now it is hardly a long running project.

> process will not be interrupt. But if the hrtimer is also runs in
> process context the timer is useless when it's inaccurate. so I want to
> consult you whether this is expected behavior? whether is reasonable to move 
> the timer IRQ
> handling to a thread?

This depends on your expectations. The timer is defined not to fire
before the programmed time. So it fires as soon as possible _after_ the
programmed time.

> I think this is why hrtimer is run as a thread, I tried to set
> hrtimer.irqsafe to 1, but the timer still seemed not right. Could anyone
> give some advise? Thanks.

By setting irqsafe to 1 you ensure taht the timer will fire from the
timer interrupt and before doing so you should ensure that the timer is
indeed IRQ safe.
Depending on what you do it is possible that the timer fires early but
the application notices it later (the scheduler will first handle RT
tasks according to their priorities followed by non RT tasks).

Sebastian


Re: [PATCH 5/5] ASoC: es7134: add support for the es7154

2018-07-02 Thread Jerome Brunet
On Mon, 2018-07-02 at 11:05 +0100, Mark Brown wrote:
> On Fri, Jun 29, 2018 at 05:09:24PM +0200, Jerome Brunet wrote:
> 
> > { .compatible = "everest,es7134", .data = _chip },
> > { .compatible = "everest,es7144", .data = _chip },
> > +   { .compatible = "everest,es7154", .data = _chip },
> > { }
> 
> This needs to be added to the DT documentation.

I believe I added this in patch 3 of this serie, which I'll resubmit.
Shall I resubmit this patch along with it ?



[PATCH v2 1/2] KVM: X86: Implement PV IPI in linux guest

2018-07-02 Thread Wanpeng Li
From: Wanpeng Li 

Implement PV IPIs in guest kernel.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Vitaly Kuznetsov 
Signed-off-by: Wanpeng Li 
---
 arch/x86/kernel/kvm.c | 99 +++
 include/uapi/linux/kvm_para.h |  1 +
 2 files changed, 100 insertions(+)

diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
index 5b2300b..7e3ee25 100644
--- a/arch/x86/kernel/kvm.c
+++ b/arch/x86/kernel/kvm.c
@@ -47,6 +47,7 @@
 #include 
 #include 
 
+static struct apic orig_apic;
 static int kvmapf = 1;
 
 static int __init parse_no_kvmapf(char *arg)
@@ -454,6 +455,89 @@ static void __init sev_map_percpu_data(void)
 }
 
 #ifdef CONFIG_SMP
+
+#ifdef CONFIG_X86_64
+static bool __send_ipi_mask(const struct cpumask *mask, int vector)
+{
+   unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0, icr = 0;
+   int cpu, apic_id, ret = 1;
+
+   if (cpumask_empty(mask))
+   return true;
+
+   local_irq_save(flags);
+
+   for_each_cpu(cpu, mask) {
+   apic_id = per_cpu(x86_cpu_to_apicid, cpu);
+   if (apic_id < BITS_PER_LONG)
+   __set_bit(apic_id, _bitmap_low);
+   else if (apic_id < 2 * BITS_PER_LONG)
+   __set_bit(apic_id - BITS_PER_LONG, _bitmap_high);
+   else
+   goto ipi_mask_done;
+   }
+
+   switch (vector) {
+   default:
+   icr = APIC_DM_FIXED | vector;
+   break;
+   case NMI_VECTOR:
+   icr = APIC_DM_NMI;
+   break;
+   }
+
+   ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high, 
icr);
+
+ipi_mask_done:
+   local_irq_restore(flags);
+   return ((ret == 0) ? true : false);
+}
+
+static void kvm_send_ipi_mask(const struct cpumask *mask, int vector)
+{
+   if (!__send_ipi_mask(mask, vector))
+   orig_apic.send_IPI_mask(mask, vector);
+}
+
+static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int 
vector)
+{
+   unsigned int this_cpu = smp_processor_id();
+   struct cpumask new_mask;
+   const struct cpumask *local_mask;
+
+   cpumask_copy(_mask, mask);
+   cpumask_clear_cpu(this_cpu, _mask);
+   local_mask = _mask;
+   if (!__send_ipi_mask(local_mask, vector))
+   orig_apic.send_IPI_mask_allbutself(mask, vector);
+}
+
+static void kvm_send_ipi_allbutself(int vector)
+{
+   kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
+}
+
+static void kvm_send_ipi_all(int vector)
+{
+   if (!__send_ipi_mask(cpu_online_mask, vector))
+   orig_apic.send_IPI_all(vector);
+}
+
+/*
+ * Set the IPI entry points
+ */
+static void kvm_setup_pv_ipi(void)
+{
+   orig_apic = *apic;
+
+   apic->send_IPI_mask = kvm_send_ipi_mask;
+   apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
+   apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
+   apic->send_IPI_all = kvm_send_ipi_all;
+   pr_info("KVM setup pv IPIs\n");
+}
+#endif
+
 static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
 {
native_smp_prepare_cpus(max_cpus);
@@ -624,12 +708,27 @@ static uint32_t __init kvm_detect(void)
return kvm_cpuid_base();
 }
 
+static void __init kvm_apic_init(void)
+{
+#if defined(CONFIG_SMP) && defined(CONFIG_X86_64)
+   if (kvm_para_has_feature(KVM_FEATURE_PV_SEND_IPI) &&
+   num_possible_cpus() <= 2 * BITS_PER_LONG)
+   kvm_setup_pv_ipi();
+#endif
+}
+
+static void __init kvm_init_platform(void)
+{
+   x86_platform.apic_post_init = kvm_apic_init;
+}
+
 const __initconst struct hypervisor_x86 x86_hyper_kvm = {
.name   = "KVM",
.detect = kvm_detect,
.type   = X86_HYPER_KVM,
.init.guest_late_init   = kvm_guest_init,
.init.x2apic_available  = kvm_para_available,
+   .init.init_platform = kvm_init_platform,
 };
 
 static __init int activate_jump_labels(void)
diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h
index dcf629d..7395f38 100644
--- a/include/uapi/linux/kvm_para.h
+++ b/include/uapi/linux/kvm_para.h
@@ -26,6 +26,7 @@
 #define KVM_HC_MIPS_EXIT_VM7
 #define KVM_HC_MIPS_CONSOLE_OUTPUT 8
 #define KVM_HC_CLOCK_PAIRING   9
+#define KVM_HC_SEND_IPI10
 
 /*
  * hypercalls use architecture specific
-- 
2.7.4



Re: [PATCH v2 6/6] mm: page_mkclean, ttu: handle pinned pages

2018-07-02 Thread Jan Kara
On Sun 01-07-18 17:56:54, john.hubb...@gmail.com wrote:
> diff --git a/mm/memory-failure.c b/mm/memory-failure.c
> index 9d142b9b86dc..c4bc8d216746 100644
> --- a/mm/memory-failure.c
> +++ b/mm/memory-failure.c
> @@ -931,6 +931,7 @@ static bool hwpoison_user_mappings(struct page *p, 
> unsigned long pfn,
>   int kill = 1, forcekill;
>   struct page *hpage = *hpagep;
>   bool mlocked = PageMlocked(hpage);
> + bool skip_pinned_pages = false;

I'm not sure we can afford to wait for page pins when handling page
poisoning. In an ideal world we should but... But I guess this is for
someone understanding memory poisoning better to judge.

> diff --git a/mm/rmap.c b/mm/rmap.c
> index 6db729dc4c50..c137c43eb2ad 100644
> --- a/mm/rmap.c
> +++ b/mm/rmap.c
> @@ -879,6 +879,26 @@ int page_referenced(struct page *page,
>   return pra.referenced;
>  }
>  
> +/* Must be called with pinned_dma_lock held. */
> +static void wait_for_dma_pinned_to_clear(struct page *page)
> +{
> + struct zone *zone = page_zone(page);
> +
> + while (PageDmaPinnedFlags(page)) {
> + spin_unlock(zone_gup_lock(zone));
> +
> + schedule();
> +
> + spin_lock(zone_gup_lock(zone));
> + }
> +}

Ouch, we definitely need something better here. Either reuse the
page_waitqueue() mechanism or create at least a global wait queue for this
(I don't expect too much contention on the waitqueue and even if there
eventually is, we can switch to page_waitqueue() when we find it).  But
this is a no-go...

> +
> +struct page_mkclean_info {
> + int cleaned;
> + int skipped;
> + bool skip_pinned_pages;
> +};
> +
>  static bool page_mkclean_one(struct page *page, struct vm_area_struct *vma,
>   unsigned long address, void *arg)
>  {
> @@ -889,7 +909,24 @@ static bool page_mkclean_one(struct page *page, struct 
> vm_area_struct *vma,
>   .flags = PVMW_SYNC,
>   };
>   unsigned long start = address, end;
> - int *cleaned = arg;
> + struct page_mkclean_info *mki = (struct page_mkclean_info *)arg;
> + bool is_dma_pinned;
> + struct zone *zone = page_zone(page);
> +
> + /* Serialize with get_user_pages: */
> + spin_lock(zone_gup_lock(zone));
> + is_dma_pinned = PageDmaPinned(page);

Hum, why do you do this for each page table this is mapped in? Also the
locking is IMHO going to hurt a lot and we need to avoid it.

What I think needs to happen is that in page_mkclean(), after you've
cleared all the page tables, you check PageDmaPinned() and wait if needed.
Page cannot be faulted in again as we hold page lock and so races with
concurrent GUP are fairly limited. So with some careful ordering & memory
barriers you should be able to get away without any locking. Ditto for the
unmap path...

Honza
-- 
Jan Kara 
SUSE Labs, CR


[PATCH v2 0/2] KVM: x86: Add PV IPIs support

2018-07-02 Thread Wanpeng Li
Using hypercall to send IPIs by one vmexit instead of one by one for
xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster 
mode. 

Even if enable qemu interrupt remapping and PV TLB Shootdown, I can still 
observe ~14% performance boost by ebizzy benchmark for 64 vCPUs VM, the 
total msr-induced vmexits reduce ~70%.

The patchset implements the PV IPIs for vCPUs <= 128 VM, this is really 
common in cloud environment, after this patchset is applied, I can continue 
to add > 64 vCPUs VM support and that implementation has to introduce more 
complex logic.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Vitaly Kuznetsov 

v1 -> v2:
 * sparse apic id > 128, or any other errors, fallback to original apic hooks
 * have two bitmask arguments so that one hypercall handles 128 vCPUs 
 * fix KVM_FEATURE_PV_SEND_IPI doc
 * document hypercall
 * fix NMI selftest fails
 * fix build errors reported by 0day

Wanpeng Li (2):
  KVM: X86: Implement PV IPI in linux guest
  KVM: X86: Implement PV send IPI support

 Documentation/virtual/kvm/cpuid.txt  |  4 ++
 Documentation/virtual/kvm/hypercalls.txt |  6 ++
 arch/x86/include/uapi/asm/kvm_para.h |  1 +
 arch/x86/kernel/kvm.c| 99 
 arch/x86/kvm/cpuid.c |  3 +-
 arch/x86/kvm/x86.c   | 42 ++
 include/uapi/linux/kvm_para.h|  1 +
 7 files changed, 155 insertions(+), 1 deletion(-)

-- 
2.7.4



[PATCH v2 2/2] KVM: X86: Implement PV send IPI support

2018-07-02 Thread Wanpeng Li
From: Wanpeng Li 

Using hypercall to send IPIs by one vmexit instead of one by one for
xAPIC/x2APIC physical mode and one vmexit per-cluster for x2APIC cluster 
mode. 

Even if enable qemu interrupt remapping and PV TLB Shootdown, I can still 
observe ~14% performance boost by ebizzy benchmark for 64 vCPUs VM, the 
total msr-induced vmexits reduce ~70%.

Cc: Paolo Bonzini 
Cc: Radim Krčmář 
Cc: Vitaly Kuznetsov 
Signed-off-by: Wanpeng Li 
---
 Documentation/virtual/kvm/cpuid.txt  |  4 +++
 Documentation/virtual/kvm/hypercalls.txt |  6 +
 arch/x86/include/uapi/asm/kvm_para.h |  1 +
 arch/x86/kvm/cpuid.c |  3 ++-
 arch/x86/kvm/x86.c   | 42 
 5 files changed, 55 insertions(+), 1 deletion(-)

diff --git a/Documentation/virtual/kvm/cpuid.txt 
b/Documentation/virtual/kvm/cpuid.txt
index ab022dc..97ca194 100644
--- a/Documentation/virtual/kvm/cpuid.txt
+++ b/Documentation/virtual/kvm/cpuid.txt
@@ -62,6 +62,10 @@ KVM_FEATURE_ASYNC_PF_VMEXIT||10 || 
paravirtualized async PF VM exit
||   || can be enabled by setting bit 2
||   || when writing to msr 0x4b564d02
 --
+KVM_FEATURE_PV_SEND_IPI||11 || guest checks this feature bit
+   ||   || before using paravirtualized
+   ||   || send IPIs.
+--
 KVM_FEATURE_CLOCKSOURCE_STABLE_BIT ||24 || host will warn if no guest-side
||   || per-cpu warps are expected in
||   || kvmclock.
diff --git a/Documentation/virtual/kvm/hypercalls.txt 
b/Documentation/virtual/kvm/hypercalls.txt
index a890529..a771ee8 100644
--- a/Documentation/virtual/kvm/hypercalls.txt
+++ b/Documentation/virtual/kvm/hypercalls.txt
@@ -121,3 +121,9 @@ compute the CLOCK_REALTIME for its clock, at the same 
instant.
 
 Returns KVM_EOPNOTSUPP if the host does not use TSC clocksource,
 or if clock type is different than KVM_CLOCK_PAIRING_WALLCLOCK.
+
+6. KVM_HC_SEND_IPI
+
+Architecture: x86
+Status: active
+Purpose: Hypercall used to send IPIs.
diff --git a/arch/x86/include/uapi/asm/kvm_para.h 
b/arch/x86/include/uapi/asm/kvm_para.h
index 0ede697..19980ec 100644
--- a/arch/x86/include/uapi/asm/kvm_para.h
+++ b/arch/x86/include/uapi/asm/kvm_para.h
@@ -28,6 +28,7 @@
 #define KVM_FEATURE_PV_UNHALT  7
 #define KVM_FEATURE_PV_TLB_FLUSH   9
 #define KVM_FEATURE_ASYNC_PF_VMEXIT10
+#define KVM_FEATURE_PV_SEND_IPI11
 
 #define KVM_HINTS_REALTIME  0
 
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 7e042e3..7bcfa61 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -621,7 +621,8 @@ static inline int __do_cpuid_ent(struct kvm_cpuid_entry2 
*entry, u32 function,
 (1 << KVM_FEATURE_CLOCKSOURCE_STABLE_BIT) |
 (1 << KVM_FEATURE_PV_UNHALT) |
 (1 << KVM_FEATURE_PV_TLB_FLUSH) |
-(1 << KVM_FEATURE_ASYNC_PF_VMEXIT);
+(1 << KVM_FEATURE_ASYNC_PF_VMEXIT) |
+(1 << KVM_FEATURE_PV_SEND_IPI);
 
if (sched_info_on())
entry->eax |= (1 << KVM_FEATURE_STEAL_TIME);
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 0046aa7..c2cef21 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -6689,6 +6689,45 @@ static void kvm_pv_kick_cpu_op(struct kvm *kvm, unsigned 
long flags, int apicid)
kvm_irq_delivery_to_apic(kvm, NULL, _irq, NULL);
 }
 
+/*
+ * Return 0 if successfully added and 1 if discarded.
+ */
+static int kvm_pv_send_ipi(struct kvm *kvm, unsigned long ipi_bitmap_low,
+   unsigned long ipi_bitmap_high, unsigned long icr)
+{
+   int i;
+   struct kvm_apic_map *map;
+   struct kvm_vcpu *vcpu;
+   struct kvm_lapic_irq irq = {0};
+
+   switch (icr & APIC_VECTOR_MASK) {
+   default:
+   irq.vector = icr & APIC_VECTOR_MASK;
+   break;
+   case NMI_VECTOR:
+   break;
+   }
+   irq.delivery_mode = icr & APIC_MODE_MASK;
+
+   rcu_read_lock();
+   map = rcu_dereference(kvm->arch.apic_map);
+
+   for_each_set_bit(i, _bitmap_low, BITS_PER_LONG) {
+   vcpu = map->phys_map[i]->vcpu;
+   if (!kvm_apic_set_irq(vcpu, , NULL))
+   return 1;
+   }
+
+   for_each_set_bit(i, _bitmap_high, BITS_PER_LONG) {
+   vcpu = map->phys_map[i + BITS_PER_LONG]->vcpu;
+   if (!kvm_apic_set_irq(vcpu, , NULL))
+   return 1;
+   }
+
+   rcu_read_unlock();
+   return 0;
+}

Re: [PATCH v2 2/2] ASoC: es7241: add es7241 codec support

2018-07-02 Thread Jerome Brunet
On Mon, 2018-07-02 at 11:12 +0100, Mark Brown wrote:
> On Sat, Jun 30, 2018 at 07:22:41PM +0200, Jerome Brunet wrote:
> 
> > +   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> > +   case SND_SOC_DAIFMT_I2S:
> > +   case SND_SOC_DAIFMT_LEFT_J:
> > +   break;
> 
> These two modes are not the same so either there should be some
> different handling to select between them or one shouldn't be supported.
> 
> Otherwise this looks good.

Actually, the difference is provided with some pull-up/pull-down resistor.
There no way to set this up in SW, AFAIK.
So the driver shall accept both and trust we are not doing anything crazy



Re: [PATCH 0/2] serial: 8250_dw: add fractional divisor support

2018-07-02 Thread Andy Shevchenko
On Mon, 2018-07-02 at 18:04 +0800, Jisheng Zhang wrote:
> For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
> valid divisor latch fraction register. The fractional divisor width is
> 4bits ~ 6bits.
> 

There are several serial IPs that have fractional divider built-in. None
is using any specific hooks. Why do you need in your case, esp. taking
into consideration that we have a custom ->set_termios() callback?

> patch1 introduces necessary hooks to 8250 core.
> patch2 implement the fractional divisor support for Synopsys DW 8250.
> 
> Jisheng Zhang (2):
>   serial: 8250: introduce get_divisor() and set_divisor() hook
>   serial: 8250_dw: add fractional divisor support
> 
>  drivers/tty/serial/8250/8250_core.c |  4 +++
>  drivers/tty/serial/8250/8250_dw.c   | 54
> +
>  drivers/tty/serial/8250/8250_port.c |  8 +
>  include/linux/serial_8250.h |  7 
>  4 files changed, 73 insertions(+)
> 

-- 
Andy Shevchenko 
Intel Finland Oy


Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier

2018-07-02 Thread Benjamin Herrenschmidt
On Sun, 2018-07-01 at 10:04 -0700, Linus Torvalds wrote:
> On Sun, Jul 1, 2018 at 12:16 AM Benjamin Herrenschmidt
>  wrote:
> > 
> > I suspect you didn't read it my entire argument or I wasn't clear
> > enough :-) This is actually the crux of the problem:
> > 
> > Yes the object continues to exist. However, the *last* kobject_put to
> > it will no longer be done under whatever higher level locking the
> > subsystem provides (whatever prevents for example concurrent add and
> > removes).
> 
> Well, yes and no.
> 
> Why "no"?
> 
> The last dropping is actually not necessarily that interesting.
> Especially with the sysfs interface, we basically know that you can
> look up the object using RCU (since that's what the filesystem lookup
> does), and that basically means that the refcount is always the final
> serialization mechanism.There is nothing else that can possibly lock
> it.
> 
> So this is where we disagree:
> 
> > Thus in that scenario the "last minute" kobject_release() done by the
> > last kobject_put() will be effectively unprotected from for example the
> > gdp_mutex (in the case of the gluedirs) or whatever other locking the
> > subsystem owning the kobject is using to avoid making that "refount 0"
> > object "discoverable".
> 
> No. *Fundamentally*, there is only one thing that protects that
> object: the refcount.
> 
> And my argument is that anything that has this model (which means
> anything that has any sysfs linkage, which pretty much means any
> kobject) absolutely *must* use "kobject_get_unless_zero()" unless it
> had an existing stable pointer and just wants to increase the refcount
> (ie "already got a reference throuigh one of my data structures that
> use the lock")
> 
> But if you have that model, that means that the "last drop" is
> actually almost totally irrelevant.  Because it doesn't matter if it's
> done inside the lock or not - you know that once it has been done,
> that object is entirely gone. It's not discoverable any more -
> regardless of locking. The discoverability is basically controlled
> entirely by the refcount.
> 
> So what happens then?
> 
> The locking isn't important for the last release, but it *is*
> important for new object *creation*.
> 
> Why?
> 
> The refcount means that once an object is gone, it's gone for
> *everyone*. It's a one-way thing, and it's thread-safe. So the code
> that does *creation* can do this:
> 
>  - get subsystem lock
>  - look up object (using the "unless_zero()" model)
>  - if you got the object, re-use it, and you're done: drop lock and return
>  - otherwise, you know that nobody else can get it either
>  - create new object and instantiate it
>  - drop lock
> 
> and this means that you create a new object IFF the old object had its
> refcount drop to zero. So you always have exactly one copy (or no copy
> at all, in between the last drop and the creation of the new one).
> 
> See? The lack of locking at drop time didn't matter.  The refcount
> itself serialized things.
> 
> So the above is what I *think* the "glue_dir" logic should be. No need
> for any other count. Just re-use the old glue dir if you can find it,
> and create a new one if you can't.
> 
> The one important thing is that the object lookup above needs to use
> the lookup needs to find the object all the way until the refcount has
> become zero. And that actually means that the object MUST NOT be
> removed from the object lists until *after* the refcount has been
> decremented to zero. Which is actually why that "automatic cleanup"
> that you hate is actually an integral and important part of the
> process: removing the object *before* the refcount went to zero is
> broken, because that means that the "look up object" phase can now
> miss an object that still has a non-zero refcount.
> 
> > So my patch 1/2 prevents us from finding the old dying object (and thus
> > from crashing) but replaces this with the duplicate name problem.
> 
> So I absolutely agree with your patch 1/2. My argument against it is
> actually that I think the "unless_zero" thing needs to be more
> universal.
> 
> > My patch 2/2 removes that second problem by ensuring we remove the
> > object from sysfs synchronously in device_del when it no longer
> > contains any children, explicitely rather than implicitely by the
> > virtue of doing the "last" kobject_put.
> 
> No. See above. The reason I think your patch 2/2 is wrong is that is
> actually *breaks* the above model, exactly because of that thing that
> you hatre.
> 
> The explicit removal is actively wrong for the "I want to reuse the
> object" model, exactly because it happens before the refcount has gone
> to zero.
> 
> > > No.  That the zero kobject_get() will not result in a warning. It just
> > > does a kref_get(), no warnings anywhere.
> > 
> > It's there but it's in refcount:
> > 
> > void refcount_inc(refcount_t *r)
> > {
> > WARN_ONCE(!refcount_inc_not_zero(r), "refcount_t: increment on 0; 
> > use-after-free.\n");
> > }
> > 

[PATCH 2/3] arm/arm64: configs: Remove the MFD_ prefix for MFD_CROS_EC_I2C/SPI symbols.

2018-07-02 Thread Enric Balletbo i Serra
The cros-ec I2C and SPI transport drivers have been moved from MFD
subsystem to platform/chrome, at the same time, the config symbol has
been renamed and lost the MFD_ prefix, so update all configs to the new
config symbol name.

Signed-off-by: Enric Balletbo i Serra 
---

 arch/arm/configs/exynos_defconfig   | 4 ++--
 arch/arm/configs/multi_v7_defconfig | 4 ++--
 arch/arm/configs/pxa_defconfig  | 4 ++--
 arch/arm64/configs/defconfig| 4 ++--
 4 files changed, 8 insertions(+), 8 deletions(-)

diff --git a/arch/arm/configs/exynos_defconfig 
b/arch/arm/configs/exynos_defconfig
index 85b2369d6b20..27ea6dfcf2f2 100644
--- a/arch/arm/configs/exynos_defconfig
+++ b/arch/arm/configs/exynos_defconfig
@@ -155,8 +155,8 @@ CONFIG_THERMAL_EMULATION=y
 CONFIG_WATCHDOG=y
 CONFIG_S3C2410_WATCHDOG=y
 CONFIG_MFD_CROS_EC=y
-CONFIG_MFD_CROS_EC_I2C=y
-CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_CROS_EC_I2C=y
+CONFIG_CROS_EC_SPI=y
 CONFIG_MFD_MAX14577=y
 CONFIG_MFD_MAX77686=y
 CONFIG_MFD_MAX77693=y
diff --git a/arch/arm/configs/multi_v7_defconfig 
b/arch/arm/configs/multi_v7_defconfig
index 8f6be1982545..be732f382418 100644
--- a/arch/arm/configs/multi_v7_defconfig
+++ b/arch/arm/configs/multi_v7_defconfig
@@ -490,8 +490,8 @@ CONFIG_MFD_AC100=y
 CONFIG_MFD_AXP20X_I2C=y
 CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=m
-CONFIG_MFD_CROS_EC_I2C=m
-CONFIG_MFD_CROS_EC_SPI=m
+CONFIG_CROS_EC_I2C=m
+CONFIG_CROS_EC_SPI=m
 CONFIG_MFD_DA9063=m
 CONFIG_MFD_MAX14577=y
 CONFIG_MFD_MAX77686=y
diff --git a/arch/arm/configs/pxa_defconfig b/arch/arm/configs/pxa_defconfig
index 5655a1cee87d..6bb506edb1f5 100644
--- a/arch/arm/configs/pxa_defconfig
+++ b/arch/arm/configs/pxa_defconfig
@@ -398,8 +398,8 @@ CONFIG_MFD_AS3711=y
 CONFIG_MFD_BCM590XX=m
 CONFIG_MFD_AXP20X=y
 CONFIG_MFD_CROS_EC=m
-CONFIG_MFD_CROS_EC_I2C=m
-CONFIG_MFD_CROS_EC_SPI=m
+CONFIG_CROS_EC_I2C=m
+CONFIG_CROS_EC_SPI=m
 CONFIG_MFD_ASIC3=y
 CONFIG_PMIC_DA903X=y
 CONFIG_HTC_EGPIO=y
diff --git a/arch/arm64/configs/defconfig b/arch/arm64/configs/defconfig
index f9a186f6af8a..3ec0feccdd62 100644
--- a/arch/arm64/configs/defconfig
+++ b/arch/arm64/configs/defconfig
@@ -372,8 +372,8 @@ CONFIG_UNIPHIER_WATCHDOG=y
 CONFIG_BCM2835_WDT=y
 CONFIG_MFD_AXP20X_RSB=y
 CONFIG_MFD_CROS_EC=y
-CONFIG_MFD_CROS_EC_I2C=y
-CONFIG_MFD_CROS_EC_SPI=y
+CONFIG_CROS_EC_I2C=y
+CONFIG_CROS_EC_SPI=y
 CONFIG_MFD_CROS_EC_CHARDEV=m
 CONFIG_MFD_EXYNOS_LPASS=m
 CONFIG_MFD_HI6421_PMIC=y
-- 
2.18.0



[PATCH 0/3] platform/chrome: mfd: Move cros-ec transport drivers to drivers/platform

2018-07-02 Thread Enric Balletbo i Serra
Hi,

The cros-ec transport drivers are placed in two subsystems, in MFD and
in platform/chrome. As far as I know there is no reason for this, so,
move the I2C and the SPI cros-ec transport driver from the MFD subsystem
to the platform/chrome. The series also removes the MFD_ prefix for the
Kconfig symbols, modifies the defconfigs that used these symbols and
fixes the KEYBOARD_CROS_EC Kconfig help.

Best regards,
 Enric

Enric Balletbo i Serra (3):
  platform/chrome: Move cros-ec transport drivers to drivers/platform.
  arm/arm64: configs: Remove the MFD_ prefix for MFD_CROS_EC_I2C/SPI
symbols.
  Input: keyboard: Fix ChromeOS EC keyboard help message.

 arch/arm/configs/exynos_defconfig |  4 ++--
 arch/arm/configs/multi_v7_defconfig   |  4 ++--
 arch/arm/configs/pxa_defconfig|  4 ++--
 arch/arm64/configs/defconfig  |  4 ++--
 drivers/input/keyboard/Kconfig|  2 +-
 drivers/mfd/Kconfig   | 20 ---
 drivers/mfd/Makefile  |  2 --
 drivers/platform/chrome/Kconfig   | 20 +++
 drivers/platform/chrome/Makefile  |  2 ++
 .../{mfd => platform/chrome}/cros_ec_i2c.c|  0
 .../{mfd => platform/chrome}/cros_ec_spi.c|  0
 11 files changed, 31 insertions(+), 31 deletions(-)
 rename drivers/{mfd => platform/chrome}/cros_ec_i2c.c (100%)
 rename drivers/{mfd => platform/chrome}/cros_ec_spi.c (100%)

-- 
2.18.0



[PATCH 3/3] Input: keyboard: Fix ChromeOS EC keyboard help message.

2018-07-02 Thread Enric Balletbo i Serra
The cros-ec I2C and SPI transport drivers have been moved from MFD
subsystem to platform/chrome, at the same time, the config symbol
has been renamed and lost the MFD_ prefix So, update the help message
accordingly.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/input/keyboard/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/input/keyboard/Kconfig b/drivers/input/keyboard/Kconfig
index 6bd97ffee761..4713957b0cbb 100644
--- a/drivers/input/keyboard/Kconfig
+++ b/drivers/input/keyboard/Kconfig
@@ -721,7 +721,7 @@ config KEYBOARD_CROS_EC
help
  Say Y here to enable the matrix keyboard used by ChromeOS devices
  and implemented on the ChromeOS EC. You must enable one bus option
- (MFD_CROS_EC_I2C or MFD_CROS_EC_SPI) to use this.
+ (CROS_EC_I2C or CROS_EC_SPI) to use this.
 
  To compile this driver as a module, choose M here: the
  module will be called cros_ec_keyb.
-- 
2.18.0



Re: [PATCH v11 2/2] Add the missing information in dump_header

2018-07-02 Thread Michal Hocko
On Sun 01-07-18 00:38:59, ufo19890...@gmail.com wrote:
> From: yuzhoujian 
> 
> Add a new func mem_cgroup_print_oom_context to print missing information
> for the system-wide oom report which includes the oom memcg that has
> reached its limit, task memcg that contains the killed task.

A proper changelog should contain the motivation. It is trivial to see
what the patch does from the diff. The motivation is less clear. What
about the followig
"
The current oom report doesn't display victim's memcg context during the
global OOM situation. While this information is not strictly needed it
can be really usefule for containerized environments to see which
container has lost a process (+ add more arguments I am just guessing
from your not really specific statements). Now that we have a single
line for the oom context we can trivially add both the oom memcg (this
can be either global_oom or a specific memcg which hits its hard limits)
and task_memcg which is the victim's memcg.
"
-- 
Michal Hocko
SUSE Labs


[PATCH] iio: dac: remove redundant variable 'shift'

2018-07-02 Thread Colin King
From: Colin Ian King 

Variable shift is being assigned but is never used hence it is
redundant and can be removed.

Cleans up two clang warnings:
warning: variable ‘shift’ set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 drivers/iio/dac/ti-dac5571.c | 6 --
 1 file changed, 6 deletions(-)

diff --git a/drivers/iio/dac/ti-dac5571.c b/drivers/iio/dac/ti-dac5571.c
index dd21eebed6a8..e39d1e901353 100644
--- a/drivers/iio/dac/ti-dac5571.c
+++ b/drivers/iio/dac/ti-dac5571.c
@@ -97,9 +97,6 @@ static int dac5571_cmd_quad(struct dac5571_data *data, int 
channel, u16 val)
 
 static int dac5571_pwrdwn_single(struct dac5571_data *data, int channel, u8 
pwrdwn)
 {
-   unsigned int shift;
-
-   shift = 12 - data->spec->resolution;
data->buf[1] = 0;
data->buf[0] = pwrdwn << DAC5571_SINGLE_PWRDWN_BITS;
 
@@ -111,9 +108,6 @@ static int dac5571_pwrdwn_single(struct dac5571_data *data, 
int channel, u8 pwrd
 
 static int dac5571_pwrdwn_quad(struct dac5571_data *data, int channel, u8 
pwrdwn)
 {
-   unsigned int shift;
-
-   shift = 16 - data->spec->resolution;
data->buf[2] = 0;
data->buf[1] = pwrdwn << DAC5571_QUAD_PWRDWN_BITS;
data->buf[0] = (channel << DAC5571_CHANNEL_SELECT) |
-- 
2.17.1



Re: [PATCH 4.9 000/101] 4.9.111-stable review

2018-07-02 Thread Greg KH
On Mon, Jul 02, 2018 at 11:57:36AM +0200, Geert Uytterhoeven wrote:
> Hi Greg,
> 
> On Sun, Jul 1, 2018 at 6:26 PM Greg Kroah-Hartman
>  wrote:
> > This is the start of the stable review cycle for the 4.9.111 release.
> > There are 101 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> 
> Thank you for your hard work on -stable!
> 
> > Pseudo-Shortlog of commits:
> 
> Given you do publish a git tree with these changes, is there any specific 
> reason
> you're not using a real shortlog? Sorting and grouping would make it
> easier to see
> which patches of mine you have backported.

Many years ago Linus wanted it in this type of format as it was easier
to see what was being applied to the trees.  Given that it is a git
tree, you can see the shortlog yourself, and you are cc:ed on any of
your own patches directly, right?

thanks,

greg k-h


Re: [PATCH 2/2] drivers: core: Remove glue dirs from sysfs earlier

2018-07-02 Thread Benjamin Herrenschmidt
On Mon, 2018-07-02 at 09:36 +1000, Benjamin Herrenschmidt wrote:
> > No. See above. The reason I think your patch 2/2 is wrong is that is
> > actually *breaks* the above model, exactly because of that thing that
> > you hatre.
> > 
> > The explicit removal is actively wrong for the "I want to reuse the
> > object" model, exactly because it happens before the refcount has gone
> > to zero.
> 
> That's indeed where we disagree.

Sooo...

I had some quality time with my good friend Oban 14 last night,
thinking through this and during the resulting hangover today. I've
tried very hard to "get" your perspective, but after another dive
through the code, I'm afraid I still think patch 2/2 is the right thing
to do.

(Let's ignore patch 1/1 for now and assume we get that part right)

Let me try one last ditch attempt to convince you using maybe a
different perspective: this is how sysfs is intended to work and how
the device model already does everywhere else except the gluedirs.

Sooo... let's start pulling the string bit by bit...

I think you agree since (I'm not going to try to quote you here) you
did mention adding/removing need to generally be protected by higher
level locks in whatever subsystem owns the kobjects. I don't think
there's an argument here.

This is hinted by some comments (among others) in sysfs/dir.c about the
kobject owner being responsible to ensure that removal doesn't race
with any operation, which is hard to do when such removal doesn't
happen under subsystem internal locks.

Now let's look at how things are handled for a normal struct device
kobject.

The device core provides device_add and device_del functions. Those are
completely orthogonal to the object lifetime controlled by
device_initialize (creation) and device_put. And for good reasons (yes,
there are helpers, device_register/unregister that combine them, but
those are just that... helpers).

Why ? For the exact same reason mentioned above: Along with all the
driver binding/unbinding business etc... those functions ensure that
the kobject of the device is added/removed from sysfs under all the
necessary locks in the device model, so that they cannot race with each
other.

This guarantees among others that it is possible to do a new device_add
for the same device immediately after device_del, without clashing with
a duplicate sysfs name, *even* if something still holds a reference to
the kobject for any reason (and there are plenty of these, see the cdev
example below).

The actual lifetime of the struct device is handled *separately* by
device_get/put which are just wrappers on kobject_get/put.

This is the same with a cdev. cdev_add and cdev_del or their friends
cdev_device_add/del do the same thing. The chardev case is interesting
specifically because it is much more common for these to persist
(lifetime) beyond cdev_del. You just need userspace to have an open
file descriptor to the chardev. Drivers have to deal with it of course,
they need to handle things like read/write/ioctl being called on
already open files after remove/del/unbind, and hopefully do so.

*But* it's also possible to create a new identical cdev with the same
sysfs name immediately after cdev_device_del even if the old one still
has open instanced precisely because we separate the sysfs presence,
handled through the device model internal locking, from the object
lifetime.

Now, going back to our gluedirs, in essence those are just more objects
owned by the device core. More specifically, they need to be created
synchronously with the first child device of a class added under a
given parent, and removed synchronously with the last child device of
that class under that same parent.

Delaying that removal from sysfs simply means that we now are unable to
re-add the same device after removing it for some arbitrary amount of
time, because something might still hold a kobject reference to the
gluedir for any reason, it doesn't matter.

It also means that the deletion from sysfs is no longer synchronized
with addition since it no longer happens from within the context of
decice_del which is the "owner" of the glue dir, under whatever locks
it uses to ensure there is no races between multiple devices addition
removal etc...

In fact, if you look at the code and the way the gdp_mutex is used, I
think this is *exactly* the intention of the code. That the
kobject_put() done inside device_del() is the last one, done under that
mutex, thus removing the gluedir synchronously and we have no race.

However, that code just fails to take into account the delayed removal
by kobject debugging and the possibility of another reference existing.

Now it's possible there there can be no other references of a gluedir
today, to be frank I haven't audited the entire code base to figure out
if anything can possibly hold one that isn't a child of that gluedir,
so if indeed there can't be any and the only references to the kref
possible *ever* on a gluedir are its children, then it's 

Re: printk() from NMI backtrace can delay a lot

2018-07-02 Thread Sergey Senozhatsky
Hi,

On (07/02/18 19:26), Tetsuo Handa wrote:
> Hello.
> 
> Today I was testing conditions when/how stall watchdog fires. I noticed that
> printing NMI backtraces to consoles is delayed till IRQ is enabled or somebody
> else schedules printk(). This is not a welcomed behavior when the cause of
> lock up is doing nearly-infinite loop with IRQ disabled. Can we improve this?

Hmm. We can't call console drivers from NMI, this can deadlock on
uart/etc locks. So we always need [except for panic()] someone else to
print NMI message for us. Either it's IRQ on a local CPU (we need two
IRQs actually - one to flush printk_nmi buffer and the second one to do
console_trylock()->console_unlock()), or printk() from another CPU that
would print pending logbuf entries. We used to have a fast path for
print_nmi messages (direct_nmi), which soon will be used only for
NMI->ftrace_dump(). Even if we re-introduce that fast path for printk_nmi
[may be we can do printk_direct_nmi type of checks for printk_nmi as well]
we still can't print anything from the NMI CPU.

I need to look more at the data you have provided.

-ss


Re: [PATCH] iio: dac: remove redundant variable 'shift'

2018-07-02 Thread Sean Nyekjær




On 2018-07-02 12:24, Colin King wrote:

From: Colin Ian King 

Variable shift is being assigned but is never used hence it is
redundant and can be removed.

Cleans up two clang warnings:
warning: variable ‘shift’ set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 

Reviewed-by: Sean Nyekjaer 

Good catch :-)

BR
/Sean


[PATCH] x86/entry/64: add two more instruction suffixes

2018-07-02 Thread Jan Beulich
Sadly, other than claimed in a368d7fd2a ("x86/entry/64: Add instruction
suffix"), there are two more instances which want to be adjusted. As
said there, omitting suffixes from instructions in AT mode is bad
practice when operand size cannot be determined by the assembler from
register operands, and is likely going to be warned about by upstream
gas in the future (mine does already). Add the other missing suffixes
here as well.

Signed-off-by: Jan Beulich 
---
 arch/x86/entry/entry_64.S |4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

--- 4.18-rc3/arch/x86/entry/entry_64.S
+++ 4.18-rc3-x86_64-entry-insn-suffix/arch/x86/entry/entry_64.S
@@ -92,7 +92,7 @@ END(native_usergs_sysret64)
 .endm
 
 .macro TRACE_IRQS_IRETQ_DEBUG
-   bt  $9, EFLAGS(%rsp)/* interrupts off? */
+   btl $9, EFLAGS(%rsp)/* interrupts off? */
jnc 1f
TRACE_IRQS_ON_DEBUG
 1:
@@ -701,7 +701,7 @@ retint_kernel:
 #ifdef CONFIG_PREEMPT
/* Interrupts are off */
/* Check if we need preemption */
-   bt  $9, EFLAGS(%rsp)/* were interrupts off? */
+   btl $9, EFLAGS(%rsp)/* were interrupts off? */
jnc 1f
 0: cmpl$0, PER_CPU_VAR(__preempt_count)
jnz 1f






[PATCH] hrtimer: consolidate hrtimer_init() + hrtimer_init_sleeper() calls

2018-07-02 Thread Anna-Maria Gleixner
From: Sebastian Andrzej Siewior 

hrtimer_init_sleeper() calls require a prior initialisation of the
hrtimer object with hrtimer_init(). Lets make the initialisation of
the hrtimer object part of hrtimer_init_sleeper(). To remain
consistent consider init_on_stack as well.

Beside adapting the hrtimer_init_sleeper[_on_stack]() functions, call
sites need to be updated as well.

Link: http://lkml.kernel.org/r/20170905135719.qsj4h5twhjkmk...@linutronix.de
Signed-off-by: Sebastian Andrzej Siewior 
[anna-maria: Updating the commit message]
Signed-off-by: Anna-Maria Gleixner 
---
 block/blk-mq.c  |  3 +--
 include/linux/hrtimer.h | 19 ++---
 include/linux/wait.h|  4 ++--
 kernel/futex.c  | 19 +++--
 kernel/time/hrtimer.c   | 46 -
 net/core/pktgen.c   |  4 ++--
 6 files changed, 65 insertions(+), 30 deletions(-)

diff --git a/block/blk-mq.c b/block/blk-mq.c
index 95919268564b..f95ad9ede0f6 100644
--- a/block/blk-mq.c
+++ b/block/blk-mq.c
@@ -2984,10 +2984,9 @@ static bool blk_mq_poll_hybrid_sleep(struct 
request_queue *q,
kt = nsecs;
 
mode = HRTIMER_MODE_REL;
-   hrtimer_init_on_stack(, CLOCK_MONOTONIC, mode);
+   hrtimer_init_sleeper_on_stack(, CLOCK_MONOTONIC, mode, current);
hrtimer_set_expires(, kt);
 
-   hrtimer_init_sleeper(, current);
do {
if (blk_mq_rq_state(rq) == MQ_RQ_COMPLETE)
break;
diff --git a/include/linux/hrtimer.h b/include/linux/hrtimer.h
index 3892e9c8b2de..b8bbaabd5aff 100644
--- a/include/linux/hrtimer.h
+++ b/include/linux/hrtimer.h
@@ -364,10 +364,17 @@ DECLARE_PER_CPU(struct tick_device, tick_cpu_device);
 /* Initialize timers: */
 extern void hrtimer_init(struct hrtimer *timer, clockid_t which_clock,
 enum hrtimer_mode mode);
+extern void hrtimer_init_sleeper(struct hrtimer_sleeper *sl, clockid_t 
clock_id,
+enum hrtimer_mode mode,
+struct task_struct *task);
 
 #ifdef CONFIG_DEBUG_OBJECTS_TIMERS
 extern void hrtimer_init_on_stack(struct hrtimer *timer, clockid_t which_clock,
  enum hrtimer_mode mode);
+extern void hrtimer_init_sleeper_on_stack(struct hrtimer_sleeper *sl,
+ clockid_t clock_id,
+ enum hrtimer_mode mode,
+ struct task_struct *task);
 
 extern void destroy_hrtimer_on_stack(struct hrtimer *timer);
 #else
@@ -377,6 +384,15 @@ static inline void hrtimer_init_on_stack(struct hrtimer 
*timer,
 {
hrtimer_init(timer, which_clock, mode);
 }
+
+static inline void hrtimer_init_sleeper_on_stack(struct hrtimer_sleeper *sl,
+   clockid_t clock_id,
+   enum hrtimer_mode mode,
+   struct task_struct *task)
+{
+   hrtimer_init_sleeper(sl, clock_id, mode, task);
+}
+
 static inline void destroy_hrtimer_on_stack(struct hrtimer *timer) { }
 #endif
 
@@ -480,9 +496,6 @@ extern long hrtimer_nanosleep(const struct timespec64 *rqtp,
  const enum hrtimer_mode mode,
  const clockid_t clockid);
 
-extern void hrtimer_init_sleeper(struct hrtimer_sleeper *sl,
-struct task_struct *tsk);
-
 extern int schedule_hrtimeout_range(ktime_t *expires, u64 delta,
const enum hrtimer_mode mode);
 extern int schedule_hrtimeout_range_clock(ktime_t *expires,
diff --git a/include/linux/wait.h b/include/linux/wait.h
index d9f131ecf708..a0938fc8dcdb 100644
--- a/include/linux/wait.h
+++ b/include/linux/wait.h
@@ -488,8 +488,8 @@ do {
\
int __ret = 0;  
\
struct hrtimer_sleeper __t; 
\

\
-   hrtimer_init_on_stack(&__t.timer, CLOCK_MONOTONIC, HRTIMER_MODE_REL);   
\
-   hrtimer_init_sleeper(&__t, current);
\
+   hrtimer_init_sleeper_on_stack(&__t, CLOCK_MONOTONIC, HRTIMER_MODE_REL,  
\
+ current); 
\
if ((timeout) != KTIME_MAX) 
\
hrtimer_start_range_ns(&__t.timer, timeout, 
\
   current->timer_slack_ns, 
\
diff --git a/kernel/futex.c b/kernel/futex.c
index 1f450e092c74..146432d78e06 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -2624,10 +2624,9 @@ static int futex_wait(u32 __user *uaddr, unsigned int 
flags, u32 val,
   

[PATCH] ide-tape: remove redundant variable buffer_size

2018-07-02 Thread Colin King
From: Colin Ian King 

Variable buffer_size is being assigned but is never used hence it is
redundant and can be removed.

Cleans up clang warning:
warning: variable 'buffer_size' set but not used [-Wunused-but-set-variable]

Signed-off-by: Colin Ian King 
---
 drivers/ide/ide-tape.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/ide/ide-tape.c b/drivers/ide/ide-tape.c
index aee7b46d2330..34c1165226a4 100644
--- a/drivers/ide/ide-tape.c
+++ b/drivers/ide/ide-tape.c
@@ -1746,7 +1746,6 @@ static void idetape_setup(ide_drive_t *drive, 
idetape_tape_t *tape, int minor)
 {
unsigned long t;
int speed;
-   int buffer_size;
u16 *ctl = (u16 *)>caps[12];
 
ide_debug_log(IDE_DBG_FUNC, "minor: %d", minor);
@@ -1781,7 +1780,6 @@ static void idetape_setup(ide_drive_t *drive, 
idetape_tape_t *tape, int minor)
*ctl /= 2;
tape->buffer_size = *ctl * tape->blk_size;
}
-   buffer_size = tape->buffer_size;
 
/* select the "best" DSC read/write polling freq */
speed = max(*(u16 *)>caps[14], *(u16 *)>caps[8]);
-- 
2.17.1



Re: [PATCH] ACPI/PPTT: use ACPI ID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set

2018-07-02 Thread Sudeep Holla



On 30/06/18 08:16, Andrew Jones wrote:
> On Fri, Jun 29, 2018 at 05:17:57PM +0100, Sudeep Holla wrote:
>> Currently we use the ACPI processor ID only for the leaf/processor nodes
>> as the specification states it must match the value of ACPI processor ID
>> field in the processor’s entry in the MADT.
>>
>> However, if a PPTT structure represents processors group, it match a
>> processor container UID in the namespace and 
>> ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
>> flag describe whether the ACPI processor ID is valid.
>>
>> Lets use UID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set to be
>> consistent instead of using table offset as it's currently done for non
>> leaf nodes.
>>
>> Cc: "Rafael J. Wysocki" 
>> Signed-off-by: Sudeep Holla 
>> ---
>>  drivers/acpi/pptt.c | 10 --
>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> There's ongoing discussion on assigning ID based in OS using simple
>> counters. It can never be consistent with firmware's view. So if the
>> firmware provides valid UID for non-processors node, we must use it.
> 
> I agree with this. I've been so focused on the fact that the ACPI offsets
> are arbitrary, and thus counters can't be worse, that I nearly forgot how
> these IDs are actually defined:
> 

Yes, it's platform dependent and I now realize that I never explicitly
mentioned that, let alone emphasize on that. I was for UID for the same
reason.

[...]

> 
> When the valid flag is set we'll now return a [hopefully] correct platform
> dependent ID, but when it's not we'll return an ACPI table offset. How
> will users of the ID know? Also, it's possible to return -ENOENT for the
> ID when calling find_acpi_cpu_topology(). How can we distinguish that from
> an arbitrary platform dependent ID?
> 

But why should one need to distinguish that ? Even offset is kind of
sparsely distributed UID.
-- 
Regards,
Sudeep


Re: [PATCH 3/5] ASoC: es7134: update DT binding with new compatible and supplies

2018-07-02 Thread Mark Brown
On Fri, Jun 29, 2018 at 05:09:22PM +0200, Jerome Brunet wrote:
> Update the documentation to add support for the es7154 and
> optional power supplies phandles.

> +Optional properties:
> +- VDD-supply: regulator phandle for the VDD supply
> +- AVDD-supply: regulator phandle for the AVDD supply

Unless the device is able to work with a power supply missing (which
doesn't seem entirely credible) supply properties should never be
optional.


signature.asc
Description: PGP signature


[PATCH 0/2] serial: 8250_dw: add fractional divisor support

2018-07-02 Thread Jisheng Zhang
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.

patch1 introduces necessary hooks to 8250 core.
patch2 implement the fractional divisor support for Synopsys DW 8250.

Jisheng Zhang (2):
  serial: 8250: introduce get_divisor() and set_divisor() hook
  serial: 8250_dw: add fractional divisor support

 drivers/tty/serial/8250/8250_core.c |  4 +++
 drivers/tty/serial/8250/8250_dw.c   | 54 +
 drivers/tty/serial/8250/8250_port.c |  8 +
 include/linux/serial_8250.h |  7 
 4 files changed, 73 insertions(+)

-- 
2.18.0



[PATCH 1/2] serial: 8250: introduce get_divisor() and set_divisor() hook

2018-07-02 Thread Jisheng Zhang
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits. Add get_divisor() and set_divisor() hook to prepare
supporting this feature in next commit.

Signed-off-by: Jisheng Zhang 
---
 drivers/tty/serial/8250/8250_core.c | 4 
 drivers/tty/serial/8250/8250_port.c | 8 
 include/linux/serial_8250.h | 7 +++
 3 files changed, 19 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_core.c 
b/drivers/tty/serial/8250/8250_core.c
index 9342fc2ee7df..da0f3849bfce 100644
--- a/drivers/tty/serial/8250/8250_core.c
+++ b/drivers/tty/serial/8250/8250_core.c
@@ -1035,6 +1035,10 @@ int serial8250_register_8250_port(struct uart_8250_port 
*up)
uart->dl_read = up->dl_read;
if (up->dl_write)
uart->dl_write = up->dl_write;
+   if (up->get_divisor)
+   uart->get_divisor = up->get_divisor;
+   if (up->set_divisor)
+   uart->set_divisor = up->set_divisor;
 
if (uart->port.type != PORT_8250_CIR) {
if (serial8250_isa_config != NULL)
diff --git a/drivers/tty/serial/8250/8250_port.c 
b/drivers/tty/serial/8250/8250_port.c
index cf541aab2bd0..0060ec54a522 100644
--- a/drivers/tty/serial/8250/8250_port.c
+++ b/drivers/tty/serial/8250/8250_port.c
@@ -2505,6 +2505,9 @@ static unsigned int serial8250_get_divisor(struct 
uart_8250_port *up,
struct uart_port *port = >port;
unsigned int quot;
 
+   if (up->get_divisor)
+   return up->get_divisor(up, baud, frac);
+
/*
 * Handle magic divisors for baud rates above baud_base on
 * SMSC SuperIO chips.
@@ -2575,6 +2578,11 @@ static void serial8250_set_divisor(struct uart_port 
*port, unsigned int baud,
 {
struct uart_8250_port *up = up_to_u8250p(port);
 
+   if (up->set_divisor) {
+   up->set_divisor(up, baud, quot, quot_frac);
+   return;
+   }
+
/* Workaround to enable 115200 baud on OMAP1510 internal ports */
if (is_omap1510_8250(up)) {
if (baud == 115200) {
diff --git a/include/linux/serial_8250.h b/include/linux/serial_8250.h
index 76b9db71e489..5093c9ca0980 100644
--- a/include/linux/serial_8250.h
+++ b/include/linux/serial_8250.h
@@ -132,6 +132,13 @@ struct uart_8250_port {
/* 8250 specific callbacks */
int (*dl_read)(struct uart_8250_port *);
void(*dl_write)(struct uart_8250_port *, int);
+   unsigned int(*get_divisor)(struct uart_8250_port *up,
+  unsigned int baud,
+  unsigned int *frac);
+   void(*set_divisor)(struct uart_8250_port *up,
+  unsigned int baud,
+  unsigned int quot,
+  unsigned int quot_frac);
 
struct uart_8250_em485 *em485;
 };
-- 
2.18.0



Re: [PATCH v2 1/2] ASoC: es7241: add dt-bindings documentation for the es7241 adc

2018-07-02 Thread Mark Brown
On Sat, Jun 30, 2018 at 07:22:40PM +0200, Jerome Brunet wrote:

> +Optional properties:
> +- VDDP-supply: regulator phandle for the VDDA supply
> +- VDDA-supply: regulator phandle for the VDDP supply
> +- VDDD-supply: regulator phandle for the VDDD supply

Same issue as with the other binding: power isn't optional in the
hardware so shouldn't be optional in the binding.


signature.asc
Description: PGP signature


[PATCH 2/2] serial: 8250_dw: add fractional divisor support

2018-07-02 Thread Jisheng Zhang
For Synopsys DesignWare 8250 uart which version >= 4.00a, there's a
valid divisor latch fraction register. The fractional divisor width is
4bits ~ 6bits.

Now the preparation is done, it's easy to add the feature support.
This patch firstly checks the component version during probe, if
version >= 4.00a, then calculates the fractional divisor width, then
setups dw specific get_divisor() and set_divisor() hook.

Signed-off-by: Jisheng Zhang 
---
 drivers/tty/serial/8250/8250_dw.c | 54 +++
 1 file changed, 54 insertions(+)

diff --git a/drivers/tty/serial/8250/8250_dw.c 
b/drivers/tty/serial/8250/8250_dw.c
index aff04f1de3a5..367a73507c5e 100644
--- a/drivers/tty/serial/8250/8250_dw.c
+++ b/drivers/tty/serial/8250/8250_dw.c
@@ -31,9 +31,12 @@
 
 /* Offsets for the DesignWare specific registers */
 #define DW_UART_USR0x1f /* UART Status Register */
+#define DW_UART_DLF0xc0 /* Divisor Latch Fraction Register */
 #define DW_UART_CPR0xf4 /* Component Parameter Register */
 #define DW_UART_UCV0xf8 /* UART Component Version */
 
+#define DW_FRAC_MIN_VERS   0x3430302A
+
 /* Component Parameter Register bits */
 #define DW_UART_CPR_ABP_DATA_WIDTH (3 << 0)
 #define DW_UART_CPR_AFCE_MODE  (1 << 4)
@@ -65,6 +68,7 @@ struct dw8250_data {
 
unsigned intskip_autocfg:1;
unsigned intuart_16550_compatible:1;
+   unsigned intdlf_size:3;
 };
 
 static inline int dw8250_modify_msr(struct uart_port *p, int offset, int value)
@@ -351,6 +355,34 @@ static bool dw8250_idma_filter(struct dma_chan *chan, void 
*param)
return param == chan->device->dev->parent;
 }
 
+/*
+ * For version >= 4.00a, the dw uarts have a valid divisor latch fraction
+ * register. Calculate divisor with extra 4bits ~ 6bits fractional portion.
+ */
+static unsigned int dw8250_get_divisor(struct uart_8250_port *up,
+  unsigned int baud,
+  unsigned int *frac)
+{
+   unsigned int quot;
+   struct uart_port *p = >port;
+   struct dw8250_data *d = p->private_data;
+
+   quot = DIV_ROUND_CLOSEST(p->uartclk << (d->dlf_size - 4), baud);
+   *frac = quot & (~0U >> (32 - d->dlf_size));
+
+   return quot >> d->dlf_size;
+}
+
+static void dw8250_set_divisor(struct uart_8250_port *up, unsigned int baud,
+  unsigned int quot, unsigned int quot_frac)
+{
+   struct uart_port *p = >port;
+
+   serial_port_out(p, DW_UART_DLF >> p->regshift, quot_frac);
+   serial_port_out(p, UART_LCR, up->lcr | UART_LCR_DLAB);
+   serial_dl_write(up, quot);
+}
+
 static void dw8250_quirks(struct uart_port *p, struct dw8250_data *data)
 {
if (p->dev->of_node) {
@@ -414,6 +446,28 @@ static void dw8250_setup_port(struct uart_port *p)
dev_dbg(p->dev, "Designware UART version %c.%c%c\n",
(reg >> 24) & 0xff, (reg >> 16) & 0xff, (reg >> 8) & 0xff);
 
+   /*
+* For version >= 4.00a, the dw uarts have a valid divisor latch
+* fraction register. Calculate the fractional divisor width.
+*/
+   if (reg >= DW_FRAC_MIN_VERS) {
+   struct dw8250_data *d = p->private_data;
+
+   if (p->iotype == UPIO_MEM32BE) {
+   iowrite32be(~0U, p->membase + DW_UART_DLF);
+   reg = ioread32be(p->membase + DW_UART_DLF);
+   } else {
+   writel(~0U, p->membase + DW_UART_DLF);
+   reg = readl(p->membase + DW_UART_DLF);
+   }
+   d->dlf_size = fls(reg);
+
+   if (d->dlf_size) {
+   up->get_divisor = dw8250_get_divisor;
+   up->set_divisor = dw8250_set_divisor;
+   }
+   }
+
if (p->iotype == UPIO_MEM32BE)
reg = ioread32be(p->membase + DW_UART_CPR);
else
-- 
2.18.0



Applied "ASoC: es7134: remove 64kHz rate from the supported rates" to the asoc tree

2018-07-02 Thread Mark Brown
The patch

   ASoC: es7134: remove 64kHz rate from the supported rates

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 5650729f9a1bbf65b57139d855dabe0a7e6cb494 Mon Sep 17 00:00:00 2001
From: Jerome Brunet 
Date: Fri, 29 Jun 2018 17:09:20 +0200
Subject: [PATCH] ASoC: es7134: remove 64kHz rate from the supported rates

64Khz is actually not supported by the es7134 according to the datasheet

Fixes: 9000b59d7a12 ("ASoC: es7134: add es7134 DAC driver")
Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/es7134.c | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/sound/soc/codecs/es7134.c b/sound/soc/codecs/es7134.c
index 58515bb1a303..2fbb49f5b278 100644
--- a/sound/soc/codecs/es7134.c
+++ b/sound/soc/codecs/es7134.c
@@ -48,7 +48,11 @@ static struct snd_soc_dai_driver es7134_dai = {
.stream_name = "Playback",
.channels_min = 2,
.channels_max = 2,
-   .rates = SNDRV_PCM_RATE_8000_192000,
+   .rates = (SNDRV_PCM_RATE_8000_48000 |
+ SNDRV_PCM_RATE_88200  |
+ SNDRV_PCM_RATE_96000  |
+ SNDRV_PCM_RATE_176400 |
+ SNDRV_PCM_RATE_192000),
.formats = (SNDRV_PCM_FMTBIT_S16_LE  |
SNDRV_PCM_FMTBIT_S18_3LE |
SNDRV_PCM_FMTBIT_S20_3LE |
-- 
2.18.0.rc2



Re: [PATCH] ACPI/PPTT: use ACPI ID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set

2018-07-02 Thread Sudeep Holla



On 29/06/18 19:18, Jeremy Linton wrote:
> Hi,
> 
> On 06/29/2018 11:17 AM, Sudeep Holla wrote:
>> Currently we use the ACPI processor ID only for the leaf/processor nodes
>> as the specification states it must match the value of ACPI processor ID
>> field in the processor’s entry in the MADT.
>>
>> However, if a PPTT structure represents processors group, it match a
>> processor container UID in the namespace and
>> ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
>> flag describe whether the ACPI processor ID is valid.
>>
>> Lets use UID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set to be
>> consistent instead of using table offset as it's currently done for non
>> leaf nodes.
>>
>> Cc: "Rafael J. Wysocki" 
>> Signed-off-by: Sudeep Holla 
>> ---
>>   drivers/acpi/pptt.c | 10 --
>>   1 file changed, 8 insertions(+), 2 deletions(-)
>>
>> Hi,
>>
>> There's ongoing discussion on assigning ID based in OS using simple
>> counters. It can never be consistent with firmware's view. So if the
>> firmware provides valid UID for non-processors node, we must use it.
>>
>> Regards,
>> Sudeep
>>
>> diff --git a/drivers/acpi/pptt.c b/drivers/acpi/pptt.c
>> index e5ea1974d1e3..d1e26cb599bf 100644
>> --- a/drivers/acpi/pptt.c
>> +++ b/drivers/acpi/pptt.c
>> @@ -481,8 +481,14 @@ static int topology_get_acpi_cpu_tag(struct
>> acpi_table_header *table,
>>   if (cpu_node) {
>>   cpu_node = acpi_find_processor_package_id(table, cpu_node,
>>     level, flag);
>> -    /* Only the first level has a guaranteed id */
>> -    if (level == 0)
>> +    /*
>> + * As per specification if the processor structure represents
>> + * an actual processor, then ACPI processor ID must be valid.
>> + * For processor containers ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
>> + * should be set if the UID is valid
>> + */
>> +    if (level == 0 ||
>> +    cpu_node->flags & ACPI_PPTT_ACPI_PROCESSOR_ID_VALID)
>>   return cpu_node->acpi_processor_id;
> 
> While, for some machines this likely helps create more human readable
> ID's... What happens when the ID namespaces conflict with each other?
> 

That's entirely left to the platform firmware. It should help userspace
to identify the topology in a way firmware is describing and no more
than that. If users use them for anything more, it's at their own risk.

> AKA, I'm a little shy of this change because your going from something
> we can guarantee is unique to depending on an portion of the PPTT
> definition that has a couple different ways that it can be interpreted.
> 

No, I am not guaranteeing anything here. I am just passing valid UID if
present to the caller. Interpretation is left to the caller and in ARM64
we should just use(at least my preference) the value as is for sysfs
topology.

> OTOH the change is probably safe at the moment because i don't think
> anyone has partially marked nodes at a given PPTT "level" valid, or put
> structures that aren't part of the PE/cache's in the tree (outside of my
> juno test tree with the GPU's/etc).
> 

Even if they are present, I don't see issue. If that's how firmware
presents the CPU topology, that should be exactly the way we too need to.

-- 
Regards,
Sudeep


Applied "ASoC: es7134: Add VDD and AVDD power supplies" to the asoc tree

2018-07-02 Thread Mark Brown
The patch

   ASoC: es7134: Add VDD and AVDD power supplies

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 424e2b4b3521334812d833eef27df77671428698 Mon Sep 17 00:00:00 2001
From: Jerome Brunet 
Date: Fri, 29 Jun 2018 17:09:23 +0200
Subject: [PATCH] ASoC: es7134: Add VDD and AVDD power supplies

Add the VDD and AVDD power supplies to the DAPM graph as some board may
need to enable a regulator to turn them on.

Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/es7134.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/sound/soc/codecs/es7134.c b/sound/soc/codecs/es7134.c
index 698289dc3e22..5ad59c38fed1 100644
--- a/sound/soc/codecs/es7134.c
+++ b/sound/soc/codecs/es7134.c
@@ -167,11 +167,15 @@ static const struct snd_soc_dapm_widget 
es7134_dapm_widgets[] = {
SND_SOC_DAPM_OUTPUT("AOUTL"),
SND_SOC_DAPM_OUTPUT("AOUTR"),
SND_SOC_DAPM_DAC("DAC", "Playback", SND_SOC_NOPM, 0, 0),
+   SND_SOC_DAPM_REGULATOR_SUPPLY("VDD", 0, 0),
+   SND_SOC_DAPM_REGULATOR_SUPPLY("AVDD", 0, 0),
 };
 
 static const struct snd_soc_dapm_route es7134_dapm_routes[] = {
{ "AOUTL", NULL, "DAC" },
{ "AOUTR", NULL, "DAC" },
+   { "Playback", NULL, "VDD" },
+   { "DAC", NULL, "AVDD" },
 };
 
 static const struct snd_soc_component_driver es7134_component_driver = {
-- 
2.18.0.rc2



Applied "ASoC: es7134: check if mclk rate is valid" to the asoc tree

2018-07-02 Thread Mark Brown
The patch

   ASoC: es7134: check if mclk rate is valid

has been applied to the asoc tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/sound.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From a016b11cc41df06b79c0c226e719d0d88373919c Mon Sep 17 00:00:00 2001
From: Jerome Brunet 
Date: Fri, 29 Jun 2018 17:09:21 +0200
Subject: [PATCH] ASoC: es7134: check if mclk rate is valid

For each supported sample rate, the es7134 can work with several
mclk / sample rate ratio. Check if ratio we get is actually OK.

Signed-off-by: Jerome Brunet 
Signed-off-by: Mark Brown 
---
 sound/soc/codecs/es7134.c | 119 +-
 1 file changed, 117 insertions(+), 2 deletions(-)

diff --git a/sound/soc/codecs/es7134.c b/sound/soc/codecs/es7134.c
index 2fbb49f5b278..698289dc3e22 100644
--- a/sound/soc/codecs/es7134.c
+++ b/sound/soc/codecs/es7134.c
@@ -17,6 +17,7 @@
  * in the file called COPYING.
  */
 
+#include 
 #include 
 #include 
 
@@ -24,6 +25,77 @@
  * The everest 7134 is a very simple DA converter with no register
  */
 
+struct es7134_clock_mode {
+   unsigned int rate_min;
+   unsigned int rate_max;
+   unsigned int *mclk_fs;
+   unsigned int mclk_fs_num;
+};
+
+struct es7134_chip {
+   const struct es7134_clock_mode *modes;
+   unsigned int mode_num;
+};
+
+struct es7134_data {
+   unsigned int mclk;
+   const struct es7134_chip *chip;
+};
+
+static int es7134_check_mclk(struct snd_soc_dai *dai,
+struct es7134_data *priv,
+unsigned int rate)
+{
+   unsigned int mfs = priv->mclk / rate;
+   int i, j;
+
+   for (i = 0; i < priv->chip->mode_num; i++) {
+   const struct es7134_clock_mode *mode = >chip->modes[i];
+
+   if (rate < mode->rate_min || rate > mode->rate_max)
+   continue;
+
+   for (j = 0; j < mode->mclk_fs_num; j++) {
+   if (mode->mclk_fs[j] == mfs)
+   return 0;
+   }
+
+   dev_err(dai->dev, "unsupported mclk_fs %u for rate %u\n",
+   mfs, rate);
+   return -EINVAL;
+   }
+
+   /* should not happen */
+   dev_err(dai->dev, "unsupported rate: %u\n", rate);
+   return -EINVAL;
+}
+
+static int es7134_hw_params(struct snd_pcm_substream *substream,
+   struct snd_pcm_hw_params *params,
+   struct snd_soc_dai *dai)
+{
+   struct es7134_data *priv = snd_soc_dai_get_drvdata(dai);
+
+   /* mclk has not been provided, assume it is OK */
+   if (!priv->mclk)
+   return 0;
+
+   return es7134_check_mclk(dai, priv, params_rate(params));
+}
+
+static int es7134_set_sysclk(struct snd_soc_dai *dai, int clk_id,
+unsigned int freq, int dir)
+{
+   struct es7134_data *priv = snd_soc_dai_get_drvdata(dai);
+
+   if (dir == SND_SOC_CLOCK_IN && clk_id == 0) {
+   priv->mclk = freq;
+   return 0;
+   }
+
+   return -ENOTSUPP;
+}
+
 static int es7134_set_fmt(struct snd_soc_dai *codec_dai, unsigned int fmt)
 {
fmt &= (SND_SOC_DAIFMT_FORMAT_MASK | SND_SOC_DAIFMT_INV_MASK |
@@ -40,6 +112,8 @@ static int es7134_set_fmt(struct snd_soc_dai *codec_dai, 
unsigned int fmt)
 
 static const struct snd_soc_dai_ops es7134_dai_ops = {
.set_fmt= es7134_set_fmt,
+   .hw_params  = es7134_hw_params,
+   .set_sysclk = es7134_set_sysclk,
 };
 
 static struct snd_soc_dai_driver es7134_dai = {
@@ -62,6 +136,33 @@ static struct snd_soc_dai_driver es7134_dai = {
.ops = _dai_ops,
 };
 
+static const struct es7134_clock_mode es7134_modes[] = {
+   {
+   /* Single speed mode */
+   .rate_min = 8000,
+   .rate_max = 5,
+   .mclk_fs = (unsigned int[]) { 256, 384, 512, 768, 1024 },
+   .mclk_fs_num = 5,
+   }, {
+   /* Double speed mode */
+   .rate_min = 84000,
+   .rate_max = 10,
+   .mclk_fs = (unsigned int[]) { 128, 192, 256, 384, 512 },
+   .mclk_fs_num = 5,
+   }, {
+   /* Quad speed mode 

Applied "spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe" to the spi tree

2018-07-02 Thread Mark Brown
The patch

   spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe

has been applied to the spi tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/spi.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From d8ffee2f551a627ffb7b216e2da322cb9a037f77 Mon Sep 17 00:00:00 2001
From: Krzysztof Kozlowski 
Date: Fri, 29 Jun 2018 13:33:09 +0200
Subject: [PATCH] spi: spi-fsl-dspi: Fix imprecise abort on VF500 during probe

Registers of DSPI should not be accessed before enabling its clock.  On
Toradex Colibri VF50 on Iris carrier board this could be seen during
bootup as imprecise abort:

Unhandled fault: imprecise external abort (0x1c06) at 0x
Internal error: : 1c06 [#1] ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper Not tainted 4.14.39-dirty #97
Hardware name: Freescale Vybrid VF5xx/VF6xx (Device Tree)
Backtrace:
[<804166a8>] (regmap_write) from [<80466b5c>] (dspi_probe+0x1f0/0x8dc)
[<8046696c>] (dspi_probe) from [<8040107c>] (platform_drv_probe+0x54/0xb8)
[<80401028>] (platform_drv_probe) from [<803ff53c>] 
(driver_probe_device+0x280/0x2f8)
[<803ff2bc>] (driver_probe_device) from [<803ff674>] 
(__driver_attach+0xc0/0xc4)
[<803ff5b4>] (__driver_attach) from [<803fd818>] 
(bus_for_each_dev+0x70/0xa4)
[<803fd7a8>] (bus_for_each_dev) from [<803fee74>] (driver_attach+0x24/0x28)
[<803fee50>] (driver_attach) from [<803fe980>] (bus_add_driver+0x1a0/0x218)
[<803fe7e0>] (bus_add_driver) from [<803fffe8>] (driver_register+0x80/0x100)
[<803fff68>] (driver_register) from [<80400fdc>] 
(__platform_driver_register+0x48/0x50)
[<80400f94>] (__platform_driver_register) from [<8091cf7c>] 
(fsl_dspi_driver_init+0x1c/0x20)
[<8091cf60>] (fsl_dspi_driver_init) from [<8010195c>] 
(do_one_initcall+0x4c/0x174)
[<80101910>] (do_one_initcall) from [<80900e8c>] 
(kernel_init_freeable+0x144/0x1d8)
[<80900d48>] (kernel_init_freeable) from [<805ff6a8>] 
(kernel_init+0x10/0x114)
[<805ff698>] (kernel_init) from [<80107be8>] (ret_from_fork+0x14/0x2c)

Cc: 
Fixes: 5ee67b587a2b ("spi: dspi: clear SPI_SR before enable interrupt")
Signed-off-by: Krzysztof Kozlowski 
Signed-off-by: Mark Brown 
---
 drivers/spi/spi-fsl-dspi.c | 24 
 1 file changed, 12 insertions(+), 12 deletions(-)

diff --git a/drivers/spi/spi-fsl-dspi.c b/drivers/spi/spi-fsl-dspi.c
index ff7456be9d6d..89a1e7a4fe5d 100644
--- a/drivers/spi/spi-fsl-dspi.c
+++ b/drivers/spi/spi-fsl-dspi.c
@@ -1071,30 +1071,30 @@ static int dspi_probe(struct platform_device *pdev)
}
}
 
+   dspi->clk = devm_clk_get(>dev, "dspi");
+   if (IS_ERR(dspi->clk)) {
+   ret = PTR_ERR(dspi->clk);
+   dev_err(>dev, "unable to get clock\n");
+   goto out_master_put;
+   }
+   ret = clk_prepare_enable(dspi->clk);
+   if (ret)
+   goto out_master_put;
+
dspi_init(dspi);
dspi->irq = platform_get_irq(pdev, 0);
if (dspi->irq < 0) {
dev_err(>dev, "can't get platform irq\n");
ret = dspi->irq;
-   goto out_master_put;
+   goto out_clk_put;
}
 
ret = devm_request_irq(>dev, dspi->irq, dspi_interrupt, 0,
pdev->name, dspi);
if (ret < 0) {
dev_err(>dev, "Unable to attach DSPI interrupt\n");
-   goto out_master_put;
-   }
-
-   dspi->clk = devm_clk_get(>dev, "dspi");
-   if (IS_ERR(dspi->clk)) {
-   ret = PTR_ERR(dspi->clk);
-   dev_err(>dev, "unable to get clock\n");
-   goto out_master_put;
+   goto out_clk_put;
}
-   ret = clk_prepare_enable(dspi->clk);
-   if (ret)
-   goto out_master_put;
 
if (dspi->devtype_data->trans_mode == DSPI_DMA_MODE) {
ret = dspi_request_dma(dspi, res->start);
-- 
2.18.0.rc2



Applied "regulator: Revert "regulator: pfuze100: add enable/disable for switch"" to the regulator tree

2018-07-02 Thread Mark Brown
The patch

   regulator: Revert "regulator: pfuze100: add enable/disable for switch"

has been applied to the regulator tree at

   https://git.kernel.org/pub/scm/linux/kernel/git/broonie/regulator.git 

All being well this means that it will be integrated into the linux-next
tree (usually sometime in the next 24 hours) and sent to Linus during
the next merge window (or sooner if it is a bug fix), however if
problems are discovered then the patch may be dropped or reverted.  

You may get further e-mails resulting from automated or manual testing
and review of the tree, please engage with people reporting problems and
send followup patches addressing any issues that are reported if needed.

If any updates are required or you are submitting further changes they
should be sent as incremental updates against current git, existing
patches will not be replaced.

Please add any relevant lists and maintainers to the CCs when replying
to this mail.

Thanks,
Mark

>From 464a5686e6c9df364fbfa9a6d0f61276a777d550 Mon Sep 17 00:00:00 2001
From: Fabio Estevam 
Date: Sun, 1 Jul 2018 22:18:27 -0300
Subject: [PATCH] regulator: Revert "regulator: pfuze100: add enable/disable
 for switch"

This reverts commit 5fe156f1cab4f340ddb6283c993912be77594016.

Commit 5fe156f1cab4 ("regulator: pfuze100: add enable/disable for switch")
causes boot regression on some platforms such as imx6sl-evk and
imx6sll-evk.

After this commit the SW4 regulator will be turned
off and since it supplies the DDR voltage on these boards, a
kernel hang is observed.

Revert it to avoid breaking old dtb's.

Fixes: 5fe156f1cab4 ("regulator: pfuze100: add enable/disable for switch")
Signed-off-by: Fabio Estevam 
Signed-off-by: Mark Brown 
---
 drivers/regulator/pfuze100-regulator.c | 8 
 1 file changed, 8 deletions(-)

diff --git a/drivers/regulator/pfuze100-regulator.c 
b/drivers/regulator/pfuze100-regulator.c
index 32f9af7f87c4..cde6eda1d283 100644
--- a/drivers/regulator/pfuze100-regulator.c
+++ b/drivers/regulator/pfuze100-regulator.c
@@ -163,9 +163,6 @@ static const struct regulator_ops 
pfuze100_fixed_regulator_ops = {
 };
 
 static const struct regulator_ops pfuze100_sw_regulator_ops = {
-   .enable = regulator_enable_regmap,
-   .disable = regulator_disable_regmap,
-   .is_enabled = regulator_is_enabled_regmap,
.list_voltage = regulator_list_voltage_linear,
.set_voltage_sel = regulator_set_voltage_sel_regmap,
.get_voltage_sel = regulator_get_voltage_sel_regmap,
@@ -212,11 +209,6 @@ static const struct regulator_ops 
pfuze100_swb_regulator_ops = {
.uV_step = (step),  \
.vsel_reg = (base) + PFUZE100_VOL_OFFSET,   \
.vsel_mask = 0x3f,  \
-   .enable_reg = (base) + PFUZE100_MODE_OFFSET,\
-   .enable_val = 0xc,  \
-   .disable_val = 0x0, \
-   .enable_mask = 0xf, \
-   .enable_time = 500, \
},  \
.stby_reg = (base) + PFUZE100_STANDBY_OFFSET,   \
.stby_mask = 0x3f,  \
-- 
2.18.0.rc2



Re: [PATCH v2 2/2] ASoC: es7241: add es7241 codec support

2018-07-02 Thread Mark Brown
On Sat, Jun 30, 2018 at 07:22:41PM +0200, Jerome Brunet wrote:

> + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> + case SND_SOC_DAIFMT_I2S:
> + case SND_SOC_DAIFMT_LEFT_J:
> + break;

These two modes are not the same so either there should be some
different handling to select between them or one shouldn't be supported.

Otherwise this looks good.


signature.asc
Description: PGP signature


Re: [PATCH v2 1/6] mm: get_user_pages: consolidate error handling

2018-07-02 Thread Jan Kara
On Sun 01-07-18 17:56:49, john.hubb...@gmail.com wrote:
> From: John Hubbard 
> 
> An upcoming patch requires a way to operate on each page that
> any of the get_user_pages_*() variants returns.
> 
> In preparation for that, consolidate the error handling for
> __get_user_pages(). This provides a single location (the "out:" label)
> for operating on the collected set of pages that are about to be returned.
> 
> As long every use of the "ret" variable is being edited, rename
> "ret" --> "err", so that its name matches its true role.
> This also gets rid of two shadowed variable declarations, as a
> tiny beneficial a side effect.
> 
> Signed-off-by: John Hubbard 

This looks nice! You can add:

Reviewed-by: Jan Kara 

Honza

> ---
>  mm/gup.c | 37 ++---
>  1 file changed, 22 insertions(+), 15 deletions(-)
> 
> diff --git a/mm/gup.c b/mm/gup.c
> index b70d7ba7cc13..73f0b3316fa7 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -660,6 +660,7 @@ static long __get_user_pages(struct task_struct *tsk, 
> struct mm_struct *mm,
>   struct vm_area_struct **vmas, int *nonblocking)
>  {
>   long i = 0;
> + int err = 0;
>   unsigned int page_mask;
>   struct vm_area_struct *vma = NULL;
>  
> @@ -685,18 +686,19 @@ static long __get_user_pages(struct task_struct *tsk, 
> struct mm_struct *mm,
>   if (!vma || start >= vma->vm_end) {
>   vma = find_extend_vma(mm, start);
>   if (!vma && in_gate_area(mm, start)) {
> - int ret;
> - ret = get_gate_page(mm, start & PAGE_MASK,
> + err = get_gate_page(mm, start & PAGE_MASK,
>   gup_flags, ,
>   pages ? [i] : NULL);
> - if (ret)
> - return i ? : ret;
> + if (err)
> + goto out;
>   page_mask = 0;
>   goto next_page;
>   }
>  
> - if (!vma || check_vma_flags(vma, gup_flags))
> - return i ? : -EFAULT;
> + if (!vma || check_vma_flags(vma, gup_flags)) {
> + err = -EFAULT;
> + goto out;
> + }
>   if (is_vm_hugetlb_page(vma)) {
>   i = follow_hugetlb_page(mm, vma, pages, vmas,
>   , _pages, i,
> @@ -709,23 +711,25 @@ static long __get_user_pages(struct task_struct *tsk, 
> struct mm_struct *mm,
>* If we have a pending SIGKILL, don't keep faulting pages and
>* potentially allocating memory.
>*/
> - if (unlikely(fatal_signal_pending(current)))
> - return i ? i : -ERESTARTSYS;
> + if (unlikely(fatal_signal_pending(current))) {
> + err = -ERESTARTSYS;
> + goto out;
> + }
>   cond_resched();
>   page = follow_page_mask(vma, start, foll_flags, _mask);
>   if (!page) {
> - int ret;
> - ret = faultin_page(tsk, vma, start, _flags,
> + err = faultin_page(tsk, vma, start, _flags,
>   nonblocking);
> - switch (ret) {
> + switch (err) {
>   case 0:
>   goto retry;
>   case -EFAULT:
>   case -ENOMEM:
>   case -EHWPOISON:
> - return i ? i : ret;
> + goto out;
>   case -EBUSY:
> - return i;
> + err = 0;
> + goto out;
>   case -ENOENT:
>   goto next_page;
>   }
> @@ -737,7 +741,8 @@ static long __get_user_pages(struct task_struct *tsk, 
> struct mm_struct *mm,
>*/
>   goto next_page;
>   } else if (IS_ERR(page)) {
> - return i ? i : PTR_ERR(page);
> + err = PTR_ERR(page);
> + goto out;
>   }
>   if (pages) {
>   pages[i] = page;
> @@ -757,7 +762,9 @@ static long __get_user_pages(struct task_struct *tsk, 
> struct mm_struct *mm,
>   start += page_increm * PAGE_SIZE;
>   nr_pages -= page_increm;
>   } while (nr_pages);
> - return i;
> +
> +out:
> + return i ? i : err;
>  }
>  
>  static bool 

Re: [PATCH v11 1/2] Refactor part of the oom report in dump_header

2018-07-02 Thread Michal Hocko
On Sun 01-07-18 00:38:58, ufo19890...@gmail.com wrote:
> From: yuzhoujian 
> 
> The current system wide oom report prints information about the victim
> and the allocation context and restrictions. It, however, doesn't
> provide any information about memory cgroup the victim belongs to. This
> information can be interesting for container users because they can find
> the victim's container much more easily.
> 
> I follow the advices of David Rientjes and Michal Hocko, and refactor
> part of the oom report. After this patch, users can get the memcg's
> path from the oom report and check the certain container more quickly.
> 
> The oom print info after this patch:
> oom-kill:constraint=,nodemask=,oom_memcg=,task_memcg=,task=,pid=,uid=

This changelog doesn't correspond to the patch. Also while we were
discussing this off-list, I have suggested to pull the cpuset info into
the single line output.

What about the following?
"
OOM report contains several sections. The first one is the allocation
context that has triggered the OOM. Then we have cpuset context
followed by the stack trace of the OOM path. Followed by the oom
eligible tasks and the information about the chosen oom victim.

One thing that makes parsing more awkward than necessary is that we do
not have a single and easily parsable line about the oom context. This
patch is reorganizing the oom report to
1) who invoked oom and what was the allocation request
[  126.168182] panic invoked oom-killer: 
gfp_mask=0x6280ca(GFP_HIGHUSER_MOVABLE|__GFP_ZERO), order=0, oom_score_adj=0

2) OOM stack trace
[  126.169806] CPU: 23 PID: 8668 Comm: panic Not tainted 4.18.0-rc2+ #36
[  126.170494] Hardware name: Inspur SA5212M4/YZMB-00370-107, BIOS 
4.1.10 11/14/2016
[  126.171197] Call Trace:
[  126.171901]  dump_stack+0x5a/0x73
[  126.172593]  dump_header+0x58/0x2dc
[  126.173294]  oom_kill_process+0x228/0x420
[  126.173999]  ? oom_badness+0x2a/0x130
[  126.174705]  out_of_memory+0x11a/0x4a0
[  126.175415]  __alloc_pages_slowpath+0x7cc/0xa1e
[  126.176128]  ? __alloc_pages_slowpath+0x194/0xa1e
[  126.176853]  ? page_counter_try_charge+0x54/0xc0
[  126.177580]  __alloc_pages_nodemask+0x277/0x290
[  126.178319]  alloc_pages_vma+0x73/0x180
[  126.179058]  do_anonymous_page+0xed/0x5a0
[  126.179825]  __handle_mm_fault+0xbb3/0xe70
[  126.180566]  handle_mm_fault+0xfa/0x210
[  126.181313]  __do_page_fault+0x233/0x4c0
[  126.182063]  do_page_fault+0x32/0x140
[  126.182812]  ? page_fault+0x8/0x30
[  126.183560]  page_fault+0x1e/0x30

3) oom context (contrains and the chosen victim)
[  126.190619] 
oom-kill:constraint=CONSTRAINT_NONE,nodemask=(null),cpuset=/,mems_allowed=0-1,task=panic,pid=
 8673,uid=0

An admin can easily get the full oom context at a single line which
makes parsing much easier.
"
-- 
Michal Hocko
SUSE Labs


Re: [PATCH v2 2/2] ASoC: es7241: add es7241 codec support

2018-07-02 Thread Mark Brown
On Mon, Jul 02, 2018 at 12:15:03PM +0200, Jerome Brunet wrote:
> On Mon, 2018-07-02 at 11:12 +0100, Mark Brown wrote:
> > On Sat, Jun 30, 2018 at 07:22:41PM +0200, Jerome Brunet wrote:

> > > + switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
> > > + case SND_SOC_DAIFMT_I2S:
> > > + case SND_SOC_DAIFMT_LEFT_J:
> > > + break;

> > These two modes are not the same so either there should be some
> > different handling to select between them or one shouldn't be supported.

> Actually, the difference is provided with some pull-up/pull-down resistor.
> There no way to set this up in SW, AFAIK.
> So the driver shall accept both and trust we are not doing anything crazy

It at least needs a comment as this is obviously dodgy code.  Ideally
there'd be a DT property saying which mode was selected on a given board
so if we ever get round to doing automatic configuration of formats the
driver will be able to cope.


signature.asc
Description: PGP signature


Re: [PATCH 5/5] ASoC: es7134: add support for the es7154

2018-07-02 Thread Mark Brown
On Mon, Jul 02, 2018 at 12:15:28PM +0200, Jerome Brunet wrote:
> On Mon, 2018-07-02 at 11:05 +0100, Mark Brown wrote:
> > On Fri, Jun 29, 2018 at 05:09:24PM +0200, Jerome Brunet wrote:

> > >   { .compatible = "everest,es7134", .data = _chip },
> > >   { .compatible = "everest,es7144", .data = _chip },
> > > + { .compatible = "everest,es7154", .data = _chip },
> > >   { }

> > This needs to be added to the DT documentation.

> I believe I added this in patch 3 of this serie, which I'll resubmit.
> Shall I resubmit this patch along with it ?

Yes, please.


signature.asc
Description: PGP signature


[PATCH 1/3] platform/chrome: Move cros-ec transport drivers to drivers/platform.

2018-07-02 Thread Enric Balletbo i Serra
There are some cros-ec transport drivers (I2C, SPI) living in MFD, while
others (LPC) living in drivers/platform. The transport drivers are more
platform specific. So, move the I2C and SPI transport drivers to the
platform/chrome directory. The patch also removes the MFD_ prefix of
their Kconfig symbols.

Signed-off-by: Enric Balletbo i Serra 
---

 drivers/mfd/Kconfig   | 20 ---
 drivers/mfd/Makefile  |  2 --
 drivers/platform/chrome/Kconfig   | 20 +++
 drivers/platform/chrome/Makefile  |  2 ++
 .../{mfd => platform/chrome}/cros_ec_i2c.c|  0
 .../{mfd => platform/chrome}/cros_ec_spi.c|  0
 6 files changed, 22 insertions(+), 22 deletions(-)
 rename drivers/{mfd => platform/chrome}/cros_ec_i2c.c (100%)
 rename drivers/{mfd => platform/chrome}/cros_ec_spi.c (100%)

diff --git a/drivers/mfd/Kconfig b/drivers/mfd/Kconfig
index b860eb5aa194..013458e728dc 100644
--- a/drivers/mfd/Kconfig
+++ b/drivers/mfd/Kconfig
@@ -202,26 +202,6 @@ config MFD_CROS_EC
  You also need to enable the driver for the bus you are using. The
  protocol for talking to the EC is defined by the bus driver.
 
-config MFD_CROS_EC_I2C
-   tristate "ChromeOS Embedded Controller (I2C)"
-   depends on MFD_CROS_EC && I2C
-
-   help
- If you say Y here, you get support for talking to the ChromeOS
- EC through an I2C bus. This uses a simple byte-level protocol with
- a checksum. Failing accesses will be retried three times to
- improve reliability.
-
-config MFD_CROS_EC_SPI
-   tristate "ChromeOS Embedded Controller (SPI)"
-   depends on MFD_CROS_EC && SPI
-
-   ---help---
- If you say Y here, you get support for talking to the ChromeOS EC
- through a SPI bus, using a byte-level protocol. Since the EC's
- response time cannot be guaranteed, we support ignoring
- 'pre-amble' bytes before the response actually starts.
-
 config MFD_CROS_EC_CHARDEV
 tristate "Chrome OS Embedded Controller userspace device interface"
 depends on MFD_CROS_EC
diff --git a/drivers/mfd/Makefile b/drivers/mfd/Makefile
index e9fd20dba18d..d13e859d7c1e 100644
--- a/drivers/mfd/Makefile
+++ b/drivers/mfd/Makefile
@@ -14,8 +14,6 @@ obj-$(CONFIG_MFD_BCM590XX)+= bcm590xx.o
 obj-$(CONFIG_MFD_BD9571MWV)+= bd9571mwv.o
 cros_ec_core-objs  := cros_ec.o
 obj-$(CONFIG_MFD_CROS_EC)  += cros_ec_core.o
-obj-$(CONFIG_MFD_CROS_EC_I2C)  += cros_ec_i2c.o
-obj-$(CONFIG_MFD_CROS_EC_SPI)  += cros_ec_spi.o
 obj-$(CONFIG_MFD_CROS_EC_CHARDEV) += cros_ec_dev.o
 obj-$(CONFIG_MFD_EXYNOS_LPASS) += exynos-lpass.o
 
diff --git a/drivers/platform/chrome/Kconfig b/drivers/platform/chrome/Kconfig
index cb0df9eb3e0f..16b1615958aa 100644
--- a/drivers/platform/chrome/Kconfig
+++ b/drivers/platform/chrome/Kconfig
@@ -52,6 +52,26 @@ config CHROMEOS_TBMC
 config CROS_EC_CTL
 tristate
 
+config CROS_EC_I2C
+   tristate "ChromeOS Embedded Controller (I2C)"
+   depends on MFD_CROS_EC && I2C
+
+   help
+ If you say Y here, you get support for talking to the ChromeOS
+ EC through an I2C bus. This uses a simple byte-level protocol with
+ a checksum. Failing accesses will be retried three times to
+ improve reliability.
+
+config CROS_EC_SPI
+   tristate "ChromeOS Embedded Controller (SPI)"
+   depends on MFD_CROS_EC && SPI
+
+   ---help---
+ If you say Y here, you get support for talking to the ChromeOS EC
+ through a SPI bus, using a byte-level protocol. Since the EC's
+ response time cannot be guaranteed, we support ignoring
+ 'pre-amble' bytes before the response actually starts.
+
 config CROS_EC_LPC
 tristate "ChromeOS Embedded Controller (LPC)"
 depends on MFD_CROS_EC && ACPI && (X86 || COMPILE_TEST)
diff --git a/drivers/platform/chrome/Makefile b/drivers/platform/chrome/Makefile
index e44c37a63fa9..cd591bf872bb 100644
--- a/drivers/platform/chrome/Makefile
+++ b/drivers/platform/chrome/Makefile
@@ -6,6 +6,8 @@ obj-$(CONFIG_CHROMEOS_TBMC) += chromeos_tbmc.o
 cros_ec_ctl-objs   := cros_ec_sysfs.o cros_ec_lightbar.o \
   cros_ec_vbc.o cros_ec_debugfs.o
 obj-$(CONFIG_CROS_EC_CTL)  += cros_ec_ctl.o
+obj-$(CONFIG_CROS_EC_I2C)  += cros_ec_i2c.o
+obj-$(CONFIG_CROS_EC_SPI)  += cros_ec_spi.o
 cros_ec_lpcs-objs  := cros_ec_lpc.o cros_ec_lpc_reg.o
 cros_ec_lpcs-$(CONFIG_CROS_EC_LPC_MEC) += cros_ec_lpc_mec.o
 obj-$(CONFIG_CROS_EC_LPC)  += cros_ec_lpcs.o
diff --git a/drivers/mfd/cros_ec_i2c.c b/drivers/platform/chrome/cros_ec_i2c.c
similarity index 100%
rename from drivers/mfd/cros_ec_i2c.c
rename to drivers/platform/chrome/cros_ec_i2c.c
diff --git a/drivers/mfd/cros_ec_spi.c b/drivers/platform/chrome/cros_ec_spi.c

Re: [PATCH v2 1/2] KVM: X86: Implement PV IPI in linux guest

2018-07-02 Thread Vitaly Kuznetsov
Wanpeng Li  writes:

> From: Wanpeng Li 
>
> Implement PV IPIs in guest kernel.
>
> Cc: Paolo Bonzini 
> Cc: Radim Krčmář 
> Cc: Vitaly Kuznetsov 
> Signed-off-by: Wanpeng Li 
> ---
>  arch/x86/kernel/kvm.c | 99 
> +++
>  include/uapi/linux/kvm_para.h |  1 +
>  2 files changed, 100 insertions(+)
>
> diff --git a/arch/x86/kernel/kvm.c b/arch/x86/kernel/kvm.c
> index 5b2300b..7e3ee25 100644
> --- a/arch/x86/kernel/kvm.c
> +++ b/arch/x86/kernel/kvm.c
> @@ -47,6 +47,7 @@
>  #include 
>  #include 
>
> +static struct apic orig_apic;
>  static int kvmapf = 1;
>
>  static int __init parse_no_kvmapf(char *arg)
> @@ -454,6 +455,89 @@ static void __init sev_map_percpu_data(void)
>  }
>
>  #ifdef CONFIG_SMP
> +
> +#ifdef CONFIG_X86_64
> +static bool __send_ipi_mask(const struct cpumask *mask, int vector)
> +{
> + unsigned long flags, ipi_bitmap_low = 0, ipi_bitmap_high = 0, icr = 0;
> + int cpu, apic_id, ret = 1;
> +
> + if (cpumask_empty(mask))
> + return true;
> +
> + local_irq_save(flags);
> +
> + for_each_cpu(cpu, mask) {
> + apic_id = per_cpu(x86_cpu_to_apicid, cpu);
> + if (apic_id < BITS_PER_LONG)
> + __set_bit(apic_id, _bitmap_low);
> + else if (apic_id < 2 * BITS_PER_LONG)
> + __set_bit(apic_id - BITS_PER_LONG, _bitmap_high);
> + else
> + goto ipi_mask_done;

Nit:

Both the fact that we don't set 'ret' here and the fact that the label
is named 'ipi_mask_done' -- which sounds like 'all OK' at least to me --
contribute to the feeling that we just skip sending IPIs in some cases.

I would prefer to see something like

else {
   ret = -EFAULT;
   goto irq_restore_exit;
}

> + }
> +
> + switch (vector) {
> + default:
> + icr = APIC_DM_FIXED | vector;
> + break;
> + case NMI_VECTOR:
> + icr = APIC_DM_NMI;
> + break;
> + }
> +
> + ret = kvm_hypercall3(KVM_HC_SEND_IPI, ipi_bitmap_low, ipi_bitmap_high, 
> icr);
> +
> +ipi_mask_done:
> + local_irq_restore(flags);
> + return ((ret == 0) ? true : false);

... and why in the first place do we need to make this function return
'bool' then? Let's just make it return 'int'.

> +}
> +
> +static void kvm_send_ipi_mask(const struct cpumask *mask, int vector)
> +{
> + if (!__send_ipi_mask(mask, vector))
> + orig_apic.send_IPI_mask(mask, vector);
> +}
> +
> +static void kvm_send_ipi_mask_allbutself(const struct cpumask *mask, int 
> vector)
> +{
> + unsigned int this_cpu = smp_processor_id();
> + struct cpumask new_mask;
> + const struct cpumask *local_mask;
> +
> + cpumask_copy(_mask, mask);
> + cpumask_clear_cpu(this_cpu, _mask);
> + local_mask = _mask;
> + if (!__send_ipi_mask(local_mask, vector))
> + orig_apic.send_IPI_mask_allbutself(mask, vector);
> +}
> +
> +static void kvm_send_ipi_allbutself(int vector)
> +{
> + kvm_send_ipi_mask_allbutself(cpu_online_mask, vector);
> +}
> +
> +static void kvm_send_ipi_all(int vector)
> +{
> + if (!__send_ipi_mask(cpu_online_mask, vector))
> + orig_apic.send_IPI_all(vector);
> +}
> +
> +/*
> + * Set the IPI entry points
> + */
> +static void kvm_setup_pv_ipi(void)
> +{
> + orig_apic = *apic;
> +
> + apic->send_IPI_mask = kvm_send_ipi_mask;
> + apic->send_IPI_mask_allbutself = kvm_send_ipi_mask_allbutself;
> + apic->send_IPI_allbutself = kvm_send_ipi_allbutself;
> + apic->send_IPI_all = kvm_send_ipi_all;
> + pr_info("KVM setup pv IPIs\n");
> +}
> +#endif
> +
>  static void __init kvm_smp_prepare_cpus(unsigned int max_cpus)
>  {
>   native_smp_prepare_cpus(max_cpus);
> @@ -624,12 +708,27 @@ static uint32_t __init kvm_detect(void)
>   return kvm_cpuid_base();
>  }
>
> +static void __init kvm_apic_init(void)
> +{
> +#if defined(CONFIG_SMP) && defined(CONFIG_X86_64)
> + if (kvm_para_has_feature(KVM_FEATURE_PV_SEND_IPI) &&
> + num_possible_cpus() <= 2 * BITS_PER_LONG)
> + kvm_setup_pv_ipi();
> +#endif
> +}
> +
> +static void __init kvm_init_platform(void)
> +{
> + x86_platform.apic_post_init = kvm_apic_init;
> +}
> +
>  const __initconst struct hypervisor_x86 x86_hyper_kvm = {
>   .name   = "KVM",
>   .detect = kvm_detect,
>   .type   = X86_HYPER_KVM,
>   .init.guest_late_init   = kvm_guest_init,
>   .init.x2apic_available  = kvm_para_available,
> + .init.init_platform = kvm_init_platform,
>  };
>
>  static __init int activate_jump_labels(void)
> diff --git a/include/uapi/linux/kvm_para.h b/include/uapi/linux/kvm_para.h
> index dcf629d..7395f38 100644
> --- a/include/uapi/linux/kvm_para.h
> +++ b/include/uapi/linux/kvm_para.h
> @@ -26,6 +26,7 @@
>  #define KVM_HC_MIPS_EXIT_VM  7
>  #define KVM_HC_MIPS_CONSOLE_OUTPUT   8
>  #define KVM_HC_CLOCK_PAIRING 

printk() from NMI backtrace can delay a lot

2018-07-02 Thread Tetsuo Handa
Hello.

Today I was testing conditions when/how stall watchdog fires. I noticed that
printing NMI backtraces to consoles is delayed till IRQ is enabled or somebody
else schedules printk(). This is not a welcomed behavior when the cause of
lock up is doing nearly-infinite loop with IRQ disabled. Can we improve this?

--
static int __init ccs_init(void)
{
unsigned long stamp = jiffies;
local_irq_disable();
while (time_before(jiffies, stamp + 130 * HZ)) /* Emulating a lockup 
bug. */
;
local_irq_enable();
return -EINVAL;
}
--

Below samples used netconsole in order to show the lag between printk() saved 
uptime
and printk() wrote the pending lines.



Loading the module after

  echo 25 > /sys/module/rcupdate/parameters/rcu_cpu_stall_timeout

--
2018-07-02 12:11:40 192.168.159.129: [   58.090624] netconsole: network 
logging started
2018-07-02 12:12:11 192.168.159.129: [   89.017794] akari_test: loading 
out-of-tree module taints kernel.
2018-07-02 12:12:41 192.168.159.129: [  119.024961] INFO: rcu_sched 
detected stalls on CPUs/tasks:
2018-07-02 12:12:41 192.168.159.129: [  119.026970] 2-...0: (0 
ticks this GP) idle=0be/1/4611686018427387904 softirq=5544/5544 fqs=7077 
2018-07-02 12:12:41 192.168.159.129: [  119.030076] (detected by 3, 
t=30005 jiffies, g=2553, c=2552, q=94)
2018-07-02 12:12:41 192.168.159.129: [  119.032142] Sending NMI from CPU 3 
to CPUs 2:

/* Here is a 32 seconds of lag which is flushed by */

2018-07-02 12:13:13 192.168.159.129: [  119.033877] NMI backtrace for cpu 2
2018-07-02 12:13:13 192.168.159.129: [  119.033884] CPU: 2 PID: 10038 Comm: 
insmod Tainted: G   O  4.18.0-rc3 #643
2018-07-02 12:13:13 192.168.159.129: [  119.033886] Hardware name: VMware, 
Inc. VMware Virtual Platform/440BX Desktop Reference Platform, BIOS 6.00 
05/19/2017
2018-07-02 12:13:13 192.168.159.129: [  119.033895] RIP: 
0010:__sanitizer_cov_trace_pc+0x20/0x50
2018-07-02 12:13:13 192.168.159.129: [  119.033896] Code: 5d c3 90 90 90 90 
90 90 90 90 55 65 48 8b 04 25 40 5e 01 00 48 89 e5 65 8b 15 6c f6 d1 7e 81 e2 
00 01 1f 00 48 8b 4d 08 75 2b <8b> 90 80 12 00 00 83 fa 02 75 20 48 8b b0 88 12 
00 00 8b 80 84 12 
2018-07-02 12:13:13 192.168.159.129: [  119.033942] RSP: 
0018:c9000205fc60 EFLAGS: 0046
2018-07-02 12:13:13 192.168.159.129: [  119.033945] RAX: 880136312080 
RBX: fffcc7e1 RCX: a000d038
2018-07-02 12:13:13 192.168.159.129: [  119.033947] RDX:  
RSI:  RDI: a000d033
2018-07-02 12:13:13 192.168.159.129: [  119.033949] RBP: c9000205fc60 
R08: 0001 R09: 
2018-07-02 12:13:13 192.168.159.129: [  119.033951] R10:  
R11:  R12: a000d000
2018-07-02 12:13:13 192.168.159.129: [  119.033953] R13: 8801351cd940 
R14: 0001 R15: c9000205fe78
2018-07-02 12:13:13 192.168.159.129: [  119.033956] FS:  
7f90d3e62740() GS:88013a68() knlGS:
2018-07-02 12:13:13 192.168.159.129: [  119.033958] CS:  0010 DS:  ES: 
 CR0: 80050033
2018-07-02 12:13:13 192.168.159.129: [  119.033961] CR2: 015051d8 
CR3: 000136a66004 CR4: 000606e0
2018-07-02 12:13:13 192.168.159.129: [  119.033998] Call Trace:
2018-07-02 12:13:13 192.168.159.129: [  119.034006]  ccs_init+0x38/0x79 
[akari_test]
2018-07-02 12:13:13 192.168.159.129: [  119.034011]  
do_one_initcall+0x7a/0x460
2018-07-02 12:13:13 192.168.159.129: [  119.034016]  ? 
trace_hardirqs_on+0xd/0x10
2018-07-02 12:13:13 192.168.159.129: [  119.034021]  
do_init_module+0x5a/0x1e0
2018-07-02 12:13:13 192.168.159.129: [  119.034024]  
load_module+0x2144/0x2800
2018-07-02 12:13:13 192.168.159.129: [  119.034030]  
__do_sys_finit_module+0xd1/0xf0
2018-07-02 12:13:13 192.168.159.129: [  119.034033]  ? 
__do_sys_finit_module+0xd1/0xf0
2018-07-02 12:13:13 192.168.159.129: [  119.034038]  
__x64_sys_finit_module+0x15/0x20
2018-07-02 12:13:13 192.168.159.129: [  119.034041]  
do_syscall_64+0x81/0x260
2018-07-02 12:13:13 192.168.159.129: [  119.034047]  
entry_SYSCALL_64_after_hwframe+0x49/0xbe
2018-07-02 12:13:13 192.168.159.129: [  119.034050] RIP: 0033:0x7f90d3335ec9
2018-07-02 12:13:13 192.168.159.129: [  119.034050] Code: 01 00 48 81 c4 80 
00 00 00 e9 f1 fe ff ff 0f 1f 00 48 89 f8 48 89 f7 48 89 d6 48 89 ca 4d 89 c2 
4d 89 c8 4c 8b 4c 24 08 0f 05 <48> 3d 01 f0 ff ff 73 01 c3 48 8b 0d 97 cf 2c 00 
f7 d8 64 89 01 48 
2018-07-02 12:13:13 192.168.159.129: [  119.034096] RSP: 
002b:7ffce0ff8338 EFLAGS: 0202 ORIG_RAX: 0139
2018-07-02 12:13:13 192.168.159.129: [  119.034100] RAX: ffda 
RBX: 015051e0 RCX: 7f90d3335ec9
2018-07-02 12:13:13 192.168.159.129: [  119.034102] RDX: 

Re: [PATCH upstream] KASAN: slab-out-of-bounds Read in getname_kernel

2018-07-02 Thread Ian Kent
On Mon, 2018-07-02 at 10:31 +0200, tomas wrote:
> Hi Ian,
> 
> you are welcome!
> 
> yes your patch is much better. You should just put the "_IOC_NR" macro
> around "cmd" in the lines added to "validate_dev_ioctl" to make it work.

LOL, yes, that was a dumb mistake.

I'll send it to Andrew Morton, after some fairly simple sanity testing,
with both our Signed-off-by added.

> 
> Tomas
> 
> 
> On 07/02/2018 03:42 AM, Ian Kent wrote:
> > On Mon, 2018-07-02 at 09:10 +0800, Ian Kent wrote:
> > > On Mon, 2018-07-02 at 00:04 +0200, tomas wrote:
> > > > Hi,
> > > > 
> > > > I've looked into this issue found by Syzbot and I made a patch:
> > > > 
> > > > https://syzkaller.appspot.com/bug?id=d03abd8b42847f7f69b1d1d7f97208ae425
> > > > b116
> > > > 3
> > > 
> > > Umm ... oops!
> > > 
> > > Thanks for looking into this Tomas.
> > > 
> > > > 
> > > > The autofs subsystem does not check that the "path" parameter is present
> > > > within the "param" struct passed by the userspace in case the
> > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD command is passed. Indeed, it assumes a
> > > > path is always provided (though a path is not always present, as per how
> > > > the struct is defined:
> > > > https://github.com/torvalds/linux/blob/master/include/uapi/linux/auto_de
> > > > v-io
> > > > ct
> > > > l.h#L89).
> > > > Skipping the check provokes an oob read in "strlen", called by
> > > > "getname_kernel", in turn called by the autofs to assess the length of
> > > > the non-existing path.
> > > > 
> > > > To solve it, modify the "validate_dev_ioctl" function to check also that
> > > > a path has been provided if the command is
> > > > AUTOFS_DEV_IOCTL_OPENMOUNT_CMD.
> > > > 
> > > > 
> > > > --- b/fs/autofs/dev-ioctl.c2018-07-01 23:10:16.059728621 +0200around
> > > > +++ a/fs/autofs/dev-ioctl.c2018-07-01 23:10:24.311792133 +0200
> > > > @@ -136,6 +136,9 @@ static int validate_dev_ioctl(int cmd, s
> > > >  goto out;
> > > >  }
> > > >  }
> > > > +/* AUTOFS_DEV_IOCTL_OPENMOUNT_CMD without path */
> > > > +else if(_IOC_NR(cmd) == AUTOFS_DEV_IOCTL_OPENMOUNT_CMD)
> > > > +return -EINVAL;
> > > 
> > > My preference is to put the comment inside the else but ...
> > > 
> > > There's another question, should the check be done in
> > > autofs_dev_ioctl_openmount() in the same way it's checked in other
> > > ioctls that need a path, such as in autofs_dev_ioctl_requester()
> > > and autofs_dev_ioctl_ismountpoint()?
> > > 
> > > For consistency I'd say it should.
> > > 
> > > >  
> > > >  err = 0;You should just put the "_IOC_NR" directive around "cmd" in
> > > > the lines added to "validate_dev_ioctl" to make it work.
> > > >  out:
> > > > 
> > > > 
> > > > Tested and solves the issue on Linus' main git tree.
> > > > 
> > > > 
> > 
> > Or perhaps this (not even compile tested) patch would be better?
> > 
> > autofs - fix slab out of bounds read in getname_kernel()
> > 
> > From: Ian Kent 
> > 
> > The autofs subsystem does not check that the "path" parameter is
> > present for all cases where it is required when it is passed in
> > via the "param" struct.
> > 
> > In particular it isn't checked for the AUTOFS_DEV_IOCTL_OPENMOUNT_CMD
> > ioctl command.
> > 
> > To solve it, modify validate_dev_ioctl() function to check that a
> > path has been provided for ioctl commands that require it.
> > ---
> >  fs/autofs/dev-ioctl.c |   15 +++
> >  1 file changed, 7 insertions(+), 8 deletions(-)
> > 
> > diff --git a/fs/autofs/dev-ioctl.c b/fs/autofs/dev-ioctl.c
> > index ea4ca1445ab7..61c63715c3fb 100644
> > --- a/fs/autofs/dev-ioctl.c
> > +++ b/fs/autofs/dev-ioctl.c
> > @@ -135,6 +135,11 @@ static int validate_dev_ioctl(int cmd, struct
> > autofs_dev_ioctl *param)
> > cmd);
> > goto out;
> > }
> > +   } else if (cmd == AUTOFS_DEV_IOCTL_OPENMOUNT_CMD ||
> > +  cmd == AUTOFS_DEV_IOCTL_REQUESTER_CMD ||
> > +  cmd == AUTOFS_DEV_IOCTL_ISMOUNTPOINT_CMD) {
> > +   err = -EINVAL;
> > +   goto out;
> > }
> >  
> > err = 0;
> > @@ -433,10 +438,7 @@ static int autofs_dev_ioctl_requester(struct file *fp,
> > dev_t devid;
> > int err = -ENOENT;
> >  
> > -   if (param->size <= AUTOFS_DEV_IOCTL_SIZE) {
> > -   err = -EINVAL;
> > -   goto out;
> > -   }
> > +   /* param->path has already been checked */
> >  
> > devid = sbi->sb->s_dev;
> >  
> > @@ -521,10 +523,7 @@ static int autofs_dev_ioctl_ismountpoint(struct file
> > *fp,
> > unsigned int devid, magic;
> > int err = -ENOENT;
> >  
> > -   if (param->size <= AUTOFS_DEV_IOCTL_SIZE) {
> > -   err = -EINVAL;
> > -   goto out;
> > -   }
> > +   /* param->path has already been checked */
> >  
> > name = param->path;
> > type = param->ismountpoint.in.type;
> 
> 


Re: [PATCH v8 2/2] regulator: add QCOM RPMh regulator driver

2018-07-02 Thread Mark Brown
On Fri, Jun 22, 2018 at 05:46:14PM -0700, David Collins wrote:

> --- /dev/null
> +++ b/drivers/regulator/qcom-rpmh-regulator.c
> @@ -0,0 +1,746 @@
> +// SPDX-License-Identifier: GPL-2.0
> +/* Copyright (c) 2018, The Linux Foundation. All rights reserved. */
> +

Please make the entire header block C++ so it looks intentional.

> + cmd.data = bypassed ? PMIC4_BOB_MODE_PASS : pmic_mode;

Please just write normal if statements, the ternery operator isn't
really helping legibility.

> +static const int pmic_mode_map_pmic4_ldo[REGULATOR_MODE_STANDBY + 1] = {
> + [REGULATOR_MODE_INVALID] = -EINVAL,
> + [REGULATOR_MODE_STANDBY] = PMIC4_LDO_MODE_RETENTION,
> + [REGULATOR_MODE_IDLE]= PMIC4_LDO_MODE_LPM,
> + [REGULATOR_MODE_NORMAL]  = -EINVAL,
> + [REGULATOR_MODE_FAST]= PMIC4_LDO_MODE_HPM,
> +};

This mapping is really weird, I'd expect one of the modes to correspond
to the normal operating mode of the regulator.  

> +static unsigned int rpmh_regulator_pmic4_ldo_of_map_mode(unsigned int mode)
> +{
> + static const unsigned int of_mode_map[RPMH_REGULATOR_MODE_COUNT] = {
> + [RPMH_REGULATOR_MODE_RET]  = REGULATOR_MODE_STANDBY,
> + [RPMH_REGULATOR_MODE_LPM]  = REGULATOR_MODE_IDLE,
> + [RPMH_REGULATOR_MODE_AUTO] = REGULATOR_MODE_INVALID,
> + [RPMH_REGULATOR_MODE_HPM]  = REGULATOR_MODE_FAST,
> + };

Same here, based on that it looks like auto mode is a good map for
normal.

> + if (mode >= RPMH_REGULATOR_MODE_COUNT)
> + return -EINVAL;

Why not use ARRAY_SIZE?


signature.asc
Description: PGP signature


[PATCH v2] x86-64: use 32-bit XOR to zero registers

2018-07-02 Thread Jan Beulich
Some Intel CPUs don't recognize 64-bit XORs as zeroing idioms. Zeroing
idioms don't require execution bandwidth, as they're being taken care
of in the frontend (through register renaming). Use 32-bit XORs instead.

Signed-off-by: Jan Beulich 
---
v2: Explain what zeroing idioms are/do in the description.
---
 arch/x86/crypto/aegis128-aesni-asm.S |2 +-
 arch/x86/crypto/aegis128l-aesni-asm.S|2 +-
 arch/x86/crypto/aegis256-aesni-asm.S |2 +-
 arch/x86/crypto/aesni-intel_asm.S|8 
 arch/x86/crypto/aesni-intel_avx-x86_64.S |4 ++--
 arch/x86/crypto/morus1280-avx2-asm.S |2 +-
 arch/x86/crypto/morus1280-sse2-asm.S |2 +-
 arch/x86/crypto/morus640-sse2-asm.S  |2 +-
 arch/x86/crypto/sha1_ssse3_asm.S |2 +-
 arch/x86/kernel/head_64.S|2 +-
 arch/x86/kernel/paravirt_patch_64.c  |2 +-
 arch/x86/lib/memcpy_64.S |2 +-
 arch/x86/power/hibernate_asm_64.S|2 +-
 13 files changed, 17 insertions(+), 17 deletions(-)

--- 4.18-rc3/arch/x86/crypto/aegis128-aesni-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/aegis128-aesni-asm.S
@@ -75,7 +75,7 @@
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
pxor MSG, MSG
 
mov LEN, %r8
--- 4.18-rc3/arch/x86/crypto/aegis128l-aesni-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/aegis128l-aesni-asm.S
@@ -66,7 +66,7 @@
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
pxor MSG0, MSG0
pxor MSG1, MSG1
 
--- 4.18-rc3/arch/x86/crypto/aegis256-aesni-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/aegis256-aesni-asm.S
@@ -59,7 +59,7 @@
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
pxor MSG, MSG
 
mov LEN, %r8
--- 4.18-rc3/arch/x86/crypto/aesni-intel_asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/aesni-intel_asm.S
@@ -258,7 +258,7 @@ ALL_F:  .octa 0x
 .macro GCM_INIT Iv SUBKEY AAD AADLEN
mov \AADLEN, %r11
mov %r11, AadLen(%arg2) # ctx_data.aad_length = aad_length
-   xor %r11, %r11
+   xor %r11d, %r11d
mov %r11, InLen(%arg2) # ctx_data.in_length = 0
mov %r11, PBlockLen(%arg2) # ctx_data.partial_block_length = 0
mov %r11, PBlockEncKey(%arg2) # ctx_data.partial_block_enc_key = 0
@@ -286,7 +286,7 @@ ALL_F:  .octa 0x
movdqu HashKey(%arg2), %xmm13
add %arg5, InLen(%arg2)
 
-   xor %r11, %r11 # initialise the data pointer offset as zero
+   xor %r11d, %r11d # initialise the data pointer offset as zero
PARTIAL_BLOCK %arg3 %arg4 %arg5 %r11 %xmm8 \operation
 
sub %r11, %arg5 # sub partial block data used
@@ -702,7 +702,7 @@ _no_extra_mask_1_\@:
 
# GHASH computation for the last <16 Byte block
GHASH_MUL \AAD_HASH, %xmm13, %xmm0, %xmm10, %xmm11, %xmm5, %xmm6
-   xor %rax,%rax
+   xor %eax, %eax
 
mov %rax, PBlockLen(%arg2)
jmp _dec_done_\@
@@ -737,7 +737,7 @@ _no_extra_mask_2_\@:
 
# GHASH computation for the last <16 Byte block
GHASH_MUL \AAD_HASH, %xmm13, %xmm0, %xmm10, %xmm11, %xmm5, %xmm6
-   xor %rax,%rax
+   xor %eax, %eax
 
mov %rax, PBlockLen(%arg2)
jmp _encode_done_\@
--- 4.18-rc3/arch/x86/crypto/aesni-intel_avx-x86_64.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/aesni-intel_avx-x86_64.S
@@ -463,7 +463,7 @@ _get_AAD_rest_final\@:
 
 _get_AAD_done\@:
# initialize the data pointer offset as zero
-   xor %r11, %r11
+   xor %r11d, %r11d
 
# start AES for num_initial_blocks blocks
mov arg5, %rax # rax = *Y0
@@ -1770,7 +1770,7 @@ _get_AAD_rest_final\@:
 
 _get_AAD_done\@:
# initialize the data pointer offset as zero
-   xor %r11, %r11
+   xor %r11d, %r11d
 
# start AES for num_initial_blocks blocks
mov arg5, %rax # rax = *Y0
--- 4.18-rc3/arch/x86/crypto/morus1280-avx2-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/morus1280-avx2-asm.S
@@ -113,7 +113,7 @@ ENDPROC(__morus1280_update_zero)
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
vpxor MSG, MSG, MSG
 
mov %rcx, %r8
--- 4.18-rc3/arch/x86/crypto/morus1280-sse2-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/morus1280-sse2-asm.S
@@ -235,7 +235,7 @@ ENDPROC(__morus1280_update_zero)
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
pxor MSG_LO, MSG_LO
pxor MSG_HI, MSG_HI
 
--- 4.18-rc3/arch/x86/crypto/morus640-sse2-asm.S
+++ 4.18-rc3-x86_64-32bit-XOR/arch/x86/crypto/morus640-sse2-asm.S
@@ -113,7 +113,7 @@ ENDPROC(__morus640_update_zero)
  *   %r9
  */
 __load_partial:
-   xor %r9, %r9
+   xor %r9d, %r9d
pxor MSG, MSG
 
mov %rcx, %r8
--- 4.18-rc3/arch/x86/crypto/sha1_ssse3_asm.S

Re: [PATCH] arm64: Use aarch64elf and aarch64elfb emulation mode variants

2018-07-02 Thread Will Deacon
On Mon, Jul 02, 2018 at 11:16:59AM +0200, Paul Kocialkowski wrote:
> The aarch64linux and aarch64linuxb emulation modes are not supported by
> bare-metal toolchains and Linux using them forbids building the kernel
> with these toolchains.
> 
> Since there is apparently no reason to target these emulation modes, the
> more generic elf modes are used instead, allowing to build on bare-metal
> toolchains as well as the already-supported ones.
> 
> Fixes: 3d6a7b99e3fa ("arm64: ensure the kernel is compiled for LP64")
> 
> Cc: sta...@vger.kernel.org
> Signed-off-by: Paul Kocialkowski 
> ---
>  arch/arm64/Makefile | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/arch/arm64/Makefile b/arch/arm64/Makefile
> index 87f7d2f9f17c..3e959ac43b40 100644
> --- a/arch/arm64/Makefile
> +++ b/arch/arm64/Makefile
> @@ -67,14 +67,14 @@ KBUILD_CPPFLAGS   += -mbig-endian
>  CHECKFLAGS   += -D__AARCH64EB__
>  AS   += -EB
>  LD   += -EB
> -LDFLAGS  += -maarch64linuxb
> +LDFLAGS  += -maarch64elfb
>  UTS_MACHINE  := aarch64_be
>  else
>  KBUILD_CPPFLAGS  += -mlittle-endian
>  CHECKFLAGS   += -D__AARCH64EL__
>  AS   += -EL
>  LD   += -EL
> -LDFLAGS  += -maarch64linux
> +LDFLAGS  += -maarch64elf
>  UTS_MACHINE  := aarch64
>  endif

Acked-by: Will Deacon 

Will


Re: [PATCH 2/2] mm: set PG_dma_pinned on get_user_pages*()

2018-07-02 Thread Michal Hocko
On Sun 01-07-18 23:41:21, John Hubbard wrote:
> On 07/01/2018 11:34 PM, Leon Romanovsky wrote:
> > On Sun, Jul 01, 2018 at 11:10:04PM -0700, John Hubbard wrote:
[...]
> >>> Sorry for naive question, but won't it create too much dirty pages
> >>> so writeback will be called "non-stop" to rebalance watermarks without
> >>> ability to progress?
> >>>
> >>
> >> That is an interesting point.
> >>
> >> Holding off page writeback of this region does seem like it could cause
> >> problems under memory pressure. Maybe adjusting the watermarks so that we
> >> tell the writeback  system, "all is well, just ignore this region until
> >> we're done with it" might help? Any ideas here are welcome...
> > 
> > AFAIR, it is per-zone, so the solution to count dirty-but-untouchable
> > number of pages to take them into account for accounting can work, but
> > it seems like an overkill. Can we create special ZONE for such gup
> > pages, or this is impossible too?
> > 
> 
> Let's see what Michal and others prefer. The zone idea intrigues me. 

No new zones please. Pinned pages are essentially mlocked pages, except
they are worse because they cannot be even migrated. What we really
needs is a) limit their usage and b) have a way to find out that pins
are not ephemeral and a special action needs to be taken. What is that
special action is yet to be decided but please do not add even more
complexity on top.

-- 
Michal Hocko
SUSE Labs


Re: [PATCH] ARM: dts: am33xx: Add pinmux data for mmc1 in am335x-evm, evmsk and beaglebone

2018-07-02 Thread Tony Lindgren
* Robert Nelson  [180618 14:00]:
> On Wed, Apr 11, 2018 at 6:48 AM, Faiz Abbas  wrote:
> > am335x-evm, am335x-evmsk and am335x-beaglebone are currently relying on
> > pinmux set by the bootloader to set the correct value for mmc1. Fix
> > this by adding pinmux data for the same in kernel.
> >
> > Signed-off-by: Faiz Abbas 
> > ---
> >  arch/arm/boot/dts/am335x-bone-common.dtsi | 9 -
> >  arch/arm/boot/dts/am335x-evm.dts  | 9 -
> >  arch/arm/boot/dts/am335x-evmsk.dts| 9 -
> >  3 files changed, 24 insertions(+), 3 deletions(-)
> >
> > diff --git a/arch/arm/boot/dts/am335x-bone-common.dtsi 
> > b/arch/arm/boot/dts/am335x-bone-common.dtsi
> > index e67b4d6..f9e8667 100644
> > --- a/arch/arm/boot/dts/am335x-bone-common.dtsi
> > +++ b/arch/arm/boot/dts/am335x-bone-common.dtsi
> > @@ -161,7 +161,14 @@
> >
> > mmc1_pins: pinmux_mmc1_pins {
> > pinctrl-single,pins = <
> > -   AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7) /* 
> > GPIO0_6 */
> > +   AM33XX_IOPAD(0x960, PIN_INPUT | MUX_MODE7)  
> > /* spio0_cs1.gpio0_6 */
> > +   AM33XX_IOPAD(0x8fc, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_dat0.mmc0_dat0 */
> > +   AM33XX_IOPAD(0x8f8, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_dat1.mmc0_dat1 */
> > +   AM33XX_IOPAD(0x8f4, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_dat2.mmc0_dat2 */
> > +   AM33XX_IOPAD(0x8f0, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_dat3.mmc0_dat3 */
> > +   AM33XX_IOPAD(0x904, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_cmd.mmc0_cmd */
> > +   AM33XX_IOPAD(0x900, PIN_INPUT_PULLUP | MUX_MODE0)   
> > /* mmc0_clk.mmc0_clk */
> > +   AM33XX_IOPAD(0x9a0, PIN_INPUT | MUX_MODE4)  
> > /* mcasp0_aclkr.mmc0_sdwp */
> 
> We went one pin too far on the Beagle's here:
> 
> 0x9a0 ( mcasp0_aclkr.mmc0_sdwp ) = Routed to P9_42, (muxed with C18,
> to a shared pin on the header), so not connected to the microSD
> socket...
> 
> https://github.com/beagleboard/beaglebone-black/blob/master/BBB_SCH.pdf
> 
> Looking at this evm schematic, it looks like 0x9a0 should be removed
> too, but I'm not sure on all revisions:
> 
> http://processors.wiki.ti.com/images/a/a2/TMDSSK3358_3H0009_REV1_2B_SCH.pdf

Hmm care to post a fix for this?

Regards,

Tony


Re: [PATCH] ACPI/PPTT: use ACPI ID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set

2018-07-02 Thread Rafael J. Wysocki
On Mon, Jul 2, 2018 at 11:57 AM, Sudeep Holla  wrote:
>
>
> On 02/07/18 10:06, Rafael J. Wysocki wrote:
>> On Fri, Jun 29, 2018 at 6:17 PM, Sudeep Holla  wrote:
>>> Currently we use the ACPI processor ID only for the leaf/processor nodes
>>> as the specification states it must match the value of ACPI processor ID
>>> field in the processor’s entry in the MADT.
>>>
>>> However, if a PPTT structure represents processors group, it match a
>>> processor container UID in the namespace and 
>>> ACPI_PPTT_ACPI_PROCESSOR_ID_VALID
>>> flag describe whether the ACPI processor ID is valid.
>>>
>>> Lets use UID whenever ACPI_PPTT_ACPI_PROCESSOR_ID_VALID is set to be
>>> consistent instead of using table offset as it's currently done for non
>>> leaf nodes.
>>>
>>> Cc: "Rafael J. Wysocki" 
>>> Signed-off-by: Sudeep Holla 
>>> ---
>>>  drivers/acpi/pptt.c | 10 --
>>>  1 file changed, 8 insertions(+), 2 deletions(-)
>>>
>>> Hi,
>>>
>>> There's ongoing discussion on assigning ID based in OS using simple
>>> counters. It can never be consistent with firmware's view. So if the
>>> firmware provides valid UID for non-processors node, we must use it.
>>
>> OK
>>
>> Do you regard this as a fix for the recently merged PPTT material?  If
>> so, I should apply it as a fix for 4.18.
>>
>
> Yes, it should be considered as fix IMO.

So any chance to provide a Fixes: tag?


[PATCHv4 03/19] arm64: kill config_sctlr_el1()

2018-07-02 Thread Mark Rutland
Now that we have sysreg_clear_set(), we can consistently use this
instead of config_sctlr_el1().

Signed-off-by: Mark Rutland 
Reviewed-by: Dave Martin 
Acked-by: Catalin Marinas 
Cc: James Morse 
Cc: Will Deacon 
---
 arch/arm64/include/asm/sysreg.h  | 10 --
 arch/arm64/kernel/armv8_deprecated.c |  8 
 arch/arm64/kernel/cpu_errata.c   |  3 +--
 arch/arm64/kernel/traps.c|  2 +-
 arch/arm64/mm/fault.c|  2 +-
 5 files changed, 7 insertions(+), 18 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index fefc17dae8ee..e205ec8489e9 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -742,16 +742,6 @@ asm(
write_sysreg(__scs_new, sysreg);\
 } while (0)
 
-static inline void config_sctlr_el1(u32 clear, u32 set)
-{
-   u32 val;
-
-   val = read_sysreg(sctlr_el1);
-   val &= ~clear;
-   val |= set;
-   write_sysreg(val, sctlr_el1);
-}
-
 #endif
 
 #endif /* __ASM_SYSREG_H */
diff --git a/arch/arm64/kernel/armv8_deprecated.c 
b/arch/arm64/kernel/armv8_deprecated.c
index d4707abb2f16..d01c7fc0463c 100644
--- a/arch/arm64/kernel/armv8_deprecated.c
+++ b/arch/arm64/kernel/armv8_deprecated.c
@@ -511,9 +511,9 @@ static int cp15barrier_handler(struct pt_regs *regs, u32 
instr)
 static int cp15_barrier_set_hw_mode(bool enable)
 {
if (enable)
-   config_sctlr_el1(0, SCTLR_EL1_CP15BEN);
+   sysreg_clear_set(sctlr_el1, 0, SCTLR_EL1_CP15BEN);
else
-   config_sctlr_el1(SCTLR_EL1_CP15BEN, 0);
+   sysreg_clear_set(sctlr_el1, SCTLR_EL1_CP15BEN, 0);
return 0;
 }
 
@@ -548,9 +548,9 @@ static int setend_set_hw_mode(bool enable)
return -EINVAL;
 
if (enable)
-   config_sctlr_el1(SCTLR_EL1_SED, 0);
+   sysreg_clear_set(sctlr_el1, SCTLR_EL1_SED, 0);
else
-   config_sctlr_el1(0, SCTLR_EL1_SED);
+   sysreg_clear_set(sctlr_el1, 0, SCTLR_EL1_SED);
return 0;
 }
 
diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 1d2b6d768efe..92128ea53102 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -76,8 +76,7 @@ has_mismatched_cache_line_size(const struct 
arm64_cpu_capabilities *entry,
 static void
 cpu_enable_trap_ctr_access(const struct arm64_cpu_capabilities *__unused)
 {
-   /* Clear SCTLR_EL1.UCT */
-   config_sctlr_el1(SCTLR_EL1_UCT, 0);
+   sysreg_clear_set(sctlr_el1, SCTLR_EL1_UCT, 0);
 }
 
 atomic_t arm64_el2_vector_last_slot = ATOMIC_INIT(-1);
diff --git a/arch/arm64/kernel/traps.c b/arch/arm64/kernel/traps.c
index d399d459397b..c27292703bd1 100644
--- a/arch/arm64/kernel/traps.c
+++ b/arch/arm64/kernel/traps.c
@@ -411,7 +411,7 @@ asmlinkage void __exception do_undefinstr(struct pt_regs 
*regs)
 
 void cpu_enable_cache_maint_trap(const struct arm64_cpu_capabilities *__unused)
 {
-   config_sctlr_el1(SCTLR_EL1_UCI, 0);
+   sysreg_clear_set(sctlr_el1, SCTLR_EL1_UCI, 0);
 }
 
 #define __user_cache_maint(insn, address, res) \
diff --git a/arch/arm64/mm/fault.c b/arch/arm64/mm/fault.c
index b8eecc7b9531..ea591c9e5144 100644
--- a/arch/arm64/mm/fault.c
+++ b/arch/arm64/mm/fault.c
@@ -879,7 +879,7 @@ void cpu_enable_pan(const struct arm64_cpu_capabilities 
*__unused)
 */
WARN_ON_ONCE(in_interrupt());
 
-   config_sctlr_el1(SCTLR_EL1_SPAN, 0);
+   sysreg_clear_set(sctlr_el1, SCTLR_EL1_SPAN, 0);
asm(SET_PSTATE_PAN(1));
 }
 #endif /* CONFIG_ARM64_PAN */
-- 
2.11.0



[PATCHv4 18/19] arm64: convert compat wrappers to C

2018-07-02 Thread Mark Rutland
In preparation for converting to pt_regs syscall wrappers, convert our
existing compat wrappers to C. This will allow the pt_regs wrappers to
be automatically generated, and will allow for the compat register
manipulation to be folded in with the pt_regs accesses.

To avoid confusion with the upcoming pt_regs wrappers and existing
compat wrappers provided by core code, the C wrappers are renamed to
compat_sys_aarch32_.

With the assembly wrappers gone, we can get rid of entry32.S and the
associated boilerplate.

Note that these must call the ksys_* syscall entry points, as the usual
sys_* entry points will be modified to take a single pt_regs pointer
argument.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/include/asm/unistd32.h |  22 
 arch/arm64/kernel/Makefile|   2 +-
 arch/arm64/kernel/entry32.S   | 111 -
 arch/arm64/kernel/sys32.c | 114 ++
 4 files changed, 115 insertions(+), 134 deletions(-)
 delete mode 100644 arch/arm64/kernel/entry32.S

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index ab95554b1734..0e3dd3265993 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -382,9 +382,9 @@ __SYSCALL(__NR_rt_sigqueueinfo, compat_sys_rt_sigqueueinfo)
 #define __NR_rt_sigsuspend 179
 __SYSCALL(__NR_rt_sigsuspend, compat_sys_rt_sigsuspend)
 #define __NR_pread64 180
-__SYSCALL(__NR_pread64, compat_sys_pread64_wrapper)
+__SYSCALL(__NR_pread64, compat_sys_aarch32_pread64)
 #define __NR_pwrite64 181
-__SYSCALL(__NR_pwrite64, compat_sys_pwrite64_wrapper)
+__SYSCALL(__NR_pwrite64, compat_sys_aarch32_pwrite64)
 #define __NR_chown 182
 __SYSCALL(__NR_chown, sys_chown16)
 #define __NR_getcwd 183
@@ -406,11 +406,11 @@ __SYSCALL(__NR_vfork, sys_vfork)
 #define __NR_ugetrlimit 191/* SuS compliant getrlimit */
 __SYSCALL(__NR_ugetrlimit, compat_sys_getrlimit)   /* SuS 
compliant getrlimit */
 #define __NR_mmap2 192
-__SYSCALL(__NR_mmap2, compat_sys_mmap2_wrapper)
+__SYSCALL(__NR_mmap2, compat_sys_aarch32_mmap2)
 #define __NR_truncate64 193
-__SYSCALL(__NR_truncate64, compat_sys_truncate64_wrapper)
+__SYSCALL(__NR_truncate64, compat_sys_aarch32_truncate64)
 #define __NR_ftruncate64 194
-__SYSCALL(__NR_ftruncate64, compat_sys_ftruncate64_wrapper)
+__SYSCALL(__NR_ftruncate64, compat_sys_aarch32_ftruncate64)
 #define __NR_stat64 195
 __SYSCALL(__NR_stat64, sys_stat64)
 #define __NR_lstat64 196
@@ -472,7 +472,7 @@ __SYSCALL(223, sys_ni_syscall)
 #define __NR_gettid 224
 __SYSCALL(__NR_gettid, sys_gettid)
 #define __NR_readahead 225
-__SYSCALL(__NR_readahead, compat_sys_readahead_wrapper)
+__SYSCALL(__NR_readahead, compat_sys_aarch32_readahead)
 #define __NR_setxattr 226
 __SYSCALL(__NR_setxattr, sys_setxattr)
 #define __NR_lsetxattr 227
@@ -554,15 +554,15 @@ __SYSCALL(__NR_clock_getres, compat_sys_clock_getres)
 #define __NR_clock_nanosleep 265
 __SYSCALL(__NR_clock_nanosleep, compat_sys_clock_nanosleep)
 #define __NR_statfs64 266
-__SYSCALL(__NR_statfs64, compat_sys_statfs64_wrapper)
+__SYSCALL(__NR_statfs64, compat_sys_aarch32_statfs64)
 #define __NR_fstatfs64 267
-__SYSCALL(__NR_fstatfs64, compat_sys_fstatfs64_wrapper)
+__SYSCALL(__NR_fstatfs64, compat_sys_aarch32_fstatfs64)
 #define __NR_tgkill 268
 __SYSCALL(__NR_tgkill, sys_tgkill)
 #define __NR_utimes 269
 __SYSCALL(__NR_utimes, compat_sys_utimes)
 #define __NR_arm_fadvise64_64 270
-__SYSCALL(__NR_arm_fadvise64_64, compat_sys_fadvise64_64_wrapper)
+__SYSCALL(__NR_arm_fadvise64_64, compat_sys_aarch32_fadvise64_64)
 #define __NR_pciconfig_iobase 271
 __SYSCALL(__NR_pciconfig_iobase, sys_pciconfig_iobase)
 #define __NR_pciconfig_read 272
@@ -704,7 +704,7 @@ __SYSCALL(__NR_get_robust_list, compat_sys_get_robust_list)
 #define __NR_splice 340
 __SYSCALL(__NR_splice, sys_splice)
 #define __NR_sync_file_range2 341
-__SYSCALL(__NR_sync_file_range2, compat_sys_sync_file_range2_wrapper)
+__SYSCALL(__NR_sync_file_range2, compat_sys_aarch32_sync_file_range2)
 #define __NR_tee 342
 __SYSCALL(__NR_tee, sys_tee)
 #define __NR_vmsplice 343
@@ -726,7 +726,7 @@ __SYSCALL(__NR_timerfd_create, sys_timerfd_create)
 #define __NR_eventfd 351
 __SYSCALL(__NR_eventfd, sys_eventfd)
 #define __NR_fallocate 352
-__SYSCALL(__NR_fallocate, compat_sys_fallocate_wrapper)
+__SYSCALL(__NR_fallocate, compat_sys_aarch32_fallocate)
 #define __NR_timerfd_settime 353
 __SYSCALL(__NR_timerfd_settime, compat_sys_timerfd_settime)
 #define __NR_timerfd_gettime 354
diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 4e24d2244bd1..95ac7374d723 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -28,7 +28,7 @@ $(obj)/%.stub.o: $(obj)/%.o FORCE
$(call if_changed,objcopy)
 
 arm64-obj-$(CONFIG_COMPAT) += sys32.o kuser32.o signal32.o 
\
-  sys_compat.o entry32.o
+   

[PATCHv4 17/19] arm64: use SYSCALL_DEFINE6() for mmap

2018-07-02 Thread Mark Rutland
We don't currently annotate our mmap implementation as a syscall, as we
need to do to use pt_regs syscall wrappers.

Let's mark it as a real syscall.

There should be no functional change as a result of this patch.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/sys.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index a82c3f7a9a90..2ad1497a184e 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -27,9 +27,9 @@
 #include 
 #include 
 
-asmlinkage long sys_mmap(unsigned long addr, unsigned long len,
-unsigned long prot, unsigned long flags,
-unsigned long fd, off_t off)
+SYSCALL_DEFINE6(mmap, unsigned long, addr, unsigned long, len,
+   unsigned long, prot, unsigned long, flags,
+   unsigned long, fd, off_t, off)
 {
if (offset_in_page(off) != 0)
return -EINVAL;
-- 
2.11.0



[PATCHv4 19/19] arm64: implement syscall wrappers

2018-07-02 Thread Mark Rutland
To minimize the risk of userspace-controlled values being used under
speculation, this patch adds pt_regs based syscall wrappers for arm64,
which pass the minimum set of required userspace values to syscall
implementations. For each syscall, a wrapper which takes a pt_regs
argument is automatically generated, and this extracts the arguments
before calling the "real" syscall implementation.

Each syscall has three functions generated:

* __do_sys_ is the "real" syscall implementation, with
  the expected prototype.

* __se_sys_ is the sign-extension/narrowing wrapper,
  inherited from common code. This takes a series of long parameters,
  casting each to the requisite types required by the "real" syscall
  implementation in __do_sys_.

  This wrapper *may* not be necessary on arm64 given the AAPCS rules on
  unused register bits, but it seemed safer to keep the wrapper for now.

* __arm64__sys_ takes a struct pt_regs pointer, and
  extracts *only* the relevant register values, passing these on to the
  __se_sys_ wrapper.

The syscall invocation code is updated to handle the calling convention
required by __arm64__sys_, and passes a single struct
pt_regs pointer.

The compiler can fold the syscall implementation and its wrappers, such
that the overhead of this approach is minimized.

Note that we play games with sys_ni_syscall(). It can't be defined with
SYSCALL_DEFINE0() because we must avoid the possibility of error
injection. Additionally, there are a couple of locations where we need
to call it from C code, and we don't (currently) have a
ksys_ni_syscall().  While it has no wrapper, passing in a redundant
pt_regs pointer is benign per the AAPCS.

When ARCH_HAS_SYSCALL_WRAPPER is selected, no prototype is defines for
sys_ni_syscall(). Since we need to treat it differently for in-kernel
calls and the syscall tables, the prototype is defined as-required.

The wrappers are largely the same as their x86 counterparts, but
simplified as we don't have a variety of compat calling conventions that
require separate stubs. Unlike x86, we have some zero-argument compat
syscalls, and must define COMPAT_SYSCALL_DEFINE0() to ensure that these
are also given an __arm64_compat_sys_ prefix.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Reviewed-by: Catalin Marinas 
Cc: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/Kconfig   |  1 +
 arch/arm64/include/asm/syscall_wrapper.h | 80 
 arch/arm64/kernel/sys.c  | 10 +++-
 arch/arm64/kernel/sys32.c|  9 +++-
 arch/arm64/kernel/syscall.c  |  9 ++--
 5 files changed, 101 insertions(+), 8 deletions(-)
 create mode 100644 arch/arm64/include/asm/syscall_wrapper.h

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 42c090cf0292..2089aa3f27bc 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -24,6 +24,7 @@ config ARM64
select ARCH_HAS_SG_CHAIN
select ARCH_HAS_STRICT_KERNEL_RWX
select ARCH_HAS_STRICT_MODULE_RWX
+   select ARCH_HAS_SYSCALL_WRAPPER
select ARCH_HAS_TICK_BROADCAST if GENERIC_CLOCKEVENTS_BROADCAST
select ARCH_HAVE_NMI_SAFE_CMPXCHG
select ARCH_INLINE_READ_LOCK if !PREEMPT
diff --git a/arch/arm64/include/asm/syscall_wrapper.h 
b/arch/arm64/include/asm/syscall_wrapper.h
new file mode 100644
index ..a4477e515b79
--- /dev/null
+++ b/arch/arm64/include/asm/syscall_wrapper.h
@@ -0,0 +1,80 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+/*
+ * syscall_wrapper.h - arm64 specific wrappers to syscall definitions
+ *
+ * Based on arch/x86/include/asm_syscall_wrapper.h
+ */
+
+#ifndef __ASM_SYSCALL_WRAPPER_H
+#define __ASM_SYSCALL_WRAPPER_H
+
+#define SC_ARM64_REGS_TO_ARGS(x, ...)  \
+   __MAP(x,__SC_ARGS   \
+ ,,regs->regs[0],,regs->regs[1],,regs->regs[2] \
+ ,,regs->regs[3],,regs->regs[4],,regs->regs[5])
+
+#ifdef CONFIG_COMPAT
+
+#define COMPAT_SYSCALL_DEFINEx(x, name, ...)   
\
+   asmlinkage long __arm64_compat_sys##name(const struct pt_regs *regs);   
\
+   ALLOW_ERROR_INJECTION(__arm64_compat_sys##name, ERRNO); 
\
+   static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__));  
\
+   static inline long 
__do_compat_sys##name(__MAP(x,__SC_DECL,__VA_ARGS__));   \
+   asmlinkage long __arm64_compat_sys##name(const struct pt_regs *regs)
\
+   {   
\
+   return 
__se_compat_sys##name(SC_ARM64_REGS_TO_ARGS(x,__VA_ARGS__)); \
+   }   
\
+   static long __se_compat_sys##name(__MAP(x,__SC_LONG,__VA_ARGS__))   
\
+   {   
   

Re: [PATCH 1/5] ARM: dts: dra7: Disable metastability workaround for USB2

2018-07-02 Thread Tony Lindgren
* Roger Quadros  [180529 02:03]:
> Disable the metastability workaround for USB2. The original
> patch disabled the workaround on the wrong USB port.
> 
> Fixes: b8c9c6fa2002 ("ARM: dts: dra7: Disable USB metastability workaround 
> for USB2")
> Cc: [4.16+]
> Signed-off-by: Roger Quadros 


Sorry for the delay, applying this one into omap-for-v4.18/fixes.

Regards,

Tony

> ---
>  arch/arm/boot/dts/dra7.dtsi | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/arch/arm/boot/dts/dra7.dtsi b/arch/arm/boot/dts/dra7.dtsi
> index f4ddd86..9cace9f 100644
> --- a/arch/arm/boot/dts/dra7.dtsi
> +++ b/arch/arm/boot/dts/dra7.dtsi
> @@ -1582,7 +1582,6 @@
>   dr_mode = "otg";
>   snps,dis_u3_susphy_quirk;
>   snps,dis_u2_susphy_quirk;
> - snps,dis_metastability_quirk;
>   };
>   };
>  
> @@ -1610,6 +1609,7 @@
>   dr_mode = "otg";
>   snps,dis_u3_susphy_quirk;
>   snps,dis_u2_susphy_quirk;
> + snps,dis_metastability_quirk;
>   };
>   };
>  
> -- 
> cheers,
> -roger
> 
> Texas Instruments Finland Oy, Porkkalankatu 22, 00180 Helsinki.
> Y-tunnus/Business ID: 0615521-4. Kotipaikka/Domicile: Helsinki
> 


Re: [PATCH 2/3] arm/arm64: configs: Remove the MFD_ prefix for MFD_CROS_EC_I2C/SPI symbols.

2018-07-02 Thread Krzysztof Kozlowski
On 2 July 2018 at 12:22, Enric Balletbo i Serra
 wrote:
> The cros-ec I2C and SPI transport drivers have been moved from MFD
> subsystem to platform/chrome, at the same time, the config symbol has
> been renamed and lost the MFD_ prefix, so update all configs to the new
> config symbol name.
>
> Signed-off-by: Enric Balletbo i Serra 
> ---
>
>  arch/arm/configs/exynos_defconfig   | 4 ++--
>  arch/arm/configs/multi_v7_defconfig | 4 ++--
>  arch/arm/configs/pxa_defconfig  | 4 ++--
>  arch/arm64/configs/defconfig| 4 ++--
>  4 files changed, 8 insertions(+), 8 deletions(-)

Since you put in one patch multiple defconfigs belonging to multiple
maintainers, I assume you are pushing this through arm-soc or Russell.
In such case, for Exynos boards:
Acked-by: Krzysztof Kozlowski 

Best regards,
Krzysztof


[PATCHv4 16/19] arm64: use {COMPAT,}SYSCALL_DEFINE0 for sigreturn

2018-07-02 Thread Mark Rutland
We don't currently annotate our various sigreturn functions as syscalls,
as we need to do to use pt_regs syscall wrappers.

Let's mark them as real syscalls.

For compat_sys_sigreturn and compat_sys_rt_sigreturn, this changes the
return type from int to long, matching the prototypes in sys32.c.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/signal.c   | 2 +-
 arch/arm64/kernel/signal32.c | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index f03e664f773f..f8b0ba50e55e 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -539,7 +539,7 @@ static int restore_sigframe(struct pt_regs *regs,
return err;
 }
 
-asmlinkage long sys_rt_sigreturn(void)
+SYSCALL_DEFINE0(rt_sigreturn)
 {
struct pt_regs *regs = current_pt_regs();
struct rt_sigframe __user *frame;
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index cb10588a7cb2..1948566dcccf 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -282,7 +282,7 @@ static int compat_restore_sigframe(struct pt_regs *regs,
return err;
 }
 
-asmlinkage int compat_sys_sigreturn(void)
+COMPAT_SYSCALL_DEFINE0(sigreturn)
 {
struct pt_regs *regs = current_pt_regs();
struct compat_sigframe __user *frame;
@@ -313,7 +313,7 @@ asmlinkage int compat_sys_sigreturn(void)
return 0;
 }
 
-asmlinkage int compat_sys_rt_sigreturn(void)
+COMPAT_SYSCALL_DEFINE0(rt_sigreturn)
 {
struct pt_regs *regs = current_pt_regs();
struct compat_rt_sigframe __user *frame;
-- 
2.11.0



[PATCHv4 07/19] arm64: convert raw syscall invocation to C

2018-07-02 Thread Mark Rutland
As a first step towards invoking syscalls with a pt_regs argument,
convert the raw syscall invocation logic to C. We end up with a bit more
register shuffling, but the unified invocation logic means we can unify
the tracing paths, too.

Previously, assembly had to open-code calls to ni_sys() when the system
call number was out-of-bounds for the relevant syscall table. This case
is now handled by invoke_syscall(), and the assembly no longer need to
handle this case explicitly. This allows the tracing paths to be
simplified and unified, as we no longer need the __ni_sys_trace path and
the __sys_trace_return label.

This only converts the invocation of the syscall. The rest of the
syscall triage and tracing is left in assembly for now, and will be
converted in subsequent patches.

Signed-off-by: Mark Rutland 
Reviewed-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/Makefile  |  3 ++-
 arch/arm64/kernel/entry.S   | 36 +
 arch/arm64/kernel/syscall.c | 49 +
 arch/arm64/kernel/traps.c   | 16 ---
 4 files changed, 61 insertions(+), 43 deletions(-)
 create mode 100644 arch/arm64/kernel/syscall.c

diff --git a/arch/arm64/kernel/Makefile b/arch/arm64/kernel/Makefile
index 0025f8691046..4e24d2244bd1 100644
--- a/arch/arm64/kernel/Makefile
+++ b/arch/arm64/kernel/Makefile
@@ -18,7 +18,8 @@ arm64-obj-y   := debug-monitors.o entry.o irq.o 
fpsimd.o  \
   hyp-stub.o psci.o cpu_ops.o insn.o   \
   return_address.o cpuinfo.o cpu_errata.o  
\
   cpufeature.o alternative.o cacheinfo.o   
\
-  smp.o smp_spin_table.o topology.o smccc-call.o
+  smp.o smp_spin_table.o topology.o smccc-call.o   
\
+  syscall.o
 
 extra-$(CONFIG_EFI):= efi-entry.o
 
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 62f2876f9c63..c0392f78e392 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -903,7 +903,6 @@ ENDPROC(el0_error)
  */
 ret_fast_syscall:
disable_daif
-   str x0, [sp, #S_X0] // returned x0
ldr x1, [tsk, #TSK_TI_FLAGS]// re-check for syscall tracing
and x2, x1, #_TIF_SYSCALL_WORK
cbnzx2, ret_fast_syscall_trace
@@ -976,15 +975,11 @@ el0_svc_naked:// 
compat entry point
 
tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
b.ne__sys_trace
-   cmp wscno, wsc_nr   // check upper syscall limit
-   b.hsni_sys
-   mask_nospec64 xscno, xsc_nr, x19// enforce bounds for syscall 
number
-   ldr x16, [stbl, xscno, lsl #3]  // address in the syscall table
-   blr x16 // call sys_* routine
-   b   ret_fast_syscall
-ni_sys:
mov x0, sp
-   bl  do_ni_syscall
+   mov w1, wscno
+   mov w2, wsc_nr
+   mov x3, stbl
+   bl  invoke_syscall
b   ret_fast_syscall
 ENDPROC(el0_svc)
 
@@ -1001,29 +996,18 @@ __sys_trace:
bl  syscall_trace_enter
cmp w0, #NO_SYSCALL // skip the syscall?
b.eq__sys_trace_return_skipped
-   mov wscno, w0   // syscall number (possibly new)
-   mov x1, sp  // pointer to regs
-   cmp wscno, wsc_nr   // check upper syscall limit
-   b.hs__ni_sys_trace
-   ldp x0, x1, [sp]// restore the syscall args
-   ldp x2, x3, [sp, #S_X2]
-   ldp x4, x5, [sp, #S_X4]
-   ldp x6, x7, [sp, #S_X6]
-   ldr x16, [stbl, xscno, lsl #3]  // address in the syscall table
-   blr x16 // call sys_* routine
 
-__sys_trace_return:
-   str x0, [sp, #S_X0] // save returned x0
+   mov x0, sp
+   mov w1, wscno
+   mov w2, wsc_nr
+   mov x3, stbl
+   bl  invoke_syscall
+
 __sys_trace_return_skipped:
mov x0, sp
bl  syscall_trace_exit
b   ret_to_user
 
-__ni_sys_trace:
-   mov x0, sp
-   bl  do_ni_syscall
-   b   __sys_trace_return
-
.popsection // .entry.text
 
 #ifdef CONFIG_UNMAP_KERNEL_AT_EL0
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
new file mode 100644
index ..8bc2530c8472
--- /dev/null
+++ b/arch/arm64/kernel/syscall.c
@@ -0,0 +1,49 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include 
+#include 
+#include 
+#include 
+
+long compat_arm_syscall(struct pt_regs *regs);
+
+asmlinkage long do_ni_syscall(struct pt_regs *regs)
+{
+#ifdef CONFIG_COMPAT
+   long ret;
+   if 

[PATCHv4 05/19] arm64: move sve_user_{enable,disable} to

2018-07-02 Thread Mark Rutland
In subsequent patches, we'll want to make use of sve_user_enable() and
sve_user_disable() outside of kernel/fpsimd.c. Let's move these to
 where we can make use of them.

To avoid ifdeffery in sequences like:

if (system_supports_sve() && some_condition)
sve_user_disable();

... empty stubs are provided when support for SVE is not enabled. Note
that system_supports_sve() contains as IS_ENABLED(CONFIG_ARM64_SVE), so
the sve_user_disable() call should be optimized away entirely when
CONFIG_ARM64_SVE is not selected.

To ensure that this is the case, the stub definitions contain a
BUILD_BUG(), as we do for other stubs for which calls should always be
optimized away when the relevant config option is not selected.

At the same time, the include list of  is sorted while
adding .

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Reviewed-by: Dave Martin 
Cc: Will Deacon 
---
 arch/arm64/include/asm/fpsimd.h | 17 -
 arch/arm64/kernel/fpsimd.c  | 10 --
 2 files changed, 16 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/include/asm/fpsimd.h b/arch/arm64/include/asm/fpsimd.h
index fa92747a49c8..dd1ad3950ef5 100644
--- a/arch/arm64/include/asm/fpsimd.h
+++ b/arch/arm64/include/asm/fpsimd.h
@@ -16,13 +16,15 @@
 #ifndef __ASM_FP_H
 #define __ASM_FP_H
 
-#include 
 #include 
+#include 
 #include 
 #include 
+#include 
 
 #ifndef __ASSEMBLY__
 
+#include 
 #include 
 #include 
 #include 
@@ -102,6 +104,16 @@ extern int sve_set_vector_length(struct task_struct *task,
 extern int sve_set_current_vl(unsigned long arg);
 extern int sve_get_current_vl(void);
 
+static inline void sve_user_disable(void)
+{
+   sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
+}
+
+static inline void sve_user_enable(void)
+{
+   sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
+}
+
 /*
  * Probing and setup functions.
  * Calls to these functions must be serialised with one another.
@@ -128,6 +140,9 @@ static inline int sve_get_current_vl(void)
return -EINVAL;
 }
 
+static inline void sve_user_disable(void) { BUILD_BUG(); }
+static inline void sve_user_enable(void) { BUILD_BUG(); }
+
 static inline void sve_init_vq_map(void) { }
 static inline void sve_update_vq_map(void) { }
 static inline int sve_verify_vq_map(void) { return 0; }
diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index a98a7f96aff1..58c53bc96928 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -159,16 +159,6 @@ static void sve_free(struct task_struct *task)
__sve_free(task);
 }
 
-static void sve_user_disable(void)
-{
-   sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
-}
-
-static void sve_user_enable(void)
-{
-   sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
-}
-
 /*
  * TIF_SVE controls whether a task can use SVE without trapping while
  * in userspace, and also the way a task's FPSIMD/SVE state is stored
-- 
2.11.0



[PATCHv4 11/19] arm64: don't reload GPRs after apply_ssbd

2018-07-02 Thread Mark Rutland
Now that all of the syscall logic works on the saved pt_regs, apply_ssbd
can safely corrupt x0-x3 in the entry paths, and we no longer need to
restore them. So let's remove the logic doing so.

With that logic gone, we can fold the branch target into the macro, so
that callers need not deal with this. GAS provides \@, which provides a
unique value per macro invocation, which we can use to create a unique
label.

Signed-off-by: Mark Rutland 
Acked-by: Marc Zyngier 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/entry.S | 20 +++-
 1 file changed, 7 insertions(+), 13 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index c41b84d06644..728bc7cc5bbb 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -130,20 +130,21 @@ alternative_else_nop_endif
 
// This macro corrupts x0-x3. It is the caller's duty
// to save/restore them if required.
-   .macro  apply_ssbd, state, targ, tmp1, tmp2
+   .macro  apply_ssbd, state, tmp1, tmp2
 #ifdef CONFIG_ARM64_SSBD
 alternative_cb arm64_enable_wa2_handling
-   b   \targ
+   b   skip_apply_ssbd\@
 alternative_cb_end
ldr_this_cpu\tmp2, arm64_ssbd_callback_required, \tmp1
-   cbz \tmp2, \targ
+   cbz \tmp2, skip_apply_ssbd\@
ldr \tmp2, [tsk, #TSK_TI_FLAGS]
-   tbnz\tmp2, #TIF_SSBD, \targ
+   tbnz\tmp2, #TIF_SSBD, skip_apply_ssbd\@
mov w0, #ARM_SMCCC_ARCH_WORKAROUND_2
mov w1, #\state
 alternative_cb arm64_update_smccc_conduit
nop // Patched to SMC/HVC #0
 alternative_cb_end
+skip_apply_ssbd\@:
 #endif
.endm
 
@@ -173,13 +174,7 @@ alternative_cb_end
ldr x19, [tsk, #TSK_TI_FLAGS]   // since we can unmask debug
disable_step_tsk x19, x20   // exceptions when scheduling.
 
-   apply_ssbd 1, 1f, x22, x23
-
-#ifdef CONFIG_ARM64_SSBD
-   ldp x0, x1, [sp, #16 * 0]
-   ldp x2, x3, [sp, #16 * 1]
-#endif
-1:
+   apply_ssbd 1, x22, x23
 
mov x29, xzr// fp pointed to user-space
.else
@@ -321,8 +316,7 @@ alternative_if ARM64_WORKAROUND_845719
 alternative_else_nop_endif
 #endif
 3:
-   apply_ssbd 0, 5f, x0, x1
-5:
+   apply_ssbd 0, x0, x1
.endif
 
msr elr_el1, x21// set up the return data
-- 
2.11.0



[PATCHv4 09/19] arm64: convert native/compat syscall entry to C

2018-07-02 Thread Mark Rutland
Now that the syscall invocation logic is in C, we can migrate the rest
of the syscall entry logic over, so that the entry assembly needn't look
at the register values at all.

The SVE reset across syscall logic now unconditionally clears TIF_SVE,
but sve_user_disable() will only write back to CPACR_EL1 when SVE is
actually enabled.

Signed-off-by: Mark Rutland 
Reviewed-by: Catalin Marinas 
Reviewed-by: Dave Martin 
Cc: Will Deacon 
---
 arch/arm64/kernel/entry.S   | 42 --
 arch/arm64/kernel/syscall.c | 41 +++--
 2 files changed, 43 insertions(+), 40 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 05b9f03f3e00..156c4e3fd1a4 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -720,14 +720,9 @@ el0_sync_compat:
b.geel0_dbg
b   el0_inv
 el0_svc_compat:
-   /*
-* AArch32 syscall handling
-*/
-   ldr x16, [tsk, #TSK_TI_FLAGS]   // load thread flags
-   adrpstbl, compat_sys_call_table // load compat syscall table 
pointer
-   mov wscno, w7   // syscall number in w7 (r7)
-   mov wsc_nr, #__NR_compat_syscalls
-   b   el0_svc_naked
+   mov x0, sp
+   bl  el0_svc_compat_handler
+   b   ret_to_user
 
.align  6
 el0_irq_compat:
@@ -925,37 +920,8 @@ ENDPROC(ret_to_user)
  */
.align  6
 el0_svc:
-   ldr x16, [tsk, #TSK_TI_FLAGS]   // load thread flags
-   adrpstbl, sys_call_table// load syscall table pointer
-   mov wscno, w8   // syscall number in w8
-   mov wsc_nr, #__NR_syscalls
-
-#ifdef CONFIG_ARM64_SVE
-alternative_if_not ARM64_SVE
-   b   el0_svc_naked
-alternative_else_nop_endif
-   tbz x16, #TIF_SVE, el0_svc_naked// Skip unless TIF_SVE set:
-   bic x16, x16, #_TIF_SVE // discard SVE state
-   str x16, [tsk, #TSK_TI_FLAGS]
-
-   /*
-* task_fpsimd_load() won't be called to update CPACR_EL1 in
-* ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
-* happens if a context switch or kernel_neon_begin() or context
-* modification (sigreturn, ptrace) intervenes.
-* So, ensure that CPACR_EL1 is already correct for the fast-path case:
-*/
-   mrs x9, cpacr_el1
-   bic x9, x9, #CPACR_EL1_ZEN_EL0EN// disable SVE for el0
-   msr cpacr_el1, x9   // synchronised by eret to el0
-#endif
-
-el0_svc_naked: // compat entry point
mov x0, sp
-   mov w1, wscno
-   mov w2, wsc_nr
-   mov x3, stbl
-   bl  el0_svc_common
+   bl  el0_svc_handler
b   ret_to_user
 ENDPROC(el0_svc)
 
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index e3153ffe7f8e..ea4fc5eea182 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -8,7 +8,9 @@
 #include 
 
 #include 
+#include 
 #include 
+#include 
 
 long compat_arm_syscall(struct pt_regs *regs);
 
@@ -61,8 +63,8 @@ static inline bool has_syscall_work(unsigned long flags)
 int syscall_trace_enter(struct pt_regs *regs);
 void syscall_trace_exit(struct pt_regs *regs);
 
-asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
-  syscall_fn_t syscall_table[])
+static void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
+  syscall_fn_t syscall_table[])
 {
unsigned long flags = current_thread_info()->flags;
 
@@ -99,3 +101,38 @@ asmlinkage void el0_svc_common(struct pt_regs *regs, int 
scno, int sc_nr,
 trace_exit:
syscall_trace_exit(regs);
 }
+
+static inline void sve_user_discard(void)
+{
+   if (!system_supports_sve())
+   return;
+
+   clear_thread_flag(TIF_SVE);
+
+   /*
+* task_fpsimd_load() won't be called to update CPACR_EL1 in
+* ret_to_user unless TIF_FOREIGN_FPSTATE is still set, which only
+* happens if a context switch or kernel_neon_begin() or context
+* modification (sigreturn, ptrace) intervenes.
+* So, ensure that CPACR_EL1 is already correct for the fast-path case.
+*/
+   sve_user_disable();
+}
+
+extern syscall_fn_t sys_call_table[];
+
+asmlinkage void el0_svc_handler(struct pt_regs *regs)
+{
+   sve_user_discard();
+   el0_svc_common(regs, regs->regs[8], __NR_syscalls, sys_call_table);
+}
+
+#ifdef CONFIG_COMPAT
+extern syscall_fn_t compat_sys_call_table[];
+
+asmlinkage void el0_svc_compat_handler(struct pt_regs *regs)
+{
+   el0_svc_common(regs, regs->regs[7], __NR_compat_syscalls,
+  compat_sys_call_table);
+}
+#endif
-- 
2.11.0



[PATCHv4 10/19] arm64: don't restore GPRs when context tracking

2018-07-02 Thread Mark Rutland
Now that syscalls are invoked with pt_regs, we no longer need to ensure
that the argument regsiters are live in the entry assembly, and it's
fine to not restore them after context_tracking_user_exit() has
corrupted them.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/entry.S | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 156c4e3fd1a4..c41b84d06644 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -41,19 +41,9 @@
  * Context tracking subsystem.  Used to instrument transitions
  * between user and kernel mode.
  */
-   .macro ct_user_exit, syscall = 0
+   .macro ct_user_exit
 #ifdef CONFIG_CONTEXT_TRACKING
bl  context_tracking_user_exit
-   .if \syscall == 1
-   /*
-* Save/restore needed during syscalls.  Restore syscall arguments from
-* the values already saved on stack during kernel_entry.
-*/
-   ldp x0, x1, [sp]
-   ldp x2, x3, [sp, #S_X2]
-   ldp x4, x5, [sp, #S_X4]
-   ldp x6, x7, [sp, #S_X6]
-   .endif
 #endif
.endm
 
-- 
2.11.0



[PATCHv4 13/19] kernel: add ksys_personality()

2018-07-02 Thread Mark Rutland
Using this helper allows us to avoid the in-kernel call to the
sys_personality() syscall. The ksys_ prefix denotes that this function
is meant as a drop-in replacement for the syscall. In particular, it
uses the same calling convention as sys_personality().

Since ksys_personality is trivial, it is implemented directly in
, as we do for ksys_close() and friends.

This helper is necessary to enable conversion of arm64's syscall
handling to use pt_regs wrappers.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Cc: Al Viro 
Cc: Christoph Hellwig 
Cc: Dave Martin 
---
 include/linux/syscalls.h | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index a368a68cb667..abfe12d8a9c5 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -80,6 +80,7 @@ union bpf_attr;
 #include 
 #include 
 #include 
+#include 
 #include 
 
 #ifdef CONFIG_ARCH_HAS_SYSCALL_WRAPPER
@@ -1281,4 +1282,14 @@ static inline long ksys_truncate(const char __user 
*pathname, loff_t length)
return do_sys_truncate(pathname, length);
 }
 
+static inline unsigned int ksys_personality(unsigned int personality)
+{
+   unsigned int old = current->personality;
+
+   if (personality != 0x)
+   set_personality(personality);
+
+   return old;
+}
+
 #endif
-- 
2.11.0



[PATCHv4 15/19] arm64: remove in-kernel call to sys_personality()

2018-07-02 Thread Mark Rutland
With pt_regs syscall wrappers, the calling convention for
sys_personality() will change. Use ksys_personality(), which is
functionally equivalent.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/sys.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 31045f3fed92..a82c3f7a9a90 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -42,7 +42,7 @@ SYSCALL_DEFINE1(arm64_personality, unsigned int, personality)
if (personality(personality) == PER_LINUX32 &&
!system_supports_32bit_el0())
return -EINVAL;
-   return sys_personality(personality);
+   return ksys_personality(personality);
 }
 
 /*
-- 
2.11.0



[PATCHv4 14/19] kernel: add kcompat_sys_{f,}statfs64()

2018-07-02 Thread Mark Rutland
Using this helper allows us to avoid the in-kernel calls to the
compat_sys_{f,}statfs64() sycalls, as are necessary for parameter
mangling in arm64's compat handling.

Following the example of ksys_* functions, kcompat_sys_* functions are
intended to be a drop-in replacement for their compat_sys_*
counterparts, with the same calling convention.

This is necessary to enable conversion of arm64's syscall handling to
use pt_regs wrappers.

Signed-off-by: Mark Rutland 
Reviewed-by: Dominik Brodowski 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
---
 fs/statfs.c| 14 --
 include/linux/compat.h | 11 +++
 2 files changed, 23 insertions(+), 2 deletions(-)

diff --git a/fs/statfs.c b/fs/statfs.c
index 5b2a24f0f263..f0216629621d 100644
--- a/fs/statfs.c
+++ b/fs/statfs.c
@@ -335,7 +335,7 @@ static int put_compat_statfs64(struct compat_statfs64 
__user *ubuf, struct kstat
return 0;
 }
 
-COMPAT_SYSCALL_DEFINE3(statfs64, const char __user *, pathname, compat_size_t, 
sz, struct compat_statfs64 __user *, buf)
+int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz, 
struct compat_statfs64 __user * buf)
 {
struct kstatfs tmp;
int error;
@@ -349,7 +349,12 @@ COMPAT_SYSCALL_DEFINE3(statfs64, const char __user *, 
pathname, compat_size_t, s
return error;
 }
 
-COMPAT_SYSCALL_DEFINE3(fstatfs64, unsigned int, fd, compat_size_t, sz, struct 
compat_statfs64 __user *, buf)
+COMPAT_SYSCALL_DEFINE3(statfs64, const char __user *, pathname, compat_size_t, 
sz, struct compat_statfs64 __user *, buf)
+{
+   return kcompat_sys_statfs64(pathname, sz, buf);
+}
+
+int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz, struct 
compat_statfs64 __user * buf)
 {
struct kstatfs tmp;
int error;
@@ -363,6 +368,11 @@ COMPAT_SYSCALL_DEFINE3(fstatfs64, unsigned int, fd, 
compat_size_t, sz, struct co
return error;
 }
 
+COMPAT_SYSCALL_DEFINE3(fstatfs64, unsigned int, fd, compat_size_t, sz, struct 
compat_statfs64 __user *, buf)
+{
+   return kcompat_sys_fstatfs64(fd, sz, buf);
+}
+
 /*
  * This is a copy of sys_ustat, just dealing with a structure layout.
  * Given how simple this syscall is that apporach is more maintainable
diff --git a/include/linux/compat.h b/include/linux/compat.h
index c68acc47da57..43f4ed44c5d5 100644
--- a/include/linux/compat.h
+++ b/include/linux/compat.h
@@ -1028,6 +1028,17 @@ static inline struct compat_timeval 
ns_to_compat_timeval(s64 nsec)
return ctv;
 }
 
+/*
+ * Kernel code should not call compat syscalls (i.e., compat_sys_xyzyyz())
+ * directly.  Instead, use one of the functions which work equivalently, such
+ * as the kcompat_sys_xyzyyz() functions prototyped below.
+ */
+
+int kcompat_sys_statfs64(const char __user * pathname, compat_size_t sz,
+struct compat_statfs64 __user * buf);
+int kcompat_sys_fstatfs64(unsigned int fd, compat_size_t sz,
+ struct compat_statfs64 __user * buf);
+
 #else /* !CONFIG_COMPAT */
 
 #define is_compat_task() (0)
-- 
2.11.0



[PATCHv4 06/19] arm64: remove sigreturn wrappers

2018-07-02 Thread Mark Rutland
The arm64 sigreturn* syscall handlers are non-standard. Rather than
taking a number of user parameters in registers as per the AAPCS,
they expect the pt_regs as their sole argument.

To make this work, we override the syscall definitions to invoke
wrappers written in assembly, which mov the SP into x0, and branch to
their respective C functions.

On other architectures (such as x86), the sigreturn* functions take no
argument and instead use current_pt_regs() to acquire the user
registers. This requires less boilerplate code, and allows for other
features such as interposing C code in this path.

This patch takes the same approach for arm64.

Signed-off-by: Mark Rutland 
Tentatively-reviewed-by: Dave Martin 
Reviewed-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/include/asm/unistd32.h |  4 ++--
 arch/arm64/kernel/entry.S |  8 
 arch/arm64/kernel/entry32.S   | 10 --
 arch/arm64/kernel/signal.c|  3 ++-
 arch/arm64/kernel/signal32.c  |  6 --
 arch/arm64/kernel/sys.c   |  3 +--
 arch/arm64/kernel/sys32.c |  4 ++--
 7 files changed, 11 insertions(+), 27 deletions(-)

diff --git a/arch/arm64/include/asm/unistd32.h 
b/arch/arm64/include/asm/unistd32.h
index ef292160748c..ab95554b1734 100644
--- a/arch/arm64/include/asm/unistd32.h
+++ b/arch/arm64/include/asm/unistd32.h
@@ -260,7 +260,7 @@ __SYSCALL(117, sys_ni_syscall)
 #define __NR_fsync 118
 __SYSCALL(__NR_fsync, sys_fsync)
 #define __NR_sigreturn 119
-__SYSCALL(__NR_sigreturn, compat_sys_sigreturn_wrapper)
+__SYSCALL(__NR_sigreturn, compat_sys_sigreturn)
 #define __NR_clone 120
 __SYSCALL(__NR_clone, sys_clone)
 #define __NR_setdomainname 121
@@ -368,7 +368,7 @@ __SYSCALL(__NR_getresgid, sys_getresgid16)
 #define __NR_prctl 172
 __SYSCALL(__NR_prctl, sys_prctl)
 #define __NR_rt_sigreturn 173
-__SYSCALL(__NR_rt_sigreturn, compat_sys_rt_sigreturn_wrapper)
+__SYSCALL(__NR_rt_sigreturn, compat_sys_rt_sigreturn)
 #define __NR_rt_sigaction 174
 __SYSCALL(__NR_rt_sigaction, compat_sys_rt_sigaction)
 #define __NR_rt_sigprocmask 175
diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 28ad8799406f..62f2876f9c63 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -1138,14 +1138,6 @@ __entry_tramp_data_start:
 #endif /* CONFIG_UNMAP_KERNEL_AT_EL0 */
 
 /*
- * Special system call wrappers.
- */
-ENTRY(sys_rt_sigreturn_wrapper)
-   mov x0, sp
-   b   sys_rt_sigreturn
-ENDPROC(sys_rt_sigreturn_wrapper)
-
-/*
  * Register switch for AArch64. The callee-saved registers need to be saved
  * and restored. On entry:
  *   x0 = previous task_struct (must be preserved across the switch)
diff --git a/arch/arm64/kernel/entry32.S b/arch/arm64/kernel/entry32.S
index f332d5d1f6b4..f9461696dde4 100644
--- a/arch/arm64/kernel/entry32.S
+++ b/arch/arm64/kernel/entry32.S
@@ -30,16 +30,6 @@
  * System call wrappers for the AArch32 compatibility layer.
  */
 
-ENTRY(compat_sys_sigreturn_wrapper)
-   mov x0, sp
-   b   compat_sys_sigreturn
-ENDPROC(compat_sys_sigreturn_wrapper)
-
-ENTRY(compat_sys_rt_sigreturn_wrapper)
-   mov x0, sp
-   b   compat_sys_rt_sigreturn
-ENDPROC(compat_sys_rt_sigreturn_wrapper)
-
 ENTRY(compat_sys_statfs64_wrapper)
mov w3, #84
cmp w1, #88
diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 70287634706e..f03e664f773f 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -539,8 +539,9 @@ static int restore_sigframe(struct pt_regs *regs,
return err;
 }
 
-asmlinkage long sys_rt_sigreturn(struct pt_regs *regs)
+asmlinkage long sys_rt_sigreturn(void)
 {
+   struct pt_regs *regs = current_pt_regs();
struct rt_sigframe __user *frame;
 
/* Always make any pending restarted system calls return -EINTR */
diff --git a/arch/arm64/kernel/signal32.c b/arch/arm64/kernel/signal32.c
index 77b91f478995..cb10588a7cb2 100644
--- a/arch/arm64/kernel/signal32.c
+++ b/arch/arm64/kernel/signal32.c
@@ -282,8 +282,9 @@ static int compat_restore_sigframe(struct pt_regs *regs,
return err;
 }
 
-asmlinkage int compat_sys_sigreturn(struct pt_regs *regs)
+asmlinkage int compat_sys_sigreturn(void)
 {
+   struct pt_regs *regs = current_pt_regs();
struct compat_sigframe __user *frame;
 
/* Always make any pending restarted system calls return -EINTR */
@@ -312,8 +313,9 @@ asmlinkage int compat_sys_sigreturn(struct pt_regs *regs)
return 0;
 }
 
-asmlinkage int compat_sys_rt_sigreturn(struct pt_regs *regs)
+asmlinkage int compat_sys_rt_sigreturn(void)
 {
+   struct pt_regs *regs = current_pt_regs();
struct compat_rt_sigframe __user *frame;
 
/* Always make any pending restarted system calls return -EINTR */
diff --git a/arch/arm64/kernel/sys.c b/arch/arm64/kernel/sys.c
index 72981bae10eb..31045f3fed92 100644
--- a/arch/arm64/kernel/sys.c
+++ b/arch/arm64/kernel/sys.c
@@ -48,8 +48,7 @@ 

[PATCHv4 12/19] arm64: zero GPRs upon entry from EL0

2018-07-02 Thread Mark Rutland
We can zero GPRs x0 - x29 upon entry from EL0 to make it harder for
userspace to control values consumed by speculative gadgets.

We don't blat x30, since this is stashed much later, and we'll blat it
before invoking C code.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/entry.S | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index 728bc7cc5bbb..6b7789d72064 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -53,6 +53,12 @@
 #endif
.endm
 
+   .macro  clear_gp_regs
+   .irp
n,0,1,2,3,4,5,6,7,8,9,10,11,12,13,14,15,16,17,18,19,20,21,22,23,24,25,26,27,28,29
+   mov x\n, xzr
+   .endr
+   .endm
+
 /*
  * Bad Abort numbers
  *-
@@ -169,6 +175,7 @@ skip_apply_ssbd\@:
stp x28, x29, [sp, #16 * 14]
 
.if \el == 0
+   clear_gp_regs
mrs x21, sp_el0
ldr_this_cputsk, __entry_task, x20  // Ensure MDSCR_EL1.SS is clear,
ldr x19, [tsk, #TSK_TI_FLAGS]   // since we can unmask debug
@@ -176,7 +183,6 @@ skip_apply_ssbd\@:
 
apply_ssbd 1, x22, x23
 
-   mov x29, xzr// fp pointed to user-space
.else
add x21, sp, #S_FRAME_SIZE
get_thread_info tsk
-- 
2.11.0



[PATCHv4 08/19] arm64: convert syscall trace logic to C

2018-07-02 Thread Mark Rutland
Currently syscall tracing is a tricky assembly state machine, which can
be rather difficult to follow, and even harder to modify. Before we
start fiddling with it for pt_regs syscalls, let's convert it to C.

This is not intended to have any functional change.

Signed-off-by: Mark Rutland 
Reviewed-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/entry.S   | 53 ++---
 arch/arm64/kernel/syscall.c | 58 ++---
 2 files changed, 57 insertions(+), 54 deletions(-)

diff --git a/arch/arm64/kernel/entry.S b/arch/arm64/kernel/entry.S
index c0392f78e392..05b9f03f3e00 100644
--- a/arch/arm64/kernel/entry.S
+++ b/arch/arm64/kernel/entry.S
@@ -896,24 +896,6 @@ el0_error_naked:
b   ret_to_user
 ENDPROC(el0_error)
 
-
-/*
- * This is the fast syscall return path.  We do as little as possible here,
- * and this includes saving x0 back into the kernel stack.
- */
-ret_fast_syscall:
-   disable_daif
-   ldr x1, [tsk, #TSK_TI_FLAGS]// re-check for syscall tracing
-   and x2, x1, #_TIF_SYSCALL_WORK
-   cbnzx2, ret_fast_syscall_trace
-   and x2, x1, #_TIF_WORK_MASK
-   cbnzx2, work_pending
-   enable_step_tsk x1, x2
-   kernel_exit 0
-ret_fast_syscall_trace:
-   enable_daif
-   b   __sys_trace_return_skipped  // we already saved x0
-
 /*
  * Ok, we need to do extra processing, enter the slow path.
  */
@@ -969,44 +951,13 @@ alternative_else_nop_endif
 #endif
 
 el0_svc_naked: // compat entry point
-   stp x0, xscno, [sp, #S_ORIG_X0] // save the original x0 and 
syscall number
-   enable_daif
-   ct_user_exit 1
-
-   tst x16, #_TIF_SYSCALL_WORK // check for syscall hooks
-   b.ne__sys_trace
mov x0, sp
mov w1, wscno
mov w2, wsc_nr
mov x3, stbl
-   bl  invoke_syscall
-   b   ret_fast_syscall
-ENDPROC(el0_svc)
-
-   /*
-* This is the really slow path.  We're going to be doing context
-* switches, and waiting for our parent to respond.
-*/
-__sys_trace:
-   cmp wscno, #NO_SYSCALL  // user-issued syscall(-1)?
-   b.ne1f
-   mov x0, #-ENOSYS// set default errno if so
-   str x0, [sp, #S_X0]
-1: mov x0, sp
-   bl  syscall_trace_enter
-   cmp w0, #NO_SYSCALL // skip the syscall?
-   b.eq__sys_trace_return_skipped
-
-   mov x0, sp
-   mov w1, wscno
-   mov w2, wsc_nr
-   mov x3, stbl
-   bl  invoke_syscall
-
-__sys_trace_return_skipped:
-   mov x0, sp
-   bl  syscall_trace_exit
+   bl  el0_svc_common
b   ret_to_user
+ENDPROC(el0_svc)
 
.popsection // .entry.text
 
diff --git a/arch/arm64/kernel/syscall.c b/arch/arm64/kernel/syscall.c
index 8bc2530c8472..e3153ffe7f8e 100644
--- a/arch/arm64/kernel/syscall.c
+++ b/arch/arm64/kernel/syscall.c
@@ -1,10 +1,15 @@
 // SPDX-License-Identifier: GPL-2.0
 
+#include 
+#include 
 #include 
 #include 
 #include 
 #include 
 
+#include 
+#include 
+
 long compat_arm_syscall(struct pt_regs *regs);
 
 asmlinkage long do_ni_syscall(struct pt_regs *regs)
@@ -31,9 +36,9 @@ static long __invoke_syscall(struct pt_regs *regs, 
syscall_fn_t syscall_fn)
  regs->regs[3], regs->regs[4], regs->regs[5]);
 }
 
-asmlinkage void invoke_syscall(struct pt_regs *regs, unsigned int scno,
-  unsigned int sc_nr,
-  syscall_fn_t syscall_table[])
+static void invoke_syscall(struct pt_regs *regs, unsigned int scno,
+  unsigned int sc_nr,
+  syscall_fn_t syscall_table[])
 {
long ret;
 
@@ -47,3 +52,50 @@ asmlinkage void invoke_syscall(struct pt_regs *regs, 
unsigned int scno,
 
regs->regs[0] = ret;
 }
+
+static inline bool has_syscall_work(unsigned long flags)
+{
+   return unlikely(flags & _TIF_SYSCALL_WORK);
+}
+
+int syscall_trace_enter(struct pt_regs *regs);
+void syscall_trace_exit(struct pt_regs *regs);
+
+asmlinkage void el0_svc_common(struct pt_regs *regs, int scno, int sc_nr,
+  syscall_fn_t syscall_table[])
+{
+   unsigned long flags = current_thread_info()->flags;
+
+   regs->orig_x0 = regs->regs[0];
+   regs->syscallno = scno;
+
+   local_daif_restore(DAIF_PROCCTX);
+   user_exit();
+
+   if (has_syscall_work(flags)) {
+   /* set default errno for user-issued syscall(-1) */
+   if (scno == NO_SYSCALL)
+   regs->regs[0] = -ENOSYS;
+   scno = syscall_trace_enter(regs);
+   if (scno == NO_SYSCALL)
+   goto trace_exit;
+   }
+
+   invoke_syscall(regs, scno, sc_nr, 

[PATCHv4 04/19] arm64: kill change_cpacr()

2018-07-02 Thread Mark Rutland
Now that we have sysreg_clear_set(), we can use this instead of
change_cpacr().

Note that the order of the set and clear arguments differs between
change_cpacr() and sysreg_clear_set(), so these are flipped as part of
the conversion. Also, sve_user_enable() redundantly clears
CPACR_EL1_ZEN_EL0EN before setting it; this is removed for clarity.

Signed-off-by: Mark Rutland 
Reviewed-by: Dave Martin 
Acked-by: Catalin Marinas 
Cc: James Morse 
Cc: Will Deacon 
---
 arch/arm64/kernel/fpsimd.c | 13 ++---
 1 file changed, 2 insertions(+), 11 deletions(-)

diff --git a/arch/arm64/kernel/fpsimd.c b/arch/arm64/kernel/fpsimd.c
index 84c68b14f1b2..a98a7f96aff1 100644
--- a/arch/arm64/kernel/fpsimd.c
+++ b/arch/arm64/kernel/fpsimd.c
@@ -159,23 +159,14 @@ static void sve_free(struct task_struct *task)
__sve_free(task);
 }
 
-static void change_cpacr(u64 val, u64 mask)
-{
-   u64 cpacr = read_sysreg(CPACR_EL1);
-   u64 new = (cpacr & ~mask) | val;
-
-   if (new != cpacr)
-   write_sysreg(new, CPACR_EL1);
-}
-
 static void sve_user_disable(void)
 {
-   change_cpacr(0, CPACR_EL1_ZEN_EL0EN);
+   sysreg_clear_set(cpacr_el1, CPACR_EL1_ZEN_EL0EN, 0);
 }
 
 static void sve_user_enable(void)
 {
-   change_cpacr(CPACR_EL1_ZEN_EL0EN, CPACR_EL1_ZEN_EL0EN);
+   sysreg_clear_set(cpacr_el1, 0, CPACR_EL1_ZEN_EL0EN);
 }
 
 /*
-- 
2.11.0



[PATCHv4 02/19] arm64: move SCTLR_EL{1,2} assertions to

2018-07-02 Thread Mark Rutland
Currently we assert that the SCTLR_EL{1,2}_{SET,CLEAR} bits are
self-consistent with an assertion in config_sctlr_el1(). This is a bit
unusual, since config_sctlr_el1() doesn't make use of these definitions,
and is far away from the definitions themselves.

We can use the CPP #error directive to have equivalent assertions in
, next to the definitions of the set/clear bits, which is
a bit clearer and simpler.

At the same time, lets fill in the upper 32 bits for both registers in
their respective RES0 definitions. This could be a little nicer with
GENMASK_ULL(63, 32), but this currently lives in , which
cannot safely be included from assembly, as  can.

Note the when the preprocessor evaluates an expression for an #if
directive, all signed or unsigned values are treated as intmax_t or
uintmax_t respectively. To avoid ambiguity, we define explicitly define
the mask of all 64 bits.

Signed-off-by: Mark Rutland 
Acked-by: Catalin Marinas 
Cc: Dave Martin 
Cc: James Morse 
Cc: Will Deacon 
---
 arch/arm64/include/asm/sysreg.h | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/arch/arm64/include/asm/sysreg.h b/arch/arm64/include/asm/sysreg.h
index a8f84812c6e8..fefc17dae8ee 100644
--- a/arch/arm64/include/asm/sysreg.h
+++ b/arch/arm64/include/asm/sysreg.h
@@ -436,7 +436,8 @@
 #define SCTLR_EL2_RES0 ((1 << 6)  | (1 << 7)  | (1 << 8)  | (1 << 9)  | \
 (1 << 10) | (1 << 13) | (1 << 14) | (1 << 15) | \
 (1 << 17) | (1 << 20) | (1 << 24) | (1 << 26) | \
-(1 << 27) | (1 << 30) | (1 << 31))
+(1 << 27) | (1 << 30) | (1 << 31) | \
+(0xUL << 32))
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
 #define ENDIAN_SET_EL2 SCTLR_ELx_EE
@@ -452,9 +453,9 @@
 SCTLR_ELx_SA | SCTLR_ELx_I| SCTLR_ELx_WXN | \
 ENDIAN_CLEAR_EL2 | SCTLR_EL2_RES0)
 
-/* Check all the bits are accounted for */
-#define SCTLR_EL2_BUILD_BUG_ON_MISSING_BITSBUILD_BUG_ON((SCTLR_EL2_SET ^ 
SCTLR_EL2_CLEAR) != ~0)
-
+#if (SCTLR_EL2_SET ^ SCTLR_EL2_CLEAR) != 0x
+#error "Inconsistent SCTLR_EL2 set/clear bits"
+#endif
 
 /* SCTLR_EL1 specific flags. */
 #define SCTLR_EL1_UCI  (1 << 26)
@@ -473,7 +474,8 @@
 #define SCTLR_EL1_RES1 ((1 << 11) | (1 << 20) | (1 << 22) | (1 << 28) | \
 (1 << 29))
 #define SCTLR_EL1_RES0  ((1 << 6)  | (1 << 10) | (1 << 13) | (1 << 17) | \
-(1 << 27) | (1 << 30) | (1 << 31))
+(1 << 27) | (1 << 30) | (1 << 31) | \
+(0xUL << 32))
 
 #ifdef CONFIG_CPU_BIG_ENDIAN
 #define ENDIAN_SET_EL1 (SCTLR_EL1_E0E | SCTLR_ELx_EE)
@@ -492,8 +494,9 @@
 SCTLR_EL1_UMA | SCTLR_ELx_WXN | ENDIAN_CLEAR_EL1 |\
 SCTLR_EL1_RES0)
 
-/* Check all the bits are accounted for */
-#define SCTLR_EL1_BUILD_BUG_ON_MISSING_BITSBUILD_BUG_ON((SCTLR_EL1_SET ^ 
SCTLR_EL1_CLEAR) != ~0)
+#if (SCTLR_EL1_SET ^ SCTLR_EL1_CLEAR) != 0x
+#error "Inconsistent SCTLR_EL1 set/clear bits"
+#endif
 
 /* id_aa64isar0 */
 #define ID_AA64ISAR0_TS_SHIFT  52
@@ -743,9 +746,6 @@ static inline void config_sctlr_el1(u32 clear, u32 set)
 {
u32 val;
 
-   SCTLR_EL2_BUILD_BUG_ON_MISSING_BITS;
-   SCTLR_EL1_BUILD_BUG_ON_MISSING_BITS;
-
val = read_sysreg(sctlr_el1);
val &= ~clear;
val |= set;
-- 
2.11.0



[PATCHv4 00/19] arm64: invoke syscalls with pt_regs

2018-07-02 Thread Mark Rutland
This series reworks arm64's syscall handling to minimize the propagation
of user-controlled register values into speculated code paths. As with
x86 [1], a wrapper is generated for each syscall, which extracts the
argument from a struct pt_regs. During kernel entry from userspace,
registers are zeroed.

The arm64 kernel code directly invokes some syscalls which the x86 code
doesn't, so I've added ksys_* wrappers for these, following the x86
example. The rest of the series is arm64-specific.

I've pushed the series out to my arm64/syscall-regs branch [2] on
kernel.org.

Since v1 [3]:
* Rebase atop of arm64 for-next/core (for SSBD conflicts)
* Move ksys_personality logic into 
* Move kcompat_sys_* wrappers to 
* Fix scno bounds check to use unsigned comparison
* Fix sve_user_reset() call in el0_svc_handler()
* Add BUILD_BUG() to the !CONFIG_ARM64_SVE stubs
* Accumulate acked-by / reviewed-by tags

Since v2 [4]:
* Rebase to v4.18-rc1
* Take upper 32 RES0 bits of SCTLR_ELx into account
* Accumulate acks

Since v3 [5]:
* Rebase to v4.18-rc3 to avoid conflict with FPSIMD/SVE fixes
* Accumulate acks / reviewed-by tags
* Rework __invoke_syscall() for consistency with do_ni_syscall()
* Rename sve_user_reset() to sve_user_discard()
* Tidied up comment placement
* Typo fixes

Thanks,
Mark.

[1] https://lkml.kernel.org/r/20180330093720.6780-1-li...@dominikbrodowski.net
[2] git://git.kernel.org/pub/scm/linux/kernel/git/mark/linux.git
[3] https://lkml.kernel.org/r/20180514094640.27569-1-mark.rutl...@arm.com
[4] https://lkml.kernel.org/r/20180601112441.37810-1-mark.rutl...@arm.com
[5] https://lkml.kernel.org/r/20180618120310.39527-1-mark.rutl...@arm.com

Mark Rutland (19):
  arm64: consistently use unsigned long for thread flags
  arm64: move SCTLR_EL{1,2} assertions to 
  arm64: kill config_sctlr_el1()
  arm64: kill change_cpacr()
  arm64: move sve_user_{enable,disable} to 
  arm64: remove sigreturn wrappers
  arm64: convert raw syscall invocation to C
  arm64: convert syscall trace logic to C
  arm64: convert native/compat syscall entry to C
  arm64: don't restore GPRs when context tracking
  arm64: don't reload GPRs after apply_ssbd
  arm64: zero GPRs upon entry from EL0
  kernel: add ksys_personality()
  kernel: add kcompat_sys_{f,}statfs64()
  arm64: remove in-kernel call to sys_personality()
  arm64: use {COMPAT,}SYSCALL_DEFINE0 for sigreturn
  arm64: use SYSCALL_DEFINE6() for mmap
  arm64: convert compat wrappers to C
  arm64: implement syscall wrappers

 arch/arm64/Kconfig   |   1 +
 arch/arm64/include/asm/fpsimd.h  |  17 +++-
 arch/arm64/include/asm/syscall_wrapper.h |  80 
 arch/arm64/include/asm/sysreg.h  |  30 ++
 arch/arm64/include/asm/unistd32.h|  26 ++---
 arch/arm64/kernel/Makefile   |   5 +-
 arch/arm64/kernel/armv8_deprecated.c |   8 +-
 arch/arm64/kernel/cpu_errata.c   |   3 +-
 arch/arm64/kernel/entry.S| 157 ---
 arch/arm64/kernel/entry32.S  | 121 
 arch/arm64/kernel/fpsimd.c   |  19 
 arch/arm64/kernel/signal.c   |   5 +-
 arch/arm64/kernel/signal32.c |   6 +-
 arch/arm64/kernel/sys.c  |  19 ++--
 arch/arm64/kernel/sys32.c| 127 ++---
 arch/arm64/kernel/syscall.c  | 137 +++
 arch/arm64/kernel/traps.c|  18 +---
 arch/arm64/mm/fault.c|   2 +-
 fs/statfs.c  |  14 ++-
 include/linux/compat.h   |  11 +++
 include/linux/syscalls.h |  11 +++
 21 files changed, 453 insertions(+), 364 deletions(-)
 create mode 100644 arch/arm64/include/asm/syscall_wrapper.h
 delete mode 100644 arch/arm64/kernel/entry32.S
 create mode 100644 arch/arm64/kernel/syscall.c

-- 
2.11.0



[PATCHv4 01/19] arm64: consistently use unsigned long for thread flags

2018-07-02 Thread Mark Rutland
In do_notify_resume, we manipulate thread_flags as a 32-bit unsigned
int, whereas thread_info::flags is a 64-bit unsigned long, and elsewhere
(e.g. in the entry assembly) we manipulate the flags as a 64-bit
quantity.

For consistency, and to avoid problems if we end up with more than 32
flags, let's make do_notify_resume take the flags as a 64-bit unsigned
long.

Signed-off-by: Mark Rutland 
Reviewed-by: Dave Martin 
Acked-by: Catalin Marinas 
Cc: Will Deacon 
---
 arch/arm64/kernel/signal.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/signal.c b/arch/arm64/kernel/signal.c
index 511af13e8d8f..70287634706e 100644
--- a/arch/arm64/kernel/signal.c
+++ b/arch/arm64/kernel/signal.c
@@ -910,7 +910,7 @@ static void do_signal(struct pt_regs *regs)
 }
 
 asmlinkage void do_notify_resume(struct pt_regs *regs,
-unsigned int thread_flags)
+unsigned long thread_flags)
 {
/*
 * The assembly code enters us with IRQs off, but it hasn't
-- 
2.11.0



Re: [PATCH 08/11 v2] ARM: OMAP1: constify gpio_led

2018-07-02 Thread Tony Lindgren
* Arvind Yadav  [171225 22:40]:
> gpio_led are not supposed to change at runtime.
> struct gpio_led_platform_data working with const gpio_led
> provided by . So mark the non-const structs
> as const.
> 
> Signed-off-by: Arvind Yadav 
> ---
> changes in v2:
>   The GPIO LED driver can be built as a module, it can
>   be loaded after the init sections have gone away.
>   So removed '__initconst'.

Sorry just noticed I still have this one tagged and it's still
pending.. Applying into omap-for-v4.19/omap1.

Regards,

Tony


>  arch/arm/mach-omap1/board-h2.c| 2 +-
>  arch/arm/mach-omap1/board-h3.c| 2 +-
>  arch/arm/mach-omap1/board-htcherald.c | 2 +-
>  arch/arm/mach-omap1/board-osk.c   | 4 ++--
>  4 files changed, 5 insertions(+), 5 deletions(-)
> 
> diff --git a/arch/arm/mach-omap1/board-h2.c b/arch/arm/mach-omap1/board-h2.c
> index ab51f85..9aeb8ad 100644
> --- a/arch/arm/mach-omap1/board-h2.c
> +++ b/arch/arm/mach-omap1/board-h2.c
> @@ -274,7 +274,7 @@ static struct platform_device h2_kp_device = {
>   .resource   = h2_kp_resources,
>  };
>  
> -static struct gpio_led h2_gpio_led_pins[] = {
> +static const struct gpio_led h2_gpio_led_pins[] = {
>   {
>   .name   = "h2:red",
>   .default_trigger = "heartbeat",
> diff --git a/arch/arm/mach-omap1/board-h3.c b/arch/arm/mach-omap1/board-h3.c
> index ad339f5..2edcd63 100644
> --- a/arch/arm/mach-omap1/board-h3.c
> +++ b/arch/arm/mach-omap1/board-h3.c
> @@ -326,7 +326,7 @@ static struct spi_board_info h3_spi_board_info[] 
> __initdata = {
>   },
>  };
>  
> -static struct gpio_led h3_gpio_led_pins[] = {
> +static const struct gpio_led h3_gpio_led_pins[] = {
>   {
>   .name   = "h3:red",
>   .default_trigger = "heartbeat",
> diff --git a/arch/arm/mach-omap1/board-htcherald.c 
> b/arch/arm/mach-omap1/board-htcherald.c
> index 67d4669..e6a79fd 100644
> --- a/arch/arm/mach-omap1/board-htcherald.c
> +++ b/arch/arm/mach-omap1/board-htcherald.c
> @@ -292,7 +292,7 @@ static struct platform_device herald_gpiokeys_device = {
>  };
>  
>  /* LEDs for the Herald.  These connect to the HTCPLD GPIO device. */
> -static struct gpio_led gpio_leds[] = {
> +static const struct gpio_led gpio_leds[] = {
>   {"dpad",NULL, HTCPLD_GPIO_LED_DPAD,0, 0, 
> LEDS_GPIO_DEFSTATE_OFF},
>   {"kbd", NULL, HTCPLD_GPIO_LED_KBD, 0, 0, 
> LEDS_GPIO_DEFSTATE_OFF},
>   {"vibrate", NULL, HTCPLD_GPIO_LED_VIBRATE, 0, 0, 
> LEDS_GPIO_DEFSTATE_OFF},
> diff --git a/arch/arm/mach-omap1/board-osk.c b/arch/arm/mach-omap1/board-osk.c
> index c66372e..e2277b5 100644
> --- a/arch/arm/mach-omap1/board-osk.c
> +++ b/arch/arm/mach-omap1/board-osk.c
> @@ -167,7 +167,7 @@ static struct platform_device *osk5912_devices[] 
> __initdata = {
>   _cf_device,
>  };
>  
> -static struct gpio_led tps_leds[] = {
> +static const struct gpio_led tps_leds[] = {
>   /* NOTE:  D9 and D2 have hardware blink support.
>* Also, D9 requires non-battery power.
>*/
> @@ -385,7 +385,7 @@ static struct platform_device osk5912_lcd_device = {
>   .id = -1,
>  };
>  
> -static struct gpio_led mistral_gpio_led_pins[] = {
> +static const struct gpio_led mistral_gpio_led_pins[] = {
>   {
>   .name   = "mistral:red",
>   .default_trigger = "heartbeat",
> -- 
> 2.7.4
> 


[PATCH v3 3/5] arm64/mm: Create initial page tables in init_pg_dir

2018-07-02 Thread Jun Yao
Create initial page tables in init_pg_dir and then create final
page tables in swapper_pg_dir directly.

Signed-off-by: Jun Yao 
---
 arch/arm64/include/asm/pgtable.h |  2 ++
 arch/arm64/kernel/head.S |  4 ++--
 arch/arm64/kernel/setup.c|  1 +
 arch/arm64/mm/mmu.c  | 24 
 4 files changed, 9 insertions(+), 22 deletions(-)

diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 7c4c8f318ba9..3b408f21fe2e 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -718,6 +718,8 @@ static inline pmd_t pmdp_establish(struct vm_area_struct 
*vma,
 }
 #endif
 
+extern pgd_t init_pg_dir[PTRS_PER_PGD] __section(.init.data);
+extern pgd_t init_pg_end[] __section(.init.data);
 extern pgd_t swapper_pg_dir[PTRS_PER_PGD];
 extern pgd_t swapper_pg_end[];
 extern pgd_t idmap_pg_dir[PTRS_PER_PGD];
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index a1c7a4d3b9f3..a8e9432ffa8a 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -380,7 +380,7 @@ __create_page_tables:
/*
 * Map the kernel image (starting with PHYS_OFFSET).
 */
-   adrpx0, swapper_pg_dir
+   adrpx0, init_pg_dir
mov_q   x5, KIMAGE_VADDR + TEXT_OFFSET  // compile time __va(_text)
add x5, x5, x23 // add KASLR displacement
mov x4, PTRS_PER_PGD
@@ -837,7 +837,7 @@ __primary_switch:
mrs x20, sctlr_el1  // preserve old SCTLR_EL1 value
 #endif
 
-   adrpx26, swapper_pg_dir
+   adrpx26, init_pg_dir
bl  __enable_mmu
 #ifdef CONFIG_RELOCATABLE
bl  __relocate_kernel
diff --git a/arch/arm64/kernel/setup.c b/arch/arm64/kernel/setup.c
index 30ad2f085d1f..b065c08d4008 100644
--- a/arch/arm64/kernel/setup.c
+++ b/arch/arm64/kernel/setup.c
@@ -249,6 +249,7 @@ void __init setup_arch(char **cmdline_p)
init_mm.end_code   = (unsigned long) _etext;
init_mm.end_data   = (unsigned long) _edata;
init_mm.brk= (unsigned long) _end;
+   init_mm.pgd= init_pg_dir;
 
*cmdline_p = boot_command_line;
 
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index 2dbb2c9f1ec1..a7ab0010ff80 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -628,26 +628,10 @@ static void __init map_kernel(pgd_t *pgdp)
  */
 void __init paging_init(void)
 {
-   phys_addr_t pgd_phys = early_pgtable_alloc();
-   pgd_t *pgdp = pgd_set_fixmap(pgd_phys);
-
-   map_kernel(pgdp);
-   map_mem(pgdp);
-
-   /*
-* We want to reuse the original swapper_pg_dir so we don't have to
-* communicate the new address to non-coherent secondaries in
-* secondary_entry, and so cpu_switch_mm can generate the address with
-* adrp+add rather than a load from some global variable.
-*
-* To do this we need to go via a temporary pgd.
-*/
-   cpu_replace_ttbr1(__va(pgd_phys));
-   memcpy(swapper_pg_dir, pgdp, PGD_SIZE);
-   cpu_replace_ttbr1(lm_alias(swapper_pg_dir));
-
-   pgd_clear_fixmap();
-   memblock_free(pgd_phys, PAGE_SIZE);
+   map_kernel(swapper_pg_dir);
+   map_mem(swapper_pg_dir);
+   cpu_replace_ttbr1(swapper_pg_dir);
+   init_mm.pgd = swapper_pg_dir;
 
/*
 * We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
-- 
2.17.1



[PATCH v3 0/5] Move {idmap_pg_dir,swapper_pg_dir} to .rodata

2018-07-02 Thread Jun Yao
Version 3 changes:
As James Morse suggested[1], we split the old patch into 5
patches:

1. Introduce init_pg_dir.
2. Make __enable_mmu() take the ttbr1 page as an argument.
3. Create initial page tables in init_pg_dir and then create final
   page tables in swapper_pg_dir directly.
4. Make swapper_pg_dir smaller.
5. Move {idmap_pg_dir, swapper_pg_dir} to .rodata section.

At the same time, fix bugs mentioned in [1] and [2].

Special thanks to James Morse and Suzuki K Poulose. Without their help, I
couldn't write these patches.

v2: https://patchwork.kernel.org/patch/10485641/
v1: https://patchwork.kernel.org/patch/10476595/

[1] https://patchwork.kernel.org/patch/10485641/
[2] https://patchwork.kernel.org/patch/10485643/

Jun Yao (5):
  arm64/mm: Introduce init_pg_dir
  arm64/mm: Make __enable_mmu() take the ttbr1 page as an argument
  arm64/mm: Create initial page tables in init_pg_dir
  arm64/mm: Make swapper_pg_dir smaller
  arm64/mm: Move {idmap_pg_dir, swapper_pg_dir} to .rodata section

 arch/arm64/include/asm/assembler.h | 23 ++
 arch/arm64/include/asm/pgalloc.h   | 48 ++
 arch/arm64/include/asm/pgtable.h   | 17 ++-
 arch/arm64/kernel/head.S   | 31 ++-
 arch/arm64/kernel/setup.c  |  1 +
 arch/arm64/kernel/sleep.S  |  1 +
 arch/arm64/kernel/vmlinux.lds.S| 29 --
 arch/arm64/mm/mmu.c| 32 +++-
 8 files changed, 129 insertions(+), 53 deletions(-)

-- 
2.17.1



[PATCH v3 1/5] arm64/mm: Introduce init_pg_dir

2018-07-02 Thread Jun Yao
Add init_pg_dir to vmlinux.lds.S and boiler-plate
clearing/cleaning/invalidating it in head.S.

Signed-off-by: Jun Yao 
---
 arch/arm64/include/asm/assembler.h | 23 +++
 arch/arm64/kernel/head.S   | 24 ++--
 arch/arm64/kernel/vmlinux.lds.S|  7 +++
 3 files changed, 48 insertions(+), 6 deletions(-)

diff --git a/arch/arm64/include/asm/assembler.h 
b/arch/arm64/include/asm/assembler.h
index 0bcc98dbba56..414fb167e3e7 100644
--- a/arch/arm64/include/asm/assembler.h
+++ b/arch/arm64/include/asm/assembler.h
@@ -456,6 +456,29 @@ USER(\label, icivau, \tmp2)// 
invalidate I line PoU
b.ne9998b
.endm
 
+/*
+ * clear_page - clear one page
+ */
+   .macro clear_page, start:req
+9996:  stp xzr, xzr, [\start], #16
+   stp xzr, xzr, [\start], #16
+   stp xzr, xzr, [\start], #16
+   stp xzr, xzr, [\start], #16
+   tst \start, #(PAGE_SIZE - 1)
+   b.ne9996b
+   .endm
+
+/*
+ * clear_pages - clear contiguous pages
+ */
+   .macro clear_pages, start:req, count:req
+9997:  cbz \count, 9998f
+   clear_page \start
+   sub \count, \count, #1
+   b   9997b
+9998:
+   .endm
+
 /*
  * Annotate a function as position independent, i.e., safe to be called before
  * the kernel virtual mapping is activated.
diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index b0853069702f..3f99c59ba193 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -295,18 +295,25 @@ __create_page_tables:
sub x1, x1, x0
bl  __inval_dcache_area
 
+   adrpx0, init_pg_dir
+   adrpx1, init_pg_end
+   sub x1, x1, x0
+   bl  __inval_dcache_area
+
/*
 * Clear the idmap and swapper page tables.
 */
adrpx0, idmap_pg_dir
adrpx1, swapper_pg_end
sub x1, x1, x0
-1: stp xzr, xzr, [x0], #16
-   stp xzr, xzr, [x0], #16
-   stp xzr, xzr, [x0], #16
-   stp xzr, xzr, [x0], #16
-   subsx1, x1, #64
-   b.ne1b
+   lsr x1, x1, #(PAGE_SHIFT)
+   clear_pages x0, x1
+
+   adrpx0, init_pg_dir
+   adrpx1, init_pg_end
+   sub x1, x1, x0
+   lsr x1, x1, #(PAGE_SHIFT)
+   clear_pages x0, x1
 
mov x7, SWAPPER_MM_MMUFLAGS
 
@@ -395,6 +402,11 @@ __create_page_tables:
dmb sy
bl  __inval_dcache_area
 
+   adrpx0, init_pg_dir
+   adrpx1, init_pg_end
+   sub x1, x1, x0
+   bl  __inval_dcache_area
+
ret x28
 ENDPROC(__create_page_tables)
.ltorg
diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index 605d1b60469c..d4fc68286a49 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -68,6 +68,12 @@ jiffies = jiffies_64;
 #define TRAMP_TEXT
 #endif
 
+#define INIT_DIR   \
+   . = ALIGN(PAGE_SIZE);   \
+   init_pg_dir = .;\
+   . += SWAPPER_DIR_SIZE;  \
+   init_pg_end = .;
+
 /*
  * The size of the PE/COFF section that covers the kernel image, which
  * runs from stext to _edata, must be a round multiple of the PE/COFF
@@ -168,6 +174,7 @@ SECTIONS
CON_INITCALL
SECURITY_INITCALL
INIT_RAM_FS
+   INIT_DIR
*(.init.rodata.* .init.bss) /* from the EFI stub */
}
.exit.data : {
-- 
2.17.1



[PATCH v3 4/5] arm64/mm: Make swapper_pg_dir smaller

2018-07-02 Thread Jun Yao
Make swapper_pg_dir smaller so we don't need to memblock_free() it.

Signed-off-by: Jun Yao 
---
 arch/arm64/kernel/vmlinux.lds.S | 2 +-
 arch/arm64/mm/mmu.c | 8 
 2 files changed, 1 insertion(+), 9 deletions(-)

diff --git a/arch/arm64/kernel/vmlinux.lds.S b/arch/arm64/kernel/vmlinux.lds.S
index d4fc68286a49..d69e11ad92e3 100644
--- a/arch/arm64/kernel/vmlinux.lds.S
+++ b/arch/arm64/kernel/vmlinux.lds.S
@@ -236,7 +236,7 @@ SECTIONS
. += RESERVED_TTBR0_SIZE;
 #endif
swapper_pg_dir = .;
-   . += SWAPPER_DIR_SIZE;
+   . += PAGE_SIZE;
swapper_pg_end = .;
 
__pecoff_data_size = ABSOLUTE(. - __initdata_begin);
diff --git a/arch/arm64/mm/mmu.c b/arch/arm64/mm/mmu.c
index a7ab0010ff80..a1e8fc624324 100644
--- a/arch/arm64/mm/mmu.c
+++ b/arch/arm64/mm/mmu.c
@@ -632,14 +632,6 @@ void __init paging_init(void)
map_mem(swapper_pg_dir);
cpu_replace_ttbr1(swapper_pg_dir);
init_mm.pgd = swapper_pg_dir;
-
-   /*
-* We only reuse the PGD from the swapper_pg_dir, not the pud + pmd
-* allocated with it.
-*/
-   memblock_free(__pa_symbol(swapper_pg_dir) + PAGE_SIZE,
- __pa_symbol(swapper_pg_end) - __pa_symbol(swapper_pg_dir)
- - PAGE_SIZE);
 }
 
 /*
-- 
2.17.1



[PATCH v3 5/5] arm64/mm: Move {idmap_pg_dir, swapper_pg_dir} to .rodata section

2018-07-02 Thread Jun Yao
Move {idmap_pg_dir, swapper_pg_dir} to .rodata section and
populate swapper_pg_dir by fixmap.

Signed-off-by: Jun Yao 
---
 arch/arm64/include/asm/pgalloc.h | 48 
 arch/arm64/include/asm/pgtable.h | 15 +-
 arch/arm64/kernel/vmlinux.lds.S  | 22 +--
 3 files changed, 68 insertions(+), 17 deletions(-)

diff --git a/arch/arm64/include/asm/pgalloc.h b/arch/arm64/include/asm/pgalloc.h
index 2e05bcd944c8..a0ce7d0f81c5 100644
--- a/arch/arm64/include/asm/pgalloc.h
+++ b/arch/arm64/include/asm/pgalloc.h
@@ -29,6 +29,23 @@
 #define PGALLOC_GFP(GFP_KERNEL | __GFP_ZERO)
 #define PGD_SIZE   (PTRS_PER_PGD * sizeof(pgd_t))
 
+static inline int in_swapper_dir(void *addr)
+{
+   if ((unsigned long)addr >= (unsigned long)swapper_pg_dir &&
+   (unsigned long)addr < (unsigned long)swapper_pg_end) {
+   return 1;
+   }
+   return 0;
+}
+
+static inline void *swapper_mirror_addr(void *start, void *addr)
+{
+   unsigned long offset;
+
+   offset = (unsigned long)addr - (unsigned long)swapper_pg_dir;
+   return start + offset;
+}
+
 #if CONFIG_PGTABLE_LEVELS > 2
 
 static inline pmd_t *pmd_alloc_one(struct mm_struct *mm, unsigned long addr)
@@ -49,6 +66,17 @@ static inline void __pud_populate(pud_t *pudp, phys_addr_t 
pmdp, pudval_t prot)
 
 static inline void pud_populate(struct mm_struct *mm, pud_t *pudp, pmd_t *pmdp)
 {
+#ifdef __PAGETABLE_PUD_FOLDED
+   if ((mm == _mm) && in_swapper_dir(pudp)) {
+   pud_t *pud;
+
+   pud = pud_set_fixmap(__pa_symbol(swapper_pg_dir));
+   pud = (pud_t *)swapper_mirror_addr(pud, pudp);
+   __pud_populate(pud, __pa(pmdp), PMD_TYPE_TABLE);
+   pud_clear_fixmap();
+   return;
+   }
+#endif
__pud_populate(pudp, __pa(pmdp), PMD_TYPE_TABLE);
 }
 #else
@@ -78,6 +106,15 @@ static inline void __pgd_populate(pgd_t *pgdp, phys_addr_t 
pudp, pgdval_t prot)
 
 static inline void pgd_populate(struct mm_struct *mm, pgd_t *pgdp, pud_t *pudp)
 {
+   if ((mm == _mm) && in_swapper_dir(pgdp)) {
+   pgd_t *pgd;
+
+   pgd = pgd_set_fixmap(__pa_symbol(swapper_pg_dir));
+   pgd = (pgd_t *)swapper_mirror_addr(pgd, pgdp);
+   __pgd_populate(pgd, __pa(pudp), PUD_TYPE_TABLE);
+   pgd_clear_fixmap();
+   return;
+   }
__pgd_populate(pgdp, __pa(pudp), PUD_TYPE_TABLE);
 }
 #else
@@ -139,6 +176,17 @@ static inline void __pmd_populate(pmd_t *pmdp, phys_addr_t 
ptep,
 static inline void
 pmd_populate_kernel(struct mm_struct *mm, pmd_t *pmdp, pte_t *ptep)
 {
+#ifdef __PAGETABLE_PMD_FOLDED
+   if (in_swapper_dir(pmdp)) {
+   pmd_t *pmd;
+
+   pmd = pmd_set_fixmap(__pa_symbol(swapper_pg_dir));
+   pmd = (pmd_t *)swapper_mirror_addr(pmd, pmdp);
+   __pmd_populate(pmd, __pa(ptep), PMD_TYPE_TABLE);
+   pmd_clear_fixmap();
+   return;
+   }
+#endif
/*
 * The pmd must be loaded with the physical address of the PTE table
 */
diff --git a/arch/arm64/include/asm/pgtable.h b/arch/arm64/include/asm/pgtable.h
index 3b408f21fe2e..b479d1b997c2 100644
--- a/arch/arm64/include/asm/pgtable.h
+++ b/arch/arm64/include/asm/pgtable.h
@@ -475,6 +475,9 @@ static inline phys_addr_t pmd_page_paddr(pmd_t pmd)
  */
 #define mk_pte(page,prot)  pfn_pte(page_to_pfn(page),prot)
 
+#define pmd_set_fixmap(addr)   ((pmd_t *)set_fixmap_offset(FIX_PMD, 
addr))
+#define pmd_clear_fixmap() clear_fixmap(FIX_PMD)
+
 #if CONFIG_PGTABLE_LEVELS > 2
 
 #define pmd_ERROR(pmd) __pmd_error(__FILE__, __LINE__, pmd_val(pmd))
@@ -506,11 +509,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 #define pmd_offset_phys(dir, addr) (pud_page_paddr(READ_ONCE(*(dir))) + 
pmd_index(addr) * sizeof(pmd_t))
 #define pmd_offset(dir, addr)  ((pmd_t *)__va(pmd_offset_phys((dir), 
(addr
 
-#define pmd_set_fixmap(addr)   ((pmd_t *)set_fixmap_offset(FIX_PMD, 
addr))
 #define pmd_set_fixmap_offset(pud, addr)   
pmd_set_fixmap(pmd_offset_phys(pud, addr))
-#define pmd_clear_fixmap() clear_fixmap(FIX_PMD)
 
 #define pud_page(pud)  pfn_to_page(__phys_to_pfn(__pud_to_phys(pud)))
+#define pud_set_fixmap(addr)   ((pud_t *)set_fixmap_offset(FIX_PUD, 
addr))
+#define pud_clear_fixmap() clear_fixmap(FIX_PUD)
 
 /* use ONLY for statically allocated translation tables */
 #define pmd_offset_kimg(dir,addr)  ((pmd_t 
*)__phys_to_kimg(pmd_offset_phys((dir), (addr
@@ -518,11 +521,11 @@ static inline phys_addr_t pud_page_paddr(pud_t pud)
 #else
 
 #define pud_page_paddr(pud)({ BUILD_BUG(); 0; })
+#define pud_set_fixmap(addr)   NULL
+#define pud_clear_fixmap()
 
 /* Match pmd_offset folding in  */
-#define pmd_set_fixmap(addr)   NULL
 #define pmd_set_fixmap_offset(pudp, addr)  ((pmd_t *)pudp)

[PATCH v3 2/5] arm64/mm: Make __enable_mmu() take the ttbr1 page as an argument

2018-07-02 Thread Jun Yao
Make __enable_mmu() take the physical address of the ttbr1 page as
an argument.

Signed-off-by: Jun Yao 
---
 arch/arm64/kernel/head.S  | 5 -
 arch/arm64/kernel/sleep.S | 1 +
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/kernel/head.S b/arch/arm64/kernel/head.S
index 3f99c59ba193..a1c7a4d3b9f3 100644
--- a/arch/arm64/kernel/head.S
+++ b/arch/arm64/kernel/head.S
@@ -718,6 +718,7 @@ secondary_startup:
 * Common entry point for secondary CPUs.
 */
bl  __cpu_setup // initialise processor
+   adrpx26, swapper_pg_dir
bl  __enable_mmu
ldr x8, =__secondary_switched
br  x8
@@ -760,6 +761,7 @@ ENDPROC(__secondary_switched)
  * Enable the MMU.
  *
  *  x0  = SCTLR_EL1 value for turning on the MMU.
+ *  x26 = TTBR1_EL1 value for turning on the MMU.
  *
  * Returns to the caller via x30/lr. This requires the caller to be covered
  * by the .idmap.text section.
@@ -774,7 +776,7 @@ ENTRY(__enable_mmu)
b.ne__no_granule_support
update_early_cpu_boot_status 0, x1, x2
adrpx1, idmap_pg_dir
-   adrpx2, swapper_pg_dir
+   mov x2, x26
phys_to_ttbr x3, x1
phys_to_ttbr x4, x2
msr ttbr0_el1, x3   // load TTBR0
@@ -835,6 +837,7 @@ __primary_switch:
mrs x20, sctlr_el1  // preserve old SCTLR_EL1 value
 #endif
 
+   adrpx26, swapper_pg_dir
bl  __enable_mmu
 #ifdef CONFIG_RELOCATABLE
bl  __relocate_kernel
diff --git a/arch/arm64/kernel/sleep.S b/arch/arm64/kernel/sleep.S
index bebec8ef9372..3f2c7bf67a2c 100644
--- a/arch/arm64/kernel/sleep.S
+++ b/arch/arm64/kernel/sleep.S
@@ -101,6 +101,7 @@ ENTRY(cpu_resume)
bl  el2_setup   // if in EL2 drop to EL1 cleanly
bl  __cpu_setup
/* enable the MMU early - so we can access sleep_save_stash by va */
+   adrpx26, swapper_pg_dir
bl  __enable_mmu
ldr x8, =_cpu_resume
br  x8
-- 
2.17.1



[PATCH v2] modsign: log module name in the event of an error

2018-07-02 Thread Jessica Yu
Now that we have the load_info struct all initialized (including
info->name, which contains the name of the module) before
module_sig_check(), make the load_info struct and hence module name
available to mod_verify_sig() so that we can log the module name in the
event of an error.

Signed-off-by: Jessica Yu 
---
v2:
 - remove _modlen argument and just use the passed info struct

 kernel/module-internal.h | 25 -
 kernel/module.c  | 22 +-
 kernel/module_signing.c  | 12 +++-
 3 files changed, 32 insertions(+), 27 deletions(-)

diff --git a/kernel/module-internal.h b/kernel/module-internal.h
index 915e123a430f..79c9be2dbbe9 100644
--- a/kernel/module-internal.h
+++ b/kernel/module-internal.h
@@ -9,4 +9,27 @@
  * 2 of the Licence, or (at your option) any later version.
  */
 
-extern int mod_verify_sig(const void *mod, unsigned long *_modlen);
+#include 
+#include 
+
+struct load_info {
+   const char *name;
+   /* pointer to module in temporary copy, freed at end of load_module() */
+   struct module *mod;
+   Elf_Ehdr *hdr;
+   unsigned long len;
+   Elf_Shdr *sechdrs;
+   char *secstrings, *strtab;
+   unsigned long symoffs, stroffs;
+   struct _ddebug *debug;
+   unsigned int num_debug;
+   bool sig_ok;
+#ifdef CONFIG_KALLSYMS
+   unsigned long mod_kallsyms_init_off;
+#endif
+   struct {
+   unsigned int sym, str, mod, vers, info, pcpu;
+   } index;
+};
+
+extern int mod_verify_sig(const void *mod, struct load_info *info);
diff --git a/kernel/module.c b/kernel/module.c
index ba45a84e4287..8a45986fd728 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -307,26 +307,6 @@ int unregister_module_notifier(struct notifier_block *nb)
 }
 EXPORT_SYMBOL(unregister_module_notifier);
 
-struct load_info {
-   const char *name;
-   /* pointer to module in temporary copy, freed at end of load_module() */
-   struct module *mod;
-   Elf_Ehdr *hdr;
-   unsigned long len;
-   Elf_Shdr *sechdrs;
-   char *secstrings, *strtab;
-   unsigned long symoffs, stroffs;
-   struct _ddebug *debug;
-   unsigned int num_debug;
-   bool sig_ok;
-#ifdef CONFIG_KALLSYMS
-   unsigned long mod_kallsyms_init_off;
-#endif
-   struct {
-   unsigned int sym, str, mod, vers, info, pcpu;
-   } index;
-};
-
 /*
  * We require a truly strong try_module_get(): 0 means success.
  * Otherwise an error is returned due to ongoing or failed
@@ -2778,7 +2758,7 @@ static int module_sig_check(struct load_info *info, int 
flags)
memcmp(mod + info->len - markerlen, MODULE_SIG_STRING, markerlen) 
== 0) {
/* We truncate the module to discard the signature */
info->len -= markerlen;
-   err = mod_verify_sig(mod, >len);
+   err = mod_verify_sig(mod, info);
}
 
if (!err) {
diff --git a/kernel/module_signing.c b/kernel/module_signing.c
index 937c844bee4a..f2075ce8e4b3 100644
--- a/kernel/module_signing.c
+++ b/kernel/module_signing.c
@@ -45,10 +45,10 @@ struct module_signature {
 /*
  * Verify the signature on a module.
  */
-int mod_verify_sig(const void *mod, unsigned long *_modlen)
+int mod_verify_sig(const void *mod, struct load_info *info)
 {
struct module_signature ms;
-   size_t modlen = *_modlen, sig_len;
+   size_t sig_len, modlen = info->len;
 
pr_devel("==>%s(,%zu)\n", __func__, modlen);
 
@@ -62,10 +62,11 @@ int mod_verify_sig(const void *mod, unsigned long *_modlen)
if (sig_len >= modlen)
return -EBADMSG;
modlen -= sig_len;
-   *_modlen = modlen;
+   info->len = modlen;
 
if (ms.id_type != PKEY_ID_PKCS7) {
-   pr_err("Module is not signed with expected PKCS#7 message\n");
+   pr_err("%s: Module is not signed with expected PKCS#7 
message\n",
+  info->name);
return -ENOPKG;
}
 
@@ -76,7 +77,8 @@ int mod_verify_sig(const void *mod, unsigned long *_modlen)
ms.__pad[0] != 0 ||
ms.__pad[1] != 0 ||
ms.__pad[2] != 0) {
-   pr_err("PKCS#7 signature info has unexpected non-zero 
params\n");
+   pr_err("%s: PKCS#7 signature info has unexpected non-zero 
params\n",
+  info->name);
return -EBADMSG;
}
 
-- 
2.16.4



Re: hrtimer become inaccurate with RT patch

2018-07-02 Thread gengdongjiu
Hi Sebastian ,
   Thanks for the answer.

On 2018/7/2 18:14, Sebastian Andrzej Siewior wrote:
> On 2018-07-02 17:34:34 [+0800], gengdongjiu wrote:
>>   The Linux kernel version is v4.1.46, and the preempt_rt patch is
>> patch-4.1.46-rt52.patch.
> 
> the 4.1 series is no longer supported (neither RT wise nor non-RT,
> https://www.kernel.org/category/releases.html). I suggest to move away.
> If you notice this problem now it is hardly a long running project.
yes, I Know, but we found the latest RT 4.14 series also has the same problem,
so this is common issue.

> 
>> process will not be interrupt. But if the hrtimer is also runs in
>> process context the timer is useless when it's inaccurate. so I want to
>> consult you whether this is expected behavior? whether is reasonable to move 
>> the timer IRQ
>> handling to a thread?
> 
> This depends on your expectations. The timer is defined not to fire
> before the programmed time. So it fires as soon as possible _after_ the
> programmed time.
It is reasonable that the timer is defined not to fire before the programmed 
time.
but we found it fires long _after_ the programmed time. For example, we define 
it to
fire after 2s, but it will fire after 5s, so it is very later than the 
expectations. I think the reason may be
that the timer handler thread is preempted by another higher priority thread. 
so from for this issue,
the timer handler should be in IRQ context instead of the process context or 
increase the timer handler thread priority, right?

> 
>> I think this is why hrtimer is run as a thread, I tried to set
>> hrtimer.irqsafe to 1, but the timer still seemed not right. Could anyone
>> give some advise? Thanks.
> 
> By setting irqsafe to 1 you ensure taht the timer will fire from the
> timer interrupt and before doing so you should ensure that the timer is
> indeed IRQ safe.
> Depending on what you do it is possible that the timer fires early but
> the application notices it later (the scheduler will first handle RT
> tasks according to their priorities followed by non RT tasks).

(I will continue check this comments, thanks)

> 
> Sebastian
> 
> .
> 



Re: [PATCH] mm: be more informative in OOM task list

2018-07-02 Thread Rodrigo Freire
Hello Michal,

- Original Message - 
> From: "Michal Hocko" 
> To: "Rodrigo Freire" 
> Cc: linux...@kvack.org, linux-kernel@vger.kernel.org
> Sent: Monday, July 2, 2018 6:30:43 AM
> Subject: Re: [PATCH] mm: be more informative in OOM task list
>
> On Sun 01-07-18 13:09:40, Rodrigo Freire wrote:
> > The default page memory unit of OOM task dump events might not be
> > intuitive for the non-initiated when debugging OOM events. Add
> > a small printk prior to the task dump informing that the memory
> > units are actually memory _pages_.
>
> Does this really help? I understand the the oom report might be not the
> easiest thing to grasp but wouldn't it be much better to actually add
> documentation with clarification of each part of it?

That would be great: After a quick grep -ri for oom in Documentation,
I found several other files containing its own OOM behaviour modifier
configurations. But it indeed lacks a central and canonical Doc file
which documents the OOM Killer behavior and workflows.

However, I still stand by my proposed patch: It is unobtrusive, infers
no performance issue and clarifying: I recently worked in a case (for
full disclosure: I am a far cry from a MM expert) where the sum of the
RSS pages made sense when interpreted as real kB pages. Reason: There
were processes sharing (a good amount of) memory regions, misleading
the interpretation and that misled not only me, but some other
colleagues a well: The pages was only sorted out after actually
inspecting the source code.

This patch is user-friendly and can be a great time saver to others in
the community.

I kindly request the ACKed-by ;-)

Have a great week,

- RF.


  1   2   3   4   5   6   7   8   9   10   >