Re: [PATCH] kernfs: kernfs_sop_show_path: don't return 0 after seq_dentry call

[Tejun Heo]

On Thu, May 12, 2016 at 12:29:45AM -0500, Serge E. Hallyn wrote:
> Our caller expects 0 on success, not >0.
> 
> This fixes a bug in the patch
> 
>   cgroup, kernfs: make mountinfo show properly scoped path for cgroup 
> namespaces
> 
> where /sys does not show up in mountinfo, breaking criu.
> 
> Thanks for catching this, Andrei.
> 
> Reported-by: Andrei Vagin 
> Signed-off-by: Serge Hallyn 

Applied to cgroup/for-4.6-fixes.

Thanks.

-- 
tejun

Re: [PATCH] kernfs: kernfs_sop_show_path: don't return 0 after seq_dentry call

[Tejun Heo]

On Thu, May 12, 2016 at 12:29:45AM -0500, Serge E. Hallyn wrote:
> Our caller expects 0 on success, not >0.
> 
> This fixes a bug in the patch
> 
>   cgroup, kernfs: make mountinfo show properly scoped path for cgroup 
> namespaces
> 
> where /sys does not show up in mountinfo, breaking criu.
> 
> Thanks for catching this, Andrei.
> 
> Reported-by: Andrei Vagin 
> Signed-off-by: Serge Hallyn 

Applied to cgroup/for-4.6-fixes.

Thanks.

-- 
tejun

Re: [RFC 1/3] dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701

[Yingjoe Chen]

On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote:
> From: YT Shen 
> 
> Add device tree binding documentation for the display subsystem in
> Mediatek SoC MT2701
> 
> Signed-off-by: YT Shen 
> ---
>  .../bindings/display/mediatek/mediatek,disp.txt|1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index db6e77e..53b3cc3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -40,6 +40,7 @@ Required properties (all function blocks):
>   "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
>   "mediatek,-disp-mutex" - display mutex
>   "mediatek,-disp-od"- overdrive
> + "mediatek,-disp-bls"   - backlight
>  - reg: Physical base address and length of the function block register space
>  - interrupts: The interrupt signal from the function block (required, except 
> for
>merge and split function blocks).


Hi,

This one is in conflict with "Support Mediatek Soc MT2701 disp pwm"
series Weiqing sent last week, which add disp-bls support to display pwm
driver.

Joe.C

Re: [RFC 1/3] dt-bindings: drm/mediatek: Add display binding for Mediatek SoC MT2701

[Yingjoe Chen]

On Thu, 2016-05-12 at 19:49 +0800, yt.s...@mediatek.com wrote:
> From: YT Shen 
> 
> Add device tree binding documentation for the display subsystem in
> Mediatek SoC MT2701
> 
> Signed-off-by: YT Shen 
> ---
>  .../bindings/display/mediatek/mediatek,disp.txt|1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git 
> a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt 
> b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> index db6e77e..53b3cc3 100644
> --- a/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> +++ b/Documentation/devicetree/bindings/display/mediatek/mediatek,disp.txt
> @@ -40,6 +40,7 @@ Required properties (all function blocks):
>   "mediatek,-dpi"- DPI controller, see mediatek,dpi.txt
>   "mediatek,-disp-mutex" - display mutex
>   "mediatek,-disp-od"- overdrive
> + "mediatek,-disp-bls"   - backlight
>  - reg: Physical base address and length of the function block register space
>  - interrupts: The interrupt signal from the function block (required, except 
> for
>merge and split function blocks).


Hi,

This one is in conflict with "Support Mediatek Soc MT2701 disp pwm"
series Weiqing sent last week, which add disp-bls support to display pwm
driver.

Joe.C

Aw: [PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

[Lino Sanfilippo]

Hi,

>
> MTU change and set channels operations are implemented as netvsc device
> re-creation destroying internal structures (struct net_device stays). This
> is really unfortunate but there is no support from Hyper-V host to do it
> in a different way. Such re-creation is unsurprisingly racy, Haiyang
> reported a crash when netvsc_change_mtu() is racing with
> netvsc_link_change() but I was able to identify additional races upon
> investigation. Both netvsc_set_channels() and netvsc_change_mtu() race
> against:
> 1) netvsc_link_change()
> 2) netvsc_remove()
> 3) netvsc_send()
> 

after having a look into this driver I got the impression that you are working 
around an
unfortunate implementation of the shutdown sequence in the remove function:
If you do unregister_netdev() first instead of resource cleanup then neither 
set_channels()
nor change_mtu() can race with remove(). This is since after 
unregister_netdev() returns
the netdev is not longer available from userspace and thus neither set_channels 
nor
change_mtu can be called anymore (note that all of these functions are 
protected by the 
rtnl_lock).

To avoid the race between netvsc_change_mtu()/netvsc_set_channels() and 
netvsc_link_change()
you have to stop the concerning worker thread (dwork) before you call 
netvsc_close() and
restart it once the device is up again.

Regards,
Lino

Aw: [PATCH 0/6] hv_netvsc: avoid races on mtu change/set channels

[Lino Sanfilippo]

Hi,

>
> MTU change and set channels operations are implemented as netvsc device
> re-creation destroying internal structures (struct net_device stays). This
> is really unfortunate but there is no support from Hyper-V host to do it
> in a different way. Such re-creation is unsurprisingly racy, Haiyang
> reported a crash when netvsc_change_mtu() is racing with
> netvsc_link_change() but I was able to identify additional races upon
> investigation. Both netvsc_set_channels() and netvsc_change_mtu() race
> against:
> 1) netvsc_link_change()
> 2) netvsc_remove()
> 3) netvsc_send()
> 

after having a look into this driver I got the impression that you are working 
around an
unfortunate implementation of the shutdown sequence in the remove function:
If you do unregister_netdev() first instead of resource cleanup then neither 
set_channels()
nor change_mtu() can race with remove(). This is since after 
unregister_netdev() returns
the netdev is not longer available from userspace and thus neither set_channels 
nor
change_mtu can be called anymore (note that all of these functions are 
protected by the 
rtnl_lock).

To avoid the race between netvsc_change_mtu()/netvsc_set_channels() and 
netvsc_link_change()
you have to stop the concerning worker thread (dwork) before you call 
netvsc_close() and
restart it once the device is up again.

Regards,
Lino

Re: [PATCH 3/4] ARM: dts: bcm2835: add the bcm2835-sdram-controller to the dt

[Stefan Wahren]

Hi,

> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
> 
> 
> From: Martin Sperl 
> 
> Add the bcm2835 sdram controller to the device tree.
> 
> Signed-off-by: Martin Sperl 
> ---
>  arch/arm/boot/dts/bcm283x.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index 8aaf193..9db9d97 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -22,6 +22,12 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>  
> + memory-controller@7e002000 {
> + compatible = "brcm,bcm2835-sdram";
> + reg = <0x7e002000 0x58>, <0x7e002800 0x58>;

where do you get these addresses?

According to register documentation [1] the adresses belong to the interrupt
controller.

Maybe 0x7ee0 is the right address.

[1] - https://github.com/hermanhermitage/videocoreiv/wiki/Register-Documentation

> + clocks = < BCM2835_CLOCK_SDRAM>;
> + };
> +
>   timer@7e003000 {
>   compatible = "brcm,bcm2835-system-timer";
>   reg = <0x7e003000 0x1000>;
> -- 
> 2.1.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH 3/4] ARM: dts: bcm2835: add the bcm2835-sdram-controller to the dt

[Stefan Wahren]

Hi,

> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
> 
> 
> From: Martin Sperl 
> 
> Add the bcm2835 sdram controller to the device tree.
> 
> Signed-off-by: Martin Sperl 
> ---
>  arch/arm/boot/dts/bcm283x.dtsi | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/arch/arm/boot/dts/bcm283x.dtsi b/arch/arm/boot/dts/bcm283x.dtsi
> index 8aaf193..9db9d97 100644
> --- a/arch/arm/boot/dts/bcm283x.dtsi
> +++ b/arch/arm/boot/dts/bcm283x.dtsi
> @@ -22,6 +22,12 @@
>   #address-cells = <1>;
>   #size-cells = <1>;
>  
> + memory-controller@7e002000 {
> + compatible = "brcm,bcm2835-sdram";
> + reg = <0x7e002000 0x58>, <0x7e002800 0x58>;

where do you get these addresses?

According to register documentation [1] the adresses belong to the interrupt
controller.

Maybe 0x7ee0 is the right address.

[1] - https://github.com/hermanhermitage/videocoreiv/wiki/Register-Documentation

> + clocks = < BCM2835_CLOCK_SDRAM>;
> + };
> +
>   timer@7e003000 {
>   compatible = "brcm,bcm2835-system-timer";
>   reg = <0x7e003000 0x1000>;
> -- 
> 2.1.4
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Re: [PATCH v7 2/6] GCC plugin infrastructure

[Emese Revfy]

On Wed, 11 May 2016 13:24:30 +0200
Michal Marek  wrote:

> On 2016-04-22 20:22, Emese Revfy wrote:
> > diff --git a/Documentation/dontdiff b/Documentation/dontdiff
> > index 8ea834f..5385cba 100644
> > --- a/Documentation/dontdiff
> > +++ b/Documentation/dontdiff
> > @@ -3,6 +3,7 @@
> >  *.bc
> >  *.bin
> >  *.bz2
> > +*.c.[012]*.*
> >  *.cis
> >  *.cpio
> >  *.csp
> 
> Hi Emese,
> 
> Where are these files generated? It should be added to .gitignore and
> the clean or mrproper rule if it's needed.

Hi,

Yes, they are generated by gcc options -fdump-* (if someone gives them in 
EXTRA_CFLAGS). 
I'll add these files to .gitignore and the clean rules.

-- 
Emese

Re: [PATCH v7 2/6] GCC plugin infrastructure

[Emese Revfy]

On Wed, 11 May 2016 13:24:30 +0200
Michal Marek  wrote:

> On 2016-04-22 20:22, Emese Revfy wrote:
> > diff --git a/Documentation/dontdiff b/Documentation/dontdiff
> > index 8ea834f..5385cba 100644
> > --- a/Documentation/dontdiff
> > +++ b/Documentation/dontdiff
> > @@ -3,6 +3,7 @@
> >  *.bc
> >  *.bin
> >  *.bz2
> > +*.c.[012]*.*
> >  *.cis
> >  *.cpio
> >  *.csp
> 
> Hi Emese,
> 
> Where are these files generated? It should be added to .gitignore and
> the clean or mrproper rule if it's needed.

Hi,

Yes, they are generated by gcc options -fdump-* (if someone gives them in 
EXTRA_CFLAGS). 
I'll add these files to .gitignore and the clean rules.

-- 
Emese

[PATCH 2/3] dmaengine: at_xdmac: fix residue corruption

[Ludovic Desroches]

An unexpected value of CUBC can lead to a corrupted residue. A more
complex sequence is needed to detect an inaccurate value for NCA or CUBC.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 54 ++
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index ba9b0b7..b02494e 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1400,6 +1400,7 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
u32 cur_nda, check_nda, cur_ubc, mask, value;
u8  dwidth = 0;
unsigned long   flags;
+   boolinitd;
 
ret = dma_cookie_status(chan, cookie, txstate);
if (ret == DMA_COMPLETE)
@@ -1435,34 +1436,43 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
}
 
/*
-* When processing the residue, we need to read two registers but we
-* can't do it in an atomic way. AT_XDMAC_CNDA is used to find where
-* we stand in the descriptor list and AT_XDMAC_CUBC is used
-* to know how many data are remaining for the current descriptor.
-* Since the dma channel is not paused to not loose data, between the
-* AT_XDMAC_CNDA and AT_XDMAC_CUBC read, we may have change of
-* descriptor.
-* For that reason, after reading AT_XDMAC_CUBC, we check if we are
-* still using the same descriptor by reading a second time
-* AT_XDMAC_CNDA. If AT_XDMAC_CNDA has changed, it means we have to
-* read again AT_XDMAC_CUBC.
+* The easiest way to compute the residue should be to pause the DMA
+* but doing this can lead to miss some data as some devices don't
+* have FIFO.
+* We need to read several registers because:
+* - DMA is running therefore a descriptor change is possible while
+* reading these registers
+* - When the block transfer is done, the value of the CUBC register
+* is set to its initial value until the fetch of the next descriptor.
+* This value will corrupt the residue calculation so we have to skip
+* it.
+*
+* INITD 
+*  ||
+*   ___  ___
+* NDA   @desc2 \/   @desc3
+*   ___/\___
+*   __  ___  ___
+* CUBC   0\/ MAX desc1 \/  MAX desc2
+*   __/\___/\___
+*
+* Since descriptors are aligned on 64 bits, we can assume that
+* the update of NDA and CUBC is atomic.
 * Memory barriers are used to ensure the read order of the registers.
-* A max number of retries is set because unlikely it can never ends if
-* we are transferring a lot of data with small buffers.
+* A max number of retries is set because unlikely it could never ends.
 */
-   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffc;
-   rmb();
-   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
-   rmb();
check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
0xfffc;
-
-   if (likely(cur_nda == check_nda))
-   break;
-
-   cur_nda = check_nda;
+   rmb();
+   initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
AT_XDMAC_CC_INITD);
rmb();
cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+   rmb();
+   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
0xfffc;
+   rmb();
+
+   if ((check_nda == cur_nda) && initd)
+   break;
}
 
if (unlikely(retry >= AT_XDMAC_RESIDUE_MAX_RETRIES)) {
-- 
2.5.0

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 05:34:15PM +0300, Yury Norov wrote:
> On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > > > of vector, and kernel reports successful read/write.
> > > > > > 
> > > > > > There are 2 problems:
> > > > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > > > 2. How fs successes to read/write at non-mapped, and in fact 
> > > > > > non-user
> > > > > > address.
> > > > > > 
> > > > > > I don't know the answer on 2'nd question, and it might be something
> > > > > > generic. But I investigated first problem.
> > > > > > 
> > > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() 
> > > > > > to
> > > > > > validate user address, and on arm64 it ends up with checking buffer
> > > > > > end against current_thread_info()->addr_limit.
> > > > > > 
> > > > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > > > It happens because on thread creation we call flush_old_exec() to 
> > > > > > set 
> > > > > > addr_limit, and completely ignore compat mode there.
> > > 
> > > [...]
> > > 
> > > > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > > > @@ -12,6 +12,7 @@
> > > > > >  do {   \
> > > > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > > > set_thread_flag(TIF_32BIT); \
> > > > > > +   set_fs(TASK_SIZE_32);   \
> > > > > >  } while (0)
> > > > > >  
> > > > > >  #define COMPAT_ARCH_DLINFO
> > > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > index a934fd4..a8599c6 100644
> > > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const 
> > > > > > cputime_t cputime,
> > > > > >  do {   
> > > > > > \
> > > > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > > > \
> > > > > > clear_thread_flag(TIF_32BIT);   
> > > > > > \
> > > > > > +   set_fs(TASK_SIZE_32);   
> > > > > > \
> > > > > >  } while (0)
> > > > > 
> > > > > I don't think we need these two. AFAICT, flush_old_exec() takes care 
> > > > > of
> > > > > setting the USER_DS for the new thread.
> > > > 
> > > > That's true, but USER_DS depends on personality which is not set yet
> > > > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > > > only, and it doesn't work
> > > 
> > > Ah, it looks like load_elf_binary() sets the personality after
> > > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> > > maximum 64-bit task value, so they should have a similar issue with
> > > native 32-bit vs compat behaviour.
> > 
> > I think we have another problem. flush_old_exec() calls the arm64
> > flush_thread() where tls_thread_flush() checks for is_compat_task(). So
> > starting a 32-bit application from a 64-bit one not go on the correct
> > path.
> 
> As per now, all native, aarch32 and ilp32 tasks can exec() any
> binaries they need.

And that's correct.

> Are you think it's wrong? If so, how we coild run
> first compat application (maybe shell), it there are only lp64 tasks
> on the system?

What I meant is that we rely on flush_old_exec() to initialise the TLS
register for the compat task but it currently depends on what the parent
is. I think tls_thread_flush() should actually drop the is_compat_task()
thread and always initialise all the TLS registers.

-- 
Catalin

[PATCH 3/3] dmaengine: at_xdmac: double FIFO flush needed to compute residue

[Ludovic Desroches]

Due to the way CUBC register is updated, a double flush is needed to
compute an accurate residue. First flush aim is to get data from the DMA
FIFO and second one ensures that we won't report data which are not in
memory.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index b02494e..75bd662 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1425,7 +1425,16 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
residue = desc->xfer_size;
/*
 * Flush FIFO: only relevant when the transfer is source peripheral
-* synchronized.
+* synchronized. Flush is needed before reading CUBC because data in
+* the FIFO are not reported by CUBC. Reporting a residue of the
+* transfer length while we have data in FIFO can cause issue.
+* Usecase: atmel USART has a timeout which means I have received
+* characters but there is no more character received for a while. On
+* timeout, it requests the residue. If the data are in the DMA FIFO,
+* we will return a residue of the transfer length. It means no data
+* received. If an application is waiting for these data, it will hang
+* since we won't have another USART timeout without receiving new
+* data.
 */
mask = AT_XDMAC_CC_TYPE | AT_XDMAC_CC_DSYNC;
value = AT_XDMAC_CC_TYPE_PER_TRAN | AT_XDMAC_CC_DSYNC_PER2MEM;
@@ -1481,6 +1490,19 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
}
 
/*
+* Flush FIFO: only relevant when the transfer is source peripheral
+* synchronized. Another flush is needed here because CUBC is updated
+* when the controller sends the data write command. It can lead to
+* report data that are not written in the memory or the device. The
+* FIFO flush ensures that data are really written.
+*/
+   if ((desc->lld.mbr_cfg & mask) == value) {
+   at_xdmac_write(atxdmac, AT_XDMAC_GSWF, atchan->mask);
+   while (!(at_xdmac_chan_read(atchan, AT_XDMAC_CIS) & 
AT_XDMAC_CIS_FIS))
+   cpu_relax();
+   }
+
+   /*
 * Remove size of all microblocks already transferred and the current
 * one. Then add the remaining size to transfer of the current
 * microblock.
-- 
2.5.0

[PATCH 2/3] dmaengine: at_xdmac: fix residue corruption

[Ludovic Desroches]

An unexpected value of CUBC can lead to a corrupted residue. A more
complex sequence is needed to detect an inaccurate value for NCA or CUBC.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 54 ++
 1 file changed, 32 insertions(+), 22 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index ba9b0b7..b02494e 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1400,6 +1400,7 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
u32 cur_nda, check_nda, cur_ubc, mask, value;
u8  dwidth = 0;
unsigned long   flags;
+   boolinitd;
 
ret = dma_cookie_status(chan, cookie, txstate);
if (ret == DMA_COMPLETE)
@@ -1435,34 +1436,43 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
}
 
/*
-* When processing the residue, we need to read two registers but we
-* can't do it in an atomic way. AT_XDMAC_CNDA is used to find where
-* we stand in the descriptor list and AT_XDMAC_CUBC is used
-* to know how many data are remaining for the current descriptor.
-* Since the dma channel is not paused to not loose data, between the
-* AT_XDMAC_CNDA and AT_XDMAC_CUBC read, we may have change of
-* descriptor.
-* For that reason, after reading AT_XDMAC_CUBC, we check if we are
-* still using the same descriptor by reading a second time
-* AT_XDMAC_CNDA. If AT_XDMAC_CNDA has changed, it means we have to
-* read again AT_XDMAC_CUBC.
+* The easiest way to compute the residue should be to pause the DMA
+* but doing this can lead to miss some data as some devices don't
+* have FIFO.
+* We need to read several registers because:
+* - DMA is running therefore a descriptor change is possible while
+* reading these registers
+* - When the block transfer is done, the value of the CUBC register
+* is set to its initial value until the fetch of the next descriptor.
+* This value will corrupt the residue calculation so we have to skip
+* it.
+*
+* INITD 
+*  ||
+*   ___  ___
+* NDA   @desc2 \/   @desc3
+*   ___/\___
+*   __  ___  ___
+* CUBC   0\/ MAX desc1 \/  MAX desc2
+*   __/\___/\___
+*
+* Since descriptors are aligned on 64 bits, we can assume that
+* the update of NDA and CUBC is atomic.
 * Memory barriers are used to ensure the read order of the registers.
-* A max number of retries is set because unlikely it can never ends if
-* we are transferring a lot of data with small buffers.
+* A max number of retries is set because unlikely it could never ends.
 */
-   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 0xfffc;
-   rmb();
-   cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
for (retry = 0; retry < AT_XDMAC_RESIDUE_MAX_RETRIES; retry++) {
-   rmb();
check_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
0xfffc;
-
-   if (likely(cur_nda == check_nda))
-   break;
-
-   cur_nda = check_nda;
+   rmb();
+   initd = !!(at_xdmac_chan_read(atchan, AT_XDMAC_CC) & 
AT_XDMAC_CC_INITD);
rmb();
cur_ubc = at_xdmac_chan_read(atchan, AT_XDMAC_CUBC);
+   rmb();
+   cur_nda = at_xdmac_chan_read(atchan, AT_XDMAC_CNDA) & 
0xfffc;
+   rmb();
+
+   if ((check_nda == cur_nda) && initd)
+   break;
}
 
