Re: [PATCH] locking: Remove an insn from spin and write locks

[Waiman Long]

On 08/20/2018 11:06 AM, Matthew Wilcox wrote:
> Both spin locks and write locks currently do:
>
>  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
>  85 c0   test   %eax,%eax
>  75 05   jne[slowpath]
>
> This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
> appropriately.  Peter pointed out that using atomic_try_cmpxchg()
> will let the compiler know this is true.  Comparing before/after
> disassemblies show the only effect is to remove this insn.
>
> Suggested-by: Peter Zijlstra 
> Signed-off-by: Matthew Wilcox 
> ---
>  include/asm-generic/qrwlock.h   | 6 +++---
>  include/asm-generic/qspinlock.h | 9 +
>  2 files changed, 8 insertions(+), 7 deletions(-)
>
> diff --git a/include/asm-generic/qrwlock.h b/include/asm-generic/qrwlock.h
> index 0f7062bd55e5..9a1beb7ad0de 100644
> --- a/include/asm-generic/qrwlock.h
> +++ b/include/asm-generic/qrwlock.h
> @@ -71,8 +71,7 @@ static inline int queued_write_trylock(struct qrwlock *lock)
>   if (unlikely(cnts))
>   return 0;
>  
> - return likely(atomic_cmpxchg_acquire(>cnts,
> -  cnts, cnts | _QW_LOCKED) == cnts);
> + return likely(atomic_try_cmpxchg(>cnts, , _QW_LOCKED));
>  }
>  /**
>   * queued_read_lock - acquire read lock of a queue rwlock
> @@ -96,8 +95,9 @@ static inline void queued_read_lock(struct qrwlock *lock)
>   */
>  static inline void queued_write_lock(struct qrwlock *lock)
>  {
> + u32 cnts = 0;
>   /* Optimize for the unfair lock case where the fair flag is 0. */
> - if (atomic_cmpxchg_acquire(>cnts, 0, _QW_LOCKED) == 0)
> + if (atomic_try_cmpxchg_acquire(>cnts, , _QW_LOCKED))
>   return;
>  
>   queued_write_lock_slowpath(lock);
> diff --git a/include/asm-generic/qspinlock.h b/include/asm-generic/qspinlock.h
> index 95263e943fcc..d125f0c0b3d9 100644
> --- a/include/asm-generic/qspinlock.h
> +++ b/include/asm-generic/qspinlock.h
> @@ -68,8 +68,10 @@ int queued_spin_is_contended(const struct qspinlock *lock)
>   */
>  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
>  {
> + u32 val = 0;
> +
>   if (!atomic_read(>val) &&
> -(atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL) == 0))
> + (atomic_try_cmpxchg(>val, , _Q_LOCKED_VAL)))

Should you keep the _acquire suffix?

>   return 1;
>   return 0;
>  }
> @@ -82,10 +84,9 @@ extern void queued_spin_lock_slowpath(struct qspinlock 
> *lock, u32 val);
>   */
>  static __always_inline void queued_spin_lock(struct qspinlock *lock)
>  {
> - u32 val;
> + u32 val = 0;
>  
> - val = atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL);
> - if (likely(val == 0))
> + if (likely(atomic_try_cmpxchg(>val, , _Q_LOCKED_VAL)))
>   return;
>   queued_spin_lock_slowpath(lock, val);
>  }

Ditto.

BTW, qspinlock and qrwlock are now also used by AArch64, mips and sparc.
Have you tried to see what the effect will be for those architecture?

-Longman

Re: [PATCH 1/2] x86: apm: mark proc_apm_show as __maybe_unused

[Thomas Gleixner]

On Tue, 14 Aug 2018, Arnd Bergmann wrote:

> A new build error appeared with CONFIG_PROC_FS disabled:
> 
> arch/x86/kernel/apm_32.c:1643:12: error: 'proc_apm_show' defined but not used 
> [-Werror=unused-function]
> 
> This marks the function as __maybe_unused to let the compiler drop
> it silently.
>
> Fixes: 3f3942aca6da ("proc: introduce proc_create_single{,_data}")

The proper fix for this is to convert the stub function for proc_apm_show()
to an inline. The compiler complains because the stub is a macro 

Thanks,

tglx

Re: [PATCH] workqueue: fix memory leak in wq_numa_init()

[Tejun Heo]

On Mon, Aug 20, 2018 at 12:05:50PM +0800, wang.y...@zte.com.cn wrote:
> Gentle ping :)
> 
> > The 'tbl' variable may leak when return in function
> > wq_numa_init(), and this patch fixes this.
> >
> > Signed-off-by: Yi Wang 
> > Reviewed-by: Jiang Biao 

It's a kernel bug path where we might as well crash.  Whether the tbl
gets leaked or not doesn't matter.

Thanks.

-- 
tejun

[PATCH 0/2] drm: rcar-du: Add interlaced feature support flag

[Kieran Bingham]

The R-Car DU on the D3 and E3 does not support interlaced pipelines,
thus we need to have a means to reject interlaced configurations on
those platoforms.

Provide a new feature flag, and add that flag to all existing devices
which currently support interlaced pipelines.

When D3 and E3 support is added, this feature flag shall be ommited.



Kieran Bingham (2):
  drm: rcar-du: Refactor Feature and Quirk definitions
  drm: rcar-du: Add interlaced feature flag

 drivers/gpu/drm/rcar-du/rcar_du_crtc.c | 14 +++
 drivers/gpu/drm/rcar-du/rcar_du_drv.c  | 32 +-
 drivers/gpu/drm/rcar-du/rcar_du_drv.h  |  9 
 3 files changed, 40 insertions(+), 15 deletions(-)

-- 
2.17.1

Re: Build failures with gcc 4.5 and older

[Arnd Bergmann]

On Mon, Aug 20, 2018 at 4:58 PM Thomas Gleixner  wrote:
>
> On Tue, 14 Aug 2018, Guenter Roeck wrote:
> >
> > For my part I am all for making gcc 4.6 mandatory.
>
> No objections from my side.

gcc-4.6 is also what I suggested a while ago as a good choice for a new minimum
version, back then I met some objection, but as time passes these probably got
less important:

https://lkml.org/lkml/2016/12/16/174

To recap the distros that I looked at back then using gcc older than
4.6, I found four:

 RHEL6: gcc-4.4
 Debian 6: gcc-4.4
 Ubuntu 10.04: gcc-4.4
 SLES11: gcc-4.3

The first three are all finally EOL as of this month, only SLES11 with gcc-4.3
is still supported in principle:

Service Pack Release FCS Date  General EndsLTSS Ends
SUSE Linux Enterprise Server 11  24 Mar 2009   31 Dec 2010 N/A
SUSE Linux Enterprise Server 11 SP1  02 Jun 2010   31 Aug 2012 30 Aug 2015
SUSE Linux Enterprise Server 11 SP2  29 Feb 2012   31 Jan 2014 30 Jan 2017
SUSE Linux Enterprise Server 11 SP3  01 Jul 2013   31 Jan 2016 30 Jan 2019
SUSE Linux Enterprise Server 11 SP4  15 Jul 2015   31 Mar 2019 31 Mar 2022

However, installing the disro's SDK package on SLES11-SP3 brings it up to
gcc-4.7, or gcc-5.2 for SP4, so this is unlikely to cause much of a problem any
more.

I also have some ideas for cleanups that can be done now, in particular
to deal with compiler warnings.

  Arnd

[tip:x86/urgent] x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit

[tip-bot for Vlastimil Babka]

Commit-ID:  9df9516940a61d29aedf4d91b483ca6597e7d480
Gitweb: https://git.kernel.org/tip/9df9516940a61d29aedf4d91b483ca6597e7d480
Author: Vlastimil Babka 
AuthorDate: Mon, 20 Aug 2018 11:58:35 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 20 Aug 2018 18:04:42 +0200

x86/speculation/l1tf: Fix overflow in l1tf_pfn_limit() on 32bit

On 32bit PAE kernels on 64bit hardware with enough physical bits,
l1tf_pfn_limit() will overflow unsigned long. This in turn affects
max_swapfile_size() and can lead to swapon returning -EINVAL. This has been
observed in a 32bit guest with 42 bits physical address size, where
max_swapfile_size() overflows exactly to 1 << 32, thus zero, and produces
the following warning to dmesg:

[6.396845] Truncating oversized swap area, only using 0k out of 2047996k

Fix this by using unsigned long long instead.

Fixes: 17dbca119312 ("x86/speculation/l1tf: Add sysfs reporting for l1tf")
Fixes: 377eeaa8e11f ("x86/speculation/l1tf: Limit swap file size to MAX_PA/2")
Reported-by: Dominique Leuenberger 
Reported-by: Adrian Schroeter 
Signed-off-by: Vlastimil Babka 
Signed-off-by: Thomas Gleixner 
Acked-by: Andi Kleen 
Acked-by: Michal Hocko 
Cc: "H . Peter Anvin" 
Cc: Linus Torvalds 
Cc: Dave Hansen 
Cc: Michal Hocko 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20180820095835.5298-1-vba...@suse.cz

---
 arch/x86/include/asm/processor.h | 4 ++--
 arch/x86/mm/init.c   | 4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/processor.h b/arch/x86/include/asm/processor.h
index 682286aca881..a0a52274cb4a 100644
--- a/arch/x86/include/asm/processor.h
+++ b/arch/x86/include/asm/processor.h
@@ -181,9 +181,9 @@ extern const struct seq_operations cpuinfo_op;
 
 extern void cpu_detect(struct cpuinfo_x86 *c);
 
-static inline unsigned long l1tf_pfn_limit(void)
+static inline unsigned long long l1tf_pfn_limit(void)
 {
-   return BIT(boot_cpu_data.x86_phys_bits - 1 - PAGE_SHIFT) - 1;
+   return BIT_ULL(boot_cpu_data.x86_phys_bits - 1 - PAGE_SHIFT) - 1;
 }
 
 extern void early_cpu_init(void);
diff --git a/arch/x86/mm/init.c b/arch/x86/mm/init.c
index acfab322fbe0..02de3d6065c4 100644
--- a/arch/x86/mm/init.c
+++ b/arch/x86/mm/init.c
@@ -923,7 +923,7 @@ unsigned long max_swapfile_size(void)
 
