Re: Prototype patch for Linux-kernel memory model

[Peter Zijlstra]

On Mon, Nov 13, 2017 at 10:40:31AM -0800, Paul E. McKenney wrote:
> commit 82a1431549b4eae531e83298fd72cd0acea08540
> Author: Paul E. McKenney 
> Date:   Mon Nov 13 10:30:07 2017 -0800
> 
> tools: Automate memory-barriers.txt; provide Linux-kernel memory model
> 
> There is some reason to believe that Documentation/memory-barriers.txt
> could use some help, and a major purpose of this patch is to provide
> that help in the form of a design-time tool that can produce all valid
> executions of a small fragment of concurrent Linux-kernel code, which is
> called a "litmus test".  This tool's functionality is roughly similar to
> a full state-space search.  Please note that this is a design-time tool,
> not useful for regression testing.  However, we hope that the underlying
> Linux-kernel memory model will be incorporated into other tools capable
> of analyzing large bodies of code for regression-testing purposes.
> 
> The main tool is herd7, together with the linux-kernel.bell,
> linux-kernel.cat, linux-kernel.cfg, linux-kernel.def, and lock.cat files
> added by this patch.  The herd7 executable takes the other files as input,
> and all of these files collectively define the Linux-kernel memory memory
> model.  A brief description of each of these other files is provided
> in the README file.  Although this tool does have its limitations,
> which are documented in the README file, it does improve on the version
> reported on in the LWN series (https://lwn.net/Articles/718628/ and
> https://lwn.net/Articles/720550/) by supporting locking and arithmetic,
> including a much wider variety of read-modify-write atomic operations.
> Please note that herd7 is not part of this submission, but is freely
> available from http://diy.inria.fr/sources/index.html (and via "git"
> at https://github.com/herd/herdtools7).
> 
> A second tool is klitmus7, which converts litmus tests to loadable
> kernel modules for direct testing.  As with herd7, the klitmus7
> code is freely available from http://diy.inria.fr/sources/index.html
> (and via "git" at https://github.com/herd/herdtools7).
> 
> Of course, litmus tests are not always the best way to fully understand a
> memory model, so this patch also includes Documentation/explanation.txt,
> which describes the memory model in detail.  In addition,
> Documentation/recipes.txt provides example known-good and known-bad use
> cases for those who prefer working by example.
> 
> This patch also includes a few sample litmus tests, and a great many
> more litmus tests are available at https://github.com/paulmckrcu/litmus.
> 
> Signed-off-by: Alan Stern 
> Signed-off-by: Andrea Parri 
> Signed-off-by: Will Deacon 
> Signed-off-by: Peter Zijlstra 
> Signed-off-by: Boqun Feng 
> Signed-off-by: Nicholas Piggin 
> Signed-off-by: David Howells 
> Signed-off-by: Jade Alglave 
> Signed-off-by: Luc Maranget 
> Signed-off-by: "Paul E. McKenney" 
> Cc: 

So I think that SoB chains like that are utter crap. I think you meant
to have all but the one from you be an Ack or similar.

RE: [PATCH v2] arm64: dts: ls1088a: Add USB support

[Yinbo Zhu]

-Original Message-
From: Yinbo Zhu 
Sent: Tuesday, October 24, 2017 5:15 PM
To: Shawn Guo 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: RE: [PATCH v2] arm64: dts: ls1088a: Add USB support


-Original Message-
From: Shawn Guo [mailto:shawn...@kernel.org] 
Sent: Friday, September 22, 2017 2:55 PM
To: Yinbo Zhu 
Cc: Rob Herring ; Mark Rutland ; 
Catalin Marinas ) ; Will Deacon ) 
; Harninder Rai ; Raghav Dogra 
; Ashish Kumar ; Andy Tang 
; open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS 
; linux-arm-ker...@lists.infradead.org; open list 

Subject: Re: [PATCH v2] arm64: dts: ls1088a: Add USB support

On Wed, Sep 13, 2017 at 05:10:09PM +0800, yinbo@nxp.com wrote:
> From: "yinbo.zhu" 
> 
> Fix the issue that usb is not detected on ls1088ardb

>It's not really about fixing issue but adding support.

The patch had been tested on upstream 4.14 code, it can fix the issue. 
> 
> Signed-off-by: yinbo.zhu 
> Signed-off-by: Ran Wang 
> ---

>You should better have a version history here to tell what's changed between 
>version.

>I will add a version history on next v3 patch
Hi,

I had modified the code as v4 version, 
https://patchwork.kernel.org/patch/10027393/
please check.

Thanks,
BRs
>  arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts |  8 
>  arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi| 20 
>  2 files changed, 28 insertions(+)
> 
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> index 213abb72de93..6c3c3bc4b681 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a-rdb.dts
> @@ -118,6 +118,14 @@
>   status = "okay";
>  };
>  
> +&usb0 {
> + status = "okay";
> +};
> +
> +&usb1 {
> + status = "okay";
> +};
> +
>  &esdhc {

>Please sort these labeled nodes alphabetically.

>Shawn

>   status = "okay";
>  };
> diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi 
> b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> index c144d06a6e33..c23fede8cf5d 100644
> --- a/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> +++ b/arch/arm64/boot/dts/freescale/fsl-ls1088a.dtsi
> @@ -359,6 +359,26 @@
>   status = "disabled";
>   };
>  
> + usb0: usb3@310 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x310 0x0 0x1>;
> + interrupts = <0 80 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
> + usb1: usb3@311 {
> + compatible = "snps,dwc3";
> + reg = <0x0 0x311 0x0 0x1>;
> + interrupts = <0 81 IRQ_TYPE_LEVEL_HIGH>;
> + dr_mode = "host";
> + snps,quirk-frame-length-adjustment = <0x20>;
> + snps,dis_rxdet_inp3_quirk;
> + status = "disabled";
> + };
> +
>   sata: sata@320 {
>   compatible = "fsl,ls1088a-ahci";
>   reg = <0x0 0x320 0x0 0x1>,
> --
> 2.14.1
> 

Re: [PATCH 4.9 00/87] 4.9.62-stable review --> crash

[Greg Kroah-Hartman]

On Tue, Nov 14, 2017 at 08:46:25AM +0100, Sebastian Gottschall wrote:
> Am 14.11.2017 um 08:41 schrieb Greg Kroah-Hartman:
> > On Tue, Nov 14, 2017 at 07:48:47AM +0100, Sebastian Gottschall wrote:
> > > ahm it compiles well. but
> > > 
> > > [   24.838120] Unable to handle kernel NULL pointer dereference at virtual
> > > address 0055
> > > [   24.846193] pgd = c0004000
> > > [   24.848893] [0055] *pgd=
> > > [   24.852472] Internal error: Oops - BUG: 817 [#1] PREEMPT SMP ARM
> > > [   24.858463] Modules linked in: xhci_plat_hcd xhci_pci xhci_hcd ohci_hcd
> > > ehci_pci ehci_platform ehci_hcd usbcore usb_common nls_base qca_ssdk
> > > gpio_pca953x mii_gpio wil6210 ath10k_pci ath10k_core ath9k ath9k_common
> > > ath9k_hw ath mac80211 cfg80211 compat
> > > [   24.880852] CPU: 2 PID: 0 Comm: swapper/2 Not tainted 4.9.62-rc1 #90
> > > [   24.887189] Hardware name: AnnapurnaLabs Alpine (Device Tree)
> > > [   24.892921] task: ef029ac0 task.stack: ef05a000
> > > [   24.897444] PC is at nf_nat_cleanup_conntrack+0x4c/0x74
> > > [   24.902657] LR is at nf_nat_cleanup_conntrack+0x38/0x74
> > > [   24.907869] pc : []    lr : []    psr: 6153
> > > [   24.907869] sp : ef05bb58  ip : ef05bb58  fp : ef05bb6c
> > > [   24.919317] r10: ed230cc0  r9 : ed230c00  r8 : edf45800
> > > [   24.924529] r7 : ebcd2f00  r6 : ec33739e  r5 : c0892294  r4 : ebcd2f00
> > > [   24.931040] r3 :   r2 : 0055  r1 :   r0 : c0892718
> > > [   24.937551] Flags: nZCv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  
> > > Segment
> > > user
> > > [   24.944755] Control: 10c5387d  Table: 2bd1006a  DAC: 0055
> > > [   24.950486] Process swapper/2 (pid: 0, stack limit = 0xef05a210)
> > > [   24.956477] Stack: (0xef05bb58 to 0xef05c000)
> > > 
> > > 
> > > will dig into the code to find the reason
> > Can you run 'git bisect' or if you use quilt, do a manual bisect to find
> > the offending patch?
> 
> already done
> 
> netfilter: nat: Revert "netfilter: nat: convert nat bysrc hash to
> rhashtable"
> 
> this one caused the crash. if i revert it, its working again

Ah nice.  Do you also have the crash in 4.14 with that patch, as it is
in there too.

thanks,

greg k-h

[PATCH V2] kdump: print a message in case parse_crashkernel_mem resulted in zero bytes

[Dave Young]

In parse_crashkernel_mem, it silently return in case we get zero
bytes in the parsing function.  It is useful for debugging for
adding a message especially sometimes kernel can not boot
up correctly.

Add a pr_info instead of pr_warn because it is expected behavior for
size = 0, eg. crashkernel=2G-4G:128M, size will be 0 in case system
memory is less than 2G.

Signed-off-by: Dave Young 
---
[v1 -> v2]: bhsharma: pr_warn looks confusing because of return 0
 kernel/crash_core.c |3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

--- linux-x86.orig/kernel/crash_core.c
+++ linux-x86/kernel/crash_core.c
@@ -108,7 +108,8 @@ static int __init parse_crashkernel_mem(
return -EINVAL;
}
}
-   }
+   } else
+   pr_info("crashkernel size resulted in zero bytes\n");
 
return 0;
 }

Coccinelle: badzero.cocci failure

[Masahiro Yamada]

Hi Coccinelle developers,


When I was working on my patch, I was hit by another issue.

badzero.cocci failed on all modes.


Can you take a look at it, please?



I tried to use DEBUG_FILE and dump the log,
but I could not get a clue of the cause of the failure.

My spatch version is:
spatch version 1.0.6-00345-g2ca0bef compiled with OCaml version 4.02.3




The following is the result on my PC:


$ make  coccicheck  COCCI=scripts/coccinelle/null/badzero.cocci  MODE=report

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

coccicheck failed
$ make  coccicheck  COCCI=scripts/coccinelle/null/badzero.cocci  MODE=patch

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

coccicheck failed
$ make  coccicheck  COCCI=scripts/coccinelle/null/badzero.cocci  MODE=context

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

coccicheck failed
$ make  coccicheck  COCCI=scripts/coccinelle/null/badzero.cocci  MODE=org

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

coccicheck failed
$ make  coccicheck  COCCI=scripts/coccinelle/null/badzero.cocci
MODE=report  DEBUG_FILE=cocci-debug.txt

Please check for false positives in the output before submitting a patch.
When using "patch" mode, carefully review the patch before submitting it.

coccicheck failed
$ cat cocci-debug.txt
/home/masahiro/bin/spatch -D report --no-show-diff --very-quiet
--cocci-file scripts/coccinelle/null/badzero.cocci --dir . -I
./arch/x86/include -I ./arch/x86/include/generated -I ./include -I
./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I
./include/uapi -I ./include/generated/uapi --include
./include/linux/kconfig.h --jobs 8 --chunksize 1
Fatal error: exception
Yes_prepare_ocamlcocci.LinkFailure("/tmp/ocaml_cocci_18c9f9.cmxs")






-- 
Best Regards
Masahiro Yamada

Re: KASAN: use-after-free Read in worker_thread (2)

[Dmitry Vyukov]

On Fri, Nov 10, 2017 at 7:49 PM, Cong Wang  wrote:
> On Wed, Nov 8, 2017 at 5:00 AM, Dmitry Vyukov  wrote:
>> On Wed, Nov 8, 2017 at 1:58 PM, syzbot
>> 
>> wrote:
>>> Hello,
>>>
>>> syzkaller hit the following crash on
>>> 7dfaa7bc99498da1c6c4a48bee8d2d5265161a8c
>>> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
>>> compiler: gcc (GCC) 7.1.1 20170620
>>> .config is attached
>>> Raw console output is attached.
>>>
>>> Unfortunately, I don't have any reproducer for this bug yet.
>>>
>>
>>
>> I guess this is more about kcmsock.c rather than workqueue.c. +kcm 
>> maintainers.
>
>
> Looks like the work is not cancelled before being freed on this path.
> Do you have a C reproducer for me to try?

This is answered in the email text and the referenced link. If the
wording is not clear, we should improve it.


>>> ==
>>> BUG: KASAN: use-after-free in worker_thread+0x15bb/0x1990
>>> kernel/workqueue.c:2245
>>> Read of size 8 at addr 8801c3a74110 by task kworker/u4:6/3515
>>>
>>> CPU: 1 PID: 3515 Comm: kworker/u4:6 Not tainted 4.14.0-rc7+ #112
>>> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
>>> Google 01/01/2011
>>> Call Trace:
>>>  __dump_stack lib/dump_stack.c:17 [inline]
>>>  dump_stack+0x194/0x257 lib/dump_stack.c:53
>>>  print_address_description+0x73/0x250 mm/kasan/report.c:252
>>>  kasan_report_error mm/kasan/report.c:351 [inline]
>>>  kasan_report+0x25b/0x340 mm/kasan/report.c:409
>>>  __asan_report_load8_noabort+0x14/0x20 mm/kasan/report.c:430
>>>  worker_thread+0x15bb/0x1990 kernel/workqueue.c:2245
>>>  kthread+0x35e/0x430 kernel/kthread.c:231
>>>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
>>>
>>> Allocated by task 31482:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>>  set_track mm/kasan/kasan.c:459 [inline]
>>>  kasan_kmalloc+0xad/0xe0 mm/kasan/kasan.c:551
>>>  kasan_slab_alloc+0x12/0x20 mm/kasan/kasan.c:489
>>>  kmem_cache_alloc+0x12e/0x760 mm/slab.c:3562
>>>  kmem_cache_zalloc include/linux/slab.h:657 [inline]
>>>  kcm_attach net/kcm/kcmsock.c:1394 [inline]
>>>  kcm_attach_ioctl net/kcm/kcmsock.c:1460 [inline]
>>>  kcm_ioctl+0x2d1/0x1610 net/kcm/kcmsock.c:1695
>>>  sock_do_ioctl+0x65/0xb0 net/socket.c:961
>>>  sock_ioctl+0x2c2/0x440 net/socket.c:1058
>>>  vfs_ioctl fs/ioctl.c:46 [inline]
>>>  do_vfs_ioctl+0x1b1/0x1520 fs/ioctl.c:686
>>>  SYSC_ioctl fs/ioctl.c:701 [inline]
>>>  SyS_ioctl+0x8f/0xc0 fs/ioctl.c:692
>>>  entry_SYSCALL_64_fastpath+0x1f/0xbe
>>>
>>> Freed by task 1249:
>>>  save_stack_trace+0x16/0x20 arch/x86/kernel/stacktrace.c:59
>>>  save_stack+0x43/0xd0 mm/kasan/kasan.c:447
>>>  set_track mm/kasan/kasan.c:459 [inline]
>>>  kasan_slab_free+0x71/0xc0 mm/kasan/kasan.c:524
>>>  __cache_free mm/slab.c:3504 [inline]
>>>  kmem_cache_free+0x77/0x280 mm/slab.c:3764
>>>  unreserve_psock+0x5a1/0x780 net/kcm/kcmsock.c:547
>>>  kcm_write_msgs+0xbae/0x1b80 net/kcm/kcmsock.c:590
>>>  kcm_tx_work+0x2e/0x190 net/kcm/kcmsock.c:731
>>>  process_one_work+0xbf0/0x1bc0 kernel/workqueue.c:2113
>>>  worker_thread+0x223/0x1990 kernel/workqueue.c:2247
>>>  kthread+0x35e/0x430 kernel/kthread.c:231
>>>  ret_from_fork+0x2a/0x40 arch/x86/entry/entry_64.S:432
>>>
>>> The buggy address belongs to the object at 8801c3a74040
>>>  which belongs to the cache kcm_psock_cache of size 552
>>> The buggy address is located 208 bytes inside of
>>>  552-byte region [8801c3a74040, 8801c3a74268)
>>> The buggy address belongs to the page:
>>> page:ea00070e9d00 count:1 mapcount:0 mapping:8801c3a74040 index:0x0
>>> compound_mapcount: 0
>>> flags: 0x2fffc008100(slab|head)
>>> raw: 02fffc008100 8801c3a74040  0001000b
>>> raw: ea00067920a0 8801d3f39948 8801d3f2a840 
>>> page dumped because: kasan: bad access detected
>>>
>>> Memory state around the buggy address:
>>>  8801c3a74000: fc fc fc fc fc fc fc fc fb fb fb fb fb fb fb fb
>>>  8801c3a74080: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb

 8801c3a74100: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>
>>>  ^
>>>  8801c3a74180: fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb fb
>>>  8801c3a74200: fb fb fb fb fb fb fb fb fb fb fb fb fb fc fc fc
>>> ==
>>>
>>>
>>> ---
>>> This bug is generated by a dumb bot. It may contain errors.
>>> See https://goo.gl/tpsmEJ for details.
>>> Direct all questions to syzkal...@googlegroups.com.
>>> Please credit me with: Reported-by: syzbot 
>>>
>>> syzbot will keep track of this bug report.
>>> Once a fix for this bug is committed, please reply to this email with:
>>> #syz fix: exact-commit-title
>>> To mark this as a duplicate of another syzbot report, please reply with:
>>> #syz dup: exact-subject-of-another-report
>>> If it's a one-off invalid bug report,

Re: [PATCH] m68k: add missing SOFTIRQENTRY_TEXT linker section

[Geert Uytterhoeven]

Hi Greg,

CC mingo, Hiramatsu-san, linux-arch, lkml