if (unlikely(retry >= AT_XDMAC_RESIDUE_MAX_RETRIES)) {
-- 
2.5.0

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 05:34:15PM +0300, Yury Norov wrote:
> On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > > > of vector, and kernel reports successful read/write.
> > > > > > 
> > > > > > There are 2 problems:
> > > > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > > > 2. How fs successes to read/write at non-mapped, and in fact 
> > > > > > non-user
> > > > > > address.
> > > > > > 
> > > > > > I don't know the answer on 2'nd question, and it might be something
> > > > > > generic. But I investigated first problem.
> > > > > > 
> > > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() 
> > > > > > to
> > > > > > validate user address, and on arm64 it ends up with checking buffer
> > > > > > end against current_thread_info()->addr_limit.
> > > > > > 
> > > > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > > > It happens because on thread creation we call flush_old_exec() to 
> > > > > > set 
> > > > > > addr_limit, and completely ignore compat mode there.
> > > 
> > > [...]
> > > 
> > > > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > > > @@ -12,6 +12,7 @@
> > > > > >  do {   \
> > > > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > > > set_thread_flag(TIF_32BIT); \
> > > > > > +   set_fs(TASK_SIZE_32);   \
> > > > > >  } while (0)
> > > > > >  
> > > > > >  #define COMPAT_ARCH_DLINFO
> > > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > index a934fd4..a8599c6 100644
> > > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const 
> > > > > > cputime_t cputime,
> > > > > >  do {   
> > > > > > \
> > > > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > > > \
> > > > > > clear_thread_flag(TIF_32BIT);   
> > > > > > \
> > > > > > +   set_fs(TASK_SIZE_32);   
> > > > > > \
> > > > > >  } while (0)
> > > > > 
> > > > > I don't think we need these two. AFAICT, flush_old_exec() takes care 
> > > > > of
> > > > > setting the USER_DS for the new thread.
> > > > 
> > > > That's true, but USER_DS depends on personality which is not set yet
> > > > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > > > only, and it doesn't work
> > > 
> > > Ah, it looks like load_elf_binary() sets the personality after
> > > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> > > maximum 64-bit task value, so they should have a similar issue with
> > > native 32-bit vs compat behaviour.
> > 
> > I think we have another problem. flush_old_exec() calls the arm64
> > flush_thread() where tls_thread_flush() checks for is_compat_task(). So
> > starting a 32-bit application from a 64-bit one not go on the correct
> > path.
> 
> As per now, all native, aarch32 and ilp32 tasks can exec() any
> binaries they need.

And that's correct.

> Are you think it's wrong? If so, how we coild run
> first compat application (maybe shell), it there are only lp64 tasks
> on the system?

What I meant is that we rely on flush_old_exec() to initialise the TLS
register for the compat task but it currently depends on what the parent
is. I think tls_thread_flush() should actually drop the is_compat_task()
thread and always initialise all the TLS registers.

-- 
Catalin

[PATCH 3/3] dmaengine: at_xdmac: double FIFO flush needed to compute residue

[Ludovic Desroches]

Due to the way CUBC register is updated, a double flush is needed to
compute an accurate residue. First flush aim is to get data from the DMA
FIFO and second one ensures that we won't report data which are not in
memory.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 24 +++-
 1 file changed, 23 insertions(+), 1 deletion(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index b02494e..75bd662 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -1425,7 +1425,16 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
residue = desc->xfer_size;
/*
 * Flush FIFO: only relevant when the transfer is source peripheral
-* synchronized.
+* synchronized. Flush is needed before reading CUBC because data in
+* the FIFO are not reported by CUBC. Reporting a residue of the
+* transfer length while we have data in FIFO can cause issue.
+* Usecase: atmel USART has a timeout which means I have received
+* characters but there is no more character received for a while. On
+* timeout, it requests the residue. If the data are in the DMA FIFO,
+* we will return a residue of the transfer length. It means no data
+* received. If an application is waiting for these data, it will hang
+* since we won't have another USART timeout without receiving new
+* data.
 */
mask = AT_XDMAC_CC_TYPE | AT_XDMAC_CC_DSYNC;
value = AT_XDMAC_CC_TYPE_PER_TRAN | AT_XDMAC_CC_DSYNC_PER2MEM;
@@ -1481,6 +1490,19 @@ at_xdmac_tx_status(struct dma_chan *chan, dma_cookie_t 
cookie,
}
 
/*
+* Flush FIFO: only relevant when the transfer is source peripheral
+* synchronized. Another flush is needed here because CUBC is updated
+* when the controller sends the data write command. It can lead to
+* report data that are not written in the memory or the device. The
+* FIFO flush ensures that data are really written.
+*/
+   if ((desc->lld.mbr_cfg & mask) == value) {
+   at_xdmac_write(atxdmac, AT_XDMAC_GSWF, atchan->mask);
+   while (!(at_xdmac_chan_read(atchan, AT_XDMAC_CIS) & 
AT_XDMAC_CIS_FIS))
+   cpu_relax();
+   }
+
+   /*
 * Remove size of all microblocks already transferred and the current
 * one. Then add the remaining size to transfer of the current
 * microblock.
-- 
2.5.0

[PATCH 1/3] dmaengine: at_xdmac: align descriptors on 64 bits

[Ludovic Desroches]

Having descriptors aligned on 64 bits allows update CNDA and CUBC in an
atomic way.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 8e304b1..ba9b0b7 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -242,7 +242,7 @@ struct at_xdmac_lld {
u32 mbr_dus;/* Destination Microblock Stride 
Register */
 };
 
-
+/* 64-bit alignment needed to update CNDA and CUBC registers in an atomic way. 
*/
 struct at_xdmac_desc {
struct at_xdmac_lld lld;
enum dma_transfer_direction direction;
@@ -253,7 +253,7 @@ struct at_xdmac_desc {
unsigned intxfer_size;
struct list_headdescs_list;
struct list_headxfer_node;
-};
+} __aligned(sizeof(u64));
 
 static inline void __iomem *at_xdmac_chan_reg_base(struct at_xdmac *atxdmac, 
unsigned int chan_nb)
 {
-- 
2.5.0

[PATCH 1/3] dmaengine: at_xdmac: align descriptors on 64 bits

[Ludovic Desroches]

Having descriptors aligned on 64 bits allows update CNDA and CUBC in an
atomic way.

Signed-off-by: Ludovic Desroches 
Fixes: e1f7c9eee707 ("dmaengine: at_xdmac: creation of the atmel
eXtended DMA Controller driver")
Cc: sta...@vger.kernel.org #v4.1 and later
---
 drivers/dma/at_xdmac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/dma/at_xdmac.c b/drivers/dma/at_xdmac.c
index 8e304b1..ba9b0b7 100644
--- a/drivers/dma/at_xdmac.c
+++ b/drivers/dma/at_xdmac.c
@@ -242,7 +242,7 @@ struct at_xdmac_lld {
u32 mbr_dus;/* Destination Microblock Stride 
Register */
 };
 
-
+/* 64-bit alignment needed to update CNDA and CUBC registers in an atomic way. 
*/
 struct at_xdmac_desc {
struct at_xdmac_lld lld;
enum dma_transfer_direction direction;
@@ -253,7 +253,7 @@ struct at_xdmac_desc {
unsigned intxfer_size;
struct list_headdescs_list;
struct list_headxfer_node;
-};
+} __aligned(sizeof(u64));
 
 static inline void __iomem *at_xdmac_chan_reg_base(struct at_xdmac *atxdmac, 
unsigned int chan_nb)
 {
-- 
2.5.0

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

[Stefan Wahren]

Hi Martin,

> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
> 
> 
> From: Martin Sperl 
> 
> As the sdram clock is a critical clock to the system
> the minimal bcm2835-sdram driver claims (and enables)
> this clock and also exposes the corresponding sdram
> registers via debugfs.

sounds like this driver should fix an clock handling issue. Unfortunately this
isn't a solution in case the driver is disabled.

Does the GPU firmware handle the SDRAM controller or is it initialized by
bootcode?

Stefan

Re: [PATCH 0/4] add minimal bcm2835-sdram driver

[Stefan Wahren]

Hi Martin,

> ker...@martin.sperl.org hat am 12. Mai 2016 um 14:38 geschrieben:
> 
> 
> From: Martin Sperl 
> 
> As the sdram clock is a critical clock to the system
> the minimal bcm2835-sdram driver claims (and enables)
> this clock and also exposes the corresponding sdram
> registers via debugfs.

sounds like this driver should fix an clock handling issue. Unfortunately this
isn't a solution in case the driver is disabled.

Does the GPU firmware handle the SDRAM controller or is it initialized by
bootcode?

Stefan

Re: [PATCH v12 06/10] arm64: Treat all entry code as non-kprobe-able

[James Morse]

Hi David, Pratyush

On 27/04/16 19:53, David Long wrote:
> From: Pratyush Anand 
> 
> Entry symbols are not kprobe safe. So blacklist them for kprobing.
> 
> Signed-off-by: Pratyush Anand 

> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> index dfa1b1f..6a1292b 100644
> --- a/arch/arm64/kernel/kprobes.c
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "kprobes-arm64.h"
>  
> @@ -514,6 +515,15 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
> struct pt_regs *regs)
>   return 1;
>  }
>  
> +bool arch_within_kprobe_blacklist(unsigned long addr)
> +{
> + return  (addr >= (unsigned long)__kprobes_text_start &&
> +  addr < (unsigned long)__kprobes_text_end) ||
> + (addr >= (unsigned long)__entry_text_start &&
> +  addr < (unsigned long)__entry_text_end) ||
> +  !!search_exception_tables(addr);
> +}
> +

Looking at __kvm_hyp_vector, we don't have support for handling breakpoints at
EL2, so we should forbid kprobing these address ranges too:
__hyp_text_start -> __hyp_text_end
__hyp_idmap_text_start -> __hyp_idmap_text_end

These can probably be guarded with is_kernel_in_hyp_mode(), if this is true then
we are running with VHE where this code runs at the same exception level as the
rest of the kernel, so we can probe them. (In this case you may want to add
'eret' to aarch64_insn_is_branch() in patch 2)


Probing things in the kernel idmap sounds dangerous! Lets blacklist that too:
__idmap_text_start -> __idmap_text_end



Thanks,

James

Re: [PATCH v12 06/10] arm64: Treat all entry code as non-kprobe-able

[James Morse]

Hi David, Pratyush

On 27/04/16 19:53, David Long wrote:
> From: Pratyush Anand 
> 
> Entry symbols are not kprobe safe. So blacklist them for kprobing.
> 
> Signed-off-by: Pratyush Anand 

> diff --git a/arch/arm64/kernel/kprobes.c b/arch/arm64/kernel/kprobes.c
> index dfa1b1f..6a1292b 100644
> --- a/arch/arm64/kernel/kprobes.c
> +++ b/arch/arm64/kernel/kprobes.c
> @@ -29,6 +29,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  
>  #include "kprobes-arm64.h"
>  
> @@ -514,6 +515,15 @@ int __kprobes longjmp_break_handler(struct kprobe *p, 
> struct pt_regs *regs)
>   return 1;
>  }
>  
> +bool arch_within_kprobe_blacklist(unsigned long addr)
> +{
> + return  (addr >= (unsigned long)__kprobes_text_start &&
> +  addr < (unsigned long)__kprobes_text_end) ||
> + (addr >= (unsigned long)__entry_text_start &&
> +  addr < (unsigned long)__entry_text_end) ||
> +  !!search_exception_tables(addr);
> +}
> +

Looking at __kvm_hyp_vector, we don't have support for handling breakpoints at
EL2, so we should forbid kprobing these address ranges too:
__hyp_text_start -> __hyp_text_end
__hyp_idmap_text_start -> __hyp_idmap_text_end

These can probably be guarded with is_kernel_in_hyp_mode(), if this is true then
we are running with VHE where this code runs at the same exception level as the
rest of the kernel, so we can probe them. (In this case you may want to add
'eret' to aarch64_insn_is_branch() in patch 2)


Probing things in the kernel idmap sounds dangerous! Lets blacklist that too:
__idmap_text_start -> __idmap_text_end



Thanks,

James

[PATCH 1/2] pinctrl: stm32: fix warning

[patrice.chotard]

From: Patrice Chotard 

fix compilation warning :
drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for 
format [-Wformat-extra-args]
   speeds[speed], "speed");

Signed-off-by: Patrice Chotard 
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 1527740..249da52 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -806,21 +806,21 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
val = stm32_pconf_output_get(bank, offset);
-   seq_printf(s, "- %s - %s - %s - %s %s",
+   seq_printf(s, "- %s - %s - %s - %s speed",
   val ? "high" : "low",
   drive ? "open drain" : "push pull",
   biasing[bias],
-  speeds[speed], "speed");
+  speeds[speed]);
break;
 
/* alternate */
case 2:
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
-   seq_printf(s, "%d - %s -%s", alt,
+   seq_printf(s, "%d - %s -%s - %s speed", alt,
   drive ? "open drain" : "push pull",
   biasing[bias],
-  speeds[speed], "speed");
+  speeds[speed]);
break;
 
/* analog */
-- 
1.9.1

[PATCH 1/2] pinctrl: stm32: fix warning

[patrice.chotard]

From: Patrice Chotard 

fix compilation warning :
drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for 
format [-Wformat-extra-args]
   speeds[speed], "speed");

Signed-off-by: Patrice Chotard 
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 1527740..249da52 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -806,21 +806,21 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
val = stm32_pconf_output_get(bank, offset);
-   seq_printf(s, "- %s - %s - %s - %s %s",
+   seq_printf(s, "- %s - %s - %s - %s speed",
   val ? "high" : "low",
   drive ? "open drain" : "push pull",
   biasing[bias],
-  speeds[speed], "speed");
+  speeds[speed]);
break;
 
/* alternate */
case 2:
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
-   seq_printf(s, "%d - %s -%s", alt,
+   seq_printf(s, "%d - %s -%s - %s speed", alt,
   drive ? "open drain" : "push pull",
   biasing[bias],
-  speeds[speed], "speed");
+  speeds[speed]);
break;
 
/* analog */
-- 
1.9.1

Re: [PATCH] pinctrl: stm32: Implement .pin_config_dbg_show()

[Patrice Chotard]

On 05/12/2016 03:40 PM, Linus Walleij wrote:

On Wed, May 11, 2016 at 3:40 PM, Patrice Chotard  wrote:

On 05/10/2016 01:50 PM, Linus Walleij wrote:
Sorry i didn't pay attention, but there is a compilation warning in this
patch.

drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for
format [-Wformat-extra-args]
speeds[speed], "speed");


What do you prefer ?
  _ me to submit a v2 fixing this warning and at the same occasion include
the requested code factorization
  _ or submit additionnal patchset ?

Just send a patch on top fixing this.


Series just send

Thanks
Patrice



Yours,
Linus Walleij

Re: [PATCH] pinctrl: stm32: Implement .pin_config_dbg_show()

[Patrice Chotard]

On 05/12/2016 03:40 PM, Linus Walleij wrote:

On Wed, May 11, 2016 at 3:40 PM, Patrice Chotard  wrote:

On 05/10/2016 01:50 PM, Linus Walleij wrote:
Sorry i didn't pay attention, but there is a compilation warning in this
patch.

drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for
format [-Wformat-extra-args]
speeds[speed], "speed");


What do you prefer ?
  _ me to submit a v2 fixing this warning and at the same occasion include
the requested code factorization
  _ or submit additionnal patchset ?

Just send a patch on top fixing this.


Series just send

Thanks
Patrice



Yours,
Linus Walleij

[PATCH 2/2] pinctrl: stm32: factorize stm32_pconf_input/output_get()

[patrice.chotard]

From: Patrice Chotard 

As these 2 functions code are 95% similar, factorize them.

Signed-off-by: Patrice Chotard 
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 31 ++-
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 249da52..8b82d3e 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -661,8 +661,8 @@ static u32 stm32_pconf_get_bias(struct stm32_gpio_bank 
*bank,
return (val >> (offset * 2));
 }
 