if (boot_cpu_has_bug(X86_BUG_L1TF)) {
/* Limit the swap file size to MAX_PA/2 for L1TF workaround */
-   unsigned long l1tf_limit = l1tf_pfn_limit() + 1;
+   unsigned long long l1tf_limit = l1tf_pfn_limit() + 1;
/*
 * We encode swap offsets also with 3 bits below those for pfn
 * which makes the usable limit higher.
@@ -931,7 +931,7 @@ unsigned long max_swapfile_size(void)
 #if CONFIG_PGTABLE_LEVELS > 2
l1tf_limit <<= PAGE_SHIFT - SWP_OFFSET_FIRST_BIT;
 #endif
-   pages = min_t(unsigned long, l1tf_limit, pages);
+   pages = min_t(unsigned long long, l1tf_limit, pages);
}
return pages;
 }

Re: libtracevent build warnings on Clear Linux (gcc 8.2.0)

[Arnaldo Carvalho de Melo]

Em Mon, Aug 20, 2018 at 08:53:05AM -0700, Thiago Macieira escreveu:
> On Monday, 20 August 2018 06:39:43 PDT Arnaldo Carvalho de Melo wrote:
> > Hi guys,
> 
> Hello
> 
> > Makefile.config:318: No libelf found. Disables 'probe' tool, jvmti and BPF
> > support in 'perf record'. Please install libelf-dev, libelf-devel or
> > elfutils-libelf-devel
> 
> You may want to install the user-basic-dev bundle.

Thanks, I'll add that one
 
> > Makefile.config:518: Disabling post unwind, no support found.
> 
> Also present in user-basic-dev.
> 
> > Makefile.config:598: slang not found, disables TUI support. Please install
> > slang-devel, libslang-dev or libslang2-dev
> 
> Ditto.
> 
> > Makefile.config:612: GTK2 not found, disables GTK2 support. Please install
> > gtk2-devel or libgtk2.0-dev
> 
> This one is in desktop-dev. We don't have that enabled in our own build of 
> perf, though.
> 
> > Makefile.config:666: No python interpreter was found: disables Python
> > support - please install python-devel/python-dev
> 
> user-basic-dev too. We're almost rid of Python 2, do you need it?

Nope, patches to make perf build with python3 (while still building with
python2, if that is what is available) were already merged, IIRC.
 
> > Makefile.config:750: No liblzma found, disables xz kernel module
> > decompression, please install xz-devel/liblzma-dev
> 
> Assuming xz is sufficient for this, user-basic-dev.

ok
 
> > Makefile.config:814: No libbabeltrace found, disables 'perf data' CTF format
> > support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev
> 
> user-basic-dev too.

Cool, now the avx2 thingy.

- Arnaldo

Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

[Thomas Gleixner]

On Mon, 20 Aug 2018, Jim Mattson wrote:
> On Mon, Aug 20, 2018 at 9:00 AM, Thomas Gleixner  wrote:
> >
> > On Tue, 7 Aug 2018, Jim Mattson wrote:
> >
> > > Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> > > conditions. On hardware, platform vulnerability can be determined
> > > simply by checking the processor's DisplayModel/DisplayFamily
> > > signature.  However, when running in a VM, the operating system should
> > > also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> > > can be set by a hypervisor to indicate that the VM might run on a
> > > vulnerable physical processor, regardless of the
> > > DisplayModel/DisplayFamily reported by CPUID.
> > >
> > > Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> > > hardware, so the DisplayModel/DisplayFamily check is still required.
> > >
> > > For all of the details, see the Intel white paper, "Retpoline: A
> > > Branch Target Injection Mitigation" (document number 337131-001),
> > > section 5.3: Virtual Machine CPU Identification.
> > >
> > > Signed-off-by: Jim Mattson 
> > > Reviewed-by: Peter Shier 
> >
> > That has been superseeded by:
> >
> >   fdf82a7856b3 ("x86/speculation: Protect against userspace-userspace 
> > spectreRSB")
> >
> > right? At least it does not apply anymore...
> 
> Right. It doesn't appear that Skylake CPUs get any special treatment any more.

Yeah, it's universally f*cked up by now.

Thanks,

tglx

Re: [PATCH v9 07/22] KVM: s390: refactor crypto initialization

[David Hildenbrand]

On 13.08.2018 23:48, Tony Krowiak wrote:
> From: Tony Krowiak 
> 
> This patch refactors the code that initializes and sets up the
> crypto configuration for a guest. The following changes are
> implemented via this patch:
> 
> 1. Prior to the introduction of AP device virtualization, it
>was not necessary to provide guest access to the CRYCB
>unless the MSA extension 3 (MSAX3) facility was installed
>on the host system. With the introduction of AP device
>virtualization, the CRYCB must be made accessible to the
>guest if the AP instructions are installed on the host
>and are to be provided to the guest.
> 
> 2. Introduces a flag indicating AP instructions executed on
>the guest shall be interpreted by the firmware. It is
>initialized to indicate AP instructions are to be
>to be interpreted and is used to set the SIE bit for
>each vcpu during vcpu setup.
> 
> Signed-off-by: Tony Krowiak 
> Reviewed-by: Halil Pasic 
> Acked-by: Christian Borntraeger 
> Acked-by: Janosch Frank 
> Tested-by: Michael Mueller 
> Tested-by: Farhan Ali 
> Signed-off-by: Christian Borntraeger 
> ---
>  arch/s390/include/asm/kvm_host.h |2 +
>  arch/s390/include/uapi/asm/kvm.h |1 +
>  arch/s390/kvm/kvm-s390.c |   81 
> +++---
>  3 files changed, 44 insertions(+), 40 deletions(-)
> 
> diff --git a/arch/s390/include/asm/kvm_host.h 
> b/arch/s390/include/asm/kvm_host.h
> index af39561..4a739d4 100644
> --- a/arch/s390/include/asm/kvm_host.h
> +++ b/arch/s390/include/asm/kvm_host.h
> @@ -187,6 +187,7 @@ struct kvm_s390_sie_block {
>  #define ECA_AIV  0x0020
>  #define ECA_VX   0x0002
>  #define ECA_PROTEXCI 0x2000
> +#define ECA_APIE 0x0008
>  #define ECA_SII  0x0001
>   __u32   eca;/* 0x004c */
>  #define ICPT_INST0x04
> @@ -256,6 +257,7 @@ struct kvm_s390_sie_block {
>   __u8reservede4[4];  /* 0x00e4 */
>   __u64   tecmc;  /* 0x00e8 */
>   __u8reservedf0[12]; /* 0x00f0 */
> +#define CRYCB_FORMAT_MASK 0x0003
>  #define CRYCB_FORMAT1 0x0001
>  #define CRYCB_FORMAT2 0x0003
>   __u32   crycbd; /* 0x00fc */
> diff --git a/arch/s390/include/uapi/asm/kvm.h 
> b/arch/s390/include/uapi/asm/kvm.h
> index 4cdaa55..a580dec 100644
> --- a/arch/s390/include/uapi/asm/kvm.h
> +++ b/arch/s390/include/uapi/asm/kvm.h
> @@ -130,6 +130,7 @@ struct kvm_s390_vm_cpu_machine {
>  #define KVM_S390_VM_CPU_FEAT_PFMFI   11
>  #define KVM_S390_VM_CPU_FEAT_SIGPIF  12
>  #define KVM_S390_VM_CPU_FEAT_KSS 13
> +#define KVM_S390_VM_CPU_FEAT_AP  14
>  struct kvm_s390_vm_cpu_feat {
>   __u64 feat[16];
>  };
> diff --git a/arch/s390/kvm/kvm-s390.c b/arch/s390/kvm/kvm-s390.c
> index 19f4f44..f7de123 100644
> --- a/arch/s390/kvm/kvm-s390.c
> +++ b/arch/s390/kvm/kvm-s390.c
> @@ -40,6 +40,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include "kvm-s390.h"
>  #include "gaccess.h"
>  
> @@ -1881,49 +1882,37 @@ long kvm_arch_vm_ioctl(struct file *filp,
>   return r;
>  }
>  
> -static int kvm_s390_query_ap_config(u8 *config)
> -{
> - u32 fcn_code = 0x0400UL;
> - u32 cc = 0;
> -
> - memset(config, 0, 128);
> - asm volatile(
> - "lgr 0,%1\n"
> - "lgr 2,%2\n"
> - ".long 0xb2af\n"/* PQAP(QCI) */
> - "0: ipm %0\n"
> - "srl %0,28\n"
> - "1:\n"
> - EX_TABLE(0b, 1b)
> - : "+r" (cc)
> - : "r" (fcn_code), "r" (config)
> - : "cc", "0", "2", "memory"
> - );
> -
> - return cc;
> -}
> -
>  static int kvm_s390_apxa_installed(void)
>  {
> - u8 config[128];
> - int cc;
> + struct ap_config_info info;
>  
> - if (test_facility(12)) {
> - cc = kvm_s390_query_ap_config(config);
> -
> - if (cc)
> - pr_err("PQAP(QCI) failed with cc=%d", cc);
> - else
> - return config[0] & 0x40;
> + if (ap_instructions_available()) {
> + if (ap_qci() == 0)
> + return info.apxa;
>   }
>  
>   return 0;
>  }
>  
> +/*
> + * The format of the crypto control block (CRYCB) is specified in the 3 low
> + * order bits of the CRYCB designation (CRYCBD) field as follows:
> + * Format 0: Neither the message security assist extension 3 (MSAX3) nor the
> + *AP extended addressing (APXA) facility are installed.
> + * Format 1: The APXA facility is not installed but the MSAX3 facility is.
> + * Format 2: Both the APXA and MSAX3 facilities are installed
> + */
>  static void kvm_s390_set_crycb_format(struct kvm *kvm)
>  {
>   kvm->arch.crypto.crycbd = (__u32)(unsigned long) kvm->arch.crypto.crycb;
>  
> + /* Clear the CRYCB format bits - i.e., set format 0 by default */
> + kvm->arch.crypto.crycbd &= ~(CRYCB_FORMAT_MASK);
> +

Re: [PATCH v9 0/4] Uprobes: Support SDT markers having reference count (semaphore)

[Song Liu]

I am testing the patch set with the following code:

#include 
#include 

volatile short semaphore = 0;

int for_uprobe(int c)
{
printf("%d\n", c + 10);
return c + 1;
}

int main(int argc, char *argv[])
{
for_uprobe(argc);
while (1) {
sleep(1);
printf("semaphore %d\n", semaphore);
}
}

I created a uprobe on function for_uprobe(), that uses semaphore as
reference counter:

  echo "p:uprobe_1 /root/a.out:0x49a(0x1036)" >> uprobe_events

I found that if I start a.out before enabling the uprobe, the output
of a.out is like:

root@virt-test:~# ~/a.out
11
semaphore 0
semaphore 0
semaphore 2  <<<  when the uprobe is enabled
semaphore 2
semaphore 2
semaphore 2
semaphore 2
semaphore 0 <<< when the uprobe is disabled
semaphore 0
semaphore 0

I am not quite sure whether the value should be 1 or 2, but it works.

However, if I start a.out AFTER enabling the uprobe, there is something wrong:

root@virt-test:~# ~/a.out
11
semaphore 0   <<< this should be non-zero, as the uprobe is already enabled
semaphore 0
semaphore 0
semaphore 0
semaphore 0   <<< disabling the uprobe, the value is still 0,
<<<  get warning "ref_ctr going negative"
at the same time
semaphore 0
semaphore 0
semaphore 1   <<< enable uprobe again, getting 1 this time
semaphore 1
semaphore 1

I haven't spent much time debugging this, but I guess there is
something wrong on the mmap path?

Thanks,
Song

On Sun, Aug 19, 2018 at 9:42 PM, Ravi Bangoria
 wrote:
> v8 -> v9:
>  - Rebased to rostedt/for-next (Commit bb730b5833b5 to be precise)
>  - Not including first two patches now. They are already pulled by
>Steven.
>  - Change delayed_uprobe_remove() function as suggested by Oleg
>  - Dump inode, offset, ref_ctr_offset, mm etc if we fail to update
>reference counter.
>  - Rename delayed_uprobe_install() to delayed_ref_ctr_inc()
>  - Use 'short d' (delta) in update_ref_ctr() in place of 'bool
>is_register'.
>
> v8: https://lkml.org/lkml/2018/8/9/81
>
> Future work:
>  - Optimize uprobe_mmap()->delayed_ref_ctr_inc() by making
>delayed_uprobe_list per mm.
>
> Description:
> Userspace Statically Defined Tracepoints[1] are dtrace style markers
> inside userspace applications. Applications like PostgreSQL, MySQL,
> Pthread, Perl, Python, Java, Ruby, Node.js, libvirt, QEMU, glib etc
> have these markers embedded in them. These markers are added by developer
> at important places in the code. Each marker source expands to a single
> nop instruction in the compiled code but there may be additional
> overhead for computing the marker arguments which expands to couple of
> instructions. In case the overhead is more, execution of it can be
> omitted by runtime if() condition when no one is tracing on the marker:
>
> if (reference_counter > 0) {
> Execute marker instructions;
> }
>
> Default value of reference counter is 0. Tracer has to increment the
> reference counter before tracing on a marker and decrement it when
> done with the tracing.
>
> Currently, perf tool has limited supports for SDT markers. I.e. it
> can not trace markers surrounded by reference counter. Also, it's
> not easy to add reference counter logic in userspace tool like perf,
> so basic idea for this patchset is to add reference counter logic in
> the a uprobe infrastructure. Ex,[2]
>
>   # cat tick.c
> ...
> for (i = 0; i < 100; i++) {
> DTRACE_PROBE1(tick, loop1, i);
> if (TICK_LOOP2_ENABLED()) {
> DTRACE_PROBE1(tick, loop2, i);
> }
> printf("hi: %d\n", i);
> sleep(1);
> }
> ...
>
> Here tick:loop1 is marker without reference counter where as tick:loop2
> is surrounded by reference counter condition.
>
>   # perf buildid-cache --add /tmp/tick
>   # perf probe sdt_tick:loop1
>   # perf probe sdt_tick:loop2
>
>   # perf stat -e sdt_tick:loop1,sdt_tick:loop2 -- /tmp/tick
>   hi: 0
>   hi: 1
>   hi: 2
>   ^C
>   Performance counter stats for '/tmp/tick':
>  3  sdt_tick:loop1
>  0  sdt_tick:loop2
>  2.747086086 seconds time elapsed
>
> Perf failed to record data for tick:loop2. Same experiment with this
> patch series:
>
>   # ./perf buildid-cache --add /tmp/tick
>   # ./perf probe sdt_tick:loop2
>   # ./perf stat -e sdt_tick:loop2 /tmp/tick
> hi: 0
> hi: 1
> hi: 2
> ^C
>  Performance counter stats for '/tmp/tick':
>  3  sdt_tick:loop2
>2.561851452 seconds time elapsed
>
> [1] https://sourceware.org/systemtap/wiki/UserSpaceProbeImplementation
> [2] https://github.com/iovisor/bcc/issues/327#issuecomment-200576506
>
> Ravi Bangoria (4):
>   Uprobes: Support SDT markers having reference count (semaphore)
>   Uprobes/sdt: Prevent multiple reference counter for same uprobe
>   trace_uprobe/sdt: Prevent multiple reference counter for same uprobe
>   perf probe: Support SDT markers having reference counter 

Re: [PATCH] mm: introduce kvvirt_to_page() helper

[Matthew Wilcox]

On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > +++ b/fs/xfs/xfs_buf.c
> > for (i = 0; i < bp->b_page_count; i++) {
> > -   bp->b_pages[i] = mem_to_page((void *)pageaddr);
> > +   bp->b_pages[i] = kvvirt_to_page((void *)pageaddr);
> > pageaddr += PAGE_SIZE;

This wants mem_range_to_page_array().

> > +++ b/net/9p/trans_virtio.c
> > for (index = 0; index < nr_pages; index++) {
> > -   if (is_vmalloc_addr(p))
> > -   (*pages)[index] = vmalloc_to_page(p);
> > -   else
> > -   (*pages)[index] = kmap_to_page(p);
> > +   (*pages)[index] = kvvirt_to_page(p);

Also mem_range_to_page_array().

> > +++ b/net/ceph/crypto.c
> > @@ -191,11 +191,7 @@ static int setup_sgtable(struct sg_table *sgt, struct 
> > scatterlist *prealloc_sg,
> > struct page *page;
> > unsigned int len = min(chunk_len - off, buf_len);
> >  
> > -   if (is_vmalloc)
> > -   page = vmalloc_to_page(buf);
> > -   else
> > -   page = virt_to_page(buf);
> > -
> > +   page = kvvirt_to_page(buf);
> > sg_set_page(sg, page, len, off);
> >  
> > off = 0;

This whole function wants to move into the core and be called something like
sg_alloc_table_from_virt().

> > +++ b/net/packet/af_packet.c
> > @@ -374,15 +367,15 @@ static void __packet_set_status(struct packet_sock 
> > *po, void *frame, int status)
> > switch (po->tp_version) {
> > case TPACKET_V1:
> > h.h1->tp_status = status;
> > -   flush_dcache_page(pgv_to_page(>tp_status));
> > +   flush_dcache_page(kvvirt_to_page(>tp_status));

This driver really wants flush_dcache_range(start, len).

[no subject]

[Alex Feinman]

Good morning.
I have a custom PCI device that needs to fill memory buffers of up to 16MB
in size. For various reasons I would like to avoid implementing
scatter-gather support in the device and would much rather prefer a
contiguous buffer view instead. The buffers are allocated using
dma_alloc_coherent or dma_alloc_attrs (as I don't necessarily need coherent
access)

This is on a custom Skylake/Kaby Lake platform

It is my understanding (possibly incorrect) that
a) The contiguous memory space available to subsystems like
videobuf2-dma-contig is limited and I won't be likely to be able tp
allocate say 4 16MB contiguous buffers reliably
b) IOMMU can solve this problem for me by providing a device-specific
contiguous view of a fragmented physical memory allocation
c) In order to enable IOMMU do the above, I need to allocate DRHDs and
DMARs in BIOS initialization (I build my own BIOS)

Please, let me know if I am on the right track? Of course I realize that
implementing SGDMA would be the best option, but short of that and blocking
out some physical memory on boot, what are my options?

Are there any pointers of how exactly achieve this (implementation I could
peruse, articles and whatnot)?

Best regards
Alex Feinman

[PATCH] x86, asm: Use CC_SET()/CC_OUT() for __cmpxchg_double

[Uros Bizjak]

Remove open-coded uses of set instructions to use CC_SET()/CC_OUT() for 
__cmpxchg_double.

Signed-off-by: Uros Bizjak 
---
 arch/x86/include/asm/cmpxchg.h | 10 ++
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/arch/x86/include/asm/cmpxchg.h b/arch/x86/include/asm/cmpxchg.h
index a55d79b233d3..bfb85e5844ab 100644
--- a/arch/x86/include/asm/cmpxchg.h
+++ b/arch/x86/include/asm/cmpxchg.h
@@ -242,10 +242,12 @@ extern void __add_wrong_size(void)
BUILD_BUG_ON(sizeof(*(p2)) != sizeof(long));\
VM_BUG_ON((unsigned long)(p1) % (2 * sizeof(long)));\
VM_BUG_ON((unsigned long)((p1) + 1) != (unsigned long)(p2));\
-   asm volatile(pfx "cmpxchg%c4b %2; sete %0"  \
-: "=a" (__ret), "+d" (__old2), \
-  "+m" (*(p1)), "+m" (*(p2))   \
-: "i" (2 * sizeof(long)), "a" (__old1),\
+   asm volatile(pfx "cmpxchg%c5b %1"   \
+CC_SET(e)  \
+: CC_OUT(e) (__ret),   \
+  "+m" (*(p1)), "+m" (*(p2)),  \
+  "+a" (__old1), "+d" (__old2) \
+: "i" (2 * sizeof(long)),  \
   "b" (__new1), "c" (__new2)); \
__ret;  \
 })
-- 
2.17.1

[PATCH] kobject: Access kobject name with caution if state is not initialized

[Srikar Dronamraju]

If kobject state is not initialized, then its not even certain that
kobject'name is initialized. Hence when accessing the kobject's name
tread carefully.

A stupid module test like
https://github.com/srikard/tests/blob/master/modules/kobject_test.c
can panic the system.

With patch: We will see the correct warning.

[ 2058.129913] [ cut here ]
[ 2058.129919] kobject: ' ' (ad405b63): is not initialized, yet 
kobject_get() is being called.
[ 2058.129938] WARNING: CPU: 58 PID: 18529 at 
/home/srikar/work/linux.git/lib/kobject.c:620 kobject_get+0x90/0xb0
[ 2058.129946] Modules linked in: kobject_test(OE+) uio_pdrv_genirq(E) uio(E) 
leds_powernv(E) powernv_op_panel(E) ipmi_powernv(E) ipmi_devintf(E) 
powernv_rng(E) ibmpowernv(E) ipmi_msghandler(E) vmx_crypto(E) 
crct10dif_vpmsum(E) sch_fq_codel(E) ip_tables(E) x_tables(E) autofs4(E) ses 
enclosure scsi_transport_sas mlx4_ib mlx4_en ib_core lpfc crc32c_vpmsum 
mlx4_core nvmet_fc nvmet nvme_fc ipr nvme_fabrics devlink scsi_transport_fc tg3 
[last unloaded: module_test]
[ 2058.130014] CPU: 58 PID: 18529 Comm: insmod Tainted: GW  OEL
4.18.0-master+ #3
[ 2058.130022] NIP:  c0d5f530 LR: c0d5f52c CTR: 
[ 2058.130029] REGS: c02fd32f3640 TRAP: 0700   Tainted: GW  OEL 
(4.18.0-master+)
[ 2058.130036] MSR:  92029033   CR: 
48002282  XER: 2000
[ 2058.130054] CFAR: c0114e10 IRQMASK: 0
   GPR00: c0d5f52c c02fd32f38c0 c17bc200 
0057
   GPR04: 0001 107e 92009033 
00f2
   GPR08: 0007 0007 0001 
92001003
   GPR12: 2200 c02e0d00  

   GPR16:  c01e92e0  
0100
   GPR20: 0001 c1662e60 c1662ed8 
c02feb4114a0
   GPR24: 0001 c0dbd438 c1662ea0 
c1662ec0
   GPR28: c02fe5f0cea0 d0001ded03d0 c02fd32f39a0 
c02fd32f39a0
[ 2058.130133] NIP [c0d5f530] kobject_get+0x90/0xb0
[ 2058.130140] LR [c0d5f52c] kobject_get+0x8c/0xb0
[ 2058.130146] Call Trace:
[ 2058.130150] [c02fd32f38c0] [c0d5f52c] kobject_get+0x8c/0xb0 
(unreliable)
[ 2058.130159] [c02fd32f3940] [d0001ded0088] 
kobject_test_init+0x80/0xb0 [kobject_test]
[ 2058.130168] [c02fd32f39f0] [c00101f8] do_one_initcall+0x58/0x240
[ 2058.130178] [c02fd32f3ab0] [c01ef2b0] do_init_module+0x90/0x260
[ 2058.130186] [c02fd32f3b40] [c01edec8] load_module+0x2d88/0x3320
[ 2058.130193] [c02fd32f3d20] [c01ee764] sys_finit_module+0xc4/0x130
[ 2058.130204] [c02fd32f3e30] [c000b288] system_call+0x5c/0x70
[ 2058.130210] Instruction dump:
[ 2058.130215] e89f 4b5b4c15 6000 2f83 419e0030 3c82ff8c 388491e0 
3c62ff90
[ 2058.130228] 7fe5fb78 3863e9b0 4b3b5881 6000 <0fe0> e8010090 7c0803a6 
4b88
[ 2058.130240] ---[ end trace 0f471c192555a013 ]---
[ 2070.084234] kobject_test module unloaded

Signed-off-by: Srikar Dronamraju 
---
 lib/kobject.c | 22 +-
 1 file changed, 17 insertions(+), 5 deletions(-)

diff --git a/lib/kobject.c b/lib/kobject.c
index 389829d3a1d1..2d65be37fd7b 100644
--- a/lib/kobject.c
+++ b/lib/kobject.c
@@ -16,6 +16,7 @@
 #include 
 #include 
 #include 
+#include 
 
 /**
  * kobject_namespace - return @kobj's namespace tag
@@ -417,8 +418,11 @@ int kobject_add(struct kobject *kobj, struct kobject 
*parent,
return -EINVAL;
 
if (!kobj->state_initialized) {
+   char tmp;
+   int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
pr_err("kobject '%s' (%p): tried to add an uninitialized 
object, something is seriously wrong.\n",
-  kobject_name(kobj), kobj);
+   ret ? " " : kobject_name(kobj), kobj);
dump_stack();
return -EINVAL;
}
@@ -606,10 +610,14 @@ EXPORT_SYMBOL(kobject_del);
 struct kobject *kobject_get(struct kobject *kobj)
 {
if (kobj) {
-   if (!kobj->state_initialized)
+   if (!kobj->state_initialized) {
+   char tmp;
+   int ret = probe_kernel_address(kobject_name(kobj), tmp);
+
WARN(1, KERN_WARNING
"kobject: '%s' (%p): is not initialized, yet 
kobject_get() is being called.\n",
-kobject_name(kobj), kobj);
+ret ? " " : kobject_name(kobj), kobj);
+   }
kref_get(>kref);
}
return kobj;
@@ -701,10 +709,14 @@ static void kobject_release(struct kref *kref)
 void kobject_put(struct kobject *kobj)
 {
if (kobj) {
-   

Re: [PATCH v2 01/32] tracing: Allow gcov profiling on only ftrace subsystem

[Steven Rostedt]

On Fri, 17 Aug 2018 01:29:39 +0900
Masami Hiramatsu  wrote:

> Add GCOV_PROFILE_FTRACE to allow gcov profiling
> on only files in ftrace subsystem. This kconfig
> flag will be used for checking kselftest/ftrace

Note, I haven't heard of "kconfig flag" as the terminology. Usually, we
just say "config" or "config option".

> coverage.
> 
> Signed-off-by: Masami Hiramatsu 
> ---
>  kernel/trace/Kconfig  |   13 +
>  kernel/trace/Makefile |5 +
>  2 files changed, 18 insertions(+)
> 
> diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig
> index fd6754b88f87..8decf6d8553a 100644
> --- a/kernel/trace/Kconfig
> +++ b/kernel/trace/Kconfig
> @@ -774,6 +774,19 @@ config TRACING_EVENTS_GPIO
>   help
> Enable tracing events for gpio subsystem
>  
> +config GCOV_PROFILE_FTRACE
> + bool "Enable GCOV profiling on ftrace subsystem"
> + depends on GCOV_KERNEL
> + help
> +   Enable GCOV profiling on ftrace subsystem for checking
> +   which functions/lines are tested.
> +
> +   If unsure, say N.
> +
> +   Note that on a kernel compiled with this flags, ftrace will be
> +   significantly run slower. So do not enable it for production
> +   kernel.


I would rewrite the above as:

Note that on a kernel compiled with this config, ftrace will
run significantly slower.

I think we can leave out the production sentence. It should be obvious
from the "significantly slower" part.

Other than that, it looks fine to me.

-- Steve

> +
>  endif # FTRACE
>  
>  endif # TRACING_SUPPORT
> diff --git a/kernel/trace/Makefile b/kernel/trace/Makefile
> index 98d53b39a8ee..f81dadbc7c4a 100644
> --- a/kernel/trace/Makefile
> +++ b/kernel/trace/Makefile
> @@ -23,6 +23,11 @@ ifdef CONFIG_TRACING_BRANCHES
>  KBUILD_CFLAGS += -DDISABLE_BRANCH_PROFILING
>  endif
>  
> +# for GCOV coverage profiling
> +ifdef CONFIG_GCOV_PROFILE_FTRACE
> +GCOV_PROFILE := y
> +endif
> +
>  CFLAGS_trace_benchmark.o := -I$(src)
>  CFLAGS_trace_events_filter.o := -I$(src)
>  

Re: [PATCH v7 2/8] dt-bindings: Introduce interconnect provider bindings

[Maxime Ripard]

Hi Georgi,

On Tue, Aug 07, 2018 at 05:54:38PM +0300, Georgi Djakov wrote:
> > There is also a patch series from Maxime Ripard that's addressing the
> > same general area. See "dt-bindings: Add a dma-parent property". We
> > don't need multiple ways to address describing the device to memory
> > paths, so you all had better work out a common solution.
> 
> Looks like this fits exactly into the interconnect API concept. I see
> MBUS as interconnect provider and display/camera as consumers, that
> report their bandwidth needs. I am also planning to add support for
> priority.

Thanks for working on this. After looking at your serie, the one thing
I'm a bit uncertain about (and the most important one to us) is how we
would be able to tell through which interconnect the DMA are done.

This is important to us since our topology is actually quite simple as
you've seen, but the RAM is not mapped on that bus and on the CPU's,
so we need to apply an offset to each buffer being DMA'd.

Maxime

-- 
Maxime Ripard, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
https://bootlin.com


signature.asc
Description: PGP signature

Re: libtracevent build warnings on Clear Linux (gcc 8.2.0)

[Thiago Macieira]

On Monday, 20 August 2018 06:39:43 PDT Arnaldo Carvalho de Melo wrote:
> Hi guys,

Hello

> Makefile.config:318: No libelf found. Disables 'probe' tool, jvmti and BPF
> support in 'perf record'. Please install libelf-dev, libelf-devel or
> elfutils-libelf-devel

You may want to install the user-basic-dev bundle.

> Makefile.config:518: Disabling post unwind, no support found.

Also present in user-basic-dev.

> Makefile.config:598: slang not found, disables TUI support. Please install
> slang-devel, libslang-dev or libslang2-dev

Ditto.

> Makefile.config:612: GTK2 not found, disables GTK2 support. Please install
> gtk2-devel or libgtk2.0-dev

This one is in desktop-dev. We don't have that enabled in our own build of 
perf, though.

> Makefile.config:666: No python interpreter was found: disables Python
> support - please install python-devel/python-dev

user-basic-dev too. We're almost rid of Python 2, do you need it?

> Makefile.config:750: No liblzma found, disables xz kernel module
> decompression, please install xz-devel/liblzma-dev

Assuming xz is sufficient for this, user-basic-dev.

> Makefile.config:814: No libbabeltrace found, disables 'perf data' CTF format
> support, please install libbabeltrace-dev[el]/libbabeltrace-ctf-dev

user-basic-dev too.

-- 
Thiago Macieira - thiago.macieira (AT) intel.com
  Software Architect - Intel Open Source Technology Center

[PATCH 21/21] tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem memcpy'

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

To bring in the change made in this cset:

Fixes: a7bea8308933 ("x86/asm/64: Use 32-bit XOR to zero registers")

  CC   /tmp/build/perf/bench/mem-memcpy-x86-64-asm.o
  LD   /tmp/build/perf/bench/perf-in.o
  LD   /tmp/build/perf/perf-in.o
  LINK /tmp/build/perf/perf

Silencing this perf build warning:

  Warning: Kernel ABI header at 'tools/arch/x86/lib/memcpy_64.S' differs from 
latest version at 'arch/x86/lib/memcpy_64.S'
  diff -u tools/arch/x86/lib/memcpy_64.S arch/x86/lib/memcpy_64.S

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jan Beulich 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-sad22dudoz71qr3tsnlqt...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/lib/memcpy_64.S | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/tools/arch/x86/lib/memcpy_64.S b/tools/arch/x86/lib/memcpy_64.S
index 298ef1479240..3b24dc05251c 100644
--- a/tools/arch/x86/lib/memcpy_64.S
+++ b/tools/arch/x86/lib/memcpy_64.S
@@ -256,7 +256,7 @@ ENTRY(__memcpy_mcsafe)
 
/* Copy successful. Return zero */
 .L_done_memcpy_trap:
-   xorq %rax, %rax
+   xorl %eax, %eax
ret
 ENDPROC(__memcpy_mcsafe)
 EXPORT_SYMBOL_GPL(__memcpy_mcsafe)
-- 
2.14.4

[PATCH 20/21] tools arch x86: Update tools's copy of cpufeatures.h

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

To get the changes in the following csets:

  301d328a6f8b ("x86/cpufeatures: Add EPT_AD feature bit")
  706d51681d63 ("x86/speculation: Support Enhanced IBRS on future CPUs")

No tools were affected, copy it to silence this perf tool build warning:

  Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' 
differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
  diff -u tools/arch/x86/include/asm/cpufeatures.h 
arch/x86/include/asm/cpufeatures.h

Cc: Adrian Hunter 
Cc: David Ahern 
Cc: Jiri Olsa 
Cc: Namhyung Kim 
Cc: Peter Feiner 
Cc: Sai Praneeth 
Cc: Thomas Gleixner 
Cc: Wang Nan 
Link: https://lkml.kernel.org/n/tip-bvs8wgd5wp4lz9f0xf1iu...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/arch/x86/include/asm/cpufeatures.h | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/tools/arch/x86/include/asm/cpufeatures.h 
b/tools/arch/x86/include/asm/cpufeatures.h
index 5701f5cecd31..b5c60faf8429 100644
--- a/tools/arch/x86/include/asm/cpufeatures.h
+++ b/tools/arch/x86/include/asm/cpufeatures.h
@@ -219,6 +219,7 @@
 #define X86_FEATURE_IBPB   ( 7*32+26) /* Indirect Branch 
Prediction Barrier */
 #define X86_FEATURE_STIBP  ( 7*32+27) /* Single Thread Indirect 
Branch Predictors */
 #define X86_FEATURE_ZEN( 7*32+28) /* "" CPU is AMD 
family 0x17 (Zen) */
+#define X86_FEATURE_IBRS_ENHANCED  ( 7*32+29) /* Enhanced IBRS */
 
 /* Virtualization flags: Linux defined, word 8 */
 #define X86_FEATURE_TPR_SHADOW ( 8*32+ 0) /* Intel TPR Shadow */
@@ -229,7 +230,7 @@
 
 #define X86_FEATURE_VMMCALL( 8*32+15) /* Prefer VMMCALL to VMCALL 
*/
 #define X86_FEATURE_XENPV  ( 8*32+16) /* "" Xen paravirtual guest 
*/
-
+#define X86_FEATURE_EPT_AD ( 8*32+17) /* Intel Extended Page Table 
access-dirty bit */
 
 /* Intel-defined CPU features, CPUID level 0x0007:0 (EBX), word 9 */
 #define X86_FEATURE_FSGSBASE   ( 9*32+ 0) /* RDFSBASE, WRFSBASE, 
RDGSBASE, WRGSBASE instructions*/
-- 
2.14.4

[PATCH 18/21] perf mmap: Store real cpu number in 'struct perf_mmap'

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Store the real cpu number in 'struct perf_mmap', which will be used by
python interface that allows user to read a particular memory map for
given cpu.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Jaroslav Škarvada 
Cc: Joe Mario 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817114556.28000-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/evlist.c | 2 +-
 tools/perf/util/mmap.c   | 3 ++-
 tools/perf/util/mmap.h   | 3 ++-
 3 files changed, 5 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index e7a4b31a84fb..be440df29615 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -803,7 +803,7 @@ static int perf_evlist__mmap_per_evsel(struct perf_evlist 
*evlist, int idx,
if (*output == -1) {
*output = fd;
 
-   if (perf_mmap__mmap([idx], mp, *output)  < 0)
+   if (perf_mmap__mmap([idx], mp, *output, 
evlist_cpu) < 0)
return -1;
} else {
if (ioctl(fd, PERF_EVENT_IOC_SET_OUTPUT, *output) != 0)
diff --git a/tools/perf/util/mmap.c b/tools/perf/util/mmap.c
index fc832676a798..215f69f41672 100644
--- a/tools/perf/util/mmap.c
+++ b/tools/perf/util/mmap.c
@@ -164,7 +164,7 @@ void perf_mmap__munmap(struct perf_mmap *map)
auxtrace_mmap__munmap(>auxtrace_mmap);
 }
 
-int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd)
+int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int 
cpu)
 {
/*
 * The last one will be done at perf_mmap__consume(), so that we
@@ -191,6 +191,7 @@ int perf_mmap__mmap(struct perf_mmap *map, struct 
mmap_params *mp, int fd)
return -1;
}
map->fd = fd;
+   map->cpu = cpu;
 
if (auxtrace_mmap__mmap(>auxtrace_mmap,
>auxtrace_mp, map->base, fd))
diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
index d82294db1295..05a6d47c7956 100644
--- a/tools/perf/util/mmap.h
+++ b/tools/perf/util/mmap.h
@@ -18,6 +18,7 @@ struct perf_mmap {
void *base;
int  mask;
int  fd;
+   int  cpu;
refcount_t   refcnt;
u64  prev;
u64  start;
@@ -60,7 +61,7 @@ struct mmap_params {
struct auxtrace_mmap_params auxtrace_mp;
 };
 
-int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd);
+int perf_mmap__mmap(struct perf_mmap *map, struct mmap_params *mp, int fd, int 
cpu);
 void perf_mmap__munmap(struct perf_mmap *map);
 
 void perf_mmap__get(struct perf_mmap *map);
-- 
2.14.4

[PATCH 13/21] perf tools: Move the temp file processing into decompress_kmodule

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

We will add a compression check in the following patch and it makes it
easier if the file processing is done in a single place. It also makes
the current code simpler.

The decompress_kmodule function now returns the fd of the uncompressed
file and the file name in the pathname arg, if it's provided.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-10-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 29 -
 1 file changed, 12 insertions(+), 17 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 54bfe1f4762f..cbeecf68 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -250,8 +250,10 @@ bool dso__needs_decompress(struct dso *dso)
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE_COMP;
 }
 
-static int decompress_kmodule(struct dso *dso, const char *name, char *tmpbuf)
+static int decompress_kmodule(struct dso *dso, const char *name,
+ char *pathname, size_t len)
 {
+   char tmpbuf[] = KMOD_DECOMP_NAME;
int fd = -1;
 
if (!dso__needs_decompress(dso))
@@ -272,34 +274,27 @@ static int decompress_kmodule(struct dso *dso, const char 
*name, char *tmpbuf)
fd = -1;
}
 
+   if (!pathname || (fd < 0))
+   unlink(tmpbuf);
+
+   if (pathname && (fd >= 0))
+   strncpy(pathname, tmpbuf, len);
+
return fd;
 }
 
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name)
 {
-   char tmpbuf[] = KMOD_DECOMP_NAME;
-   int fd;
-
-   fd = decompress_kmodule(dso, name, tmpbuf);
-   unlink(tmpbuf);
-   return fd;
+   return decompress_kmodule(dso, name, NULL, 0);
 }
 
 int dso__decompress_kmodule_path(struct dso *dso, const char *name,
 char *pathname, size_t len)
 {
-   char tmpbuf[] = KMOD_DECOMP_NAME;
-   int fd;
-
-   fd = decompress_kmodule(dso, name, tmpbuf);
-   if (fd < 0) {
-   unlink(tmpbuf);
-   return -1;
-   }
+   int fd = decompress_kmodule(dso, name, pathname, len);
 
-   strncpy(pathname, tmpbuf, len);
close(fd);
-   return 0;
+   return fd >= 0 ? 0 : -1;
 }
 
 /*
-- 
2.14.4

[PATCH 14/21] perf tools: Add is_compressed callback to compressions array

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add is_compressed callback to the compressions array, that returns 0 if
the file is compressed or != 0 if not.

The new callback is used to recognize the situation when we have a
'compressed' object, like:

  /lib/modules/.../drivers/net/ethernet/intel/igb/igb.ko.xz

but we need to read its debug data from debuginfo files, which might not
be compressed, like:

  /root/.debug/.build-id/d6/...c4b301f/debug

So even for a 'compressed' object we read debug data from a plain
uncompressed object. To keep this transparent, we detect this in
decompress_kmodule() and return the file descriptor to the uncompressed
file.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-11-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/compress.h |  2 ++
 tools/perf/util/dso.c  | 23 ---
 tools/perf/util/lzma.c |  5 +
 tools/perf/util/zlib.c |  6 ++
 4 files changed, 33 insertions(+), 3 deletions(-)

diff --git a/tools/perf/util/compress.h b/tools/perf/util/compress.h
index ecca688a25fb..892e92e7e7fc 100644
--- a/tools/perf/util/compress.h
+++ b/tools/perf/util/compress.h
@@ -4,10 +4,12 @@
 
 #ifdef HAVE_ZLIB_SUPPORT
 int gzip_decompress_to_file(const char *input, int output_fd);
+bool gzip_is_compressed(const char *input);
 #endif
 
 #ifdef HAVE_LZMA_SUPPORT
 int lzma_decompress_to_file(const char *input, int output_fd);
+bool lzma_is_compressed(const char *input);
 #endif
 
 #endif /* PERF_COMPRESS_H */
diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index cbeecf68..8b9243f13b88 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -196,15 +196,16 @@ enum {
 static const struct {
const char *fmt;
int (*decompress)(const char *input, int output);
+   bool (*is_compressed)(const char *input);
 } compressions[] = {
[COMP_ID__NONE] = { .fmt = NULL, },
 #ifdef HAVE_ZLIB_SUPPORT
-   { "gz", gzip_decompress_to_file },
+   { "gz", gzip_decompress_to_file, gzip_is_compressed },
 #endif
 #ifdef HAVE_LZMA_SUPPORT
-   { "xz", lzma_decompress_to_file },
+   { "xz", lzma_decompress_to_file, lzma_is_compressed },
 #endif
-   { NULL, NULL },
+   { NULL, NULL, NULL },
 };
 
 static int is_supported_compression(const char *ext)
@@ -262,6 +263,22 @@ static int decompress_kmodule(struct dso *dso, const char 
*name,
if (dso->comp == COMP_ID__NONE)
return -1;
 
+   /*
+* We have proper compression id for DSO and yet the file
+* behind the 'name' can still be plain uncompressed object.
+*
+* The reason is behind the logic we open the DSO object files,
+* when we try all possible 'debug' objects until we find the
+* data. So even if the DSO is represented by 'krava.xz' module,
+* we can end up here opening ~/.debug/23432432/debug' file
+* which is not compressed.
+*
+* To keep this transparent, we detect this and return the file
+* descriptor to the uncompressed file.
+*/
+   if (!compressions[dso->comp].is_compressed(name))
+   return open(name, O_RDONLY);
+
fd = mkstemp(tmpbuf);
if (fd < 0) {
dso->load_errno = errno;
diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
index 07498eaddc08..7032caaf75eb 100644
--- a/tools/perf/util/lzma.c
+++ b/tools/perf/util/lzma.c
@@ -99,3 +99,8 @@ int lzma_decompress_to_file(const char *input, int output_fd)
fclose(infile);
return err;
 }
+
+bool lzma_is_compressed(const char *input __maybe_unused)
+{
+   return true;
+}
diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c
index a725b958cf31..e68317214679 100644
--- a/tools/perf/util/zlib.c
+++ b/tools/perf/util/zlib.c
@@ -5,6 +5,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "util/compress.h"
 #include "util/util.h"
@@ -79,3 +80,8 @@ int gzip_decompress_to_file(const char *input, int output_fd)
 
return ret == Z_STREAM_END ? 0 : -1;
 }
+
+bool gzip_is_compressed(const char *input __maybe_unused)
+{
+   return true;
+}
-- 
2.14.4

[PATCH 16/21] perf tools: Add gzip_is_compressed function

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add implementation of the is_compressed callback for gzip.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-13-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/zlib.c | 16 ++--
 1 file changed, 14 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/zlib.c b/tools/perf/util/zlib.c
index e68317214679..902ce6384f57 100644
--- a/tools/perf/util/zlib.c
+++ b/tools/perf/util/zlib.c
@@ -6,6 +6,7 @@
 #include 
 #include 
 #include 
+#include 
 
 #include "util/compress.h"
 #include "util/util.h"
@@ -81,7 +82,18 @@ int gzip_decompress_to_file(const char *input, int output_fd)
return ret == Z_STREAM_END ? 0 : -1;
 }
 
-bool gzip_is_compressed(const char *input __maybe_unused)
+bool gzip_is_compressed(const char *input)
 {
-   return true;
+   int fd = open(input, O_RDONLY);
+   const uint8_t magic[2] = { 0x1f, 0x8b };
+   char buf[2] = { 0 };
+   ssize_t rc;
+
+   if (fd < 0)
+   return -1;
+
+   rc = read(fd, buf, sizeof(buf));
+   close(fd);
+   return rc == sizeof(buf) ?
+  memcmp(buf, magic, sizeof(buf)) == 0 : false;
 }
-- 
2.14.4

[PATCH 15/21] perf tools: Add lzma_is_compressed function

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add implementation of the is_compressed callback for lzma.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-12-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/lzma.c | 19 +--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/lzma.c b/tools/perf/util/lzma.c
index 7032caaf75eb..b1dd29a9d915 100644
--- a/tools/perf/util/lzma.c
+++ b/tools/perf/util/lzma.c
@@ -3,9 +3,13 @@
 #include 
 #include 
 #include 
+#include 
+#include 
+#include 
 #include "compress.h"
 #include "util.h"
 #include "debug.h"
+#include 
 
 #define BUFSIZE 8192
 
@@ -100,7 +104,18 @@ int lzma_decompress_to_file(const char *input, int 
output_fd)
return err;
 }
 
-bool lzma_is_compressed(const char *input __maybe_unused)
+bool lzma_is_compressed(const char *input)
 {
-   return true;
+   int fd = open(input, O_RDONLY);
+   const uint8_t magic[6] = { 0xFD, '7', 'z', 'X', 'Z', 0x00 };
+   char buf[6] = { 0 };
+   ssize_t rc;
+
+   if (fd < 0)
+   return -1;
+
+   rc = read(fd, buf, sizeof(buf));
+   close(fd);
+   return rc == sizeof(buf) ?
+  memcmp(buf, magic, sizeof(buf)) == 0 : false;
 }
-- 
2.14.4

[PATCH 17/21] perf tools: Remove ext from struct kmod_path

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Having comp carrying the compression ID, we no longer need return the
extension. Removing it and updating the automated test.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-14-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/kmod-path.c | 136 +--
 tools/perf/util/dso.c|  10 +---
 tools/perf/util/dso.h|   8 +--
 3 files changed, 69 insertions(+), 85 deletions(-)

diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index f92f78f683ea..0579a70bbbff 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -5,34 +5,28 @@
 #include "dso.h"
 #include "debug.h"
 
-static int test(const char *path, bool alloc_name, bool alloc_ext,
-   bool kmod, int comp, const char *name, const char *ext)
+static int test(const char *path, bool alloc_name, bool kmod,
+   int comp, const char *name)
 {
struct kmod_path m;
 
memset(, 0x0, sizeof(m));
 
TEST_ASSERT_VAL("kmod_path__parse",
-   !__kmod_path__parse(, path, alloc_name, alloc_ext));
+   !__kmod_path__parse(, path, alloc_name));
 
-   pr_debug("%s - alloc name %d, alloc ext %d, kmod %d, comp %d, name 
'%s', ext '%s'\n",
-path, alloc_name, alloc_ext, m.kmod, m.comp, m.name, m.ext);
+   pr_debug("%s - alloc name %d, kmod %d, comp %d, name '%s'\n",
+path, alloc_name, m.kmod, m.comp, m.name);
 
TEST_ASSERT_VAL("wrong kmod", m.kmod == kmod);
TEST_ASSERT_VAL("wrong comp", m.comp == comp);
 
-   if (ext)
-   TEST_ASSERT_VAL("wrong ext", m.ext && !strcmp(ext, m.ext));
-   else
-   TEST_ASSERT_VAL("wrong ext", !m.ext);
-
if (name)
TEST_ASSERT_VAL("wrong name", m.name && !strcmp(name, m.name));
else
TEST_ASSERT_VAL("wrong name", !m.name);
 
free(m.name);
-   free(m.ext);
return 0;
 }
 
@@ -45,118 +39,118 @@ static int test_is_kernel_module(const char *path, int 
cpumode, bool expect)
return 0;
 }
 
-#define T(path, an, ae, k, c, n, e) \
-   TEST_ASSERT_VAL("failed", !test(path, an, ae, k, c, n, e))
+#define T(path, an, k, c, n) \
+   TEST_ASSERT_VAL("failed", !test(path, an, k, c, n))
 
 #define M(path, c, e) \
TEST_ASSERT_VAL("failed", !test_is_kernel_module(path, c, e))
 
 int test__kmod_path__parse(struct test *t __maybe_unused, int subtest 
__maybe_unused)
 {
-   /* pathalloc_name  alloc_ext   kmod  comp   name 
ext */
-   T("///x-x.ko", true  , true  , true, 0, "[x_x]", 
NULL);
-   T("///x-x.ko", false , true  , true, 0, NULL   , 
NULL);
-   T("///x-x.ko", true  , false , true, 0, "[x_x]", 
NULL);
-   T("///x-x.ko", false , false , true, 0, NULL   , 
NULL);
+   /* pathalloc_name  kmod  comp   name   */
+   T("///x-x.ko", true  , true, 0, "[x_x]");
+   T("///x-x.ko", false , true, 0, NULL   );
+   T("///x-x.ko", true  , true, 0, "[x_x]");
+   T("///x-x.ko", false , true, 0, NULL   );
M("///x-x.ko", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("///x-x.ko", PERF_RECORD_MISC_USER, false);
 
 #ifdef HAVE_ZLIB_SUPPORT
-   /* pathalloc_name  alloc_ext   kmod  comp  name   ext */
-   T("///x.ko.gz", true , true  , true, 1   , "[x]", "gz");
-   T("///x.ko.gz", false, true  , true, 1   , NULL , "gz");
-   T("///x.ko.gz", true , false , true, 1   , "[x]", NULL);
-   T("///x.ko.gz", false, false , true, 1   , NULL , NULL);
+   /* pathalloc_name   kmod  comp  name  */
+   T("///x.ko.gz", true , true, 1   , "[x]");
+   T("///x.ko.gz", false, true, 1   , NULL );
+   T("///x.ko.gz", true , true, 1   , "[x]");
+   T("///x.ko.gz", false, true, 1   , NULL );
M("///x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x.ko.gz", PERF_RECORD_MISC_KERNEL, true);
M("///x.ko.gz", PERF_RECORD_MISC_USER, false);
 
-   /* path  alloc_name  alloc_ext  kmod   comp  nameext */
-   T("///x.gz", true  , true , false, 1   , "x.gz" ,"gz");
-   T("///x.gz", false , true , false, 1   , NULL   ,"gz");
-   T("///x.gz", true  , false, false, 1   , "x.gz" , NULL);
-   T("///x.gz", false , false, false, 1   , NULL   , NULL);
+   /* path  

[PATCH 19/21] perf python: Fix pyrf_evlist__read_on_cpu() interface

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Jaroslav reported errors from valgrind over perf python script:

  # echo 0 > /sys/devices/system/cpu/cpu4/online
  # valgrind ./test.py
  ==7524== Memcheck, a memory error detector
  ...
  ==7524== Command: ./test.py
  ==7524==
  pid 7526 exited
  ==7524== Invalid read of size 8
  ==7524==at 0xCC2C2B3: perf_mmap__read_forward (evlist.c:780)
  ==7524==by 0xCC2A681: pyrf_evlist__read_on_cpu (python.c:959)
  ...
  ==7524==  Address 0x65c4868 is 16 bytes after a block of size 459,36..
  ==7524==at 0x4C2B955: calloc (vg_replace_malloc.c:711)
  ==7524==by 0xCC2F484: zalloc (util.h:35)
  ==7524==by 0xCC2F484: perf_evlist__alloc_mmap (evlist.c:978)
  ...

The reason for this is in the python interface, that allows a script to
pass arbitrary cpu number, which is then used to access struct
perf_evlist::mmap array. That's obviously wrong and works only when if
all cpus are available and fails if some cpu is missing, like in the
example above.

This patch makes pyrf_evlist__read_on_cpu() search the evlist's maps
array for the proper map to access.

It's linear search at the moment. Based on the way how is the
read_on_cpu used, I don't think we need to be fast in here.  But we
could add some hash in the middle to make it fast/er.

We don't allow python interface to set write_backward event attribute,
so it's safe to check only evlist's mmaps.

Reported-by: Jaroslav Škarvada 
Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Joe Mario 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817114556.28000-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/python.c | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/python.c b/tools/perf/util/python.c
index f74fbb652a4f..ce501ba14b08 100644
--- a/tools/perf/util/python.c
+++ b/tools/perf/util/python.c
@@ -11,6 +11,7 @@
 #include "cpumap.h"
 #include "print_binary.h"
 #include "thread_map.h"
+#include "mmap.h"
 
 #if PY_MAJOR_VERSION < 3
 #define _PyUnicode_FromString(arg) \
@@ -976,6 +977,20 @@ static PyObject *pyrf_evlist__add(struct pyrf_evlist 
*pevlist,
return Py_BuildValue("i", evlist->nr_entries);
 }
 
+static struct perf_mmap *get_md(struct perf_evlist *evlist, int cpu)
+{
+   int i;
+
+   for (i = 0; i < evlist->nr_mmaps; i++) {
+   struct perf_mmap *md = >mmap[i];
+
+   if (md->cpu == cpu)
+   return md;
+   }
+
+   return NULL;
+}
+
 static PyObject *pyrf_evlist__read_on_cpu(struct pyrf_evlist *pevlist,
  PyObject *args, PyObject *kwargs)
 {
@@ -990,7 +1005,10 @@ static PyObject *pyrf_evlist__read_on_cpu(struct 
pyrf_evlist *pevlist,
 , _id_all))
return NULL;
 
-   md = >mmap[cpu];
+   md = get_md(evlist, cpu);
+   if (!md)
+   return NULL;
+
if (perf_mmap__read_init(md) < 0)
goto end;
 
-- 
2.14.4

[PATCH 12/21] perf tools: Use compression id in decompress_kmodule()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Once we parsed out the compression ID, we dont need to iterate all
available compressions and we can call it directly.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-9-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 24 +++-
 1 file changed, 3 insertions(+), 21 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index d875e6956a3e..54bfe1f4762f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -244,18 +244,6 @@ bool is_kernel_module(const char *pathname, int cpumode)
return m.kmod;
 }
 
-static bool decompress_to_file(const char *ext, const char *filename, int 
output_fd)
-{
-   unsigned i;
-
-   for (i = 0; compressions[i].fmt; i++) {
-   if (!strcmp(ext, compressions[i].fmt))
-   return !compressions[i].decompress(filename,
-  output_fd);
-   }
-   return false;
-}
-
 bool dso__needs_decompress(struct dso *dso)
 {
return dso->symtab_type == DSO_BINARY_TYPE__SYSTEM_PATH_KMODULE_COMP ||
@@ -265,31 +253,25 @@ bool dso__needs_decompress(struct dso *dso)
 static int decompress_kmodule(struct dso *dso, const char *name, char *tmpbuf)
 {
int fd = -1;
-   struct kmod_path m;
 
if (!dso__needs_decompress(dso))
return -1;
 
-   if (kmod_path__parse_ext(, dso->long_name))
+   if (dso->comp == COMP_ID__NONE)
return -1;
 
-   if (!m.comp)
-   goto out;
-
fd = mkstemp(tmpbuf);
if (fd < 0) {
dso->load_errno = errno;
-   goto out;
+   return -1;
}
 
-   if (!decompress_to_file(m.ext, name, fd)) {
+   if (compressions[dso->comp].decompress(name, fd)) {
dso->load_errno = DSO_LOAD_ERRNO__DECOMPRESSION_FAILURE;
close(fd);
fd = -1;
}
 
-out:
-   free(m.ext);
return fd;
 }
 
-- 
2.14.4

[PATCH 11/21] perf tools: Store compression id into struct dso

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Add comp to 'struct dso' to hold the compression index.  It will be used
in the following patches.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-8-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 5 -
 tools/perf/util/dso.h | 1 +
 tools/perf/util/machine.c | 4 +++-
 3 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index d34e47bb09d9..d875e6956a3e 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -417,8 +417,10 @@ void dso__set_module_info(struct dso *dso, struct 
kmod_path *m,
dso->symtab_type = DSO_BINARY_TYPE__GUEST_KMODULE;
 
/* _KMODULE_COMP should be next to _KMODULE */
-   if (m->kmod && m->comp)
+   if (m->kmod && m->comp) {
dso->symtab_type++;
+   dso->comp = m->comp;
+   }
 
dso__set_short_name(dso, strdup(m->name), true);
 }
@@ -1224,6 +1226,7 @@ struct dso *dso__new(const char *name)
dso->a2l_fails = 1;
dso->kernel = DSO_TYPE_USER;
dso->needs_swap = DSO_SWAP__UNSET;
+   dso->comp = COMP_ID__NONE;
RB_CLEAR_NODE(>rb_node);
dso->root = NULL;
INIT_LIST_HEAD(>node);
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index 7bde23f6e5a9..a6c7af52115f 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -175,6 +175,7 @@ struct dso {
u16  short_name_len;
void*dwfl;  /* DWARF debug info */
struct auxtrace_cache *auxtrace_cache;
+   int  comp;
 
/* dso data file */
struct {
diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
index b300a3973448..c4acd2001db0 100644
--- a/tools/perf/util/machine.c
+++ b/tools/perf/util/machine.c
@@ -1212,8 +1212,10 @@ static int map_groups__set_module_path(struct map_groups 
*mg, const char *path,
 * Full name could reveal us kmod compression, so
 * we need to update the symtab_type if needed.
 */
-   if (m->comp && is_kmod_dso(map->dso))
+   if (m->comp && is_kmod_dso(map->dso)) {
map->dso->symtab_type++;
+   map->dso->comp = m->comp;
+   }
 
return 0;
 }
-- 
2.14.4

[tip:locking/urgent] futex: Mark expected switch fall-throughs

[tip-bot for Gustavo A. R. Silva]

Commit-ID:  b639186ffe9168fd1d2f95a1fff8571720739126
Gitweb: https://git.kernel.org/tip/b639186ffe9168fd1d2f95a1fff8571720739126
Author: Gustavo A. R. Silva 
AuthorDate: Thu, 16 Aug 2018 12:21:24 -0500
Committer:  Thomas Gleixner 
CommitDate: Mon, 20 Aug 2018 18:23:00 +0200

futex: Mark expected switch fall-throughs

In preparation of enabling -Wimplicit-fallthrough, mark switch cases which
fall through.

Signed-off-by: Gustavo A. R. Silva 
Signed-off-by: Thomas Gleixner 
Cc: Peter Zijlstra 
Cc: Darren Hart 
Link: https://lkml.kernel.org/r/20180816172124.ga2...@embeddedor.com

---
 kernel/futex.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/kernel/futex.c b/kernel/futex.c
index 1f450e092c74..11fc3bb456d6 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -3523,10 +3523,12 @@ long do_futex(u32 __user *uaddr, int op, u32 val, 
ktime_t *timeout,
switch (cmd) {
case FUTEX_WAIT:
val3 = FUTEX_BITSET_MATCH_ANY;
+   /* fall through */
case FUTEX_WAIT_BITSET:
return futex_wait(uaddr, flags, val, timeout, val3);
case FUTEX_WAKE:
val3 = FUTEX_BITSET_MATCH_ANY;
+   /* fall through */
case FUTEX_WAKE_BITSET:
return futex_wake(uaddr, flags, val, val3);
case FUTEX_REQUEUE:

[GIT PULL] livepatching

[Jiri Kosina]

Linus,

please pull from

  git://git.kernel.org/pub/scm/linux/kernel/git/jikos/livepatching.git for-linus

to receive livepatching updates

=
- code cleanups from Kamalesh Babulal
=

Thanks.


Kamalesh Babulal (2):
  livepatch: Remove reliable stacktrace check in klp_try_switch_task()
  livepatch: Validate module/old func name length

 kernel/livepatch/core.c   | 6 ++
 kernel/livepatch/transition.c | 7 ---
 2 files changed, 6 insertions(+), 7 deletions(-)

-- 
Jiri Kosina
SUSE Labs

[PATCH] sparc: fix KBUILD_DEFCONFIG for ARCH=sparc32

[Masahiro Yamada]

As commit 5ba800962a80 ("kbuild: update ARCH alias info for sparc")
addressed, SPARC accepts ARCH=sparc32 as an alias.

However, arch/sparc/Makefile wrongly sets KBUILD_DEFCONFIG, then
sparc64_defconfig is chosen as the base configuration for ARCH=sparc32.

  $ make ARCH=sparc32 defconfig
  *** Default configuration is based on 'sparc64_defconfig'
  #
  # configuration written to .config
  #

Fix the logic to choose sparc64_defconfig only when ARCH=sparc64.

Signed-off-by: Masahiro Yamada 
---

 arch/sparc/Makefile | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/sparc/Makefile b/arch/sparc/Makefile
index 966a13d..e32ef20 100644
--- a/arch/sparc/Makefile
+++ b/arch/sparc/Makefile
@@ -9,10 +9,10 @@
 # Copyright (C) 1998 Jakub Jelinek (j...@ultra.linux.cz)
 
 # We are not yet configured - so test on arch
-ifeq ($(ARCH),sparc)
-KBUILD_DEFCONFIG := sparc32_defconfig
-else
+ifeq ($(ARCH),sparc64)
 KBUILD_DEFCONFIG := sparc64_defconfig
+else
+KBUILD_DEFCONFIG := sparc32_defconfig
 endif
 
 ifeq ($(CONFIG_SPARC32),y)
-- 
2.7.4

Re: [PATCH 1/5] iio: potentiometer: mcp4018: use the correct MODULE_LICENSE

[Jonathan Cameron]

On Mon, 20 Aug 2018 12:01:10 +0200
Peter Rosin  wrote:

> The file is GPL v2 only.
> 
> Signed-off-by: Peter Rosin 
Applied to the togreg branch of iio.git and pushed out as testing for
the autobuilders to play with it.

thanks,

Jonathan
> ---
>  drivers/iio/potentiometer/mcp4018.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/iio/potentiometer/mcp4018.c 
> b/drivers/iio/potentiometer/mcp4018.c
> index 320a7c929777..5ab74a839982 100644
> --- a/drivers/iio/potentiometer/mcp4018.c
> +++ b/drivers/iio/potentiometer/mcp4018.c
> @@ -190,4 +190,4 @@ module_i2c_driver(mcp4018_driver);
>  
>  MODULE_AUTHOR("Peter Rosin ");
>  MODULE_DESCRIPTION("MCP4018 digital potentiometer");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");

Re: [PATCH v3 0/7] perf: Add ioctl for PMU driver configuration

[Kim Phillips]

On Mon, 20 Aug 2018 15:36:47 +0100
Suzuki K Poulose  wrote:

> On 08/20/2018 03:22 PM, Kim Phillips wrote:
> > On Mon, 20 Aug 2018 11:03:03 +0100
> > Suzuki K Poulose  wrote:
> > 
> >> On 08/16/2018 08:28 PM, Mathieu Poirier wrote:
> >>> On Wed, 15 Aug 2018 at 09:28, Kim Phillips  wrote:
> 
>  On Wed, 15 Aug 2018 10:39:13 +0100
>  Will Deacon  wrote:
> 
> > On Tue, Aug 14, 2018 at 01:42:27PM -0600, Mathieu Poirier wrote:
> >> On Tue, 14 Aug 2018 at 11:09, Kim Phillips  
> >> wrote:
> >>> The other thing that's going on here is that I'm becoming numb to the
> >>> loathsome "failed to mmap with 12 (Cannot allocate memory)" being
> >>> returned no matter what the error is/was. E.g., an error that would
> >>> indicate a sense of non-implementation would be much better
> >>> appreciated than presumably what the above is doing, i.e., returning
> >>> -ENOMEM.  That, backed up with specific details in the form of human
> >>> readable text in dmesg would be *most* welcome.
> >>
> >> As part of the refactoring of the code to support CPU-wide scenarios I
> >> intend to emit better diagnostic messages from the driver.  Modifying
> >> rb_alloc_aux() to propagate the error message generated by the
> >> architecture specific PMUs doesn't look hard either and I _may_ get to
> >> it as part of this work.
> >
> > For the record, I will continue to oppose PMU drivers that dump 
> > diagnostics
> > about user-controlled input into dmesg, but the coresight drivers are 
> > yours
> > so it's up to you and I won't get in the way!
> 
>  That sounds technically self-contradicting to me.  Why shouldn't
>  coresight share the same policies as those used for PMU drivers?  Or
>  why not allow the individual vendor PMU driver authors control the
>  level of user-friendliness of their own drivers?
> 
>  That being said, Matheiu, would you accept patches that make coresight
>  more verbose in dmesg?
> >>>
> >>> It depends on the issue you're hoping to address.  I'd rather see the
> >>> root cause of the problem fixed than adding temporary code.  Suzuki
> >>> added the ETR perf API and I'm currently working on CPU-wide
> >>> scenarios.  From there and with regards to what can happen in
> >>> setup_aux(), we should have things covered.
> >>
> >> I think the main issue is the lack of error code propagation from
> >> setup_aux() back to the perf_aux_output_handle_begin(), which always
> >> return -ENOMEM. If we fix that, we could get better idea of whats
> >> wrong.
> > 
> > Why get a better idea when we can get the exact details?
> 
> The different values for error numbers are there for a reason...

But the same error number, e.g., EINVAL, can be returned for different
reasons.

> >> If someone is planning to add verbose messages, they may do so by adding
> >> dev_dbg() / pr_debug(), which can be turned on as and when needed.
> > 
> > I disagree:  that just adds another usage and kernel configuration
> > obstacle.  Why not use pr_err straight up?
> 
> I personally don't agree to usage of pr_err() in paths which are easily
> triggered from user input.

Why not?  pr_* are ratelimited.

> Also, we are moving all the "debugging"
> messages to the dynamic debug, to prevent lockdep splats.

Are you referring to this?:

https://lkml.org/lkml/2018/5/1/73

Re-reading the thread, AFAICT, it was never proven that the splats
occurred due to the dev_infos, and there's no dev_info in this
stacktrace:

https://lkml.org/lkml/2018/5/10/269

But even if it were, wouldn't the splats also occur with dev_dbg?

Kim

Re: [PATCH v2 01/32] tracing: Allow gcov profiling on only ftrace subsystem

[Steven Rostedt]

On Mon, 20 Aug 2018 11:32:13 -0400
Steven Rostedt  wrote:

> Other than that, it looks fine to me.

This patch also seems out of place for the series. Want to resend it
separately, and I'll apply it?

Thanks!

-- Steve

mfd: cros_ec: Check for mkbp events on resume only if supported.

[RaviChandra Sadineni]

Currently on every resume we check for mkbp events and notify the
clients. This helps in identifying the wakeup sources. But on devices
that do not support mkbp protocol, we might end up querying key state of
the keyboard in a loop which blocks the resume. Instead check for events
only if mkbp is supported.

Signed-off-by: RaviChandra Sadineni 
---

 Note: This patch fixes the suspend/resume issue on Snow and Peach-Pit
 Chromebooks, both on vanilla v4.18 as well as linux-next from 20 August 
 2018. Further info at: https://lkml.org/lkml/2018/6/5/1076
 
 drivers/mfd/cros_ec.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/mfd/cros_ec.c b/drivers/mfd/cros_ec.c
index 65a9757a6d21..fe6f83766144 100644
--- a/drivers/mfd/cros_ec.c
+++ b/drivers/mfd/cros_ec.c
@@ -218,7 +218,8 @@ EXPORT_SYMBOL(cros_ec_suspend);
 
 static void cros_ec_report_events_during_suspend(struct cros_ec_device *ec_dev)
 {
-   while (cros_ec_get_next_event(ec_dev, NULL) > 0)
+   while (ec_dev->mkbp_event_supported &&
+  cros_ec_get_next_event(ec_dev, NULL) > 0)
blocking_notifier_call_chain(_dev->event_notifier,
 1, ec_dev);
 }
-- 
2.16.4

Re: [PATCH V3 0/4] clk: new APIs to handle all available clocks

[Thor Thayer]

Hi,

On 08/16/2018 09:33 PM, A.s. Dong wrote:

Hi Stephen,

Do you want me to resend this series for review?
It seems have been pending for quite a long time.

Thor just pinged me for its status as he wants to use it.

Regards
Dong Aisheng


-Original Message-
From: A.s. Dong
Sent: Wednesday, June 20, 2018 10:54 AM
To: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
sb...@kernel.org; mturque...@baylibre.com; shawn...@kernel.org; dl-
linux-imx 
Subject: RE: [PATCH V3 0/4] clk: new APIs to handle all available clocks

Ping


-Original Message-
From: A.s. Dong
Sent: Friday, May 25, 2018 6:37 PM
To: linux-...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org;
linux-arm-ker...@lists.infradead.org;
sb...@kernel.org; mturque...@baylibre.com; shawn...@kernel.org; dl-
linux-imx ; A.s. Dong 
Subject: [PATCH V3 0/4] clk: new APIs to handle all available clocks

This patch series is a continue of discussion from here,
https://patchwork.kernel.org/patch/9986293/
that some users may want to handle all available clocks from device
tree without need to know the detailed clock information likes clock
numbers and names. This is useful in writing some generic drivers to handle

clock part.


Note:
This patch series is tested on MX6Q SDB cpufreq driver with a minor
change to switch to use clk_bulk_get_all.
But patch 4 only test compiling. Hopefully someone could help test the
function.

v2->v3:
  * address all comments from Stephen
  * fix build warnings on other architectures.
v1->v2:
  * add clk_bulk_{get|put}_all() which only supports DT platform
currently
  * remove _all variants and the wrapper struct clk_bulk
  * make of_clk_bulk_get and of_clk_bulk_get_all private until someone
proves they need it because they don't have a struct device pointer.

Dong Aisheng (4):
   clk: bulk: add of_clk_bulk_get()
   clk: add new APIs to operate on all available clocks
   clk: add managed version of clk_bulk_get_all
   video: simplefb: switch to use clk_bulk API to simplify clock
 operations

  drivers/clk/clk-bulk.c | 80
++
  drivers/clk/clk-devres.c   | 24 +
  drivers/video/fbdev/simplefb.c | 66 +++---
  include/linux/clk.h| 65 +-
  4 files changed, 180 insertions(+), 55 deletions(-)

--
2.7.4





Nice patchset!

FWIW, I've tested patches 1-3 on Stratix10 SOCFPGA for a SMMU driver I'm 
working on.


Tested-by: Thor Thayer 

Re: [PATCH v8 1/2] PCI: pciehp: Ignore link events when there is a fatal error pending

[Sinan Kaya]

On 8/20/2018 5:22 AM, Lukas Wunner wrote:

+

This differs from v7 of the patch in that*any*  fatal error, not just
a Surprise Link Down, results in pciehp waiting for the error to clear.

I'm wondering if that's safe:  Theoretically, the user might quickly
swap the card in the slot during, say, a Completion Timeout Error,
and with this patch pciehp would carry on as if nothing happened.


Functionally both patches are identical. The v7 was still allowing
AER/DPC to handle all fatal error events except Surprise Link Down.

Now, second patch (v8 2/2) is masking the surprise link down event
as we have talked before. Therefore, there is no need to filter
out incoming errors by reading the status register and masking the
unwanted bits.

Just to clarify something, this patch will wait for only the FATAL
error events to be handled by the error handling services only.

Completion Timeout is a NONFATAL error event by default unless
somebody tweaks the severity bits.

Anyhow, all FATAL errors cause one sort of link down either
initiated by software (AER) or hardware (DPC).
Therefore, hotplug driver will observe a link down event and
AER/DPC needs to handle the event as usual.

Re: [PATCH v1 2/2] Embedded USB Debugger (EUD) driver

[pheragu]

On 2018-08-17 12:47, Trilok Soni wrote:

Hi Prakruthi,

On 8/16/2018 5:05 PM, Prakruthi Deepak Heragu wrote:

+
+#define EUD_INT_VBUS   BIT(2)
+#define EUD_INT_CHGR   BIT(3)
+#define EUD_INT_SAFE_MODE  BIT(4)
+
+#define EUD_NR 1


I don't see any use of EUD_NR in the driver below. Do we need it?

Sorry about that. Will get rid of it.

Re: [PATCH] mm: introduce kvvirt_to_page() helper

[Matthew Wilcox]

On Mon, Aug 20, 2018 at 06:24:06PM +0200, Michal Hocko wrote:
> On Mon 20-08-18 07:49:23, Matthew Wilcox wrote:
> > On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > > On Sat 18-08-18 20:49:01, Li RongQing wrote:
> > > > The new helper returns address mapping page, which has several users
> > > > in individual subsystem, like mem_to_page in xfs_buf.c and pgv_to_page
> > > > in af_packet.c, unify them
> > > 
> > > kvvirt_to_page is a weird name. I guess you wanted it to fit into
> > > kv*alloc, kvfree naming, right? If yes then I guess kvmem_to_page
> > > would be slightly better.
> > > 
> > > Other than that the patch makes sense to me. It would be great to add
> > > some documentation and be explicit that the call is only safe on
> > > directly mapped kernel address and vmalloc areas.
> > 
> > ... and not safe if the length crosses a page boundary.  I don't want to
> > see new code emerge that does kvmalloc(PAGE_SIZE * 2, ...); kvmem_to_page()
> > and have it randomly crash when kvmalloc happens to fall back to vmalloc()
> > under heavy memory pressure.
> > 
> > Also, people are going to start using this for stack addresses.  Perhaps
> > we should have a debug option to guard against them doing that.
> 
> I do agree that such an interface is quite dangerous. That's why I was
> stressing out the proper documentation. I would be much happier if we
> could do without it altogether. Maybe the existing users can be rewoked
> to not rely on the addr2page functionality. If that is not the case then
> we should probably offer a helper. With some WARN_ONs to catch misuse
> would be really nice. I am not really sure how many abuses can we catch
> actually though.

I certainly understand the enthusiasm for sharing this code rather than
having dozens of places outside the VM implement their own version of it.
But I think most of these users are using code that's working at the wrong
level.  Most of them seem to have an address range which may-or-may-not-be
virtually mapped and they want to get an array-of-pages for that.

Perhaps we should offer -that- API instead.  vmalloc/vmap already has
an array-of-pages, and the various users could be given a pointer to
that array.  If the memory isn't vmapped, maybe the caller could pass
an array pointer like XFS does, or we could require them to pass GFP flags
to allocate a new array.

Re: [PATCH v2 1/2] x86: corruption-check: Passing memory_corruption_check to command line causes panic

[Greg KH]

On Mon, Aug 20, 2018 at 04:56:22PM +0800, He Zhe wrote:
> Could you please provide your input? Thanks.

It is the middle of the merge window, we can not do anything with new
patches.  This is a trivial cleanup fix, nothing that is really
important at the moment it will be reviewed in time, please give us a
chance.

thanks,

greg k-h

Re: [PATCH 1/4] regulator: core: If consumers don't call regulator_set_load() assume max

[Mark Brown]

On Fri, Aug 17, 2018 at 02:36:01PM -0700, Bjorn Andersson wrote:

> FWIW, we've had this problem on other devices as well; where the eMMC
> won't operate properly unless the supply operates in HPM. We've worked
> around this by specifying regulator-system-load for said regulators.

You can set the regulator to work in a single mode all the time, that's
not a problem.  If you know the system needs to be in a specific mode
it's easy to configure that (some might require a mode below the highest
power one since that's sometimes the noisiest).


signature.asc
Description: PGP signature

Re: [PATCH v4 4/7] i2c: designware: document MSCC Ocelot bindings

[Rob Herring]

On Thu, Aug 16, 2018 at 10:45:18AM +0200, Alexandre Belloni wrote:
> Document bindings for the Microsemi Ocelot integration of the Designware
> I2C controller.
> 
> Cc: Rob Herring 
> Signed-off-by: Alexandre Belloni 
> ---
>  Documentation/devicetree/bindings/i2c/i2c-designware.txt | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)

No need to re-spin just for the subject.

Reviewed-by: Rob Herring 

Re: [PATCH 2/5] iio: potentiometer: mcp4531: switch to SPDX license identifier

[Jonathan Cameron]

On Mon, 20 Aug 2018 12:01:11 +0200
Peter Rosin  wrote:

> Drop the boilerplate license text and use the correct MODULE_LICENSE.
> 
> Signed-off-by: Peter Rosin 
Applied.

thanks,

Jonathan
> ---
>  drivers/iio/potentiometer/mcp4531.c | 7 ++-
>  1 file changed, 2 insertions(+), 5 deletions(-)
> 
> diff --git a/drivers/iio/potentiometer/mcp4531.c 
> b/drivers/iio/potentiometer/mcp4531.c
> index df894af6cccb..831ad3e7871c 100644
> --- a/drivers/iio/potentiometer/mcp4531.c
> +++ b/drivers/iio/potentiometer/mcp4531.c
> @@ -1,3 +1,4 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Industrial I/O driver for Microchip digital potentiometers
>   * Copyright (c) 2015  Axentia Technologies AB
> @@ -22,10 +23,6 @@
>   * mcp4652   2   257 5, 10, 50, 100  01011xx
>   * mcp4661   2   257 5, 10, 50, 100  0101xxx
>   * mcp4662   2   257 5, 10, 50, 100  01011xx
> - *
> - * This program is free software; you can redistribute it and/or modify it
> - * under the terms of the GNU General Public License version 2 as published 
> by
> - * the Free Software Foundation.
>   */
>  
>  #include 
> @@ -403,4 +400,4 @@ module_i2c_driver(mcp4531_driver);
>  
>  MODULE_AUTHOR("Peter Rosin ");
>  MODULE_DESCRIPTION("MCP4531 digital potentiometer");
> -MODULE_LICENSE("GPL");
> +MODULE_LICENSE("GPL v2");

Re: [PATCH 3/5] iio: envelope-detector: switch to SPDX license identifier

[Jonathan Cameron]

On Mon, 20 Aug 2018 12:01:12 +0200
Peter Rosin  wrote:

> Drop the boilerplate license text.
> 
> Signed-off-by: Peter Rosin 
Applied, thanks.
> ---
>  drivers/iio/adc/envelope-detector.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/adc/envelope-detector.c 
> b/drivers/iio/adc/envelope-detector.c
> index 4ebda8ab54fe..2f2b563c1162 100644
> --- a/drivers/iio/adc/envelope-detector.c
> +++ b/drivers/iio/adc/envelope-detector.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * Driver for an envelope detector using a DAC and a comparator
>   *
>   * Copyright (C) 2016 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>  
>  /*

Re: [PATCH 1/7] dt-bindings: Add DT bindings documentation for Allwinner Thermal Sensor Controller

[Rob Herring]

On Mon, Aug 20, 2018 at 9:07 AM Maxime Ripard  wrote:
>
> On Mon, Aug 20, 2018 at 07:41:22AM -0600, Rob Herring wrote:
> > On Mon, Aug 20, 2018 at 5:17 AM Maxime Ripard  
> > wrote:
> > >
> > > On Sat, Aug 04, 2018 at 09:03:49AM +0200, Emmanuel Vadot wrote:
> > > > This patch adds documentation for Device-Tree bindings for the Allwinner
> > > > Thermal Sensor Controller found on the H3, H5 and A64 SoCs
> > > >
> > > > Signed-off-by: Emmanuel Vadot 
> > >
> > > I'm not going to merge a binding for a device that doesn't have any
> > > driver implemented at the moment in Linux.
> >
> > I'll take it then. Linux is not the only DT client.
>
> Then don't complain if we ever have to break the ABI.

My only complaint is when breaking ABIs and not being clear about
doing so. Otherwise, it is up to platform maintainers to not upset
their users (including if some of those users are FreeBSD).

> We never tested
> that hardware, never had any code running on it, and it *will* cause
> some issues. For example, the calibration data have never been used
> and how they should be represented have never been described, since no
> one ever actually tried to use it.

Then perhaps that part of the binding should be omitted for now. But I
don't see how if this works for FreeBSD how it wouldn't for Linux.

Rob

Re: [PATCH] signal: Don't send signals to tasks that don't exist

[J. Bruce Fields]

On Sat, Aug 18, 2018 at 12:51:14AM -0500, Eric W. Biederman wrote:
> I was dismayed when I saw the syzbot report triggered someone to remove
> themselves from MAINTAINERS.

You're talking about my patch?  I think you misread it, I'm not removing
myself from MAINTAINERS.

--b.

Re: [PATCH] mm: introduce kvvirt_to_page() helper

[Michal Hocko]

On Mon 20-08-18 07:49:23, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 04:41:16PM +0200, Michal Hocko wrote:
> > On Sat 18-08-18 20:49:01, Li RongQing wrote:
> > > The new helper returns address mapping page, which has several users
> > > in individual subsystem, like mem_to_page in xfs_buf.c and pgv_to_page
> > > in af_packet.c, unify them
> > 
> > kvvirt_to_page is a weird name. I guess you wanted it to fit into
> > kv*alloc, kvfree naming, right? If yes then I guess kvmem_to_page
> > would be slightly better.
> > 
> > Other than that the patch makes sense to me. It would be great to add
> > some documentation and be explicit that the call is only safe on
> > directly mapped kernel address and vmalloc areas.
> 
> ... and not safe if the length crosses a page boundary.  I don't want to
> see new code emerge that does kvmalloc(PAGE_SIZE * 2, ...); kvmem_to_page()
> and have it randomly crash when kvmalloc happens to fall back to vmalloc()
> under heavy memory pressure.
> 
> Also, people are going to start using this for stack addresses.  Perhaps
> we should have a debug option to guard against them doing that.

I do agree that such an interface is quite dangerous. That's why I was
stressing out the proper documentation. I would be much happier if we
could do without it altogether. Maybe the existing users can be rewoked
to not rely on the addr2page functionality. If that is not the case then
we should probably offer a helper. With some WARN_ONs to catch misuse
would be really nice. I am not really sure how many abuses can we catch
actually though.
-- 
Michal Hocko
SUSE Labs

[PATCH] rtc: jz4740: Drop dependency on MACH_INGENIC

[Paul Cercueil]

Depending on MACH_INGENIC prevent us from creating a generic kernel that
works on more than one MIPS board. Instead, we just depend on MIPS being
set.

Signed-off-by: Paul Cercueil 
---
 drivers/rtc/Kconfig | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index a2ba5db36145..98c7f19256b1 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -1608,7 +1608,7 @@ config RTC_DRV_MPC5121
 
 config RTC_DRV_JZ4740
tristate "Ingenic JZ4740 SoC"
-   depends on MACH_INGENIC || COMPILE_TEST
+   depends on MIPS || COMPILE_TEST
help
  If you say yes here you get support for the Ingenic JZ47xx SoCs RTC
  controllers.
-- 
2.11.0

[RFC PATCH tip] x86/platform/uv/BAU: uv_bau_crash_shutdown() can be static

[kbuild test robot]

Fixes: 99f396587875 ("x86/platform/uv/BAU: Gracefully disable BAU during panic")
Signed-off-by: kbuild test robot 
---
 tlb_uv.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/arch/x86/platform/uv/tlb_uv.c b/arch/x86/platform/uv/tlb_uv.c
index 4c1e119..bce4d14 100644
--- a/arch/x86/platform/uv/tlb_uv.c
+++ b/arch/x86/platform/uv/tlb_uv.c
@@ -2206,7 +2206,7 @@ static const struct bau_operations uv4_bau_ops 
__initconst = {
  * Bring BAU to quiesence by abandoning current broadcasts and freeing up
  * resources needed by firmware-initiated BAU broadcasts.
  */
-void uv_bau_crash_shutdown(struct pt_regs *regs)
+static void uv_bau_crash_shutdown(struct pt_regs *regs)
 {
int pnode = 0;
int uvhub = 0;

[tip:x86/urgent 6/6] arch/x86/platform/uv/tlb_uv.c:2209:6: sparse: symbol 'uv_bau_crash_shutdown' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git x86/urgent
head:   99f3965878759d36baac944df004b4dafcc272b4
commit: 99f3965878759d36baac944df004b4dafcc272b4 [6/6] x86/platform/uv/BAU: 
Gracefully disable BAU during panic
reproduce:
# apt-get install sparse
git checkout 99f3965878759d36baac944df004b4dafcc272b4
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   include/linux/nodemask.h:265:16: sparse: expression using sizeof(void)
   include/linux/nodemask.h:271:16: sparse: expression using sizeof(void)
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in argument 
1 (different address spaces) @@expected void const volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:687:42:expected void const volatile 
[noderef] *addr
   arch/x86/include/asm/uv/uv_hub.h:687:42:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in argument 
1 (different address spaces) @@expected void const volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:687:42:expected void const volatile 
[noderef] *addr
   arch/x86/include/asm/uv/uv_hub.h:687:42:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in argument 
1 (different address spaces) @@expected void const volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:687:42:expected void const volatile 
[noderef] *addr
   arch/x86/include/asm/uv/uv_hub.h:687:42:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in argument 
1 (different address spaces) @@expected void const volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:687:42:expected void const volatile 
[noderef] *addr
   arch/x86/include/asm/uv/uv_hub.h:687:42:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:692:41: sparse: incorrect type in argument 
2 (different address spaces) @@expected void volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:692:41:expected void volatile [noderef] 
*addr
   arch/x86/include/asm/uv/uv_hub.h:692:41:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in argument 
1 (different address spaces) @@expected void const volatile [noderef] 
*addr @@got deref] *addr @@
   arch/x86/include/asm/uv/uv_hub.h:687:42:expected void const volatile 
[noderef] *addr
   arch/x86/include/asm/uv/uv_hub.h:687:42:got unsigned long *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:652:16: sparse: incorrect type in return 
expression (different address spaces) @@expected void volatile [noderef] 
* @@got sn:2>* @@
   arch/x86/include/asm/uv/uv_hub.h:652:16:expected void volatile [noderef] 
*
   arch/x86/include/asm/uv/uv_hub.h:652:16:got void *
   arch/x86/include/asm/uv/uv_hub.h:687:42: sparse: incorrect type in 

Re: [PATCH 5/5] iio: multiplexer: switch to SPDX license identifier

[Jonathan Cameron]

On Mon, 20 Aug 2018 12:01:14 +0200
Peter Rosin  wrote:

> Drop the boilerplate license text.
> 
> Signed-off-by: Peter Rosin 
Applied.

Thanks,

Jonathan

> ---
>  drivers/iio/multiplexer/iio-mux.c | 5 +
>  1 file changed, 1 insertion(+), 4 deletions(-)
> 
> diff --git a/drivers/iio/multiplexer/iio-mux.c 
> b/drivers/iio/multiplexer/iio-mux.c
> index e1f44cecdef4..0422ef57914c 100644
> --- a/drivers/iio/multiplexer/iio-mux.c
> +++ b/drivers/iio/multiplexer/iio-mux.c
> @@ -1,13 +1,10 @@
> +// SPDX-License-Identifier: GPL-2.0
>  /*
>   * IIO multiplexer driver
>   *
>   * Copyright (C) 2017 Axentia Technologies AB
>   *
>   * Author: Peter Rosin 
> - *
> - * This program is free software; you can redistribute it and/or modify
> - * it under the terms of the GNU General Public License version 2 as
> - * published by the Free Software Foundation.
>   */
>  
>  #include 

Re: Build failures with gcc 4.5 and older

[Linus Torvalds]

On Mon, Aug 20, 2018 at 10:46 AM Nick Desaulniers
 wrote:
>
> I think we should take Joe's patch.

I'll happily take Joe's patch and get the whole "ancient gcc versions"
issue behind us.

We'll come back to it in a few years when 4.6 is ancient too, but for
now we have no pressing need not to support it.

Joe - proper commit message and sign-off?

  Linus

Re: [PATCH v8 1/2] kbuild: Allow asm-specific compiler_types.h

[Paul Burton]

Hi Masahiro,

On Mon, Aug 20, 2018 at 02:04:24PM +0900, Masahiro Yamada wrote:
> 2018-08-19 3:10 GMT+09:00 Paul Burton :
> > We have a need to override the definition of
> > barrier_before_unreachable() for MIPS, which means we either need to add
> > architecture-specific code into linux/compiler-gcc.h or we need to allow
> > the architecture to provide a header that can define the macro before
> > the generic definition. The latter seems like the better approach.
> >
> > A straightforward approach to the per-arch header is to make use of
> > asm-generic to provide a default empty header & adjust architectures
> > which don't need anything specific to make use of that by adding the
> > header to generic-y. Unfortunately this doesn't work so well due to
> > commit a95b37e20db9 ("kbuild: get  out of
> > ") which moved the inclusion of linux/compiler.h to
> > cflags using the -include compiler flag.
> >
> > Because the -include flag is present for all C files we compile, we need
> > the architecture-provided header to be present before any C files are
> > compiled. If any C files can be compiled prior to the asm-generic header
> > wrappers being generated then we hit a build failure due to missing
> > header. Such cases do exist - one pointed out by the kbuild test robot
> > is the compilation of arch/ia64/kernel/nr-irqs.c, which occurs as part
> > of the archprepare target [1].
> >
> > This leaves us with a few options:
> >
> >   1) Use generic-y & fix any build failures we find by enforcing
> >  ordering such that the asm-generic target occurs before any C
> >  compilation, such that linux/compiler_types.h can always include
> >  the generated asm-generic wrapper which in turn includes the empty
> >  asm-generic header. This would rely on us finding all the
> >  problematic cases - I don't know for sure that the ia64 issue is
> >  the only one.
> >
> >   2) Add an actual empty header to each architecture, so that we don't
> >  need the generated asm-generic wrapper. This seems messy.
> >
> >   3) Give up & add #ifdef CONFIG_MIPS or similar to
> >  linux/compiler_types.h. This seems messy too.
> >
> >   4) Include the arch header only when it's actually needed, removing
> >  the need for the asm-generic wrapper for all other architectures.
> >
> > This patch allows us to use approach 4, by including an
> > asm/compiler_types.h header using the -include flag in the same way we
> > do for linux/compiler_types.h, but only if the header actually exists.
> 
> I agree with the approach 4),
> but I am of two minds about how to implement it.
> 
> I guess the cost of evaluating 'wildcard' for each C file
> is unnoticeable level, but I am slightly in favor of
> including  from 
> conditionally.
> 
> I am not sure about the CONFIG name, but for example, like this.
> 
> #ifdef CONFIG_HAVE_ARCH_COMPILER_TYPES
> #include 
> #endif
> 
> What do you think?

That sounds fine to me - I'll submit a v9 shortly :)

Thanks,
Paul

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

[Michal Hocko]

On Mon 20-08-18 11:03:53, Andi Kleen wrote:
> On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> > On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > > Hi,
> > > 
> > > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> > 
> > Could you try to apply fd7e315988b7 ("x86/mm: Simplify p[g4um]d_page()
> > macros"). I do not see it in stable 4.4 tree and it has been introduced
> > much later in 4.14. This one gave us quite some headache because it is
> > s easy to overlook.
> 
> Good catch!
> 
> I tested that with 4.9 and backporting the patch indeed fixes the
> syzcaller test case running in a KVM VM. Backported patch appended.
> 
> Should probably go into 4.4 and 4.9.
> 
> Cannot explain the 4.17 report unfortunately.

I haven't seen that one yet and likely won't get to it tomorrow as well
but I would start looking for a direct pte_val usage. We have had som
out of tree xen code which was doing exactly this. Not really easy to
find by a code inspection.
-- 
Michal Hocko
SUSE Labs

Re: [PATCH] rtc: jz4740: Drop dependency on MACH_INGENIC

[Alexandre Belloni]

On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
> Depending on MACH_INGENIC prevent us from creating a generic kernel that
> works on more than one MIPS board. Instead, we just depend on MIPS being
> set.

Maybe you could consider dropping the whole dependency as we already
know it will build on every architecture.

> 
> Signed-off-by: Paul Cercueil 
> ---
>  drivers/rtc/Kconfig | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
> index a2ba5db36145..98c7f19256b1 100644
> --- a/drivers/rtc/Kconfig
> +++ b/drivers/rtc/Kconfig
> @@ -1608,7 +1608,7 @@ config RTC_DRV_MPC5121
>  
>  config RTC_DRV_JZ4740
>   tristate "Ingenic JZ4740 SoC"
> - depends on MACH_INGENIC || COMPILE_TEST
> + depends on MIPS || COMPILE_TEST
>   help
> If you say yes here you get support for the Ingenic JZ47xx SoCs RTC
> controllers.
> -- 
> 2.11.0
> 

-- 
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH] kobject: Access kobject name with caution if state is not initialized

[Greg Kroah-Hartman]

On Mon, Aug 20, 2018 at 10:39:47PM +0530, Srikar Dronamraju wrote:
> If kobject state is not initialized, then its not even certain that
> kobject'name is initialized. Hence when accessing the kobject's name
> tread carefully.
> 
> A stupid module test like
> https://github.com/srikard/tests/blob/master/modules/kobject_test.c
> can panic the system.

Lots of stupid modules can do dumb things.  Just don't do that.  The
kernel is not built to keep you from doing stupid things in kernel code
:)

So I fail to see why this patch is needed.  What in-kernel code path is
trying to print a kobject's name before it is initialized?  Why not fix
that obvious bug instead of forcing the kernel core to protect from
stupid code?

thanks,

greg k-h

Re: [PATCH] ia64: Fix kernel BUG at lib/ioremap.c:72!

[Linus Torvalds]

On Mon, Aug 20, 2018 at 9:31 AM Tony Luck  wrote:
> I'd suggested an #if !CONFIG_IA64 in the functon, but Arnd
> suggested keeping the fix inside the arch/ia64 tree.
>
> Fixes: 0bbf47eab469 ("ia64: use asm-generic/io.h")

Applied.

Linus

Re: [PATCH] ARM: dts: imx6: Add stdout-path to Wandboard

[Fabio Estevam]

Hi Tuomas,

On Tue, Aug 14, 2018 at 5:47 PM, Tuomas Tynkkynen  wrote:
> Setting a stdout-path in the .dtb is convenient because then the user
> gets a serial console on the RS-232 connector without any extra effort
> of figuring out the relevant 'console=' boot parameter.
>
> Signed-off-by: Tuomas Tynkkynen 

Patch looks good.

Only a minor nit on the Subject line: I would do it like this to make
it consistent:

ARM: dts: imx6qdl-wandboard: Add stdout-path

Reviewed-by: Fabio Estevam 

Re: [PATCH] x86/spectre: Expand test for vulnerability to empty RSB exploits

[Thomas Gleixner]

On Tue, 7 Aug 2018, Jim Mattson wrote:

> Skylake-era Intel CPUs are vulnerable to exploits of empty RSB
> conditions. On hardware, platform vulnerability can be determined
> simply by checking the processor's DisplayModel/DisplayFamily
> signature.  However, when running in a VM, the operating system should
> also query IA32_ARCH_CAPABILITIES.RSBA[bit 2], a synthetic bit that
> can be set by a hypervisor to indicate that the VM might run on a
> vulnerable physical processor, regardless of the
> DisplayModel/DisplayFamily reported by CPUID.
> 
> Note that IA32_ARCH_CAPABILITIES.RSBA[bit 2] is always clear on
> hardware, so the DisplayModel/DisplayFamily check is still required.
> 
> For all of the details, see the Intel white paper, "Retpoline: A
> Branch Target Injection Mitigation" (document number 337131-001),
> section 5.3: Virtual Machine CPU Identification.
> 
> Signed-off-by: Jim Mattson 
> Reviewed-by: Peter Shier 

That has been superseeded by:

  fdf82a7856b3 ("x86/speculation: Protect against userspace-userspace 
spectreRSB")

right? At least it does not apply anymore...

Thanks,

tglx

[tip:x86/urgent] x86/process: Re-export start_thread()

[tip-bot for Rian Hunter]

Commit-ID:  dc76803e57cc86589c4efcb5362918f9b0c0436f
Gitweb: https://git.kernel.org/tip/dc76803e57cc86589c4efcb5362918f9b0c0436f
Author: Rian Hunter 
AuthorDate: Sun, 19 Aug 2018 16:08:53 -0700
Committer:  Thomas Gleixner 
CommitDate: Mon, 20 Aug 2018 18:04:42 +0200

x86/process: Re-export start_thread()

The consolidation of the start_thread() functions removed the export
unintentionally. This breaks binfmt handlers built as a module.

Add it back.

Fixes: e634d8fc792c ("x86-64: merge the standard and compat start_thread() 
functions")
Signed-off-by: Rian Hunter 
Signed-off-by: Thomas Gleixner 
Cc: "H. Peter Anvin" 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Vitaly Kuznetsov 
Cc: Joerg Roedel 
Cc: Dmitry Safonov 
Cc: Josh Poimboeuf 
Cc: sta...@vger.kernel.org
Link: https://lkml.kernel.org/r/20180819230854.7275-1-r...@alum.mit.edu

---
 arch/x86/kernel/process_64.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/kernel/process_64.c b/arch/x86/kernel/process_64.c
index 476e3ddf8890..a451bc374b9b 100644
--- a/arch/x86/kernel/process_64.c
+++ b/arch/x86/kernel/process_64.c
@@ -384,6 +384,7 @@ start_thread(struct pt_regs *regs, unsigned long new_ip, 
unsigned long new_sp)
start_thread_common(regs, new_ip, new_sp,
__USER_CS, __USER_DS, 0);
 }
+EXPORT_SYMBOL_GPL(start_thread);
 
 #ifdef CONFIG_COMPAT
 void compat_start_thread(struct pt_regs *regs, u32 new_ip, u32 new_sp)

[tip:x86/urgent] x86/vdso: Fix vDSO build if a retpoline is emitted

[tip-bot for Andy Lutomirski]

Commit-ID:  2e549b2ee0e358bc758480e716b881f9cabedb6a
Gitweb: https://git.kernel.org/tip/2e549b2ee0e358bc758480e716b881f9cabedb6a
Author: Andy Lutomirski 
AuthorDate: Thu, 16 Aug 2018 12:41:15 -0700
Committer:  Thomas Gleixner 
CommitDate: Mon, 20 Aug 2018 18:04:41 +0200

x86/vdso: Fix vDSO build if a retpoline is emitted

Currently, if the vDSO ends up containing an indirect branch or
call, GCC will emit the "external thunk" style of retpoline, and it
will fail to link.

Fix it by building the vDSO with inline retpoline thunks.

I haven't seen any reports of this triggering on an unpatched
kernel.

Fixes: commit 76b043848fd2 ("x86/retpoline: Add initial retpoline support")
Signed-off-by: Andy Lutomirski 
Signed-off-by: Thomas Gleixner 
Acked-by: Matt Rickard 
Cc: Borislav Petkov 
Cc: Jason Vas Dias 
Cc: David Woodhouse 
Cc: Peter Zijlstra 
Cc: Andi Kleen 
Cc: sta...@vger.kernel.org
Link: 
https://lkml.kernel.org/r/c76538cd3afbe19c6246c2d1715bc6a60bd63985.1534448381.git.l...@kernel.org

---
 Makefile | 4 
 arch/x86/entry/vdso/Makefile | 6 --
 2 files changed, 8 insertions(+), 2 deletions(-)

diff --git a/Makefile b/Makefile
index a0650bf79606..7bab2e90e4e1 100644
--- a/Makefile
+++ b/Makefile
@@ -507,9 +507,13 @@ KBUILD_AFLAGS += $(call cc-option, -no-integrated-as)
 endif
 
 RETPOLINE_CFLAGS_GCC := -mindirect-branch=thunk-extern 
-mindirect-branch-register
+RETPOLINE_VDSO_CFLAGS_GCC := -mindirect-branch=thunk-inline 
-mindirect-branch-register
 RETPOLINE_CFLAGS_CLANG := -mretpoline-external-thunk
+RETPOLINE_VDSO_CFLAGS_CLANG := -mretpoline
 RETPOLINE_CFLAGS := $(call cc-option,$(RETPOLINE_CFLAGS_GCC),$(call 
cc-option,$(RETPOLINE_CFLAGS_CLANG)))
+RETPOLINE_VDSO_CFLAGS := $(call cc-option,$(RETPOLINE_VDSO_CFLAGS_GCC),$(call 
cc-option,$(RETPOLINE_VDSO_CFLAGS_CLANG)))
 export RETPOLINE_CFLAGS
+export RETPOLINE_VDSO_CFLAGS
 
 KBUILD_CFLAGS  += $(call cc-option,-fno-PIE)
 KBUILD_AFLAGS  += $(call cc-option,-fno-PIE)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index 9f695f517747..fa3f439f0a92 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -68,9 +68,9 @@ $(obj)/vdso-image-%.c: $(obj)/vdso%.so.dbg $(obj)/vdso%.so 
$(obj)/vdso2c FORCE
 CFL := $(PROFILING) -mcmodel=small -fPIC -O2 -fasynchronous-unwind-tables -m64 
\
$(filter -g%,$(KBUILD_CFLAGS)) $(call cc-option, -fno-stack-protector) \
-fno-omit-frame-pointer -foptimize-sibling-calls \
-   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO
+   -DDISABLE_BRANCH_PROFILING -DBUILD_VDSO $(RETPOLINE_VDSO_CFLAGS)
 
-$(vobjs): KBUILD_CFLAGS := $(filter-out 
$(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
+$(vobjs): KBUILD_CFLAGS := $(filter-out $(GCC_PLUGINS_CFLAGS) 
$(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS)) $(CFL)
 
 #
 # vDSO code runs in userspace and -pg doesn't help with profiling anyway.
@@ -132,11 +132,13 @@ KBUILD_CFLAGS_32 := $(filter-out 
-mcmodel=kernel,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -fno-pic,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out -mfentry,$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 := $(filter-out $(GCC_PLUGINS_CFLAGS),$(KBUILD_CFLAGS_32))
+KBUILD_CFLAGS_32 := $(filter-out $(RETPOLINE_CFLAGS),$(KBUILD_CFLAGS_32))
 KBUILD_CFLAGS_32 += -m32 -msoft-float -mregparm=0 -fpic
 KBUILD_CFLAGS_32 += $(call cc-option, -fno-stack-protector)
 KBUILD_CFLAGS_32 += $(call cc-option, -foptimize-sibling-calls)
 KBUILD_CFLAGS_32 += -fno-omit-frame-pointer
 KBUILD_CFLAGS_32 += -DDISABLE_BRANCH_PROFILING
+KBUILD_CFLAGS_32 += $(RETPOLINE_VDSO_CFLAGS)
 $(obj)/vdso32.so.dbg: KBUILD_CFLAGS = $(KBUILD_CFLAGS_32)
 
 $(obj)/vdso32.so.dbg: FORCE \

[tip:x86/urgent] x86/mce: Add notifier_block forward declaration

[tip-bot for Arnd Bergmann]

Commit-ID:  704ae091b061082b37a9968621af4c290c641d50
Gitweb: https://git.kernel.org/tip/704ae091b061082b37a9968621af4c290c641d50
Author: Arnd Bergmann 
AuthorDate: Fri, 17 Aug 2018 12:01:36 +0200
Committer:  Thomas Gleixner 
CommitDate: Mon, 20 Aug 2018 18:04:42 +0200

x86/mce: Add notifier_block forward declaration

Without linux/irq.h, there is no declaration of notifier_block, leading to
a build warning:

In file included from arch/x86/kernel/cpu/mcheck/threshold.c:10:
arch/x86/include/asm/mce.h:151:46: error: 'struct notifier_block' declared 
inside parameter list will not be visible outside of this definition or 
declaration [-Werror]

It's sufficient to declare the struct tag here, which avoids pulling in
more header files.

Fixes: 447ae3166702 ("x86: Don't include linux/irq.h from asm/hardirq.h")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Thomas Gleixner 
Cc: Nicolai Stange 
Cc: "H. Peter Anvin" 
Cc: Greg Kroah-Hartman 
Cc: Borislav Petkov 
Link: https://lkml.kernel.org/r/20180817100156.3009043-1-a...@arndb.de

---
 arch/x86/include/asm/mce.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/x86/include/asm/mce.h b/arch/x86/include/asm/mce.h
index 8c7b3e5a2d01..3a17107594c8 100644
--- a/arch/x86/include/asm/mce.h
+++ b/arch/x86/include/asm/mce.h
@@ -148,6 +148,7 @@ enum mce_notifier_prios {
MCE_PRIO_LOWEST = 0,
 };
 
+struct notifier_block;
 extern void mce_register_decode_chain(struct notifier_block *nb);
 extern void mce_unregister_decode_chain(struct notifier_block *nb);
 

[PATCH] ia64: Fix kernel BUG at lib/ioremap.c:72!

[Tony Luck]

Commit:
  0bbf47eab469 ("ia64: use asm-generic/io.h")

results in a BUG while booting ia64.  This is because
asm-generic/io.h defines PCI_IOBASE, which results in
the function acpi_pci_root_remap_iospace() doing a lot
of unnecessary (and wrong) things.

I'd suggested an #if !CONFIG_IA64 in the functon, but Arnd
suggested keeping the fix inside the arch/ia64 tree.

Fixes: 0bbf47eab469 ("ia64: use asm-generic/io.h")
Suggested-by: Arnd Bergman 
Signed-off-by: Tony Luck 
---
 arch/ia64/include/asm/io.h | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/ia64/include/asm/io.h b/arch/ia64/include/asm/io.h
index 6f952171abf9..1e6fef69bb01 100644
--- a/arch/ia64/include/asm/io.h
+++ b/arch/ia64/include/asm/io.h
@@ -454,6 +454,7 @@ extern void memset_io(volatile void __iomem *s, int c, long 
n);
 #define xlate_dev_kmem_ptr xlate_dev_kmem_ptr
 #define xlate_dev_mem_ptr xlate_dev_mem_ptr
 #include 
+#undef PCI_IOBASE
 
 # endif /* __KERNEL__ */
 
-- 
2.17.1

Re: [PATCH 1/3] iio: adxl372: Provide validate_trigger and validate_device callbacks

[jic23]

On 20.08.2018 16:47, Lars-Peter Clausen wrote:

On 08/20/2018 04:53 PM, Stefan Popa wrote:
This patch provides a validate_device callback for the trigger which 
makes

sure that other devices are rejected.

Signed-off-by: Stefan Popa @@ -762,11 +762,24 @@ static int adxl372_dready_trig_set_state(struct 
iio_trigger *trig,

return adxl372_set_interrupts(st, mask, 0);
 }

+static int adxl372_validate_trigger(struct iio_dev *indio_dev,
+   struct iio_trigger *trig)
+{
+   struct adxl372_state *st = iio_priv(indio_dev);
+
+   if (st->dready_trig != trig)
+   return -EINVAL;
+
+   return 0;
+}
+
 static const struct iio_trigger_ops adxl372_trigger_ops = {
+   .validate_device = _trigger_validate_own_device,
.set_trigger_state = adxl372_dready_trig_set_state,
 };

 static const struct iio_info adxl372_info = {
+   .validate_trigger = _validate_trigger,


I wonder, if the device only works with the trigger and the trigger 
only

works with the device should we actually register a trigger?

Seems to be just extra hassle when setting up the device without any 
extra

benefits.


I wondered the same, but there is a reason to do this if we think we
will eventually have support for other triggers (which looks possible 
for

this device as we can bypass the fifo).  Then we want to do it in order
to avoid a breaking ABI change.  There is a way around that by setting
a default trigger so that it'll still use this one unless it is 
explicitly

set but that is rather ugly!

Jonathan

Re: [PATCH v9 12/22] s390: vfio-ap: sysfs interfaces to configure control domains

[Halil Pasic]

On 08/20/2018 04:23 PM, Cornelia Huck wrote:

On Mon, 13 Aug 2018 17:48:09 -0400
Tony Krowiak  wrote:


From: Tony Krowiak 

Provides the sysfs interfaces for:

1. Assigning AP control domains to the mediated matrix device

2. Unassigning AP control domains from a mediated matrix device

3. Displaying the control domains assigned to a mediated matrix
device

The IDs of the AP control domains assigned to the mediated matrix
device are stored in an AP domain mask (ADM). The bits in the ADM,
from most significant to least significant bit, correspond to
AP domain numbers 0 to 255. On some systems, the maximum allowable
domain number may be less than 255 - depending upon the host's
AP configuration - and assignment may be rejected if the input
domain ID exceeds the limit.


Please remind me of the relationship between control domains and usage
domains... IIRC, usage domains allow both requests and configuration,
while control domains allow only configuration, and are by convention a
superset of usage domains.



The whole terminology with control and usage domains is IMHO a bit
confusing. With the HMC one can assign a domain either as a 'Control'
or as a 'Control and Usage' domain.

Regarding the masks in the CRYCB, the AQM controls 'using' the domain
(e.g. if AQM bit is zero NQAP will refuse to enqueue on that queue)
while ADM tells if the guest is allowed to 'change' the given domain.
Whether a command-request is of type 'using' or 'changing' is a property
of the command request.

You can think of 'using' a domain like signing stuff with a key residing
within the domain, and of 'changing' a domain like issuing a command to
generate a new key for the given domain.



Is there a hard requirement somewhere in there, or can the admin
cheerfully use different masks for usage domains and control domains
without the SIE choking on it?



It is a convention. AFAIR it ain't architecture. SIE won't choke on it
I've tried it out. I was arguing along the lines that the kernel should
not enforce this convention -- tooling can still do that if we want this
enforced.

Regards,
Halil

Re: [PATCH RFC] mm: don't miss the last page because of round-off error

[Roman Gushchin]

On Fri, Aug 17, 2018 at 06:22:13PM -0700, Matthew Wilcox wrote:
> On Fri, Aug 17, 2018 at 04:18:34PM -0700, Roman Gushchin wrote:
> > -   scan = div64_u64(scan * fraction[file],
> > -denominator);
> > +   if (scan > 1)
> > +   scan = div64_u64(scan * fraction[file],
> > +denominator);
> 
> Wouldn't we be better off doing a div_round_up?  ie:
> 
>   scan = div64_u64(scan * fraction[file] + denominator - 1, denominator);
> 
> although i'd rather hide that in a new macro in math64.h than opencode it
> here.

Good idea! Will do in v2.

Thanks!

Re: [PATCH v8 1/2] PCI: pciehp: Ignore link events when there is a fatal error pending

[Lukas Wunner]

On Mon, Aug 20, 2018 at 12:59:05PM -0400, Sinan Kaya wrote:
> On 8/20/2018 5:22 AM, Lukas Wunner wrote:
> > > +
> > This differs from v7 of the patch in that*any*  fatal error, not just
> > a Surprise Link Down, results in pciehp waiting for the error to clear.
> > 
> > I'm wondering if that's safe:  Theoretically, the user might quickly
> > swap the card in the slot during, say, a Completion Timeout Error,
> > and with this patch pciehp would carry on as if nothing happened.
> 
> Functionally both patches are identical. The v7 was still allowing
> AER/DPC to handle all fatal error events except Surprise Link Down.
> 
> Now, second patch (v8 2/2) is masking the surprise link down event
> as we have talked before. Therefore, there is no need to filter
> out incoming errors by reading the status register and masking the
> unwanted bits.

Ok, missed that.


> Just to clarify something, this patch will wait for only the FATAL
> error events to be handled by the error handling services only.
> 
> Completion Timeout is a NONFATAL error event by default unless
> somebody tweaks the severity bits.
> 
> Anyhow, all FATAL errors cause one sort of link down either
> initiated by software (AER) or hardware (DPC).
> Therefore, hotplug driver will observe a link down event and
> AER/DPC needs to handle the event as usual.

Thanks for the clarification.

Lukas

Re: [PATCH v8 2/2] PCI: pciehp: Mask AER surprise link down error if hotplug is enabled

[Sinan Kaya]

On 8/20/2018 4:21 AM, Lukas Wunner wrote:

On Fri, Aug 17, 2018 at 11:51:10PM -0700, Sinan Kaya wrote:

+static int pciehp_control_surprise_error(struct controller *ctrl, bool enable)


The return value isn't checked, so this could return void.



Sure, I can do that.




@@ -280,6 +303,9 @@ static int pciehp_probe(struct pcie_device *dev)
  
  	pciehp_check_presence(ctrl);
  
+	/* We want exclusive control of link down events in hotplug driver */

+   pciehp_control_surprise_error(ctrl, false);
+
return 0;


Hm, if the platform firmware hasn't granted native hotplug control to OSPM,
or if some other hotplug driver than pciehp is used, shouldn't surprise down
be ignored by error recovery as well?  If yes, the mask would have to be set
in generic code somewhere in drivers/pci/probe.c I guess, based on the
is_hotplug_bridge bit in struct pci_dev.


I could move this code if we know that is_hotplug_bridge flag is set
regardless of OS hotplug driver control or not.




(Interestingly, PCI_ERR_UNCOR_MASK is already changed in probe.c by
program_hpp_type2().  That seems to be ACPI-specific code, which kind
of begs the question why it's not in pci-acpi.c?)


Yes, you can tell the OS what AER mask to set following hotplug
insertion via ACPI HPP table especially if you remove a hotplug bridge.
This is used during ACPI hotplug.



Thanks,

Lukas

Re: [PATCH v2] fpga: dfl: region: Restory symmetry in probe()/remove()

[Moritz Fischer]

Hi Alan,

On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer  wrote:
> 
> Hi Moritz,
> 
> > Replace dev_get_drvdata() with platform_get_drvdata() to
> > match the platform_set_drvdata() in the probe function of
> > the platform driver.
> >
> > Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for 
> > FME")
> > Signed-off-by: Moritz Fischer 
> > ---
> >
> > Changes from v1:
> > - Still compile after change ...
> >
> > ---
> >  drivers/fpga/dfl-fme-region.c | 2 +-
> 
> Thanks for catching this.  of-fpga-region.c does a similar thing and
> needs s/dev_set_drvdata/platform_set_drvdata/ in the probe.  Could you
> fix it here too?

Yeah, can do in a v3 series ... Will add your Suggested-by: ...

Cheers,

Moritz

[PATCH 0/3] ARM: OMAP1: ams-delta: Clean up GPIO setup for MODEM

[Janusz Krzysztofik]

Convert modem related GPIO setup from integer space to GPIO descriptors.
Also, restore original initialization order of the MODEM device and its
related GPIO pins.

Cleanup of MODEM relaated regulator setup is postponed while waiting for
upcoming conversion of fixed regulator API to GPIO descriptors.


Janusz Krzysztofik (3):
  ARM: OMAP1: ams-delta: assign MODEM IRQ from GPIO descriptor
  ARM: OMAP1: ams-delta: initialize latch2 pins to safe values
  ARM: OMAP1: ams-delta: register MODEM device earlier


diffstat:
 board-ams-delta.c |  120 +++---
 board-ams-delta.h |7 ---
 2 files changed, 88 insertions(+), 39 deletions(-)

[PATCH 1/3] ARM: OMAP1: ams-delta: assign MODEM IRQ from GPIO descriptor

[Janusz Krzysztofik]

Don't request MODEM IRQ GPIO by its global number in
ams_delta_modem_init().  Instead, obtain its GPIO descriptor
and assign related IRQ to the MODEM.  Do that from
omap_gpio_deps_init(), where the chip is already looked up.  Then, in
ams_delta_modem_init(), just check for the IRQ number having been
already assigned.

Signed-off-by: Janusz Krzysztofik 
---
 arch/arm/mach-omap1/board-ams-delta.c | 46 ++-
 1 file changed, 35 insertions(+), 11 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index 34cb63ff45b3..b3fe515b6f49 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -630,6 +630,28 @@ static struct gpiod_hog ams_delta_gpio_hogs[] = {
{},
 };
 
+static struct plat_serial8250_port ams_delta_modem_ports[];
+
+/*
+ * Obtain MODEM IRQ GPIO descriptor using its hardware pin
+ * number and assign related IRQ number to the MODEM port.
+ * Keep the GPIO descriptor open so nobody steps in.
+ */
+static void __init modem_assign_irq(struct gpio_chip *chip)
+{
+   struct gpio_desc *gpiod;
+
+   gpiod = gpiochip_request_own_desc(chip, AMS_DELTA_GPIO_PIN_MODEM_IRQ,
+ "modem_irq");
+   if (IS_ERR(gpiod)) {
+   pr_err("%s: modem IRQ GPIO request failed (%ld)\n", __func__,
+  PTR_ERR(gpiod));
+   } else {
+   gpiod_direction_input(gpiod);
+   ams_delta_modem_ports[0].irq = gpiod_to_irq(gpiod);
+   }
+}
+
 /*
  * The purpose of this function is to take care of proper initialization of
  * devices and data structures which depend on GPIO lines provided by OMAP GPIO
@@ -649,7 +671,13 @@ static void __init omap_gpio_deps_init(void)
return;
}
 
+   /*
+* Start with FIQ initialization as it may have to request
+* and release successfully each OMAP GPIO pin in turn.
+*/
ams_delta_init_fiq(chip, _delta_serio_device);
+
+   modem_assign_irq(chip);
 }
 
 static void __init ams_delta_init(void)
@@ -844,20 +872,18 @@ static int __init modem_nreset_init(void)
 }
 
 
+/*
+ * This function expects MODEM IRQ number already assigned to the port
+ * and fails if it's not.
+ */
 static int __init ams_delta_modem_init(void)
 {
int err;
 
-   omap_cfg_reg(M14_1510_GPIO2);
-   ams_delta_modem_ports[0].irq =
-   gpio_to_irq(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+   if (ams_delta_modem_ports[0].irq < 0)
+   return ams_delta_modem_ports[0].irq;
 
-   err = gpio_request(AMS_DELTA_GPIO_PIN_MODEM_IRQ, "modem");
-   if (err) {
-   pr_err("Couldn't request gpio pin for modem\n");
-   return err;
-   }
-   gpio_direction_input(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
+   omap_cfg_reg(M14_1510_GPIO2);
 
/* Initialize the modem_nreset regulator consumer before use */
modem_priv.regulator = ERR_PTR(-ENODEV);
@@ -866,8 +892,6 @@ static int __init ams_delta_modem_init(void)
AMS_DELTA_LATCH2_MODEM_CODEC);
 
err = platform_device_register(_delta_modem_device);
-   if (err)
-   gpio_free(AMS_DELTA_GPIO_PIN_MODEM_IRQ);
 
return err;
 }
-- 
2.16.4

[PATCH 3/3] ARM: OMAP1: ams-delta: register MODEM device earlier

[Janusz Krzysztofik]

Amstrad Delta MODEM device used to be initialized at arch_initcall
before it was once moved to late_initcall by commit f7519d8c8290 ("ARM:
OMAP1: ams-delta: register latch dependent devices later"). The purpose
of that change was to postpone initialization of devices which depended
on latch2 pins until latch2 converted to GPIO device was ready.

After recent fixes to GPIO handling, it was possible to moove
registration of most of those device back to where they were before.
The same can be safely done with the MODEM device as initialization
of GPIO pins it depends on was moved to machine_init by preceding
patch.

Move registration of the MODEM device to arch_initcall_sync, not to
arch_initcall, so it is never exposed to potential conflictinh
registration order hazard against OMAP serial ports.

Signed-off-by: Janusz Krzysztofik 
---
 arch/arm/mach-omap1/board-ams-delta.c | 22 ++
 1 file changed, 18 insertions(+), 4 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index c865c6921af8..a98783f98f3a 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -896,11 +896,28 @@ static int __init modem_nreset_init(void)
 /*
  * This function expects MODEM IRQ number already assigned to the port
  * and fails if it's not.
+ * The MODEM device requires its RESET# pin kept high during probe.
+ * That requirement can be fulfilled in several ways:
+ * - with a descriptor of already functional modem_nreset regulator
+ *   assigned to the MODEM private data,
+ * - with the regulator not yet controlled by modem_pm function but
+ *   already enabled by default on probe,
+ * - before the modem_nreset regulator is probed, with the pin already
+ *   set high explicitly.
+ * The last one is already guaranteed by ams_delta_latch2_init() called
+ * from machine_init.
+ * In order to avoid taking over ttyS0 device slot, the MODEM device
+ * should be registered after OMAP serial ports.  Since those ports
+ * are registered at arch_initcall, this function can be called safely
+ * at arch_initcall_sync earliest.
  */
 static int __init ams_delta_modem_init(void)
 {
int err;
 
+   if (!machine_is_ams_delta())
+   return -ENODEV;
+
if (ams_delta_modem_ports[0].irq < 0)
return ams_delta_modem_ports[0].irq;
 
@@ -913,6 +930,7 @@ static int __init ams_delta_modem_init(void)
 
return err;
 }
+arch_initcall_sync(ams_delta_modem_init);
 
 static int __init late_init(void)
 {
@@ -922,10 +940,6 @@ static int __init late_init(void)
if (err)
return err;
 
-   err = ams_delta_modem_init();
-   if (err)
-   return err;
-
/*
 * Once the modem device is registered, the modem_nreset
 * regulator can be requested on behalf of that device.
-- 
2.16.4

[PATCH 2/3] ARM: OMAP1: ams-delta: initialize latch2 pins to safe values

[Janusz Krzysztofik]

Latch2 pins control a number of on-board devices, namely LCD, NAND,
MODEM and CODEC.  Those pins used to be initialized with safe values
from init_machine before that operation was:
1) moved to late_initcall in preparation for conversion of latch2 to
GPIO device - see commit f7519d8c8290 ("ARM: OMAP1: ams-delta: register
latch dependent devices later"),
2) replaced with non-atomic initialization performed by means of
gpio_request_array() - see commit 937eb4bb0058 ("ARM: OMAP1: ams-delta:
convert latches to basic_mmio_gpio"),
3) made completely asynchronous by delegation of GPIO request
operations performed on subsets of pins to respective device drivers in
subsequent commits.

One visible negative result of that disintegration was corrupt keyboard
data reported by serio driver, recently fixed by commit 41f8fee385a0
("ARM: OMAP1: ams-delta: Hog "keybrd_dataout" GPIO pin").

Moreover, initialization of LATCH2_PIN_MODEM_CODEC still performed with
ams_delta_latch2_write() wrapper from late_init() is now done on not
requested GPIO pin.

Reintroduce atomic initialization of latch2 pins at machine_init to
prevent from random values potentially corrupting NAND data or maybe
even destroing other hardware.  Also take care of MODEM/CODEC related
pins so MODEM device probe succeeds even if latch2 GPIO device or
dependent regulator is not ready and CODEC can be reached over the
MODEM even if audio driver doesn't take control over
LATCH2_PIN_MODEM_CODEC.

Once done, remove the no longer needed GPIO based implementation of
ams_delta_latch_write() and its frontend macro.

Signed-off-by: Janusz Krzysztofik 
---
 arch/arm/mach-omap1/board-ams-delta.c | 52 +++
 arch/arm/mach-omap1/board-ams-delta.h |  7 -
 2 files changed, 35 insertions(+), 24 deletions(-)

diff --git a/arch/arm/mach-omap1/board-ams-delta.c 
b/arch/arm/mach-omap1/board-ams-delta.c
index b3fe515b6f49..c865c6921af8 100644
--- a/arch/arm/mach-omap1/board-ams-delta.c
+++ b/arch/arm/mach-omap1/board-ams-delta.c
@@ -321,20 +321,6 @@ struct modem_private_data {
 
 static struct modem_private_data modem_priv;
 
-void ams_delta_latch_write(int base, int ngpio, u16 mask, u16 value)
-{
-   int bit = 0;
-   u16 bitpos = 1 << bit;
-
-   for (; bit < ngpio; bit++, bitpos = bitpos << 1) {
-   if (!(mask & bitpos))
-   continue;
-   else
-   gpio_set_value(base + bit, (value & bitpos) != 0);
-   }
-}
-EXPORT_SYMBOL(ams_delta_latch_write);
-
 static struct resource ams_delta_nand_resources[] = {
[0] = {
.start  = OMAP1_MPUIO_BASE,
@@ -680,6 +666,40 @@ static void __init omap_gpio_deps_init(void)
modem_assign_irq(chip);
 }
 
+/*
+ * Initialize latch2 pins with values which are safe for dependent on-board
+ * devices or useful for their successull initialization even before GPIO
+ * driver takes control over the latch pins:
+ * - LATCH2_PIN_LCD_VBLEN  = 0
+ * - LATCH2_PIN_LCD_NDISP  = 0 Keep LCD device powered off before its
+ * driver takes control over it.
+ * - LATCH2_PIN_NAND_NCE   = 0
+ * - LATCH2_PIN_NAND_NWP   = 0 Keep NAND device down and write-
+ * protected before its driver takes
+ * control over it.
+ * - LATCH2_PIN_KEYBRD_PWR = 0 Keep keyboard powered off before serio
+ * driver takes control over it.
+ * - LATCH2_PIN_KEYBRD_DATAOUT = 0 Keep low to avoid corruption of first
+ * byte of data received from attached
+ * keyboard when serio device is probed;
+ * the pin is also hogged low by the latch2
+ * GPIO driver as soon as it is ready.
+ * - LATCH2_PIN_MODEM_NRESET   = 1 Enable voice MODEM device, allowing for
+ * its successful probe even before a
+ * regulator it depends on, which in turn
+ * takes control over the pin, is set up.
+ * - LATCH2_PIN_MODEM_CODEC= 1 Attach voice MODEM CODEC data port
+ * to the MODEM so the CODEC is under
+ * control even if audio driver doesn't
+ * take it over.
+ */
+static void __init ams_delta_latch2_init(void)
+{
+   u16 latch2 = 1 << LATCH2_PIN_MODEM_NRESET | 1 << LATCH2_PIN_MODEM_CODEC;
+
+   __raw_writew(latch2, LATCH2_VIRT);
+}
+
 static void __init ams_delta_init(void)
 {
/* mux pins for uarts */
@@ -701,6 +721,7 @@ static void __init ams_delta_init(void)
omap_cfg_reg(J18_1610_CAM_D7);
 
omap_gpio_deps_init();
+   ams_delta_latch2_init();
gpiod_add_hogs(ams_delta_gpio_hogs);
 

Re: [PATCH] scripts/dtc: consolidate include path options in Makefile

[Frank Rowand]

On 07/03/18 18:59, Masahiro Yamada wrote:
> It is tedious to specify extra compiler options for every file.
> HOST_EXTRACFLAGS is useful to add options to all files in a
> directory.
> 
> -I$(src)/libfdt is needed for all the files in this directory
> to include libfdt_env.h etc. from scripts/dtc/libfdt/.
> 
> On the other hand, -I$(src) is used to include check-in headers
> from generated C files.  Thus, I added it only to dtc-lexer.lex.o
> and dtc-parser.tab.o .
> 
> Signed-off-by: Masahiro Yamada 
> ---
> 
>  scripts/dtc/Makefile | 18 --
>  1 file changed, 4 insertions(+), 14 deletions(-)
> 
> diff --git a/scripts/dtc/Makefile b/scripts/dtc/Makefile
> index 9cac65b..1c943e0 100644
> --- a/scripts/dtc/Makefile
> +++ b/scripts/dtc/Makefile
> @@ -9,21 +9,11 @@ dtc-objs:= dtc.o flattree.o fstree.o data.o livetree.o 
> treesource.o \
>  dtc-objs += dtc-lexer.lex.o dtc-parser.tab.o
>  
>  # Source files need to get at the userspace version of libfdt_env.h to 
> compile
> +HOST_EXTRACFLAGS := -I$(src)/libfdt

Shouldn't that be += instead of :=?

-Frank

>  
> -HOSTCFLAGS_DTC := -I$(src) -I$(src)/libfdt
> -
> -HOSTCFLAGS_checks.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_data.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_dtc.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_flattree.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_fstree.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_livetree.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_srcpos.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_treesource.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_util.o := $(HOSTCFLAGS_DTC)
> -
> -HOSTCFLAGS_dtc-lexer.lex.o := $(HOSTCFLAGS_DTC)
> -HOSTCFLAGS_dtc-parser.tab.o := $(HOSTCFLAGS_DTC)
> +# Generated files need one more search path to include headers in source tree
> +HOSTCFLAGS_dtc-lexer.lex.o := -I$(src)
> +HOSTCFLAGS_dtc-parser.tab.o := -I$(src)
>  
>  # dependencies on generated files need to be listed explicitly
>  $(obj)/dtc-lexer.lex.o: $(obj)/dtc-parser.tab.h
> 

Re: cgroup aware oom killer (was Re: [PATCH 0/3] introduce memory.oom.group)

[Roman Gushchin]

On Sun, Aug 19, 2018 at 04:26:50PM -0700, David Rientjes wrote:
> Roman, have you had time to go through this?

Hm, I thought we've finished this part of discussion, no?
Anyway, let me repeat my position: I don't like the interface
you've proposed in that follow-up patchset, and I explained why.
If you've a new proposal, please, rebase it to the current
mm tree, and we can discuss it separately.
Alternatively, we can discuss the interface first (without
the implementation), but, please, make a new thread with a
fresh description of a proposed interface.

Thanks!

> 
> 
> On Tue, 7 Aug 2018, David Rientjes wrote:
> 
> > On Mon, 6 Aug 2018, Roman Gushchin wrote:
> > 
> > > > In a cgroup-aware oom killer world, yes, we need the ability to specify 
> > > > that the usage of the entire subtree should be compared as a single 
> > > > entity with other cgroups.  That is necessary for user subtrees but may 
> > > > not be necessary for top-level cgroups depending on how you structure 
> > > > your 
> > > > unified cgroup hierarchy.  So it needs to be configurable, as you 
> > > > suggest, 
> > > > and you are correct it can be different than oom.group.
> > > > 
> > > > That's not the only thing we need though, as I'm sure you were 
> > > > expecting 
> > > > me to say :)
> > > > 
> > > > We need the ability to preserve existing behavior, i.e. process based 
> > > > and 
> > > > not cgroup aware, for subtrees so that our users who have clear 
> > > > expectations and tune their oom_score_adj accordingly based on how the 
> > > > oom 
> > > > killer has always chosen processes for oom kill do not suddenly regress.
> > > 
> > > Isn't the combination of oom.group=0 and oom.evaluate_together=1 
> > > describing
> > > this case? This basically means that if memcg is selected as target,
> > > the process inside will be selected using traditional per-process 
> > > approach.
> > > 
> > 
> > No, that would overload the policy and mechanism.  We want the ability to 
> > consider user-controlled subtrees as a single entity for comparison with 
> > other user subtrees to select which subtree to target.  This does not 
> > imply that users want their entire subtree oom killed.
> > 
> > > > So we need to define the policy for a subtree that is oom, and I 
> > > > suggest 
> > > > we do that as a characteristic of the cgroup that is oom ("process" vs 
> > > > "cgroup", and process would be the default to preserve what currently 
> > > > happens in a user subtree).
> > > 
> > > I'm not entirely convinced here.
> > > I do agree, that some sub-tree may have a well tuned oom_score_adj,
> > > and it's preferable to keep the current behavior.
> > > 
> > > At the same time I don't like the idea to look at the policy of the OOMing
> > > cgroup. Why exceeding of one limit should be handled different to 
> > > exceeding
> > > of another? This seems to be a property of workload, not a limit.
> > > 
> > 
> > The limit is the property of the mem cgroup, so it's logical that the 
> > policy when reaching that limit is a property of the same mem cgroup.
> > Using the user-controlled subtree example, if we have /david and /roman, 
> > we can define our own policies on oom, we are not restricted to cgroup 
> > aware selection on the entire hierarchy.  /david/oom.policy can be 
> > "process" so that I haven't regressed with earlier kernels, and 
> > /roman/oom.policy can be "cgroup" to target the largest cgroup in your 
> > subtree.
> > 
> > Something needs to be oom killed when a mem cgroup at any level in the 
> > hierarchy is reached and reclaim has failed.  What to do when that limit 
> > is reached is a property of that cgroup.
> > 
> > > > Now, as users who rely on process selection are well aware, we have 
> > > > oom_score_adj to influence the decision of which process to oom kill.  
> > > > If 
> > > > our oom subtree is cgroup aware, we should have the ability to likewise 
> > > > influence that decision.  For example, we have high priority 
> > > > applications 
> > > > that run at the top-level that use a lot of memory and strictly oom 
> > > > killing them in all scenarios because they use a lot of memory isn't 
> > > > appropriate.  We need to be able to adjust the comparison of a cgroup 
> > > > (or 
> > > > subtree) when compared to other cgroups.
> > > > 
> > > > I've also suggested, but did not implement in my patchset because I was 
> > > > trying to define the API and find common ground first, that we have a 
> > > > need 
> > > > for priority based selection.  In other words, define the priority of a 
> > > > subtree regardless of cgroup usage.
> > > > 
> > > > So with these four things, we have
> > > > 
> > > >  - an "oom.policy" tunable to define "cgroup" or "process" for that 
> > > >subtree (and plans for "priority" in the future),
> > > > 
> > > >  - your "oom.evaluate_as_group" tunable to account the usage of the
> > > >subtree as the cgroup's own usage for comparison with others,
> > > > 
> > > >  - an 

Re: [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

[Lina Iyer]

On Sat, Aug 18 2018 at 07:13 -0600, Marc Zyngier wrote:

Hi Lina,

On Fri, 17 Aug 2018 20:10:23 +0100,
Lina Iyer  wrote:


During suspend the system may power down some of the system rails. As a
result, the TLMM hw block may not be operational anymore and wakeup
capable GPIOs will not be detected. The PDC however will be operational
and the GPIOs that are routed to the PDC as IRQs can wake the system up.

To avoid being interrupted twice (for TLMM and once for PDC IRQ) when a
GPIO trips, use TLMM for active and switch to PDC for suspend. When
entering suspend, disable the TLMM wakeup interrupt and instead enable
the PDC IRQ and revert upon resume.

Signed-off-by: Lina Iyer 
---
 drivers/pinctrl/qcom/pinctrl-msm.c | 60 +-
 drivers/pinctrl/qcom/pinctrl-msm.h |  3 ++
 2 files changed, 62 insertions(+), 1 deletion(-)

diff --git a/drivers/pinctrl/qcom/pinctrl-msm.c 
b/drivers/pinctrl/qcom/pinctrl-msm.c
index 03ef1d29d078..17e541f8f09d 100644
--- a/drivers/pinctrl/qcom/pinctrl-msm.c
+++ b/drivers/pinctrl/qcom/pinctrl-msm.c
@@ -37,6 +37,7 @@
 #include "../pinctrl-utils.h"

 #define MAX_NR_GPIO 300
+#define MAX_PDC_IRQ 1024


Where is this value coming from? Is it guaranteed to be an
architectural maximum? Or something that is likely to vary in future
implementations?


 #define PS_HOLD_OFFSET 0x820

 /**
@@ -51,6 +52,7 @@
  * @enabled_irqs:   Bitmap of currently enabled irqs.
  * @dual_edge_irqs: Bitmap of irqs that need sw emulated dual edge
  *  detection.
+ * @pdc_irqs:   Bitmap of wakeup capable irqs.
  * @soc;Reference to soc_data of platform specific data.
  * @regs:   Base address for the TLMM register map.
  */
@@ -68,11 +70,14 @@ struct msm_pinctrl {

DECLARE_BITMAP(dual_edge_irqs, MAX_NR_GPIO);
DECLARE_BITMAP(enabled_irqs, MAX_NR_GPIO);
+   DECLARE_BITMAP(pdc_irqs, MAX_PDC_IRQ);

const struct msm_pinctrl_soc_data *soc;
void __iomem *regs;
 };

+static bool in_suspend;
+
 static int msm_get_groups_count(struct pinctrl_dev *pctldev)
 {
struct msm_pinctrl *pctrl = pinctrl_dev_get_drvdata(pctldev);
@@ -787,8 +792,11 @@ static int msm_gpio_irq_set_wake(struct irq_data *d, 
unsigned int on)

raw_spin_lock_irqsave(>lock, flags);

-   if (pdc_irqd)
+   if (pdc_irqd && !in_suspend) {
irq_set_irq_wake(pdc_irqd->irq, on);
+   on ? set_bit(pdc_irqd->irq, pctrl->pdc_irqs) :
+clear_bit(pdc_irqd->irq, pctrl->pdc_irqs);


I think we'll all survive the two extra lines if you write this as an
'if' statement (unless you're competing for the next IOCCC, and then
you need to up your game a bit).

Also, are you indexing the bitmap using a Linux irq number? If so,
that's an absolute NACK. Out of the box, a Linux IRQ can be up to
NR_IRQS+8196 on arm64, and there are plans to push that to be a much
larger space.


I didn't realize this. I have been using linux IRQ number on this
bitmask and I will need to fix this.


+   }

irq_set_irq_wake(pctrl->irq, on);


I'm a bit worried by the way you call into the irq subsystem with this
spinlock held. Have you run that code with lockdep enabled?


I have not tried lockdep. Will try it.
This specific line is already part of the driver. I added a similar line
irq_set_irq_wake(pdc_irqd->irq) just above following the same pattern.



@@ -920,6 +928,8 @@ static int msm_gpio_pdc_pin_request(struct irq_data *d)
}

irq_set_handler_data(d->irq, irq_get_irq_data(irq));
+   irq_set_handler_data(irq, d);
+   irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);


Could you explain what this is trying to do? I'm trying to understand
this code, but this function isn't in 4.18...


Oh, I have been able to test only on 4.14 so far. The flag does seem to
exist at least, I didn't get a compiler error.

I read this in kernel/irq/chip.c -

If the interrupt chip does not implement the irq_disable callback,
a driver can disable the lazy approach for a particular irq line by
calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can
be used for devices which cannot disable the interrupt at the
device level under certain circumstances and have to use
disable_irq[_nosync] instead.

And interpreted this as something that this would prevent 'relaxed'
disable. I am enabling and disabling the IRQ in suspend path, that I
thought this would help avoid issues caused by late disable. Am I
mistaken?


disable_irq(irq);

return 0;
@@ -1070,6 +1080,54 @@ static void msm_pinctrl_setup_pm_reset(struct 
msm_pinctrl *pctrl)
}
 }

+int __maybe_unused msm_pinctrl_suspend_late(struct device *dev)
+{
+   struct msm_pinctrl *pctrl = dev_get_drvdata(dev);
+   struct irq_data *irqd;
+   int i;
+
+   in_suspend = true;
+   for_each_set_bit(i, pctrl->pdc_irqs, MAX_PDC_IRQ) {
+   irqd = irq_get_handler_data(i);


So this is what I though. You're using the Linux 

Re: [PATCH] locking: Remove an insn from spin and write locks

[Waiman Long]

On 08/20/2018 11:50 AM, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 11:14:04AM -0400, Waiman Long wrote:
>> On 08/20/2018 11:06 AM, Matthew Wilcox wrote:
>>> Both spin locks and write locks currently do:
>>>
>>>  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
>>>  85 c0   test   %eax,%eax
>>>  75 05   jne[slowpath]
>>>
>>> This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
>>> appropriately.  Peter pointed out that using atomic_try_cmpxchg()
>>> will let the compiler know this is true.  Comparing before/after
>>> disassemblies show the only effect is to remove this insn.
> ...
>>>  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
>>>  {
>>> +   u32 val = 0;
>>> +
>>> if (!atomic_read(>val) &&
>>> -  (atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL) == 0))
>>> +   (atomic_try_cmpxchg(>val, , _Q_LOCKED_VAL)))
>> Should you keep the _acquire suffix?
> I don't know ;-)  Probably.  Peter didn't include it as part of his
> suggested fix, but on reviewing the documentation, it seems likely that
> it should be retained.  I put them back in and (as expected) it changes
> nothing on x86-64.

We will certainly need to keep the _acquire suffix or it will likely
regress performance for arm64.

>> BTW, qspinlock and qrwlock are now also used by AArch64, mips and sparc.
>> Have you tried to see what the effect will be for those architecture?
> Nope!  That's why I cc'd linux-arch, because I don't know who (other
> than arm64 and x86) is using q-locks these days.

I think both Sparc and mips are using qlocks now, though these
architectures are not the ones that I am interested in. I do like to
make sure that there will be no regression for arm64. Will should be
able to answer that.

Cheers,
Longman

Re: [PATCH] locking: Remove an insn from spin and write locks

[Peter Zijlstra]

On Mon, Aug 20, 2018 at 08:50:02AM -0700, Matthew Wilcox wrote:
> On Mon, Aug 20, 2018 at 11:14:04AM -0400, Waiman Long wrote:
> > On 08/20/2018 11:06 AM, Matthew Wilcox wrote:
> > > Both spin locks and write locks currently do:
> > >
> > >  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
> > >  85 c0   test   %eax,%eax
> > >  75 05   jne[slowpath]
> > >
> > > This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
> > > appropriately.  Peter pointed out that using atomic_try_cmpxchg()
> > > will let the compiler know this is true.  Comparing before/after
> > > disassemblies show the only effect is to remove this insn.
> ...
> > >  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
> > >  {
> > > + u32 val = 0;
> > > +
> > >   if (!atomic_read(>val) &&
> > > -(atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL) == 0))
> > > + (atomic_try_cmpxchg(>val, , _Q_LOCKED_VAL)))
> > 
> > Should you keep the _acquire suffix?
> 
> I don't know ;-)  Probably.  Peter didn't include it as part of his
> suggested fix, but on reviewing the documentation, it seems likely that
> it should be retained.  I put them back in and (as expected) it changes
> nothing on x86-64.

Yeah, _acquire should be retained; sorry about loosing that. I'm neck
deep into tlb invalidate stuff and wrote this without much thinking
involved.

[PATCH 06/21] perf tools: Get rid of dso__needs_decompress() call in symbol__disassemble()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no need to call dso__needs_decompress() twice in the function.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-3-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/annotate.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index e4268b948e0e..20061cf42288 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -1629,6 +1629,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
char symfs_filename[PATH_MAX];
struct kcore_extract kce;
bool delete_extract = false;
+   bool decomp = false;
int stdout_fd[2];
int lineno = 0;
int nline;
@@ -1662,6 +1663,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
 tmp, sizeof(tmp)) < 0)
goto out;
 
+   decomp = true;
strcpy(symfs_filename, tmp);
}
 
@@ -1748,7 +1750,7 @@ static int symbol__disassemble(struct symbol *sym, struct 
annotate_args *args)
 out_remove_tmp:
close(stdout_fd[0]);
 
-   if (dso__needs_decompress(dso))
+   if (decomp)
unlink(symfs_filename);
 
if (delete_extract)
-- 
2.14.4

[PATCH 07/21] perf tools: Get rid of dso__needs_decompress() call in __open_dso()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no need to call dso__needs_decompress() twice in the function.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-4-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 51cf82cf1882..8ee1faa5726f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -468,6 +468,7 @@ static int __open_dso(struct dso *dso, struct machine 
*machine)
int fd = -EINVAL;
char *root_dir = (char *)"";
char *name = malloc(PATH_MAX);
+   bool decomp = false;
 
if (!name)
return -ENOMEM;
@@ -491,12 +492,13 @@ static int __open_dso(struct dso *dso, struct machine 
*machine)
goto out;
}
 
+   decomp = true;
strcpy(name, newpath);
}
 
