Re: Some questions about the spi mem framework

[Xiangsheng Hou]

Hi Boris,

On Thu, 2018-05-17 at 09:42 +0200, Boris Brezillon wrote:
> On Thu, 17 May 2018 15:35:04 +0800
> Xiangsheng Hou  wrote:
> 
> > On Thu, 2018-05-17 at 09:13 +0200, Boris Brezillon wrote:
> > > On Thu, 17 May 2018 14:58:24 +0800
> > > Xiangsheng Hou  wrote:
> > >   
> > > > Hi Boris,
> > > > 
> > > > On Wed, 2018-05-16 at 14:42 +0200, Boris Brezillon wrote:  
> > > > > On Wed, 16 May 2018 20:11:39 +0800
> > > > > Xiangsheng Hou  wrote:
> > > > > 
> > > > > > Hi Boris,
> > > > > > 
> > > > > > On Tue, 2018-05-15 at 17:25 +0200, Boris Brezillon wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Tue, 15 May 2018 11:43:20 +0800
> > > > > > > Xiangsheng Hou  wrote:
> > > > > > >   
> > > > > > > > Hello Boris,
> > > > > > > > 
> > > > > > > > I have seen you are working on extend the framework to 
> > > > > > > > generically
> > > > > > > > support spi memory devices.
> > > > > > > > And, I am working on upstream SPI Nand driver of Mediatek SPI 
> > > > > > > > NAND
> > > > > > > > controller based on your branch[1].  
> > > > > > > 
> > > > > > > Great!
> > > > > > >   
> > > > > > > > I have some questions need your comment.
> > > > > > > > 
> > > > > > > > 1) There is a difference between different SPI NAND Flash when 
> > > > > > > > using the
> > > > > > > > Quad SPI command,for example Macronix,Etron and GigaDevice, 
> > > > > > > > Quad SPI commands require the Quad Enable bit in Status 
> > > > > > > > Register(B0H) to
> > > > > > > > be set.
> > > > > > > > However, current spi-mem framework does not have this operation,
> > > > > > > > do you have a plan to support it?  
> > > > > > > 
> > > > > > > I added support for the QE bit in the v7 I sent just a few 
> > > > > > > minutes ago
> > > > > > > [1].  
> > > > > > 
> > > > > > Ok,I have studied v7.
> > > > > > 
> > > > > > >   
> > > > > > > > 
> > > > > > > > 2) I see that current spi-mem framework doesn't support ECC,
> > > > > > > > But we need ECC, and we use Mediatek controller's HW ECC
> > > > > > > > instead of spi nand on-chip ECC,
> > > > > > > > maybe other companies also have this behavior,
> > > > > > > > So the ECC part must be implemented in controller's driver.
> > > > > > > > Will you abstract ECC interface in future?   
> > > > > > > 
> > > > > > > Well, I added support for on-die ECC in my v7 since all chips 
> > > > > > > seem to
> > > > > > > provide this feature. I was initially planning on abstracting ECC
> > > > > > > engines, but I decided to go for a simpler approach and only 
> > > > > > > support
> > > > > > > on-die ECC. That does not mean we shouldn't work on this "ECC 
> > > > > > > engine
> > > > > > > abstraction", just that I wanted to get something out and didn't 
> > > > > > > have
> > > > > > > time to spend on this topic.
> > > > > > > 
> > > > > > > I'd be happy if someone else could work on that aspect though. 
> > > > > > > BTW, do
> > > > > > > you plan to use this engine [2], or is this yet another ECC 
> > > > > > > engine?  
> > > > > > 
> > > > > > Yes,I plan to use this ecc engine[2].
> > > > > 
> > > > > Cool. That probably means we'll have to move the driver one level up
> > > > > (in drivers/mtd/nand) and work on this ECC engine interface I was
> > > > > talking about.
> > > > >  
> > > > > > > > 3) You know, some nand controller need configure their 
> > > > > > > > registers when
> > > > > > > > getting some information(page size, spare size) of nand flash,
> > > > > > > > But the spi-mem framework doesn't has an interface for scanning 
> > > > > > > > NAND
> > > > > > > > flash, when controller driver initialization.  
> > > > > > > 
> > > > > > > You seem to mix 2 different things:
> > > > > > > - spi-mem: this is generic interface provided by the SPI 
> > > > > > > framework to
> > > > > > >   send spi_mem_op. There's nothing NOR or NAND specific in there, 
> > > > > > > and
> > > > > > >   I'd like it to stay like that as much as possible
> > > > > > > - spinand: this the spi-mem driver that is dealing with SPI NAND
> > > > > > >   devices, and this is where all the code related to SPI NAND 
> > > > > > > support
> > > > > > >   should end up.
> > > > > > > 
> > > > > > > Can you tell me exactly why your SPI controller needs such a 
> > > > > > > detailed
> > > > > > > description? Is it able to program/read pages or erase blocks on 
> > > > > > > its
> > > > > > > own? Do you have a spec of this controller publicly available?
> > > > > > >   
> > > > > > 
> > > > > > For Mediatek SPI Nand controller,I have to configure registers for 
> > > > > > ECC
> > > > > > engine,page format and spare format according to nand information 
> > > > > > just
> > > > > > like[3] in mtk_nfc_hw_runtime_config() function.
> > > > > 
> > > > > So it's all related to the NAND controller, nothing specific to the 
> > > > > 

Re: Some questions about the spi mem framework

[Xiangsheng Hou]

Hi Boris,

On Thu, 2018-05-17 at 09:42 +0200, Boris Brezillon wrote:
> On Thu, 17 May 2018 15:35:04 +0800
> Xiangsheng Hou  wrote:
> 
> > On Thu, 2018-05-17 at 09:13 +0200, Boris Brezillon wrote:
> > > On Thu, 17 May 2018 14:58:24 +0800
> > > Xiangsheng Hou  wrote:
> > >   
> > > > Hi Boris,
> > > > 
> > > > On Wed, 2018-05-16 at 14:42 +0200, Boris Brezillon wrote:  
> > > > > On Wed, 16 May 2018 20:11:39 +0800
> > > > > Xiangsheng Hou  wrote:
> > > > > 
> > > > > > Hi Boris,
> > > > > > 
> > > > > > On Tue, 2018-05-15 at 17:25 +0200, Boris Brezillon wrote:
> > > > > > > Hi,
> > > > > > > 
> > > > > > > On Tue, 15 May 2018 11:43:20 +0800
> > > > > > > Xiangsheng Hou  wrote:
> > > > > > >   
> > > > > > > > Hello Boris,
> > > > > > > > 
> > > > > > > > I have seen you are working on extend the framework to 
> > > > > > > > generically
> > > > > > > > support spi memory devices.
> > > > > > > > And, I am working on upstream SPI Nand driver of Mediatek SPI 
> > > > > > > > NAND
> > > > > > > > controller based on your branch[1].  
> > > > > > > 
> > > > > > > Great!
> > > > > > >   
> > > > > > > > I have some questions need your comment.
> > > > > > > > 
> > > > > > > > 1) There is a difference between different SPI NAND Flash when 
> > > > > > > > using the
> > > > > > > > Quad SPI command,for example Macronix,Etron and GigaDevice, 
> > > > > > > > Quad SPI commands require the Quad Enable bit in Status 
> > > > > > > > Register(B0H) to
> > > > > > > > be set.
> > > > > > > > However, current spi-mem framework does not have this operation,
> > > > > > > > do you have a plan to support it?  
> > > > > > > 
> > > > > > > I added support for the QE bit in the v7 I sent just a few 
> > > > > > > minutes ago
> > > > > > > [1].  
> > > > > > 
> > > > > > Ok,I have studied v7.
> > > > > > 
> > > > > > >   
> > > > > > > > 
> > > > > > > > 2) I see that current spi-mem framework doesn't support ECC,
> > > > > > > > But we need ECC, and we use Mediatek controller's HW ECC
> > > > > > > > instead of spi nand on-chip ECC,
> > > > > > > > maybe other companies also have this behavior,
> > > > > > > > So the ECC part must be implemented in controller's driver.
> > > > > > > > Will you abstract ECC interface in future?   
> > > > > > > 
> > > > > > > Well, I added support for on-die ECC in my v7 since all chips 
> > > > > > > seem to
> > > > > > > provide this feature. I was initially planning on abstracting ECC
> > > > > > > engines, but I decided to go for a simpler approach and only 
> > > > > > > support
> > > > > > > on-die ECC. That does not mean we shouldn't work on this "ECC 
> > > > > > > engine
> > > > > > > abstraction", just that I wanted to get something out and didn't 
> > > > > > > have
> > > > > > > time to spend on this topic.
> > > > > > > 
> > > > > > > I'd be happy if someone else could work on that aspect though. 
> > > > > > > BTW, do
> > > > > > > you plan to use this engine [2], or is this yet another ECC 
> > > > > > > engine?  
> > > > > > 
> > > > > > Yes,I plan to use this ecc engine[2].
> > > > > 
> > > > > Cool. That probably means we'll have to move the driver one level up
> > > > > (in drivers/mtd/nand) and work on this ECC engine interface I was
> > > > > talking about.
> > > > >  
> > > > > > > > 3) You know, some nand controller need configure their 
> > > > > > > > registers when
> > > > > > > > getting some information(page size, spare size) of nand flash,
> > > > > > > > But the spi-mem framework doesn't has an interface for scanning 
> > > > > > > > NAND
> > > > > > > > flash, when controller driver initialization.  
> > > > > > > 
> > > > > > > You seem to mix 2 different things:
> > > > > > > - spi-mem: this is generic interface provided by the SPI 
> > > > > > > framework to
> > > > > > >   send spi_mem_op. There's nothing NOR or NAND specific in there, 
> > > > > > > and
> > > > > > >   I'd like it to stay like that as much as possible
> > > > > > > - spinand: this the spi-mem driver that is dealing with SPI NAND
> > > > > > >   devices, and this is where all the code related to SPI NAND 
> > > > > > > support
> > > > > > >   should end up.
> > > > > > > 
> > > > > > > Can you tell me exactly why your SPI controller needs such a 
> > > > > > > detailed
> > > > > > > description? Is it able to program/read pages or erase blocks on 
> > > > > > > its
> > > > > > > own? Do you have a spec of this controller publicly available?
> > > > > > >   
> > > > > > 
> > > > > > For Mediatek SPI Nand controller,I have to configure registers for 
> > > > > > ECC
> > > > > > engine,page format and spare format according to nand information 
> > > > > > just
> > > > > > like[3] in mtk_nfc_hw_runtime_config() function.
> > > > > 
> > > > > So it's all related to the NAND controller, nothing specific to the 
> > > > > SPI
> > > > > controller, right?
> > > > 
> > > > Yes,we use NAND controller rather than SPI controller.  
> > > 

Re: [PATCH] scripts/tags.sh: don't rely on parsing `ls` for $ALLSOURCE_ARCHS generation

[Masahiro Yamada]

2018-05-16 9:13 GMT+09:00 Joey Pabalinas :
> Parsing `ls` is fragile at best and _will_ fail when $tree
> contains spaces. Replace this with a glob-generated string
> and directly assign it to $ALLSOURCE_ARCHS; use a subshell
> so `cd` doesn't affect the current working directory.
>
> Signed-off-by: Joey Pabalinas 
>
>  1 file changed, 1 insertion(+), 4 deletions(-)


Andrew picked it up, but this patch is *bad*

You missed arch/Kconfig.

$(cd "${tree}arch/" && echo *)
contains Kconfig, but it is not arch.





> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index 78e546ff689c2d5f40..b84acf8889fe836c60 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -29,14 +29,11 @@ fi
>  ignore="$ignore ( -path ${tree}tools ) -prune -o"
>
>  # Find all available archs
>  find_all_archs()
>  {
> -   ALLSOURCE_ARCHS=""
> -   for arch in `ls ${tree}arch`; do
> -   ALLSOURCE_ARCHS="${ALLSOURCE_ARCHS} "${arch##\/}
> -   done
> +   ALLSOURCE_ARCHS="$( (cd "${tree}arch/" && echo *) )"
>  }
>
>  # Detect if ALLSOURCE_ARCHS is set. If not, we assume SRCARCH
>  if [ "${ALLSOURCE_ARCHS}" = "" ]; then
> ALLSOURCE_ARCHS=${SRCARCH}
> --
> 2.17.0.rc1.35.g90bbd502d54fe92035.dirty
>



-- 
Best Regards
Masahiro Yamada

Re: [PATCH] scripts/tags.sh: don't rely on parsing `ls` for $ALLSOURCE_ARCHS generation

[Masahiro Yamada]

2018-05-16 9:13 GMT+09:00 Joey Pabalinas :
> Parsing `ls` is fragile at best and _will_ fail when $tree
> contains spaces. Replace this with a glob-generated string
> and directly assign it to $ALLSOURCE_ARCHS; use a subshell
> so `cd` doesn't affect the current working directory.
>
> Signed-off-by: Joey Pabalinas 
>
>  1 file changed, 1 insertion(+), 4 deletions(-)


Andrew picked it up, but this patch is *bad*

You missed arch/Kconfig.

$(cd "${tree}arch/" && echo *)
contains Kconfig, but it is not arch.





> diff --git a/scripts/tags.sh b/scripts/tags.sh
> index 78e546ff689c2d5f40..b84acf8889fe836c60 100755
> --- a/scripts/tags.sh
> +++ b/scripts/tags.sh
> @@ -29,14 +29,11 @@ fi
>  ignore="$ignore ( -path ${tree}tools ) -prune -o"
>
>  # Find all available archs
>  find_all_archs()
>  {
> -   ALLSOURCE_ARCHS=""
> -   for arch in `ls ${tree}arch`; do
> -   ALLSOURCE_ARCHS="${ALLSOURCE_ARCHS} "${arch##\/}
> -   done
> +   ALLSOURCE_ARCHS="$( (cd "${tree}arch/" && echo *) )"
>  }
>
>  # Detect if ALLSOURCE_ARCHS is set. If not, we assume SRCARCH
>  if [ "${ALLSOURCE_ARCHS}" = "" ]; then
> ALLSOURCE_ARCHS=${SRCARCH}
> --
> 2.17.0.rc1.35.g90bbd502d54fe92035.dirty
>



-- 
Best Regards
Masahiro Yamada

Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

[Andrzej Hajda]

On 17.05.2018 18:06, kbuild test robot wrote:
> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
> Signed-off-by: kbuild test robot 

It should be static of course, my bad.

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

> ---
>  drd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index 2706824..218371f 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>  {
>   struct device *dev = dwc->dev;
>   struct device_node *np_phy, *np_conn;
>
>
>

Re: [RFC PATCH linux-next] USB: dwc3: dwc3_get_extcon() can be static

[Andrzej Hajda]

On 17.05.2018 18:06, kbuild test robot wrote:
> Fixes: 5f0b74e54890 ("USB: dwc3: get extcon device by OF graph bindings")
> Signed-off-by: kbuild test robot 

It should be static of course, my bad.

Reviewed-by: Andrzej Hajda 

 --
Regards
Andrzej

> ---
>  drd.c |2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/usb/dwc3/drd.c b/drivers/usb/dwc3/drd.c
> index 2706824..218371f 100644
> --- a/drivers/usb/dwc3/drd.c
> +++ b/drivers/usb/dwc3/drd.c
> @@ -440,7 +440,7 @@ static int dwc3_drd_notifier(struct notifier_block *nb,
>   return NOTIFY_DONE;
>  }
>  
> -struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
> +static struct extcon_dev *dwc3_get_extcon(struct dwc3 *dwc)
>  {
>   struct device *dev = dwc->dev;
>   struct device_node *np_phy, *np_conn;
>
>
>

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Y Song]

On Thu, May 17, 2018 at 2:45 PM, Sean Young  wrote:
> Hi,
>
> Again thanks for a thoughtful review. This will definitely will improve
> the code.
>
> On Thu, May 17, 2018 at 10:02:52AM -0700, Y Song wrote:
>> On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
>> > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
>> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
>> > that the last key should be repeated.
>> >
>> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
>> > the target_fd must be the /dev/lircN device.
>> >
>> > Signed-off-by: Sean Young 
>> > ---
>> >  drivers/media/rc/Kconfig   |  13 ++
>> >  drivers/media/rc/Makefile  |   1 +
>> >  drivers/media/rc/bpf-rawir-event.c | 363 +
>> >  drivers/media/rc/lirc_dev.c|  24 ++
>> >  drivers/media/rc/rc-core-priv.h|  24 ++
>> >  drivers/media/rc/rc-ir-raw.c   |  14 +-
>> >  include/linux/bpf_rcdev.h  |  30 +++
>> >  include/linux/bpf_types.h  |   3 +
>> >  include/uapi/linux/bpf.h   |  55 -
>> >  kernel/bpf/syscall.c   |   7 +
>> >  10 files changed, 531 insertions(+), 3 deletions(-)
>> >  create mode 100644 drivers/media/rc/bpf-rawir-event.c
>> >  create mode 100644 include/linux/bpf_rcdev.h
>> >
>> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
>> > index eb2c3b6eca7f..2172d65b0213 100644
>> > --- a/drivers/media/rc/Kconfig
>> > +++ b/drivers/media/rc/Kconfig
>> > @@ -25,6 +25,19 @@ config LIRC
>> >passes raw IR to and from userspace, which is needed for
>> >IR transmitting (aka "blasting") and for the lirc daemon.
>> >
>> > +config BPF_RAWIR_EVENT
>> > +   bool "Support for eBPF programs attached to lirc devices"
>> > +   depends on BPF_SYSCALL
>> > +   depends on RC_CORE=y
>> > +   depends on LIRC
>> > +   help
>> > +  Allow attaching eBPF programs to a lirc device using the bpf(2)
>> > +  syscall command BPF_PROG_ATTACH. This is supported for raw IR
>> > +  receivers.
>> > +
>> > +  These eBPF programs can be used to decode IR into scancodes, for
>> > +  IR protocols not supported by the kernel decoders.
>> > +
>> >  menuconfig RC_DECODERS
>> > bool "Remote controller decoders"
>> > depends on RC_CORE
>> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
>> > index 2e1c87066f6c..74907823bef8 100644
>> > --- a/drivers/media/rc/Makefile
>> > +++ b/drivers/media/rc/Makefile
>> > @@ -5,6 +5,7 @@ obj-y += keymaps/
>> >  obj-$(CONFIG_RC_CORE) += rc-core.o
>> >  rc-core-y := rc-main.o rc-ir-raw.o
>> >  rc-core-$(CONFIG_LIRC) += lirc_dev.o
>> > +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o
>> >  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
>> >  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
>> >  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
>> > diff --git a/drivers/media/rc/bpf-rawir-event.c 
>> > b/drivers/media/rc/bpf-rawir-event.c
>> > new file mode 100644
>> > index ..7cb48b8d87b5
>> > --- /dev/null
>> > +++ b/drivers/media/rc/bpf-rawir-event.c
>> > @@ -0,0 +1,363 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// bpf-rawir-event.c - handles bpf
>> > +//
>> > +// Copyright (C) 2018 Sean Young 
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "rc-core-priv.h"
>> > +
>> > +/*
>> > + * BPF interface for raw IR
>> > + */
>> > +const struct bpf_prog_ops rawir_event_prog_ops = {
>> > +};
>> > +
>> > +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_repeat(ctrl->dev);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_repeat_proto = {
>> > +   .func  = bpf_rc_repeat,
>> > +   .gpl_only  = true, /* rc_repeat is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +};
>> > +
>> > +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol,
>> > +  u32, scancode, u32, toggle)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_keydown_proto = {
>> > +   .func  = bpf_rc_keydown,
>> > +   .gpl_only  = true, /* rc_keydown is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +   .arg2_type = ARG_ANYTHING,
>> > +   .arg3_type = ARG_ANYTHING,
>> > +   .arg4_type = ARG_ANYTHING,
>> > +};
>> > +
>> > +static 

Re: [PATCH v3 1/2] media: rc: introduce BPF_PROG_RAWIR_EVENT

[Y Song]

On Thu, May 17, 2018 at 2:45 PM, Sean Young  wrote:
> Hi,
>
> Again thanks for a thoughtful review. This will definitely will improve
> the code.
>
> On Thu, May 17, 2018 at 10:02:52AM -0700, Y Song wrote:
>> On Wed, May 16, 2018 at 2:04 PM, Sean Young  wrote:
>> > Add support for BPF_PROG_RAWIR_EVENT. This type of BPF program can call
>> > rc_keydown() to reported decoded IR scancodes, or rc_repeat() to report
>> > that the last key should be repeated.
>> >
>> > The bpf program can be attached to using the bpf(BPF_PROG_ATTACH) syscall;
>> > the target_fd must be the /dev/lircN device.
>> >
>> > Signed-off-by: Sean Young 
>> > ---
>> >  drivers/media/rc/Kconfig   |  13 ++
>> >  drivers/media/rc/Makefile  |   1 +
>> >  drivers/media/rc/bpf-rawir-event.c | 363 +
>> >  drivers/media/rc/lirc_dev.c|  24 ++
>> >  drivers/media/rc/rc-core-priv.h|  24 ++
>> >  drivers/media/rc/rc-ir-raw.c   |  14 +-
>> >  include/linux/bpf_rcdev.h  |  30 +++
>> >  include/linux/bpf_types.h  |   3 +
>> >  include/uapi/linux/bpf.h   |  55 -
>> >  kernel/bpf/syscall.c   |   7 +
>> >  10 files changed, 531 insertions(+), 3 deletions(-)
>> >  create mode 100644 drivers/media/rc/bpf-rawir-event.c
>> >  create mode 100644 include/linux/bpf_rcdev.h
>> >
>> > diff --git a/drivers/media/rc/Kconfig b/drivers/media/rc/Kconfig
>> > index eb2c3b6eca7f..2172d65b0213 100644
>> > --- a/drivers/media/rc/Kconfig
>> > +++ b/drivers/media/rc/Kconfig
>> > @@ -25,6 +25,19 @@ config LIRC
>> >passes raw IR to and from userspace, which is needed for
>> >IR transmitting (aka "blasting") and for the lirc daemon.
>> >
>> > +config BPF_RAWIR_EVENT
>> > +   bool "Support for eBPF programs attached to lirc devices"
>> > +   depends on BPF_SYSCALL
>> > +   depends on RC_CORE=y
>> > +   depends on LIRC
>> > +   help
>> > +  Allow attaching eBPF programs to a lirc device using the bpf(2)
>> > +  syscall command BPF_PROG_ATTACH. This is supported for raw IR
>> > +  receivers.
>> > +
>> > +  These eBPF programs can be used to decode IR into scancodes, for
>> > +  IR protocols not supported by the kernel decoders.
>> > +
>> >  menuconfig RC_DECODERS
>> > bool "Remote controller decoders"
>> > depends on RC_CORE
>> > diff --git a/drivers/media/rc/Makefile b/drivers/media/rc/Makefile
>> > index 2e1c87066f6c..74907823bef8 100644
>> > --- a/drivers/media/rc/Makefile
>> > +++ b/drivers/media/rc/Makefile
>> > @@ -5,6 +5,7 @@ obj-y += keymaps/
>> >  obj-$(CONFIG_RC_CORE) += rc-core.o
>> >  rc-core-y := rc-main.o rc-ir-raw.o
>> >  rc-core-$(CONFIG_LIRC) += lirc_dev.o
>> > +rc-core-$(CONFIG_BPF_RAWIR_EVENT) += bpf-rawir-event.o
>> >  obj-$(CONFIG_IR_NEC_DECODER) += ir-nec-decoder.o
>> >  obj-$(CONFIG_IR_RC5_DECODER) += ir-rc5-decoder.o
>> >  obj-$(CONFIG_IR_RC6_DECODER) += ir-rc6-decoder.o
>> > diff --git a/drivers/media/rc/bpf-rawir-event.c 
>> > b/drivers/media/rc/bpf-rawir-event.c
>> > new file mode 100644
>> > index ..7cb48b8d87b5
>> > --- /dev/null
>> > +++ b/drivers/media/rc/bpf-rawir-event.c
>> > @@ -0,0 +1,363 @@
>> > +// SPDX-License-Identifier: GPL-2.0
>> > +// bpf-rawir-event.c - handles bpf
>> > +//
>> > +// Copyright (C) 2018 Sean Young 
>> > +
>> > +#include 
>> > +#include 
>> > +#include 
>> > +#include "rc-core-priv.h"
>> > +
>> > +/*
>> > + * BPF interface for raw IR
>> > + */
>> > +const struct bpf_prog_ops rawir_event_prog_ops = {
>> > +};
>> > +
>> > +BPF_CALL_1(bpf_rc_repeat, struct bpf_rawir_event*, event)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_repeat(ctrl->dev);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_repeat_proto = {
>> > +   .func  = bpf_rc_repeat,
>> > +   .gpl_only  = true, /* rc_repeat is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +};
>> > +
>> > +BPF_CALL_4(bpf_rc_keydown, struct bpf_rawir_event*, event, u32, protocol,
>> > +  u32, scancode, u32, toggle)
>> > +{
>> > +   struct ir_raw_event_ctrl *ctrl;
>> > +
>> > +   ctrl = container_of(event, struct ir_raw_event_ctrl, 
>> > bpf_rawir_event);
>> > +
>> > +   rc_keydown(ctrl->dev, protocol, scancode, toggle != 0);
>> > +
>> > +   return 0;
>> > +}
>> > +
>> > +static const struct bpf_func_proto rc_keydown_proto = {
>> > +   .func  = bpf_rc_keydown,
>> > +   .gpl_only  = true, /* rc_keydown is EXPORT_SYMBOL_GPL */
>> > +   .ret_type  = RET_INTEGER,
>> > +   .arg1_type = ARG_PTR_TO_CTX,
>> > +   .arg2_type = ARG_ANYTHING,
>> > +   .arg3_type = ARG_ANYTHING,
>> > +   .arg4_type = ARG_ANYTHING,
>> > +};
>> > +
>> > +static const struct bpf_func_proto *
>> > 

Re: [PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls

[Bjorn Andersson]

On Thu 17 May 04:32 PDT 2018, Vikash Garodia wrote:

> In order to invoke scm calls, ensure that the platform
> has the required support to invoke the scm calls in
> secure world.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/soc/qcom/mdt_loader.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 17b314d..db55d53 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct 
> firmware *fw,
>   if (!fw_name)
>   return -ENOMEM;
>  
> - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> - if (ret) {
> - dev_err(dev, "invalid firmware metadata\n");
> - goto out;
> + if (qcom_scm_is_available()) {

qcom_scm_is_available() tells you if the qcom_scm driver has been
probed, not if your platform implements PAS.

Please add a DT property to tell the driver if it should require PAS or
not (the absence of such property should indicate PAS is required, for
backwards compatibility purposes). For the MDT loader we need to merge
the following patch to make this work:

https://patchwork.kernel.org/patch/10397889/ 

Regards,
Bjorn

Re: [PATCH 1/4] soc: qcom: mdt_loader: Add check to make scm calls

[Bjorn Andersson]

On Thu 17 May 04:32 PDT 2018, Vikash Garodia wrote:

> In order to invoke scm calls, ensure that the platform
> has the required support to invoke the scm calls in
> secure world.
> 
> Signed-off-by: Vikash Garodia 
> ---
>  drivers/soc/qcom/mdt_loader.c | 21 +
>  1 file changed, 13 insertions(+), 8 deletions(-)
> 
> diff --git a/drivers/soc/qcom/mdt_loader.c b/drivers/soc/qcom/mdt_loader.c
> index 17b314d..db55d53 100644
> --- a/drivers/soc/qcom/mdt_loader.c
> +++ b/drivers/soc/qcom/mdt_loader.c
> @@ -121,10 +121,12 @@ int qcom_mdt_load(struct device *dev, const struct 
> firmware *fw,
>   if (!fw_name)
>   return -ENOMEM;
>  
> - ret = qcom_scm_pas_init_image(pas_id, fw->data, fw->size);
> - if (ret) {
> - dev_err(dev, "invalid firmware metadata\n");
> - goto out;
> + if (qcom_scm_is_available()) {

qcom_scm_is_available() tells you if the qcom_scm driver has been
probed, not if your platform implements PAS.

Please add a DT property to tell the driver if it should require PAS or
not (the absence of such property should indicate PAS is required, for
backwards compatibility purposes). For the MDT loader we need to merge
the following patch to make this work:

https://patchwork.kernel.org/patch/10397889/ 

Regards,
Bjorn

Re: [PATCH v2] ipc: Adding new return type vm_fault_t

[Davidlohr Bueso]

On Wed, 16 May 2018, Souptick Joarder wrote:


On Thu, May 10, 2018 at 7:34 PM, Souptick Joarder  wrote:

On Wed, Apr 25, 2018 at 10:04 AM, Souptick Joarder  wrote:

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

Commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 


Acked-by: Davidlohr Bueso 

Re: [PATCH v2] ipc: Adding new return type vm_fault_t

[Davidlohr Bueso]

On Wed, 16 May 2018, Souptick Joarder wrote:


On Thu, May 10, 2018 at 7:34 PM, Souptick Joarder  wrote:

On Wed, Apr 25, 2018 at 10:04 AM, Souptick Joarder  wrote:

Use new return type vm_fault_t for fault handler. For
now, this is just documenting that the function returns
a VM_FAULT value rather than an errno. Once all instances
are converted, vm_fault_t will become a distinct type.

Commit 1c8f422059ae ("mm: change return type to vm_fault_t")

Signed-off-by: Souptick Joarder 
Reviewed-by: Matthew Wilcox 


Acked-by: Davidlohr Bueso 

[PATCH] perf/x86/intel/uncore: allocate pmu index for pci device dynamically

[Eric Ren]

Some boxes/devices of uncore are exported as pcie devices. However,
the box number is different on different micro-architecture. For
example, the max memory channels for Broadwell is up to 8. However,
there are only 2 channels for Broadwell-DE, 4 channels for Broadwell-EP,
and 8 channels for Broadwell-EX.

The current code allocates pmu index statically so that on Broadwell-EP
machine "perf list|grep uncore" shows discontinuous iMC number, which
doesn't look nice:

Test on Broadwell-EP using "ls /sys/devices | grep -i imc":

Without this patch,
uncore_imc_0
uncore_imc_1
uncore_imc_4
uncore_imc_5

To maintain pmu index dynamically, move index allocation logic to
uncore_pci_probe(). As a result, we can get continuous index of iMC
devices under /sys/devices directory:

Applied this patch:,
uncore_imc_0
uncore_imc_1
uncore_imc_2
uncore_imc_3

Signed-off-by: Shanpei Chen 
Signed-off-by: Eric Ren 
---
 arch/x86/events/intel/uncore.c | 7 ++-
 arch/x86/events/intel/uncore.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index a7956fc..88d390e 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -818,7 +818,9 @@ static int __init uncore_type_init(struct intel_uncore_type 
*type, bool setid)
 
for (i = 0; i < type->num_boxes; i++) {
pmus[i].func_id = setid ? i : -1;
-   pmus[i].pmu_idx = i;
+   /* The pmu idx will be decided at probe for pci device. */
+   if (setid)
+   pmus[i].pmu_idx = i;
pmus[i].type= type;
pmus[i].boxes   = kzalloc(size, GFP_KERNEL);
if (!pmus[i].boxes)
@@ -957,6 +959,9 @@ static int uncore_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id
if (atomic_inc_return(>activeboxes) > 1)
return 0;
 
+   /*  Count the real number of pmus for pci uncore device */
+   pmu->pmu_idx = type->num_pmus++;
+
/* First active box registers the pmu */
ret = uncore_pmu_register(pmu);
if (ret) {
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index 414dc7e..c4f54fb 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -40,6 +40,7 @@ struct intel_uncore_type {
const char *name;
int num_counters;
int num_boxes;
+   int num_pmus; /* for pci uncore device */
int perf_ctr_bits;
int fixed_ctr_bits;
unsigned perf_ctr;
-- 
1.8.3.1

[PATCH] perf/x86/intel/uncore: allocate pmu index for pci device dynamically

[Eric Ren]

Some boxes/devices of uncore are exported as pcie devices. However,
the box number is different on different micro-architecture. For
example, the max memory channels for Broadwell is up to 8. However,
there are only 2 channels for Broadwell-DE, 4 channels for Broadwell-EP,
and 8 channels for Broadwell-EX.

The current code allocates pmu index statically so that on Broadwell-EP
machine "perf list|grep uncore" shows discontinuous iMC number, which
doesn't look nice:

Test on Broadwell-EP using "ls /sys/devices | grep -i imc":

Without this patch,
uncore_imc_0
uncore_imc_1
uncore_imc_4
uncore_imc_5

To maintain pmu index dynamically, move index allocation logic to
uncore_pci_probe(). As a result, we can get continuous index of iMC
devices under /sys/devices directory:

Applied this patch:,
uncore_imc_0
uncore_imc_1
uncore_imc_2
uncore_imc_3

Signed-off-by: Shanpei Chen 
Signed-off-by: Eric Ren 
---
 arch/x86/events/intel/uncore.c | 7 ++-
 arch/x86/events/intel/uncore.h | 1 +
 2 files changed, 7 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/intel/uncore.c b/arch/x86/events/intel/uncore.c
index a7956fc..88d390e 100644
--- a/arch/x86/events/intel/uncore.c
+++ b/arch/x86/events/intel/uncore.c
@@ -818,7 +818,9 @@ static int __init uncore_type_init(struct intel_uncore_type 
*type, bool setid)
 
for (i = 0; i < type->num_boxes; i++) {
pmus[i].func_id = setid ? i : -1;
-   pmus[i].pmu_idx = i;
+   /* The pmu idx will be decided at probe for pci device. */
+   if (setid)
+   pmus[i].pmu_idx = i;
pmus[i].type= type;
pmus[i].boxes   = kzalloc(size, GFP_KERNEL);
if (!pmus[i].boxes)
@@ -957,6 +959,9 @@ static int uncore_pci_probe(struct pci_dev *pdev, const 
struct pci_device_id *id
if (atomic_inc_return(>activeboxes) > 1)
return 0;
 
+   /*  Count the real number of pmus for pci uncore device */
+   pmu->pmu_idx = type->num_pmus++;
+
/* First active box registers the pmu */
ret = uncore_pmu_register(pmu);
if (ret) {
diff --git a/arch/x86/events/intel/uncore.h b/arch/x86/events/intel/uncore.h
index 414dc7e..c4f54fb 100644
--- a/arch/x86/events/intel/uncore.h
+++ b/arch/x86/events/intel/uncore.h
@@ -40,6 +40,7 @@ struct intel_uncore_type {
const char *name;
int num_counters;
int num_boxes;
+   int num_pmus; /* for pci uncore device */
int perf_ctr_bits;
int fixed_ctr_bits;
unsigned perf_ctr;
-- 
1.8.3.1

[RFC PATCH net-next] tcp: tcp_rack_reo_wnd() can be static

[kbuild test robot]

Fixes: 20b654dfe1be ("tcp: support DUPACK threshold in RACK")
Signed-off-by: kbuild test robot 
---
 tcp_recovery.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
index 30cbfb6..71593e4 100644
--- a/net/ipv4/tcp_recovery.c
+++ b/net/ipv4/tcp_recovery.c
@@ -21,7 +21,7 @@ static bool tcp_rack_sent_after(u64 t1, u64 t2, u32 seq1, u32 
seq2)
return t1 > t2 || (t1 == t2 && after(seq1, seq2));
 }
 
-u32 tcp_rack_reo_wnd(const struct sock *sk)
+static u32 tcp_rack_reo_wnd(const struct sock *sk)
 {
struct tcp_sock *tp = tcp_sk(sk);
 

[RFC PATCH net-next] tcp: tcp_rack_reo_wnd() can be static

[kbuild test robot]

Fixes: 20b654dfe1be ("tcp: support DUPACK threshold in RACK")
Signed-off-by: kbuild test robot 
---
 tcp_recovery.c |2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/net/ipv4/tcp_recovery.c b/net/ipv4/tcp_recovery.c
index 30cbfb6..71593e4 100644
--- a/net/ipv4/tcp_recovery.c
+++ b/net/ipv4/tcp_recovery.c
@@ -21,7 +21,7 @@ static bool tcp_rack_sent_after(u64 t1, u64 t2, u32 seq1, u32 
seq2)
return t1 > t2 || (t1 == t2 && after(seq1, seq2));
 }
 
-u32 tcp_rack_reo_wnd(const struct sock *sk)
+static u32 tcp_rack_reo_wnd(const struct sock *sk)
 {
struct tcp_sock *tp = tcp_sk(sk);
 

[net-next:master 1200/1233] net/ipv4/tcp_recovery.c:24:5: sparse: symbol 'tcp_rack_reo_wnd' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   538e2de104cfb4ef1acb35af42427bff42adbe4d
commit: 20b654dfe1beaca60ab51894ff405a049248433d [1200/1233] tcp: support 
DUPACK threshold in RACK
reproduce:
# apt-get install sparse
git checkout 20b654dfe1beaca60ab51894ff405a049248433d
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   net/ipv4/tcp_recovery.c:46:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:46:16: sparse: expression using sizeof(void)
>> net/ipv4/tcp_recovery.c:24:5: sparse: symbol 'tcp_rack_reo_wnd' was not 
>> declared. Should it be static?
   include/net/tcp.h:738:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:102:40: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:102:40: sparse: expression using sizeof(void)
   include/net/tcp.h:738:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:210:42: sparse: expression using sizeof(void)

Please review and possibly fold the followup patch.

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

[net-next:master 1200/1233] net/ipv4/tcp_recovery.c:24:5: sparse: symbol 'tcp_rack_reo_wnd' was not declared. Should it be static?

[kbuild test robot]

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git 
master
head:   538e2de104cfb4ef1acb35af42427bff42adbe4d
commit: 20b654dfe1beaca60ab51894ff405a049248433d [1200/1233] tcp: support 
DUPACK threshold in RACK
reproduce:
# apt-get install sparse
git checkout 20b654dfe1beaca60ab51894ff405a049248433d
make ARCH=x86_64 allmodconfig
make C=1 CF=-D__CHECK_ENDIAN__


sparse warnings: (new ones prefixed by >>)

   net/ipv4/tcp_recovery.c:46:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:46:16: sparse: expression using sizeof(void)
>> net/ipv4/tcp_recovery.c:24:5: sparse: symbol 'tcp_rack_reo_wnd' was not 
>> declared. Should it be static?
   include/net/tcp.h:738:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:102:40: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:102:40: sparse: expression using sizeof(void)
   include/net/tcp.h:738:16: sparse: expression using sizeof(void)
   net/ipv4/tcp_recovery.c:210:42: sparse: expression using sizeof(void)

Please review and possibly fold the followup patch.

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

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Masahiro Yamada]

Hi Randy,

2018-04-07 6:37 GMT+09:00 Randy Dunlap :
> On 03/14/2018 10:50 PM, Masahiro Yamada wrote:
>> 2018-03-13 11:30 GMT+09:00 Randy Dunlap :
>>> From: Randy Dunlap 
>>>
>>> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
>>> that other required files are present, but none of these check that
>>> pkg-config itself is present.  Add a check for all 4 of these targets.
>>>
>>> Fixes kernel bugzilla #77511:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>>>
>>> Signed-off-by: Randy Dunlap 
>>> ---
>>> v2: use 'command -v' instead of 'which'
>>>
>>> I'm also OK with just documenting the pkg-config requirement in
>>> Documentation/Changes (= Documentation/process/changes.rst).
>>>
>>>  scripts/kconfig/Makefile   |   15 ++-
>>>  scripts/kconfig/check-pkgconfig.sh |   12 
>>>  2 files changed, 26 insertions(+), 1 deletion(-)
>>>
>>> --- lnx-416-rc3.orig/scripts/kconfig/Makefile
>>> +++ lnx-416-rc3/scripts/kconfig/Makefile
>>> @@ -160,6 +160,9 @@ help:
>>> @echo  '  xenconfig   - Enable additional options for xen dom0 
>>> and guest kernel support'
>>> @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>>>
>>> +# pkg-config check
>>> +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
>>> +
>>>  # lxdialog stuff
>>>  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>>>
>>> @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
>>>  $(obj)/dochecklxdialog:
>>> $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
>>> $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
>>>
>>> -always := dochecklxdialog
>>> +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
>>> +PHONY += $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
>>> +
>>> +$(obj)/docheckpkgconfig:
>>> +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
>>> +
>>> +always := docheckpkgconfig dochecklxdialog
>>
>>
>> I did not test this patch, but does this check work as expected?
>>
>> Probably we want to run 'docheckpkgconfig'
>> before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
>> But, I do not see such dependencies.
>>
>>
>> Also, if we make 'pkg-config' mandatory,
>> should we entirely drop fall-back logics like follows?
>>
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230
>>
>>
>> What do you think?
>>
>
> Hi,
>
> I'm willing to keep patching/testing on this, but both pkg-config and depmod
> (for depmod, see: https://bugzilla.kernel.org/show_bug.cgi?id=198965)
> are basic requirements IMO, so just documenting their requirements is good
> enough to me, but might not be good enough for some users.
>
> Comments?

Sorry for late comments.

OK, I am fine with making pkg-config a requirement.
(and it should be documented)

But, I'd like to clean-up scripts/kconfig/Makefile first.
It is already cluttered, and hesitate to add new code based on that.
I posted the patches.

Could you send v3 after the cleaning work is done?

-- 
Best Regards
Masahiro Yamada

Re: [PATCH v2] kbuild: check for pkg-config on make {menu,n,g,x}config

[Masahiro Yamada]

Hi Randy,

2018-04-07 6:37 GMT+09:00 Randy Dunlap :
> On 03/14/2018 10:50 PM, Masahiro Yamada wrote:
>> 2018-03-13 11:30 GMT+09:00 Randy Dunlap :
>>> From: Randy Dunlap 
>>>
>>> Each of 'make {menu,n,g,x}config' uses (needs) pkg-config to make sure
>>> that other required files are present, but none of these check that
>>> pkg-config itself is present.  Add a check for all 4 of these targets.
>>>
>>> Fixes kernel bugzilla #77511:
>>> https://bugzilla.kernel.org/show_bug.cgi?id=77511
>>>
>>> Signed-off-by: Randy Dunlap 
>>> ---
>>> v2: use 'command -v' instead of 'which'
>>>
>>> I'm also OK with just documenting the pkg-config requirement in
>>> Documentation/Changes (= Documentation/process/changes.rst).
>>>
>>>  scripts/kconfig/Makefile   |   15 ++-
>>>  scripts/kconfig/check-pkgconfig.sh |   12 
>>>  2 files changed, 26 insertions(+), 1 deletion(-)
>>>
>>> --- lnx-416-rc3.orig/scripts/kconfig/Makefile
>>> +++ lnx-416-rc3/scripts/kconfig/Makefile
>>> @@ -160,6 +160,9 @@ help:
>>> @echo  '  xenconfig   - Enable additional options for xen dom0 
>>> and guest kernel support'
>>> @echo  '  tinyconfig  - Configure the tiniest possible kernel'
>>>
>>> +# pkg-config check
>>> +check-pkgconfig  := $(srctree)/$(src)/check-pkgconfig.sh
>>> +
>>>  # lxdialog stuff
>>>  check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
>>>
>>> @@ -205,7 +208,17 @@ $(addprefix $(obj)/, mconf.o $(lxdialog)
>>>  $(obj)/dochecklxdialog:
>>> $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
>>> $(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
>>>
>>> -always := dochecklxdialog
>>> +# Check that we have pkg-config (used by each of menu/n/g/xconfig)
>>> +PHONY += $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, mconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, nconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, gconf.o): $(obj)/docheckpkgconfig
>>> +$(addprefix $(obj)/, qconf.o): $(obj)/docheckpkgconfig
>>> +
>>> +$(obj)/docheckpkgconfig:
>>> +   $(Q)$(CONFIG_SHELL) $(check-pkgconfig)
>>> +
>>> +always := docheckpkgconfig dochecklxdialog
>>
>>
>> I did not test this patch, but does this check work as expected?
>>
>> Probably we want to run 'docheckpkgconfig'
>> before 'dochecklxdiag', '.tmp_gtkcheck', '.tmp_qtcheck', etc.
>> But, I do not see such dependencies.
>>
>>
>> Also, if we make 'pkg-config' mandatory,
>> should we entirely drop fall-back logics like follows?
>>
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L10
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/lxdialog/check-lxdialog.sh#L29
>> https://github.com/torvalds/linux/blob/v4.16-rc5/scripts/kconfig/Makefile#L230
>>
>>
>> What do you think?
>>
>
> Hi,
>
> I'm willing to keep patching/testing on this, but both pkg-config and depmod
> (for depmod, see: https://bugzilla.kernel.org/show_bug.cgi?id=198965)
> are basic requirements IMO, so just documenting their requirements is good
> enough to me, but might not be good enough for some users.
>
> Comments?

Sorry for late comments.

OK, I am fine with making pkg-config a requirement.
(and it should be documented)

But, I'd like to clean-up scripts/kconfig/Makefile first.
It is already cluttered, and hesitate to add new code based on that.
I posted the patches.

Could you send v3 after the cleaning work is done?

-- 
Best Regards
Masahiro Yamada

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

[AKASHI Takahiro]

Baoquan,

On Fri, May 18, 2018 at 09:37:35AM +0800, Baoquan He wrote:
> On 05/17/18 at 07:04pm, James Morse wrote:
> > Hi Baoquan,
> > 
> > On 17/05/18 03:15, Baoquan He wrote:
> > > On 05/17/18 at 10:10am, Baoquan He wrote:
> > >> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > >>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> >  On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved, 
> > 
> > > instead of system resource tree.
> > 
> >  Didn't we try to fix the system-resource-tree in order to fix 
> >  regular-kexec to
> >  be safe in the EFI-memory-map/ACPI-tables case?
> > 
> >  It would be good to avoid having two ways of doing this, and I would 
> >  like to
> >  avoid having extra arch code...
> > >>>
> > >>> I know what you mean.
> > >>> /proc/iomem or system resource is, in my opinion, not the best place to
> > >>> describe memory usage of kernel but rather to describe *physical* 
> > >>> hardware
> > >>> layout. As we are still discussing about "reserved" memory, I don't want
> > >>> to depend on it.
> > >>> Along with memblock list, we will have more accurate control over memory
> > >>> usage.
> > >>
> > >> In kexec-tools, we see any usable memory as candidate which can be used
> > > 
> > > Here I said 'any', it's not accurate. Those memory which need be passed
> > > to 2nd kernel for use need be excluded, just as we have done in
> > > kexec-tools.
> > > 
> > >> to load kexec kernel image/initrd etc. However kexec loading is a
> > >> preparation work, it just books those position for later kexec kernel
> > >> jumping after "kexec -e", that is why we need kexec_buf to remember
> > >> them and do the real content copy of kernel/initrd.
> > 
> > The problem we have on arm64 is /proc/iomem is being used for two things.
> > 1) Kexec's this is memory I can book for the new kernel.
> > 2) Kdump's this is memory I must describe for vmcore.
> > 
> > We get the memory map from UEFI via the EFI stub, and leave it in
> > memblock_reserved() memory. A new kexec kernel needs this to boot: it 
> > mustn't
> > overwrite it. The same goes for the ACPI tables, they could be reclaimed and
> > used as memory, but the new kexec kernel needs them to boot, they are
> > memblock_reserved() too.
> 
> Thanks for these details. Seems arm64 is different. In x86 64 memblock

Thanks to James from me, too.

> is used as bootmem allocator and will be released when buddy takes over.
> Mainly, using memblock may bring concern that kexec kernel
> will jump to a unfixed position. This creates an unexpected effect as
> KASLR is doing, namely kernel could be put at a random position. As we

I don't think that this would be a problem on arm64.

> know, kexec was invented for fast kernel dev testing by bypassing
> firmware reset, and has been taken to reboot those huge server with
> thousands of devices and large memory for business currently. This extra
> unpected KASLR effect may cause annoyance even though people have
> disabled KASLR explicitly for a specific testing purpose.
> 
> Besides, discarding the /proc/iomem scanning but taking memblock instead
> in kernel space works for kexec loading for the time being, the flaw of
> /proc/iomem still exists and cause problem for user space kexec-tools,
> as pointed out. Do we have a plan for that?

This was the difference between my and James' standpoint (at leas initially).
James didn't want to require userspace changes to fix the issue, but
the reality is that, without modifying it, we can't support kexec and kdump
perfectly as James explained in his email.

> > 
> > If we knock all memblock_reserved() regions out of /proc/iomem then kdump
> > doesn't work, because /proc/iomem is only generated once. Its a snapshot. 
> > The
> > initcode/data is an example of memory we release from memblock_reserve() 
> > after
> > this, then gets used for data we need in the vmcore.
> 
> Hmm, I'm a little confused here. We have defined different iores type
> for different memory region. If acpi need be reused by kdump/kexec, we
> can change to not reclaim it, and add them into /proc/iomem in order to
> notify components which rely on them to process.
> 
> 
> enum {  
> IORES_DESC_NONE = 0,
> IORES_DESC_CRASH_KERNEL = 1,
> IORES_DESC_ACPI_TABLES  = 2,
> IORES_DESC_ACPI_NV_STORAGE  = 3,
> IORES_DESC_PERSISTENT_MEMORY= 4,
> 

Re: [PATCH v9 04/11] arm64: kexec_file: allocate memory walking through memblock list

[AKASHI Takahiro]

Baoquan,

On Fri, May 18, 2018 at 09:37:35AM +0800, Baoquan He wrote:
> On 05/17/18 at 07:04pm, James Morse wrote:
> > Hi Baoquan,
> > 
> > On 17/05/18 03:15, Baoquan He wrote:
> > > On 05/17/18 at 10:10am, Baoquan He wrote:
> > >> On 05/07/18 at 02:59pm, AKASHI Takahiro wrote:
> > >>> On Tue, May 01, 2018 at 06:46:09PM +0100, James Morse wrote:
> >  On 25/04/18 07:26, AKASHI Takahiro wrote:
> > > We need to prevent firmware-reserved memory regions, particularly EFI
> > > memory map as well as ACPI tables, from being corrupted by loading
> > > kernel/initrd (or other kexec buffers). We also want to support memory
> > > allocation in top-down manner in addition to default bottom-up.
> > > So let's have arm64 specific arch_kexec_walk_mem() which will search
> > > for available memory ranges in usable memblock list,
> > > i.e. !NOMAP & !reserved, 
> > 
> > > instead of system resource tree.
> > 
> >  Didn't we try to fix the system-resource-tree in order to fix 
> >  regular-kexec to
> >  be safe in the EFI-memory-map/ACPI-tables case?
> > 
> >  It would be good to avoid having two ways of doing this, and I would 
> >  like to
> >  avoid having extra arch code...
> > >>>
> > >>> I know what you mean.
> > >>> /proc/iomem or system resource is, in my opinion, not the best place to
> > >>> describe memory usage of kernel but rather to describe *physical* 
> > >>> hardware
> > >>> layout. As we are still discussing about "reserved" memory, I don't want
> > >>> to depend on it.
> > >>> Along with memblock list, we will have more accurate control over memory
> > >>> usage.
> > >>
> > >> In kexec-tools, we see any usable memory as candidate which can be used
> > > 
> > > Here I said 'any', it's not accurate. Those memory which need be passed
> > > to 2nd kernel for use need be excluded, just as we have done in
> > > kexec-tools.
> > > 
> > >> to load kexec kernel image/initrd etc. However kexec loading is a
> > >> preparation work, it just books those position for later kexec kernel
> > >> jumping after "kexec -e", that is why we need kexec_buf to remember
> > >> them and do the real content copy of kernel/initrd.
> > 
> > The problem we have on arm64 is /proc/iomem is being used for two things.
> > 1) Kexec's this is memory I can book for the new kernel.
> > 2) Kdump's this is memory I must describe for vmcore.
> > 
> > We get the memory map from UEFI via the EFI stub, and leave it in
> > memblock_reserved() memory. A new kexec kernel needs this to boot: it 
> > mustn't
> > overwrite it. The same goes for the ACPI tables, they could be reclaimed and
> > used as memory, but the new kexec kernel needs them to boot, they are
> > memblock_reserved() too.
> 
> Thanks for these details. Seems arm64 is different. In x86 64 memblock

Thanks to James from me, too.

> is used as bootmem allocator and will be released when buddy takes over.
> Mainly, using memblock may bring concern that kexec kernel
> will jump to a unfixed position. This creates an unexpected effect as
> KASLR is doing, namely kernel could be put at a random position. As we

I don't think that this would be a problem on arm64.

> know, kexec was invented for fast kernel dev testing by bypassing
> firmware reset, and has been taken to reboot those huge server with
> thousands of devices and large memory for business currently. This extra
> unpected KASLR effect may cause annoyance even though people have
> disabled KASLR explicitly for a specific testing purpose.
> 
> Besides, discarding the /proc/iomem scanning but taking memblock instead
> in kernel space works for kexec loading for the time being, the flaw of
> /proc/iomem still exists and cause problem for user space kexec-tools,
> as pointed out. Do we have a plan for that?

This was the difference between my and James' standpoint (at leas initially).
James didn't want to require userspace changes to fix the issue, but
the reality is that, without modifying it, we can't support kexec and kdump
perfectly as James explained in his email.

> > 
> > If we knock all memblock_reserved() regions out of /proc/iomem then kdump
> > doesn't work, because /proc/iomem is only generated once. Its a snapshot. 
> > The
> > initcode/data is an example of memory we release from memblock_reserve() 
> > after
> > this, then gets used for data we need in the vmcore.
> 
> Hmm, I'm a little confused here. We have defined different iores type
> for different memory region. If acpi need be reused by kdump/kexec, we
> can change to not reclaim it, and add them into /proc/iomem in order to
> notify components which rely on them to process.
> 
> 
> enum {  
> IORES_DESC_NONE = 0,
> IORES_DESC_CRASH_KERNEL = 1,
> IORES_DESC_ACPI_TABLES  = 2,
> IORES_DESC_ACPI_NV_STORAGE  = 3,
> IORES_DESC_PERSISTENT_MEMORY= 4,
> 

[PATCH v2 3/3] perf annotate: Support '--group' option

[Jin Yao]

With the '--group' option, even for non-explicit group, perf annotate
will enable the group output.

For example,

perf record -e cycles,branches ./div
perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

But if without --group, there is only one event reported.

perf annotate main --stdio

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 121212;
 :
 :s_randseed = time(0);
0.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-annotate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6e5d9f7..5272d48 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -45,6 +45,7 @@ struct perf_annotate {
bool   print_line;
bool   skip_missing;
bool   has_br_stack;
+   bool   group_set;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -508,6 +509,9 @@ int cmd_annotate(int argc, const char **argv)
"Don't shorten the displayed pathnames"),
OPT_BOOLEAN(0, "skip-missing", _missing,
"Skip symbols that cannot be annotated"),
+   OPT_BOOLEAN_SET(0, "group", _conf.event_group,
+   _set,
+   "Show event group information together"),
OPT_STRING('C', "cpu", _list, "cpu", "list of cpus to 
profile"),
OPT_CALLBACK(0, "symfs", NULL, "directory",
 "Look for files with symbols relative to this directory",
@@ -570,6 +574,9 @@ int cmd_annotate(int argc, const char **argv)
annotate.has_br_stack = perf_header__has_feat(>header,
  HEADER_BRANCH_STACK);
 
+   if (annotate.group_set)
+   perf_evlist_forced_leader(annotate.session->evlist);
+
ret = symbol__annotation_init();
if (ret < 0)
goto out_delete;
-- 
2.7.4

[PATCH v2 3/3] perf annotate: Support '--group' option

[Jin Yao]

With the '--group' option, even for non-explicit group, perf annotate
will enable the group output.

For example,

perf record -e cycles,branches ./div
perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

But if without --group, there is only one event reported.

perf annotate main --stdio

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 121212;
 :
 :s_randseed = time(0);
0.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-annotate.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/tools/perf/builtin-annotate.c b/tools/perf/builtin-annotate.c
index 6e5d9f7..5272d48 100644
--- a/tools/perf/builtin-annotate.c
+++ b/tools/perf/builtin-annotate.c
@@ -45,6 +45,7 @@ struct perf_annotate {
bool   print_line;
bool   skip_missing;
bool   has_br_stack;
+   bool   group_set;
const char *sym_hist_filter;
const char *cpu_list;
DECLARE_BITMAP(cpu_bitmap, MAX_NR_CPUS);
@@ -508,6 +509,9 @@ int cmd_annotate(int argc, const char **argv)
"Don't shorten the displayed pathnames"),
OPT_BOOLEAN(0, "skip-missing", _missing,
"Skip symbols that cannot be annotated"),
+   OPT_BOOLEAN_SET(0, "group", _conf.event_group,
+   _set,
+   "Show event group information together"),
OPT_STRING('C', "cpu", _list, "cpu", "list of cpus to 
profile"),
OPT_CALLBACK(0, "symfs", NULL, "directory",
 "Look for files with symbols relative to this directory",
@@ -570,6 +574,9 @@ int cmd_annotate(int argc, const char **argv)
annotate.has_br_stack = perf_header__has_feat(>header,
  HEADER_BRANCH_STACK);
 
+   if (annotate.group_set)
+   perf_evlist_forced_leader(annotate.session->evlist);
+
ret = symbol__annotation_init();
if (ret < 0)
goto out_delete;
-- 
2.7.4

[PATCH v2 2/3] perf report: Use perf_evlist_forced_leader to support '--group'

[Jin Yao]

Since we have created a new function perf_evlist_forced_leader,
so now remove the old code and use perf_evlist_forced_leader
instead.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-report.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4c931af..63fe776 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -202,12 +202,8 @@ static int hist_iter__branch_callback(struct 
hist_entry_iter *iter,
 static void setup_forced_leader(struct report *report,
struct perf_evlist *evlist)
 {
-   if (report->group_set && !evlist->nr_groups) {
-   struct perf_evsel *leader = perf_evlist__first(evlist);
-
-   perf_evlist__set_leader(evlist);
-   leader->forced_leader = true;
-   }
+   if (report->group_set)
+   perf_evlist_forced_leader(evlist);
 }
 
 static int process_feature_event(struct perf_tool *tool,
-- 
2.7.4

[PATCH v2 2/3] perf report: Use perf_evlist_forced_leader to support '--group'

[Jin Yao]

Since we have created a new function perf_evlist_forced_leader,
so now remove the old code and use perf_evlist_forced_leader
instead.

Signed-off-by: Jin Yao 
---
 tools/perf/builtin-report.c | 8 ++--
 1 file changed, 2 insertions(+), 6 deletions(-)

diff --git a/tools/perf/builtin-report.c b/tools/perf/builtin-report.c
index 4c931af..63fe776 100644
--- a/tools/perf/builtin-report.c
+++ b/tools/perf/builtin-report.c
@@ -202,12 +202,8 @@ static int hist_iter__branch_callback(struct 
hist_entry_iter *iter,
 static void setup_forced_leader(struct report *report,
struct perf_evlist *evlist)
 {
-   if (report->group_set && !evlist->nr_groups) {
-   struct perf_evsel *leader = perf_evlist__first(evlist);
-
-   perf_evlist__set_leader(evlist);
-   leader->forced_leader = true;
-   }
+   if (report->group_set)
+   perf_evlist_forced_leader(evlist);
 }
 
 static int process_feature_event(struct perf_tool *tool,
-- 
2.7.4

[PATCH v2 1/3] perf evlist: Create a new function perf_evlist_forced_leader

[Jin Yao]

For non-explicit group, perf report supports a option '--group'
which can enable group output. We also need to support perf annotate
with the same '--group'.

Create a new function perf_evlist_forced_leader which contains
common code to force setting the group leader.

Signed-off-by: Jin Yao 
---
 tools/perf/util/evlist.c | 10 ++
 tools/perf/util/evlist.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a59281d..ed8a9d5 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1795,3 +1795,13 @@ bool perf_evlist__exclude_kernel(struct perf_evlist 
*evlist)
 
return true;
 }
+
+void perf_evlist_forced_leader(struct perf_evlist *evlist)
+{
+   if (!evlist->nr_groups) {
+   struct perf_evsel *leader = perf_evlist__first(evlist);
+
+   perf_evlist__set_leader(evlist);
+   leader->forced_leader = true;
+   }
+}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 6c41b2f..d77d514 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -309,4 +309,7 @@ struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
union perf_event *event);
 
 bool perf_evlist__exclude_kernel(struct perf_evlist *evlist);
+
+void perf_evlist_forced_leader(struct perf_evlist *evlist);
+
 #endif /* __PERF_EVLIST_H */
-- 
2.7.4

[PATCH v2 1/3] perf evlist: Create a new function perf_evlist_forced_leader

[Jin Yao]

For non-explicit group, perf report supports a option '--group'
which can enable group output. We also need to support perf annotate
with the same '--group'.

Create a new function perf_evlist_forced_leader which contains
common code to force setting the group leader.

Signed-off-by: Jin Yao 
---
 tools/perf/util/evlist.c | 10 ++
 tools/perf/util/evlist.h |  3 +++
 2 files changed, 13 insertions(+)

diff --git a/tools/perf/util/evlist.c b/tools/perf/util/evlist.c
index a59281d..ed8a9d5 100644
--- a/tools/perf/util/evlist.c
+++ b/tools/perf/util/evlist.c
@@ -1795,3 +1795,13 @@ bool perf_evlist__exclude_kernel(struct perf_evlist 
*evlist)
 
return true;
 }
+
+void perf_evlist_forced_leader(struct perf_evlist *evlist)
+{
+   if (!evlist->nr_groups) {
+   struct perf_evsel *leader = perf_evlist__first(evlist);
+
+   perf_evlist__set_leader(evlist);
+   leader->forced_leader = true;
+   }
+}
diff --git a/tools/perf/util/evlist.h b/tools/perf/util/evlist.h
index 6c41b2f..d77d514 100644
--- a/tools/perf/util/evlist.h
+++ b/tools/perf/util/evlist.h
@@ -309,4 +309,7 @@ struct perf_evsel *perf_evlist__event2evsel(struct 
perf_evlist *evlist,
union perf_event *event);
 
 bool perf_evlist__exclude_kernel(struct perf_evlist *evlist);
+
+void perf_evlist_forced_leader(struct perf_evlist *evlist);
+
 #endif /* __PERF_EVLIST_H */
-- 
2.7.4

[PATCH v2 0/3] perf annotate: Support '--group' option

[Jin Yao]

For non-explicit group, perf report has already supported a option
'--group' which can enable group output.

This patch-set will support perf annotate with the same '--group'.

For example,

perf record -e cycles,branches ./div
perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

v2:
-
Arnaldo points out that it should be done the way it is for
perf report --group. v2 refers to this way and the patch is
totally rewritten.

Init post:
--
Post the patch 'perf annotate: Support multiple events without group'

Jin Yao (3):
  perf evlist: Create a new function perf_evlist_forced_leader
  perf report: Use perf_evlist_forced_leader to support '--group'
  perf annotate: Support '--group' option

 tools/perf/builtin-annotate.c |  7 +++
 tools/perf/builtin-report.c   |  8 ++--
 tools/perf/util/evlist.c  | 10 ++
 tools/perf/util/evlist.h  |  3 +++
 4 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.7.4

[PATCH v2 0/3] perf annotate: Support '--group' option

[Jin Yao]

For non-explicit group, perf report has already supported a option
'--group' which can enable group output.

This patch-set will support perf annotate with the same '--group'.

For example,

perf record -e cycles,branches ./div
perf annotate main --stdio --group

 :Disassembly of section .text:
 :
 :004004b0 :
 :main():
 :
 :return i;
 :}
 :
 :int main(void)
 :{
0.000.00 :   4004b0:   push   %rbx
 :int i;
 :int flag;
 :volatile double x = 1212121212, y = 
121212;
 :
 :s_randseed = time(0);
0.000.00 :   4004b1:   xor%edi,%edi
 :srand(s_randseed);
0.000.00 :   4004b3:   mov$0x77359400,%ebx
 :
 :return i;
 :}
 :

v2:
-
Arnaldo points out that it should be done the way it is for
perf report --group. v2 refers to this way and the patch is
totally rewritten.

Init post:
--
Post the patch 'perf annotate: Support multiple events without group'

Jin Yao (3):
  perf evlist: Create a new function perf_evlist_forced_leader
  perf report: Use perf_evlist_forced_leader to support '--group'
  perf annotate: Support '--group' option

 tools/perf/builtin-annotate.c |  7 +++
 tools/perf/builtin-report.c   |  8 ++--
 tools/perf/util/evlist.c  | 10 ++
 tools/perf/util/evlist.h  |  3 +++
 4 files changed, 22 insertions(+), 6 deletions(-)

-- 
2.7.4

[git pull] drm fixes for v4.17-rc6

[Dave Airlie]

Hi Linus,

Pretty quiet week again, one vmwgfx regression fix, one core buffer
overflow fix,one vc4 leak fix and three i915 fixes.

Dave.

The following changes since commit 76ef6b28ea4f81c3d511866a9b31392caa833126:

  drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc6

for you to fetch changes up to 1827cad96d624ec127853a71cb931c74024e57d6:

  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-05-18
12:01:49 +1000)


i915, vc4, vmwgfx and core fixes


Chris Wilson (1):
  drm/i915/execlists: Use rmb() to order CSB reads

Dan Carpenter (1):
  drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

Dave Airlie (3):
  Merge tag 'drm-misc-fixes-2018-05-16' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Deepak Rawat (1):
  drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful

Eric Anholt (1):
  drm/vc4: Fix leak of the file_priv that stored the perfmon.

Haneen Mohammed (1):
  drm: Match sysfs name in link removal to link creation

Matthew Auld (1):
  drm/i915/userptr: reject zero user_size

Michel Thierry (1):
  drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

 drivers/gpu/drm/drm_drv.c   | 2 +-
 drivers/gpu/drm/drm_dumb_buffers.c  | 7 ---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 4 
 drivers/gpu/drm/i915/intel_lrc.c| 1 +
 drivers/gpu/drm/vc4/vc4_drv.c   | 1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 2 ++
 8 files changed, 19 insertions(+), 4 deletions(-)

[git pull] drm fixes for v4.17-rc6

[Dave Airlie]

Hi Linus,

Pretty quiet week again, one vmwgfx regression fix, one core buffer
overflow fix,one vc4 leak fix and three i915 fixes.

Dave.

The following changes since commit 76ef6b28ea4f81c3d511866a9b31392caa833126:

  drm: set FMODE_UNSIGNED_OFFSET for drm files (2018-05-15 14:46:04 +1000)

are available in the Git repository at:

  git://people.freedesktop.org/~airlied/linux tags/drm-fixes-for-v4.17-rc6

for you to fetch changes up to 1827cad96d624ec127853a71cb931c74024e57d6:

  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes (2018-05-18
12:01:49 +1000)


i915, vc4, vmwgfx and core fixes


Chris Wilson (1):
  drm/i915/execlists: Use rmb() to order CSB reads

Dan Carpenter (1):
  drm/dumb-buffers: Integer overflow in drm_mode_create_ioctl()

Dave Airlie (3):
  Merge tag 'drm-misc-fixes-2018-05-16' of
git://anongit.freedesktop.org/drm/drm-misc into drm-fixes
  Merge branch 'vmwgfx-fixes-4.17' of
git://people.freedesktop.org/~thomash/linux into drm-fixes
  Merge tag 'drm-intel-fixes-2018-05-17' of
git://anongit.freedesktop.org/drm/drm-intel into drm-fixes

Deepak Rawat (1):
  drm/vmwgfx: Set dmabuf_size when vmw_dmabuf_init is successful

Eric Anholt (1):
  drm/vc4: Fix leak of the file_priv that stored the perfmon.

Haneen Mohammed (1):
  drm: Match sysfs name in link removal to link creation

Matthew Auld (1):
  drm/i915/userptr: reject zero user_size

Michel Thierry (1):
  drm/i915/gen9: Add WaClearHIZ_WM_CHICKEN3 for bxt and glk

 drivers/gpu/drm/drm_drv.c   | 2 +-
 drivers/gpu/drm/drm_dumb_buffers.c  | 7 ---
 drivers/gpu/drm/i915/i915_gem_userptr.c | 3 +++
 drivers/gpu/drm/i915/i915_reg.h | 3 +++
 drivers/gpu/drm/i915/intel_engine_cs.c  | 4 
 drivers/gpu/drm/i915/intel_lrc.c| 1 +
 drivers/gpu/drm/vc4/vc4_drv.c   | 1 +
 drivers/gpu/drm/vmwgfx/vmwgfx_scrn.c| 2 ++
 8 files changed, 19 insertions(+), 4 deletions(-)

[PATCH 3/5] kconfig: refactor GTK+ package checks for building gconf

[Masahiro Yamada]

Refactor the necessary package checks for building gconf in the same
way as for qconf.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 43 +--
 scripts/kconfig/gconf-cfg.sh | 23 +++
 2 files changed, 32 insertions(+), 34 deletions(-)
 create mode 100755 scripts/kconfig/gconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index e9a87bf..c222745 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -188,8 +188,6 @@ HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) 
$(check-lxdialog) -ccflags) \
 # Utilizes ncurses
 # mconf:  Used for the menuconfig target
 # Utilizes the lxdialog package
-# gconf:  Used for the gconfig target
-# Based on GTK+ which needs to be installed to compile it
 # object files used by all kconfig flavours
 
 lxdialog := lxdialog/checklist.o lxdialog/util.o lxdialog/inputbox.o
@@ -199,12 +197,10 @@ conf-objs := conf.o  zconf.tab.o
 mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
-gconf-objs := gconf.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext gconf
+hostprogs-y := conf nconf mconf kxgettext
 
 targets+= zconf.lex.c
-clean-files:= .tmp_gtkcheck
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
@@ -224,10 +220,6 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_gconf= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
-HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 gmodule-2.0 
libglade-2.0` \
-  -Wno-missing-prototypes
-
 HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
$(HOSTCC))
 
 HOSTLOADLIBES_nconf= $(shell \
@@ -251,31 +243,14 @@ quiet_cmd_moc = MOC $@
 $(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg
$(call cmd,moc)
 
-$(obj)/gconf.o: $(obj)/.tmp_gtkcheck
-
-ifeq ($(MAKECMDGOALS),gconfig)
--include $(obj)/.tmp_gtkcheck
-
-# GTK+ needs some extra effort, too...
-$(obj)/.tmp_gtkcheck:
-   @if `pkg-config --exists gtk+-2.0 gmodule-2.0 libglade-2.0`; then   
\
-   if `pkg-config --atleast-version=2.0.0 gtk+-2.0`; then  
\
-   touch $@;   
\
-   else
\
-   echo >&2 "*";   
\
-   echo >&2 "* GTK+ is present but version >= 2.0.0 is 
required."; \
-   echo >&2 "*";   
\
-   false;  
\
-   fi  
\
-   else
\
-   echo >&2 "*";   
\
-   echo >&2 "* Unable to find the GTK+ installation. Please make 
sure that";   \
-   echo >&2 "* the GTK+ 2.0 development package is correctly 
installed...";\
-   echo >&2 "* You need gtk+-2.0, glib-2.0 and libglade-2.0."; 
\
-   echo >&2 "*";   
\
-   false;  
\
-   fi
-endif
+# gconf: Used for the gconfig target based on GTK+
+hostprogs-y+= gconf
+gconf-objs := gconf.o zconf.tab.o
+
+HOSTLOADLIBES_gconf = $(shell . $(obj)/.gconf-cfg && echo $$libs)
+HOSTCFLAGS_gconf.o  = $(shell . $(obj)/.gconf-cfg && echo $$cflags)
+
+$(obj)/gconf.o: $(obj)/.gconf-cfg
 
 $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh
new file mode 100755
index 000..533b3d8
--- /dev/null
+++ b/scripts/kconfig/gconf-cfg.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+PKG="gtk+-2.0 gmodule-2.0 libglade-2.0"
+
+if ! pkg-config --exists $PKG; then
+   echo >&2 "*"
+   echo >&2 "* Unable to find the GTK+ installation. Please make sure that"
+   echo >&2 "* the GTK+ 2.0 development package is correctly installed."
+   echo >&2 "* You need $PKG"
+   echo >&2 "*"
+   exit 1
+fi
+
+if ! pkg-config --atleast-version=2.0.0 gtk+-2.0; then
+   echo >&2 "*"
+   echo >&2 "* GTK+ is present but version >= 2.0.0 is required."
+   echo >&2 "*"
+   exit 1
+fi
+
+echo cflags=\"$(pkg-config --cflags $PKG)\"
+echo libs=\"$(pkg-config --libs $PKG)\"
-- 
2.7.4

[PATCH 5/5] kconfig: refactor ncurses package checks for building nconf

[Masahiro Yamada]

Building nconf requires ncurses, but its presence is not checked.
Check and configure necessary packages as in the other GUI frontends.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 16 
 scripts/kconfig/nconf-cfg.sh | 22 ++
 2 files changed, 30 insertions(+), 8 deletions(-)
 create mode 100644 scripts/kconfig/nconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 25a3d25..b90e801 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -176,15 +176,12 @@ help:
 # ===
 # Shared Makefile for the various kconfig executables:
 # conf:  Used for defconfig, oldconfig and related targets
-# nconf:  Used for the nconfig target.
-# Utilizes ncurses
 # object files used by all kconfig flavours
 
 conf-objs  := conf.o  zconf.tab.o
-nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
 
-hostprogs-y := conf nconf kxgettext
+hostprogs-y := conf kxgettext
 
 targets+= zconf.lex.c
 clean-files+= gconf.glade.h
@@ -199,10 +196,13 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_nconf= $(shell \
-   pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
-   || pkg-config --libs menu panel ncurses 
2>/dev/null \
-   || echo "-lmenu -lpanel -lncurses"  )
+# nconf: Used for the nconfig target based on ncurses
+hostprogs-y+= nconf
+nconf-objs := nconf.o zconf.tab.o nconf.gui.o
+
+HOSTLOADLIBES_nconf= $(shell . $(obj)/.nconf-cfg && echo $$libs)
+
+$(obj)/nconf.o: $(obj)/.nconf-cfg
 
 # mconf: Used for the menuconfig target based on lxdialog
 hostprogs-y+= mconf
diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh
new file mode 100644
index 000..9def36f
--- /dev/null
+++ b/scripts/kconfig/nconf-cfg.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+PKG="menuw panelw ncursesw"
+PKG2="menu panel ncurses"
+
+if pkg-config --exists $PKG; then
+   echo libs=\"$(pkg-config --libs $PKG)\"
+   exit 0
+fi
+
+if pkg-config --exists $PKG2; then
+   echo libs=\"$(pkg-config --libs $PKG2)\"
+   exit 0
+fi
+
+echo >&2 "*"
+echo >&2 "* Unable to find the ncurses."
+echo >&2 "* Install ncurses (ncurses-devel or libncurses-dev"
+echo >&2 "* depending on your distribution)"
+echo >&2 "*"
+exit 1
-- 
2.7.4

[PATCH 3/5] kconfig: refactor GTK+ package checks for building gconf

[Masahiro Yamada]

Refactor the necessary package checks for building gconf in the same
way as for qconf.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 43 +--
 scripts/kconfig/gconf-cfg.sh | 23 +++
 2 files changed, 32 insertions(+), 34 deletions(-)
 create mode 100755 scripts/kconfig/gconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index e9a87bf..c222745 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -188,8 +188,6 @@ HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) 
$(check-lxdialog) -ccflags) \
 # Utilizes ncurses
 # mconf:  Used for the menuconfig target
 # Utilizes the lxdialog package
-# gconf:  Used for the gconfig target
-# Based on GTK+ which needs to be installed to compile it
 # object files used by all kconfig flavours
 
 lxdialog := lxdialog/checklist.o lxdialog/util.o lxdialog/inputbox.o
@@ -199,12 +197,10 @@ conf-objs := conf.o  zconf.tab.o
 mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
-gconf-objs := gconf.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext gconf
+hostprogs-y := conf nconf mconf kxgettext
 
 targets+= zconf.lex.c
-clean-files:= .tmp_gtkcheck
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
@@ -224,10 +220,6 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_gconf= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
-HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 gmodule-2.0 
libglade-2.0` \
-  -Wno-missing-prototypes
-
 HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
$(HOSTCC))
 
 HOSTLOADLIBES_nconf= $(shell \
@@ -251,31 +243,14 @@ quiet_cmd_moc = MOC $@
 $(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg
$(call cmd,moc)
 
-$(obj)/gconf.o: $(obj)/.tmp_gtkcheck
-
-ifeq ($(MAKECMDGOALS),gconfig)
--include $(obj)/.tmp_gtkcheck
-
-# GTK+ needs some extra effort, too...
-$(obj)/.tmp_gtkcheck:
-   @if `pkg-config --exists gtk+-2.0 gmodule-2.0 libglade-2.0`; then   
\
-   if `pkg-config --atleast-version=2.0.0 gtk+-2.0`; then  
\
-   touch $@;   
\
-   else
\
-   echo >&2 "*";   
\
-   echo >&2 "* GTK+ is present but version >= 2.0.0 is 
required."; \
-   echo >&2 "*";   
\
-   false;  
\
-   fi  
\
-   else
\
-   echo >&2 "*";   
\
-   echo >&2 "* Unable to find the GTK+ installation. Please make 
sure that";   \
-   echo >&2 "* the GTK+ 2.0 development package is correctly 
installed...";\
-   echo >&2 "* You need gtk+-2.0, glib-2.0 and libglade-2.0."; 
\
-   echo >&2 "*";   
\
-   false;  
\
-   fi
-endif
+# gconf: Used for the gconfig target based on GTK+
+hostprogs-y+= gconf
+gconf-objs := gconf.o zconf.tab.o
+
+HOSTLOADLIBES_gconf = $(shell . $(obj)/.gconf-cfg && echo $$libs)
+HOSTCFLAGS_gconf.o  = $(shell . $(obj)/.gconf-cfg && echo $$cflags)
+
+$(obj)/gconf.o: $(obj)/.gconf-cfg
 
 $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
diff --git a/scripts/kconfig/gconf-cfg.sh b/scripts/kconfig/gconf-cfg.sh
new file mode 100755
index 000..533b3d8
--- /dev/null
+++ b/scripts/kconfig/gconf-cfg.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+PKG="gtk+-2.0 gmodule-2.0 libglade-2.0"
+
+if ! pkg-config --exists $PKG; then
+   echo >&2 "*"
+   echo >&2 "* Unable to find the GTK+ installation. Please make sure that"
+   echo >&2 "* the GTK+ 2.0 development package is correctly installed."
+   echo >&2 "* You need $PKG"
+   echo >&2 "*"
+   exit 1
+fi
+
+if ! pkg-config --atleast-version=2.0.0 gtk+-2.0; then
+   echo >&2 "*"
+   echo >&2 "* GTK+ is present but version >= 2.0.0 is required."
+   echo >&2 "*"
+   exit 1
+fi
+
+echo cflags=\"$(pkg-config --cflags $PKG)\"
+echo libs=\"$(pkg-config --libs $PKG)\"
-- 
2.7.4

[PATCH 5/5] kconfig: refactor ncurses package checks for building nconf

[Masahiro Yamada]

Building nconf requires ncurses, but its presence is not checked.
Check and configure necessary packages as in the other GUI frontends.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 16 
 scripts/kconfig/nconf-cfg.sh | 22 ++
 2 files changed, 30 insertions(+), 8 deletions(-)
 create mode 100644 scripts/kconfig/nconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 25a3d25..b90e801 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -176,15 +176,12 @@ help:
 # ===
 # Shared Makefile for the various kconfig executables:
 # conf:  Used for defconfig, oldconfig and related targets
-# nconf:  Used for the nconfig target.
-# Utilizes ncurses
 # object files used by all kconfig flavours
 
 conf-objs  := conf.o  zconf.tab.o
-nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
 
-hostprogs-y := conf nconf kxgettext
+hostprogs-y := conf kxgettext
 
 targets+= zconf.lex.c
 clean-files+= gconf.glade.h
@@ -199,10 +196,13 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_nconf= $(shell \
-   pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
-   || pkg-config --libs menu panel ncurses 
2>/dev/null \
-   || echo "-lmenu -lpanel -lncurses"  )
+# nconf: Used for the nconfig target based on ncurses
+hostprogs-y+= nconf
+nconf-objs := nconf.o zconf.tab.o nconf.gui.o
+
+HOSTLOADLIBES_nconf= $(shell . $(obj)/.nconf-cfg && echo $$libs)
+
+$(obj)/nconf.o: $(obj)/.nconf-cfg
 
 # mconf: Used for the menuconfig target based on lxdialog
 hostprogs-y+= mconf
diff --git a/scripts/kconfig/nconf-cfg.sh b/scripts/kconfig/nconf-cfg.sh
new file mode 100644
index 000..9def36f
--- /dev/null
+++ b/scripts/kconfig/nconf-cfg.sh
@@ -0,0 +1,22 @@
+#!/bin/sh
+# SPDX-License-Identifier: GPL-2.0
+
+PKG="menuw panelw ncursesw"
+PKG2="menu panel ncurses"
+
+if pkg-config --exists $PKG; then
+   echo libs=\"$(pkg-config --libs $PKG)\"
+   exit 0
+fi
+
+if pkg-config --exists $PKG2; then
+   echo libs=\"$(pkg-config --libs $PKG2)\"
+   exit 0
+fi
+
+echo >&2 "*"
+echo >&2 "* Unable to find the ncurses."
+echo >&2 "* Install ncurses (ncurses-devel or libncurses-dev"
+echo >&2 "* depending on your distribution)"
+echo >&2 "*"
+exit 1
-- 
2.7.4

[PATCH 0/5] kconfig: refactor package checks for GUI frontends

[Masahiro Yamada]

Kconfig supports 4 GUI frontends.
Each of them needs some support packages, but checks them differently:

  qconf, gconf: check packages in Makefile (pkg-config is required)
  mconf: lxdialog/check-lxdialog.sh
  nconf: needs ncurses, but its presence is not checked

This series refactor the package checks so that all of them work
in the same way.

The package check scripts have been moved to scripts/kconfig/*conf-cfg.sh

The motivation of this clean-up is Randy's following patch:
https://patchwork.kernel.org/patch/10277723/

I want to clean up existing code before adding more checks.



Masahiro Yamada (5):
  kbuild: do not display CHK for filechk
  kconfig: refactor Qt package checks for building qconf
  kconfig: refactor GTK+ package checks for building gconf
  kconfig: refactor ncurses package checks for building mconf
  kconfig: refactor ncurses package checks for building nconf

 scripts/Kbuild.include |   1 -
 scripts/kconfig/Makefile   | 160 ++---
 scripts/kconfig/gconf-cfg.sh   |  23 +
 scripts/kconfig/lxdialog/check-lxdialog.sh |  93 -
 scripts/kconfig/lxdialog/dialog.h  |   2 +-
 scripts/kconfig/mconf-cfg.sh   |  24 +
 scripts/kconfig/nconf-cfg.sh   |  22 
 scripts/kconfig/qconf-cfg.sh   |  25 +
 8 files changed, 148 insertions(+), 202 deletions(-)
 create mode 100755 scripts/kconfig/gconf-cfg.sh
 delete mode 100755 scripts/kconfig/lxdialog/check-lxdialog.sh
 create mode 100755 scripts/kconfig/mconf-cfg.sh
 create mode 100644 scripts/kconfig/nconf-cfg.sh
 create mode 100755 scripts/kconfig/qconf-cfg.sh

-- 
2.7.4

[PATCH 1/5] kbuild: do not display CHK for filechk

[Masahiro Yamada]

filechk displays two short logs; CHK for creating a temporary file,
and UPD for really updating the target.

IMHO, the build system can be quiet when the target file has not
been updated.

Signed-off-by: Masahiro Yamada 
---

 scripts/Kbuild.include | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 50cee53..c7fedc5 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -57,7 +57,6 @@ kecho := $($(quiet)kecho)
 #   to specify a valid file as first prerequisite (often the kbuild file)
 define filechk
$(Q)set -e; \
-   $(kecho) '  CHK $@';\
mkdir -p $(dir $@); \
$(filechk_$(1)) < $< > $@.tmp;  \
if [ -r $@ ] && cmp -s $@ $@.tmp; then  \
-- 
2.7.4

[PATCH 4/5] kconfig: refactor ncurses package checks for building mconf

[Masahiro Yamada]

The mconf (or its infrastructure, lxdiaglog) depends on ncurses.
check-lxdialog.sh has additional checks in case pkg-config is not
available.  However, qconf and gconf already rely on pkg-config to
check necessary packages.  For simplification, drop the fallback
code from check-lxdialog.sh and move/rename to mconf-cfg.sh to
make it work in the same way as the other GUI frontends.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile   | 44 +-
 scripts/kconfig/lxdialog/check-lxdialog.sh | 93 --
 scripts/kconfig/lxdialog/dialog.h  |  2 +-
 scripts/kconfig/mconf-cfg.sh   | 24 
 4 files changed, 41 insertions(+), 122 deletions(-)
 delete mode 100755 scripts/kconfig/lxdialog/check-lxdialog.sh
 create mode 100755 scripts/kconfig/mconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index c222745..25a3d25 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -173,60 +173,48 @@ help:
@echo  '  xenconfig   - Enable additional options for xen dom0 and 
guest kernel support'
@echo  '  tinyconfig  - Configure the tiniest possible kernel'
 
-# lxdialog stuff
-check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
-
-# Use recursively expanded variables so we do not call gcc unless
-# we really need to do so. (Do not call gcc as part of make mrproper)
-HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
--DLOCALE
-
 # ===
 # Shared Makefile for the various kconfig executables:
 # conf:  Used for defconfig, oldconfig and related targets
 # nconf:  Used for the nconfig target.
 # Utilizes ncurses
-# mconf:  Used for the menuconfig target
-# Utilizes the lxdialog package
 # object files used by all kconfig flavours
 
-lxdialog := lxdialog/checklist.o lxdialog/util.o lxdialog/inputbox.o
-lxdialog += lxdialog/textbox.o lxdialog/yesno.o lxdialog/menubox.o
-
 conf-objs  := conf.o  zconf.tab.o
-mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext
+hostprogs-y := conf nconf kxgettext
 
 targets+= zconf.lex.c
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
-# Check that we have the required ncurses stuff installed for lxdialog 
(menuconfig)
-PHONY += $(obj)/dochecklxdialog
-$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog
-$(obj)/dochecklxdialog:
-   $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
$(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
-
-always := dochecklxdialog
-
 # Add environment specific flags
-HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCC) $(HOSTCFLAGS))
-HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCXX) $(HOSTCXXFLAGS))
-
+HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCC) $(HOSTCFLAGS)) \
+   -DLOCALE
+HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCXX) $(HOSTCXXFLAGS)) \
+   -DLOCALE
 # generated files seem to need this to find local include files
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
$(HOSTCC))
-
 HOSTLOADLIBES_nconf= $(shell \
pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
|| pkg-config --libs menu panel ncurses 
2>/dev/null \
|| echo "-lmenu -lpanel -lncurses"  )
 
+# mconf: Used for the menuconfig target based on lxdialog
+hostprogs-y+= mconf
+lxdialog   := checklist.o inputbox.o menubox.o textbox.o util.o yesno.o
+mconf-objs := mconf.o zconf.tab.o $(addprefix lxdialog/, $(lxdialog))
+
+HOSTLOADLIBES_mconf = $(shell . $(obj)/.mconf-cfg && echo $$libs)
+$(foreach f, mconf.o $(lxdialog), \
+  $(eval HOSTCFLAGS_$f = $$(shell . $(obj)/.mconf-cfg && echo cflags)))
+
+$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/.mconf-cfg
+
 # qconf: Used for the xconfig target based on Qt
 hostprogs-y+= qconf
 qconf-cxxobjs  := qconf.o
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh 
b/scripts/kconfig/lxdialog/check-lxdialog.sh
deleted file mode 100755
index 6c0bcd9..000
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ /dev/null
@@ -1,93 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-# Check ncurses compatibility
-
-# What library to link
-ldflags()
-{
-   pkg-config --libs ncursesw 2>/dev/null && exit
-   pkg-config --libs ncurses 2>/dev/null && exit
-   for ext in so a dll.a dylib ; do
-   for lib in ncursesw ncurses curses ; do
-   

[PATCH 1/5] kbuild: do not display CHK for filechk

[Masahiro Yamada]

filechk displays two short logs; CHK for creating a temporary file,
and UPD for really updating the target.

IMHO, the build system can be quiet when the target file has not
been updated.

Signed-off-by: Masahiro Yamada 
---

 scripts/Kbuild.include | 1 -
 1 file changed, 1 deletion(-)

diff --git a/scripts/Kbuild.include b/scripts/Kbuild.include
index 50cee53..c7fedc5 100644
--- a/scripts/Kbuild.include
+++ b/scripts/Kbuild.include
@@ -57,7 +57,6 @@ kecho := $($(quiet)kecho)
 #   to specify a valid file as first prerequisite (often the kbuild file)
 define filechk
$(Q)set -e; \
-   $(kecho) '  CHK $@';\
mkdir -p $(dir $@); \
$(filechk_$(1)) < $< > $@.tmp;  \
if [ -r $@ ] && cmp -s $@ $@.tmp; then  \
-- 
2.7.4

[PATCH 4/5] kconfig: refactor ncurses package checks for building mconf

[Masahiro Yamada]

The mconf (or its infrastructure, lxdiaglog) depends on ncurses.
check-lxdialog.sh has additional checks in case pkg-config is not
available.  However, qconf and gconf already rely on pkg-config to
check necessary packages.  For simplification, drop the fallback
code from check-lxdialog.sh and move/rename to mconf-cfg.sh to
make it work in the same way as the other GUI frontends.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile   | 44 +-
 scripts/kconfig/lxdialog/check-lxdialog.sh | 93 --
 scripts/kconfig/lxdialog/dialog.h  |  2 +-
 scripts/kconfig/mconf-cfg.sh   | 24 
 4 files changed, 41 insertions(+), 122 deletions(-)
 delete mode 100755 scripts/kconfig/lxdialog/check-lxdialog.sh
 create mode 100755 scripts/kconfig/mconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index c222745..25a3d25 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -173,60 +173,48 @@ help:
@echo  '  xenconfig   - Enable additional options for xen dom0 and 
guest kernel support'
@echo  '  tinyconfig  - Configure the tiniest possible kernel'
 
-# lxdialog stuff
-check-lxdialog  := $(srctree)/$(src)/lxdialog/check-lxdialog.sh
-
-# Use recursively expanded variables so we do not call gcc unless
-# we really need to do so. (Do not call gcc as part of make mrproper)
-HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(check-lxdialog) -ccflags) \
--DLOCALE
-
 # ===
 # Shared Makefile for the various kconfig executables:
 # conf:  Used for defconfig, oldconfig and related targets
 # nconf:  Used for the nconfig target.
 # Utilizes ncurses
-# mconf:  Used for the menuconfig target
-# Utilizes the lxdialog package
 # object files used by all kconfig flavours
 
-lxdialog := lxdialog/checklist.o lxdialog/util.o lxdialog/inputbox.o
-lxdialog += lxdialog/textbox.o lxdialog/yesno.o lxdialog/menubox.o
-
 conf-objs  := conf.o  zconf.tab.o
-mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext
+hostprogs-y := conf nconf kxgettext
 
 targets+= zconf.lex.c
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
-# Check that we have the required ncurses stuff installed for lxdialog 
(menuconfig)
-PHONY += $(obj)/dochecklxdialog
-$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/dochecklxdialog
-$(obj)/dochecklxdialog:
-   $(Q)$(CONFIG_SHELL) $(check-lxdialog) -check $(HOSTCC) 
$(HOST_EXTRACFLAGS) $(HOSTLOADLIBES_mconf)
-
-always := dochecklxdialog
-
 # Add environment specific flags
-HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCC) $(HOSTCFLAGS))
-HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCXX) $(HOSTCXXFLAGS))
-
+HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCC) $(HOSTCFLAGS)) \
+   -DLOCALE
+HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) $(srctree)/$(src)/check.sh 
$(HOSTCXX) $(HOSTCXXFLAGS)) \
+   -DLOCALE
 # generated files seem to need this to find local include files
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_mconf   = $(shell $(CONFIG_SHELL) $(check-lxdialog) -ldflags 
$(HOSTCC))
-
 HOSTLOADLIBES_nconf= $(shell \
pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
|| pkg-config --libs menu panel ncurses 
2>/dev/null \
|| echo "-lmenu -lpanel -lncurses"  )
 
+# mconf: Used for the menuconfig target based on lxdialog
+hostprogs-y+= mconf
+lxdialog   := checklist.o inputbox.o menubox.o textbox.o util.o yesno.o
+mconf-objs := mconf.o zconf.tab.o $(addprefix lxdialog/, $(lxdialog))
+
+HOSTLOADLIBES_mconf = $(shell . $(obj)/.mconf-cfg && echo $$libs)
+$(foreach f, mconf.o $(lxdialog), \
+  $(eval HOSTCFLAGS_$f = $$(shell . $(obj)/.mconf-cfg && echo cflags)))
+
+$(addprefix $(obj)/, mconf.o $(lxdialog)): $(obj)/.mconf-cfg
+
 # qconf: Used for the xconfig target based on Qt
 hostprogs-y+= qconf
 qconf-cxxobjs  := qconf.o
diff --git a/scripts/kconfig/lxdialog/check-lxdialog.sh 
b/scripts/kconfig/lxdialog/check-lxdialog.sh
deleted file mode 100755
index 6c0bcd9..000
--- a/scripts/kconfig/lxdialog/check-lxdialog.sh
+++ /dev/null
@@ -1,93 +0,0 @@
-#!/bin/sh
-# SPDX-License-Identifier: GPL-2.0
-# Check ncurses compatibility
-
-# What library to link
-ldflags()
-{
-   pkg-config --libs ncursesw 2>/dev/null && exit
-   pkg-config --libs ncurses 2>/dev/null && exit
-   for ext in so a dll.a dylib ; do
-   for lib in ncursesw ncurses curses ; do
-   $cc 

[PATCH 0/5] kconfig: refactor package checks for GUI frontends

[Masahiro Yamada]

Kconfig supports 4 GUI frontends.
Each of them needs some support packages, but checks them differently:

  qconf, gconf: check packages in Makefile (pkg-config is required)
  mconf: lxdialog/check-lxdialog.sh
  nconf: needs ncurses, but its presence is not checked

This series refactor the package checks so that all of them work
in the same way.

The package check scripts have been moved to scripts/kconfig/*conf-cfg.sh

The motivation of this clean-up is Randy's following patch:
https://patchwork.kernel.org/patch/10277723/

I want to clean up existing code before adding more checks.



Masahiro Yamada (5):
  kbuild: do not display CHK for filechk
  kconfig: refactor Qt package checks for building qconf
  kconfig: refactor GTK+ package checks for building gconf
  kconfig: refactor ncurses package checks for building mconf
  kconfig: refactor ncurses package checks for building nconf

 scripts/Kbuild.include |   1 -
 scripts/kconfig/Makefile   | 160 ++---
 scripts/kconfig/gconf-cfg.sh   |  23 +
 scripts/kconfig/lxdialog/check-lxdialog.sh |  93 -
 scripts/kconfig/lxdialog/dialog.h  |   2 +-
 scripts/kconfig/mconf-cfg.sh   |  24 +
 scripts/kconfig/nconf-cfg.sh   |  22 
 scripts/kconfig/qconf-cfg.sh   |  25 +
 8 files changed, 148 insertions(+), 202 deletions(-)
 create mode 100755 scripts/kconfig/gconf-cfg.sh
 delete mode 100755 scripts/kconfig/lxdialog/check-lxdialog.sh
 create mode 100755 scripts/kconfig/mconf-cfg.sh
 create mode 100644 scripts/kconfig/nconf-cfg.sh
 create mode 100755 scripts/kconfig/qconf-cfg.sh

-- 
2.7.4

[PATCH 2/5] kconfig: refactor Qt package checks for building qconf

[Masahiro Yamada]

Currently, the necessary package checks for building qconf is
surrounded by ifeq ($(MAKECMDGOALS),xconfig) ... endif.
Then, Make will restart when .tmp_qtcheck is generated.

To simplify the Makefile, move the scripting to a separate file,
and use filechk.  The shell script is executed everytime xconfig
is run, but it is not a costly script.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 73 +---
 scripts/kconfig/qconf-cfg.sh | 25 +++
 2 files changed, 53 insertions(+), 45 deletions(-)
 create mode 100755 scripts/kconfig/qconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 5def877..e9a87bf 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -188,8 +188,6 @@ HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) 
$(check-lxdialog) -ccflags) \
 # Utilizes ncurses
 # mconf:  Used for the menuconfig target
 # Utilizes the lxdialog package
-# qconf:  Used for the xconfig target
-# Based on Qt which needs to be installed to compile it
 # gconf:  Used for the gconfig target
 # Based on GTK+ which needs to be installed to compile it
 # object files used by all kconfig flavours
@@ -201,14 +199,12 @@ conf-objs := conf.o  zconf.tab.o
 mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
-qconf-cxxobjs  := qconf.o
-qconf-objs := zconf.tab.o
 gconf-objs := gconf.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext qconf gconf
+hostprogs-y := conf nconf mconf kxgettext gconf
 
 targets+= zconf.lex.c
-clean-files:= qconf.moc .tmp_qtcheck .tmp_gtkcheck
+clean-files:= .tmp_gtkcheck
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
@@ -228,9 +224,6 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_qconf= $(KC_QT_LIBS)
-HOSTCXXFLAGS_qconf.o   = $(KC_QT_CFLAGS)
-
 HOSTLOADLIBES_gconf= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
 HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 gmodule-2.0 
libglade-2.0` \
   -Wno-missing-prototypes
@@ -241,34 +234,22 @@ HOSTLOADLIBES_nconf   = $(shell \
pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
|| pkg-config --libs menu panel ncurses 
2>/dev/null \
|| echo "-lmenu -lpanel -lncurses"  )
-$(obj)/qconf.o: $(obj)/.tmp_qtcheck
-
-ifeq ($(MAKECMDGOALS),xconfig)
-$(obj)/.tmp_qtcheck: $(src)/Makefile
--include $(obj)/.tmp_qtcheck
-
-# Qt needs some extra effort...
-$(obj)/.tmp_qtcheck:
-   @set -e; $(kecho) "  CHECK   qt"; \
-   if pkg-config --exists Qt5Core; then \
-   cflags="-std=c++11 -fPIC `pkg-config --cflags Qt5Core Qt5Gui 
Qt5Widgets`"; \
-   libs=`pkg-config --libs Qt5Core Qt5Gui Qt5Widgets`; \
-   moc=`pkg-config --variable=host_bins Qt5Core`/moc; \
-   elif pkg-config --exists QtCore; then \
-   cflags=`pkg-config --cflags QtCore QtGui`; \
-   libs=`pkg-config --libs QtCore QtGui`; \
-   moc=`pkg-config --variable=moc_location QtCore`; \
-   else \
-   echo >&2 "*"; \
-   echo >&2 "* Could not find Qt via pkg-config."; \
-   echo >&2 "* Please install either Qt 4.8 or 5.x. and make sure it's 
in PKG_CONFIG_PATH"; \
-   echo >&2 "*"; \
-   exit 1; \
-   fi; \
-   echo "KC_QT_CFLAGS=$$cflags" > $@; \
-   echo "KC_QT_LIBS=$$libs" >> $@; \
-   echo "KC_QT_MOC=$$moc" >> $@
-endif
+
+# qconf: Used for the xconfig target based on Qt
+hostprogs-y+= qconf
+qconf-cxxobjs  := qconf.o
+qconf-objs := zconf.tab.o
+
+HOSTLOADLIBES_qconf= $(shell . $(obj)/.qconf-cfg && echo $$libs)
+HOSTCXXFLAGS_qconf.o   = $(shell . $(obj)/.qconf-cfg && echo $$cflags)
+
+$(obj)/qconf.o: $(obj)/.qconf-cfg $(obj)/qconf.moc
+
+quiet_cmd_moc = MOC $@
+  cmd_moc = $(shell . $(obj)/.qconf-cfg && echo $$moc) -i $< -o $@
+
+$(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg
+   $(call cmd,moc)
 
 $(obj)/gconf.o: $(obj)/.tmp_gtkcheck
 
@@ -298,15 +279,17 @@ endif
 
 $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
-$(obj)/qconf.o: $(obj)/qconf.moc
-
-quiet_cmd_moc = MOC $@
-  cmd_moc = $(KC_QT_MOC) -i $< -o $@
-
-$(obj)/%.moc: $(src)/%.h $(obj)/.tmp_qtcheck
-   $(call cmd,moc)
-
 # Extract gconf menu items for i18n support
 $(obj)/gconf.glade.h: $(obj)/gconf.glade
$(Q)intltool-extract --type=gettext/glade --srcdir=$(srctree) \
$(obj)/gconf.glade
+
+# check if necessary packages are available, and configure build flags
+define filechk_conf_cfg
+   $(CONFIG_SHELL) $<
+endef
+
+$(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
+   $(call filechk,conf_cfg)
+

[PATCH 2/5] kconfig: refactor Qt package checks for building qconf

[Masahiro Yamada]

Currently, the necessary package checks for building qconf is
surrounded by ifeq ($(MAKECMDGOALS),xconfig) ... endif.
Then, Make will restart when .tmp_qtcheck is generated.

To simplify the Makefile, move the scripting to a separate file,
and use filechk.  The shell script is executed everytime xconfig
is run, but it is not a costly script.

Signed-off-by: Masahiro Yamada 
---

 scripts/kconfig/Makefile | 73 +---
 scripts/kconfig/qconf-cfg.sh | 25 +++
 2 files changed, 53 insertions(+), 45 deletions(-)
 create mode 100755 scripts/kconfig/qconf-cfg.sh

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 5def877..e9a87bf 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -188,8 +188,6 @@ HOST_EXTRACFLAGS += $(shell $(CONFIG_SHELL) 
$(check-lxdialog) -ccflags) \
 # Utilizes ncurses
 # mconf:  Used for the menuconfig target
 # Utilizes the lxdialog package
-# qconf:  Used for the xconfig target
-# Based on Qt which needs to be installed to compile it
 # gconf:  Used for the gconfig target
 # Based on GTK+ which needs to be installed to compile it
 # object files used by all kconfig flavours
@@ -201,14 +199,12 @@ conf-objs := conf.o  zconf.tab.o
 mconf-objs := mconf.o zconf.tab.o $(lxdialog)
 nconf-objs := nconf.o zconf.tab.o nconf.gui.o
 kxgettext-objs := kxgettext.o zconf.tab.o
-qconf-cxxobjs  := qconf.o
-qconf-objs := zconf.tab.o
 gconf-objs := gconf.o zconf.tab.o
 
-hostprogs-y := conf nconf mconf kxgettext qconf gconf
+hostprogs-y := conf nconf mconf kxgettext gconf
 
 targets+= zconf.lex.c
-clean-files:= qconf.moc .tmp_qtcheck .tmp_gtkcheck
+clean-files:= .tmp_gtkcheck
 clean-files+= gconf.glade.h
 clean-files += config.pot linux.pot
 
@@ -228,9 +224,6 @@ HOST_EXTRACXXFLAGS += $(shell $(CONFIG_SHELL) 
$(srctree)/$(src)/check.sh $(HOSTC
 HOSTCFLAGS_zconf.lex.o := -I$(src)
 HOSTCFLAGS_zconf.tab.o := -I$(src)
 
-HOSTLOADLIBES_qconf= $(KC_QT_LIBS)
-HOSTCXXFLAGS_qconf.o   = $(KC_QT_CFLAGS)
-
 HOSTLOADLIBES_gconf= `pkg-config --libs gtk+-2.0 gmodule-2.0 libglade-2.0`
 HOSTCFLAGS_gconf.o = `pkg-config --cflags gtk+-2.0 gmodule-2.0 
libglade-2.0` \
   -Wno-missing-prototypes
@@ -241,34 +234,22 @@ HOSTLOADLIBES_nconf   = $(shell \
pkg-config --libs menuw panelw ncursesw 
2>/dev/null \
|| pkg-config --libs menu panel ncurses 
2>/dev/null \
|| echo "-lmenu -lpanel -lncurses"  )
-$(obj)/qconf.o: $(obj)/.tmp_qtcheck
-
-ifeq ($(MAKECMDGOALS),xconfig)
-$(obj)/.tmp_qtcheck: $(src)/Makefile
--include $(obj)/.tmp_qtcheck
-
-# Qt needs some extra effort...
-$(obj)/.tmp_qtcheck:
-   @set -e; $(kecho) "  CHECK   qt"; \
-   if pkg-config --exists Qt5Core; then \
-   cflags="-std=c++11 -fPIC `pkg-config --cflags Qt5Core Qt5Gui 
Qt5Widgets`"; \
-   libs=`pkg-config --libs Qt5Core Qt5Gui Qt5Widgets`; \
-   moc=`pkg-config --variable=host_bins Qt5Core`/moc; \
-   elif pkg-config --exists QtCore; then \
-   cflags=`pkg-config --cflags QtCore QtGui`; \
-   libs=`pkg-config --libs QtCore QtGui`; \
-   moc=`pkg-config --variable=moc_location QtCore`; \
-   else \
-   echo >&2 "*"; \
-   echo >&2 "* Could not find Qt via pkg-config."; \
-   echo >&2 "* Please install either Qt 4.8 or 5.x. and make sure it's 
in PKG_CONFIG_PATH"; \
-   echo >&2 "*"; \
-   exit 1; \
-   fi; \
-   echo "KC_QT_CFLAGS=$$cflags" > $@; \
-   echo "KC_QT_LIBS=$$libs" >> $@; \
-   echo "KC_QT_MOC=$$moc" >> $@
-endif
+
+# qconf: Used for the xconfig target based on Qt
+hostprogs-y+= qconf
+qconf-cxxobjs  := qconf.o
+qconf-objs := zconf.tab.o
+
+HOSTLOADLIBES_qconf= $(shell . $(obj)/.qconf-cfg && echo $$libs)
+HOSTCXXFLAGS_qconf.o   = $(shell . $(obj)/.qconf-cfg && echo $$cflags)
+
+$(obj)/qconf.o: $(obj)/.qconf-cfg $(obj)/qconf.moc
+
+quiet_cmd_moc = MOC $@
+  cmd_moc = $(shell . $(obj)/.qconf-cfg && echo $$moc) -i $< -o $@
+
+$(obj)/%.moc: $(src)/%.h $(obj)/.qconf-cfg
+   $(call cmd,moc)
 
 $(obj)/gconf.o: $(obj)/.tmp_gtkcheck
 
@@ -298,15 +279,17 @@ endif
 
 $(obj)/zconf.tab.o: $(obj)/zconf.lex.c
 
-$(obj)/qconf.o: $(obj)/qconf.moc
-
-quiet_cmd_moc = MOC $@
-  cmd_moc = $(KC_QT_MOC) -i $< -o $@
-
-$(obj)/%.moc: $(src)/%.h $(obj)/.tmp_qtcheck
-   $(call cmd,moc)
-
 # Extract gconf menu items for i18n support
 $(obj)/gconf.glade.h: $(obj)/gconf.glade
$(Q)intltool-extract --type=gettext/glade --srcdir=$(srctree) \
$(obj)/gconf.glade
+
+# check if necessary packages are available, and configure build flags
+define filechk_conf_cfg
+   $(CONFIG_SHELL) $<
+endef
+
+$(obj)/.%conf-cfg: $(src)/%conf-cfg.sh FORCE
+   $(call filechk,conf_cfg)
+
+clean-files += .*conf-cfg
diff --git 

[PATCH v2 7/7] memcg: supports movement of surplus hugepages statistics

[TSUKADA Koutaro]

When the task that charged surplus hugepages moves memory cgroup, it
updates the statistical information correctly.

Signed-off-by: TSUKADA Koutaro 
---
 memcontrol.c |   99 +++
 1 file changed, 99 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a8f1ff8..63f0922 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4698,12 +4698,110 @@ static int mem_cgroup_count_precharge_pte_range(pmd_t 
*pmd,
return 0;
 }

+#ifdef CONFIG_HUGETLB_PAGE
+static enum mc_target_type get_mctgt_type_hugetlb(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *pte, union mc_target *target)
+{
+   struct page *page = NULL;
+   pte_t entry;
+   enum mc_target_type ret = MC_TARGET_NONE;
+
+   if (!(mc.flags & MOVE_ANON))
+   return ret;
+
+   entry = huge_ptep_get(pte);
+   if (!pte_present(entry))
+   return ret;
+
+   page = pte_page(entry);
+   VM_BUG_ON_PAGE(!page || !PageHead(page), page);
+   if (likely(!PageSurplusCharge(page)))
+   return ret;
+   if (page->mem_cgroup == mc.from) {
+   ret = MC_TARGET_PAGE;
+   if (target) {
+   get_page(page);
+   target->page = page;
+   }
+   }
+
+   return ret;
+}
+
+static int hugetlb_count_precharge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk->vma;
+   struct mm_struct *mm = walk->mm;
+   spinlock_t *ptl;
+   union mc_target target;
+
+   ptl = huge_pte_lock(hstate_vma(vma), mm, pte);
+   if (get_mctgt_type_hugetlb(vma, addr, pte, ) == MC_TARGET_PAGE) {
+   mc.precharge += (1 << compound_order(target.page));
+   put_page(target.page);
+   }
+   spin_unlock(ptl);
+
+   return 0;
+}
+
+static int hugetlb_move_charge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk->vma;
+   struct mm_struct *mm = walk->mm;
+   spinlock_t *ptl;
+   enum mc_target_type target_type;
+   union mc_target target;
+   struct page *page;
+   unsigned long nr_pages;
+
+   ptl = huge_pte_lock(hstate_vma(vma), mm, pte);
+   target_type = get_mctgt_type_hugetlb(vma, addr, pte, );
+   if (target_type == MC_TARGET_PAGE) {
+   page = target.page;
+   nr_pages = (1 << compound_order(page));
+   if (mc.precharge < nr_pages) {
+   put_page(page);
+   goto unlock;
+   }
+   if (!mem_cgroup_move_account(page, true, mc.from, mc.to)) {
+   mc.precharge -= nr_pages;
+   mc.moved_charge += nr_pages;
+   }
+   put_page(page);
+   }
+unlock:
+   spin_unlock(ptl);
+
+   return 0;
+}
+#else
+static int hugetlb_count_precharge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   return 0;
+}
+
+static int hugetlb_move_charge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   return 0;
+}
+#endif
+
 static unsigned long mem_cgroup_count_precharge(struct mm_struct *mm)
 {
unsigned long precharge;

struct mm_walk mem_cgroup_count_precharge_walk = {
.pmd_entry = mem_cgroup_count_precharge_pte_range,
+   .hugetlb_entry = hugetlb_count_precharge_pte_range,
.mm = mm,
};
down_read(>mmap_sem);
@@ -4981,6 +5079,7 @@ static void mem_cgroup_move_charge(void)
 {
struct mm_walk mem_cgroup_move_charge_walk = {
.pmd_entry = mem_cgroup_move_charge_pte_range,
+   .hugetlb_entry = hugetlb_move_charge_pte_range,
.mm = mc.mm,
};

-- 
Tsukada

[PATCH v2 7/7] memcg: supports movement of surplus hugepages statistics

[TSUKADA Koutaro]

When the task that charged surplus hugepages moves memory cgroup, it
updates the statistical information correctly.

Signed-off-by: TSUKADA Koutaro 
---
 memcontrol.c |   99 +++
 1 file changed, 99 insertions(+)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index a8f1ff8..63f0922 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4698,12 +4698,110 @@ static int mem_cgroup_count_precharge_pte_range(pmd_t 
*pmd,
return 0;
 }

+#ifdef CONFIG_HUGETLB_PAGE
+static enum mc_target_type get_mctgt_type_hugetlb(struct vm_area_struct *vma,
+   unsigned long addr, pte_t *pte, union mc_target *target)
+{
+   struct page *page = NULL;
+   pte_t entry;
+   enum mc_target_type ret = MC_TARGET_NONE;
+
+   if (!(mc.flags & MOVE_ANON))
+   return ret;
+
+   entry = huge_ptep_get(pte);
+   if (!pte_present(entry))
+   return ret;
+
+   page = pte_page(entry);
+   VM_BUG_ON_PAGE(!page || !PageHead(page), page);
+   if (likely(!PageSurplusCharge(page)))
+   return ret;
+   if (page->mem_cgroup == mc.from) {
+   ret = MC_TARGET_PAGE;
+   if (target) {
+   get_page(page);
+   target->page = page;
+   }
+   }
+
+   return ret;
+}
+
+static int hugetlb_count_precharge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk->vma;
+   struct mm_struct *mm = walk->mm;
+   spinlock_t *ptl;
+   union mc_target target;
+
+   ptl = huge_pte_lock(hstate_vma(vma), mm, pte);
+   if (get_mctgt_type_hugetlb(vma, addr, pte, ) == MC_TARGET_PAGE) {
+   mc.precharge += (1 << compound_order(target.page));
+   put_page(target.page);
+   }
+   spin_unlock(ptl);
+
+   return 0;
+}
+
+static int hugetlb_move_charge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   struct vm_area_struct *vma = walk->vma;
+   struct mm_struct *mm = walk->mm;
+   spinlock_t *ptl;
+   enum mc_target_type target_type;
+   union mc_target target;
+   struct page *page;
+   unsigned long nr_pages;
+
+   ptl = huge_pte_lock(hstate_vma(vma), mm, pte);
+   target_type = get_mctgt_type_hugetlb(vma, addr, pte, );
+   if (target_type == MC_TARGET_PAGE) {
+   page = target.page;
+   nr_pages = (1 << compound_order(page));
+   if (mc.precharge < nr_pages) {
+   put_page(page);
+   goto unlock;
+   }
+   if (!mem_cgroup_move_account(page, true, mc.from, mc.to)) {
+   mc.precharge -= nr_pages;
+   mc.moved_charge += nr_pages;
+   }
+   put_page(page);
+   }
+unlock:
+   spin_unlock(ptl);
+
+   return 0;
+}
+#else
+static int hugetlb_count_precharge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   return 0;
+}
+
+static int hugetlb_move_charge_pte_range(pte_t *pte, unsigned long hmask,
+   unsigned long addr, unsigned long end,
+   struct mm_walk *walk)
+{
+   return 0;
+}
+#endif
+
 static unsigned long mem_cgroup_count_precharge(struct mm_struct *mm)
 {
unsigned long precharge;

struct mm_walk mem_cgroup_count_precharge_walk = {
.pmd_entry = mem_cgroup_count_precharge_pte_range,
+   .hugetlb_entry = hugetlb_count_precharge_pte_range,
.mm = mm,
};
down_read(>mmap_sem);
@@ -4981,6 +5079,7 @@ static void mem_cgroup_move_charge(void)
 {
struct mm_walk mem_cgroup_move_charge_walk = {
.pmd_entry = mem_cgroup_move_charge_pte_range,
+   .hugetlb_entry = hugetlb_move_charge_pte_range,
.mm = mc.mm,
};

-- 
Tsukada

[PATCH v2 6/7] Documentation, hugetlb: describe about charge_surplus_hugepages,

[TSUKADA Koutaro]

Add a description about charge_surplus_hugepages.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlbpage.txt |6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index faf077d..af8d112 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -129,6 +129,11 @@ number of "surplus" huge pages from the kernel's normal 
page pool, when the
 persistent huge page pool is exhausted. As these surplus huge pages become
 unused, they are freed back to the kernel's normal page pool.

+/proc/sys/vm/charge_surplus_hugepages indicates to charge "surplus" huge pages
+obteined from the normal page pool to memory cgroup. If true, the amount to be
+overcommitted is limited within memory usage allowed by the memory cgroup to
+which the task belongs. The default value is false.
+
 When increasing the huge page pool size via nr_hugepages, any existing surplus
 pages will first be promoted to persistent huge pages.  Then, additional
 huge pages will be allocated, if necessary and if possible, to fulfill
@@ -169,6 +174,7 @@ Inside each of these directories, the same set of files 
will exist:
free_hugepages
resv_hugepages
surplus_hugepages
+   charge_surplus_hugepages

 which function as described above for the default huge page-sized case.

-- 
Tsukada

[PATCH v2 6/7] Documentation, hugetlb: describe about charge_surplus_hugepages,

[TSUKADA Koutaro]

Add a description about charge_surplus_hugepages.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlbpage.txt |6 ++
 1 file changed, 6 insertions(+)

diff --git a/Documentation/vm/hugetlbpage.txt b/Documentation/vm/hugetlbpage.txt
index faf077d..af8d112 100644
--- a/Documentation/vm/hugetlbpage.txt
+++ b/Documentation/vm/hugetlbpage.txt
@@ -129,6 +129,11 @@ number of "surplus" huge pages from the kernel's normal 
page pool, when the
 persistent huge page pool is exhausted. As these surplus huge pages become
 unused, they are freed back to the kernel's normal page pool.

+/proc/sys/vm/charge_surplus_hugepages indicates to charge "surplus" huge pages
+obteined from the normal page pool to memory cgroup. If true, the amount to be
+overcommitted is limited within memory usage allowed by the memory cgroup to
+which the task belongs. The default value is false.
+
 When increasing the huge page pool size via nr_hugepages, any existing surplus
 pages will first be promoted to persistent huge pages.  Then, additional
 huge pages will be allocated, if necessary and if possible, to fulfill
@@ -169,6 +174,7 @@ Inside each of these directories, the same set of files 
will exist:
free_hugepages
resv_hugepages
surplus_hugepages
+   charge_surplus_hugepages

 which function as described above for the default huge page-sized case.

-- 
Tsukada

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Ian Kent]

On 18/05/18 12:23, Randy Dunlap wrote:
> On 05/17/2018 08:50 PM, Ian Kent wrote:
>> On 18/05/18 08:21, Randy Dunlap wrote:
>>> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to

http://www.ozlabs.org/~akpm/mmotm/

 mmotm-readme.txt says

 README for mm-of-the-moment:

 http://www.ozlabs.org/~akpm/mmotm/

 This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
 more than once a week.

 You will need quilt to apply these patches to the latest Linus release (4.x
 or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
 http://ozlabs.org/~akpm/mmotm/series

 The file broken-out.tar.gz contains two datestamp files: .DATE and
 .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
 followed by the base kernel version against which this patch series is to
 be applied.

 This tree is partially included in linux-next.  To see which patches are
 included in linux-next, consult the `series' file.  Only the patches
 within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
 linux-next.

 A git tree which contains the memory management portion of this tree is
 maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
 by Michal Hocko.  It contains the patches which are between the
 "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
 file, http://www.ozlabs.org/~akpm/mmotm/series.


 A full copy of the full kernel tree with the linux-next and mmotm patches
 already applied is available through git within an hour of the mmotm
 release.  Individual mmotm releases are tagged.  The master branch always
 points to the latest release, so it's constantly rebasing.
>>>
>>>
>>> on x86_64: with (randconfig):
>>> CONFIG_AUTOFS_FS=y
>>> CONFIG_AUTOFS4_FS=y
>>
>> Oh right, I need to make these exclusive.
>>
>> I seem to remember trying to do that along the way, can't remember why
>> I didn't do it in the end.
>>
>> Any suggestions about potential problems when doing it?
> 
> I think that just using "depends on" for each of them will cause kconfig to
> complain about circular dependencies, so probably using "choice" will be
> needed.  Or (since this is just temporary?) just say "don't do that."
> 

No doubt that was what happened, unfortunately I forgot to return to it.

Right, a conditional with a message should work  thanks.

Ian

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Ian Kent]

On 18/05/18 12:23, Randy Dunlap wrote:
> On 05/17/2018 08:50 PM, Ian Kent wrote:
>> On 18/05/18 08:21, Randy Dunlap wrote:
>>> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
 The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to

http://www.ozlabs.org/~akpm/mmotm/

 mmotm-readme.txt says

 README for mm-of-the-moment:

 http://www.ozlabs.org/~akpm/mmotm/

 This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
 more than once a week.

 You will need quilt to apply these patches to the latest Linus release (4.x
 or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
 http://ozlabs.org/~akpm/mmotm/series

 The file broken-out.tar.gz contains two datestamp files: .DATE and
 .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
 followed by the base kernel version against which this patch series is to
 be applied.

 This tree is partially included in linux-next.  To see which patches are
 included in linux-next, consult the `series' file.  Only the patches
 within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
 linux-next.

 A git tree which contains the memory management portion of this tree is
 maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
 by Michal Hocko.  It contains the patches which are between the
 "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
 file, http://www.ozlabs.org/~akpm/mmotm/series.


 A full copy of the full kernel tree with the linux-next and mmotm patches
 already applied is available through git within an hour of the mmotm
 release.  Individual mmotm releases are tagged.  The master branch always
 points to the latest release, so it's constantly rebasing.
>>>
>>>
>>> on x86_64: with (randconfig):
>>> CONFIG_AUTOFS_FS=y
>>> CONFIG_AUTOFS4_FS=y
>>
>> Oh right, I need to make these exclusive.
>>
>> I seem to remember trying to do that along the way, can't remember why
>> I didn't do it in the end.
>>
>> Any suggestions about potential problems when doing it?
> 
> I think that just using "depends on" for each of them will cause kconfig to
> complain about circular dependencies, so probably using "choice" will be
> needed.  Or (since this is just temporary?) just say "don't do that."
> 

No doubt that was what happened, unfortunately I forgot to return to it.

Right, a conditional with a message should work  thanks.

Ian

[PATCH v2 5/7] hugetlb: add charge_surplus_hugepages attribute

[TSUKADA Koutaro]

Add an entry for charge_surplus_hugepages to sysfs.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlb.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9a9549c..2f9bdbc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2662,6 +2662,30 @@ static ssize_t surplus_hugepages_show(struct kobject 
*kobj,
 }
 HSTATE_ATTR_RO(surplus_hugepages);

+static ssize_t charge_surplus_hugepages_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   struct hstate *h = kobj_to_hstate(kobj, NULL);
+   return sprintf(buf, "%d\n", h->charge_surplus_huge_pages);
+}
+
+static ssize_t charge_surplus_hugepages_store(struct kobject *kobj,
+   struct kobj_attribute *attr, const char *buf, size_t len)
+{
+   int err;
+   unsigned long input;
+   struct hstate *h = kobj_to_hstate(kobj, NULL);
+
+   err = kstrtoul(buf, 10, );
+   if (err)
+   return err;
+
+   h->charge_surplus_huge_pages = input ? true : false;
+
+   return len;
+}
+HSTATE_ATTR(charge_surplus_hugepages);
+
 static struct attribute *hstate_attrs[] = {
_hugepages_attr.attr,
_overcommit_hugepages_attr.attr,
@@ -2671,6 +2695,7 @@ static ssize_t surplus_hugepages_show(struct kobject 
*kobj,
 #ifdef CONFIG_NUMA
_hugepages_mempolicy_attr.attr,
 #endif
+   _surplus_hugepages_attr.attr,
NULL,
 };

-- 
Tsukada

[PATCH v2 5/7] hugetlb: add charge_surplus_hugepages attribute

[TSUKADA Koutaro]

Add an entry for charge_surplus_hugepages to sysfs.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlb.c |   25 +
 1 file changed, 25 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 9a9549c..2f9bdbc 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -2662,6 +2662,30 @@ static ssize_t surplus_hugepages_show(struct kobject 
*kobj,
 }
 HSTATE_ATTR_RO(surplus_hugepages);

+static ssize_t charge_surplus_hugepages_show(struct kobject *kobj,
+   struct kobj_attribute *attr, char *buf)
+{
+   struct hstate *h = kobj_to_hstate(kobj, NULL);
+   return sprintf(buf, "%d\n", h->charge_surplus_huge_pages);
+}
+
+static ssize_t charge_surplus_hugepages_store(struct kobject *kobj,
+   struct kobj_attribute *attr, const char *buf, size_t len)
+{
+   int err;
+   unsigned long input;
+   struct hstate *h = kobj_to_hstate(kobj, NULL);
+
+   err = kstrtoul(buf, 10, );
+   if (err)
+   return err;
+
+   h->charge_surplus_huge_pages = input ? true : false;
+
+   return len;
+}
+HSTATE_ATTR(charge_surplus_hugepages);
+
 static struct attribute *hstate_attrs[] = {
_hugepages_attr.attr,
_overcommit_hugepages_attr.attr,
@@ -2671,6 +2695,7 @@ static ssize_t surplus_hugepages_show(struct kobject 
*kobj,
 #ifdef CONFIG_NUMA
_hugepages_mempolicy_attr.attr,
 #endif
+   _surplus_hugepages_attr.attr,
NULL,
 };

-- 
Tsukada

[PATCH v2 4/7] mm, sysctl: make charging surplus hugepages controllable

[TSUKADA Koutaro]

Make the default hugetlb surplus hugepage controlable by
/proc/sys/vm/charge_surplus_hugepages.

Signed-off-by: TSUKADA Koutaro 
---
 include/linux/hugetlb.h |2 ++
 kernel/sysctl.c |7 +++
 mm/hugetlb.c|   21 +
 3 files changed, 30 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 33fe5be..9314b07 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -80,6 +80,8 @@ struct hugepage_subpool *hugepage_new_subpool(struct hstate 
*h, long max_hpages,
 void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
 int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, 
loff_t *);
 int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t 
*, loff_t *);
+int hugetlb_charge_surplus_handler(struct ctl_table *, int, void __user *,
+   size_t *, loff_t *);
 int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, 
size_t *, loff_t *);

 #ifdef CONFIG_NUMA
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6a78cf7..d562d64 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1394,6 +1394,13 @@ static int sysrq_sysctl_handler(struct ctl_table *table, 
int write,
.mode   = 0644,
.proc_handler   = hugetlb_overcommit_handler,
},
+   {
+   .procname   = "charge_surplus_hugepages",
+   .data   = NULL,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = hugetlb_charge_surplus_handler,
+   },
 #endif
{
.procname   = "lowmem_reserve_ratio",
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2e7b543..9a9549c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3069,6 +3069,27 @@ int hugetlb_overcommit_handler(struct ctl_table *table, 
int write,
return ret;
 }

+int hugetlb_charge_surplus_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos)
+{
+   struct hstate *h = _hstate;
+   int tmp, ret;
+
+   if (!hugepages_supported())
+   return -EOPNOTSUPP;
+
+   tmp = h->charge_surplus_huge_pages ? 1 : 0;
+   table->data = 
+   table->maxlen = sizeof(int);
+   ret = proc_dointvec_minmax(table, write, buffer, length, ppos);
+   if (ret)
+   goto out;
+
+   if (write)
+   h->charge_surplus_huge_pages = tmp ? true : false;
+out:
+   return ret;
+}
 #endif /* CONFIG_SYSCTL */

 void hugetlb_report_meminfo(struct seq_file *m)

--
Tsukada

[PATCH v2 4/7] mm, sysctl: make charging surplus hugepages controllable

[TSUKADA Koutaro]

Make the default hugetlb surplus hugepage controlable by
/proc/sys/vm/charge_surplus_hugepages.

Signed-off-by: TSUKADA Koutaro 
---
 include/linux/hugetlb.h |2 ++
 kernel/sysctl.c |7 +++
 mm/hugetlb.c|   21 +
 3 files changed, 30 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 33fe5be..9314b07 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -80,6 +80,8 @@ struct hugepage_subpool *hugepage_new_subpool(struct hstate 
*h, long max_hpages,
 void reset_vma_resv_huge_pages(struct vm_area_struct *vma);
 int hugetlb_sysctl_handler(struct ctl_table *, int, void __user *, size_t *, 
loff_t *);
 int hugetlb_overcommit_handler(struct ctl_table *, int, void __user *, size_t 
*, loff_t *);
+int hugetlb_charge_surplus_handler(struct ctl_table *, int, void __user *,
+   size_t *, loff_t *);
 int hugetlb_treat_movable_handler(struct ctl_table *, int, void __user *, 
size_t *, loff_t *);

 #ifdef CONFIG_NUMA
diff --git a/kernel/sysctl.c b/kernel/sysctl.c
index 6a78cf7..d562d64 100644
--- a/kernel/sysctl.c
+++ b/kernel/sysctl.c
@@ -1394,6 +1394,13 @@ static int sysrq_sysctl_handler(struct ctl_table *table, 
int write,
.mode   = 0644,
.proc_handler   = hugetlb_overcommit_handler,
},
+   {
+   .procname   = "charge_surplus_hugepages",
+   .data   = NULL,
+   .maxlen = sizeof(int),
+   .mode   = 0644,
+   .proc_handler   = hugetlb_charge_surplus_handler,
+   },
 #endif
{
.procname   = "lowmem_reserve_ratio",
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2e7b543..9a9549c 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -3069,6 +3069,27 @@ int hugetlb_overcommit_handler(struct ctl_table *table, 
int write,
return ret;
 }

+int hugetlb_charge_surplus_handler(struct ctl_table *table, int write,
+   void __user *buffer, size_t *length, loff_t *ppos)
+{
+   struct hstate *h = _hstate;
+   int tmp, ret;
+
+   if (!hugepages_supported())
+   return -EOPNOTSUPP;
+
+   tmp = h->charge_surplus_huge_pages ? 1 : 0;
+   table->data = 
+   table->maxlen = sizeof(int);
+   ret = proc_dointvec_minmax(table, write, buffer, length, ppos);
+   if (ret)
+   goto out;
+
+   if (write)
+   h->charge_surplus_huge_pages = tmp ? true : false;
+out:
+   return ret;
+}
 #endif /* CONFIG_SYSCTL */

 void hugetlb_report_meminfo(struct seq_file *m)

--
Tsukada

[PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

[TSUKADA Koutaro]

The current memcg implementation assumes that the compound page is THP.
In order to be able to charge surplus hugepage, we use compound_order.

Signed-off-by: TSUKADA Koutaro 
---
 memcontrol.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2bd3df3..a8f1ff8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4483,7 +4483,7 @@ static int mem_cgroup_move_account(struct page *page,
   struct mem_cgroup *to)
 {
unsigned long flags;
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;
int ret;
bool anon;

@@ -5417,7 +5417,7 @@ int mem_cgroup_try_charge(struct page *page, struct 
mm_struct *mm,
  bool compound)
 {
struct mem_cgroup *memcg = NULL;
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;
int ret = 0;

if (mem_cgroup_disabled())
@@ -5478,7 +5478,7 @@ int mem_cgroup_try_charge(struct page *page, struct 
mm_struct *mm,
 void mem_cgroup_commit_charge(struct page *page, struct mem_cgroup *memcg,
  bool lrucare, bool compound)
 {
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;

VM_BUG_ON_PAGE(!page->mapping, page);
VM_BUG_ON_PAGE(PageLRU(page) && !lrucare, page);
@@ -5522,7 +5522,7 @@ void mem_cgroup_commit_charge(struct page *page, struct 
mem_cgroup *memcg,
 void mem_cgroup_cancel_charge(struct page *page, struct mem_cgroup *memcg,
bool compound)
 {
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;

if (mem_cgroup_disabled())
return;
@@ -5729,7 +5729,7 @@ void mem_cgroup_migrate(struct page *oldpage, struct page 
*newpage)

/* Force-charge the new page. The old one will be freed soon */
compound = PageTransHuge(newpage);
-   nr_pages = compound ? hpage_nr_pages(newpage) : 1;
+   nr_pages = compound ? (1 << compound_order(newpage)) : 1;

page_counter_charge(>memory, nr_pages);
if (do_memsw_account())

-- 
Tsukada

[PATCH v2 3/7] memcg: use compound_order rather than hpage_nr_pages

[TSUKADA Koutaro]

The current memcg implementation assumes that the compound page is THP.
In order to be able to charge surplus hugepage, we use compound_order.

Signed-off-by: TSUKADA Koutaro 
---
 memcontrol.c |   10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/mm/memcontrol.c b/mm/memcontrol.c
index 2bd3df3..a8f1ff8 100644
--- a/mm/memcontrol.c
+++ b/mm/memcontrol.c
@@ -4483,7 +4483,7 @@ static int mem_cgroup_move_account(struct page *page,
   struct mem_cgroup *to)
 {
unsigned long flags;
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;
int ret;
bool anon;

@@ -5417,7 +5417,7 @@ int mem_cgroup_try_charge(struct page *page, struct 
mm_struct *mm,
  bool compound)
 {
struct mem_cgroup *memcg = NULL;
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;
int ret = 0;

if (mem_cgroup_disabled())
@@ -5478,7 +5478,7 @@ int mem_cgroup_try_charge(struct page *page, struct 
mm_struct *mm,
 void mem_cgroup_commit_charge(struct page *page, struct mem_cgroup *memcg,
  bool lrucare, bool compound)
 {
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;

VM_BUG_ON_PAGE(!page->mapping, page);
VM_BUG_ON_PAGE(PageLRU(page) && !lrucare, page);
@@ -5522,7 +5522,7 @@ void mem_cgroup_commit_charge(struct page *page, struct 
mem_cgroup *memcg,
 void mem_cgroup_cancel_charge(struct page *page, struct mem_cgroup *memcg,
bool compound)
 {
-   unsigned int nr_pages = compound ? hpage_nr_pages(page) : 1;
+   unsigned int nr_pages = compound ? (1 << compound_order(page)) : 1;

if (mem_cgroup_disabled())
return;
@@ -5729,7 +5729,7 @@ void mem_cgroup_migrate(struct page *oldpage, struct page 
*newpage)

/* Force-charge the new page. The old one will be freed soon */
compound = PageTransHuge(newpage);
-   nr_pages = compound ? hpage_nr_pages(newpage) : 1;
+   nr_pages = compound ? (1 << compound_order(newpage)) : 1;

page_counter_charge(>memory, nr_pages);
if (do_memsw_account())

-- 
Tsukada

Re: [PATCH 1/2] perf script: Show virtual addresses instead of offsets

[Ravi Bangoria]

Arnaldo,

We already have a binary offset handy in perf code but there is no way to
dump it with perf script. We can derive it from symname+symoff but that's
a manual work.

Will it be good to have a '-F binoff' option?

Ravi


On 05/18/2018 01:29 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 17, 2018 at 12:03:25PM +0530, Sandipan Das escreveu:
>> When perf data is recorded with the call-graph option enabled,
>> the callchain shown by perf script shows the binary offsets of
>> the symbols as the ip. This is incorrect for kernel symbols as
>> the ip values are always off by a fixed offset depending on the
>> architecture. If the offsets from the start of the symbols are
>> printed, they are also incorrect for both kernel and userspace
>> symbols.
>>
>> Without the call-graph option, the callchain shows the virtual
>> addresses of the symbols rather than their binary offsets. The
>> offsets printed in this case are also correct.
>>
>> This fixes the inconsistency in perf script's output.
> 
> Thanks, tested and applied,
> 
> - Arnaldo
> 

Re: [PATCH 1/2] perf script: Show virtual addresses instead of offsets

[Ravi Bangoria]

Arnaldo,

We already have a binary offset handy in perf code but there is no way to
dump it with perf script. We can derive it from symname+symoff but that's
a manual work.

Will it be good to have a '-F binoff' option?

Ravi


On 05/18/2018 01:29 AM, Arnaldo Carvalho de Melo wrote:
> Em Thu, May 17, 2018 at 12:03:25PM +0530, Sandipan Das escreveu:
>> When perf data is recorded with the call-graph option enabled,
>> the callchain shown by perf script shows the binary offsets of
>> the symbols as the ip. This is incorrect for kernel symbols as
>> the ip values are always off by a fixed offset depending on the
>> architecture. If the offsets from the start of the symbols are
>> printed, they are also incorrect for both kernel and userspace
>> symbols.
>>
>> Without the call-graph option, the callchain shows the virtual
>> addresses of the symbols rather than their binary offsets. The
>> offsets printed in this case are also correct.
>>
>> This fixes the inconsistency in perf script's output.
> 
> Thanks, tested and applied,
> 
> - Arnaldo
> 

[PATCH v2 2/7] hugetlb: support migrate charging for surplus hugepages

[TSUKADA Koutaro]

Surplus hugepages allocated for migration also charge to memory cgroup.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlb.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 679c151f..2e7b543 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1687,6 +1687,8 @@ static struct page *alloc_migrate_huge_page(struct hstate 
*h, gfp_t gfp_mask,
if (!page)
return NULL;

+   surplus_hugepage_set_charge(h, page);
+
/*
 * We do not account these pages as surplus because they are only
 * temporary and will be released properly on the last reference

-- 
Tsukada

[PATCH v2 2/7] hugetlb: support migrate charging for surplus hugepages

[TSUKADA Koutaro]

Surplus hugepages allocated for migration also charge to memory cgroup.

Signed-off-by: TSUKADA Koutaro 
---
 hugetlb.c |2 ++
 1 file changed, 2 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 679c151f..2e7b543 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -1687,6 +1687,8 @@ static struct page *alloc_migrate_huge_page(struct hstate 
*h, gfp_t gfp_mask,
if (!page)
return NULL;

+   surplus_hugepage_set_charge(h, page);
+
/*
 * We do not account these pages as surplus because they are only
 * temporary and will be released properly on the last reference

-- 
Tsukada

[PATCH v2 1/7] hugetlb: introduce charge_surplus_huge_pages to struct hstate

[TSUKADA Koutaro]

The charge_surplus_huge_pages indicates to charge surplus huge pages
obteined from the normal page pool to memory cgroup. The default value is
false.

This patch implements the core part of charging surplus hugepages. Use the
private and mem_cgroup member of the second entry of compound hugepage for
surplus hugepage charging.

Mark when surplus hugepage is obtained from normal pool, and charge to
memory cgroup at alloc_huge_page. Once the mapping of the page is decided,
commit the charge. surplus hugepages will uncharge or cancel at
free_huge_page.

Signed-off-by: TSUKADA Koutaro 
---
 include/linux/hugetlb.h |2
 mm/hugetlb.c|  100 
 2 files changed, 102 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 36fa6a2..33fe5be 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -158,6 +158,7 @@ unsigned long hugetlb_change_protection(struct 
vm_area_struct *vma,
unsigned long address, unsigned long end, pgprot_t newprot);

 bool is_hugetlb_entry_migration(pte_t pte);
+bool PageSurplusCharge(struct page *page);

 #else /* !CONFIG_HUGETLB_PAGE */

@@ -338,6 +339,7 @@ struct hstate {
unsigned int nr_huge_pages_node[MAX_NUMNODES];
unsigned int free_huge_pages_node[MAX_NUMNODES];
unsigned int surplus_huge_pages_node[MAX_NUMNODES];
+   bool charge_surplus_huge_pages; /* default to off */
 #ifdef CONFIG_CGROUP_HUGETLB
/* cgroup control files */
struct cftype cgroup_files[5];
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2186791..679c151f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"

 int hugetlb_max_hstate __read_mostly;
@@ -1236,6 +1237,90 @@ static inline void ClearPageHugeTemporary(struct page 
*page)
page[2].mapping = NULL;
 }

+#define HUGETLB_SURPLUS_CHARGE 1UL
+
+bool PageSurplusCharge(struct page *page)
+{
+   if (!PageHuge(page))
+   return false;
+   return page[1].private == HUGETLB_SURPLUS_CHARGE;
+}
+
+static inline void SetPageSurplusCharge(struct page *page)
+{
+   page[1].private = HUGETLB_SURPLUS_CHARGE;
+}
+
+static inline void ClearPageSurplusCharge(struct page *page)
+{
+   page[1].private = 0;
+}
+
+static inline void
+set_surplus_hugepage_memcg(struct page *page, struct mem_cgroup *memcg)
+{
+   page[1].mem_cgroup = memcg;
+}
+
+static inline struct mem_cgroup *get_surplus_hugepage_memcg(struct page *page)
+{
+   return page[1].mem_cgroup;
+}
+
+static void surplus_hugepage_set_charge(struct hstate *h, struct page *page)
+{
+   if (likely(!h->charge_surplus_huge_pages))
+   return;
+   if (unlikely(!page))
+   return;
+   SetPageSurplusCharge(page);
+}
+
+static int surplus_hugepage_try_charge(struct page *page, struct mm_struct *mm)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return 0;
+
+   if (mem_cgroup_try_charge(page, mm, GFP_KERNEL, , true)) {
+   /* mem_cgroup oom invoked */
+   ClearPageSurplusCharge(page);
+   return -ENOMEM;
+   }
+   set_surplus_hugepage_memcg(page, memcg);
+
+   return 0;
+}
+
+static void surplus_hugepage_commit_charge(struct page *page)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return;
+
+   memcg = get_surplus_hugepage_memcg(page);
+   mem_cgroup_commit_charge(page, memcg, false, true);
+   set_surplus_hugepage_memcg(page, NULL);
+}
+
+static void surplus_hugepage_finalize_charge(struct page *page)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return;
+
+   memcg = get_surplus_hugepage_memcg(page);
+   if (memcg)
+   mem_cgroup_cancel_charge(page, memcg, true);
+   else
+   mem_cgroup_uncharge(page);
+   set_surplus_hugepage_memcg(page, NULL);
+   ClearPageSurplusCharge(page);
+}
+
 void free_huge_page(struct page *page)
 {
/*
@@ -1248,6 +1333,8 @@ void free_huge_page(struct page *page)
(struct hugepage_subpool *)page_private(page);
bool restore_reserve;

+   surplus_hugepage_finalize_charge(page);
+
set_page_private(page, 0);
page->mapping = NULL;
VM_BUG_ON_PAGE(page_count(page), page);
@@ -1583,6 +1670,8 @@ static struct page *alloc_surplus_huge_page(struct hstate 
*h, gfp_t gfp_mask,
 out_unlock:
spin_unlock(_lock);

+   surplus_hugepage_set_charge(h, page);
+
return page;
 }

@@ -2062,6 +2151,11 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
hugetlb_cgroup_commit_charge(idx, pages_per_huge_page(h), h_cg, page);
spin_unlock(_lock);

+   if (unlikely(surplus_hugepage_try_charge(page, vma->vm_mm))) {
+  

[PATCH v2 1/7] hugetlb: introduce charge_surplus_huge_pages to struct hstate

[TSUKADA Koutaro]

The charge_surplus_huge_pages indicates to charge surplus huge pages
obteined from the normal page pool to memory cgroup. The default value is
false.

This patch implements the core part of charging surplus hugepages. Use the
private and mem_cgroup member of the second entry of compound hugepage for
surplus hugepage charging.

Mark when surplus hugepage is obtained from normal pool, and charge to
memory cgroup at alloc_huge_page. Once the mapping of the page is decided,
commit the charge. surplus hugepages will uncharge or cancel at
free_huge_page.

Signed-off-by: TSUKADA Koutaro 
---
 include/linux/hugetlb.h |2
 mm/hugetlb.c|  100 
 2 files changed, 102 insertions(+)

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 36fa6a2..33fe5be 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -158,6 +158,7 @@ unsigned long hugetlb_change_protection(struct 
vm_area_struct *vma,
unsigned long address, unsigned long end, pgprot_t newprot);

 bool is_hugetlb_entry_migration(pte_t pte);
+bool PageSurplusCharge(struct page *page);

 #else /* !CONFIG_HUGETLB_PAGE */

@@ -338,6 +339,7 @@ struct hstate {
unsigned int nr_huge_pages_node[MAX_NUMNODES];
unsigned int free_huge_pages_node[MAX_NUMNODES];
unsigned int surplus_huge_pages_node[MAX_NUMNODES];
+   bool charge_surplus_huge_pages; /* default to off */
 #ifdef CONFIG_CGROUP_HUGETLB
/* cgroup control files */
struct cftype cgroup_files[5];
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 2186791..679c151f 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -36,6 +36,7 @@
 #include 
 #include 
 #include 
+#include 
 #include "internal.h"

 int hugetlb_max_hstate __read_mostly;
@@ -1236,6 +1237,90 @@ static inline void ClearPageHugeTemporary(struct page 
*page)
page[2].mapping = NULL;
 }

+#define HUGETLB_SURPLUS_CHARGE 1UL
+
+bool PageSurplusCharge(struct page *page)
+{
+   if (!PageHuge(page))
+   return false;
+   return page[1].private == HUGETLB_SURPLUS_CHARGE;
+}
+
+static inline void SetPageSurplusCharge(struct page *page)
+{
+   page[1].private = HUGETLB_SURPLUS_CHARGE;
+}
+
+static inline void ClearPageSurplusCharge(struct page *page)
+{
+   page[1].private = 0;
+}
+
+static inline void
+set_surplus_hugepage_memcg(struct page *page, struct mem_cgroup *memcg)
+{
+   page[1].mem_cgroup = memcg;
+}
+
+static inline struct mem_cgroup *get_surplus_hugepage_memcg(struct page *page)
+{
+   return page[1].mem_cgroup;
+}
+
+static void surplus_hugepage_set_charge(struct hstate *h, struct page *page)
+{
+   if (likely(!h->charge_surplus_huge_pages))
+   return;
+   if (unlikely(!page))
+   return;
+   SetPageSurplusCharge(page);
+}
+
+static int surplus_hugepage_try_charge(struct page *page, struct mm_struct *mm)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return 0;
+
+   if (mem_cgroup_try_charge(page, mm, GFP_KERNEL, , true)) {
+   /* mem_cgroup oom invoked */
+   ClearPageSurplusCharge(page);
+   return -ENOMEM;
+   }
+   set_surplus_hugepage_memcg(page, memcg);
+
+   return 0;
+}
+
+static void surplus_hugepage_commit_charge(struct page *page)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return;
+
+   memcg = get_surplus_hugepage_memcg(page);
+   mem_cgroup_commit_charge(page, memcg, false, true);
+   set_surplus_hugepage_memcg(page, NULL);
+}
+
+static void surplus_hugepage_finalize_charge(struct page *page)
+{
+   struct mem_cgroup *memcg;
+
+   if (likely(!PageSurplusCharge(page)))
+   return;
+
+   memcg = get_surplus_hugepage_memcg(page);
+   if (memcg)
+   mem_cgroup_cancel_charge(page, memcg, true);
+   else
+   mem_cgroup_uncharge(page);
+   set_surplus_hugepage_memcg(page, NULL);
+   ClearPageSurplusCharge(page);
+}
+
 void free_huge_page(struct page *page)
 {
/*
@@ -1248,6 +1333,8 @@ void free_huge_page(struct page *page)
(struct hugepage_subpool *)page_private(page);
bool restore_reserve;

+   surplus_hugepage_finalize_charge(page);
+
set_page_private(page, 0);
page->mapping = NULL;
VM_BUG_ON_PAGE(page_count(page), page);
@@ -1583,6 +1670,8 @@ static struct page *alloc_surplus_huge_page(struct hstate 
*h, gfp_t gfp_mask,
 out_unlock:
spin_unlock(_lock);

+   surplus_hugepage_set_charge(h, page);
+
return page;
 }

@@ -2062,6 +2151,11 @@ struct page *alloc_huge_page(struct vm_area_struct *vma,
hugetlb_cgroup_commit_charge(idx, pages_per_huge_page(h), h_cg, page);
spin_unlock(_lock);

+   if (unlikely(surplus_hugepage_try_charge(page, vma->vm_mm))) {
+   put_page(page);
+

[PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

Thanks to Mike Kravetz for comment on the previous version patch.

The purpose of this patch-set is to make it possible to control whether or
not to charge surplus hugetlb pages obtained by overcommitting to memory
cgroup. In the future, I am trying to accomplish limiting the memory usage
of applications that use both normal pages and hugetlb pages by the memory
cgroup(not use the hugetlb cgroup).

Applications that use shared libraries like libhugetlbfs.so use both normal
pages and hugetlb pages, but we do not know how much to use each. Please
suppose you want to manage the memory usage of such applications by cgroup
How do you set the memory cgroup and hugetlb cgroup limit when you want to
limit memory usage to 10GB?

If you set a limit of 10GB for each, the user can use a total of 20GB of
memory and can not limit it well. Since it is difficult to estimate the
ratio used by user of normal pages and hugetlb pages, setting limits of 2GB
to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a
case, I thought that by using my patch-set, we could manage resources just
by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb
cgroup).

In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
struct hstate. If it is true, it charges to the memory cgroup to which the
task that obtained surplus hugepages belongs. If it is false, do nothing as
before, and the default value is false. The charge_surplus_huge_pages can
be controlled procfs or sysfs interfaces.

Since THP is very effective in environments with kernel page size of 4KB,
such as x86, there is no reason to positively use HugeTLBfs, so I think
that there is no situation to enable charge_surplus_huge_pages. However, in
some distributions such as arm64, the page size of the kernel is 64KB, and
the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs
may support multiple huge page sizes, and in such a special environment
there is a desire to use HugeTLBfs.

The patch set is for 4.17.0-rc3+. I don't know whether patch-set are
acceptable or not, so I just done a simple test.

Thanks,
Tsukada

TSUKADA Koutaro (7):
  hugetlb: introduce charge_surplus_huge_pages to struct hstate
  hugetlb: supports migrate charging for surplus hugepages
  memcg: use compound_order rather than hpage_nr_pages
  mm, sysctl: make charging surplus hugepages controllable
  hugetlb: add charge_surplus_hugepages attribute
  Documentation, hugetlb: describe about charge_surplus_hugepages
  memcg: supports movement of surplus hugepages statistics

 Documentation/vm/hugetlbpage.txt |6 +
 include/linux/hugetlb.h  |4 +
 kernel/sysctl.c  |7 +
 mm/hugetlb.c |  148 +++
 mm/memcontrol.c  |  109 +++-
 5 files changed, 269 insertions(+), 5 deletions(-)

-- 
Tsukada

[PATCH v2 0/7] mm: pages for hugetlb's overcommit may be able to charge to memcg

[TSUKADA Koutaro]

Thanks to Mike Kravetz for comment on the previous version patch.

The purpose of this patch-set is to make it possible to control whether or
not to charge surplus hugetlb pages obtained by overcommitting to memory
cgroup. In the future, I am trying to accomplish limiting the memory usage
of applications that use both normal pages and hugetlb pages by the memory
cgroup(not use the hugetlb cgroup).

Applications that use shared libraries like libhugetlbfs.so use both normal
pages and hugetlb pages, but we do not know how much to use each. Please
suppose you want to manage the memory usage of such applications by cgroup
How do you set the memory cgroup and hugetlb cgroup limit when you want to
limit memory usage to 10GB?

If you set a limit of 10GB for each, the user can use a total of 20GB of
memory and can not limit it well. Since it is difficult to estimate the
ratio used by user of normal pages and hugetlb pages, setting limits of 2GB
to memory cgroup and 8GB to hugetlb cgroup is not very good idea. In such a
case, I thought that by using my patch-set, we could manage resources just
by setting 10GB as the limit of memory cgoup(there is no limit to hugetlb
cgroup).

In this patch-set, introduce the charge_surplus_huge_pages(boolean) to
struct hstate. If it is true, it charges to the memory cgroup to which the
task that obtained surplus hugepages belongs. If it is false, do nothing as
before, and the default value is false. The charge_surplus_huge_pages can
be controlled procfs or sysfs interfaces.

Since THP is very effective in environments with kernel page size of 4KB,
such as x86, there is no reason to positively use HugeTLBfs, so I think
that there is no situation to enable charge_surplus_huge_pages. However, in
some distributions such as arm64, the page size of the kernel is 64KB, and
the size of THP is too huge as 512MB, making it difficult to use. HugeTLBfs
may support multiple huge page sizes, and in such a special environment
there is a desire to use HugeTLBfs.

The patch set is for 4.17.0-rc3+. I don't know whether patch-set are
acceptable or not, so I just done a simple test.

Thanks,
Tsukada

TSUKADA Koutaro (7):
  hugetlb: introduce charge_surplus_huge_pages to struct hstate
  hugetlb: supports migrate charging for surplus hugepages
  memcg: use compound_order rather than hpage_nr_pages
  mm, sysctl: make charging surplus hugepages controllable
  hugetlb: add charge_surplus_hugepages attribute
  Documentation, hugetlb: describe about charge_surplus_hugepages
  memcg: supports movement of surplus hugepages statistics

 Documentation/vm/hugetlbpage.txt |6 +
 include/linux/hugetlb.h  |4 +
 kernel/sysctl.c  |7 +
 mm/hugetlb.c |  148 +++
 mm/memcontrol.c  |  109 +++-
 5 files changed, 269 insertions(+), 5 deletions(-)

-- 
Tsukada

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Randy Dunlap]

On 05/17/2018 08:50 PM, Ian Kent wrote:
> On 18/05/18 08:21, Randy Dunlap wrote:
>> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to
>>>
>>>http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> README for mm-of-the-moment:
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>>> more than once a week.
>>>
>>> You will need quilt to apply these patches to the latest Linus release (4.x
>>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>>> http://ozlabs.org/~akpm/mmotm/series
>>>
>>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>>> followed by the base kernel version against which this patch series is to
>>> be applied.
>>>
>>> This tree is partially included in linux-next.  To see which patches are
>>> included in linux-next, consult the `series' file.  Only the patches
>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>> linux-next.
>>>
>>> A git tree which contains the memory management portion of this tree is
>>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>>> by Michal Hocko.  It contains the patches which are between the
>>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>>
>>>
>>> A full copy of the full kernel tree with the linux-next and mmotm patches
>>> already applied is available through git within an hour of the mmotm
>>> release.  Individual mmotm releases are tagged.  The master branch always
>>> points to the latest release, so it's constantly rebasing.
>>
>>
>> on x86_64: with (randconfig):
>> CONFIG_AUTOFS_FS=y
>> CONFIG_AUTOFS4_FS=y
> 
> Oh right, I need to make these exclusive.
> 
> I seem to remember trying to do that along the way, can't remember why
> I didn't do it in the end.
> 
> Any suggestions about potential problems when doing it?

I think that just using "depends on" for each of them will cause kconfig to
complain about circular dependencies, so probably using "choice" will be
needed.  Or (since this is just temporary?) just say "don't do that."

-- 
~Randy

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Randy Dunlap]

On 05/17/2018 08:50 PM, Ian Kent wrote:
> On 18/05/18 08:21, Randy Dunlap wrote:
>> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
>>> The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to
>>>
>>>http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> mmotm-readme.txt says
>>>
>>> README for mm-of-the-moment:
>>>
>>> http://www.ozlabs.org/~akpm/mmotm/
>>>
>>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>>> more than once a week.
>>>
>>> You will need quilt to apply these patches to the latest Linus release (4.x
>>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>>> http://ozlabs.org/~akpm/mmotm/series
>>>
>>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>>> followed by the base kernel version against which this patch series is to
>>> be applied.
>>>
>>> This tree is partially included in linux-next.  To see which patches are
>>> included in linux-next, consult the `series' file.  Only the patches
>>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>>> linux-next.
>>>
>>> A git tree which contains the memory management portion of this tree is
>>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>>> by Michal Hocko.  It contains the patches which are between the
>>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>>
>>>
>>> A full copy of the full kernel tree with the linux-next and mmotm patches
>>> already applied is available through git within an hour of the mmotm
>>> release.  Individual mmotm releases are tagged.  The master branch always
>>> points to the latest release, so it's constantly rebasing.
>>
>>
>> on x86_64: with (randconfig):
>> CONFIG_AUTOFS_FS=y
>> CONFIG_AUTOFS4_FS=y
> 
> Oh right, I need to make these exclusive.
> 
> I seem to remember trying to do that along the way, can't remember why
> I didn't do it in the end.
> 
> Any suggestions about potential problems when doing it?

I think that just using "depends on" for each of them will cause kconfig to
complain about circular dependencies, so probably using "choice" will be
needed.  Or (since this is just temporary?) just say "don't do that."

-- 
~Randy

Re: [PATCH rdma-next 4/5] RDMA/hns: Add reset process for RoCE in hip08

[Jason Gunthorpe]

On Fri, May 18, 2018 at 11:28:11AM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2018/5/17 23:14, Jason Gunthorpe wrote:
> > On Thu, May 17, 2018 at 04:02:52PM +0800, Wei Hu (Xavier) wrote:
> >> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
> >> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> >> index 86ef15f..e1c44a6 100644
> >> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> >> @@ -774,6 +774,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev 
> >> *hr_dev,
> >>int ret = 0;
> >>int ntc;
> >>  
> >> +  if (hr_dev->is_reset)
> >> +  return 0;
> >> +
> >>spin_lock_bh(>lock);
> >>  
> >>if (num > hns_roce_cmq_space(csq)) {
> >> @@ -4790,6 +4793,7 @@ static int hns_roce_hw_v2_init_instance(struct 
> >> hnae3_handle *handle)
> >>return 0;
> >>  
> >>  error_failed_get_cfg:
> >> +  handle->priv = NULL;
> >>kfree(hr_dev->priv);
> >>  
> >>  error_failed_kzalloc:
> >> @@ -4803,14 +4807,70 @@ static void hns_roce_hw_v2_uninit_instance(struct 
> >> hnae3_handle *handle,
> >>  {
> >>struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
> >>  
> >> +  if (!hr_dev)
> >> +  return;
> >> +
> >>hns_roce_exit(hr_dev);
> >> +  handle->priv = NULL;
> >>kfree(hr_dev->priv);
> >>ib_dealloc_device(_dev->ib_dev);
> >>  }
> > Why are these hunks here? If init fails then uninit should not be
> > called, so why meddle with priv?
> In hns_roce_hw_v2_init_instance function, we evaluate handle->priv with 
> hr_dev,
> We want clear the value in hns_roce_hw_v2_uninit_instance function.
> So we can ensure no problem in RoCE driver.

What problem could happen?

I keep removing unnecessary sets to null and checks of null, so please
don't add them if they cannot happen.

Eg uninit should never be called with a null priv, that is a serious
logic mis-design someplace if it happens.

Jason

Re: [PATCH rdma-next 4/5] RDMA/hns: Add reset process for RoCE in hip08

[Jason Gunthorpe]

On Fri, May 18, 2018 at 11:28:11AM +0800, Wei Hu (Xavier) wrote:
> 
> 
> On 2018/5/17 23:14, Jason Gunthorpe wrote:
> > On Thu, May 17, 2018 at 04:02:52PM +0800, Wei Hu (Xavier) wrote:
> >> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
> >> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> >> index 86ef15f..e1c44a6 100644
> >> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
> >> @@ -774,6 +774,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev 
> >> *hr_dev,
> >>int ret = 0;
> >>int ntc;
> >>  
> >> +  if (hr_dev->is_reset)
> >> +  return 0;
> >> +
> >>spin_lock_bh(>lock);
> >>  
> >>if (num > hns_roce_cmq_space(csq)) {
> >> @@ -4790,6 +4793,7 @@ static int hns_roce_hw_v2_init_instance(struct 
> >> hnae3_handle *handle)
> >>return 0;
> >>  
> >>  error_failed_get_cfg:
> >> +  handle->priv = NULL;
> >>kfree(hr_dev->priv);
> >>  
> >>  error_failed_kzalloc:
> >> @@ -4803,14 +4807,70 @@ static void hns_roce_hw_v2_uninit_instance(struct 
> >> hnae3_handle *handle,
> >>  {
> >>struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
> >>  
> >> +  if (!hr_dev)
> >> +  return;
> >> +
> >>hns_roce_exit(hr_dev);
> >> +  handle->priv = NULL;
> >>kfree(hr_dev->priv);
> >>ib_dealloc_device(_dev->ib_dev);
> >>  }
> > Why are these hunks here? If init fails then uninit should not be
> > called, so why meddle with priv?
> In hns_roce_hw_v2_init_instance function, we evaluate handle->priv with 
> hr_dev,
> We want clear the value in hns_roce_hw_v2_uninit_instance function.
> So we can ensure no problem in RoCE driver.

What problem could happen?

I keep removing unnecessary sets to null and checks of null, so please
don't add them if they cannot happen.

Eg uninit should never be called with a null priv, that is a serious
logic mis-design someplace if it happens.

Jason

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

[Vinod]

On 17-05-18, 12:20, Frank Mori Hess wrote:
> Sorry to keep coming back to this, but I'm experiencing a bit of
> incredulity that you are saying what you seem to be saying.  You seem
> to be saying dmaengine provides no way to permanently stop a transfer
> safely other than transferring the full number of bytes initially
> requested.  So the proper resolution is the 8250 serial driver needs
> to remove rx dma support, because they are just trying to do something
> that is not supported.
> 
> On Thu, May 17, 2018 at 12:19 AM, Vinod Koul  wrote:
> >> > Terminate is abort, data loss may happen here.
> >>
> >> Wait, are you saying if you do
> >>
> >> dma pause
> >
> > no data loss
> >> read residue
> >
> > here as well
> >> dma terminate
> >
> > Oh yes, we aborted...
> >>
> 
> I see two ways of interpreting what you are saying. First, from the
> point of view of the user of the dmaengine api.  From this point of
> view it is impossible for data loss to occur during pause or reading
> the residue, so saying they cause no data loss during
> pause/residue/terminate is meaningless.  This is because the user
> can't confirm any data loss until after they have read the residue and
> the transfer is terminated, since optimistically the data may still be
> available if only the user would resume and allow the transfer to
> continue.
> 
> Second there is the interpretation I want to believe.  This is "no
> data loss on pause" means that after the pause, no data has been
> discarded by the dma controller hardware, in fact all the data it has
> read before being paused has been fully transferred to its
> destination.  Reading the residue while paused gives you an accurate,
> up-to-date state of the paused transfer.  Then finally, although in
> general dma terminate causes data loss, it does not in this case since
> we terminated while we were paused and read the up-to-date residue.
> This is the interpretation implicit in the 8250 serial driver.

You are simply mixing things up! On Pause we don't expect data loss, as user can
resume the transfer. This means as you rightly guessed, the DMA HW should not 
drop
any data, nor should SW.

Now if you want to read residue at this point it is perfectly valid. But if you
decide to terminate the channel (yes it is terminate_all API), we abort and 
don't
have context to report back!

As Lars rightly pointed out, residue calculation are very tricky, DMA fifo may
have data, some data may be in device FIFO, so residue is always from DMA point
of view and may differ from device view (more or less depending upon direction)

Now if you require to add more features for your usecase, please do feel free to
send a patch. The framework can always be improved, we haven't solved world
hunger yet!

-- 
~Vinod

Re: Revert "dmaengine: pl330: add DMA_PAUSE feature"

[Vinod]

On 17-05-18, 12:20, Frank Mori Hess wrote:
> Sorry to keep coming back to this, but I'm experiencing a bit of
> incredulity that you are saying what you seem to be saying.  You seem
> to be saying dmaengine provides no way to permanently stop a transfer
> safely other than transferring the full number of bytes initially
> requested.  So the proper resolution is the 8250 serial driver needs
> to remove rx dma support, because they are just trying to do something
> that is not supported.
> 
> On Thu, May 17, 2018 at 12:19 AM, Vinod Koul  wrote:
> >> > Terminate is abort, data loss may happen here.
> >>
> >> Wait, are you saying if you do
> >>
> >> dma pause
> >
> > no data loss
> >> read residue
> >
> > here as well
> >> dma terminate
> >
> > Oh yes, we aborted...
> >>
> 
> I see two ways of interpreting what you are saying. First, from the
> point of view of the user of the dmaengine api.  From this point of
> view it is impossible for data loss to occur during pause or reading
> the residue, so saying they cause no data loss during
> pause/residue/terminate is meaningless.  This is because the user
> can't confirm any data loss until after they have read the residue and
> the transfer is terminated, since optimistically the data may still be
> available if only the user would resume and allow the transfer to
> continue.
> 
> Second there is the interpretation I want to believe.  This is "no
> data loss on pause" means that after the pause, no data has been
> discarded by the dma controller hardware, in fact all the data it has
> read before being paused has been fully transferred to its
> destination.  Reading the residue while paused gives you an accurate,
> up-to-date state of the paused transfer.  Then finally, although in
> general dma terminate causes data loss, it does not in this case since
> we terminated while we were paused and read the up-to-date residue.
> This is the interpretation implicit in the 8250 serial driver.

You are simply mixing things up! On Pause we don't expect data loss, as user can
resume the transfer. This means as you rightly guessed, the DMA HW should not 
drop
any data, nor should SW.

Now if you want to read residue at this point it is perfectly valid. But if you
decide to terminate the channel (yes it is terminate_all API), we abort and 
don't
have context to report back!

As Lars rightly pointed out, residue calculation are very tricky, DMA fifo may
have data, some data may be in device FIFO, so residue is always from DMA point
of view and may differ from device view (more or less depending upon direction)

Now if you require to add more features for your usecase, please do feel free to
send a patch. The framework can always be improved, we haven't solved world
hunger yet!

-- 
~Vinod

Re: [PATCH 0/3] Add support to disable sensor groups in P9

[Shilpasri G Bhat]

On 05/17/2018 06:08 PM, Guenter Roeck wrote:
> On 05/16/2018 11:10 PM, Shilpasri G Bhat wrote:
>>
>>
>> On 05/15/2018 08:32 PM, Guenter Roeck wrote:
>>> On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote:
 This patch series adds support to enable/disable OCC based
 inband-sensor groups at runtime. The environmental sensor groups are
 managed in HWMON and the remaining platform specific sensor groups are
 managed in /sys/firmware/opal.

 The firmware changes required for this patch is posted below:
 https://lists.ozlabs.org/pipermail/skiboot/2018-March/010812.html

>>>
>>> Sorry for not getting back earlier. This is a tough one.
>>>
>>
>> Thanks for the reply. I have tried to answer your questions according to my
>> understanding below:
>>
>>> Key problem is that you are changing the ABI with those new attributes.
>>> On top of that, the attributes _do_ make some sense (many chips support
>>> enabling/disabling of individual sensors), suggesting that those or
>>> similar attributes may or even should at some point be added to the ABI.
>>>
>>> At the same time, returning "0" as measurement values when sensors are
>>> disabled does not seem like a good idea, since "0" is a perfectly valid
>>> measurement, at least for most sensors.
>>
>> I agree.
>>
>>>
>>> Given that, we need to have a discussion about adding _enable attributes to
>>> the ABI
>>
>>> what is the scope,
>> IIUC the scope should be RW and the attribute is defined for each supported
>> sensor group
>>
> 
> That is _your_ need. I am not aware of any other chip where a per-sensor group
> attribute would make sense. The discussion we need has to extend beyond the 
> need
> of a single chip.
> 
> Guenter
> 


Is it okay if the ABI provides provision for both types of attribute
power_enable and powerX_enable. And is it okay to decide which type of attribute
to be used by the capability provided by the hwmon chip?


- Shilpa

>>> when should the attributes exist and when not,
>> We control this currently via device-tree
>>
>>> do we want/need power_enable or powerX_enable or both, and so on), and
>> We need power_enable right now
>>
>>> what to return if a sensor is disabled (such as -ENODATA).
>> -ENODATA sounds good.
>>
>> Thanks and Regards,
>> Shilpa
>>
>>   Once we have an
>>> agreement, we can continue with an implementation.
>>>
>>> Guenter
>>>
 Shilpasri G Bhat (3):
powernv:opal-sensor-groups: Add support to enable sensor groups
hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
powernv: opal-sensor-groups: Add attributes to disable/enable sensors

   .../ABI/testing/sysfs-firmware-opal-sensor-groups  |  34 ++
   Documentation/hwmon/ibmpowernv |  31 -
   arch/powerpc/include/asm/opal-api.h|   4 +-
   arch/powerpc/include/asm/opal.h|   2 +
   .../powerpc/platforms/powernv/opal-sensor-groups.c | 104 
 -
   arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
   drivers/hwmon/ibmpowernv.c | 127
 +++--
   7 files changed, 265 insertions(+), 38 deletions(-)
   create mode 100644
 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups

 -- 
 1.8.3.1

 -- 
 To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
> 

Re: [PATCH 0/3] Add support to disable sensor groups in P9

[Shilpasri G Bhat]

On 05/17/2018 06:08 PM, Guenter Roeck wrote:
> On 05/16/2018 11:10 PM, Shilpasri G Bhat wrote:
>>
>>
>> On 05/15/2018 08:32 PM, Guenter Roeck wrote:
>>> On Thu, Mar 22, 2018 at 04:24:32PM +0530, Shilpasri G Bhat wrote:
 This patch series adds support to enable/disable OCC based
 inband-sensor groups at runtime. The environmental sensor groups are
 managed in HWMON and the remaining platform specific sensor groups are
 managed in /sys/firmware/opal.

 The firmware changes required for this patch is posted below:
 https://lists.ozlabs.org/pipermail/skiboot/2018-March/010812.html

>>>
>>> Sorry for not getting back earlier. This is a tough one.
>>>
>>
>> Thanks for the reply. I have tried to answer your questions according to my
>> understanding below:
>>
>>> Key problem is that you are changing the ABI with those new attributes.
>>> On top of that, the attributes _do_ make some sense (many chips support
>>> enabling/disabling of individual sensors), suggesting that those or
>>> similar attributes may or even should at some point be added to the ABI.
>>>
>>> At the same time, returning "0" as measurement values when sensors are
>>> disabled does not seem like a good idea, since "0" is a perfectly valid
>>> measurement, at least for most sensors.
>>
>> I agree.
>>
>>>
>>> Given that, we need to have a discussion about adding _enable attributes to
>>> the ABI
>>
>>> what is the scope,
>> IIUC the scope should be RW and the attribute is defined for each supported
>> sensor group
>>
> 
> That is _your_ need. I am not aware of any other chip where a per-sensor group
> attribute would make sense. The discussion we need has to extend beyond the 
> need
> of a single chip.
> 
> Guenter
> 


Is it okay if the ABI provides provision for both types of attribute
power_enable and powerX_enable. And is it okay to decide which type of attribute
to be used by the capability provided by the hwmon chip?


- Shilpa

>>> when should the attributes exist and when not,
>> We control this currently via device-tree
>>
>>> do we want/need power_enable or powerX_enable or both, and so on), and
>> We need power_enable right now
>>
>>> what to return if a sensor is disabled (such as -ENODATA).
>> -ENODATA sounds good.
>>
>> Thanks and Regards,
>> Shilpa
>>
>>   Once we have an
>>> agreement, we can continue with an implementation.
>>>
>>> Guenter
>>>
 Shilpasri G Bhat (3):
powernv:opal-sensor-groups: Add support to enable sensor groups
hwmon: ibmpowernv: Add attributes to enable/disable sensor groups
powernv: opal-sensor-groups: Add attributes to disable/enable sensors

   .../ABI/testing/sysfs-firmware-opal-sensor-groups  |  34 ++
   Documentation/hwmon/ibmpowernv |  31 -
   arch/powerpc/include/asm/opal-api.h|   4 +-
   arch/powerpc/include/asm/opal.h|   2 +
   .../powerpc/platforms/powernv/opal-sensor-groups.c | 104 
 -
   arch/powerpc/platforms/powernv/opal-wrappers.S |   1 +
   drivers/hwmon/ibmpowernv.c | 127
 +++--
   7 files changed, 265 insertions(+), 38 deletions(-)
   create mode 100644
 Documentation/ABI/testing/sysfs-firmware-opal-sensor-groups

 -- 
 1.8.3.1

 -- 
 To unsubscribe from this list: send the line "unsubscribe linux-hwmon" in
 the body of a message to majord...@vger.kernel.org
 More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>
>>
> 

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

[Joonsoo Kim]

On Thu, May 17, 2018 at 10:53:32AM -0700, Laura Abbott wrote:
> On 05/17/2018 10:08 AM, Michal Hocko wrote:
> >On Thu 17-05-18 18:49:47, Michal Hocko wrote:
> >>On Thu 17-05-18 16:58:32, Ville Syrjälä wrote:
> >>>On Thu, May 17, 2018 at 04:36:29PM +0300, Ville Syrjälä wrote:
> On Thu, May 17, 2018 at 03:21:09PM +0200, Michal Hocko wrote:
> >On Thu 17-05-18 15:59:59, Ville Syrjala wrote:
> >>From: Ville Syrjälä 
> >>
> >>This reverts commit bad8c6c0b1144694ecb0bc5629ede9b8b578b86e.
> >>
> >>Make x86 with HIGHMEM=y and CMA=y boot again.
> >
> >Is there any bug report with some more details? It is much more
> >preferable to fix the issue rather than to revert the whole thing
> >right away.
> 
> The machine I have in front of me right now didn't give me anything.
> Black screen, and netconsole was silent. No serial port on this
> machine unfortunately.
> >>>
> >>>Booted on another machine with serial:
> >>
> >>Could you provide your .config please?
> >>
> >>[...]
> >>>[0.00] cma: Reserved 4 MiB at 0x3700
> >>[...]
> >>>[0.00] BUG: Bad page state in process swapper  pfn:377fe
> >>>[0.00] page:f53effc0 count:0 mapcount:-127 mapping: 
> >>>index:0x0
> >>
> >>OK, so this looks the be the source of the problem. -128 would be a
> >>buddy page but I do not see anything that would set the counter to -127
> >>and the real map count updates shouldn't really happen that early.
> >>
> >>Maybe CONFIG_DEBUG_VM and CONFIG_DEBUG_HIGHMEM will tell us more.
> >
> >Looking closer, I _think_ that the bug is in 
> >set_highmem_pages_init->is_highmem
> >and zone_movable_is_highmem might force CMA pages in the zone movable to
> >be initialized as highmem. And that sounds supicious to me. Joonsoo?
> >
> 
> For a point of reference, arm with this configuration doesn't hit this bug
> because highmem pages are freed via the memblock interface only instead
> of iterating through each zone. It looks like the x86 highmem code
> assumes only a single highmem zone and/or it's disjoint?

Good point! Reason of the crash is that the span of MOVABLE_ZONE is
extended to whole node span for future CMA initialization, and,
normal memory is wrongly freed here.

Here goes the fix. Ville, Could you test below patch?
I re-generated the issue on my side and this patch fixed it.

Thanks.

>8-
>From 569899a4dbd28cebb8d350d3d1ebb590d88b2629 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim 
Date: Fri, 18 May 2018 10:52:05 +0900
Subject: [PATCH] x86/32/highmem: check if the zone is matched when free
 highmem pages on init

If CONFIG_CMA is enabled, it extends the span of the MOVABLE_ZONE
to manage the CMA memory later. And, in this case, the span of the
MOVABLE_ZONE could overlap the other zone's memory. We need to
avoid freeing this overlapped memory here since it would be the
memory of the other zone. Therefore, this patch adds a check
whether the page is indeed on the requested zone or not. Skipped
page will be freed when the memory of the matched zone is freed.

Reported-by: Ville Syrjälä 
Signed-off-by: Joonsoo Kim 
---
 arch/x86/include/asm/highmem.h |  4 ++--
 arch/x86/mm/highmem_32.c   |  5 -
 arch/x86/mm/init_32.c  | 25 +
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/highmem.h b/arch/x86/include/asm/highmem.h
index a805993..e383f57 100644
--- a/arch/x86/include/asm/highmem.h
+++ b/arch/x86/include/asm/highmem.h
@@ -72,8 +72,8 @@ void *kmap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot);
 
 #define flush_cache_kmaps()do { } while (0)
 
-extern void add_highpages_with_active_regions(int nid, unsigned long start_pfn,
-   unsigned long end_pfn);
+extern void add_highpages_with_active_regions(int nid, struct zone *zone,
+   unsigned long start_pfn, unsigned long end_pfn);
 
 #endif /* __KERNEL__ */
 
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index 6d18b70..bf9f5b8 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@ -120,6 +120,9 @@ void __init set_highmem_pages_init(void)
if (!is_highmem(zone))
continue;
 
+   if (!populated_zone(zone))
+   continue;
+
zone_start_pfn = zone->zone_start_pfn;
zone_end_pfn = zone_start_pfn + zone->spanned_pages;
 
@@ -127,7 +130,7 @@ void __init set_highmem_pages_init(void)
printk(KERN_INFO "Initializing %s for node %d (%08lx:%08lx)\n",
zone->name, nid, zone_start_pfn, zone_end_pfn);
 
-   add_highpages_with_active_regions(nid, zone_start_pfn,
+   add_highpages_with_active_regions(nid, zone, zone_start_pfn,
  

Re: [PATCH] Revert "mm/cma: manage the memory of the CMA area by using the ZONE_MOVABLE"

[Joonsoo Kim]

On Thu, May 17, 2018 at 10:53:32AM -0700, Laura Abbott wrote:
> On 05/17/2018 10:08 AM, Michal Hocko wrote:
> >On Thu 17-05-18 18:49:47, Michal Hocko wrote:
> >>On Thu 17-05-18 16:58:32, Ville Syrjälä wrote:
> >>>On Thu, May 17, 2018 at 04:36:29PM +0300, Ville Syrjälä wrote:
> On Thu, May 17, 2018 at 03:21:09PM +0200, Michal Hocko wrote:
> >On Thu 17-05-18 15:59:59, Ville Syrjala wrote:
> >>From: Ville Syrjälä 
> >>
> >>This reverts commit bad8c6c0b1144694ecb0bc5629ede9b8b578b86e.
> >>
> >>Make x86 with HIGHMEM=y and CMA=y boot again.
> >
> >Is there any bug report with some more details? It is much more
> >preferable to fix the issue rather than to revert the whole thing
> >right away.
> 
> The machine I have in front of me right now didn't give me anything.
> Black screen, and netconsole was silent. No serial port on this
> machine unfortunately.
> >>>
> >>>Booted on another machine with serial:
> >>
> >>Could you provide your .config please?
> >>
> >>[...]
> >>>[0.00] cma: Reserved 4 MiB at 0x3700
> >>[...]
> >>>[0.00] BUG: Bad page state in process swapper  pfn:377fe
> >>>[0.00] page:f53effc0 count:0 mapcount:-127 mapping: 
> >>>index:0x0
> >>
> >>OK, so this looks the be the source of the problem. -128 would be a
> >>buddy page but I do not see anything that would set the counter to -127
> >>and the real map count updates shouldn't really happen that early.
> >>
> >>Maybe CONFIG_DEBUG_VM and CONFIG_DEBUG_HIGHMEM will tell us more.
> >
> >Looking closer, I _think_ that the bug is in 
> >set_highmem_pages_init->is_highmem
> >and zone_movable_is_highmem might force CMA pages in the zone movable to
> >be initialized as highmem. And that sounds supicious to me. Joonsoo?
> >
> 
> For a point of reference, arm with this configuration doesn't hit this bug
> because highmem pages are freed via the memblock interface only instead
> of iterating through each zone. It looks like the x86 highmem code
> assumes only a single highmem zone and/or it's disjoint?

Good point! Reason of the crash is that the span of MOVABLE_ZONE is
extended to whole node span for future CMA initialization, and,
normal memory is wrongly freed here.

Here goes the fix. Ville, Could you test below patch?
I re-generated the issue on my side and this patch fixed it.

Thanks.

>8-
>From 569899a4dbd28cebb8d350d3d1ebb590d88b2629 Mon Sep 17 00:00:00 2001
From: Joonsoo Kim 
Date: Fri, 18 May 2018 10:52:05 +0900
Subject: [PATCH] x86/32/highmem: check if the zone is matched when free
 highmem pages on init

If CONFIG_CMA is enabled, it extends the span of the MOVABLE_ZONE
to manage the CMA memory later. And, in this case, the span of the
MOVABLE_ZONE could overlap the other zone's memory. We need to
avoid freeing this overlapped memory here since it would be the
memory of the other zone. Therefore, this patch adds a check
whether the page is indeed on the requested zone or not. Skipped
page will be freed when the memory of the matched zone is freed.

Reported-by: Ville Syrjälä 
Signed-off-by: Joonsoo Kim 
---
 arch/x86/include/asm/highmem.h |  4 ++--
 arch/x86/mm/highmem_32.c   |  5 -
 arch/x86/mm/init_32.c  | 25 +
 3 files changed, 27 insertions(+), 7 deletions(-)

diff --git a/arch/x86/include/asm/highmem.h b/arch/x86/include/asm/highmem.h
index a805993..e383f57 100644
--- a/arch/x86/include/asm/highmem.h
+++ b/arch/x86/include/asm/highmem.h
@@ -72,8 +72,8 @@ void *kmap_atomic_prot_pfn(unsigned long pfn, pgprot_t prot);
 
 #define flush_cache_kmaps()do { } while (0)
 
-extern void add_highpages_with_active_regions(int nid, unsigned long start_pfn,
-   unsigned long end_pfn);
+extern void add_highpages_with_active_regions(int nid, struct zone *zone,
+   unsigned long start_pfn, unsigned long end_pfn);
 
 #endif /* __KERNEL__ */
 
diff --git a/arch/x86/mm/highmem_32.c b/arch/x86/mm/highmem_32.c
index 6d18b70..bf9f5b8 100644
--- a/arch/x86/mm/highmem_32.c
+++ b/arch/x86/mm/highmem_32.c
@@ -120,6 +120,9 @@ void __init set_highmem_pages_init(void)
if (!is_highmem(zone))
continue;
 
+   if (!populated_zone(zone))
+   continue;
+
zone_start_pfn = zone->zone_start_pfn;
zone_end_pfn = zone_start_pfn + zone->spanned_pages;
 
@@ -127,7 +130,7 @@ void __init set_highmem_pages_init(void)
printk(KERN_INFO "Initializing %s for node %d (%08lx:%08lx)\n",
zone->name, nid, zone_start_pfn, zone_end_pfn);
 
-   add_highpages_with_active_regions(nid, zone_start_pfn,
+   add_highpages_with_active_regions(nid, zone, zone_start_pfn,
 zone_end_pfn);
}
 }
diff --git a/arch/x86/mm/init_32.c b/arch/x86/mm/init_32.c
index 

[PATCH v2 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc

[djw]

From: Levin Du 

In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.

This special pin can now be reference as <_mute 1>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.

If the signal voltage changes, the io domain needs to change
correspondingly.

To use this feature, the following options are required in kernel config:
 - CONFIG_GPIO_SYSCON=y
 - CONFIG_POWER_AVS=y
 - CONFIG_ROCKCHIP_IODOMAIN=y

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts

Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node

 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..e3162bb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <_io>;
};
 
+   vcc_sdio: sdmmcio-regulator {
+   compatible = "regulator-gpio";
+   gpios = <_mute 1 GPIO_ACTIVE_HIGH>;
+   states = <180 0x1
+ 330 0x0>;
+   regulator-name = "vcc_sdio";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
 
vccio1-supply = <_io>;
vccio2-supply = <_emmc>;
-   vccio3-supply = <_io>;
+   vccio3-supply = <_sdio>;
vccio4-supply = <_18>;
vccio5-supply = <_io>;
vccio6-supply = <_io>;
@@ -242,7 +255,12 @@
max-frequency = <15000>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _dectn _bus4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
vmmc-supply = <_sd>;
+   vqmmc-supply = <_sdio>;
status = "okay";
 };
 
-- 
2.7.4

[PATCH v2 5/5] arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc

[djw]

From: Levin Du 

In roc-rk3328-cc board, the signal voltage of sdmmc is supplied by
the vcc_sdio regulator, which is a mux between 1.8V and 3.3V,
controlled by a special output only gpio pin labeled
"gpiomut_pmuio_iout", corresponding bit 1 of the syscon GRF_SOC_CON10.

This special pin can now be reference as <_mute 1>, thanks
to the gpio-syscon driver, which makes writing regulator-gpio possible.

If the signal voltage changes, the io domain needs to change
correspondingly.

To use this feature, the following options are required in kernel config:
 - CONFIG_GPIO_SYSCON=y
 - CONFIG_POWER_AVS=y
 - CONFIG_ROCKCHIP_IODOMAIN=y

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts

Changes in v1:
- Split into small patches
- Sort dts properties in sdmmc node

 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 20 +++-
 1 file changed, 19 insertions(+), 1 deletion(-)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index b983abd..e3162bb 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -41,6 +41,19 @@
vin-supply = <_io>;
};
 
+   vcc_sdio: sdmmcio-regulator {
+   compatible = "regulator-gpio";
+   gpios = <_mute 1 GPIO_ACTIVE_HIGH>;
+   states = <180 0x1
+ 330 0x0>;
+   regulator-name = "vcc_sdio";
+   regulator-type = "voltage";
+   regulator-min-microvolt = <180>;
+   regulator-max-microvolt = <330>;
+   regulator-always-on;
+   vin-supply = <_sys>;
+   };
+
vcc_host1_5v: vcc_otg_5v: vcc-host1-5v-regulator {
compatible = "regulator-fixed";
enable-active-high;
@@ -213,7 +226,7 @@
 
vccio1-supply = <_io>;
vccio2-supply = <_emmc>;
-   vccio3-supply = <_io>;
+   vccio3-supply = <_sdio>;
vccio4-supply = <_18>;
vccio5-supply = <_io>;
vccio6-supply = <_io>;
@@ -242,7 +255,12 @@
max-frequency = <15000>;
pinctrl-names = "default";
pinctrl-0 = <_clk _cmd _dectn _bus4>;
+   sd-uhs-sdr12;
+   sd-uhs-sdr25;
+   sd-uhs-sdr50;
+   sd-uhs-sdr104;
vmmc-supply = <_sd>;
+   vqmmc-supply = <_sdio>;
status = "okay";
 };
 
-- 
2.7.4

[PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip

[djw]

From: Levin Du 

Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.

Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc

Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt

 .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++
 drivers/gpio/gpio-syscon.c | 30 
 2 files changed, 71 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt 
b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 000..b1b2a67
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+0 = Active high,
+1 = Active low.
+- gpio,syscon-dev: Should contain .
+  If declared as child of the grf node, the grf_phandle can be 0.
+
+Example:
+
+1. As child of grf node:
+
+   grf: syscon@ff10 {
+   compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = <0 0x0428 0>;
+   };
+   };
+
+
+2. Not child of grf node:
+
+   grf: syscon@ff10 {
+   compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+   //...
+   };
+
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = < 0x0428 0>;
+   };
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..e24b408 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = 
{
.dat_bit_offset = 0x40 * 8 + 8,
 };
 
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+   struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+   unsigned int offs;
+   u8 bit;
+   u32 data;
+   int ret;
+
+   offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+   bit = offs % SYSCON_REG_BITS;
+   data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+   ret = regmap_write(priv->syscon,
+  (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+  data);
+   if (ret < 0)
+   dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_gpio_syscon = {
+   /* Rockchip GRF_SOC_CON Bits 0-15 */
+   .flags  = GPIO_SYSCON_FEAT_OUT,
+   .bit_count  = 16,
+   .set= rockchip_gpio_set,
+};
+
 #define KEYSTONE_LOCK_BIT BIT(0)
 
 static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data   = _dsp_gpio,
},
+   {
+   .compatible = "rockchip,gpio-syscon",
+   .data   = _gpio_syscon,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
-- 
2.7.4

[PATCH v2 2/5] gpio: syscon: Add gpio-syscon for rockchip

[djw]

From: Levin Du 

Some GPIOs sit in the GRF_SOC_CON registers of Rockchip SoCs,
which do not belong to the general pinctrl.

Adding gpio-syscon support makes controlling regulator or
LED using these special pins very easy by reusing existing
drivers, such as gpio-regulator and led-gpio.

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc

Changes in v1:
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt

 .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++
 drivers/gpio/gpio-syscon.c | 30 
 2 files changed, 71 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt

diff --git a/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt 
b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
new file mode 100644
index 000..b1b2a67
--- /dev/null
+++ b/Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt
@@ -0,0 +1,41 @@
+* Rockchip GPIO support for GRF_SOC_CON registers
+
+Required properties:
+- compatible: Should contain "rockchip,gpio-syscon".
+- gpio-controller: Marks the device node as a gpio controller.
+- #gpio-cells: Should be two. The first cell is the pin number and
+  the second cell is used to specify the gpio polarity:
+0 = Active high,
+1 = Active low.
+- gpio,syscon-dev: Should contain .
+  If declared as child of the grf node, the grf_phandle can be 0.
+
+Example:
+
+1. As child of grf node:
+
+   grf: syscon@ff10 {
+   compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = <0 0x0428 0>;
+   };
+   };
+
+
+2. Not child of grf node:
+
+   grf: syscon@ff10 {
+   compatible = "rockchip,rk3328-grf", "syscon", "simple-mfd";
+   //...
+   };
+
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = < 0x0428 0>;
+   };
diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 7325b86..e24b408 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -135,6 +135,32 @@ static const struct syscon_gpio_data clps711x_mctrl_gpio = 
{
.dat_bit_offset = 0x40 * 8 + 8,
 };
 
+static void rockchip_gpio_set(struct gpio_chip *chip, unsigned int offset,
+ int val)
+{
+   struct syscon_gpio_priv *priv = gpiochip_get_data(chip);
+   unsigned int offs;
+   u8 bit;
+   u32 data;
+   int ret;
+
+   offs = priv->dreg_offset + priv->data->dat_bit_offset + offset;
+   bit = offs % SYSCON_REG_BITS;
+   data = (val ? BIT(bit) : 0) | BIT(bit + 16);
+   ret = regmap_write(priv->syscon,
+  (offs / SYSCON_REG_BITS) * SYSCON_REG_SIZE,
+  data);
+   if (ret < 0)
+   dev_err(chip->parent, "gpio write failed ret(%d)\n", ret);
+}
+
+static const struct syscon_gpio_data rockchip_gpio_syscon = {
+   /* Rockchip GRF_SOC_CON Bits 0-15 */
+   .flags  = GPIO_SYSCON_FEAT_OUT,
+   .bit_count  = 16,
+   .set= rockchip_gpio_set,
+};
+
 #define KEYSTONE_LOCK_BIT BIT(0)
 
 static void keystone_gpio_set(struct gpio_chip *chip, unsigned offset, int val)
@@ -175,6 +201,10 @@ static const struct of_device_id syscon_gpio_ids[] = {
.compatible = "ti,keystone-dsp-gpio",
.data   = _dsp_gpio,
},
+   {
+   .compatible = "rockchip,gpio-syscon",
+   .data   = _gpio_syscon,
+   },
{ }
 };
 MODULE_DEVICE_TABLE(of, syscon_gpio_ids);
-- 
2.7.4

[PATCH v2 1/5] gpio: syscon: allow fetching syscon from parent node

[djw]

From: Heiko Stuebner 

Syscon nodes can be a simple-mfd and the syscon-users then be declared
as children of this node. That way the parent-child structure can be
better represented for devices that are fully embedded in the syscon.

Therefore allow getting the syscon from the parent if neither
a special compatible nor a gpio,syscon-dev property is defined.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Levin Du 
---

Changes in v2: None
Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver

 drivers/gpio/gpio-syscon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 537cec7..7325b86 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -205,6 +205,8 @@ static int syscon_gpio_probe(struct platform_device *pdev)
} else {
priv->syscon =
syscon_regmap_lookup_by_phandle(np, "gpio,syscon-dev");
+   if (IS_ERR(priv->syscon) && np->parent)
+   priv->syscon = syscon_node_to_regmap(np->parent);
if (IS_ERR(priv->syscon))
return PTR_ERR(priv->syscon);
 
-- 
2.7.4

[PATCH v2 1/5] gpio: syscon: allow fetching syscon from parent node

[djw]

From: Heiko Stuebner 

Syscon nodes can be a simple-mfd and the syscon-users then be declared
as children of this node. That way the parent-child structure can be
better represented for devices that are fully embedded in the syscon.

Therefore allow getting the syscon from the parent if neither
a special compatible nor a gpio,syscon-dev property is defined.

Signed-off-by: Heiko Stuebner 
Signed-off-by: Levin Du 
---

Changes in v2: None
Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver

 drivers/gpio/gpio-syscon.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/gpio/gpio-syscon.c b/drivers/gpio/gpio-syscon.c
index 537cec7..7325b86 100644
--- a/drivers/gpio/gpio-syscon.c
+++ b/drivers/gpio/gpio-syscon.c
@@ -205,6 +205,8 @@ static int syscon_gpio_probe(struct platform_device *pdev)
} else {
priv->syscon =
syscon_regmap_lookup_by_phandle(np, "gpio,syscon-dev");
+   if (IS_ERR(priv->syscon) && np->parent)
+   priv->syscon = syscon_node_to_regmap(np->parent);
if (IS_ERR(priv->syscon))
return PTR_ERR(priv->syscon);
 
-- 
2.7.4

[PATCH v2 3/5] arm64: dts: rockchip: Add gpio-mute to rk3328

[djw]

From: Levin Du 

Adding a new gpio controller named "gpio-mute" to rk3328, providing
access to the GPIO_MUTE pin defined in the syscon GRF_SOC_CON10.

The GPIO_MUTE pin is referred to as < 1>.

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi

Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.

 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da1..5ba29d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -309,6 +309,13 @@
mode-loader = ;
};
 
+   /* The GPIO_MUTE pin is referred to as < 1>.*/
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = <0 0x0428 0>;
+   };
};
 
uart0: serial@ff11 {
-- 
2.7.4

[PATCH v2 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc

[djw]

From: Levin Du 

It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.

Signed-off-by: Levin Du 

---

Changes in v2: None
Changes in v1:
- Split from V0.

 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
 };
 
+_domains {
+   status = "okay";
+
+   vccio1-supply = <_io>;
+   vccio2-supply = <_emmc>;
+   vccio3-supply = <_io>;
+   vccio4-supply = <_18>;
+   vccio5-supply = <_io>;
+   vccio6-supply = <_io>;
+   pmuio-supply = <_io>;
+};
+
  {
pmic {
pmic_int_l: pmic-int-l {
-- 
2.7.4

[PATCH v2 3/5] arm64: dts: rockchip: Add gpio-mute to rk3328

[djw]

From: Levin Du 

Adding a new gpio controller named "gpio-mute" to rk3328, providing
access to the GPIO_MUTE pin defined in the syscon GRF_SOC_CON10.

The GPIO_MUTE pin is referred to as < 1>.

Signed-off-by: Levin Du 

---

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi

Changes in v1:
- Split from V0 and add to rk3328.dtsi for general use.

 arch/arm64/boot/dts/rockchip/rk3328.dtsi | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328.dtsi 
b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
index b8e9da1..5ba29d3 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328.dtsi
+++ b/arch/arm64/boot/dts/rockchip/rk3328.dtsi
@@ -309,6 +309,13 @@
mode-loader = ;
};
 
+   /* The GPIO_MUTE pin is referred to as < 1>.*/
+   gpio_mute: gpio-mute {
+   compatible = "rockchip,gpio-syscon";
+   gpio-controller;
+   #gpio-cells = <2>;
+   gpio,syscon-dev = <0 0x0428 0>;
+   };
};
 
uart0: serial@ff11 {
-- 
2.7.4

[PATCH v2 4/5] arm64: dts: rockchip: Add io-domain to roc-rk3328-cc

[djw]

From: Levin Du 

It is necessary for the io domain setting of the SoC to match
the voltage supplied by the regulators.

Signed-off-by: Levin Du 

---

Changes in v2: None
Changes in v1:
- Split from V0.

 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 12 
 1 file changed, 12 insertions(+)

diff --git a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts 
b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
index 246c317..b983abd 100644
--- a/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
+++ b/arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts
@@ -208,6 +208,18 @@
};
 };
 
+_domains {
+   status = "okay";
+
+   vccio1-supply = <_io>;
+   vccio2-supply = <_emmc>;
+   vccio3-supply = <_io>;
+   vccio4-supply = <_18>;
+   vccio5-supply = <_io>;
+   vccio6-supply = <_io>;
+   pmuio-supply = <_io>;
+};
+
  {
pmic {
pmic_int_l: pmic-int-l {
-- 
2.7.4

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Ian Kent]

On 18/05/18 08:21, Randy Dunlap wrote:
> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>> more than once a week.
>>
>> You will need quilt to apply these patches to the latest Linus release (4.x
>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>> http://ozlabs.org/~akpm/mmotm/series
>>
>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>> followed by the base kernel version against which this patch series is to
>> be applied.
>>
>> This tree is partially included in linux-next.  To see which patches are
>> included in linux-next, consult the `series' file.  Only the patches
>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>> linux-next.
>>
>> A git tree which contains the memory management portion of this tree is
>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> by Michal Hocko.  It contains the patches which are between the
>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>
>>
>> A full copy of the full kernel tree with the linux-next and mmotm patches
>> already applied is available through git within an hour of the mmotm
>> release.  Individual mmotm releases are tagged.  The master branch always
>> points to the latest release, so it's constantly rebasing.
> 
> 
> on x86_64: with (randconfig):
> CONFIG_AUTOFS_FS=y
> CONFIG_AUTOFS4_FS=y

Oh right, I need to make these exclusive.

I seem to remember trying to do that along the way, can't remember why
I didn't do it in the end.

Any suggestions about potential problems when doing it?

Thanks,
Ian

Re: mmotm 2018-05-17-16-26 uploaded (autofs)

[Ian Kent]

On 18/05/18 08:21, Randy Dunlap wrote:
> On 05/17/2018 04:26 PM, a...@linux-foundation.org wrote:
>> The mm-of-the-moment snapshot 2018-05-17-16-26 has been uploaded to
>>
>>http://www.ozlabs.org/~akpm/mmotm/
>>
>> mmotm-readme.txt says
>>
>> README for mm-of-the-moment:
>>
>> http://www.ozlabs.org/~akpm/mmotm/
>>
>> This is a snapshot of my -mm patch queue.  Uploaded at random hopefully
>> more than once a week.
>>
>> You will need quilt to apply these patches to the latest Linus release (4.x
>> or 4.x-rcY).  The series file is in broken-out.tar.gz and is duplicated in
>> http://ozlabs.org/~akpm/mmotm/series
>>
>> The file broken-out.tar.gz contains two datestamp files: .DATE and
>> .DATE--mm-dd-hh-mm-ss.  Both contain the string -mm-dd-hh-mm-ss,
>> followed by the base kernel version against which this patch series is to
>> be applied.
>>
>> This tree is partially included in linux-next.  To see which patches are
>> included in linux-next, consult the `series' file.  Only the patches
>> within the #NEXT_PATCHES_START/#NEXT_PATCHES_END markers are included in
>> linux-next.
>>
>> A git tree which contains the memory management portion of this tree is
>> maintained at git://git.kernel.org/pub/scm/linux/kernel/git/mhocko/mm.git
>> by Michal Hocko.  It contains the patches which are between the
>> "#NEXT_PATCHES_START mm" and "#NEXT_PATCHES_END" markers, from the series
>> file, http://www.ozlabs.org/~akpm/mmotm/series.
>>
>>
>> A full copy of the full kernel tree with the linux-next and mmotm patches
>> already applied is available through git within an hour of the mmotm
>> release.  Individual mmotm releases are tagged.  The master branch always
>> points to the latest release, so it's constantly rebasing.
> 
> 
> on x86_64: with (randconfig):
> CONFIG_AUTOFS_FS=y
> CONFIG_AUTOFS4_FS=y

Oh right, I need to make these exclusive.

I seem to remember trying to do that along the way, can't remember why
I didn't do it in the end.

Any suggestions about potential problems when doing it?

Thanks,
Ian

Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper

[Eric W. Biederman]

Casey Schaufler  writes:

> On 5/17/2018 7:48 AM, Mimi Zohar wrote:
>> In order for LSMs and IMA-appraisal to differentiate between the original
>> and new syscalls (eg. kexec, kernel modules, firmware), both the original
>> and new syscalls must call an LSM hook.
>>
>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook")
>> introduced calling security_kernel_module_from_file() in both the original
>> and new syscalls.  Commit a1db74209483 ("module: replace
>> copy_module_from_fd with kernel version") replaced these LSM calls with
>> security_kernel_read_file().
>>
>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents()
>> with kernel version") and commit b804defe4297  ("kexec: replace call to
>> copy_file_from_fd() with kernel version") replaced their own version of
>> reading a file from the kernel with the generic
>> kernel_read_file_from_path/fd() versions, which call the pre and post
>> security_kernel_read_file LSM hooks.
>>
>> Missing are LSM calls in the original kexec syscall and firmware sysfs
>> fallback method.  From a technical perspective there is no justification
>> for defining a new LSM hook, as the existing security_kernel_read_file()
>> works just fine.  The original syscalls, however, do not read a file, so
>> the security hook name is inappropriate.  Instead of defining a new LSM
>> hook, this patch defines security_kernel_read_blob() as a wrapper for
>> the existing LSM security_kernel_file_read() hook.
>
> What a marvelous opportunity to bikeshed!
>
> I really dislike adding another security_ interface just because
> the name isn't quite right. Especially a wrapper, which is just
> code and execution overhead. Why not change security_kernel_read_file()
> to security_kernel_read_blob() everywhere and be done?

Nacked-by: "Eric W. Biederman" 

Nack on this sharing nonsense.  These two interfaces do not share any
code in their implementations other than the if statement to distinguish
between the two cases.

Casey you are wrong.  We need something different here.

Mimi a wrapper does not cut it.   The code is not shared.  Despite using
a single function call today.

If we want comprehensible and maintainable code in the security modules
we need to split these two pieces of functionality apart.

Eric

Re: [PATCH v2 3/9] security: define security_kernel_read_blob() wrapper

[Eric W. Biederman]

Casey Schaufler  writes:

> On 5/17/2018 7:48 AM, Mimi Zohar wrote:
>> In order for LSMs and IMA-appraisal to differentiate between the original
>> and new syscalls (eg. kexec, kernel modules, firmware), both the original
>> and new syscalls must call an LSM hook.
>>
>> Commit 2e72d51b4ac3 ("security: introduce kernel_module_from_file hook")
>> introduced calling security_kernel_module_from_file() in both the original
>> and new syscalls.  Commit a1db74209483 ("module: replace
>> copy_module_from_fd with kernel version") replaced these LSM calls with
>> security_kernel_read_file().
>>
>> Commit e40ba6d56b41 ("firmware: replace call to fw_read_file_contents()
>> with kernel version") and commit b804defe4297  ("kexec: replace call to
>> copy_file_from_fd() with kernel version") replaced their own version of
>> reading a file from the kernel with the generic
>> kernel_read_file_from_path/fd() versions, which call the pre and post
>> security_kernel_read_file LSM hooks.
>>
>> Missing are LSM calls in the original kexec syscall and firmware sysfs
>> fallback method.  From a technical perspective there is no justification
>> for defining a new LSM hook, as the existing security_kernel_read_file()
>> works just fine.  The original syscalls, however, do not read a file, so
>> the security hook name is inappropriate.  Instead of defining a new LSM
>> hook, this patch defines security_kernel_read_blob() as a wrapper for
>> the existing LSM security_kernel_file_read() hook.
>
> What a marvelous opportunity to bikeshed!
>
> I really dislike adding another security_ interface just because
> the name isn't quite right. Especially a wrapper, which is just
> code and execution overhead. Why not change security_kernel_read_file()
> to security_kernel_read_blob() everywhere and be done?

Nacked-by: "Eric W. Biederman" 

Nack on this sharing nonsense.  These two interfaces do not share any
code in their implementations other than the if statement to distinguish
between the two cases.

Casey you are wrong.  We need something different here.

Mimi a wrapper does not cut it.   The code is not shared.  Despite using
a single function call today.

If we want comprehensible and maintainable code in the security modules
we need to split these two pieces of functionality apart.

Eric

[PATCH v2 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.

[djw]

From: Levin Du 


Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.

This patch series adds a new compatible `rockchip,gpio-syscon` to
the gpio-syscon driver for general Rockchip SoC usage.

A new gpio controller named `gpio_mute` is defined in
rk3328.dtsi so that all rk3328 boards has access to it.

The ROC-RK3328-CC board use the new gpio <_mute 1> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.

Many thanks to Heiko's great advice!

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts

Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
- Split from V0 into small patches
- Sort dts properties in sdmmc node

Heiko Stuebner (1):
  gpio: syscon: allow fetching syscon from parent node

Levin Du (4):
  gpio: syscon: Add gpio-syscon for rockchip
  arm64: dts: rockchip: Add gpio-mute to rk3328
  arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
  arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc

 .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 30 
 arch/arm64/boot/dts/rockchip/rk3328.dtsi   |  7 
 drivers/gpio/gpio-syscon.c | 32 +
 4 files changed, 110 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt

-- 
2.7.4

[PATCH v2 0/5] Add sdmmc UHS support to ROC-RK3328-CC board.

[djw]

From: Levin Du 


Hi all, this is an attemp to add sdmmc UHS support to the
ROC-RK3328-CC board.

This patch series adds a new compatible `rockchip,gpio-syscon` to
the gpio-syscon driver for general Rockchip SoC usage.

A new gpio controller named `gpio_mute` is defined in
rk3328.dtsi so that all rk3328 boards has access to it.

The ROC-RK3328-CC board use the new gpio <_mute 1> in
gpio-regulator to control the signal voltage of the sdmmc.
It is essential for UHS support which requires 1.8V signal voltage.

Many thanks to Heiko's great advice!

Changes in v2:
- Rename gpio_syscon10 to gpio_mute in doc
- Rename gpio_syscon10 to gpio_mute in rk3328.dtsi
- Rename gpio_syscon10 to gpio_mute in rk3328-roc-cc.dts

Changes in v1:
- New: allow fetching syscon from parent node in gpio-syscon driver
- Refactured for general gpio-syscon usage for Rockchip SoCs.
- Add doc rockchip,gpio-syscon.txt
- Split from V0 into small patches
- Sort dts properties in sdmmc node

Heiko Stuebner (1):
  gpio: syscon: allow fetching syscon from parent node

Levin Du (4):
  gpio: syscon: Add gpio-syscon for rockchip
  arm64: dts: rockchip: Add gpio-mute to rk3328
  arm64: dts: rockchip: Add io-domain to roc-rk3328-cc
  arm64: dts: rockchip: Add sdmmc UHS support for roc-rk3328-cc

 .../bindings/gpio/rockchip,gpio-syscon.txt | 41 ++
 arch/arm64/boot/dts/rockchip/rk3328-roc-cc.dts | 30 
 arch/arm64/boot/dts/rockchip/rk3328.dtsi   |  7 
 drivers/gpio/gpio-syscon.c | 32 +
 4 files changed, 110 insertions(+)
 create mode 100644 
Documentation/devicetree/bindings/gpio/rockchip,gpio-syscon.txt

-- 
2.7.4

[PATCH v2] net: qcom/emac: Allocate buffers from local node

[Hemanth Puranik]

Currently we use non-NUMA aware allocation for TPD and RRD buffers,
this patch modifies to use NUMA friendly allocation.

Signed-off-by: Hemanth Puranik 
---
Change since v1:
- Addressed comments related to ordering

 drivers/net/ethernet/qualcomm/emac/emac-mac.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c 
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 092718a..031f6e6 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -683,10 +683,11 @@ static int emac_tx_q_desc_alloc(struct emac_adapter *adpt,
struct emac_tx_queue *tx_q)
 {
struct emac_ring_header *ring_header = >ring_header;
+   int node = dev_to_node(adpt->netdev->dev.parent);
size_t size;
 
size = sizeof(struct emac_buffer) * tx_q->tpd.count;
-   tx_q->tpd.tpbuff = kzalloc(size, GFP_KERNEL);
+   tx_q->tpd.tpbuff = kzalloc_node(size, GFP_KERNEL, node);
if (!tx_q->tpd.tpbuff)
return -ENOMEM;
 
@@ -723,11 +724,12 @@ static void emac_rx_q_bufs_free(struct emac_adapter *adpt)
 static int emac_rx_descs_alloc(struct emac_adapter *adpt)
 {
struct emac_ring_header *ring_header = >ring_header;
+   int node = dev_to_node(adpt->netdev->dev.parent);
struct emac_rx_queue *rx_q = >rx_q;
size_t size;
 
size = sizeof(struct emac_buffer) * rx_q->rfd.count;
-   rx_q->rfd.rfbuff = kzalloc(size, GFP_KERNEL);
+   rx_q->rfd.rfbuff = kzalloc_node(size, GFP_KERNEL, node);
if (!rx_q->rfd.rfbuff)
return -ENOMEM;
 
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

[PATCH v2] net: qcom/emac: Allocate buffers from local node

[Hemanth Puranik]

Currently we use non-NUMA aware allocation for TPD and RRD buffers,
this patch modifies to use NUMA friendly allocation.

Signed-off-by: Hemanth Puranik 
---
Change since v1:
- Addressed comments related to ordering

 drivers/net/ethernet/qualcomm/emac/emac-mac.c | 6 --
 1 file changed, 4 insertions(+), 2 deletions(-)

diff --git a/drivers/net/ethernet/qualcomm/emac/emac-mac.c 
b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
index 092718a..031f6e6 100644
--- a/drivers/net/ethernet/qualcomm/emac/emac-mac.c
+++ b/drivers/net/ethernet/qualcomm/emac/emac-mac.c
@@ -683,10 +683,11 @@ static int emac_tx_q_desc_alloc(struct emac_adapter *adpt,
struct emac_tx_queue *tx_q)
 {
struct emac_ring_header *ring_header = >ring_header;
+   int node = dev_to_node(adpt->netdev->dev.parent);
size_t size;
 
size = sizeof(struct emac_buffer) * tx_q->tpd.count;
-   tx_q->tpd.tpbuff = kzalloc(size, GFP_KERNEL);
+   tx_q->tpd.tpbuff = kzalloc_node(size, GFP_KERNEL, node);
if (!tx_q->tpd.tpbuff)
return -ENOMEM;
 
@@ -723,11 +724,12 @@ static void emac_rx_q_bufs_free(struct emac_adapter *adpt)
 static int emac_rx_descs_alloc(struct emac_adapter *adpt)
 {
struct emac_ring_header *ring_header = >ring_header;
+   int node = dev_to_node(adpt->netdev->dev.parent);
struct emac_rx_queue *rx_q = >rx_q;
size_t size;
 
size = sizeof(struct emac_buffer) * rx_q->rfd.count;
-   rx_q->rfd.rfbuff = kzalloc(size, GFP_KERNEL);
+   rx_q->rfd.rfbuff = kzalloc_node(size, GFP_KERNEL, node);
if (!rx_q->rfd.rfbuff)
return -ENOMEM;
 
-- 
Qualcomm Datacenter Technologies as an affiliate of Qualcomm Technologies, Inc.
Qualcomm Technologies, Inc. is a member of the
Code Aurora Forum, a Linux Foundation Collaborative Project.

Re: [PATCH rdma-next 4/5] RDMA/hns: Add reset process for RoCE in hip08

[Wei Hu (Xavier)]

On 2018/5/17 23:14, Jason Gunthorpe wrote:
> On Thu, May 17, 2018 at 04:02:52PM +0800, Wei Hu (Xavier) wrote:
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index 86ef15f..e1c44a6 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -774,6 +774,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev *hr_dev,
>>  int ret = 0;
>>  int ntc;
>>  
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  spin_lock_bh(>lock);
>>  
>>  if (num > hns_roce_cmq_space(csq)) {
>> @@ -4790,6 +4793,7 @@ static int hns_roce_hw_v2_init_instance(struct 
>> hnae3_handle *handle)
>>  return 0;
>>  
>>  error_failed_get_cfg:
>> +handle->priv = NULL;
>>  kfree(hr_dev->priv);
>>  
>>  error_failed_kzalloc:
>> @@ -4803,14 +4807,70 @@ static void hns_roce_hw_v2_uninit_instance(struct 
>> hnae3_handle *handle,
>>  {
>>  struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>>  
>> +if (!hr_dev)
>> +return;
>> +
>>  hns_roce_exit(hr_dev);
>> +handle->priv = NULL;
>>  kfree(hr_dev->priv);
>>  ib_dealloc_device(_dev->ib_dev);
>>  }
> Why are these hunks here? If init fails then uninit should not be
> called, so why meddle with priv?
In hns_roce_hw_v2_init_instance function, we evaluate handle->priv with 
hr_dev,
We want clear the value in hns_roce_hw_v2_uninit_instance function.
So we can ensure no problem in RoCE driver.


static int hns_roce_hw_v2_init_instance(struct hnae3_handle *handle)
{
struct hns_roce_dev *hr_dev;
int ret;

hr_dev = (struct hns_roce_dev *)ib_alloc_device(sizeof(*hr_dev));
if (!hr_dev)
return -ENOMEM;

   ...// other code

handle->priv = hr_dev;

// other code

return 0;

error_xxx:
handle->priv = NULL;
...// other code

error_:
ib_dealloc_device(_dev->ib_dev);

return ret;
}

static void hns_roce_hw_v2_uninit_instance(struct hnae3_handle *handle,
   bool reset)
{
struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;

if (!hr_dev)
return;

hns_roce_exit(hr_dev);
handle->priv = NULL;
kfree(hr_dev->priv);
ib_dealloc_device(_dev->ib_dev);
}

>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: [PATCH rdma-next 4/5] RDMA/hns: Add reset process for RoCE in hip08

[Wei Hu (Xavier)]

On 2018/5/17 23:14, Jason Gunthorpe wrote:
> On Thu, May 17, 2018 at 04:02:52PM +0800, Wei Hu (Xavier) wrote:
>> diff --git a/drivers/infiniband/hw/hns/hns_roce_hw_v2.c 
>> b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> index 86ef15f..e1c44a6 100644
>> +++ b/drivers/infiniband/hw/hns/hns_roce_hw_v2.c
>> @@ -774,6 +774,9 @@ static int hns_roce_cmq_send(struct hns_roce_dev *hr_dev,
>>  int ret = 0;
>>  int ntc;
>>  
>> +if (hr_dev->is_reset)
>> +return 0;
>> +
>>  spin_lock_bh(>lock);
>>  
>>  if (num > hns_roce_cmq_space(csq)) {
>> @@ -4790,6 +4793,7 @@ static int hns_roce_hw_v2_init_instance(struct 
>> hnae3_handle *handle)
>>  return 0;
>>  
>>  error_failed_get_cfg:
>> +handle->priv = NULL;
>>  kfree(hr_dev->priv);
>>  
>>  error_failed_kzalloc:
>> @@ -4803,14 +4807,70 @@ static void hns_roce_hw_v2_uninit_instance(struct 
>> hnae3_handle *handle,
>>  {
>>  struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;
>>  
>> +if (!hr_dev)
>> +return;
>> +
>>  hns_roce_exit(hr_dev);
>> +handle->priv = NULL;
>>  kfree(hr_dev->priv);
>>  ib_dealloc_device(_dev->ib_dev);
>>  }
> Why are these hunks here? If init fails then uninit should not be
> called, so why meddle with priv?
In hns_roce_hw_v2_init_instance function, we evaluate handle->priv with 
hr_dev,
We want clear the value in hns_roce_hw_v2_uninit_instance function.
So we can ensure no problem in RoCE driver.


static int hns_roce_hw_v2_init_instance(struct hnae3_handle *handle)
{
struct hns_roce_dev *hr_dev;
int ret;

hr_dev = (struct hns_roce_dev *)ib_alloc_device(sizeof(*hr_dev));
if (!hr_dev)
return -ENOMEM;

   ...// other code

handle->priv = hr_dev;

// other code

return 0;

error_xxx:
handle->priv = NULL;
...// other code

error_:
ib_dealloc_device(_dev->ib_dev);

return ret;
}

static void hns_roce_hw_v2_uninit_instance(struct hnae3_handle *handle,
   bool reset)
{
struct hns_roce_dev *hr_dev = (struct hns_roce_dev *)handle->priv;

if (!hr_dev)
return;

hns_roce_exit(hr_dev);
handle->priv = NULL;
kfree(hr_dev->priv);
ib_dealloc_device(_dev->ib_dev);
}

>
> Jason
> --
> To unsubscribe from this list: send the line "unsubscribe linux-rdma" in
> the body of a message to majord...@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>
>

Re: [PATCHv2][SMB3] Add kernel trace support

[Ronnie Sahlberg]

Very nice.

Acked-by: Ronnie Sahlberg 

Possibly change the output from 
pid=6633 tid=0x0 sid=0x0 cmd=0 mid=0
to
cmd=0 mid=0 pid=6633 tid=0x0 sid=0x0

just to make it easier for human-searching. I think the cmd will be useful much 
more often than pid/tid/sid
and this would make it easier to look for as all cmd= entries will be aligned 
to the same column.



- Original Message -
From: "Steve French" 
To: "CIFS" , "LKML" , 
"samba-technical" , "linux-fsdevel" 

Sent: Friday, 18 May, 2018 12:36:36 PM
Subject: [PATCHv2][SMB3] Add kernel trace support

Patch updated with additional tracepoint locations and some formatting
improvements. There are some obvious additional tracepoints that could
be added, but this should be a reasonable group to start with.

>From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
From: Steve French 
Date: Thu, 17 May 2018 21:16:55 -0500
Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging

Although dmesg logs and wireshark network traces can be
helpful, being able to dynamically enable/disable tracepoints
(in this case via the kernel ftrace mechanism) can also be
helpful in more quickly debugging problems, and more
selectively tracing the events related to the bug report.

This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
in some obvious locations.  Subsequent patches will add more
as needed.

Example use:
   trace-cmd record -e cifs
   
   trace-cmd show

Various trace events can be filtered. See:
   trace-cmd list | grep cifs
for the current list of cifs tracepoints.

Sample output (from mount and writing to a file):

root@smf:/sys/kernel/debug/tracing/events/cifs# trace-cmd show

  mount.cifs-6633  [006]   7246.936461: smb3_cmd_done:
pid=6633 tid=0x0 sid=0x0 cmd=0 mid=0
  mount.cifs-6633  [006]   7246.936701: smb3_cmd_err:
pid=6633 tid=0x0 sid=0x3d9cf8e5 cmd=1 mid=1 status=0xc016 rc=-5
  mount.cifs-6633  [006]   7246.943055: smb3_cmd_done:
pid=6633 tid=0x0 sid=0x3d9cf8e5 cmd=1 mid=2
  mount.cifs-6633  [006]   7246.943298: smb3_cmd_done:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=3 mid=3
  mount.cifs-6633  [006]   7246.943446: smb3_cmd_done:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=11 mid=4
  mount.cifs-6633  [006]   7246.943659: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=3 mid=5
  mount.cifs-6633  [006]   7246.943766: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=11 mid=6
  mount.cifs-6633  [006]   7246.943937: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=7
  mount.cifs-6633  [006]   7246.944020: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=8
  mount.cifs-6633  [006]   7246.944091: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=9
  mount.cifs-6633  [006]   7246.944163: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=10
  mount.cifs-6633  [006]   7246.944218: smb3_cmd_err:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=11 mid=11 status=0xc225
rc=-2
  mount.cifs-6633  [006]   7246.944219: smb3_fsctl_err: xid=0
fid=0x tid=0xf9447636 sid=0x3d9cf8e5 class=0
type=393620 rc=-2
  mount.cifs-6633  [007]   7246.944353: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=12
bash-2071  [000]   7256.903844: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=13
bash-2071  [000]   7256.904172: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=14
bash-2071  [000]   7256.904471: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=17 mid=15
bash-2071  [000]   7256.904950: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=16
bash-2071  [000]   7256.905305: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=17 mid=17
bash-2071  [000]   7256.905688: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=6 mid=18
bash-2071  [000]   7256.905809: smb3_write_done: xid=0
fid=0xd628f511 tid=0xe1b781a sid=0x3d9cf8e5 offset=0x0 len=0x1b

Signed-off-by: Steve French 
---
 fs/cifs/Makefile   |   7 +-
 fs/cifs/smb2maperror.c |  10 +-
 fs/cifs/smb2pdu.c  |  56 +++-
 fs/cifs/trace.c|  18 +++
 fs/cifs/trace.h| 298 +
 5 files changed, 379 insertions(+), 10 deletions(-)
 create mode 100644 fs/cifs/trace.c
 create mode 100644 fs/cifs/trace.h

diff --git a/fs/cifs/Makefile b/fs/cifs/Makefile
index 7e4a1e2f0696..85817991ee68 100644
--- a/fs/cifs/Makefile
+++ b/fs/cifs/Makefile
@@ -1,11 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0
 #
-# Makefile for Linux CIFS VFS client
+# Makefile 

Re: [PATCHv2][SMB3] Add kernel trace support

[Ronnie Sahlberg]

Very nice.

Acked-by: Ronnie Sahlberg 

Possibly change the output from 
pid=6633 tid=0x0 sid=0x0 cmd=0 mid=0
to
cmd=0 mid=0 pid=6633 tid=0x0 sid=0x0

just to make it easier for human-searching. I think the cmd will be useful much 
more often than pid/tid/sid
and this would make it easier to look for as all cmd= entries will be aligned 
to the same column.



- Original Message -
From: "Steve French" 
To: "CIFS" , "LKML" , 
"samba-technical" , "linux-fsdevel" 

Sent: Friday, 18 May, 2018 12:36:36 PM
Subject: [PATCHv2][SMB3] Add kernel trace support

Patch updated with additional tracepoint locations and some formatting
improvements. There are some obvious additional tracepoints that could
be added, but this should be a reasonable group to start with.

>From edc02d6f9dc24963d510c7ef59067428d3b082d3 Mon Sep 17 00:00:00 2001
From: Steve French 
Date: Thu, 17 May 2018 21:16:55 -0500
Subject: [PATCH] smb3: Add ftrace tracepoints for improved SMB3 debugging

Although dmesg logs and wireshark network traces can be
helpful, being able to dynamically enable/disable tracepoints
(in this case via the kernel ftrace mechanism) can also be
helpful in more quickly debugging problems, and more
selectively tracing the events related to the bug report.

This patch adds 12 ftrace tracepoints to cifs.ko for SMB3 events
in some obvious locations.  Subsequent patches will add more
as needed.

Example use:
   trace-cmd record -e cifs
   
   trace-cmd show

Various trace events can be filtered. See:
   trace-cmd list | grep cifs
for the current list of cifs tracepoints.

Sample output (from mount and writing to a file):

root@smf:/sys/kernel/debug/tracing/events/cifs# trace-cmd show

  mount.cifs-6633  [006]   7246.936461: smb3_cmd_done:
pid=6633 tid=0x0 sid=0x0 cmd=0 mid=0
  mount.cifs-6633  [006]   7246.936701: smb3_cmd_err:
pid=6633 tid=0x0 sid=0x3d9cf8e5 cmd=1 mid=1 status=0xc016 rc=-5
  mount.cifs-6633  [006]   7246.943055: smb3_cmd_done:
pid=6633 tid=0x0 sid=0x3d9cf8e5 cmd=1 mid=2
  mount.cifs-6633  [006]   7246.943298: smb3_cmd_done:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=3 mid=3
  mount.cifs-6633  [006]   7246.943446: smb3_cmd_done:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=11 mid=4
  mount.cifs-6633  [006]   7246.943659: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=3 mid=5
  mount.cifs-6633  [006]   7246.943766: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=11 mid=6
  mount.cifs-6633  [006]   7246.943937: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=7
  mount.cifs-6633  [006]   7246.944020: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=8
  mount.cifs-6633  [006]   7246.944091: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=9
  mount.cifs-6633  [006]   7246.944163: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=10
  mount.cifs-6633  [006]   7246.944218: smb3_cmd_err:
pid=6633 tid=0xf9447636 sid=0x3d9cf8e5 cmd=11 mid=11 status=0xc225
rc=-2
  mount.cifs-6633  [006]   7246.944219: smb3_fsctl_err: xid=0
fid=0x tid=0xf9447636 sid=0x3d9cf8e5 class=0
type=393620 rc=-2
  mount.cifs-6633  [007]   7246.944353: smb3_cmd_done:
pid=6633 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=12
bash-2071  [000]   7256.903844: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=13
bash-2071  [000]   7256.904172: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=16 mid=14
bash-2071  [000]   7256.904471: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=17 mid=15
bash-2071  [000]   7256.904950: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=5 mid=16
bash-2071  [000]   7256.905305: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=17 mid=17
bash-2071  [000]   7256.905688: smb3_cmd_done:
pid=2071 tid=0xe1b781a sid=0x3d9cf8e5 cmd=6 mid=18
bash-2071  [000]   7256.905809: smb3_write_done: xid=0
fid=0xd628f511 tid=0xe1b781a sid=0x3d9cf8e5 offset=0x0 len=0x1b

Signed-off-by: Steve French 
---
 fs/cifs/Makefile   |   7 +-
 fs/cifs/smb2maperror.c |  10 +-
 fs/cifs/smb2pdu.c  |  56 +++-
 fs/cifs/trace.c|  18 +++
 fs/cifs/trace.h| 298 +
 5 files changed, 379 insertions(+), 10 deletions(-)
 create mode 100644 fs/cifs/trace.c
 create mode 100644 fs/cifs/trace.h

diff --git a/fs/cifs/Makefile b/fs/cifs/Makefile
index 7e4a1e2f0696..85817991ee68 100644
--- a/fs/cifs/Makefile
+++ b/fs/cifs/Makefile
@@ -1,11 +1,12 @@
 # SPDX-License-Identifier: GPL-2.0
 #
-# Makefile for Linux CIFS VFS client
+# Makefile for Linux CIFS/SMB2/SMB3 VFS client
 #
+ccflags-y += -I$(src)# needed for trace events
 obj-$(CONFIG_CIFS) += cifs.o

-cifs-y := cifsfs.o cifssmb.o cifs_debug.o connect.o dir.o file.o inode.o \
-  

[PATCH v2] Print the memcg's name when system-wide OOM happened

[ufo19890607]

From: yuzhoujian 

The dump_header does not print the memcg's name when the system
oom happened. So users cannot locate the certain container which
contains the task that has been killed by the oom killer. System
oom report will contain the memcg's name after this patch.

Changes since v1:
- replace adding mem_cgroup_print_oom_info with printing the memcg's
  name only.

Signed-off-by: yuzhoujian 
---
 mm/oom_kill.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 8ba6cb88cf58..b0abb5930232 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -433,6 +433,9 @@ static void dump_header(struct oom_control *oc, struct 
task_struct *p)
if (is_memcg_oom(oc))
mem_cgroup_print_oom_info(oc->memcg, p);
else {
+   pr_info("Task in ");
+   pr_cont_cgroup_path(task_cgroup(p, memory_cgrp_id));
+   pr_cont(" killed as a result of limit of ");
show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
if (is_dump_unreclaim_slabs())
dump_unreclaimable_slab();
-- 
2.14.1

[PATCH v2] Print the memcg's name when system-wide OOM happened

[ufo19890607]

From: yuzhoujian 

The dump_header does not print the memcg's name when the system
oom happened. So users cannot locate the certain container which
contains the task that has been killed by the oom killer. System
oom report will contain the memcg's name after this patch.

Changes since v1:
- replace adding mem_cgroup_print_oom_info with printing the memcg's
  name only.

Signed-off-by: yuzhoujian 
---
 mm/oom_kill.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/mm/oom_kill.c b/mm/oom_kill.c
index 8ba6cb88cf58..b0abb5930232 100644
--- a/mm/oom_kill.c
+++ b/mm/oom_kill.c
@@ -433,6 +433,9 @@ static void dump_header(struct oom_control *oc, struct 
task_struct *p)
if (is_memcg_oom(oc))
mem_cgroup_print_oom_info(oc->memcg, p);
else {
+   pr_info("Task in ");
+   pr_cont_cgroup_path(task_cgroup(p, memory_cgrp_id));
+   pr_cont(" killed as a result of limit of ");
show_mem(SHOW_MEM_FILTER_NODES, oc->nodemask);
if (is_dump_unreclaim_slabs())
dump_unreclaimable_slab();
-- 
2.14.1

[PATCH -mm] mm, huge page: Copy to access sub-page last when copy huge page

[Huang, Ying]

From: Huang Ying 

Huge page helps to reduce TLB miss rate, but it has higher cache
footprint, sometimes this may cause some issue.  For example, when
copying huge page on x86_64 platform, the cache footprint is 4M.  But
on a Xeon E5 v3 2699 CPU, there are 18 cores, 36 threads, and only 45M
LLC (last level cache).  That is, in average, there are 2.5M LLC for
each core and 1.25M LLC for each thread.

If the cache pressure is heavy when copying the huge page, and we copy
the huge page from the begin to the end, it is possible that the begin
of huge page is evicted from the cache after we finishing copying the
end of the huge page.  And it is possible for the application to access
the begin of the huge page after copying the huge page.

To help the above situation, in this patch, when we copy a huge page,
the order to copy sub-pages is changed.  In quite some situation, we
can get the address that the application will access after we copy the
huge page, for example, in a page fault handler.  Instead of copying
the huge page from begin to end, we will copy the sub-pages farthest
from the the sub-page to access firstly, and copy the sub-page to
access last.  This will make the sub-page to access most cache-hot and
sub-pages around it more cache-hot too.  If we cannot know the address
the application will access, the begin of the huge page is assumed to be
the the address the application will access.

The patch is a generic optimization which should benefit quite some
workloads, not for a specific use case.  To demonstrate the performance
benefit of the patch, we tested it with vm-scalability run on
transparent huge page.

With this patch, the throughput increases ~16.6% in vm-scalability
anon-cow-seq test case with 36 processes on a 2 socket Xeon E5 v3 2699
system (36 cores, 72 threads).  The test case set
/sys/kernel/mm/transparent_hugepage/enabled to be always, mmap() a big
anonymous memory area and populate it, then forked 36 child processes,
each writes to the anonymous memory area from the begin to the end, so
cause copy on write.  For each child process, other child processes
could be seen as other workloads which generate heavy cache pressure.
At the same time, the IPC (instruction per cycle) increased from 0.63
to 0.78, and the time spent in user space is reduced ~7.2%.

Signed-off-by: "Huang, Ying" 
Cc: Andi Kleen 
Cc: Jan Kara 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: "Kirill A. Shutemov" 
Cc: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Shaohua Li 
Cc: Christopher Lameter 
Cc: Mike Kravetz 
---
 include/linux/mm.h |  3 ++-
 mm/huge_memory.c   |  3 ++-
 mm/memory.c| 43 +++
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3fa3b1356c34..a5fae31988e6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2732,7 +2732,8 @@ extern void clear_huge_page(struct page *page,
unsigned long addr_hint,
unsigned int pages_per_huge_page);
 extern void copy_user_huge_page(struct page *dst, struct page *src,
-   unsigned long addr, struct vm_area_struct *vma,
+   unsigned long addr_hint,
+   struct vm_area_struct *vma,
unsigned int pages_per_huge_page);
 extern long copy_huge_page_from_user(struct page *dst_page,
const void __user *usr_src,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 323acdd14e6e..7e720e92fcd6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1331,7 +1331,8 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t 
orig_pmd)
if (!page)
clear_huge_page(new_page, vmf->address, HPAGE_PMD_NR);
else
-   copy_user_huge_page(new_page, page, haddr, vma, HPAGE_PMD_NR);
+   copy_user_huge_page(new_page, page, vmf->address,
+   vma, HPAGE_PMD_NR);
__SetPageUptodate(new_page);
 
mmun_start = haddr;
diff --git a/mm/memory.c b/mm/memory.c
index 14578158ed20..f8868c94d6ab 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4654,10 +4654,12 @@ static void copy_user_gigantic_page(struct page *dst, 
struct page *src,
 }
 
 void copy_user_huge_page(struct page *dst, struct page *src,
-unsigned long addr, struct vm_area_struct *vma,
+unsigned long addr_hint, struct vm_area_struct *vma,
 unsigned int pages_per_huge_page)
 {
-   int i;
+   int i, n, base, l;
+   unsigned long addr = addr_hint &
+   ~(((unsigned 

[PATCH -mm] mm, huge page: Copy to access sub-page last when copy huge page

[Huang, Ying]

From: Huang Ying 

Huge page helps to reduce TLB miss rate, but it has higher cache
footprint, sometimes this may cause some issue.  For example, when
copying huge page on x86_64 platform, the cache footprint is 4M.  But
on a Xeon E5 v3 2699 CPU, there are 18 cores, 36 threads, and only 45M
LLC (last level cache).  That is, in average, there are 2.5M LLC for
each core and 1.25M LLC for each thread.

If the cache pressure is heavy when copying the huge page, and we copy
the huge page from the begin to the end, it is possible that the begin
of huge page is evicted from the cache after we finishing copying the
end of the huge page.  And it is possible for the application to access
the begin of the huge page after copying the huge page.

To help the above situation, in this patch, when we copy a huge page,
the order to copy sub-pages is changed.  In quite some situation, we
can get the address that the application will access after we copy the
huge page, for example, in a page fault handler.  Instead of copying
the huge page from begin to end, we will copy the sub-pages farthest
from the the sub-page to access firstly, and copy the sub-page to
access last.  This will make the sub-page to access most cache-hot and
sub-pages around it more cache-hot too.  If we cannot know the address
the application will access, the begin of the huge page is assumed to be
the the address the application will access.

The patch is a generic optimization which should benefit quite some
workloads, not for a specific use case.  To demonstrate the performance
benefit of the patch, we tested it with vm-scalability run on
transparent huge page.

With this patch, the throughput increases ~16.6% in vm-scalability
anon-cow-seq test case with 36 processes on a 2 socket Xeon E5 v3 2699
system (36 cores, 72 threads).  The test case set
/sys/kernel/mm/transparent_hugepage/enabled to be always, mmap() a big
anonymous memory area and populate it, then forked 36 child processes,
each writes to the anonymous memory area from the begin to the end, so
cause copy on write.  For each child process, other child processes
could be seen as other workloads which generate heavy cache pressure.
At the same time, the IPC (instruction per cycle) increased from 0.63
to 0.78, and the time spent in user space is reduced ~7.2%.

Signed-off-by: "Huang, Ying" 
Cc: Andi Kleen 
Cc: Jan Kara 
Cc: Michal Hocko 
Cc: Andrea Arcangeli 
Cc: "Kirill A. Shutemov" 
Cc: Matthew Wilcox 
Cc: Hugh Dickins 
Cc: Minchan Kim 
Cc: Shaohua Li 
Cc: Christopher Lameter 
Cc: Mike Kravetz 
---
 include/linux/mm.h |  3 ++-
 mm/huge_memory.c   |  3 ++-
 mm/memory.c| 43 +++
 3 files changed, 43 insertions(+), 6 deletions(-)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 3fa3b1356c34..a5fae31988e6 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -2732,7 +2732,8 @@ extern void clear_huge_page(struct page *page,
unsigned long addr_hint,
unsigned int pages_per_huge_page);
 extern void copy_user_huge_page(struct page *dst, struct page *src,
-   unsigned long addr, struct vm_area_struct *vma,
+   unsigned long addr_hint,
+   struct vm_area_struct *vma,
unsigned int pages_per_huge_page);
 extern long copy_huge_page_from_user(struct page *dst_page,
const void __user *usr_src,
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 323acdd14e6e..7e720e92fcd6 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -1331,7 +1331,8 @@ int do_huge_pmd_wp_page(struct vm_fault *vmf, pmd_t 
orig_pmd)
if (!page)
clear_huge_page(new_page, vmf->address, HPAGE_PMD_NR);
else
-   copy_user_huge_page(new_page, page, haddr, vma, HPAGE_PMD_NR);
+   copy_user_huge_page(new_page, page, vmf->address,
+   vma, HPAGE_PMD_NR);
__SetPageUptodate(new_page);
 
mmun_start = haddr;
diff --git a/mm/memory.c b/mm/memory.c
index 14578158ed20..f8868c94d6ab 100644
--- a/mm/memory.c
+++ b/mm/memory.c
@@ -4654,10 +4654,12 @@ static void copy_user_gigantic_page(struct page *dst, 
struct page *src,
 }
 
 void copy_user_huge_page(struct page *dst, struct page *src,
-unsigned long addr, struct vm_area_struct *vma,
+unsigned long addr_hint, struct vm_area_struct *vma,
 unsigned int pages_per_huge_page)
 {
-   int i;
+   int i, n, base, l;
+   unsigned long addr = addr_hint &
+   ~(((unsigned long)pages_per_huge_page << PAGE_SHIFT) - 1);
 
if (unlikely(pages_per_huge_page > MAX_ORDER_NR_PAGES)) {
copy_user_gigantic_page(dst, src, addr, vma,
@@ -4665,10 +4667,43 @@ void copy_user_huge_page(struct page *dst, struct page 
*src,