On Tue, Nov 14, 2017 at 7:04 AM, Greg Ungerer  wrote:
> Commit be7635e7287e ("arch, ftrace: for KASAN put hard/soft IRQ entries
> into separate sections") added a new linker section, SOFTIRQENTRY_TEXT,
> to the linker scripts for most architectures. It didn't add it to any of
> the linker scripts for the m68k architecture. This was not really a problem
> because it is only defined if either of CONFIG_FUNCTION_GRAPH_TRACER or
> CONFIG_KASAN are enabled - which can never be true for m68k.
>
> However commit 229a71860547 ("irq: Make the irqentry text section
> unconditional") means that SOFTIRQENTRY_TEXT is now always defined. So on
> m68k we now end up with a separate ELF section for .softirqentry.text
> instead of it being part of the .text section. On some m68k targets in some

Nice catch!

+10 other architectures also don't have the section.

> configurations this can also cause a fatal link error:
>
>   LD  vmlinux
> /usr/local/bin/../m68k-uclinux/bin/ld.real: section .softirqentry.text loaded 
> at [10de10c0,10de12dd] overlaps section .rodata loaded at 
> [10de10c0,10e0fd67]

How does it cause the overlap?

For me, "readelf -S vmlinux" gives:

There are 21 section headers, starting at offset 0x524850:

Section Headers:
  [Nr] Name  TypeAddr OffSize   ES Flg Lk Inf Al
  [ 0]   NULL 00 00 00  0   0  0
  [ 1] .text PROGBITS1000 001000 2dacb4 00  AX  0   0  4
  [ 2] .softirqentry.tex PROGBITS002dbcb4 2dbcb4 0001a0 00  AX  0   0  2
  [ 3] __ex_tablePROGBITS002dbe60 2dbe60 0027f0 00   A  0   0  4
  [ 4] .rodata   PROGBITS002df000 2df000 09ee20 00  WA  0   0 16
  [ 5] __ksymtab PROGBITS0037de20 37de20 006538 00   A  0   0  2
  [ 6] __ksymtab_gpl PROGBITS00384358 384358 003f08 00   A  0   0  2
  [ 7] __ksymtab_strings PROGBITS00388260 388260 01747d 00   A  0   0  1
  [ 8] __param   PROGBITS0039f6e0 39f6e0 000924 00   A  0   0  4
  [ 9] __modver  PROGBITS003a0004 3a0004 000ffc 00   A  0   0  2
  [10] .data PROGBITS003a1000 3a1000 021c20 00  WA  0   0 32
  [11] .bss  NOBITS  003c2c20 3c2c20 02b2fc 00  WA  0   0 16
  [12] .init.textPROGBITS003ee000 3c4000 01a4b2 00  AX  0   0  4
  [13] .init.dataPROGBITS004084b4 3de4b4 008180 00  WA  0   0  4
  [14] .m68k_fixup   PROGBITS00410634 3e6634 001140 00  WA  0   0  1
  [15] .notesNOTE00411774 3e7774 24 00   A  0   0  4
  [16] .init_end NOBITS  00411798 3e7798 000868 00  WA  0   0  1
  [17] .comment  PROGBITS 3e7798 39 01  MS  0   0  1
  [18] .shstrtab STRTAB   524791 bd 00  0   0  1
  [19] .symtab   SYMTAB   3e77d4 0a66e0 10
20 32238  4
  [20] .strtab   STRTAB   48deb4 0968dd 00  0   0  1
Key to Flags:
  W (write), A (alloc), X (execute), M (merge), S (strings)
  I (info), L (link order), G (group), T (TLS), E (exclude), x (unknown)
  O (extra OS processing required) o (OS specific), p (processor specific)

> To fix add in the missing SOFTIRQENTRY_TEXT section into the m68k linker
> scripts. I noticed that m68k is also missing the IRQENTRY_TEXT section,
> so this patch also adds an entry for that too.
>
> Signed-off-by: Greg Ungerer 
> ---
>  arch/m68k/kernel/vmlinux-nommu.lds | 2 ++
>  arch/m68k/kernel/vmlinux-std.lds   | 2 ++
>  arch/m68k/kernel/vmlinux-sun3.lds  | 2 ++
>  3 files changed, 6 insertions(+)
>
> diff --git a/arch/m68k/kernel/vmlinux-nommu.lds 
> b/arch/m68k/kernel/vmlinux-nommu.lds
> index 3aa571a..cf6edda 100644
> --- a/arch/m68k/kernel/vmlinux-nommu.lds
> +++ b/arch/m68k/kernel/vmlinux-nommu.lds
> @@ -45,6 +45,8 @@ SECTIONS {
> .text : {
> HEAD_TEXT
> TEXT_TEXT
> +   IRQENTRY_TEXT
> +   SOFTIRQENTRY_TEXT
> SCHED_TEXT
> CPUIDLE_TEXT
> LOCK_TEXT
> diff --git a/arch/m68k/kernel/vmlinux-std.lds 
> b/arch/m68k/kernel/vmlinux-std.lds
> index 89172b8..625a578 100644
> --- a/arch/m68k/kernel/vmlinux-std.lds
> +++ b/arch/m68k/kernel/vmlinux-std.lds
> @@ -16,6 +16,8 @@ SECTIONS
>.text : {
> HEAD_TEXT
> TEXT_TEXT
> +   IRQENTRY_TEXT
> +   SOFTIRQENTRY_TEXT
> SCHED_TEXT
> CPUIDLE_TEXT
> LOCK_TEXT
> diff --git a/arch/m68k/kernel/vmlinux-sun3.lds 
> b/arch/m68k/kernel/vmlinux-sun3.lds
> index 293990e..9868270 100644
> --- a/arch/m68k/kernel/vmlinux-sun3.lds
> +++ b/arch/m68k/kernel/vmlinux-sun3.lds
> @@ -16,6 +16,8 @@ SECTIONS
>.text : {
> HEAD_TEXT
> TEXT_TEXT
> +   IRQENTRY_TEXT
> +   SOFTIRQENTRY_TEXT
> SCHED_TEXT
> CPUIDLE_TEXT

[PATCH] atm: horizon: Fix irq release error

[Arvind Yadav]

atm_dev_register() can fail here and passed parameters to free irq
which is not initialised. Initialization of 'dev->irq' happened after
the 'goto out_free_irq'. So using 'irq' insted of 'dev->irq' in
free_irq().

Signed-off-by: Arvind Yadav 
---
 drivers/atm/horizon.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/atm/horizon.c b/drivers/atm/horizon.c
index 7e76b35..e121b84 100644
--- a/drivers/atm/horizon.c
+++ b/drivers/atm/horizon.c
@@ -2803,7 +2803,7 @@ static int hrz_probe(struct pci_dev *pci_dev,
return err;
 
 out_free_irq:
-   free_irq(dev->irq, dev);
+   free_irq(irq, dev);
 out_free:
kfree(dev);
 out_release:
-- 
1.9.1

Re: CONFIG_DEBUG_INFO_SPLIT impacts on faddr2line

[Fengguang Wu]

Hi Andi,

On Mon, Nov 13, 2017 at 10:52:27AM -0800, Andi Kleen wrote:

> It's the "CONFIG_DEBUG_INFO_SPLIT" thing that makes faddr2line unable
> to see the inlining information,
>
> Using OPTIMIZE_INLINING is fine.

Good to know that!


It works for me. Perhaps your binutils is too old? It was
added at some point. Can you try upgrading?

% ./linux/scripts/faddr2line obj/vmlinux schedule+10
schedule+10/0x80:
schedule at arch/x86/include/asm/current.h:15

% addr2line --version
GNU addr2line version 2.27-24.fc26


I use debian and tried addr2line in 2 systems:

GNU addr2line (GNU Binutils for Debian) 2.28
GNU addr2line (GNU Binutils for Debian) 2.29.1

Regards,
Fengguang

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

[Quan Xu]

On 2017/11/14 15:12, Wanpeng Li wrote:

2017-11-14 15:02 GMT+08:00 Quan Xu :


On 2017/11/13 18:53, Juergen Gross wrote:

On 13/11/17 11:06, Quan Xu wrote:

From: Quan Xu 

So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.

In virtualization, idle path includes several heavy operations
includes timer access(LAPIC timer or TSC deadline timer) which will
hurt performance especially for latency intensive workload like message
passing task. The cost is mainly from the vmexit which is a hardware
context switch between virtual machine and hypervisor. Our solution is
to poll for a while and do not enter real idle path if we can get the
schedule event during polling.

Poll may cause the CPU waste so we adopt a smart polling mechanism to
reduce the useless poll.

Signed-off-by: Yang Zhang 
Signed-off-by: Quan Xu 
Cc: Juergen Gross 
Cc: Alok Kataria 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org

Hmm, is the idle entry path really so critical to performance that a new
pvops function is necessary?

Juergen, Here is the data we get when running benchmark netperf:
  1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
 29031.6 bit/s -- 76.1 %CPU

  2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
 35787.7 bit/s -- 129.4 %CPU

  3. w/ kvm dynamic poll:
 35735.6 bit/s -- 200.0 %CPU

Actually we can reduce the CPU utilization by sleeping a period of
time as what has already been done in the poll logic of IO subsystem,
then we can improve the algorithm in kvm instead of introduing another
duplicate one in the kvm guest.

We really appreciate upstream's kvm dynamic poll mechanism, which is
really helpful for a lot of scenario..

However, as description said, in virtualization, idle path includes
several heavy operations includes timer access (LAPIC timer or TSC
deadline timer) which will hurt performance especially for latency
intensive workload like message passing task. The cost is mainly from
the vmexit which is a hardware context switch between virtual machine
and hypervisor.

for upstream's kvm dynamic poll mechanism, even you could provide a
better algorism, how could you bypass timer access (LAPIC timer or TSC
deadline timer), or a hardware context switch between virtual machine
and hypervisor. I know these is a tradeoff.

Furthermore, here is the data we get when running benchmark contextswitch
to measure the latency(lower is better):

1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
  3402.9 ns/ctxsw -- 199.8 %CPU

2. w/ patch and disable kvm dynamic poll:
  1163.5 ns/ctxsw -- 205.5 %CPU

3. w/ kvm dynamic poll:
  2280.6 ns/ctxsw -- 199.5 %CPU

so, these tow solution are quite similar, but not duplicate..

that's also why to add a generic idle poll before enter real idle path.
When a reschedule event is pending, we can bypass the real idle path.


Quan
Alibaba Cloud





Regards,
Wanpeng Li


  4. w/patch and w/ kvm dynamic poll:
 42225.3 bit/s -- 198.7 %CPU

  5. idle=poll
 37081.7 bit/s -- 998.1 %CPU



  w/ this patch, we will improve performance by 23%.. even we could improve
  performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
  cost of CPU is much lower than 'idle=poll' case..


Wouldn't a function pointer, maybe guarded
by a static key, be enough? A further advantage would be that this would
work on other architectures, too.


I assume this feature will be ported to other archs.. a new pvops makes code
clean and easy to maintain. also I tried to add it into existed pvops, but
it
doesn't match.



Quan
Alibaba Cloud


Juergen

Re: [PATCH] mm: show stats for non-default hugepage sizes in /proc/meminfo

[Michal Hocko]

On Mon 13-11-17 16:33:05, Roman Gushchin wrote:
[...]
> IMO, /proc/meminfo should give a user a high-level overview of memory usage
> in the system, without a need to look into other places. Of course, we always
> have some amount of unaccounted memory, but it shouldn't be measured in Gb,
> as in this case.

Well, this is not so easy. There can be _a lot_ of unaccounted memory.
Gbs is not something unheard of (fs metadata directly allocated by the
page allocator, network buffers, you name it). Unlike those the hugetlb
requires an explicit admin interaction. Especially for the non-default
hugetlb page sizes.

-- 
Michal Hocko
SUSE Labs

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

[Wanpeng Li]

2017-11-14 16:15 GMT+08:00 Quan Xu :
>
>
> On 2017/11/14 15:12, Wanpeng Li wrote:
>>
>> 2017-11-14 15:02 GMT+08:00 Quan Xu :
>>>
>>>
>>> On 2017/11/13 18:53, Juergen Gross wrote:

 On 13/11/17 11:06, Quan Xu wrote:
>
> From: Quan Xu 
>
> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
> in idle path which will poll for a while before we enter the real idle
> state.
>
> In virtualization, idle path includes several heavy operations
> includes timer access(LAPIC timer or TSC deadline timer) which will
> hurt performance especially for latency intensive workload like message
> passing task. The cost is mainly from the vmexit which is a hardware
> context switch between virtual machine and hypervisor. Our solution is
> to poll for a while and do not enter real idle path if we can get the
> schedule event during polling.
>
> Poll may cause the CPU waste so we adopt a smart polling mechanism to
> reduce the useless poll.
>
> Signed-off-by: Yang Zhang 
> Signed-off-by: Quan Xu 
> Cc: Juergen Gross 
> Cc: Alok Kataria 
> Cc: Rusty Russell 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org

 Hmm, is the idle entry path really so critical to performance that a new
 pvops function is necessary?
>>>
>>> Juergen, Here is the data we get when running benchmark netperf:
>>>   1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
>>>  29031.6 bit/s -- 76.1 %CPU
>>>
>>>   2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
>>>  35787.7 bit/s -- 129.4 %CPU
>>>
>>>   3. w/ kvm dynamic poll:
>>>  35735.6 bit/s -- 200.0 %CPU
>>
>> Actually we can reduce the CPU utilization by sleeping a period of
>> time as what has already been done in the poll logic of IO subsystem,
>> then we can improve the algorithm in kvm instead of introduing another
>> duplicate one in the kvm guest.
>
> We really appreciate upstream's kvm dynamic poll mechanism, which is
> really helpful for a lot of scenario..
>
> However, as description said, in virtualization, idle path includes
> several heavy operations includes timer access (LAPIC timer or TSC
> deadline timer) which will hurt performance especially for latency
> intensive workload like message passing task. The cost is mainly from
> the vmexit which is a hardware context switch between virtual machine
> and hypervisor.
>
> for upstream's kvm dynamic poll mechanism, even you could provide a
> better algorism, how could you bypass timer access (LAPIC timer or TSC
> deadline timer), or a hardware context switch between virtual machine
> and hypervisor. I know these is a tradeoff.
>
> Furthermore, here is the data we get when running benchmark contextswitch
> to measure the latency(lower is better):
>
> 1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
>   3402.9 ns/ctxsw -- 199.8 %CPU
>
> 2. w/ patch and disable kvm dynamic poll:
>   1163.5 ns/ctxsw -- 205.5 %CPU
>
> 3. w/ kvm dynamic poll:
>   2280.6 ns/ctxsw -- 199.5 %CPU
>
> so, these tow solution are quite similar, but not duplicate..
>
> that's also why to add a generic idle poll before enter real idle path.
> When a reschedule event is pending, we can bypass the real idle path.
>

There is a similar logic in the idle governor/driver, so how this
patchset influence the decision in the idle governor/driver when
running on bare-metal(power managment is not exposed to the guest so
we will not enter into idle driver in the guest)?

Regards,
Wanpeng Li

Re: [PATCH v5 11/11] intel_sgx: driver documentation

[Borislav Petkov]

On Mon, Nov 13, 2017 at 09:45:28PM +0200, Jarkko Sakkinen wrote:

<--- and yeah, all those patches without a commit message, need one.

> Signed-off-by: Jarkko Sakkinen 
> ---
>  Documentation/index.rst |   1 +
>  Documentation/x86/intel_sgx.rst | 131 
> 
>  2 files changed, 132 insertions(+)
>  create mode 100644 Documentation/x86/intel_sgx.rst

...

> +Launch control
> +==
> +
> +For launching an enclave, two structures must be provided for ENCLS(EINIT):
> +
> +1. **SIGSTRUCT:** a signed measurement of the enclave binary.
> +2. **EINITTOKEN:** the measurement, the public key of the signer and various
> +   enclave attributes. This structure contains a MAC of its contents using
> +   hardware derived symmetric key called *launch key*.
> +
> +The hardware platform contains a root key pair for signing the SIGTRUCT
> +for a *launch enclave* that is able to acquire the *launch key* for
> +creating EINITTOKEN's for other enclaves.  For the launch enclave
> +EINITTOKEN is not needed because it is signed with the private root key.
> +
> +There are two feature control bits associate with launch control
> +
> +* **IA32_FEATURE_CONTROL[0]**: locks down the feature control register
> +* **IA32_FEATURE_CONTROL[17]**: allow runtime reconfiguration of
> +  IA32_SGXLEPUBKEYHASHn MSRs that define MRSIGNER hash for the launch
> +  enclave. Essentially they define a signing key that does not require
> +  EINITTOKEN to be let run.
> +
> +The BIOS can configure IA32_SGXLEPUBKEYHASHn MSRs before feature control
> +register is locked.
> +
> +It could be tempting to implement launch control by writing the MSRs
> +every time when an enclave is launched. This does not scale because for
> +generic case because BIOS might lock down the MSRs before handover to
> +the OS.

What does that mean exactly?

OEM vendor BIOS can control how many enclaves user can launch and what
signing key is loaded and lock down the feature control register so that
no other signing keys are loaded?

Or am I misreading this?

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

[RFC PATCH] drivers: base: dma-coherent: find free region without alignment

[Jaewon Kim]

dma-coherent uses bitmap API which internally consider align based on the
requested size. Depending on some usage pattern, using align, I think, may
be good for fast search and anti-fragmentation. But with the align, an
allocation may be failed.

This is a example, total size is 30MB, only few memory at front is being
used, and 9MB is being requsted. Then 9MB will be aligned to 16MB. The
first try on offset 0MB will be failed because of others already using. The
second try on offset 16MB will be failed because of ouf of bound.

So if the align is not necessary on dma-coherent, this patch removes the
align policy to allow allocation without increasing the total size.

Signed-off-by: Jaewon Kim 
---
 drivers/base/dma-coherent.c | 8 +---
 1 file changed, 5 insertions(+), 3 deletions(-)

diff --git a/drivers/base/dma-coherent.c b/drivers/base/dma-coherent.c
index 744f64f43454..b86a96d0cd07 100644
--- a/drivers/base/dma-coherent.c
+++ b/drivers/base/dma-coherent.c
@@ -162,7 +162,7 @@ EXPORT_SYMBOL(dma_mark_declared_memory_occupied);
 static void *__dma_alloc_from_coherent(struct dma_coherent_mem *mem,
ssize_t size, dma_addr_t *dma_handle)
 {
-   int order = get_order(size);
+   int nr_page = PAGE_ALIGN(size) >> PAGE_SHIFT;
unsigned long flags;
int pageno;
void *ret;
@@ -172,9 +172,11 @@ static void *__dma_alloc_from_coherent(struct 
dma_coherent_mem *mem,
if (unlikely(size > (mem->size << PAGE_SHIFT)))
goto err;
 
-   pageno = bitmap_find_free_region(mem->bitmap, mem->size, order);
-   if (unlikely(pageno < 0))
+   pageno = bitmap_find_next_zero_area(mem->bitmap, mem->size, 0,
+   nr_page, 0);
+   if (unlikely(pageno >= mem->size)) {
goto err;
+   bitmap_set(mem->bitmap, pageno, nr_page);
 
/*
 * Memory was found in the coherent area.
-- 
2.13.0

Re: 4.1 EOL

[Jani Nikula]

Tuncer, where's your bug report? Can't find one. Please file your bug at
the fdo bugzilla.

Thanks,
Jani.

On Mon, 13 Nov 2017, alexander.le...@verizon.com wrote:
> I've cc'ed some folks in hopes to get this resolved upstream.
>
> Either way, 4.1's EoL was previously moved to about 6 months from now,
> so hopefully we'll have more than enough time to get this resolved.
>
> On Sat, Nov 11, 2017 at 10:13:55PM +, Tuncer Ayaz wrote:
>>The predicament I'm in on my machines is that ever since drm-intel has
>>implemented atomic modesetting, there's a list regressions caused by
>>those fundamental architecture changes and the code churn it implied.
>>This means 4.1 is (from what I can tell) the last kernel before atomic
>>modesetting was added and the only kernel free of all those issues
>>which necessitate trying out various combinations of flags on the
>>kernel cmdline.
>>
>>For instance, right now I'm trying 4.13.12 with these flags:
>>video=SVIDEO-1:d
>>i915.semaphores=1
>>i915.enable_rc6=0
>>i915.enable_psr=0
>>intel_iommu=igfx_off
>>
>>PS: I'm kinda confused how anyone uses DMAR with VT-d when it's known
>>to be buggy.
>>
>>The flags seem to decrease the chances of provoking the bugs, but after a
>>day of running Xorg, it's possible to still hit the RCS0 GPU hangs.
>>
>>If you don't pass video=SVIDEO-1:d, then atomic's flip_done times out
>>on boot or exit to VT console. It's good that other people have the same
>>issues and have been following the bugzilla tickets, and con confirm
>>the results.
>>
>>I'm kinda glad I don't have a machine that's newer than Sandybridge
>>since that means I can use 4.1, though it's not a long-term solution,
>>and the plan is for the reported bugzilla tickets to be resolved at
>>some point, or me switching away from Intel GPUs, which might be
>>doable if I save money and get an AMD APU laptop next summer and
>>switch my desktop to a discrete GPU.
>>
>>For example:
>>https://bugs.freedesktop.org/show_bug.cgi?id=101237
>>https://bugs.freedesktop.org/show_bug.cgi?id=103076
>>https://bbs.archlinux.org/viewtopic.php?id=218581&p=3
>>https://bugs.archlinux.org/task/51703
>>
>>So, since 4.4, 4.9 and 4.12, drm-tip are still regressive,
>>I wanted to ask if you considered pushing back 4.1's EOL.
>>
>>Given a look at bugzilla, I have the impression that those issues will
>>need at least another year before they're fixed, since most of them
>>have been sitting there for many, many months. I suspect the Intel DRM
>>team doesn't have the bandwidth to address the issues in a timely
>>fashion while still adding upbringing for new GPUs and features
>>(fences, etc.).
>>
>>The generic modesetting DDX and Wayland are less susceptible to the
>>GPU hangs, but can be made to provoke it if tried long enough.
>>However, the modesetting DDX tears heavily and is about to gain atomic
>>modesetting in the next Xorg release, so will suffer from the same
>>easy GPU hang likelihood.
>>
>>Prior to SandyBridge there was zero tearing but beginning with
>>SandyBridge xf86-video-intel's TearFree=TRUE is the only reliable way
>>to fix Xorg tearing.
>>
>>I do appreciate you maintaining 4.1 so far and hate to admit that I'm
>>reliant on it on more than two machines, before and after Sandybridge,
>>exluding those machines which need a newer kernel. I also understand
>>how much work this is and since I'm not using Linux professionally for
>>a product, I can't offer compensation for your time. I can only offer
>>to collect and point you at a list of DRM bugs for validation of my
>>claims.

-- 
Jani Nikula, Intel Open Source Technology Center

[PATCH v8 0/6] stm32 clocksource driver rework

[Benjamin Gaignard]

version 8:
 - rebased on timers/core
 - change timer_of_exit() name to timer_of_cleanup()
 - update stm32 clocksource driver to use this function

version 7:
 - reword "clocksource: stm32: only use 32 bits timers" commit message
   to give more details about why 16 bits are problematics.

version 6:
 - add dedicated patch min delta change
 - rework commit messages, I hope it will be better now
 - change new function name from timer_of_deinit to timer_of_exit
 - make stm32_clock_event_set_next_event() safer like done in other
   drivers

version 6:
- add timer_of_deinit function in core
- rework failure cases in probe function

version 5:
- rebase on top of timer/core branch
- rework commit message of the first patch

version 4:
- split patch in 3 parts
  - convert code to timer_of
  - only use 32 bits timers
  - add clocksource support

version 3:
- fix comments done by Daniel
- use timer_of helper functions

version 2:
- fix uninitialized variable

Benjamin Gaignard (6):
  clocksource: timer_of: rename timer_of_exit to timer_of_cleanup
  clocksource: stm32: convert driver to timer_of
  clocksource: stm32: increase min delta value
  clocksource: stm32: only use 32 bits timers
  clocksource: stm32: add clocksource support
  arm: dts: stm32: remove useless clocksource nodes

 arch/arm/boot/dts/stm32f429.dtsi  |  32 -
 arch/arm/boot/dts/stm32f746.dtsi  |  32 -
 drivers/clocksource/Kconfig   |   1 +
 drivers/clocksource/timer-of.c|   9 +-
 drivers/clocksource/timer-of.h|   2 +-
 drivers/clocksource/timer-stm32.c | 242 --
 6 files changed, 138 insertions(+), 180 deletions(-)

-- 
2.7.4

Re: [PATCH] HID: input: enable Totem on the Dell Canvas 27

[Peter Hutterer]

sorry, this one got stuck in my outbox.

On Fri, Nov 10, 2017 at 11:26:35AM +0100, Benjamin Tissoires wrote:
> The Dell Canvas 27 has a tool that can be put on the surface and acts
> as a dial. The firmware processes the detection of the tool and forward
> regular HID reports with X, Y, Azimuth, rotation, width/height.
> 
> The firmware also exports Contact ID, Countact Count which may hint that
> several totems can be used at the same time, but for now, only allow
> one totem at a time.
> 
> We also ignore scan time in hid-input.c because there is not much point
> to forward it now given that the indication of the tool being present
> is already provided through BTN_TOOL_DIAL.
> 
> We need to add a new BTN_TOOL_DIAL event because the HID mapping
> suggests that this tool is aimed at being used by the system and not
> the applications. Also this prevents current systemd heuristics to
> apply ID_INPUT_TOUCHSCREEN to this new type of devices.
> 
> I mapped Azimuth to ABS_WHEEL to somehow ressemble the Wacom Pads.

HID docs indicate this is a full tool rotation, so ABS_RZ would be more
appropriate?

"Azimuth 
The counter-clockwise rotation of the cursor about the Z-axis."

But you also say it has rotation, so this is a bit confusing now :)
We should also use INPUT_PROP_DIRECT here.

> Last, both Width and Heigth are groupped together, the FW reports

typo: grouped

> similar values for both and we are out of ABS_* events.
> 
> Link: https://bugzilla.redhat.com/show_bug.cgi?id=1511846
> 
> Signed-off-by: Benjamin Tissoires 
> ---
> 
> Hi,
> 
> This is probably v4.16 material as we are close to the merge window
> (I wouldn't mind it applied in v4.15 though ;-P)

I'm going to be annoying here and say I'd like to figure out how to add this
to libinput first to figure out what details can go wrong before we merge it
and commit to this forever. Hopefully that shouldn't take that long...

Cheers,
   Peter

> The patch does the job but we probably need to decide if the mappings
> I chose are correct.
> 
> For the record, I uploaded some evemu-record traces and hid-recorder
> traces in the RH Bz linked above to keep traces of them.
> The interesting one is the evemu one for the totem with this patch
> applied:
> https://bugzilla.redhat.com/attachment.cgi?id=1350389
> 
> Cheers,
> Benjamin
> 
>  drivers/hid/hid-input.c| 28 +++-
>  drivers/hid/hid-multitouch.c   | 11 +++
>  include/linux/hid.h|  6 ++
>  include/uapi/linux/input-event-codes.h |  1 +
>  4 files changed, 45 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
> index 04d01b57d94c..7da72b571b7d 100644
> --- a/drivers/hid/hid-input.c
> +++ b/drivers/hid/hid-input.c
> @@ -229,6 +229,7 @@ __s32 hidinput_calc_abs_res(const struct hid_field 
> *field, __u16 code)
>   case ABS_X:
>   case ABS_Y:
>   case ABS_Z:
> + case ABS_TOOL_WIDTH:
>   case ABS_MT_POSITION_X:
>   case ABS_MT_POSITION_Y:
>   case ABS_MT_TOOL_X:
> @@ -786,13 +787,24 @@ static void hidinput_configure_usage(struct hid_input 
> *hidinput, struct hid_fiel
>   map_abs_clear(ABS_TILT_Y);
>   break;
>  
> + case 0x3f: /* Azimuth */
> + map_abs_clear(ABS_WHEEL);
> + break;
> +
>   case 0x33: /* Touch */
> - case 0x42: /* TipSwitch */
>   case 0x43: /* TipSwitch2 */
>   device->quirks &= ~HID_QUIRK_NOTOUCH;
>   map_key_clear(BTN_TOUCH);
>   break;
>  
> + case 0x42: /* TipSwitch */
> + if (field->application == HID_GD_SYSTEM_MULTIAXIS) {
> + map_key_clear(BTN_TOOL_DIAL);
> + } else {
> + device->quirks &= ~HID_QUIRK_NOTOUCH;
> + map_key_clear(BTN_TOUCH);
> + }
> + break;
>   case 0x44: /* BarrelSwitch */
>   map_key_clear(BTN_STYLUS);
>   break;
> @@ -806,6 +818,20 @@ static void hidinput_configure_usage(struct hid_input 
> *hidinput, struct hid_fiel
>   map_key_clear(BTN_TOUCH);
>   break;
>  
> + case 0x48: /* WIDTH */
> + case 0x49: /* HEIGHT */
> + map_abs_clear(ABS_TOOL_WIDTH);
> + break;
> +
> + case 0x51: /* CONTACT ID */
> + goto ignore;
> +
> + case 0x54: /* CONTACT COUNT */
> + goto ignore;
> +
> + case 0x56: /* SCANTIME */
> + goto ignore;
> +
>   case 0x46: /* TabletPick */
>   case 0x5a: /* SecondaryBarrelSwitch */
>   map_key_clear(BTN_STYLUS2);
> diff --git a/drivers/hid/hid-multitouch.c 

[PATCH v8 2/6] clocksource: stm32: convert driver to timer_of

[Benjamin Gaignard]

Convert driver to use timer_of helpers. This allow to remove
custom proprietary structure.

Signed-off-by: Benjamin Gaignard 
---
 drivers/clocksource/Kconfig   |   1 +
 drivers/clocksource/timer-stm32.c | 160 ++
 2 files changed, 58 insertions(+), 103 deletions(-)

diff --git a/drivers/clocksource/Kconfig b/drivers/clocksource/Kconfig
index c729a88..28bc5595 100644
--- a/drivers/clocksource/Kconfig
+++ b/drivers/clocksource/Kconfig
@@ -269,6 +269,7 @@ config CLKSRC_STM32
bool "Clocksource for STM32 SoCs" if !ARCH_STM32
depends on OF && ARM && (ARCH_STM32 || COMPILE_TEST)
select CLKSRC_MMIO
+   select TIMER_OF
 
 config CLKSRC_MPS2
bool "Clocksource for MPS2 SoCs" if COMPILE_TEST
diff --git a/drivers/clocksource/timer-stm32.c 
b/drivers/clocksource/timer-stm32.c
index 8f24237..fc61fd1 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -17,6 +17,8 @@
 #include 
 #include 
 
+#include "timer-of.h"
+
 #define TIM_CR10x00
 #define TIM_DIER   0x0c
 #define TIM_SR 0x10
@@ -34,117 +36,84 @@
 
 #define TIM_EGR_UG BIT(0)
 
-struct stm32_clock_event_ddata {
-   struct clock_event_device evtdev;
-   unsigned periodic_top;
-   void __iomem *base;
-};
-
-static int stm32_clock_event_shutdown(struct clock_event_device *evtdev)
+static int stm32_clock_event_shutdown(struct clock_event_device *evt)
 {
-   struct stm32_clock_event_ddata *data =
-   container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
-   void *base = data->base;
+   struct timer_of *to = to_timer_of(evt);
 
-   writel_relaxed(0, base + TIM_CR1);
+   writel_relaxed(0, timer_of_base(to) + TIM_CR1);
return 0;
 }
 
-static int stm32_clock_event_set_periodic(struct clock_event_device *evtdev)
+static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
 {
-   struct stm32_clock_event_ddata *data =
-   container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
-   void *base = data->base;
+   struct timer_of *to = to_timer_of(evt);
+
+   writel_relaxed(timer_of_period(to), timer_of_base(to) + TIM_ARR);
+   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, timer_of_base(to) + TIM_CR1);
 
-   writel_relaxed(data->periodic_top, base + TIM_ARR);
-   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, base + TIM_CR1);
return 0;
 }
 
 static int stm32_clock_event_set_next_event(unsigned long evt,
-   struct clock_event_device *evtdev)
+   struct clock_event_device *clkevt)
 {
-   struct stm32_clock_event_ddata *data =
-   container_of(evtdev, struct stm32_clock_event_ddata, evtdev);
+   struct timer_of *to = to_timer_of(clkevt);
 
-   writel_relaxed(evt, data->base + TIM_ARR);
+   writel_relaxed(evt, timer_of_base(to) + TIM_ARR);
writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
-  data->base + TIM_CR1);
+  timer_of_base(to) + TIM_CR1);
 
return 0;
 }
 
 static irqreturn_t stm32_clock_event_handler(int irq, void *dev_id)
 {
-   struct stm32_clock_event_ddata *data = dev_id;
+   struct clock_event_device *evt = (struct clock_event_device *)dev_id;
+   struct timer_of *to = to_timer_of(evt);
 
-   writel_relaxed(0, data->base + TIM_SR);
+   writel_relaxed(0, timer_of_base(to) + TIM_SR);
 
-   data->evtdev.event_handler(&data->evtdev);
+   evt->event_handler(evt);
 
return IRQ_HANDLED;
 }
 
-static struct stm32_clock_event_ddata clock_event_ddata = {
-   .evtdev = {
-   .name = "stm32 clockevent",
-   .features = CLOCK_EVT_FEAT_ONESHOT | CLOCK_EVT_FEAT_PERIODIC,
-   .set_state_shutdown = stm32_clock_event_shutdown,
-   .set_state_periodic = stm32_clock_event_set_periodic,
-   .set_state_oneshot = stm32_clock_event_shutdown,
-   .tick_resume = stm32_clock_event_shutdown,
-   .set_next_event = stm32_clock_event_set_next_event,
-   .rating = 200,
-   },
-};
-
-static int __init stm32_clockevent_init(struct device_node *np)
+static int __init stm32_clockevent_init(struct device_node *node)
 {
-   struct stm32_clock_event_ddata *data = &clock_event_ddata;
-   struct clk *clk;
struct reset_control *rstc;
-   unsigned long rate, max_delta;
-   int irq, ret, bits, prescaler = 1;
-
-   clk = of_clk_get(np, 0);
-   if (IS_ERR(clk)) {
-   ret = PTR_ERR(clk);
-   pr_err("failed to get clock for clockevent (%d)\n", ret);
-   goto err_clk_get;
-   }
-
-   ret = clk_prepare_enable(clk);
-   if (ret) {
-   pr_err("failed to enable timer clock for clockevent (%d)\n",
-  ret);
-   goto err_clk_enable;
-   

[PATCH v8 1/6] clocksource: timer_of: rename timer_of_exit to timer_of_cleanup

[Benjamin Gaignard]

Change function name to something more explicit since it is only
used in init error cases.
Add __init annotation and description about the function usage.

Signed-off-by: Benjamin Gaignard 
---
 drivers/clocksource/timer-of.c | 9 -
 drivers/clocksource/timer-of.h | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
index 7c64a5c1..a319904 100644
--- a/drivers/clocksource/timer-of.c
+++ b/drivers/clocksource/timer-of.c
@@ -177,7 +177,14 @@ int __init timer_of_init(struct device_node *np, struct 
timer_of *to)
return ret;
 }
 
-void timer_of_exit(struct timer_of *to)
+/**
+ * timer_of_cleanup - release timer_of ressources
+ * @to: timer_of structure
+ *
+ * Release the ressources that has been used in timer_of_init().
+ * This function should be called in init error cases
+ */
+void __init timer_of_cleanup(struct timer_of *to)
 {
if (to->flags & TIMER_OF_IRQ)
timer_irq_exit(&to->of_irq);
diff --git a/drivers/clocksource/timer-of.h b/drivers/clocksource/timer-of.h
index 44f57e0..f521477 100644
--- a/drivers/clocksource/timer-of.h
+++ b/drivers/clocksource/timer-of.h
@@ -67,6 +67,6 @@ static inline unsigned long timer_of_period(struct timer_of 
*to)
 extern int __init timer_of_init(struct device_node *np,
struct timer_of *to);
 
-extern void timer_of_exit(struct timer_of *to);
+extern void __init timer_of_cleanup(struct timer_of *to);
 
 #endif
-- 
2.7.4

[PATCH v8 3/6] clocksource: stm32: increase min delta value

[Benjamin Gaignard]

The CPU is a CortexM4 @ 200MHZ and the clocks driving
the timers are at 90MHZ with a min delta at 1 you could
have an interrupt each 0.01 ms which is really to much.
By increase it to 0x60 it give more time (around 1 ms)
to CPU to handle the interrupt.

Signed-off-by: Benjamin Gaignard 
---
 drivers/clocksource/timer-stm32.c | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/drivers/clocksource/timer-stm32.c 
b/drivers/clocksource/timer-stm32.c
index fc61fd1..ae41a19 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -36,6 +36,8 @@
 
 #define TIM_EGR_UG BIT(0)
 
+#define MIN_DELTA  0x60
+
 static int stm32_clock_event_shutdown(struct clock_event_device *evt)
 {
struct timer_of *to = to_timer_of(evt);
@@ -129,7 +131,7 @@ static int __init stm32_clockevent_init(struct device_node 
*node)
writel_relaxed(0, timer_of_base(to) + TIM_SR);
 
clockevents_config_and_register(&to->clkevt,
-   timer_of_period(to), 0x1, max_delta);
+   timer_of_period(to), MIN_DELTA, 
max_delta);
 
pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
node, bits);
-- 
2.7.4

[PATCH v8 6/6] arm: dts: stm32: remove useless clocksource nodes

[Benjamin Gaignard]

16 bits timers aren't accurate enough to be used as
clocksource, remove them from stm32f4 and stm32f7 devicetree.

Signed-off-by: Benjamin Gaignard 
---
 arch/arm/boot/dts/stm32f429.dtsi | 32 
 arch/arm/boot/dts/stm32f746.dtsi | 32 
 2 files changed, 64 deletions(-)

diff --git a/arch/arm/boot/dts/stm32f429.dtsi b/arch/arm/boot/dts/stm32f429.dtsi
index dd7e99b..ac9a3e6 100644
--- a/arch/arm/boot/dts/stm32f429.dtsi
+++ b/arch/arm/boot/dts/stm32f429.dtsi
@@ -108,14 +108,6 @@
};
};
 
-   timer3: timer@4400 {
-   compatible = "st,stm32-timer";
-   reg = <0x4400 0x400>;
-   interrupts = <29>;
-   clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM3)>;
-   status = "disabled";
-   };
-
timers3: timers@4400 {
#address-cells = <1>;
#size-cells = <0>;
@@ -137,14 +129,6 @@
};
};
 
-   timer4: timer@4800 {
-   compatible = "st,stm32-timer";
-   reg = <0x4800 0x400>;
-   interrupts = <30>;
-   clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM4)>;
-   status = "disabled";
-   };
-
timers4: timers@4800 {
#address-cells = <1>;
#size-cells = <0>;
@@ -194,14 +178,6 @@
};
};
 
-   timer6: timer@40001000 {
-   compatible = "st,stm32-timer";
-   reg = <0x40001000 0x400>;
-   interrupts = <54>;
-   clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM6)>;
-   status = "disabled";
-   };
-
timers6: timers@40001000 {
#address-cells = <1>;
#size-cells = <0>;
@@ -218,14 +194,6 @@
};
};
 