fd = do_open(name);
 
-   if (dso__needs_decompress(dso))
+   if (decomp)
unlink(name);
 
 out:
-- 
2.14.4

[PATCH 04/21] tools lib traceevent: Change to SPDX License format

[Arnaldo Carvalho de Melo]

From: "Steven Rostedt (VMware)" 

Replace the GPL text with SPDX tags in the tools/lib/traceevent files.

Signed-off-by: Steven Rostedt 
Cc: Jiri Olsa 
Cc: Tzvetomir Stoyanov (VMware) 
Cc: Yordan Karadzhov (VMware) 
Cc: linux-trace-de...@vger.kernel.org
Link: http://lkml.kernel.org/r/20180816111015.125e0...@gandalf.local.home
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/lib/traceevent/event-parse.c   | 16 +---
 tools/lib/traceevent/event-plugin.c  | 16 +---
 tools/lib/traceevent/event-utils.h   | 16 +---
 tools/lib/traceevent/kbuffer-parse.c | 17 +
 tools/lib/traceevent/parse-filter.c  | 16 +---
 tools/lib/traceevent/parse-utils.c   | 16 +---
 tools/lib/traceevent/trace-seq.c | 16 +---
 7 files changed, 7 insertions(+), 106 deletions(-)

diff --git a/tools/lib/traceevent/event-parse.c 
b/tools/lib/traceevent/event-parse.c
index 6313e32680ff..ce1e20227c64 100644
--- a/tools/lib/traceevent/event-parse.c
+++ b/tools/lib/traceevent/event-parse.c
@@ -1,21 +1,7 @@
+// SPDX-License-Identifier: LGPL-2.1
 /*
  * Copyright (C) 2009, 2010 Red Hat Inc, Steven Rostedt 
  *
- * ~~
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License (not later!)
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not,  see 
- *
- * ~~
  *
  *  The parts for function graph printing was taken and modified from the
  *  Linux Kernel that were written by
diff --git a/tools/lib/traceevent/event-plugin.c 
b/tools/lib/traceevent/event-plugin.c
index 8e324ed46547..f17e25097e1e 100644
--- a/tools/lib/traceevent/event-plugin.c
+++ b/tools/lib/traceevent/event-plugin.c
@@ -1,21 +1,7 @@
+// SPDX-License-Identifier: LGPL-2.1
 /*
  * Copyright (C) 2009, 2010 Red Hat Inc, Steven Rostedt 
  *
- * ~~
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License (not later!)
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not,  see 
- *
- * ~~
  */
 
 #include 