-static bool stm32_pconf_input_get(struct stm32_gpio_bank *bank,
-   unsigned int offset)
+static bool stm32_pconf_get(struct stm32_gpio_bank *bank,
+   unsigned int offset, bool dir)
 {
unsigned long flags;
u32 val;
@@ -670,23 +670,12 @@ static bool stm32_pconf_input_get(struct stm32_gpio_bank 
*bank,
clk_enable(bank->clk);
spin_lock_irqsave(>lock, flags);
 
-   val = !!(readl_relaxed(bank->base + STM32_GPIO_IDR) & BIT(offset));
-
-   spin_unlock_irqrestore(>lock, flags);
-   clk_disable(bank->clk);
-
-   return val;
-}
-
-static bool stm32_pconf_output_get(struct stm32_gpio_bank *bank,
-   unsigned int offset)
-{
-   unsigned long flags;
-   u32 val;
-
-   clk_enable(bank->clk);
-   spin_lock_irqsave(>lock, flags);
-   val = !!(readl_relaxed(bank->base + STM32_GPIO_ODR) & BIT(offset));
+   if (dir)
+   val = !!(readl_relaxed(bank->base + STM32_GPIO_IDR) &
+BIT(offset));
+   else
+   val = !!(readl_relaxed(bank->base + STM32_GPIO_ODR) &
+BIT(offset));
 
spin_unlock_irqrestore(>lock, flags);
clk_disable(bank->clk);
@@ -795,7 +784,7 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
switch (mode) {
/* input */
case 0:
-   val = stm32_pconf_input_get(bank, offset);
+   val = stm32_pconf_get(bank, offset, true);
seq_printf(s, "- %s - %s",
   val ? "high" : "low",
   biasing[bias]);
@@ -805,7 +794,7 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
case 1:
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
-   val = stm32_pconf_output_get(bank, offset);
+   val = stm32_pconf_get(bank, offset, false);
seq_printf(s, "- %s - %s - %s - %s speed",
   val ? "high" : "low",
   drive ? "open drain" : "push pull",
-- 
1.9.1

[PATCH 2/2] pinctrl: stm32: factorize stm32_pconf_input/output_get()

[patrice.chotard]

From: Patrice Chotard 

As these 2 functions code are 95% similar, factorize them.

Signed-off-by: Patrice Chotard 
---
 drivers/pinctrl/stm32/pinctrl-stm32.c | 31 ++-
 1 file changed, 10 insertions(+), 21 deletions(-)

diff --git a/drivers/pinctrl/stm32/pinctrl-stm32.c 
b/drivers/pinctrl/stm32/pinctrl-stm32.c
index 249da52..8b82d3e 100644
--- a/drivers/pinctrl/stm32/pinctrl-stm32.c
+++ b/drivers/pinctrl/stm32/pinctrl-stm32.c
@@ -661,8 +661,8 @@ static u32 stm32_pconf_get_bias(struct stm32_gpio_bank 
*bank,
return (val >> (offset * 2));
 }
 
-static bool stm32_pconf_input_get(struct stm32_gpio_bank *bank,
-   unsigned int offset)
+static bool stm32_pconf_get(struct stm32_gpio_bank *bank,
+   unsigned int offset, bool dir)
 {
unsigned long flags;
u32 val;
@@ -670,23 +670,12 @@ static bool stm32_pconf_input_get(struct stm32_gpio_bank 
*bank,
clk_enable(bank->clk);
spin_lock_irqsave(>lock, flags);
 
-   val = !!(readl_relaxed(bank->base + STM32_GPIO_IDR) & BIT(offset));
-
-   spin_unlock_irqrestore(>lock, flags);
-   clk_disable(bank->clk);
-
-   return val;
-}
-
-static bool stm32_pconf_output_get(struct stm32_gpio_bank *bank,
-   unsigned int offset)
-{
-   unsigned long flags;
-   u32 val;
-
-   clk_enable(bank->clk);
-   spin_lock_irqsave(>lock, flags);
-   val = !!(readl_relaxed(bank->base + STM32_GPIO_ODR) & BIT(offset));
+   if (dir)
+   val = !!(readl_relaxed(bank->base + STM32_GPIO_IDR) &
+BIT(offset));
+   else
+   val = !!(readl_relaxed(bank->base + STM32_GPIO_ODR) &
+BIT(offset));
 
spin_unlock_irqrestore(>lock, flags);
clk_disable(bank->clk);
@@ -795,7 +784,7 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
switch (mode) {
/* input */
case 0:
-   val = stm32_pconf_input_get(bank, offset);
+   val = stm32_pconf_get(bank, offset, true);
seq_printf(s, "- %s - %s",
   val ? "high" : "low",
   biasing[bias]);
@@ -805,7 +794,7 @@ static void stm32_pconf_dbg_show(struct pinctrl_dev 
*pctldev,
case 1:
drive = stm32_pconf_get_driving(bank, offset);
speed = stm32_pconf_get_speed(bank, offset);
-   val = stm32_pconf_output_get(bank, offset);
+   val = stm32_pconf_get(bank, offset, false);
seq_printf(s, "- %s - %s - %s - %s speed",
   val ? "high" : "low",
   drive ? "open drain" : "push pull",
-- 
1.9.1

[PATCH 0/2] pinctrl: stm32: .pin_config_dbg_show fixes

[patrice.chotard]

From: Patrice Chotard 

Patrice Chotard (2):
  pinctrl: stm32: fix warning
  pinctrl: stm32: factorize stm32_pconf_input/output_get()

 drivers/pinctrl/stm32/pinctrl-stm32.c | 39 +--
 1 file changed, 14 insertions(+), 25 deletions(-)

-- 
1.9.1

[PATCH 0/2] pinctrl: stm32: .pin_config_dbg_show fixes

[patrice.chotard]

From: Patrice Chotard 

Patrice Chotard (2):
  pinctrl: stm32: fix warning
  pinctrl: stm32: factorize stm32_pconf_input/output_get()

 drivers/pinctrl/stm32/pinctrl-stm32.c | 39 +--
 1 file changed, 14 insertions(+), 25 deletions(-)

-- 
1.9.1

Re: next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Borislav Petkov]

On Thu, May 12, 2016 at 03:51:31PM +0200, Borislav Petkov wrote:
> On Thu, May 12, 2016 at 06:34:29AM -0700, Guenter Roeck wrote:
> > Borislav,
> > 
> > your patch 'locking/rwsem, x86: Clean up down_write()' causes various
> > crashes in x86 qemu tests.
> 
> Thanks for the report, let me take a look.
> 
> @Ingo: can you please back this one out of the lineup for the merge
> window until I've sorted out the issue?

Ok, I was able to reproduce:

BUG: unable to handle kernel NULL pointer dereference at 0015
IP: [] down_write+0x24/0x30
*pde =  
Oops: 0002 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S  W   
4.6.0-rc7-next-20160511-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
task: f4d0 ti: f4d08000 task.ti: f4d08000
EIP: 0060:[] EFLAGS: 00210282 CPU: 0
EIP is at down_write+0x24/0x30
EAX: f4d0 EBX: f4f6d600 ECX: 0001 EDX: 0001
ESI: 0168 EDI: c1c2eb68 EBP: f4d09ef4 ESP: f4d09eec
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 80050033 CR2: 0015 CR3: 01ccb000 CR4: 000406d0

We fault here:

c185e070 :
c185e070:   55  push   %ebp
c185e071:   89 e5   mov%esp,%ebp
c185e073:   e8 20 2b 00 00  call   c1860b98 
c185e078:   b9 01 00 ff ff  mov$0x0001,%ecx
c185e07d:   89 c2   mov%eax,%edx
c185e07f:   f0 0f c1 08 lock xadd %ecx,(%eax)
c185e083:   66 85 c9test   %cx,%cx
c185e086:   74 05   je c185e08d 
c185e088:   e8 f7 31 b7 ff  call   c13d1284 

c185e08d:   64 a1 48 59 cb c1   mov%fs:0xc1cb5948,%eax
c185e093:   5d  pop%ebp
c185e094:   89 42 14mov%eax,0x14(%edx)  <--- 
HERE
c185e097:   c3  ret
c185e098:   90  nop
c185e099:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi

and %edx is 1 (+ 0x14 gives the 0015 deref addr).

But edx should contain sem. The code does:

.loc 1 47 0
movl%eax, %edx  # sem, sem

lock;   xadd  %ecx,(%eax)   # tmp91, sem

call call_rwsem_down_write_failed

mov%eax,0x14(%edx)

and if something in that call clobbers %edx, boom! Now I need to think
about how to make gcc reload sem after

LOCK_CONTENDED(sem, __down_write_trylock, __down_write);

for
rwsem_set_owner(sem);

Btw, the hunk below seems to fix it. And the comment above those
{save,restore}_common_regs talk about "Save the C-clobbered registers
(%eax, %edx and %ecx)" but the only reg we're stashing is ecx.

Why aren't we stashing edx too?

Ingo, Peter?

---
diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S
index a37462a23546..02240807e97a 100644
--- a/arch/x86/lib/rwsem.S
+++ b/arch/x86/lib/rwsem.S
@@ -33,10 +33,12 @@
  * value or just clobbered..
  */
 
-#define save_common_regs \
-   pushl %ecx
+#define save_common_regs   \
+   pushl %ecx; \
+   pushl %edx
 
-#define restore_common_regs \
+#define restore_common_regs\
+   popl %edx;  \
popl %ecx
 
/* Avoid uglifying the argument copying x86-64 needs to do. */

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Borislav Petkov]

On Thu, May 12, 2016 at 03:51:31PM +0200, Borislav Petkov wrote:
> On Thu, May 12, 2016 at 06:34:29AM -0700, Guenter Roeck wrote:
> > Borislav,
> > 
> > your patch 'locking/rwsem, x86: Clean up down_write()' causes various
> > crashes in x86 qemu tests.
> 
> Thanks for the report, let me take a look.
> 
> @Ingo: can you please back this one out of the lineup for the merge
> window until I've sorted out the issue?

Ok, I was able to reproduce:

BUG: unable to handle kernel NULL pointer dereference at 0015
IP: [] down_write+0x24/0x30
*pde =  
Oops: 0002 [#1] PREEMPT SMP
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Tainted: G S  W   
4.6.0-rc7-next-20160511-yocto-standard #1
Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.7.5-20140531_083030-gandalf 04/01/2014
task: f4d0 ti: f4d08000 task.ti: f4d08000
EIP: 0060:[] EFLAGS: 00210282 CPU: 0
EIP is at down_write+0x24/0x30
EAX: f4d0 EBX: f4f6d600 ECX: 0001 EDX: 0001
ESI: 0168 EDI: c1c2eb68 EBP: f4d09ef4 ESP: f4d09eec
 DS: 007b ES: 007b FS: 00d8 GS:  SS: 0068
CR0: 80050033 CR2: 0015 CR3: 01ccb000 CR4: 000406d0

We fault here:

c185e070 :
c185e070:   55  push   %ebp
c185e071:   89 e5   mov%esp,%ebp
c185e073:   e8 20 2b 00 00  call   c1860b98 
c185e078:   b9 01 00 ff ff  mov$0x0001,%ecx
c185e07d:   89 c2   mov%eax,%edx
c185e07f:   f0 0f c1 08 lock xadd %ecx,(%eax)
c185e083:   66 85 c9test   %cx,%cx
c185e086:   74 05   je c185e08d 
c185e088:   e8 f7 31 b7 ff  call   c13d1284 

c185e08d:   64 a1 48 59 cb c1   mov%fs:0xc1cb5948,%eax
c185e093:   5d  pop%ebp
c185e094:   89 42 14mov%eax,0x14(%edx)  <--- 
HERE
c185e097:   c3  ret
c185e098:   90  nop
c185e099:   8d b4 26 00 00 00 00lea0x0(%esi,%eiz,1),%esi

and %edx is 1 (+ 0x14 gives the 0015 deref addr).

But edx should contain sem. The code does:

.loc 1 47 0
movl%eax, %edx  # sem, sem

lock;   xadd  %ecx,(%eax)   # tmp91, sem

call call_rwsem_down_write_failed

mov%eax,0x14(%edx)

and if something in that call clobbers %edx, boom! Now I need to think
about how to make gcc reload sem after

LOCK_CONTENDED(sem, __down_write_trylock, __down_write);

for
rwsem_set_owner(sem);

Btw, the hunk below seems to fix it. And the comment above those
{save,restore}_common_regs talk about "Save the C-clobbered registers
(%eax, %edx and %ecx)" but the only reg we're stashing is ecx.

Why aren't we stashing edx too?

Ingo, Peter?

---
diff --git a/arch/x86/lib/rwsem.S b/arch/x86/lib/rwsem.S
index a37462a23546..02240807e97a 100644
--- a/arch/x86/lib/rwsem.S
+++ b/arch/x86/lib/rwsem.S
@@ -33,10 +33,12 @@
  * value or just clobbered..
  */
 
-#define save_common_regs \
-   pushl %ecx
+#define save_common_regs   \
+   pushl %ecx; \
+   pushl %edx
 
-#define restore_common_regs \
+#define restore_common_regs\
+   popl %edx;  \
popl %ecx
 
/* Avoid uglifying the argument copying x86-64 needs to do. */

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: [PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Noralf Trønnes]

Den 12.05.2016 15:47, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patch.

On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:

Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.

Cc: laurent.pinch...@ideasonboard.com
Signed-off-by: Noralf Trønnes 
---

Changes since v1:
- Expand docs

  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
  include/drm/drm_fb_cma_helper.h |  3 +++
  2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
drm_device *dev, }

  /**
- * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
callback function
+ * drm_fb_cma_create_with_funcs() - helper function for the
+ *  _mode_config_funcs ->fb_create
+ *  callback function
   *
- * If your hardware has special alignment or pitch requirements these
should be
- * checked before calling this function.
+ * This can be used to set _framebuffer_funcs for drivers that need the
+ * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
* _framebuffer_funcs.
   */
-struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
-   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
*dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs)

Shouldn't the funcs argument be const ?


Yes you're right, drm_framebuffer_init() uses const.
I missed this in my previous patch as well, so I need to fix up
drm_fb_cma_alloc() and drm_fbdev_cma_create_with_funcs() as well.

Thanks.

Noralf.


Apart from that,

Acked-by: Laurent Pinchart 


  {
struct drm_fb_cma *fb_cma;
struct drm_gem_cma_object *objs[4];
@@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
}

-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
+   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
if (IS_ERR(fb_cma)) {
ret = PTR_ERR(fb_cma);
goto err_gem_object_unreference;
@@ -215,6 +219,21 @@ err_gem_object_unreference:
drm_gem_object_unreference_unlocked([i]->base);
return ERR_PTR(ret);
  }
+EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
+
+/**
+ * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
function
+ *
+ * If your hardware has special alignment or pitch requirements these
should be
+ * checked before calling this function. Use drm_fb_cma_create_with_funcs()
if
+ * you need to set _framebuffer_funcs ->dirty.
+ */
+struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
+   _fb_cma_funcs);
+}
  EXPORT_SYMBOL_GPL(drm_fb_cma_create);

  /**
diff --git a/include/drm/drm_fb_cma_helper.h
b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle);

+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
*dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs);
  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

Re: [PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Noralf Trønnes]

Den 12.05.2016 15:47, skrev Laurent Pinchart:

Hi Noralf,

Thank you for the patch.

On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:

Add drm_fb_cma_create_with_funcs() for drivers that need to set the
dirty() callback.

Cc: laurent.pinch...@ideasonboard.com
Signed-off-by: Noralf Trønnes 
---

Changes since v1:
- Expand docs

  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
  include/drm/drm_fb_cma_helper.h |  3 +++
  2 files changed, 28 insertions(+), 6 deletions(-)

diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
--- a/drivers/gpu/drm/drm_fb_cma_helper.c
+++ b/drivers/gpu/drm/drm_fb_cma_helper.c
@@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
drm_device *dev, }

  /**
- * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
callback function
+ * drm_fb_cma_create_with_funcs() - helper function for the
+ *  _mode_config_funcs ->fb_create
+ *  callback function
   *
- * If your hardware has special alignment or pitch requirements these
should be
- * checked before calling this function.
+ * This can be used to set _framebuffer_funcs for drivers that need the
+ * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
* _framebuffer_funcs.
   */
-struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
-   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
*dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs)

Shouldn't the funcs argument be const ?


Yes you're right, drm_framebuffer_init() uses const.
I missed this in my previous patch as well, so I need to fix up
drm_fb_cma_alloc() and drm_fbdev_cma_create_with_funcs() as well.

Thanks.

Noralf.


Apart from that,

Acked-by: Laurent Pinchart 


  {
struct drm_fb_cma *fb_cma;
struct drm_gem_cma_object *objs[4];
@@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
}

-   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
+   fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
if (IS_ERR(fb_cma)) {
ret = PTR_ERR(fb_cma);
goto err_gem_object_unreference;
@@ -215,6 +219,21 @@ err_gem_object_unreference:
drm_gem_object_unreference_unlocked([i]->base);
return ERR_PTR(ret);
  }
+EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
+
+/**
+ * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
function
+ *
+ * If your hardware has special alignment or pitch requirements these
should be
+ * checked before calling this function. Use drm_fb_cma_create_with_funcs()
if
+ * you need to set _framebuffer_funcs ->dirty.
+ */
+struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
+{
+   return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
+   _fb_cma_funcs);
+}
  EXPORT_SYMBOL_GPL(drm_fb_cma_create);

  /**
diff --git a/include/drm/drm_fb_cma_helper.h
b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
--- a/include/drm/drm_fb_cma_helper.h
+++ b/include/drm/drm_fb_cma_helper.h
@@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
struct drm_file *file_priv, unsigned int *handle);

+struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
*dev,
+   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
+   struct drm_framebuffer_funcs *funcs);
  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > > of vector, and kernel reports successful read/write.
> > > > > 
> > > > > There are 2 problems:
> > > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > > address.
> > > > > 
> > > > > I don't know the answer on 2'nd question, and it might be something
> > > > > generic. But I investigated first problem.
> > > > > 
> > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > > validate user address, and on arm64 it ends up with checking buffer
> > > > > end against current_thread_info()->addr_limit.
> > > > > 
> > > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > > addr_limit, and completely ignore compat mode there.
> > 
> > [...]
> > 
> > > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > > @@ -12,6 +12,7 @@
> > > > >  do { \
> > > > >   clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > >   set_thread_flag(TIF_32BIT); \
> > > > > + set_fs(TASK_SIZE_32);   \
> > > > >  } while (0)
> > > > >  
> > > > >  #define COMPAT_ARCH_DLINFO
> > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > index a934fd4..a8599c6 100644
> > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const 
> > > > > cputime_t cputime,
> > > > >  do { 
> > > > > \
> > > > >   set_thread_flag(TIF_32BIT_AARCH64); 
> > > > > \
> > > > >   clear_thread_flag(TIF_32BIT);   
> > > > > \
> > > > > + set_fs(TASK_SIZE_32);   
> > > > > \
> > > > >  } while (0)
> > > > 
> > > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > > setting the USER_DS for the new thread.
> > > 
> > > That's true, but USER_DS depends on personality which is not set yet
> > > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > > only, and it doesn't work
> > 
> > Ah, it looks like load_elf_binary() sets the personality after
> > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> > maximum 64-bit task value, so they should have a similar issue with
> > native 32-bit vs compat behaviour.
> 
> I think we have another problem. flush_old_exec() calls the arm64
> flush_thread() where tls_thread_flush() checks for is_compat_task(). So
> starting a 32-bit application from a 64-bit one not go on the correct
> path.

As per now, all native, aarch32 and ilp32 tasks can exec() any
binaries they need. Are you think it's wrong? If so, how we coild run
first compat application (maybe shell), it there are only lp64 tasks
on the system?

> 
> -- 
> Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 03:20:16PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > > of vector, and kernel reports successful read/write.
> > > > > 
> > > > > There are 2 problems:
> > > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > > address.
> > > > > 
> > > > > I don't know the answer on 2'nd question, and it might be something
> > > > > generic. But I investigated first problem.
> > > > > 
> > > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > > validate user address, and on arm64 it ends up with checking buffer
> > > > > end against current_thread_info()->addr_limit.
> > > > > 
> > > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > > addr_limit, and completely ignore compat mode there.
> > 
> > [...]
> > 
> > > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > > @@ -12,6 +12,7 @@
> > > > >  do { \
> > > > >   clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > >   set_thread_flag(TIF_32BIT); \
> > > > > + set_fs(TASK_SIZE_32);   \
> > > > >  } while (0)
> > > > >  
> > > > >  #define COMPAT_ARCH_DLINFO
> > > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > index a934fd4..a8599c6 100644
> > > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const 
> > > > > cputime_t cputime,
> > > > >  do { 
> > > > > \
> > > > >   set_thread_flag(TIF_32BIT_AARCH64); 
> > > > > \
> > > > >   clear_thread_flag(TIF_32BIT);   
> > > > > \
> > > > > + set_fs(TASK_SIZE_32);   
> > > > > \
> > > > >  } while (0)
> > > > 
> > > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > > setting the USER_DS for the new thread.
> > > 
> > > That's true, but USER_DS depends on personality which is not set yet
> > > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > > only, and it doesn't work
> > 
> > Ah, it looks like load_elf_binary() sets the personality after
> > flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> > maximum 64-bit task value, so they should have a similar issue with
> > native 32-bit vs compat behaviour.
> 
> I think we have another problem. flush_old_exec() calls the arm64
> flush_thread() where tls_thread_flush() checks for is_compat_task(). So
> starting a 32-bit application from a 64-bit one not go on the correct
> path.

As per now, all native, aarch32 and ilp32 tasks can exec() any
binaries they need. Are you think it's wrong? If so, how we coild run
first compat application (maybe shell), it there are only lp64 tasks
on the system?

> 
> -- 
> Catalin

Re: [PATCH] kvm-pr: manage illegal instructions

[Laurent Vivier]

On 12/05/2016 11:27, Alexander Graf wrote:
> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
>>
>> On 11/05/2016 13:49, Alexander Graf wrote:
>>> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
 On 11/05/2016 12:35, Alexander Graf wrote:
> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>> While writing some instruction tests for kvm-unit-tests for powerpc,
>> I've found that illegal instructions are not managed correctly with
>> kvm-pr,
>> while it is fine with kvm-hv.
>>
>> When an illegal instruction (like ".long 0") is processed by kvm-pr,
>> the kernel logs are filled with:
>>
>> Couldn't emulate instruction 0x (op 0 xop 0)
>> kvmppc_handle_exit_pr: emulation at 700 failed ()
>>
>> While the exception handler receives an interrupt for each
>> instruction
>> executed after the illegal instruction.
>>
>> Signed-off-by: Laurent Vivier 
>> ---
>> arch/powerpc/kvm/book3s_emulate.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index 2afdb9c..4ee969d 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -99,7 +99,6 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run,
>> struct kvm_vcpu *vcpu,
>>   switch (get_op(inst)) {
>> case 0:
>> -emulated = EMULATE_FAIL;
>> if ((kvmppc_get_msr(vcpu) & MSR_LE) &&
>> (inst == swab32(inst_sc))) {
>> /*
>> @@ -112,6 +111,9 @@ int kvmppc_core_emulate_op_pr(struct kvm_run
>> *run,
>> struct kvm_vcpu *vcpu,
>> kvmppc_set_gpr(vcpu, 3, EV_UNIMPLEMENTED);
>> kvmppc_set_pc(vcpu, kvmppc_get_pc(vcpu) + 4);
>> emulated = EMULATE_DONE;
>> +} else {
>> +kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> But isn't that exactly what the semantic of EMULATE_FAIL is? Fixing it
> up in book3s_emulate.c is definitely the wrong spot.
>
> So what is the problem you're trying to solve? Is the SRR0 at the
> wrong
> spot or are the log messages the problem?
 No, the problem is the host kernel logs are filled by the message and
 the execution hangs. And the host becomes unresponsiveness, even after
 the end of the tests.

 Please, try to run kvm-unit-tests (the emulator test) on a KVM-PR host,
 and check the kernel logs (dmesg), then try to ssh to the host...
>>> Ok, so the log messages are the problem. Please fix the message output
>>> then - or remove it altogether. Or if you like, create a module
>>> parameter that allows you to emit them.
>>>
>>> I personally think the best solution would be to just convert the
>>> message into a trace point.
>>>
>>> While at it, please see whether the guest can trigger similar host log
>>> output excess in other code paths.
>> The problem is not really with the log messages: they are consequence of
>> the bug I try to fix.
>>
>> What happens is once kvm_pr decodes an invalid instruction all the valid
>> following instructions trigger a Program exception to the guest (but are
>> executed correctly). It has no real consequence on big machine like
>> POWER8, except that the guest become very slow and the log files of the
>> host are filled with messages (and qemu uses 100% of the CPU). On a
>> smaller machine like a  PowerMac G5, the machine becomes simply unusable.
> 
> It's probably more related to your verbosity level of kernel messages.
> If you pass loglevel=0 (or quiet) to you kernel cmdline you won't get
> the messages printed to serial which is what's slowing you down.
> 
> The other problem sounds pretty severe, but the only thing your patch
> does any different from the current code flow would be the patch below.
> Or did I miss anything?
> 
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index 5cc2e7a..4672bc2 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -302,7 +302,11 @@ int kvmppc_emulate_instruction(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> advance = 0;
> printk(KERN_ERR "Couldn't emulate instruction
> 0x%08x "
>"(op %d xop %d)\n", inst, get_op(inst),
> get_xop(inst));
> +#ifdef CONFIG_PPC_BOOK3S
> +   kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> +#else
> kvmppc_core_queue_program(vcpu, 0);
> +#endif
> }
> }
> 

OK, that fixes the problem. Thanks. :)

Could you apply it?

Laurent

Re: [PATCH] kvm-pr: manage illegal instructions

[Laurent Vivier]

On 12/05/2016 11:27, Alexander Graf wrote:
> On 05/12/2016 11:10 AM, Laurent Vivier wrote:
>>
>> On 11/05/2016 13:49, Alexander Graf wrote:
>>> On 05/11/2016 01:14 PM, Laurent Vivier wrote:
 On 11/05/2016 12:35, Alexander Graf wrote:
> On 03/15/2016 09:18 PM, Laurent Vivier wrote:
>> While writing some instruction tests for kvm-unit-tests for powerpc,
>> I've found that illegal instructions are not managed correctly with
>> kvm-pr,
>> while it is fine with kvm-hv.
>>
>> When an illegal instruction (like ".long 0") is processed by kvm-pr,
>> the kernel logs are filled with:
>>
>> Couldn't emulate instruction 0x (op 0 xop 0)
>> kvmppc_handle_exit_pr: emulation at 700 failed ()
>>
>> While the exception handler receives an interrupt for each
>> instruction
>> executed after the illegal instruction.
>>
>> Signed-off-by: Laurent Vivier 
>> ---
>> arch/powerpc/kvm/book3s_emulate.c | 4 +++-
>> 1 file changed, 3 insertions(+), 1 deletion(-)
>>
>> diff --git a/arch/powerpc/kvm/book3s_emulate.c
>> b/arch/powerpc/kvm/book3s_emulate.c
>> index 2afdb9c..4ee969d 100644
>> --- a/arch/powerpc/kvm/book3s_emulate.c
>> +++ b/arch/powerpc/kvm/book3s_emulate.c
>> @@ -99,7 +99,6 @@ int kvmppc_core_emulate_op_pr(struct kvm_run *run,
>> struct kvm_vcpu *vcpu,
>>   switch (get_op(inst)) {
>> case 0:
>> -emulated = EMULATE_FAIL;
>> if ((kvmppc_get_msr(vcpu) & MSR_LE) &&
>> (inst == swab32(inst_sc))) {
>> /*
>> @@ -112,6 +111,9 @@ int kvmppc_core_emulate_op_pr(struct kvm_run
>> *run,
>> struct kvm_vcpu *vcpu,
>> kvmppc_set_gpr(vcpu, 3, EV_UNIMPLEMENTED);
>> kvmppc_set_pc(vcpu, kvmppc_get_pc(vcpu) + 4);
>> emulated = EMULATE_DONE;
>> +} else {
>> +kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> But isn't that exactly what the semantic of EMULATE_FAIL is? Fixing it
> up in book3s_emulate.c is definitely the wrong spot.
>
> So what is the problem you're trying to solve? Is the SRR0 at the
> wrong
> spot or are the log messages the problem?
 No, the problem is the host kernel logs are filled by the message and
 the execution hangs. And the host becomes unresponsiveness, even after
 the end of the tests.

 Please, try to run kvm-unit-tests (the emulator test) on a KVM-PR host,
 and check the kernel logs (dmesg), then try to ssh to the host...
>>> Ok, so the log messages are the problem. Please fix the message output
>>> then - or remove it altogether. Or if you like, create a module
>>> parameter that allows you to emit them.
>>>
>>> I personally think the best solution would be to just convert the
>>> message into a trace point.
>>>
>>> While at it, please see whether the guest can trigger similar host log
>>> output excess in other code paths.
>> The problem is not really with the log messages: they are consequence of
>> the bug I try to fix.
>>
>> What happens is once kvm_pr decodes an invalid instruction all the valid
>> following instructions trigger a Program exception to the guest (but are
>> executed correctly). It has no real consequence on big machine like
>> POWER8, except that the guest become very slow and the log files of the
>> host are filled with messages (and qemu uses 100% of the CPU). On a
>> smaller machine like a  PowerMac G5, the machine becomes simply unusable.
> 
> It's probably more related to your verbosity level of kernel messages.
> If you pass loglevel=0 (or quiet) to you kernel cmdline you won't get
> the messages printed to serial which is what's slowing you down.
> 
> The other problem sounds pretty severe, but the only thing your patch
> does any different from the current code flow would be the patch below.
> Or did I miss anything?
> 
> diff --git a/arch/powerpc/kvm/emulate.c b/arch/powerpc/kvm/emulate.c
> index 5cc2e7a..4672bc2 100644
> --- a/arch/powerpc/kvm/emulate.c
> +++ b/arch/powerpc/kvm/emulate.c
> @@ -302,7 +302,11 @@ int kvmppc_emulate_instruction(struct kvm_run *run,
> struct kvm_vcpu *vcpu)
> advance = 0;
> printk(KERN_ERR "Couldn't emulate instruction
> 0x%08x "
>"(op %d xop %d)\n", inst, get_op(inst),
> get_xop(inst));
> +#ifdef CONFIG_PPC_BOOK3S
> +   kvmppc_core_queue_program(vcpu, SRR1_PROGILL);
> +#else
> kvmppc_core_queue_program(vcpu, 0);
> +#endif
> }
> }
> 

OK, that fixes the problem. Thanks. :)

Could you apply it?

Laurent

Re: [PATCH] tools lib traceevent: Do not reassign parg after collapse_tree()

[Arnaldo Carvalho de Melo]

Em Thu, May 12, 2016 at 09:57:13PM +0900, Namhyung Kim escreveu:
> Hi Steve,
> 
> On Thu, May 12, 2016 at 4:09 AM, Steven Rostedt  wrote:
> >
> > At the end of process_filter(), collapse_tree() was changed to update the
> > parg parameter, but the reassignment after the call wasn't removed.
> > What happens is that the "current_op" gets modified and freed and parg
> > is assigned to the new allocated argument. But after the call to
> > collapse_tree(), parg is assigned again to the just freed "current_op",
> > and this causes the tool to crash.
> >
> > current_op must also be assigned to NULL in case of error, otherwise it
> > will cause it to be free()ed twice.
> >
> > Cc: sta...@vger.kernel.org # 3.14+
> > Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()")
> > Signed-off-by: Steven Rostedt 
 
> Acked-by: Namhyung Kim 

Thanks, applied to perf/urgent.

- Arnaldo

Re: [PATCH] tools lib traceevent: Do not reassign parg after collapse_tree()

[Arnaldo Carvalho de Melo]

Em Thu, May 12, 2016 at 09:57:13PM +0900, Namhyung Kim escreveu:
> Hi Steve,
> 
> On Thu, May 12, 2016 at 4:09 AM, Steven Rostedt  wrote:
> >
> > At the end of process_filter(), collapse_tree() was changed to update the
> > parg parameter, but the reassignment after the call wasn't removed.
> > What happens is that the "current_op" gets modified and freed and parg
> > is assigned to the new allocated argument. But after the call to
> > collapse_tree(), parg is assigned again to the just freed "current_op",
> > and this causes the tool to crash.
> >
> > current_op must also be assigned to NULL in case of error, otherwise it
> > will cause it to be free()ed twice.
> >
> > Cc: sta...@vger.kernel.org # 3.14+
> > Fixes: 42d6194d133c ("tools lib traceevent: Refactor process_filter()")
> > Signed-off-by: Steven Rostedt 
 
> Acked-by: Namhyung Kim 

Thanks, applied to perf/urgent.

- Arnaldo

[PATCH] arm64: Implement optimised IP checksum helpers

[Robin Murphy]

AArch64 is capable of 128-bit memory accesses without alignment
restrictions, which makes it both possible and highly practical to slurp
up a typical 20-byte IP header in just 2 loads. Implement our own
version of ip_fast_checksum() to take advantage of that, resulting in
considerably fewer instructions and memory accesses than the generic
version. We can also get more optimal code generation for csum_fold() by
defining it a slightly different way round from the generic version, so
throw that into the mix too.

Suggested-by: Luke Starrett 
Signed-off-by: Robin Murphy 
---

Having spent an evening poring over disassembler output, it turns out
that there's really no need to drop into asm for this, hurrah! I've
taken it for a spin on both big and little-endian, with no ill effects.

 arch/arm64/include/asm/checksum.h | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm64/include/asm/checksum.h

diff --git a/arch/arm64/include/asm/checksum.h 
b/arch/arm64/include/asm/checksum.h
new file mode 100644
index ..7e975ffce837
--- /dev/null
+++ b/arch/arm64/include/asm/checksum.h
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_CHECKSUM_H
+#define __ASM_CHECKSUM_H
+
+static inline __sum16 csum_fold(__wsum csum)
+{
+   u32 sum = (__force u32)csum;
+   sum += (sum >> 16) | (sum << 16);
+   return ~(__force __sum16)(sum >> 16);
+}
+#define csum_fold csum_fold
+
+static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
+{
+   __uint128_t tmp;
+   u64 sum;
+
+   tmp = *(const __uint128_t *)iph;
+   iph += 16;
+   ihl -= 4;
+   tmp += ((tmp >> 64) | (tmp << 64));
+   sum = tmp >> 64;
+   do {
+   sum += *(const u32 *)iph;
+   iph += 4;
+   } while (--ihl);
+
+   sum += ((sum >> 32) | (sum << 32));
+   return csum_fold(sum >> 32);
+}
+#define ip_fast_csum ip_fast_csum
+
+#include 
+
+#endif /* __ASM_CHECKSUM_H */
-- 
2.8.1.dirty

[PATCH] arm64: Implement optimised IP checksum helpers

[Robin Murphy]

AArch64 is capable of 128-bit memory accesses without alignment
restrictions, which makes it both possible and highly practical to slurp
up a typical 20-byte IP header in just 2 loads. Implement our own
version of ip_fast_checksum() to take advantage of that, resulting in
considerably fewer instructions and memory accesses than the generic
version. We can also get more optimal code generation for csum_fold() by
defining it a slightly different way round from the generic version, so
throw that into the mix too.

Suggested-by: Luke Starrett 
Signed-off-by: Robin Murphy 
---

Having spent an evening poring over disassembler output, it turns out
that there's really no need to drop into asm for this, hurrah! I've
taken it for a spin on both big and little-endian, with no ill effects.

 arch/arm64/include/asm/checksum.h | 49 +++
 1 file changed, 49 insertions(+)
 create mode 100644 arch/arm64/include/asm/checksum.h

diff --git a/arch/arm64/include/asm/checksum.h 
b/arch/arm64/include/asm/checksum.h
new file mode 100644
index ..7e975ffce837
--- /dev/null
+++ b/arch/arm64/include/asm/checksum.h
@@ -0,0 +1,49 @@
+/*
+ * Copyright (C) 2016 ARM Ltd.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License version 2 as
+ * published by the Free Software Foundation.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program.  If not, see .
+ */
+#ifndef __ASM_CHECKSUM_H
+#define __ASM_CHECKSUM_H
+
+static inline __sum16 csum_fold(__wsum csum)
+{
+   u32 sum = (__force u32)csum;
+   sum += (sum >> 16) | (sum << 16);
+   return ~(__force __sum16)(sum >> 16);
+}
+#define csum_fold csum_fold
+
+static inline __sum16 ip_fast_csum(const void *iph, unsigned int ihl)
+{
+   __uint128_t tmp;
+   u64 sum;
+
+   tmp = *(const __uint128_t *)iph;
+   iph += 16;
+   ihl -= 4;
+   tmp += ((tmp >> 64) | (tmp << 64));
+   sum = tmp >> 64;
+   do {
+   sum += *(const u32 *)iph;
+   iph += 4;
+   } while (--ihl);
+
+   sum += ((sum >> 32) | (sum << 32));
+   return csum_fold(sum >> 32);
+}
+#define ip_fast_csum ip_fast_csum
+
+#include 
+
+#endif /* __ASM_CHECKSUM_H */
-- 
2.8.1.dirty

URGENT RESPONSE NEEDED, PLEASE REPLY....

[Mr. Ragner Henderson]

Dear Friend,

Pardon me for not having the pleasure of knowing your mindset before making you 
this offer and it is utterly confidential and genuine by virtue of its nature I 
write to solicit your assistance in a funds transfer deal involving £15.2M.This 
fund has been stashed out of the excess profit made last 2years by my branch 
office of  the Co-operative Bank Plc here in United Kingdom which I am the 
manager.

I have already submitted an approved end-of-the-year report for the year 2015 
to my head office here in Manchester UK. and they will never know of this 
excess.

I have since then, placed this amount on a Non-Investment Account without a 
beneficiary. Upon your response, I will configure your name on our database as 
holder of the Non-Investment Account. I will then guide you on how to apply to 
my head office for the Account Closure/bank-to-bank remittance of the funds to 
your designated bank account.
If you concur with this proposal, I intend for you to retain 30% of the funds 
while 70% shall be for me. Kindly forward your response to me immediately to my 
private mail box: (mr.ragnerhender...@yahoo.com) thank you.

With Regards,

Mr. Ragner Henderson.

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

URGENT RESPONSE NEEDED, PLEASE REPLY....

[Mr. Ragner Henderson]

Dear Friend,

Pardon me for not having the pleasure of knowing your mindset before making you 
this offer and it is utterly confidential and genuine by virtue of its nature I 
write to solicit your assistance in a funds transfer deal involving £15.2M.This 
fund has been stashed out of the excess profit made last 2years by my branch 
office of  the Co-operative Bank Plc here in United Kingdom which I am the 
manager.

I have already submitted an approved end-of-the-year report for the year 2015 
to my head office here in Manchester UK. and they will never know of this 
excess.

I have since then, placed this amount on a Non-Investment Account without a 
beneficiary. Upon your response, I will configure your name on our database as 
holder of the Non-Investment Account. I will then guide you on how to apply to 
my head office for the Account Closure/bank-to-bank remittance of the funds to 
your designated bank account.
If you concur with this proposal, I intend for you to retain 30% of the funds 
while 70% shall be for me. Kindly forward your response to me immediately to my 
private mail box: (mr.ragnerhender...@yahoo.com) thank you.

With Regards,

Mr. Ragner Henderson.

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

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > of vector, and kernel reports successful read/write.
> > > > 
> > > > There are 2 problems:
> > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > address.
> > > > 
> > > > I don't know the answer on 2'nd question, and it might be something
> > > > generic. But I investigated first problem.
> > > > 
> > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > validate user address, and on arm64 it ends up with checking buffer
> > > > end against current_thread_info()->addr_limit.
> > > > 
> > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > addr_limit, and completely ignore compat mode there.
> 
> [...]
> 
> > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > @@ -12,6 +12,7 @@
> > > >  do {   \
> > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > set_thread_flag(TIF_32BIT); \
> > > > +   set_fs(TASK_SIZE_32);   \
> > > >  } while (0)
> > > >  
> > > >  #define COMPAT_ARCH_DLINFO
> > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > index a934fd4..a8599c6 100644
> > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > > cputime,
> > > >  do {   
> > > > \
> > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > \
> > > > clear_thread_flag(TIF_32BIT);   
> > > > \
> > > > +   set_fs(TASK_SIZE_32);   
> > > > \
> > > >  } while (0)
> > > 
> > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > setting the USER_DS for the new thread.
> > 
> > That's true, but USER_DS depends on personality which is not set yet
> > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > only, and it doesn't work
> 
> Ah, it looks like load_elf_binary() sets the personality after
> flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> maximum 64-bit task value, so they should have a similar issue with
> native 32-bit vs compat behaviour.

Hmmm. If so, it means we'd introduce generic fix. It would be removing 
set_fs() from flush_old_exec() and appending it to load_elf_binary()
after SET_PERSONALITY(). But I think it should be agreed with other
arches developers. I've sent standalone patch for aarch64 (you in CC)
so let's move discussion there.

> So what exactly is LTP complaining about? Is different error (like
> EFAULT vs EINVAL) or not getting an error at all.
 
It should be EINVAL, but it succeed. The other problem is that
following fs routines does not complain on wrong address.

> (I need to update my LTP, the preadv tests appeared in December last
> year)
> 

preadv02 was extended with this testcase in April.

> -- 
> Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > of vector, and kernel reports successful read/write.
> > > > 
> > > > There are 2 problems:
> > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > address.
> > > > 
> > > > I don't know the answer on 2'nd question, and it might be something
> > > > generic. But I investigated first problem.
> > > > 
> > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > validate user address, and on arm64 it ends up with checking buffer
> > > > end against current_thread_info()->addr_limit.
> > > > 
> > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > addr_limit, and completely ignore compat mode there.
> 
> [...]
> 
> > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > @@ -12,6 +12,7 @@
> > > >  do {   \
> > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > set_thread_flag(TIF_32BIT); \
> > > > +   set_fs(TASK_SIZE_32);   \
> > > >  } while (0)
> > > >  
> > > >  #define COMPAT_ARCH_DLINFO
> > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > index a934fd4..a8599c6 100644
> > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > > cputime,
> > > >  do {   
> > > > \
> > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > \
> > > > clear_thread_flag(TIF_32BIT);   
> > > > \
> > > > +   set_fs(TASK_SIZE_32);   
> > > > \
> > > >  } while (0)
> > > 
> > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > setting the USER_DS for the new thread.
> > 
> > That's true, but USER_DS depends on personality which is not set yet
> > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > only, and it doesn't work
> 
> Ah, it looks like load_elf_binary() sets the personality after
> flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> maximum 64-bit task value, so they should have a similar issue with
> native 32-bit vs compat behaviour.

Hmmm. If so, it means we'd introduce generic fix. It would be removing 
set_fs() from flush_old_exec() and appending it to load_elf_binary()
after SET_PERSONALITY(). But I think it should be agreed with other
arches developers. I've sent standalone patch for aarch64 (you in CC)
so let's move discussion there.

> So what exactly is LTP complaining about? Is different error (like
> EFAULT vs EINVAL) or not getting an error at all.
 
It should be EINVAL, but it succeed. The other problem is that
following fs routines does not complain on wrong address.

> (I need to update my LTP, the preadv tests appeared in December last
> year)
> 

preadv02 was extended with this testcase in April.

> -- 
> Catalin

Re: [PATCH] deb-pkg: add the shared header file for arm64

[Michal Marek]

On 2016-05-12 11:03, Huang Shijie wrote:
> The arch/arm/include/asm/opcodes.h is also used by the arm64.
> This patch copies it to the arm64 deb package.
> 
> Signed-off-by: Huang Shijie 
> ---
>  scripts/package/builddeb | 6 ++
>  1 file changed, 6 insertions(+)


Hi Huang,

this is fixed (admittedly in a more aggressive way) by 962475ac2f96
("builddeb: fix missing headers in linux-headers package") in linux-next.

Michal

Re: [PATCH] deb-pkg: add the shared header file for arm64

[Michal Marek]

On 2016-05-12 11:03, Huang Shijie wrote:
> The arch/arm/include/asm/opcodes.h is also used by the arm64.
> This patch copies it to the arm64 deb package.
> 
> Signed-off-by: Huang Shijie 
> ---
>  scripts/package/builddeb | 6 ++
>  1 file changed, 6 insertions(+)


Hi Huang,

this is fixed (admittedly in a more aggressive way) by 962475ac2f96
("builddeb: fix missing headers in linux-headers package") in linux-next.

Michal

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > of vector, and kernel reports successful read/write.
> > > > 
> > > > There are 2 problems:
> > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > address.
> > > > 
> > > > I don't know the answer on 2'nd question, and it might be something
> > > > generic. But I investigated first problem.
> > > > 
> > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > validate user address, and on arm64 it ends up with checking buffer
> > > > end against current_thread_info()->addr_limit.
> > > > 
> > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > addr_limit, and completely ignore compat mode there.
> 
> [...]
> 
> > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > @@ -12,6 +12,7 @@
> > > >  do {   \
> > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > set_thread_flag(TIF_32BIT); \
> > > > +   set_fs(TASK_SIZE_32);   \
> > > >  } while (0)
> > > >  
> > > >  #define COMPAT_ARCH_DLINFO
> > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > index a934fd4..a8599c6 100644
> > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > > cputime,
> > > >  do {   
> > > > \
> > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > \
> > > > clear_thread_flag(TIF_32BIT);   
> > > > \
> > > > +   set_fs(TASK_SIZE_32);   
> > > > \
> > > >  } while (0)
> > > 
> > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > setting the USER_DS for the new thread.
> > 
> > That's true, but USER_DS depends on personality which is not set yet
> > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > only, and it doesn't work
> 
> Ah, it looks like load_elf_binary() sets the personality after
> flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> maximum 64-bit task value, so they should have a similar issue with
> native 32-bit vs compat behaviour.

I think we have another problem. flush_old_exec() calls the arm64
flush_thread() where tls_thread_flush() checks for is_compat_task(). So
starting a 32-bit application from a 64-bit one not go on the correct
path.

-- 
Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 03:07:35PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> > On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > > of vector, and kernel reports successful read/write.
> > > > 
> > > > There are 2 problems:
> > > > 1. How kernel allows such address to be passed to fs subsystem;
> > > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > > address.
> > > > 
> > > > I don't know the answer on 2'nd question, and it might be something
> > > > generic. But I investigated first problem.
> > > > 
> > > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > > validate user address, and on arm64 it ends up with checking buffer
> > > > end against current_thread_info()->addr_limit.
> > > > 
> > > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > > It happens because on thread creation we call flush_old_exec() to set 
> > > > addr_limit, and completely ignore compat mode there.
> 
> [...]
> 
> > > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > > @@ -12,6 +12,7 @@
> > > >  do {   \
> > > > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > > > set_thread_flag(TIF_32BIT); \
> > > > +   set_fs(TASK_SIZE_32);   \
> > > >  } while (0)
> > > >  
> > > >  #define COMPAT_ARCH_DLINFO
> > > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > > index a934fd4..a8599c6 100644
> > > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > > cputime,
> > > >  do {   
> > > > \
> > > > set_thread_flag(TIF_32BIT_AARCH64); 
> > > > \
> > > > clear_thread_flag(TIF_32BIT);   
> > > > \
> > > > +   set_fs(TASK_SIZE_32);   
> > > > \
> > > >  } while (0)
> > > 
> > > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > > setting the USER_DS for the new thread.
> > 
> > That's true, but USER_DS depends on personality which is not set yet
> > for new thread, as I wrote above. In fact, I tried correct USER_DS
> > only, and it doesn't work
> 
> Ah, it looks like load_elf_binary() sets the personality after
> flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
> maximum 64-bit task value, so they should have a similar issue with
> native 32-bit vs compat behaviour.

I think we have another problem. flush_old_exec() calls the arm64
flush_thread() where tls_thread_flush() checks for is_compat_task(). So
starting a 32-bit application from a 64-bit one not go on the correct
path.

-- 
Catalin

[PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

[Benjamin Tissoires]

There is no reasons to filter out keyboard and consumer control collections
in hid-multitouch.
With the previous hid-input fix, there is now a full support of the Type
Cover and we can remove all specific bits from hid-core and hid-microsoft.

hid-multitouch will automatically set HID_QUIRK_NO_INIT_REPORTS so we can
also remove it from the list of ushbid quirks.

Signed-off-by: Benjamin Tissoires 
---

Andy, would you mind checking if this series is sufficient to enable the
TypeCover of the Surface Book?

Cheers,
Benjamin

 drivers/hid/hid-core.c  | 2 --
 drivers/hid/hid-ids.h   | 1 -
 drivers/hid/hid-microsoft.c | 2 --
 drivers/hid/hid-multitouch.c| 4 +++-
 drivers/hid/usbhid/hid-quirks.c | 1 -
 5 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8ea3a26..f055a68 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -727,7 +727,6 @@ static void hid_scan_collection(struct hid_parser *parser, 
unsigned type)
(hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
 hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
hid->group == HID_GROUP_MULTITOUCH)
hid->group = HID_GROUP_GENERIC;
@@ -1976,7 +1975,6 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3eec09a1..99e9852 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -703,7 +703,6 @@
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2  0x07e2
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
-#define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
 #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
 
 #define USB_VENDOR_ID_MOJO 0x8282
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index e924d55..cf6920b 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -288,8 +288,6 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
.driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3),
-   .driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index c741f5e..ac35731 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -835,7 +835,9 @@ static int mt_input_mapping(struct hid_device *hdev, struct 
hid_input *hi,
if (!td->mtclass.export_all_inputs &&
field->application != HID_DG_TOUCHSCREEN &&
field->application != HID_DG_PEN &&
-   field->application != HID_DG_TOUCHPAD)
+   field->application != HID_DG_TOUCHPAD &&
+   field->application != HID_GD_KEYBOARD &&
+   field->application != HID_CP_CONSUMER_CONTROL)
return -1;
 
/*
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index b4b8c6a..baf2bad 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -98,7 +98,6 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, 
HID_QUIRK_NO_INIT_REPORTS },
-   { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, 

[PATCH 2/2] HID: multitouch: enable the Surface 3 Type Cover to report multitouch data

[Benjamin Tissoires]

There is no reasons to filter out keyboard and consumer control collections
in hid-multitouch.
With the previous hid-input fix, there is now a full support of the Type
Cover and we can remove all specific bits from hid-core and hid-microsoft.

hid-multitouch will automatically set HID_QUIRK_NO_INIT_REPORTS so we can
also remove it from the list of ushbid quirks.

Signed-off-by: Benjamin Tissoires 
---

Andy, would you mind checking if this series is sufficient to enable the
TypeCover of the Surface Book?

Cheers,
Benjamin

 drivers/hid/hid-core.c  | 2 --
 drivers/hid/hid-ids.h   | 1 -
 drivers/hid/hid-microsoft.c | 2 --
 drivers/hid/hid-multitouch.c| 4 +++-
 drivers/hid/usbhid/hid-quirks.c | 1 -
 5 files changed, 3 insertions(+), 7 deletions(-)

diff --git a/drivers/hid/hid-core.c b/drivers/hid/hid-core.c
index 8ea3a26..f055a68 100644
--- a/drivers/hid/hid-core.c
+++ b/drivers/hid/hid-core.c
@@ -727,7 +727,6 @@ static void hid_scan_collection(struct hid_parser *parser, 
unsigned type)
(hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2 ||
 hid->product == USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP ||
-hid->product == USB_DEVICE_ID_MS_TYPE_COVER_3 ||
 hid->product == USB_DEVICE_ID_MS_POWER_COVER) &&
hid->group == HID_GROUP_MULTITOUCH)
hid->group = HID_GROUP_GENERIC;
@@ -1976,7 +1975,6 @@ static const struct hid_device_id 
hid_have_special_driver[] = {
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP) },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_7K) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_600) },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_DIGITAL_MEDIA_3KV1) },
diff --git a/drivers/hid/hid-ids.h b/drivers/hid/hid-ids.h
index 3eec09a1..99e9852 100644
--- a/drivers/hid/hid-ids.h
+++ b/drivers/hid/hid-ids.h
@@ -703,7 +703,6 @@
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_30x07dc
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2  0x07e2
 #define USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP 0x07dd
-#define USB_DEVICE_ID_MS_TYPE_COVER_30x07de
 #define USB_DEVICE_ID_MS_POWER_COVER 0x07da
 
 #define USB_VENDOR_ID_MOJO 0x8282
diff --git a/drivers/hid/hid-microsoft.c b/drivers/hid/hid-microsoft.c
index e924d55..cf6920b 100644
--- a/drivers/hid/hid-microsoft.c
+++ b/drivers/hid/hid-microsoft.c
@@ -288,8 +288,6 @@ static const struct hid_device_id ms_devices[] = {
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP),
.driver_data = MS_HIDINPUT },
-   { HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_TYPE_COVER_3),
-   .driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER),
.driver_data = MS_HIDINPUT },
{ HID_USB_DEVICE(USB_VENDOR_ID_MICROSOFT, 
USB_DEVICE_ID_MS_COMFORT_KEYBOARD),
diff --git a/drivers/hid/hid-multitouch.c b/drivers/hid/hid-multitouch.c
index c741f5e..ac35731 100644
--- a/drivers/hid/hid-multitouch.c
+++ b/drivers/hid/hid-multitouch.c
@@ -835,7 +835,9 @@ static int mt_input_mapping(struct hid_device *hdev, struct 
hid_input *hi,
if (!td->mtclass.export_all_inputs &&
field->application != HID_DG_TOUCHSCREEN &&
field->application != HID_DG_PEN &&
-   field->application != HID_DG_TOUCHPAD)
+   field->application != HID_DG_TOUCHPAD &&
+   field->application != HID_GD_KEYBOARD &&
+   field->application != HID_CP_CONSUMER_CONTROL)
return -1;
 
/*
diff --git a/drivers/hid/usbhid/hid-quirks.c b/drivers/hid/usbhid/hid-quirks.c
index b4b8c6a..baf2bad 100644
--- a/drivers/hid/usbhid/hid-quirks.c
+++ b/drivers/hid/usbhid/hid-quirks.c
@@ -98,7 +98,6 @@ static const struct hid_blacklist {
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_2, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_PRO_3_JP, 
HID_QUIRK_NO_INIT_REPORTS },
-   { USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_TYPE_COVER_3, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MICROSOFT, USB_DEVICE_ID_MS_POWER_COVER, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_MSI, USB_DEVICE_ID_MSI_GT683R_LED_PANEL, 
HID_QUIRK_NO_INIT_REPORTS },
{ USB_VENDOR_ID_NEXIO, USB_DEVICE_ID_NEXIO_MULTITOUCH_PTI0750, 

[PATCH 1/2] HID: input: rework HID_QUIRK_MULTI_INPUT

[Benjamin Tissoires]

The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.

The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.

To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodes

Signed-off-by: Benjamin Tissoires 
---
 drivers/hid/hid-input.c | 95 -
 include/linux/hid.h |  1 +
 2 files changed, 55 insertions(+), 41 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index bcfaf32..bb2ec45 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1458,6 +1458,31 @@ static void hidinput_cleanup_hidinput(struct hid_device 
*hid,
kfree(hidinput);
 }
 
+static struct hid_input *hidinput_match(struct hid_report *report)
+{
+   struct hid_device *hid = report->device;
+   struct hid_input *hidinput;
+
+   list_for_each_entry(hidinput, >inputs, list) {
+   if (hidinput->report &&
+   hidinput->report->id == report->id)
+   return hidinput;
+   }
+
+   return NULL;
+}
+
+static inline void hidinput_configure_usages(struct hid_input *hidinput,
+struct hid_report *report)
+{
+   int i, j;
+
+   for (i = 0; i < report->maxfield; i++)
+   for (j = 0; j < report->field[i]->maxusage; j++)
+   hidinput_configure_usage(hidinput, report->field[i],
+report->field[i]->usage + j);
+}
+
 /*
  * Register the input device; print a message.
  * Configure the input layer interface
@@ -1468,8 +1493,8 @@ int hidinput_connect(struct hid_device *hid, unsigned int 
force)
 {
struct hid_driver *drv = hid->driver;
struct hid_report *report;
-   struct hid_input *hidinput = NULL;
-   int i, j, k;
+   struct hid_input *next, *hidinput = NULL;
+   int i, k;
 
INIT_LIST_HEAD(>inputs);
INIT_WORK(>led_work, hidinput_led_worker);
@@ -1499,43 +1524,40 @@ int hidinput_connect(struct hid_device *hid, unsigned 
int force)
if (!report->maxfield)
continue;
 
+   /*
+* Find the previous hidinput report attached
+* to this report id.
+*/
+   if (hid->quirks & HID_QUIRK_MULTI_INPUT)
+   hidinput = hidinput_match(report);
+
if (!hidinput) {
hidinput = hidinput_allocate(hid);
if (!hidinput)
goto out_unwind;
}
 
-   for (i = 0; i < report->maxfield; i++)
-   for (j = 0; j < report->field[i]->maxusage; j++)
-   hidinput_configure_usage(hidinput, 
report->field[i],
-
report->field[i]->usage + j);
-
-   if ((hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
-   !hidinput_has_been_populated(hidinput))
-   continue;
+   hidinput_configure_usages(hidinput, report);
 
-   if (hid->quirks & HID_QUIRK_MULTI_INPUT) {
-   /* This will leave hidinput NULL, so that it
-* allocates another one if we have more inputs 
on
-* the same interface. Some devices (e.g. Happ's
-* UGCI) cram a lot of unrelated inputs into the
-* same interface. */
+   if (hid->quirks & HID_QUIRK_MULTI_INPUT)
hidinput->report = report;
-   if (drv->input_configured &&
-   drv->input_configured(hid, hidinput))
-   goto out_cleanup;
-   if (input_register_device(hidinput->input))
-   goto out_cleanup;
-   hidinput = NULL;
-   }
}
}
 
-   if (hidinput && (hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
-   !hidinput_has_been_populated(hidinput)) {
-   /* no need to register an input device not populated */
-   hidinput_cleanup_hidinput(hid, 

[PATCH 1/2] HID: input: rework HID_QUIRK_MULTI_INPUT

[Benjamin Tissoires]

The purpose of HID_QUIRK_MULTI_INPUT is to have an input device per
report id. This is useful when the HID device presents several HID
collections of different device types.

The current implementation of hid-input creates one input node per id per
type (input or output). This is problematic for the LEDs of a keyboard as
they are often set through an output report. The current code creates
one input node with all the keyboard keys, and one other with only the
LEDs.

To solve this, we use a two-passes way:
- first, we initialize all input nodes and associate one per report id
- then, we register all the input nodes

Signed-off-by: Benjamin Tissoires 
---
 drivers/hid/hid-input.c | 95 -
 include/linux/hid.h |  1 +
 2 files changed, 55 insertions(+), 41 deletions(-)

diff --git a/drivers/hid/hid-input.c b/drivers/hid/hid-input.c
index bcfaf32..bb2ec45 100644
--- a/drivers/hid/hid-input.c
+++ b/drivers/hid/hid-input.c
@@ -1458,6 +1458,31 @@ static void hidinput_cleanup_hidinput(struct hid_device 
*hid,
kfree(hidinput);
 }
 
+static struct hid_input *hidinput_match(struct hid_report *report)
+{
+   struct hid_device *hid = report->device;
+   struct hid_input *hidinput;
+
+   list_for_each_entry(hidinput, >inputs, list) {
+   if (hidinput->report &&
+   hidinput->report->id == report->id)
+   return hidinput;
+   }
+
+   return NULL;
+}
+
+static inline void hidinput_configure_usages(struct hid_input *hidinput,
+struct hid_report *report)
+{
+   int i, j;
+
+   for (i = 0; i < report->maxfield; i++)
+   for (j = 0; j < report->field[i]->maxusage; j++)
+   hidinput_configure_usage(hidinput, report->field[i],
+report->field[i]->usage + j);
+}
+
 /*
  * Register the input device; print a message.
  * Configure the input layer interface
@@ -1468,8 +1493,8 @@ int hidinput_connect(struct hid_device *hid, unsigned int 
force)
 {
struct hid_driver *drv = hid->driver;
struct hid_report *report;
-   struct hid_input *hidinput = NULL;
-   int i, j, k;
+   struct hid_input *next, *hidinput = NULL;
+   int i, k;
 
INIT_LIST_HEAD(>inputs);
INIT_WORK(>led_work, hidinput_led_worker);
@@ -1499,43 +1524,40 @@ int hidinput_connect(struct hid_device *hid, unsigned 
int force)
if (!report->maxfield)
continue;
 
+   /*
+* Find the previous hidinput report attached
+* to this report id.
+*/
+   if (hid->quirks & HID_QUIRK_MULTI_INPUT)
+   hidinput = hidinput_match(report);
+
if (!hidinput) {
hidinput = hidinput_allocate(hid);
if (!hidinput)
goto out_unwind;
}
 
-   for (i = 0; i < report->maxfield; i++)
-   for (j = 0; j < report->field[i]->maxusage; j++)
-   hidinput_configure_usage(hidinput, 
report->field[i],
-
report->field[i]->usage + j);
-
-   if ((hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
-   !hidinput_has_been_populated(hidinput))
-   continue;
+   hidinput_configure_usages(hidinput, report);
 
-   if (hid->quirks & HID_QUIRK_MULTI_INPUT) {
-   /* This will leave hidinput NULL, so that it
-* allocates another one if we have more inputs 
on
-* the same interface. Some devices (e.g. Happ's
-* UGCI) cram a lot of unrelated inputs into the
-* same interface. */
+   if (hid->quirks & HID_QUIRK_MULTI_INPUT)
hidinput->report = report;
-   if (drv->input_configured &&
-   drv->input_configured(hid, hidinput))
-   goto out_cleanup;
-   if (input_register_device(hidinput->input))
-   goto out_cleanup;
-   hidinput = NULL;
-   }
}
}
 
-   if (hidinput && (hid->quirks & HID_QUIRK_NO_EMPTY_INPUT) &&
-   !hidinput_has_been_populated(hidinput)) {
-   /* no need to register an input device not populated */
-   hidinput_cleanup_hidinput(hid, hidinput);
-   

Re: [PATCH v2] sched/completion: convert completions to use simple wait queues

[Daniel Wagner]

On 04/28/2016 02:57 PM, Daniel Wagner wrote:
> As one can see above in the swait_stat output, the fork() path is
> using completion. A histogram of a fork bomp (1000 forks) benchmark
> shows a slight performance drop by 4%.
> 
> [wagi@handman completion-test-5 (master)]$ cat forky-4.6.0-rc4.txt | perl 
> histo -min 0.12 -max 0.20 -int 0.01 -stars -scale 10
> # NumSamples = 1000; Max = 0.208; Min = 0.123
> # Mean = 0.146406; Variance = 0.00027535116356; SD = 0.0165937085668019
> # Each * represents a count of 10
>  0.1200 - 0.1300 [   113]: 
>  0.1300 - 0.1400 [   324]: *
>  0.1400 - 0.1500 [   219]: **
>  0.1500 - 0.1600 [   139]: **
>  0.1600 - 0.1700 [94]: **
>  0.1700 - 0.1800 [54]: **
>  0.1800 - 0.1900 [37]: 
>  0.1900 - 0.2000 [18]: **
> 
> [wagi@handman completion-test-5 (master)]$ cat 
> forky-4.6.0-rc4-1-g0a16067.txt | perl histo -min 0.12 -max 0.20 -int 0.01 
> -stars -scale 10
> # NumSamples = 1000; Max = 0.207; Min = 0.121
> # Mean = 0.152056; Variance = 0.00029547486394; SD = 0.0171893823042014
> # Each * represents a count of 10
>  0.1200 - 0.1300 [17]: **
>  0.1300 - 0.1400 [   282]: *
>  0.1400 - 0.1500 [   240]: 
>  0.1500 - 0.1600 [   158]: 
>  0.1600 - 0.1700 [   114]: 
>  0.1700 - 0.1800 [94]: **
>  0.1800 - 0.1900 [66]: ***
>  0.1900 - 0.2000 [25]: ***
>  0.2000 - 0.2100 [ 1]: *


I redid the above test and changed my fork bomb to this:

for (i = 0; i < MAX_CHILDREN; i++) {
switch(fork()) {
case -1:
exit(1);
case 0:
_exit(0);
}
}

for (i = 0; i < MAX_CHILDREN; i++) {
do {
pid = waitpid(-1, , WUNTRACED );
if (pid < 0 && errno != ECHILD)
exit(1);
} while (!WIFEXITED(status) && !WIFSIGNALED(status));
}

Obviously, fork is not a very good benchmark since we might end up
into memory allocation etc. The distribution I get from baseline and
this batch look very similiar:

[wagi@handman completion (master)]$ cat results/forky-4.6.0-rc4.txt  | perl 
histo -min 0.09 -max 0.11 -int 0.001 -stars -scale 100
 0.0910 - 0.0920 [ 3]: *
 0.0920 - 0.0930 [ 8]: *
 0.0930 - 0.0940 [52]: *
 0.0940 - 0.0950 [   404]: *
 0.0950 - 0.0960 [  1741]: **
 0.0960 - 0.0970 [  2221]: ***
 0.0970 - 0.0980 [  1612]: *
 0.0980 - 0.0990 [  1346]: **
 0.0990 - 0.1000 [  1223]: *
 0.1000 - 0.1010 [   724]: 
 0.1010 - 0.1020 [   362]: 
 0.1020 - 0.1030 [   186]: **
 0.1030 - 0.1040 [71]: *
 0.1040 - 0.1050 [29]: *
 0.1050 - 0.1060 [12]: *
 0.1060 - 0.1070 [ 4]: *
 0.1080 - 0.1090 [ 2]: *

[wagi@handman completion (master)]$ cat 
results/forky-4.6.0-rc4-1-gc4c770c.txt  | perl histo -min 0.09 -max 0.11 
-int 0.001 -stars -scale 100
 0.0930 - 0.0940 [ 3]: *
 0.0940 - 0.0950 [ 9]: *
 0.0950 - 0.0960 [25]: *
 0.0960 - 0.0970 [77]: *
 0.0970 - 0.0980 [   324]: 
 0.0980 - 0.0990 [  1503]: 
 0.0990 - 0.1000 [  2247]: ***
 0.1000 - 0.1010 [  1708]: **
 0.1010 - 0.1020 [  1486]: ***
 0.1020 - 0.1030 [  1215]: *
 0.1030 - 0.1040 [   729]: 
 0.1040 - 0.1050 [   368]: 
 0.1050 - 0.1060 [   197]: **
 0.1060 - 0.1070 [65]: *
 0.1070 - 0.1080 [32]: *
 0.1080 - 0.1090 [ 7]: *
 0.1090 - 0.1100 [ 2]: *

A t-test (determine if two sets of data are significantly different)
returns a p value of 0 (< 1%). That means we reject the null
hypothesis of equal avarages. That means we have a 0.3% decrease in
perforamnce compared with the baseline.

 
> Compiling a kernel 100 times results in following statistics gather
> by 'time make -j200'
> 
> user
> meanstd   
>  varmaxmin
>kernbech-4.6.0-rc4  9.126 0.2919
> 0.08523   9.92   8.55
>kernbech-4.6.0-rc4-1-g0...   9.24  -1.25% 0.2768   5.17%
> 0.07664  10.07%  10.11  -1.92%   8.44   1.29%
> 
> 
> system
> meanstd   
>  varmaxmin
>kernbech-4.6.0-rc4  1.676e+03  2.409  
> 5.804  1.681e+03  1.666e+03
>kernbech-4.6.0-rc4-1-g0... 

Re: [PATCH v2] sched/completion: convert completions to use simple wait queues

[Daniel Wagner]

On 04/28/2016 02:57 PM, Daniel Wagner wrote:
> As one can see above in the swait_stat output, the fork() path is
> using completion. A histogram of a fork bomp (1000 forks) benchmark
> shows a slight performance drop by 4%.
> 
> [wagi@handman completion-test-5 (master)]$ cat forky-4.6.0-rc4.txt | perl 
> histo -min 0.12 -max 0.20 -int 0.01 -stars -scale 10
> # NumSamples = 1000; Max = 0.208; Min = 0.123
> # Mean = 0.146406; Variance = 0.00027535116356; SD = 0.0165937085668019
> # Each * represents a count of 10
>  0.1200 - 0.1300 [   113]: 
>  0.1300 - 0.1400 [   324]: *
>  0.1400 - 0.1500 [   219]: **
>  0.1500 - 0.1600 [   139]: **
>  0.1600 - 0.1700 [94]: **
>  0.1700 - 0.1800 [54]: **
>  0.1800 - 0.1900 [37]: 
>  0.1900 - 0.2000 [18]: **
> 
> [wagi@handman completion-test-5 (master)]$ cat 
> forky-4.6.0-rc4-1-g0a16067.txt | perl histo -min 0.12 -max 0.20 -int 0.01 
> -stars -scale 10
> # NumSamples = 1000; Max = 0.207; Min = 0.121
> # Mean = 0.152056; Variance = 0.00029547486394; SD = 0.0171893823042014
> # Each * represents a count of 10
>  0.1200 - 0.1300 [17]: **
>  0.1300 - 0.1400 [   282]: *
>  0.1400 - 0.1500 [   240]: 
>  0.1500 - 0.1600 [   158]: 
>  0.1600 - 0.1700 [   114]: 
>  0.1700 - 0.1800 [94]: **
>  0.1800 - 0.1900 [66]: ***
>  0.1900 - 0.2000 [25]: ***
>  0.2000 - 0.2100 [ 1]: *


I redid the above test and changed my fork bomb to this:

for (i = 0; i < MAX_CHILDREN; i++) {
switch(fork()) {
case -1:
exit(1);
case 0:
_exit(0);
}
}

for (i = 0; i < MAX_CHILDREN; i++) {
do {
pid = waitpid(-1, , WUNTRACED );
if (pid < 0 && errno != ECHILD)
exit(1);
} while (!WIFEXITED(status) && !WIFSIGNALED(status));
}

Obviously, fork is not a very good benchmark since we might end up
into memory allocation etc. The distribution I get from baseline and
this batch look very similiar:

[wagi@handman completion (master)]$ cat results/forky-4.6.0-rc4.txt  | perl 
histo -min 0.09 -max 0.11 -int 0.001 -stars -scale 100
 0.0910 - 0.0920 [ 3]: *
 0.0920 - 0.0930 [ 8]: *
 0.0930 - 0.0940 [52]: *
 0.0940 - 0.0950 [   404]: *
 0.0950 - 0.0960 [  1741]: **
 0.0960 - 0.0970 [  2221]: ***
 0.0970 - 0.0980 [  1612]: *
 0.0980 - 0.0990 [  1346]: **
 0.0990 - 0.1000 [  1223]: *
 0.1000 - 0.1010 [   724]: 
 0.1010 - 0.1020 [   362]: 
 0.1020 - 0.1030 [   186]: **
 0.1030 - 0.1040 [71]: *
 0.1040 - 0.1050 [29]: *
 0.1050 - 0.1060 [12]: *
 0.1060 - 0.1070 [ 4]: *
 0.1080 - 0.1090 [ 2]: *

[wagi@handman completion (master)]$ cat 
results/forky-4.6.0-rc4-1-gc4c770c.txt  | perl histo -min 0.09 -max 0.11 
-int 0.001 -stars -scale 100
 0.0930 - 0.0940 [ 3]: *
 0.0940 - 0.0950 [ 9]: *
 0.0950 - 0.0960 [25]: *
 0.0960 - 0.0970 [77]: *
 0.0970 - 0.0980 [   324]: 
 0.0980 - 0.0990 [  1503]: 
 0.0990 - 0.1000 [  2247]: ***
 0.1000 - 0.1010 [  1708]: **
 0.1010 - 0.1020 [  1486]: ***
 0.1020 - 0.1030 [  1215]: *
 0.1030 - 0.1040 [   729]: 
 0.1040 - 0.1050 [   368]: 
 0.1050 - 0.1060 [   197]: **
 0.1060 - 0.1070 [65]: *
 0.1070 - 0.1080 [32]: *
 0.1080 - 0.1090 [ 7]: *
 0.1090 - 0.1100 [ 2]: *

A t-test (determine if two sets of data are significantly different)
returns a p value of 0 (< 1%). That means we reject the null
hypothesis of equal avarages. That means we have a 0.3% decrease in
perforamnce compared with the baseline.

 
> Compiling a kernel 100 times results in following statistics gather
> by 'time make -j200'
> 
> user
> meanstd   
>  varmaxmin
>kernbech-4.6.0-rc4  9.126 0.2919
> 0.08523   9.92   8.55
>kernbech-4.6.0-rc4-1-g0...   9.24  -1.25% 0.2768   5.17%
> 0.07664  10.07%  10.11  -1.92%   8.44   1.29%
> 
> 
> system
> meanstd   
>  varmaxmin
>kernbech-4.6.0-rc4  1.676e+03  2.409  
> 5.804  1.681e+03  1.666e+03
>kernbech-4.6.0-rc4-1-g0... 

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > of vector, and kernel reports successful read/write.
> > > 
> > > There are 2 problems:
> > > 1. How kernel allows such address to be passed to fs subsystem;
> > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > address.
> > > 
> > > I don't know the answer on 2'nd question, and it might be something
> > > generic. But I investigated first problem.
> > > 
> > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > validate user address, and on arm64 it ends up with checking buffer
> > > end against current_thread_info()->addr_limit.
> > > 
> > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > It happens because on thread creation we call flush_old_exec() to set 
> > > addr_limit, and completely ignore compat mode there.

[...]

> > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > @@ -12,6 +12,7 @@
> > >  do { \
> > >   clear_thread_flag(TIF_32BIT_AARCH64);   \
> > >   set_thread_flag(TIF_32BIT); \
> > > + set_fs(TASK_SIZE_32);   \
> > >  } while (0)
> > >  
> > >  #define COMPAT_ARCH_DLINFO
> > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > index a934fd4..a8599c6 100644
> > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > cputime,
> > >  do { 
> > > \
> > >   set_thread_flag(TIF_32BIT_AARCH64); \
> > >   clear_thread_flag(TIF_32BIT);   \
> > > + set_fs(TASK_SIZE_32);   \
> > >  } while (0)
> > 
> > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > setting the USER_DS for the new thread.
> 
> That's true, but USER_DS depends on personality which is not set yet
> for new thread, as I wrote above. In fact, I tried correct USER_DS
> only, and it doesn't work

Ah, it looks like load_elf_binary() sets the personality after
flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
maximum 64-bit task value, so they should have a similar issue with
native 32-bit vs compat behaviour.

So what exactly is LTP complaining about? Is different error (like
EFAULT vs EINVAL) or not getting an error at all.

(I need to update my LTP, the preadv tests appeared in December last
year)

-- 
Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 04:44:31PM +0300, Yury Norov wrote:
> On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> > On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > > of vector, and kernel reports successful read/write.
> > > 
> > > There are 2 problems:
> > > 1. How kernel allows such address to be passed to fs subsystem;
> > > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > > address.
> > > 
> > > I don't know the answer on 2'nd question, and it might be something
> > > generic. But I investigated first problem.
> > > 
> > > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > > validate user address, and on arm64 it ends up with checking buffer
> > > end against current_thread_info()->addr_limit.
> > > 
> > > current_thread_info()->addr_limit for ilp32, and most probably for
> > > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > > It happens because on thread creation we call flush_old_exec() to set 
> > > addr_limit, and completely ignore compat mode there.

[...]

> > > --- a/arch/arm64/kernel/binfmt_elf32.c
> > > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > > @@ -12,6 +12,7 @@
> > >  do { \
> > >   clear_thread_flag(TIF_32BIT_AARCH64);   \
> > >   set_thread_flag(TIF_32BIT); \
> > > + set_fs(TASK_SIZE_32);   \
> > >  } while (0)
> > >  
> > >  #define COMPAT_ARCH_DLINFO
> > > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > > b/arch/arm64/kernel/binfmt_ilp32.c
> > > index a934fd4..a8599c6 100644
> > > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > > cputime,
> > >  do { 
> > > \
> > >   set_thread_flag(TIF_32BIT_AARCH64); \
> > >   clear_thread_flag(TIF_32BIT);   \
> > > + set_fs(TASK_SIZE_32);   \
> > >  } while (0)
> > 
> > I don't think we need these two. AFAICT, flush_old_exec() takes care of
> > setting the USER_DS for the new thread.
> 
> That's true, but USER_DS depends on personality which is not set yet
> for new thread, as I wrote above. In fact, I tried correct USER_DS
> only, and it doesn't work

Ah, it looks like load_elf_binary() sets the personality after
flush_old_exec(). Looking at powerpc and x86, they set USER_DS to the
maximum 64-bit task value, so they should have a similar issue with
native 32-bit vs compat behaviour.

So what exactly is LTP complaining about? Is different error (like
EFAULT vs EINVAL) or not getting an error at all.

(I need to update my LTP, the preadv tests appeared in December last
year)

-- 
Catalin

[PATCH] ACPI / scan: force creation of platform device for the Surface tablets

[Benjamin Tissoires]

As mentioned in drivers/platform/x86/surfacepro3_button.c, the various
Microsoft Surface tablets do not follow the ACPI SOC buttons specification.
They present an I2C device like this:

  Device (WBUT)
  {
  Method (_HID, 0, NotSerialized)  // _HID: Hardware ID
  {
  Return ("PNP0C40")
  }
 
  Name (_CID, "PNP0C40" /* Standard Button Controller */)  // _CID: 
Compatible ID
  Method (_STA, 0, NotSerialized)  // _STA: Status
  {
  Return (0x0F)
  }
 
  Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
  {
  [stripped]
  }
  }
 
  Device (TEV2)
  {
  Name (_HID, "MSHW0028")  // _HID: Hardware ID
  Name (_DEP, Package (0x06)  // _DEP: Dependencies
  {
  GPO0,
  GPO2,
  GPO1,
  ^PCI0.I2C2,
  ^PCI0.I2C7,
  ^PCI0.I2C7.PMIC
  })
  Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
  {
  Name (RBUF, ResourceTemplate ()
  {
  GpioInt (Edge, ActiveBoth, SharedAndWake, PullDefault, 0x09C4,
  "\\_SB.GPO2", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x0008
  }
  GpioInt (Edge, ActiveBoth, SharedAndWake, PullDefault, 0x09C4,
  "\\_SB.GPO2", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x000A
  }
  GpioInt (Edge, ActiveBoth, Shared, PullDefault, 0x09C4,
  "\\_SB.GPO0", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x005D
  }
  GpioInt (Edge, ActiveBoth, Shared, PullDefault, 0x09C4,
  "\\_SB.GPO1", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x0008
  }
  I2cSerialBus (0x002D, ControllerInitiated, 0x00061A80,
  AddressingMode7Bit, "\\_SB.PCI0.I2C2",
  0x00, ResourceConsumer, ,
  )
  [stripped]
  })
  [stripped]
  If ((OBID <= 0x0C))
  {
  Return (RBUF) /* \_SB_.TEV2._CRS.RBUF */
  }
 
  Return (PBUF) /* \_SB_.TEV2._CRS.PBUF */
  }
 
  Method (_STA, 0, NotSerialized)  // _STA: Status
  {
  Return (0x0F)
  }
 
  Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
  {
  [stripped]
  }
  }

The actual HW button is named MSHW0028 on the MS Surface (Pro) 3 and
is meant to be bound on the I2C bus 7. The problem is that the bus
doesn't see any device on the address 0x002D.

The Surface Pro devices have working ACPI events and thus we can use
surfacepro3_button which is a pure acpi driver. The Surface 3 however
does not generate any ACPI events and the buttons are not working
through surfacepro3_button (even when we add the name TEV2 in this module).

The solution consists in forcing the creation of an platform device
which we can handle in soc_button_array as any proper SOC GPIO buttons
should be.

Signed-off-by: Benjamin Tissoires 
---

Hi,

this is IMO the best way to handle this situation (besides fixing the DSDT
itself). The other solutions I thought were:
- add a specific acpi driver that will unbind the current I2C acpi handle
  and will create the platform_driver
- add a specific acpi driver that merges surfacepro3_button and soc_button_array
  but has a lot of code duplication

I am open to any other solution if we could have this list of ids in a different
place but I could not see any other.

Cheers,
Benjamin

 drivers/acpi/scan.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..6fe9296 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -46,6 +46,12 @@ DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
 
+static const struct acpi_device_id i2c_whitelisted_id_list[] = {
+   {"MSHW0028", 0},/* Surface (Pro) 3 buttons */
+   {"MSHW0040", 0},/* Surface Pro 4 buttons */
+   {"", 0},
+};
+
 struct acpi_dep_data {
struct list_head node;
acpi_handle master;
@@ -1676,13 +1682,21 @@ static void acpi_default_enumeration(struct acpi_device 
*device)
bool is_spi_i2c_slave = false;
 
/*
-* Do not enemerate SPI/I2C slaves as they will be enuerated by their
+* Do not enemerate SPI/I2C slaves as they will be enumerated by their
 * respective parents.
 */
INIT_LIST_HEAD(_list);
acpi_dev_get_resources(device, _list, acpi_check_spi_i2c_slave,
   _spi_i2c_slave);
acpi_dev_free_resource_list(_list);
+
+   /*
+* these devices are declared 

[PATCH] ACPI / scan: force creation of platform device for the Surface tablets

[Benjamin Tissoires]

As mentioned in drivers/platform/x86/surfacepro3_button.c, the various
Microsoft Surface tablets do not follow the ACPI SOC buttons specification.
They present an I2C device like this:

  Device (WBUT)
  {
  Method (_HID, 0, NotSerialized)  // _HID: Hardware ID
  {
  Return ("PNP0C40")
  }
 
  Name (_CID, "PNP0C40" /* Standard Button Controller */)  // _CID: 
Compatible ID
  Method (_STA, 0, NotSerialized)  // _STA: Status
  {
  Return (0x0F)
  }
 
  Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
  {
  [stripped]
  }
  }
 
  Device (TEV2)
  {
  Name (_HID, "MSHW0028")  // _HID: Hardware ID
  Name (_DEP, Package (0x06)  // _DEP: Dependencies
  {
  GPO0,
  GPO2,
  GPO1,
  ^PCI0.I2C2,
  ^PCI0.I2C7,
  ^PCI0.I2C7.PMIC
  })
  Method (_CRS, 0, NotSerialized)  // _CRS: Current Resource Settings
  {
  Name (RBUF, ResourceTemplate ()
  {
  GpioInt (Edge, ActiveBoth, SharedAndWake, PullDefault, 0x09C4,
  "\\_SB.GPO2", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x0008
  }
  GpioInt (Edge, ActiveBoth, SharedAndWake, PullDefault, 0x09C4,
  "\\_SB.GPO2", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x000A
  }
  GpioInt (Edge, ActiveBoth, Shared, PullDefault, 0x09C4,
  "\\_SB.GPO0", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x005D
  }
  GpioInt (Edge, ActiveBoth, Shared, PullDefault, 0x09C4,
  "\\_SB.GPO1", 0x00, ResourceConsumer, ,
  )
  {   // Pin list
  0x0008
  }
  I2cSerialBus (0x002D, ControllerInitiated, 0x00061A80,
  AddressingMode7Bit, "\\_SB.PCI0.I2C2",
  0x00, ResourceConsumer, ,
  )
  [stripped]
  })
  [stripped]
  If ((OBID <= 0x0C))
  {
  Return (RBUF) /* \_SB_.TEV2._CRS.RBUF */
  }
 
  Return (PBUF) /* \_SB_.TEV2._CRS.PBUF */
  }
 
  Method (_STA, 0, NotSerialized)  // _STA: Status
  {
  Return (0x0F)
  }
 
  Method (_DSM, 4, Serialized)  // _DSM: Device-Specific Method
  {
  [stripped]
  }
  }

The actual HW button is named MSHW0028 on the MS Surface (Pro) 3 and
is meant to be bound on the I2C bus 7. The problem is that the bus
doesn't see any device on the address 0x002D.

The Surface Pro devices have working ACPI events and thus we can use
surfacepro3_button which is a pure acpi driver. The Surface 3 however
does not generate any ACPI events and the buttons are not working
through surfacepro3_button (even when we add the name TEV2 in this module).

The solution consists in forcing the creation of an platform device
which we can handle in soc_button_array as any proper SOC GPIO buttons
should be.

Signed-off-by: Benjamin Tissoires 
---

Hi,

this is IMO the best way to handle this situation (besides fixing the DSDT
itself). The other solutions I thought were:
- add a specific acpi driver that will unbind the current I2C acpi handle
  and will create the platform_driver
- add a specific acpi driver that merges surfacepro3_button and soc_button_array
  but has a lot of code duplication

I am open to any other solution if we could have this list of ids in a different
place but I could not see any other.

Cheers,
Benjamin

 drivers/acpi/scan.c | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/drivers/acpi/scan.c b/drivers/acpi/scan.c
index 5f28cf7..6fe9296 100644
--- a/drivers/acpi/scan.c
+++ b/drivers/acpi/scan.c
@@ -46,6 +46,12 @@ DEFINE_MUTEX(acpi_device_lock);
 LIST_HEAD(acpi_wakeup_device_list);
 static DEFINE_MUTEX(acpi_hp_context_lock);
 
+static const struct acpi_device_id i2c_whitelisted_id_list[] = {
+   {"MSHW0028", 0},/* Surface (Pro) 3 buttons */
+   {"MSHW0040", 0},/* Surface Pro 4 buttons */
+   {"", 0},
+};
+
 struct acpi_dep_data {
struct list_head node;
acpi_handle master;
@@ -1676,13 +1682,21 @@ static void acpi_default_enumeration(struct acpi_device 
*device)
bool is_spi_i2c_slave = false;
 
/*
-* Do not enemerate SPI/I2C slaves as they will be enuerated by their
+* Do not enemerate SPI/I2C slaves as they will be enumerated by their
 * respective parents.
 */
INIT_LIST_HEAD(_list);
acpi_dev_get_resources(device, _list, acpi_check_spi_i2c_slave,
   _spi_i2c_slave);
acpi_dev_free_resource_list(_list);
+
+   /*
+* these devices are declared as I2C but should actually be
+ 

Re: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus

[Peter Zijlstra]

On Thu, May 12, 2016 at 01:30:36PM +, Liang, Kan wrote:
> 
> 
> > ---
> > Subject: perf/core: don't find side-band event from all pmus
> > From: Kan Liang 
> > Date: Wed, 23 Mar 2016 11:24:37 -0700
> > 
> Hi Peter,
> 
> Is there something wrong with the patch?
> The last time I saw this patch was in your personal tree 
> (kernel/git/peterz/queue.git).
> But now I cannot find it anymore. 

Hurm; I seem to have lost it, sorry about that.

Let me go find where its gone.

Re: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus

[Peter Zijlstra]

On Thu, May 12, 2016 at 01:30:36PM +, Liang, Kan wrote:
> 
> 
> > ---
> > Subject: perf/core: don't find side-band event from all pmus
> > From: Kan Liang 
> > Date: Wed, 23 Mar 2016 11:24:37 -0700
> > 
> Hi Peter,
> 
> Is there something wrong with the patch?
> The last time I saw this patch was in your personal tree 
> (kernel/git/peterz/queue.git).
> But now I cannot find it anymore. 

Hurm; I seem to have lost it, sorry about that.

Let me go find where its gone.

Re: [PATCH v2] tpm: Fix suspend regression

[Jarkko Sakkinen]

On Thu, May 12, 2016 at 04:49:52PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 11, 2016 at 11:28:27AM -0400, Stefan Berger wrote:
> > Fix the suspend regression due to the wrong way of retrieving the
> > chip structure. The suspend functions are attached to the hardware
> > device, not the chip and thus must rely on drvdata.
> > 
> > Fixes: e89f8b1ade9cc1a ("tpm: Remove all uses of drvdata from the TPM Core")
> > Reported-by: Jeremiah Mahler 
> > Signed-off-by: Stefan Berger 
> > Tested-by: Stefan Berger 
> > Reviewed-by: Jason Gunthorpe 
> > Tested-by: Jeremiah Mahler 
> 
> Acked-by: Jarkko Sakkinen 

Merged to next.

/Jarkko

> /Jarkko
> 
> > ---
> >  drivers/char/tpm/tpm-interface.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-interface.c 
> > b/drivers/char/tpm/tpm-interface.c
> > index 080dade..5e3c1b6 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -934,7 +934,7 @@ static struct tpm_input_header savestate_header = {
> >   */
> >  int tpm_pm_suspend(struct device *dev)
> >  {
> > -   struct tpm_chip *chip = to_tpm_chip(dev);
> > +   struct tpm_chip *chip = dev_get_drvdata(dev);
> > struct tpm_cmd_t cmd;
> > int rc, try;
> >  
> > @@ -995,7 +995,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_suspend);
> >   */
> >  int tpm_pm_resume(struct device *dev)
> >  {
> > -   struct tpm_chip *chip = to_tpm_chip(dev);
> > +   struct tpm_chip *chip = dev_get_drvdata(dev);
> >  
> > if (chip == NULL)
> > return -ENODEV;
> > -- 
> > 2.4.3
> > 

Re: [PATCH v2] tpm: Fix suspend regression

[Jarkko Sakkinen]

On Thu, May 12, 2016 at 04:49:52PM +0300, Jarkko Sakkinen wrote:
> On Wed, May 11, 2016 at 11:28:27AM -0400, Stefan Berger wrote:
> > Fix the suspend regression due to the wrong way of retrieving the
> > chip structure. The suspend functions are attached to the hardware
> > device, not the chip and thus must rely on drvdata.
> > 
> > Fixes: e89f8b1ade9cc1a ("tpm: Remove all uses of drvdata from the TPM Core")
> > Reported-by: Jeremiah Mahler 
> > Signed-off-by: Stefan Berger 
> > Tested-by: Stefan Berger 
> > Reviewed-by: Jason Gunthorpe 
> > Tested-by: Jeremiah Mahler 
> 
> Acked-by: Jarkko Sakkinen 

Merged to next.

/Jarkko

> /Jarkko
> 
> > ---
> >  drivers/char/tpm/tpm-interface.c | 4 ++--
> >  1 file changed, 2 insertions(+), 2 deletions(-)
> > 
> > diff --git a/drivers/char/tpm/tpm-interface.c 
> > b/drivers/char/tpm/tpm-interface.c
> > index 080dade..5e3c1b6 100644
> > --- a/drivers/char/tpm/tpm-interface.c
> > +++ b/drivers/char/tpm/tpm-interface.c
> > @@ -934,7 +934,7 @@ static struct tpm_input_header savestate_header = {
> >   */
> >  int tpm_pm_suspend(struct device *dev)
> >  {
> > -   struct tpm_chip *chip = to_tpm_chip(dev);
> > +   struct tpm_chip *chip = dev_get_drvdata(dev);
> > struct tpm_cmd_t cmd;
> > int rc, try;
> >  
> > @@ -995,7 +995,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_suspend);
> >   */
> >  int tpm_pm_resume(struct device *dev)
> >  {
> > -   struct tpm_chip *chip = to_tpm_chip(dev);
> > +   struct tpm_chip *chip = dev_get_drvdata(dev);
> >  
> > if (chip == NULL)
> > return -ENODEV;
> > -- 
> > 2.4.3
> > 

Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable

[Peter Zijlstra]

On Thu, May 12, 2016 at 02:19:07PM +0200, Michal Hocko wrote:
> On Thu 12-05-16 14:12:04, Peter Zijlstra wrote:
> > On Wed, May 11, 2016 at 08:03:46PM +0200, Michal Hocko wrote:
> > > I still cannot say I would understand why the pending
> > > RWSEM_WAITING_BIAS matters but I would probably need to look at the code
> > > again with a clean head, __rwsem_wake is quite tricky...
> > 
> > Ah, you're asking why an unconditional __rwsem_wake(ANY) isn't enough?
> > 
> > Because; if at that point there's nobody waiting, we're left with an
> > empty list and WAITER_BIAS set. This in turn will make all fast paths
> > fail.
> > 
> > Look at rwsem_down_read_failed() for instance; if we enter that we'll
> > unconditionally queue ourself, with nobody left to come wake us.
> 
> This is still not clear to me because rwsem_down_read_failed will call
> __rwsem_do_wake if the count is RWSEM_WAITING_BIAS so we shouldn't go to
> sleep and get the lock. So you are right that we would force everybody
> to the slow path which is not great but shouldn't cause incorrect
> behavior. I guess I must be missing something obvious here...


Ah me too; I missed the obvious: we do the __rwsem_do_wake() after we
add ourselves to the list, which means we'll also wake ourselves.

I'll have more thinking..

Re: [PATCH 03/11] locking, rwsem: introduce basis for down_write_killable

[Peter Zijlstra]

On Thu, May 12, 2016 at 02:19:07PM +0200, Michal Hocko wrote:
> On Thu 12-05-16 14:12:04, Peter Zijlstra wrote:
> > On Wed, May 11, 2016 at 08:03:46PM +0200, Michal Hocko wrote:
> > > I still cannot say I would understand why the pending
> > > RWSEM_WAITING_BIAS matters but I would probably need to look at the code
> > > again with a clean head, __rwsem_wake is quite tricky...
> > 
> > Ah, you're asking why an unconditional __rwsem_wake(ANY) isn't enough?
> > 
> > Because; if at that point there's nobody waiting, we're left with an
> > empty list and WAITER_BIAS set. This in turn will make all fast paths
> > fail.
> > 
> > Look at rwsem_down_read_failed() for instance; if we enter that we'll
> > unconditionally queue ourself, with nobody left to come wake us.
> 
> This is still not clear to me because rwsem_down_read_failed will call
> __rwsem_do_wake if the count is RWSEM_WAITING_BIAS so we shouldn't go to
> sleep and get the lock. So you are right that we would force everybody
> to the slow path which is not great but shouldn't cause incorrect
> behavior. I guess I must be missing something obvious here...


Ah me too; I missed the obvious: we do the __rwsem_do_wake() after we
add ourselves to the list, which means we'll also wake ourselves.

I'll have more thinking..

[PATCH ] pinctrl: tegra: Get rid of parked_reg

[Laxman Dewangan]

Remove the use of parked_reg and use parked_bit for to know
whether field is supported or not.

This is fix for the patch
commit 1d18a3f0f0809f6c71f1f6e9e268ee904ce0b588
"pinctrl: tegra: avoid parked_reg and parked_bank

Signed-off-by: Laxman Dewangan 
---
 drivers/pinctrl/tegra/pinctrl-tegra20.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/tegra/pinctrl-tegra20.c 
b/drivers/pinctrl/tegra/pinctrl-tegra20.c
index 91254d0..ad62451 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra20.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra20.c
@@ -2030,7 +2030,7 @@ static struct tegra_function tegra20_functions[] = {
.tri_reg = -1,  \
.drv_reg = ((r) - PINGROUP_REG_A),  \
.drv_bank = 3,  \
-   .parked_reg = -1,   \
+   .parked_bit = -1,   \
.hsm_bit = hsm_b,   \
.schmitt_bit = schmitt_b,   \
.lpmd_bit = lpmd_b, \
-- 
2.1.4

[PATCH ] pinctrl: tegra: Get rid of parked_reg

[Laxman Dewangan]

Remove the use of parked_reg and use parked_bit for to know
whether field is supported or not.

This is fix for the patch
commit 1d18a3f0f0809f6c71f1f6e9e268ee904ce0b588
"pinctrl: tegra: avoid parked_reg and parked_bank

Signed-off-by: Laxman Dewangan 
---
 drivers/pinctrl/tegra/pinctrl-tegra20.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/pinctrl/tegra/pinctrl-tegra20.c 
b/drivers/pinctrl/tegra/pinctrl-tegra20.c
index 91254d0..ad62451 100644
--- a/drivers/pinctrl/tegra/pinctrl-tegra20.c
+++ b/drivers/pinctrl/tegra/pinctrl-tegra20.c
@@ -2030,7 +2030,7 @@ static struct tegra_function tegra20_functions[] = {
.tri_reg = -1,  \
.drv_reg = ((r) - PINGROUP_REG_A),  \
.drv_bank = 3,  \
-   .parked_reg = -1,   \
+   .parked_bit = -1,   \
.hsm_bit = hsm_b,   \
.schmitt_bit = schmitt_b,   \
.lpmd_bit = lpmd_b, \
-- 
2.1.4

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

[Jerome Glisse]

On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote:
> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
> > On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote:
> >>
> >> Le 05/11/2016 à 04:51 PM, Jerome Glisse a écrit :
> >>> On Wed, May 11, 2016 at 01:15:54PM +0200, Nicolas Morey Chaisemartin 
> >>> wrote:
>  Le 05/10/2016 à 12:01 PM, Jerome Glisse a écrit :
> > On Tue, May 10, 2016 at 09:04:36AM +0200, Nicolas Morey Chaisemartin 
> > wrote:
> >> Le 05/03/2016 à 12:11 PM, Jerome Glisse a écrit :
> >>> On Mon, May 02, 2016 at 09:04:02PM -0700, Hugh Dickins wrote:
>  On Fri, 29 Apr 2016, Nicolas Morey Chaisemartin wrote:
>  [...]
> >> Hi,
> >>
> >> I backported the patch to 3.10 (had to copy paste pmd_protnone 
> >> defitinition from 4.5) and it's working !
> >> I'll open a ticket in Redhat tracker to try and get this fixed in 
> >> RHEL7.
> >>
> >> I have a dumb question though: how can we end up in numa/misplaced 
> >> memory code on a single socket system?
> >>
> > This patch is not a fix, do you see bug message in kernel log ? Because 
> > if
> > you do that it means we have a bigger issue.
> >
> > You did not answer one of my previous question, do you set 
> > get_user_pages
> > with write = 1 as a paremeter ?
> >
> > Also it would be a lot easier if you were testing with lastest 4.6 or 
> > 4.5
> > not RHEL kernel as they are far appart and what might looks like same 
> > issue
> > on both might be totaly different bugs.
> >
> > If you only really care about RHEL kernel then open a bug with Red Hat 
> > and
> > you can add me in bug-cc 
> >
> > Cheers,
> > Jérôme
>  I finally managed to get a proper setup.
>  I build a vanilla 4.5 kernel from git tree using the Centos7 config, my 
>  test fails as usual.
>  I applied your patch, rebuild => still fails and no new messages in 
>  dmesg.
> 
>  Now that I don't have to go through the RPM repackaging, I can try out 
>  things much quicker if you have any ideas.
> 
> >>> Still an issue if you boot with transparent_hugepage=never ?
> >>>
> >>> Also to simplify investigation force write to 1 all the time no matter 
> >>> what.
> >>>
> >>> Cheers,
> >>> Jérôme
> >> With transparent_hugepage=never I can't see the bug anymore.
> >>
> > Can you test https://patchwork.kernel.org/patch/9061351/ with 4.5
> > (does not apply to 3.10) and without transparent_hugepage=never
> >
> > Jérôme
> 
> Fails with 4.5 + this patch and with 4.5 + this patch + yours
> 

There must be some bug in your code, we have upstream user that works
fine with the above combination (see drivers/vfio/vfio_iommu_type1.c)
i suspect you might be releasing the page pin too early (put_page()).

If you really believe it is bug upstream we would need a dumb kernel
module that does gup like you do and that shows the issue. Right now
looking at code (assuming above patches applied) i can't see anything
that can go wrong with THP.

Cheers,
Jérôme

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

[Jerome Glisse]

On Thu, May 12, 2016 at 03:30:24PM +0200, Nicolas Morey-Chaisemartin wrote:
> Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
> > On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote:
> >>
> >> Le 05/11/2016 à 04:51 PM, Jerome Glisse a écrit :
> >>> On Wed, May 11, 2016 at 01:15:54PM +0200, Nicolas Morey Chaisemartin 
> >>> wrote:
>  Le 05/10/2016 à 12:01 PM, Jerome Glisse a écrit :
> > On Tue, May 10, 2016 at 09:04:36AM +0200, Nicolas Morey Chaisemartin 
> > wrote:
> >> Le 05/03/2016 à 12:11 PM, Jerome Glisse a écrit :
> >>> On Mon, May 02, 2016 at 09:04:02PM -0700, Hugh Dickins wrote:
>  On Fri, 29 Apr 2016, Nicolas Morey Chaisemartin wrote:
>  [...]
> >> Hi,
> >>
> >> I backported the patch to 3.10 (had to copy paste pmd_protnone 
> >> defitinition from 4.5) and it's working !
> >> I'll open a ticket in Redhat tracker to try and get this fixed in 
> >> RHEL7.
> >>
> >> I have a dumb question though: how can we end up in numa/misplaced 
> >> memory code on a single socket system?
> >>
> > This patch is not a fix, do you see bug message in kernel log ? Because 
> > if
> > you do that it means we have a bigger issue.
> >
> > You did not answer one of my previous question, do you set 
> > get_user_pages
> > with write = 1 as a paremeter ?
> >
> > Also it would be a lot easier if you were testing with lastest 4.6 or 
> > 4.5
> > not RHEL kernel as they are far appart and what might looks like same 
> > issue
> > on both might be totaly different bugs.
> >
> > If you only really care about RHEL kernel then open a bug with Red Hat 
> > and
> > you can add me in bug-cc 
> >
> > Cheers,
> > Jérôme
>  I finally managed to get a proper setup.
>  I build a vanilla 4.5 kernel from git tree using the Centos7 config, my 
>  test fails as usual.
>  I applied your patch, rebuild => still fails and no new messages in 
>  dmesg.
> 
>  Now that I don't have to go through the RPM repackaging, I can try out 
>  things much quicker if you have any ideas.
> 
> >>> Still an issue if you boot with transparent_hugepage=never ?
> >>>
> >>> Also to simplify investigation force write to 1 all the time no matter 
> >>> what.
> >>>
> >>> Cheers,
> >>> Jérôme
> >> With transparent_hugepage=never I can't see the bug anymore.
> >>
> > Can you test https://patchwork.kernel.org/patch/9061351/ with 4.5
> > (does not apply to 3.10) and without transparent_hugepage=never
> >
> > Jérôme
> 
> Fails with 4.5 + this patch and with 4.5 + this patch + yours
> 

There must be some bug in your code, we have upstream user that works
fine with the above combination (see drivers/vfio/vfio_iommu_type1.c)
i suspect you might be releasing the page pin too early (put_page()).

If you really believe it is bug upstream we would need a dumb kernel
module that does gup like you do and that shows the issue. Right now
looking at code (assuming above patches applied) i can't see anything
that can go wrong with THP.

Cheers,
Jérôme

Re: next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Borislav Petkov]

On Thu, May 12, 2016 at 06:34:29AM -0700, Guenter Roeck wrote:
> Borislav,
> 
> your patch 'locking/rwsem, x86: Clean up down_write()' causes various
> crashes in x86 qemu tests.

Thanks for the report, let me take a look.

@Ingo: can you please back this one out of the lineup for the merge
window until I've sorted out the issue?

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

Re: next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Borislav Petkov]

On Thu, May 12, 2016 at 06:34:29AM -0700, Guenter Roeck wrote:
> Borislav,
> 
> your patch 'locking/rwsem, x86: Clean up down_write()' causes various
> crashes in x86 qemu tests.

Thanks for the report, let me take a look.

@Ingo: can you please back this one out of the lineup for the merge
window until I've sorted out the issue?

Thanks.

-- 
Regards/Gruss,
Boris.

SUSE Linux GmbH, GF: Felix Imendörffer, Jane Smithard, Graham Norton, HRB 21284 
(AG Nürnberg)
-- 

[PATCH v4] platform:x86: Add PMC Driver for Intel Core SOC

[Rajneesh Bhardwaj]

This patch adds the Power Management Controller driver as a pci driver
for Intel Core SOC architecture.

This driver can utilize debugging capabilities and supported features
as exposed by the Power Management Controller.

Please refer to the below specification for more details on PMC features.
http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html

The current version of this driver exposes slp_s0_residency counter.
This counter can be used for detecting fragile SLP_S0 signal related
failures and take corrective actions when PCH SLP_S0 signal is not
asserted after kernel freeze as part of suspend to idle flow
(echo freeze > /sys/power/state).

Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
detects favorable conditions to enter its low power mode. As a
pre-requisite the SOC should be in deepest possible Package C-State
and devices should be in low power mode. For example, on Skylake SOC
the deepest Package C-State is Package C10 or PC10. Suspend to idle
flow generally leads to PC10 state but PC10 state may not be sufficient
for realizing the platform wide power potential which SLP_S0 signal
assertion can provide.

SLP_S0 signal is often connected to the Embedded Controller (EC) and the
Power Management IC (PMIC) for other platform power management related
optimizations.

In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
power gated + PLL Idle.

As part of this driver, a mechanism to read the slp_s0 residency is exposed
as an api and also debugfs features are added to indicate slp_s0 signal
assertion residency in microseconds.

echo freeze > /sys/power/state
wake the system
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec

Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Vishwanath Somayaji 
---
Changes in v4:
 * Moved the header file to drivers/platform/x86 directory.
 * Updated the same in MAINTAINERS.
 * Removed 'default y' option from Kconfig.
 * Introduced static inline dummy functions for debugfs register
   and unregister case when CONFIG_DEBUG_FS is not set. Removed 
   #if IS_ENABLED(CONFIG_DEBUG_FS) check from .probe and .remove calls.
 * Add CC to LKML (linux-kernel@vger.kernel.org)
 * Earlier review comments till v3 are available at:
   - http://www.spinics.net/lists/platform-driver-x86/msg08790.html
   - http://www.spinics.net/lists/platform-driver-x86/msg08759.html
   - http://www.spinics.net/lists/platform-driver-x86/msg08742.html

Changes in v3:
 * Updated the commit message, added reference to the chipset datasheet.
 * Renamed the header file to intel_pmc_core.h for consistency.
 * Added All rights reserved notification after the Copyright message.
 * Improved variable names in the header file. Added SPT prefix.
 * Fixed kernel-doc related whitespace and comma issues for struct pmc_dev.
 * Changed feature_available to bool has_slp_s0_res.
 * Enhanced the Kconfig description as per the review suggestions.
 * Added error propagating logic to pmc_core_dev_state_show.
 * Streamlined intel_pmc_slp_s0_counter_read as per the review comments.
 * Streamlined the use of #if IS_ENABLED(CONFIG_DEBUG_FS) while registering
   debugfs in the probe call.
 * Removed the *duplicate definition* of pmc_core_debugfs_register.
 * Added MAINTAINERS related changes.
 * Checkpatch warning due to long URL name in the commit message.

Changes in v2:
 * Fixed inconsistent spaces in the header file.
 * Updated commit message.
 * Enhanced acronym SKL CPU to Skylake CPUID Signature.
 * Put error check on pci_read_config_dword in probe function.
 * Changed goto label (disable) to disable_pci.
 * Changed x86_match_cpu error handling for consistency.

 MAINTAINERS   |   8 ++
 drivers/platform/x86/Kconfig  |  12 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/intel_pmc_core.c | 201 ++
 drivers/platform/x86/intel_pmc_core.h |  54 +
 5 files changed, 276 insertions(+)
 create mode 100644 drivers/platform/x86/intel_pmc_core.c
 create mode 100644 drivers/platform/x86/intel_pmc_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d5b4be..9164949 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5879,6 +5879,14 @@ S:   Maintained
 F: arch/x86/include/asm/intel_telemetry.h
 F: drivers/platform/x86/intel_telemetry*
 
+INTEL PMC CORE DRIVER
+M:  Rajneesh Bhardwaj 
+M:  Vishwanath Somayaji 
+L:  platform-driver-...@vger.kernel.org
+S:  Maintained
+F:  drivers/platform/x86/intel_pmc_core.h
+F:  drivers/platform/x86/intel_pmc_core.c
+
 IOC3 ETHERNET DRIVER
 M: Ralf Baechle 
 L: linux-m...@linux-mips.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ed2004b..2d2b3f6 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -821,6 

[PATCH v4] platform:x86: Add PMC Driver for Intel Core SOC

[Rajneesh Bhardwaj]

This patch adds the Power Management Controller driver as a pci driver
for Intel Core SOC architecture.

This driver can utilize debugging capabilities and supported features
as exposed by the Power Management Controller.

Please refer to the below specification for more details on PMC features.
http://www.intel.in/content/www/in/en/chipsets/100-series-chipset-datasheet-vol-2.html

The current version of this driver exposes slp_s0_residency counter.
This counter can be used for detecting fragile SLP_S0 signal related
failures and take corrective actions when PCH SLP_S0 signal is not
asserted after kernel freeze as part of suspend to idle flow
(echo freeze > /sys/power/state).

Intel Platform Controller Hub (PCH) asserts SLP_S0 signal when it
detects favorable conditions to enter its low power mode. As a
pre-requisite the SOC should be in deepest possible Package C-State
and devices should be in low power mode. For example, on Skylake SOC
the deepest Package C-State is Package C10 or PC10. Suspend to idle
flow generally leads to PC10 state but PC10 state may not be sufficient
for realizing the platform wide power potential which SLP_S0 signal
assertion can provide.

SLP_S0 signal is often connected to the Embedded Controller (EC) and the
Power Management IC (PMIC) for other platform power management related
optimizations.

In general, SLP_S0 assertion == PC10 + PCH low power mode + ModPhy Lanes
power gated + PLL Idle.

As part of this driver, a mechanism to read the slp_s0 residency is exposed
as an api and also debugfs features are added to indicate slp_s0 signal
assertion residency in microseconds.

echo freeze > /sys/power/state
wake the system
cat /sys/kernel/debug/pmc_core/slp_s0_residency_usec

Signed-off-by: Rajneesh Bhardwaj 
Signed-off-by: Vishwanath Somayaji 
---
Changes in v4:
 * Moved the header file to drivers/platform/x86 directory.
 * Updated the same in MAINTAINERS.
 * Removed 'default y' option from Kconfig.
 * Introduced static inline dummy functions for debugfs register
   and unregister case when CONFIG_DEBUG_FS is not set. Removed 
   #if IS_ENABLED(CONFIG_DEBUG_FS) check from .probe and .remove calls.
 * Add CC to LKML (linux-kernel@vger.kernel.org)
 * Earlier review comments till v3 are available at:
   - http://www.spinics.net/lists/platform-driver-x86/msg08790.html
   - http://www.spinics.net/lists/platform-driver-x86/msg08759.html
   - http://www.spinics.net/lists/platform-driver-x86/msg08742.html

Changes in v3:
 * Updated the commit message, added reference to the chipset datasheet.
 * Renamed the header file to intel_pmc_core.h for consistency.
 * Added All rights reserved notification after the Copyright message.
 * Improved variable names in the header file. Added SPT prefix.
 * Fixed kernel-doc related whitespace and comma issues for struct pmc_dev.
 * Changed feature_available to bool has_slp_s0_res.
 * Enhanced the Kconfig description as per the review suggestions.
 * Added error propagating logic to pmc_core_dev_state_show.
 * Streamlined intel_pmc_slp_s0_counter_read as per the review comments.
 * Streamlined the use of #if IS_ENABLED(CONFIG_DEBUG_FS) while registering
   debugfs in the probe call.
 * Removed the *duplicate definition* of pmc_core_debugfs_register.
 * Added MAINTAINERS related changes.
 * Checkpatch warning due to long URL name in the commit message.

Changes in v2:
 * Fixed inconsistent spaces in the header file.
 * Updated commit message.
 * Enhanced acronym SKL CPU to Skylake CPUID Signature.
 * Put error check on pci_read_config_dword in probe function.
 * Changed goto label (disable) to disable_pci.
 * Changed x86_match_cpu error handling for consistency.

 MAINTAINERS   |   8 ++
 drivers/platform/x86/Kconfig  |  12 ++
 drivers/platform/x86/Makefile |   1 +
 drivers/platform/x86/intel_pmc_core.c | 201 ++
 drivers/platform/x86/intel_pmc_core.h |  54 +
 5 files changed, 276 insertions(+)
 create mode 100644 drivers/platform/x86/intel_pmc_core.c
 create mode 100644 drivers/platform/x86/intel_pmc_core.h

diff --git a/MAINTAINERS b/MAINTAINERS
index 1d5b4be..9164949 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -5879,6 +5879,14 @@ S:   Maintained
 F: arch/x86/include/asm/intel_telemetry.h
 F: drivers/platform/x86/intel_telemetry*
 
+INTEL PMC CORE DRIVER
+M:  Rajneesh Bhardwaj 
+M:  Vishwanath Somayaji 
+L:  platform-driver-...@vger.kernel.org
+S:  Maintained
+F:  drivers/platform/x86/intel_pmc_core.h
+F:  drivers/platform/x86/intel_pmc_core.c
+
 IOC3 ETHERNET DRIVER
 M: Ralf Baechle 
 L: linux-m...@linux-mips.org
diff --git a/drivers/platform/x86/Kconfig b/drivers/platform/x86/Kconfig
index ed2004b..2d2b3f6 100644
--- a/drivers/platform/x86/Kconfig
+++ b/drivers/platform/x86/Kconfig
@@ -821,6 +821,18 @@ config INTEL_IPS
  functionality.  If in doubt, say Y here; it will only load on
  supported platforms.
 
+config 

Re: [PATCH v2] tpm: Fix suspend regression

[Jarkko Sakkinen]

On Wed, May 11, 2016 at 11:28:27AM -0400, Stefan Berger wrote:
> Fix the suspend regression due to the wrong way of retrieving the
> chip structure. The suspend functions are attached to the hardware
> device, not the chip and thus must rely on drvdata.
> 
> Fixes: e89f8b1ade9cc1a ("tpm: Remove all uses of drvdata from the TPM Core")
> Reported-by: Jeremiah Mahler 
> Signed-off-by: Stefan Berger 
> Tested-by: Stefan Berger 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Jeremiah Mahler 

Acked-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/tpm-interface.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c 
> b/drivers/char/tpm/tpm-interface.c
> index 080dade..5e3c1b6 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -934,7 +934,7 @@ static struct tpm_input_header savestate_header = {
>   */
>  int tpm_pm_suspend(struct device *dev)
>  {
> - struct tpm_chip *chip = to_tpm_chip(dev);
> + struct tpm_chip *chip = dev_get_drvdata(dev);
>   struct tpm_cmd_t cmd;
>   int rc, try;
>  
> @@ -995,7 +995,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_suspend);
>   */
>  int tpm_pm_resume(struct device *dev)
>  {
> - struct tpm_chip *chip = to_tpm_chip(dev);
> + struct tpm_chip *chip = dev_get_drvdata(dev);
>  
>   if (chip == NULL)
>   return -ENODEV;
> -- 
> 2.4.3
> 

Re: [PATCH v2] tpm: Fix suspend regression

[Jarkko Sakkinen]

On Wed, May 11, 2016 at 11:28:27AM -0400, Stefan Berger wrote:
> Fix the suspend regression due to the wrong way of retrieving the
> chip structure. The suspend functions are attached to the hardware
> device, not the chip and thus must rely on drvdata.
> 
> Fixes: e89f8b1ade9cc1a ("tpm: Remove all uses of drvdata from the TPM Core")
> Reported-by: Jeremiah Mahler 
> Signed-off-by: Stefan Berger 
> Tested-by: Stefan Berger 
> Reviewed-by: Jason Gunthorpe 
> Tested-by: Jeremiah Mahler 

Acked-by: Jarkko Sakkinen 

/Jarkko

> ---
>  drivers/char/tpm/tpm-interface.c | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/drivers/char/tpm/tpm-interface.c 
> b/drivers/char/tpm/tpm-interface.c
> index 080dade..5e3c1b6 100644
> --- a/drivers/char/tpm/tpm-interface.c
> +++ b/drivers/char/tpm/tpm-interface.c
> @@ -934,7 +934,7 @@ static struct tpm_input_header savestate_header = {
>   */
>  int tpm_pm_suspend(struct device *dev)
>  {
> - struct tpm_chip *chip = to_tpm_chip(dev);
> + struct tpm_chip *chip = dev_get_drvdata(dev);
>   struct tpm_cmd_t cmd;
>   int rc, try;
>  
> @@ -995,7 +995,7 @@ EXPORT_SYMBOL_GPL(tpm_pm_suspend);
>   */
>  int tpm_pm_resume(struct device *dev)
>  {
> - struct tpm_chip *chip = to_tpm_chip(dev);
> + struct tpm_chip *chip = dev_get_drvdata(dev);
>  
>   if (chip == NULL)
>   return -ENODEV;
> -- 
> 2.4.3
> 

Re: [PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:
> Add drm_fb_cma_create_with_funcs() for drivers that need to set the
> dirty() callback.
> 
> Cc: laurent.pinch...@ideasonboard.com
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes since v1:
> - Expand docs
> 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
>  include/drm/drm_fb_cma_helper.h |  3 +++
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
> drm_device *dev, }
> 
>  /**
> - * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
> callback function
> + * drm_fb_cma_create_with_funcs() - helper function for the
> + *  _mode_config_funcs ->fb_create
> + *  callback function
>   *
> - * If your hardware has special alignment or pitch requirements these
> should be
> - * checked before calling this function.
> + * This can be used to set _framebuffer_funcs for drivers that need the
> + * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
> * _framebuffer_funcs.
>   */
> -struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs)

Shouldn't the funcs argument be const ?

Apart from that,

Acked-by: Laurent Pinchart 

>  {
>   struct drm_fb_cma *fb_cma;
>   struct drm_gem_cma_object *objs[4];
> @@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
> drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
>   }
> 
> - fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
> + fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
>   if (IS_ERR(fb_cma)) {
>   ret = PTR_ERR(fb_cma);
>   goto err_gem_object_unreference;
> @@ -215,6 +219,21 @@ err_gem_object_unreference:
>   drm_gem_object_unreference_unlocked([i]->base);
>   return ERR_PTR(ret);
>  }
> +EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
> +
> +/**
> + * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
> function
> + *
> + * If your hardware has special alignment or pitch requirements these
> should be
> + * checked before calling this function. Use drm_fb_cma_create_with_funcs()
> if
> + * you need to set _framebuffer_funcs ->dirty.
> + */
> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
> + _fb_cma_funcs);
> +}
>  EXPORT_SYMBOL_GPL(drm_fb_cma_create);
> 
>  /**
> diff --git a/include/drm/drm_fb_cma_helper.h
> b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
>  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
>   struct drm_file *file_priv, unsigned int *handle);
> 
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs);
>  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

-- 
Regards,

Laurent Pinchart

Re: [PATCH v3 1/2] drm/fb-cma-helper: Add function drm_fb_cma_create_with_funcs()

[Laurent Pinchart]

Hi Noralf,

Thank you for the patch.

On Thursday 12 May 2016 14:53:25 Noralf Trønnes wrote:
> Add drm_fb_cma_create_with_funcs() for drivers that need to set the
> dirty() callback.
> 
> Cc: laurent.pinch...@ideasonboard.com
> Signed-off-by: Noralf Trønnes 
> ---
> 
> Changes since v1:
> - Expand docs
> 
>  drivers/gpu/drm/drm_fb_cma_helper.c | 31 +--
>  include/drm/drm_fb_cma_helper.h |  3 +++
>  2 files changed, 28 insertions(+), 6 deletions(-)
> 
> diff --git a/drivers/gpu/drm/drm_fb_cma_helper.c
> b/drivers/gpu/drm/drm_fb_cma_helper.c index 3165ac0..ede77c9 100644
> --- a/drivers/gpu/drm/drm_fb_cma_helper.c
> +++ b/drivers/gpu/drm/drm_fb_cma_helper.c
> @@ -159,13 +159,17 @@ static struct drm_fb_cma *drm_fb_cma_alloc(struct
> drm_device *dev, }
> 
>  /**
> - * drm_fb_cma_create() - (struct drm_mode_config_funcs *)->fb_create
> callback function
> + * drm_fb_cma_create_with_funcs() - helper function for the
> + *  _mode_config_funcs ->fb_create
> + *  callback function
>   *
> - * If your hardware has special alignment or pitch requirements these
> should be
> - * checked before calling this function.
> + * This can be used to set _framebuffer_funcs for drivers that need the
> + * dirty() callback. Use drm_fb_cma_create() if you don't need to change +
> * _framebuffer_funcs.
>   */
> -struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> - struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs)

Shouldn't the funcs argument be const ?

Apart from that,

Acked-by: Laurent Pinchart 

>  {
>   struct drm_fb_cma *fb_cma;
>   struct drm_gem_cma_object *objs[4];
> @@ -202,7 +206,7 @@ struct drm_framebuffer *drm_fb_cma_create(struct
> drm_device *dev, objs[i] = to_drm_gem_cma_obj(obj);
>   }
> 
> - fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, _fb_cma_funcs);
> + fb_cma = drm_fb_cma_alloc(dev, mode_cmd, objs, i, funcs);
>   if (IS_ERR(fb_cma)) {
>   ret = PTR_ERR(fb_cma);
>   goto err_gem_object_unreference;
> @@ -215,6 +219,21 @@ err_gem_object_unreference:
>   drm_gem_object_unreference_unlocked([i]->base);
>   return ERR_PTR(ret);
>  }
> +EXPORT_SYMBOL_GPL(drm_fb_cma_create_with_funcs);
> +
> +/**
> + * drm_fb_cma_create() - _mode_config_funcs ->fb_create callback
> function
> + *
> + * If your hardware has special alignment or pitch requirements these
> should be
> + * checked before calling this function. Use drm_fb_cma_create_with_funcs()
> if
> + * you need to set _framebuffer_funcs ->dirty.
> + */
> +struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd)
> +{
> + return drm_fb_cma_create_with_funcs(dev, file_priv, mode_cmd,
> + _fb_cma_funcs);
> +}
>  EXPORT_SYMBOL_GPL(drm_fb_cma_create);
> 
>  /**
> diff --git a/include/drm/drm_fb_cma_helper.h
> b/include/drm/drm_fb_cma_helper.h index c6d9c9c..1f9a8bc 100644
> --- a/include/drm/drm_fb_cma_helper.h
> +++ b/include/drm/drm_fb_cma_helper.h
> @@ -31,6 +31,9 @@ void drm_fb_cma_destroy(struct drm_framebuffer *fb);
>  int drm_fb_cma_create_handle(struct drm_framebuffer *fb,
>   struct drm_file *file_priv, unsigned int *handle);
> 
> +struct drm_framebuffer *drm_fb_cma_create_with_funcs(struct drm_device
> *dev,
> + struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd,
> + struct drm_framebuffer_funcs *funcs);
>  struct drm_framebuffer *drm_fb_cma_create(struct drm_device *dev,
>   struct drm_file *file_priv, const struct drm_mode_fb_cmd2 *mode_cmd);

-- 
Regards,

Laurent Pinchart

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > of vector, and kernel reports successful read/write.
> > 
> > There are 2 problems:
> > 1. How kernel allows such address to be passed to fs subsystem;
> > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > address.
> > 
> > I don't know the answer on 2'nd question, and it might be something
> > generic. But I investigated first problem.
> > 
> > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > validate user address, and on arm64 it ends up with checking buffer
> > end against current_thread_info()->addr_limit.
> > 
> > current_thread_info()->addr_limit for ilp32, and most probably for
> > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > It happens because on thread creation we call flush_old_exec() to set 
> > addr_limit, and completely ignore compat mode there.
> 
> I assume accesses beyond this address would fault anyway but I haven't
> checked the code paths.
> 
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index 7a39683..6ba4952 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/include/asm/elf.h
> > @@ -146,6 +146,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> >  do {   \
> > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > clear_thread_flag(TIF_32BIT);   \
> > +   set_fs(TASK_SIZE_64);   \
> >  } while (0)
> 
> See below.
> 
> > diff --git a/arch/arm64/include/asm/uaccess.h 
> > b/arch/arm64/include/asm/uaccess.h
> > index 19cfdc5..3b0dd8d 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -51,7 +51,7 @@
> >  #define KERNEL_DS  (-1UL)
> >  #define get_ds()   (KERNEL_DS)
> >  
> > -#define USER_DSTASK_SIZE_64
> > +#define USER_DSTASK_SIZE
> 
> I agree with this.
> 
> >  #define get_fs()   (current_thread_info()->addr_limit)
> >  
> >  static inline void set_fs(mm_segment_t fs)
> > diff --git a/arch/arm64/kernel/binfmt_elf32.c 
> > b/arch/arm64/kernel/binfmt_elf32.c
> > index 5487872..2e8d9f3 100644
> > --- a/arch/arm64/kernel/binfmt_elf32.c
> > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > @@ -12,6 +12,7 @@
> >  do {   \
> > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > set_thread_flag(TIF_32BIT); \
> > +   set_fs(TASK_SIZE_32);   \
> >  } while (0)
> >  
> >  #define COMPAT_ARCH_DLINFO
> > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > b/arch/arm64/kernel/binfmt_ilp32.c
> > index a934fd4..a8599c6 100644
> > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > cputime,
> >  do {   
> > \
> > set_thread_flag(TIF_32BIT_AARCH64); \
> > clear_thread_flag(TIF_32BIT);   \
> > +   set_fs(TASK_SIZE_32);   \
> >  } while (0)
> 
> I don't think we need these two. AFAICT, flush_old_exec() takes care of
> setting the USER_DS for the new thread.

That's true, but USER_DS depends on personality which is not set yet
for new thread, as I wrote above. In fact, I tried correct USER_DS
only, and it doesn't work

> 
> -- 
> Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Yury Norov]

On Thu, May 12, 2016 at 02:35:34PM +0100, Catalin Marinas wrote:
> On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> > I debugged preadv02 and pwritev02 failures and found very weird bug.
> > Test passes {iovec_base = 0x, iovec_len = 64} as one element
> > of vector, and kernel reports successful read/write.
> > 
> > There are 2 problems:
> > 1. How kernel allows such address to be passed to fs subsystem;
> > 2. How fs successes to read/write at non-mapped, and in fact non-user
> > address.
> > 
> > I don't know the answer on 2'nd question, and it might be something
> > generic. But I investigated first problem.
> > 
> > The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> > validate user address, and on arm64 it ends up with checking buffer
> > end against current_thread_info()->addr_limit.
> > 
> > current_thread_info()->addr_limit for ilp32, and most probably for
> > aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> > It happens because on thread creation we call flush_old_exec() to set 
> > addr_limit, and completely ignore compat mode there.
> 
> I assume accesses beyond this address would fault anyway but I haven't
> checked the code paths.
> 
> > diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> > index 7a39683..6ba4952 100644
> > --- a/arch/arm64/include/asm/elf.h
> > +++ b/arch/arm64/include/asm/elf.h
> > @@ -146,6 +146,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
> >  do {   \
> > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > clear_thread_flag(TIF_32BIT);   \
> > +   set_fs(TASK_SIZE_64);   \
> >  } while (0)
> 
> See below.
> 
> > diff --git a/arch/arm64/include/asm/uaccess.h 
> > b/arch/arm64/include/asm/uaccess.h
> > index 19cfdc5..3b0dd8d 100644
> > --- a/arch/arm64/include/asm/uaccess.h
> > +++ b/arch/arm64/include/asm/uaccess.h
> > @@ -51,7 +51,7 @@
> >  #define KERNEL_DS  (-1UL)
> >  #define get_ds()   (KERNEL_DS)
> >  
> > -#define USER_DSTASK_SIZE_64
> > +#define USER_DSTASK_SIZE
> 
> I agree with this.
> 
> >  #define get_fs()   (current_thread_info()->addr_limit)
> >  
> >  static inline void set_fs(mm_segment_t fs)
> > diff --git a/arch/arm64/kernel/binfmt_elf32.c 
> > b/arch/arm64/kernel/binfmt_elf32.c
> > index 5487872..2e8d9f3 100644
> > --- a/arch/arm64/kernel/binfmt_elf32.c
> > +++ b/arch/arm64/kernel/binfmt_elf32.c
> > @@ -12,6 +12,7 @@
> >  do {   \
> > clear_thread_flag(TIF_32BIT_AARCH64);   \
> > set_thread_flag(TIF_32BIT); \
> > +   set_fs(TASK_SIZE_32);   \
> >  } while (0)
> >  
> >  #define COMPAT_ARCH_DLINFO
> > diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> > b/arch/arm64/kernel/binfmt_ilp32.c
> > index a934fd4..a8599c6 100644
> > --- a/arch/arm64/kernel/binfmt_ilp32.c
> > +++ b/arch/arm64/kernel/binfmt_ilp32.c
> > @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> > cputime,
> >  do {   
> > \
> > set_thread_flag(TIF_32BIT_AARCH64); \
> > clear_thread_flag(TIF_32BIT);   \
> > +   set_fs(TASK_SIZE_32);   \
> >  } while (0)
> 
> I don't think we need these two. AFAICT, flush_old_exec() takes care of
> setting the USER_DS for the new thread.

That's true, but USER_DS depends on personality which is not set yet
for new thread, as I wrote above. In fact, I tried correct USER_DS
only, and it doesn't work

> 
> -- 
> Catalin

Re: [RFC 05/13] mm, page_alloc: make THP-specific decisions more generic

[Michal Hocko]

On Tue 10-05-16 09:35:55, Vlastimil Babka wrote:
> Since THP allocations during page faults can be costly, extra decisions are
> employed for them to avoid excessive reclaim and compaction, if the initial
> compaction doesn't look promising. The detection has never been perfect as
> there is no gfp flag specific to THP allocations. At this moment it checks the
> whole combination of flags that makes up GFP_TRANSHUGE, and hopes that no 
> other
> users of such combination exist, or would mind being treated the same way.
> Extra care is also taken to separate allocations from khugepaged, where 
> latency
> doesn't matter that much.
> 
> It is however possible to distinguish these allocations in a simpler and more
> reliable way. The key observation is that after the initial compaction 
> followed
> by the first iteration of "standard" reclaim/compaction, both __GFP_NORETRY
> allocations and costly allocations without __GFP_REPEAT are declared as
> failures:
> 
> /* Do not loop if specifically requested */
> if (gfp_mask & __GFP_NORETRY)
> goto nopage;
> 
> /*
>  * Do not retry costly high order allocations unless they are
>  * __GFP_REPEAT
>  */
> if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
> goto nopage;
> 
> This means we can further distinguish allocations that are costly order *and*
> additionally include the __GFP_NORETRY flag. As it happens, GFP_TRANSHUGE
> allocations do already fall into this category. This will also allow other
> costly allocations with similar high-order benefit vs latency considerations 
> to
> use this semantic. Furthermore, we can distinguish THP allocations that should
> try a bit harder (such as from khugepageed) by removing __GFP_NORETRY, as will
> be done in the next patch.

Yes, using __GFP_NORETRY makes perfect sense. It is the weakest mode for
the costly allocation which includes both compaction and reclaim. I am
happy to see is_thp_gfp_mask going away.

> Signed-off-by: Vlastimil Babka 

Acked-by: Michal Hocko 

> ---
>  mm/page_alloc.c | 22 +-
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 88d680b3e7b6..f5d931e0854a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3182,7 +3182,6 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int 
> order,
>   return page;
>  }
>  
> -
>  /*
>   * Maximum number of compaction retries wit a progress before OOM
>   * killer is consider as the only way to move forward.
> @@ -3447,11 +3446,6 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
>   return !!(gfp_to_alloc_flags(gfp_mask) & ALLOC_NO_WATERMARKS);
>  }
>  
> -static inline bool is_thp_gfp_mask(gfp_t gfp_mask)
> -{
> - return (gfp_mask & (GFP_TRANSHUGE | __GFP_KSWAPD_RECLAIM)) == 
> GFP_TRANSHUGE;
> -}
> -
>  /*
>   * Maximum number of reclaim retries without any progress before OOM killer
>   * is consider as the only way to move forward.
> @@ -3610,8 +3604,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
> order,
>   if (page)
>   goto got_pg;
>  
> - /* Checks for THP-specific high-order allocations */
> - if (is_thp_gfp_mask(gfp_mask)) {
> + /*
> +  * Checks for costly allocations with __GFP_NORETRY, which
> +  * includes THP page fault allocations
> +  */
> + if (gfp_mask & __GFP_NORETRY) {
>   /*
>* If compaction is deferred for high-order allocations,
>* it is because sync compaction recently failed. If
> @@ -3631,11 +3628,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
> order,
>   goto nopage;
>  
>   /*
> -  * It can become very expensive to allocate transparent
> -  * hugepages at fault, so use asynchronous memory
> -  * compaction for THP unless it is khugepaged trying to
> -  * collapse. All other requests should tolerate at
> -  * least light sync migration.
> +  * Looks like reclaim/compaction is worth trying, but
> +  * sync compaction could be very expensive, so keep
> +  * using async compaction, unless it's khugepaged
> +  * trying to collapse.
>*/
>   if (!(current->flags & PF_KTHREAD))
>   migration_mode = MIGRATE_ASYNC;
> -- 
> 2.8.2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [RFC 05/13] mm, page_alloc: make THP-specific decisions more generic

[Michal Hocko]

On Tue 10-05-16 09:35:55, Vlastimil Babka wrote:
> Since THP allocations during page faults can be costly, extra decisions are
> employed for them to avoid excessive reclaim and compaction, if the initial
> compaction doesn't look promising. The detection has never been perfect as
> there is no gfp flag specific to THP allocations. At this moment it checks the
> whole combination of flags that makes up GFP_TRANSHUGE, and hopes that no 
> other
> users of such combination exist, or would mind being treated the same way.
> Extra care is also taken to separate allocations from khugepaged, where 
> latency
> doesn't matter that much.
> 
> It is however possible to distinguish these allocations in a simpler and more
> reliable way. The key observation is that after the initial compaction 
> followed
> by the first iteration of "standard" reclaim/compaction, both __GFP_NORETRY
> allocations and costly allocations without __GFP_REPEAT are declared as
> failures:
> 
> /* Do not loop if specifically requested */
> if (gfp_mask & __GFP_NORETRY)
> goto nopage;
> 
> /*
>  * Do not retry costly high order allocations unless they are
>  * __GFP_REPEAT
>  */
> if (order > PAGE_ALLOC_COSTLY_ORDER && !(gfp_mask & __GFP_REPEAT))
> goto nopage;
> 
> This means we can further distinguish allocations that are costly order *and*
> additionally include the __GFP_NORETRY flag. As it happens, GFP_TRANSHUGE
> allocations do already fall into this category. This will also allow other
> costly allocations with similar high-order benefit vs latency considerations 
> to
> use this semantic. Furthermore, we can distinguish THP allocations that should
> try a bit harder (such as from khugepageed) by removing __GFP_NORETRY, as will
> be done in the next patch.

Yes, using __GFP_NORETRY makes perfect sense. It is the weakest mode for
the costly allocation which includes both compaction and reclaim. I am
happy to see is_thp_gfp_mask going away.

> Signed-off-by: Vlastimil Babka 

Acked-by: Michal Hocko 

> ---
>  mm/page_alloc.c | 22 +-
>  1 file changed, 9 insertions(+), 13 deletions(-)
> 
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> index 88d680b3e7b6..f5d931e0854a 100644
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -3182,7 +3182,6 @@ __alloc_pages_may_oom(gfp_t gfp_mask, unsigned int 
> order,
>   return page;
>  }
>  
> -
>  /*
>   * Maximum number of compaction retries wit a progress before OOM
>   * killer is consider as the only way to move forward.
> @@ -3447,11 +3446,6 @@ bool gfp_pfmemalloc_allowed(gfp_t gfp_mask)
>   return !!(gfp_to_alloc_flags(gfp_mask) & ALLOC_NO_WATERMARKS);
>  }
>  
> -static inline bool is_thp_gfp_mask(gfp_t gfp_mask)
> -{
> - return (gfp_mask & (GFP_TRANSHUGE | __GFP_KSWAPD_RECLAIM)) == 
> GFP_TRANSHUGE;
> -}
> -
>  /*
>   * Maximum number of reclaim retries without any progress before OOM killer
>   * is consider as the only way to move forward.
> @@ -3610,8 +3604,11 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
> order,
>   if (page)
>   goto got_pg;
>  
> - /* Checks for THP-specific high-order allocations */
> - if (is_thp_gfp_mask(gfp_mask)) {
> + /*
> +  * Checks for costly allocations with __GFP_NORETRY, which
> +  * includes THP page fault allocations
> +  */
> + if (gfp_mask & __GFP_NORETRY) {
>   /*
>* If compaction is deferred for high-order allocations,
>* it is because sync compaction recently failed. If
> @@ -3631,11 +3628,10 @@ __alloc_pages_slowpath(gfp_t gfp_mask, unsigned int 
> order,
>   goto nopage;
>  
>   /*
> -  * It can become very expensive to allocate transparent
> -  * hugepages at fault, so use asynchronous memory
> -  * compaction for THP unless it is khugepaged trying to
> -  * collapse. All other requests should tolerate at
> -  * least light sync migration.
> +  * Looks like reclaim/compaction is worth trying, but
> +  * sync compaction could be very expensive, so keep
> +  * using async compaction, unless it's khugepaged
> +  * trying to collapse.
>*/
>   if (!(current->flags & PF_KTHREAD))
>   migration_mode = MIGRATE_ASYNC;
> -- 
> 2.8.2
> 
> --
> To unsubscribe, send a message with 'unsubscribe linux-mm' in
> the body to majord...@kvack.org.  For more info on Linux MM,
> see: http://www.linux-mm.org/ .
> Don't email: mailto:"d...@kvack.org;> em...@kvack.org 

-- 
Michal Hocko
SUSE Labs

Re: [PATCH] pinctrl: stm32: Implement .pin_config_dbg_show()

[Linus Walleij]

On Wed, May 11, 2016 at 3:40 PM, Patrice Chotard  wrote:
> On 05/10/2016 01:50 PM, Linus Walleij wrote:

> Sorry i didn't pay attention, but there is a compilation warning in this
> patch.
>
> drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for
> format [-Wformat-extra-args]
>speeds[speed], "speed");
>
>
> What do you prefer ?
>  _ me to submit a v2 fixing this warning and at the same occasion include
> the requested code factorization
>  _ or submit additionnal patchset ?

Just send a patch on top fixing this.

Yours,
Linus Walleij

Re: [PATCH] pinctrl: stm32: Implement .pin_config_dbg_show()

[Linus Walleij]

On Wed, May 11, 2016 at 3:40 PM, Patrice Chotard  wrote:
> On 05/10/2016 01:50 PM, Linus Walleij wrote:

> Sorry i didn't pay attention, but there is a compilation warning in this
> patch.
>
> drivers/pinctrl/stm32/pinctrl-stm32.c:823:7: warning: too many arguments for
> format [-Wformat-extra-args]
>speeds[speed], "speed");
>
>
> What do you prefer ?
>  _ me to submit a v2 fixing this warning and at the same occasion include
> the requested code factorization
>  _ or submit additionnal patchset ?

Just send a patch on top fixing this.

Yours,
Linus Walleij

Re: linux-next: build failure after merge of the pinctrl tree

[Linus Walleij]

Laxman, this must be due to one of the two top commits for tegra:

commit 1d18a3f0f0809f6c71f1f6e9e268ee904ce0b588
"pinctrl: tegra: avoid parked_reg and parked_bank"
commit b22ef2a0979f2b91cfeeabb086e4d665183a93a1
"pinctrl: tegra: Correctly check the supported configuration"

Is it something you can fix quickly or should I just revert both patches
for the time being?

Yours,
Linus Walleij

On Thu, May 12, 2016 at 6:14 AM, Stephen Rothwell  wrote:
> Hi Linus,
>
> After merging the pinctrl tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/thread_info.h:11:0,
>  from include/asm-generic/preempt.h:4,
>  from arch/arm/include/generated/asm/preempt.h:1,
>  from include/linux/preempt.h:59,
>  from include/linux/spinlock.h:50,
>  from include/linux/seqlock.h:35,
>  from include/linux/time.h:5,
>  from include/linux/stat.h:18,
>  from include/linux/module.h:10,
>  from drivers/pinctrl/tegra/pinctrl-tegra20.c:20:
> include/linux/bug.h:34:45: error: unknown field 'parked_reg' specified in 
> initializer
>  #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>  ^
> include/linux/compiler-gcc.h:64:28: note: in expansion of macro 
> 'BUILD_BUG_ON_ZERO'
>  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> ^
> include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2027:12: note: in expansion of macro 
> 'ARRAY_SIZE'
>.npins = ARRAY_SIZE(drive_##pg_name##_pins), \
> ^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2050:2: note: in expansion of macro 
> 'DRV_PG_EXT'
>   DRV_PG_EXT(pg_name, r, 2,  3,  4, 12, 20, 28, 2, 30, 2)
>   ^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2178:2: note: in expansion of macro 
> 'DRV_PG'
>   DRV_PG(ao1,0x868),
>   ^
>
> and many more.
>
> I cannot figure out what caused it, but using the pinctrl tree from
> next-20160511 makes it build again.
>
> I am using gcc 5.2.0 hosted on powerpcle, if that matters.
>
> --
> Cheers,
> Stephen Rothwell

Re: linux-next: build failure after merge of the pinctrl tree

[Linus Walleij]

Laxman, this must be due to one of the two top commits for tegra:

commit 1d18a3f0f0809f6c71f1f6e9e268ee904ce0b588
"pinctrl: tegra: avoid parked_reg and parked_bank"
commit b22ef2a0979f2b91cfeeabb086e4d665183a93a1
"pinctrl: tegra: Correctly check the supported configuration"

Is it something you can fix quickly or should I just revert both patches
for the time being?

Yours,
Linus Walleij

On Thu, May 12, 2016 at 6:14 AM, Stephen Rothwell  wrote:
> Hi Linus,
>
> After merging the pinctrl tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> In file included from include/linux/thread_info.h:11:0,
>  from include/asm-generic/preempt.h:4,
>  from arch/arm/include/generated/asm/preempt.h:1,
>  from include/linux/preempt.h:59,
>  from include/linux/spinlock.h:50,
>  from include/linux/seqlock.h:35,
>  from include/linux/time.h:5,
>  from include/linux/stat.h:18,
>  from include/linux/module.h:10,
>  from drivers/pinctrl/tegra/pinctrl-tegra20.c:20:
> include/linux/bug.h:34:45: error: unknown field 'parked_reg' specified in 
> initializer
>  #define BUILD_BUG_ON_ZERO(e) (sizeof(struct { int:-!!(e); }))
>  ^
> include/linux/compiler-gcc.h:64:28: note: in expansion of macro 
> 'BUILD_BUG_ON_ZERO'
>  #define __must_be_array(a) BUILD_BUG_ON_ZERO(__same_type((a), &(a)[0]))
> ^
> include/linux/kernel.h:54:59: note: in expansion of macro '__must_be_array'
>  #define ARRAY_SIZE(arr) (sizeof(arr) / sizeof((arr)[0]) + 
> __must_be_array(arr))
>^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2027:12: note: in expansion of macro 
> 'ARRAY_SIZE'
>.npins = ARRAY_SIZE(drive_##pg_name##_pins), \
> ^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2050:2: note: in expansion of macro 
> 'DRV_PG_EXT'
>   DRV_PG_EXT(pg_name, r, 2,  3,  4, 12, 20, 28, 2, 30, 2)
>   ^
> drivers/pinctrl/tegra/pinctrl-tegra20.c:2178:2: note: in expansion of macro 
> 'DRV_PG'
>   DRV_PG(ao1,0x868),
>   ^
>
> and many more.
>
> I cannot figure out what caused it, but using the pinctrl tree from
> next-20160511 makes it build again.
>
> I am using gcc 5.2.0 hosted on powerpcle, if that matters.
>
> --
> Cheers,
> Stephen Rothwell

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Yury Norov]

On Thu, May 12, 2016 at 03:06:39PM +0200, Arnd Bergmann wrote:
> On Thursday 12 May 2016 20:49:24 Zhangjian wrote:
> > Hi,
> > 
> > On 2016/5/12 17:21, Arnd Bergmann wrote:
> > > On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote:
> > >> On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote:
> > >>> On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote:
> > >>>
> > >>> I don't think the shifts are a problem, the main downside would be
> > >>> the limit to 44 bits of file offsets (16TB files), but it's also
> > >>> unclear if that is a practical problem at all. If it is, we run
> > >>> into the same problem on all other 32-bit architectures too.
> > >>
> > >> I hope people are seriously thinking of moving to an LP64 ABI if they
> > >> have such large file offset needs.
> > >
> > > Good point. 44 bits of file size is certainly enough for mmap()
> > > on a 32-bit task: you would only be able to map a very small fraction
> > > of the file anyway, and if you want to map larger files, and should
> > > move to 64-bit tasks long before this becomes a limitation.
> > Hi,
> > 
> > I apply the following patch in order to make use of the REAL mmmap2. LTP
> > test pass in litle endian. mmap16 successful with segfault in big endian.
> > 
> > BTW, I saw the similar code in tile, mips, microblaze and s390 compat. 
> > Should
> > we merge these code into a common syscall wrapper?
> 
> I think that's a good idea. The function used to be slightly different
> for each architecture, but now it seems we have a significant number
> of identical implementations that we could just merge them together
> into one.
> 
> sys_mmap_pgoff was originally introduced as the common implementation
> and it reduced the amount of duplication a lot, but as its units
> are based on PAGE_SIZE rather than hardwired 4096 bytes, it's
> not as useful.
> 

microblaze and mips (twice) are doing like this. And aarh32 as well,
in arch/arm64/kernel/entry32.S

In previous submissions it was a patch that shares aarch32 code to
ilp32. If we decided turn around again, I think, we'd pick up that patch.

The other option is to make this hack generic, as so many arches use it.

Re: [PATCH 20/25] arm64:ilp32: add sys_ilp32.c and a separate table (in entry.S) to use it

[Yury Norov]

On Thu, May 12, 2016 at 03:06:39PM +0200, Arnd Bergmann wrote:
> On Thursday 12 May 2016 20:49:24 Zhangjian wrote:
> > Hi,
> > 
> > On 2016/5/12 17:21, Arnd Bergmann wrote:
> > > On Thursday 12 May 2016 10:17:58 Catalin Marinas wrote:
> > >> On Wed, May 11, 2016 at 09:30:07PM +0200, Arnd Bergmann wrote:
> > >>> On Wednesday 11 May 2016 17:59:01 Catalin Marinas wrote:
> > >>>
> > >>> I don't think the shifts are a problem, the main downside would be
> > >>> the limit to 44 bits of file offsets (16TB files), but it's also
> > >>> unclear if that is a practical problem at all. If it is, we run
> > >>> into the same problem on all other 32-bit architectures too.
> > >>
> > >> I hope people are seriously thinking of moving to an LP64 ABI if they
> > >> have such large file offset needs.
> > >
> > > Good point. 44 bits of file size is certainly enough for mmap()
> > > on a 32-bit task: you would only be able to map a very small fraction
> > > of the file anyway, and if you want to map larger files, and should
> > > move to 64-bit tasks long before this becomes a limitation.
> > Hi,
> > 
> > I apply the following patch in order to make use of the REAL mmmap2. LTP
> > test pass in litle endian. mmap16 successful with segfault in big endian.
> > 
> > BTW, I saw the similar code in tile, mips, microblaze and s390 compat. 
> > Should
> > we merge these code into a common syscall wrapper?
> 
> I think that's a good idea. The function used to be slightly different
> for each architecture, but now it seems we have a significant number
> of identical implementations that we could just merge them together
> into one.
> 
> sys_mmap_pgoff was originally introduced as the common implementation
> and it reduced the amount of duplication a lot, but as its units
> are based on PAGE_SIZE rather than hardwired 4096 bytes, it's
> not as useful.
> 

microblaze and mips (twice) are doing like this. And aarh32 as well,
in arch/arm64/kernel/entry32.S

In previous submissions it was a patch that shares aarch32 code to
ilp32. If we decided turn around again, I think, we'd pick up that patch.

The other option is to make this hack generic, as so many arches use it.

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> I debugged preadv02 and pwritev02 failures and found very weird bug.
> Test passes {iovec_base = 0x, iovec_len = 64} as one element
> of vector, and kernel reports successful read/write.
> 
> There are 2 problems:
> 1. How kernel allows such address to be passed to fs subsystem;
> 2. How fs successes to read/write at non-mapped, and in fact non-user
> address.
> 
> I don't know the answer on 2'nd question, and it might be something
> generic. But I investigated first problem.
> 
> The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> validate user address, and on arm64 it ends up with checking buffer
> end against current_thread_info()->addr_limit.
> 
> current_thread_info()->addr_limit for ilp32, and most probably for
> aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> It happens because on thread creation we call flush_old_exec() to set 
> addr_limit, and completely ignore compat mode there.

I assume accesses beyond this address would fault anyway but I haven't
checked the code paths.

> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 7a39683..6ba4952 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -146,6 +146,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
>  do { \
>   clear_thread_flag(TIF_32BIT_AARCH64);   \
>   clear_thread_flag(TIF_32BIT);   \
> + set_fs(TASK_SIZE_64);   \
>  } while (0)

See below.

> diff --git a/arch/arm64/include/asm/uaccess.h 
> b/arch/arm64/include/asm/uaccess.h
> index 19cfdc5..3b0dd8d 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -51,7 +51,7 @@
>  #define KERNEL_DS(-1UL)
>  #define get_ds() (KERNEL_DS)
>  
> -#define USER_DS  TASK_SIZE_64
> +#define USER_DS  TASK_SIZE

I agree with this.

>  #define get_fs() (current_thread_info()->addr_limit)
>  
>  static inline void set_fs(mm_segment_t fs)
> diff --git a/arch/arm64/kernel/binfmt_elf32.c 
> b/arch/arm64/kernel/binfmt_elf32.c
> index 5487872..2e8d9f3 100644
> --- a/arch/arm64/kernel/binfmt_elf32.c
> +++ b/arch/arm64/kernel/binfmt_elf32.c
> @@ -12,6 +12,7 @@
>  do { \
>   clear_thread_flag(TIF_32BIT_AARCH64);   \
>   set_thread_flag(TIF_32BIT); \
> + set_fs(TASK_SIZE_32);   \
>  } while (0)
>  
>  #define COMPAT_ARCH_DLINFO
> diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> b/arch/arm64/kernel/binfmt_ilp32.c
> index a934fd4..a8599c6 100644
> --- a/arch/arm64/kernel/binfmt_ilp32.c
> +++ b/arch/arm64/kernel/binfmt_ilp32.c
> @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> cputime,
>  do { \
>   set_thread_flag(TIF_32BIT_AARCH64); \
>   clear_thread_flag(TIF_32BIT);   \
> + set_fs(TASK_SIZE_32);   \
>  } while (0)

I don't think we need these two. AFAICT, flush_old_exec() takes care of
setting the USER_DS for the new thread.

-- 
Catalin

Re: [RFC6 PATCH v6 00/21] ILP32 for ARM64

[Catalin Marinas]

On Thu, May 12, 2016 at 03:20:00AM +0300, Yury Norov wrote:
> I debugged preadv02 and pwritev02 failures and found very weird bug.
> Test passes {iovec_base = 0x, iovec_len = 64} as one element
> of vector, and kernel reports successful read/write.
> 
> There are 2 problems:
> 1. How kernel allows such address to be passed to fs subsystem;
> 2. How fs successes to read/write at non-mapped, and in fact non-user
> address.
> 
> I don't know the answer on 2'nd question, and it might be something
> generic. But I investigated first problem.
> 
> The problem is that compat_rw_copy_check_uvector() uses access_ok() to
> validate user address, and on arm64 it ends up with checking buffer
> end against current_thread_info()->addr_limit.
> 
> current_thread_info()->addr_limit for ilp32, and most probably for
> aarch32 is equal to aarch64 one, and so adress_ok() doesn't fail.
> It happens because on thread creation we call flush_old_exec() to set 
> addr_limit, and completely ignore compat mode there.

I assume accesses beyond this address would fault anyway but I haven't
checked the code paths.

> diff --git a/arch/arm64/include/asm/elf.h b/arch/arm64/include/asm/elf.h
> index 7a39683..6ba4952 100644
> --- a/arch/arm64/include/asm/elf.h
> +++ b/arch/arm64/include/asm/elf.h
> @@ -146,6 +146,7 @@ typedef struct user_fpsimd_state elf_fpregset_t;
>  do { \
>   clear_thread_flag(TIF_32BIT_AARCH64);   \
>   clear_thread_flag(TIF_32BIT);   \
> + set_fs(TASK_SIZE_64);   \
>  } while (0)

See below.

> diff --git a/arch/arm64/include/asm/uaccess.h 
> b/arch/arm64/include/asm/uaccess.h
> index 19cfdc5..3b0dd8d 100644
> --- a/arch/arm64/include/asm/uaccess.h
> +++ b/arch/arm64/include/asm/uaccess.h
> @@ -51,7 +51,7 @@
>  #define KERNEL_DS(-1UL)
>  #define get_ds() (KERNEL_DS)
>  
> -#define USER_DS  TASK_SIZE_64
> +#define USER_DS  TASK_SIZE

I agree with this.

>  #define get_fs() (current_thread_info()->addr_limit)
>  
>  static inline void set_fs(mm_segment_t fs)
> diff --git a/arch/arm64/kernel/binfmt_elf32.c 
> b/arch/arm64/kernel/binfmt_elf32.c
> index 5487872..2e8d9f3 100644
> --- a/arch/arm64/kernel/binfmt_elf32.c
> +++ b/arch/arm64/kernel/binfmt_elf32.c
> @@ -12,6 +12,7 @@
>  do { \
>   clear_thread_flag(TIF_32BIT_AARCH64);   \
>   set_thread_flag(TIF_32BIT); \
> + set_fs(TASK_SIZE_32);   \
>  } while (0)
>  
>  #define COMPAT_ARCH_DLINFO
> diff --git a/arch/arm64/kernel/binfmt_ilp32.c 
> b/arch/arm64/kernel/binfmt_ilp32.c
> index a934fd4..a8599c6 100644
> --- a/arch/arm64/kernel/binfmt_ilp32.c
> +++ b/arch/arm64/kernel/binfmt_ilp32.c
> @@ -59,6 +59,7 @@ static void cputime_to_compat_timeval(const cputime_t 
> cputime,
>  do { \
>   set_thread_flag(TIF_32BIT_AARCH64); \
>   clear_thread_flag(TIF_32BIT);   \
> + set_fs(TASK_SIZE_32);   \
>  } while (0)

I don't think we need these two. AFAICT, flush_old_exec() takes care of
setting the USER_DS for the new thread.

-- 
Catalin

Re: linux-next: manual merge of the gpio tree with the mips tree

[Linus Walleij]

On Thu, May 12, 2016 at 6:17 AM, Stephen Rothwell  wrote:

> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Yeah this is trivial and ACKed by the MIPS mainatainer so should be
safe, thanks!

Yours,
Linus Walleij

Re: linux-next: manual merge of the gpio tree with the mips tree

[Linus Walleij]

On Thu, May 12, 2016 at 6:17 AM, Stephen Rothwell  wrote:

> I fixed it up (see below) and can carry the fix as necessary. This
> is now fixed as far as linux-next is concerned, but any non trivial
> conflicts should be mentioned to your upstream maintainer when your tree
> is submitted for merging.  You may also want to consider cooperating
> with the maintainer of the conflicting tree to minimise any particularly
> complex conflicts.

Yeah this is trivial and ACKed by the MIPS mainatainer so should be
safe, thanks!

Yours,
Linus Walleij

next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Guenter Roeck]

Borislav,

your patch 'locking/rwsem, x86: Clean up down_write()' causes various
crashes in x86 qemu tests.

BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] crypto_larval_kill+0x15/0x70
 [] crypto_wait_for_test+0x46/0x70
 [] crypto_register_alg+0x5c/0x70
 [] crypto_register_algs+0x35/0x80
 [] ? hmac_module_init+0xf/0xf
 [] crypto_null_mod_init+0x13/0x41
 [] do_one_initcall+0x3b/0x150
 [ ... ]


BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] copy_process.part.52+0xba5/0x15c0
 [] ? _raw_spin_unlock_bh+0x18/0x20
 [] _do_fork+0xcd/0x380
 [] SyS_clone+0x2c/0x30
 [] do_int80_syscall_32+0x5a/0xa0
 [] entry_INT80_32+0x2a/0x2a

BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] unlink_file_vma+0x30/0x50
 [] free_pgtables+0x33/0xc0
 [] exit_mmap+0x8e/0xe0
 [] mmput+0x2b/0xa0
 [] flush_old_exec+0x312/0x650
 [] load_elf_binary+0x2ad/0x1080
 [] ? __get_user_pages+0x3c/0x60
 [] ? get_user_pages_remote+0x5f/0x70
 [] ? _copy_from_user+0x31/0x50
 [] search_binary_handler+0x7c/0x1b0
 [] do_execveat_common+0x4bb/0x650
 [] do_execve+0x24/0x30
 [] SyS_execve+0x1b/0x20
 [] do_int80_syscall_32+0x5a/0xa0
 [] entry_INT80_32+0x2a/0x2a

Reverting the patch fixes the problem.

Complete logs are available at http://kerneltests.org/builders/qemu-x86-next.
Scripts, configuration, and root file system used are available at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86

Bisect log is attached.

Guenter

---
Bisect log:

# bad: [13425f1bf7f9f28fcef53057303319d5afb907f7] Add linux-next specific files 
for 20160511
# good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
git bisect start 'HEAD' 'v4.6-rc7'
# good: [b6cf27d48f370bf2d42888921632ae05340aaca9] Merge remote-tracking branch 
'crypto/master'
git bisect good b6cf27d48f370bf2d42888921632ae05340aaca9
# bad: [607563e7793b7c4f3ab134dc200552a555ca5cb2] Merge remote-tracking branch 
'tip/auto-latest'
git bisect bad 607563e7793b7c4f3ab134dc200552a555ca5cb2
# good: [05454bc3dd6d8c4cff684ea881d79db952030075] Merge remote-tracking branch 
'block/for-next'
git bisect good 05454bc3dd6d8c4cff684ea881d79db952030075
# good: [3ed15da0d55d9147f6434fe57db60a5b4059cbfd] Merge remote-tracking branch 
'spi/for-next'
git bisect good 3ed15da0d55d9147f6434fe57db60a5b4059cbfd
# bad: [25ea4e608611c03ad9829a727f6cc198db952d06] Merge branch 'perf/core'
git bisect bad 25ea4e608611c03ad9829a727f6cc198db952d06
# good: [f127fa098d76444c7a47b2f009356979492d77cd] perf/x86/intel/pt: Add IP 
filtering register/CPUID bits
git bisect good f127fa098d76444c7a47b2f009356979492d77cd
# good: [13a00bc35b2a9f8b750a292dcc84111bdfb1edd4] Merge branch 'efi/core'
git bisect good 13a00bc35b2a9f8b750a292dcc84111bdfb1edd4
# bad: [0b749d9316aa32dc3fe67d7c0b4fb650873709aa] Merge branch 'locking/rwsem'
git bisect bad 0b749d9316aa32dc3fe67d7c0b4fb650873709aa
# good: [a1cc5bcfcfca0b99f009b117785142dbdc3b87a3] locking/atomics: Flip 
atomic_fetch_or() arguments
git bisect good a1cc5bcfcfca0b99f009b117785142dbdc3b87a3
# good: [00fb16e26ac8559e69c3bb14284f4a548d28ee0d] locking/rwsem, x86: Add 
frame annotation for call_rwsem_down_write_failed_killable()
git bisect good 00fb16e26ac8559e69c3bb14284f4a548d28ee0d
# good: [e3825ba1af3a27d7522c9f5f929f5a13b8b138ae] irqchip/gic-v3: Add support 
for partitioned PPIs
git bisect good e3825ba1af3a27d7522c9f5f929f5a13b8b138ae
# good: [5e4c588054d52d1b25633c6074c5f3c6228e26ed] Merge branch 'irq/core'
git bisect good 5e4c588054d52d1b25633c6074c5f3c6228e26ed
# bad: [71c01930b42e5dd65d4820dea116bcbe95a0b768] locking/rwsem, x86: Clean up 
down_write()
git bisect bad 71c01930b42e5dd65d4820dea116bcbe95a0b768
# first bad commit: [71c01930b42e5dd65d4820dea116bcbe95a0b768] locking/rwsem, 
x86: Clean up down_write()

next: Crashes in x86 images due to 'locking/rwsem, x86: Clean up ____down_write()'

[Guenter Roeck]

Borislav,

your patch 'locking/rwsem, x86: Clean up down_write()' causes various
crashes in x86 qemu tests.

BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] crypto_larval_kill+0x15/0x70
 [] crypto_wait_for_test+0x46/0x70
 [] crypto_register_alg+0x5c/0x70
 [] crypto_register_algs+0x35/0x80
 [] ? hmac_module_init+0xf/0xf
 [] crypto_null_mod_init+0x13/0x41
 [] do_one_initcall+0x3b/0x150
 [ ... ]


BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] copy_process.part.52+0xba5/0x15c0
 [] ? _raw_spin_unlock_bh+0x18/0x20
 [] _do_fork+0xcd/0x380
 [] SyS_clone+0x2c/0x30
 [] do_int80_syscall_32+0x5a/0xa0
 [] entry_INT80_32+0x2a/0x2a

BUG: unable to handle kernel paging request at 8015
IP: [] down_write+0x23/0x30

Call Trace:
 [] unlink_file_vma+0x30/0x50
 [] free_pgtables+0x33/0xc0
 [] exit_mmap+0x8e/0xe0
 [] mmput+0x2b/0xa0
 [] flush_old_exec+0x312/0x650
 [] load_elf_binary+0x2ad/0x1080
 [] ? __get_user_pages+0x3c/0x60
 [] ? get_user_pages_remote+0x5f/0x70
 [] ? _copy_from_user+0x31/0x50
 [] search_binary_handler+0x7c/0x1b0
 [] do_execveat_common+0x4bb/0x650
 [] do_execve+0x24/0x30
 [] SyS_execve+0x1b/0x20
 [] do_int80_syscall_32+0x5a/0xa0
 [] entry_INT80_32+0x2a/0x2a

Reverting the patch fixes the problem.

Complete logs are available at http://kerneltests.org/builders/qemu-x86-next.
Scripts, configuration, and root file system used are available at
https://github.com/groeck/linux-build-test/tree/master/rootfs/x86

Bisect log is attached.

Guenter

---
Bisect log:

# bad: [13425f1bf7f9f28fcef53057303319d5afb907f7] Add linux-next specific files 
for 20160511
# good: [44549e8f5eea4e0a41b487b63e616cb089922b99] Linux 4.6-rc7
git bisect start 'HEAD' 'v4.6-rc7'
# good: [b6cf27d48f370bf2d42888921632ae05340aaca9] Merge remote-tracking branch 
'crypto/master'
git bisect good b6cf27d48f370bf2d42888921632ae05340aaca9
# bad: [607563e7793b7c4f3ab134dc200552a555ca5cb2] Merge remote-tracking branch 
'tip/auto-latest'
git bisect bad 607563e7793b7c4f3ab134dc200552a555ca5cb2
# good: [05454bc3dd6d8c4cff684ea881d79db952030075] Merge remote-tracking branch 
'block/for-next'
git bisect good 05454bc3dd6d8c4cff684ea881d79db952030075
# good: [3ed15da0d55d9147f6434fe57db60a5b4059cbfd] Merge remote-tracking branch 
'spi/for-next'
git bisect good 3ed15da0d55d9147f6434fe57db60a5b4059cbfd
# bad: [25ea4e608611c03ad9829a727f6cc198db952d06] Merge branch 'perf/core'
git bisect bad 25ea4e608611c03ad9829a727f6cc198db952d06
# good: [f127fa098d76444c7a47b2f009356979492d77cd] perf/x86/intel/pt: Add IP 
filtering register/CPUID bits
git bisect good f127fa098d76444c7a47b2f009356979492d77cd
# good: [13a00bc35b2a9f8b750a292dcc84111bdfb1edd4] Merge branch 'efi/core'
git bisect good 13a00bc35b2a9f8b750a292dcc84111bdfb1edd4
# bad: [0b749d9316aa32dc3fe67d7c0b4fb650873709aa] Merge branch 'locking/rwsem'
git bisect bad 0b749d9316aa32dc3fe67d7c0b4fb650873709aa
# good: [a1cc5bcfcfca0b99f009b117785142dbdc3b87a3] locking/atomics: Flip 
atomic_fetch_or() arguments
git bisect good a1cc5bcfcfca0b99f009b117785142dbdc3b87a3
# good: [00fb16e26ac8559e69c3bb14284f4a548d28ee0d] locking/rwsem, x86: Add 
frame annotation for call_rwsem_down_write_failed_killable()
git bisect good 00fb16e26ac8559e69c3bb14284f4a548d28ee0d
# good: [e3825ba1af3a27d7522c9f5f929f5a13b8b138ae] irqchip/gic-v3: Add support 
for partitioned PPIs
git bisect good e3825ba1af3a27d7522c9f5f929f5a13b8b138ae
# good: [5e4c588054d52d1b25633c6074c5f3c6228e26ed] Merge branch 'irq/core'
git bisect good 5e4c588054d52d1b25633c6074c5f3c6228e26ed
# bad: [71c01930b42e5dd65d4820dea116bcbe95a0b768] locking/rwsem, x86: Clean up 
down_write()
git bisect bad 71c01930b42e5dd65d4820dea116bcbe95a0b768
# first bad commit: [71c01930b42e5dd65d4820dea116bcbe95a0b768] locking/rwsem, 
x86: Clean up down_write()

RE: [PATCH 1/1] perf/core: fix implicitly enable dynamic interrupt throttle

[Liang, Kan]

> 
> 
> Hmm, would it not be nicer to simply reject the write instead of silently
> ignoring it?
>

Yes, I agree.

Thanks,
Kan

> ---
>  kernel/events/core.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c index
> 050a290c72c7..0a51a568d4eb 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -396,6 +396,13 @@ int perf_proc_update_handler(struct ctl_table
> *table, int write,
>   if (ret || !write)
>   return ret;
> 
> + /*
> +  * If the throttling is disabled; don't allow the write.
> +  */
> + if (sysctl_perf_cpu_time_max_percent == 100 ||
> + sysctl_perf_cpu_time_max_percent == 0)
> + return -EINVAL;
> +
>   max_samples_per_tick =
> DIV_ROUND_UP(sysctl_perf_event_sample_rate, HZ);
>   perf_sample_period_ns = NSEC_PER_SEC /
> sysctl_perf_event_sample_rate;
>   update_perf_cpu_limits();

RE: [PATCH 1/1] perf/core: fix implicitly enable dynamic interrupt throttle

[Liang, Kan]

> 
> 
> Hmm, would it not be nicer to simply reject the write instead of silently
> ignoring it?
>

Yes, I agree.

Thanks,
Kan

> ---
>  kernel/events/core.c | 7 +++
>  1 file changed, 7 insertions(+)
> 
> diff --git a/kernel/events/core.c b/kernel/events/core.c index
> 050a290c72c7..0a51a568d4eb 100644
> --- a/kernel/events/core.c
> +++ b/kernel/events/core.c
> @@ -396,6 +396,13 @@ int perf_proc_update_handler(struct ctl_table
> *table, int write,
>   if (ret || !write)
>   return ret;
> 
> + /*
> +  * If the throttling is disabled; don't allow the write.
> +  */
> + if (sysctl_perf_cpu_time_max_percent == 100 ||
> + sysctl_perf_cpu_time_max_percent == 0)
> + return -EINVAL;
> +
>   max_samples_per_tick =
> DIV_ROUND_UP(sysctl_perf_event_sample_rate, HZ);
>   perf_sample_period_ns = NSEC_PER_SEC /
> sysctl_perf_event_sample_rate;
>   update_perf_cpu_limits();

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

[Nicolas Morey-Chaisemartin]

Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
> On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote:
>>
>> Le 05/11/2016 à 04:51 PM, Jerome Glisse a écrit :
>>> On Wed, May 11, 2016 at 01:15:54PM +0200, Nicolas Morey Chaisemartin wrote:
 Le 05/10/2016 à 12:01 PM, Jerome Glisse a écrit :
> On Tue, May 10, 2016 at 09:04:36AM +0200, Nicolas Morey Chaisemartin 
> wrote:
>> Le 05/03/2016 à 12:11 PM, Jerome Glisse a écrit :
>>> On Mon, May 02, 2016 at 09:04:02PM -0700, Hugh Dickins wrote:
 On Fri, 29 Apr 2016, Nicolas Morey Chaisemartin wrote:
 [...]
>> Hi,
>>
>> I backported the patch to 3.10 (had to copy paste pmd_protnone 
>> defitinition from 4.5) and it's working !
>> I'll open a ticket in Redhat tracker to try and get this fixed in RHEL7.
>>
>> I have a dumb question though: how can we end up in numa/misplaced 
>> memory code on a single socket system?
>>
> This patch is not a fix, do you see bug message in kernel log ? Because if
> you do that it means we have a bigger issue.
>
> You did not answer one of my previous question, do you set get_user_pages
> with write = 1 as a paremeter ?
>
> Also it would be a lot easier if you were testing with lastest 4.6 or 4.5
> not RHEL kernel as they are far appart and what might looks like same 
> issue
> on both might be totaly different bugs.
>
> If you only really care about RHEL kernel then open a bug with Red Hat and
> you can add me in bug-cc 
>
> Cheers,
> Jérôme
 I finally managed to get a proper setup.
 I build a vanilla 4.5 kernel from git tree using the Centos7 config, my 
 test fails as usual.
 I applied your patch, rebuild => still fails and no new messages in dmesg.

 Now that I don't have to go through the RPM repackaging, I can try out 
 things much quicker if you have any ideas.

>>> Still an issue if you boot with transparent_hugepage=never ?
>>>
>>> Also to simplify investigation force write to 1 all the time no matter what.
>>>
>>> Cheers,
>>> Jérôme
>> With transparent_hugepage=never I can't see the bug anymore.
>>
> Can you test https://patchwork.kernel.org/patch/9061351/ with 4.5
> (does not apply to 3.10) and without transparent_hugepage=never
>
> Jérôme

Fails with 4.5 + this patch and with 4.5 + this patch + yours

Nicolas

Re: usb: dwc2: regression on MyBook Live Duo / Canyonlands since 4.3.0-rc4

[Christian Lamparter]

On Thursday, May 12, 2016 01:55:44 PM Arnd Bergmann wrote:
> On Thursday 12 May 2016 11:58:18 Christian Lamparter wrote:
> > > > > Detecting the endianess of the
> > > > > device is probably the best future-proof solution, but it's also
> > > > > considerably more work to do in the driver, and comes with a
> > > > > tiny runtime overhead.
> > > > 
> > > > The runtime overhead is probably non-measurable compared with the cost
> > > > of the actual MMIOs.
> > > 
> > > Right. The code size increase is probably measurable (but still small),
> > > the runtime overhead is not.
> > 
> > Ok, so no rebuts or complains have been posted.
> > 
> > I've tested the patch you made in: https://lkml.org/lkml/2016/5/9/354
> > and it works: 
> > 
> > Tested-by: Christian Lamparter 
> > 
> > So, how do we go from here? There is are two small issues with the
> > original patch (#ifdef DWC2_LOG_WRITES got converted to lower case:
> > #ifdef dwc2_log_writes) and I guess a proper subject would be nice.  
> > 
> > Arnd, can you please respin and post it (cc'd stable as well)?
> > So this is can be picked up? Or what's your plan?
> 
> (I just realized my reply was stuck in my outbox, so the patch
> went out first)
> 
> If I recall correctly, the rough consensus was to go with your longer
> patch in the future (fixed up for the comments that BenH and
> I sent), and I'd suggest basing it on top of a fixed version of
> my patch.
Well, but it comes with the "overhead"! So this was just as I said:
"Let's look at it and see if it's any good"... And I think it isn't
since the usb/host/ehci people also opted for #ifdef CONFIG_BIG_ENDIAN
archs etc...
 
> Felipe just had another idea, to change the endianess of the dwc2
> block by setting a registers (if that exists). That would indeed
> be preferable, then we can just revert the broken change that
> went into 4.4 and backport that fix instead.
Just a quick reply. I have the docs for the thing. There's something
like that in GAHBCFG at Bit 24... BUT it only switches the endiannes
for the DMA descriptors (which is not always used, there are devices
with PIO only)! It doesn't deal with the MMIO access at all. 

The pin that would select which endian the device uses is probably
connected to a DCR or GPIO but I don't know which or where so this
is more or less useless. (Or the selectable endianness was dropped
during synth).

Regards,
Christian

RE: [PATCH V2 1/1] perf/core: don't find side-band event from all pmus

[Liang, Kan]

> ---
> Subject: perf/core: don't find side-band event from all pmus
> From: Kan Liang 
> Date: Wed, 23 Mar 2016 11:24:37 -0700
> 
Hi Peter,

Is there something wrong with the patch?
The last time I saw this patch was in your personal tree 
(kernel/git/peterz/queue.git).
But now I cannot find it anymore. 

Thanks,
Kan
> perf_event_aux funciton goes through all pmus and all events in whatever
> contexts to find the side-band event to output, which is unnecessary and
> expensive.
> 
> For example, the brk test case in lkp triggers many mmap operations, at the
> time, perf with cycles:pp is also running on the system. As a result, many
> perf_event_aux are invoked, and each would search all pmus and all events.
> If we enable the uncore support (even when uncore event are not really
> used), dozens of uncore pmus will be added into pmus list, which can
> significantly decrease brk_test's ops_per_sec. Based on our test, the
> ops_per_sec without uncore patch is 2647573, while the ops_per_sec with
> uncore patch is only 1768444, which is a 33.2% reduction.
> 
> To get at the per cpu side-band event, this patch put the side-band events to
> four categories, which are tracked by 4 per-cpu lists. It only finds the
> interested events from masked category.
> To get at the per task side-band event, each task context for current task 
> will
> be searched. Because we don't want to go update more global state on
> context switch.
> 
> 
> Cc: vincent.wea...@maine.edu
> Cc: mi...@kernel.org
> Cc: a...@redhat.com
> Cc: a...@linux.intel.com
> Cc: jo...@redhat.com
> Cc: t...@linutronix.de
> Cc: eran...@google.com
> Cc: alexander.shish...@linux.intel.com
> Reported-by: Huang, Ying 
> Suggested-by: Peter Zijlstra (Intel) 
> Signed-off-by: Kan Liang 
> Signed-off-by: Peter Zijlstra (Intel) 
> Link: http://lkml.kernel.org/r/1458757477-3781-1-git-send-email-
> kan.li...@intel.com 

Re: [Question] Missing data after DMA read transfer - mm issue with transparent huge page?

[Nicolas Morey-Chaisemartin]

Le 05/12/2016 à 11:36 AM, Jerome Glisse a écrit :
> On Thu, May 12, 2016 at 08:07:59AM +0200, Nicolas Morey-Chaisemartin wrote:
>>
>> Le 05/11/2016 à 04:51 PM, Jerome Glisse a écrit :
>>> On Wed, May 11, 2016 at 01:15:54PM +0200, Nicolas Morey Chaisemartin wrote:
 Le 05/10/2016 à 12:01 PM, Jerome Glisse a écrit :
> On Tue, May 10, 2016 at 09:04:36AM +0200, Nicolas Morey Chaisemartin 
> wrote:
>> Le 05/03/2016 à 12:11 PM, Jerome Glisse a écrit :
>>> On Mon, May 02, 2016 at 09:04:02PM -0700, Hugh Dickins wrote:
 On Fri, 29 Apr 2016, Nicolas Morey Chaisemartin wrote:
 [...]
>> Hi,
>>
>> I backported the patch to 3.10 (had to copy paste pmd_protnone 
>> defitinition from 4.5) and it's working !
>> I'll open a ticket in Redhat tracker to try and get this fixed in RHEL7.
>>
>> I have a dumb question though: how can we end up in numa/misplaced 
>> memory code on a single socket system?
>>
> This patch is not a fix, do you see bug message in kernel log ? Because if
> you do that it means we have a bigger issue.
>
> You did not answer one of my previous question, do you set get_user_pages
> with write = 1 as a paremeter ?
>
> Also it would be a lot easier if you were testing with lastest 4.6 or 4.5
> not RHEL kernel as they are far appart and what might looks like same 
> issue
> on both might be totaly different bugs.
>
> If you only really care about RHEL kernel then open a bug with Red Hat and
> you can add me in bug-cc 
>
> Cheers,
> Jérôme
 I finally managed to get a proper setup.
 I build a vanilla 4.5 kernel from git tree using the Centos7 config, my 
 test fails as usual.
 I applied your patch, rebuild => still fails and no new messages in dmesg.

 Now that I don't have to go through the RPM repackaging, I can try out 
 things much quicker if you have any ideas.

>>> Still an issue if you boot with transparent_hugepage=never ?
>>>
>>> Also to simplify investigation force write to 1 all the time no matter what.
>>>
>>> Cheers,
>>> Jérôme
>> With transparent_hugepage=never I can't see the bug anymore.
>>
> Can you test https://patchwork.kernel.org/patch/9061351/ with 4.5
> (does not apply to 3.10) and without transparent_hugepage=never
>
> Jérôme

Fails with 4.5 + this patch and with 4.5 + this patch + yours

Nicolas