-   timer7: timer@40001400 {
-   compatible = "st,stm32-timer";
-   reg = <0x40001400 0x400>;
-   interrupts = <55>;
-   clocks = <&rcc 0 STM32F4_APB1_CLOCK(TIM7)>;
-   status = "disabled";
-   };
-
timers7: timers@40001400 {
#address-cells = <1>;
#size-cells = <0>;
diff --git a/arch/arm/boot/dts/stm32f746.dtsi b/arch/arm/boot/dts/stm32f746.dtsi
index 5633860..a9077e6 100644
--- a/arch/arm/boot/dts/stm32f746.dtsi
+++ b/arch/arm/boot/dts/stm32f746.dtsi
@@ -82,22 +82,6 @@
status = "disabled";
};
 
-   timer3: timer@4400 {
-   compatible = "st,stm32-timer";
-   reg = <0x4400 0x400>;
-   interrupts = <29>;
-   clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM3)>;
-   status = "disabled";
-   };
-
-   timer4: timer@4800 {
-   compatible = "st,stm32-timer";
-   reg = <0x4800 0x400>;
-   interrupts = <30>;
-   clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM4)>;
-   status = "disabled";
-   };
-
timer5: timer@4c00 {
compatible = "st,stm32-timer";
reg = <0x4c00 0x400>;
@@ -105,22 +89,6 @@
clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM5)>;
};
 
-   timer6: timer@40001000 {
-   compatible = "st,stm32-timer";
-   reg = <0x40001000 0x400>;
-   interrupts = <54>;
-   clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM6)>;
-   status = "disabled";
-   };
-
-   timer7: timer@40001400 {
-   compatible = "st,stm32-timer";
-   reg = <0x40001400 0x400>;
-   interrupts = <55>;
-   clocks = <&rcc 0 STM32F7_APB1_CLOCK(TIM7)>;
-   status = "disabled";
-   };
-
rtc: rtc@40002800 {
compatible = "st,stm32-rtc";
reg = <0x40002800 0x400>;
-- 
2.7.4

Re: linux-next: Tree for Nov 7

[Michael Ellerman]

Michal Hocko  writes:

> On Mon 13-11-17 22:34:50, Michael Ellerman wrote:
>> Hi Michal,
>> 
>> Michal Hocko  writes:
>> > On Mon 13-11-17 10:20:06, Michal Hocko wrote:
>> >> [Cc arm and ppc maintainers]
>> >
>> > Hmm, it turned out to be a problem on other architectures as well.
>> > CCing more maintainers. For your reference, we are talking about
>> > http://lkml.kernel.org/r/20171023082608.6167-1-mho...@kernel.org
>> > which has broken architectures which do apply aligning on the mmap
>> > address hint without MAP_FIXED applied. See below my proposed way
>> > around this issue because I belive that the above patch is quite
>> > valuable on its own to be dropped for all archs.
>> 
>> I don't really like your solution sorry :)  The fact that you've had to
>> patch seven arches seems like a red flag.
>> 
>> I think this is a generic problem with MAP_FIXED, which I've heard
>> userspace folks complain about in the past.
>
> The thing is that we canno  change MAP_FIXED behavior as it is carved in
> stone

Yes obviously. I didn't mean to imply we would change MAP_FIXED, rather
we would add a new flag with the new semantics.

>> Currently MAP_FIXED does two things:
>>   1. makes addr not a hint but the required address
>>   2. blasts any existing mapping
>> 
>> You want 1) but not 2).
>
> + fail if there is a clashing range

Yep. I thought that was implied :)

>> So the right solution IMHO would be to add a new mmap flag to request
>> that behaviour, ie. a fixed address but iff there is nothing already
>> mapped there.
>> 
>> I don't know the mm code well enough to know if that's hard for some
>> reason, but it *seems* like it should be doable.
>
> Yes, I have mentioned that in the previous email but the amount of code
> would be even larger. Basically every arch which reimplements
> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> do vma lookup.

I'd have to look, but my memory of the arch code is that it doesn't deal
with the vma so it wouldn't need any change.

> So this was the most simple solution I could come up
> with. If there was a general interest for MAP_FIXED_SAFE then we can
> introduce it later of course. I would just like the hardening merged
> sooner rather than later.

Sure. But in the scheme of things one more kernel release is not that
big a deal to get it right. Given that the simple approach of dropping
MAP_FIXED turns out to not be simple at all.

cheers

[PATCH v8 5/6] clocksource: stm32: add clocksource support

[Benjamin Gaignard]

The stm32 timer hardware is currently only used as a clock event device,
but it can be utilized as a clocksource as well.

Implement this by enabling the free running counter in the hardware block
and converting the clock event part from a count down event timer to a
comparator based timer.

Signed-off-by: Benjamin Gaignard 
---
 drivers/clocksource/timer-stm32.c | 116 +-
 1 file changed, 88 insertions(+), 28 deletions(-)

diff --git a/drivers/clocksource/timer-stm32.c 
b/drivers/clocksource/timer-stm32.c
index 8173bcf..c0a62cd 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -16,6 +16,8 @@
 #include 
 #include 
 #include 
+#include 
+#include 
 
 #include "timer-of.h"
 
@@ -23,16 +25,16 @@
 #define TIM_DIER   0x0c
 #define TIM_SR 0x10
 #define TIM_EGR0x14
+#define TIM_CNT0x24
 #define TIM_PSC0x28
 #define TIM_ARR0x2c
+#define TIM_CCR1   0x34
 
 #define TIM_CR1_CENBIT(0)
-#define TIM_CR1_OPMBIT(3)
+#define TIM_CR1_UDIS   BIT(1)
 #define TIM_CR1_ARPE   BIT(7)
 
-#define TIM_DIER_UIE   BIT(0)
-
-#define TIM_SR_UIF BIT(0)
+#define TIM_DIER_CC1IE BIT(1)
 
 #define TIM_EGR_UG BIT(0)
 
@@ -42,28 +44,44 @@ static int stm32_clock_event_shutdown(struct 
clock_event_device *evt)
 {
struct timer_of *to = to_timer_of(evt);
 
-   writel_relaxed(0, timer_of_base(to) + TIM_CR1);
+   writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+
return 0;
 }
 
-static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
+static int stm32_clock_event_set_next_event(unsigned long evt,
+   struct clock_event_device *clkevt)
 {
-   struct timer_of *to = to_timer_of(evt);
+   struct timer_of *to = to_timer_of(clkevt);
+   unsigned long now, next;
 
-   writel_relaxed(timer_of_period(to), timer_of_base(to) + TIM_ARR);
-   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_CEN, timer_of_base(to) + TIM_CR1);
+   next = readl_relaxed(timer_of_base(to) + TIM_CNT) + evt;
+   writel_relaxed(next, timer_of_base(to) + TIM_CCR1);
+   now = readl_relaxed(timer_of_base(to) + TIM_CNT);
+
+   if ((next - now) > evt)
+   return -ETIME;
+
+   writel_relaxed(TIM_DIER_CC1IE, timer_of_base(to) + TIM_DIER);
 
return 0;
 }
 
-static int stm32_clock_event_set_next_event(unsigned long evt,
-   struct clock_event_device *clkevt)
+static int stm32_clock_event_set_periodic(struct clock_event_device *evt)
 {
-   struct timer_of *to = to_timer_of(clkevt);
+   struct timer_of *to = to_timer_of(evt);
 
-   writel_relaxed(evt, timer_of_base(to) + TIM_ARR);
-   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_OPM | TIM_CR1_CEN,
-  timer_of_base(to) + TIM_CR1);
+   return stm32_clock_event_set_next_event(timer_of_period(to), evt);
+}
+
+static int stm32_clock_event_set_oneshot(struct clock_event_device *evt)
+{
+   struct timer_of *to = to_timer_of(evt);
+   unsigned long val;
+
+   val = readl_relaxed(timer_of_base(to) + TIM_CNT);
+   writel_relaxed(val, timer_of_base(to) + TIM_CCR1);
+   writel_relaxed(TIM_DIER_CC1IE, timer_of_base(to) + TIM_DIER);
 
return 0;
 }
@@ -75,12 +93,57 @@ static irqreturn_t stm32_clock_event_handler(int irq, void 
*dev_id)
 
writel_relaxed(0, timer_of_base(to) + TIM_SR);
 
+   if (clockevent_state_periodic(evt))
+   stm32_clock_event_set_periodic(evt);
+   else
+   stm32_clock_event_shutdown(evt);
+
evt->event_handler(evt);
 
return IRQ_HANDLED;
 }
 
-static int __init stm32_clockevent_init(struct device_node *node)
+static void __init stm32_clockevent_init(struct timer_of *to)
+{
+   writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+   writel_relaxed(0, timer_of_base(to) + TIM_SR);
+
+   clockevents_config_and_register(&to->clkevt,
+   timer_of_rate(to), MIN_DELTA, ~0U);
+}
+
+static void __iomem *stm32_timer_cnt __read_mostly;
+static u64 notrace stm32_read_sched_clock(void)
+{
+   return readl_relaxed(stm32_timer_cnt);
+}
+
+static int __init stm32_clocksource_init(struct timer_of *to)
+{
+   writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
+   writel_relaxed(0, timer_of_base(to) + TIM_PSC);
+   writel_relaxed(0, timer_of_base(to) + TIM_SR);
+   writel_relaxed(0, timer_of_base(to) + TIM_DIER);
+   writel_relaxed(0, timer_of_base(to) + TIM_SR);
+   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_UDIS,
+  timer_of_base(to) + TIM_CR1);
+
+   /* Make sure that registers are updated */
+   writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
+
+   /* Enable controller */
+   writel_relaxed(TIM_CR1_ARPE | TIM_CR1_UDIS | TIM_CR1_CEN,
+  timer_of_base(to) + TIM_CR1);
+
+   st

[PATCH v8 4/6] clocksource: stm32: only use 32 bits timers

[Benjamin Gaignard]

The clock driving counters is at 90MHz so the maximum period
for 16 bis counters is around 750 ms which is a short period
for a clocksource. For 32 bits counters this period is close
47 secondes which is more acceptable.

This patch remove 16 bits counters support and makes sure that
they won't be probed anymore.

Signed-off-by: Benjamin Gaignard 
---
 drivers/clocksource/timer-stm32.c | 26 --
 1 file changed, 12 insertions(+), 14 deletions(-)

diff --git a/drivers/clocksource/timer-stm32.c 
b/drivers/clocksource/timer-stm32.c
index ae41a19..8173bcf 100644
--- a/drivers/clocksource/timer-stm32.c
+++ b/drivers/clocksource/timer-stm32.c
@@ -83,9 +83,9 @@ static irqreturn_t stm32_clock_event_handler(int irq, void 
*dev_id)
 static int __init stm32_clockevent_init(struct device_node *node)
 {
struct reset_control *rstc;
-   unsigned long max_delta;
-   int ret, bits, prescaler = 1;
+   unsigned long max_arr;
struct timer_of *to;
+   int ret;
 
to = kzalloc(sizeof(*to), GFP_KERNEL);
if (!to)
@@ -115,29 +115,27 @@ static int __init stm32_clockevent_init(struct 
device_node *node)
 
/* Detect whether the timer is 16 or 32 bits */
writel_relaxed(~0U, timer_of_base(to) + TIM_ARR);
-   max_delta = readl_relaxed(timer_of_base(to) + TIM_ARR);
-   if (max_delta == ~0U) {
-   prescaler = 1;
-   bits = 32;
-   } else {
-   prescaler = 1024;
-   bits = 16;
+   max_arr = readl_relaxed(timer_of_base(to) + TIM_ARR);
+   if (max_arr != ~0U) {
+   pr_err("32 bits timer is needed\n");
+   ret = -EINVAL;
+   goto deinit;
}
+
writel_relaxed(0, timer_of_base(to) + TIM_ARR);
 
-   writel_relaxed(prescaler - 1, timer_of_base(to) + TIM_PSC);
+   writel_relaxed(0, timer_of_base(to) + TIM_PSC);
writel_relaxed(TIM_EGR_UG, timer_of_base(to) + TIM_EGR);
writel_relaxed(TIM_DIER_UIE, timer_of_base(to) + TIM_DIER);
writel_relaxed(0, timer_of_base(to) + TIM_SR);
 
clockevents_config_and_register(&to->clkevt,
-   timer_of_period(to), MIN_DELTA, 
max_delta);
-
-   pr_info("%pOF: STM32 clockevent driver initialized (%d bits)\n",
-   node, bits);
+   timer_of_period(to), MIN_DELTA, ~0U);
 
return 0;
 
+deinit:
+   timer_of_exit(to);
 err:
kfree(to);
return ret;
-- 
2.7.4

Re: [PATCH] lib: Avoid redundant sizeof checking in __bitmap_weight() calculation.

[Rakib Mullick]

On Tue, Nov 14, 2017 at 1:23 PM, Rasmus Villemoes
 wrote:
>
> hint: sizeof() very rarely evaluates to zero... So this is the same as
> "is32 = 1". So the patch as-is is broken (and may explain the 1-byte
> delta in vmlinux). But even if this condition is fixed, the patch
> doesn't change anything, since the sizeof() evaluation is done at
> compile-time, regardless of whether it happens inside the inlined
> hweight_long or outside. So it is certainly not worth it to duplicate
> the loop.
>
Right, no need to duplicate the loop. Checking the objdump output, it
didn't changed anything at all. Fixed condition nullifies the vmlinux
size advantage also. Drop it.

Thanks,
Rakib.

Re: linux-next: build warning after merge of the bluetooth tree

[Hans de Goede]

Hi,

On 14-11-17 01:56, Stephen Rothwell wrote:

Hi all,

After merging the bluetooth tree, today's linux-next build (arm
multi_v7_defconfig) produced this warning:

drivers/bluetooth/Kconfig:35:warning: multi-line strings not supported