diff --git a/tools/lib/traceevent/event-utils.h 
b/tools/lib/traceevent/event-utils.h
index d1dc2170e402..0560b96a31d1 100644
--- a/tools/lib/traceevent/event-utils.h
+++ b/tools/lib/traceevent/event-utils.h
@@ -1,21 +1,7 @@
+/* SPDX-License-Identifier: LGPL-2.1 */
 /*
  * Copyright (C) 2010 Red Hat Inc, Steven Rostedt 
  *
- * ~~
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as published by the Free Software Foundation;
- * version 2.1 of the License (not later!)
- *
- * This program is distributed in the hope that it will be useful,
- * but WITHOUT ANY WARRANTY; without even the implied warranty of
- * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
- * GNU Lesser General Public License for more details.
- *
- * You should have received a copy of the GNU Lesser General Public
- * License along with this program; if not,  see 
- *
- * ~~
  */
 #ifndef __UTIL_H
 #define __UTIL_H
diff --git a/tools/lib/traceevent/kbuffer-parse.c 
b/tools/lib/traceevent/kbuffer-parse.c
index ca424b157e46..af2a1f3b7424 100644
--- a/tools/lib/traceevent/kbuffer-parse.c
+++ b/tools/lib/traceevent/kbuffer-parse.c
@@ -1,22 +1,7 @@
+// SPDX-License-Identifier: LGPL-2.1
 /*
  * Copyright (C) 2009, 2010 Red Hat Inc, Steven Rostedt 
  *
- * ~~
- * This program is free software; you can redistribute it and/or
- * modify it under the terms of the GNU Lesser General Public
- * License as 

[PATCH 09/21] perf tools: Make is_supported_compression() static

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no outside user of it.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-6-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 2 +-
 tools/perf/util/dso.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 9f4b72d8f50f..b8b5fdb1a15b 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -202,7 +202,7 @@ static const struct {
{ NULL, NULL },
 };
 
-bool is_supported_compression(const char *ext)
+static bool is_supported_compression(const char *ext)
 {
unsigned i;
 
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index e1adadd1fe1e..870346b333ee 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -250,7 +250,6 @@ int dso__kernel_module_get_build_id(struct dso *dso, const 
char *root_dir);
 char dso__symtab_origin(const struct dso *dso);
 int dso__read_binary_type_filename(const struct dso *dso, enum dso_binary_type 
type,
   char *root_dir, char *filename, size_t size);
-bool is_supported_compression(const char *ext);
 bool is_kernel_module(const char *pathname, int cpumode);
 bool dso__needs_decompress(struct dso *dso);
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name);
-- 
2.14.4

Re: [PATCH] nios2: kconfig: remove duplicate DEBUG_STACK_USAGE symbol defintions

[Masahiro Yamada]

2018-08-16 16:05 GMT+09:00 Tobias Klauser :
> DEBUG_STACK_USAGE is already defined in lib/Kconfig.debug
>
> Signed-off-by: Tobias Klauser 


Reviewed-by: Masahiro Yamada 


> ---
>  arch/nios2/Kconfig.debug | 9 -
>  1 file changed, 9 deletions(-)
>
> diff --git a/arch/nios2/Kconfig.debug b/arch/nios2/Kconfig.debug
> index 7a49f0d28d14..f1da8a7b17ff 100644
> --- a/arch/nios2/Kconfig.debug
> +++ b/arch/nios2/Kconfig.debug
> @@ -3,15 +3,6 @@
>  config TRACE_IRQFLAGS_SUPPORT
> def_bool y
>
> -config DEBUG_STACK_USAGE
> -   bool "Enable stack utilization instrumentation"
> -   depends on DEBUG_KERNEL
> -   help
> - Enables the display of the minimum amount of free stack which each
> - task has ever had available in the sysrq-T and sysrq-P debug output.
> -
> - This option will slow down process creation somewhat.
> -
>  config EARLY_PRINTK
> bool "Activate early kernel debugging"
> default y
> --
> 2.18.0.130.g98da2f6b3e4a
>
>



-- 
Best Regards
Masahiro Yamada

[PATCH 08/21] perf tools: Make decompress_to_file() function static

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no outside user of it.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-5-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/dso.c | 2 +-
 tools/perf/util/dso.h | 1 -
 2 files changed, 1 insertion(+), 2 deletions(-)

diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
index 8ee1faa5726f..9f4b72d8f50f 100644
--- a/tools/perf/util/dso.c
+++ b/tools/perf/util/dso.c
@@ -239,7 +239,7 @@ bool is_kernel_module(const char *pathname, int cpumode)
return m.kmod;
 }
 
-bool decompress_to_file(const char *ext, const char *filename, int output_fd)
+static bool decompress_to_file(const char *ext, const char *filename, int 
output_fd)
 {
unsigned i;
 
diff --git a/tools/perf/util/dso.h b/tools/perf/util/dso.h
index ef69de2e69ea..e1adadd1fe1e 100644
--- a/tools/perf/util/dso.h
+++ b/tools/perf/util/dso.h
@@ -252,7 +252,6 @@ int dso__read_binary_type_filename(const struct dso *dso, 
enum dso_binary_type t
   char *root_dir, char *filename, size_t size);
 bool is_supported_compression(const char *ext);
 bool is_kernel_module(const char *pathname, int cpumode);
-bool decompress_to_file(const char *ext, const char *filename, int output_fd);
 bool dso__needs_decompress(struct dso *dso);
 int dso__decompress_kmodule_fd(struct dso *dso, const char *name);
 int dso__decompress_kmodule_path(struct dso *dso, const char *name,
-- 
2.14.4

[PATCH 01/21] perf tools: Disable parallelism for 'make clean'

[Arnaldo Carvalho de Melo]

From: Rasmus Villemoes 

The Yocto build system does a 'make clean' when rebuilding due to
changed dependencies, and that consistently fails for me (causing the
whole BSP build to fail) with errors such as

| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: '[...]/perf/1.0-r9/perf-1.0/plugin_mac80211.so': No such file or 
directory
| find: find: 
'[...]/perf/1.0-r9/perf-1.0/libtraceevent.a''[...]/perf/1.0-r9/perf-1.0/libtraceevent.a':
 No such file or directory: No such file or directory
|
[...]
| find: cannot delete 
'/mnt/xfs/devel/pil/yocto/tmp-glibc/work/wandboard-oe-linux-gnueabi/perf/1.0-r9/perf-1.0/util/.pstack.o.cmd':
 No such file or directory

Apparently (despite the comment), 'make clean' ends up launching
multiple sub-makes that all want to remove the same things - perhaps
this only happens in combination with a O=... parameter. In any case, we
don't lose much by explicitly disabling the parallelism for the clean
target, and it makes automated builds much more reliable.

Signed-off-by: Rasmus Villemoes 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180705131527.19749-1-li...@rasmusvillemoes.dk
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/Makefile | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/tools/perf/Makefile b/tools/perf/Makefile
index 225454416ed5..7902a5681fc8 100644
--- a/tools/perf/Makefile
+++ b/tools/perf/Makefile
@@ -84,10 +84,10 @@ endif # has_clean
 endif # MAKECMDGOALS
 
 #
-# The clean target is not really parallel, don't print the jobs info:
+# Explicitly disable parallelism for the clean target.
 #
 clean:
-   $(make)
+   $(make) -j1
 
 #
 # The build-test target is not really parallel, don't print the jobs info,
-- 
2.14.4

[GIT PULL 00/21] perf/core improvements and fixes

[Arnaldo Carvalho de Melo]

Hi Ingo,

Please consider pullimg,

- Arnaldo


Test results at the end of this message, as usual.

The following changes since commit 5804b11034a21e4287daaf017c5ad60ad7af8d67:

  Merge tag 'perf-core-for-mingo-4.19-20180815' of 
git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/urgent 
(2018-08-18 13:11:51 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git 
tags/perf-core-for-mingo-4.19-20180820

for you to fetch changes up to 78303650e4cd873c6c4276c6fe3e768ff0b46d22:

  tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem 
memcpy' (2018-08-20 10:17:14 -0300)


perf/core improvements and fixes:

LLVM/clang/eBPF: (Arnaldo Carvalho de Melo)

- Allow passing options to llc in addition to to clang.

Hardware tracing: (Jack Henschel)

- Improve error message for PMU address filters, clarifying availability of
  that feature in hardware having hardware tracing such as Intel PT.

Python interface: (Jiri Olsa)

- Fix read_on_cpu() interface.

ELF/DWARF libraries: (Jiri Olsa)

- Fix handling of the combo compressed module file + decompressed associated
  debuginfo file.

Build (Rasmus Villemoes)

- Disable parallelism for 'make clean', avoiding multiple submakes deleting
  the same files and causing the build to fail on systems such as Yocto.

Kernel ABI copies: (Arnaldo Carvalho de Melo)

- Update tools's copy of x86's cpufeatures.h.

- Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem memcpy'.

Miscellaneous: (Steven Rostedt)

- Change libtraceevent to SPDX License format.

Signed-off-by: Arnaldo Carvalho de Melo 


Arnaldo Carvalho de Melo (3):
  perf llvm: Allow passing options to llc in addition to clang
  tools arch x86: Update tools's copy of cpufeatures.h
  tools arch: Update arch/x86/lib/memcpy_64.S copy used in 'perf bench mem 
memcpy'

Jack Henschel (1):
  perf parser: Improve error message for PMU address filters

Jiri Olsa (15):
  perf tools: Get rid of dso__needs_decompress() call in read_object_code()
  perf tools: Get rid of dso__needs_decompress() call in 
symbol__disassemble()
  perf tools: Get rid of dso__needs_decompress() call in __open_dso()
  perf tools: Make decompress_to_file() function static
  perf tools: Make is_supported_compression() static
  perf tools: Add compression id into 'struct kmod_path'
  perf tools: Store compression id into struct dso
  perf tools: Use compression id in decompress_kmodule()
  perf tools: Move the temp file processing into decompress_kmodule
  perf tools: Add is_compressed callback to compressions array
  perf tools: Add lzma_is_compressed function
  perf tools: Add gzip_is_compressed function
  perf tools: Remove ext from struct kmod_path
  perf mmap: Store real cpu number in 'struct perf_mmap'
  perf python: Fix pyrf_evlist__read_on_cpu() interface

Rasmus Villemoes (1):
  perf tools: Disable parallelism for 'make clean'

Steven Rostedt (VMware) (1):
  tools lib traceevent: Change to SPDX License format

 tools/arch/x86/include/asm/cpufeatures.h |   3 +-
 tools/arch/x86/lib/memcpy_64.S   |   2 +-
 tools/lib/traceevent/event-parse.c   |  16 +---
 tools/lib/traceevent/event-plugin.c  |  16 +---
 tools/lib/traceevent/event-utils.h   |  16 +---
 tools/lib/traceevent/kbuffer-parse.c |  17 +---
 tools/lib/traceevent/parse-filter.c  |  16 +---
 tools/lib/traceevent/parse-utils.c   |  16 +---
 tools/lib/traceevent/trace-seq.c |  16 +---
 tools/perf/Makefile  |   4 +-
 tools/perf/tests/code-reading.c  |   4 +-
 tools/perf/tests/kmod-path.c | 136 +++
 tools/perf/util/annotate.c   |   4 +-
 tools/perf/util/compress.h   |   2 +
 tools/perf/util/dso.c| 111 -
 tools/perf/util/dso.h|  13 ++-
 tools/perf/util/evlist.c |   2 +-
 tools/perf/util/llvm-utils.c |  31 ++-
 tools/perf/util/llvm-utils.h |   9 ++
 tools/perf/util/lzma.c   |  20 +
 tools/perf/util/machine.c|   4 +-
 tools/perf/util/mmap.c   |   3 +-
 tools/perf/util/mmap.h   |   3 +-
 tools/perf/util/parse-events.c   |  20 ++---
 tools/perf/util/python.c |  20 -
 tools/perf/util/zlib.c   |  18 
 26 files changed, 256 insertions(+), 266 deletions(-)

Test results:

The first ones are container (docker) based builds of tools/perf with
and without libelf support.  Where clang is available, it is also used
to build perf with/without libelf, and building with LIBCLANGLLVM=1
(built-in clang) with gcc and clang when clang and its devel libraries

[PATCH 05/21] perf tools: Get rid of dso__needs_decompress() call in read_object_code()

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

There's no need to call dso__needs_decompress() twice in the function.

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-2-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/code-reading.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/tools/perf/tests/code-reading.c b/tools/perf/tests/code-reading.c
index 4892bd2dc33e..6b049f3f5cf4 100644
--- a/tools/perf/tests/code-reading.c
+++ b/tools/perf/tests/code-reading.c
@@ -232,6 +232,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
u64 objdump_addr;
const char *objdump_name;
char decomp_name[KMOD_DECOMP_LEN];
+   bool decomp = false;
int ret;
 
pr_debug("Reading object code for memory address: %#"PRIx64"\n", addr);
@@ -305,6 +306,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
return -1;
}
 
+   decomp = true;
objdump_name = decomp_name;
}
 
@@ -312,7 +314,7 @@ static int read_object_code(u64 addr, size_t len, u8 
cpumode,
objdump_addr = map__rip_2objdump(al.map, al.addr);
ret = read_via_objdump(objdump_name, objdump_addr, buf2, len);
 
-   if (dso__needs_decompress(al.map->dso))
+   if (decomp)
unlink(objdump_name);
 
if (ret > 0) {
-- 
2.14.4

[PATCH 02/21] perf parser: Improve error message for PMU address filters

[Arnaldo Carvalho de Melo]

From: Jack Henschel 

This is the second version of a patch that improves the error message of
the perf events parser when the PMU hardware does not support address
filters.

Previously, the perf returned the following error:

  $ perf record -e intel_pt// --filter 'filter sys_write'
  --filter option should follow a -e tracepoint or HW tracer option

This implies there is some syntax error present in the command line,
which is not true. Rather, notify the user that the CPU does not have
support for this feature.

For example, Intel chips based on the Broadwell micro-archticture have
the Intel PT PMU, but do not support address filtering.

Now, perf prints the following error message:

  $ perf record -e intel_pt// --filter 'filter sys_write'
  This CPU does not support address filtering

Signed-off-by: Jack Henschel 
Tested-by: Arnaldo Carvalho de Melo 
Acked-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180704121345.19025-1-jack...@mailbox.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/parse-events.c | 20 ++--
 1 file changed, 10 insertions(+), 10 deletions(-)

diff --git a/tools/perf/util/parse-events.c b/tools/perf/util/parse-events.c
index 15eec49e71a1..f8cd3e7c9186 100644
--- a/tools/perf/util/parse-events.c
+++ b/tools/perf/util/parse-events.c
@@ -1991,8 +1991,11 @@ static int set_filter(struct perf_evsel *evsel, const 
void *arg)
int nr_addr_filters = 0;
struct perf_pmu *pmu = NULL;
 
-   if (evsel == NULL)
-   goto err;
+   if (evsel == NULL) {
+   fprintf(stderr,
+   "--filter option should follow a -e tracepoint or HW 
tracer option\n");
+   return -1;
+   }
 
if (evsel->attr.type == PERF_TYPE_TRACEPOINT) {
if (perf_evsel__append_tp_filter(evsel, str) < 0) {
@@ -2014,8 +2017,11 @@ static int set_filter(struct perf_evsel *evsel, const 
void *arg)
perf_pmu__scan_file(pmu, "nr_addr_filters",
"%d", _addr_filters);
 
-   if (!nr_addr_filters)
-   goto err;
+   if (!nr_addr_filters) {
+   fprintf(stderr,
+   "This CPU does not support address filtering\n");
+   return -1;
+   }
 
if (perf_evsel__append_addr_filter(evsel, str) < 0) {
fprintf(stderr,
@@ -2024,12 +2030,6 @@ static int set_filter(struct perf_evsel *evsel, const 
void *arg)
}
 
return 0;
-
-err:
-   fprintf(stderr,
-   "--filter option should follow a -e tracepoint or HW tracer 
option\n");
-
-   return -1;
 }
 
 int parse_filter(const struct option *opt, const char *str,
-- 
2.14.4

[PATCH 03/21] perf llvm: Allow passing options to llc in addition to clang

[Arnaldo Carvalho de Melo]

From: Arnaldo Carvalho de Melo 

The newly added 'llvm.opts' variable allows passing options directly to
llc, like needed to get sane DWARF in BPF ELF debug sections:

With:

  [root@seventh perf]# cat ~/.perfconfig
  [llvm]
  dump-obj = true
clang-opt = -g
  [root@seventh perf]#

We get:

  [root@seventh perf]# perf trace -e tools/perf/examples/bpf/hello.c cat 
/etc/passwd > /dev/null
  LLVM: dumping tools/perf/examples/bpf/hello.o
   0.000 __bpf_stdout__:Hello, world
   0.015 __bpf_stdout__:Hello, world
   0.187 __bpf_stdout__:Hello, world
  [root@seventh perf]# pahole tools/perf/examples/bpf/hello.o
  struct clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c) {
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /* 0 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /* 4 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /* 8 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /*12 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /*16 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /*20 4 */
  clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566e.org clang version 8.0.0 (http://llvm.org/git/clang.git 
8587270a739ee30c926a76d5657e65e85b560f6e) (http://llvm.org/git/llvm.git 
0566eefef9c3777bd780ec4cbb9efa764633b76c); /*24 4 */

  /* size: 28, cachelines: 1, members: 7 */
  /* last cacheline: 28 bytes */
  };
  [root@seventh perf]#

