Re: [PATCH 2/3] userfaultfd: use fault_wqh lock

[Mike Rapoport]

Hi,

On Thu, Dec 14, 2017 at 04:23:43PM +0100, Christoph Hellwig wrote:
> From: Matthew Wilcox 
> 
> The epoll code currently uses the unlocked waitqueue helpers for managing

The userfaultfd code

> fault_wqh, but instead of holding the waitqueue lock for this waitqueue
> around these calls, it the waitqueue lock of fault_pending_wq, which is
> a different waitqueue instance.  Given that the waitqueue is not exposed
> to the rest of the kernel this actually works ok at the moment, but
> prevents the epoll locking rules from being enforced using lockdep.

ditto

> Switch to the internally locked waitqueue helpers instead.  This means
> that the lock inside fault_wqh now nests inside the fault_pending_wqh
> lock, but that's not a problem since it was entireyl unused before.

spelling: entirely

> Signed-off-by: Matthew Wilcox 
> [hch: slight changelog updates]
> Signed-off-by: Christoph Hellwig 

Reviewed-by: Mike Rapoport 

> ---
>  fs/userfaultfd.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index ac9a4e65ca49..a39bc3237b68 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -879,7 +879,7 @@ static int userfaultfd_release(struct inode *inode, 
> struct file *file)
>*/
>   spin_lock(>fault_pending_wqh.lock);
>   __wake_up_locked_key(>fault_pending_wqh, TASK_NORMAL, );
> - __wake_up_locked_key(>fault_wqh, TASK_NORMAL, );
> + __wake_up(>fault_wqh, TASK_NORMAL, 1, );
>   spin_unlock(>fault_pending_wqh.lock);
> 
>   /* Flush pending events that may still wait on event_wqh */
> @@ -1045,7 +1045,7 @@ static ssize_t userfaultfd_ctx_read(struct 
> userfaultfd_ctx *ctx, int no_wait,
>* anyway.
>*/
>   list_del(>wq.entry);
> - __add_wait_queue(>fault_wqh, >wq);
> + add_wait_queue(>fault_wqh, >wq);
> 
>   write_seqcount_end(>refile_seq);
> 
> @@ -1194,7 +1194,7 @@ static void __wake_userfault(struct userfaultfd_ctx 
> *ctx,
>   __wake_up_locked_key(>fault_pending_wqh, TASK_NORMAL,
>range);
>   if (waitqueue_active(>fault_wqh))
> - __wake_up_locked_key(>fault_wqh, TASK_NORMAL, range);
> + __wake_up(>fault_wqh, TASK_NORMAL, 1, range);
>   spin_unlock(>fault_pending_wqh.lock);
>  }
> 
> -- 
> 2.14.2
> 

-- 
Sincerely yours,
Mike.

Re: [PATCH 2/3] userfaultfd: use fault_wqh lock

[Mike Rapoport]

Hi,

On Thu, Dec 14, 2017 at 04:23:43PM +0100, Christoph Hellwig wrote:
> From: Matthew Wilcox 
> 
> The epoll code currently uses the unlocked waitqueue helpers for managing

The userfaultfd code

> fault_wqh, but instead of holding the waitqueue lock for this waitqueue
> around these calls, it the waitqueue lock of fault_pending_wq, which is
> a different waitqueue instance.  Given that the waitqueue is not exposed
> to the rest of the kernel this actually works ok at the moment, but
> prevents the epoll locking rules from being enforced using lockdep.

ditto

> Switch to the internally locked waitqueue helpers instead.  This means
> that the lock inside fault_wqh now nests inside the fault_pending_wqh
> lock, but that's not a problem since it was entireyl unused before.

spelling: entirely

> Signed-off-by: Matthew Wilcox 
> [hch: slight changelog updates]
> Signed-off-by: Christoph Hellwig 

Reviewed-by: Mike Rapoport 

> ---
>  fs/userfaultfd.c | 6 +++---
>  1 file changed, 3 insertions(+), 3 deletions(-)
> 
> diff --git a/fs/userfaultfd.c b/fs/userfaultfd.c
> index ac9a4e65ca49..a39bc3237b68 100644
> --- a/fs/userfaultfd.c
> +++ b/fs/userfaultfd.c
> @@ -879,7 +879,7 @@ static int userfaultfd_release(struct inode *inode, 
> struct file *file)
>*/
>   spin_lock(>fault_pending_wqh.lock);
>   __wake_up_locked_key(>fault_pending_wqh, TASK_NORMAL, );
> - __wake_up_locked_key(>fault_wqh, TASK_NORMAL, );
> + __wake_up(>fault_wqh, TASK_NORMAL, 1, );
>   spin_unlock(>fault_pending_wqh.lock);
> 
>   /* Flush pending events that may still wait on event_wqh */
> @@ -1045,7 +1045,7 @@ static ssize_t userfaultfd_ctx_read(struct 
> userfaultfd_ctx *ctx, int no_wait,
>* anyway.
>*/
>   list_del(>wq.entry);
> - __add_wait_queue(>fault_wqh, >wq);
> + add_wait_queue(>fault_wqh, >wq);
> 
>   write_seqcount_end(>refile_seq);
> 
> @@ -1194,7 +1194,7 @@ static void __wake_userfault(struct userfaultfd_ctx 
> *ctx,
>   __wake_up_locked_key(>fault_pending_wqh, TASK_NORMAL,
>range);
>   if (waitqueue_active(>fault_wqh))
> - __wake_up_locked_key(>fault_wqh, TASK_NORMAL, range);
> + __wake_up(>fault_wqh, TASK_NORMAL, 1, range);
>   spin_unlock(>fault_pending_wqh.lock);
>  }
> 
> -- 
> 2.14.2
> 

-- 
Sincerely yours,
Mike.

Re: Detecting RWF_NOWAIT support

[Avi Kivity]

On 12/16/2017 08:12 PM, vcap...@pengaru.com wrote:

On Sat, Dec 16, 2017 at 10:03:38AM -0800, vcap...@pengaru.com wrote:

On Sat, Dec 16, 2017 at 04:49:08PM +0200, Avi Kivity wrote:


On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:

On 12/14/2017 11:38 AM, Avi Kivity wrote:

I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at runtime whether the kernel support
RWF_NOWAIT or not.


The only method I could find was to issue an I/O with RWF_NOWAIT set,
and look for errors. This is somewhat less than perfect:

   - from the error, I can't tell whether RWF_NOWAIT was the problem, or
something else. If I enable a number of new features, I have to run
through all combinations to figure out which ones are supported and
which are not.

Here is the return codes for RWF_NOWAIT
EINVAL - not supported (older kernel)
EOPNOTSUPP - not supported
EAGAIN - supported but could not complete because I/O will be delayed

Which of these are returned from io_submit() and which are returned in the
iocb?


0 - supported and I/O completed (success).


   - RWF_NOWAIT support is per-filesystem, so I can't just remember not to
enable RWF_NOWAIT globally, I have to track it per file.

Yes, the support is per filesystem. So, the application must know if the
filesystem supports it, possibly by performing a small I/O.

So the application must know about filesystem mount points, and be prepared
to create a file and try to write it (in case the filesystem is empty) or
alter its behavior during runtime depending on the errors it sees.

Can't the application simply add a "nowait" flag to its open file
descriptor encapsulation struct, then in the constructor perform a
zero-length RWF_NOWAIT write immediately after opening the fd to set the
flag?  Then all writes branch according to the flag.

According to write(2):

If  count is zero and fd refers to a regular file, then write()
may return a failure status if one of the errors below is
detected.  If no errors are detected,  or error detection is not
performed, 0 will be returned without causing any other effect.
If count is zero and fd refers to a file  other than a regular
file, the results are not specified.

So the zero-length RWF_NOWAIT write should return zero, unless it's not
supported.


Oh, I assumed this new flag applied to pwritev2() flags.  Disregard my
comment, I see the ambiguity causing your question Avi and do not know
the best approach.



Actually it's not a bad idea. I'm using AIO, not p{read,write}v2, but I 
can assume that the response will be the same and that a zero-length 
read will return immediately.

Re: Detecting RWF_NOWAIT support

[Avi Kivity]

On 12/16/2017 08:12 PM, vcap...@pengaru.com wrote:

On Sat, Dec 16, 2017 at 10:03:38AM -0800, vcap...@pengaru.com wrote:

On Sat, Dec 16, 2017 at 04:49:08PM +0200, Avi Kivity wrote:


On 12/14/2017 09:15 PM, Goldwyn Rodrigues wrote:

On 12/14/2017 11:38 AM, Avi Kivity wrote:

I'm looking to add support for RWF_NOWAIT within a linux-aio iocb.
Naturally, I need to detect at runtime whether the kernel support
RWF_NOWAIT or not.


The only method I could find was to issue an I/O with RWF_NOWAIT set,
and look for errors. This is somewhat less than perfect:

   - from the error, I can't tell whether RWF_NOWAIT was the problem, or
something else. If I enable a number of new features, I have to run
through all combinations to figure out which ones are supported and
which are not.

Here is the return codes for RWF_NOWAIT
EINVAL - not supported (older kernel)
EOPNOTSUPP - not supported
EAGAIN - supported but could not complete because I/O will be delayed

Which of these are returned from io_submit() and which are returned in the
iocb?


0 - supported and I/O completed (success).


   - RWF_NOWAIT support is per-filesystem, so I can't just remember not to
enable RWF_NOWAIT globally, I have to track it per file.

Yes, the support is per filesystem. So, the application must know if the
filesystem supports it, possibly by performing a small I/O.

So the application must know about filesystem mount points, and be prepared
to create a file and try to write it (in case the filesystem is empty) or
alter its behavior during runtime depending on the errors it sees.

Can't the application simply add a "nowait" flag to its open file
descriptor encapsulation struct, then in the constructor perform a
zero-length RWF_NOWAIT write immediately after opening the fd to set the
flag?  Then all writes branch according to the flag.

According to write(2):

If  count is zero and fd refers to a regular file, then write()
may return a failure status if one of the errors below is
detected.  If no errors are detected,  or error detection is not
performed, 0 will be returned without causing any other effect.
If count is zero and fd refers to a file  other than a regular
file, the results are not specified.

So the zero-length RWF_NOWAIT write should return zero, unless it's not
supported.


Oh, I assumed this new flag applied to pwritev2() flags.  Disregard my
comment, I see the ambiguity causing your question Avi and do not know
the best approach.



Actually it's not a bad idea. I'm using AIO, not p{read,write}v2, but I 
can assume that the response will be the same and that a zero-length 
read will return immediately.

Re: [PATCH 04/10] staging: ccree: staging: ccree: replace sysfs by debugfs interface

[Gilad Ben-Yossef]

On Thu, Dec 14, 2017 at 4:30 PM, Philippe Ombredanne
 wrote:
> Gilad,
>
> On Thu, Dec 14, 2017 at 3:02 PM, Gilad Ben-Yossef  wrote:
>> The ccree driver has had a none standard sysfs interface for debugging.
>> Replace it with a proper debugfs interface.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> 
>
>> --- /dev/null
>> +++ b/drivers/staging/ccree/cc_debugfs.c
>> @@ -0,0 +1,114 @@
>> +/*
>> + * Copyright (C) 2012-2017 ARM Limited or its affiliates.
>> + *
>> + * 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 .
>> + */
>
> Could you use the new SPDX tags instead of this fine and long
> boilerplate? See Thomas doc for details [1]


That's a good idea. I'll prepare a patch set to turn the entire driver.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

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

Re: [PATCH 04/10] staging: ccree: staging: ccree: replace sysfs by debugfs interface

[Gilad Ben-Yossef]

On Thu, Dec 14, 2017 at 4:30 PM, Philippe Ombredanne
 wrote:
> Gilad,
>
> On Thu, Dec 14, 2017 at 3:02 PM, Gilad Ben-Yossef  wrote:
>> The ccree driver has had a none standard sysfs interface for debugging.
>> Replace it with a proper debugfs interface.
>>
>> Signed-off-by: Gilad Ben-Yossef 
>
> 
>
>> --- /dev/null
>> +++ b/drivers/staging/ccree/cc_debugfs.c
>> @@ -0,0 +1,114 @@
>> +/*
>> + * Copyright (C) 2012-2017 ARM Limited or its affiliates.
>> + *
>> + * 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 .
>> + */
>
> Could you use the new SPDX tags instead of this fine and long
> boilerplate? See Thomas doc for details [1]


That's a good idea. I'll prepare a patch set to turn the entire driver.

Thanks,
Gilad

-- 
Gilad Ben-Yossef
Chief Coffee Drinker

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

RE: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver

[Dhaval Rajeshbhai Shah]

Hi Randy,

Thanks a lot for the review.

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Saturday, December 16, 2017 2:18 PM
> To: Dhaval Rajeshbhai Shah ; a...@arndb.de;
> gre...@linuxfoundation.org; robh...@kernel.org; mark.rutl...@arm.com
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> michal.si...@xilinx.com; Hyun Kwon ; Dhaval Rajeshbhai
> Shah 
> Subject: Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP
> init driver
> 
> On 12/14/2017 11:24 PM, Dhaval Shah wrote:
> > Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP
> > design created. This driver provides the processing system and
> > programmable logic isolation. Set the frequency based on the clock
> > information get from the logicoreIP register set.
> >
> > It is put in drivers/misc as there is no subsystem for this logicoreIP.
> >
> > Signed-off-by: Dhaval Shah 
> > ---
> >
> >  drivers/misc/Kconfig|  15 ++
> >  drivers/misc/Makefile   |   1 +
> >  drivers/misc/xlnx_vcu.c | 631
> > 
> >  3 files changed, 647 insertions(+)
> >  create mode 100644 drivers/misc/xlnx_vcu.c
> 
> > diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c new
> > file mode 100644 index 000..f489d34
> > --- /dev/null
> > +++ b/drivers/misc/xlnx_vcu.c
> > @@ -0,0 +1,631 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx VCU Init
> > + *
> > + * Copyright (C) 2016 - 2017 Xilinx, Inc.
> > + *
> > + * Contacts   Dhaval Shah 
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> [snip]
> 
> 
> > +/**
> > + * xvcu_set_vcu_pll_info - Set the VCU PLL info
> > + * @xvcu:  Pointer to the xvcu_device structure
> > + *
> > + * Programming the VCU PLL based on the user configuration
> > + * (ref clock freq, core clock freq, mcu clock freq).
> > + * Core clock frequency has higher priority than mcu clock frequency
> > + * Errors in following cases
> > + *- When mcu or clock clock get from logicoreIP is 0
> > + *- When VCU PLL DIV related bits value other than 1
> > + *- When proper data not found for given data
> > + *- When sis570_1 clocksource related operation failed
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu) {
> > +   u32 refclk, coreclk, mcuclk, inte, deci;
> > +   u32 divisor_mcu, divisor_core, fvco;
> > +   u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
> > +   u32 cfg_val, mod, ctrl;
> > +   int ret;
> > +   unsigned int i;
> > +   const struct xvcu_pll_cfg *found = NULL;
> > +
> > +   inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
> > +   deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
> > +   coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
> > +   mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
> > +   if (!mcuclk || !coreclk) {
> > +   dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
> > +   dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
> > +   dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
> > +   dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
> > +
> > +   clk_disable_unprepare(xvcu->pll_ref);
> > +   ret = clk_set_rate(xvcu->pll_ref, refclk);
> > +   if (ret)
> > +   dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
> > +
> > +   ret = clk_prepare_enable(xvcu->pll_ref);
> > +   if (ret) {
> > +   dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
> > +   return ret;
> > +   }
> > +
> > +   refclk = clk_get_rate(xvcu->pll_ref);
> > +
> > +   /*
> > +* The divide-by-2 should be always enabled (==1)
> > +* to meet the timing in the design.
> > +* Otherwise, it's an error
> > +*/
> > +   vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
> > +   clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
> > +   clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
> > +   if (clkoutdiv != 1) {
> > +   dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
> 
> When does that for loop terminate?
> 
This loop will terminate either it reach to i =0 and one other case is when it 
find the proper expected value.  Break statement is used to exit in that case. 
> > +   const struct xvcu_pll_cfg *cfg = _pll_cfg[i];
> > +
> > +   fvco = cfg->fbdiv * refclk;
> > +   if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
> > +   pll_clk = fvco / VCU_PLL_DIV2;
> > +   if (fvco % VCU_PLL_DIV2 != 0)
> > + 

RE: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP init driver

[Dhaval Rajeshbhai Shah]

Hi Randy,

Thanks a lot for the review.

> -Original Message-
> From: Randy Dunlap [mailto:rdun...@infradead.org]
> Sent: Saturday, December 16, 2017 2:18 PM
> To: Dhaval Rajeshbhai Shah ; a...@arndb.de;
> gre...@linuxfoundation.org; robh...@kernel.org; mark.rutl...@arm.com
> Cc: devicet...@vger.kernel.org; linux-kernel@vger.kernel.org;
> michal.si...@xilinx.com; Hyun Kwon ; Dhaval Rajeshbhai
> Shah 
> Subject: Re: [PATCH v4 2/2] misc: xlnx_vcu: Add Xilinx ZYNQMP VCU logicoreIP
> init driver
> 
> On 12/14/2017 11:24 PM, Dhaval Shah wrote:
> > Xilinx ZYNQMP logicoreIP Init driver is based on the new LogiCoreIP
> > design created. This driver provides the processing system and
> > programmable logic isolation. Set the frequency based on the clock
> > information get from the logicoreIP register set.
> >
> > It is put in drivers/misc as there is no subsystem for this logicoreIP.
> >
> > Signed-off-by: Dhaval Shah 
> > ---
> >
> >  drivers/misc/Kconfig|  15 ++
> >  drivers/misc/Makefile   |   1 +
> >  drivers/misc/xlnx_vcu.c | 631
> > 
> >  3 files changed, 647 insertions(+)
> >  create mode 100644 drivers/misc/xlnx_vcu.c
> 
> > diff --git a/drivers/misc/xlnx_vcu.c b/drivers/misc/xlnx_vcu.c new
> > file mode 100644 index 000..f489d34
> > --- /dev/null
> > +++ b/drivers/misc/xlnx_vcu.c
> > @@ -0,0 +1,631 @@
> > +// SPDX-License-Identifier: GPL-2.0
> > +/*
> > + * Xilinx VCU Init
> > + *
> > + * Copyright (C) 2016 - 2017 Xilinx, Inc.
> > + *
> > + * Contacts   Dhaval Shah 
> > + */
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> > +#include 
> 
> [snip]
> 
> 
> > +/**
> > + * xvcu_set_vcu_pll_info - Set the VCU PLL info
> > + * @xvcu:  Pointer to the xvcu_device structure
> > + *
> > + * Programming the VCU PLL based on the user configuration
> > + * (ref clock freq, core clock freq, mcu clock freq).
> > + * Core clock frequency has higher priority than mcu clock frequency
> > + * Errors in following cases
> > + *- When mcu or clock clock get from logicoreIP is 0
> > + *- When VCU PLL DIV related bits value other than 1
> > + *- When proper data not found for given data
> > + *- When sis570_1 clocksource related operation failed
> > + *
> > + * Return: Returns status, either success or error+reason
> > + */
> > +static int xvcu_set_vcu_pll_info(struct xvcu_device *xvcu) {
> > +   u32 refclk, coreclk, mcuclk, inte, deci;
> > +   u32 divisor_mcu, divisor_core, fvco;
> > +   u32 clkoutdiv, vcu_pll_ctrl, pll_clk;
> > +   u32 cfg_val, mod, ctrl;
> > +   int ret;
> > +   unsigned int i;
> > +   const struct xvcu_pll_cfg *found = NULL;
> > +
> > +   inte = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK);
> > +   deci = xvcu_read(xvcu->logicore_reg_ba, VCU_PLL_CLK_DEC);
> > +   coreclk = xvcu_read(xvcu->logicore_reg_ba, VCU_CORE_CLK) * MHZ;
> > +   mcuclk = xvcu_read(xvcu->logicore_reg_ba, VCU_MCU_CLK) * MHZ;
> > +   if (!mcuclk || !coreclk) {
> > +   dev_err(xvcu->dev, "Invalid mcu and core clock data\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   refclk = (inte * MHZ) + (deci * (MHZ / FRAC));
> > +   dev_dbg(xvcu->dev, "Ref clock from logicoreIP is %uHz\n", refclk);
> > +   dev_dbg(xvcu->dev, "Core clock from logicoreIP is %uHz\n", coreclk);
> > +   dev_dbg(xvcu->dev, "Mcu clock from logicoreIP is %uHz\n", mcuclk);
> > +
> > +   clk_disable_unprepare(xvcu->pll_ref);
> > +   ret = clk_set_rate(xvcu->pll_ref, refclk);
> > +   if (ret)
> > +   dev_warn(xvcu->dev, "failed to set logicoreIP refclk rate\n");
> > +
> > +   ret = clk_prepare_enable(xvcu->pll_ref);
> > +   if (ret) {
> > +   dev_err(xvcu->dev, "failed to enable pll_ref clock source\n");
> > +   return ret;
> > +   }
> > +
> > +   refclk = clk_get_rate(xvcu->pll_ref);
> > +
> > +   /*
> > +* The divide-by-2 should be always enabled (==1)
> > +* to meet the timing in the design.
> > +* Otherwise, it's an error
> > +*/
> > +   vcu_pll_ctrl = xvcu_read(xvcu->vcu_slcr_ba, VCU_PLL_CTRL);
> > +   clkoutdiv = vcu_pll_ctrl >> VCU_PLL_CTRL_CLKOUTDIV_SHIFT;
> > +   clkoutdiv = clkoutdiv && VCU_PLL_CTRL_CLKOUTDIV_MASK;
> > +   if (clkoutdiv != 1) {
> > +   dev_err(xvcu->dev, "clkoutdiv value is invalid\n");
> > +   return -EINVAL;
> > +   }
> > +
> > +   for (i = ARRAY_SIZE(xvcu_pll_cfg) - 1; i > 0; i--) {
> 
> When does that for loop terminate?
> 
This loop will terminate either it reach to i =0 and one other case is when it 
find the proper expected value.  Break statement is used to exit in that case. 
> > +   const struct xvcu_pll_cfg *cfg = _pll_cfg[i];
> > +
> > +   fvco = cfg->fbdiv * refclk;
> > +   if (fvco >= FVCO_MIN && fvco <= FVCO_MAX) {
> > +   pll_clk = fvco / VCU_PLL_DIV2;
> > +   if (fvco % VCU_PLL_DIV2 != 0)
> > +   pll_clk++;
> > +   mod = pll_clk % coreclk;
> > 

Re: [PATCH v19 3/7] xbitmap: add more operations

[Wei Wang]

On 12/16/2017 07:28 PM, Tetsuo Handa wrote:

Wei Wang wrote:

On 12/16/2017 02:42 AM, Matthew Wilcox wrote:

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote:

+int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp);

I'm struggling to understand when one would use this.  The xb_ API
requires you to handle your own locking.  But specifying GFP flags
here implies you can sleep.  So ... um ... there's no locking?

In the regular use cases, people would do xb_preload() before taking the
lock, and the xb_set/clear within the lock.

In the virtio-balloon usage, we have a large number of bits to set with
the balloon_lock being held (we're not unlocking for each bit), so we
used the above wrapper to do preload and set within the balloon_lock,
and passed in GFP_NOWAIT to avoid sleeping. Probably we can change to
put this wrapper implementation to virtio-balloon, since it would not be
useful for the regular cases.

GFP_NOWAIT is chosen in order not to try to OOM-kill something, isn't it?


Yes, I think that's right the issue we are discussing here (also 
discussed in the deadlock patch before): Suppose we use a sleep-able 
flag GFP_KERNEL, which gets the caller (fill_balloon or leak_balloon) 
into sleep with balloon_lock being held, and the memory reclaiming from 
GFP_KERNEL would fall into the OOM code path which first invokes the 
oom_notify-->leak_balloon to release some balloon memory, which needs to 
take the balloon_lock that is being held by the task who is sleeping.


So, using GFP_NOWAIT avoids sleeping to get memory through directly 
memory reclaiming, which could fall into that OOM code path that needs 
to take the balloon_lock.




But passing GFP_NOWAIT means that we can handle allocation failure. There is
no need to use preload approach when we can handle allocation failure.


I think the reason we need xb_preload is because radix tree insertion 
needs the memory being preallocated already (it couldn't suffer from 
memory failure during the process of inserting, probably because 
handling the failure there isn't easy, Matthew may know the backstory of 
this)


So, I think we can handle the memory failure with xb_preload, which 
stops going into the radix tree APIs, but shouldn't call radix tree APIs 
without the related memory preallocated.


Best,
Wei

Re: [PATCH v19 3/7] xbitmap: add more operations

[Wei Wang]

On 12/16/2017 07:28 PM, Tetsuo Handa wrote:

Wei Wang wrote:

On 12/16/2017 02:42 AM, Matthew Wilcox wrote:

On Tue, Dec 12, 2017 at 07:55:55PM +0800, Wei Wang wrote:

+int xb_preload_and_set_bit(struct xb *xb, unsigned long bit, gfp_t gfp);

I'm struggling to understand when one would use this.  The xb_ API
requires you to handle your own locking.  But specifying GFP flags
here implies you can sleep.  So ... um ... there's no locking?

In the regular use cases, people would do xb_preload() before taking the
lock, and the xb_set/clear within the lock.

In the virtio-balloon usage, we have a large number of bits to set with
the balloon_lock being held (we're not unlocking for each bit), so we
used the above wrapper to do preload and set within the balloon_lock,
and passed in GFP_NOWAIT to avoid sleeping. Probably we can change to
put this wrapper implementation to virtio-balloon, since it would not be
useful for the regular cases.

GFP_NOWAIT is chosen in order not to try to OOM-kill something, isn't it?


Yes, I think that's right the issue we are discussing here (also 
discussed in the deadlock patch before): Suppose we use a sleep-able 
flag GFP_KERNEL, which gets the caller (fill_balloon or leak_balloon) 
into sleep with balloon_lock being held, and the memory reclaiming from 
GFP_KERNEL would fall into the OOM code path which first invokes the 
oom_notify-->leak_balloon to release some balloon memory, which needs to 
take the balloon_lock that is being held by the task who is sleeping.


So, using GFP_NOWAIT avoids sleeping to get memory through directly 
memory reclaiming, which could fall into that OOM code path that needs 
to take the balloon_lock.




But passing GFP_NOWAIT means that we can handle allocation failure. There is
no need to use preload approach when we can handle allocation failure.


I think the reason we need xb_preload is because radix tree insertion 
needs the memory being preallocated already (it couldn't suffer from 
memory failure during the process of inserting, probably because 
handling the failure there isn't easy, Matthew may know the backstory of 
this)


So, I think we can handle the memory failure with xb_preload, which 
stops going into the radix tree APIs, but shouldn't call radix tree APIs 
without the related memory preallocated.


Best,
Wei

Re: mailbox: ti-msgmgr: Switch to SPDX Licensing

[Jassi Brar]

On Sun, Dec 17, 2017 at 3:19 AM, Nishanth Menon  wrote:
> On 08:21-20171213, Lokesh Vutla wrote:
>>
>>
>> On Saturday 02 December 2017 03:52 PM, Nishanth Menon wrote:
>> > Switch to SPDX licensing and drop the GPL text which comes redundant.
>> >
>> > Signed-off-by: Nishanth Menon 
>>
>>
>> Reviewed-by: Lokesh Vutla 
>>
>
> Hi Jassi,
>Gentle ping.
>
I haven't missed. I usually club patches, that don't fix a bug, for
the merge window.
Cheers!

Re: mailbox: ti-msgmgr: Switch to SPDX Licensing

[Jassi Brar]

On Sun, Dec 17, 2017 at 3:19 AM, Nishanth Menon  wrote:
> On 08:21-20171213, Lokesh Vutla wrote:
>>
>>
>> On Saturday 02 December 2017 03:52 PM, Nishanth Menon wrote:
>> > Switch to SPDX licensing and drop the GPL text which comes redundant.
>> >
>> > Signed-off-by: Nishanth Menon 
>>
>>
>> Reviewed-by: Lokesh Vutla 
>>
>
> Hi Jassi,
>Gentle ping.
>
I haven't missed. I usually club patches, that don't fix a bug, for
the merge window.
Cheers!

[PATCH] KVM: x86: Assign separate names for Intel and AMD to LBR MSRs

[Soramichi AKIYAMA]

Some of the MSRs related to LBR (Last Branch Record) have different names
and layouts among Intel and AMD, but the kernel does not distinguish them.
Currently it does not invoke any bugs, but it is better to assign them separate
macros in order to avoid confusion.

Signed-off-by: Soramichi Akiyama 
---
 arch/x86/include/asm/msr-index.h | 19 +++
 arch/x86/kvm/x86.c   |  8 
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 34c4922bbc3f..a1c69de453d1 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -123,10 +123,21 @@
 #define MSR_IA32_CR_PAT0x0277
 
 #define MSR_IA32_DEBUGCTLMSR   0x01d9
-#define MSR_IA32_LASTBRANCHFROMIP  0x01db
-#define MSR_IA32_LASTBRANCHTOIP0x01dc
-#define MSR_IA32_LASTINTFROMIP 0x01dd
-#define MSR_IA32_LASTINTTOIP   0x01de
+/*
+ * 0x1db - 0x1de have different names and layouts between Intel and AMD
+ * so it is better to define dedicated macros for each of them.
+ * An Intel one (e.g. MSR_IA32_LASTBRANCH0) contains both "from" and "to"
+ * addresses (because they are used only in old 32 bit CPUs), while an AMD
+ * one (e.g. MSR_IA32_LASTBRANCHFROMIP) contains only one 64 bits address.
+ */
+#define MSR_IA32_LASTBRANCH0   0x01db /* Intel */
+#define MSR_IA32_LASTBRANCH1   0x01dc /* Intel */
+#define MSR_IA32_LASTBRANCH2   0x01dd /* Intel */
+#define MSR_IA32_LASTBRANCH3   0x01de /* Intel */
+#define MSR_IA32_LASTBRANCHFROMIP  0x01db /* AMD */
+#define MSR_IA32_LASTBRANCHTOIP0x01dc /* AMD */
+#define MSR_IA32_LASTINTFROMIP 0x01dd /* AMD */
+#define MSR_IA32_LASTINTTOIP   0x01de /* AMD */
 
 /* DEBUGCTLMSR bits (others vary by model): */
 #define DEBUGCTLMSR_LBR(1UL <<  0) /* last branch 
recording */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 56d036b9ad75..cef109f112f5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2434,10 +2434,10 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_IA32_PLATFORM_ID:
case MSR_IA32_EBL_CR_POWERON:
case MSR_IA32_DEBUGCTLMSR:
-   case MSR_IA32_LASTBRANCHFROMIP:
-   case MSR_IA32_LASTBRANCHTOIP:
-   case MSR_IA32_LASTINTFROMIP:
-   case MSR_IA32_LASTINTTOIP:
+   case MSR_IA32_LASTBRANCH0:
+   case MSR_IA32_LASTBRANCH1:
+   case MSR_IA32_LASTBRANCH2:
+   case MSR_IA32_LASTBRANCH3:
case MSR_K8_SYSCFG:
case MSR_K8_TSEG_ADDR:
case MSR_K8_TSEG_MASK:
-- 
2.11.0

[PATCH] KVM: x86: Assign separate names for Intel and AMD to LBR MSRs

[Soramichi AKIYAMA]

Some of the MSRs related to LBR (Last Branch Record) have different names
and layouts among Intel and AMD, but the kernel does not distinguish them.
Currently it does not invoke any bugs, but it is better to assign them separate
macros in order to avoid confusion.

Signed-off-by: Soramichi Akiyama 
---
 arch/x86/include/asm/msr-index.h | 19 +++
 arch/x86/kvm/x86.c   |  8 
 2 files changed, 19 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/msr-index.h b/arch/x86/include/asm/msr-index.h
index 34c4922bbc3f..a1c69de453d1 100644
--- a/arch/x86/include/asm/msr-index.h
+++ b/arch/x86/include/asm/msr-index.h
@@ -123,10 +123,21 @@
 #define MSR_IA32_CR_PAT0x0277
 
 #define MSR_IA32_DEBUGCTLMSR   0x01d9
-#define MSR_IA32_LASTBRANCHFROMIP  0x01db
-#define MSR_IA32_LASTBRANCHTOIP0x01dc
-#define MSR_IA32_LASTINTFROMIP 0x01dd
-#define MSR_IA32_LASTINTTOIP   0x01de
+/*
+ * 0x1db - 0x1de have different names and layouts between Intel and AMD
+ * so it is better to define dedicated macros for each of them.
+ * An Intel one (e.g. MSR_IA32_LASTBRANCH0) contains both "from" and "to"
+ * addresses (because they are used only in old 32 bit CPUs), while an AMD
+ * one (e.g. MSR_IA32_LASTBRANCHFROMIP) contains only one 64 bits address.
+ */
+#define MSR_IA32_LASTBRANCH0   0x01db /* Intel */
+#define MSR_IA32_LASTBRANCH1   0x01dc /* Intel */
+#define MSR_IA32_LASTBRANCH2   0x01dd /* Intel */
+#define MSR_IA32_LASTBRANCH3   0x01de /* Intel */
+#define MSR_IA32_LASTBRANCHFROMIP  0x01db /* AMD */
+#define MSR_IA32_LASTBRANCHTOIP0x01dc /* AMD */
+#define MSR_IA32_LASTINTFROMIP 0x01dd /* AMD */
+#define MSR_IA32_LASTINTTOIP   0x01de /* AMD */
 
 /* DEBUGCTLMSR bits (others vary by model): */
 #define DEBUGCTLMSR_LBR(1UL <<  0) /* last branch 
recording */
diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
index 56d036b9ad75..cef109f112f5 100644
--- a/arch/x86/kvm/x86.c
+++ b/arch/x86/kvm/x86.c
@@ -2434,10 +2434,10 @@ int kvm_get_msr_common(struct kvm_vcpu *vcpu, struct 
msr_data *msr_info)
case MSR_IA32_PLATFORM_ID:
case MSR_IA32_EBL_CR_POWERON:
case MSR_IA32_DEBUGCTLMSR:
-   case MSR_IA32_LASTBRANCHFROMIP:
-   case MSR_IA32_LASTBRANCHTOIP:
-   case MSR_IA32_LASTINTFROMIP:
-   case MSR_IA32_LASTINTTOIP:
+   case MSR_IA32_LASTBRANCH0:
+   case MSR_IA32_LASTBRANCH1:
+   case MSR_IA32_LASTBRANCH2:
+   case MSR_IA32_LASTBRANCH3:
case MSR_K8_SYSCFG:
case MSR_K8_TSEG_ADDR:
case MSR_K8_TSEG_MASK:
-- 
2.11.0

[alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

[Steven Eckhoff]

Currently there is no support for TSCS42xx audio CODECs.

Add support for TSCS42xx audio CODECs.

Acked-by: Philippe Ombredanne 
Signed-off-by: Steven Eckhoff 
---
 .../devicetree/bindings/sound/tscs42xx.txt |   16 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 MAINTAINERS|7 +
 sound/soc/codecs/Kconfig   |8 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/tscs42xx.c| 1520 +++
 sound/soc/codecs/tscs42xx.h| 2693 
 7 files changed, 4247 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/tscs42xx.txt
 create mode 100644 sound/soc/codecs/tscs42xx.c
 create mode 100644 sound/soc/codecs/tscs42xx.h

diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt 
b/Documentation/devicetree/bindings/sound/tscs42xx.txt
new file mode 100644
index ..2ac2f0996697
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt
@@ -0,0 +1,16 @@
+TSCS42XX Audio CODEC
+
+Required Properties:
+
+   - compatible :  "tempo,tscs42A1" for analog mic
+   "tempo,tscs42A2" for digital mic
+
+   - reg : <0x71> for analog mic
+   <0x69> for digital mic
+
+Example:
+
+wookie: codec@69 {
+   compatible = "tempo,tscs42A2";
+   reg = <0x69>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef73ab0d..4543e688c5d4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ snps  Synopsys, Inc.
 st STMicroelectronics
 steST-Ericsson
 stericsson ST-Ericsson
+tempo  Tempo Semiconductor
 ti Texas Instruments
 toshibaToshiba Corporation
 viaVIA Technologies, Inc.
diff --git a/MAINTAINERS b/MAINTAINERS
index 8bdd7a7ef2f4..6c9adfcbc7a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8094,6 +8094,13 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
 S: Maintained
 K: ^Subject:.*(?i)trivial
 
+TEMPO SEMICONDUCTOR DRIVERS
+M: Steven Eckhoff 
+S: Maintained
+F: sound/soc/codecs/tscs*.c
+F: sound/soc/codecs/tscs*.h
+F: Documentation/devicetree/bindings/sound/tscs*.txt
+
 TTY LAYER
 M: Greg Kroah-Hartman 
 M: Jiri Slaby 
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 45b72561c615..dcedfaa2c94d 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -69,6 +69,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
+   select SND_SOC_TSCS42XX if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
select SND_SOC_UDA134X
@@ -336,6 +337,13 @@ config SND_SOC_TLV320AIC3X
 config SND_SOC_TLV320DAC33
tristate
 
+config SND_SOC_TSCS42XX
+   tristate "Tempo Semiconductor TSCS42xx CODEC"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Add support for Tempo Semiconductor's TSCS42xx audio CODEC.
+
 config SND_SOC_TWL4030
select MFD_TWL4030_AUDIO
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 6a3b3c3b8b41..2d42710a6bc2 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -60,6 +60,7 @@ snd-soc-tlv320aic26-objs := tlv320aic26.o
 snd-soc-tlv320aic3x-objs := tlv320aic3x.o
 snd-soc-tlv320aic32x4-objs := tlv320aic32x4.o
 snd-soc-tlv320dac33-objs := tlv320dac33.o
+snd-soc-tscs42xx-objs := tscs42xx.o
 snd-soc-twl4030-objs := twl4030.o
 snd-soc-twl6040-objs := twl6040.o
 snd-soc-uda134x-objs := uda134x.o
@@ -182,6 +183,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC26)   += snd-soc-tlv320aic26.o
 obj-$(CONFIG_SND_SOC_TLV320AIC3X)  += snd-soc-tlv320aic3x.o
 obj-$(CONFIG_SND_SOC_TLV320AIC32X4) += snd-soc-tlv320aic32x4.o
 obj-$(CONFIG_SND_SOC_TLV320DAC33)  += snd-soc-tlv320dac33.o
+obj-$(CONFIG_SND_SOC_TSCS42XX) += snd-soc-tscs42xx.o
 obj-$(CONFIG_SND_SOC_TWL4030)  += snd-soc-twl4030.o
 obj-$(CONFIG_SND_SOC_TWL6040)  += snd-soc-twl6040.o
 obj-$(CONFIG_SND_SOC_UDA134X)  += snd-soc-uda134x.o
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
new file mode 100644
index ..840f6e3ba160
--- /dev/null
+++ b/sound/soc/codecs/tscs42xx.c
@@ -0,0 +1,1520 @@
+// SPDX-License-Identifier: GPL-2.0
+// tscs42xx.c -- TSCS42xx ALSA SoC Audio driver
+// Copyright 2017 Tempo Semiconductor, Inc.
+// Author: Steven Eckhoff 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+

[alsa-devel][PATCH v6] ASoC: TSCS42xx: Support Tempo Semiconductor's TSCS42xx audio CODECs

[Steven Eckhoff]

Currently there is no support for TSCS42xx audio CODECs.

Add support for TSCS42xx audio CODECs.

Acked-by: Philippe Ombredanne 
Signed-off-by: Steven Eckhoff 
---
 .../devicetree/bindings/sound/tscs42xx.txt |   16 +
 .../devicetree/bindings/vendor-prefixes.txt|1 +
 MAINTAINERS|7 +
 sound/soc/codecs/Kconfig   |8 +
 sound/soc/codecs/Makefile  |2 +
 sound/soc/codecs/tscs42xx.c| 1520 +++
 sound/soc/codecs/tscs42xx.h| 2693 
 7 files changed, 4247 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/sound/tscs42xx.txt
 create mode 100644 sound/soc/codecs/tscs42xx.c
 create mode 100644 sound/soc/codecs/tscs42xx.h

diff --git a/Documentation/devicetree/bindings/sound/tscs42xx.txt 
b/Documentation/devicetree/bindings/sound/tscs42xx.txt
new file mode 100644
index ..2ac2f0996697
--- /dev/null
+++ b/Documentation/devicetree/bindings/sound/tscs42xx.txt
@@ -0,0 +1,16 @@
+TSCS42XX Audio CODEC
+
+Required Properties:
+
+   - compatible :  "tempo,tscs42A1" for analog mic
+   "tempo,tscs42A2" for digital mic
+
+   - reg : <0x71> for analog mic
+   <0x69> for digital mic
+
+Example:
+
+wookie: codec@69 {
+   compatible = "tempo,tscs42A2";
+   reg = <0x69>;
+};
diff --git a/Documentation/devicetree/bindings/vendor-prefixes.txt 
b/Documentation/devicetree/bindings/vendor-prefixes.txt
index 19e1ef73ab0d..4543e688c5d4 100644
--- a/Documentation/devicetree/bindings/vendor-prefixes.txt
+++ b/Documentation/devicetree/bindings/vendor-prefixes.txt
@@ -54,6 +54,7 @@ snps  Synopsys, Inc.
 st STMicroelectronics
 steST-Ericsson
 stericsson ST-Ericsson
+tempo  Tempo Semiconductor
 ti Texas Instruments
 toshibaToshiba Corporation
 viaVIA Technologies, Inc.
diff --git a/MAINTAINERS b/MAINTAINERS
index 8bdd7a7ef2f4..6c9adfcbc7a4 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -8094,6 +8094,13 @@ T:   git 
git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial.git
 S: Maintained
 K: ^Subject:.*(?i)trivial
 
+TEMPO SEMICONDUCTOR DRIVERS
+M: Steven Eckhoff 
+S: Maintained
+F: sound/soc/codecs/tscs*.c
+F: sound/soc/codecs/tscs*.h
+F: Documentation/devicetree/bindings/sound/tscs*.txt
+
 TTY LAYER
 M: Greg Kroah-Hartman 
 M: Jiri Slaby 
diff --git a/sound/soc/codecs/Kconfig b/sound/soc/codecs/Kconfig
index 45b72561c615..dcedfaa2c94d 100644
--- a/sound/soc/codecs/Kconfig
+++ b/sound/soc/codecs/Kconfig
@@ -69,6 +69,7 @@ config SND_SOC_ALL_CODECS
select SND_SOC_TLV320AIC3X if I2C
select SND_SOC_TPA6130A2 if I2C
select SND_SOC_TLV320DAC33 if I2C
+   select SND_SOC_TSCS42XX if I2C
select SND_SOC_TWL4030 if TWL4030_CORE
select SND_SOC_TWL6040 if TWL6040_CORE
select SND_SOC_UDA134X
@@ -336,6 +337,13 @@ config SND_SOC_TLV320AIC3X
 config SND_SOC_TLV320DAC33
tristate
 
+config SND_SOC_TSCS42XX
+   tristate "Tempo Semiconductor TSCS42xx CODEC"
+   depends on I2C
+   select REGMAP_I2C
+   help
+ Add support for Tempo Semiconductor's TSCS42xx audio CODEC.
+
 config SND_SOC_TWL4030
select MFD_TWL4030_AUDIO
tristate
diff --git a/sound/soc/codecs/Makefile b/sound/soc/codecs/Makefile
index 6a3b3c3b8b41..2d42710a6bc2 100644
--- a/sound/soc/codecs/Makefile
+++ b/sound/soc/codecs/Makefile
@@ -60,6 +60,7 @@ snd-soc-tlv320aic26-objs := tlv320aic26.o
 snd-soc-tlv320aic3x-objs := tlv320aic3x.o
 snd-soc-tlv320aic32x4-objs := tlv320aic32x4.o
 snd-soc-tlv320dac33-objs := tlv320dac33.o
+snd-soc-tscs42xx-objs := tscs42xx.o
 snd-soc-twl4030-objs := twl4030.o
 snd-soc-twl6040-objs := twl6040.o
 snd-soc-uda134x-objs := uda134x.o
@@ -182,6 +183,7 @@ obj-$(CONFIG_SND_SOC_TLV320AIC26)   += snd-soc-tlv320aic26.o
 obj-$(CONFIG_SND_SOC_TLV320AIC3X)  += snd-soc-tlv320aic3x.o
 obj-$(CONFIG_SND_SOC_TLV320AIC32X4) += snd-soc-tlv320aic32x4.o
 obj-$(CONFIG_SND_SOC_TLV320DAC33)  += snd-soc-tlv320dac33.o
+obj-$(CONFIG_SND_SOC_TSCS42XX) += snd-soc-tscs42xx.o
 obj-$(CONFIG_SND_SOC_TWL4030)  += snd-soc-twl4030.o
 obj-$(CONFIG_SND_SOC_TWL6040)  += snd-soc-twl6040.o
 obj-$(CONFIG_SND_SOC_UDA134X)  += snd-soc-uda134x.o
diff --git a/sound/soc/codecs/tscs42xx.c b/sound/soc/codecs/tscs42xx.c
new file mode 100644
index ..840f6e3ba160
--- /dev/null
+++ b/sound/soc/codecs/tscs42xx.c
@@ -0,0 +1,1520 @@
+// SPDX-License-Identifier: GPL-2.0
+// tscs42xx.c -- TSCS42xx ALSA SoC Audio driver
+// Copyright 2017 Tempo Semiconductor, Inc.
+// Author: Steven Eckhoff 
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "tscs42xx.h"
+
+#define COEFF_SIZE 3
+#define BIQUAD_COEFF_COUNT 5
+#define BIQUAD_SIZE (COEFF_SIZE * BIQUAD_COEFF_COUNT)
+
+#define COEFF_RAM_MAX_ADDR 0xcd
+#define 

Re: [PATCH] ipv6: icmp6: Allow icmp messages to be looped back

[David Miller]

From: Brendan McGrath 
Date: Wed, 13 Dec 2017 22:14:57 +1100

> One example of when an ICMPv6 packet is required to be looped back is
> when a host acts as both a Multicast Listener and a Multicast Router.
> 
> A Multicast Router will listen on address ff02::16 for MLDv2 messages.
> 
> Currently, MLDv2 messages originating from a Multicast Listener running
> on the same host as the Multicast Router are not being delivered to the
> Multicast Router. This is due to dst.input being assigned the default
> value of dst_discard.
> 
> This results in the packet being looped back but discarded before being
> delivered to the Multicast Router.
> 
> This patch sets dst.input to ip6_input to ensure a looped back packet
> is delivered to the Multicast Router.
> 
> Signed-off-by: Brendan McGrath 

Ok, after a lot of consideration this seems like a reasonable way to
solve this problem.

Applied, thank you.

Re: [PATCH] ipv6: icmp6: Allow icmp messages to be looped back

[David Miller]

From: Brendan McGrath 
Date: Wed, 13 Dec 2017 22:14:57 +1100

> One example of when an ICMPv6 packet is required to be looped back is
> when a host acts as both a Multicast Listener and a Multicast Router.
> 
> A Multicast Router will listen on address ff02::16 for MLDv2 messages.
> 
> Currently, MLDv2 messages originating from a Multicast Listener running
> on the same host as the Multicast Router are not being delivered to the
> Multicast Router. This is due to dst.input being assigned the default
> value of dst_discard.
> 
> This results in the packet being looped back but discarded before being
> delivered to the Multicast Router.
> 
> This patch sets dst.input to ip6_input to ensure a looped back packet
> is delivered to the Multicast Router.
> 
> Signed-off-by: Brendan McGrath 

Ok, after a lot of consideration this seems like a reasonable way to
solve this problem.

Applied, thank you.

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[Nicolas Pitre]

On Sat, 16 Dec 2017, Linus Torvalds wrote:

> Nico,
> 
> On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot
>  wrote:
> >
> > fs/cramfs/inode.c:641: undefined reference to `mtd_point'
> > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
> > fs/cramfs/inode.c:959: undefined reference to `mount_mtd'
> 
> This does seem to be real.
> 
> As of 99c18ce580c6 ("cramfs: direct memory access support") cramfs
> seems to require MTD, but that's not expressed in the Kconfig.

That was reported a while ago. The fix didn't make it up to you somehow. 
Please apply the following:

- >8
Date: Fri, 10 Nov 2017 15:57:21 +0100
From: Arnd Bergmann 
Subject: [PATCH] cramfs: fix MTD dependency

With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:

fs/cramfs/inode.o: In function `cramfs_mount':
inode.c:(.text+0x220): undefined reference to `mount_mtd'
fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
inode.c:(.text+0x6d8): undefined reference to `mtd_point'
inode.c:(.text+0xae4): undefined reference to `mtd_unpoint'

This adds a more specific Kconfig dependency to avoid the
broken configuration. Alternatively we could make CRAMFS
itself depend on "MTD || !MTD" with a similar result.

Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Nicolas Pitre 
---
 fs/cramfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
index f937082f3244..58e2fe40b2a0 100644
--- a/fs/cramfs/Kconfig
+++ b/fs/cramfs/Kconfig
@@ -34,6 +34,7 @@ config CRAMFS_BLOCKDEV
 config CRAMFS_MTD
bool "Support CramFs image directly mapped in physical memory"
depends on CRAMFS && MTD
+   depends on CRAMFS=m || MTD=y
default y if !CRAMFS_BLOCKDEV
help
  This option allows the CramFs driver to load data directly from

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[Nicolas Pitre]

On Sat, 16 Dec 2017, Linus Torvalds wrote:

> Nico,
> 
> On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot
>  wrote:
> >
> > fs/cramfs/inode.c:641: undefined reference to `mtd_point'
> > fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
> > fs/cramfs/inode.c:959: undefined reference to `mount_mtd'
> 
> This does seem to be real.
> 
> As of 99c18ce580c6 ("cramfs: direct memory access support") cramfs
> seems to require MTD, but that's not expressed in the Kconfig.

That was reported a while ago. The fix didn't make it up to you somehow. 
Please apply the following:

- >8
Date: Fri, 10 Nov 2017 15:57:21 +0100
From: Arnd Bergmann 
Subject: [PATCH] cramfs: fix MTD dependency

With CONFIG_MTD=m and CONFIG_CRAMFS=y, we now get a link failure:

fs/cramfs/inode.o: In function `cramfs_mount':
inode.c:(.text+0x220): undefined reference to `mount_mtd'
fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
inode.c:(.text+0x6d8): undefined reference to `mtd_point'
inode.c:(.text+0xae4): undefined reference to `mtd_unpoint'

This adds a more specific Kconfig dependency to avoid the
broken configuration. Alternatively we could make CRAMFS
itself depend on "MTD || !MTD" with a similar result.

Fixes: 99c18ce580c6 ("cramfs: direct memory access support")
Signed-off-by: Arnd Bergmann 
Signed-off-by: Nicolas Pitre 
---
 fs/cramfs/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/fs/cramfs/Kconfig b/fs/cramfs/Kconfig
index f937082f3244..58e2fe40b2a0 100644
--- a/fs/cramfs/Kconfig
+++ b/fs/cramfs/Kconfig
@@ -34,6 +34,7 @@ config CRAMFS_BLOCKDEV
 config CRAMFS_MTD
bool "Support CramFs image directly mapped in physical memory"
depends on CRAMFS && MTD
+   depends on CRAMFS=m || MTD=y
default y if !CRAMFS_BLOCKDEV
help
  This option allows the CramFs driver to load data directly from

Re: [GIT PULL] x86 fixes

[Andy Lutomirski]

On Fri, Dec 15, 2017 at 8:07 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> On Fri, Dec 15, 2017 at 7:43 AM, Ingo Molnar  wrote:
>> > Linus,
>>
>> >
>> >  - two 5-level paging related fixes
>>
>> Which reminds me: can you grab this one, too?
>>
>> https://lkml.kernel.org/r/24c898b4f44fdf8c22d93703850fb384ef87cfdc.1513035461.git.l...@kernel.org
>
> Yeah, done - it's now in x86/urgent as:
>
>   c739f930be1d: x86/espfix/64: Fix espfix double-fault handling on 5-level 
> systems
>
> Will push it out soon. Linus will get it with the next x86/urgent batch, as
> there's no production 5-level paging CPUs out there yet, right?
>
> I'm also picking up your pending PTI fixes/updates over the weekend, but I 
> spent
> today mostly to make sure that the system call trampoline bits and its
> dependencies were robust in practice.
>
> Could you please have a good look at that tree:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tmp.tmp
>
> This includes the preparatory merges and cherry-picks, and some other low risk
> preparatory bits related to PTI.
>
> Is this tree looking good to you standalone?

I think this stuff is looking okay, although I'm a bit mystified by
the whole merge base thing.  But if the backporters and Linus like it,
then whatever.

I few things I noticed in the PTI tree:

"x86/mm/pti: Map ESPFIX into user space" has a leftover pr_err().
Sorry, my bad, I've spent *way* too long looking at this crap to
retain my sanity.  Also, if you're feeling like being super tidy, the
init/main.c change in their could be folded in to whatever patch adds
pti_init() in the first place, but it doesn't really matter.

"x86/pti: Map the vsyscall page if needed" has a change to
pgtable_64.h that could be folded into an earlier patch.  This is
probably my fault for applying Dave Hansen's cleanup request to the
wrong patch.

"x86/mm/64: Make a full PGD-entry size hole in the memory map" would
benefit from a mention of "5-level" somewhere in the subject or
changelog.

In "x86/fixmap: Add debugstore entries to cpu_entry_area", I think the
function "set_percpu_fixmap_ptes" is misnamed.  It should be something
like "allocate_percpu_fixmap_ptes", perhaps, and it should either warn
or do nothing if the PTE is already present, I think.  As it stands,
it's a wee bit dangerous.

X86_BUG_CPU_SECURE_MODE_PTI should be added to DISABLED_FEATURES or
DISABLED_BUGS or whatever if it's not configured in, which will reduce
bloat.  Borislav, that's kind of up your alley, since I don't think
the appropriate mask even exists right now.



Anyway, I stuck a few minor fixups here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti

Re: [GIT PULL] x86 fixes

[Andy Lutomirski]

On Fri, Dec 15, 2017 at 8:07 AM, Ingo Molnar  wrote:
>
> * Andy Lutomirski  wrote:
>
>> On Fri, Dec 15, 2017 at 7:43 AM, Ingo Molnar  wrote:
>> > Linus,
>>
>> >
>> >  - two 5-level paging related fixes
>>
>> Which reminds me: can you grab this one, too?
>>
>> https://lkml.kernel.org/r/24c898b4f44fdf8c22d93703850fb384ef87cfdc.1513035461.git.l...@kernel.org
>
> Yeah, done - it's now in x86/urgent as:
>
>   c739f930be1d: x86/espfix/64: Fix espfix double-fault handling on 5-level 
> systems
>
> Will push it out soon. Linus will get it with the next x86/urgent batch, as
> there's no production 5-level paging CPUs out there yet, right?
>
> I'm also picking up your pending PTI fixes/updates over the weekend, but I 
> spent
> today mostly to make sure that the system call trampoline bits and its
> dependencies were robust in practice.
>
> Could you please have a good look at that tree:
>
>git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git tmp.tmp
>
> This includes the preparatory merges and cherry-picks, and some other low risk
> preparatory bits related to PTI.
>
> Is this tree looking good to you standalone?

I think this stuff is looking okay, although I'm a bit mystified by
the whole merge base thing.  But if the backporters and Linus like it,
then whatever.

I few things I noticed in the PTI tree:

"x86/mm/pti: Map ESPFIX into user space" has a leftover pr_err().
Sorry, my bad, I've spent *way* too long looking at this crap to
retain my sanity.  Also, if you're feeling like being super tidy, the
init/main.c change in their could be folded in to whatever patch adds
pti_init() in the first place, but it doesn't really matter.

"x86/pti: Map the vsyscall page if needed" has a change to
pgtable_64.h that could be folded into an earlier patch.  This is
probably my fault for applying Dave Hansen's cleanup request to the
wrong patch.

"x86/mm/64: Make a full PGD-entry size hole in the memory map" would
benefit from a mention of "5-level" somewhere in the subject or
changelog.

In "x86/fixmap: Add debugstore entries to cpu_entry_area", I think the
function "set_percpu_fixmap_ptes" is misnamed.  It should be something
like "allocate_percpu_fixmap_ptes", perhaps, and it should either warn
or do nothing if the PTE is already present, I think.  As it stands,
it's a wee bit dangerous.

X86_BUG_CPU_SECURE_MODE_PTI should be added to DISABLED_FEATURES or
DISABLED_BUGS or whatever if it's not configured in, which will reduce
bloat.  Borislav, that's kind of up your alley, since I don't think
the appropriate mask even exists right now.



Anyway, I stuck a few minor fixups here:

https://git.kernel.org/pub/scm/linux/kernel/git/luto/linux.git/log/?h=x86/pti

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[Linus Torvalds]

Nico,

On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot
 wrote:
>
> fs/cramfs/inode.c:641: undefined reference to `mtd_point'
> fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
> fs/cramfs/inode.c:959: undefined reference to `mount_mtd'

This does seem to be real.

As of 99c18ce580c6 ("cramfs: direct memory access support") cramfs
seems to require MTD, but that's not expressed in the Kconfig.

Oddly, _some_ of the mtd functions are protected with

if (IS_ENABLED(CCONFIG_CRAMFS_MTD) ..)

but cramfs_mtd_fill_super() is not.

It is only *used* if CONFIG_CRAMFS_MTD is enabled (the call to
mount_mtd(.., cramfs_mtd_fill_super) is conditional, but..

   Linus

Re: [linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[Linus Torvalds]

Nico,

On Sat, Dec 16, 2017 at 7:00 PM, kbuild test robot
 wrote:
>
> fs/cramfs/inode.c:641: undefined reference to `mtd_point'
> fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
> fs/cramfs/inode.c:959: undefined reference to `mount_mtd'

This does seem to be real.

As of 99c18ce580c6 ("cramfs: direct memory access support") cramfs
seems to require MTD, but that's not expressed in the Kconfig.

Oddly, _some_ of the mtd functions are protected with

if (IS_ENABLED(CCONFIG_CRAMFS_MTD) ..)

but cramfs_mtd_fill_super() is not.

It is only *used* if CONFIG_CRAMFS_MTD is enabled (the call to
mount_mtd(.., cramfs_mtd_fill_super) is conditional, but..

   Linus

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> On POWER8 and POWER9, the PMSR and the PMCR registers define pstates
> to be 8-bit wide values. The device-tree exports pstates as 32-bit
> wide values of which the lower byte is the actual pstate.
>
> The current implementation in the kernel treats pstates as integer
> type, since it used to use the sign of the pstate for performing some
> boundary-checks. This is no longer required after the patch
> "powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous
> pstates".
>
> So, in this patch, we modify the powernv-cpufreq driver to uniformly
> treat pstates as opaque 8-bit values obtained from the device-tree or
> the PMCR. This simplifies the extract_pstate() helper function since
> we no longer no longer require to worry about the sign-extentions.
>
> Signed-off-by: Gautham R. Shenoy 
> ---
>  drivers/cpufreq/powernv-cpufreq.c | 47 
> ---
>  1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index 8e3dbca..8a4e2ce 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -110,12 +110,11 @@ struct global_pstate_info {
>   * hashtable
>   */
>  struct pstate_idx_revmap_data {
> -   int pstate_id;
> +   u8 pstate_id;
> unsigned int cpufreq_table_idx;
> struct hlist_node hentry;
>  };
>
> -u32 pstate_sign_prefix;
>  static bool rebooting, throttled, occ_reset;
>
>  static const char * const throttle_reason[] = {
> @@ -170,14 +169,9 @@ enum throttle_reason_type {
> bool wof_enabled;
>  } powernv_pstate_info;
>
> -static inline int extract_pstate(u64 pmsr_val, unsigned int shift)
> +static inline u8 extract_pstate(u64 pmsr_val, unsigned int shift)
>  {
> -   int ret = ((pmsr_val >> shift) & 0xFF);
> -
> -   if (!ret)
> -   return ret;
> -
> -   return (pstate_sign_prefix | ret);
> +   return ((pmsr_val >> shift) & 0xFF);
>  }

So we just added this and moved from an int to u8. I was going to ask
if we still need an int in patch1, but I thought the driver dealt with
just integers because of the larger framework.

Balbir Singh.

Re: [v3 PATCH 3/3] powernv-cpufreq: Treat pstates as opaque 8-bit values

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> On POWER8 and POWER9, the PMSR and the PMCR registers define pstates
> to be 8-bit wide values. The device-tree exports pstates as 32-bit
> wide values of which the lower byte is the actual pstate.
>
> The current implementation in the kernel treats pstates as integer
> type, since it used to use the sign of the pstate for performing some
> boundary-checks. This is no longer required after the patch
> "powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous
> pstates".
>
> So, in this patch, we modify the powernv-cpufreq driver to uniformly
> treat pstates as opaque 8-bit values obtained from the device-tree or
> the PMCR. This simplifies the extract_pstate() helper function since
> we no longer no longer require to worry about the sign-extentions.
>
> Signed-off-by: Gautham R. Shenoy 
> ---
>  drivers/cpufreq/powernv-cpufreq.c | 47 
> ---
>  1 file changed, 19 insertions(+), 28 deletions(-)
>
> diff --git a/drivers/cpufreq/powernv-cpufreq.c 
> b/drivers/cpufreq/powernv-cpufreq.c
> index 8e3dbca..8a4e2ce 100644
> --- a/drivers/cpufreq/powernv-cpufreq.c
> +++ b/drivers/cpufreq/powernv-cpufreq.c
> @@ -110,12 +110,11 @@ struct global_pstate_info {
>   * hashtable
>   */
>  struct pstate_idx_revmap_data {
> -   int pstate_id;
> +   u8 pstate_id;
> unsigned int cpufreq_table_idx;
> struct hlist_node hentry;
>  };
>
> -u32 pstate_sign_prefix;
>  static bool rebooting, throttled, occ_reset;
>
>  static const char * const throttle_reason[] = {
> @@ -170,14 +169,9 @@ enum throttle_reason_type {
> bool wof_enabled;
>  } powernv_pstate_info;
>
> -static inline int extract_pstate(u64 pmsr_val, unsigned int shift)
> +static inline u8 extract_pstate(u64 pmsr_val, unsigned int shift)
>  {
> -   int ret = ((pmsr_val >> shift) & 0xFF);
> -
> -   if (!ret)
> -   return ret;
> -
> -   return (pstate_sign_prefix | ret);
> +   return ((pmsr_val >> shift) & 0xFF);
>  }

So we just added this and moved from an int to u8. I was going to ask
if we still need an int in patch1, but I thought the driver dealt with
just integers because of the larger framework.

Balbir Singh.

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> The code in powernv-cpufreq, makes the following two assumptions which
> are not guaranteed by the device-tree bindings:
>
> 1) Pstate ids are continguous: This is used in pstate_to_idx() to
>obtain the reverse map from a pstate to it's corresponding
>entry into the cpufreq frequency table.
>
> 2) Every Pstate should always lie between the max and the min
>pstates that are explicitly reported in the device tree: This
>is used to determine whether a pstate reported by the PMSR is
>out of bounds.
>
> Both these assumptions are unwarranted and can change on future
> platforms.

While this is a good thing, I wonder if it is worth the complexity. Pstates
are contiguous because they define transitions in incremental value
of change in frequency and I can't see how this can be broken in the
future?

Balbir Singh.

Re: [v3 PATCH 2/3] powernv-cpufreq: Fix pstate_to_idx() to handle non-continguous pstates

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> The code in powernv-cpufreq, makes the following two assumptions which
> are not guaranteed by the device-tree bindings:
>
> 1) Pstate ids are continguous: This is used in pstate_to_idx() to
>obtain the reverse map from a pstate to it's corresponding
>entry into the cpufreq frequency table.
>
> 2) Every Pstate should always lie between the max and the min
>pstates that are explicitly reported in the device tree: This
>is used to determine whether a pstate reported by the PMSR is
>out of bounds.
>
> Both these assumptions are unwarranted and can change on future
> platforms.

While this is a good thing, I wonder if it is worth the complexity. Pstates
are contiguous because they define transitions in incremental value
of change in frequency and I can't see how this can be broken in the
future?

Balbir Singh.

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> On POWERNV platform, the fields for pstates in the Power Management
> Status Register (PMSR) and the Power Management Control Register
> (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered
> while on POWER9 they are positively numbered.
>
> The device-tree exports pstates as 32-bit entries. The device-tree
> implementation sign-extends the 8-bit pstate values to obtain the
> corresponding 32-bit entry.
>
> Eg: On POWER8, a pstate value 0x82 [-126] is represented in the
> device-tree as 0xfff82 while on POWER9, the same value 0x82 [130]
> is represented in the device-tree as 0x0082.
>
> The powernv-cpufreq driver implementation represents pstates using the
> integer type. In multiple places in the driver, the code interprets
> the pstates extracted from the PMSR as a signed byte and assigns it to
> a integer variable to get the sign-extention.
>
> On POWER9 platforms which have greater than 128 pstates, this results
> in the driver performing incorrect sign-extention, and thereby
> treating a legitimate pstate (say 130) as an invalid pstates (since it
> is interpreted as -126).
>
> This patch fixes the issue by implementing a helper function to
> extract Pstates from PMSR register, and correctly sign-extend it to be
> consistent with the values provided by the device-tree.
>
> Signed-off-by: Gautham R. Shenoy 
> ---

This looks better

Acked-by: Balbir Singh 

Balbir Singh

Re: [v3 PATCH 1/3] powernv-cpufreq: Add helper to extract pstate from PMSR

[Balbir Singh]

On Wed, Dec 13, 2017 at 5:57 PM, Gautham R. Shenoy
 wrote:
> From: "Gautham R. Shenoy" 
>
> On POWERNV platform, the fields for pstates in the Power Management
> Status Register (PMSR) and the Power Management Control Register
> (PMCR) are 8-bits wide. On POWER8 the pstates are negatively numbered
> while on POWER9 they are positively numbered.
>
> The device-tree exports pstates as 32-bit entries. The device-tree
> implementation sign-extends the 8-bit pstate values to obtain the
> corresponding 32-bit entry.
>
> Eg: On POWER8, a pstate value 0x82 [-126] is represented in the
> device-tree as 0xfff82 while on POWER9, the same value 0x82 [130]
> is represented in the device-tree as 0x0082.
>
> The powernv-cpufreq driver implementation represents pstates using the
> integer type. In multiple places in the driver, the code interprets
> the pstates extracted from the PMSR as a signed byte and assigns it to
> a integer variable to get the sign-extention.
>
> On POWER9 platforms which have greater than 128 pstates, this results
> in the driver performing incorrect sign-extention, and thereby
> treating a legitimate pstate (say 130) as an invalid pstates (since it
> is interpreted as -126).
>
> This patch fixes the issue by implementing a helper function to
> extract Pstates from PMSR register, and correctly sign-extend it to be
> consistent with the values provided by the device-tree.
>
> Signed-off-by: Gautham R. Shenoy 
> ---

This looks better

Acked-by: Balbir Singh 

Balbir Singh

[linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[kbuild test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
 master
branch HEAD: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051  Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Regressions in current branch:

cc1: error: '-march=r3900' requires '-mfp32'
fs/cramfs/inode.c:641: undefined reference to `mtd_point'
fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
fs/cramfs/inode.c:959: undefined reference to `mount_mtd'
fs/xfs/xfs_ioctl.c:1629:1: internal compiler error: in change_address_1, at 
emit-rtl.c:2150
Please submit a full bug report,
{standard input}:1226: Error: displacement to undefined symbol .L329 overflows 
12-bit field
{standard input}:1233: Error: displacement to undefined symbol .L331 overflows 
12-bit field
{standard input}:1253: Error: displacement to undefined symbol .L359 overflows 
12-bit field
{standard input}:1278: Error: displacement to undefined symbol .L360 overflows 
12-bit field
{standard input}:1408: Error: invalid operands for opcode
{standard input}:1408: Error: missing operand
{standard input}:1893: Error: displacement to undefined symbol .L229 overflows 
12-bit field
{standard input}:2013: Error: displacement to undefined symbol .L235 overflows 
12-bit field
{standard input}:2299: Error: invalid operands for opcode
{standard input}:2299: Error: missing operand
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc 
directive
verifier.c:(.text+0x372c): undefined reference to `__multi3'

Error ids grouped by kconfigs:

recent_errors
├── i386-randconfig-x018-201751
│   ├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
│   ├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
│   └── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint
├── i386-randconfig-x073-201751
│   ├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
│   ├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
│   └── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint
├── mips-64r6el_defconfig
│   └── verifier.c:(.text):undefined-reference-to-__multi3
├── mips-jmr3927_defconfig
│   └── cc1:error:march-r3900-requires-mfp32
├── sh-allmodconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── Please-submit-a-full-bug-report
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L229-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L235-overflows-bit-field
│   ├── standard-input:Error:invalid-operands-for-opcode
│   ├── standard-input:Error:missing-operand
│   └── 
standard-input:Error:open-CFI-at-the-end-of-file-missing-.cfi_endproc-directive
├── sh-allyesconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── standard-input:Error:invalid-operands-for-opcode
│   ├── standard-input:Error:missing-operand
│   └── 
standard-input:Error:open-CFI-at-the-end-of-file-missing-.cfi_endproc-directive
├── sh-titan_defconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── Please-submit-a-full-bug-report
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L329-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L331-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L359-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L360-overflows-bit-field
│   ├── standard-input:Error:invalid-operands-for-opcode
│   └── standard-input:Error:missing-operand
└── x86_64-randconfig-x015-201751
├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
└── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint


i386-tinyconfig vmlinux size:

=
 TOTAL  TEXT  workqueue_offline_cpu()  wq_unbind_fn()   
 
=
 0 00   0  dabe589657ad Merge 
branch 'efi-urgent-for-linus' of git://git.kernel.org/ 
-8 00   0  61d6be3a7a11 Merge 
branch 'irq-urgent-for-linus' of git://git.kernel.org/ 
 0 00   0  189dbab0dddc Merge 
branch 'locking-urgent-for-linus' of git://git.kernel. 
   +20   +200   0  1c7647253c64 Merge 
branch 'perf-urgent-for-linus' of git://git.kernel.org 
-1-10   0  e017b4db26d0 Merge 
branch 'sched-urgent-for-linus' of git://git.kernel.or 
 0 00   0  4b43a3bc20ec Merge 
branch 'smp-urgent-for-linus' of git://git.kernel.org/ 
   +95   

[linus:master] BUILD REGRESSION f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051

[kbuild test robot]

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
 master
branch HEAD: f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051  Merge tag 'for-linus' of 
git://git.kernel.org/pub/scm/linux/kernel/git/rdma/rdma

Regressions in current branch:

cc1: error: '-march=r3900' requires '-mfp32'
fs/cramfs/inode.c:641: undefined reference to `mtd_point'
fs/cramfs/inode.c:658: undefined reference to `mtd_unpoint'
fs/cramfs/inode.c:959: undefined reference to `mount_mtd'
fs/xfs/xfs_ioctl.c:1629:1: internal compiler error: in change_address_1, at 
emit-rtl.c:2150
Please submit a full bug report,
{standard input}:1226: Error: displacement to undefined symbol .L329 overflows 
12-bit field
{standard input}:1233: Error: displacement to undefined symbol .L331 overflows 
12-bit field
{standard input}:1253: Error: displacement to undefined symbol .L359 overflows 
12-bit field
{standard input}:1278: Error: displacement to undefined symbol .L360 overflows 
12-bit field
{standard input}:1408: Error: invalid operands for opcode
{standard input}:1408: Error: missing operand
{standard input}:1893: Error: displacement to undefined symbol .L229 overflows 
12-bit field
{standard input}:2013: Error: displacement to undefined symbol .L235 overflows 
12-bit field
{standard input}:2299: Error: invalid operands for opcode
{standard input}:2299: Error: missing operand
{standard input}: Error: open CFI at the end of file; missing .cfi_endproc 
directive
verifier.c:(.text+0x372c): undefined reference to `__multi3'

Error ids grouped by kconfigs:

recent_errors
├── i386-randconfig-x018-201751
│   ├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
│   ├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
│   └── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint
├── i386-randconfig-x073-201751
│   ├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
│   ├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
│   └── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint
├── mips-64r6el_defconfig
│   └── verifier.c:(.text):undefined-reference-to-__multi3
├── mips-jmr3927_defconfig
│   └── cc1:error:march-r3900-requires-mfp32
├── sh-allmodconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── Please-submit-a-full-bug-report
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L229-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L235-overflows-bit-field
│   ├── standard-input:Error:invalid-operands-for-opcode
│   ├── standard-input:Error:missing-operand
│   └── 
standard-input:Error:open-CFI-at-the-end-of-file-missing-.cfi_endproc-directive
├── sh-allyesconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── standard-input:Error:invalid-operands-for-opcode
│   ├── standard-input:Error:missing-operand
│   └── 
standard-input:Error:open-CFI-at-the-end-of-file-missing-.cfi_endproc-directive
├── sh-titan_defconfig
│   ├── 
fs-xfs-xfs_ioctl.c:internal-compiler-error:in-change_address_1-at-emit-rtl.c
│   ├── Please-submit-a-full-bug-report
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L329-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L331-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L359-overflows-bit-field
│   ├── 
standard-input:Error:displacement-to-undefined-symbol-.L360-overflows-bit-field
│   ├── standard-input:Error:invalid-operands-for-opcode
│   └── standard-input:Error:missing-operand
└── x86_64-randconfig-x015-201751
├── fs-cramfs-inode.c:undefined-reference-to-mount_mtd
├── fs-cramfs-inode.c:undefined-reference-to-mtd_point
└── fs-cramfs-inode.c:undefined-reference-to-mtd_unpoint


i386-tinyconfig vmlinux size:

=
 TOTAL  TEXT  workqueue_offline_cpu()  wq_unbind_fn()   
 
=
 0 00   0  dabe589657ad Merge 
branch 'efi-urgent-for-linus' of git://git.kernel.org/ 
-8 00   0  61d6be3a7a11 Merge 
branch 'irq-urgent-for-linus' of git://git.kernel.org/ 
 0 00   0  189dbab0dddc Merge 
branch 'locking-urgent-for-linus' of git://git.kernel. 
   +20   +200   0  1c7647253c64 Merge 
branch 'perf-urgent-for-linus' of git://git.kernel.org 
-1-10   0  e017b4db26d0 Merge 
branch 'sched-urgent-for-linus' of git://git.kernel.or 
 0 00   0  4b43a3bc20ec Merge 
branch 'smp-urgent-for-linus' of git://git.kernel.org/ 
   +95   

[no subject]

[Friedrich Mayhofer]

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donates the sum of $ 1,000,000.00 to You, Email Me  
personally for more details.
 

Regards.
Friedrich Mayrhofer

[no subject]

[Friedrich Mayhofer]

This is the second time i am sending you this mail.

I, Friedrich Mayrhofer Donates the sum of $ 1,000,000.00 to You, Email Me  
personally for more details.
 

Regards.
Friedrich Mayrhofer

Re: [tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

[Andy Lutomirski]

On Sat, Dec 16, 2017 at 3:35 PM, kbuild test robot
 wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> WIP.x86/pti-upstream
> head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
> commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
> in its own PGD if PTI is on
> config: i386-randconfig-h0-12170619 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
> git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/x86//kernel/apic/ipi.c:16:0:
>arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>>> (first use in this function)
>  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
>  ^
>arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
> is reported only once for each function it appears in
> --
>In file included from arch/x86//kernel/cpu/common.c:22:0:
>arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>>> (first use in this function)
>  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
>  ^
>arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
> is reported only once for each function it appears in
>In file included from arch/x86//kernel/cpu/common.c:22:0:
>arch/x86/include/asm/mmu_context.h:74:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
> }
> ^
>
> vim +/LDT_BASE_ADDR +73 arch/x86/include/asm/mmu_context.h
>
> 70
> 71  static inline void *ldt_slot_va(int slot)
> 72  {
>   > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
> 74  }
> 75
>

I would fix this like this:

index b7ffd45b22f7..3c7042877e63 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -70,7 +70,11 @@ struct ldt_struct {

 static inline void *ldt_slot_va(int slot)
 {
+#ifdef CONFIG_X86_64
return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
+#else
+   BUG();
+#endif
 }

Ingo or Thomas, want to do that manually?  It's probably easier than
folding in a patch.

Re: [tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

[Andy Lutomirski]

On Sat, Dec 16, 2017 at 3:35 PM, kbuild test robot
 wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
> WIP.x86/pti-upstream
> head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
> commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
> in its own PGD if PTI is on
> config: i386-randconfig-h0-12170619 (attached as .config)
> compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
> reproduce:
> git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
> # save the attached .config to linux build tree
> make ARCH=i386
>
> All errors (new ones prefixed by >>):
>
>In file included from arch/x86//kernel/apic/ipi.c:16:0:
>arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>>> (first use in this function)
>  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
>  ^
>arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
> is reported only once for each function it appears in
> --
>In file included from arch/x86//kernel/cpu/common.c:22:0:
>arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>>> (first use in this function)
>  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
>  ^
>arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
> is reported only once for each function it appears in
>In file included from arch/x86//kernel/cpu/common.c:22:0:
>arch/x86/include/asm/mmu_context.h:74:1: warning: control reaches end of 
> non-void function [-Wreturn-type]
> }
> ^
>
> vim +/LDT_BASE_ADDR +73 arch/x86/include/asm/mmu_context.h
>
> 70
> 71  static inline void *ldt_slot_va(int slot)
> 72  {
>   > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
> 74  }
> 75
>

I would fix this like this:

index b7ffd45b22f7..3c7042877e63 100644
--- a/arch/x86/include/asm/mmu_context.h
+++ b/arch/x86/include/asm/mmu_context.h
@@ -70,7 +70,11 @@ struct ldt_struct {

 static inline void *ldt_slot_va(int slot)
 {
+#ifdef CONFIG_X86_64
return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
+#else
+   BUG();
+#endif
 }

Ingo or Thomas, want to do that manually?  It's probably easier than
folding in a patch.

[PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

[Jonathan Neuschäfer]

The compatible string for this panel was specified as
toshiba,lt089ac29000.txt. I believe this is a mistake.

Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
Cc: Lucas Stach 
Signed-off-by: Jonathan Neuschäfer 
---
 .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt 
b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
index 4c0caaf246c9..89826116628c 100644
--- a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
+++ b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
@@ -1,7 +1,7 @@
 Toshiba 8.9" WXGA (1280x768) TFT LCD panel
 
 Required properties:
-- compatible: should be "toshiba,lt089ac29000.txt"
+- compatible: should be "toshiba,lt089ac29000"
 - power-supply: as specified in the base binding
 
 This binding is compatible with the simple-panel binding, which is specified
-- 
2.15.0

[PATCH] dt-bindings: display: panel: Fix compatible string for Toshiba LT089AC29000

[Jonathan Neuschäfer]

The compatible string for this panel was specified as
toshiba,lt089ac29000.txt. I believe this is a mistake.

Fixes: 06e733e41f87 ("drm/panel: simple: add Toshiba LT089AC19000")
Cc: Lucas Stach 
Signed-off-by: Jonathan Neuschäfer 
---
 .../devicetree/bindings/display/panel/toshiba,lt089ac29000.txt  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt 
b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
index 4c0caaf246c9..89826116628c 100644
--- a/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
+++ b/Documentation/devicetree/bindings/display/panel/toshiba,lt089ac29000.txt
@@ -1,7 +1,7 @@
 Toshiba 8.9" WXGA (1280x768) TFT LCD panel
 
 Required properties:
-- compatible: should be "toshiba,lt089ac29000.txt"
+- compatible: should be "toshiba,lt089ac29000"
 - power-supply: as specified in the base binding
 
 This binding is compatible with the simple-panel binding, which is specified
-- 
2.15.0

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Knut Omang]

On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:25 +0100
> Knut Omang  wrote:
> 
> > This patch series implements features to make it easier to run checkers on 
> > the
> > entire kernel as part of automatic and developer testing.
> > 
> > This is done by replacing the sparse specific setup for the C={1,2} variable
> > in the makefiles with setup for running scripts/runchecks, a new program 
> > that
> > can run any number of different "checkers". The behaviour of runchecks is
> > defined by simple "global" configuration in scripts/runchecks.cfg which can 
> > be
> > extended by local configuration applying to individual files, directories or
> > subtrees in the source.
> > 
> > It also fixes a minor issue with "checkpatch --fix-inplace" found during 
> > testing
> > (patch #3).
> > 
> > The runchecks.cfg files are parsed according to this minimal language:
> > 
> ># comments
> ># "Global configuration in scripts/runchecks.cfg:
> >checker 
> >typedef NAME regex
> >run  > 
> ># "local" configuration:
> >line_len 
> >except checkpatch_type [files ...]
> >pervasive checkpatch_type1 [checkpatch_type2 ...]
> > 
> > With "make C=2" runchecks first parse the file scripts/runchecks.cfg, then
> > look for a file named 'runchecks.cfg' in the same directory as the source 
> > file.
> > If that file exists, it will be parsed and it's local configuration applied 
> > to
> > allow suppression on a per checker, per check and per file basis.
> > If a "local" configuration does not exist, either in the source directory or
> > above, make will simply silently ignore the file.
> > 
> > The idea is that the community can work to add runchecks.cfg files to
> > directories, serving both as documentation and as a way for subsystem
> > maintainers to enforce policies and individual tastes as well as TODOs 
> > and/or
> > priorities, to make it easier for newcomers to contribute in this area. By
> > ignoring directories/subtrees without such files, automation can start right
> > away as it is trivially possible to run errorless with C=2 for the entire
> > kernel.
> > 
> > For the checker maintainers this should be a benefit as well: new
> > or improved checks would generate new errors/warnings. With automatic 
> > testing
> > for the checkers, these new checks would generate error reports and cause
> > builds to fail. Adding the new check a 'pervasive' option at the top level 
> > or
> > even for specific files, marked with a "new check - please consider fixing" 
> > comment
> > or similar would make those builds pass while documenting and making the 
> > new check
> > more visible.
> > 
> > The patches includes a documentation file with some more details.
> > 
> > This patch set has evolved from an earlier shell script implementation I 
> > made
> > as only a wrapper script around checkpatch. That version have been used for 
> > a
> > number of years on a driver project I worked on where we had automatic 
> > checkin
> > regression testing. I extended that to also run checkpatch to avoid having 
> > to
> > clean up frequent unintended whitespace changes and style violations from 
> > others...
> > 
> > I have also tested this version on some directories I am familiar with.  The
> > result of that work is available in two patch sets of 10 and 11 patches, 
> > but we
> > agreed that it would be better to post them as separate patch sets later.
> > 
> > Those patch sets illustrates how I picture the "flow" from just "reining 
> > in" the
> > checkpatch detections to actually fixing classes of checkpatch issues one by
> > one, while updating the checkpatch.cfg file(s) to have 0 errors or warnings 
> > at
> > any commit boundary.
> > 
> > The combined set is available here:
> > 
> >git://github.com/knuto/linux.git  branch runchecks
> > 
> > I only include version 0 of runchecks.cfg in the two directories I
> > worked on here as the final two patches. These files both documents where
> > the issues are in those two directories, and can be used by the maintainer
> > to indicate to potential helpers what to focus on as I have tried to
> > illustrate by means of comments.
> > 
> > Changes from v1:
> > -
> > Based on feedback, the implementation is completely rewritten and extended.
> > Instead of patches to checkpatch, and a sole checkpatch focus, it is now a
> > generic solution implemented in python, for any type of checkers, extendable
> > through some basic generic functionality, and for special needs by 
> > subclassing
> > the Checker class in the implementation.
> > 
> > This implementation fully supports checkpatch, sparse and
> > checkdoc == kernel-doc -none, and also has been tested with coccicheck.
> > To facilitate the same mechanism of using check types to filter what
> > checks to be suppressed, I introduced the concept of "typedefs" which allows
> > runchecks to 

Re: [PATCH v2 0/5] Support for generalized use of make C={1,2} via a wrapper program

[Knut Omang]

On Sat, 2017-12-16 at 09:47 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:25 +0100
> Knut Omang  wrote:
> 
> > This patch series implements features to make it easier to run checkers on 
> > the
> > entire kernel as part of automatic and developer testing.
> > 
> > This is done by replacing the sparse specific setup for the C={1,2} variable
> > in the makefiles with setup for running scripts/runchecks, a new program 
> > that
> > can run any number of different "checkers". The behaviour of runchecks is
> > defined by simple "global" configuration in scripts/runchecks.cfg which can 
> > be
> > extended by local configuration applying to individual files, directories or
> > subtrees in the source.
> > 
> > It also fixes a minor issue with "checkpatch --fix-inplace" found during 
> > testing
> > (patch #3).
> > 
> > The runchecks.cfg files are parsed according to this minimal language:
> > 
> ># comments
> ># "Global configuration in scripts/runchecks.cfg:
> >checker 
> >typedef NAME regex
> >run  > 
> ># "local" configuration:
> >line_len 
> >except checkpatch_type [files ...]
> >pervasive checkpatch_type1 [checkpatch_type2 ...]
> > 
> > With "make C=2" runchecks first parse the file scripts/runchecks.cfg, then
> > look for a file named 'runchecks.cfg' in the same directory as the source 
> > file.
> > If that file exists, it will be parsed and it's local configuration applied 
> > to
> > allow suppression on a per checker, per check and per file basis.
> > If a "local" configuration does not exist, either in the source directory or
> > above, make will simply silently ignore the file.
> > 
> > The idea is that the community can work to add runchecks.cfg files to
> > directories, serving both as documentation and as a way for subsystem
> > maintainers to enforce policies and individual tastes as well as TODOs 
> > and/or
> > priorities, to make it easier for newcomers to contribute in this area. By
> > ignoring directories/subtrees without such files, automation can start right
> > away as it is trivially possible to run errorless with C=2 for the entire
> > kernel.
> > 
> > For the checker maintainers this should be a benefit as well: new
> > or improved checks would generate new errors/warnings. With automatic 
> > testing
> > for the checkers, these new checks would generate error reports and cause
> > builds to fail. Adding the new check a 'pervasive' option at the top level 
> > or
> > even for specific files, marked with a "new check - please consider fixing" 
> > comment
> > or similar would make those builds pass while documenting and making the 
> > new check
> > more visible.
> > 
> > The patches includes a documentation file with some more details.
> > 
> > This patch set has evolved from an earlier shell script implementation I 
> > made
> > as only a wrapper script around checkpatch. That version have been used for 
> > a
> > number of years on a driver project I worked on where we had automatic 
> > checkin
> > regression testing. I extended that to also run checkpatch to avoid having 
> > to
> > clean up frequent unintended whitespace changes and style violations from 
> > others...
> > 
> > I have also tested this version on some directories I am familiar with.  The
> > result of that work is available in two patch sets of 10 and 11 patches, 
> > but we
> > agreed that it would be better to post them as separate patch sets later.
> > 
> > Those patch sets illustrates how I picture the "flow" from just "reining 
> > in" the
> > checkpatch detections to actually fixing classes of checkpatch issues one by
> > one, while updating the checkpatch.cfg file(s) to have 0 errors or warnings 
> > at
> > any commit boundary.
> > 
> > The combined set is available here:
> > 
> >git://github.com/knuto/linux.git  branch runchecks
> > 
> > I only include version 0 of runchecks.cfg in the two directories I
> > worked on here as the final two patches. These files both documents where
> > the issues are in those two directories, and can be used by the maintainer
> > to indicate to potential helpers what to focus on as I have tried to
> > illustrate by means of comments.
> > 
> > Changes from v1:
> > -
> > Based on feedback, the implementation is completely rewritten and extended.
> > Instead of patches to checkpatch, and a sole checkpatch focus, it is now a
> > generic solution implemented in python, for any type of checkers, extendable
> > through some basic generic functionality, and for special needs by 
> > subclassing
> > the Checker class in the implementation.
> > 
> > This implementation fully supports checkpatch, sparse and
> > checkdoc == kernel-doc -none, and also has been tested with coccicheck.
> > To facilitate the same mechanism of using check types to filter what
> > checks to be suppressed, I introduced the concept of "typedefs" which allows
> > runchecks to effectively augment the check 

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 10:24 -0800, Joe Perches wrote:
> On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> > On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang  wrote:
> > > +# Code simplification:
> > > +#
> > > +except ALLOC_WITH_MULTIPLY ib.c
> > > +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> > > threads.c
> transport.c
> > > +except UNNECESSARY_ELSE ib_fmr.c
> > > +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> > > +except PRINTK_RATELIMITED ib_frmr.c
> > > +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> > > +
> > > +# Style and readability:
> > > +#
> > > +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> > > +except OOM_MESSAGE ib.c tcp.c
> > > +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> > > +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> > > +except OPEN_ENDED_LINE recv.c ib_recv.c
> > > +
> > > +# Candidates to leave as exceptions (don't fix):
> > > +except MULTIPLE_ASSIGNMENTS ib_send.c
> > > +except LONG_LINE_STRING connection.c
> > > +except OPEN_BRACE connection.c
> > > +
> > 
> > Why start letting subsystems have a free-pass?
> > Also this would mean that new patches to IB would continue the bad habits.
> 
> I agree with this comment at least for net/rds.
> 
> Most of these existing messages from checkpatch should
> probably be inspected and corrected where possible to
> minimize the style differences between this subsystem
> and the rest of the kernel.

Please get me right here, I want us to fix all or at least most the issues, 
unless there
are very good reasons for keeping some. But to fix a problem, partitioning it 
into easy
manageable and distributable pieces can often be a good idea. It also allows us 
to focus
on the most important or easiest issues first - my comments here are intended as
examples/guidance/classification.

> For instance, here's a trivial patch to substitute
> pr_ for printks and a couple braces next to
> these substitutions.

yes - I have about 10 such patches for RDMA and 10 for RDS 
fixing various issues "queued up" here - done while I worked on the logic:

https://github.com/knuto/linux/tree/runchecks

I just felt that mixing them up with the runchecks functionality itself would 
be wrong,
but wanted to throw in these two configuration files to give you some example 
of how it
can be used.

Thanks,
Knut

> btw:
> 
> in ib_cm, why is one call to ib_modify_qp emitted
> with a -ret and the other with a positive err?


> 
> ---
>  net/rds/ib_cm.c  | 21 ++---
>  net/rds/ib_recv.c|  5 ++---
>  net/rds/ib_send.c| 23 ---
>  net/rds/rdma_transport.c | 14 +++---
>  net/rds/send.c   |  8 
>  net/rds/tcp_send.c   |  4 +---
>  net/rds/threads.c|  6 ++
>  net/rds/transport.c  | 12 ++--
>  8 files changed, 44 insertions(+), 49 deletions(-)
> 
> diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
> index 80fb6f63e768..92694c9cb7c9 100644
> --- a/net/rds/ib_cm.c
> +++ b/net/rds/ib_cm.c
> @@ -86,7 +86,7 @@ rds_ib_tune_rnr(struct rds_ib_connection *ic, struct 
> ib_qp_attr *attr)
>   attr->min_rnr_timer = IB_RNR_TIMER_000_32;
>   ret = ib_modify_qp(ic->i_cm_id->qp, attr, IB_QP_MIN_RNR_TIMER);
>   if (ret)
> - printk(KERN_NOTICE "ib_modify_qp(IB_QP_MIN_RNR_TIMER): 
> err=%d\n",
> -ret);
> + pr_notice("ib_modify_qp(IB_QP_MIN_RNR_TIMER): err=%d\n", -ret);
>  }
>  
>  /*
> @@ -146,13 +146,12 @@ void rds_ib_cm_connect_complete(struct rds_connection 
> *conn,
> struct rdma_cm_even
>   qp_attr.qp_state = IB_QPS_RTS;
>   err = ib_modify_qp(ic->i_cm_id->qp, _attr, IB_QP_STATE);
>   if (err)
> - printk(KERN_NOTICE "ib_modify_qp(IB_QP_STATE, RTS): err=%d\n", 
> err);
> + pr_notice("ib_modify_qp(IB_QP_STATE, RTS): err=%d\n", err);
>  
>   /* update ib_device with this local ipaddr */
>   err = rds_ib_update_ipaddr(ic->rds_ibdev, conn->c_laddr);
>   if (err)
> - printk(KERN_ERR "rds_ib_update_ipaddr failed (%d)\n",
> - err);
> + pr_err("rds_ib_update_ipaddr failed (%d)\n", err);
>  
>   /* If the peer gave us the last packet it saw, process this as if
>* we had received a regular ACK. */
> @@ -594,8 +593,7 @@ static u32 rds_ib_protocol_compatible(struct 
> rdma_cm_event *event)
>  
>   /* Be paranoid. RDS always has privdata */
>   if (!event->param.conn.private_data_len) {
> - printk(KERN_NOTICE "RDS incoming connection has no private 
> data, "
> - "rejecting\n");
> + pr_notice("RDS incoming connection has no private data, 
> rejecting\n");
>   return 0;
>   }
>  
> @@ -609,11 +607,12 @@ static u32 rds_ib_protocol_compatible(struct 
> rdma_cm_event *event)
>   version = RDS_PROTOCOL_3_0;
>   while ((common >>= 1) != 0)
>   version++;
> - } 

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 10:24 -0800, Joe Perches wrote:
> On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> > On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang  wrote:
> > > +# Code simplification:
> > > +#
> > > +except ALLOC_WITH_MULTIPLY ib.c
> > > +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> > > threads.c
> transport.c
> > > +except UNNECESSARY_ELSE ib_fmr.c
> > > +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> > > +except PRINTK_RATELIMITED ib_frmr.c
> > > +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> > > +
> > > +# Style and readability:
> > > +#
> > > +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> > > +except OOM_MESSAGE ib.c tcp.c
> > > +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> > > +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> > > +except OPEN_ENDED_LINE recv.c ib_recv.c
> > > +
> > > +# Candidates to leave as exceptions (don't fix):
> > > +except MULTIPLE_ASSIGNMENTS ib_send.c
> > > +except LONG_LINE_STRING connection.c
> > > +except OPEN_BRACE connection.c
> > > +
> > 
> > Why start letting subsystems have a free-pass?
> > Also this would mean that new patches to IB would continue the bad habits.
> 
> I agree with this comment at least for net/rds.
> 
> Most of these existing messages from checkpatch should
> probably be inspected and corrected where possible to
> minimize the style differences between this subsystem
> and the rest of the kernel.

Please get me right here, I want us to fix all or at least most the issues, 
unless there
are very good reasons for keeping some. But to fix a problem, partitioning it 
into easy
manageable and distributable pieces can often be a good idea. It also allows us 
to focus
on the most important or easiest issues first - my comments here are intended as
examples/guidance/classification.

> For instance, here's a trivial patch to substitute
> pr_ for printks and a couple braces next to
> these substitutions.

yes - I have about 10 such patches for RDMA and 10 for RDS 
fixing various issues "queued up" here - done while I worked on the logic:

https://github.com/knuto/linux/tree/runchecks

I just felt that mixing them up with the runchecks functionality itself would 
be wrong,
but wanted to throw in these two configuration files to give you some example 
of how it
can be used.

Thanks,
Knut

> btw:
> 
> in ib_cm, why is one call to ib_modify_qp emitted
> with a -ret and the other with a positive err?


> 
> ---
>  net/rds/ib_cm.c  | 21 ++---
>  net/rds/ib_recv.c|  5 ++---
>  net/rds/ib_send.c| 23 ---
>  net/rds/rdma_transport.c | 14 +++---
>  net/rds/send.c   |  8 
>  net/rds/tcp_send.c   |  4 +---
>  net/rds/threads.c|  6 ++
>  net/rds/transport.c  | 12 ++--
>  8 files changed, 44 insertions(+), 49 deletions(-)
> 
> diff --git a/net/rds/ib_cm.c b/net/rds/ib_cm.c
> index 80fb6f63e768..92694c9cb7c9 100644
> --- a/net/rds/ib_cm.c
> +++ b/net/rds/ib_cm.c
> @@ -86,7 +86,7 @@ rds_ib_tune_rnr(struct rds_ib_connection *ic, struct 
> ib_qp_attr *attr)
>   attr->min_rnr_timer = IB_RNR_TIMER_000_32;
>   ret = ib_modify_qp(ic->i_cm_id->qp, attr, IB_QP_MIN_RNR_TIMER);
>   if (ret)
> - printk(KERN_NOTICE "ib_modify_qp(IB_QP_MIN_RNR_TIMER): 
> err=%d\n",
> -ret);
> + pr_notice("ib_modify_qp(IB_QP_MIN_RNR_TIMER): err=%d\n", -ret);
>  }
>  
>  /*
> @@ -146,13 +146,12 @@ void rds_ib_cm_connect_complete(struct rds_connection 
> *conn,
> struct rdma_cm_even
>   qp_attr.qp_state = IB_QPS_RTS;
>   err = ib_modify_qp(ic->i_cm_id->qp, _attr, IB_QP_STATE);
>   if (err)
> - printk(KERN_NOTICE "ib_modify_qp(IB_QP_STATE, RTS): err=%d\n", 
> err);
> + pr_notice("ib_modify_qp(IB_QP_STATE, RTS): err=%d\n", err);
>  
>   /* update ib_device with this local ipaddr */
>   err = rds_ib_update_ipaddr(ic->rds_ibdev, conn->c_laddr);
>   if (err)
> - printk(KERN_ERR "rds_ib_update_ipaddr failed (%d)\n",
> - err);
> + pr_err("rds_ib_update_ipaddr failed (%d)\n", err);
>  
>   /* If the peer gave us the last packet it saw, process this as if
>* we had received a regular ACK. */
> @@ -594,8 +593,7 @@ static u32 rds_ib_protocol_compatible(struct 
> rdma_cm_event *event)
>  
>   /* Be paranoid. RDS always has privdata */
>   if (!event->param.conn.private_data_len) {
> - printk(KERN_NOTICE "RDS incoming connection has no private 
> data, "
> - "rejecting\n");
> + pr_notice("RDS incoming connection has no private data, 
> rejecting\n");
>   return 0;
>   }
>  
> @@ -609,11 +607,12 @@ static u32 rds_ib_protocol_compatible(struct 
> rdma_cm_event *event)
>   version = RDS_PROTOCOL_3_0;
>   while ((common >>= 1) != 0)
>   version++;
> - } else
> - 

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote:
> On 12/16/17 10:24 AM, Joe Perches wrote:
> > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> >> On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang  
> >> wrote:
> >>> +# Code simplification:
> >>> +#
> >>> +except ALLOC_WITH_MULTIPLY ib.c
> >>> +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> >>> threads.c
> transport.c
> >>> +except UNNECESSARY_ELSE ib_fmr.c
> >>> +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> >>> +except PRINTK_RATELIMITED ib_frmr.c
> >>> +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> >>> +
> >>> +# Style and readability:
> >>> +#
> >>> +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> >>> +except OOM_MESSAGE ib.c tcp.c
> >>> +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> >>> +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> >>> +except OPEN_ENDED_LINE recv.c ib_recv.c
> >>> +
> >>> +# Candidates to leave as exceptions (don't fix):
> >>> +except MULTIPLE_ASSIGNMENTS ib_send.c
> >>> +except LONG_LINE_STRING connection.c
> >>> +except OPEN_BRACE connection.c
> >>> +
> >>
> >> Why start letting subsystems have a free-pass?
> >> Also this would mean that new patches to IB would continue the bad habits.
> And I don't need any free pass for RDS either.

It's not a free pass, it's an assessment of the current situation, to allow 
people to start working on it easily. I have already done some of that work
and will post that later.

> I missed V1 of this series but Knut, please don't add
> any exceptions for RDS and if there is something needs to
> be fixed, we can address it. Once your infrastructure
> gets merged, the subsequent fixes can be added.

This is about temporary masking some errors to allow automated testing
to prevent new regressions to occur in all the files and for all the 
types that are not excepted!

> > 
> > I agree with this comment at least for net/rds.
> > 
> > Most of these existing messages from checkpatch should
> > probably be inspected and corrected where possible to
> > minimize the style differences between this subsystem
> > and the rest of the kernel.
> > 
> > For instance, here's a trivial patch to substitute
> > pr_ for printks and a couple braces next to
> > these substitutions.
> >
> Thanks Joe. I actually had a similar patch a while back but
> since it was lot of churn, and code was already merged,
> never submitted it and then later forgot about it.
> 
> Will look into it.

Please look at my set here first - I have already spent considerable time 
cleaning up
stuff while working on this:

https://github.com/knuto/linux/tree/runchecks

Thanks,
Knut

> > btw:
> > 
> > in ib_cm, why is one call to ib_modify_qp emitted
> > with a -ret and the other with a positive err?
> >
> Its oversight and will fix that.
> 
> Regards,
> Santosh

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 12:00 -0800, santosh.shilim...@oracle.com wrote:
> On 12/16/17 10:24 AM, Joe Perches wrote:
> > On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> >> On Sat, 16 Dec 2017 15:42:29 +0100 Knut Omang  
> >> wrote:
> >>> +# Code simplification:
> >>> +#
> >>> +except ALLOC_WITH_MULTIPLY ib.c
> >>> +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> >>> threads.c
> transport.c
> >>> +except UNNECESSARY_ELSE ib_fmr.c
> >>> +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> >>> +except PRINTK_RATELIMITED ib_frmr.c
> >>> +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> >>> +
> >>> +# Style and readability:
> >>> +#
> >>> +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> >>> +except OOM_MESSAGE ib.c tcp.c
> >>> +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> >>> +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> >>> +except OPEN_ENDED_LINE recv.c ib_recv.c
> >>> +
> >>> +# Candidates to leave as exceptions (don't fix):
> >>> +except MULTIPLE_ASSIGNMENTS ib_send.c
> >>> +except LONG_LINE_STRING connection.c
> >>> +except OPEN_BRACE connection.c
> >>> +
> >>
> >> Why start letting subsystems have a free-pass?
> >> Also this would mean that new patches to IB would continue the bad habits.
> And I don't need any free pass for RDS either.

It's not a free pass, it's an assessment of the current situation, to allow 
people to start working on it easily. I have already done some of that work
and will post that later.

> I missed V1 of this series but Knut, please don't add
> any exceptions for RDS and if there is something needs to
> be fixed, we can address it. Once your infrastructure
> gets merged, the subsequent fixes can be added.

This is about temporary masking some errors to allow automated testing
to prevent new regressions to occur in all the files and for all the 
types that are not excepted!

> > 
> > I agree with this comment at least for net/rds.
> > 
> > Most of these existing messages from checkpatch should
> > probably be inspected and corrected where possible to
> > minimize the style differences between this subsystem
> > and the rest of the kernel.
> > 
> > For instance, here's a trivial patch to substitute
> > pr_ for printks and a couple braces next to
> > these substitutions.
> >
> Thanks Joe. I actually had a similar patch a while back but
> since it was lot of churn, and code was already merged,
> never submitted it and then later forgot about it.
> 
> Will look into it.

Please look at my set here first - I have already spent considerable time 
cleaning up
stuff while working on this:

https://github.com/knuto/linux/tree/runchecks

Thanks,
Knut

> > btw:
> > 
> > in ib_cm, why is one call to ib_modify_qp emitted
> > with a -ret and the other with a positive err?
> >
> Its oversight and will fix that.
> 
> Regards,
> Santosh

Re: [PATCH v4] KVM: Fix stack-out-of-bounds read in write_mmio

[Wanpeng Li]

2017-12-15 19:06 GMT+08:00 Marc Zyngier :
> On 15/12/17 01:40, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> Reported by syzkaller:
>>
>>   BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
>>   Read of size 8 at addr 8803259df7f8 by task syz-executor/32298
>>
>>   CPU: 6 PID: 32298 Comm: syz-executor Tainted: G   OE
>> 4.15.0-rc2+ #18
>>   Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
>> 02/16/2016
>>   Call Trace:
>>dump_stack+0xab/0xe1
>>print_address_description+0x6b/0x290
>>kasan_report+0x28a/0x370
>>write_mmio+0x11e/0x270 [kvm]
>>emulator_read_write_onepage+0x311/0x600 [kvm]
>>emulator_read_write+0xef/0x240 [kvm]
>>emulator_fix_hypercall+0x105/0x150 [kvm]
>>em_hypercall+0x2b/0x80 [kvm]
>>x86_emulate_insn+0x2b1/0x1640 [kvm]
>>x86_emulate_instruction+0x39a/0xb90 [kvm]
>>handle_exception+0x1b4/0x4d0 [kvm_intel]
>>vcpu_enter_guest+0x15a0/0x2640 [kvm]
>>kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm]
>>kvm_vcpu_ioctl+0x479/0x880 [kvm]
>>do_vfs_ioctl+0x142/0x9a0
>>SyS_ioctl+0x74/0x80
>>entry_SYSCALL_64_fastpath+0x23/0x9a
>>
>> The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall)
>> to the guest memory, however, write_mmio tracepoint always prints 8 bytes
>> through *(u64 *)val since kvm splits the mmio access into 8 bytes. This
>> can result in stack-out-of-bounds read due to access the extra 5 bytes.
>> This patch fixes it by just accessing the bytes which we operates on.
>>
>> Before patch:
>>
>> syz-executor-5567  [007]  51370.561696: kvm_mmio: mmio write len 3 gpa 
>> 0x10 val 0x110077c1010f
>>
>> After patch:
>>
>> syz-executor-13416 [002]  51302.299573: kvm_mmio: mmio write len 3 gpa 
>> 0x10 val 0xc1010f
>>
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Marc Zyngier 
>> Cc: Christoffer Dall 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v3 -> v4:
>>  * fix the arm tracepoint
>> v2 -> v3:
>>  * fix sparse warning
>> v1 -> v2:
>>  * do the memcpy in kvm_mmio tracepoint
>>
>>  arch/x86/kvm/x86.c | 8 
>>  include/trace/events/kvm.h | 6 --
>>  virt/kvm/arm/mmio.c| 6 +++---
>>  3 files changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 0f82e2c..c7071e7 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -4456,7 +4456,7 @@ static int vcpu_mmio_read(struct kvm_vcpu *vcpu, gpa_t 
>> addr, int len, void *v)
>>addr, n, v))
>>   && kvm_io_bus_read(vcpu, KVM_MMIO_BUS, addr, n, v))
>>   break;
>> - trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, *(u64 *)v);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, v);
>>   handled += n;
>>   addr += n;
>>   len -= n;
>> @@ -4715,7 +4715,7 @@ static int read_prepare(struct kvm_vcpu *vcpu, void 
>> *val, int bytes)
>>  {
>>   if (vcpu->mmio_read_completed) {
>>   trace_kvm_mmio(KVM_TRACE_MMIO_READ, bytes,
>> -vcpu->mmio_fragments[0].gpa, *(u64 *)val);
>> +vcpu->mmio_fragments[0].gpa, val);
>>   vcpu->mmio_read_completed = 0;
>>   return 1;
>>   }
>> @@ -4737,14 +4737,14 @@ static int write_emulate(struct kvm_vcpu *vcpu, 
>> gpa_t gpa,
>>
>>  static int write_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, int bytes, void 
>> *val)
>>  {
>> - trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, val);
>>   return vcpu_mmio_write(vcpu, gpa, bytes, val);
>>  }
>>
>>  static int read_exit_mmio(struct kvm_vcpu *vcpu, gpa_t gpa,
>> void *val, int bytes)
>>  {
>> - trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, 0);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, NULL);
>>   return X86EMUL_IO_NEEDED;
>>  }
>>
>> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
>> index e4b0b8e..dfd2170 100644
>> --- a/include/trace/events/kvm.h
>> +++ b/include/trace/events/kvm.h
>> @@ -211,7 +211,7 @@ TRACE_EVENT(kvm_ack_irq,
>>   { KVM_TRACE_MMIO_WRITE, "write" }
>>
>>  TRACE_EVENT(kvm_mmio,
>> - TP_PROTO(int type, int len, u64 gpa, u64 val),
>> + TP_PROTO(int type, int len, u64 gpa, void *val),
>>   TP_ARGS(type, len, gpa, val),
>>
>>   TP_STRUCT__entry(
>> @@ -225,7 +225,9 @@ TRACE_EVENT(kvm_mmio,
>>   __entry->type   = type;
>>   __entry->len= len;
>>   __entry->gpa= gpa;
>> - __entry->val= val;
>> + __entry->val = 0;
>> + if 

Re: [PATCH v4] KVM: Fix stack-out-of-bounds read in write_mmio

[Wanpeng Li]

2017-12-15 19:06 GMT+08:00 Marc Zyngier :
> On 15/12/17 01:40, Wanpeng Li wrote:
>> From: Wanpeng Li 
>>
>> Reported by syzkaller:
>>
>>   BUG: KASAN: stack-out-of-bounds in write_mmio+0x11e/0x270 [kvm]
>>   Read of size 8 at addr 8803259df7f8 by task syz-executor/32298
>>
>>   CPU: 6 PID: 32298 Comm: syz-executor Tainted: G   OE
>> 4.15.0-rc2+ #18
>>   Hardware name: LENOVO ThinkCentre M8500t-N000/SHARKBAY, BIOS FBKTC1AUS 
>> 02/16/2016
>>   Call Trace:
>>dump_stack+0xab/0xe1
>>print_address_description+0x6b/0x290
>>kasan_report+0x28a/0x370
>>write_mmio+0x11e/0x270 [kvm]
>>emulator_read_write_onepage+0x311/0x600 [kvm]
>>emulator_read_write+0xef/0x240 [kvm]
>>emulator_fix_hypercall+0x105/0x150 [kvm]
>>em_hypercall+0x2b/0x80 [kvm]
>>x86_emulate_insn+0x2b1/0x1640 [kvm]
>>x86_emulate_instruction+0x39a/0xb90 [kvm]
>>handle_exception+0x1b4/0x4d0 [kvm_intel]
>>vcpu_enter_guest+0x15a0/0x2640 [kvm]
>>kvm_arch_vcpu_ioctl_run+0x549/0x7d0 [kvm]
>>kvm_vcpu_ioctl+0x479/0x880 [kvm]
>>do_vfs_ioctl+0x142/0x9a0
>>SyS_ioctl+0x74/0x80
>>entry_SYSCALL_64_fastpath+0x23/0x9a
>>
>> The path of patched vmmcall will patch 3 bytes opcode 0F 01 C1(vmcall)
>> to the guest memory, however, write_mmio tracepoint always prints 8 bytes
>> through *(u64 *)val since kvm splits the mmio access into 8 bytes. This
>> can result in stack-out-of-bounds read due to access the extra 5 bytes.
>> This patch fixes it by just accessing the bytes which we operates on.
>>
>> Before patch:
>>
>> syz-executor-5567  [007]  51370.561696: kvm_mmio: mmio write len 3 gpa 
>> 0x10 val 0x110077c1010f
>>
>> After patch:
>>
>> syz-executor-13416 [002]  51302.299573: kvm_mmio: mmio write len 3 gpa 
>> 0x10 val 0xc1010f
>>
>> Reported-by: Dmitry Vyukov 
>> Cc: Paolo Bonzini 
>> Cc: Radim Krčmář 
>> Cc: Marc Zyngier 
>> Cc: Christoffer Dall 
>> Signed-off-by: Wanpeng Li 
>> ---
>> v3 -> v4:
>>  * fix the arm tracepoint
>> v2 -> v3:
>>  * fix sparse warning
>> v1 -> v2:
>>  * do the memcpy in kvm_mmio tracepoint
>>
>>  arch/x86/kvm/x86.c | 8 
>>  include/trace/events/kvm.h | 6 --
>>  virt/kvm/arm/mmio.c| 6 +++---
>>  3 files changed, 11 insertions(+), 9 deletions(-)
>>
>> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
>> index 0f82e2c..c7071e7 100644
>> --- a/arch/x86/kvm/x86.c
>> +++ b/arch/x86/kvm/x86.c
>> @@ -4456,7 +4456,7 @@ static int vcpu_mmio_read(struct kvm_vcpu *vcpu, gpa_t 
>> addr, int len, void *v)
>>addr, n, v))
>>   && kvm_io_bus_read(vcpu, KVM_MMIO_BUS, addr, n, v))
>>   break;
>> - trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, *(u64 *)v);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_READ, n, addr, v);
>>   handled += n;
>>   addr += n;
>>   len -= n;
>> @@ -4715,7 +4715,7 @@ static int read_prepare(struct kvm_vcpu *vcpu, void 
>> *val, int bytes)
>>  {
>>   if (vcpu->mmio_read_completed) {
>>   trace_kvm_mmio(KVM_TRACE_MMIO_READ, bytes,
>> -vcpu->mmio_fragments[0].gpa, *(u64 *)val);
>> +vcpu->mmio_fragments[0].gpa, val);
>>   vcpu->mmio_read_completed = 0;
>>   return 1;
>>   }
>> @@ -4737,14 +4737,14 @@ static int write_emulate(struct kvm_vcpu *vcpu, 
>> gpa_t gpa,
>>
>>  static int write_mmio(struct kvm_vcpu *vcpu, gpa_t gpa, int bytes, void 
>> *val)
>>  {
>> - trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, *(u64 *)val);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_WRITE, bytes, gpa, val);
>>   return vcpu_mmio_write(vcpu, gpa, bytes, val);
>>  }
>>
>>  static int read_exit_mmio(struct kvm_vcpu *vcpu, gpa_t gpa,
>> void *val, int bytes)
>>  {
>> - trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, 0);
>> + trace_kvm_mmio(KVM_TRACE_MMIO_READ_UNSATISFIED, bytes, gpa, NULL);
>>   return X86EMUL_IO_NEEDED;
>>  }
>>
>> diff --git a/include/trace/events/kvm.h b/include/trace/events/kvm.h
>> index e4b0b8e..dfd2170 100644
>> --- a/include/trace/events/kvm.h
>> +++ b/include/trace/events/kvm.h
>> @@ -211,7 +211,7 @@ TRACE_EVENT(kvm_ack_irq,
>>   { KVM_TRACE_MMIO_WRITE, "write" }
>>
>>  TRACE_EVENT(kvm_mmio,
>> - TP_PROTO(int type, int len, u64 gpa, u64 val),
>> + TP_PROTO(int type, int len, u64 gpa, void *val),
>>   TP_ARGS(type, len, gpa, val),
>>
>>   TP_STRUCT__entry(
>> @@ -225,7 +225,9 @@ TRACE_EVENT(kvm_mmio,
>>   __entry->type   = type;
>>   __entry->len= len;
>>   __entry->gpa= gpa;
>> - __entry->val= val;
>> + __entry->val = 0;
>> + if (val)
>> + memcpy(&__entry->val, val, min(8, len));
>
> I'm not fond of hardcoded sizes; they tend to break as people change the
> code around. Consider using 

[GIT PULL] ext4 bug fixes for 4.15

[Theodore Ts'o]

The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:

  Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_stable

for you to fetch changes up to 9d5afec6b8bd46d6ed821aa1579634437f58ef1f:

  ext4: fix crash when a directory's i_size is too small (2017-12-11 15:00:57 
-0500)


Fix a regression which caused us to fail to interpret symlinks in very
ancient ext3 file system images.  Also fix two xfstests failures, one
of which could cause a OOPS, plus an additional bug fix caught by fuzz
testing.


Andi Kleen (1):
  ext4: support fast symlinks from ext3 file systems

Chandan Rajendra (1):
  ext4: fix crash when a directory's i_size is too small

Eryu Guan (1):
  ext4: fix fdatasync(2) after fallocate(2) operation

Theodore Ts'o (1):
  ext4: add missing error check in __ext4_new_inode()

 fs/ext4/extents.c | 1 +
 fs/ext4/ialloc.c  | 2 ++
 fs/ext4/inode.c   | 9 +
 fs/ext4/namei.c   | 4 
 4 files changed, 16 insertions(+)

[GIT PULL] ext4 bug fixes for 4.15

[Theodore Ts'o]

The following changes since commit ae64f9bd1d3621b5e60d7363bc20afb46aede215:

  Linux 4.15-rc2 (2017-12-03 11:01:47 -0500)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git 
tags/ext4_for_stable

for you to fetch changes up to 9d5afec6b8bd46d6ed821aa1579634437f58ef1f:

  ext4: fix crash when a directory's i_size is too small (2017-12-11 15:00:57 
-0500)


Fix a regression which caused us to fail to interpret symlinks in very
ancient ext3 file system images.  Also fix two xfstests failures, one
of which could cause a OOPS, plus an additional bug fix caught by fuzz
testing.


Andi Kleen (1):
  ext4: support fast symlinks from ext3 file systems

Chandan Rajendra (1):
  ext4: fix crash when a directory's i_size is too small

Eryu Guan (1):
  ext4: fix fdatasync(2) after fallocate(2) operation

Theodore Ts'o (1):
  ext4: add missing error check in __ext4_new_inode()

 fs/ext4/extents.c | 1 +
 fs/ext4/ialloc.c  | 2 ++
 fs/ext4/inode.c   | 9 +
 fs/ext4/namei.c   | 4 
 4 files changed, 16 insertions(+)

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:29 +0100
> Knut Omang  wrote:
> 
> > +
> > +# Important to fix from a quality perspective:
> > +#
> > +except AVOID_BUG connection.c ib.c ib_cm.c ib_rdma.c ib_recv.c ib_ring.c 
> > ib_send.c
> info.c loop.c message.c
> > +except AVOID_BUG rdma.c recv.c send.c stats.c tcp_recv.c transport.c
> > +except MEMORY_BARRIER ib_recv.c send.c tcp_send.c
> > +except WAITQUEUE_ACTIVE cong.c ib_rdma.c ib_ring.c ib_send.c
> > +except UNNECESSARY_ELSE bind.c ib_cm.c
> > +except MACRO_ARG_PRECEDENCE connection.c ib.h rds.h
> > +except MACRO_ARG_REUSE rds.h
> > +except ALLOC_SIZEOF_STRUCT cong.c ib.c ib_cm.c loop.c message.c rdma.c
> > +except UNCOMMENTED_DEFINITION ib_cm.c
> > +
> > +# Code simplification:
> > +#
> > +except ALLOC_WITH_MULTIPLY ib.c
> > +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> > threads.c
> transport.c
> > +except UNNECESSARY_ELSE ib_fmr.c
> > +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> > +except PRINTK_RATELIMITED ib_frmr.c
> > +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> > +
> > +# Style and readability:
> > +#
> > +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> > +except OOM_MESSAGE ib.c tcp.c
> > +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> > +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> > +except OPEN_ENDED_LINE recv.c ib_recv.c
> > +
> > +# Candidates to leave as exceptions (don't fix):
> > +except MULTIPLE_ASSIGNMENTS ib_send.c
> > +except LONG_LINE_STRING connection.c
> > +except OPEN_BRACE connection.c
> > +
> 
> Why start letting subsystems have a free-pass?

It's not a free pass, on the contrary - it's a way to enable the build bots/CI 
systems to
prevent regressions!

Right now, no automatic system can be set up to run checkpatch on almost any 
subsystem in
the kernel because there are so many warnings. That means that regressions 
happens all
over the place, even on source files and for types of checks that there 
currently are no
issues. Also reviewers have to spend time correcting whitespace issues which 
automation
can really handle much better!

Now, let's assume that we get the build bots to run their builds with make C=2 
(which my
patches here allow, since it produces 0 warnings by design and by default)

Once this patch is in, errors of any kind of any of the types that are *not* 
excepted by
this file will break the build and generate a warning report, forcing the 
committer to fix
the errors right away. To me that's a big improvement from today.

> Also this would mean that new patches to IB would continue the bad habits

That's **only for the excepted types and files, and a temporary situation 
until we can fix the rest of the issues.

See my additional patch set here as an example of how I see us attack this 
piecemeal:

https://github.com/knuto/linux/tree/runchecks

I'll post that set as soon as patch #1/2 here is in.

I hope this clarifies!

Thanks,
Knut

Re: [PATCH v2 4/5] rds: Add runchecks.cfg for net/rds

[Knut Omang]

On Sat, 2017-12-16 at 09:45 -0800, Stephen Hemminger wrote:
> On Sat, 16 Dec 2017 15:42:29 +0100
> Knut Omang  wrote:
> 
> > +
> > +# Important to fix from a quality perspective:
> > +#
> > +except AVOID_BUG connection.c ib.c ib_cm.c ib_rdma.c ib_recv.c ib_ring.c 
> > ib_send.c
> info.c loop.c message.c
> > +except AVOID_BUG rdma.c recv.c send.c stats.c tcp_recv.c transport.c
> > +except MEMORY_BARRIER ib_recv.c send.c tcp_send.c
> > +except WAITQUEUE_ACTIVE cong.c ib_rdma.c ib_ring.c ib_send.c
> > +except UNNECESSARY_ELSE bind.c ib_cm.c
> > +except MACRO_ARG_PRECEDENCE connection.c ib.h rds.h
> > +except MACRO_ARG_REUSE rds.h
> > +except ALLOC_SIZEOF_STRUCT cong.c ib.c ib_cm.c loop.c message.c rdma.c
> > +except UNCOMMENTED_DEFINITION ib_cm.c
> > +
> > +# Code simplification:
> > +#
> > +except ALLOC_WITH_MULTIPLY ib.c
> > +except PREFER_PR_LEVEL ib_cm.c ib_recv.c ib_send.c rdma_transport.c 
> > threads.c
> transport.c
> > +except UNNECESSARY_ELSE ib_fmr.c
> > +except UNNECESSARY_PARENTHESES ib_rdma.c rdma.c recv.c send.c
> > +except PRINTK_RATELIMITED ib_frmr.c
> > +except EMBEDDED_FUNCTION_NAME ib_rdma.c
> > +
> > +# Style and readability:
> > +#
> > +except BRACES ib_cm.c ib_rdma.c ib_recv.c send.c transport.c
> > +except OOM_MESSAGE ib.c tcp.c
> > +except LONG_LINE_STRING ib.c ib_recv.c ib_send.c
> > +except FUNCTION_ARGUMENTS ib.h ib_mr.h rds.h tcp.h
> > +except OPEN_ENDED_LINE recv.c ib_recv.c
> > +
> > +# Candidates to leave as exceptions (don't fix):
> > +except MULTIPLE_ASSIGNMENTS ib_send.c
> > +except LONG_LINE_STRING connection.c
> > +except OPEN_BRACE connection.c
> > +
> 
> Why start letting subsystems have a free-pass?

It's not a free pass, on the contrary - it's a way to enable the build bots/CI 
systems to
prevent regressions!

Right now, no automatic system can be set up to run checkpatch on almost any 
subsystem in
the kernel because there are so many warnings. That means that regressions 
happens all
over the place, even on source files and for types of checks that there 
currently are no
issues. Also reviewers have to spend time correcting whitespace issues which 
automation
can really handle much better!

Now, let's assume that we get the build bots to run their builds with make C=2 
(which my
patches here allow, since it produces 0 warnings by design and by default)

Once this patch is in, errors of any kind of any of the types that are *not* 
excepted by
this file will break the build and generate a warning report, forcing the 
committer to fix
the errors right away. To me that's a big improvement from today.

> Also this would mean that new patches to IB would continue the bad habits

That's **only for the excepted types and files, and a temporary situation 
until we can fix the rest of the issues.

See my additional patch set here as an example of how I see us attack this 
piecemeal:

https://github.com/knuto/linux/tree/runchecks

I'll post that set as soon as patch #1/2 here is in.

I hope this clarifies!

Thanks,
Knut

[PATCH] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible

[megous]

From: Ondrej Jirman 

Without this the AXP813 PMIC fails to probe on TBS A711.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index e6b00b3774e3..76be9d43f906 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -479,6 +479,7 @@
status = "okay";
 
axp81x: pmic@3a3 {
+   compatible = "x-powers,axp813";
reg = <0x3a3>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-- 
2.15.1

[PATCH] ARM: dts: sun8i-a83t-tbs-a711: Add missing axp813 compatible

[megous]

From: Ondrej Jirman 

Without this the AXP813 PMIC fails to probe on TBS A711.

Signed-off-by: Ondrej Jirman 
---
 arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts 
b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
index e6b00b3774e3..76be9d43f906 100644
--- a/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
+++ b/arch/arm/boot/dts/sun8i-a83t-tbs-a711.dts
@@ -479,6 +479,7 @@
status = "okay";
 
axp81x: pmic@3a3 {
+   compatible = "x-powers,axp813";
reg = <0x3a3>;
interrupt-parent = <_intc>;
interrupts = <0 IRQ_TYPE_LEVEL_LOW>;
-- 
2.15.1

[RFC patch] checkpatch: Add a test for long function definitions (>200 lines)

[Joe Perches]

On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
>  - There's no warning for the first paragraph of section 6:
> 
> 6) Functions
> 
> 
> Functions should be short and sweet, and do just one thing.  They should
> fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
> as we all know), and do one thing and do that well.
> 
>I'm not expecting you to be able to write a perl script that checks
>the first line, but we have way too many 200-plus line functions in
>the kernel.  I'd like a warning on anything over 200 lines (a factor
>of 4 over Linus's stated goal).

In response to Matthew's request:

This is a possible checkpatch warning for long
function definitions.

Running against the last 1 git commits, there
are no false positives though perhaps there are
some false negatives.

These are the matches in the last 1 commits:

 1 227  42e0442f8a237d3de9ea3f2dd2be2739e6db7fdb:1157: WARNING: 
'ir_lirc_ioctl' function definition is 206 lines, perhaps refactor
 2 552  148abd3b5b146021a637d36ac5c0ee91cd4ad520:790: WARNING: 
'tda18250_set_params' function definition is 206 lines, perhaps refactor
 31352  123e25c4a5658be27f08ed0fb85ade34683e5dc7:366: WARNING: 
'cudbg_fill_meminfo' function definition is 252 lines, perhaps refactor
 42688  62d591a8e00cc349e6a9efb87efac9548f178624:462: WARNING: 
'program_watermarks' function definition is 232 lines, perhaps refactor
 56171  d2ddc776a4581d900fc3bdc7803b403daae64d88:3530: WARNING: 
'afs_select_fileserver' function definition is 283 lines, perhaps refactor
 69135  2f4b411a3d6766e6362ffbf00e0495a2dfe92507:962: WARNING: 
'i40e_parse_cls_flower' function definition is 242 lines, perhaps refactor
 79450  fd708b81d972a0714b02a60eb4792fdbf15868c4:1094: WARNING: 
'btrfs_ref_tree_mod' function definition is 201 lines, perhaps refactor

Running against files in mm lib and kernel, there are
52 functions that exceed 200 lines.

$ git ls-files -- mm kernel lib | \
  xargs ./scripts/checkpatch.pl -f  --types=long_function --terse --quiet 
--no-summary | \
  cat -n
 1  kernel/audit.c:1447: WARNING: 'audit_receive_msg' function definition 
is 308 lines, perhaps refactor
 2  kernel/auditsc.c:713: WARNING: 'audit_filter_rules' function definition 
is 273 lines, perhaps refactor
 3  kernel/bpf/core.c:1285: WARNING: '___bpf_prog_run' function definition 
is 508 lines, perhaps refactor
 4  kernel/bpf/verifier.c:2240: WARNING: 'adjust_scalar_min_max_vals' 
function definition is 218 lines, perhaps refactor
 5  kernel/bpf/verifier.c:4064: WARNING: 'do_check' function definition is 
288 lines, perhaps refactor
 6  kernel/debug/debug_core.c:682: WARNING: 'kgdb_cpu_enter' function 
definition is 214 lines, perhaps refactor
 7  kernel/debug/kdb/kdb_io.c:422: WARNING: 'kdb_read' function definition 
is 217 lines, perhaps refactor
 8  kernel/debug/kdb/kdb_io.c:850: WARNING: 'vkdb_printf' function 
definition is 297 lines, perhaps refactor
 9  kernel/fork.c:2033: WARNING: 'copy_process' function definition is 454 
lines, perhaps refactor
10  kernel/futex.c:705: WARNING: 'get_futex_key' function definition is 204 
lines, perhaps refactor
11  kernel/futex.c:2135: WARNING: 'futex_requeue' function definition is 
283 lines, perhaps refactor
12  kernel/irq/manage.c:1488: WARNING: '__setup_irq' function definition is 
354 lines, perhaps refactor
13  kernel/locking/locktorture.c:1050: WARNING: 'lock_torture_init' 
function definition is 201 lines, perhaps refactor
14  kernel/locking/qspinlock.c:505: WARNING: 'queued_spin_lock_slowpath' 
function definition is 210 lines, perhaps refactor
15  kernel/locking/rtmutex.c:796: WARNING: 'rt_mutex_adjust_prio_chain' 
function definition is 348 lines, perhaps refactor
16  kernel/power/swap.c:873: WARNING: 'save_image_lzo' function definition 
is 205 lines, perhaps refactor
17  kernel/power/swap.c:1469: WARNING: 'load_image_lzo' function definition 
is 312 lines, perhaps refactor
18  kernel/ptrace.c:1104: WARNING: 'ptrace_request' function definition is 
221 lines, perhaps refactor
19  kernel/sched/core.c:4254: WARNING: '_setscheduler' function definition 
is 238 lines, perhaps refactor
20  kernel/sched/fair.c:8722: WARNING: 'load_balance' function definition 
is 261 lines, perhaps refactor
21  kernel/trace/trace_kprobe.c:839: WARNING: 'create_trace_kprobe' 
function definition is 207 lines, perhaps refactor
22  kernel/trace/trace_uprobe.c:564: WARNING: 'create_trace_uprobe' 
function definition is 202 lines, perhaps refactor
23  lib/asn1_decoder.c:518: WARNING: 'asn1_ber_decoder' function definition 
is 347 lines, perhaps refactor
24  lib/assoc_array.c:790: WARNING: 'assoc_array_insert_into_terminal_node' 
function definition is 312 lines, perhaps refactor
25  lib/assoc_array.c:1721: WARNING: 'assoc_array_gc' function definition 
is 266 lines, perhaps 

[RFC patch] checkpatch: Add a test for long function definitions (>200 lines)

[Joe Perches]

On Mon, 2017-12-11 at 14:43 -0800, Matthew Wilcox wrote:
>  - There's no warning for the first paragraph of section 6:
> 
> 6) Functions
> 
> 
> Functions should be short and sweet, and do just one thing.  They should
> fit on one or two screenfuls of text (the ISO/ANSI screen size is 80x24,
> as we all know), and do one thing and do that well.
> 
>I'm not expecting you to be able to write a perl script that checks
>the first line, but we have way too many 200-plus line functions in
>the kernel.  I'd like a warning on anything over 200 lines (a factor
>of 4 over Linus's stated goal).

In response to Matthew's request:

This is a possible checkpatch warning for long
function definitions.

Running against the last 1 git commits, there
are no false positives though perhaps there are
some false negatives.

These are the matches in the last 1 commits:

 1 227  42e0442f8a237d3de9ea3f2dd2be2739e6db7fdb:1157: WARNING: 
'ir_lirc_ioctl' function definition is 206 lines, perhaps refactor
 2 552  148abd3b5b146021a637d36ac5c0ee91cd4ad520:790: WARNING: 
'tda18250_set_params' function definition is 206 lines, perhaps refactor
 31352  123e25c4a5658be27f08ed0fb85ade34683e5dc7:366: WARNING: 
'cudbg_fill_meminfo' function definition is 252 lines, perhaps refactor
 42688  62d591a8e00cc349e6a9efb87efac9548f178624:462: WARNING: 
'program_watermarks' function definition is 232 lines, perhaps refactor
 56171  d2ddc776a4581d900fc3bdc7803b403daae64d88:3530: WARNING: 
'afs_select_fileserver' function definition is 283 lines, perhaps refactor
 69135  2f4b411a3d6766e6362ffbf00e0495a2dfe92507:962: WARNING: 
'i40e_parse_cls_flower' function definition is 242 lines, perhaps refactor
 79450  fd708b81d972a0714b02a60eb4792fdbf15868c4:1094: WARNING: 
'btrfs_ref_tree_mod' function definition is 201 lines, perhaps refactor

Running against files in mm lib and kernel, there are
52 functions that exceed 200 lines.

$ git ls-files -- mm kernel lib | \
  xargs ./scripts/checkpatch.pl -f  --types=long_function --terse --quiet 
--no-summary | \
  cat -n
 1  kernel/audit.c:1447: WARNING: 'audit_receive_msg' function definition 
is 308 lines, perhaps refactor
 2  kernel/auditsc.c:713: WARNING: 'audit_filter_rules' function definition 
is 273 lines, perhaps refactor
 3  kernel/bpf/core.c:1285: WARNING: '___bpf_prog_run' function definition 
is 508 lines, perhaps refactor
 4  kernel/bpf/verifier.c:2240: WARNING: 'adjust_scalar_min_max_vals' 
function definition is 218 lines, perhaps refactor
 5  kernel/bpf/verifier.c:4064: WARNING: 'do_check' function definition is 
288 lines, perhaps refactor
 6  kernel/debug/debug_core.c:682: WARNING: 'kgdb_cpu_enter' function 
definition is 214 lines, perhaps refactor
 7  kernel/debug/kdb/kdb_io.c:422: WARNING: 'kdb_read' function definition 
is 217 lines, perhaps refactor
 8  kernel/debug/kdb/kdb_io.c:850: WARNING: 'vkdb_printf' function 
definition is 297 lines, perhaps refactor
 9  kernel/fork.c:2033: WARNING: 'copy_process' function definition is 454 
lines, perhaps refactor
10  kernel/futex.c:705: WARNING: 'get_futex_key' function definition is 204 
lines, perhaps refactor
11  kernel/futex.c:2135: WARNING: 'futex_requeue' function definition is 
283 lines, perhaps refactor
12  kernel/irq/manage.c:1488: WARNING: '__setup_irq' function definition is 
354 lines, perhaps refactor
13  kernel/locking/locktorture.c:1050: WARNING: 'lock_torture_init' 
function definition is 201 lines, perhaps refactor
14  kernel/locking/qspinlock.c:505: WARNING: 'queued_spin_lock_slowpath' 
function definition is 210 lines, perhaps refactor
15  kernel/locking/rtmutex.c:796: WARNING: 'rt_mutex_adjust_prio_chain' 
function definition is 348 lines, perhaps refactor
16  kernel/power/swap.c:873: WARNING: 'save_image_lzo' function definition 
is 205 lines, perhaps refactor
17  kernel/power/swap.c:1469: WARNING: 'load_image_lzo' function definition 
is 312 lines, perhaps refactor
18  kernel/ptrace.c:1104: WARNING: 'ptrace_request' function definition is 
221 lines, perhaps refactor
19  kernel/sched/core.c:4254: WARNING: '_setscheduler' function definition 
is 238 lines, perhaps refactor
20  kernel/sched/fair.c:8722: WARNING: 'load_balance' function definition 
is 261 lines, perhaps refactor
21  kernel/trace/trace_kprobe.c:839: WARNING: 'create_trace_kprobe' 
function definition is 207 lines, perhaps refactor
22  kernel/trace/trace_uprobe.c:564: WARNING: 'create_trace_uprobe' 
function definition is 202 lines, perhaps refactor
23  lib/asn1_decoder.c:518: WARNING: 'asn1_ber_decoder' function definition 
is 347 lines, perhaps refactor
24  lib/assoc_array.c:790: WARNING: 'assoc_array_insert_into_terminal_node' 
function definition is 312 lines, perhaps refactor
25  lib/assoc_array.c:1721: WARNING: 'assoc_array_gc' function definition 
is 266 lines, perhaps 

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared; did you mean '_ASM_ADD'?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.x86/pti-upstream
head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
in its own PGD if PTI is on
config: i386-alldefconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/step.c:10:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function); did you mean '_ASM_ADD'?
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
 _ASM_ADD
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in

vim +73 arch/x86/include/asm/mmu_context.h

70  
71  static inline void *ldt_slot_va(int slot)
72  {
  > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
74  }
75  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared; did you mean '_ASM_ADD'?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.x86/pti-upstream
head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
in its own PGD if PTI is on
config: i386-alldefconfig (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86/kernel/step.c:10:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function); did you mean '_ASM_ADD'?
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
 _ASM_ADD
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in

vim +73 arch/x86/include/asm/mmu_context.h

70  
71  static inline void *ldt_slot_va(int slot)
72  {
  > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
74  }
75  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

[Jeff Layton]

On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote:
> On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> > From: Jeff Layton 
> > 
> > Add a documentation blob that explains what the i_version field is, how
> > it is expected to work, and how it is currently implemented by various
> > filesystems.
> > 
> > We already have inode_inc_iversion. Add several other functions for
> > manipulating and accessing the i_version counter. For now, the
> > implementation is trivial and basically works the way that all of the
> > open-coded i_version accesses work today.
> > 
> > Future patches will convert existing users of i_version to use the new
> > API, and then convert the backend implementation to do things more
> > efficiently.
> > 
> > Signed-off-by: Jeff Layton 
> > ---
> >  include/linux/fs.h | 200 
> > ++---
> >  1 file changed, 192 insertions(+), 8 deletions(-)
> 
> Just a random sunday morning coffee musing
> 
> I was just wondering if it would be better to split this stuff out
> into it's own header file now? include/linux/fs.h is aleady a
> massive header file (~3500 lines) and changes cause tree-wide
> rebuilds, so maybe it would be better to split relatively isolated
> functionality like this out while it's being reworked and you're
> already touching every file that uses it?
> 
> Cheers,
> 
> Dave.

That's a good idea. Let me do that and I'll re-post.

Thanks,
-- 
Jeff Layton 

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

[Jeff Layton]

On Sun, 2017-12-17 at 09:37 +1100, Dave Chinner wrote:
> On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> > From: Jeff Layton 
> > 
> > Add a documentation blob that explains what the i_version field is, how
> > it is expected to work, and how it is currently implemented by various
> > filesystems.
> > 
> > We already have inode_inc_iversion. Add several other functions for
> > manipulating and accessing the i_version counter. For now, the
> > implementation is trivial and basically works the way that all of the
> > open-coded i_version accesses work today.
> > 
> > Future patches will convert existing users of i_version to use the new
> > API, and then convert the backend implementation to do things more
> > efficiently.
> > 
> > Signed-off-by: Jeff Layton 
> > ---
> >  include/linux/fs.h | 200 
> > ++---
> >  1 file changed, 192 insertions(+), 8 deletions(-)
> 
> Just a random sunday morning coffee musing
> 
> I was just wondering if it would be better to split this stuff out
> into it's own header file now? include/linux/fs.h is aleady a
> massive header file (~3500 lines) and changes cause tree-wide
> rebuilds, so maybe it would be better to split relatively isolated
> functionality like this out while it's being reworked and you're
> already touching every file that uses it?
> 
> Cheers,
> 
> Dave.

That's a good idea. Let me do that and I'll re-post.

Thanks,
-- 
Jeff Layton 

Hello Dear,

[www.]

Hello Dear,
Greetings,I'm here to meet a serious man who is ready to keep a serious
relationship with me. I know its hard to find a serious man on internet, I
believe dream come through with one mind. I need reliable person who is honest. 
I am
looking for the right man for me who is sincere, loyal, fun loving and
straight forward. I'm kind,respectful of others and I always try to play
fair. I'm not perfect and am not looking for perfection.I would like to
find a happy person who is comfortable with himself...
i have an important issue to share with you
please email me with.( carawill...@yahoo.com ) for more details.
am not often on this site,
I wait your reply to my email.
Hugs
Cara Williams

Hello Dear,

[www.]

Hello Dear,
Greetings,I'm here to meet a serious man who is ready to keep a serious
relationship with me. I know its hard to find a serious man on internet, I
believe dream come through with one mind. I need reliable person who is honest. 
I am
looking for the right man for me who is sincere, loyal, fun loving and
straight forward. I'm kind,respectful of others and I always try to play
fair. I'm not perfect and am not looking for perfection.I would like to
find a happy person who is comfortable with himself...
i have an important issue to share with you
please email me with.( carawill...@yahoo.com ) for more details.
am not often on this site,
I wait your reply to my email.
Hugs
Cara Williams

fs/cramfs/inode.c:698: undefined reference to `mount_mtd'

[kbuild test robot]

Hi Nicolas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access 
support
date:   9 weeks ago
config: i386-randconfig-x018-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 99c18ce580c6cc6763e694b4ce320d7b226ab59b
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   fs/cramfs/inode.o: In function `cramfs_mount':
>> fs/cramfs/inode.c:698: undefined reference to `mount_mtd'
   fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
>> fs/cramfs/inode.c:432: undefined reference to `mtd_point'
>> fs/cramfs/inode.c:449: undefined reference to `mtd_unpoint'
   fs/cramfs/inode.c:450: undefined reference to `mtd_point'

vim +698 fs/cramfs/inode.c

   691  
   692  static struct dentry *cramfs_mount(struct file_system_type *fs_type, 
int flags,
   693 const char *dev_name, void *data)
   694  {
   695  struct dentry *ret = ERR_PTR(-ENOPROTOOPT);
   696  
   697  if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
 > 698  ret = mount_mtd(fs_type, flags, dev_name, data,
   699  cramfs_mtd_fill_super);
   700  if (!IS_ERR(ret))
   701  return ret;
   702  }
   703  if (IS_ENABLED(CONFIG_CRAMFS_BLOCKDEV)) {
   704  ret = mount_bdev(fs_type, flags, dev_name, data,
   705   cramfs_blkdev_fill_super);
   706  }
   707  return ret;
   708  }
   709  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

fs/cramfs/inode.c:698: undefined reference to `mount_mtd'

[kbuild test robot]

Hi Nicolas,

FYI, the error/warning still remains.

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   f3b5ad89de16f5d42e8ad36fbdf85f705c1ae051
commit: 99c18ce580c6cc6763e694b4ce320d7b226ab59b cramfs: direct memory access 
support
date:   9 weeks ago
config: i386-randconfig-x018-201751 (attached as .config)
compiler: gcc-7 (Debian 7.2.0-12) 7.2.1 20171025
reproduce:
git checkout 99c18ce580c6cc6763e694b4ce320d7b226ab59b
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   fs/cramfs/inode.o: In function `cramfs_mount':
>> fs/cramfs/inode.c:698: undefined reference to `mount_mtd'
   fs/cramfs/inode.o: In function `cramfs_mtd_fill_super':
>> fs/cramfs/inode.c:432: undefined reference to `mtd_point'
>> fs/cramfs/inode.c:449: undefined reference to `mtd_unpoint'
   fs/cramfs/inode.c:450: undefined reference to `mtd_point'

vim +698 fs/cramfs/inode.c

   691  
   692  static struct dentry *cramfs_mount(struct file_system_type *fs_type, 
int flags,
   693 const char *dev_name, void *data)
   694  {
   695  struct dentry *ret = ERR_PTR(-ENOPROTOOPT);
   696  
   697  if (IS_ENABLED(CONFIG_CRAMFS_MTD)) {
 > 698  ret = mount_mtd(fs_type, flags, dev_name, data,
   699  cramfs_mtd_fill_super);
   700  if (!IS_ERR(ret))
   701  return ret;
   702  }
   703  if (IS_ENABLED(CONFIG_CRAMFS_BLOCKDEV)) {
   704  ret = mount_bdev(fs_type, flags, dev_name, data,
   705   cramfs_blkdev_fill_super);
   706  }
   707  return ret;
   708  }
   709  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

[Rafael J. Wysocki]

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote:
> On 16 December 2017 at 22:10, Rafael J. Wysocki  wrote:
> > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar  
> > wrote:
> 
> >> +#define SCHED_CPUFREQ_CLEAR(1U << 31)
> >
> > I'm not thrilled by this, because schedutil is not the only user of
> > the flags and it's totally unclear what the other user(s) should do
> > when this is set.
> 
> intel-pstate is the only other user of the IOWAIT flag, right? In order
> not to change the current behavior, we can update that to return early
> for now ?

We can do that in principle, but why should it return early?  Maybe it's
a good time to update things, incidentally?

I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very
much specific to schedutil and blatantly ignores everybody else.

Alternatively, you could add two flags for clearing SCHED_CPUFREQ_RT and
SCHED_CPUFREQ_DL that could just be ingored entirely by intel_pstate.

So, why don't you make SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL "sticky" until,
say, SCHED_CPUFREQ_NO_RT and SCHED_CPUFREQ_NO_DL are passed, respectively?

Thanks,
Rafael

Re: [PATCH 2/4] sched: cpufreq: Keep track of cpufreq utilization update flags

[Rafael J. Wysocki]

On Saturday, December 16, 2017 5:47:07 PM CET Viresh Kumar wrote:
> On 16 December 2017 at 22:10, Rafael J. Wysocki  wrote:
> > On Wed, Dec 13, 2017 at 10:53 AM, Viresh Kumar  
> > wrote:
> 
> >> +#define SCHED_CPUFREQ_CLEAR(1U << 31)
> >
> > I'm not thrilled by this, because schedutil is not the only user of
> > the flags and it's totally unclear what the other user(s) should do
> > when this is set.
> 
> intel-pstate is the only other user of the IOWAIT flag, right? In order
> not to change the current behavior, we can update that to return early
> for now ?

We can do that in principle, but why should it return early?  Maybe it's
a good time to update things, incidentally?

I actually don't like the SCHED_CPUFRREQ_CLEAR flag *concept* as it is very
much specific to schedutil and blatantly ignores everybody else.

Alternatively, you could add two flags for clearing SCHED_CPUFREQ_RT and
SCHED_CPUFREQ_DL that could just be ingored entirely by intel_pstate.

So, why don't you make SCHED_CPUFREQ_RT and SCHED_CPUFREQ_DL "sticky" until,
say, SCHED_CPUFREQ_NO_RT and SCHED_CPUFREQ_NO_DL are passed, respectively?

Thanks,
Rafael

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/platform/efi/efi_64.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index ccf5239923e8..6b541bdbda5f 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -189,8 +189,6 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
early_code_mapping_set_exec(0);
 }
 
-static pgd_t *efi_pgd;
-
 /*
  * We need our own copy of the higher levels of the page tables
  * because we want to avoid inserting EFI region mappings (EFI_VA_END
@@ -199,7 +197,7 @@ static pgd_t *efi_pgd;
  */
 int __init efi_alloc_page_tables(void)
 {
-   pgd_t *pgd;
+   pgd_t *pgd, *efi_pgd;
p4d_t *p4d;
pud_t *pud;
gfp_t gfp_mask;
@@ -227,6 +225,7 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   efi_mm.pgd = efi_pgd;
mm_init_cpumask(_mm);
init_new_context(NULL, _mm);
 
@@ -242,6 +241,7 @@ void efi_sync_low_kernel_mappings(void)
pgd_t *pgd_k, *pgd_efi;
p4d_t *p4d_k, *p4d_efi;
pud_t *pud_k, *pud_efi;
+   pgd_t *efi_pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return;
@@ -335,7 +335,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
unsigned long pfn, text, pf;
struct page *page;
unsigned npages;
-   pgd_t *pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
@@ -345,8 +345,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 * this value is loaded into cr3 the PGD will be decrypted during
 * the pagetable walk.
 */
-   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
-   pgd = efi_pgd;
+   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(pgd);
 
/*
 * It can happen that the physical address of new_memmap lands in memory
@@ -416,7 +415,7 @@ static void __init __map_region(efi_memory_desc_t *md, u64 
va)
 {
unsigned long flags = _PAGE_RW;
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
@@ -520,7 +519,7 @@ void __init parse_efi_setup(u64 phys_addr, u32 data_len)
 static int __init efi_update_mappings(efi_memory_desc_t *md, unsigned long pf)
 {
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
int err1, err2;
 
/* Update the 1:1 mapping */
@@ -617,7 +616,7 @@ void __init efi_dump_pagetable(void)
if (efi_enabled(EFI_OLD_MEMMAP))
ptdump_walk_pgd_level(NULL, swapper_pg_dir);
else
-   ptdump_walk_pgd_level(NULL, efi_pgd);
+   ptdump_walk_pgd_level(NULL, efi_mm.pgd);
 #endif
 }
 
-- 
2.1.4

[PATCH 2/3] x86/efi: Replace efi_pgd with efi_mm.pgd

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Since the previous patch added support for efi_mm, let's handle efi_pgd
through efi_mm and remove global variable efi_pgd.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/platform/efi/efi_64.c | 17 -
 1 file changed, 8 insertions(+), 9 deletions(-)

diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index ccf5239923e8..6b541bdbda5f 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -189,8 +189,6 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
early_code_mapping_set_exec(0);
 }
 
-static pgd_t *efi_pgd;
-
 /*
  * We need our own copy of the higher levels of the page tables
  * because we want to avoid inserting EFI region mappings (EFI_VA_END
@@ -199,7 +197,7 @@ static pgd_t *efi_pgd;
  */
 int __init efi_alloc_page_tables(void)
 {
-   pgd_t *pgd;
+   pgd_t *pgd, *efi_pgd;
p4d_t *p4d;
pud_t *pud;
gfp_t gfp_mask;
@@ -227,6 +225,7 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   efi_mm.pgd = efi_pgd;
mm_init_cpumask(_mm);
init_new_context(NULL, _mm);
 
@@ -242,6 +241,7 @@ void efi_sync_low_kernel_mappings(void)
pgd_t *pgd_k, *pgd_efi;
p4d_t *p4d_k, *p4d_efi;
pud_t *pud_k, *pud_efi;
+   pgd_t *efi_pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return;
@@ -335,7 +335,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
unsigned long pfn, text, pf;
struct page *page;
unsigned npages;
-   pgd_t *pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (efi_enabled(EFI_OLD_MEMMAP))
return 0;
@@ -345,8 +345,7 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
 * this value is loaded into cr3 the PGD will be decrypted during
 * the pagetable walk.
 */
-   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(efi_pgd);
-   pgd = efi_pgd;
+   efi_scratch.efi_pgt = (pgd_t *)__sme_pa(pgd);
 
/*
 * It can happen that the physical address of new_memmap lands in memory
@@ -416,7 +415,7 @@ static void __init __map_region(efi_memory_desc_t *md, u64 
va)
 {
unsigned long flags = _PAGE_RW;
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
 
if (!(md->attribute & EFI_MEMORY_WB))
flags |= _PAGE_PCD;
@@ -520,7 +519,7 @@ void __init parse_efi_setup(u64 phys_addr, u32 data_len)
 static int __init efi_update_mappings(efi_memory_desc_t *md, unsigned long pf)
 {
unsigned long pfn;
-   pgd_t *pgd = efi_pgd;
+   pgd_t *pgd = efi_mm.pgd;
int err1, err2;
 
/* Update the 1:1 mapping */
@@ -617,7 +616,7 @@ void __init efi_dump_pagetable(void)
if (efi_enabled(EFI_OLD_MEMMAP))
ptdump_walk_pgd_level(NULL, swapper_pg_dir);
else
-   ptdump_walk_pgd_level(NULL, efi_pgd);
+   ptdump_walk_pgd_level(NULL, efi_mm.pgd);
 #endif
 }
 
-- 
2.1.4

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Use helper function (efi_switch_mm()) to switch to/from efi_mm. We
switch to efi_mm before calling
1. efi_set_virtual_address_map() and
2. Invoking any efi_runtime_service()

Likewise, we need to switch back to previous mm (mm context stolen by
efi_mm) after the above calls return successfully. We can use
efi_switch_mm() helper function only with x86_64 kernel and
"efi=old_map" disabled because, x86_32 and efi=old_map doesn't use
efi_pgd, rather they use swapper_pg_dir.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/include/asm/efi.h   | 25 +-
 arch/x86/platform/efi/efi_64.c   | 41 ++--
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 3 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 00f977ddd718..cda9940bed7a 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -62,14 +62,13 @@ extern asmlinkage u64 efi_call(void *fp, ...);
 #define efi_call_phys(f, args...)  efi_call((f), args)
 
 /*
- * Scratch space used for switching the pagetable in the EFI stub
+ * struct efi_scratch - Scratch space used while switching to/from efi_mm
+ * @phys_stack: stack used during EFI Mixed Mode
+ * @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
  */
 struct efi_scratch {
-   u64 r15;
-   u64 prev_cr3;
-   pgd_t   *efi_pgt;
-   booluse_pgd;
-   u64 phys_stack;
+   u64 phys_stack;
+   struct mm_struct*prev_mm;
 } __packed;
 
 #define arch_efi_call_virt_setup() \
@@ -78,11 +77,8 @@ struct efi_scratch {
preempt_disable();  \
__kernel_fpu_begin();   \
\
-   if (efi_scratch.use_pgd) {  \
-   efi_scratch.prev_cr3 = __read_cr3();\
-   write_cr3((unsigned long)efi_scratch.efi_pgt);  \
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(_mm); \
 })
 
 #define arch_efi_call_virt(p, f, args...)  \
@@ -90,10 +86,8 @@ struct efi_scratch {
 
 #define arch_efi_call_virt_teardown()  \
 ({ \
-   if (efi_scratch.use_pgd) {  \
-   write_cr3(efi_scratch.prev_cr3);\
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(efi_scratch.prev_mm); \
\
__kernel_fpu_end(); \
preempt_enable();   \
@@ -135,6 +129,7 @@ extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
 extern void efi_delete_dummy_variable(void);
+extern void efi_switch_mm(struct mm_struct *mm);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6b541bdbda5f..c325b1cc4d1a 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -82,9 +82,8 @@ pgd_t * __init efi_call_phys_prolog(void)
int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   save_pgd = (pgd_t *)__read_cr3();
-   write_cr3((unsigned long)efi_scratch.efi_pgt);
-   goto out;
+   efi_switch_mm(_mm);
+   return NULL;
}
 
early_code_mapping_set_exec(1);
@@ -154,8 +153,7 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
pud_t *pud;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   

[PATCH 3/3] x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Use helper function (efi_switch_mm()) to switch to/from efi_mm. We
switch to efi_mm before calling
1. efi_set_virtual_address_map() and
2. Invoking any efi_runtime_service()

Likewise, we need to switch back to previous mm (mm context stolen by
efi_mm) after the above calls return successfully. We can use
efi_switch_mm() helper function only with x86_64 kernel and
"efi=old_map" disabled because, x86_32 and efi=old_map doesn't use
efi_pgd, rather they use swapper_pg_dir.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Bhupesh Sharma 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/include/asm/efi.h   | 25 +-
 arch/x86/platform/efi/efi_64.c   | 41 ++--
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 3 files changed, 32 insertions(+), 36 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 00f977ddd718..cda9940bed7a 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -62,14 +62,13 @@ extern asmlinkage u64 efi_call(void *fp, ...);
 #define efi_call_phys(f, args...)  efi_call((f), args)
 
 /*
- * Scratch space used for switching the pagetable in the EFI stub
+ * struct efi_scratch - Scratch space used while switching to/from efi_mm
+ * @phys_stack: stack used during EFI Mixed Mode
+ * @prev_mm:store/restore stolen mm_struct while switching to/from efi_mm
  */
 struct efi_scratch {
-   u64 r15;
-   u64 prev_cr3;
-   pgd_t   *efi_pgt;
-   booluse_pgd;
-   u64 phys_stack;
+   u64 phys_stack;
+   struct mm_struct*prev_mm;
 } __packed;
 
 #define arch_efi_call_virt_setup() \
@@ -78,11 +77,8 @@ struct efi_scratch {
preempt_disable();  \
__kernel_fpu_begin();   \
\
-   if (efi_scratch.use_pgd) {  \
-   efi_scratch.prev_cr3 = __read_cr3();\
-   write_cr3((unsigned long)efi_scratch.efi_pgt);  \
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(_mm); \
 })
 
 #define arch_efi_call_virt(p, f, args...)  \
@@ -90,10 +86,8 @@ struct efi_scratch {
 
 #define arch_efi_call_virt_teardown()  \
 ({ \
-   if (efi_scratch.use_pgd) {  \
-   write_cr3(efi_scratch.prev_cr3);\
-   __flush_tlb_all();  \
-   }   \
+   if (!efi_enabled(EFI_OLD_MEMMAP))   \
+   efi_switch_mm(efi_scratch.prev_mm); \
\
__kernel_fpu_end(); \
preempt_enable();   \
@@ -135,6 +129,7 @@ extern void __init efi_dump_pagetable(void);
 extern void __init efi_apply_memmap_quirks(void);
 extern int __init efi_reuse_config(u64 tables, int nr_tables);
 extern void efi_delete_dummy_variable(void);
+extern void efi_switch_mm(struct mm_struct *mm);
 
 struct efi_setup_data {
u64 fw_vendor;
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6b541bdbda5f..c325b1cc4d1a 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -82,9 +82,8 @@ pgd_t * __init efi_call_phys_prolog(void)
int n_pgds, i, j;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   save_pgd = (pgd_t *)__read_cr3();
-   write_cr3((unsigned long)efi_scratch.efi_pgt);
-   goto out;
+   efi_switch_mm(_mm);
+   return NULL;
}
 
early_code_mapping_set_exec(1);
@@ -154,8 +153,7 @@ void __init efi_call_phys_epilog(pgd_t *save_pgd)
pud_t *pud;
 
if (!efi_enabled(EFI_OLD_MEMMAP)) {
-   write_cr3((unsigned long)save_pgd);
-   __flush_tlb_all();
+   efi_switch_mm(efi_scratch.prev_mm);
return;
}
 
@@ -341,13 +339,6 @@ int __init efi_setup_page_tables(unsigned long pa_memmap, 
unsigned num_pages)
return 0;
 
/*
-* 

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, only ARM uses mm_struct to manage efi page tables and efi
runtime region mappings. As this is the preferred approach, let's make
this data structure common across architectures. Specially, for x86,
using this data structure improves code maintainability and readability.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/include/asm/efi.h | 4 
 arch/x86/platform/efi/efi_64.c | 3 +++
 drivers/firmware/efi/arm-runtime.c | 9 -
 drivers/firmware/efi/efi.c | 9 +
 include/linux/efi.h| 2 ++
 5 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 85f6ccb80b91..00f977ddd718 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -2,10 +2,14 @@
 #ifndef _ASM_X86_EFI_H
 #define _ASM_X86_EFI_H
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /*
  * We map the EFI regions needed for runtime services non-contiguously,
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6a151ce70e86..ccf5239923e8 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -227,6 +227,9 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   mm_init_cpumask(_mm);
+   init_new_context(NULL, _mm);
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 1cc41c3d6315..d6b26534812b 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -31,15 +31,6 @@
 
 extern u64 efi_system_table;
 
-static struct mm_struct efi_mm = {
-   .mm_rb  = RB_ROOT,
-   .mm_users   = ATOMIC_INIT(2),
-   .mm_count   = ATOMIC_INIT(1),
-   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
-   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
-   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
-};
-
 #ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
 #include 
 
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 557a47829d03..760260b933b6 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -74,6 +74,15 @@ static unsigned long *efi_tables[] = {
_attr_table,
 };
 
+struct mm_struct efi_mm = {
+   .mm_rb  = RB_ROOT,
+   .mm_users   = ATOMIC_INIT(2),
+   .mm_count   = ATOMIC_INIT(1),
+   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
+   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
+   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
+};
+
 static bool disable_runtime;
 static int __init setup_noefi(char *arg)
 {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index d813f7b04da7..6745f4dbbcc1 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -928,6 +928,8 @@ extern struct efi {
unsigned long flags;
 } efi;
 
+extern struct mm_struct efi_mm;
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
-- 
2.1.4

[PATCH 1/3] efi: Use efi_mm in x86 as well as ARM

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, only ARM uses mm_struct to manage efi page tables and efi
runtime region mappings. As this is the preferred approach, let's make
this data structure common across architectures. Specially, for x86,
using this data structure improves code maintainability and readability.

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 
---
 arch/x86/include/asm/efi.h | 4 
 arch/x86/platform/efi/efi_64.c | 3 +++
 drivers/firmware/efi/arm-runtime.c | 9 -
 drivers/firmware/efi/efi.c | 9 +
 include/linux/efi.h| 2 ++
 5 files changed, 18 insertions(+), 9 deletions(-)

diff --git a/arch/x86/include/asm/efi.h b/arch/x86/include/asm/efi.h
index 85f6ccb80b91..00f977ddd718 100644
--- a/arch/x86/include/asm/efi.h
+++ b/arch/x86/include/asm/efi.h
@@ -2,10 +2,14 @@
 #ifndef _ASM_X86_EFI_H
 #define _ASM_X86_EFI_H
 
+#include 
+#include 
+
 #include 
 #include 
 #include 
 #include 
+#include 
 
 /*
  * We map the EFI regions needed for runtime services non-contiguously,
diff --git a/arch/x86/platform/efi/efi_64.c b/arch/x86/platform/efi/efi_64.c
index 6a151ce70e86..ccf5239923e8 100644
--- a/arch/x86/platform/efi/efi_64.c
+++ b/arch/x86/platform/efi/efi_64.c
@@ -227,6 +227,9 @@ int __init efi_alloc_page_tables(void)
return -ENOMEM;
}
 
+   mm_init_cpumask(_mm);
+   init_new_context(NULL, _mm);
+
return 0;
 }
 
diff --git a/drivers/firmware/efi/arm-runtime.c 
b/drivers/firmware/efi/arm-runtime.c
index 1cc41c3d6315..d6b26534812b 100644
--- a/drivers/firmware/efi/arm-runtime.c
+++ b/drivers/firmware/efi/arm-runtime.c
@@ -31,15 +31,6 @@
 
 extern u64 efi_system_table;
 
-static struct mm_struct efi_mm = {
-   .mm_rb  = RB_ROOT,
-   .mm_users   = ATOMIC_INIT(2),
-   .mm_count   = ATOMIC_INIT(1),
-   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
-   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
-   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
-};
-
 #ifdef CONFIG_ARM64_PTDUMP_DEBUGFS
 #include 
 
diff --git a/drivers/firmware/efi/efi.c b/drivers/firmware/efi/efi.c
index 557a47829d03..760260b933b6 100644
--- a/drivers/firmware/efi/efi.c
+++ b/drivers/firmware/efi/efi.c
@@ -74,6 +74,15 @@ static unsigned long *efi_tables[] = {
_attr_table,
 };
 
+struct mm_struct efi_mm = {
+   .mm_rb  = RB_ROOT,
+   .mm_users   = ATOMIC_INIT(2),
+   .mm_count   = ATOMIC_INIT(1),
+   .mmap_sem   = __RWSEM_INITIALIZER(efi_mm.mmap_sem),
+   .page_table_lock= __SPIN_LOCK_UNLOCKED(efi_mm.page_table_lock),
+   .mmlist = LIST_HEAD_INIT(efi_mm.mmlist),
+};
+
 static bool disable_runtime;
 static int __init setup_noefi(char *arg)
 {
diff --git a/include/linux/efi.h b/include/linux/efi.h
index d813f7b04da7..6745f4dbbcc1 100644
--- a/include/linux/efi.h
+++ b/include/linux/efi.h
@@ -928,6 +928,8 @@ extern struct efi {
unsigned long flags;
 } efi;
 
+extern struct mm_struct efi_mm;
+
 static inline int
 efi_guidcmp (efi_guid_t left, efi_guid_t right)
 {
-- 
2.1.4

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, in x86, to invoke any efi function like
efi_set_virtual_address_map() or any efi_runtime_service() the code path
typically involves read_cr3() (save previous pgd), write_cr3()
(write efi_pgd) and calling efi function. Likewise after returning from
efi function the code path typically involves read_cr3() (save efi_pgd),
write_cr3() (write previous pgd). We do this couple of times in efi
subsystem of Linux kernel, instead we can use helper function
efi_switch_mm() to do this. This improves readability and maintainability.
Also, instead of maintaining a separate struct "efi_scratch" to store/restore
efi_pgd, we can use mm_struct to do this.

I have tested this patch set against LUV (Linux UEFI Validation), so I
think I didn't break any existing configurations. I have tested this
patch set for
1. x86_64,
2. x86_32,
3. Mixed mode
with efi=old_map and for kexec kernel. Please let me know if I have
missed any other configurations.

Changes in V2:
1. Resolve mm_dropping() issue by not mm_dropping()/mm_grabbing() any mm,
as we are not losing/creating any references.

Changes in V3:
1. When CPUMASK_OFFSTACK is enabled, switch_mm_irqs_off() sets cpumask
by calling cpumask_set_cpu(). This panics kernel as efi_mm is not
initialized, therefore initialize efi_mm in efi_alloc_page_tables().

Note:
This patch set is based on Linus's tree v4.15-rc3

Sai Praneeth (3):
  efi: Use efi_mm in x86 as well as ARM
  x86/efi: Replace efi_pgd with efi_mm.pgd
  x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

 arch/x86/include/asm/efi.h   | 29 +-
 arch/x86/platform/efi/efi_64.c   | 59 +++-
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 drivers/firmware/efi/arm-runtime.c   |  9 --
 drivers/firmware/efi/efi.c   |  9 ++
 include/linux/efi.h  |  2 ++
 6 files changed, 57 insertions(+), 53 deletions(-)

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 

-- 
2.1.4

[PATCH 0/3] Use mm_struct and switch_mm() instead of manually

[Sai Praneeth Prakhya]

From: Sai Praneeth 

Presently, in x86, to invoke any efi function like
efi_set_virtual_address_map() or any efi_runtime_service() the code path
typically involves read_cr3() (save previous pgd), write_cr3()
(write efi_pgd) and calling efi function. Likewise after returning from
efi function the code path typically involves read_cr3() (save efi_pgd),
write_cr3() (write previous pgd). We do this couple of times in efi
subsystem of Linux kernel, instead we can use helper function
efi_switch_mm() to do this. This improves readability and maintainability.
Also, instead of maintaining a separate struct "efi_scratch" to store/restore
efi_pgd, we can use mm_struct to do this.

I have tested this patch set against LUV (Linux UEFI Validation), so I
think I didn't break any existing configurations. I have tested this
patch set for
1. x86_64,
2. x86_32,
3. Mixed mode
with efi=old_map and for kexec kernel. Please let me know if I have
missed any other configurations.

Changes in V2:
1. Resolve mm_dropping() issue by not mm_dropping()/mm_grabbing() any mm,
as we are not losing/creating any references.

Changes in V3:
1. When CPUMASK_OFFSTACK is enabled, switch_mm_irqs_off() sets cpumask
by calling cpumask_set_cpu(). This panics kernel as efi_mm is not
initialized, therefore initialize efi_mm in efi_alloc_page_tables().

Note:
This patch set is based on Linus's tree v4.15-rc3

Sai Praneeth (3):
  efi: Use efi_mm in x86 as well as ARM
  x86/efi: Replace efi_pgd with efi_mm.pgd
  x86/efi: Use efi_switch_mm() rather than manually twiddling with %cr3

 arch/x86/include/asm/efi.h   | 29 +-
 arch/x86/platform/efi/efi_64.c   | 59 +++-
 arch/x86/platform/efi/efi_thunk_64.S |  2 +-
 drivers/firmware/efi/arm-runtime.c   |  9 --
 drivers/firmware/efi/efi.c   |  9 ++
 include/linux/efi.h  |  2 ++
 6 files changed, 57 insertions(+), 53 deletions(-)

Signed-off-by: Sai Praneeth Prakhya 
Cc: Lee, Chun-Yi 
Cc: Borislav Petkov 
Cc: Tony Luck 
Cc: Andy Lutomirski 
Cc: Michael S. Tsirkin 
Cc: Ricardo Neri 
Cc: Matt Fleming 
Cc: Ard Biesheuvel 
Cc: Ravi Shankar 
Tested-by: Bhupesh Sharma 

-- 
2.1.4

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar  wrote:
> >
> > These are the x86-64 low level entry code preparatory patches for the page 
> > table
> > isolation patches - which are required for PTI, which addresses KASLR and 
> > similar
> > information leaks.
> 
> Ugh.
> 
> Ok, I've read through this, and while I like most of it (I do like the
> percpu syscall stack), I have this urge to wait until after rc4. With
> the suspend/resume issues,

Yeah, so as a response to those breakages I recently started testing s2ram as a 
regular part of -tip testing, so every tree I send to you does s2ram fine on my 
(suspendable) testsystems. That's still not full coverage, but should be better 
than what we had.

> [...] we've had a horrible track record for 4.15 rc's so far, I'l like to not 
> pull another low-level x86 change just before an rc release and potentially 
> make 
> it four for four broken rc's.

Yeah, I can understand that. I knew the weekend timing is awkward, but I tried 
to 
post it as soon as I felt it was ready and as soon upstream (x86) stability 
looked 
good.

> And I absolutely detest how that cherry-pick branch was done. I can
> see why, but:
> 
>  - now we have those extra cherry-picks that I already have
> 
>  - and the merge commit isn't even a no-op!
> 
> Dammit, if the point was to have a branch that worked for 4.14, I can
> see that. But look at that merge (on the "other side"), and notice how
> the end result is *not* identical to the parent.
> 
> IOW, that
> 
>   9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
> up cherry-picked base tree and preparatory patches
> 
> was supposed to be a synchronization point, but if you do
> 
> git diff 9a818d1a3235..9a818d1a3235^
> 
> it isn't actually synchronized. It's *almost* synchronized, but not
> quite. How did those cherry-picks that were already upstream end up
> causing *changes* upstream? That's odd.
> 
> So there are some technical oddities in there.

Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, 
except these two commits:

One of the PTI namespace preparatory patches ended up in the 'base' tree:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the 
namespace

plus there's this cherry-pick from a very recent upstream kernel:

  c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h

which was required for UML to build and be testable.

We can move both commits to a later stage in the tree to make the v4.14 base 
tree 
an 'obvious' upstream-identical tree.

Will respin it all tomorrow.

Thanks,

Ingo

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Ingo Molnar]

* Linus Torvalds  wrote:

> On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar  wrote:
> >
> > These are the x86-64 low level entry code preparatory patches for the page 
> > table
> > isolation patches - which are required for PTI, which addresses KASLR and 
> > similar
> > information leaks.
> 
> Ugh.
> 
> Ok, I've read through this, and while I like most of it (I do like the
> percpu syscall stack), I have this urge to wait until after rc4. With
> the suspend/resume issues,

Yeah, so as a response to those breakages I recently started testing s2ram as a 
regular part of -tip testing, so every tree I send to you does s2ram fine on my 
(suspendable) testsystems. That's still not full coverage, but should be better 
than what we had.

> [...] we've had a horrible track record for 4.15 rc's so far, I'l like to not 
> pull another low-level x86 change just before an rc release and potentially 
> make 
> it four for four broken rc's.

Yeah, I can understand that. I knew the weekend timing is awkward, but I tried 
to 
post it as soon as I felt it was ready and as soon upstream (x86) stability 
looked 
good.

> And I absolutely detest how that cherry-pick branch was done. I can
> see why, but:
> 
>  - now we have those extra cherry-picks that I already have
> 
>  - and the merge commit isn't even a no-op!
> 
> Dammit, if the point was to have a branch that worked for 4.14, I can
> see that. But look at that merge (on the "other side"), and notice how
> the end result is *not* identical to the parent.
> 
> IOW, that
> 
>   9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
> up cherry-picked base tree and preparatory patches
> 
> was supposed to be a synchronization point, but if you do
> 
> git diff 9a818d1a3235..9a818d1a3235^
> 
> it isn't actually synchronized. It's *almost* synchronized, but not
> quite. How did those cherry-picks that were already upstream end up
> causing *changes* upstream? That's odd.
> 
> So there are some technical oddities in there.

Indeed, and I tried to make it a no-op merge, and it's _almost_ a no-op merge, 
except these two commits:

One of the PTI namespace preparatory patches ended up in the 'base' tree:

  d78b637b29a2: drivers/misc/intel/pti: Rename the header file to free up the 
namespace

plus there's this cherry-pick from a very recent upstream kernel:

  c3bc8b53d54c: bpf: fix build issues on um due to mising bpf_perf_event.h

which was required for UML to build and be testable.

We can move both commits to a later stage in the tree to make the v4.14 base 
tree 
an 'obvious' upstream-identical tree.

Will respin it all tomorrow.

Thanks,

Ingo

[PATCH][next] mei: fix spelling mistake: "botther" -> "bother"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_dbg debug message. Also
add in a missing comma.

Signed-off-by: Colin Ian King 
---
 drivers/misc/mei/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 2a5146bdecf1..3e5eabdae8d9 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -549,7 +549,7 @@ int mei_cldev_disable(struct mei_cl_device *cldev)
}
 
if (bus->dev_state == MEI_DEV_POWER_DOWN) {
-   dev_dbg(bus->dev, "Device is powering down don't botther with 
disconnection\n");
+   dev_dbg(bus->dev, "Device is powering down, don't bother with 
disconnection\n");
err = 0;
goto out;
}
-- 
2.14.1

[PATCH][next] mei: fix spelling mistake: "botther" -> "bother"

[Colin King]

From: Colin Ian King 

Trivial fix to spelling mistake in dev_dbg debug message. Also
add in a missing comma.

Signed-off-by: Colin Ian King 
---
 drivers/misc/mei/bus.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/misc/mei/bus.c b/drivers/misc/mei/bus.c
index 2a5146bdecf1..3e5eabdae8d9 100644
--- a/drivers/misc/mei/bus.c
+++ b/drivers/misc/mei/bus.c
@@ -549,7 +549,7 @@ int mei_cldev_disable(struct mei_cl_device *cldev)
}
 
if (bus->dev_state == MEI_DEV_POWER_DOWN) {
-   dev_dbg(bus->dev, "Device is powering down don't botther with 
disconnection\n");
+   dev_dbg(bus->dev, "Device is powering down, don't bother with 
disconnection\n");
err = 0;
goto out;
}
-- 
2.14.1

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.x86/pti-upstream
head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
in its own PGD if PTI is on
config: i386-randconfig-h0-12170619 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86//kernel/apic/ipi.c:16:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function)
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in
--
   In file included from arch/x86//kernel/cpu/common.c:22:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function)
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in
   In file included from arch/x86//kernel/cpu/common.c:22:0:
   arch/x86/include/asm/mmu_context.h:74:1: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^

vim +/LDT_BASE_ADDR +73 arch/x86/include/asm/mmu_context.h

70  
71  static inline void *ldt_slot_va(int slot)
72  {
  > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
74  }
75  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

[tip:WIP.x86/pti-upstream 38/50] arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
WIP.x86/pti-upstream
head:   78e4da51f7c77587cc6f419af4f63a21b289bdb7
commit: 7e482cfe4a23ead21215423c4566c8516ba21025 [38/50] x86/pti: Put the LDT 
in its own PGD if PTI is on
config: i386-randconfig-h0-12170619 (attached as .config)
compiler: gcc-6 (Debian 6.4.0-9) 6.4.0 20171026
reproduce:
git checkout 7e482cfe4a23ead21215423c4566c8516ba21025
# save the attached .config to linux build tree
make ARCH=i386 

All errors (new ones prefixed by >>):

   In file included from arch/x86//kernel/apic/ipi.c:16:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function)
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in
--
   In file included from arch/x86//kernel/cpu/common.c:22:0:
   arch/x86/include/asm/mmu_context.h: In function 'ldt_slot_va':
>> arch/x86/include/asm/mmu_context.h:73:18: error: 'LDT_BASE_ADDR' undeclared 
>> (first use in this function)
 return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
 ^
   arch/x86/include/asm/mmu_context.h:73:18: note: each undeclared identifier 
is reported only once for each function it appears in
   In file included from arch/x86//kernel/cpu/common.c:22:0:
   arch/x86/include/asm/mmu_context.h:74:1: warning: control reaches end of 
non-void function [-Wreturn-type]
}
^

vim +/LDT_BASE_ADDR +73 arch/x86/include/asm/mmu_context.h

70  
71  static inline void *ldt_slot_va(int slot)
72  {
  > 73  return (void *)(LDT_BASE_ADDR + LDT_SLOT_STRIDE * slot);
74  }
75  

---
0-DAY kernel test infrastructureOpen Source Technology Center
https://lists.01.org/pipermail/kbuild-all   Intel Corporation


.config.gz
Description: application/gzip

Re: [PATCH] ext4: delayed inode update for the consistency of file size after a crash

[Theodore Ts'o]

On Sat, Dec 16, 2017 at 01:33:26PM +0900, Seongbae Son wrote:
> > > Details can be found as follows.
> > >
> > > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 
> > > Filesystem”,
> > > In Proc. of APSYS 2017, Mumbai, India
> 
> > This is behind a paywall, so I can't access it.  I am sorry I wasn't
> > on the program committee, or I would have pointed this out while the
> > paper was being reviewed.
> 
> Thanks for your quick answer.
> I am sorry about that. I could not think about the paywall.

If you want to send me a PDF of the paper, I'm happy to look at it.

> I have performed the above scenario to xfs, btrfs, f2fs, and zfs.
> As the test result, all of the four file systems does not have the problem
> that fileA in which fsync() was not executed has the wrong file size
> after a system crash. So, I think, the portability of applications might be
> okay even though EXT4 guarantees the consistency between the file size and
> the data blocks of the file that fsync() is not executed after a system crash.

So first of all, there are more file systems than xfs, btrfs, f2fs,
and zfs, and there are more operating systems than Linux and Solaris.

Secondly, your patch doesn't solve the problem.  Updating the
timestamps without putting the changes in a transaction is no
guarantee; if some other process does some operation such as chmod,
et. al, the inode timestamps will get updated ahead of time.  Worse,
you are updating the i_size in a separate handle, right *before* the
write request is submitted.  So if a transaction commit gets started
immediately after call to ext4_journal_stop() which was added in
mpage_process_page_bufs(), it's still possible for i_size to be
updated and be visible after a crash, without the data block being
updated.  It's a narrower race window, but it's still there.

Furthermore, the patch is huge because the introduction of the new
functions _ext4_update_time(), ext4_update_time(),
_generic_file_write_iter() have included a large amount of extra lines
of code which are copied from elsewhere --- e.g., this is "reverse
code factoring" --- and it makes the resulting source less
maintainable.  And the fact that it forces every single write which
affects the last block in the file to be written *twice* means that it
has really unfortunate real performance impacts for workloads which
are appending to a file (e.g., any kind of log file).

If you really want to solve this problem, what needs to be done is
that update of the timestamp and i_size needs to be moved to an I/O
completion handler.  We do this already to convert unwritten requests
to be written in fs/ext4/page_io.c.  See ext4_put_io_end_defer() in
fs/ext4/page_io.c; if we need to convert unwritten extents the
EXT4_IO_END_UNWRITTEN flag is set, and ext4_add_complete_io() tacks
the io_end queue onto a workqueue.  This infrastructure could be made
more general so that it can do other work after the I/O has been
completed, including the i_size update.

I'm not really convinced it's worth it, but this would be a much more
efficient way of solving the problem, and it would avoid need to clone
a large amount of code both in ext4 and in the generic mm/filemap.c
file.

Best regards,

- Ted

Re: [PATCH] ext4: delayed inode update for the consistency of file size after a crash

[Theodore Ts'o]

On Sat, Dec 16, 2017 at 01:33:26PM +0900, Seongbae Son wrote:
> > > Details can be found as follows.
> > >
> > > Son et al. "Guaranteeing the Metadata Update Atomicity in EXT4 
> > > Filesystem”,
> > > In Proc. of APSYS 2017, Mumbai, India
> 
> > This is behind a paywall, so I can't access it.  I am sorry I wasn't
> > on the program committee, or I would have pointed this out while the
> > paper was being reviewed.
> 
> Thanks for your quick answer.
> I am sorry about that. I could not think about the paywall.

If you want to send me a PDF of the paper, I'm happy to look at it.

> I have performed the above scenario to xfs, btrfs, f2fs, and zfs.
> As the test result, all of the four file systems does not have the problem
> that fileA in which fsync() was not executed has the wrong file size
> after a system crash. So, I think, the portability of applications might be
> okay even though EXT4 guarantees the consistency between the file size and
> the data blocks of the file that fsync() is not executed after a system crash.

So first of all, there are more file systems than xfs, btrfs, f2fs,
and zfs, and there are more operating systems than Linux and Solaris.

Secondly, your patch doesn't solve the problem.  Updating the
timestamps without putting the changes in a transaction is no
guarantee; if some other process does some operation such as chmod,
et. al, the inode timestamps will get updated ahead of time.  Worse,
you are updating the i_size in a separate handle, right *before* the
write request is submitted.  So if a transaction commit gets started
immediately after call to ext4_journal_stop() which was added in
mpage_process_page_bufs(), it's still possible for i_size to be
updated and be visible after a crash, without the data block being
updated.  It's a narrower race window, but it's still there.

Furthermore, the patch is huge because the introduction of the new
functions _ext4_update_time(), ext4_update_time(),
_generic_file_write_iter() have included a large amount of extra lines
of code which are copied from elsewhere --- e.g., this is "reverse
code factoring" --- and it makes the resulting source less
maintainable.  And the fact that it forces every single write which
affects the last block in the file to be written *twice* means that it
has really unfortunate real performance impacts for workloads which
are appending to a file (e.g., any kind of log file).

If you really want to solve this problem, what needs to be done is
that update of the timestamp and i_size needs to be moved to an I/O
completion handler.  We do this already to convert unwritten requests
to be written in fs/ext4/page_io.c.  See ext4_put_io_end_defer() in
fs/ext4/page_io.c; if we need to convert unwritten extents the
EXT4_IO_END_UNWRITTEN flag is set, and ext4_add_complete_io() tacks
the io_end queue onto a workqueue.  This infrastructure could be made
more general so that it can do other work after the I/O has been
completed, including the i_size update.

I'm not really convinced it's worth it, but this would be a much more
efficient way of solving the problem, and it would avoid need to clone
a large amount of code both in ext4 and in the generic mm/filemap.c
file.

Best regards,

- Ted

Re: BUG: bad usercopy in ___sys_sendmsg

[Kees Cook]

On Sat, Dec 16, 2017 at 12:29 PM, syzbot

wrote:
> Hello,
>
> syzkaller hit the following crash on
> 5c13e07580c8bd2af6aa902d6b62faa968c360bc
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> Unfortunately, I don't have any reproducer for this bug yet.
>

The report before the BUG output is:

[  518.368426] usercopy: kernel memory overwrite attempt detected to
9919ac15 (kmalloc-1024) (960 bytes)

This looks like a heap overflow (the offset into the 1024 buffer isn't
being reported, so it's not clear how far it goes):

if (copy_from_user(ctl_buf,
   (void __user __force *)msg_sys->msg_control,
   ctl_len))

I would expect the 960 to be ctl_len, though this somehow means the
earlier sock_kmalloc() and kmalloc() broke in some insane fashion.

A reproducer would be nice here; maybe there is some other corruption
happening that manifests as an overflow?

-Kees


>
> [ cut here ]
> netlink: 'syz-executor2': attribute type 5 has an invalid length.
> kernel BUG at mm/usercopy.c:72!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 24150 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #153
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:report_usercopy mm/usercopy.c:64 [inline]
> RIP: 0010:__check_object_size+0x3a2/0x4f0 mm/usercopy.c:264
> RSP: 0018:8801cece7940 EFLAGS: 00010282
> RAX: 0061 RBX: 85328d40 RCX: 
> RDX: 0061 RSI: c90003cae000 RDI: ed0039d9cf1c
> RBP: 8801cece7a30 R08: 8801cece71a8 R09: 
> R10: 712bcb5c R11:  R12: 85328d00
> R13: 8801cb8936d0 R14: 03c0 R15: ea00072e2480
> FS:  7f8422fd6700() GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 558e50e10460 CR3: 00019cd91000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  check_object_size include/linux/thread_info.h:112 [inline]
>  check_copy_size include/linux/thread_info.h:143 [inline]
>  copy_from_user include/linux/uaccess.h:146 [inline]
>  ___sys_sendmsg+0x58f/0x8a0 net/socket.c:2003
>  __sys_sendmmsg+0x1e6/0x5f0 net/socket.c:2116
>  SYSC_sendmmsg net/socket.c:2147 [inline]
>  SyS_sendmmsg+0x35/0x60 net/socket.c:2142
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f8422fd5c58 EFLAGS: 0212 ORIG_RAX: 0133
> RAX: ffda RBX: 7f8422fd6700 RCX: 00452a39
> RDX: 0006 RSI: 2077ce98 RDI: 0015
> RBP:  R08:  R09: 
> R10:  R11: 0212 R12: 
> R13: 00a6f7ff R14: 7f8422fd69c0 R15: 
> Code: 48 0f 44 da e8 e0 6e c2 ff 48 8b 85 28 ff ff ff 4d 89 f1 4c 89 e9 4c
> 89 e2 48 89 de 48 c7 c7 00 8e 32 85 49 89 c0 e8 e6 2c ac ff <0f> 0b 48 c7 c0
> c0 8b 32 85 eb 96 48 c7 c0 00 8c 32 85 eb 8d 48
> RIP: report_usercopy mm/usercopy.c:64 [inline] RSP: 8801cece7940
> RIP: __check_object_size+0x3a2/0x4f0 mm/usercopy.c:264 RSP: 8801cece7940
> ---[ end trace 22ce313ea80c715c ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.



-- 
Kees Cook
Pixel Security

Re: BUG: bad usercopy in ___sys_sendmsg

[Kees Cook]

On Sat, Dec 16, 2017 at 12:29 PM, syzbot

wrote:
> Hello,
>
> syzkaller hit the following crash on
> 5c13e07580c8bd2af6aa902d6b62faa968c360bc
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console output is attached.
>
> Unfortunately, I don't have any reproducer for this bug yet.
>

The report before the BUG output is:

[  518.368426] usercopy: kernel memory overwrite attempt detected to
9919ac15 (kmalloc-1024) (960 bytes)

This looks like a heap overflow (the offset into the 1024 buffer isn't
being reported, so it's not clear how far it goes):

if (copy_from_user(ctl_buf,
   (void __user __force *)msg_sys->msg_control,
   ctl_len))

I would expect the 960 to be ctl_len, though this somehow means the
earlier sock_kmalloc() and kmalloc() broke in some insane fashion.

A reproducer would be nice here; maybe there is some other corruption
happening that manifests as an overflow?

-Kees


>
> [ cut here ]
> netlink: 'syz-executor2': attribute type 5 has an invalid length.
> kernel BUG at mm/usercopy.c:72!
> invalid opcode:  [#1] SMP KASAN
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Modules linked in:
> CPU: 0 PID: 24150 Comm: syz-executor3 Not tainted 4.15.0-rc2+ #153
> Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS
> Google 01/01/2011
> RIP: 0010:report_usercopy mm/usercopy.c:64 [inline]
> RIP: 0010:__check_object_size+0x3a2/0x4f0 mm/usercopy.c:264
> RSP: 0018:8801cece7940 EFLAGS: 00010282
> RAX: 0061 RBX: 85328d40 RCX: 
> RDX: 0061 RSI: c90003cae000 RDI: ed0039d9cf1c
> RBP: 8801cece7a30 R08: 8801cece71a8 R09: 
> R10: 712bcb5c R11:  R12: 85328d00
> R13: 8801cb8936d0 R14: 03c0 R15: ea00072e2480
> FS:  7f8422fd6700() GS:8801db40() knlGS:
> CS:  0010 DS:  ES:  CR0: 80050033
> CR2: 558e50e10460 CR3: 00019cd91000 CR4: 001406f0
> DR0:  DR1:  DR2: 
> DR3:  DR6: fffe0ff0 DR7: 0400
> Call Trace:
>  check_object_size include/linux/thread_info.h:112 [inline]
>  check_copy_size include/linux/thread_info.h:143 [inline]
>  copy_from_user include/linux/uaccess.h:146 [inline]
>  ___sys_sendmsg+0x58f/0x8a0 net/socket.c:2003
>  __sys_sendmmsg+0x1e6/0x5f0 net/socket.c:2116
>  SYSC_sendmmsg net/socket.c:2147 [inline]
>  SyS_sendmmsg+0x35/0x60 net/socket.c:2142
>  entry_SYSCALL_64_fastpath+0x1f/0x96
> RIP: 0033:0x452a39
> RSP: 002b:7f8422fd5c58 EFLAGS: 0212 ORIG_RAX: 0133
> RAX: ffda RBX: 7f8422fd6700 RCX: 00452a39
> RDX: 0006 RSI: 2077ce98 RDI: 0015
> RBP:  R08:  R09: 
> R10:  R11: 0212 R12: 
> R13: 00a6f7ff R14: 7f8422fd69c0 R15: 
> Code: 48 0f 44 da e8 e0 6e c2 ff 48 8b 85 28 ff ff ff 4d 89 f1 4c 89 e9 4c
> 89 e2 48 89 de 48 c7 c7 00 8e 32 85 49 89 c0 e8 e6 2c ac ff <0f> 0b 48 c7 c0
> c0 8b 32 85 eb 96 48 c7 c0 00 8c 32 85 eb 8d 48
> RIP: report_usercopy mm/usercopy.c:64 [inline] RSP: 8801cece7940
> RIP: __check_object_size+0x3a2/0x4f0 mm/usercopy.c:264 RSP: 8801cece7940
> ---[ end trace 22ce313ea80c715c ]---
> Kernel panic - not syncing: Fatal exception
> Dumping ftrace buffer:
>(ftrace buffer empty)
> Kernel Offset: disabled
> Rebooting in 86400 seconds..
>
>
> ---
> This bug is generated by a dumb bot. It may contain errors.
> See https://goo.gl/tpsmEJ for details.
> Direct all questions to syzkal...@googlegroups.com.
> Please credit me with: Reported-by: syzbot 
>
> syzbot will keep track of this bug report.
> Once a fix for this bug is merged into any tree, reply to this email with:
> #syz fix: exact-commit-title
> To mark this as a duplicate of another syzbot report, please reply with:
> #syz dup: exact-subject-of-another-report
> If it's a one-off invalid bug report, please reply with:
> #syz invalid
> Note: if the crash happens again, it will cause creation of a new bug
> report.
> Note: all commands must start from beginning of the line in the email body.



-- 
Kees Cook
Pixel Security

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Linus Torvalds]

On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar  wrote:
>
> These are the x86-64 low level entry code preparatory patches for the page 
> table
> isolation patches - which are required for PTI, which addresses KASLR and 
> similar
> information leaks.

Ugh.

Ok, I've read through this, and while I like most of it (I do like the
percpu syscall stack), I have this urge to wait until after rc4. With
the suspend/resume issues, we've had a horrible track record for 4.15
rc's so far, I'l like to not pull another low-level x86 change just
before an rc release and potentially make it four for four broken
rc's.

And I absolutely detest how that cherry-pick branch was done. I can
see why, but:

 - now we have those extra cherry-picks that I already have

 - and the merge commit isn't even a no-op!

Dammit, if the point was to have a branch that worked for 4.14, I can
see that. But look at that merge (on the "other side"), and notice how
the end result is *not* identical to the parent.

IOW, that

  9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
up cherry-picked base tree and preparatory patches

was supposed to be a synchronization point, but if you do

git diff 9a818d1a3235..9a818d1a3235^

it isn't actually synchronized. It's *almost* synchronized, but not
quite. How did those cherry-picks that were already upstream end up
causing *changes* upstream? That's odd.

So there are some technical oddities in there.

I'll read through it tomorrow again.. Maybe I'll change my mind.

   Linus

Re: [RFC GIT PULL] x86 Page Table Isolation (PTI) syscall entry code preparatory patches

[Linus Torvalds]

On Fri, Dec 15, 2017 at 5:58 PM, Ingo Molnar  wrote:
>
> These are the x86-64 low level entry code preparatory patches for the page 
> table
> isolation patches - which are required for PTI, which addresses KASLR and 
> similar
> information leaks.

Ugh.

Ok, I've read through this, and while I like most of it (I do like the
percpu syscall stack), I have this urge to wait until after rc4. With
the suspend/resume issues, we've had a horrible track record for 4.15
rc's so far, I'l like to not pull another low-level x86 change just
before an rc release and potentially make it four for four broken
rc's.

And I absolutely detest how that cherry-pick branch was done. I can
see why, but:

 - now we have those extra cherry-picks that I already have

 - and the merge commit isn't even a no-op!

Dammit, if the point was to have a branch that worked for 4.14, I can
see that. But look at that merge (on the "other side"), and notice how
the end result is *not* identical to the parent.

IOW, that

  9a818d1a3235 Merge branch 'WIP.x86/pti.base' into x86/pti, to pick
up cherry-picked base tree and preparatory patches

was supposed to be a synchronization point, but if you do

git diff 9a818d1a3235..9a818d1a3235^

it isn't actually synchronized. It's *almost* synchronized, but not
quite. How did those cherry-picks that were already upstream end up
causing *changes* upstream? That's odd.

So there are some technical oddities in there.

I'll read through it tomorrow again.. Maybe I'll change my mind.

   Linus

Re: [PATCH] divers/soc/ti: fix max dup length for kstrndup

[santosh.shilim...@oracle.com]

On 12/12/17 1:29 AM, Ma Shimiao wrote:

If source string longer than max, kstrndup will alloc max+1 space.
So, we should make sure the result will not over limit.

Signed-off-by: Ma Shimiao 
---

Applied. Thanks !!

Re: [PATCH] divers/soc/ti: fix max dup length for kstrndup

[santosh.shilim...@oracle.com]

On 12/12/17 1:29 AM, Ma Shimiao wrote:

If source string longer than max, kstrndup will alloc max+1 space.
So, we should make sure the result will not over limit.

Signed-off-by: Ma Shimiao 
---

Applied. Thanks !!

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> So from all tests and discussion I would propose new unification:
> 
> 1. Read label only from the root directory. If label in root directory
>is missing then disk would be treated as without label. Label from
>boot sector would not be read.
> 
>--> Reason: Windows XP and mlabel ignores what is written in boot
>sector. Windows XP even do not update boot sector, so label
>stored in boot sector is incorrect after any change done by
>Windows XP.
> 
>This logic is used by all tested MS-DOS and Windows versions,
>plus also by mtools on Linux.
> 
> 2. Write label to to both location, boot sector and root directory.
> 
>--> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
>Linux do this. This is also what is written in FAT specification.
> 
>It also provides backward compatibility with old dosfslabel
>versions which read label only from boot sector.
> 
> 2. Process 'NO NAME' label in root directory as 'NO NAME' name. Not
>as empty label.
> 
>--> Reason: 'NO NAME' is regular entry in root directory and both
>Windows XP and mlabel handle it in this way.
> 
> 3. Process 'NO NAME' label in boot directory as empty label. Not as
>label with name 'NO NAME'.
> 
>--> Reason: On Windows XP when formatting empty disk and label is not
>specified then 'NO NAME' is stored to boot sector.
> 
>Also in FAT specification is written that empty label is stored
>as 'NO NAME'.
> 
> With this change we would get compatibility with MS-DOS, Windows (both
> DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> code page.
> 
> There are just two negatives:
> 
> 1) Labels set by old dosfslabel versions (which stored them only to boot
>sector) would not be visible. But they are already not visible on
>MS-DOS or Windows machines, and also via mlabel (from mtools).
> 
> 2) Behavior of blkid and fatlabel would be changed as both tools have
>different as proposed above, and based on tests they also differ each
>from other.
> 
> Andreas, Karel, what do you think about it?

Andreas, any comments? It is OK?

More then month passed... and I would like to move forward.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: Linux & FAT32 label

[Pali Rohár]

On Thursday 09 November 2017 22:21:31 Pali Rohár wrote:
> So from all tests and discussion I would propose new unification:
> 
> 1. Read label only from the root directory. If label in root directory
>is missing then disk would be treated as without label. Label from
>boot sector would not be read.
> 
>--> Reason: Windows XP and mlabel ignores what is written in boot
>sector. Windows XP even do not update boot sector, so label
>stored in boot sector is incorrect after any change done by
>Windows XP.
> 
>This logic is used by all tested MS-DOS and Windows versions,
>plus also by mtools on Linux.
> 
> 2. Write label to to both location, boot sector and root directory.
> 
>--> Reason: MS-DOS 6.22, MS-DOS 7.10, Windows 98 and also mtools on
>Linux do this. This is also what is written in FAT specification.
> 
>It also provides backward compatibility with old dosfslabel
>versions which read label only from boot sector.
> 
> 2. Process 'NO NAME' label in root directory as 'NO NAME' name. Not
>as empty label.
> 
>--> Reason: 'NO NAME' is regular entry in root directory and both
>Windows XP and mlabel handle it in this way.
> 
> 3. Process 'NO NAME' label in boot directory as empty label. Not as
>label with name 'NO NAME'.
> 
>--> Reason: On Windows XP when formatting empty disk and label is not
>specified then 'NO NAME' is stored to boot sector.
> 
>Also in FAT specification is written that empty label is stored
>as 'NO NAME'.
> 
> With this change we would get compatibility with MS-DOS, Windows (both
> DOS-based and NT-based) and also with Linux mtools, modulo problems DOS
> code page.
> 
> There are just two negatives:
> 
> 1) Labels set by old dosfslabel versions (which stored them only to boot
>sector) would not be visible. But they are already not visible on
>MS-DOS or Windows machines, and also via mlabel (from mtools).
> 
> 2) Behavior of blkid and fatlabel would be changed as both tools have
>different as proposed above, and based on tests they also differ each
>from other.
> 
> Andreas, Karel, what do you think about it?

Andreas, any comments? It is OK?

More then month passed... and I would like to move forward.

-- 
Pali Rohár
pali.ro...@gmail.com

Re: [PATCH V2 0/8] ARM: dts: keystone*: Stage 1 cleanup for W=1

[santosh.shilim...@oracle.com]

On 12/16/17 12:40 PM, Nishanth Menon wrote:

Hi,
The following changes have been done in the updated series:
* Updates for couple few typo errors in commit messages
* copyrights are now always behind description
* rebased to maintainer branch (was previously against master)

Rebased to:
  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
  for_4.16/keystone-dts : 7fbec17465fc ARM: dts: k2g-evm: Enable UART 2


Thanks Nishant. Applied and should show up in next soon.

Regards,
Santosh

Re: [PATCH V2 0/8] ARM: dts: keystone*: Stage 1 cleanup for W=1

[santosh.shilim...@oracle.com]

On 12/16/17 12:40 PM, Nishanth Menon wrote:

Hi,
The following changes have been done in the updated series:
* Updates for couple few typo errors in commit messages
* copyrights are now always behind description
* rebased to maintainer branch (was previously against master)

Rebased to:
  git://git.kernel.org/pub/scm/linux/kernel/git/ssantosh/linux-keystone.git
  for_4.16/keystone-dts : 7fbec17465fc ARM: dts: k2g-evm: Enable UART 2


Thanks Nishant. Applied and should show up in next soon.

Regards,
Santosh

Re: [PATCH] firmware: ti_sci: Use %zu for size_t print format

[santosh.shilim...@oracle.com]

On 12/2/17 2:20 AM, Nishanth Menon wrote:

mbox_msg->len is of type size_t and %d is incorrect format. Instead
use %zu for handling size_t correctly.

Signed-off-by: Nishanth Menon 
---

Applied to 'for_4.16/drivers-soc' with Lokesh's ack.

Re: [PATCH] firmware: ti_sci: Use %zu for size_t print format

[santosh.shilim...@oracle.com]

On 12/2/17 2:20 AM, Nishanth Menon wrote:

mbox_msg->len is of type size_t and %d is incorrect format. Instead
use %zu for handling size_t correctly.

Signed-off-by: Nishanth Menon 
---

Applied to 'for_4.16/drivers-soc' with Lokesh's ack.

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

[Dave Chinner]

On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> From: Jeff Layton 
> 
> Add a documentation blob that explains what the i_version field is, how
> it is expected to work, and how it is currently implemented by various
> filesystems.
> 
> We already have inode_inc_iversion. Add several other functions for
> manipulating and accessing the i_version counter. For now, the
> implementation is trivial and basically works the way that all of the
> open-coded i_version accesses work today.
> 
> Future patches will convert existing users of i_version to use the new
> API, and then convert the backend implementation to do things more
> efficiently.
> 
> Signed-off-by: Jeff Layton 
> ---
>  include/linux/fs.h | 200 
> ++---
>  1 file changed, 192 insertions(+), 8 deletions(-)

Just a random sunday morning coffee musing

I was just wondering if it would be better to split this stuff out
into it's own header file now? include/linux/fs.h is aleady a
massive header file (~3500 lines) and changes cause tree-wide
rebuilds, so maybe it would be better to split relatively isolated
functionality like this out while it's being reworked and you're
already touching every file that uses it?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

Re: [PATCH v2 01/19] fs: new API for handling inode->i_version

[Dave Chinner]

On Sat, Dec 16, 2017 at 08:46:38AM -0500, Jeff Layton wrote:
> From: Jeff Layton 
> 
> Add a documentation blob that explains what the i_version field is, how
> it is expected to work, and how it is currently implemented by various
> filesystems.
> 
> We already have inode_inc_iversion. Add several other functions for
> manipulating and accessing the i_version counter. For now, the
> implementation is trivial and basically works the way that all of the
> open-coded i_version accesses work today.
> 
> Future patches will convert existing users of i_version to use the new
> API, and then convert the backend implementation to do things more
> efficiently.
> 
> Signed-off-by: Jeff Layton 
> ---
>  include/linux/fs.h | 200 
> ++---
>  1 file changed, 192 insertions(+), 8 deletions(-)

Just a random sunday morning coffee musing

I was just wondering if it would be better to split this stuff out
into it's own header file now? include/linux/fs.h is aleady a
massive header file (~3500 lines) and changes cause tree-wide
rebuilds, so maybe it would be better to split relatively isolated
functionality like this out while it's being reworked and you're
already touching every file that uses it?

Cheers,

Dave.
-- 
Dave Chinner
da...@fromorbit.com

[BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"

[Yang Shi]

Hi folks,

I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. 
But, I ran into the below compile error with 4.15-rc3 kernel:


In file included from ./include/uapi/linux/uuid.h:21:0,
 from ./include/linux/uuid.h:19,
 from ./include/linux/mod_devicetable.h:12,
 from scripts/mod/devicetable-offsets.c:2:
./include/linux/string.h:8:20: fatal error: stdarg.h: No such file or 
directory

 #include 

I bisected to commit 3298b690b21cdbe6b2ae8076d9147027f396f2b1 ("kbuild: 
Add a cache for generated variables"). Once I revert this commit, kernel 
build is fine.


gcc 4.8.5 is fine to build kernel with this commit.

I'm not quite sure if this is a bug or my gcc install is skewed although 
it can build kernel without that commit since that commit might 
exacerbate the case.


Any hint is appreciated

Regards,
Yang

[BUG] Build error for 4.15-rc3 kernel caused by patch "kbuild: Add a cache for generated variables"

[Yang Shi]

Hi folks,

I just upgraded gcc to 6.4 on my centos 7 machine by Arnd's suggestion. 
But, I ran into the below compile error with 4.15-rc3 kernel:


In file included from ./include/uapi/linux/uuid.h:21:0,
 from ./include/linux/uuid.h:19,
 from ./include/linux/mod_devicetable.h:12,
 from scripts/mod/devicetable-offsets.c:2:
./include/linux/string.h:8:20: fatal error: stdarg.h: No such file or 
directory

 #include 

I bisected to commit 3298b690b21cdbe6b2ae8076d9147027f396f2b1 ("kbuild: 
Add a cache for generated variables"). Once I revert this commit, kernel 
build is fine.


gcc 4.8.5 is fine to build kernel with this commit.

I'm not quite sure if this is a bug or my gcc install is skewed although 
it can build kernel without that commit since that commit might 
exacerbate the case.


Any hint is appreciated

Regards,
Yang

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

[Balbir Singh]

On Sun, Dec 17, 2017 at 8:34 AM, Rob Landley  wrote:
> I just added a ppc64 target to https://github.com/landley/mkroot which
> means I built 4.14 with the attached miniconfig and ran it with the
> attached qemu command line, and it works fine as is but if you remove
> the transactional mem line from the config the kernel panics instead
> of launching a shell prompt:
>
> init[1]: unhandled signal 4 at 10001a04 nip 10001a04
> lr 1002ebe8 code 1
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004
>

what does the instruction at 10001a04 look like?

Balbir Singh.

Re: powerpc64 kernel panic if you disable CONFIG_PPC_TRANSACTIONAL_MEM?

[Balbir Singh]

On Sun, Dec 17, 2017 at 8:34 AM, Rob Landley  wrote:
> I just added a ppc64 target to https://github.com/landley/mkroot which
> means I built 4.14 with the attached miniconfig and ran it with the
> attached qemu command line, and it works fine as is but if you remove
> the transactional mem line from the config the kernel panics instead
> of launching a shell prompt:
>
> init[1]: unhandled signal 4 at 10001a04 nip 10001a04
> lr 1002ebe8 code 1
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0004
>

what does the instruction at 10001a04 look like?

Balbir Singh.

Re: [PATCH] mm: thp: avoid uninitialized variable use

[Yang Shi]

On 12/16/17 4:24 AM, Arnd Bergmann wrote:

On Fri, Dec 15, 2017 at 7:01 PM, Yang Shi  wrote:



On 12/15/17 4:51 AM, Arnd Bergmann wrote:


When the down_read_trylock() fails, 'vma' has not been initialized
yet, which gcc now warns about:

mm/khugepaged.c: In function 'khugepaged':
mm/khugepaged.c:1659:25: error: 'vma' may be used uninitialized in this
function [-Werror=maybe-uninitialized]



Arnd,

Thanks for catching this. I'm wondering why my test didn't catch it. It
might be because my gcc is old. I'm using gcc 4.8.5 on centos 7.


Correct, gcc-4.8 and earlier have too many false-positive warnings with
-Wmaybe-uninitialized, so we turn it off on those versions. 4.9 is much
better here, but I'd recommend using gcc-6 or gcc-7 when you upgrade,
they have a much better set of default warnings besides producing better
binary code.


Thanks, I just upgraded gcc to 6.4 on my cetnos 7 machine. But, I ran 
into a build error with 4.15-rc3 kernel, but 4.14 is fine. I bisected to 
a commit in Makefile. I will email my bug report to the mailing list.


Regards,
Yang



See http://git.infradead.org/users/segher/buildall.git for a simple way
to build toolchains suitable for building kernels in varying architectures
and versions.

Arnd

Re: [PATCH] mm: thp: avoid uninitialized variable use

[Yang Shi]

On 12/16/17 4:24 AM, Arnd Bergmann wrote:

On Fri, Dec 15, 2017 at 7:01 PM, Yang Shi  wrote:



On 12/15/17 4:51 AM, Arnd Bergmann wrote:


When the down_read_trylock() fails, 'vma' has not been initialized
yet, which gcc now warns about:

mm/khugepaged.c: In function 'khugepaged':
mm/khugepaged.c:1659:25: error: 'vma' may be used uninitialized in this
function [-Werror=maybe-uninitialized]



Arnd,

Thanks for catching this. I'm wondering why my test didn't catch it. It
might be because my gcc is old. I'm using gcc 4.8.5 on centos 7.


Correct, gcc-4.8 and earlier have too many false-positive warnings with
-Wmaybe-uninitialized, so we turn it off on those versions. 4.9 is much
better here, but I'd recommend using gcc-6 or gcc-7 when you upgrade,
they have a much better set of default warnings besides producing better
binary code.


Thanks, I just upgraded gcc to 6.4 on my cetnos 7 machine. But, I ran 
into a build error with 4.15-rc3 kernel, but 4.14 is fine. I bisected to 
a commit in Makefile. I will email my bug report to the mailing list.


Regards,
Yang



See http://git.infradead.org/users/segher/buildall.git for a simple way
to build toolchains suitable for building kernels in varying architectures
and versions.

Arnd