Introduced by commit

   86be3c232877 ("Bluetooth: btusb: Add a Kconfig option to enable USB autosuspend 
by default")

There is a missing close double quote ...


Ugh, sorry about that, a patch (on top of the original) fixing this
is coming up right away.

Regards,

Hans

Re: linux-next: error fetching the vfs-jk tree

[Jan Kara]

Hi,

On Tue 14-11-17 09:40:10, Stephen Rothwell wrote:
> Fetching the vfs-jk tree
> (git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git#vfs)
> produces this error:
> 
> fatal: Couldn't find remote ref refs/heads/vfs
> 
> Do you want me to still fetch/merge that tree?

Sorry, I forgot you were still fetching it. No, there's no need to fetch
that branch anymore (it was a branch for one time work and I've deleted it
now since it was untouched for an year or so). Thanks!

Honza
-- 
Jan Kara 
SUSE Labs, CR

Re: linux-next: Tree for Nov 7

[Michael Ellerman]

Michal Hocko  writes:

> On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> [...]
>> Yes, I have mentioned that in the previous email but the amount of code
>> would be even larger. Basically every arch which reimplements
>> arch_get_unmapped_area would have to special case new MAP_FIXED flag to
>> do vma lookup.
>
> It turned out that this might be much more easier than I thought after
> all. It seems we can really handle that in the common code.

Ah nice. I should have read this before replying to your previous mail.

> This would mean that we are exposing a new functionality to the userspace 
> though.
> Myabe this would be useful on its own though.

Yes I think it would. At least jemalloc seems like it could use it:

  
https://github.com/jemalloc/jemalloc/blob/9f455e2786685b443201c33119765c8093461174/src/pages.c#L65

And I have memories of some JIT code I read once which did a loop of
mmap()s or something to try and get allocations below 4GB or some other
limit - but I can't remember now what it was.

> Just a quick draft (not
> even compile tested) whether this makes sense in general. I would be
> worried about unexpected behavior when somebody set other bit without a
> good reason and we might fail with ENOMEM for such a call now.
>
> Elf loader would then use MAP_FIXED_SAFE rather than MAP_FIXED.
> ---
> diff --git a/arch/alpha/include/uapi/asm/mman.h 
> b/arch/alpha/include/uapi/asm/mman.h
> index 3b26cc62dadb..d021c21f9b01 100644
> --- a/arch/alpha/include/uapi/asm/mman.h
> +++ b/arch/alpha/include/uapi/asm/mman.h
> @@ -31,6 +31,9 @@
>  #define MAP_STACK0x8 /* give out an address that is best 
> suited for process/thread stacks */
>  #define MAP_HUGETLB  0x10/* create a huge page mapping */
>  
> +#define MAP_KEEP_MAPPING 0x200
> +#define MAP_FIXED_SAFE   MAP_FIXED|MAP_KEEP_MAPPING /* enforce MAP_FIXED 
> without clobbering an existing mapping */


So bike-shedding a bit, but I think "SAFE" is too vague a name.

Perhaps MAP_NO_CLOBBER - which has the single semantic of "do not
clobber any existing mappings".

It would be a flag on its own, so you could pass it with or without
MAP_FIXED, but it would only change the behaviour when MAP_FIXED is
specified also.

cheers

Re: linux-next: Tree for Nov 7

[Michal Hocko]

On Tue 14-11-17 19:54:59, Michael Ellerman wrote:
> Michal Hocko  writes:
[...]
> > So this was the most simple solution I could come up
> > with. If there was a general interest for MAP_FIXED_SAFE then we can
> > introduce it later of course. I would just like the hardening merged
> > sooner rather than later.
> 
> Sure. But in the scheme of things one more kernel release is not that
> big a deal to get it right. Given that the simple approach of dropping
> MAP_FIXED turns out to not be simple at all.

Well, my idea was to push this hardening to older kernels because those
were more vulnerable for the PIE base vs. stack placement and stack
controllable size from userspace etc... Anyway, as per [1] it seems that
the MAP_FIXED_SAFE doesn't look terrible from the backporting POV.

If there is a general consensus that this is the preferred way to go, I
will post the patch as an RFC to linux-api

[1] http://lkml.kernel.org/r/20171113160637.jhekbdyfpccme...@dhcp22.suse.cz
-- 
Michal Hocko
SUSE Labs

Re: [GIT PULL] RISC-V Port for Linux 4.15 v9

[Arnd Bergmann]

On Mon, Nov 13, 2017 at 10:56 PM, Palmer Dabbelt  wrote:
> The following changes since commit bebc6082da0a9f5d47a1ea2edc099bf671058bd4:
>
>   Linux 4.14 (2017-11-12 10:46:13 -0800)
>
> are available in the git repository at:
>
>   git://git.kernel.org/pub/scm/linux/kernel/git/palmer/linux.git 
> tags/riscv-for-linus-4.15-arch-v9
>
> for you to fetch changes up to 512d88db5ef3de56f392f761657c2ab2cadc0498:
>
>   Merge tag 'v4.14' into for-linus (2017-11-13 13:17:51 -0800)
>
> 
> RISC-V Port for Linux 4.15 v9
>
> This tag contains the core RISC-V Linux port, which has been through
> nine rounds of review on various mailing lists.  The port is not
> complete: there's some cleanup patches moving through the review
> process, a whole bunch of drivers that need some work, and a lot of
> feature additions that will be needed.
>
> The patches contained in this tag have been through nine rounds of
> review on the various mailing lists.  I have some outstanding cleanup
> patches, but since there's been so much review on these patches I
> thought it would be best to submit them as-is and then submit explicit
> cleanup patches so everyone can review them.  This first patch set is
> big enough that it's a bit of a pain to constantly rewrite, and it's
> caused a few headaches with various contributors.
>
> The port is definately a work in progress.  While what's there builds
> and boots with 4.14, it's a bit hard to actually see anything happen
> because there are no device drivers yet.  I maintain a staging branch
> that contains all the device drivers and cleanup that actually works,
> but those patches won't all be ready for a while.  I'd like to get what
> we currently have into your tree so everyone can start working from a
> single base -- of particular importance is allowing the glibc
> upstreaming process to proceed so we can sort out any possibly lingering
> user-visible ABI problems we might have.

For the contents:

Reviewed-by: Arnd Bergmann 

As you say, there are a few FIXME's left, but nothing that can't
just be handled after the merge.

Two small things I noticed about the pull request:

- I see you pulled in the v4.14 tag, presumably to have a cleaner
  merge base. It's better not to do that kind of "back-merge", it
  will mess up the git history and it doesn't really help with anything
  important like bisection through the series.

- The last commit before the backmerge is from Sep 26. I would
  assume that you have done other work since then (I saw at
  least one patch). Shouldn't they be included here?

   Arnd

Re: Coccinelle: badzero.cocci failure

[Julia Lawall]

> coccicheck failed
> $ cat cocci-debug.txt
> /home/masahiro/bin/spatch -D report --no-show-diff --very-quiet
> --cocci-file scripts/coccinelle/null/badzero.cocci --dir . -I
> ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I
> ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I
> ./include/uapi -I ./include/generated/uapi --include
> ./include/linux/kconfig.h --jobs 8 --chunksize 1
> Fatal error: exception
> Yes_prepare_ocamlcocci.LinkFailure("/tmp/ocaml_cocci_18c9f9.cmxs")

Does your Coccinelle support OCaml?  I'm not sure what is the proper way to
check for this, but in my coccinelle/config.log file I have

FEATURE_OCAML='1'

spatch --version gives:

spatch version 1.0.6-00147-g19f9421 compiled with OCaml version 4.02.3
Flags passed to the configure script: [none]
Python scripting support: yes
Syntax of regular expresssions: Str

I'm not sure why it doesn't give feedback on whether OCaml scripting is
supported.  I will check on this.

julia

[PATCH v3] coccinelle: fix parallel build with CHECK=scripts/coccicheck

[Masahiro Yamada]

The command "make -j8 C=1 CHECK=scripts/coccicheck COCCI=..." produces
lots of "coccicheck failed" error messages.

Julia Lawall explained the coccinelle behavior as follows:
"The problem on the Coccinelle side is that it uses a subdirectory
with the name of the semantic patch to store standard output and
standard error for the different threads.  I didn't want to use a
name with the pid, so that one could easily find this information
while Coccinelle is running.  Normally the subdirectory is cleaned
up when Coccinelle completes, so there is only one of them at a time.
Maybe it is best to just add the pid.  There is the risk that these
subdirectories will accumulate if Coccinelle crashes in a way such
that they don't get cleaned up, but Coccinelle could print a warning
if it detects this case, rather than failing."

When scripts/coccicheck is used as CHECK tool and -j option is given
to Make, the whole of build process runs in parallel.  So, multiple
processes try to get access to the same subdirectory.

I notice spatch creates the subdirectory only when it runs in parallel
(i.e. --jobs  is given and  is greater than 1).

Setting NPROC=1 is a sensible solution; spatch does not create the
subdirectory.  Besides, ONLINE=1 mode takes a single file input for
each spatch invocation, so there is no reason to parallelize it in
the first place.

Signed-off-by: Masahiro Yamada 
---

Changes in v3:
  - Set NPROC=1 because this is a more sensible solution
given that there is no reason to run coccinelle in parallel
for ONLINE=1 mode.
  - Move J= option handling to a proper place.
  - Add more detailed explanation

Changes in v2:
  - Grep '-j' instead of '--jobserver-auth'.
'--jobserver-*' is not a stable option flag.
Make 4.2 change '--jobserver-fds' into '--jobserver-auth'
  - Add -q option to grep

 scripts/coccicheck | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/scripts/coccicheck b/scripts/coccicheck
index 040a8b1..7da82a1 100755
--- a/scripts/coccicheck
+++ b/scripts/coccicheck
@@ -30,12 +30,6 @@ else
VERBOSE=0
 fi
 
-if [ -z "$J" ]; then
-   NPROC=$(getconf _NPROCESSORS_ONLN)
-else
-   NPROC="$J"
-fi
-
 FLAGS="--very-quiet"
 
 # You can use SPFLAGS to append extra arguments to coccicheck or override any
@@ -70,6 +64,13 @@ if [ "$C" = "1" -o "$C" = "2" ]; then
 # Take only the last argument, which is the C file to test
 shift $(( $# - 1 ))
 OPTIONS="$COCCIINCLUDE $1"
+
+# If -j option is given to Make, scripts/coccicheck runs in parallel.
+# If coccinelle also runs in parallel, it fails because multiple processes
+# try to get access to the same subdirectory that stores stdout/stderr.
+# No need to parallelize coccinelle in this case - this mode takes only
+# one file input.
+NPROC=1
 else
 ONLINE=0
 if [ "$KBUILD_EXTMOD" = "" ] ; then
@@ -77,6 +78,12 @@ else
 else
 OPTIONS="--dir $KBUILD_EXTMOD $COCCIINCLUDE"
 fi
+
+if [ -z "$J" ]; then
+NPROC=$(getconf _NPROCESSORS_ONLN)
+else
+NPROC="$J"
+fi
 fi
 
 if [ "$KBUILD_EXTMOD" != "" ] ; then
-- 
2.7.4

Re: [PATCH v2] coccinelle: fix parallel build with CHECK=scripts/coccicheck

[Masahiro Yamada]

Hi Julia,


2017-11-14 15:44 GMT+09:00 Julia Lawall :
>
>
> On Tue, 14 Nov 2017, Masahiro Yamada wrote:
>
>> Hi Julia,
>>
>> 2017-11-14 1:45 GMT+09:00 Julia Lawall :
>> >
>> >
>> > On Tue, 14 Nov 2017, Masahiro Yamada wrote:
>> >
>> >> Hi Julia,
>> >>
>> >>
>> >> 2017-11-14 0:30 GMT+09:00 Julia Lawall :
>> >> >
>> >> >
>> >> > On Thu, 9 Nov 2017, Masahiro Yamada wrote:
>> >> >
>> >> >> The command "make -j8 C=1 CHECK=scripts/coccicheck" produces lots of
>> >> >> "coccicheck failed" error messages.
>> >> >>
>> >> >> I do not know the coccinelle internals, but I guess --jobs does not
>> >> >> work well if spatch is invoked from Make running in parallel.
>> >> >> Disable --jobs in this case.
>> >> >
>> >> > Why is this change under:
>> >> >
>> >> > if [ "$C" = "1" -o "$C" = "2" ];
>> >> >
>> >> > The coccicheck failed messages come also if one runs Coccinelle on the
>> >> > entire kernel.
>> >>
>> >> As far as I tested, "coccicheck failed" error only happens
>> >> when ONLINE=1.
>> >>
>> >>
>> >> make -j8 C=1 CHECK=scripts/coccicheck  
>> >> COCCI=scripts/coccinelle/misc/bugon.cocci
>> >>
>> >> emits lots of errors.
>> >>
>> >>
>> >> make -j8 coccicheck  COCCI=scripts/coccinelle/misc/bugon.cocci
>> >>
>> >> is fine.
>> >>
>> >>
>> >> Have you tested it?
>> >> Do you mean you got a different result from mine?
>> >
>> > I agree with your results, with respect to the number of errors.
>> >
>> > julia
>> >
>>
>> So, what shall we do?
>>
>> If you do not like to fix it (or you can fix coccinelle itself),
>> I can take back this patch.
>
> I'm OK with your fix.  I will check and ack it today.
>
>> I am not a coccinelle developer, so
>> setting USE_JOBS="no" is the best I can do.
>
> The problem on the Coccinelle side is that it uses a subdirectory with the
> name of the semantic patch to store standard output and standard error for
> the different threads.  I didn't want to use a name with the pid, so that
> one could easily find this information while Coccinelle is running.
> Normally the subdirectory is cleaned up when Coccinelle completes, so
> there is only one of them at a time.  Maybe it is best to just add the
> pid.  There is the risk that these subdirectories will accumulate if
> Coccinelle crashes in a way such that they don't get cleaned up, but
> Coccinelle could print a warning if it detects this case, rather than
> failing.
>
> Still I think it is useful to do something on the make coccicheck side,
> because there is no need for the double layer of parallelism.
>


Thanks a lot for detailed explanation!

I brushed up my patch.

Could you check v3, please?


-- 
Best Regards
Masahiro Yamada

[PATCH] kernel: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "".

Signed-off-by: Martin Kepplinger 
---

This is an attempt to sneak this in in one go for the kernel directory.
I think it's important to take the license statement serious and to not
confuse users.

If this should go in as seperate patches, each to their lists, please
say so.

thanks

 martin



 kernel/audit.c  | 3 +--
 kernel/audit.h  | 3 +--
 kernel/audit_watch.c| 3 +--
 kernel/auditfilter.c| 3 +--
 kernel/auditsc.c| 3 +--
 kernel/events/hw_breakpoint.c   | 3 +--
 kernel/events/uprobes.c | 3 +--
 kernel/extable.c| 3 +--
 kernel/futex.c  | 3 +--
 kernel/kprobes.c| 3 +--
 kernel/module.c | 3 +--
 kernel/params.c | 3 +--
 kernel/time/timeconv.c  | 3 +--
 kernel/trace/trace_events_filter.c  | 3 +--
 kernel/trace/trace_events_trigger.c | 3 +--
 kernel/trace/trace_kprobe.c | 3 +--
 kernel/trace/trace_probe.c  | 3 +--
 kernel/trace/trace_probe.h  | 3 +--
 kernel/trace/trace_uprobe.c | 3 +--
 kernel/tracepoint.c | 3 +--
 20 files changed, 20 insertions(+), 40 deletions(-)

diff --git a/kernel/audit.c b/kernel/audit.c
index 227db99b0f19..1aa743f21c0d 100644
--- a/kernel/audit.c
+++ b/kernel/audit.c
@@ -16,8 +16,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see .
  *
  * Written by Rickard E. (Rik) Faith 
  *
diff --git a/kernel/audit.h b/kernel/audit.h
index af5bc59487ed..27f01e30a0db 100644
--- a/kernel/audit.h
+++ b/kernel/audit.h
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see .
  */
 
 #include 
diff --git a/kernel/audit_watch.c b/kernel/audit_watch.c
index 9eb8b3511636..93cb46c5dbe1 100644
--- a/kernel/audit_watch.c
+++ b/kernel/audit_watch.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see .
  */
 
 #include 
diff --git a/kernel/auditfilter.c b/kernel/auditfilter.c
index 4a1758adb222..5e61702b06cd 100644
--- a/kernel/auditfilter.c
+++ b/kernel/auditfilter.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see .
  */
 
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
diff --git a/kernel/auditsc.c b/kernel/auditsc.c
index e80459f7e132..7ef2078334b6 100644
--- a/kernel/auditsc.c
+++ b/kernel/auditsc.c
@@ -17,8 +17,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program. If not, see .
  *
  * Written by Rickard E. (Rik) Faith 
  *
diff --git a/kernel/events/hw_breakpoint.c b/kernel/events/hw_breakpoint.c
index 3f8cb1e14588..4aaf161870a1 100644
--- a/kernel/events/hw_breakpoint.c
+++ b/kernel/events/hw_breakpoint.c
@@ -10,8 +10,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program. If not, see .
  *
  * Copyright (C) 2007 Alan Stern
  * Copyright (C) IBM Corporation, 2009
diff --git a/kernel/events/uprobes.c b/kernel/events/uprobes.c
index 267f6ef91d97..5d9835116f08 100644
--- a/kernel/events/uprobes.c
+++ b/kernel/events/uprobes.c
@@ -12,8 +12,7 @@
  * GNU 

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

[Ulf Hansson]

On 13 November 2017 at 22:50, Rafael J. Wysocki  wrote:
> On Monday, November 13, 2017 2:26:28 PM CET Ulf Hansson wrote:
>> On 12 November 2017 at 01:27, Rafael J. Wysocki  wrote:
>> > From: Rafael J. Wysocki 
>> >
>> > The check for "active" children in __pm_runtime_set_status(), when
>> > trying to set the parent device status to "suspended", doesn't
>> > really make sense, because in fact it is not invalid to set the
>> > status of a device with runtime PM disabled to "suspended" in any
>> > case.  It is invalid to enable runtime PM for a device with its
>> > status set to "suspended" while its child_count reference counter
>> > is nonzero, but the check in __pm_runtime_set_status() doesn't
>> > really cover that situation.
>>
>> The reason to why I changed this in commit a8636c89648a ("PM /
>> Runtime: Don't allow to suspend a device with an active child") was
>> because to get a consistent behavior.
>
> Well, it causes the function to return an error in a non-error situation,
> which IMnsHO is a bug.
>
>> Because, setting the device's status to active (RPM_ACTIVE) via
>> __pm_runtime_set_status(), requires its parent to also be active (in
>> case the parent has runtime PM enabled).
>
> No!!!
>
> The check is in there, because the parent's usage_count is affected by that
> code and incrementing it in case the parent has runtime PM enabled and is
> RPM_SUSPENDED leads to an inconsistent runtime PM state of the parent.  IOW,
> it would confuse the framework.

Right, I do understand the reasons *why* it is like this.

>
> There's no such issue if the runtime PM status of a child is set to 
> RPM_SUSPENDED.
>
> It is all consistent without the check I'm removing and is made inconsistent
> by that very check.
>
>> I would prefer to try maintain this consistency, but I also I realize
>> that commit a8636c89648a, should also have been checking if the parent
>> has runtime PM enabled (again for consistency), which it doesn't.
>>
>> What about fixing that instead?
>
> Runtime PM is *disabled* for the parent at this point, guaranteed, so there's
> nothing to check, I'm afraid ...

Where and how is that guarantee made?

[...]

Kind regards
Uffe

Re: linux-next: Tree for Nov 7

[Michael Ellerman]

Michal Hocko  writes:

> [Sorry for spamming, this one is the last attempt hopefully]
>
> On Mon 13-11-17 16:49:39, Michal Hocko wrote:
>> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
>> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
>> > [...]
>> > > Yes, I have mentioned that in the previous email but the amount of code
>> > > would be even larger. Basically every arch which reimplements
>> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
>> > > do vma lookup.
>> > 
>> > It turned out that this might be much more easier than I thought after
>> > all. It seems we can really handle that in the common code. This would
>> > mean that we are exposing a new functionality to the userspace though.
>> > Myabe this would be useful on its own though. Just a quick draft (not
>> > even compile tested) whether this makes sense in general. I would be
>> > worried about unexpected behavior when somebody set other bit without a
>> > good reason and we might fail with ENOMEM for such a call now.
>> 
>> Hmm, the bigger problem would be the backward compatibility actually. We
>> would get silent corruptions which is exactly what the flag is trying
>> fix. mmap flags handling really sucks. So I guess we would have to make
>> the flag internal only :/
>
> OK, so this one should take care of the backward compatibility while
> still not touching the arch code

I'm not sure I understand your worries about backward compatibility?

If we add a new mmap flag which is currently unused then what is the
problem? Are you worried about user code that accidentally passes that
flag already?

> diff --git a/include/uapi/asm-generic/mman-common.h 
> b/include/uapi/asm-generic/mman-common.h
> index 203268f9231e..03c518777f83 100644
> --- a/include/uapi/asm-generic/mman-common.h
> +++ b/include/uapi/asm-generic/mman-common.h
> @@ -25,6 +25,8 @@
>  # define MAP_UNINITIALIZED 0x0   /* Don't support this flag */
>  #endif
>  
> +#define MAP_FIXED_SAFE 0x200 /* MAP_FIXED which doesn't unmap 
> underlying mapping */
> +

As I said in my other mail I think this should be a modifier to
MAP_FIXED. That way all the existing code that checks for MAP_FIXED (in
the kernel) works exactly as it currently does - like the check Khalid
pointed out.

And I think MAP_NO_CLOBBER would be a better name.

cheers

Re: [PATCH] bluetooth: btusb: Add device ID for RTL8822BE

[kbuild test robot]

Hi Larry,

I love your patch! Perhaps something to improve:

[auto build test WARNING on bluetooth-next/master]
[also build test WARNING on v4.14 next-20171114]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Larry-Finger/bluetooth-btusb-Add-device-ID-for-RTL8822BE/20171114-152910
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
master
config: xtensa-allyesconfig (attached as .config)
compiler: xtensa-linux-gcc (GCC) 4.9.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=xtensa 

All warnings (new ones prefixed by >>):

>> drivers/bluetooth/btusb.c:373:2: warning: large integer implicitly truncated 
>> to unsigned type [-Woverflow]
 { USB_DEVICE(0x0b05, 0x1185c), .driver_info = BTUSB_REALTEK },
 ^

vim +373 drivers/bluetooth/btusb.c

   181  
   182  static const struct usb_device_id blacklist_table[] = {
   183  /* CSR BlueCore devices */
   184  { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_CSR },
   185  
   186  /* Broadcom BCM2033 without firmware */
   187  { USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE },
   188  
   189  /* Broadcom BCM2045 devices */
   190  { USB_DEVICE(0x0a5c, 0x2045), .driver_info = BTUSB_BCM2045 },
   191  
   192  /* Atheros 3011 with sflash firmware */
   193  { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
   194  { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
   195  { USB_DEVICE(0x04f2, 0xaff1), .driver_info = BTUSB_IGNORE },
   196  { USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
   197  { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE },
   198  { USB_DEVICE(0x0cf3, 0xe019), .driver_info = BTUSB_IGNORE },
   199  { USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
   200  
   201  /* Atheros AR9285 Malbec with sflash firmware */
   202  { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
   203  
   204  /* Atheros 3012 with sflash firmware */
   205  { USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
   206  { USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
   207  { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
   208  { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
   209  { USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
   210  { USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
   211  { USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
   212  { USB_DEVICE(0x0489, 0xe095), .driver_info = BTUSB_ATH3012 },
   213  { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
   214  { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
   215  { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
   216  { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
   217  { USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
   218  { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
   219  { USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
   220  { USB_DEVICE(0x04ca, 0x300d), .driver_info = BTUSB_ATH3012 },
   221  { USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
   222  { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
   223  { USB_DEVICE(0x04ca, 0x3014), .driver_info = BTUSB_ATH3012 },
   224  { USB_DEVICE(0x04ca, 0x3018), .driver_info = BTUSB_ATH3012 },
   225  { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
   226  { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
   227  { USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
   228  { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
   229  { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
   230  { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
   231  { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
   232  { USB_DEVICE(0x0cf3, 0x3008), .driver_info = BTUSB_ATH3012 },
   233  { USB_DEVICE(0x0cf3, 0x311d), .driver_info = BTUSB_ATH3012 },
   234  { USB_DEVICE(0x0cf3, 0x311e), .driver_info = BTUSB_ATH3012 },
   235  { USB_DEVICE(0x0cf3, 0x311f), .driver_info = BTUSB_ATH3012 },
   236  { USB_DEVICE(0x0cf3, 0x3121), .driver_info = BTUSB_ATH3012 },
   237  { USB_DEVICE(0x0cf3, 0x817a), .driver_info = BTUSB_ATH3012 },
   238  { USB_DEVICE(0x0cf3, 0x8

Re: [PATCH] quota: be aware of error from dquot_initialize

[Jan Kara]

On Tue 14-11-17 11:43:49, Chao Yu wrote:
> On 2017/11/13 17:18, Jan Kara wrote:
> > On Mon 13-11-17 11:31:48, Chao Yu wrote:
> >> Commit 6184fc0b8dd7 ("quota: Propagate error from ->acquire_dquot()")
> >> missed to handle error from dquot_initialize in dquot_file_open, fix it.
> >>
> >> Signed-off-by: Chao Yu 
> > 
> > Good spotting. I've added the patch to my tree.
> 
> Thanks for queuing the patch. :)
> 
> BTW, I notice in add_dquot_ref we also didn't handle error of
> __dquot_initialize, should we handle it too?

It is questionable what we should do with an error in add_dquot_ref(). User
asked us to turn quotas on - that succeeded just fine but then we walked
over already active inodes in add_dquot_ref(), wanted to initialize
accounting information, and that failed for some inode. We can just leave
quota on, the accounting will work for other inodes - that's what we do
now. We could also propagate the failure up and refuse to turn quotas off.
I guess that's a somewhat better approach so if you want to implement that,
go ahead.

Honza
-- 
Jan Kara 
SUSE Labs, CR

[PATCH] crypto: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "".

Signed-off-by: Martin Kepplinger 
---
 crypto/ablk_helper.c  | 4 +---
 crypto/camellia_generic.c | 3 +--
 crypto/cast5_generic.c| 3 +--
 crypto/cast6_generic.c| 3 +--
 crypto/simd.c | 4 +---
 crypto/twofish_common.c   | 5 ++---
 crypto/twofish_generic.c  | 5 ++---
 crypto/xcbc.c | 3 +--
 8 files changed, 10 insertions(+), 20 deletions(-)

diff --git a/crypto/ablk_helper.c b/crypto/ablk_helper.c
index 1441f07d0a19..6e5d2f149b89 100644
--- a/crypto/ablk_helper.c
+++ b/crypto/ablk_helper.c
@@ -18,9 +18,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see .
  *
  */
 
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index a02286bf319e..32ddd4836ff5 100644
--- a/crypto/camellia_generic.c
+++ b/crypto/camellia_generic.c
@@ -13,8 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.
+ * along with this program.  If not, see .
  */
 
 /*
diff --git a/crypto/cast5_generic.c b/crypto/cast5_generic.c
index df5c72629383..66169c178314 100644
--- a/crypto/cast5_generic.c
+++ b/crypto/cast5_generic.c
@@ -16,8 +16,7 @@
 * any later version.
 *
 * You should have received a copy of the GNU General Public License
-* along with this program; if not, write to the Free Software
-* Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+* along with this program.  If not, see .
 */
 
 
diff --git a/crypto/cast6_generic.c b/crypto/cast6_generic.c
index 058c8d755d03..c8e5ec69790e 100644
--- a/crypto/cast6_generic.c
+++ b/crypto/cast6_generic.c
@@ -13,8 +13,7 @@
  * any later version.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see .
  */
 
 
diff --git a/crypto/simd.c b/crypto/simd.c
index 88203370a62f..208226d7f908 100644
--- a/crypto/simd.c
+++ b/crypto/simd.c
@@ -19,9 +19,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see .
  *
  */
 
diff --git a/crypto/twofish_common.c b/crypto/twofish_common.c
index 5f62c4f9f6e0..f3a0dd25f871 100644
--- a/crypto/twofish_common.c
+++ b/crypto/twofish_common.c
@@ -24,9 +24,8 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see .
+ *
  *
  * This code is a "clean room" implementation, written from the paper
  * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey,
diff --git a/crypto/twofish_generic.c b/crypto/twofish_generic.c
index ebf7a3efb572..07e62433fbfb 100644
--- a/crypto/twofish_generic.c
+++ b/crypto/twofish_generic.c
@@ -23,9 +23,8 @@
  * GNU General Public License for more details.
  * 
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- * USA
+ * along with this program.  If not, see .
+ *
  *
  * This code is a "clean room" implementation, written from the paper
  * _Twofish: A 128-Bit Block Cipher_ by Bruce Schneier, John Kelsey,
diff --git a/crypto/xcbc.c b/crypto/xcbc.c
index df90b332554c..25c75af50d3f 100644
--- a/crypto/xcbc.c
+++ b/crypto/xcbc.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  US

[PATCH v4 1/3] kernel/modules: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

Livepatch re-uses module loader function apply_relocate_add() to write
relocations, instead of managing them by arch-dependent
klp_write_module_reloc() function.

apply_relocate_add() doesn't understand livepatch symbols (marked with
SHN_LIVEPATCH symbol section index) and assumes them to be local symbols
by default for R_PPC64_REL24 relocation type. It fails with an error,
when trying to calculate offset with local_entry_offset():

 module_64: kpatch_meminfo: REL24 -1152921504897399800 out of range!

Whereas livepatch symbols are essentially SHN_UNDEF, should be
called via stub used for global calls. This issue can be fixed by
teaching apply_relocate_add() to handle both SHN_UNDEF/SHN_LIVEPATCH
symbols via the same stub. This patch extends SHN_UNDEF code to handle
livepatch symbols too.

Signed-off-by: Kamalesh Babulal 
CC: Balbir Singh 
Cc: Naveen N. Rao 
Cc: Josh Poimboeuf 
Cc: Jessica Yu 
Cc: Ananth N Mavinakayanahalli 
Cc: Aravinda Prasad 
Cc: Torsten Duwe 
---
 arch/powerpc/kernel/module_64.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 0b0f896..39b01fd 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -613,7 +613,8 @@ int apply_relocate_add(Elf64_Shdr *sechdrs,
 
case R_PPC_REL24:
/* FIXME: Handle weak symbols here --RR */
-   if (sym->st_shndx == SHN_UNDEF) {
+   if (sym->st_shndx == SHN_UNDEF ||
+   sym->st_shndx == SHN_LIVEPATCH) {
/* External: go via stub */
value = stub_for_addr(sechdrs, value, me);
if (!value)
-- 
2.9.3

[PATCH] init: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "".

Signed-off-by: Martin Kepplinger 
---
 init/noinitramfs.c | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/init/noinitramfs.c b/init/noinitramfs.c
index 267739d85179..3ee9e3dbfbc4 100644
--- a/init/noinitramfs.c
+++ b/init/noinitramfs.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  */
 #include 
 #include 
-- 
2.11.0

Re: linux-next: Tree for Nov 7

[Michal Hocko]

On Tue 14-11-17 20:18:04, Michael Ellerman wrote:
> Michal Hocko  writes:
> 
> > [Sorry for spamming, this one is the last attempt hopefully]
> >
> > On Mon 13-11-17 16:49:39, Michal Hocko wrote:
> >> On Mon 13-11-17 16:16:41, Michal Hocko wrote:
> >> > On Mon 13-11-17 13:00:57, Michal Hocko wrote:
> >> > [...]
> >> > > Yes, I have mentioned that in the previous email but the amount of code
> >> > > would be even larger. Basically every arch which reimplements
> >> > > arch_get_unmapped_area would have to special case new MAP_FIXED flag to
> >> > > do vma lookup.
> >> > 
> >> > It turned out that this might be much more easier than I thought after
> >> > all. It seems we can really handle that in the common code. This would
> >> > mean that we are exposing a new functionality to the userspace though.
> >> > Myabe this would be useful on its own though. Just a quick draft (not
> >> > even compile tested) whether this makes sense in general. I would be
> >> > worried about unexpected behavior when somebody set other bit without a
> >> > good reason and we might fail with ENOMEM for such a call now.
> >> 
> >> Hmm, the bigger problem would be the backward compatibility actually. We
> >> would get silent corruptions which is exactly what the flag is trying
> >> fix. mmap flags handling really sucks. So I guess we would have to make
> >> the flag internal only :/
> >
> > OK, so this one should take care of the backward compatibility while
> > still not touching the arch code
> 
> I'm not sure I understand your worries about backward compatibility?

Just imagine you are running an application which uses the new flag
combination on an older kernel. You will get no warning, yet you have no
way to check that you have actually clobbered an existing mapping
because MAP_FIXED will be used the old way.

> If we add a new mmap flag which is currently unused then what is the
> problem? Are you worried about user code that accidentally passes that
> flag already?

If we add a completely new flag, like in this patch, then the code using
the flag will not clobber an existing mapping on older kernels which do
not recognize it (we will simply fall back to the default hint based
implementation). You might not get the mapping you asked for which sucks
but that is not fixable AFAICS. You can at least do

mapped_addr = mmap(addr, ... MAP_FIXED_SAFE...);
assert(mapped_addr == addr);

So I do not think we can go with the modifier unfortunatelly.
-- 
Michal Hocko
SUSE Labs

[PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

[Kamalesh Babulal]

From: Josh Poimboeuf 

When attempting to load a livepatch module, I got the following error:

  module_64: patch_module: Expect noop after relocate, got 3c82

The error was triggered by the following code in
unregister_netdevice_queue():

  14c:   00 00 00 48 b   14c 
 14c: R_PPC64_REL24  net_set_todo
  150:   00 00 82 3c addis   r4,r2,0

GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns.  The nop isn't needed after the
branch in that case.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Kamalesh Babulal 
---
 arch/powerpc/kernel/module_64.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 39b01fd..9e5391f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -489,6 +489,10 @@ static int restore_r2(u32 *instruction, struct module *me)
if (is_early_mcount_callsite(instruction - 1))
return 1;
 
+   /* Sibling calls don't return, so they don't need to restore r2 */
+   if (instruction[-1] == PPC_INST_BRANCH)
+   return 1;
+
if (*instruction != PPC_INST_NOP) {
pr_err("%s: Expect noop after relocate, got %08x\n",
   me->name, *instruction);
-- 
2.9.3

[PATCH v4 3/3] powerpc/modules: Improve restore_r2() error message

[Kamalesh Babulal]

From: Josh Poimboeuf 

Print the function address associated with the restore_r2() error to
make it easier to debug the problem.

Also clarify the wording a bit.

Before:

  module_64: patch_foo: Expect noop after relocate, got 3c82

After:

  module_64: patch_foo: Expected noop after call, got 7c630034 at 
netdev_has_upper_dev+0x54/0xb0 [patch_foo]

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Kamalesh Babulal 
---
 arch/powerpc/kernel/module_64.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 9e5391f..dad3ea5 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -494,8 +494,8 @@ static int restore_r2(u32 *instruction, struct module *me)
return 1;
 
if (*instruction != PPC_INST_NOP) {
-   pr_err("%s: Expect noop after relocate, got %08x\n",
-  me->name, *instruction);
+   pr_err("%s: Expected noop after call, got %08x at %pS\n",
+   me->name, *instruction, instruction);
return 0;
}
/* ld r2,R2_STACK_OFFSET(r1) */
-- 
2.9.3

Re: [PATCH 07/24] staging: ccree: remove unneeded cast

[Gilad Ben-Yossef]

On Mon, Nov 13, 2017 at 5:41 PM, Joe Perches  wrote:
>
> On Mon, 2017-11-13 at 14:45 +, Gilad Ben-Yossef wrote:
> > Remove uneeded cast from writel_relaxed parameter.
> []
> > diff --git a/drivers/staging/ccree/ssi_request_mgr.c 
> > b/drivers/staging/ccree/ssi_request_mgr.c
> []
> > @@ -167,13 +167,13 @@ static inline void enqueue_seq(
> >   int i;
> >
> >   for (i = 0; i < seq_len; i++) {
> > - writel_relaxed(seq[i].word[0], (volatile void __iomem 
> > *)(cc_base + CC_REG(DSCRPTR_QUEUE_WORD0)));
> > - writel_relaxed(seq[i].word[1], (volatile void __iomem 
> > *)(cc_base + CC_REG(DSCRPTR_QUEUE_WORD0)));
> > - writel_relaxed(seq[i].word[2], (volatile void __iomem 
> > *)(cc_base + CC_REG(DSCRPTR_QUEUE_WORD0)));
> > - writel_relaxed(seq[i].word[3], (volatile void __iomem 
> > *)(cc_base + CC_REG(DSCRPTR_QUEUE_WORD0)));
> > - writel_relaxed(seq[i].word[4], (volatile void __iomem 
> > *)(cc_base + CC_REG(DSCRPTR_QUEUE_WORD0)));
> > + writel_relaxed(seq[i].word[0], (cc_base + 
> > CC_REG(DSCRPTR_QUEUE_WORD0)));
>
> Maybe remove the now unnecessary parentheses around
> (cc_case + CC_REG(foo))
>
> Maybe review the use of inline in .c files too
>
> $ git grep -w inline drivers/staging/ccree/*.c | wc -l
> 41
>

Thanks, will do both.

Gilad



-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

Re: [PATCH 16/35] perf annotate: Add samples into struct annotation_line

[Jiri Olsa]

On Mon, Nov 13, 2017 at 09:14:38PM +0100, Jiri Olsa wrote:
> On Mon, Nov 13, 2017 at 09:16:20PM +0530, Ravi Bangoria wrote:
> > Hi Jiri,
> > 
> > This patch seems to be causing segfault with "perf top --stdio".
> > 
> > Steps to reproduce:
> > 1. start "perf top --stdio" in one terminal
> > 2. run some simple workload in another terminal, let it get finished.
> > 3. annotate function from previous workload in perf top (press 'a' followed
> > by 's')
> > 
> > Perf will crash with:
> > 
> >   perf: Segmentation fault
> >   Obtained 8 stack frames.
> >   ./perf(sighandler_dump_stack+0x3e) [0x4f1b6e]
> >   /lib64/libc.so.6(+0x36a7f) [0x7ff3aa7e4a7f]
> >   ./perf() [0x4a27fd]
> >   ./perf(symbol__annotate+0x199) [0x4a4439]
> >   ./perf() [0x44e32d]
> >   ./perf() [0x44f098]
> >   /lib64/libpthread.so.0(+0x736c) [0x7ff3acee836c]
> >   /lib64/libc.so.6(clone+0x3e) [0x7ff3aa8bee1e]
> > 
> > Can you please check.
> 
> hum, I'm getting following crash after resizing the terminal window:
> 
> perf: Floating point exception
> Obtained 8 stack frames.
> ./perf(dump_stack+0x2e) [0x510c89]
> ./perf(sighandler_dump_stack+0x2e) [0x510d69]
> /lib64/libc.so.6(+0x36a80) [0x7f9419588a80]
> ./perf(perf_top__header_snprintf+0x208) [0x4f42c1]
> ./perf() [0x453c09]
> ./perf() [0x454ddb]
> /lib64/libpthread.so.0(+0x736d) [0x7f941bc8c36d]
> /lib64/libc.so.6(clone+0x3f) [0x7f9419662e1f]
> Floating point exception (core dumped)
> 
> working on fix

so my crash is caused by bogus resize code, I have it working with fix for
memory corruption happening in SIGWINCH signal handler (attached)
could you please check if that fixes the code for you?

I'll check if that does not break the TUI

jirka


---
 tools/perf/builtin-top.c | 19 +--
 1 file changed, 13 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-top.c b/tools/perf/builtin-top.c
index adfeeb488f1a..7a2a7d7931c6 100644
--- a/tools/perf/builtin-top.c
+++ b/tools/perf/builtin-top.c
@@ -77,6 +77,7 @@
 #include "sane_ctype.h"
 
 static volatile int done;
+static volatile int resize;
 
 #define HEADER_LINE_NR  5
 
@@ -86,10 +87,13 @@ static void perf_top__update_print_entries(struct perf_top 
*top)
 }
 
 static void perf_top__sig_winch(int sig __maybe_unused,
-   siginfo_t *info __maybe_unused, void *arg)
+   siginfo_t *info __maybe_unused, void *arg 
__maybe_unused)
 {
-   struct perf_top *top = arg;
+   resize = 1;
+}
 
+static void perf_top__resize(struct perf_top *top)
+{
get_term_dimensions(&top->winsize);
perf_top__update_print_entries(top);
 }
@@ -475,9 +479,8 @@ static bool perf_top__handle_keypress(struct perf_top *top, 
int c)
if (top->print_entries == 0) {
struct sigaction act = {
.sa_sigaction = perf_top__sig_winch,
-   .sa_flags = SA_SIGINFO,
};
-   perf_top__sig_winch(SIGWINCH, NULL, top);
+   perf_top__resize(top);
sigaction(SIGWINCH, &act, NULL);
} else {
signal(SIGWINCH, SIG_DFL);
@@ -1030,6 +1033,11 @@ static int __cmd_top(struct perf_top *top)
 
if (hits == top->samples)
ret = perf_evlist__poll(top->evlist, 100);
+
+   if (resize) {
+   perf_top__resize(top);
+   resize = 0;
+   }
}
 
ret = 0;
@@ -1354,9 +1362,8 @@ int cmd_top(int argc, const char **argv)
if (top.print_entries == 0) {
struct sigaction act = {
.sa_sigaction = perf_top__sig_winch,
-   .sa_flags = SA_SIGINFO,
};
-   perf_top__update_print_entries(&top);
+   perf_top__resize(&top);
sigaction(SIGWINCH, &act, NULL);
}
 
-- 
2.9.5

[PATCH v4 0/3] ppc64le: Add REL24 relocation support of livepatch symbols

[Kamalesh Babulal]

This patchset drop the approach of creating new stub type for livepatch
symbols and offloads the issue of handling local function becoming global
to kpatch tool via gcc-plugin.

In function restore_r2(), a check for sibling call is added and also
improves the error message on unexpected op-code.

v4:
 - Drop creation of stubs for livepatch symbols and offload solution
   to kpatch tool.
 - Introduce check for sibling call, when restoring r2 after branch. (Josh)
 - Improve error message in restore_r2(). (Josh)

v3:
 - Defined FUNC_DESC_OFFSET to calculate func_desc offset from
   struct ppc64le_klp_stub_entry.
 - Replaced BUG_ON() with WARN_ON() in klp_stub_for_addr().
 - Major commit message re-write.

v2:
 - Changed klp_stub construction to re-use livepatch_handler and
   additional patch code required for klp_stub, instead of duplicating it.
 - Minor comments and commit body edit.

Josh Poimboeuf (2):
  powerpc/modules: Don't try to restore r2 after a sibling call
  powerpc/modules: Improve restore_r2() error message

Kamalesh Babulal (1):
  kernel/modules: Add REL24 relocation support of livepatch symbols

 arch/powerpc/kernel/module_64.c | 11 ---
 1 file changed, 8 insertions(+), 3 deletions(-)

-- 
2.9.3

Re: [PATCH] bluetooth: btusb: Add device ID for RTL8822BE

[kbuild test robot]

Hi Larry,

I love your patch! Perhaps something to improve:

[auto build test WARNING on bluetooth-next/master]
[also build test WARNING on v4.14 next-20171114]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Larry-Finger/bluetooth-btusb-Add-device-ID-for-RTL8822BE/20171114-152910
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/bluetooth/bluetooth-next.git 
master
config: i386-randconfig-x002-201746 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
# save the attached .config to linux build tree
make ARCH=i386 

All warnings (new ones prefixed by >>):

   In file included from drivers/bluetooth/btusb.c:25:0:
>> include/linux/usb.h:927:15: warning: large integer implicitly truncated to 
>> unsigned type [-Woverflow]
 .idProduct = (prod)
  ^
>> drivers/bluetooth/btusb.c:373:4: note: in expansion of macro 'USB_DEVICE'
 { USB_DEVICE(0x0b05, 0x1185c), .driver_info = BTUSB_REALTEK },
   ^~
--
   In file included from drivers//bluetooth/btusb.c:25:0:
>> include/linux/usb.h:927:15: warning: large integer implicitly truncated to 
>> unsigned type [-Woverflow]
 .idProduct = (prod)
  ^
   drivers//bluetooth/btusb.c:373:4: note: in expansion of macro 'USB_DEVICE'
 { USB_DEVICE(0x0b05, 0x1185c), .driver_info = BTUSB_REALTEK },
   ^~

vim +/USB_DEVICE +373 drivers/bluetooth/btusb.c

   181  
   182  static const struct usb_device_id blacklist_table[] = {
   183  /* CSR BlueCore devices */
   184  { USB_DEVICE(0x0a12, 0x0001), .driver_info = BTUSB_CSR },
   185  
   186  /* Broadcom BCM2033 without firmware */
   187  { USB_DEVICE(0x0a5c, 0x2033), .driver_info = BTUSB_IGNORE },
   188  
   189  /* Broadcom BCM2045 devices */
   190  { USB_DEVICE(0x0a5c, 0x2045), .driver_info = BTUSB_BCM2045 },
   191  
   192  /* Atheros 3011 with sflash firmware */
   193  { USB_DEVICE(0x0489, 0xe027), .driver_info = BTUSB_IGNORE },
   194  { USB_DEVICE(0x0489, 0xe03d), .driver_info = BTUSB_IGNORE },
   195  { USB_DEVICE(0x04f2, 0xaff1), .driver_info = BTUSB_IGNORE },
   196  { USB_DEVICE(0x0930, 0x0215), .driver_info = BTUSB_IGNORE },
   197  { USB_DEVICE(0x0cf3, 0x3002), .driver_info = BTUSB_IGNORE },
   198  { USB_DEVICE(0x0cf3, 0xe019), .driver_info = BTUSB_IGNORE },
   199  { USB_DEVICE(0x13d3, 0x3304), .driver_info = BTUSB_IGNORE },
   200  
   201  /* Atheros AR9285 Malbec with sflash firmware */
   202  { USB_DEVICE(0x03f0, 0x311d), .driver_info = BTUSB_IGNORE },
   203  
   204  /* Atheros 3012 with sflash firmware */
   205  { USB_DEVICE(0x0489, 0xe04d), .driver_info = BTUSB_ATH3012 },
   206  { USB_DEVICE(0x0489, 0xe04e), .driver_info = BTUSB_ATH3012 },
   207  { USB_DEVICE(0x0489, 0xe056), .driver_info = BTUSB_ATH3012 },
   208  { USB_DEVICE(0x0489, 0xe057), .driver_info = BTUSB_ATH3012 },
   209  { USB_DEVICE(0x0489, 0xe05f), .driver_info = BTUSB_ATH3012 },
   210  { USB_DEVICE(0x0489, 0xe076), .driver_info = BTUSB_ATH3012 },
   211  { USB_DEVICE(0x0489, 0xe078), .driver_info = BTUSB_ATH3012 },
   212  { USB_DEVICE(0x0489, 0xe095), .driver_info = BTUSB_ATH3012 },
   213  { USB_DEVICE(0x04c5, 0x1330), .driver_info = BTUSB_ATH3012 },
   214  { USB_DEVICE(0x04ca, 0x3004), .driver_info = BTUSB_ATH3012 },
   215  { USB_DEVICE(0x04ca, 0x3005), .driver_info = BTUSB_ATH3012 },
   216  { USB_DEVICE(0x04ca, 0x3006), .driver_info = BTUSB_ATH3012 },
   217  { USB_DEVICE(0x04ca, 0x3007), .driver_info = BTUSB_ATH3012 },
   218  { USB_DEVICE(0x04ca, 0x3008), .driver_info = BTUSB_ATH3012 },
   219  { USB_DEVICE(0x04ca, 0x300b), .driver_info = BTUSB_ATH3012 },
   220  { USB_DEVICE(0x04ca, 0x300d), .driver_info = BTUSB_ATH3012 },
   221  { USB_DEVICE(0x04ca, 0x300f), .driver_info = BTUSB_ATH3012 },
   222  { USB_DEVICE(0x04ca, 0x3010), .driver_info = BTUSB_ATH3012 },
   223  { USB_DEVICE(0x04ca, 0x3014), .driver_info = BTUSB_ATH3012 },
   224  { USB_DEVICE(0x04ca, 0x3018), .driver_info = BTUSB_ATH3012 },
   225  { USB_DEVICE(0x0930, 0x0219), .driver_info = BTUSB_ATH3012 },
   226  { USB_DEVICE(0x0930, 0x021c), .driver_info = BTUSB_ATH3012 },
   227  { USB_DEVICE(0x0930, 0x0220), .driver_info = BTUSB_ATH3012 },
   228  { USB_DEVICE(0x0930, 0x0227), .driver_info = BTUSB_ATH3012 },
   229  { USB_DEVICE(0x0b05, 0x17d0), .driver_info = BTUSB_ATH3012 },
   230  { USB_DEVICE(0x0cf3, 0x0036), .driver_info = BTUSB_ATH3012 },
   231  { USB_DEVICE(0x0cf3, 0x3004), .driver_info = BTUSB_ATH3012 },
   232  { USB_DEVICE

Re: [PATCH 1/5] KVM: vmx: use X86_CR4_UMIP and X86_FEATURE_UMIP

[Wanpeng Li]

2017-11-13 22:40 GMT+08:00 Paolo Bonzini :
> These bits were not defined until now in common code, but they are
> now that the kernel supports UMIP too.
>
> Signed-off-by: Paolo Bonzini 

Reviewed-by: Wanpeng Li 

> ---
>  arch/x86/kvm/vmx.c | 3 +--
>  1 file changed, 1 insertion(+), 2 deletions(-)
>
> diff --git a/arch/x86/kvm/vmx.c b/arch/x86/kvm/vmx.c
> index a6f4f095f8f4..8917e100ddeb 100644
> --- a/arch/x86/kvm/vmx.c
> +++ b/arch/x86/kvm/vmx.c
> @@ -9732,8 +9732,7 @@ static void nested_vmx_cr_fixed1_bits_update(struct 
> kvm_vcpu *vcpu)
> cr4_fixed1_update(X86_CR4_SMEP,   ebx, bit(X86_FEATURE_SMEP));
> cr4_fixed1_update(X86_CR4_SMAP,   ebx, bit(X86_FEATURE_SMAP));
> cr4_fixed1_update(X86_CR4_PKE,ecx, bit(X86_FEATURE_PKU));
> -   /* TODO: Use X86_CR4_UMIP and X86_FEATURE_UMIP macros */
> -   cr4_fixed1_update(bit(11),ecx, bit(2));
> +   cr4_fixed1_update(X86_CR4_UMIP,   ecx, bit(X86_FEATURE_UMIP));
>
>  #undef cr4_fixed1_update
>  }
> --
> 1.8.3.1
>
>

Re: [PATCH 00/24] staging: ccree: more cleanup patches

[Gilad Ben-Yossef]

On Mon, Nov 13, 2017 at 8:33 PM, Dan Carpenter  wrote:
> These cleanups look nice.  Thanks.
>
> I hope you do a mass remove of likely/unlikely in a patch soon.
> Whenever, I see one of those in a + line I always have to remind myself
> that you're planning to do it in a later patch.
>

So, a question about that - there indeed seems to be an inflation of
likely/unlikely in the ccree driver, but
what stopped me from removing them was that I found out I don't have a
clue about when it's a good idea
to use them and when it isn't (obviously in places where you know the
probable code flow of course).

Any hints?

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

"If you take a class in large-scale robotics, can you end up in a
situation where the homework eats your dog?"
 -- Jean-Baptiste Queru

[tip:x86/urgent] x86/umip: Identify the STR and SLDT instructions

[tip-bot for Ricardo Neri]

Commit-ID:  6e2a3064d6a86094fecc20cd430fd96aaa801687
Gitweb: https://git.kernel.org/tip/6e2a3064d6a86094fecc20cd430fd96aaa801687
Author: Ricardo Neri 
AuthorDate: Mon, 13 Nov 2017 22:29:44 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 14 Nov 2017 08:38:09 +0100

x86/umip: Identify the STR and SLDT instructions

The STR and SLDT instructions are not emulated by the UMIP code, thus
there's no functionality in the decoder to identify them.

However, a subsequent commit will introduce a warning about the use
of all the instructions that UMIP protect/changes, not only those that
are emulated.

A first step for that is to add the ability to decode/identify them.

Plus, now that STR and SLDT are identified, we need to explicitly avoid
their emulation (i.e., not rely on successful identification). Group
together all the cases that we do not want to emulate: STR, SLDT and user
long mode processes.

Signed-off-by: Ricardo Neri 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: ricardo.n...@intel.com
Link: 
http://lkml.kernel.org/r/1510640985-18412-4-git-send-email-ricardo.neri-calde...@linux.intel.com
[ Rewrote the changelog, fixed ugly col80 artifact. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/umip.c | 24 
 1 file changed, 16 insertions(+), 8 deletions(-)

diff --git a/arch/x86/kernel/umip.c b/arch/x86/kernel/umip.c
index 6ba82be..1f1f2d5 100644
--- a/arch/x86/kernel/umip.c
+++ b/arch/x86/kernel/umip.c
@@ -78,7 +78,9 @@
 
 #defineUMIP_INST_SGDT  0   /* 0F 01 /0 */
 #defineUMIP_INST_SIDT  1   /* 0F 01 /1 */
-#defineUMIP_INST_SMSW  3   /* 0F 01 /4 */
+#defineUMIP_INST_SMSW  2   /* 0F 01 /4 */
+#defineUMIP_INST_SLDT  3   /* 0F 00 /0 */
+#defineUMIP_INST_STR   4   /* 0F 00 /1 */
 
 /**
  * identify_insn() - Identify a UMIP-protected instruction
@@ -118,10 +120,16 @@ static int identify_insn(struct insn *insn)
default:
return -EINVAL;
}
+   } else if (insn->opcode.bytes[1] == 0x0) {
+   if (X86_MODRM_REG(insn->modrm.value) == 0)
+   return UMIP_INST_SLDT;
+   else if (X86_MODRM_REG(insn->modrm.value) == 1)
+   return UMIP_INST_STR;
+   else
+   return -EINVAL;
+   } else {
+   return -EINVAL;
}
-
-   /* SLDT AND STR are not emulated */
-   return -EINVAL;
 }
 
 /**
@@ -267,10 +275,6 @@ bool fixup_umip_exception(struct pt_regs *regs)
if (!regs)
return false;
 
-   /* Do not emulate 64-bit processes. */
-   if (user_64bit_mode(regs))
-   return false;
-
/*
 * If not in user-space long mode, a custom code segment could be in
 * use. This is true in protected mode (if the process defined a local
@@ -322,6 +326,10 @@ bool fixup_umip_exception(struct pt_regs *regs)
if (umip_inst < 0)
return false;
 
+   /* Do not emulate SLDT, STR or user long mode processes. */
+   if (umip_inst == UMIP_INST_STR || umip_inst == UMIP_INST_SLDT || 
user_64bit_mode(regs))
+   return false;
+
if (emulate_umip_insn(&insn, umip_inst, dummy_data, &dummy_data_size))
return false;
 

[tip:x86/urgent] x86/umip: Select X86_INTEL_UMIP by default

[tip-bot for Ricardo Neri]

Commit-ID:  796ebc81b9931bfa293b4ca38ae28c21a363f4d0
Gitweb: https://git.kernel.org/tip/796ebc81b9931bfa293b4ca38ae28c21a363f4d0
Author: Ricardo Neri 
AuthorDate: Mon, 13 Nov 2017 22:29:42 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 14 Nov 2017 08:38:08 +0100

x86/umip: Select X86_INTEL_UMIP by default

UMIP does cause any performance penalty to the vast majority of x86 code
that does not use the legacy instructions affected by UMIP.

Also describe UMIP more accurately and explain the behavior that can be
expected by the (few) applications that use the affected instructions.

Suggested-by: Ingo Molnar 
Signed-off-by: Ricardo Neri 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: ricardo.n...@intel.com
Link: 
http://lkml.kernel.org/r/1510640985-18412-2-git-send-email-ricardo.neri-calde...@linux.intel.com
[ Spelling fixes, rewrote the changelog. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/Kconfig | 12 +---
 1 file changed, 9 insertions(+), 3 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index f08977d..a0623f0 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -1805,14 +1805,20 @@ config X86_SMAP
  If unsure, say Y.
 
 config X86_INTEL_UMIP
-   def_bool n
+   def_bool y
depends on CPU_SUP_INTEL
prompt "Intel User Mode Instruction Prevention" if EXPERT
---help---
  The User Mode Instruction Prevention (UMIP) is a security
  feature in newer Intel processors. If enabled, a general
- protection fault is issued if the instructions SGDT, SLDT,
- SIDT, SMSW and STR are executed in user mode.
+ protection fault is issued if the SGDT, SLDT, SIDT, SMSW
+ or STR instructions are executed in user mode. These instructions
+ unnecessarily expose information about the hardware state.
+
+ The vast majority of applications do not use these instructions.
+ For the very few that do, software emulation is provided in
+ specific cases in protected and virtual-8086 modes. Emulated
+ results are dummy.
 
 config X86_INTEL_MPX
prompt "Intel MPX (Memory Protection Extensions)"

[tip:locking/urgent] jump_label: Invoke jump_label_test() via early_initcall()

[tip-bot for Jason Baron]

Commit-ID:  92ee46efeb505ead3ab06d3c5ce695637ed5f152
Gitweb: https://git.kernel.org/tip/92ee46efeb505ead3ab06d3c5ce695637ed5f152
Author: Jason Baron 
AuthorDate: Mon, 13 Nov 2017 16:48:47 -0500
Committer:  Ingo Molnar 
CommitDate: Tue, 14 Nov 2017 08:41:41 +0100

jump_label: Invoke jump_label_test() via early_initcall()

Fengguang Wu reported that running the rcuperf test during boot can cause
the jump_label_test() to hit a WARN_ON(). The issue is that the core jump
label code relies on kernel_text_address() to detect when it can no longer
update branches that may be contained in __init sections. The
kernel_text_address() in turn assumes that if the system_state variable is
greter than or equal to SYSTEM_RUNNING then __init sections are no longer
valid (since the assumption is that they have been freed). However, when
rcuperf is setup to run in early boot it can call kernel_power_off() which
sets the system_state to SYSTEM_POWER_OFF.

Since rcuperf initialization is invoked via a module_init(), we can make
the dependency of jump_label_test() needing to complete before rcuperf
explicit by calling it via early_initcall().

Reported-by: Fengguang Wu 
Signed-off-by: Jason Baron 
Acked-by: Paul E. McKenney 
Cc: Linus Torvalds 
Cc: Peter Zijlstra 
Cc: Steven Rostedt 
Cc: Thomas Gleixner 
Link: 
http://lkml.kernel.org/r/1510609727-2238-1-git-send-email-jba...@akamai.com
Signed-off-by: Ingo Molnar 
---
 kernel/jump_label.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/kernel/jump_label.c b/kernel/jump_label.c
index 8ff4ca4..8594d24 100644
--- a/kernel/jump_label.c
+++ b/kernel/jump_label.c
@@ -769,7 +769,7 @@ static __init int jump_label_test(void)
 
return 0;
 }
-late_initcall(jump_label_test);
+early_initcall(jump_label_test);
 #endif /* STATIC_KEYS_SELFTEST */
 
 #endif /* HAVE_JUMP_LABEL */

[tip:x86/urgent] x86/umip: Print a line in the boot log that UMIP has been enabled

[tip-bot for Ricardo Neri]

Commit-ID:  770c77557757873808a474016a3cae4b37690cb2
Gitweb: https://git.kernel.org/tip/770c77557757873808a474016a3cae4b37690cb2
Author: Ricardo Neri 
AuthorDate: Mon, 13 Nov 2017 22:29:43 -0800
Committer:  Ingo Molnar 
CommitDate: Tue, 14 Nov 2017 08:38:09 +0100

x86/umip: Print a line in the boot log that UMIP has been enabled

Indicate that this feature has been enabled.

Suggested-by: Ingo Molnar 
Signed-off-by: Ricardo Neri 
Cc: Andy Lutomirski 
Cc: Borislav Petkov 
Cc: Linus Torvalds 
Cc: Paolo Bonzini 
Cc: Peter Zijlstra 
Cc: Ravi V. Shankar 
Cc: Thomas Gleixner 
Cc: Tony Luck 
Cc: ricardo.n...@intel.com
Link: 
http://lkml.kernel.org/r/1510640985-18412-3-git-send-email-ricardo.neri-calde...@linux.intel.com
[ Changelog tweaks. ]
Signed-off-by: Ingo Molnar 
---
 arch/x86/kernel/cpu/common.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index 13ae9e5..fa998ca 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -341,6 +341,8 @@ static __always_inline void setup_umip(struct cpuinfo_x86 
*c)
 
cr4_set_bits(X86_CR4_UMIP);
 
+   pr_info("x86/cpu: Activated the Intel User Mode Instruction Prevention 
(UMIP) CPU feature\n");
+
return;
 
 out:

RE: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of supported chip names

[Fabrizio Castro]

Dear All,

how does this patch look like?

Thanks,
Fabrizio

> Subject: [PATCH v2] dt-bindings: mtd: Add sst25vf016b to the list of 
> supported chip names
>
> There are a few DT files that make use of sst25vf016b in their
> compatible strings, and the driver supports this chip already.
> This patch improves the documentation and therefore the result
> of ./scripts/checkpatch.pl.
>
> Signed-off-by: Fabrizio Castro 
> Signed-off-by: Chris Paterson 
> Acked-by: Rob Herring 
> Acked-by: Geert Uytterhoeven 
> ---
> Thank you Rob, thank you Geert, and sorry for the delay on this one.
> Here is v2.
>
> Changes in v2:
> * fixed subject prefix
> * added changelog
>
>  Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt 
> b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> index 4cab5d8..bf56d77 100644
> --- a/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> +++ b/Documentation/devicetree/bindings/mtd/jedec,spi-nor.txt
> @@ -31,6 +31,7 @@ Required properties:
>   s25sl12801
>   s25fl008k
>   s25fl064k
> + sst25vf016b
>   sst25vf040b
>   sst25wf040b
>   m25p40
> --
> 2.7.4




Renesas Electronics Europe Ltd, Dukes Meadow, Millboard Road, Bourne End, 
Buckinghamshire, SL8 5FH, UK. Registered in England & Wales under Registered 
No. 04586709.

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

[Quan Xu]

On 2017/11/14 15:30, Juergen Gross wrote:

On 14/11/17 08:02, Quan Xu wrote:


On 2017/11/13 18:53, Juergen Gross wrote:

On 13/11/17 11:06, Quan Xu wrote:

From: Quan Xu 

So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.

In virtualization, idle path includes several heavy operations
includes timer access(LAPIC timer or TSC deadline timer) which will
hurt performance especially for latency intensive workload like message
passing task. The cost is mainly from the vmexit which is a hardware
context switch between virtual machine and hypervisor. Our solution is
to poll for a while and do not enter real idle path if we can get the
schedule event during polling.

Poll may cause the CPU waste so we adopt a smart polling mechanism to
reduce the useless poll.

Signed-off-by: Yang Zhang 
Signed-off-by: Quan Xu 
Cc: Juergen Gross 
Cc: Alok Kataria 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org

Hmm, is the idle entry path really so critical to performance that a new
pvops function is necessary?

Juergen, Here is the data we get when running benchmark netperf:
  1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
     29031.6 bit/s -- 76.1 %CPU

  2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
     35787.7 bit/s -- 129.4 %CPU

  3. w/ kvm dynamic poll:
     35735.6 bit/s -- 200.0 %CPU

  4. w/patch and w/ kvm dynamic poll:
     42225.3 bit/s -- 198.7 %CPU

  5. idle=poll
     37081.7 bit/s -- 998.1 %CPU



  w/ this patch, we will improve performance by 23%.. even we could improve
  performance by 45.4%, if we use w/patch and w/ kvm dynamic poll. also the
  cost of CPU is much lower than 'idle=poll' case..

I don't question the general idea. I just think pvops isn't the best way
to implement it.


Wouldn't a function pointer, maybe guarded
by a static key, be enough? A further advantage would be that this would
work on other architectures, too.

I assume this feature will be ported to other archs.. a new pvops makes


  sorry, a typo.. /other archs/other hypervisors/
  it refers hypervisor like Xen, HyperV and VMware)..


code
clean and easy to maintain. also I tried to add it into existed pvops,
but it
doesn't match.

You are aware that pvops is x86 only?


yes, I'm aware..


I really don't see the big difference in maintainability compared to the
static key / function pointer variant:

void (*guest_idle_poll_func)(void);
struct static_key guest_idle_poll_key __read_mostly;

static inline void guest_idle_poll(void)
{
if (static_key_false(&guest_idle_poll_key))
guest_idle_poll_func();
}




thank you for your sample code :)
I agree there is no big difference.. I think we are discussion for two 
things:

 1) x86 VM on different hypervisors
 2) different archs VM on kvm hypervisor

What I want to do is x86 VM on different hypervisors, such as kvm / xen 
/ hyperv ..



And KVM would just need to set guest_idle_poll_func and enable the
static key. Works on non-x86 architectures, too.



.. referred to 'pv_mmu_ops', HyperV and Xen can implement their own 
functions for 'pv_mmu_ops'.

I think it is the same to pv_idle_ops.

with above explaination, do you still think I need to define the static
key/function pointer variant?

btw, any interest to port it to Xen HVM guest? :)

Quan
Alibaba Cloud

Re: [PATCH v2] fs: fsnotify: account fsnotify metadata to kmemcg

[Michal Hocko]

On Tue 14-11-17 03:10:22, Yang Shi wrote:
> 
> 
> On 11/9/17 5:54 AM, Michal Hocko wrote:
> > [Sorry for the late reply]
> > 
> > On Tue 31-10-17 11:12:38, Jan Kara wrote:
> > > On Tue 31-10-17 00:39:58, Yang Shi wrote:
> > [...]
> > > > I do agree it is not fair and not neat to account to producer rather 
> > > > than
> > > > misbehaving consumer, but current memcg design looks not support such 
> > > > use
> > > > case. And, the other question is do we know who is the listener if it
> > > > doesn't read the events?
> > > 
> > > So you never know who will read from the notification file descriptor but
> > > you can simply account that to the process that created the notification
> > > group and that is IMO the right process to account to.
> > 
> > Yes, if the creator is de-facto owner which defines the lifetime of
> > those objects then this should be a target of the charge.
> > 
> > > I agree that current SLAB memcg accounting does not allow to account to a
> > > different memcg than the one of the running process. However I *think* it
> > > should be possible to add such interface. Michal?
> > 
> > We do have memcg_kmem_charge_memcg but that would require some plumbing
> > to hook it into the specific allocation path. I suspect it uses kmalloc,
> > right?
> 
> Yes.
> 
> I took a look at the implementation and the callsites of
> memcg_kmem_charge_memcg(). It looks it is called by:
> 
> * charge kmem to memcg, but it is charged to the allocator's memcg
> * allocate new slab page, charge to memcg_params.memcg
> 
> I think this is the plumbing you mentioned, right?

Maybe I have misunderstood, but you are using slab allocator. So you
would need to force it to use a different charging context than current.
I haven't checked deeply but this doesn't look trivial to me.
-- 
Michal Hocko
SUSE Labs

[PATCH] lib: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "" in the lib directory.

Signed-off-by: Martin Kepplinger 
---

This is an attempt to sneak this in for the lib subdirectory in one go.
If you would rather have the changes individually go to the relevant
people, please just say so.

thanks
   martin


 lib/decompress_unlzo.c| 3 +--
 lib/dma-debug.c   | 3 +--
 lib/flex_array.c  | 3 +--
 lib/llist.c   | 3 +--
 lib/mpi/generic_mpih-add1.c   | 3 +--
 lib/mpi/generic_mpih-lshift.c | 3 +--
 lib/mpi/generic_mpih-mul1.c   | 3 +--
 lib/mpi/generic_mpih-mul2.c   | 3 +--
 lib/mpi/generic_mpih-mul3.c   | 3 +--
 lib/mpi/generic_mpih-rshift.c | 3 +--
 lib/mpi/generic_mpih-sub1.c   | 3 +--
 lib/mpi/longlong.h| 5 ++---
 lib/mpi/mpi-bit.c | 3 +--
 lib/mpi/mpi-cmp.c | 3 +--
 lib/mpi/mpi-inline.h  | 3 +--
 lib/mpi/mpi-internal.h| 3 +--
 lib/mpi/mpi-pow.c | 3 +--
 lib/mpi/mpicoder.c| 3 +--
 lib/mpi/mpih-cmp.c| 3 +--
 lib/mpi/mpih-div.c| 3 +--
 lib/mpi/mpih-mul.c| 3 +--
 lib/mpi/mpiutil.c | 3 +--
 lib/rbtree.c  | 3 +--
 lib/timerqueue.c  | 3 +--
 24 files changed, 25 insertions(+), 49 deletions(-)

diff --git a/lib/decompress_unlzo.c b/lib/decompress_unlzo.c
index f4c158e3a022..fa71c4dc0542 100644
--- a/lib/decompress_unlzo.c
+++ b/lib/decompress_unlzo.c
@@ -22,8 +22,7 @@
  *
  * You should have received a copy of the GNU General Public License
  * along with this program; see the file COPYING.
- * If not, write to the Free Software Foundation, Inc.,
- * 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * If not, see .
  *
  * Markus F.X.J. Oberhumer
  * 
diff --git a/lib/dma-debug.c b/lib/dma-debug.c
index e5b4237da650..d76e5c1a495c 100644
--- a/lib/dma-debug.c
+++ b/lib/dma-debug.c
@@ -13,8 +13,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307 USA
+ * along with this program.  If not, see .
  */
 
 #include 
diff --git a/lib/flex_array.c b/lib/flex_array.c
index 2eed22fa507c..234895ab27d9 100644
--- a/lib/flex_array.c
+++ b/lib/flex_array.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program.  If not, see .
  *
  * Copyright IBM Corporation, 2009
  *
diff --git a/lib/llist.c b/lib/llist.c
index 7062e931a7bb..a56ba9f0350e 100644
--- a/lib/llist.c
+++ b/lib/llist.c
@@ -19,8 +19,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program.  If not, see .
  */
 #include 
 #include 
diff --git a/lib/mpi/generic_mpih-add1.c b/lib/mpi/generic_mpih-add1.c
index c94c7dd344b3..3c3e94556adb 100644
--- a/lib/mpi/generic_mpih-add1.c
+++ b/lib/mpi/generic_mpih-add1.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see .
  *
  * Note: This code is heavily based on the GNU MP Library.
  *  Actually it's the same code with only minor changes in the
diff --git a/lib/mpi/generic_mpih-lshift.c b/lib/mpi/generic_mpih-lshift.c
index 86318927231a..84d0d800996c 100644
--- a/lib/mpi/generic_mpih-lshift.c
+++ b/lib/mpi/generic_mpih-lshift.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
+ * along with this program.  If not, see .
  *
  * Note: This code is heavily based on the GNU MP Library.
  *  Actually it's the same code with only minor changes in the
diff --git a/lib/mp

[PATCH] mm: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "" in the mm directory.

Signed-off-by: Martin Kepplinger 
---
 mm/kmemleak-test.c | 3 +--
 mm/kmemleak.c  | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/mm/kmemleak-test.c b/mm/kmemleak-test.c
index dd3c23a801b1..9a13ad2c0cca 100644
--- a/mm/kmemleak-test.c
+++ b/mm/kmemleak-test.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  */
 
 #define pr_fmt(fmt) "kmemleak: " fmt
diff --git a/mm/kmemleak.c b/mm/kmemleak.c
index e4738d5e9b8c..e6d6d3c9f543 100644
--- a/mm/kmemleak.c
+++ b/mm/kmemleak.c
@@ -14,8 +14,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  *
  *
  * For more information on the algorithm and kmemleak usage, please see
-- 
2.11.0

Re: [PATCH] lib: use correct format string for find-bit tests

[Yury Norov]

On Mon, Nov 13, 2017 at 02:55:45PM +0100, Arnd Bergmann wrote:
> The cycles_t definition is architecture specific, which causes
> a link error on all architectures that use a 'long long' or 'int'
> type for it:
> 
> lib/test_find_bit.c: In function 'test_find_last_bit':
> include/linux/kern_levels.h:5:18: error: format '%ld' expects argument of 
> type 'long int', but argument 2 has type 'cycles_t {aka long long unsigned 
> int}' [-Werror=format=]
> 
> This adds an explicit cast to 'u64' for it, which lets us use
> '%llu' everywhere.
> 
> Fixes: 09588b1f1d58 ("lib: test module for find_*_bit() functions")
> Signed-off-by: Arnd Bergmann 

Hi Arnd,

patch looks OK. Thank you.

Acked-by: Yury Norov 

Re: [GIT PULL] x86 updates for v4.15

[Borislav Petkov]

On Mon, Nov 13, 2017 at 09:02:36PM -0800, Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 12:24 AM, Ingo Molnar  wrote:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > x86-asm-for-linus
> 
> Hmm #2.
> 
> My laptop had odd SIGBUS and IO errors after a suspend/resume cycle
> when running commit d6ec9d9a4def, which is after my merge of the x86
> core changes.

Just did 2 suspend cycles (once to RAM and once to disk) on my x230
with your tree from right now and it looks ok so far. So it could be
machine- and config-specific...

-- 
Regards/Gruss,
Boris.

Good mailing practices for 400: avoid top-posting and trim the reply.

Re: [PATCH 00/24] staging: ccree: more cleanup patches

[Dan Carpenter]

On Tue, Nov 14, 2017 at 11:33:20AM +0200, Gilad Ben-Yossef wrote:
> On Mon, Nov 13, 2017 at 8:33 PM, Dan Carpenter  
> wrote:
> > These cleanups look nice.  Thanks.
> >
> > I hope you do a mass remove of likely/unlikely in a patch soon.
> > Whenever, I see one of those in a + line I always have to remind myself
> > that you're planning to do it in a later patch.
> >
> 
> So, a question about that - there indeed seems to be an inflation of
> likely/unlikely in the ccree driver, but
> what stopped me from removing them was that I found out I don't have a
> clue about when it's a good idea
> to use them and when it isn't (obviously in places where you know the
> probable code flow of course).
> 
> Any hints?

They should only be included if benchmarking shows that it makes a
difference.  I think they need to be about 100 right predictions to 1
wrong prediction on a fast path.  So remove them all and add them back
one at a time.


regards,
dan carpenter

Re: [PATCH v3] coccinelle: fix parallel build with CHECK=scripts/coccicheck

[Julia Lawall]

> +
> +# If -j option is given to Make, scripts/coccicheck runs in parallel.
> +# If coccinelle also runs in parallel, it fails because multiple 
> processes
> +# try to get access to the same subdirectory that stores stdout/stderr.
> +# No need to parallelize coccinelle in this case - this mode takes only
> +# one file input.
> +NPROC=1

Since I am also changing Coccinelle to avoid the problem, maybe it would
be better to just remove the explanation sentence (If coccinelle also runs
in parallel,...).

julia

Re: [PATCH] mm: replace FSF address with web source in license notices

[Michal Hocko]

On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
> A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
> still in our source files feels old and unmaintained.
> 
> Let's take the license statement serious and not confuse users.
> 
> As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
> postal address with "" in the mm directory.

Why to change this now? Isn't there a general plan to move to SPDX?
-- 
Michal Hocko
SUSE Labs

[PATCH] kbuild: move coccicheck help in scripts/Makefile.help to top Makefile

[Masahiro Yamada]

I do not think it is helpful to have a separate file just for the
coccicheck help message.  Merge scripts/Makefile.help into the
top-level Makefile.

Signed-off-by: Masahiro Yamada 
---

 Makefile  | 2 +-
 scripts/Makefile.help | 3 ---
 2 files changed, 1 insertion(+), 4 deletions(-)
 delete mode 100644 scripts/Makefile.help

diff --git a/Makefile b/Makefile
index f060f94..3b7d477 100644
--- a/Makefile
+++ b/Makefile
@@ -1388,7 +1388,7 @@ help:
@echo  '  export_report   - List the usages of all exported symbols'
@echo  '  headers_check   - Sanity check on exported headers'
@echo  '  headerdep   - Detect inclusion cycles in headers'
-   @$(MAKE) -f $(srctree)/scripts/Makefile.help checker-help
+   @echo  '  coccicheck  - Check with Coccinelle'
@echo  ''
@echo  'Kernel selftest:'
@echo  '  kselftest   - Build and run kernel selftest (run as root)'
diff --git a/scripts/Makefile.help b/scripts/Makefile.help
deleted file mode 100644
index d03608f..000
--- a/scripts/Makefile.help
+++ /dev/null
@@ -1,3 +0,0 @@
-
-checker-help:
-   @echo  '  coccicheck  - Check with Coccinelle.'
-- 
2.7.4

[PATCH] samples: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "" in the samples
directory.

Signed-off-by: Martin Kepplinger 
---
 samples/auxdisplay/cfag12864b-example.c | 3 +--
 samples/configfs/configfs_sample.c  | 6 ++
 samples/connector/cn_test.c | 3 +--
 samples/connector/ucon.c| 3 +--
 samples/hw_breakpoint/data_breakpoint.c | 3 +--
 5 files changed, 6 insertions(+), 12 deletions(-)

diff --git a/samples/auxdisplay/cfag12864b-example.c 
b/samples/auxdisplay/cfag12864b-example.c
index e7823ffb1ca0..fc8b4c6c655f 100644
--- a/samples/auxdisplay/cfag12864b-example.c
+++ b/samples/auxdisplay/cfag12864b-example.c
@@ -17,8 +17,7 @@
  *  GNU General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ *  along with this program.  If not, see .
  *
  */
 
diff --git a/samples/configfs/configfs_sample.c 
b/samples/configfs/configfs_sample.c
index 004a4e201476..43810e6c745d 100644
--- a/samples/configfs/configfs_sample.c
+++ b/samples/configfs/configfs_sample.c
@@ -15,10 +15,8 @@
  * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
  * General Public License for more details.
  *
- * You should have received a copy of the GNU General Public
- * License along with this program; if not, write to the
- * Free Software Foundation, Inc., 59 Temple Place - Suite 330,
- * Boston, MA 021110-1307, USA.
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
  *
  * Based on sysfs:
  * sysfs is Copyright (C) 2001, 2002, 2003 Patrick Mochel
diff --git a/samples/connector/cn_test.c b/samples/connector/cn_test.c
index 95cd06f4ec1e..48dfe47e65a5 100644
--- a/samples/connector/cn_test.c
+++ b/samples/connector/cn_test.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307  USA
+ * along with this program.  If not, see .
  */
 
 #define pr_fmt(fmt) "cn_test: " fmt
diff --git a/samples/connector/ucon.c b/samples/connector/ucon.c
index 8a4da64e02a8..1943aba7e903 100644
--- a/samples/connector/ucon.c
+++ b/samples/connector/ucon.c
@@ -15,8 +15,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  */
 
 #include 
diff --git a/samples/hw_breakpoint/data_breakpoint.c 
b/samples/hw_breakpoint/data_breakpoint.c
index ef7f32291852..7ff5db0ccfe9 100644
--- a/samples/hw_breakpoint/data_breakpoint.c
+++ b/samples/hw_breakpoint/data_breakpoint.c
@@ -12,8 +12,7 @@
  * GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program; if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ * along with this program.  If not, see .
  *
  * usage: insmod data_breakpoint.ko ksym=
  *
-- 
2.11.0

Re: [PATCH v4 5/6] remoteproc: qcom: Add support for q6v5-wcss pil

[Sricharan R]

Hi Rob,

On 11/11/2017 2:38 AM, Rob Herring wrote:
> On Thu, Nov 09, 2017 at 08:16:14PM +0530, Sricharan R wrote:
>> IPQ8074 has an integrated Hexagon dsp core q6v5 and a wireless lan
>> (Lithium) IP. An mdt type single image format is used for the
>> firmware. So the mdt_load function can be directly used to load
>> the firmware. Also add the relevant resets required for this core.
>>
>> Signed-off-by: Sricharan R 
>> ---
>>  .../devicetree/bindings/remoteproc/qcom,q6v5.txt   |  7 ++-
> 
> Please add acks when posting new versions.

oops.Really sorry, missed it. will update.

Regards,
 Sricharan

-- 
"QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a member of 
Code Aurora Forum, hosted by The Linux Foundation

---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus

Re: [PATCH] kbuild: move coccicheck help in scripts/Makefile.help to top Makefile

[Julia Lawall]

On Tue, 14 Nov 2017, Masahiro Yamada wrote:

> I do not think it is helpful to have a separate file just for the
> coccicheck help message.  Merge scripts/Makefile.help into the
> top-level Makefile.
>
> Signed-off-by: Masahiro Yamada 

Acked-by: Julia Lawall 

Thanks!

> ---
>
>  Makefile  | 2 +-
>  scripts/Makefile.help | 3 ---
>  2 files changed, 1 insertion(+), 4 deletions(-)
>  delete mode 100644 scripts/Makefile.help
>
> diff --git a/Makefile b/Makefile
> index f060f94..3b7d477 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -1388,7 +1388,7 @@ help:
>   @echo  '  export_report   - List the usages of all exported symbols'
>   @echo  '  headers_check   - Sanity check on exported headers'
>   @echo  '  headerdep   - Detect inclusion cycles in headers'
> - @$(MAKE) -f $(srctree)/scripts/Makefile.help checker-help
> + @echo  '  coccicheck  - Check with Coccinelle'
>   @echo  ''
>   @echo  'Kernel selftest:'
>   @echo  '  kselftest   - Build and run kernel selftest (run as root)'
> diff --git a/scripts/Makefile.help b/scripts/Makefile.help
> deleted file mode 100644
> index d03608f..000
> --- a/scripts/Makefile.help
> +++ /dev/null
> @@ -1,3 +0,0 @@
> -
> -checker-help:
> - @echo  '  coccicheck  - Check with Coccinelle.'
> --
> 2.7.4
>
>

Re: [PATCH -next] irqchip/exiu: Fix return value check in exiu_init()

[Ard Biesheuvel]

On 14 November 2017 at 06:57, Wei Yongjun  wrote:
> In case of error, the function of_iomap() returns NULL pointer not
> ERR_PTR(). The IS_ERR() test in the return value check should be
> replaced with NULL test.
>
> Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU 
> controller")
> Signed-off-by: Wei Yongjun 
> ---
>  drivers/irqchip/irq-sni-exiu.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/irqchip/irq-sni-exiu.c b/drivers/irqchip/irq-sni-exiu.c
> index 1b6e2f7..1927b2f 100644
> --- a/drivers/irqchip/irq-sni-exiu.c
> +++ b/drivers/irqchip/irq-sni-exiu.c
> @@ -196,8 +196,8 @@ static int __init exiu_init(struct device_node *node,
> }
>
> data->base = of_iomap(node, 0);
> -   if (IS_ERR(data->base)) {
> -   err = PTR_ERR(data->base);
> +   if (!data->base) {
> +   err = -ENODEV;
> goto out_free;
> }
>

I was going to blame Marc's Tegra code for this, because that is where
I copied most of the code from, but the bug doesn't exist there, and
so it appears to be an original work. Oops.

Acked-by: Ard Biesheuvel 

Re: [PATCH] mm: replace FSF address with web source in license notices

[Martin Kepplinger]

Am 14.11.2017 10:49 schrieb Michal Hocko:

On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
A few years ago the FSF moved and "59 Temple Place" is wrong. Having 
this

still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace 
the
postal address with "" in the mm 
directory.


Why to change this now? Isn't there a general plan to move to SPDX?


Shouldn't a move to SPDX only be additions to what we currently have? 
That's
at least what the "reuse" project suggests, see 
https://reuse.software/practices/

with "Don’t remove existing headers, but only add to them."

thanks

   martin

Re: [PATCH] PM / runtime: Drop children check from __pm_runtime_set_status()

[Ulf Hansson]

On 14 November 2017 at 10:13, Ulf Hansson  wrote:
> On 13 November 2017 at 22:50, Rafael J. Wysocki  wrote:
>> On Monday, November 13, 2017 2:26:28 PM CET Ulf Hansson wrote:
>>> On 12 November 2017 at 01:27, Rafael J. Wysocki  wrote:
>>> > From: Rafael J. Wysocki 
>>> >
>>> > The check for "active" children in __pm_runtime_set_status(), when
>>> > trying to set the parent device status to "suspended", doesn't
>>> > really make sense, because in fact it is not invalid to set the
>>> > status of a device with runtime PM disabled to "suspended" in any
>>> > case.  It is invalid to enable runtime PM for a device with its
>>> > status set to "suspended" while its child_count reference counter
>>> > is nonzero, but the check in __pm_runtime_set_status() doesn't
>>> > really cover that situation.
>>>
>>> The reason to why I changed this in commit a8636c89648a ("PM /
>>> Runtime: Don't allow to suspend a device with an active child") was
>>> because to get a consistent behavior.
>>
>> Well, it causes the function to return an error in a non-error situation,
>> which IMnsHO is a bug.
>>
>>> Because, setting the device's status to active (RPM_ACTIVE) via
>>> __pm_runtime_set_status(), requires its parent to also be active (in
>>> case the parent has runtime PM enabled).
>>
>> No!!!
>>
>> The check is in there, because the parent's usage_count is affected by that
>> code and incrementing it in case the parent has runtime PM enabled and is
>> RPM_SUSPENDED leads to an inconsistent runtime PM state of the parent.  IOW,
>> it would confuse the framework.
>
> Right, I do understand the reasons *why* it is like this.
>
>>
>> There's no such issue if the runtime PM status of a child is set to 
>> RPM_SUSPENDED.
>>
>> It is all consistent without the check I'm removing and is made inconsistent
>> by that very check.
>>
>>> I would prefer to try maintain this consistency, but I also I realize
>>> that commit a8636c89648a, should also have been checking if the parent
>>> has runtime PM enabled (again for consistency), which it doesn't.
>>>
>>> What about fixing that instead?
>>
>> Runtime PM is *disabled* for the parent at this point, guaranteed, so there's
>> nothing to check, I'm afraid ...
>
> Where and how is that guarantee made?

Oh, just realize that it should be "child" instead of "parent", in the
above reasoning. Apologize for giving the wrong argument.

So, let's me take this once again, to make it clear.

When pm_runtime_set_suspended(dev) is called, dev's child device may
still be runtime PM enabled and active.
I was suggesting to add a check for this scenario, to see if dev's
child device is runtime PM is enabled, as and additional constraint
before deciding to return an error code.

The idea was to get a consistent behavior, from the
pm_runtime_set_active|suspended() APIs point of view, and not from the
runtime PM core point of view.

Of course, because dev->power.child_count, is maintained properly even
when runtime PM is disabled for dev's child device, it works as you
have suggested in $subject patch as well.

[...]

Kind regards
Uffe

Re: [PATCH] mm: replace FSF address with web source in license notices

[Michal Hocko]

On Tue 14-11-17 10:55:35, Martin Kepplinger wrote:
> Am 14.11.2017 10:49 schrieb Michal Hocko:
> > On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
> > > A few years ago the FSF moved and "59 Temple Place" is wrong. Having
> > > this
> > > still in our source files feels old and unmaintained.
> > > 
> > > Let's take the license statement serious and not confuse users.
> > > 
> > > As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace
> > > the
> > > postal address with "" in the mm
> > > directory.
> > 
> > Why to change this now? Isn't there a general plan to move to SPDX?
> 
> Shouldn't a move to SPDX only be additions to what we currently have? That's
> at least what the "reuse" project suggests, see
> https://reuse.software/practices/
> with "Don’t remove existing headers, but only add to them."

I thought the primary motivation was to unify _all_ headers and get rid
of all the duplication. (aside from files which do not have any license
which is under discussion elsewhere).
-- 
Michal Hocko
SUSE Labs

Re: [PATCH v3] coccinelle: fix parallel build with CHECK=scripts/coccicheck

[Masahiro Yamada]

Hi Julia,


2017-11-14 18:49 GMT+09:00 Julia Lawall :
>> +
>> +# If -j option is given to Make, scripts/coccicheck runs in parallel.
>> +# If coccinelle also runs in parallel, it fails because multiple 
>> processes
>> +# try to get access to the same subdirectory that stores stdout/stderr.
>> +# No need to parallelize coccinelle in this case - this mode takes only
>> +# one file input.
>> +NPROC=1
>
> Since I am also changing Coccinelle to avoid the problem, maybe it would
> be better to just remove the explanation sentence (If coccinelle also runs
> in parallel,...).
>
> julia

OK.  Which lines are unneeded?

Is it OK to remove all the comments, then just add "NPROC=1"?


-- 
Best Regards
Masahiro Yamada

Re: [GIT pull] printk updates for 4.15

[Petr Mladek]

On Mon 2017-11-13 17:18:33, Linus Torvalds wrote:
> On Mon, Nov 13, 2017 at 1:36 AM, Thomas Gleixner  wrote:
> > Linus,
> >
> > please pull the latest core-printk-for-linus git tree from:
> >
> >git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> > core-printk-for-linus
> >
> > This update adds the mechanisms to emit printk timestamps based on
> > different clocks:
> >
> >   - scheduler clock (default)
> >   - monotonic time
> >   - boot time
> >   - wall clock time
> >
> > This helps to correlate dmesg with user space log information, tracing,
> > etc. This can be local correlation or in case of wall clock time correlated
> > across machines, assumed that all machines are synchronized via
> > NTP/PTP.
> 
> Honestly, this just seems bogus to me, particularly since it's a single 
> choice.
> 
> The *sane* model would be to
> 
>  (a) continue to use the existing time that we always have
> (local_clock()) in the printk timestamps, and don't confuse people
> with the semantics of that field changing.
> 
>  (b) just emit a "synchronization printk" every once in a while, which
> is obviously also using the same standard time source, but the line
> actually _says_ what the other time sources are.

This was actually the original approach by Mark Salyzyn, see
https://lkml.kernel.org/r/20170720182505.9357-1-saly...@android.com


> Then it's easy to see what the printk time source is, in relation to
> any _number_ of other timesources. And if that synchronization printk
> is nicely formatted, it will even be something that people appreciate
> seeing in dmesg _irrespective_ of any actual synchronization issues.
> 
> And something that reads the journal could trivially pick up on the
> synchronization printk line, and then correct the local timesource to
> whatever internal journal timesource it wants to. And the important
> thing is that because you just give *all* timesources in the
> synchronization line, that choice isn't fixed by some random kernel
> configuration or setting.

One risk is that the messages might get lost. For example, they might be
filtered by loglevel or during a flood of messages on slow consoles.


> Instead, this seems to have a completely broken "pick one time source
> model at random" approach, so now different machines will have
> different models, and it will likely _break_ existing code that picks
> the timesource from the kernel dmesg, unless you just pick the local
> one.

AFAIK, local clock is not synchronous between different machines
and even CPUs on the same machine. It was used in printk() because
it was lockless. Therefore it is kind of random itself.

You could make some post-synchronization using that printed
time stamps from other clocks. But it is not reliable (lost
messages) and somehow inconvenient.

I am not super happy that userspace might need update with
the approach in this pull request. But it seems to be rather
trivial. The timestamp (number) in the log can be converted into
the date+time as following:

  + realtime: timestamp ~= number of micro sec. since 1.1.1970
  + other clocks: timestamp ~= number of micro sec. since boot


> That seems like bad design, and really stupid.
>
> Am I missing something? Because as-is, this just seems like a horribly
> bad feature to me. I'm not pulling it without some very good arguments
> for this all.

I wonder if the current approach might be acceptable if we print
some suffix after real-time or any non-local_clock timestamps.
This would allow userspace to always handle this correctly.
IMHO, it would be more reliable and convenient than the
"synchronization printks".

Best Regards,
Petr

Re: [PATCH v5 24/37] tracing: Add support for 'synthetic' events

[Namhyung Kim]

On Thu, Nov 09, 2017 at 02:33:55PM -0600, Tom Zanussi wrote:
> Synthetic events are user-defined events generated from hist trigger
> variables saved from one or more other events.
> 
> To define a synthetic event, the user writes a simple specification
> consisting of the name of the new event along with one or more
> variables and their type(s), to the tracing/synthetic_events file.
> 
> For instance, the following creates a new event named 'wakeup_latency'
> with 3 fields: lat, pid, and prio:
> 
> # echo 'wakeup_latency u64 lat; pid_t pid; int prio' >> \
>   /sys/kernel/debug/tracing/synthetic_events
> 
> Reading the tracing/synthetic_events file lists all the
> currently-defined synthetic events, in this case the event we defined
> above:
> 
> # cat /sys/kernel/debug/tracing/synthetic_events
> wakeup_latency u64 lat; pid_t pid; int prio
> 
> At this point, the synthetic event is ready to use, and a histogram
> can be defined using it:
> 
> # echo 'hist:keys=pid,prio,lat.log2:sort=pid,lat' >> \
> /sys/kernel/debug/tracing/events/synthetic/wakeup_latency/trigger
> 
> The new event is created under the tracing/events/synthetic/ directory
> and looks and behaves just like any other event:
> 
> # ls /sys/kernel/debug/tracing/events/synthetic/wakeup_latency
>   enable  filter  format  hist  id  trigger
> 
> Although a histogram can be defined for it, nothing will happen until
> an action tracing that event via the trace_synth() function occurs.
> The trace_synth() function is very similar to all the other trace_*
> invocations spread throughout the kernel, except in this case the
> trace_ function and its corresponding tracepoint isn't statically
> generated but defined by the user at run-time.
> 
> How this can be automatically hooked up via a hist trigger 'action' is
> discussed in a subsequent patch.
> 
> Signed-off-by: Tom Zanussi 
> ---
>  kernel/trace/trace_events_hist.c | 908 
> ++-
>  1 file changed, 906 insertions(+), 2 deletions(-)
> 
> diff --git a/kernel/trace/trace_events_hist.c 
> b/kernel/trace/trace_events_hist.c
> index 3504aa8..510b10d 100644
> --- a/kernel/trace/trace_events_hist.c
> +++ b/kernel/trace/trace_events_hist.c
> @@ -20,10 +20,16 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "tracing_map.h"
>  #include "trace.h"
>  
> +#define SYNTH_SYSTEM "synthetic"
> +#define SYNTH_FIELDS_MAX 16
> +
> +#define STR_VAR_LEN_MAX  32 /* must be multiple of sizeof(u64) */
> +
>  struct hist_field;
>  
>  typedef u64 (*hist_field_fn_t) (struct hist_field *field,
> @@ -270,6 +276,26 @@ struct hist_trigger_data {
>   unsigned intn_actions;
>  };
>  
> +struct synth_field {
> + char *type;
> + char *name;
> + size_t size;
> + bool is_signed;
> + bool is_string;
> +};
> +
> +struct synth_event {
> + struct list_headlist;
> + int ref;
> + char*name;
> + struct synth_field  **fields;
> + unsigned intn_fields;
> + unsigned intn_u64;
> + struct trace_event_classclass;
> + struct trace_event_call call;
> + struct tracepoint   *tp;
> +};
> +
>  struct action_data;
>  
>  typedef void (*action_fn_t) (struct hist_trigger_data *hist_data,
> @@ -282,6 +308,803 @@ struct action_data {
>   unsigned intvar_ref_idx;
>  };
>  
> +static LIST_HEAD(synth_event_list);
> +static DEFINE_MUTEX(synth_event_mutex);
> +
> +struct synth_trace_event {
> + struct trace_entry  ent;
> + u64 fields[];
> +};
> +
> +static int synth_event_define_fields(struct trace_event_call *call)
> +{
> + struct synth_trace_event trace;
> + int offset = offsetof(typeof(trace), fields);
> + struct synth_event *event = call->data;
> + unsigned int i, size, n_u64;
> + char *name, *type;
> + bool is_signed;
> + int ret = 0;
> +
> + for (i = 0, n_u64 = 0; i < event->n_fields; i++) {
> + size = event->fields[i]->size;
> + is_signed = event->fields[i]->is_signed;
> + type = event->fields[i]->type;
> + name = event->fields[i]->name;
> + ret = trace_define_field(call, type, name, offset, size,
> +  is_signed, FILTER_OTHER);
> + if (ret)
> + break;
> +
> + if (event->fields[i]->is_string) {
> + offset += STR_VAR_LEN_MAX;
> + n_u64 += STR_VAR_LEN_MAX / sizeof(u64);

Did you use fixed size array for strings?


> + } else {
> + offset += sizeof(u64);
> + n_u64++;
> + }
> + }
> +
> + event->n_u64 = n_u64;
> +
> + retur

[PATCH] scripts: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "" in the scripts
directory.

Signed-off-by: Martin Kepplinger 
---
 scripts/dtc/checks.c| 4 +---
 scripts/dtc/data.c  | 4 +---
 scripts/dtc/dtc-lexer.l | 4 +---
 scripts/dtc/dtc-lexer.lex.c_shipped | 4 +---
 scripts/dtc/dtc-parser.y| 4 +---
 scripts/dtc/dtc.c   | 4 +---
 scripts/dtc/fdtget.c| 4 +---
 scripts/dtc/fdtput.c| 4 +---
 scripts/dtc/flattree.c  | 4 +---
 scripts/dtc/fstree.c| 4 +---
 scripts/dtc/livetree.c  | 4 +---
 scripts/dtc/srcpos.c| 4 +---
 scripts/dtc/srcpos.h| 4 +---
 scripts/dtc/treesource.c| 4 +---
 scripts/dtc/util.c  | 4 +---
 scripts/dtc/util.h  | 4 +---
 scripts/genksyms/genksyms.c | 4 ++--
 scripts/genksyms/genksyms.h | 4 ++--
 scripts/genksyms/lex.l  | 4 ++--
 scripts/genksyms/lex.lex.c_shipped  | 4 ++--
 scripts/genksyms/parse.y| 4 ++--
 scripts/selinux/mdp/mdp.c   | 3 +--
 22 files changed, 27 insertions(+), 60 deletions(-)

diff --git a/scripts/dtc/checks.c b/scripts/dtc/checks.c
index e66138449886..27dd1e0de47a 100644
--- a/scripts/dtc/checks.c
+++ b/scripts/dtc/checks.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see .
  */
 
 #include "dtc.h"
diff --git a/scripts/dtc/data.c b/scripts/dtc/data.c
index aa37a16c8891..ed6ab5817603 100644
--- a/scripts/dtc/data.c
+++ b/scripts/dtc/data.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see .
  */
 
 #include "dtc.h"
diff --git a/scripts/dtc/dtc-lexer.l b/scripts/dtc/dtc-lexer.l
index fd825ebba69c..164798e6e9ce 100644
--- a/scripts/dtc/dtc-lexer.l
+++ b/scripts/dtc/dtc-lexer.l
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see .
  */
 
 %option noyywrap nounput noinput never-interactive
diff --git a/scripts/dtc/dtc-lexer.lex.c_shipped 
b/scripts/dtc/dtc-lexer.lex.c_shipped
index 011bb9632ff2..fd5b12a283be 100644
--- a/scripts/dtc/dtc-lexer.lex.c_shipped
+++ b/scripts/dtc/dtc-lexer.lex.c_shipped
@@ -618,9 +618,7 @@ char *yytext;
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see .
  */
 #define YY_NO_INPUT 1
 
diff --git a/scripts/dtc/dtc-parser.y b/scripts/dtc/dtc-parser.y
index affc81a8f9ab..e3a3b155ace8 100644
--- a/scripts/dtc/dtc-parser.y
+++ b/scripts/dtc/dtc-parser.y
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA  02111-1307
- *   USA
+ *  along with this program.  If not, see .
  */
 %{
 #include 
diff --git a/scripts/dtc/dtc.c b/scripts/dtc/dtc.c
index 5ed873c72ad1..da967e7a8050 100644
--- a/scripts/dtc/dtc.c
+++ b/scripts/dtc/dtc.c
@@ -13,9 +13,7 @@
  *  General Public License for more details.
  *
  *  You should have received a copy of the GNU General Public License
- *  along with this program; if not, write to the Free Software
- *  Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA

Re: [PATCH] lib: test module for find_*_bit() functions

[Yury Norov]

Hi Alexey, Andrew,

Thanks for comments.

On Fri, Nov 10, 2017 at 12:45:18PM +0200, Alexey Dobriyan wrote:
> On 11/10/17, Andrew Morton  wrote:
> > On Thu,  9 Nov 2017 17:07:14 +0300 Yury Norov 
> > wrote:
> >
> >> find_bit functions are widely used in the kernel, including hot paths.
> >> This module tests performance of that functions in 2 typical scenarios:
> >> randomly filled bitmap with relatively equal distribution of set and
> >> cleared bits, and sparse bitmap which has 1 set bit for 500 cleared bits.
> >>
> >> ...
> >>
> >> +config TEST_FIND_BIT
> >
> > Well.  It doesn't actually "test" the code.  It measures its performance ;)
> 
> Yes!
> 
> Yyra, you can grab CONFIG_BENCHMARK_* namespace :-)
 
There's no CONFIG_BENCHMARK_* namespace actually. The 'CONFIG_*_BENCHMARK' is
referenced only 3 times in linux sources - CONFIG_RING_BUFFER_BENCHMARK,
CONFIG_TRACEPOINT_BENCHMARK and CONFIG_GUP_BENCHMARK, so I simply didn't know
about it. Some other tests like lib/rbtree_test.c also measure performance and
use TEST namespace, but if you think it's better, I don't object to change it.
 
> Another thing:
> 
> > +
> > +   return 0;
> > +}
> > +module_init(find_bit_test);
> > +
> > +static void __exit test_find_bit_cleanup(void)
> > +{
> > +}
> > +module_exit(test_find_bit_cleanup);
> 
> module exit hook is entirely unnecessary as you can return -E from init hook.
> See lib/test-kstrtox.c

Ack. 

I thought to send v3, but the patch is already in next tree, so I'll
send fix in separated patch. OK?

Yury

[PATCH] security: replace FSF address with web source in license notices

[Martin Kepplinger]

A few years ago the FSF moved and "59 Temple Place" is wrong. Having this
still in our source files feels old and unmaintained.

Let's take the license statement serious and not confuse users.

As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace the
postal address with "" in the security
directory.

Signed-off-by: Martin Kepplinger 
---
 security/selinux/include/netlabel.h | 3 +--
 security/selinux/netlabel.c | 3 +--
 2 files changed, 2 insertions(+), 4 deletions(-)

diff --git a/security/selinux/include/netlabel.h 
b/security/selinux/include/netlabel.h
index 75686d53df07..e77a5e307955 100644
--- a/security/selinux/include/netlabel.h
+++ b/security/selinux/include/netlabel.h
@@ -19,8 +19,7 @@
  * the GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program;  if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  *
  */
 
diff --git a/security/selinux/netlabel.c b/security/selinux/netlabel.c
index aaba6677ee2e..2c297b995b16 100644
--- a/security/selinux/netlabel.c
+++ b/security/selinux/netlabel.c
@@ -22,8 +22,7 @@
  * the GNU General Public License for more details.
  *
  * You should have received a copy of the GNU General Public License
- * along with this program;  if not, write to the Free Software
- * Foundation, Inc., 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA
+ * along with this program.  If not, see .
  *
  */
 
-- 
2.11.0

Re: Coccinelle: badzero.cocci failure

[Masahiro Yamada]

Hi Julia,


2017-11-14 18:07 GMT+09:00 Julia Lawall :
>> coccicheck failed
>> $ cat cocci-debug.txt
>> /home/masahiro/bin/spatch -D report --no-show-diff --very-quiet
>> --cocci-file scripts/coccinelle/null/badzero.cocci --dir . -I
>> ./arch/x86/include -I ./arch/x86/include/generated -I ./include -I
>> ./arch/x86/include/uapi -I ./arch/x86/include/generated/uapi -I
>> ./include/uapi -I ./include/generated/uapi --include
>> ./include/linux/kconfig.h --jobs 8 --chunksize 1
>> Fatal error: exception
>> Yes_prepare_ocamlcocci.LinkFailure("/tmp/ocaml_cocci_18c9f9.cmxs")
>
> Does your Coccinelle support OCaml?  I'm not sure what is the proper way to
> check for this, but in my coccinelle/config.log file I have
>
> FEATURE_OCAML='1'


Yes.  I also see this line in my config.log


> spatch --version gives:
>
> spatch version 1.0.6-00147-g19f9421 compiled with OCaml version 4.02.3
> Flags passed to the configure script: [none]
> Python scripting support: yes
> Syntax of regular expresssions: Str

My version output looks like follows:

$ spatch --version
spatch version 1.0.6-00345-g2ca0bef compiled with OCaml version 4.02.3
Flags passed to the configure script: --prefix=/home/masahiro
Python scripting support: yes
Syntax of regular expresssions: PCRE


> I'm not sure why it doesn't give feedback on whether OCaml scripting is
> supported.  I will check on this.
>

Thanks!


-- 
Best Regards
Masahiro Yamada

Re: [PATCH 16/35] perf annotate: Add samples into struct annotation_line

[Ravi Bangoria]

Hi Jiri,

On 11/14/2017 03:01 PM, Jiri Olsa wrote:

On Mon, Nov 13, 2017 at 09:14:38PM +0100, Jiri Olsa wrote:

On Mon, Nov 13, 2017 at 09:16:20PM +0530, Ravi Bangoria wrote:

Hi Jiri,

This patch seems to be causing segfault with "perf top --stdio".

Steps to reproduce:
1. start "perf top --stdio" in one terminal
2. run some simple workload in another terminal, let it get finished.
3. annotate function from previous workload in perf top (press 'a' followed
by 's')

Perf will crash with:

   perf: Segmentation fault
   Obtained 8 stack frames.
   ./perf(sighandler_dump_stack+0x3e) [0x4f1b6e]
   /lib64/libc.so.6(+0x36a7f) [0x7ff3aa7e4a7f]
   ./perf() [0x4a27fd]
   ./perf(symbol__annotate+0x199) [0x4a4439]
   ./perf() [0x44e32d]
   ./perf() [0x44f098]
   /lib64/libpthread.so.0(+0x736c) [0x7ff3acee836c]
   /lib64/libc.so.6(clone+0x3e) [0x7ff3aa8bee1e]

Can you please check.

hum, I'm getting following crash after resizing the terminal window:

perf: Floating point exception
Obtained 8 stack frames.
./perf(dump_stack+0x2e) [0x510c89]
./perf(sighandler_dump_stack+0x2e) [0x510d69]
/lib64/libc.so.6(+0x36a80) [0x7f9419588a80]
./perf(perf_top__header_snprintf+0x208) [0x4f42c1]
./perf() [0x453c09]
./perf() [0x454ddb]
/lib64/libpthread.so.0(+0x736d) [0x7f941bc8c36d]
/lib64/libc.so.6(clone+0x3f) [0x7f9419662e1f]
Floating point exception (core dumped)

working on fix

so my crash is caused by bogus resize code, I have it working with fix for
memory corruption happening in SIGWINCH signal handler (attached)
could you please check if that fixes the code for you?


Yes, this fixes the crash caused by resize.

But original crash I reported is still there. Issue seems to be with evsel
being NULL and we are trying to de-reference it somewhere inside
annotation_line__new().

Will try to spend more time on it.

-Ravi

[PATCH net-next v2] net: stmmac: fix LPI transitioning for dwmac4

[Niklas Cassel]

The LPI transitioning logic in stmmac_main uses
priv->tx_path_in_lpi_mode to enter/exit LPI.

However, priv->tx_path_in_lpi_mode is assigned
using the return value from host_irq_status().

So for dwmac4, priv->tx_path_in_lpi_mode was always false,
so stmmac_tx_clean() would always try to put us in eee mode,
and stmmac_xmit() would never take us out of eee mode.

To fix this, make host_irq_status() read and return the LPI
irq status also for dwmac4.

This also increments the existing LPI counters, so that
ethtool --statistics shows LPI transitions also for dwmac4.

For dwmac1000, irqs are enabled/disabled using the register
named "Interrupt Mask Register", and thus setting a bit disables
that specific irq.

For dwmac4 the matching register is named "MAC_Interrupt_Enable",
and thus setting a bit enables that specific irq.

Looking at dwmac1000_core.c, the irqs that are always enabled are:
LPI and PMT.

Looking at dwmac4_core.c, the irqs that are always enabled are:
PMT.

To be able to read the LPI irq status, we need to enable the LPI
irq also for dwmac4.

Signed-off-by: Niklas Cassel 
---
Changes since v1:
Fixed two typos in the commit message.

 drivers/net/ethernet/stmicro/stmmac/dwmac4.h  |  7 ++-
 drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c | 19 +++
 2 files changed, 25 insertions(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
index aeda3ab2d761..789dad8a07b5 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4.h
@@ -98,7 +98,7 @@
 #defineGMAC_PCS_IRQ_DEFAULT(GMAC_INT_RGSMIIS | GMAC_INT_PCS_LINK | 
\
 GMAC_INT_PCS_ANE)
 
-#defineGMAC_INT_DEFAULT_MASK   GMAC_INT_PMT_EN
+#defineGMAC_INT_DEFAULT_MASK   (GMAC_INT_PMT_EN | GMAC_INT_LPI_EN)
 
 enum dwmac4_irq_status {
time_stamp_irq = 0x1000,
@@ -106,6 +106,7 @@ enum dwmac4_irq_status {
mmc_tx_irq = 0x0400,
mmc_rx_irq = 0x0200,
mmc_irq = 0x0100,
+   lpi_irq = 0x0020,
pmt_irq = 0x0010,
 };
 
@@ -132,6 +133,10 @@ enum power_event {
 #define GMAC4_LPI_CTRL_STATUS_LPITXA   BIT(19) /* Enable LPI TX Automate */
 #define GMAC4_LPI_CTRL_STATUS_PLS  BIT(17) /* PHY Link Status */
 #define GMAC4_LPI_CTRL_STATUS_LPIENBIT(16) /* LPI Enable */
+#define GMAC4_LPI_CTRL_STATUS_RLPIEX   BIT(3) /* Receive LPI Exit */
+#define GMAC4_LPI_CTRL_STATUS_RLPIEN   BIT(2) /* Receive LPI Entry */
+#define GMAC4_LPI_CTRL_STATUS_TLPIEX   BIT(1) /* Transmit LPI Exit */
+#define GMAC4_LPI_CTRL_STATUS_TLPIEN   BIT(0) /* Transmit LPI Entry */
 
 /* MAC Debug bitmap */
 #define GMAC_DEBUG_TFCSTS_MASK GENMASK(18, 17)
diff --git a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c 
b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
index 2f7d7ec59962..f3ed8f7853eb 100644
--- a/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
+++ b/drivers/net/ethernet/stmicro/stmmac/dwmac4_core.c
@@ -580,6 +580,25 @@ static int dwmac4_irq_status(struct mac_device_info *hw,
x->irq_receive_pmt_irq_n++;
}
 
+   /* MAC tx/rx EEE LPI entry/exit interrupts */
+   if (intr_status & lpi_irq) {
+   /* Clear LPI interrupt by reading MAC_LPI_Control_Status */
+   u32 status = readl(ioaddr + GMAC4_LPI_CTRL_STATUS);
+
+   if (status & GMAC4_LPI_CTRL_STATUS_TLPIEN) {
+   ret |= CORE_IRQ_TX_PATH_IN_LPI_MODE;
+   x->irq_tx_path_in_lpi_mode_n++;
+   }
+   if (status & GMAC4_LPI_CTRL_STATUS_TLPIEX) {
+   ret |= CORE_IRQ_TX_PATH_EXIT_LPI_MODE;
+   x->irq_tx_path_exit_lpi_mode_n++;
+   }
+   if (status & GMAC4_LPI_CTRL_STATUS_RLPIEN)
+   x->irq_rx_path_in_lpi_mode_n++;
+   if (status & GMAC4_LPI_CTRL_STATUS_RLPIEX)
+   x->irq_rx_path_exit_lpi_mode_n++;
+   }
+
dwmac_pcs_isr(ioaddr, GMAC_PCS_BASE, intr_status, x);
if (intr_status & PCS_RGSMIIIS_IRQ)
dwmac4_phystatus(ioaddr, x);
-- 
2.14.2

Re: [patch 0/7] LICENSES: Add documentation and initial License files

[Russell King - ARM Linux]

On Sun, Nov 12, 2017 at 08:18:21PM +0100, Thomas Gleixner wrote:
> Folks!
> 
> First of all I want to apologize for the suboptimal process which brought
> this initial SPDX annotation into the kernel. We surely should have posted
> exactly this patch series first, but we were too focused on the actual
> annotation and analysis work, which took place in the last 10 months. As is
> happens often with work which occupies one on the 'technical' level
> completely, documentation is the last thing to think of.

Hi Thomas,

Thank you for doing this, this addresses many of my concerns with the
SPDX license tagging.  For the series:

Acked-by: Russell King 

As for the comment style, I'm sure that we'll eventually learn to use
the appropriate style for the file type, but I suspect it won't be
easy as it's not intuitive.

-- 
RMK's Patch system: http://www.armlinux.org.uk/developer/patches/
FTTC broadband for 0.8mile line in suburbia: sync at 8.8Mbps down 630kbps up
According to speedtest.net: 8.21Mbps down 510kbps up

Re: tipc_udp_send_msg oops in 4.4 when setting link tolerance

[Tommi Rantala]

On 13.11.2017 23:25, Jon Maloy wrote:
> Hi Tommi,
> I am not sure, but is seems like the following patch is what you need:
> commit 9b3009604b8e ("tipc: add net device to skb before UDP xmit")
> This was applied in tipc 4.5.

Found it, the missing patch is this one (9b3009604b8e does not help):

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585
Author: Richard Alpe 
Date:   Mon Feb 1 08:19:56 2016 +0100

tipc: fix link attribute propagation bug


It does not apply as-is to 4.4, so backported it, see below.
Does it look good? I can send it forward to Greg for inclusion in 4.4.


But with this patch included, I can easily reproduce the "BUG: Bad page 
state in process git" issue also in 4.4 like this:


$ tipc link set tolerance 100 link $LINKNAME
$ cd /tmp && git clone /path/to/linux-stable

I can try to debug that a bit more to see if I can figure it out.

-Tommi



From e1857e6c60355296fd1cbe6e376d8a7265c2b289 Mon Sep 17 00:00:00 2001
From: Richard Alpe 
Date: Tue, 14 Nov 2017 11:09:50 +0200
Subject: [PATCH] tipc: fix link attribute propagation bug

commit d01332f1acacc0cb43a61f4244dd2b846d4cd585 upstream.

[backported to 4.4 by Tommi Rantala]

Changing certain link attributes (link tolerance and link priority)
from the TIPC management tool is supposed to automatically take
effect at both endpoints of the affected link.

Currently the media address is not instantiated for the link and is
used uninstantiated when crafting protocol messages designated for the
peer endpoint. This means that changing a link property currently
results in the property being changed on the local machine but the
protocol message designated for the peer gets lost. Resulting in
property discrepancy between the endpoints.

In this patch we resolve this by using the media address from the
link entry and using the bearer transmit function to send it. Hence,
we can now eliminate the redundant function tipc_link_prot_xmit() and
the redundant field tipc_link::media_addr.

Fixes: 2af5ae372a4b (tipc: clean up unused code and structures)
Reviewed-by: Jon Maloy 
Reported-by: Jason Hu 
Signed-off-by: Richard Alpe 
Signed-off-by: David S. Miller 
Signed-off-by: Tommi Rantala 
---
 net/tipc/link.c | 28 ++--
 net/tipc/link.h |  1 - 

 2 files changed, 6 insertions(+), 23 deletions(-) 




diff --git a/net/tipc/link.c b/net/tipc/link.c 

index 72268eac4ec7..736fffb28ab6 100644 

--- a/net/tipc/link.c 

+++ b/net/tipc/link.c 

@@ -1084,25 +1084,6 @@ drop: 

return rc; 

 } 




-/* 

- * Send protocol message to the other endpoint. 

- */ 

-void tipc_link_proto_xmit(struct tipc_link *l, u32 msg_typ, int 
probe_msg,
- u32 gap, u32 tolerance, u32 priority) 

-{ 

-   struct sk_buff *skb = NULL; 

-   struct sk_buff_head xmitq; 

- 

-   __skb_queue_head_init(&xmitq); 

-   tipc_link_build_proto_msg(l, msg_typ, probe_msg, gap, 

- tolerance, priority, &xmitq); 

-   skb = __skb_dequeue(&xmitq); 

-   if (!skb) 

-   return; 

-   tipc_bearer_xmit_skb(l->net, l->bearer_id, skb, l->media_addr); 

-   l->rcv_unacked = 0; 

-} 

- 

 static void tipc_link_build_proto_msg(struct tipc_link *l, int mtyp, 
bool probe,
  u16 rcvgap, int tolerance, int 
priority,
  struct sk_buff_head *xmitq) 

@@ -1636,9 +1617,12 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)
char *name; 


struct tipc_link *link;
struct tipc_node *node;
+   struct sk_buff_head xmitq;
struct nlattr *attrs[TIPC_NLA_LINK_MAX + 1];
struct net *net = sock_net(skb->sk);

+   __skb_queue_head_init(&xmitq);
+
if (!info->attrs[TIPC_NLA_LINK])
return -EINVAL;

@@ -1683,14 +1667,14 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)


tol = nla_get_u32(props[TIPC_NLA_PROP_TOL]);
link->tolerance = tol;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, tol, 0);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
tol, 0, &xmitq);

}
if (props[TIPC_NLA_PROP_PRIO]) {
u32 prio;

prio = nla_get_u32(props[TIPC_NLA_PROP_PRIO]);
link->priority = prio;
-   tipc_link_proto_xmit(link, STATE_MSG, 0, 0, 0, 
prio);
+   tipc_link_build_proto_msg(link, STATE_MSG, 0, 0, 
0, prio, &xmitq);

}
if (props[TIPC_NLA_PROP_WIN]) {
u32 win;
@@ -1702,7 +1686,7 @@ int tipc_nl_link_set(struct sk_buff *skb, struct 
genl_info *info)


 out:
tipc_node_unlock(node);
-
+   tipc_bearer_xmit(net, bearer_id, &xmitq, 
&node->links[bearer_id].maddr);

return res;
 }

diff --git a/net/tipc/link.h b/net/tipc/link.h
index 66d859

Re: powerpc-linux-gnu-ld: warning: orphan section `.data.rel.ro' from `arch/powerpc/kernel/head_44x.o' being placed in section `.data.rel.ro'.

[Michael Ellerman]

Masahiro Yamada  writes:

> Hi Nicholas,
>
>
> 2017-11-11 17:45 GMT+09:00 Nicholas Piggin :
>> On Fri, 10 Nov 2017 23:41:49 +0800
>> kbuild test robot  wrote:
>>
>>> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
>>> master
>>> head:   1c9dbd4615fd751e5e0b99807a3c7c8612e28e20
>>> commit: cb87481ee89dbd6609e227afbf64900fb4e5c930 kbuild: linker script do 
>>> not match C names unless LD_DEAD_CODE_DATA_ELIMINATION is configured
>>> date:   3 months ago
>>> config: powerpc-fsp2_defconfig (attached as .config)
>>> compiler: powerpc-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
>>> reproduce:
>>> wget 
>>> https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
>>> ~/bin/make.cross
>>> chmod +x ~/bin/make.cross
>>> git checkout cb87481ee89dbd6609e227afbf64900fb4e5c930
>>> # save the attached .config to linux build tree
>>> make.cross ARCH=powerpc
>>>
>>> All warnings (new ones prefixed by >>):
>>>
>>> >> powerpc-linux-gnu-ld: warning: orphan section `.data.rel.ro' from 
>>> >> `arch/powerpc/kernel/head_44x.o' being placed in section `.data.rel.ro'.
>>> >> powerpc-linux-gnu-ld: warning: orphan section `.data.rel.ro' from 
>>> >> `arch/powerpc/kernel/head_44x.o' being placed in section `.data.rel.ro'.
>>> >> powerpc-linux-gnu-ld: warning: orphan section `.data.rel.ro' from 
>>> >> `arch/powerpc/kernel/head_44x.o' being placed in section `.data.rel.ro'.
>>
>> Okay this is not caused by the above patch, it was just hiding it.
>> This should do the trick I think:
>> --
>> powerpc/32: Add .data.rel* sections explicitly
>>
>> Match powerpc/64 and include .data.rel* input sections in the .data output
>> section explicitly.
>>
>> This should solve the warning:
>>
>> powerpc-linux-gnu-ld: warning: orphan section `.data.rel.ro' from 
>> `arch/powerpc/kernel/head_44x.o' being placed in section `.data.rel.ro'.
>>
>> Reported-by: kbuild test robot 
>> Signed-off-by: Nicholas Piggin 
>
>
> I think this will go to the PPC tree.

Yeah I can take it.

> I will not touch this patch, but
> if necessary, please feel free to add
>
> Reviewed-by: Masahiro Yamada 

Thanks.

cheers

Re: [PATCH -next] irqchip/exiu: Fix return value check in exiu_init()

[Marc Zyngier]

On Tue, Nov 14 2017 at  9:55:46 am GMT, Ard Biesheuvel 
 wrote:
> On 14 November 2017 at 06:57, Wei Yongjun  wrote:
>> In case of error, the function of_iomap() returns NULL pointer not
>> ERR_PTR(). The IS_ERR() test in the return value check should be
>> replaced with NULL test.
>>
>> Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU 
>> controller")
>> Signed-off-by: Wei Yongjun 
>> ---
>>  drivers/irqchip/irq-sni-exiu.c | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/drivers/irqchip/irq-sni-exiu.c b/drivers/irqchip/irq-sni-exiu.c
>> index 1b6e2f7..1927b2f 100644
>> --- a/drivers/irqchip/irq-sni-exiu.c
>> +++ b/drivers/irqchip/irq-sni-exiu.c
>> @@ -196,8 +196,8 @@ static int __init exiu_init(struct device_node *node,
>> }
>>
>> data->base = of_iomap(node, 0);
>> -   if (IS_ERR(data->base)) {
>> -   err = PTR_ERR(data->base);
>> +   if (!data->base) {
>> +   err = -ENODEV;
>> goto out_free;
>> }
>>
>
> I was going to blame Marc's Tegra code for this, because that is where
> I copied most of the code from, but the bug doesn't exist there, and
> so it appears to be an original work. Oops.

Ah, nice try! ;-)

> Acked-by: Ard Biesheuvel 

Applied to irqchip-4.15, thanks both.

M.
-- 
Jazz is not dead, it just smell funny.

Re: [perf_swevent_add] WARNING: CPU: 0 PID: 393 at kernel/events/core.c:7735 perf_swevent_add+0xe0/0x14f

[Jiri Olsa]

On Mon, Nov 13, 2017 at 10:47:12PM +0800, Fengguang Wu wrote:
> On Mon, Nov 13, 2017 at 03:36:05PM +0100, Jiri Olsa wrote:
> > On Sat, Nov 11, 2017 at 06:37:58PM +0800, Fengguang Wu wrote:
> > > Hello,
> > > 
> > > FYI this happens in 4.14.0-rc8, however not a new bug.
> > 
> > SNIP
> > 
> > > #!/bin/bash
> > > 
> > > kernel=$1
> > > initrd=initrd.img
> > > 
> > > wget --no-clobber 
> > > https://github.com/fengguang/reproduce-kernel-bug/raw/master/initrd.img/$initrd
> > 
> > 2017-11-13 15:34:14 ERROR 404: Not Found.
> 
> Sorry, please replace the 2 lines with
> 
>initrd=quantal-core-x86_64.cgz
> 
>wget --no-clobber 
> https://github.com/fengguang/reproduce-kernel-bug/raw/master/quantal/$initrd
> 

reproduced, thanks

jirka

Re: [PATCH] mm: replace FSF address with web source in license notices

[Martin Kepplinger]

Am 14.11.2017 11:02 schrieb Michal Hocko:

On Tue 14-11-17 10:55:35, Martin Kepplinger wrote:

Am 14.11.2017 10:49 schrieb Michal Hocko:
> On Tue 14-11-17 10:44:38, Martin Kepplinger wrote:
> > A few years ago the FSF moved and "59 Temple Place" is wrong. Having
> > this
> > still in our source files feels old and unmaintained.
> >
> > Let's take the license statement serious and not confuse users.
> >
> > As https://www.gnu.org/licenses/gpl-howto.html suggests, we replace
> > the
> > postal address with "" in the mm
> > directory.
>
> Why to change this now? Isn't there a general plan to move to SPDX?

Shouldn't a move to SPDX only be additions to what we currently have? 
That's

at least what the "reuse" project suggests, see
https://reuse.software/practices/
with "Don’t remove existing headers, but only add to them."


I thought the primary motivation was to unify _all_ headers and get rid
of all the duplication. (aside from files which do not have any license
which is under discussion elsewhere).


I doubt that this can be fully accieved in the long run :) It'd be nice 
of course in

some way.

But I also doubt that it'd be so easy to remove the permission 
statements.

The FSF who's license we use suggest to have them, but others do too.
And as mentioned, "using SPDX" doesn't imply "not having permission
statements".

But I think that's off-topic actually. Moving to SPDX could still be 
done in
any way whatsoever after this. This change fixes a *mistake* and can 
reduce

confusion or even support license compliance, who knows :)

thanks
martin

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

[Quan Xu]

On 2017/11/14 16:22, Wanpeng Li wrote:

2017-11-14 16:15 GMT+08:00 Quan Xu :


On 2017/11/14 15:12, Wanpeng Li wrote:

2017-11-14 15:02 GMT+08:00 Quan Xu :


On 2017/11/13 18:53, Juergen Gross wrote:

On 13/11/17 11:06, Quan Xu wrote:

From: Quan Xu 

So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
in idle path which will poll for a while before we enter the real idle
state.

In virtualization, idle path includes several heavy operations
includes timer access(LAPIC timer or TSC deadline timer) which will
hurt performance especially for latency intensive workload like message
passing task. The cost is mainly from the vmexit which is a hardware
context switch between virtual machine and hypervisor. Our solution is
to poll for a while and do not enter real idle path if we can get the
schedule event during polling.

Poll may cause the CPU waste so we adopt a smart polling mechanism to
reduce the useless poll.

Signed-off-by: Yang Zhang 
Signed-off-by: Quan Xu 
Cc: Juergen Gross 
Cc: Alok Kataria 
Cc: Rusty Russell 
Cc: Thomas Gleixner 
Cc: Ingo Molnar 
Cc: "H. Peter Anvin" 
Cc: x...@kernel.org
Cc: virtualizat...@lists.linux-foundation.org
Cc: linux-kernel@vger.kernel.org
Cc: xen-de...@lists.xenproject.org

Hmm, is the idle entry path really so critical to performance that a new
pvops function is necessary?

Juergen, Here is the data we get when running benchmark netperf:
   1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
  29031.6 bit/s -- 76.1 %CPU

   2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
  35787.7 bit/s -- 129.4 %CPU

   3. w/ kvm dynamic poll:
  35735.6 bit/s -- 200.0 %CPU

Actually we can reduce the CPU utilization by sleeping a period of
time as what has already been done in the poll logic of IO subsystem,
then we can improve the algorithm in kvm instead of introduing another
duplicate one in the kvm guest.

We really appreciate upstream's kvm dynamic poll mechanism, which is
really helpful for a lot of scenario..

However, as description said, in virtualization, idle path includes
several heavy operations includes timer access (LAPIC timer or TSC
deadline timer) which will hurt performance especially for latency
intensive workload like message passing task. The cost is mainly from
the vmexit which is a hardware context switch between virtual machine
and hypervisor.

for upstream's kvm dynamic poll mechanism, even you could provide a
better algorism, how could you bypass timer access (LAPIC timer or TSC
deadline timer), or a hardware context switch between virtual machine
and hypervisor. I know these is a tradeoff.

Furthermore, here is the data we get when running benchmark contextswitch
to measure the latency(lower is better):

1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
   3402.9 ns/ctxsw -- 199.8 %CPU

2. w/ patch and disable kvm dynamic poll:
   1163.5 ns/ctxsw -- 205.5 %CPU

3. w/ kvm dynamic poll:
   2280.6 ns/ctxsw -- 199.5 %CPU

so, these tow solution are quite similar, but not duplicate..

that's also why to add a generic idle poll before enter real idle path.
When a reschedule event is pending, we can bypass the real idle path.


There is a similar logic in the idle governor/driver, so how this
patchset influence the decision in the idle governor/driver when
running on bare-metal(power managment is not exposed to the guest so
we will not enter into idle driver in the guest)?



This is expected to take effect only when running as a virtual machine with
proper CONFIG_* enabled. This can not work on bare mental even with proper
CONFIG_* enabled.

Quan
Alibaba Cloud

[tip:timers/urgent] clocksource/timer_of: Rename timer_of_exit to timer_of_cleanup

[tip-bot for Benjamin Gaignard]

Commit-ID:  558de28249508dc3ec0ec8981d1315eb8b63f0d9
Gitweb: https://git.kernel.org/tip/558de28249508dc3ec0ec8981d1315eb8b63f0d9
Author: Benjamin Gaignard 
AuthorDate: Tue, 14 Nov 2017 09:52:38 +0100
Committer:  Thomas Gleixner 
CommitDate: Tue, 14 Nov 2017 11:20:24 +0100

clocksource/timer_of: Rename timer_of_exit to timer_of_cleanup

Change the function name to something more explicit since it is only used
in init error cases.

Add __init annotation and description about the function usage.

Signed-off-by: Benjamin Gaignard 
Signed-off-by: Thomas Gleixner 
Cc: mark.rutl...@arm.com
Cc: devicet...@vger.kernel.org
Cc: alexandre.tor...@st.com
Cc: a...@arndb.de
Cc: julien.thie...@arm.com
Cc: daniel.lezc...@linaro.org
Cc: li...@armlinux.org.uk
Cc: robh...@kernel.org
Cc: linux-arm-ker...@lists.infradead.org
Cc: mcoquelin.st...@gmail.com
Cc: sudeep.ho...@arm.com
Cc: ludovic.ba...@st.com
Link: 
https://lkml.kernel.org/r/1510649563-22975-2-git-send-email-benjamin.gaign...@linaro.org

---
 drivers/clocksource/timer-of.c | 9 -
 drivers/clocksource/timer-of.h | 2 +-
 2 files changed, 9 insertions(+), 2 deletions(-)

diff --git a/drivers/clocksource/timer-of.c b/drivers/clocksource/timer-of.c
index 7c64a5c1..a319904 100644
--- a/drivers/clocksource/timer-of.c
+++ b/drivers/clocksource/timer-of.c
@@ -177,7 +177,14 @@ out_fail:
return ret;
 }
 
-void timer_of_exit(struct timer_of *to)
+/**
+ * timer_of_cleanup - release timer_of ressources
+ * @to: timer_of structure
+ *
+ * Release the ressources that has been used in timer_of_init().
+ * This function should be called in init error cases
+ */
+void __init timer_of_cleanup(struct timer_of *to)
 {
if (to->flags & TIMER_OF_IRQ)
timer_irq_exit(&to->of_irq);
diff --git a/drivers/clocksource/timer-of.h b/drivers/clocksource/timer-of.h
index 43f5ba3..3f708f1 100644
--- a/drivers/clocksource/timer-of.h
+++ b/drivers/clocksource/timer-of.h
@@ -68,6 +68,6 @@ static inline unsigned long timer_of_period(struct timer_of 
*to)
 extern int __init timer_of_init(struct device_node *np,
struct timer_of *to);
 
-extern void timer_of_exit(struct timer_of *to);
+extern void __init timer_of_cleanup(struct timer_of *to);
 
 #endif

Re: [PATCH 4/4] ARCv2: entry: Reduce perf intr return path

[Peter Zijlstra]

On Tue, Nov 07, 2017 at 02:13:04PM -0800, Vineet Gupta wrote:
> In the more likely case of returning to kernel from perf interrupt, do a
> fast path returning w/o bothering about CONFIG_PREEMPT etc

I think this needs more explaining and certainly also deserves a code
comment.

Is the argument something along these lines?

  Assumes the interrupt will never set TIF_NEED_RESCHED;
  therefore no preemption is ever required on return from
  the interrupt.

What do you (on ARC) do about irq_work ?

> +ENTRY(handle_interrupt_pct)
> +
> + INTERRUPT_PROLOGUE  irq
> +
> + IRQ_DISABLE
> +
> + lr  r0, [ICAUSE]
> +
> + bl.darch_do_IRQ
> + mov r1, sp
> +
> + ld  r0, [sp, PT_status32]   ; returning to User/Kernel Mode
> + btstr0, STATUS_U_BIT
> + bnz resume_user_mode_begin
> +
> + clri
> + b   .Lisr_ret_fast_path_to_k
> +
> +END(handle_interrupt_pct)

[tip:timers/urgent] timekeeping: Remove CONFIG_GENERIC_TIME_VSYSCALL_OLD

[tip-bot for Miroslav Lichvar]

Commit-ID:  aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Gitweb: https://git.kernel.org/tip/aea3706cfc4d952ed6d32b6d5845b5ecd99ed7f5
Author: Miroslav Lichvar 
AuthorDate: Mon, 13 Nov 2017 14:51:31 -0800
Committer:  Thomas Gleixner 
CommitDate: Tue, 14 Nov 2017 11:20:25 +0100

timekeeping: Remove CONFIG_GENERIC_TIME_VSYSCALL_OLD

As of d4d1fc61eb38f (ia64: Update fsyscall gettime to use modern
vsyscall_update)the last user of CONFIG_GENERIC_TIME_VSYSCALL_OLD
have been updated, the legacy support for old-style vsyscall
implementations can be removed from the timekeeping code.

(Thanks again to Tony Luck for helping remove the last user!)

[jstultz: Commit message rework]

Signed-off-by: Miroslav Lichvar 
Signed-off-by: John Stultz 
Signed-off-by: Thomas Gleixner 
Cc: Prarit Bhargava 
Cc: Tony Luck 
Cc: Richard Cochran 
Cc: Stephen Boyd 
Link: 
https://lkml.kernel.org/r/1510613491-16695-1-git-send-email-john.stu...@linaro.org

---
 include/linux/timekeeper_internal.h |  7 --
 kernel/time/Kconfig |  4 
 kernel/time/timekeeping.c   | 45 -
 3 files changed, 56 deletions(-)

diff --git a/include/linux/timekeeper_internal.h 
b/include/linux/timekeeper_internal.h
index 7e90111..d315c3d 100644
--- a/include/linux/timekeeper_internal.h
+++ b/include/linux/timekeeper_internal.h
@@ -136,13 +136,6 @@ struct timekeeper {
 extern void update_vsyscall(struct timekeeper *tk);
 extern void update_vsyscall_tz(void);
 
-#elif defined(CONFIG_GENERIC_TIME_VSYSCALL_OLD)
-
-extern void update_vsyscall_old(struct timespec *ts, struct timespec *wtm,
-   struct clocksource *c, u32 mult,
-   u64 cycle_last);
-extern void update_vsyscall_tz(void);
-
 #else
 
 static inline void update_vsyscall(struct timekeeper *tk)
diff --git a/kernel/time/Kconfig b/kernel/time/Kconfig
index d689a95..e776fc8 100644
--- a/kernel/time/Kconfig
+++ b/kernel/time/Kconfig
@@ -21,10 +21,6 @@ config CLOCKSOURCE_VALIDATE_LAST_CYCLE
 config GENERIC_TIME_VSYSCALL
bool
 
-# Timekeeping vsyscall support
-config GENERIC_TIME_VSYSCALL_OLD
-   bool
-
 # Old style timekeeping
 config ARCH_USES_GETTIMEOFFSET
bool
diff --git a/kernel/time/timekeeping.c b/kernel/time/timekeeping.c
index 198afa7..cd03317 100644
--- a/kernel/time/timekeeping.c
+++ b/kernel/time/timekeeping.c
@@ -557,45 +557,6 @@ static void halt_fast_timekeeper(struct timekeeper *tk)
update_fast_timekeeper(&tkr_dummy, &tk_fast_raw);
 }
 
-#ifdef CONFIG_GENERIC_TIME_VSYSCALL_OLD
-#warning Please contact your maintainers, as GENERIC_TIME_VSYSCALL_OLD 
compatibity will disappear soon.
-
-static inline void update_vsyscall(struct timekeeper *tk)
-{
-   struct timespec xt, wm;
-
-   xt = timespec64_to_timespec(tk_xtime(tk));
-   wm = timespec64_to_timespec(tk->wall_to_monotonic);
-   update_vsyscall_old(&xt, &wm, tk->tkr_mono.clock, tk->tkr_mono.mult,
-   tk->tkr_mono.cycle_last);
-}
-
-static inline void old_vsyscall_fixup(struct timekeeper *tk)
-{
-   s64 remainder;
-
-   /*
-   * Store only full nanoseconds into xtime_nsec after rounding
-   * it up and add the remainder to the error difference.
-   * XXX - This is necessary to avoid small 1ns inconsistnecies caused
-   * by truncating the remainder in vsyscalls. However, it causes
-   * additional work to be done in timekeeping_adjust(). Once
-   * the vsyscall implementations are converted to use xtime_nsec
-   * (shifted nanoseconds), and CONFIG_GENERIC_TIME_VSYSCALL_OLD
-   * users are removed, this can be killed.
-   */
-   remainder = tk->tkr_mono.xtime_nsec & ((1ULL << tk->tkr_mono.shift) - 
1);
-   if (remainder != 0) {
-   tk->tkr_mono.xtime_nsec -= remainder;
-   tk->tkr_mono.xtime_nsec += 1ULL << tk->tkr_mono.shift;
-   tk->ntp_error += remainder << tk->ntp_error_shift;
-   tk->ntp_error -= (1ULL << tk->tkr_mono.shift) << 
tk->ntp_error_shift;
-   }
-}
-#else
-#define old_vsyscall_fixup(tk)
-#endif
-
 static RAW_NOTIFIER_HEAD(pvclock_gtod_chain);
 
 static void update_pvclock_gtod(struct timekeeper *tk, bool was_set)
@@ -2164,12 +2125,6 @@ void update_wall_time(void)
timekeeping_adjust(tk, offset);
 
/*
-* XXX This can be killed once everyone converts
-* to the new update_vsyscall.
-*/
-   old_vsyscall_fixup(tk);
-
-   /*
 * Finally, make sure that after the rounding
 * xtime_nsec isn't larger than NSEC_PER_SEC
 */

Re: [PATCH RFC v3 1/6] x86/paravirt: Add pv_idle_ops to paravirt ops

[Juergen Gross]

On 14/11/17 10:38, Quan Xu wrote:
> 
> 
> On 2017/11/14 15:30, Juergen Gross wrote:
>> On 14/11/17 08:02, Quan Xu wrote:
>>>
>>> On 2017/11/13 18:53, Juergen Gross wrote:
 On 13/11/17 11:06, Quan Xu wrote:
> From: Quan Xu 
>
> So far, pv_idle_ops.poll is the only ops for pv_idle. .poll is called
> in idle path which will poll for a while before we enter the real idle
> state.
>
> In virtualization, idle path includes several heavy operations
> includes timer access(LAPIC timer or TSC deadline timer) which will
> hurt performance especially for latency intensive workload like
> message
> passing task. The cost is mainly from the vmexit which is a hardware
> context switch between virtual machine and hypervisor. Our solution is
> to poll for a while and do not enter real idle path if we can get the
> schedule event during polling.
>
> Poll may cause the CPU waste so we adopt a smart polling mechanism to
> reduce the useless poll.
>
> Signed-off-by: Yang Zhang 
> Signed-off-by: Quan Xu 
> Cc: Juergen Gross 
> Cc: Alok Kataria 
> Cc: Rusty Russell 
> Cc: Thomas Gleixner 
> Cc: Ingo Molnar 
> Cc: "H. Peter Anvin" 
> Cc: x...@kernel.org
> Cc: virtualizat...@lists.linux-foundation.org
> Cc: linux-kernel@vger.kernel.org
> Cc: xen-de...@lists.xenproject.org
 Hmm, is the idle entry path really so critical to performance that a
 new
 pvops function is necessary?
>>> Juergen, Here is the data we get when running benchmark netperf:
>>>   1. w/o patch and disable kvm dynamic poll (halt_poll_ns=0):
>>>  29031.6 bit/s -- 76.1 %CPU
>>>
>>>   2. w/ patch and disable kvm dynamic poll (halt_poll_ns=0):
>>>  35787.7 bit/s -- 129.4 %CPU
>>>
>>>   3. w/ kvm dynamic poll:
>>>  35735.6 bit/s -- 200.0 %CPU
>>>
>>>   4. w/patch and w/ kvm dynamic poll:
>>>  42225.3 bit/s -- 198.7 %CPU
>>>
>>>   5. idle=poll
>>>  37081.7 bit/s -- 998.1 %CPU
>>>
>>>
>>>
>>>   w/ this patch, we will improve performance by 23%.. even we could
>>> improve
>>>   performance by 45.4%, if we use w/patch and w/ kvm dynamic poll.
>>> also the
>>>   cost of CPU is much lower than 'idle=poll' case..
>> I don't question the general idea. I just think pvops isn't the best way
>> to implement it.
>>
 Wouldn't a function pointer, maybe guarded
 by a static key, be enough? A further advantage would be that this
 would
 work on other architectures, too.
>>> I assume this feature will be ported to other archs.. a new pvops makes
> 
>   sorry, a typo.. /other archs/other hypervisors/
>   it refers hypervisor like Xen, HyperV and VMware)..
> 
>>> code
>>> clean and easy to maintain. also I tried to add it into existed pvops,
>>> but it
>>> doesn't match.
>> You are aware that pvops is x86 only?
> 
> yes, I'm aware..
> 
>> I really don't see the big difference in maintainability compared to the
>> static key / function pointer variant:
>>
>> void (*guest_idle_poll_func)(void);
>> struct static_key guest_idle_poll_key __read_mostly;
>>
>> static inline void guest_idle_poll(void)
>> {
>> if (static_key_false(&guest_idle_poll_key))
>>     guest_idle_poll_func();
>> }
> 
> 
> 
> thank you for your sample code :)
> I agree there is no big difference.. I think we are discussion for two
> things:
>  1) x86 VM on different hypervisors
>  2) different archs VM on kvm hypervisor
> 
> What I want to do is x86 VM on different hypervisors, such as kvm / xen
> / hyperv ..

Why limit the solution to x86 if the more general solution isn't
harder?

As you didn't give any reason why the pvops approach is better other
than you don't care for non-x86 platforms you won't get an "Ack" from
me for this patch.

> 
>> And KVM would just need to set guest_idle_poll_func and enable the
>> static key. Works on non-x86 architectures, too.
>>
> 
> .. referred to 'pv_mmu_ops', HyperV and Xen can implement their own
> functions for 'pv_mmu_ops'.
> I think it is the same to pv_idle_ops.
> 
> with above explaination, do you still think I need to define the static
> key/function pointer variant?
> 
> btw, any interest to port it to Xen HVM guest? :)

Maybe. But this should work for Xen on ARM, too.


Juergen

Re: [PATCH v4 2/3] powerpc/modules: Don't try to restore r2 after a sibling call

[Naveen N. Rao]

Kamalesh Babulal wrote:

From: Josh Poimboeuf 

When attempting to load a livepatch module, I got the following error:

  module_64: patch_module: Expect noop after relocate, got 3c82

The error was triggered by the following code in
unregister_netdevice_queue():

  14c:   00 00 00 48 b   14c 
 14c: R_PPC64_REL24  net_set_todo
  150:   00 00 82 3c addis   r4,r2,0

GCC didn't insert a nop after the branch to net_set_todo() because it's
a sibling call, so it never returns.  The nop isn't needed after the
branch in that case.

Signed-off-by: Josh Poimboeuf 
Signed-off-by: Kamalesh Babulal 
---
 arch/powerpc/kernel/module_64.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/arch/powerpc/kernel/module_64.c b/arch/powerpc/kernel/module_64.c
index 39b01fd..9e5391f 100644
--- a/arch/powerpc/kernel/module_64.c
+++ b/arch/powerpc/kernel/module_64.c
@@ -489,6 +489,10 @@ static int restore_r2(u32 *instruction, struct module *me)
if (is_early_mcount_callsite(instruction - 1))
return 1;

+   /* Sibling calls don't return, so they don't need to restore r2 */
+   if (instruction[-1] == PPC_INST_BRANCH)
+   return 1;
+


This looks quite fragile, unless we know for sure that gcc will _always_
emit this instruction form for sibling calls with relocations.

As an alternative, does it make sense to do the following check instead?
if ((instr_is_branch_iform(insn) || instr_is_branch_bform(insn))
&& !(insn & 0x1))


- Naveen

Re: [PATCH 16/35] perf annotate: Add samples into struct annotation_line

[Jiri Olsa]

On Tue, Nov 14, 2017 at 03:45:27PM +0530, Ravi Bangoria wrote:
> Hi Jiri,
> 
> On 11/14/2017 03:01 PM, Jiri Olsa wrote:
> > On Mon, Nov 13, 2017 at 09:14:38PM +0100, Jiri Olsa wrote:
> > > On Mon, Nov 13, 2017 at 09:16:20PM +0530, Ravi Bangoria wrote:
> > > > Hi Jiri,
> > > > 
> > > > This patch seems to be causing segfault with "perf top --stdio".
> > > > 
> > > > Steps to reproduce:
> > > > 1. start "perf top --stdio" in one terminal
> > > > 2. run some simple workload in another terminal, let it get finished.
> > > > 3. annotate function from previous workload in perf top (press 'a' 
> > > > followed
> > > > by 's')
> > > > 
> > > > Perf will crash with:
> > > > 
> > > >    perf: Segmentation fault
> > > >    Obtained 8 stack frames.
> > > >    ./perf(sighandler_dump_stack+0x3e) [0x4f1b6e]
> > > >    /lib64/libc.so.6(+0x36a7f) [0x7ff3aa7e4a7f]
> > > >    ./perf() [0x4a27fd]
> > > >    ./perf(symbol__annotate+0x199) [0x4a4439]
> > > >    ./perf() [0x44e32d]
> > > >    ./perf() [0x44f098]
> > > >    /lib64/libpthread.so.0(+0x736c) [0x7ff3acee836c]
> > > >    /lib64/libc.so.6(clone+0x3e) [0x7ff3aa8bee1e]
> > > > 
> > > > Can you please check.
> > > hum, I'm getting following crash after resizing the terminal window:
> > > 
> > > perf: Floating point exception
> > > Obtained 8 stack frames.
> > > ./perf(dump_stack+0x2e) [0x510c89]
> > > ./perf(sighandler_dump_stack+0x2e) [0x510d69]
> > > /lib64/libc.so.6(+0x36a80) [0x7f9419588a80]
> > > ./perf(perf_top__header_snprintf+0x208) [0x4f42c1]
> > > ./perf() [0x453c09]
> > > ./perf() [0x454ddb]
> > > /lib64/libpthread.so.0(+0x736d) [0x7f941bc8c36d]
> > > /lib64/libc.so.6(clone+0x3f) [0x7f9419662e1f]
> > > Floating point exception (core dumped)
> > > 
> > > working on fix
> > so my crash is caused by bogus resize code, I have it working with fix for
> > memory corruption happening in SIGWINCH signal handler (attached)
> > could you please check if that fixes the code for you?
> 
> Yes, this fixes the crash caused by resize.
> 
> But original crash I reported is still there. Issue seems to be with evsel
> being NULL and we are trying to de-reference it somewhere inside
> annotation_line__new().
> 
> Will try to spend more time on it.

right, I can see it now.. we are passing NULL as evsel in
the top but does not check on that.. attached patch prevents
the crash for me, but I'll need to double check if that's
correct fix

jirka


---
diff --git a/tools/perf/util/annotate.c b/tools/perf/util/annotate.c
index 54321b947de8..07bbebfa2fe5 100644
--- a/tools/perf/util/annotate.c
+++ b/tools/perf/util/annotate.c
@@ -916,7 +916,7 @@ annotation_line__new(struct annotate_args *args, size_t 
privsize)
size_t size = privsize + sizeof(*al);
int nr = 1;
 
-   if (perf_evsel__is_group_event(evsel))
+   if (evsel && perf_evsel__is_group_event(evsel))
nr = evsel->nr_members;
 
size += sizeof(al->samples[0]) * nr;

Re: [PATCH v2] kbuild: comments correction & update on Makefile.host

[Masahiro Yamada]

Hi Cao,

2017-11-01 10:43 GMT+09:00 Cao jin :
> host-cmulti means the composite host program that is compiled/linked
> from several .c file, not .o file, because .o file could also be
> compiled from .cpp file.
>
> Bonus: update the stale comment.
> Signed-off-by: Cao jin 
> ---
>  scripts/Makefile.host | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/scripts/Makefile.host b/scripts/Makefile.host
> index 9cfd5c84d76f..8181df66d764 100644
> --- a/scripts/Makefile.host
> +++ b/scripts/Makefile.host
> @@ -25,11 +25,11 @@ host-cshlib := $(sort $(hostlibs-y) $(hostlibs-m))
>  host-cxxshlib := $(sort $(hostcxxlibs-y) $(hostcxxlibs-m))
>
>  # C code
> -# Executables compiled from a single .c file
> +# C Executables compiled from a single .c file


Is anything wrong with the current comment?


>  host-csingle   := $(foreach m,$(__hostprogs), \
> $(if $($(m)-objs)$($(m)-cxxobjs),,$(m)))
>
> -# C executables linked based on several .o files
> +# C executables compiled from several .c files, and only .c files

Your comment is even clearer, but
I think the current comment is also true, at least.

host-cmulti is liked from .o files
after each was compiled from .c


>  host-cmulti:= $(foreach m,$(__hostprogs),\
>$(if $($(m)-cxxobjs),,$(if $($(m)-objs),$(m
>
> @@ -50,7 +50,7 @@ host-cxxshobjs:= $(sort $(foreach 
> m,$(host-cxxshlib),$($(m:.so=-objs
>
>  # output directory for programs/.o files
>  # hostprogs-y := tools/build may have been specified.
> -# Retrieve also directory of .o files from prog-objs or prog-cxxobjs notation
> +# Retrieve also directory of .o files from host-cobjs and host-cxxobjs 
> notation
>  host-objdirs := $(dir $(__hostprogs) $(host-cobjs) $(host-cxxobjs))
>
>  host-objdirs := $(strip $(sort $(filter-out ./,$(host-objdirs
> --

I am removing all host-objdirs stuff.
I do not need this hunk.


-- 
Best Regards
Masahiro Yamada

[PATCH] perf mmap: Convert ACCESS_ONCE() to READ_ONCE()

[Mark Rutland]

Recently there was a treewide conversion of ACCESS_ONCE() to
{READ,WRITE}_ONCE(), but a new use was introduced concurrently by
commit:

  1695849735752d2a ("perf mmap: Move perf_mmap and methods to separate 
mmap.[ch] files")

Let's convert this over to READ_ONCE() so that we can remove the
ACCESS_ONCE() definitions in subsequent patches.

Signed-off-by: Mark Rutland 
Cc: Arnaldo Carvalho de Melo 
Cc: Ingo Molnar 
Cc: Paul E. McKenney 
Cc: Peter Zijlstra 
---
 tools/perf/util/mmap.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Hi,

Would it be possible for this to be taken as a fixup in an upcoming rc? That
way we should be able to remove the ACCESS_ONCE() definitions prior to v4.15.

Thanks,
Mark.

diff --git a/tools/perf/util/mmap.h b/tools/perf/util/mmap.h
index efd78b827b05..3a5cb5a6e94a 100644
--- a/tools/perf/util/mmap.h
+++ b/tools/perf/util/mmap.h
@@ -70,7 +70,7 @@ void perf_mmap__read_catchup(struct perf_mmap *md);
 static inline u64 perf_mmap__read_head(struct perf_mmap *mm)
 {
struct perf_event_mmap_page *pc = mm->base;
-   u64 head = ACCESS_ONCE(pc->data_head);
+   u64 head = READ_ONCE(pc->data_head);
rmb();
return head;
 }
-- 
2.11.0

Re: linux-next: error fetching the vfs-jk tree

[Stephen Rothwell]

Hi Jan,

On Tue, 14 Nov 2017 10:00:37 +0100 Jan Kara  wrote:
>
> On Tue 14-11-17 09:40:10, Stephen Rothwell wrote:
> > Fetching the vfs-jk tree
> > (git://git.kernel.org/pub/scm/linux/kernel/git/jack/linux-fs.git#vfs)
> > produces this error:
> > 
> > fatal: Couldn't find remote ref refs/heads/vfs
> > 
> > Do you want me to still fetch/merge that tree?  
> 
> Sorry, I forgot you were still fetching it. No, there's no need to fetch
> that branch anymore (it was a branch for one time work and I've deleted it
> now since it was untouched for an year or so). Thanks!

All gone now.

-- 
Cheers,
Stephen Rothwell

[tip:irq/urgent] irqchip/exiu: Fix return value check in exiu_init()

[tip-bot for Wei Yongjun]

Commit-ID:  0e54705b0e01dcaf3eb2a496bb66d5f05012056b
Gitweb: https://git.kernel.org/tip/0e54705b0e01dcaf3eb2a496bb66d5f05012056b
Author: Wei Yongjun 
AuthorDate: Tue, 14 Nov 2017 06:57:28 +
Committer:  Thomas Gleixner 
CommitDate: Tue, 14 Nov 2017 11:27:22 +0100

irqchip/exiu: Fix return value check in exiu_init()

In case of error, the function of_iomap() returns NULL pointer not
ERR_PTR().

Replace the IS_ERR() test of the return value with NULL test and return
a proper error code.

Fixes: 706cffc1b912 ("irqchip/exiu: Add support for Socionext Synquacer EXIU 
controller")
Signed-off-by: Wei Yongjun 
Signed-off-by: Thomas Gleixner 
Acked-by: Ard Biesheuvel 
Cc: Marc Zyngier 
Cc: Jason Cooper 
Link: 
https://lkml.kernel.org/r/1510642648-123574-1-git-send-email-weiyongj...@huawei.com

---
 drivers/irqchip/irq-sni-exiu.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/irqchip/irq-sni-exiu.c b/drivers/irqchip/irq-sni-exiu.c
index 1b6e2f7..1927b2f 100644
--- a/drivers/irqchip/irq-sni-exiu.c
+++ b/drivers/irqchip/irq-sni-exiu.c
@@ -196,8 +196,8 @@ static int __init exiu_init(struct device_node *node,
}
 
data->base = of_iomap(node, 0);
-   if (IS_ERR(data->base)) {
-   err = PTR_ERR(data->base);
+   if (!data->base) {
+   err = -ENODEV;
goto out_free;
}
 

Re: [patch v2 7/8] KVM: x86: add Intel PT msr RTIT_CTL read/write

[Paolo Bonzini]

On 14/11/2017 07:59, Kang, Luwei wrote:
> Will add it in next version. This is use for live migration, is that right?

Yes.

> If use XSAVES and XRSTORS for context switch.
> 1. Before  kvm_load_guest_fpu(vcpu), we need to save host RTIT_CTL, disable 
> PT and restore the value of  "vmx->pt_desc.guest.ctl" to GUEST_IA32_RTIT_CTL. 
> Is that right?

The idea is to make the MSR get/set handlers operate on an XSAVES state
separate from the guest FPU state.  RTIT_CTL in the XSAVES state is
special cased to always be zero.

Then you could do

  if (!system mode) {
if (guest RTIT_CTL.TraceEn != 0) {
  set PT in IA32_XSS
  XSAVES the host PT state
  // RTIT_CTL.TraceEn is now zero, and remains zero after XRSTORS
  XRSTORS the guest PT state
  clear PT in IA32_XSS
} else {
  save host RTIT_CTL
}
// guest RTIT_CTL.TraceEn will be loaded by vmentry
  }

on vmentry, and

  if (!system mode) {
// RTIT_CTL.TraceEn is zero here
if (guest RTIT_CTL.TraceEn != 0) {
  set PT in IA32_XSS
  // no need to XSAVES guest state, all MSR writes cause a vmexit
  XRSTORS the host PT state
  clear PT in IA32_XSS
} else if (host RTIT_CTL.TraceEn != 0) {
  restore host RTIT_CTL
}
  }

on vmexit.  It should still be cheaper than many rdmsr/wrmsr operations.

Paolo

> 2. After VM-exit (step out from kvm_x86_ops->run(vcpu)), we need to
> save the status of GUEST_IA32_RTIT_CTL . TRACEEN=0 and others MSRs are
> still in guest status. Where to enable PT if in host-guest mode. I think
> we should enable PT after vm-exit but it may cause #GP. " If XRSTORS
> would restore (or initialize) PT state and IA32_RTIT_CTL.TraceEn = 1,
> the instruction causes a general-protection exception. SDM 13.5.6". if
> enable after kvm_put_guest_fpu() I think it too late.)

RE: [v11,1/4] drivers: jtag: Add JTAG core driver

[Oleksandr Shamray]

> -Original Message-
> From: Chip Bilbrey [mailto:c...@bilbrey.org]
> Sent: Monday, November 6, 2017 12:33 AM
> To: Oleksandr Shamray 
> Cc: gre...@linuxfoundation.org; a...@arndb.de; linux-
> ker...@vger.kernel.org; linux-arm-ker...@lists.infradead.org;
> devicet...@vger.kernel.org; open...@lists.ozlabs.org; j...@jms.id.au;
> j...@resnulli.us; tklau...@distanz.ch; linux-ser...@vger.kernel.org;
> m...@shout.net; Vadim Pasternak ; system-sw-low-
> level ; robh...@kernel.org; openocd-
> devel-ow...@lists.sourceforge.net; linux-...@vger.kernel.org;
> da...@davemloft.net; mche...@kernel.org; Jiri Pirko 
> Subject: Re: [v11,1/4] drivers: jtag: Add JTAG core driver
> 
> 
> Oleksandr Shamray writes:

[..]

> I notice the single-open()-per-device lock was dropped by request in an 
> earlier
> revision of your patches, but multiple processes trying to drive a single JTAG
> master could wreak serious havoc if transactions get interleaved. Would
> something like an added JTAG_LOCKCHAIN/UNLOCKCHAIN
> ioctl() for exclusive client access be reasonable to prevent this?
> 

Yes, it dropped by recommendation of Greg KH . 

Greg, what you can suggest about it. May be better to add again 
single-open()-per-device lock with right locking way like:

>if (mutex_lock_interruptible(&jtag->open_lock)) {
>   return -ERESTARTSYS;
>}
>
>if (jtag->opened) {
>   mutex_unlock(&jtag->open_lock);
>   return -EINVAL;
>}
>
>nonseekable_open(inode, file);
>file->private_data = jtag;
>jtag->opened++;
>mutex_unlock(&jtag->open_lock);
>

Thaks.

> -Chip