Adding these options to be passed to llvm's llc:

  [root@seventh perf]# cat ~/.perfconfig
  [llvm]
  dump-obj = true
  clang-opt = -g
  opts = -mattr=dwarfris
  [root@seventh perf]#

We get sane output:

  [root@seventh perf]# perf trace -e tools/perf/examples/bpf/hello.c cat 
/etc/passwd > /dev/null
  LLVM: dumping tools/perf/examples/bpf/hello.o
   0.000 __bpf_stdout__:Hello, world
   0.015 __bpf_stdout__:Hello, world
   0.185 __bpf_stdout__:Hello, world
  [root@seventh perf]# pahole tools/perf/examples/bpf/hello.o
  struct bpf_map {
  unsigned int   type; /* 0 4 */
  unsigned int   key_size; /* 4 4 */
  unsigned int   value_size;   /* 8 4 */
  unsigned int   max_entries;  /*12 4 */
  unsigned int   map_flags;/*16 4 */
  unsigned int   inner_map_idx;/*20 4 */
  unsigned int   numa_node;/*24 4 */

  /* size: 28, cachelines: 1, members: 7 */
  /* last cacheline: 28 bytes */
  };
  [root@seventh perf]#

Cc: Alexei Starovoitov 
Cc: Daniel Borkmann 
Cc: Jiri Olsa 
Cc: Martin KaFai Lau 
Cc: Namhyung Kim 
Cc: Wang Nan ,
Cc: Yonghong Song 
Link: https://lkml.kernel.org/n/tip-0lrwmrip4dru1651rm8xa...@git.kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/util/llvm-utils.c | 31 +--
 tools/perf/util/llvm-utils.h |  9 +
 2 files changed, 38 insertions(+), 2 deletions(-)

diff --git a/tools/perf/util/llvm-utils.c b/tools/perf/util/llvm-utils.c
index 

[PATCH 10/21] perf tools: Add compression id into 'struct kmod_path'

[Arnaldo Carvalho de Melo]

From: Jiri Olsa 

Store a decompression ID in 'struct kmod_path', so it can be later
stored in 'struct dso'.

Switch 'struct kmod_path's 'comp' from 'bool' to 'int' to return the
compressions array index. Add 0 index item into compressions array, so
that the comp usage stays as it was: 0 - no compression, != 0
compression index.

Update the kmod_path tests.

Committer notes:

Use a designated initializer + terminating comma, e.g. { .fmt = NULL, }, to fix
the build in several distros:

  centos:6:   util/dso.c:201: error: missing initializer
  centos:6:   util/dso.c:201: error: (near initialization for 
'compressions[0].decompress')
  debian:9:   util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  fedora:25:  util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  fedora:26:  util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  fedora:27:  util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  oraclelinux:6:  util/dso.c:201: error: missing initializer
  oraclelinux:6:  util/dso.c:201: error: (near initialization for 
'compressions[0].decompress')
  ubuntu:12.04.5: util/dso.c:201:2: error: missing initializer 
[-Werror=missing-field-initializers]
  ubuntu:12.04.5: util/dso.c:201:2: error: (near initialization for 
'compressions[0].decompress') [-Werror=missing-field-initializers]
  ubuntu:16.04:   util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  ubuntu:16.10:   util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  ubuntu:16.10:   util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]
  ubuntu:17.10:   util/dso.c:201:24: error: missing field 'decompress' 
initializer [-Werror,-Wmissing-field-initializers]

Signed-off-by: Jiri Olsa 
Cc: Alexander Shishkin 
Cc: David Ahern 
Cc: Michael Petlan 
Cc: Namhyung Kim 
Cc: Peter Zijlstra 
Link: http://lkml.kernel.org/r/20180817094813.15086-7-jo...@kernel.org
Signed-off-by: Arnaldo Carvalho de Melo 
---
 tools/perf/tests/kmod-path.c | 42 +-
 tools/perf/util/dso.c| 18 +++---
 tools/perf/util/dso.h|  2 +-
 3 files changed, 33 insertions(+), 29 deletions(-)

diff --git a/tools/perf/tests/kmod-path.c b/tools/perf/tests/kmod-path.c
index 148dd31cc201..f92f78f683ea 100644
--- a/tools/perf/tests/kmod-path.c
+++ b/tools/perf/tests/kmod-path.c
@@ -6,7 +6,7 @@
 #include "debug.h"
 
 static int test(const char *path, bool alloc_name, bool alloc_ext,
-   bool kmod, bool comp, const char *name, const char *ext)
+   bool kmod, int comp, const char *name, const char *ext)
 {
struct kmod_path m;
 
@@ -54,47 +54,47 @@ static int test_is_kernel_module(const char *path, int 
cpumode, bool expect)
 int test__kmod_path__parse(struct test *t __maybe_unused, int subtest 
__maybe_unused)
 {
/* pathalloc_name  alloc_ext   kmod  comp   name 
ext */
-   T("///x-x.ko", true  , true  , true, false, "[x_x]", 
NULL);
-   T("///x-x.ko", false , true  , true, false, NULL   , 
NULL);
-   T("///x-x.ko", true  , false , true, false, "[x_x]", 
NULL);
-   T("///x-x.ko", false , false , true, false, NULL   , 
NULL);
+   T("///x-x.ko", true  , true  , true, 0, "[x_x]", 
NULL);
+   T("///x-x.ko", false , true  , true, 0, NULL   , 
NULL);
+   T("///x-x.ko", true  , false , true, 0, "[x_x]", 
NULL);
+   T("///x-x.ko", false , false , true, 0, NULL   , 
NULL);
M("///x-x.ko", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x-x.ko", PERF_RECORD_MISC_KERNEL, true);
M("///x-x.ko", PERF_RECORD_MISC_USER, false);
 
 #ifdef HAVE_ZLIB_SUPPORT
/* pathalloc_name  alloc_ext   kmod  comp  name   ext */
-   T("///x.ko.gz", true , true  , true, true, "[x]", "gz");
-   T("///x.ko.gz", false, true  , true, true, NULL , "gz");
-   T("///x.ko.gz", true , false , true, true, "[x]", NULL);
-   T("///x.ko.gz", false, false , true, true, NULL , NULL);
+   T("///x.ko.gz", true , true  , true, 1   , "[x]", "gz");
+   T("///x.ko.gz", false, true  , true, 1   , NULL , "gz");
+   T("///x.ko.gz", true , false , true, 1   , "[x]", NULL);
+   T("///x.ko.gz", false, false , true, 1   , NULL , NULL);
M("///x.ko.gz", PERF_RECORD_MISC_CPUMODE_UNKNOWN, true);
M("///x.ko.gz", PERF_RECORD_MISC_KERNEL, 

Re: [PATCH v3] staging: mt7621-mmc: Fix debug macros and their usages

[Nishad Kamdar]

On Sun, Aug 19, 2018 at 01:34:01PM +0200, Greg Kroah-Hartman wrote:
> On Sun, Aug 19, 2018 at 03:35:02PM +0530, Nishad Kamdar wrote:
> > Fixed four debug macros and their usages. Replaced printk with
> > dev_ without __func__ or __LINE__ or current->comm and
> > current->pid. Further removed the do {} while(0) loop for single
> > statement macros.
> > Out of the four, replaced all usages of ERR_MSG and IRQ_MSG with
> > dev_err() in the code itself and dropped them from dbg.h.
> > Removed all INIT_MSG usages and dropped it from dgb.h.
> > Issues found by checkpatch.
> 
> This needs to be multiple patches.  One for each type of macro you are
> deleting/changing, not all lumped together into one big patch.
> 
> Plaese fix that up and resend.
> 
> thanks,
> 
> greg k-h

Ok, I'll do that.

Thanks for the review.

regards,
nishad

Re: linux-next: build warnings from Linus' tree

[Miguel Ojeda]

Hi Ted,

On Mon, Aug 20, 2018 at 2:02 AM, Theodore Y. Ts'o  wrote:
> P.S.  It's really, really too bad there isn't a simpler way to shut up
> gcc.  You need the #ifdef __GNUC_PREREQ nonsense because otherwise
> older versions of gcc that don't understand the particular warning
> you're trying to suppress will complain loudly.  (Ask me how I
> know)

Please check out the __nonstring patch I sent (the one Linus is
referring to, I guess) and see if you think it would be a good
solution for your case:

  https://lore.kernel.org/lkml/20180814193813.ga5...@gmail.com/

I just tried the patch below with 8.2 [*] and those two warnings in
fs/ext4 go away as expected.

I think marking those fixed-width fields is a good idea anyway (i.e.
makes it clear that they are not meant to be null-terminated), but I
would like to hear opinions on the matter.

Cheers,
Miguel

[*]

diff --git a/fs/ext4/ext4.h b/fs/ext4/ext4.h
index 0f0edd1cd0cd..3eef4b286895 100644
--- a/fs/ext4/ext4.h
+++ b/fs/ext4/ext4.h
@@ -1277,13 +1277,13 @@ struct ext4_super_block {
__le32  s_first_error_time; /* first time an error happened */
__le32  s_first_error_ino;  /* inode involved in first error */
__le64  s_first_error_block;/* block involved of first error */
-   __u8s_first_error_func[32]; /* function where the error happened */
+   __u8s_first_error_func[32] __nonstring; /* function
where the error happened */
__le32  s_first_error_line; /* line number where error happened */
__le32  s_last_error_time;  /* most recent time of an error */
__le32  s_last_error_ino;   /* inode involved in last error */
__le32  s_last_error_line;  /* line number where error happened */
__le64  s_last_error_block; /* block involved of last error */
-   __u8s_last_error_func[32];  /* function where the error happened */
+   __u8s_last_error_func[32] __nonstring;  /* function
where the error happened */
 #define EXT4_S_ERR_END offsetof(struct ext4_super_block, s_mount_opts)
__u8s_mount_opts[64];
__le32  s_usr_quota_inum;   /* inode for tracking user quota */

Re: [PATCH v2] fpga: dfl: region: Restory symmetry in probe()/remove()

[Alan Tull]

On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer  wrote:

Hi Moritz,

> Replace dev_get_drvdata() with platform_get_drvdata() to
> match the platform_set_drvdata() in the probe function of
> the platform driver.
>
> Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for 
> FME")
> Signed-off-by: Moritz Fischer 
> ---
>
> Changes from v1:
> - Still compile after change ...
>
> ---
>  drivers/fpga/dfl-fme-region.c | 2 +-

Thanks for catching this.  of-fpga-region.c does a similar thing and
needs s/dev_set_drvdata/platform_set_drvdata/ in the probe.  Could you
fix it here too?

Alan

>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/fpga/dfl-fme-region.c b/drivers/fpga/dfl-fme-region.c
> index 0b7e19c27c6d..11d3c23a8936 100644
> --- a/drivers/fpga/dfl-fme-region.c
> +++ b/drivers/fpga/dfl-fme-region.c
> @@ -65,7 +65,7 @@ static int fme_region_probe(struct platform_device *pdev)
>
>  static int fme_region_remove(struct platform_device *pdev)
>  {
> -   struct fpga_region *region = dev_get_drvdata(>dev);
> +   struct fpga_region *region = platform_get_drvdata(pdev);
>
> fpga_region_unregister(region);
> fpga_mgr_put(region->mgr);
> --
> 2.18.0
>

Re: [PATCH v5 1/2] dt-bindings: leds: Add bindings for lm3697 driver

[Rob Herring]

On Fri, 17 Aug 2018 10:15:27 -0500, Dan Murphy wrote:
> Add the device tree bindings for the lm3697
> LED driver for backlighting and display.
> 
> Signed-off-by: Dan Murphy 
> ---
> 
> v5 - Fix the comment for the example - 
> https://lore.kernel.org/patchwork/patch/975060/
> 
> v4 - Removed HVLED definition in favor of HVLED place definition - 
> https://lore.kernel.org/patchwork/patch/974812/
> v3 - Updated subject with prefered title - 
> https://lore.kernel.org/patchwork/patch/972337/
> v2 - Fixed subject and patch commit message - 
> https://lore.kernel.org/patchwork/patch/971326/
> 
>  .../devicetree/bindings/leds/leds-lm3697.txt  | 86 +++
>  1 file changed, 86 insertions(+)
>  create mode 100644 Documentation/devicetree/bindings/leds/leds-lm3697.txt
> 

Reviewed-by: Rob Herring 

Re: Crash in MM code in v4.4.y, v4.9.y with TRANSPARENT_HUGEPAGE enabled

[Andi Kleen]

On Mon, Aug 20, 2018 at 06:29:38PM +0200, Michal Hocko wrote:
> On Fri 17-08-18 15:27:33, Guenter Roeck wrote:
> > Hi,
> > 
> > the following crash is seen in v4.4.148, v4.4.149, v4.9.120, and v4.9.121
> > with CONFIG_TRANSPARENT_HUGEPAGE=y, CONFIG_TRANSPARENT_HUGEPAGE_MADVISE=y.
> 
> Could you try to apply fd7e315988b7 ("x86/mm: Simplify p[g4um]d_page()
> macros"). I do not see it in stable 4.4 tree and it has been introduced
> much later in 4.14. This one gave us quite some headache because it is
> s easy to overlook.

Good catch!

I tested that with 4.9 and backporting the patch indeed fixes the
syzcaller test case running in a KVM VM. Backported patch appended.

Should probably go into 4.4 and 4.9.

Cannot explain the 4.17 report unfortunately.

I'll resend it as an email too

---

x86/mm: Simplify p[g4um]d_page() macros

Create a pgd_pfn() macro similar to the p[4um]d_pfn() macros and then
use the p[g4um]d_pfn() macros in the p[g4um]d_page() macros instead of
duplicating the code.

[Needed to fix crashes caused by earlier backports in 4.9 stable, likely 4.4 
too]

Signed-off-by: Tom Lendacky 
Reviewed-by: Thomas Gleixner 
Reviewed-by: Borislav Petkov 
Cc: Alexander Potapenko 
Cc: Andrey Ryabinin 
Cc: Andy Lutomirski 
Cc: Arnd Bergmann 
Cc: Borislav Petkov 
Cc: Brijesh Singh 
Cc: Dave Young 
Cc: Dmitry Vyukov 
Cc: Jonathan Corbet 
Cc: Konrad Rzeszutek Wilk 
Cc: Larry Woodman 
Cc: Linus Torvalds 
Cc: Matt Fleming 
Cc: Michael S. Tsirkin 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Radim Krčmář 
Cc: Rik van Riel 
Cc: Toshimitsu Kani 
Cc: kasan-...@googlegroups.com
Cc: k...@vger.kernel.org
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux...@kvack.org
Link: 
http://lkml.kernel.org/r/e61eb533a6d0aac941db2723d8aa63ef6b882dee.1500319216.git.thomas.lenda...@amd.com
[Backported to 4.9 stable by AK, suggested by Michael Hocko]
Signed-off-by: Ingo Molnar 
Signed-off-by: Andi Kleen 

diff --git a/arch/x86/include/asm/pgtable.h b/arch/x86/include/asm/pgtable.h
index 4de6c282c02a..68a55273ce0f 100644
--- a/arch/x86/include/asm/pgtable.h
+++ b/arch/x86/include/asm/pgtable.h
@@ -173,6 +173,11 @@ static inline unsigned long pud_pfn(pud_t pud)
return (pfn & pud_pfn_mask(pud)) >> PAGE_SHIFT;
 }
 
+static inline unsigned long pgd_pfn(pgd_t pgd)
+{
+   return (pgd_val(pgd) & PTE_PFN_MASK) >> PAGE_SHIFT;
+}
+
 #define pte_page(pte)  pfn_to_page(pte_pfn(pte))
 
 static inline int pmd_large(pmd_t pte)
@@ -578,8 +583,7 @@ static inline unsigned long pmd_page_vaddr(pmd_t pmd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pmd_page(pmd)  \
-   pfn_to_page((pmd_val(pmd) & pmd_pfn_mask(pmd)) >> PAGE_SHIFT)
+#define pmd_page(pmd)  pfn_to_page(pmd_pfn(pmd))
 
 /*
  * the pmd page can be thought of an array like this: pmd_t[PTRS_PER_PMD]
@@ -647,8 +651,7 @@ static inline unsigned long pud_page_vaddr(pud_t pud)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pud_page(pud)  \
-   pfn_to_page((pud_val(pud) & pud_pfn_mask(pud)) >> PAGE_SHIFT)
+#define pud_page(pud)  pfn_to_page(pud_pfn(pud))
 
 /* Find an entry in the second-level page table.. */
 static inline pmd_t *pmd_offset(pud_t *pud, unsigned long address)
@@ -688,7 +691,7 @@ static inline unsigned long pgd_page_vaddr(pgd_t pgd)
  * Currently stuck as a macro due to indirect forward reference to
  * linux/mmzone.h's __section_mem_map_addr() definition:
  */
-#define pgd_page(pgd)  pfn_to_page(pgd_val(pgd) >> PAGE_SHIFT)
+#define pgd_page(pgd)  pfn_to_page(pgd_pfn(pgd))
 
 /* to find an entry in a page-table-directory. */
 static inline unsigned long pud_index(unsigned long address)

Re: [PATCH v2] fpga: dfl: region: Restory symmetry in probe()/remove()

[Alan Tull]

On Mon, Aug 20, 2018 at 12:54 PM, Moritz Fischer  wrote:
> Hi Alan,
>
> On Mon, Aug 20, 2018 at 12:46:32PM -0500, Alan Tull wrote:
>> On Mon, Aug 20, 2018 at 12:18 PM, Moritz Fischer  wrote:
>>
>> Hi Moritz,
>>
>> > Replace dev_get_drvdata() with platform_get_drvdata() to
>> > match the platform_set_drvdata() in the probe function of
>> > the platform driver.
>> >
>> > Fixes commit bb61b9be3e6b ("fpga: dfl: add fpga region platform driver for 
>> > FME")
>> > Signed-off-by: Moritz Fischer 
>> > ---
>> >
>> > Changes from v1:
>> > - Still compile after change ...
>> >
>> > ---
>> >  drivers/fpga/dfl-fme-region.c | 2 +-
>>
>> Thanks for catching this.  of-fpga-region.c does a similar thing and
>> needs s/dev_set_drvdata/platform_set_drvdata/ in the probe.  Could you
>> fix it here too?

Actually I should have said something more like
s/dev_set_drvdata(dev/platform_set_drvdata(pdev/

>
> Yeah, can do in a v3 series ... Will add your Suggested-by: ...

Thanks!

>
> Cheers,
>
> Moritz

Re: [PATCH v7 2/2] powerpc: Use cpu_smallcore_sibling_mask at SMT level on bigcores

[Srikar Dronamraju]

* Gautham R. Shenoy  [2018-08-20 11:11:44]:

> From: "Gautham R. Shenoy" 
> 
> Each of the SMT4 cores forming a big-core are more or less independent
> units. Thus when multiple tasks are scheduled to run on the fused
> core, we get the best performance when the tasks are spread across the
> pair of SMT4 cores.
> 
> This patch achieves this by setting the SMT level mask to correspond
> to the smallcore sibling mask on big-core systems. This patch also
> ensures that while checked for shared-caches on big-core system, we
> use the smallcore_sibling_mask to compare with the l2_cache_mask.
> This ensure that the CACHE level sched-domain is created, whose groups
> correspond to the threads of the big-core.
> 
> With this patch, the SMT sched-domain with SMT=8,4,2 on big-core
> systems are as follows:


Reviewed-by: Srikar Dronamraju 

Re: [PATCH] rtc: jz4740: Drop dependency on MACH_INGENIC

[Paul Cercueil]

Hi,

Le lun. 20 août 2018 à 21:12, Alexandre Belloni 
 a écrit :

On 20/08/2018 20:07:16+0200, Paul Cercueil wrote:
 Depending on MACH_INGENIC prevent us from creating a generic kernel 
that
 works on more than one MIPS board. Instead, we just depend on MIPS 
being

 set.


Maybe you could consider dropping the whole dependency as we already
know it will build on every architecture.


Well, I didn't really want the Kconfig option to show on the menu when
compiling for non-MIPS, since it's only ever useful there.

Should I drop the dependency then?



 Signed-off-by: Paul Cercueil 
 ---
  drivers/rtc/Kconfig | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
 index a2ba5db36145..98c7f19256b1 100644
 --- a/drivers/rtc/Kconfig
 +++ b/drivers/rtc/Kconfig
 @@ -1608,7 +1608,7 @@ config RTC_DRV_MPC5121

  config RTC_DRV_JZ4740
tristate "Ingenic JZ4740 SoC"
 -  depends on MACH_INGENIC || COMPILE_TEST
 +  depends on MIPS || COMPILE_TEST
help
  	  If you say yes here you get support for the Ingenic JZ47xx SoCs 
RTC

  controllers.
 --
 2.11.0



--
Alexandre Belloni, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

Re: [PATCH RESEND v1 2/5] drivers: pinctrl: msm: enable PDC interrupt only during suspend

[Lina Iyer]

On Mon, Aug 20 2018 at 09:34 -0600, Marc Zyngier wrote:

On 20/08/18 16:26, Lina Iyer wrote:

On Sat, Aug 18 2018 at 07:13 -0600, Marc Zyngier wrote:

Hi Lina,

On Fri, 17 Aug 2018 20:10:23 +0100,
Lina Iyer  wrote:


[...]


@@ -920,6 +928,8 @@ static int msm_gpio_pdc_pin_request(struct irq_data *d)
}

irq_set_handler_data(d->irq, irq_get_irq_data(irq));
+   irq_set_handler_data(irq, d);
+   irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY);


Could you explain what this is trying to do? I'm trying to understand
this code, but this function isn't in 4.18...


Oh, I have been able to test only on 4.14 so far. The flag does seem to
exist at least, I didn't get a compiler error.

I read this in kernel/irq/chip.c -

If the interrupt chip does not implement the irq_disable callback,
a driver can disable the lazy approach for a particular irq line by
calling 'irq_set_status_flags(irq, IRQ_DISABLE_UNLAZY)'. This can
be used for devices which cannot disable the interrupt at the
device level under certain circumstances and have to use
disable_irq[_nosync] instead.

And interpreted this as something that this would prevent 'relaxed'
disable. I am enabling and disabling the IRQ in suspend path, that I
thought this would help avoid issues caused by late disable. Am I
mistaken?


Sorry, I wasn't clear enough. I'm talking about what you're trying to do
in this particular function (msm_gpio_pdc_pin_request), which doesn't
exist in 4.18. Short of having a bit of context, I can hardly review this.


Sorry, my patch generation during the resend is messed up. Seems like I
didn't send that patch out during the resend.

-- Lina

Re: [PATCH] locking: Remove an insn from spin and write locks

[Matthew Wilcox]

On Mon, Aug 20, 2018 at 11:14:04AM -0400, Waiman Long wrote:
> On 08/20/2018 11:06 AM, Matthew Wilcox wrote:
> > Both spin locks and write locks currently do:
> >
> >  f0 0f b1 17 lock cmpxchg %edx,(%rdi)
> >  85 c0   test   %eax,%eax
> >  75 05   jne[slowpath]
> >
> > This 'test' insn is superfluous; the cmpxchg insn sets the Z flag
> > appropriately.  Peter pointed out that using atomic_try_cmpxchg()
> > will let the compiler know this is true.  Comparing before/after
> > disassemblies show the only effect is to remove this insn.
...
> >  static __always_inline int queued_spin_trylock(struct qspinlock *lock)
> >  {
> > +   u32 val = 0;
> > +
> > if (!atomic_read(>val) &&
> > -  (atomic_cmpxchg_acquire(>val, 0, _Q_LOCKED_VAL) == 0))
> > +   (atomic_try_cmpxchg(>val, , _Q_LOCKED_VAL)))
> 
> Should you keep the _acquire suffix?

I don't know ;-)  Probably.  Peter didn't include it as part of his
suggested fix, but on reviewing the documentation, it seems likely that
it should be retained.  I put them back in and (as expected) it changes
nothing on x86-64.

> BTW, qspinlock and qrwlock are now also used by AArch64, mips and sparc.
> Have you tried to see what the effect will be for those architecture?

Nope!  That's why I cc'd linux-arch, because I don't know who (other
than arm64 and x86) is using q-locks these days.