Re: [RFC PATCH 6/7] sched/fair: update cpu_capcity to reflect thermal pressure

[Javi Merino]

On Tue, Oct 09, 2018 at 12:25:01PM -0400, Thara Gopinath wrote:
> cpu_capacity relflects the maximum available capacity of a cpu. Thermal
> pressure on a cpu means this maximum available capacity is reduced. This
> patch reduces the average thermal pressure for a cpu from its maximum
> available capacity so that cpu_capacity reflects the actual
> available capacity.
> 
> Signed-off-by: Thara Gopinath 
> ---
>  kernel/sched/fair.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7deb1d0..8651e55 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7497,6 +7497,7 @@ static unsigned long scale_rt_capacity(int cpu)
>  
>   used = READ_ONCE(rq->avg_rt.util_avg);
>   used += READ_ONCE(rq->avg_dl.util_avg);
> + used += READ_ONCE(rq->avg_thermal.load_avg);

IIUIC, you are treating thermal pressure as an artificial load on the
cpu.  If so, this sounds like a hard to maintain hack.  Thermal
pressure have different characteristics to utilization.  What happens
if thermal sets the cpu cooling state back to 0 because there is
thermal headroom again?  Do we keep adding this artificial load to the
cpu just because there was thermal pressure in the past and let it
decay as if it was cpu load?

Cheers,
Javi

Re: [RFC PATCH 6/7] sched/fair: update cpu_capcity to reflect thermal pressure

[Javi Merino]

On Tue, Oct 09, 2018 at 12:25:01PM -0400, Thara Gopinath wrote:
> cpu_capacity relflects the maximum available capacity of a cpu. Thermal
> pressure on a cpu means this maximum available capacity is reduced. This
> patch reduces the average thermal pressure for a cpu from its maximum
> available capacity so that cpu_capacity reflects the actual
> available capacity.
> 
> Signed-off-by: Thara Gopinath 
> ---
>  kernel/sched/fair.c | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
> index 7deb1d0..8651e55 100644
> --- a/kernel/sched/fair.c
> +++ b/kernel/sched/fair.c
> @@ -7497,6 +7497,7 @@ static unsigned long scale_rt_capacity(int cpu)
>  
>   used = READ_ONCE(rq->avg_rt.util_avg);
>   used += READ_ONCE(rq->avg_dl.util_avg);
> + used += READ_ONCE(rq->avg_thermal.load_avg);

IIUIC, you are treating thermal pressure as an artificial load on the
cpu.  If so, this sounds like a hard to maintain hack.  Thermal
pressure have different characteristics to utilization.  What happens
if thermal sets the cpu cooling state back to 0 because there is
thermal headroom again?  Do we keep adding this artificial load to the
cpu just because there was thermal pressure in the past and let it
decay as if it was cpu load?

Cheers,
Javi

Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool

[Bjorn Andersson]

On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:

> This patch creates a dedicated vdev subdevice for each vdev declared
> in firmware resource table and associates carveout named "vdev%dbuffer"
> (with %d vdev index in resource table) if any as dma coherent memory pool.
> 
> Then vdev subdevice is used as parent for virtio device.
> 
> Signed-off-by: Loic Pallardy 
> ---
>  drivers/remoteproc/remoteproc_core.c | 35 +++---
>  drivers/remoteproc/remoteproc_internal.h |  1 +
>  drivers/remoteproc/remoteproc_virtio.c   | 42 
> +++-
>  include/linux/remoteproc.h   |  1 +
>  4 files changed, 75 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 4edc6f0..adcc66e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc *rproc)
>   iommu_domain_free(domain);
>  }
>  
> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
>  {
>   /*
>* Return physical address according to virtual address location
> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void *cpu_addr)
>   WARN_ON(!virt_addr_valid(cpu_addr));
>   return virt_to_phys(cpu_addr);
>  }
> +EXPORT_SYMBOL(rproc_va_to_pa);
>  
>  /**
>   * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc 
> address
> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct rproc_subdev 
> *subdev, bool crashed)
>  }
>  
>  /**
> + * rproc_rvdev_release() - release the existence of a rvdev
> + *
> + * @dev: the subdevice's dev
> + */
> +static void rproc_rvdev_release(struct device *dev)
> +{
> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev, dev);
> +
> + of_reserved_mem_device_release(dev);
> +
> + kfree(rvdev);
> +}
> +
> +/**
>   * rproc_handle_vdev() - handle a vdev fw resource
>   * @rproc: the remote processor
>   * @rsc: the vring resource descriptor
> @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   struct device *dev = >dev;
>   struct rproc_vdev *rvdev;
>   int i, ret;
> + char name[16];
>  
>   /* make sure resource isn't truncated */
>   if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring)
> @@ -488,6 +505,18 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   rvdev->rproc = rproc;
>   rvdev->index = rproc->nb_vdev++;
>  
> + /* Initialise vdev subdevice */
> + snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> + rvdev->dev.parent = rproc->dev.parent;
> + rvdev->dev.release = rproc_rvdev_release;
> + dev_set_name(>dev, "%s#%s", dev_name(rvdev->dev.parent), name);
> + dev_set_drvdata(>dev, rvdev);
> + dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> +
> + ret = device_register(>dev);
> + if (ret)
> + goto free_rvdev;
> +
>   /* parse the vrings */
>   for (i = 0; i < rsc->num_of_vrings; i++) {
>   ret = rproc_parse_vring(rvdev, rsc, i);
> @@ -518,7 +547,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   for (i--; i >= 0; i--)
>   rproc_free_vring(>vring[i]);
>  free_rvdev:
> - kfree(rvdev);
> + device_unregister(>dev);
>   return ret;
>  }
>  
> @@ -536,7 +565,7 @@ void rproc_vdev_release(struct kref *ref)
>  
>   rproc_remove_subdev(rproc, >subdev);
>   list_del(>node);
> - kfree(rvdev);
> + device_unregister(>dev);
>  }
>  
>  /**
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index f6cad24..bfeacfd 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -52,6 +52,7 @@ struct dentry *rproc_create_trace_file(const char *name, 
> struct rproc *rproc,
>  int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
>  
>  void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
> +phys_addr_t rproc_va_to_pa(void *cpu_addr);
>  int rproc_trigger_recovery(struct rproc *rproc);
>  
>  int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
> index de21f62..9ee63c0 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -17,7 +17,9 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -315,10 +317,48 @@ static void rproc_virtio_dev_release(struct device *dev)
>  int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>  {
>   

Re: [PATCH v4 13/17] remoteproc: create vdev subdevice with specific dma memory pool

[Bjorn Andersson]

On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:

> This patch creates a dedicated vdev subdevice for each vdev declared
> in firmware resource table and associates carveout named "vdev%dbuffer"
> (with %d vdev index in resource table) if any as dma coherent memory pool.
> 
> Then vdev subdevice is used as parent for virtio device.
> 
> Signed-off-by: Loic Pallardy 
> ---
>  drivers/remoteproc/remoteproc_core.c | 35 +++---
>  drivers/remoteproc/remoteproc_internal.h |  1 +
>  drivers/remoteproc/remoteproc_virtio.c   | 42 
> +++-
>  include/linux/remoteproc.h   |  1 +
>  4 files changed, 75 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/remoteproc/remoteproc_core.c 
> b/drivers/remoteproc/remoteproc_core.c
> index 4edc6f0..adcc66e 100644
> --- a/drivers/remoteproc/remoteproc_core.c
> +++ b/drivers/remoteproc/remoteproc_core.c
> @@ -39,6 +39,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -145,7 +146,7 @@ static void rproc_disable_iommu(struct rproc *rproc)
>   iommu_domain_free(domain);
>  }
>  
> -static phys_addr_t rproc_va_to_pa(void *cpu_addr)
> +phys_addr_t rproc_va_to_pa(void *cpu_addr)
>  {
>   /*
>* Return physical address according to virtual address location
> @@ -160,6 +161,7 @@ static phys_addr_t rproc_va_to_pa(void *cpu_addr)
>   WARN_ON(!virt_addr_valid(cpu_addr));
>   return virt_to_phys(cpu_addr);
>  }
> +EXPORT_SYMBOL(rproc_va_to_pa);
>  
>  /**
>   * rproc_da_to_va() - lookup the kernel virtual address for a remoteproc 
> address
> @@ -423,6 +425,20 @@ static void rproc_vdev_do_stop(struct rproc_subdev 
> *subdev, bool crashed)
>  }
>  
>  /**
> + * rproc_rvdev_release() - release the existence of a rvdev
> + *
> + * @dev: the subdevice's dev
> + */
> +static void rproc_rvdev_release(struct device *dev)
> +{
> + struct rproc_vdev *rvdev = container_of(dev, struct rproc_vdev, dev);
> +
> + of_reserved_mem_device_release(dev);
> +
> + kfree(rvdev);
> +}
> +
> +/**
>   * rproc_handle_vdev() - handle a vdev fw resource
>   * @rproc: the remote processor
>   * @rsc: the vring resource descriptor
> @@ -455,6 +471,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   struct device *dev = >dev;
>   struct rproc_vdev *rvdev;
>   int i, ret;
> + char name[16];
>  
>   /* make sure resource isn't truncated */
>   if (sizeof(*rsc) + rsc->num_of_vrings * sizeof(struct fw_rsc_vdev_vring)
> @@ -488,6 +505,18 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   rvdev->rproc = rproc;
>   rvdev->index = rproc->nb_vdev++;
>  
> + /* Initialise vdev subdevice */
> + snprintf(name, sizeof(name), "vdev%dbuffer", rvdev->index);
> + rvdev->dev.parent = rproc->dev.parent;
> + rvdev->dev.release = rproc_rvdev_release;
> + dev_set_name(>dev, "%s#%s", dev_name(rvdev->dev.parent), name);
> + dev_set_drvdata(>dev, rvdev);
> + dma_set_coherent_mask(>dev, DMA_BIT_MASK(32));
> +
> + ret = device_register(>dev);
> + if (ret)
> + goto free_rvdev;
> +
>   /* parse the vrings */
>   for (i = 0; i < rsc->num_of_vrings; i++) {
>   ret = rproc_parse_vring(rvdev, rsc, i);
> @@ -518,7 +547,7 @@ static int rproc_handle_vdev(struct rproc *rproc, struct 
> fw_rsc_vdev *rsc,
>   for (i--; i >= 0; i--)
>   rproc_free_vring(>vring[i]);
>  free_rvdev:
> - kfree(rvdev);
> + device_unregister(>dev);
>   return ret;
>  }
>  
> @@ -536,7 +565,7 @@ void rproc_vdev_release(struct kref *ref)
>  
>   rproc_remove_subdev(rproc, >subdev);
>   list_del(>node);
> - kfree(rvdev);
> + device_unregister(>dev);
>  }
>  
>  /**
> diff --git a/drivers/remoteproc/remoteproc_internal.h 
> b/drivers/remoteproc/remoteproc_internal.h
> index f6cad24..bfeacfd 100644
> --- a/drivers/remoteproc/remoteproc_internal.h
> +++ b/drivers/remoteproc/remoteproc_internal.h
> @@ -52,6 +52,7 @@ struct dentry *rproc_create_trace_file(const char *name, 
> struct rproc *rproc,
>  int rproc_alloc_vring(struct rproc_vdev *rvdev, int i);
>  
>  void *rproc_da_to_va(struct rproc *rproc, u64 da, int len);
> +phys_addr_t rproc_va_to_pa(void *cpu_addr);
>  int rproc_trigger_recovery(struct rproc *rproc);
>  
>  int rproc_elf_sanity_check(struct rproc *rproc, const struct firmware *fw);
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
> index de21f62..9ee63c0 100644
> --- a/drivers/remoteproc/remoteproc_virtio.c
> +++ b/drivers/remoteproc/remoteproc_virtio.c
> @@ -17,7 +17,9 @@
>   * GNU General Public License for more details.
>   */
>  
> +#include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -315,10 +317,48 @@ static void rproc_virtio_dev_release(struct device *dev)
>  int rproc_add_virtio_dev(struct rproc_vdev *rvdev, int id)
>  {
>   

Re: [PATCH 4.4 000/113] 4.4.160-stable review

[Greg Kroah-Hartman]

On Tue, Oct 09, 2018 at 02:05:01PM -0700, Guenter Roeck wrote:
> On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.160 release.
> > There are 113 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Oct 10 17:55:13 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 150 pass: 150 fail: 0
> Qemu test results:
>   total: 286 pass: 286 fail: 0
> 
> The previously reported failure of
> powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
> is no longer reported because CONFIG_OF_UNITTEST is now disabled.
> This applies to all reports.

That's one way to fix the failing test :)

Seriously, hopefully Rob's fix for this lands soon.

Thanks for testing all of these and letting me know,

greg k-h

Re: [PATCH 4.18 000/168] 4.18.13-stable review

[Greg Kroah-Hartman]

On Wed, Oct 10, 2018 at 09:42:46AM +0530, Naresh Kamboju wrote:
> On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
>  wrote:
> >
> > On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.18.13 release.
> > > There are 168 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed Oct 10 17:55:44 UTC 2018.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >   
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc1.gz
> > > or in the git tree and branch at:
> > >   
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > > linux-4.18.y
> >
> > -rc2 is out to resolve some reported issues:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc2.gz
> >
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
> 
> NOTE: Now the reports gets regressions and fixes.


Great, thanks for testing all of these and letting me know.

greg k-h

Re: [PATCH 4.4 000/113] 4.4.160-stable review

[Greg Kroah-Hartman]

On Tue, Oct 09, 2018 at 02:05:01PM -0700, Guenter Roeck wrote:
> On Mon, Oct 08, 2018 at 08:30:01PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.4.160 release.
> > There are 113 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> > 
> > Responses should be made by Wed Oct 10 17:55:13 UTC 2018.
> > Anything received after that time might be too late.
> > 
> 
> Build results:
>   total: 150 pass: 150 fail: 0
> Qemu test results:
>   total: 286 pass: 286 fail: 0
> 
> The previously reported failure of
> powerpc:g3beige:ppc_book3s_defconfig:nosmp:ide:rootfs
> is no longer reported because CONFIG_OF_UNITTEST is now disabled.
> This applies to all reports.

That's one way to fix the failing test :)

Seriously, hopefully Rob's fix for this lands soon.

Thanks for testing all of these and letting me know,

greg k-h

Re: [PATCH 4.18 000/168] 4.18.13-stable review

[Greg Kroah-Hartman]

On Wed, Oct 10, 2018 at 09:42:46AM +0530, Naresh Kamboju wrote:
> On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
>  wrote:
> >
> > On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > > This is the start of the stable review cycle for the 4.18.13 release.
> > > There are 168 patches in this series, all will be posted as a response
> > > to this one.  If anyone has any issues with these being applied, please
> > > let me know.
> > >
> > > Responses should be made by Wed Oct 10 17:55:44 UTC 2018.
> > > Anything received after that time might be too late.
> > >
> > > The whole patch series can be found in one patch at:
> > >   
> > > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc1.gz
> > > or in the git tree and branch at:
> > >   
> > > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > > linux-4.18.y
> >
> > -rc2 is out to resolve some reported issues:
> > 
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc2.gz
> >
> 
> Results from Linaro’s test farm.
> No regressions on arm64, arm, x86_64, and i386.
> 
> NOTE: Now the reports gets regressions and fixes.


Great, thanks for testing all of these and letting me know.

greg k-h

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

Laurent Pinchart schrieb:
> Hi Josh,
> 
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
 On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> The current code of conduct has an ambiguity in the it considers
> publishing private information such as email addresses unacceptable
> behaviour. Since the Linux kernel collects and publishes email
> addresses as part of the patch process, add an exception clause for
> email addresses ordinarily collected by the project to correct this
> ambiguity.

 Upstream has now adopted a FAQ, which addresses this and many other
 questions. See https://www.contributor-covenant.org/faq .

 Might I suggest adding that link to the bottom of the document, instead?
 (And then, optionally, submitting entries for that FAQ.)
>>>
>>> The Code of Conflict has 28 lines, including the heading.
>>> The Code of Conduct has 81 lines, including the heading. And it needs a
>>> FAQ. Hm.
>>
>> Yes, it turns out to be a more complicated problem than it was
>> previously oversimplified to. People don't automatically share a common
>> understanding.
> 
> I see an elephant in the room in the fact that we have carefully avoided 
> discussing whether people share a common goal here :-/
> 
I've been thinking about this a bit lately. Maybe it might be good to 
explicitly mention that common
goal in a sort of a preamble. Here are the first few lines of what came to my 
mind:


Code of Conduct
+++

The goal of the Linux kernel development process is to maintain and advance
the most robust operating system kernel ever.

Needless to say, views on how to achieve this will differ at times.

In order to keep arguments civilized and to ensure an open, positive
and constructive environment, we have setup guidelines
that participants are expected to comply with:

No bias
===

Nobody must be discriminated or favored due to personal traits like
- for example - age, gender or ethnicity. They are irrelevant.
What counts is whether the contribution is in line with a/m goal.
Any such contribution will be carefully reviewed.

Be excellent to each other
==
[...]


So long!

Rainer Fiebig

Re: [Ksummit-discuss] [PATCH 1/2] code-of-conduct: Fix the ambiguity about collecting email addresses

[Rainer Fiebig]

Laurent Pinchart schrieb:
> Hi Josh,
> 
> On Tuesday, 9 October 2018 21:56:23 EEST Josh Triplett wrote:
>> On Tue, Oct 09, 2018 at 08:29:24PM +0200, Rainer Fiebig wrote:
>>> Am Montag, 8. Oktober 2018, 08:20:44 schrieb Josh Triplett:
 On Sat, Oct 06, 2018 at 02:36:39PM -0700, James Bottomley wrote:
> The current code of conduct has an ambiguity in the it considers
> publishing private information such as email addresses unacceptable
> behaviour. Since the Linux kernel collects and publishes email
> addresses as part of the patch process, add an exception clause for
> email addresses ordinarily collected by the project to correct this
> ambiguity.

 Upstream has now adopted a FAQ, which addresses this and many other
 questions. See https://www.contributor-covenant.org/faq .

 Might I suggest adding that link to the bottom of the document, instead?
 (And then, optionally, submitting entries for that FAQ.)
>>>
>>> The Code of Conflict has 28 lines, including the heading.
>>> The Code of Conduct has 81 lines, including the heading. And it needs a
>>> FAQ. Hm.
>>
>> Yes, it turns out to be a more complicated problem than it was
>> previously oversimplified to. People don't automatically share a common
>> understanding.
> 
> I see an elephant in the room in the fact that we have carefully avoided 
> discussing whether people share a common goal here :-/
> 
I've been thinking about this a bit lately. Maybe it might be good to 
explicitly mention that common
goal in a sort of a preamble. Here are the first few lines of what came to my 
mind:


Code of Conduct
+++

The goal of the Linux kernel development process is to maintain and advance
the most robust operating system kernel ever.

Needless to say, views on how to achieve this will differ at times.

In order to keep arguments civilized and to ensure an open, positive
and constructive environment, we have setup guidelines
that participants are expected to comply with:

No bias
===

Nobody must be discriminated or favored due to personal traits like
- for example - age, gender or ethnicity. They are irrelevant.
What counts is whether the contribution is in line with a/m goal.
Any such contribution will be carefully reviewed.

Be excellent to each other
==
[...]


So long!

Rainer Fiebig

Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

[Ingo Molnar]

* Yi Sun  wrote:

> On 18-10-09 12:54:27, Ingo Molnar wrote:
> > 
> > * Yi Sun  wrote:
> > 
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hyper-V.
> > 
> > > +#if defined(CONFIG_SMP)
> > > + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> > > +#endif
> > 
> > What's wrong with using the common pattern of:
> > 
> > #ifdef CONFIG_SMP
> > 
> > ?
> 
> There is no difference between "#ifdef" and "#if defined". I just copied
> it from "hv_smp_prepare_boot_cpu()". Do you need me submit a fix patch
> after this set is merged?

It's equivalent code, my point was that '#ifdef CONFIG_XYZ' is the shorter, 
more canonical 
pattern we use in the kernel most of the time, it's shorter, easier to read. We 
only use 
defined() for longer preprocessor directive conditions, and it's a pattern for 
"there's 
something more complex here than a simple CONFIG_XYZ dependency".

Anyway, Thomas fixed it up in the latest iteration.

Thanks,

Ingo

Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

[Ingo Molnar]

* Yi Sun  wrote:

> On 18-10-09 12:54:27, Ingo Molnar wrote:
> > 
> > * Yi Sun  wrote:
> > 
> > > Follow PV spinlock mechanism to implement the callback functions
> > > to allow the CPU idling and kicking operations on Hyper-V.
> > 
> > > +#if defined(CONFIG_SMP)
> > > + smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> > > +#endif
> > 
> > What's wrong with using the common pattern of:
> > 
> > #ifdef CONFIG_SMP
> > 
> > ?
> 
> There is no difference between "#ifdef" and "#if defined". I just copied
> it from "hv_smp_prepare_boot_cpu()". Do you need me submit a fix patch
> after this set is merged?

It's equivalent code, my point was that '#ifdef CONFIG_XYZ' is the shorter, 
more canonical 
pattern we use in the kernel most of the time, it's shorter, easier to read. We 
only use 
defined() for longer preprocessor directive conditions, and it's a pattern for 
"there's 
something more complex here than a simple CONFIG_XYZ dependency".

Anyway, Thomas fixed it up in the latest iteration.

Thanks,

Ingo

Re: [PATCH v2] clocksource/drivers/fttmr010: fix invalid interrupt register access

[Tao Ren]

On 10/7/18, 2:03 PM, "Linus Walleij"  wrote:

>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
>> not interrupt status register on ast2400 and ast2500 chips. Although
>> there is no side effect to reset the register in fttmr010_common_init(),
>> it's just misleading to do so.
>>
>> Besides, "count_down" is renamed to "is_aspeed" in "fttmr010" structure,
>> and more comments are added so the code is more readble.
>>
>> Signed-off-by: Tao Ren 
>> ---
>> Changes in v2:
>>   - "count_down" is renamed to "is_aspeed" in "fttmr010" structure.
>>   - more comments are added to make the code more readable.
>>
>Reviewed-by: Linus Walleij 

Thanks for the review, Linus.


- Tao Ren

Re: [PATCH v2] clocksource/drivers/fttmr010: fix invalid interrupt register access

[Tao Ren]

On 10/7/18, 2:03 PM, "Linus Walleij"  wrote:

>> TIMER_INTR_MASK register (Base Address of Timer + 0x38) is not designed
>> for masking interrupts on ast2500 chips, and it's not even listed in
>> ast2400 datasheet, so it's not safe to access TIMER_INTR_MASK on aspeed
>> chips.
>>
>> Similarly, TIMER_INTR_STATE register (Base Address of Timer + 0x34) is
>> not interrupt status register on ast2400 and ast2500 chips. Although
>> there is no side effect to reset the register in fttmr010_common_init(),
>> it's just misleading to do so.
>>
>> Besides, "count_down" is renamed to "is_aspeed" in "fttmr010" structure,
>> and more comments are added so the code is more readble.
>>
>> Signed-off-by: Tao Ren 
>> ---
>> Changes in v2:
>>   - "count_down" is renamed to "is_aspeed" in "fttmr010" structure.
>>   - more comments are added to make the code more readable.
>>
>Reviewed-by: Linus Walleij 

Thanks for the review, Linus.


- Tao Ren

linux-next: Tree for Oct 10

[Stephen Rothwell]

Hi all,

Changes since 20181009:

The ext4 tree lost its build failure.

The kvm-ppc tree gained a conflict against the kvm-arm tree.

Non-merge commits (relative to Linus' tree): 9423
 8942 files changed, 420582 insertions(+), 194157 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 291 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (64c5e530ac2c Merge tag 'arc-4.19-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ab515a3c8ca5 samples: disable CONFIG_SAMPLES for 
UML)
Merging arc-current/for-curr (c58a584f05e3 ARC: clone syscall to setp r25 as 
thread pointer)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (2a3f93459d68 arm64: KVM: Sanitize PSTATE.M 
when being set from userspace)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a offline 
node in kdump path)
Merging sparc/master (ff5d1a42096c sunvdc: Remove VLA usage)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (4cf34c0cf60e Merge branch 'ena-fixes')
Merging bpf/master (262f9d811c76 bpf: do not blindly change rlimit in reuseport 
net selftest)
Merging ipsec/master (4da402597c2b xfrm: fix gro_cells leak when remove virtual 
xfrm interfaces)
Merging netfilter/master (1ad98e9d1bdf tcp/dccp: fix lockdep issue when SYN is 
backlogged)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue 
size)
Merging mac80211/master (e2a322a0c8ce Merge branch 
'net-smc-userspace-breakage-fixes')
Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before 
releasing reference)
Merging sound-current/for-linus (709ae62e8e6d ALSA: hda/realtek - Cannot adjust 
speaker's volume on Dell XPS 27 7760)
Merging sound-asoc-fixes/for-linus (3aed34a933a4 Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (0238df646e62 Linux 4.19-rc7)
Merging spi-fixes/for-linus (0238df646e62 Linux 4.19-rc7)
Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in 
Kconfig help text)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (0238df646e62 Linux 4.19-rc7)
Merging usb.current/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging staging.current/staging-linus (7876320f8880 Linux 4.19-rc4)
Merging char-misc.current/char-misc-linus (0238df646e62 Linux 4.19-rc7)
Merging soundwire-fixes/fixes (8d6ccf5cebbc soundwire: Fix acquiring bus lock 
twice during master release)
M

linux-next: Tree for Oct 10

[Stephen Rothwell]

Hi all,

Changes since 20181009:

The ext4 tree lost its build failure.

The kvm-ppc tree gained a conflict against the kvm-arm tree.

Non-merge commits (relative to Linus' tree): 9423
 8942 files changed, 420582 insertions(+), 194157 deletions(-)



I have created today's linux-next tree at
git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git
(patches at http://www.kernel.org/pub/linux/kernel/next/ ).  If you
are tracking the linux-next tree using git, you should not use "git pull"
to do so as that will try to merge the new linux-next release with the
old one.  You should use "git fetch" and checkout or reset to the new
master.

You can see which trees have been included by looking in the Next/Trees
file in the source.  There are also quilt-import.log and merge.log
files in the Next directory.  Between each merge, the tree was built
with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a
multi_v7_defconfig for arm and a native build of tools/perf. After
the final fixups (if any), I do an x86_64 modules_install followed by
builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit),
ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc
and sparc64 defconfig. And finally, a simple boot test of the powerpc
pseries_le_defconfig kernel in qemu (with and without kvm enabled).

Below is a summary of the state of the merge.

I am currently merging 291 trees (counting Linus' and 66 trees of bug
fix patches pending for the current merge release).

Stats about the size of the tree over time can be seen at
http://neuling.org/linux-next-size.html .

Status of my local build tests will be at
http://kisskb.ellerman.id.au/linux-next .  If maintainers want to give
advice about cross compilers/configs that work, we are always open to add
more builds.

Thanks to Randy Dunlap for doing many randconfig builds.  And to Paul
Gortmaker for triage and bug fixes.

-- 
Cheers,
Stephen Rothwell

$ git checkout master
$ git reset --hard stable
Merging origin/master (64c5e530ac2c Merge tag 'arc-4.19-rc8' of 
git://git.kernel.org/pub/scm/linux/kernel/git/vgupta/arc)
Merging fixes/master (72358c0b59b7 linux-next: build warnings from the build of 
Linus' tree)
Merging kbuild-current/fixes (ab515a3c8ca5 samples: disable CONFIG_SAMPLES for 
UML)
Merging arc-current/for-curr (c58a584f05e3 ARC: clone syscall to setp r25 as 
thread pointer)
Merging arm-current/fixes (3a58ac65e2d7 ARM: 8799/1: mm: fix pci_ioremap_io() 
offset check)
Merging arm64-fixes/for-next/fixes (2a3f93459d68 arm64: KVM: Sanitize PSTATE.M 
when being set from userspace)
Merging m68k-current/for-linus (0986b16ab49b m68k/mac: Use correct PMU response 
format)
Merging powerpc-fixes/fixes (ac1788cc7da4 powerpc/numa: Skip onlining a offline 
node in kdump path)
Merging sparc/master (ff5d1a42096c sunvdc: Remove VLA usage)
Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2)
Merging net/master (4cf34c0cf60e Merge branch 'ena-fixes')
Merging bpf/master (262f9d811c76 bpf: do not blindly change rlimit in reuseport 
net selftest)
Merging ipsec/master (4da402597c2b xfrm: fix gro_cells leak when remove virtual 
xfrm interfaces)
Merging netfilter/master (1ad98e9d1bdf tcp/dccp: fix lockdep issue when SYN is 
backlogged)
Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates 
of non-anonymous set)
Merging wireless-drivers/master (3baafeffa48a iwlwifi: 1000: set the TFD queue 
size)
Merging mac80211/master (e2a322a0c8ce Merge branch 
'net-smc-userspace-breakage-fixes')
Merging rdma-fixes/for-rc (5c5702e259dc RDMA/core: Set right entry state before 
releasing reference)
Merging sound-current/for-linus (709ae62e8e6d ALSA: hda/realtek - Cannot adjust 
speaker's volume on Dell XPS 27 7760)
Merging sound-asoc-fixes/for-linus (3aed34a933a4 Merge branch 'asoc-4.19' into 
asoc-linus)
Merging regmap-fixes/for-linus (7876320f8880 Linux 4.19-rc4)
Merging regulator-fixes/for-linus (0238df646e62 Linux 4.19-rc7)
Merging spi-fixes/for-linus (0238df646e62 Linux 4.19-rc7)
Merging pci-current/for-linus (2edab4df98d9 PCI: Expand the "PF" acronym in 
Kconfig help text)
Merging driver-core.current/driver-core-linus (7876320f8880 Linux 4.19-rc4)
Merging tty.current/tty-linus (0238df646e62 Linux 4.19-rc7)
Merging usb.current/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-gadget-fixes/fixes (d9707490077b usb: dwc2: Fix call location of 
dwc2_check_core_endianness)
Merging usb-serial-fixes/usb-linus (0238df646e62 Linux 4.19-rc7)
Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: 
Always build ULPI code)
Merging phy/fixes (5b394b2ddf03 Linux 4.19-rc1)
Merging staging.current/staging-linus (7876320f8880 Linux 4.19-rc4)
Merging char-misc.current/char-misc-linus (0238df646e62 Linux 4.19-rc7)
Merging soundwire-fixes/fixes (8d6ccf5cebbc soundwire: Fix acquiring bus lock 
twice during master release)
M

Re: [RFC PATCH 0/7] Introduce thermal pressure

[Javi Merino]

On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, in event of maximum
> frequency capping of a cpu, the maximum available compute
> capacity of the cpu is not adjusted at all. In other words, scheduler
> is unware maximum cpu capacity restrictions placed due to thermal
> activity.

Interesting, I would have sworn that I tested this years ago by
lowering the maximum frequency of a cpufreq domain, and the scheduler
reacted accordingly to the new maximum capacities of the cpus.

>   This patch series attempts to address this issue.
> The benefits identified are better task placement among available
> cpus in event of overheating which in turn leads to better
> performance numbers.
> 
> The delta between the maximum possible capacity of a cpu and
> maximum available capacity of a cpu due to thermal event can
> be considered as thermal pressure. Instantaneous thermal pressure
> is hard to record and can sometime be erroneous as there can be mismatch
> between the actual capping of capacity and scheduler recording it.
> Thus solution is to have a weighted average per cpu value for thermal
> pressure over time. The weight reflects the amount of time the cpu has
> spent at a capped maximum frequency. To accumulate, average and
> appropriately decay thermal pressure, this patch series uses pelt
> signals and reuses the available framework that does a similar
> bookkeeping of rt/dl task utilization.
> 
> Regarding testing, basic build, boot and sanity testing have been
> performed on hikey960 mainline kernel with debian file system.
> Further aobench (An occlusion renderer for benchmarking realworld
> floating point performance) showed the following results on hikey960
> with debain.
> 
> Result  Standard
> Standard
> (Time secs) Error   
> Deviation
> Hikey 960 - no thermal pressure applied 138.67  6.5211.52%
> Hikey 960 -  thermal pressure applied   122.37  5.7811.57%
> 
> Thara Gopinath (7):
>   sched/pelt: Add option to make load and util calculations frequency
> invariant
>   sched/pelt.c: Add support to track thermal pressure
>   sched: Add infrastructure to store and update instantaneous thermal
> pressure
>   sched: Initialize per cpu thermal pressure structure
>   sched/fair: Enable CFS periodic tick to update thermal pressure
>   sched/fair: update cpu_capcity to reflect thermal pressure
>   thermal/cpu-cooling: Update thermal pressure in case of a maximum
> frequency capping
> 
>  drivers/base/arch_topology.c  |  1 +
>  drivers/thermal/cpu_cooling.c | 20 -

thermal?  There are other ways in which the maximum frequency of a cpu
can be limited, for example from userspace via scaling_max_freq.

When something (anything) changes the maximum frequency of a cpufreq
policy, the scheduler should be notified.  I think this change should
be done in cpufreq instead to make it generic and not particular to
a given maximum frequency "capper".

Cheers,
Javi

Re: [RFC PATCH 0/7] Introduce thermal pressure

[Javi Merino]

On Tue, Oct 09, 2018 at 12:24:55PM -0400, Thara Gopinath wrote:
> Thermal governors can respond to an overheat event for a cpu by
> capping the cpu's maximum possible frequency. This in turn
> means that the maximum available compute capacity of the
> cpu is restricted. But today in linux kernel, in event of maximum
> frequency capping of a cpu, the maximum available compute
> capacity of the cpu is not adjusted at all. In other words, scheduler
> is unware maximum cpu capacity restrictions placed due to thermal
> activity.

Interesting, I would have sworn that I tested this years ago by
lowering the maximum frequency of a cpufreq domain, and the scheduler
reacted accordingly to the new maximum capacities of the cpus.

>   This patch series attempts to address this issue.
> The benefits identified are better task placement among available
> cpus in event of overheating which in turn leads to better
> performance numbers.
> 
> The delta between the maximum possible capacity of a cpu and
> maximum available capacity of a cpu due to thermal event can
> be considered as thermal pressure. Instantaneous thermal pressure
> is hard to record and can sometime be erroneous as there can be mismatch
> between the actual capping of capacity and scheduler recording it.
> Thus solution is to have a weighted average per cpu value for thermal
> pressure over time. The weight reflects the amount of time the cpu has
> spent at a capped maximum frequency. To accumulate, average and
> appropriately decay thermal pressure, this patch series uses pelt
> signals and reuses the available framework that does a similar
> bookkeeping of rt/dl task utilization.
> 
> Regarding testing, basic build, boot and sanity testing have been
> performed on hikey960 mainline kernel with debian file system.
> Further aobench (An occlusion renderer for benchmarking realworld
> floating point performance) showed the following results on hikey960
> with debain.
> 
> Result  Standard
> Standard
> (Time secs) Error   
> Deviation
> Hikey 960 - no thermal pressure applied 138.67  6.5211.52%
> Hikey 960 -  thermal pressure applied   122.37  5.7811.57%
> 
> Thara Gopinath (7):
>   sched/pelt: Add option to make load and util calculations frequency
> invariant
>   sched/pelt.c: Add support to track thermal pressure
>   sched: Add infrastructure to store and update instantaneous thermal
> pressure
>   sched: Initialize per cpu thermal pressure structure
>   sched/fair: Enable CFS periodic tick to update thermal pressure
>   sched/fair: update cpu_capcity to reflect thermal pressure
>   thermal/cpu-cooling: Update thermal pressure in case of a maximum
> frequency capping
> 
>  drivers/base/arch_topology.c  |  1 +
>  drivers/thermal/cpu_cooling.c | 20 -

thermal?  There are other ways in which the maximum frequency of a cpu
can be limited, for example from userspace via scaling_max_freq.

When something (anything) changes the maximum frequency of a cpufreq
policy, the scheduler should be notified.  I think this change should
be done in cpufreq instead to make it generic and not particular to
a given maximum frequency "capper".

Cheers,
Javi

Re: perf report segfault

[Sandipan Das]

Hi Jiri,

Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.

ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")

Adding Milian to the loop as well.

With Regards,
Sandipan

On 10/10/18 3:50 AM, Jiri Olsa wrote:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
>> I can try building perf from the latest sources. I've attached the
>> perf.data and perf.data.tar.bz2 from the test program I sent earlier.
> 
> cool, reproduced.. it seems to get introduced by:
>   2a9d5050dc84 perf script: Show correct offsets for DWARF-based unwinding
> 
> reverting that patch fixes the issue for me, but looks like
> we could just make th attached check and prevent the crash
> 
> adding Sandipan Das to the loop, the author of that commit, any idea?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index c4acd2001db0..ea68c805c7ac 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2312,7 +2312,6 @@ static int unwind_entry(struct unwind_entry *entry, 
> void *arg)
>  {
>   struct callchain_cursor *cursor = arg;
>   const char *srcline = NULL;
> - u64 addr;
>  
>   if (symbol_conf.hide_unresolved && entry->sym == NULL)
>   return 0;
> @@ -2320,13 +2319,15 @@ static int unwind_entry(struct unwind_entry *entry, 
> void *arg)
>   if (append_inlines(cursor, entry->map, entry->sym, entry->ip) == 0)
>   return 0;
>  
> - /*
> -  * Convert entry->ip from a virtual address to an offset in
> -  * its corresponding binary.
> -  */
> - addr = map__map_ip(entry->map, entry->ip);
> + if (entry->map) {
> + /*
> +  * Convert entry->ip from a virtual address to an offset in
> +  * its corresponding binary.
> +  */
> + u64 addr = map__map_ip(entry->map, entry->ip);
> + srcline = callchain_srcline(entry->map, entry->sym, addr);
> + }
>  
> - srcline = callchain_srcline(entry->map, entry->sym, addr);
>   return callchain_cursor_append(cursor, entry->ip,
>  entry->map, entry->sym,
>  false, NULL, 0, 0, 0, srcline);
> 

Re: perf report segfault

[Sandipan Das]

Hi Jiri,

Yes, this happens when entry->map is NULL. While your fix seems correct, the
following commit from Milian Wolff had already addressed this. I think this
was pulled in with one of Arnaldo's recent perf/urgent updates.

ff4ce2885af8 ("perf report: Don't try to map ip to invalid map")

Adding Milian to the loop as well.

With Regards,
Sandipan

On 10/10/18 3:50 AM, Jiri Olsa wrote:
> On Tue, Oct 09, 2018 at 04:47:31PM -0500, Anthony LaTorre wrote:
>> I can try building perf from the latest sources. I've attached the
>> perf.data and perf.data.tar.bz2 from the test program I sent earlier.
> 
> cool, reproduced.. it seems to get introduced by:
>   2a9d5050dc84 perf script: Show correct offsets for DWARF-based unwinding
> 
> reverting that patch fixes the issue for me, but looks like
> we could just make th attached check and prevent the crash
> 
> adding Sandipan Das to the loop, the author of that commit, any idea?
> 
> thanks,
> jirka
> 
> 
> ---
> diff --git a/tools/perf/util/machine.c b/tools/perf/util/machine.c
> index c4acd2001db0..ea68c805c7ac 100644
> --- a/tools/perf/util/machine.c
> +++ b/tools/perf/util/machine.c
> @@ -2312,7 +2312,6 @@ static int unwind_entry(struct unwind_entry *entry, 
> void *arg)
>  {
>   struct callchain_cursor *cursor = arg;
>   const char *srcline = NULL;
> - u64 addr;
>  
>   if (symbol_conf.hide_unresolved && entry->sym == NULL)
>   return 0;
> @@ -2320,13 +2319,15 @@ static int unwind_entry(struct unwind_entry *entry, 
> void *arg)
>   if (append_inlines(cursor, entry->map, entry->sym, entry->ip) == 0)
>   return 0;
>  
> - /*
> -  * Convert entry->ip from a virtual address to an offset in
> -  * its corresponding binary.
> -  */
> - addr = map__map_ip(entry->map, entry->ip);
> + if (entry->map) {
> + /*
> +  * Convert entry->ip from a virtual address to an offset in
> +  * its corresponding binary.
> +  */
> + u64 addr = map__map_ip(entry->map, entry->ip);
> + srcline = callchain_srcline(entry->map, entry->sym, addr);
> + }
>  
> - srcline = callchain_srcline(entry->map, entry->sym, addr);
>   return callchain_cursor_append(cursor, entry->ip,
>  entry->map, entry->sym,
>  false, NULL, 0, 0, 0, srcline);
> 

Re: [PATCH] platform/chrome: chromeos_tbmc - Remove unneeded const

[Benson Leung]

Hi Nathan,

On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
> 
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>  ^
> ./include/linux/pm.h:365:56: note: expanded from macro
> 'SIMPLE_DEV_PM_OPS'
> #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
>^
> 1 warning generated.
> 
> SIMPLE_DEV_PM_OPS is already declared as const, this one is unnecessary
> so remove it.
> 
> Signed-off-by: Nathan Chancellor 

Applied for 4.20. Thank you.

Benson

> ---
>  drivers/platform/chrome/chromeos_tbmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/chromeos_tbmc.c 
> b/drivers/platform/chrome/chromeos_tbmc.c
> index 1e81f8144c0d..ce259ec9f990 100644
> --- a/drivers/platform/chrome/chromeos_tbmc.c
> +++ b/drivers/platform/chrome/chromeos_tbmc.c
> @@ -99,7 +99,7 @@ static const struct acpi_device_id 
> chromeos_tbmc_acpi_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, chromeos_tbmc_acpi_device_ids);
>  
> -static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> +static SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>   chromeos_tbmc_resume);
>  
>  static struct acpi_driver chromeos_tbmc_driver = {
> -- 
> 2.19.0
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH] platform/chrome: chromeos_tbmc - Remove unneeded const

[Benson Leung]

Hi Nathan,

On Mon, Oct 08, 2018 at 03:20:41PM -0700, Nathan Chancellor wrote:
> Clang warns:
> 
> drivers/platform/chrome/chromeos_tbmc.c:102:14: warning: duplicate
> 'const' declaration specifier [-Wduplicate-decl-specifier]
> static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>  ^
> ./include/linux/pm.h:365:56: note: expanded from macro
> 'SIMPLE_DEV_PM_OPS'
> #define SIMPLE_DEV_PM_OPS(name, suspend_fn, resume_fn) \
>^
> 1 warning generated.
> 
> SIMPLE_DEV_PM_OPS is already declared as const, this one is unnecessary
> so remove it.
> 
> Signed-off-by: Nathan Chancellor 

Applied for 4.20. Thank you.

Benson

> ---
>  drivers/platform/chrome/chromeos_tbmc.c | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/drivers/platform/chrome/chromeos_tbmc.c 
> b/drivers/platform/chrome/chromeos_tbmc.c
> index 1e81f8144c0d..ce259ec9f990 100644
> --- a/drivers/platform/chrome/chromeos_tbmc.c
> +++ b/drivers/platform/chrome/chromeos_tbmc.c
> @@ -99,7 +99,7 @@ static const struct acpi_device_id 
> chromeos_tbmc_acpi_device_ids[] = {
>  };
>  MODULE_DEVICE_TABLE(acpi, chromeos_tbmc_acpi_device_ids);
>  
> -static const SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
> +static SIMPLE_DEV_PM_OPS(chromeos_tbmc_pm_ops, NULL,
>   chromeos_tbmc_resume);
>  
>  static struct acpi_driver chromeos_tbmc_driver = {
> -- 
> 2.19.0
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v10 4/5] clk: imx: add imx composite clock

[Sascha Hauer]

On Tue, Oct 09, 2018 at 10:56:14PM +, Leonard Crestez wrote:
> On Tue, 2018-10-09 at 08:37 +, Abel Vesa wrote:
> > +struct clk *imx_clk_composite_8m_flags(const char *name,
> > +   const char **parent_names,
> > +   int num_parents, void __iomem *reg,
> > +   unsigned long flags);
> > +
> > +#define __imx_clk_composite_8m(name, parent_names, reg, flags) \
> > +   imx_clk_composite_8m_flags(name, parent_names, \
> > +   ARRAY_SIZE(parent_names), reg, \
> > +   flags | CLK_SET_RATE_NO_REPARENT | CLK_OPS_PARENT_ENABLE)
> > +
> > +#define imx_clk_composite_8m(name, parent_names, reg) \
> > +   __imx_clk_composite_8m(name, parent_names, reg, 0)
> > +
> > +#define imx_clk_composite_8m_critical(name, parent_names, reg) \
> > +   __imx_clk_composite_8m(name, parent_names, reg, CLK_IS_CRITICAL)
> 
> Does anyone else think that the "8m" would be prettier next to imx
> rather than as a suffix? Using imx8m_clk_composite* and
> imx7ulp_clk_composite* makes more sense to me.

+1

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v10 4/5] clk: imx: add imx composite clock

[Sascha Hauer]

On Tue, Oct 09, 2018 at 10:56:14PM +, Leonard Crestez wrote:
> On Tue, 2018-10-09 at 08:37 +, Abel Vesa wrote:
> > +struct clk *imx_clk_composite_8m_flags(const char *name,
> > +   const char **parent_names,
> > +   int num_parents, void __iomem *reg,
> > +   unsigned long flags);
> > +
> > +#define __imx_clk_composite_8m(name, parent_names, reg, flags) \
> > +   imx_clk_composite_8m_flags(name, parent_names, \
> > +   ARRAY_SIZE(parent_names), reg, \
> > +   flags | CLK_SET_RATE_NO_REPARENT | CLK_OPS_PARENT_ENABLE)
> > +
> > +#define imx_clk_composite_8m(name, parent_names, reg) \
> > +   __imx_clk_composite_8m(name, parent_names, reg, 0)
> > +
> > +#define imx_clk_composite_8m_critical(name, parent_names, reg) \
> > +   __imx_clk_composite_8m(name, parent_names, reg, CLK_IS_CRITICAL)
> 
> Does anyone else think that the "8m" would be prettier next to imx
> rather than as a suffix? Using imx8m_clk_composite* and
> imx7ulp_clk_composite* makes more sense to me.

+1

Sascha

-- 
Pengutronix e.K.   | |
Industrial Linux Solutions | http://www.pengutronix.de/  |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0|
Amtsgericht Hildesheim, HRA 2686   | Fax:   +49-5121-206917- |

Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator

[Bjorn Andersson]

On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
>  int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
[..]
> @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct virtio_device 
> *vdev,
>   rvring->vq = vq;
>   vq->priv = rvring;
>  
> + /* Update vring in resource table */
> + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset;
> + rsc->vring[id].da = mem->da;
> +

This would now happen after we've started the remoteproc. Don't we need
to do this in-between allocating the carveouts and booting the
remoteproc?

Regards,
Bjorn

Re: [PATCH v4 12/17] remoteproc: modify vring allocation to rely on centralized carveout allocator

[Bjorn Andersson]

On Fri 27 Jul 06:14 PDT 2018, Loic Pallardy wrote:
>  int rproc_fw_sanity_check(struct rproc *rproc, const struct firmware *fw)
> diff --git a/drivers/remoteproc/remoteproc_virtio.c 
> b/drivers/remoteproc/remoteproc_virtio.c
[..]
> @@ -114,6 +122,10 @@ static struct virtqueue *rp_find_vq(struct virtio_device 
> *vdev,
>   rvring->vq = vq;
>   vq->priv = rvring;
>  
> + /* Update vring in resource table */
> + rsc = (void *)rproc->table_ptr + rvdev->rsc_offset;
> + rsc->vring[id].da = mem->da;
> +

This would now happen after we've started the remoteproc. Don't we need
to do this in-between allocating the carveouts and booting the
remoteproc?

Regards,
Bjorn

Installation Notes for Teo En Ming Extremely Simple Linux 1810.08

[Turritopsis Dohrnii Teo En Ming]

Installation Notes for Teo En Ming Extremely Simple Linux 1810.08
=

Definitely must watch YouTube video: https://www.youtube.com/watch?v=YrJADssqaQU

Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore

Start: 8th October 2018 Monday 10:00 PM Singapore Time GMT+8
End: 9th October 2018 Tuesday 2:30 AM Singapore Time GMT+8

NOTE: Compiling a Linux operating system on Intel Core i7-5820K (6
cores) will take
approximately 4.5 hours.

Steps
=

001. Download CentOS 7.5 1804 from the mirror at National University
of Singapore (NUS)
http://mirror.nus.edu.sg/centos/7.5.1804/isos/x86_64/CentOS-7-x86_64-DVD-1804.iso

002. Install CentOS 7.5 1804 as an Oracle VirtualBox 5.2.18 virtual
machine in Windows 10 version 1803 host operating system.

003. During Software Selection, choose *Development and Creative
Workstation*. This is mandatory for compiling software and
operating systems.

004. Click Additional Development.

005. Click Development Tools.

006. Click Perl for Web.

007. Click Platform Development.

008. Click Done.

009. After completing installation, login to CentOS 7.5 1804 using Putty.

010. Search for gcc (GNU Compiler Collection).

[teoenming@centos ~]$ rpm -qa | grep gcc
gcc-4.8.5-28.el7.x86_64
gcc-c++-4.8.5-28.el7.x86_64
gcc-gfortran-4.8.5-28.el7.x86_64
libgcc-4.8.5-28.el7.x86_64

011. Search for make.

[teoenming@centos ~]$ rpm -qa | grep make
make-3.82-23.el7.x86_64
automake-1.13.4-3.el7.noarch
cmake-2.8.12.2-2.el7.x86_64

012. Search for ncurses.

[teoenming@centos ~]$ rpm -qa | grep ncurses
ncurses-base-5.9-14.20130511.el7_4.noarch
ncurses-devel-5.9-14.20130511.el7_4.x86_64
ncurses-5.9-14.20130511.el7_4.x86_64
ncurses-libs-5.9-14.20130511.el7_4.x86_64

013. Search for perl.

[teoenming@centos ~]$ rpm -qa | grep perl


014. Search for grub (Grand Unified Boot Loader).

[root@centos ~]# rpm -qa | grep grub
grub2-pc-modules-2.02-0.65.el7.centos.2.noarch
grubby-8.28-23.el7.x86_64
grub2-2.02-0.65.el7.centos.2.x86_64
grub2-common-2.02-0.65.el7.centos.2.noarch
grub2-tools-minimal-2.02-0.65.el7.centos.2.x86_64
grub2-tools-extra-2.02-0.65.el7.centos.2.x86_64
grub2-tools-2.02-0.65.el7.centos.2.x86_64
grub2-pc-2.02-0.65.el7.centos.2.x86_64

***Apparently GRUB Legacy 0.97 has been deprecated on CentOS 7.5.
GRUB2 is now installed by default on CentOS 7.5.***

015. Download the latest binutils-2.31

wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.xz

016. Download the latest busybox-1.29.3

wget https://busybox.net/downloads/busybox-1.29.3.tar.bz2

017. Download the latest Cross Linux From Scratch (CLFS) Bootscripts

wget 
http://ftp.osuosl.org/pub/clfs/conglomeration/clfs-embedded-bootscripts/clfs-embedded-bootscripts-1.0-pre5.tar.bz2

018. Download the latest GNU Compiler Collection (gcc) version 8.2.0

wget https://ftp.gnu.org/gnu/gcc/gcc-8.2.0/gcc-8.2.0.tar.xz

019. Download the latest C Programming Library version 2.28

wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.xz

020. Download the latest gmp-6.1.2

wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.bz2

021. Download the latest Linux Kernel version 4.18.12 (stable branch)

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.18.12.tar.xz

022. Download the latest mpc-1.1.0

wget https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz

023. Download the latest mpfr-4.0.1

wget https://ftp.gnu.org/gnu/mpfr/mpfr-4.0.1.tar.xz

024. Download the latest zlib-1.2.11

wget https://zlib.net/zlib-1.2.11.tar.gz

>From now on, follow Petros Koutoupis' guide at Linux Journal.

[Guide] DIY: Build a Custom Minimal Linux Distribution from Source
Link: 
https://www.linuxjournal.com/content/diy-build-custom-minimal-linux-distribution-source

Follow the instructions until the section "Building the Cross Compiler".

At the Kernel Headers sub-section,

025. Extract the latest Linux Kernel 4.18.12 (stable branch)

tar xfvJ linux-4.18.12.tar.xz

026. Change directory into the Linux Kernel 4.18.12 source code directory

cd linux-4.18.12

Then continue following the instructions.

At the section on Glibc, glibc-2.28 (C Programming Library version
2.28) won't compile.

So we will use glibc-2.27 (C Programming Library version 2.27) instead.

027. Download C Programming Library version 2.27

wget https://ftp.gnu.org/gnu/glibc/glibc-2.27.tar.xz

At "The Bootscripts" section, modify Makefile in the root directory as follows.
You *CANNOT* copy and paste the following code section into a
patchfile and use the patch command
patch -p0  prompt instead.

At the grub> prompt, execute the following commands.

grub> linux /boot/vmlinuz-4.18.12 root=/dev/sda1 ro quiet
grub> boot

Teo En Ming Extremely Simple Linux 1810.08 will now boot up.

Please watch my YouTube video at https://www.youtube.com/watch?v=YrJADssqaQU

Question: Should I use CentOS 6 as my development workstation instead?
This is because CentOS 6 will definitely have GRUB Legacy.


===BEGIN SIGNATURE===

Turritopsis Dohrnii Teo En Ming's 

Installation Notes for Teo En Ming Extremely Simple Linux 1810.08

[Turritopsis Dohrnii Teo En Ming]

Installation Notes for Teo En Ming Extremely Simple Linux 1810.08
=

Definitely must watch YouTube video: https://www.youtube.com/watch?v=YrJADssqaQU

Author: Mr. Turritopsis Dohrnii Teo En Ming
Country: Singapore

Start: 8th October 2018 Monday 10:00 PM Singapore Time GMT+8
End: 9th October 2018 Tuesday 2:30 AM Singapore Time GMT+8

NOTE: Compiling a Linux operating system on Intel Core i7-5820K (6
cores) will take
approximately 4.5 hours.

Steps
=

001. Download CentOS 7.5 1804 from the mirror at National University
of Singapore (NUS)
http://mirror.nus.edu.sg/centos/7.5.1804/isos/x86_64/CentOS-7-x86_64-DVD-1804.iso

002. Install CentOS 7.5 1804 as an Oracle VirtualBox 5.2.18 virtual
machine in Windows 10 version 1803 host operating system.

003. During Software Selection, choose *Development and Creative
Workstation*. This is mandatory for compiling software and
operating systems.

004. Click Additional Development.

005. Click Development Tools.

006. Click Perl for Web.

007. Click Platform Development.

008. Click Done.

009. After completing installation, login to CentOS 7.5 1804 using Putty.

010. Search for gcc (GNU Compiler Collection).

[teoenming@centos ~]$ rpm -qa | grep gcc
gcc-4.8.5-28.el7.x86_64
gcc-c++-4.8.5-28.el7.x86_64
gcc-gfortran-4.8.5-28.el7.x86_64
libgcc-4.8.5-28.el7.x86_64

011. Search for make.

[teoenming@centos ~]$ rpm -qa | grep make
make-3.82-23.el7.x86_64
automake-1.13.4-3.el7.noarch
cmake-2.8.12.2-2.el7.x86_64

012. Search for ncurses.

[teoenming@centos ~]$ rpm -qa | grep ncurses
ncurses-base-5.9-14.20130511.el7_4.noarch
ncurses-devel-5.9-14.20130511.el7_4.x86_64
ncurses-5.9-14.20130511.el7_4.x86_64
ncurses-libs-5.9-14.20130511.el7_4.x86_64

013. Search for perl.

[teoenming@centos ~]$ rpm -qa | grep perl


014. Search for grub (Grand Unified Boot Loader).

[root@centos ~]# rpm -qa | grep grub
grub2-pc-modules-2.02-0.65.el7.centos.2.noarch
grubby-8.28-23.el7.x86_64
grub2-2.02-0.65.el7.centos.2.x86_64
grub2-common-2.02-0.65.el7.centos.2.noarch
grub2-tools-minimal-2.02-0.65.el7.centos.2.x86_64
grub2-tools-extra-2.02-0.65.el7.centos.2.x86_64
grub2-tools-2.02-0.65.el7.centos.2.x86_64
grub2-pc-2.02-0.65.el7.centos.2.x86_64

***Apparently GRUB Legacy 0.97 has been deprecated on CentOS 7.5.
GRUB2 is now installed by default on CentOS 7.5.***

015. Download the latest binutils-2.31

wget https://ftp.gnu.org/gnu/binutils/binutils-2.31.tar.xz

016. Download the latest busybox-1.29.3

wget https://busybox.net/downloads/busybox-1.29.3.tar.bz2

017. Download the latest Cross Linux From Scratch (CLFS) Bootscripts

wget 
http://ftp.osuosl.org/pub/clfs/conglomeration/clfs-embedded-bootscripts/clfs-embedded-bootscripts-1.0-pre5.tar.bz2

018. Download the latest GNU Compiler Collection (gcc) version 8.2.0

wget https://ftp.gnu.org/gnu/gcc/gcc-8.2.0/gcc-8.2.0.tar.xz

019. Download the latest C Programming Library version 2.28

wget https://ftp.gnu.org/gnu/glibc/glibc-2.28.tar.xz

020. Download the latest gmp-6.1.2

wget https://ftp.gnu.org/gnu/gmp/gmp-6.1.2.tar.bz2

021. Download the latest Linux Kernel version 4.18.12 (stable branch)

wget https://cdn.kernel.org/pub/linux/kernel/v4.x/linux-4.18.12.tar.xz

022. Download the latest mpc-1.1.0

wget https://ftp.gnu.org/gnu/mpc/mpc-1.1.0.tar.gz

023. Download the latest mpfr-4.0.1

wget https://ftp.gnu.org/gnu/mpfr/mpfr-4.0.1.tar.xz

024. Download the latest zlib-1.2.11

wget https://zlib.net/zlib-1.2.11.tar.gz

>From now on, follow Petros Koutoupis' guide at Linux Journal.

[Guide] DIY: Build a Custom Minimal Linux Distribution from Source
Link: 
https://www.linuxjournal.com/content/diy-build-custom-minimal-linux-distribution-source

Follow the instructions until the section "Building the Cross Compiler".

At the Kernel Headers sub-section,

025. Extract the latest Linux Kernel 4.18.12 (stable branch)

tar xfvJ linux-4.18.12.tar.xz

026. Change directory into the Linux Kernel 4.18.12 source code directory

cd linux-4.18.12

Then continue following the instructions.

At the section on Glibc, glibc-2.28 (C Programming Library version
2.28) won't compile.

So we will use glibc-2.27 (C Programming Library version 2.27) instead.

027. Download C Programming Library version 2.27

wget https://ftp.gnu.org/gnu/glibc/glibc-2.27.tar.xz

At "The Bootscripts" section, modify Makefile in the root directory as follows.
You *CANNOT* copy and paste the following code section into a
patchfile and use the patch command
patch -p0  prompt instead.

At the grub> prompt, execute the following commands.

grub> linux /boot/vmlinuz-4.18.12 root=/dev/sda1 ro quiet
grub> boot

Teo En Ming Extremely Simple Linux 1810.08 will now boot up.

Please watch my YouTube video at https://www.youtube.com/watch?v=YrJADssqaQU

Question: Should I use CentOS 6 as my development workstation instead?
This is because CentOS 6 will definitely have GRUB Legacy.


===BEGIN SIGNATURE===

Turritopsis Dohrnii Teo En Ming's 

Re: [PATCH] KVM: Start populating /sys/hypervisor with KVM entries

[kbuild test robot]

Hi Filippo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Filippo-Sironi/KVM-Start-populating-sys-hypervisor-with-KVM-entries/20181010-064236
base:   https://github.com/thesofproject/linux master
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc64 

All error/warnings (new ones prefixed by >>):

   In file included from arch/powerpc/include/uapi/asm/kvm_para.h:82:0,
from arch/powerpc/include/asm/kvm_para.h:22,
from drivers//kvm/sys-hypervisor.c:3:
>> arch/powerpc/include/asm/epapr_hcalls.h:109:12: error: expected '=', ',', 
>> ';', 'asm' or '__attribute__' before 'epapr_paravirt_early_init'
int __init epapr_paravirt_early_init(void);
   ^
   In file included from arch/powerpc/include/asm/epapr_hcalls.h:53:0,
from arch/powerpc/include/uapi/asm/kvm_para.h:82,
from arch/powerpc/include/asm/kvm_para.h:22,
from drivers//kvm/sys-hypervisor.c:3:
   arch/powerpc/include/asm/kvm_para.h: In function 'kvm_arch_para_features':
>> arch/powerpc/include/asm/kvm_para.h:58:40: error: 'KVM_HC_FEATURES' 
>> undeclared (first use in this function); did you mean 'KVM_HCALL_TOKEN'?
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^
   arch/powerpc/include/uapi/asm/epapr_hcalls.h:75:51: note: in definition of 
macro '_EV_HCALL_TOKEN'
#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
  ^~~
>> arch/powerpc/include/asm/kvm_para.h:58:24: note: in expansion of macro 
>> 'KVM_HCALL_TOKEN'
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^~~
   arch/powerpc/include/asm/kvm_para.h:58:40: note: each undeclared identifier 
is reported only once for each function it appears in
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^
   arch/powerpc/include/uapi/asm/epapr_hcalls.h:75:51: note: in definition of 
macro '_EV_HCALL_TOKEN'
#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
  ^~~
>> arch/powerpc/include/asm/kvm_para.h:58:24: note: in expansion of macro 
>> 'KVM_HCALL_TOKEN'
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^~~

vim +58 arch/powerpc/include/asm/kvm_para.h

bbf45ba5 include/asm-powerpc/kvm_para.h  Hollis Blanchard 2008-04-16  21  
c3617f72 arch/powerpc/include/asm/kvm_para.h David Howells2012-10-09 @22  
#include 
bbf45ba5 include/asm-powerpc/kvm_para.h  Hollis Blanchard 2008-04-16  23  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  24  
#ifdef CONFIG_KVM_GUEST
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  25  
26e673c3 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-09-03  26  
#include 
26e673c3 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-09-03  27  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  28  
static inline int kvm_para_available(void)
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  29  {
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  30
struct device_node *hyper_node;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  31  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  32
hyper_node = of_find_node_by_path("/hypervisor");
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  33
if (!hyper_node)
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  34
return 0;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  35  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  36
if (!of_device_is_compatible(hyper_node, "linux,kvm"))
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  37
return 0;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  38  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  39
return 1;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010

Re: [PATCH] KVM: Start populating /sys/hypervisor with KVM entries

[kbuild test robot]

Hi Filippo,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on linux-sof-driver/master]
[also build test ERROR on v4.19-rc7 next-20181009]
[if your patch is applied to the wrong git tree, please drop us a note to help 
improve the system]

url:
https://github.com/0day-ci/linux/commits/Filippo-Sironi/KVM-Start-populating-sys-hypervisor-with-KVM-entries/20181010-064236
base:   https://github.com/thesofproject/linux master
config: powerpc64-allmodconfig (attached as .config)
compiler: powerpc64-linux-gnu-gcc (Debian 7.2.0-11) 7.2.0
reproduce:
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
GCC_VERSION=7.2.0 make.cross ARCH=powerpc64 

All error/warnings (new ones prefixed by >>):

   In file included from arch/powerpc/include/uapi/asm/kvm_para.h:82:0,
from arch/powerpc/include/asm/kvm_para.h:22,
from drivers//kvm/sys-hypervisor.c:3:
>> arch/powerpc/include/asm/epapr_hcalls.h:109:12: error: expected '=', ',', 
>> ';', 'asm' or '__attribute__' before 'epapr_paravirt_early_init'
int __init epapr_paravirt_early_init(void);
   ^
   In file included from arch/powerpc/include/asm/epapr_hcalls.h:53:0,
from arch/powerpc/include/uapi/asm/kvm_para.h:82,
from arch/powerpc/include/asm/kvm_para.h:22,
from drivers//kvm/sys-hypervisor.c:3:
   arch/powerpc/include/asm/kvm_para.h: In function 'kvm_arch_para_features':
>> arch/powerpc/include/asm/kvm_para.h:58:40: error: 'KVM_HC_FEATURES' 
>> undeclared (first use in this function); did you mean 'KVM_HCALL_TOKEN'?
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^
   arch/powerpc/include/uapi/asm/epapr_hcalls.h:75:51: note: in definition of 
macro '_EV_HCALL_TOKEN'
#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
  ^~~
>> arch/powerpc/include/asm/kvm_para.h:58:24: note: in expansion of macro 
>> 'KVM_HCALL_TOKEN'
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^~~
   arch/powerpc/include/asm/kvm_para.h:58:40: note: each undeclared identifier 
is reported only once for each function it appears in
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^
   arch/powerpc/include/uapi/asm/epapr_hcalls.h:75:51: note: in definition of 
macro '_EV_HCALL_TOKEN'
#define _EV_HCALL_TOKEN(id, num) (((id) << 16) | (num))
  ^~~
>> arch/powerpc/include/asm/kvm_para.h:58:24: note: in expansion of macro 
>> 'KVM_HCALL_TOKEN'
 if(epapr_hypercall0_1(KVM_HCALL_TOKEN(KVM_HC_FEATURES), ))
   ^~~

vim +58 arch/powerpc/include/asm/kvm_para.h

bbf45ba5 include/asm-powerpc/kvm_para.h  Hollis Blanchard 2008-04-16  21  
c3617f72 arch/powerpc/include/asm/kvm_para.h David Howells2012-10-09 @22  
#include 
bbf45ba5 include/asm-powerpc/kvm_para.h  Hollis Blanchard 2008-04-16  23  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  24  
#ifdef CONFIG_KVM_GUEST
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  25  
26e673c3 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-09-03  26  
#include 
26e673c3 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-09-03  27  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  28  
static inline int kvm_para_available(void)
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  29  {
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  30
struct device_node *hyper_node;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  31  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  32
hyper_node = of_find_node_by_path("/hypervisor");
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  33
if (!hyper_node)
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  34
return 0;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  35  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  36
if (!of_device_is_compatible(hyper_node, "linux,kvm"))
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  37
return 0;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  38  
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010-07-29  39
return 1;
2a342ed5 arch/powerpc/include/asm/kvm_para.h Alexander Graf   2010

[GIT PULL] s390 patches for 4.19 #4

[Martin Schwidefsky]

Hi Greg,

please pull s390 fixes for 4.19:

The following changes since commit 4b92e7fd76e94624e3d5ff56b3d6a5788c4a7ac8:

  Merge tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd 
(2018-09-20 11:25:20 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.19-4

for you to fetch changes up to 7c75544983edece1b745367922cf1053606cd369:

  Merge tag 'vfio-ccw-20181002' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into fixes 
(2018-10-08 09:08:21 +0200)


s390 fixes for 4.19-rc8

Four more patches for 4.19

 - Fix resume after suspend-to-disk if resume-CPU != suspend-CPU

 - Fix vfio-ccw check for pinned pages

 - Two patches to avoid a usercopy-whitelist warning in vfio-ccw


Eric Farman (3):
  s390/cio: Convert ccw_io_region to pointer
  s390/cio: Refactor alloc of ccw_io_region
  s390/cio: Fix how vfio-ccw checks pinned pages

Gerald Schaefer (1):
  s390/hibernate: fix error handling when suspend cpu != resume cpu

Martin Schwidefsky (2):
  Merge tag 'vfio-ccw-20181001' of 
git://git.kernel.org/.../kvms390/vfio-ccw into fixes
  Merge tag 'vfio-ccw-20181002' of 
git://git.kernel.org/.../kvms390/vfio-ccw into fixes

 arch/s390/include/asm/sclp.h|  3 ++-
 arch/s390/kernel/early_printk.c |  2 +-
 arch/s390/kernel/swsusp.S   |  8 +++-
 drivers/s390/char/sclp_early_core.c | 11 ---
 drivers/s390/cio/vfio_ccw_cp.c  |  2 +-
 drivers/s390/cio/vfio_ccw_drv.c | 24 +++-
 drivers/s390/cio/vfio_ccw_fsm.c |  6 +++---
 drivers/s390/cio/vfio_ccw_ops.c |  4 ++--
 drivers/s390/cio/vfio_ccw_private.h |  2 +-
 9 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/arch/s390/include/asm/sclp.h b/arch/s390/include/asm/sclp.h
index 3cae916..e44a8d7 100644
--- a/arch/s390/include/asm/sclp.h
+++ b/arch/s390/include/asm/sclp.h
@@ -108,7 +108,8 @@ int sclp_early_get_core_info(struct sclp_core_info *info);
 void sclp_early_get_ipl_info(struct sclp_ipl_info *info);
 void sclp_early_detect(void);
 void sclp_early_printk(const char *s);
-void __sclp_early_printk(const char *s, unsigned int len);
+void sclp_early_printk_force(const char *s);
+void __sclp_early_printk(const char *s, unsigned int len, unsigned int force);
 
 int _sclp_get_core_info(struct sclp_core_info *info);
 int sclp_core_configure(u8 core);
diff --git a/arch/s390/kernel/early_printk.c b/arch/s390/kernel/early_printk.c
index 9431784..40c1dfe 100644
--- a/arch/s390/kernel/early_printk.c
+++ b/arch/s390/kernel/early_printk.c
@@ -10,7 +10,7 @@
 
 static void sclp_early_write(struct console *con, const char *s, unsigned int 
len)
 {
-   __sclp_early_printk(s, len);
+   __sclp_early_printk(s, len, 0);
 }
 
 static struct console sclp_early_console = {
diff --git a/arch/s390/kernel/swsusp.S b/arch/s390/kernel/swsusp.S
index a049a7b..c1a080b 100644
--- a/arch/s390/kernel/swsusp.S
+++ b/arch/s390/kernel/swsusp.S
@@ -198,12 +198,10 @@ pgm_check_entry:
 
/* Suspend CPU not available -> panic */
larl%r15,init_thread_union
-   ahi %r15,1<<(PAGE_SHIFT+THREAD_SIZE_ORDER)
+   aghi%r15,1<<(PAGE_SHIFT+THREAD_SIZE_ORDER)
+   aghi%r15,-STACK_FRAME_OVERHEAD
larl%r2,.Lpanic_string
-   lghi%r1,0
-   sam31
-   sigp%r1,%r0,SIGP_SET_ARCHITECTURE
-   brasl   %r14,sclp_early_printk
+   brasl   %r14,sclp_early_printk_force
larl%r3,.Ldisabled_wait_31
lpsw0(%r3)
 4:
diff --git a/drivers/s390/char/sclp_early_core.c 
b/drivers/s390/char/sclp_early_core.c
index eceba38..2f61f55 100644
--- a/drivers/s390/char/sclp_early_core.c
+++ b/drivers/s390/char/sclp_early_core.c
@@ -210,11 +210,11 @@ static int sclp_early_setup(int disable, int 
*have_linemode, int *have_vt220)
  * Output one or more lines of text on the SCLP console (VT220 and /
  * or line-mode).
  */
-void __sclp_early_printk(const char *str, unsigned int len)
+void __sclp_early_printk(const char *str, unsigned int len, unsigned int force)
 {
int have_linemode, have_vt220;
 
-   if (sclp_init_state != sclp_init_state_uninitialized)
+   if (!force && sclp_init_state != sclp_init_state_uninitialized)
return;
if (sclp_early_setup(0, _linemode, _vt220) != 0)
return;
@@ -227,5 +227,10 @@ void __sclp_early_printk(const char *str, unsigned int len)
 
 void sclp_early_printk(const char *str)
 {
-   __sclp_early_printk(str, strlen(str));
+   __sclp_early_printk(str, strlen(str), 0);
+}
+
+void sclp_early_printk_force(const char *str)
+{
+   __sclp_early_printk(str, strlen(str), 1);
 }
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index dbe7c7a..fd77e46 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ 

[GIT PULL] s390 patches for 4.19 #4

[Martin Schwidefsky]

Hi Greg,

please pull s390 fixes for 4.19:

The following changes since commit 4b92e7fd76e94624e3d5ff56b3d6a5788c4a7ac8:

  Merge tag 'mtd/fixes-for-4.19-rc5' of git://git.infradead.org/linux-mtd 
(2018-09-20 11:25:20 +0200)

are available in the git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux.git tags/s390-4.19-4

for you to fetch changes up to 7c75544983edece1b745367922cf1053606cd369:

  Merge tag 'vfio-ccw-20181002' of 
git://git.kernel.org/pub/scm/linux/kernel/git/kvms390/vfio-ccw into fixes 
(2018-10-08 09:08:21 +0200)


s390 fixes for 4.19-rc8

Four more patches for 4.19

 - Fix resume after suspend-to-disk if resume-CPU != suspend-CPU

 - Fix vfio-ccw check for pinned pages

 - Two patches to avoid a usercopy-whitelist warning in vfio-ccw


Eric Farman (3):
  s390/cio: Convert ccw_io_region to pointer
  s390/cio: Refactor alloc of ccw_io_region
  s390/cio: Fix how vfio-ccw checks pinned pages

Gerald Schaefer (1):
  s390/hibernate: fix error handling when suspend cpu != resume cpu

Martin Schwidefsky (2):
  Merge tag 'vfio-ccw-20181001' of 
git://git.kernel.org/.../kvms390/vfio-ccw into fixes
  Merge tag 'vfio-ccw-20181002' of 
git://git.kernel.org/.../kvms390/vfio-ccw into fixes

 arch/s390/include/asm/sclp.h|  3 ++-
 arch/s390/kernel/early_printk.c |  2 +-
 arch/s390/kernel/swsusp.S   |  8 +++-
 drivers/s390/char/sclp_early_core.c | 11 ---
 drivers/s390/cio/vfio_ccw_cp.c  |  2 +-
 drivers/s390/cio/vfio_ccw_drv.c | 24 +++-
 drivers/s390/cio/vfio_ccw_fsm.c |  6 +++---
 drivers/s390/cio/vfio_ccw_ops.c |  4 ++--
 drivers/s390/cio/vfio_ccw_private.h |  2 +-
 9 files changed, 44 insertions(+), 18 deletions(-)

diff --git a/arch/s390/include/asm/sclp.h b/arch/s390/include/asm/sclp.h
index 3cae916..e44a8d7 100644
--- a/arch/s390/include/asm/sclp.h
+++ b/arch/s390/include/asm/sclp.h
@@ -108,7 +108,8 @@ int sclp_early_get_core_info(struct sclp_core_info *info);
 void sclp_early_get_ipl_info(struct sclp_ipl_info *info);
 void sclp_early_detect(void);
 void sclp_early_printk(const char *s);
-void __sclp_early_printk(const char *s, unsigned int len);
+void sclp_early_printk_force(const char *s);
+void __sclp_early_printk(const char *s, unsigned int len, unsigned int force);
 
 int _sclp_get_core_info(struct sclp_core_info *info);
 int sclp_core_configure(u8 core);
diff --git a/arch/s390/kernel/early_printk.c b/arch/s390/kernel/early_printk.c
index 9431784..40c1dfe 100644
--- a/arch/s390/kernel/early_printk.c
+++ b/arch/s390/kernel/early_printk.c
@@ -10,7 +10,7 @@
 
 static void sclp_early_write(struct console *con, const char *s, unsigned int 
len)
 {
-   __sclp_early_printk(s, len);
+   __sclp_early_printk(s, len, 0);
 }
 
 static struct console sclp_early_console = {
diff --git a/arch/s390/kernel/swsusp.S b/arch/s390/kernel/swsusp.S
index a049a7b..c1a080b 100644
--- a/arch/s390/kernel/swsusp.S
+++ b/arch/s390/kernel/swsusp.S
@@ -198,12 +198,10 @@ pgm_check_entry:
 
/* Suspend CPU not available -> panic */
larl%r15,init_thread_union
-   ahi %r15,1<<(PAGE_SHIFT+THREAD_SIZE_ORDER)
+   aghi%r15,1<<(PAGE_SHIFT+THREAD_SIZE_ORDER)
+   aghi%r15,-STACK_FRAME_OVERHEAD
larl%r2,.Lpanic_string
-   lghi%r1,0
-   sam31
-   sigp%r1,%r0,SIGP_SET_ARCHITECTURE
-   brasl   %r14,sclp_early_printk
+   brasl   %r14,sclp_early_printk_force
larl%r3,.Ldisabled_wait_31
lpsw0(%r3)
 4:
diff --git a/drivers/s390/char/sclp_early_core.c 
b/drivers/s390/char/sclp_early_core.c
index eceba38..2f61f55 100644
--- a/drivers/s390/char/sclp_early_core.c
+++ b/drivers/s390/char/sclp_early_core.c
@@ -210,11 +210,11 @@ static int sclp_early_setup(int disable, int 
*have_linemode, int *have_vt220)
  * Output one or more lines of text on the SCLP console (VT220 and /
  * or line-mode).
  */
-void __sclp_early_printk(const char *str, unsigned int len)
+void __sclp_early_printk(const char *str, unsigned int len, unsigned int force)
 {
int have_linemode, have_vt220;
 
-   if (sclp_init_state != sclp_init_state_uninitialized)
+   if (!force && sclp_init_state != sclp_init_state_uninitialized)
return;
if (sclp_early_setup(0, _linemode, _vt220) != 0)
return;
@@ -227,5 +227,10 @@ void __sclp_early_printk(const char *str, unsigned int len)
 
 void sclp_early_printk(const char *str)
 {
-   __sclp_early_printk(str, strlen(str));
+   __sclp_early_printk(str, strlen(str), 0);
+}
+
+void sclp_early_printk_force(const char *str)
+{
+   __sclp_early_printk(str, strlen(str), 1);
 }
diff --git a/drivers/s390/cio/vfio_ccw_cp.c b/drivers/s390/cio/vfio_ccw_cp.c
index dbe7c7a..fd77e46 100644
--- a/drivers/s390/cio/vfio_ccw_cp.c
+++ 

Re: [PATCH v3] mfd: cros-ec: copy the whole event in get_next_event_xfer

[Benson Leung]

Hi Emil,
On Wed, Oct 3, 2018 at 11:43 AM Emil Karlson  wrote:
>
> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard events
> be truncated on many chromebooks so that Left and Right keys on Column 12 were
> always 0. Use ret as memcpy len to fix this.
>
> The old code was using ec_dev->event_size, which is the event payload/data 
> size
> excluding event_type header, for the length of the memcpy operation. Use ret
> as memcpy length to avoid the off by one and copy the whole msg->data.
>
> Fixes: 57e94c8b974d ("mfd: cros-ec: Increase maximum mkbp event size")
>
> Acked-by: Enric Balletbo i Serra 
> Tested-by: Emil Renner Berthing 
> Signed-off-by: Emil Karlson 

Applied. Sent to Greg for rc8, hopefully.



-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org

Re: [PATCH v3] mfd: cros-ec: copy the whole event in get_next_event_xfer

[Benson Leung]

Hi Emil,
On Wed, Oct 3, 2018 at 11:43 AM Emil Karlson  wrote:
>
> Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard events
> be truncated on many chromebooks so that Left and Right keys on Column 12 were
> always 0. Use ret as memcpy len to fix this.
>
> The old code was using ec_dev->event_size, which is the event payload/data 
> size
> excluding event_type header, for the length of the memcpy operation. Use ret
> as memcpy length to avoid the off by one and copy the whole msg->data.
>
> Fixes: 57e94c8b974d ("mfd: cros-ec: Increase maximum mkbp event size")
>
> Acked-by: Enric Balletbo i Serra 
> Tested-by: Emil Renner Berthing 
> Signed-off-by: Emil Karlson 

Applied. Sent to Greg for rc8, hopefully.



-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org

enquiry 09-10-2018

[Daniel Murray]

Hi,friend,

This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in 
your products.
Could you kindly send us your Latest catalog and price list for our trial order.

Best Regards,

Daniel Murray
Purchasing Manager

enquiry 09-10-2018

[Daniel Murray]

Hi,friend,

This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in 
your products.
Could you kindly send us your Latest catalog and price list for our trial order.

Best Regards,

Daniel Murray
Purchasing Manager

Re: [PATCH 2/2] platform/chrome: Add a new interrupt path for cros_ec_lpc

[Benson Leung]

Hi Enrico,

On Wed, Oct 03, 2018 at 11:45:06AM -0700, Enrico Granata wrote:
> From: Enrico Granata 
> 
> This commit allows cros_ec_lpc to register a direct IRQ instead of relying
> on the ACPI notification chain to receive MKBP events.
> 
> This change is done in the interest of allowing reduced jitter in the
> communication path between the CrOS EC and the host for receiving sensor
> data.
> 
> Signed-off-by: Enrico Granata 

Applied for v4.20. Thanks!

Benson

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 31c8b8c49e45..07eea608915e 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -248,7 +249,7 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
>   acpi_status status;
>   struct cros_ec_device *ec_dev;
>   u8 buf[2];
> - int ret;
> + int irq, ret;
>  
>   if (!devm_request_region(dev, EC_LPC_ADDR_MEMMAP, EC_MEMMAP_SIZE,
>dev_name(dev))) {
> @@ -287,6 +288,18 @@ static int cros_ec_lpc_probe(struct platform_device 
> *pdev)
>  sizeof(struct ec_response_get_protocol_info);
>   ec_dev->dout_size = sizeof(struct ec_host_request);
>  
> + /*
> +  * Some boards do not have an IRQ allotted for cros_ec_lpc,
> +  * which makes ENXIO an expected (and safe) scenario.
> +  */
> + irq = platform_get_irq(pdev, 0);
> + if (irq > 0)
> + ec_dev->irq = irq;
> + else if (irq != -ENXIO) {
> + dev_err(dev, "couldn't retrieve IRQ number (%d)\n", irq);
> + return irq;
> + }
> +
>   ret = cros_ec_register(ec_dev);
>   if (ret) {
>   dev_err(dev, "couldn't register ec_dev (%d)\n", ret);
> @@ -294,11 +307,11 @@ static int cros_ec_lpc_probe(struct platform_device 
> *pdev)
>   }
>  
>   /*
> -  * Connect a notify handler to process MKBP messages if we have a
> -  * companion ACPI device.
> +  * If we have a companion ACPI device and no dedicated IRQ
> +  * connect a notify handler to process MKBP messages.
>*/
>   adev = ACPI_COMPANION(dev);
> - if (adev) {
> + if (adev && ec_dev->irq <= 0) {
>   status = acpi_install_notify_handler(adev->handle,
>ACPI_ALL_NOTIFY,
>cros_ec_lpc_acpi_notify,
> -- 
> 2.19.0.605.g01d371f741-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH 2/2] platform/chrome: Add a new interrupt path for cros_ec_lpc

[Benson Leung]

Hi Enrico,

On Wed, Oct 03, 2018 at 11:45:06AM -0700, Enrico Granata wrote:
> From: Enrico Granata 
> 
> This commit allows cros_ec_lpc to register a direct IRQ instead of relying
> on the ACPI notification chain to receive MKBP events.
> 
> This change is done in the interest of allowing reduced jitter in the
> communication path between the CrOS EC and the host for receiving sensor
> data.
> 
> Signed-off-by: Enrico Granata 

Applied for v4.20. Thanks!

Benson

> ---
>  drivers/platform/chrome/cros_ec_lpc.c | 21 +
>  1 file changed, 17 insertions(+), 4 deletions(-)
> 
> diff --git a/drivers/platform/chrome/cros_ec_lpc.c 
> b/drivers/platform/chrome/cros_ec_lpc.c
> index 31c8b8c49e45..07eea608915e 100644
> --- a/drivers/platform/chrome/cros_ec_lpc.c
> +++ b/drivers/platform/chrome/cros_ec_lpc.c
> @@ -25,6 +25,7 @@
>  #include 
>  #include 
>  #include 
> +#include 
>  #include 
>  #include 
>  #include 
> @@ -248,7 +249,7 @@ static int cros_ec_lpc_probe(struct platform_device *pdev)
>   acpi_status status;
>   struct cros_ec_device *ec_dev;
>   u8 buf[2];
> - int ret;
> + int irq, ret;
>  
>   if (!devm_request_region(dev, EC_LPC_ADDR_MEMMAP, EC_MEMMAP_SIZE,
>dev_name(dev))) {
> @@ -287,6 +288,18 @@ static int cros_ec_lpc_probe(struct platform_device 
> *pdev)
>  sizeof(struct ec_response_get_protocol_info);
>   ec_dev->dout_size = sizeof(struct ec_host_request);
>  
> + /*
> +  * Some boards do not have an IRQ allotted for cros_ec_lpc,
> +  * which makes ENXIO an expected (and safe) scenario.
> +  */
> + irq = platform_get_irq(pdev, 0);
> + if (irq > 0)
> + ec_dev->irq = irq;
> + else if (irq != -ENXIO) {
> + dev_err(dev, "couldn't retrieve IRQ number (%d)\n", irq);
> + return irq;
> + }
> +
>   ret = cros_ec_register(ec_dev);
>   if (ret) {
>   dev_err(dev, "couldn't register ec_dev (%d)\n", ret);
> @@ -294,11 +307,11 @@ static int cros_ec_lpc_probe(struct platform_device 
> *pdev)
>   }
>  
>   /*
> -  * Connect a notify handler to process MKBP messages if we have a
> -  * companion ACPI device.
> +  * If we have a companion ACPI device and no dedicated IRQ
> +  * connect a notify handler to process MKBP messages.
>*/
>   adev = ACPI_COMPANION(dev);
> - if (adev) {
> + if (adev && ec_dev->irq <= 0) {
>   status = acpi_install_notify_handler(adev->handle,
>ACPI_ALL_NOTIFY,
>cros_ec_lpc_acpi_notify,
> -- 
> 2.19.0.605.g01d371f741-goog
> 

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[GIT PULL] IB between mfd and platform/chrome for move of lpc driver

[Benson Leung]

Hi Lee,

Sorry for the super late reply to your email before. I wanted to make sure
this wasn't dropped so we could get this into v4.20.

Thanks,
Benson

The following changes since commit 57361846b52bc686112da6ca5368d11210796804:

  Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/tag-ib-chrome-platform-mfd-move-cros_ec_lpc

for you to fetch changes up to e2bbf91cad09118d7500f1fdaaa83d7741d30395:

  mfd: cros_ec: Fix and improve kerneldoc comments. (2018-09-07 15:56:37 +0800)


IB between mfd and chrome platform for move of lpc drivers


Enric Balletbo i Serra (2):
  platform/chrome: Move mfd/cros_ec_lpc* includes to drivers/platform.
  mfd: cros_ec: Fix and improve kerneldoc comments.

 drivers/mfd/cros_ec_dev.h  |  13 +-
 drivers/platform/chrome/cros_ec_lpc.c  |   3 +-
 drivers/platform/chrome/cros_ec_lpc_mec.c  |   3 +-
 .../platform/chrome}/cros_ec_lpc_mec.h |   6 +-
 drivers/platform/chrome/cros_ec_lpc_reg.c  |   3 +-
 .../platform/chrome}/cros_ec_lpc_reg.h |   6 +-
 include/linux/mfd/cros_ec.h| 214 ---
 include/linux/mfd/cros_ec_commands.h   | 295 +
 8 files changed, 322 insertions(+), 221 deletions(-)
 rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_mec.h (96%)
 rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_reg.h (94%)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[GIT PULL] IB between mfd and platform/chrome for move of lpc driver

[Benson Leung]

Hi Lee,

Sorry for the super late reply to your email before. I wanted to make sure
this wasn't dropped so we could get this into v4.20.

Thanks,
Benson

The following changes since commit 57361846b52bc686112da6ca5368d11210796804:

  Linux 4.19-rc2 (2018-09-02 14:37:30 -0700)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/tag-ib-chrome-platform-mfd-move-cros_ec_lpc

for you to fetch changes up to e2bbf91cad09118d7500f1fdaaa83d7741d30395:

  mfd: cros_ec: Fix and improve kerneldoc comments. (2018-09-07 15:56:37 +0800)


IB between mfd and chrome platform for move of lpc drivers


Enric Balletbo i Serra (2):
  platform/chrome: Move mfd/cros_ec_lpc* includes to drivers/platform.
  mfd: cros_ec: Fix and improve kerneldoc comments.

 drivers/mfd/cros_ec_dev.h  |  13 +-
 drivers/platform/chrome/cros_ec_lpc.c  |   3 +-
 drivers/platform/chrome/cros_ec_lpc_mec.c  |   3 +-
 .../platform/chrome}/cros_ec_lpc_mec.h |   6 +-
 drivers/platform/chrome/cros_ec_lpc_reg.c  |   3 +-
 .../platform/chrome}/cros_ec_lpc_reg.h |   6 +-
 include/linux/mfd/cros_ec.h| 214 ---
 include/linux/mfd/cros_ec_commands.h   | 295 +
 8 files changed, 322 insertions(+), 221 deletions(-)
 rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_mec.h (96%)
 rename {include/linux/mfd => drivers/platform/chrome}/cros_ec_lpc_reg.h (94%)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

[GIT PULL] chrome-platform fixes for v4.19-rc8

[Benson Leung]

Hi Greg,

Sorry for the late in the cycle request, but this one is fairly urgent.

Please pull thi fix to chrome platform. A patch that landed
for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.

Thanks,
Benson

The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21:

  Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/tag-chrome-platform-fixes-for-v4.19-rc8

for you to fetch changes up to d4d2313a3c17eff4aef9a544023c2df5b9f5bedc:

  mfd: cros-ec: copy the whole event in get_next_event_xfer (2018-10-09 
20:57:30 -0700)


chrome-platform-fixes-for-v4.19-rc8

This contains a fix to 57e94c8b974db2d83c60e1139c89a70806abbea0, which caused
cros_ec based chromebooks to truncate an entire column of their built-in
keyboard.


Emil Karlson (1):
  mfd: cros-ec: copy the whole event in get_next_event_xfer

 drivers/platform/chrome/cros_ec_proto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] arm/arm64: KVM: enable 32 bits kvm vcpu events support

[gengdongjiu]

Hi Suzuki

On 2018/10/10 1:22, Suzuki K Poulose wrote:
> 
> 
> On 08/10/18 13:34, Dongjiu Geng wrote:
>> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
>> get/set events useful to 32bit") shares the get/set events
>> helper for arm64 and arm32, it is better also share the check
>> for vcpu events capability to enable 32 bit kvm vcpu events
>> support.
>>
>> User space will check whether KVM supports vcpu events through
>> KVM_CAP_VCPU_EVENTS IOCTL.
> 
> nit: User space will check whether KVM supports vcpu events by checking
> the KVM_CAP_VCPU_EVENTS extension.

  Thanks for the pointing out, I will update it.

> 
>>
>> Cc: James Morse 
>> Signed-off-by: Dongjiu Geng 
> 
> Reviewed-by : Suzuki K Poulose 
> 
>> ---
>> For the 32 bits kvm migration, it needs to enable the vcpu events,
>> this patch will enable it. The user space QEMU patch is here:
>> https://patchwork.ozlabs.org/patch/975615/
>> ---
>>   arch/arm64/kvm/reset.c | 1 -
>>   virt/kvm/arm/arm.c | 1 +
>>   2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index fd37c53..e50245e 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -82,7 +82,6 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, 
>> long ext)
>>   break;
>>   case KVM_CAP_SET_GUEST_DEBUG:
>>   case KVM_CAP_VCPU_ATTRIBUTES:
>> -    case KVM_CAP_VCPU_EVENTS:
>>   r = 1;
>>   break;
>>   default:
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index 40e79ea..64e5d97 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -212,6 +212,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
>> ext)
>>   case KVM_CAP_READONLY_MEM:
>>   case KVM_CAP_MP_STATE:
>>   case KVM_CAP_IMMEDIATE_EXIT:
>> +    case KVM_CAP_VCPU_EVENTS:
>>   r = 1;
>>   break;
>>   case KVM_CAP_ARM_SET_DEVICE_ADDR:
>>
> 
> .
> 

[GIT PULL] chrome-platform fixes for v4.19-rc8

[Benson Leung]

Hi Greg,

Sorry for the late in the cycle request, but this one is fairly urgent.

Please pull thi fix to chrome platform. A patch that landed
for 4.19 broke cros_ec based chromebooks' keyboards, and this fixes them.

Thanks,
Benson

The following changes since commit 0238df646e6224016a45505d2c111a24669ebe21:

  Linux 4.19-rc7 (2018-10-07 17:26:02 +0200)

are available in the Git repository at:

  git://git.kernel.org/pub/scm/linux/kernel/git/bleung/chrome-platform.git 
tags/tag-chrome-platform-fixes-for-v4.19-rc8

for you to fetch changes up to d4d2313a3c17eff4aef9a544023c2df5b9f5bedc:

  mfd: cros-ec: copy the whole event in get_next_event_xfer (2018-10-09 
20:57:30 -0700)


chrome-platform-fixes-for-v4.19-rc8

This contains a fix to 57e94c8b974db2d83c60e1139c89a70806abbea0, which caused
cros_ec based chromebooks to truncate an entire column of their built-in
keyboard.


Emil Karlson (1):
  mfd: cros-ec: copy the whole event in get_next_event_xfer

 drivers/platform/chrome/cros_ec_proto.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org


signature.asc
Description: PGP signature

Re: [PATCH v2 2/2] arm/arm64: KVM: enable 32 bits kvm vcpu events support

[gengdongjiu]

Hi Suzuki

On 2018/10/10 1:22, Suzuki K Poulose wrote:
> 
> 
> On 08/10/18 13:34, Dongjiu Geng wrote:
>> The commit 539aee0edb9f ("KVM: arm64: Share the parts of
>> get/set events useful to 32bit") shares the get/set events
>> helper for arm64 and arm32, it is better also share the check
>> for vcpu events capability to enable 32 bit kvm vcpu events
>> support.
>>
>> User space will check whether KVM supports vcpu events through
>> KVM_CAP_VCPU_EVENTS IOCTL.
> 
> nit: User space will check whether KVM supports vcpu events by checking
> the KVM_CAP_VCPU_EVENTS extension.

  Thanks for the pointing out, I will update it.

> 
>>
>> Cc: James Morse 
>> Signed-off-by: Dongjiu Geng 
> 
> Reviewed-by : Suzuki K Poulose 
> 
>> ---
>> For the 32 bits kvm migration, it needs to enable the vcpu events,
>> this patch will enable it. The user space QEMU patch is here:
>> https://patchwork.ozlabs.org/patch/975615/
>> ---
>>   arch/arm64/kvm/reset.c | 1 -
>>   virt/kvm/arm/arm.c | 1 +
>>   2 files changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/arch/arm64/kvm/reset.c b/arch/arm64/kvm/reset.c
>> index fd37c53..e50245e 100644
>> --- a/arch/arm64/kvm/reset.c
>> +++ b/arch/arm64/kvm/reset.c
>> @@ -82,7 +82,6 @@ int kvm_arch_vm_ioctl_check_extension(struct kvm *kvm, 
>> long ext)
>>   break;
>>   case KVM_CAP_SET_GUEST_DEBUG:
>>   case KVM_CAP_VCPU_ATTRIBUTES:
>> -    case KVM_CAP_VCPU_EVENTS:
>>   r = 1;
>>   break;
>>   default:
>> diff --git a/virt/kvm/arm/arm.c b/virt/kvm/arm/arm.c
>> index 40e79ea..64e5d97 100644
>> --- a/virt/kvm/arm/arm.c
>> +++ b/virt/kvm/arm/arm.c
>> @@ -212,6 +212,7 @@ int kvm_vm_ioctl_check_extension(struct kvm *kvm, long 
>> ext)
>>   case KVM_CAP_READONLY_MEM:
>>   case KVM_CAP_MP_STATE:
>>   case KVM_CAP_IMMEDIATE_EXIT:
>> +    case KVM_CAP_VCPU_EVENTS:
>>   r = 1;
>>   break;
>>   case KVM_CAP_ARM_SET_DEVICE_ADDR:
>>
> 
> .
> 

Re: [PATCH] ceph: only allow punch hole mode in fallocate

[Yan, Zheng]

On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques  wrote:
>
> Current implementation of cephfs fallocate isn't correct as it doesn't
> really reserve the space in the cluster, which means that a subsequent
> call to a write may actually fail due to lack of space.  In fact, it is
> currently possible to fallocate an amount space that is larger than the
> free space in the cluster.
>
> Since there's no easy solution to fix this at the moment, this patch
> simply removes support for all fallocate operations but
> FALLOC_FL_PUNCH_HOLE (which implies FALLOC_FL_KEEP_SIZE).
>
> Link: https://tracker.ceph.com/issues/36317
> Cc: sta...@vger.kernel.org
> Fixes: ad7a60de882a ("ceph: punch hole support")
> Signed-off-by: Luis Henriques 
> ---
>  fs/ceph/file.c | 45 +
>  1 file changed, 9 insertions(+), 36 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 92ab20433682..91a7ad259bcf 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -1735,7 +1735,6 @@ static long ceph_fallocate(struct file *file, int mode,
> struct ceph_file_info *fi = file->private_data;
> struct inode *inode = file_inode(file);
> struct ceph_inode_info *ci = ceph_inode(inode);
> -   struct ceph_fs_client *fsc = ceph_inode_to_client(inode);
> struct ceph_cap_flush *prealloc_cf;
> int want, got = 0;
> int dirty;
> @@ -1743,10 +1742,7 @@ static long ceph_fallocate(struct file *file, int mode,
> loff_t endoff = 0;
> loff_t size;
>
> -   if ((offset + length) > max(i_size_read(inode), fsc->max_file_size))
> -   return -EFBIG;
> -
> -   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> +   if (mode != (FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> return -EOPNOTSUPP;
>
> if (!S_ISREG(inode->i_mode))
> @@ -1763,18 +1759,6 @@ static long ceph_fallocate(struct file *file, int mode,
> goto unlock;
> }
>
> -   if (!(mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)) &&
> -   ceph_quota_is_max_bytes_exceeded(inode, offset + length)) {
> -   ret = -EDQUOT;
> -   goto unlock;
> -   }
> -
> -   if (ceph_osdmap_flag(>client->osdc, CEPH_OSDMAP_FULL) &&
> -   !(mode & FALLOC_FL_PUNCH_HOLE)) {
> -   ret = -ENOSPC;
> -   goto unlock;
> -   }
> -
> if (ci->i_inline_version != CEPH_INLINE_NONE) {
> ret = ceph_uninline_data(file, NULL);
> if (ret < 0)
> @@ -1782,12 +1766,12 @@ static long ceph_fallocate(struct file *file, int 
> mode,
> }
>
> size = i_size_read(inode);
> -   if (!(mode & FALLOC_FL_KEEP_SIZE)) {
> -   endoff = offset + length;
> -   ret = inode_newsize_ok(inode, endoff);
> -   if (ret)
> -   goto unlock;
> -   }
> +
> +   /* Are we punching a hole beyond EOF? */
> +   if (offset >= size)
> +   goto unlock;
> +   if ((offset + length) > size)
> +   length = size - offset;
>
> if (fi->fmode & CEPH_FILE_MODE_LAZY)
> want = CEPH_CAP_FILE_BUFFER | CEPH_CAP_FILE_LAZYIO;
> @@ -1798,16 +1782,8 @@ static long ceph_fallocate(struct file *file, int mode,
> if (ret < 0)
> goto unlock;
>
> -   if (mode & FALLOC_FL_PUNCH_HOLE) {
> -   if (offset < size)
> -   ceph_zero_pagecache_range(inode, offset, length);
> -   ret = ceph_zero_objects(inode, offset, length);
> -   } else if (endoff > size) {
> -   truncate_pagecache_range(inode, size, -1);
> -   if (ceph_inode_set_size(inode, endoff))
> -   ceph_check_caps(ceph_inode(inode),
> -   CHECK_CAPS_AUTHONLY, NULL);
> -   }
> +   ceph_zero_pagecache_range(inode, offset, length);
> +   ret = ceph_zero_objects(inode, offset, length);
>
> if (!ret) {
> spin_lock(>i_ceph_lock);
> @@ -1817,9 +1793,6 @@ static long ceph_fallocate(struct file *file, int mode,
> spin_unlock(>i_ceph_lock);
> if (dirty)
> __mark_inode_dirty(inode, dirty);
> -   if ((endoff > size) &&
> -   ceph_quota_is_max_bytes_approaching(inode, endoff))
> -   ceph_check_caps(ci, CHECK_CAPS_NODELAY, NULL);
> }
>
> ceph_put_cap_refs(ci, got);

Applied, thanks

Yan, Zheng

Re: [PATCH] ceph: only allow punch hole mode in fallocate

[Yan, Zheng]

On Wed, Oct 10, 2018 at 1:54 AM Luis Henriques  wrote:
>
> Current implementation of cephfs fallocate isn't correct as it doesn't
> really reserve the space in the cluster, which means that a subsequent
> call to a write may actually fail due to lack of space.  In fact, it is
> currently possible to fallocate an amount space that is larger than the
> free space in the cluster.
>
> Since there's no easy solution to fix this at the moment, this patch
> simply removes support for all fallocate operations but
> FALLOC_FL_PUNCH_HOLE (which implies FALLOC_FL_KEEP_SIZE).
>
> Link: https://tracker.ceph.com/issues/36317
> Cc: sta...@vger.kernel.org
> Fixes: ad7a60de882a ("ceph: punch hole support")
> Signed-off-by: Luis Henriques 
> ---
>  fs/ceph/file.c | 45 +
>  1 file changed, 9 insertions(+), 36 deletions(-)
>
> diff --git a/fs/ceph/file.c b/fs/ceph/file.c
> index 92ab20433682..91a7ad259bcf 100644
> --- a/fs/ceph/file.c
> +++ b/fs/ceph/file.c
> @@ -1735,7 +1735,6 @@ static long ceph_fallocate(struct file *file, int mode,
> struct ceph_file_info *fi = file->private_data;
> struct inode *inode = file_inode(file);
> struct ceph_inode_info *ci = ceph_inode(inode);
> -   struct ceph_fs_client *fsc = ceph_inode_to_client(inode);
> struct ceph_cap_flush *prealloc_cf;
> int want, got = 0;
> int dirty;
> @@ -1743,10 +1742,7 @@ static long ceph_fallocate(struct file *file, int mode,
> loff_t endoff = 0;
> loff_t size;
>
> -   if ((offset + length) > max(i_size_read(inode), fsc->max_file_size))
> -   return -EFBIG;
> -
> -   if (mode & ~(FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> +   if (mode != (FALLOC_FL_KEEP_SIZE | FALLOC_FL_PUNCH_HOLE))
> return -EOPNOTSUPP;
>
> if (!S_ISREG(inode->i_mode))
> @@ -1763,18 +1759,6 @@ static long ceph_fallocate(struct file *file, int mode,
> goto unlock;
> }
>
> -   if (!(mode & (FALLOC_FL_PUNCH_HOLE | FALLOC_FL_KEEP_SIZE)) &&
> -   ceph_quota_is_max_bytes_exceeded(inode, offset + length)) {
> -   ret = -EDQUOT;
> -   goto unlock;
> -   }
> -
> -   if (ceph_osdmap_flag(>client->osdc, CEPH_OSDMAP_FULL) &&
> -   !(mode & FALLOC_FL_PUNCH_HOLE)) {
> -   ret = -ENOSPC;
> -   goto unlock;
> -   }
> -
> if (ci->i_inline_version != CEPH_INLINE_NONE) {
> ret = ceph_uninline_data(file, NULL);
> if (ret < 0)
> @@ -1782,12 +1766,12 @@ static long ceph_fallocate(struct file *file, int 
> mode,
> }
>
> size = i_size_read(inode);
> -   if (!(mode & FALLOC_FL_KEEP_SIZE)) {
> -   endoff = offset + length;
> -   ret = inode_newsize_ok(inode, endoff);
> -   if (ret)
> -   goto unlock;
> -   }
> +
> +   /* Are we punching a hole beyond EOF? */
> +   if (offset >= size)
> +   goto unlock;
> +   if ((offset + length) > size)
> +   length = size - offset;
>
> if (fi->fmode & CEPH_FILE_MODE_LAZY)
> want = CEPH_CAP_FILE_BUFFER | CEPH_CAP_FILE_LAZYIO;
> @@ -1798,16 +1782,8 @@ static long ceph_fallocate(struct file *file, int mode,
> if (ret < 0)
> goto unlock;
>
> -   if (mode & FALLOC_FL_PUNCH_HOLE) {
> -   if (offset < size)
> -   ceph_zero_pagecache_range(inode, offset, length);
> -   ret = ceph_zero_objects(inode, offset, length);
> -   } else if (endoff > size) {
> -   truncate_pagecache_range(inode, size, -1);
> -   if (ceph_inode_set_size(inode, endoff))
> -   ceph_check_caps(ceph_inode(inode),
> -   CHECK_CAPS_AUTHONLY, NULL);
> -   }
> +   ceph_zero_pagecache_range(inode, offset, length);
> +   ret = ceph_zero_objects(inode, offset, length);
>
> if (!ret) {
> spin_lock(>i_ceph_lock);
> @@ -1817,9 +1793,6 @@ static long ceph_fallocate(struct file *file, int mode,
> spin_unlock(>i_ceph_lock);
> if (dirty)
> __mark_inode_dirty(inode, dirty);
> -   if ((endoff > size) &&
> -   ceph_quota_is_max_bytes_approaching(inode, endoff))
> -   ceph_check_caps(ci, CHECK_CAPS_NODELAY, NULL);
> }
>
> ceph_put_cap_refs(ci, got);

Applied, thanks

Yan, Zheng

Re: [PATCH 4.4 000/113] 4.4.160-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 00:03, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.160-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: b5eb3855f86e32f79c8034c539bdaafa45832e8b
git describe: v4.4.159-114-gb5eb3855f86e
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.159-114-gb5eb3855f86e


No regressions (compared to build v4.4.159-114-g20e5d5bcb76b)


No fixes (compared to build v4.4.159-114-g20e5d5bcb76b)

Re: [PATCH 4.4 000/113] 4.4.160-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 00:03, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.4.160 release.
> There are 113 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Oct 10 17:55:13 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.4.160-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.4.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.4.160-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.4.y
git commit: b5eb3855f86e32f79c8034c539bdaafa45832e8b
git describe: v4.4.159-114-gb5eb3855f86e
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.4-oe/build/v4.4.159-114-gb5eb3855f86e


No regressions (compared to build v4.4.159-114-g20e5d5bcb76b)


No fixes (compared to build v4.4.159-114-g20e5d5bcb76b)

Re: [PATCH 4.9 00/59] 4.9.132-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 00:08, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Oct 10 17:55:28 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.132-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.132-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 610c33176e692eba4072ed7afbe58d397b6e4567
git describe: v4.9.131-60-g610c33176e69
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.131-60-g610c33176e69


No regressions (compared to build v4.9.131)

No fixes (compared to build v4.9.131)


Ran 16766 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.9 00/59] 4.9.132-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 00:08, Greg Kroah-Hartman
 wrote:
>
> This is the start of the stable review cycle for the 4.9.132 release.
> There are 59 patches in this series, all will be posted as a response
> to this one.  If anyone has any issues with these being applied, please
> let me know.
>
> Responses should be made by Wed Oct 10 17:55:28 UTC 2018.
> Anything received after that time might be too late.
>
> The whole patch series can be found in one patch at:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.9.132-rc1.gz
> or in the git tree and branch at:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> linux-4.9.y
> and the diffstat can be found below.
>
> thanks,
>
> greg k-h

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.9.132-rc1
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.9.y
git commit: 610c33176e692eba4072ed7afbe58d397b6e4567
git describe: v4.9.131-60-g610c33176e69
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.9-oe/build/v4.9.131-60-g610c33176e69


No regressions (compared to build v4.9.131)

No fixes (compared to build v4.9.131)


Ran 16766 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.14 00/94] 4.14.75-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 21:45, Greg Kroah-Hartman
 wrote:
>
> On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.75 release.
> > There are 94 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Oct 10 17:55:37 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >   
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.75-rc1.gz
>
> -rc2 is out to resolve some reported issues:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.75-rc2.gz
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.75-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 2040d5afb6ee8186df604b87a7e49c4ad71d3ecf
git describe: v4.14.74-94-g2040d5afb6ee
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.74-94-g2040d5afb6ee


No regressions (compared to build v4.14.74)


No fixes (compared to build v4.14.74)


Ran 21078 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-fsx-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: [PATCH 4.14 00/94] 4.14.75-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 21:45, Greg Kroah-Hartman
 wrote:
>
> On Mon, Oct 08, 2018 at 08:30:41PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.14.75 release.
> > There are 94 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Oct 10 17:55:37 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >   
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.75-rc1.gz
>
> -rc2 is out to resolve some reported issues:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.14.75-rc2.gz
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

Summary


kernel: 4.14.75-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.14.y
git commit: 2040d5afb6ee8186df604b87a7e49c4ad71d3ecf
git describe: v4.14.74-94-g2040d5afb6ee
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.14-oe/build/v4.14.74-94-g2040d5afb6ee


No regressions (compared to build v4.14.74)


No fixes (compared to build v4.14.74)


Ran 21078 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-fsx-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

[PATCH v5 1/3] mm: get_user_pages: consolidate error handling

[john . hubbard]

From: John Hubbard 

An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.

In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set of pages that are about to be returned.

As long every use of the "ret" variable is being edited, rename
"ret" --> "err", so that its name matches its true role.
This also gets rid of two shadowed variable declarations, as a
tiny beneficial a side effect.

Reviewed-by: Jan Kara 
Reviewed-by: Andrew Morton 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 1abc8b4afff6..05ee7c18e59a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -660,6 +660,7 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
struct vm_area_struct **vmas, int *nonblocking)
 {
long i = 0;
+   int err = 0;
unsigned int page_mask;
struct vm_area_struct *vma = NULL;
 
@@ -685,18 +686,19 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
if (!vma || start >= vma->vm_end) {
vma = find_extend_vma(mm, start);
if (!vma && in_gate_area(mm, start)) {
-   int ret;
-   ret = get_gate_page(mm, start & PAGE_MASK,
+   err = get_gate_page(mm, start & PAGE_MASK,
gup_flags, ,
pages ? [i] : NULL);
-   if (ret)
-   return i ? : ret;
+   if (err)
+   goto out;
page_mask = 0;
goto next_page;
}
 
-   if (!vma || check_vma_flags(vma, gup_flags))
-   return i ? : -EFAULT;
+   if (!vma || check_vma_flags(vma, gup_flags)) {
+   err = -EFAULT;
+   goto out;
+   }
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
, _pages, i,
@@ -709,23 +711,25 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
 * If we have a pending SIGKILL, don't keep faulting pages and
 * potentially allocating memory.
 */
-   if (unlikely(fatal_signal_pending(current)))
-   return i ? i : -ERESTARTSYS;
+   if (unlikely(fatal_signal_pending(current))) {
+   err = -ERESTARTSYS;
+   goto out;
+   }
cond_resched();
page = follow_page_mask(vma, start, foll_flags, _mask);
if (!page) {
-   int ret;
-   ret = faultin_page(tsk, vma, start, _flags,
+   err = faultin_page(tsk, vma, start, _flags,
nonblocking);
-   switch (ret) {
+   switch (err) {
case 0:
goto retry;
case -EFAULT:
case -ENOMEM:
case -EHWPOISON:
-   return i ? i : ret;
+   goto out;
case -EBUSY:
-   return i;
+   err = 0;
+   goto out;
case -ENOENT:
goto next_page;
}
@@ -737,7 +741,8 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
 */
goto next_page;
} else if (IS_ERR(page)) {
-   return i ? i : PTR_ERR(page);
+   err = PTR_ERR(page);
+   goto out;
}
if (pages) {
pages[i] = page;
@@ -757,7 +762,9 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
start += page_increm * PAGE_SIZE;
nr_pages -= page_increm;
} while (nr_pages);
-   return i;
+
+out:
+   return i ? i : err;
 }
 
 static bool vma_permits_fault(struct vm_area_struct *vma,
-- 
2.19.1

Re: [PATCH 4.18 000/168] 4.18.13-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
 wrote:
>
> On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.13 release.
> > There are 168 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Oct 10 17:55:44 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >   
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc1.gz
> > or in the git tree and branch at:
> >   
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.18.y
>
> -rc2 is out to resolve some reported issues:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc2.gz
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

NOTE: Now the reports gets regressions and fixes.

Summary


kernel: 4.18.13-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: 5492998ebf547be45246ae72220e9429e329e05f
git describe: v4.18.12-169-g5492998ebf54
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.12-169-g5492998ebf54

No regressions (compared to build v4.18.12)

No fixes (compared to build v4.18.12)

Ran 20171 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

[PATCH v5 1/3] mm: get_user_pages: consolidate error handling

[john . hubbard]

From: John Hubbard 

An upcoming patch requires a way to operate on each page that
any of the get_user_pages_*() variants returns.

In preparation for that, consolidate the error handling for
__get_user_pages(). This provides a single location (the "out:" label)
for operating on the collected set of pages that are about to be returned.

As long every use of the "ret" variable is being edited, rename
"ret" --> "err", so that its name matches its true role.
This also gets rid of two shadowed variable declarations, as a
tiny beneficial a side effect.

Reviewed-by: Jan Kara 
Reviewed-by: Andrew Morton 
Signed-off-by: John Hubbard 
---
 mm/gup.c | 37 ++---
 1 file changed, 22 insertions(+), 15 deletions(-)

diff --git a/mm/gup.c b/mm/gup.c
index 1abc8b4afff6..05ee7c18e59a 100644
--- a/mm/gup.c
+++ b/mm/gup.c
@@ -660,6 +660,7 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
struct vm_area_struct **vmas, int *nonblocking)
 {
long i = 0;
+   int err = 0;
unsigned int page_mask;
struct vm_area_struct *vma = NULL;
 
@@ -685,18 +686,19 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
if (!vma || start >= vma->vm_end) {
vma = find_extend_vma(mm, start);
if (!vma && in_gate_area(mm, start)) {
-   int ret;
-   ret = get_gate_page(mm, start & PAGE_MASK,
+   err = get_gate_page(mm, start & PAGE_MASK,
gup_flags, ,
pages ? [i] : NULL);
-   if (ret)
-   return i ? : ret;
+   if (err)
+   goto out;
page_mask = 0;
goto next_page;
}
 
-   if (!vma || check_vma_flags(vma, gup_flags))
-   return i ? : -EFAULT;
+   if (!vma || check_vma_flags(vma, gup_flags)) {
+   err = -EFAULT;
+   goto out;
+   }
if (is_vm_hugetlb_page(vma)) {
i = follow_hugetlb_page(mm, vma, pages, vmas,
, _pages, i,
@@ -709,23 +711,25 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
 * If we have a pending SIGKILL, don't keep faulting pages and
 * potentially allocating memory.
 */
-   if (unlikely(fatal_signal_pending(current)))
-   return i ? i : -ERESTARTSYS;
+   if (unlikely(fatal_signal_pending(current))) {
+   err = -ERESTARTSYS;
+   goto out;
+   }
cond_resched();
page = follow_page_mask(vma, start, foll_flags, _mask);
if (!page) {
-   int ret;
-   ret = faultin_page(tsk, vma, start, _flags,
+   err = faultin_page(tsk, vma, start, _flags,
nonblocking);
-   switch (ret) {
+   switch (err) {
case 0:
goto retry;
case -EFAULT:
case -ENOMEM:
case -EHWPOISON:
-   return i ? i : ret;
+   goto out;
case -EBUSY:
-   return i;
+   err = 0;
+   goto out;
case -ENOENT:
goto next_page;
}
@@ -737,7 +741,8 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
 */
goto next_page;
} else if (IS_ERR(page)) {
-   return i ? i : PTR_ERR(page);
+   err = PTR_ERR(page);
+   goto out;
}
if (pages) {
pages[i] = page;
@@ -757,7 +762,9 @@ static long __get_user_pages(struct task_struct *tsk, 
struct mm_struct *mm,
start += page_increm * PAGE_SIZE;
nr_pages -= page_increm;
} while (nr_pages);
-   return i;
+
+out:
+   return i ? i : err;
 }
 
 static bool vma_permits_fault(struct vm_area_struct *vma,
-- 
2.19.1

Re: [PATCH 4.18 000/168] 4.18.13-stable review

[Naresh Kamboju]

On Tue, 9 Oct 2018 at 21:44, Greg Kroah-Hartman
 wrote:
>
> On Mon, Oct 08, 2018 at 08:29:40PM +0200, Greg Kroah-Hartman wrote:
> > This is the start of the stable review cycle for the 4.18.13 release.
> > There are 168 patches in this series, all will be posted as a response
> > to this one.  If anyone has any issues with these being applied, please
> > let me know.
> >
> > Responses should be made by Wed Oct 10 17:55:44 UTC 2018.
> > Anything received after that time might be too late.
> >
> > The whole patch series can be found in one patch at:
> >   
> > https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc1.gz
> > or in the git tree and branch at:
> >   
> > git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git 
> > linux-4.18.y
>
> -rc2 is out to resolve some reported issues:
> 
> https://www.kernel.org/pub/linux/kernel/v4.x/stable-review/patch-4.18.13-rc2.gz
>

Results from Linaro’s test farm.
No regressions on arm64, arm, x86_64, and i386.

NOTE: Now the reports gets regressions and fixes.

Summary


kernel: 4.18.13-rc2
git repo: 
https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-stable-rc.git
git branch: linux-4.18.y
git commit: 5492998ebf547be45246ae72220e9429e329e05f
git describe: v4.18.12-169-g5492998ebf54
Test details: 
https://qa-reports.linaro.org/lkft/linux-stable-rc-4.18-oe/build/v4.18.12-169-g5492998ebf54

No regressions (compared to build v4.18.12)

No fixes (compared to build v4.18.12)

Ran 20171 total tests in the following environments and test suites.

Environments
--
- dragonboard-410c - arm64
- hi6220-hikey - arm64
- i386
- juno-r2 - arm64
- qemu_arm
- qemu_arm64
- qemu_i386
- qemu_x86_64
- x15 - arm
- x86_64

Test Suites
---
* boot
* kselftest
* libhugetlbfs
* ltp-cap_bounds-tests
* ltp-containers-tests
* ltp-cve-tests
* ltp-fcntl-locktests-tests
* ltp-filecaps-tests
* ltp-fs-tests
* ltp-fs_bind-tests
* ltp-fs_perms_simple-tests
* ltp-fsx-tests
* ltp-hugetlb-tests
* ltp-io-tests
* ltp-ipc-tests
* ltp-math-tests
* ltp-nptl-tests
* ltp-pty-tests
* ltp-sched-tests
* ltp-securebits-tests
* ltp-syscalls-tests
* ltp-timers-tests
* ltp-open-posix-tests
* kselftest-vsyscall-mode-native
* kselftest-vsyscall-mode-none

-- 
Linaro LKFT
https://lkft.linaro.org

Re: INFO: rcu detected stall in shmem_fault

[David Rientjes]

On Wed, 10 Oct 2018, Tetsuo Handa wrote:

> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> 
> What should we do if memcg-OOM found no killable task because the allocating 
> task
> was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog fires 
> (which seems to be caused by commit 3100dab2aa09dc6e ("mm: memcontrol: print 
> proper
> OOM header when no eligible victim left") because syzbot was terminating the 
> test
> upon WARN(1) removed by that commit) is not a good behavior.
> 

Not printing anything would be the obvious solution but the ideal solution 
would probably involve

 - adding feedback to the memcg oom killer that there are no killable 
   processes,

 - adding complete coverage for memcg_oom_recover() in all uncharge paths
   where the oom memcg's page_counter is decremented, and

 - having all processes stall until memcg_oom_recover() is called so 
   looping back into try_charge() has a reasonable expectation to succeed.

Re: INFO: rcu detected stall in shmem_fault

[David Rientjes]

On Wed, 10 Oct 2018, Tetsuo Handa wrote:

> syzbot is hitting RCU stall due to memcg-OOM event.
> https://syzkaller.appspot.com/bug?id=4ae3fff7fcf4c33a47c1192d2d62d2e03efffa64
> 
> What should we do if memcg-OOM found no killable task because the allocating 
> task
> was oom_score_adj == -1000 ? Flooding printk() until RCU stall watchdog fires 
> (which seems to be caused by commit 3100dab2aa09dc6e ("mm: memcontrol: print 
> proper
> OOM header when no eligible victim left") because syzbot was terminating the 
> test
> upon WARN(1) removed by that commit) is not a good behavior.
> 

Not printing anything would be the obvious solution but the ideal solution 
would probably involve

 - adding feedback to the memcg oom killer that there are no killable 
   processes,

 - adding complete coverage for memcg_oom_recover() in all uncharge paths
   where the oom memcg's page_counter is decremented, and

 - having all processes stall until memcg_oom_recover() is called so 
   looping back into try_charge() has a reasonable expectation to succeed.

[PATCH v5 3/3] infiniband/mm: convert put_page() to put_user_page*()

[john . hubbard]

From: John Hubbard 

For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()

This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:

1) Provide put_user_page*() routines, intended to be used
   for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
   invoke put_user_page*(), instead of put_page(). This involves dozens of
   call sites, any will take some time.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
   implement tracking of these pages. This tracking will be separate from
   the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
   special handling (especially in writeback paths) when the pages are
   backed by a filesystem. Again, [1] provides details as to why that is
   desirable.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

CC: Doug Ledford 
CC: Jason Gunthorpe 
CC: Mike Marciniszyn 
CC: Dennis Dalessandro 
CC: Christian Benvenuti 

CC: linux-r...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux...@kvack.org

Reviewed-by: Jan Kara 
Reviewed-by: Dennis Dalessandro 
Acked-by: Jason Gunthorpe 
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem.c  |  7 ---
 drivers/infiniband/core/umem_odp.c  |  2 +-
 drivers/infiniband/hw/hfi1/user_pages.c | 11 ---
 drivers/infiniband/hw/mthca/mthca_memfree.c |  6 +++---
 drivers/infiniband/hw/qib/qib_user_pages.c  | 11 ---
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  6 +++---
 drivers/infiniband/hw/usnic/usnic_uiom.c|  7 ---
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index a41792dbae1f..7ab7a3a35eb4 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -58,9 +58,10 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
 
page = sg_page(sg);
-   if (!PageDirty(page) && umem->writable && dirty)
-   set_page_dirty_lock(page);
-   put_page(page);
+   if (umem->writable && dirty)
+   put_user_pages_dirty_lock(, 1);
+   else
+   put_user_page(page);
}
 
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index 6ec748eccff7..6227b89cf05c 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -717,7 +717,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64 
user_virt, u64 bcnt,
ret = -EFAULT;
break;
}
-   put_page(local_page_list[j]);
+   put_user_page(local_page_list[j]);
continue;
}
 
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index e341e6dcc388..99ccc0483711 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -121,13 +121,10 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, 
unsigned long vaddr, size_t np
 void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
 size_t npages, bool dirty)
 {
-   size_t i;
-
-   for (i = 0; i < npages; i++) {
-   if (dirty)
-   set_page_dirty_lock(p[i]);
-   put_page(p[i]);
-   }
+   if (dirty)
+   put_user_pages_dirty_lock(p, npages);
+   else
+   put_user_pages(p, npages);
 
if (mm) { /* during close after signal, mm can be NULL */
down_write(>mmap_sem);
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c 
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index cc9c0c8ccba3..b8b12effd009 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -481,7 +481,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
 
ret = pci_map_sg(dev->pdev, _tab->page[i].mem, 1, PCI_DMA_TODEVICE);
if (ret < 0) {
-   put_page(pages[0]);
+   put_user_page(pages[0]);
goto out;
}
 
@@ -489,7 +489,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
 mthca_uarc_virt(dev, uar, i));
if (ret) {
pci_unmap_sg(dev->pdev, _tab->page[i].mem, 1, 
PCI_DMA_TODEVICE);
-   put_page(sg_page(_tab->page[i].mem));
+   

[PATCH v5 2/3] mm: introduce put_user_page*(), placeholder versions

[john . hubbard]

From: John Hubbard 

Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().

Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for release_pages(), and also as a replacement
for open-coded loops that release multiple pages.
These may be used for subsequent performance improvements,
via batching of pages to be released.

This is the first step of fixing the problem described in [1]. The steps
are:

1) (This patch): provide put_user_page*() routines, intended to be used
   for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
   invoke put_user_page*(), instead of put_page(). This involves dozens of
   call sites, any will take some time.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
   implement tracking of these pages. This tracking will be separate from
   the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
   special handling (especially in writeback paths) when the pages are
   backed by a filesystem. Again, [1] provides details as to why that is
   desirable.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

CC: Matthew Wilcox 
CC: Michal Hocko 
CC: Christopher Lameter 
CC: Jason Gunthorpe 
CC: Dan Williams 
CC: Jan Kara 
CC: Al Viro 
CC: Jerome Glisse 
CC: Christoph Hellwig 
CC: Ralph Campbell 

Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 include/linux/mm.h | 20 +++
 mm/swap.c  | 83 ++
 2 files changed, 103 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0416a7204be3..76d18aada9f8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -943,6 +943,26 @@ static inline void put_page(struct page *page)
__put_page(page);
 }
 
+/*
+ * put_user_page() - release a page that had previously been acquired via
+ * a call to one of the get_user_pages*() functions.
+ *
+ * Pages that were pinned via get_user_pages*() must be released via
+ * either put_user_page(), or one of the put_user_pages*() routines
+ * below. This is so that eventually, pages that are pinned via
+ * get_user_pages*() can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special
+ * handling.
+ */
+static inline void put_user_page(struct page *page)
+{
+   put_page(page);
+}
+
+void put_user_pages_dirty(struct page **pages, unsigned long npages);
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages);
+void put_user_pages(struct page **pages, unsigned long npages);
+
 #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
 #define SECTION_IN_PAGE_FLAGS
 #endif
diff --git a/mm/swap.c b/mm/swap.c
index 26fc9b5f1b6c..efab3a6b6f91 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -134,6 +134,89 @@ void put_pages_list(struct list_head *pages)
 }
 EXPORT_SYMBOL(put_pages_list);
 
+/*
+ * put_user_pages_dirty() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * set_page_dirty(), which does not lock the page, is used here.
+ * Therefore, it is the caller's responsibility to ensure that this is
+ * safe. If not, then put_user_pages_dirty_lock() should be called instead.
+ *
+ * @pages:  array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty(struct page **pages, unsigned long npages)
+{
+   unsigned long index;
+
+   for (index = 0; index < npages; index++) {
+   struct page *page = compound_head(pages[index]);
+
+   if (!PageDirty(page))
+   set_page_dirty(page);
+
+   put_user_page(page);
+   }
+}
+EXPORT_SYMBOL(put_user_pages_dirty);
+
+/*
+ * put_user_pages_dirty_lock() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * This is just like put_user_pages_dirty(), except that it invokes
+ * set_page_dirty_lock(), instead of set_page_dirty().
+ *
+ * @pages:  array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
+{
+   unsigned long index;
+
+   for (index = 0; index < npages; index++) {
+   struct page *page = compound_head(pages[index]);
+
+   if (!PageDirty(page))
+   

[PATCH v5 0/3] get_user_pages*() and RDMA: first steps

[john . hubbard]

From: John Hubbard 

Changes since v4:

-- Changed the new put_user_page*() functions to operate only on the head
   page, because that's how the final version of those functions will work.
   (Andrew Morton's feedback prompted this, thanks!)

-- Added proper documentation of the new put_user_page*() functions.

-- Moved most of the new put_user_page*() functions out of the header file,
   and into swap.c, because they have grown a little bigger than static
   inline functions should be. The trivial put_user_page() was left as
   a static inline for now, though.

-- Picked up Andrew Morton's Reviewed-by, for the first patch. I left
   Jan's Reviewed-by in place for now, but we should verify that it still
   holds, with the various changes above. The main difference is the change
   to use the head page, the rest is just code movement and documentation.

-- Fixed a bug in the infiniband patch, found by the kbuild bot.

-- Rewrote the changelogs (and part of this cover letter) to be clearer.
   Part of that is less reliance on links, and instead, just writing the
   steps directly.

Changes since v3:

-- Picks up Reviewed-by tags from Jan Kara and Dennis Dalessandro.

-- Picks up Acked-by tag from Jason Gunthorpe, in case this ends up *not*
   going in via the RDMA tree.

-- Fixes formatting of a comment.

Changes since v2:

-- Absorbed more dirty page handling logic into the put_user_page*(), and
   handled some page releasing loops in infiniband more thoroughly, as per
   Jason Gunthorpe's feedback.

-- Fixed a bug in the put_user_pages*() routines' loops (thanks to
   Ralph Campbell for spotting it).

Changes since v1:

-- Renamed release_user_pages*() to put_user_pages*(), from Jan's feedback.

-- Removed the goldfish.c changes, and instead, only included a single
   user (infiniband) of the new functions. That is because goldfish.c no
   longer has a name collision (it has a release_user_pages() routine), and
   also because infiniband exercises both the put_user_page() and
   put_user_pages*() paths.

-- Updated links to discussions and plans, so as to be sure to include
   bounce buffers, thanks to Jerome's feedback.

Also:

This short series prepares for eventually fixing the problem described
in [1]. The steps are:

1) (This patchset): Provide put_user_page*() routines, intended to be used
for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
invoke put_user_page*(), instead of put_page(). This involves dozens of
call sites, any will take some time. Patch 3/3 here kicks off the effort,
by applying it to infiniband.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
implement tracking of these pages. This tracking will be separate from
the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
special handling (especially in writeback paths) when the pages are
backed by a filesystem. Again, [1] provides details as to why that is
desirable.

Patch 1, although not technically critical to do now, is still nice to
have, because it's already been reviewed by Jan (and Andrew, now), and
it's just one more thing on the long TODO list here, that is ready to be
checked off.

Patch 2 is required in order to allow me (and others, if I'm lucky) to
start submitting changes to convert all of the callsites of
get_user_pages*() and put_page().  I think this will work a lot better
than trying to maintain a massive patchset and submitting all at once.

Patch 3 converts infiniband drivers: put_page() --> put_user_page(), and
also exercises put_user_pages_dirty_locked().

Once these are all in, then the floodgates can open up to convert the large
number of remaining get_user_pages*() callsites.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

[2] https://lkml.kernel.org/r/20180709080554.21931-1-jhubb...@nvidia.com
Proposed steps for fixing get_user_pages() + DMA problems.

[3]https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz
Bounce buffers (otherwise [2] is not really viable).

[4] https://lkml.kernel.org/r/20181003162115.gg24...@quack2.suse.cz
Follow-up discussions.

CC: Matthew Wilcox 
CC: Michal Hocko 
CC: Christopher Lameter 
CC: Jason Gunthorpe 
CC: Dan Williams 
CC: Jan Kara 
CC: Al Viro 
CC: Jerome Glisse 
CC: Christoph Hellwig 
CC: Ralph Campbell 
CC: Andrew Morton 

John Hubbard (3):
  mm: get_user_pages: consolidate error handling
  mm: introduce put_user_page*(), placeholder versions
  infiniband/mm: convert put_page() to put_user_page*()

 drivers/infiniband/core/umem.c  |  7 +-
 drivers/infiniband/core/umem_odp.c  |  2 +-
 drivers/infiniband/hw/hfi1/user_pages.c | 11 +--
 drivers/infiniband/hw/mthca/mthca_memfree.c |  6 +-
 drivers/infiniband/hw/qib/qib_user_pages.c  | 11 +--
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  6 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c|  7 +-
 

[PATCH v5 3/3] infiniband/mm: convert put_page() to put_user_page*()

[john . hubbard]

From: John Hubbard 

For infiniband code that retains pages via get_user_pages*(),
release those pages via the new put_user_page(), or
put_user_pages*(), instead of put_page()

This is a tiny part of the second step of fixing the problem described
in [1]. The steps are:

1) Provide put_user_page*() routines, intended to be used
   for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
   invoke put_user_page*(), instead of put_page(). This involves dozens of
   call sites, any will take some time.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
   implement tracking of these pages. This tracking will be separate from
   the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
   special handling (especially in writeback paths) when the pages are
   backed by a filesystem. Again, [1] provides details as to why that is
   desirable.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

CC: Doug Ledford 
CC: Jason Gunthorpe 
CC: Mike Marciniszyn 
CC: Dennis Dalessandro 
CC: Christian Benvenuti 

CC: linux-r...@vger.kernel.org
CC: linux-kernel@vger.kernel.org
CC: linux...@kvack.org

Reviewed-by: Jan Kara 
Reviewed-by: Dennis Dalessandro 
Acked-by: Jason Gunthorpe 
Signed-off-by: John Hubbard 
---
 drivers/infiniband/core/umem.c  |  7 ---
 drivers/infiniband/core/umem_odp.c  |  2 +-
 drivers/infiniband/hw/hfi1/user_pages.c | 11 ---
 drivers/infiniband/hw/mthca/mthca_memfree.c |  6 +++---
 drivers/infiniband/hw/qib/qib_user_pages.c  | 11 ---
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  6 +++---
 drivers/infiniband/hw/usnic/usnic_uiom.c|  7 ---
 7 files changed, 23 insertions(+), 27 deletions(-)

diff --git a/drivers/infiniband/core/umem.c b/drivers/infiniband/core/umem.c
index a41792dbae1f..7ab7a3a35eb4 100644
--- a/drivers/infiniband/core/umem.c
+++ b/drivers/infiniband/core/umem.c
@@ -58,9 +58,10 @@ static void __ib_umem_release(struct ib_device *dev, struct 
ib_umem *umem, int d
for_each_sg(umem->sg_head.sgl, sg, umem->npages, i) {
 
page = sg_page(sg);
-   if (!PageDirty(page) && umem->writable && dirty)
-   set_page_dirty_lock(page);
-   put_page(page);
+   if (umem->writable && dirty)
+   put_user_pages_dirty_lock(, 1);
+   else
+   put_user_page(page);
}
 
sg_free_table(>sg_head);
diff --git a/drivers/infiniband/core/umem_odp.c 
b/drivers/infiniband/core/umem_odp.c
index 6ec748eccff7..6227b89cf05c 100644
--- a/drivers/infiniband/core/umem_odp.c
+++ b/drivers/infiniband/core/umem_odp.c
@@ -717,7 +717,7 @@ int ib_umem_odp_map_dma_pages(struct ib_umem *umem, u64 
user_virt, u64 bcnt,
ret = -EFAULT;
break;
}
-   put_page(local_page_list[j]);
+   put_user_page(local_page_list[j]);
continue;
}
 
diff --git a/drivers/infiniband/hw/hfi1/user_pages.c 
b/drivers/infiniband/hw/hfi1/user_pages.c
index e341e6dcc388..99ccc0483711 100644
--- a/drivers/infiniband/hw/hfi1/user_pages.c
+++ b/drivers/infiniband/hw/hfi1/user_pages.c
@@ -121,13 +121,10 @@ int hfi1_acquire_user_pages(struct mm_struct *mm, 
unsigned long vaddr, size_t np
 void hfi1_release_user_pages(struct mm_struct *mm, struct page **p,
 size_t npages, bool dirty)
 {
-   size_t i;
-
-   for (i = 0; i < npages; i++) {
-   if (dirty)
-   set_page_dirty_lock(p[i]);
-   put_page(p[i]);
-   }
+   if (dirty)
+   put_user_pages_dirty_lock(p, npages);
+   else
+   put_user_pages(p, npages);
 
if (mm) { /* during close after signal, mm can be NULL */
down_write(>mmap_sem);
diff --git a/drivers/infiniband/hw/mthca/mthca_memfree.c 
b/drivers/infiniband/hw/mthca/mthca_memfree.c
index cc9c0c8ccba3..b8b12effd009 100644
--- a/drivers/infiniband/hw/mthca/mthca_memfree.c
+++ b/drivers/infiniband/hw/mthca/mthca_memfree.c
@@ -481,7 +481,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
 
ret = pci_map_sg(dev->pdev, _tab->page[i].mem, 1, PCI_DMA_TODEVICE);
if (ret < 0) {
-   put_page(pages[0]);
+   put_user_page(pages[0]);
goto out;
}
 
@@ -489,7 +489,7 @@ int mthca_map_user_db(struct mthca_dev *dev, struct 
mthca_uar *uar,
 mthca_uarc_virt(dev, uar, i));
if (ret) {
pci_unmap_sg(dev->pdev, _tab->page[i].mem, 1, 
PCI_DMA_TODEVICE);
-   put_page(sg_page(_tab->page[i].mem));
+   

[PATCH v5 2/3] mm: introduce put_user_page*(), placeholder versions

[john . hubbard]

From: John Hubbard 

Introduces put_user_page(), which simply calls put_page().
This provides a way to update all get_user_pages*() callers,
so that they call put_user_page(), instead of put_page().

Also introduces put_user_pages(), and a few dirty/locked variations,
as a replacement for release_pages(), and also as a replacement
for open-coded loops that release multiple pages.
These may be used for subsequent performance improvements,
via batching of pages to be released.

This is the first step of fixing the problem described in [1]. The steps
are:

1) (This patch): provide put_user_page*() routines, intended to be used
   for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
   invoke put_user_page*(), instead of put_page(). This involves dozens of
   call sites, any will take some time.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
   implement tracking of these pages. This tracking will be separate from
   the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
   special handling (especially in writeback paths) when the pages are
   backed by a filesystem. Again, [1] provides details as to why that is
   desirable.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

CC: Matthew Wilcox 
CC: Michal Hocko 
CC: Christopher Lameter 
CC: Jason Gunthorpe 
CC: Dan Williams 
CC: Jan Kara 
CC: Al Viro 
CC: Jerome Glisse 
CC: Christoph Hellwig 
CC: Ralph Campbell 

Reviewed-by: Jan Kara 
Signed-off-by: John Hubbard 
---
 include/linux/mm.h | 20 +++
 mm/swap.c  | 83 ++
 2 files changed, 103 insertions(+)

diff --git a/include/linux/mm.h b/include/linux/mm.h
index 0416a7204be3..76d18aada9f8 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -943,6 +943,26 @@ static inline void put_page(struct page *page)
__put_page(page);
 }
 
+/*
+ * put_user_page() - release a page that had previously been acquired via
+ * a call to one of the get_user_pages*() functions.
+ *
+ * Pages that were pinned via get_user_pages*() must be released via
+ * either put_user_page(), or one of the put_user_pages*() routines
+ * below. This is so that eventually, pages that are pinned via
+ * get_user_pages*() can be separately tracked and uniquely handled. In
+ * particular, interactions with RDMA and filesystems need special
+ * handling.
+ */
+static inline void put_user_page(struct page *page)
+{
+   put_page(page);
+}
+
+void put_user_pages_dirty(struct page **pages, unsigned long npages);
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages);
+void put_user_pages(struct page **pages, unsigned long npages);
+
 #if defined(CONFIG_SPARSEMEM) && !defined(CONFIG_SPARSEMEM_VMEMMAP)
 #define SECTION_IN_PAGE_FLAGS
 #endif
diff --git a/mm/swap.c b/mm/swap.c
index 26fc9b5f1b6c..efab3a6b6f91 100644
--- a/mm/swap.c
+++ b/mm/swap.c
@@ -134,6 +134,89 @@ void put_pages_list(struct list_head *pages)
 }
 EXPORT_SYMBOL(put_pages_list);
 
+/*
+ * put_user_pages_dirty() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * set_page_dirty(), which does not lock the page, is used here.
+ * Therefore, it is the caller's responsibility to ensure that this is
+ * safe. If not, then put_user_pages_dirty_lock() should be called instead.
+ *
+ * @pages:  array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty(struct page **pages, unsigned long npages)
+{
+   unsigned long index;
+
+   for (index = 0; index < npages; index++) {
+   struct page *page = compound_head(pages[index]);
+
+   if (!PageDirty(page))
+   set_page_dirty(page);
+
+   put_user_page(page);
+   }
+}
+EXPORT_SYMBOL(put_user_pages_dirty);
+
+/*
+ * put_user_pages_dirty_lock() - for each page in the @pages array, make
+ * that page (or its head page, if a compound page) dirty, if it was
+ * previously listed as clean. Then, release the page using
+ * put_user_page().
+ *
+ * Please see the put_user_page() documentation for details.
+ *
+ * This is just like put_user_pages_dirty(), except that it invokes
+ * set_page_dirty_lock(), instead of set_page_dirty().
+ *
+ * @pages:  array of pages to be marked dirty and released.
+ * @npages: number of pages in the @pages array.
+ *
+ */
+void put_user_pages_dirty_lock(struct page **pages, unsigned long npages)
+{
+   unsigned long index;
+
+   for (index = 0; index < npages; index++) {
+   struct page *page = compound_head(pages[index]);
+
+   if (!PageDirty(page))
+   

[PATCH v5 0/3] get_user_pages*() and RDMA: first steps

[john . hubbard]

From: John Hubbard 

Changes since v4:

-- Changed the new put_user_page*() functions to operate only on the head
   page, because that's how the final version of those functions will work.
   (Andrew Morton's feedback prompted this, thanks!)

-- Added proper documentation of the new put_user_page*() functions.

-- Moved most of the new put_user_page*() functions out of the header file,
   and into swap.c, because they have grown a little bigger than static
   inline functions should be. The trivial put_user_page() was left as
   a static inline for now, though.

-- Picked up Andrew Morton's Reviewed-by, for the first patch. I left
   Jan's Reviewed-by in place for now, but we should verify that it still
   holds, with the various changes above. The main difference is the change
   to use the head page, the rest is just code movement and documentation.

-- Fixed a bug in the infiniband patch, found by the kbuild bot.

-- Rewrote the changelogs (and part of this cover letter) to be clearer.
   Part of that is less reliance on links, and instead, just writing the
   steps directly.

Changes since v3:

-- Picks up Reviewed-by tags from Jan Kara and Dennis Dalessandro.

-- Picks up Acked-by tag from Jason Gunthorpe, in case this ends up *not*
   going in via the RDMA tree.

-- Fixes formatting of a comment.

Changes since v2:

-- Absorbed more dirty page handling logic into the put_user_page*(), and
   handled some page releasing loops in infiniband more thoroughly, as per
   Jason Gunthorpe's feedback.

-- Fixed a bug in the put_user_pages*() routines' loops (thanks to
   Ralph Campbell for spotting it).

Changes since v1:

-- Renamed release_user_pages*() to put_user_pages*(), from Jan's feedback.

-- Removed the goldfish.c changes, and instead, only included a single
   user (infiniband) of the new functions. That is because goldfish.c no
   longer has a name collision (it has a release_user_pages() routine), and
   also because infiniband exercises both the put_user_page() and
   put_user_pages*() paths.

-- Updated links to discussions and plans, so as to be sure to include
   bounce buffers, thanks to Jerome's feedback.

Also:

This short series prepares for eventually fixing the problem described
in [1]. The steps are:

1) (This patchset): Provide put_user_page*() routines, intended to be used
for releasing pages that were pinned via get_user_pages*().

2) Convert all of the call sites for get_user_pages*(), to
invoke put_user_page*(), instead of put_page(). This involves dozens of
call sites, any will take some time. Patch 3/3 here kicks off the effort,
by applying it to infiniband.

3) After (2) is complete, use get_user_pages*() and put_user_page*() to
implement tracking of these pages. This tracking will be separate from
the existing struct page refcounting.

4) Use the tracking and identification of these pages, to implement
special handling (especially in writeback paths) when the pages are
backed by a filesystem. Again, [1] provides details as to why that is
desirable.

Patch 1, although not technically critical to do now, is still nice to
have, because it's already been reviewed by Jan (and Andrew, now), and
it's just one more thing on the long TODO list here, that is ready to be
checked off.

Patch 2 is required in order to allow me (and others, if I'm lucky) to
start submitting changes to convert all of the callsites of
get_user_pages*() and put_page().  I think this will work a lot better
than trying to maintain a massive patchset and submitting all at once.

Patch 3 converts infiniband drivers: put_page() --> put_user_page(), and
also exercises put_user_pages_dirty_locked().

Once these are all in, then the floodgates can open up to convert the large
number of remaining get_user_pages*() callsites.

[1] https://lwn.net/Articles/753027/ : "The Trouble with get_user_pages()"

[2] https://lkml.kernel.org/r/20180709080554.21931-1-jhubb...@nvidia.com
Proposed steps for fixing get_user_pages() + DMA problems.

[3]https://lkml.kernel.org/r/20180710082100.mkdwngdv5kkrc...@quack2.suse.cz
Bounce buffers (otherwise [2] is not really viable).

[4] https://lkml.kernel.org/r/20181003162115.gg24...@quack2.suse.cz
Follow-up discussions.

CC: Matthew Wilcox 
CC: Michal Hocko 
CC: Christopher Lameter 
CC: Jason Gunthorpe 
CC: Dan Williams 
CC: Jan Kara 
CC: Al Viro 
CC: Jerome Glisse 
CC: Christoph Hellwig 
CC: Ralph Campbell 
CC: Andrew Morton 

John Hubbard (3):
  mm: get_user_pages: consolidate error handling
  mm: introduce put_user_page*(), placeholder versions
  infiniband/mm: convert put_page() to put_user_page*()

 drivers/infiniband/core/umem.c  |  7 +-
 drivers/infiniband/core/umem_odp.c  |  2 +-
 drivers/infiniband/hw/hfi1/user_pages.c | 11 +--
 drivers/infiniband/hw/mthca/mthca_memfree.c |  6 +-
 drivers/infiniband/hw/qib/qib_user_pages.c  | 11 +--
 drivers/infiniband/hw/qib/qib_user_sdma.c   |  6 +-
 drivers/infiniband/hw/usnic/usnic_uiom.c|  7 +-
 

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

[Anshuman Khandual]

On 10/09/2018 07:28 PM, Zi Yan wrote:
> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
> PMD migration entry check)
> 
> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
> 
>> A normal mapped THP page at PMD level should be correctly differentiated
>> from a PMD migration entry while walking the page table. A mapped THP would
>> additionally check positive for pmd_present() along with pmd_trans_huge()
>> as compared to a PMD migration entry. This just adds a new conditional test
>> differentiating the two while walking the page table.
>>
>> Fixes: 616b8371539a6 ("mm: thp: enable thp migration in generic path")
>> Signed-off-by: Anshuman Khandual 
>> ---
>> On X86, pmd_trans_huge() and is_pmd_migration_entry() are always mutually
>> exclusive which makes the current conditional block work for both mapped
>> and migration entries. This is not same with arm64 where pmd_trans_huge()
> 
> !pmd_present() && pmd_trans_huge() is used to represent THPs under splitting,

Not really if we just look at code in the conditional blocks.

> since _PAGE_PRESENT is cleared during THP splitting but _PAGE_PSE is not.
> See the comment in pmd_present() for x86, in arch/x86/include/asm/pgtable.h


if (pmd_trans_huge(pmde) || is_pmd_migration_entry(pmde)) {
pvmw->ptl = pmd_lock(mm, pvmw->pmd);
if (likely(pmd_trans_huge(*pvmw->pmd))) {
if (pvmw->flags & PVMW_MIGRATION)
return not_found(pvmw);
if (pmd_page(*pvmw->pmd) != page)
return not_found(pvmw);
return true;
} else if (!pmd_present(*pvmw->pmd)) {
if (thp_migration_supported()) {
if (!(pvmw->flags & PVMW_MIGRATION))
return not_found(pvmw);
if 
(is_migration_entry(pmd_to_swp_entry(*pvmw->pmd))) {
swp_entry_t entry = 
pmd_to_swp_entry(*pvmw->pmd);

if (migration_entry_to_page(entry) != 
page)
return not_found(pvmw);
return true;
}
}
return not_found(pvmw);
} else {
/* THP pmd was split under us: handle on pte level */
spin_unlock(pvmw->ptl);
pvmw->ptl = NULL;
}
} else if (!pmd_present(pmde)) { ---> Outer 'else if'
return false;
}

Looking at the above code, it seems the conditional check for a THP
splitting case would be (!pmd_trans_huge && pmd_present) instead as
it has skipped the first two conditions. But THP splitting must have
been initiated once it has cleared the outer check (else it would not
have cleared otherwise)

if (pmd_trans_huge(pmde) || is_pmd_migration_entry(pmde)).


BTW what PMD state does the outer 'else if' block identify which must
have cleared the following condition to get there.

(!pmd_present && !pmd_trans_huge && !is_pmd_migration_entry)

Re: [PATCH] mm/thp: Correctly differentiate between mapped THP and PMD migration entry

[Anshuman Khandual]

On 10/09/2018 07:28 PM, Zi Yan wrote:
> cc: Naoya Horiguchi (who proposed to use !_PAGE_PRESENT && !_PAGE_PSE for x86
> PMD migration entry check)
> 
> On 8 Oct 2018, at 23:58, Anshuman Khandual wrote:
> 
>> A normal mapped THP page at PMD level should be correctly differentiated
>> from a PMD migration entry while walking the page table. A mapped THP would
>> additionally check positive for pmd_present() along with pmd_trans_huge()
>> as compared to a PMD migration entry. This just adds a new conditional test
>> differentiating the two while walking the page table.
>>
>> Fixes: 616b8371539a6 ("mm: thp: enable thp migration in generic path")
>> Signed-off-by: Anshuman Khandual 
>> ---
>> On X86, pmd_trans_huge() and is_pmd_migration_entry() are always mutually
>> exclusive which makes the current conditional block work for both mapped
>> and migration entries. This is not same with arm64 where pmd_trans_huge()
> 
> !pmd_present() && pmd_trans_huge() is used to represent THPs under splitting,

Not really if we just look at code in the conditional blocks.

> since _PAGE_PRESENT is cleared during THP splitting but _PAGE_PSE is not.
> See the comment in pmd_present() for x86, in arch/x86/include/asm/pgtable.h


if (pmd_trans_huge(pmde) || is_pmd_migration_entry(pmde)) {
pvmw->ptl = pmd_lock(mm, pvmw->pmd);
if (likely(pmd_trans_huge(*pvmw->pmd))) {
if (pvmw->flags & PVMW_MIGRATION)
return not_found(pvmw);
if (pmd_page(*pvmw->pmd) != page)
return not_found(pvmw);
return true;
} else if (!pmd_present(*pvmw->pmd)) {
if (thp_migration_supported()) {
if (!(pvmw->flags & PVMW_MIGRATION))
return not_found(pvmw);
if 
(is_migration_entry(pmd_to_swp_entry(*pvmw->pmd))) {
swp_entry_t entry = 
pmd_to_swp_entry(*pvmw->pmd);

if (migration_entry_to_page(entry) != 
page)
return not_found(pvmw);
return true;
}
}
return not_found(pvmw);
} else {
/* THP pmd was split under us: handle on pte level */
spin_unlock(pvmw->ptl);
pvmw->ptl = NULL;
}
} else if (!pmd_present(pmde)) { ---> Outer 'else if'
return false;
}

Looking at the above code, it seems the conditional check for a THP
splitting case would be (!pmd_trans_huge && pmd_present) instead as
it has skipped the first two conditions. But THP splitting must have
been initiated once it has cleared the outer check (else it would not
have cleared otherwise)

if (pmd_trans_huge(pmde) || is_pmd_migration_entry(pmde)).


BTW what PMD state does the outer 'else if' block identify which must
have cleared the following condition to get there.

(!pmd_present && !pmd_trans_huge && !is_pmd_migration_entry)

Re: [PATCH v3 4/7] dmaengine: stm32-dma: Add DMA/MDMA chaining support

[Vinod]

On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
> 
> 
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between peripherals and STM32 DMA.
> >> This intermediate transfer is triggered by SW for single M2D transfer and
> >> by STM32 DMA IP for all other modes (sg, cyclic) and direction (D2M).
> >>
> >> A generic SRAM allocator is used for this intermediate buffer
> >> Each DMA channel will be able to define its SRAM needs to achieve chaining
> >> feature : (2 ^ order) * PAGE_SIZE.
> >> For cyclic, SRAM buffer is derived from period length (rounded on
> >> PAGE_SIZE).
> > 
> > So IIUC, you chain two dma txns together and transfer data via an SRAM?
> 
> Correct. one DMA is DMAv2 (stm32-dma) and the other is MDMA(stm32-mdma).
> Intermediate transfer is between device and memory.
> This intermediate transfer is using SDRAM.

Ah so you use dma calls to setup mdma xtfers? I dont think that is a
good idea. How do you know you should use mdma for subsequent transfer?


> >>  drivers/dma/stm32-dma.c | 879 
> >> ++--
> > 
> > that is a lot of change for a driver, consider splitting it up
> > logically in smaller changes...
> > 
> 
> This feature is rather monolithic. Difficult to split up.
> All the code is required at once.

It can be enabled at last but split up logically. Intrusive changes to a
driver make it hard to review..

-- 
~Vinod

Re: [PATCH v3 4/7] dmaengine: stm32-dma: Add DMA/MDMA chaining support

[Vinod]

On 09-10-18, 10:40, Pierre Yves MORDRET wrote:
> 
> 
> On 10/07/2018 06:00 PM, Vinod wrote:
> > On 28-09-18, 15:01, Pierre-Yves MORDRET wrote:
> >> This patch adds support of DMA/MDMA chaining support.
> >> It introduces an intermediate transfer between peripherals and STM32 DMA.
> >> This intermediate transfer is triggered by SW for single M2D transfer and
> >> by STM32 DMA IP for all other modes (sg, cyclic) and direction (D2M).
> >>
> >> A generic SRAM allocator is used for this intermediate buffer
> >> Each DMA channel will be able to define its SRAM needs to achieve chaining
> >> feature : (2 ^ order) * PAGE_SIZE.
> >> For cyclic, SRAM buffer is derived from period length (rounded on
> >> PAGE_SIZE).
> > 
> > So IIUC, you chain two dma txns together and transfer data via an SRAM?
> 
> Correct. one DMA is DMAv2 (stm32-dma) and the other is MDMA(stm32-mdma).
> Intermediate transfer is between device and memory.
> This intermediate transfer is using SDRAM.

Ah so you use dma calls to setup mdma xtfers? I dont think that is a
good idea. How do you know you should use mdma for subsequent transfer?


> >>  drivers/dma/stm32-dma.c | 879 
> >> ++--
> > 
> > that is a lot of change for a driver, consider splitting it up
> > logically in smaller changes...
> > 
> 
> This feature is rather monolithic. Difficult to split up.
> All the code is required at once.

It can be enabled at last but split up logically. Intrusive changes to a
driver make it hard to review..

-- 
~Vinod

Re: [PATCH] perf trace beautify: Beautify flags of mount(2) and umount(2).

[Benjamin Peterson]

Hi Arnaldo,
Did you get a chance to look at this again?

On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> Thanks for the review.
> 
> On Thu, Aug 30, 2018, at 11:28, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 27, 2018 at 08:53:44PM -0700, Benjamin Peterson escreveu:
> > > Example output of perf trace -e mount,umount2:
> > > 
> > >   6243.930 ( 0.052 ms): mount/30976 mount(dev_name: 0x55dc541bb920, 
> > > dir_name: 0x55dc541bc960, type: 0x55dc541b9c40, flags: BIND) = 0
> > >   7851.821 (26.015 ms): umount/30983 umount2(name: 0x558daa82cf50, flags: 
> > > MNT_FORCE) = 0
> > > 
> > > Signed-off-by: Benjamin Peterson 
> > 
> > So, I tried:
> > 
> > Before your patch:
> > 
> >   # perf trace -e *mount* mount /dev/mapper/fedora-home /s
> >  0.000 ( 4.335 ms): mount/3126 mount(dev_name: 0x55deecc4d480, 
> > dir_name: 0x55deecc4d4a0, type: 0x55deecc53880, flags: 3236757504) = 0
> >   #
> >   # perf trace -e *mount* umount /dev/mapper/fedora-home /s
> >  ? ( ): umount/3138  ... [continued]: umount2()) = 0
> > 11.576 (umount:  0.004 ms): /s: not mounted.umount/
> > 3138 umount2(arg0: 94501956754656, arg1: 0, arg2: 1, arg3: 
> > 140051050083104, arg4: 4, arg5: 94501956755136) = -1 EINVAL Invalid 
> > argument
> >   #
> > 
> > After:
> > 
> > [root@jouet ~]# perf trace -e *mount* mount /dev/mapper/fedora-home /s
> >  0.000 ( 1.213 ms): mount/5244 mount(dev_name: 0x5558c1169480, 
> > dir_name: 0x5558c11694a0, type: 0x5558c116f880, flags: ) = 0
> > [root@jouet ~]# perf trace -e *mount* umount /s
> >  0.000 ( 9.241 ms): umount/5251 umount2(name: 
> > 0x55f74a986480  ) = 0
> > 
> > The flags for mount got empty? Can you pleaes check that? I.e. using the
> > default mount options, not specifying a 'bind' mount like you did.
> 
> That comes from these lines in syscall_arg__scnprintf_mount_flags:
> 
> if ((flags & MS_MGC_MSK) == MS_MGC_VAL)
>   flags &= ~MS_MGC_MSK;
> 
> The reason for this is explained in the comment for do_mount in 
> fs/namespace.c:
> 
> /*
>  * Pre-0.97 versions of mount() didn't have a flags word.
>  * When the flags word was introduced its top half was required
>  * to have the magic value 0xC0ED, and this remained so until 2.4.0-test9.
>  * Therefore, if this magic number is present, it carries no information
>  * and must be discarded.
> */
> 
> (I used a bind mount for my commit message example because a "default" 
> mount() doesn't use any flags.)
> 
> > 
> > I'm splitting this patch so that the aliasing of 'umount2' to 'umount'
> > gets merged now,
> > 
> > Check my perf/core branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> 
> LGTM. Thanks
> 

Re: [PATCH] perf trace beautify: Beautify flags of mount(2) and umount(2).

[Benjamin Peterson]

Hi Arnaldo,
Did you get a chance to look at this again?

On Thu, Aug 30, 2018, at 14:50, Benjamin Peterson wrote:
> Thanks for the review.
> 
> On Thu, Aug 30, 2018, at 11:28, Arnaldo Carvalho de Melo wrote:
> > Em Mon, Aug 27, 2018 at 08:53:44PM -0700, Benjamin Peterson escreveu:
> > > Example output of perf trace -e mount,umount2:
> > > 
> > >   6243.930 ( 0.052 ms): mount/30976 mount(dev_name: 0x55dc541bb920, 
> > > dir_name: 0x55dc541bc960, type: 0x55dc541b9c40, flags: BIND) = 0
> > >   7851.821 (26.015 ms): umount/30983 umount2(name: 0x558daa82cf50, flags: 
> > > MNT_FORCE) = 0
> > > 
> > > Signed-off-by: Benjamin Peterson 
> > 
> > So, I tried:
> > 
> > Before your patch:
> > 
> >   # perf trace -e *mount* mount /dev/mapper/fedora-home /s
> >  0.000 ( 4.335 ms): mount/3126 mount(dev_name: 0x55deecc4d480, 
> > dir_name: 0x55deecc4d4a0, type: 0x55deecc53880, flags: 3236757504) = 0
> >   #
> >   # perf trace -e *mount* umount /dev/mapper/fedora-home /s
> >  ? ( ): umount/3138  ... [continued]: umount2()) = 0
> > 11.576 (umount:  0.004 ms): /s: not mounted.umount/
> > 3138 umount2(arg0: 94501956754656, arg1: 0, arg2: 1, arg3: 
> > 140051050083104, arg4: 4, arg5: 94501956755136) = -1 EINVAL Invalid 
> > argument
> >   #
> > 
> > After:
> > 
> > [root@jouet ~]# perf trace -e *mount* mount /dev/mapper/fedora-home /s
> >  0.000 ( 1.213 ms): mount/5244 mount(dev_name: 0x5558c1169480, 
> > dir_name: 0x5558c11694a0, type: 0x5558c116f880, flags: ) = 0
> > [root@jouet ~]# perf trace -e *mount* umount /s
> >  0.000 ( 9.241 ms): umount/5251 umount2(name: 
> > 0x55f74a986480  ) = 0
> > 
> > The flags for mount got empty? Can you pleaes check that? I.e. using the
> > default mount options, not specifying a 'bind' mount like you did.
> 
> That comes from these lines in syscall_arg__scnprintf_mount_flags:
> 
> if ((flags & MS_MGC_MSK) == MS_MGC_VAL)
>   flags &= ~MS_MGC_MSK;
> 
> The reason for this is explained in the comment for do_mount in 
> fs/namespace.c:
> 
> /*
>  * Pre-0.97 versions of mount() didn't have a flags word.
>  * When the flags word was introduced its top half was required
>  * to have the magic value 0xC0ED, and this remained so until 2.4.0-test9.
>  * Therefore, if this magic number is present, it carries no information
>  * and must be discarded.
> */
> 
> (I used a bind mount for my commit message example because a "default" 
> mount() doesn't use any flags.)
> 
> > 
> > I'm splitting this patch so that the aliasing of 'umount2' to 'umount'
> > gets merged now,
> > 
> > Check my perf/core branch at:
> > 
> > git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git
> 
> LGTM. Thanks
> 

Re: [PATCH] mfd: cros-ec: copy the whole event in get_next_event_xfer

[Benson Leung]

Hi Enric,
On Wed, Oct 3, 2018 at 4:01 AM Enric Balletbo i Serra
 wrote:
>
> Hi Emil,
>
> Many thanks to catch this and fix. Some comments below.
>
> You missed to add the v2, please send the next patch with v3 prefix.
>
> On 28/9/18 19:08, Emil Karlson wrote:
> > Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard 
> > events
> > be truncated on many chromebooks so that Left and Right keys on Column 12 
> > were
> > always 0. Use ret as memcpy len to fix this.
> >
>
> That's fine
>
> > drivers/platform/chrome/cros_ec_proto.c:509
> > get_next_event_xfer uses ret from cros_ec_cmd_xfer for memcpy for msg->data 
> > len
> > drivers/platform/chrome/cros_ec_proto.c:445
> > cros_ec_cmd_xfer gets ret from send_command
> > drivers/platform/chrome/cros_ec_proto.c:93
> > send_command gets ret from bus specific xfer_fn
> > drivers/mfd/cros_ec_spi.c:598
> > cros_ec_cmd_xfer_spi copies len amount to ec_msg->data and returns len as 
> > ret
> > drivers/mfd/cros_ec_i2c.c:267
> > cros_ec_cmd_xfer_i2c copies len amount to ec_msg->data and returns len as 
> > ret
> >
> > so msg->data length is always the same as ret.
> >
>
> Instead of describe the different calls involved and the returns. I'd explain
> why using ret fixes the issue.
>
> > Fixes: 57e94c8b974d ("mfd: cros-ec: Increase maximum mkbp event size")
> > Signed-off-by: Emil Karlson 
> > ---
> >  drivers/platform/chrome/cros_ec_proto.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 398393ab5df8..b6fd4838f60f 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -520,7 +520,7 @@ static int get_next_event_xfer(struct cros_ec_device 
> > *ec_dev,
> >   ret = cros_ec_cmd_xfer(ec_dev, msg);
> >   if (ret > 0) {
> >   ec_dev->event_size = ret - 1;
> > - memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> > + memcpy(_dev->event_data, msg->data, ret);
> >   }
> >
> >   return ret;
> >
>
> After thinking a bit more on this I think that how you fixed this is really
> clear. I was wondering if the downstream solution would be better but as is
> really late and will be good have this as urgent fix for the coming release I 
> am
> happy with it. We can always send follow up patches to sync with the 
> downstream
> version if is preferred.
>
> Neil, can you give us your Tested-by to have the make sure this doesn't break
> with protocol v1, I don't have such hardware.
>
> Benson, will be really good have this merged in this rc. Are you fine with 
> this
> solution?

Yes, I'm fine with it. Let me get this ready and try to get it before
we run out of rcs of 4.19.

>
> BTW, you can add my in next version.
>
> Acked-by: Enric Balletbo i Serra 



-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org

Re: [PATCH] mfd: cros-ec: copy the whole event in get_next_event_xfer

[Benson Leung]

Hi Enric,
On Wed, Oct 3, 2018 at 4:01 AM Enric Balletbo i Serra
 wrote:
>
> Hi Emil,
>
> Many thanks to catch this and fix. Some comments below.
>
> You missed to add the v2, please send the next patch with v3 prefix.
>
> On 28/9/18 19:08, Emil Karlson wrote:
> > Commit 57e94c8b974db2d83c60e1139c89a70806abbea0 caused cros-ec keyboard 
> > events
> > be truncated on many chromebooks so that Left and Right keys on Column 12 
> > were
> > always 0. Use ret as memcpy len to fix this.
> >
>
> That's fine
>
> > drivers/platform/chrome/cros_ec_proto.c:509
> > get_next_event_xfer uses ret from cros_ec_cmd_xfer for memcpy for msg->data 
> > len
> > drivers/platform/chrome/cros_ec_proto.c:445
> > cros_ec_cmd_xfer gets ret from send_command
> > drivers/platform/chrome/cros_ec_proto.c:93
> > send_command gets ret from bus specific xfer_fn
> > drivers/mfd/cros_ec_spi.c:598
> > cros_ec_cmd_xfer_spi copies len amount to ec_msg->data and returns len as 
> > ret
> > drivers/mfd/cros_ec_i2c.c:267
> > cros_ec_cmd_xfer_i2c copies len amount to ec_msg->data and returns len as 
> > ret
> >
> > so msg->data length is always the same as ret.
> >
>
> Instead of describe the different calls involved and the returns. I'd explain
> why using ret fixes the issue.
>
> > Fixes: 57e94c8b974d ("mfd: cros-ec: Increase maximum mkbp event size")
> > Signed-off-by: Emil Karlson 
> > ---
> >  drivers/platform/chrome/cros_ec_proto.c | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/platform/chrome/cros_ec_proto.c 
> > b/drivers/platform/chrome/cros_ec_proto.c
> > index 398393ab5df8..b6fd4838f60f 100644
> > --- a/drivers/platform/chrome/cros_ec_proto.c
> > +++ b/drivers/platform/chrome/cros_ec_proto.c
> > @@ -520,7 +520,7 @@ static int get_next_event_xfer(struct cros_ec_device 
> > *ec_dev,
> >   ret = cros_ec_cmd_xfer(ec_dev, msg);
> >   if (ret > 0) {
> >   ec_dev->event_size = ret - 1;
> > - memcpy(_dev->event_data, msg->data, ec_dev->event_size);
> > + memcpy(_dev->event_data, msg->data, ret);
> >   }
> >
> >   return ret;
> >
>
> After thinking a bit more on this I think that how you fixed this is really
> clear. I was wondering if the downstream solution would be better but as is
> really late and will be good have this as urgent fix for the coming release I 
> am
> happy with it. We can always send follow up patches to sync with the 
> downstream
> version if is preferred.
>
> Neil, can you give us your Tested-by to have the make sure this doesn't break
> with protocol v1, I don't have such hardware.
>
> Benson, will be really good have this merged in this rc. Are you fine with 
> this
> solution?

Yes, I'm fine with it. Let me get this ready and try to get it before
we run out of rcs of 4.19.

>
> BTW, you can add my in next version.
>
> Acked-by: Enric Balletbo i Serra 



-- 
Benson Leung
Staff Software Engineer
Chrome OS Kernel
Google Inc.
ble...@google.com
Chromium OS Project
ble...@chromium.org

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

[Bough Chen]

Hi Adam

Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!

Best Regards
Bough Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux Kernel Mailing List
> ; A.s. Dong ;
> haibo.c...@freescale.com; Fabio Estevam 
> Subject: Pinmuxing and SDHC speeds on sdhci-esdhc-imx
> 
> I have a question regarding the pinstate and the corresponding uhs_signaling.
> 
> The uhs_signaling shows a variety of timing options,
> 
>  MMC_TIMING_UHS_SDR12,  MMC_TIMING_UHS_SDR25:,
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104,
> MMC_TIMING_MMC_HS200,  MMC_TIMING_UHS_DDR50,
> MMC_TIMING_MMC_DDR52,  MMC_TIMING_MMC_HS400, and
> MMC_TIMING_LEGACY
> 
> However the esdhc_change_pinstate function only lists
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_DDR50,
> MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, and
> MMC_TIMING_MMC_HS40, and a defaut.
> 
> From what I can tell, this means that  MMC_TIMING_MMC_DDR52 uses the
> default pinmux.  I am wondering if it should use pins_100mhz.  We have an
> eMMC part that we want to operate at this point and it seems like it missing.
> If so, I can submit a patch.
> 
> It also seems like that SDR12, SDR25 use the default.  I assume this is OK.
> 
> adam

RE: Pinmuxing and SDHC speeds on sdhci-esdhc-imx

[Bough Chen]

Hi Adam

Yes, MMC_DDR52 can use pins_100mhz. You can do that, thanks!

Best Regards
Bough Chen

> -Original Message-
> From: linux-mmc-ow...@vger.kernel.org
> [mailto:linux-mmc-ow...@vger.kernel.org] On Behalf Of Adam Ford
> Sent: 2018年10月9日 21:38
> To: linux-...@vger.kernel.org; Linux Kernel Mailing List
> ; A.s. Dong ;
> haibo.c...@freescale.com; Fabio Estevam 
> Subject: Pinmuxing and SDHC speeds on sdhci-esdhc-imx
> 
> I have a question regarding the pinstate and the corresponding uhs_signaling.
> 
> The uhs_signaling shows a variety of timing options,
> 
>  MMC_TIMING_UHS_SDR12,  MMC_TIMING_UHS_SDR25:,
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_SDR104,
> MMC_TIMING_MMC_HS200,  MMC_TIMING_UHS_DDR50,
> MMC_TIMING_MMC_DDR52,  MMC_TIMING_MMC_HS400, and
> MMC_TIMING_LEGACY
> 
> However the esdhc_change_pinstate function only lists
> MMC_TIMING_UHS_SDR50, MMC_TIMING_UHS_DDR50,
> MMC_TIMING_UHS_SDR104, MMC_TIMING_MMC_HS200, and
> MMC_TIMING_MMC_HS40, and a defaut.
> 
> From what I can tell, this means that  MMC_TIMING_MMC_DDR52 uses the
> default pinmux.  I am wondering if it should use pins_100mhz.  We have an
> eMMC part that we want to operate at this point and it seems like it missing.
> If so, I can submit a patch.
> 
> It also seems like that SDR12, SDR25 use the default.  I assume this is OK.
> 
> adam

Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/09/2018 07:44 PM, Michal Hocko wrote:
> On Fri 05-10-18 13:04:43, Anshuman Khandual wrote:
>> Does the following sound close enough to what you are looking for ?
> 
> I do not think so

Okay.

> 
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..070c419 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -504,6 +504,13 @@ static inline bool hugepage_migration_supported(struct 
>> hstate *h)
>> return arch_hugetlb_migration_supported(h);
>>  }
>>  
>> +static inline bool hugepage_movable_required(struct hstate *h)
>> +{
>> +   if (hstate_is_gigantic(h))
>> +   return true;
>> +   return false;
>> +}
>> +
> 
> Apart from naming (hugepage_movable_supported?) the above doesn't do the
> most essential thing to query whether the hugepage migration is
> supported at all. Apart from that i would expect the logic to be revers.

My assumption was hugepage_migration_supported() should only be called from
unmap_and_move_huge_page() but we can add that here as well to limit the
set further.

> We do not really support giga pages migration enough to support them in
> movable zone.

Reversing the logic here would change gfp_t for a large number of huge pages.
Current implementation is very liberal in assigning __GFP_MOVABLE for multiple
huge page sizes (all most all of them when migration is enabled). But I guess
it should be okay because after all we are tying to control which all sizes
should be movable and which all should not be.

static inline bool hugepage_migration_supported(struct hstate *h)
{
#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
if ((huge_page_shift(h) == PMD_SHIFT) ||
(huge_page_shift(h) == PGDIR_SHIFT))
return true;
else
return false;
#else
return false;
#endif
}

static inline gfp_t htlb_alloc_mask(struct hstate *h)
{
if (hugepage_migration_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;
}

>> @@ -1652,6 +1655,9 @@ struct page *alloc_huge_page_nodemask(struct hstate 
>> *h, int preferred_nid,
>>  {
>> gfp_t gfp_mask = htlb_alloc_mask(h);
>>  
>> +   if (hugepage_movable_required(h))
>> +   gfp_mask |= __GFP_MOVABLE;
>> +
> 
> And besides that this really want to live in htlb_alloc_mask because
> this is really an allocation policy. It would be unmap_and_move_huge_page
> to call hugepage_migration_supported. The later is the one to allow for
> an arch specific override.
> 
> Makes sense?
> 

hugepage_migration_supported() will be checked inside 
hugepage_movable_supported().
A changed version 

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 9df1d59..4bcbf1e 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -504,6 +504,16 @@ static inline bool hugepage_migration_supported(struct 
hstate *h)
return arch_hugetlb_migration_supported(h);
 }
 
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+   if (!hugepage_migration_supported(h)) --> calls arch override 
restricting the set
+   return false;
+
+   if (hstate_is_gigantic(h)   > restricts the set further
+   return false;
+   return true;
+}
+
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
 {
@@ -600,6 +610,11 @@ static inline bool hugepage_migration_supported(struct 
hstate *h)
return false;
 }
 
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+   return false;
+}
+
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
 {
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775..a5a111d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -919,7 +919,7 @@ static struct page *dequeue_huge_page_nodemask(struct 
hstate *h, gfp_t gfp_mask,
 /* Movability of hugepages depends on migration support. */
 static inline gfp_t htlb_alloc_mask(struct hstate *h)
 {
-   if (hugepage_migration_supported(h))
+   if (hugepage_movable_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;


The above patch is in addition to the following later patch in the series.

mm/hugetlb: Enable arch specific huge page size support for migration

Architectures like arm64 have HugeTLB page sizes which are different than
generic sizes at PMD, PUD, PGD level and implemented via contiguous bits.
At present these special size HugeTLB pages cannot be identified through
macros like (PMD|PUD|PGDIR)_SHIFT and hence chosen not be migrated.

Enabling migration support for these special HugeTLB page sizes along with
the generic ones (PMD|PUD|PGD) would require identifying all of them on a
given platform. A platform 

Re: [PATCH 1/4] mm/hugetlb: Enable PUD level huge page migration

[Anshuman Khandual]

On 10/09/2018 07:44 PM, Michal Hocko wrote:
> On Fri 05-10-18 13:04:43, Anshuman Khandual wrote:
>> Does the following sound close enough to what you are looking for ?
> 
> I do not think so

Okay.

> 
>> diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
>> index 9df1d59..070c419 100644
>> --- a/include/linux/hugetlb.h
>> +++ b/include/linux/hugetlb.h
>> @@ -504,6 +504,13 @@ static inline bool hugepage_migration_supported(struct 
>> hstate *h)
>> return arch_hugetlb_migration_supported(h);
>>  }
>>  
>> +static inline bool hugepage_movable_required(struct hstate *h)
>> +{
>> +   if (hstate_is_gigantic(h))
>> +   return true;
>> +   return false;
>> +}
>> +
> 
> Apart from naming (hugepage_movable_supported?) the above doesn't do the
> most essential thing to query whether the hugepage migration is
> supported at all. Apart from that i would expect the logic to be revers.

My assumption was hugepage_migration_supported() should only be called from
unmap_and_move_huge_page() but we can add that here as well to limit the
set further.

> We do not really support giga pages migration enough to support them in
> movable zone.

Reversing the logic here would change gfp_t for a large number of huge pages.
Current implementation is very liberal in assigning __GFP_MOVABLE for multiple
huge page sizes (all most all of them when migration is enabled). But I guess
it should be okay because after all we are tying to control which all sizes
should be movable and which all should not be.

static inline bool hugepage_migration_supported(struct hstate *h)
{
#ifdef CONFIG_ARCH_ENABLE_HUGEPAGE_MIGRATION
if ((huge_page_shift(h) == PMD_SHIFT) ||
(huge_page_shift(h) == PGDIR_SHIFT))
return true;
else
return false;
#else
return false;
#endif
}

static inline gfp_t htlb_alloc_mask(struct hstate *h)
{
if (hugepage_migration_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;
}

>> @@ -1652,6 +1655,9 @@ struct page *alloc_huge_page_nodemask(struct hstate 
>> *h, int preferred_nid,
>>  {
>> gfp_t gfp_mask = htlb_alloc_mask(h);
>>  
>> +   if (hugepage_movable_required(h))
>> +   gfp_mask |= __GFP_MOVABLE;
>> +
> 
> And besides that this really want to live in htlb_alloc_mask because
> this is really an allocation policy. It would be unmap_and_move_huge_page
> to call hugepage_migration_supported. The later is the one to allow for
> an arch specific override.
> 
> Makes sense?
> 

hugepage_migration_supported() will be checked inside 
hugepage_movable_supported().
A changed version 

diff --git a/include/linux/hugetlb.h b/include/linux/hugetlb.h
index 9df1d59..4bcbf1e 100644
--- a/include/linux/hugetlb.h
+++ b/include/linux/hugetlb.h
@@ -504,6 +504,16 @@ static inline bool hugepage_migration_supported(struct 
hstate *h)
return arch_hugetlb_migration_supported(h);
 }
 
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+   if (!hugepage_migration_supported(h)) --> calls arch override 
restricting the set
+   return false;
+
+   if (hstate_is_gigantic(h)   > restricts the set further
+   return false;
+   return true;
+}
+
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
 {
@@ -600,6 +610,11 @@ static inline bool hugepage_migration_supported(struct 
hstate *h)
return false;
 }
 
+static inline bool hugepage_movable_supported(struct hstate *h)
+{
+   return false;
+}
+
 static inline spinlock_t *huge_pte_lockptr(struct hstate *h,
   struct mm_struct *mm, pte_t *pte)
 {
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 3c21775..a5a111d 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -919,7 +919,7 @@ static struct page *dequeue_huge_page_nodemask(struct 
hstate *h, gfp_t gfp_mask,
 /* Movability of hugepages depends on migration support. */
 static inline gfp_t htlb_alloc_mask(struct hstate *h)
 {
-   if (hugepage_migration_supported(h))
+   if (hugepage_movable_supported(h))
return GFP_HIGHUSER_MOVABLE;
else
return GFP_HIGHUSER;


The above patch is in addition to the following later patch in the series.

mm/hugetlb: Enable arch specific huge page size support for migration

Architectures like arm64 have HugeTLB page sizes which are different than
generic sizes at PMD, PUD, PGD level and implemented via contiguous bits.
At present these special size HugeTLB pages cannot be identified through
macros like (PMD|PUD|PGDIR)_SHIFT and hence chosen not be migrated.

Enabling migration support for these special HugeTLB page sizes along with
the generic ones (PMD|PUD|PGD) would require identifying all of them on a
given platform. A platform 

RE: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function

[Chuanhua Han]

> -Original Message-
> From: Esben Haabendal  On Behalf Of Esben
> Haabendal
> Sent: 2018年10月9日 19:21
> To: Chuanhua Han 
> Cc: Boris Brezillon ; broo...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> Chuanhua Han  writes:
> 
> >> -Original Message-
> >> From: Boris Brezillon 
> >> Sent: 2018年10月9日 18:05
> >> To: Chuanhua Han 
> >> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; e...@deif.com
> >> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw
> >> function
> >>
> >> On Tue, 9 Oct 2018 09:52:23 +
> >> Chuanhua Han  wrote:
> >>
> >> > 1. In the dspi driver (spi controller), bits_per_word
> >> > (dspi->bits_per_word = transfer->bits_per_word) passed from the
> >> > upper layer (spi-mem.c) is used. In this way, I can only assign the
> >> > appropriate value of transfer->bits_per_word before passing to the
> >> > controller, that is, the controller driver does not know the value
> >> > of bits_per_word, and it will use this value when the upper level
> >> > sets what value is passed.
> >>
> >> I think you're missing my point: ->bits_per_word is not what you're
> >> looking for if what you're trying to do is use 32-bits accesses when
> >> things are properly aligned.
> >>
> > In the dspi driver (spi controller driver), it is based on whether
> > ->bits_per_word is
> > larger than 16 to decide whether to use the XSPI mode (32bit) to transfer
> data.
> 
> Not completely true.  XSPI mode is enabled, also for words smaller than or
> equal to 16 bits.  But TX FIFO and CMD FIFO is written together, just as for
> non-XSPI mode.
> 
> > If ->bits_per_word is not set and the default bits_per_word =8 is
> > passed to the dspi driver, the XSPI mode (32bit) is not used for data
> > transfer in the dspi driver
> 
> Not true.  XSPI mode is unconditionally enabled in dspi_init().  But XSPI
> mode does not overrule the value of transfer->bits_per_word.
> The meaning of XSPI mode is the following:
> 
> 1. Frame (word) size is max 32 bits (with normal SPI mode, max is 16 bits).
> 2. For frames (words) with more than 16 bits per frame (word), each frame
> transfer results in 2 TX FIFO pop operations.
> 3. Command cycling is possible, enabled when SPI_CTARE[DTCP] > 1.
> 
> Command cycling is currently not implemented.  If implemented, it would be
> possible to send multiple frames (words) by writing one time to CMD FIFO and
> multiple times to TX FIFO.  This could possibly improve performance
> 
> Another possibility would be to use EOQ mode, if supported by the DSPI
> controller in the CPU.  It allows for filling TX FIFO, and getting IRQ only 
> after
> last TX FIFO entry is sent.  This is also a likely performance improvement.
> 
> >> > 2. As I understand, bits_per_word does not exist for non-byte
> >> > alignment, but for the need to reserve non-byte transmission mode
> >> > that meets the controller.
> >>
> >> Exactly. It's an optimization you have to take care of inside your
> >> driver. The core cannot help you with that.
> >>
> > The core layer is the upper layer. If you don't set ->bits_per_word,
> > bits_per_word will use the default value of 8, so that the
> > controller's specific mode for transferring data cannot be used (eg:
> > XSPI mode).
> 
> XSPI mode is independent of bits_per_word.  In XSPI mode, you can send
> frames as small as 4 bits, and up to 32 bits.  In normal SPI mode, you can
> send frames from 4 to 16 bits.
> 
> >> > 3. In addition, now the
> >> > XSPI of dspi cannot transfer data normally, so this problem needs
> >> > to be solved.
> >>
> >> I still don't understand what the problem is.
> >>
> > The problem is that I tested the XSPI mode and could not work, that
> > is, the data could not be transmitted normally.
> 
> What does "could not be transmitted normally" mean?
> 
> I am using XSPI mode on LS1021A, talking to a lot of different SPI devices.
> And they all work, and I believe everything is quite "normal".
> 
Since I don't have the board of LS1021, I can't test it. I use other boards 
with DSPI (such as LS1043, LS2088, etc.), 
and I test sp-flash connected on DSPI. If XSPI mode is used at this time, data 
cannot be transmitted normally.
> /Esben

RE: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function

[Chuanhua Han]

> -Original Message-
> From: Esben Haabendal  On Behalf Of Esben
> Haabendal
> Sent: 2018年10月9日 19:21
> To: Chuanhua Han 
> Cc: Boris Brezillon ; broo...@kernel.org;
> linux-...@vger.kernel.org; linux-kernel@vger.kernel.org
> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw function
> 
> Chuanhua Han  writes:
> 
> >> -Original Message-
> >> From: Boris Brezillon 
> >> Sent: 2018年10月9日 18:05
> >> To: Chuanhua Han 
> >> Cc: broo...@kernel.org; linux-...@vger.kernel.org;
> >> linux-kernel@vger.kernel.org; e...@deif.com
> >> Subject: Re: [PATCH 1/2] spi: spi-mem: Add the spi_set_xfer_bpw
> >> function
> >>
> >> On Tue, 9 Oct 2018 09:52:23 +
> >> Chuanhua Han  wrote:
> >>
> >> > 1. In the dspi driver (spi controller), bits_per_word
> >> > (dspi->bits_per_word = transfer->bits_per_word) passed from the
> >> > upper layer (spi-mem.c) is used. In this way, I can only assign the
> >> > appropriate value of transfer->bits_per_word before passing to the
> >> > controller, that is, the controller driver does not know the value
> >> > of bits_per_word, and it will use this value when the upper level
> >> > sets what value is passed.
> >>
> >> I think you're missing my point: ->bits_per_word is not what you're
> >> looking for if what you're trying to do is use 32-bits accesses when
> >> things are properly aligned.
> >>
> > In the dspi driver (spi controller driver), it is based on whether
> > ->bits_per_word is
> > larger than 16 to decide whether to use the XSPI mode (32bit) to transfer
> data.
> 
> Not completely true.  XSPI mode is enabled, also for words smaller than or
> equal to 16 bits.  But TX FIFO and CMD FIFO is written together, just as for
> non-XSPI mode.
> 
> > If ->bits_per_word is not set and the default bits_per_word =8 is
> > passed to the dspi driver, the XSPI mode (32bit) is not used for data
> > transfer in the dspi driver
> 
> Not true.  XSPI mode is unconditionally enabled in dspi_init().  But XSPI
> mode does not overrule the value of transfer->bits_per_word.
> The meaning of XSPI mode is the following:
> 
> 1. Frame (word) size is max 32 bits (with normal SPI mode, max is 16 bits).
> 2. For frames (words) with more than 16 bits per frame (word), each frame
> transfer results in 2 TX FIFO pop operations.
> 3. Command cycling is possible, enabled when SPI_CTARE[DTCP] > 1.
> 
> Command cycling is currently not implemented.  If implemented, it would be
> possible to send multiple frames (words) by writing one time to CMD FIFO and
> multiple times to TX FIFO.  This could possibly improve performance
> 
> Another possibility would be to use EOQ mode, if supported by the DSPI
> controller in the CPU.  It allows for filling TX FIFO, and getting IRQ only 
> after
> last TX FIFO entry is sent.  This is also a likely performance improvement.
> 
> >> > 2. As I understand, bits_per_word does not exist for non-byte
> >> > alignment, but for the need to reserve non-byte transmission mode
> >> > that meets the controller.
> >>
> >> Exactly. It's an optimization you have to take care of inside your
> >> driver. The core cannot help you with that.
> >>
> > The core layer is the upper layer. If you don't set ->bits_per_word,
> > bits_per_word will use the default value of 8, so that the
> > controller's specific mode for transferring data cannot be used (eg:
> > XSPI mode).
> 
> XSPI mode is independent of bits_per_word.  In XSPI mode, you can send
> frames as small as 4 bits, and up to 32 bits.  In normal SPI mode, you can
> send frames from 4 to 16 bits.
> 
> >> > 3. In addition, now the
> >> > XSPI of dspi cannot transfer data normally, so this problem needs
> >> > to be solved.
> >>
> >> I still don't understand what the problem is.
> >>
> > The problem is that I tested the XSPI mode and could not work, that
> > is, the data could not be transmitted normally.
> 
> What does "could not be transmitted normally" mean?
> 
> I am using XSPI mode on LS1021A, talking to a lot of different SPI devices.
> And they all work, and I believe everything is quite "normal".
> 
Since I don't have the board of LS1021, I can't test it. I use other boards 
with DSPI (such as LS1043, LS2088, etc.), 
and I test sp-flash connected on DSPI. If XSPI mode is used at this time, data 
cannot be transmitted normally.
> /Esben

Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

[Yi Sun]

On 18-10-09 12:54:27, Ingo Molnar wrote:
> 
> * Yi Sun  wrote:
> 
> > Follow PV spinlock mechanism to implement the callback functions
> > to allow the CPU idling and kicking operations on Hyper-V.
> 
> > +#if defined(CONFIG_SMP)
> > +   smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> > +#endif
> 
> What's wrong with using the common pattern of:
> 
>   #ifdef CONFIG_SMP
> 
> ?

There is no difference between "#ifdef" and "#if defined". I just copied
it from "hv_smp_prepare_boot_cpu()". Do you need me submit a fix patch
after this set is merged?

> 
> Thanks,
> 
>   Ingo

Re: [PATCH v4 2/2] locking/pvqspinlock, hv: Enable PV qspinlock for Hyper-V

[Yi Sun]

On 18-10-09 12:54:27, Ingo Molnar wrote:
> 
> * Yi Sun  wrote:
> 
> > Follow PV spinlock mechanism to implement the callback functions
> > to allow the CPU idling and kicking operations on Hyper-V.
> 
> > +#if defined(CONFIG_SMP)
> > +   smp_ops.smp_prepare_boot_cpu = hv_smp_prepare_boot_cpu;
> > +#endif
> 
> What's wrong with using the common pattern of:
> 
>   #ifdef CONFIG_SMP
> 
> ?

There is no difference between "#ifdef" and "#if defined". I just copied
it from "hv_smp_prepare_boot_cpu()". Do you need me submit a fix patch
after this set is merged?

> 
> Thanks,
> 
>   Ingo

linux-next: manual merge of the kvm-ppc tree with the kvm-arm tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc tree got a conflict in:

  include/uapi/linux/kvm.h

between commit:

  233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")

from the kvm-arm tree and commit:

  aa069a996951 ("KVM: PPC: Book3S HV: Add a VM capability to enable nested 
virtualization")

from the kvm-ppc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index 95aa73ca65dc,7f2ff3a76995..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -962,7 -954,7 +963,8 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_NESTED_STATE 157
  #define KVM_CAP_ARM_INJECT_SERROR_ESR 158
  #define KVM_CAP_MSR_PLATFORM_INFO 159
 -#define KVM_CAP_PPC_NESTED_HV 160
 +#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
++#define KVM_CAP_PPC_NESTED_HV 161
  
  #ifdef KVM_CAP_IRQ_ROUTING
  


pgpt7xrFV8uUa.pgp
Description: OpenPGP digital signature

linux-next: manual merge of the kvm-ppc tree with the kvm-arm tree

[Stephen Rothwell]

Hi Paul,

Today's linux-next merge of the kvm-ppc tree got a conflict in:

  include/uapi/linux/kvm.h

between commit:

  233a7cb23531 ("kvm: arm64: Allow tuning the physical address size for VM")

from the kvm-arm tree and commit:

  aa069a996951 ("KVM: PPC: Book3S HV: Add a VM capability to enable nested 
virtualization")

from the kvm-ppc tree.

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

-- 
Cheers,
Stephen Rothwell

diff --cc include/uapi/linux/kvm.h
index 95aa73ca65dc,7f2ff3a76995..
--- a/include/uapi/linux/kvm.h
+++ b/include/uapi/linux/kvm.h
@@@ -962,7 -954,7 +963,8 @@@ struct kvm_ppc_resize_hpt 
  #define KVM_CAP_NESTED_STATE 157
  #define KVM_CAP_ARM_INJECT_SERROR_ESR 158
  #define KVM_CAP_MSR_PLATFORM_INFO 159
 -#define KVM_CAP_PPC_NESTED_HV 160
 +#define KVM_CAP_ARM_VM_IPA_SIZE 160 /* returns maximum IPA bits for a VM */
++#define KVM_CAP_PPC_NESTED_HV 161
  
  #ifdef KVM_CAP_IRQ_ROUTING
  


pgpt7xrFV8uUa.pgp
Description: OpenPGP digital signature

[PATCH 2/2] clk: add 74aup1g157gw 2-input multiplexer as clock driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This driver adds new 74aup1g157gw as clock multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
input as output.

Signed-off-by: Kuninori Morimoto 
---
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   2 +-
 drivers/clk/nxp/Kconfig|   4 +
 drivers/clk/nxp/Makefile   |   1 +
 drivers/clk/nxp/clk-74aup1g157gw.c | 213 +
 5 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/nxp/Kconfig
 create mode 100644 drivers/clk/nxp/clk-74aup1g157gw.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 292056b..9cfeb0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -299,5 +299,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/nxp/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ed344eb..fcfd42a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_ARCH_MMP)+= mmp/
 endif
 obj-y  += mvebu/
 obj-$(CONFIG_ARCH_MXS) += mxs/
-obj-$(CONFIG_COMMON_CLK_NXP)   += nxp/
+obj-y  += nxp/
 obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
 obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
diff --git a/drivers/clk/nxp/Kconfig b/drivers/clk/nxp/Kconfig
new file mode 100644
index 000..44c8fed
--- /dev/null
+++ b/drivers/clk/nxp/Kconfig
@@ -0,0 +1,4 @@
+config CLK_74AUP1G157GW
+   tristate "NXP 74AUP1G157GW Low-power 2-input multiplexer support as 
clock"
+   help
+ This enables NXP 74AUP1G157GW 2-input multiplexer as clock driver
diff --git a/drivers/clk/nxp/Makefile b/drivers/clk/nxp/Makefile
index d456ee6..2965bdd 100644
--- a/drivers/clk/nxp/Makefile
+++ b/drivers/clk/nxp/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_ARCH_LPC18XX)  += clk-lpc18xx-cgu.o
 obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-ccu.o
 obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-creg.o
 obj-$(CONFIG_ARCH_LPC32XX) += clk-lpc32xx.o
+obj-$(CONFIG_CLK_74AUP1G157GW) += clk-74aup1g157gw.o
diff --git a/drivers/clk/nxp/clk-74aup1g157gw.c 
b/drivers/clk/nxp/clk-74aup1g157gw.c
new file mode 100644
index 000..78199bb
--- /dev/null
+++ b/drivers/clk/nxp/clk-74aup1g157gw.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2018 Renesas Solutions Corp.
+// Kuninori Morimoto 
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLK_I_NUM 2
+struct clk_priv {
+   struct clk_hw hw;
+   struct device *dev;
+   struct clk *i[CLK_I_NUM];
+   struct gpio_desc *sel;
+   long (*round_rate)(struct clk_hw *hw, unsigned long rate,
+  unsigned long *parent_rate);
+};
+#define hw_to_priv(_hw) container_of(_hw, struct clk_priv, hw)
+#define priv_to_dev(priv) priv->dev
+#define for_each_iclk(i)   \
+   for ((i) = 0; (i) < CLK_I_NUM; (i)++)
+
+static int clk74_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   int i;
+
+   for_each_iclk(i) {
+   if (rate == clk_get_rate(priv->i[i])) {
+   dev_dbg(dev, "set rate %lu as i%d\n", rate, i);
+   gpiod_set_value_cansleep(priv->sel, i);
+   return 0;
+   }
+   }
+
+   dev_err(dev, "unsupported rate %lu\n", rate);
+   return -EIO;
+}
+
+static long clk74_round_rate_close(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   unsigned long min = ~0;
+   unsigned long ret = 0;
+   int i;
+
+   /*
+* select closest rate
+*/
+   for_each_iclk(i) {
+   unsigned long irate = clk_get_rate(priv->i[i]);
+   unsigned long diff = abs(rate - irate);
+
+   if (min > diff) {
+   min = diff;
+   ret = irate;
+   }
+   }
+
+   dev_dbg(dev, "(close)round rate %lu\n", ret);
+
+   return ret;
+}
+
+static long clk74_round_rate_audio(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   unsigned long ret = 0;
+   int is_8k = 0;
+ 

[PATCH 1/2] dt-bindings: clock: add description of 74aup1g157gw

[Kuninori Morimoto]

From: Kuninori Morimoto 

74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This patch adds description for 74aup1g157gw as clock
multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
input as output.

Signed-off-by: Kuninori Morimoto 
---
 .../devicetree/bindings/clock/nxp,74aup1g157gw.txt| 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt

diff --git a/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt 
b/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt
new file mode 100644
index 000..d07bc04
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt
@@ -0,0 +1,19 @@
+NXP 74AUP1G157GW Low-power 2-input multiplexer for clock
+
+Required properties:
+- compatible:  "nxp,74aup1g157gw-clk"  (select closest input as output)
+   "nxp,74aup1g157gw-audio-clk (select 48kHz / 44.1kHz as output)
+- clocks:  select input clock as i0, i1
+- clock-names: "i0" and "i1"
+- sel-gpios:   selector pin
+
+Examples:
+
+   clk {
+   #clock-cells = <0>;
+   compatible = "nxp,74aup1g157gw-audio-clk";
+   clocks = <>, <>;
+   clock-names = "i0", "i1";
+   sel-gpios = <_exp_75 13 GPIO_ACTIVE_HIGH>;
+   };
+
-- 
2.7.4

[PATCH 1/2] dt-bindings: clock: add description of 74aup1g157gw

[Kuninori Morimoto]

From: Kuninori Morimoto 

74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This patch adds description for 74aup1g157gw as clock
multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
input as output.

Signed-off-by: Kuninori Morimoto 
---
 .../devicetree/bindings/clock/nxp,74aup1g157gw.txt| 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt

diff --git a/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt 
b/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt
new file mode 100644
index 000..d07bc04
--- /dev/null
+++ b/Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt
@@ -0,0 +1,19 @@
+NXP 74AUP1G157GW Low-power 2-input multiplexer for clock
+
+Required properties:
+- compatible:  "nxp,74aup1g157gw-clk"  (select closest input as output)
+   "nxp,74aup1g157gw-audio-clk (select 48kHz / 44.1kHz as output)
+- clocks:  select input clock as i0, i1
+- clock-names: "i0" and "i1"
+- sel-gpios:   selector pin
+
+Examples:
+
+   clk {
+   #clock-cells = <0>;
+   compatible = "nxp,74aup1g157gw-audio-clk";
+   clocks = <>, <>;
+   clock-names = "i0", "i1";
+   sel-gpios = <_exp_75 13 GPIO_ACTIVE_HIGH>;
+   };
+
-- 
2.7.4

[PATCH 2/2] clk: add 74aup1g157gw 2-input multiplexer as clock driver

[Kuninori Morimoto]

From: Kuninori Morimoto 

74aup1g157gw needs i0 and i1 pin as input, select and output it by
sel gpio pin. This driver adds new 74aup1g157gw as clock multiplexer.
"nxp,74aup1g157gw-clk" will select most closest input as output,
"nxp,74aup1g157gw-audio-clk" will select 48kHz/44.1kHz categorized
input as output.

Signed-off-by: Kuninori Morimoto 
---
 drivers/clk/Kconfig|   1 +
 drivers/clk/Makefile   |   2 +-
 drivers/clk/nxp/Kconfig|   4 +
 drivers/clk/nxp/Makefile   |   1 +
 drivers/clk/nxp/clk-74aup1g157gw.c | 213 +
 5 files changed, 220 insertions(+), 1 deletion(-)
 create mode 100644 drivers/clk/nxp/Kconfig
 create mode 100644 drivers/clk/nxp/clk-74aup1g157gw.c

diff --git a/drivers/clk/Kconfig b/drivers/clk/Kconfig
index 292056b..9cfeb0e 100644
--- a/drivers/clk/Kconfig
+++ b/drivers/clk/Kconfig
@@ -299,5 +299,6 @@ source "drivers/clk/sunxi-ng/Kconfig"
 source "drivers/clk/tegra/Kconfig"
 source "drivers/clk/ti/Kconfig"
 source "drivers/clk/uniphier/Kconfig"
+source "drivers/clk/nxp/Kconfig"
 
 endmenu
diff --git a/drivers/clk/Makefile b/drivers/clk/Makefile
index ed344eb..fcfd42a 100644
--- a/drivers/clk/Makefile
+++ b/drivers/clk/Makefile
@@ -84,7 +84,7 @@ obj-$(CONFIG_ARCH_MMP)+= mmp/
 endif
 obj-y  += mvebu/
 obj-$(CONFIG_ARCH_MXS) += mxs/
-obj-$(CONFIG_COMMON_CLK_NXP)   += nxp/
+obj-y  += nxp/
 obj-$(CONFIG_MACH_PISTACHIO)   += pistachio/
 obj-$(CONFIG_COMMON_CLK_PXA)   += pxa/
 obj-$(CONFIG_COMMON_CLK_QCOM)  += qcom/
diff --git a/drivers/clk/nxp/Kconfig b/drivers/clk/nxp/Kconfig
new file mode 100644
index 000..44c8fed
--- /dev/null
+++ b/drivers/clk/nxp/Kconfig
@@ -0,0 +1,4 @@
+config CLK_74AUP1G157GW
+   tristate "NXP 74AUP1G157GW Low-power 2-input multiplexer support as 
clock"
+   help
+ This enables NXP 74AUP1G157GW 2-input multiplexer as clock driver
diff --git a/drivers/clk/nxp/Makefile b/drivers/clk/nxp/Makefile
index d456ee6..2965bdd 100644
--- a/drivers/clk/nxp/Makefile
+++ b/drivers/clk/nxp/Makefile
@@ -2,3 +2,4 @@ obj-$(CONFIG_ARCH_LPC18XX)  += clk-lpc18xx-cgu.o
 obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-ccu.o
 obj-$(CONFIG_ARCH_LPC18XX) += clk-lpc18xx-creg.o
 obj-$(CONFIG_ARCH_LPC32XX) += clk-lpc32xx.o
+obj-$(CONFIG_CLK_74AUP1G157GW) += clk-74aup1g157gw.o
diff --git a/drivers/clk/nxp/clk-74aup1g157gw.c 
b/drivers/clk/nxp/clk-74aup1g157gw.c
new file mode 100644
index 000..78199bb
--- /dev/null
+++ b/drivers/clk/nxp/clk-74aup1g157gw.c
@@ -0,0 +1,213 @@
+// SPDX-License-Identifier: GPL-2.0
+//
+// Copyright (C) 2018 Renesas Solutions Corp.
+// Kuninori Morimoto 
+//
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#define CLK_I_NUM 2
+struct clk_priv {
+   struct clk_hw hw;
+   struct device *dev;
+   struct clk *i[CLK_I_NUM];
+   struct gpio_desc *sel;
+   long (*round_rate)(struct clk_hw *hw, unsigned long rate,
+  unsigned long *parent_rate);
+};
+#define hw_to_priv(_hw) container_of(_hw, struct clk_priv, hw)
+#define priv_to_dev(priv) priv->dev
+#define for_each_iclk(i)   \
+   for ((i) = 0; (i) < CLK_I_NUM; (i)++)
+
+static int clk74_set_rate(struct clk_hw *hw, unsigned long rate,
+ unsigned long parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   int i;
+
+   for_each_iclk(i) {
+   if (rate == clk_get_rate(priv->i[i])) {
+   dev_dbg(dev, "set rate %lu as i%d\n", rate, i);
+   gpiod_set_value_cansleep(priv->sel, i);
+   return 0;
+   }
+   }
+
+   dev_err(dev, "unsupported rate %lu\n", rate);
+   return -EIO;
+}
+
+static long clk74_round_rate_close(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   unsigned long min = ~0;
+   unsigned long ret = 0;
+   int i;
+
+   /*
+* select closest rate
+*/
+   for_each_iclk(i) {
+   unsigned long irate = clk_get_rate(priv->i[i]);
+   unsigned long diff = abs(rate - irate);
+
+   if (min > diff) {
+   min = diff;
+   ret = irate;
+   }
+   }
+
+   dev_dbg(dev, "(close)round rate %lu\n", ret);
+
+   return ret;
+}
+
+static long clk74_round_rate_audio(struct clk_hw *hw, unsigned long rate,
+unsigned long *parent_rate)
+{
+   struct clk_priv *priv = hw_to_priv(hw);
+   struct device *dev = priv_to_dev(priv);
+   unsigned long ret = 0;
+   int is_8k = 0;
+ 

[PATCH 0/2] add 74aup1g157gw 2-input multiplexer as clock driver

[Kuninori Morimoto]

Hi Michael, Stephen, Rob, Mark

These adds 74aup1g157gw 2-input multiplexer as clock driver.

Kuninori Morimoto (2):
  dt-bindings: clock: add description of 74aup1g157gw
  clk: add 74aup1g157gw 2-input multiplexer as clock driver

 Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt |  19 ++
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   2 +-
 drivers/clk/nxp/Kconfig  |   4 ++
 drivers/clk/nxp/Makefile |   1 +
 drivers/clk/nxp/clk-74aup1g157gw.c   | 213 
++
 6 files changed, 239 insertions(+), 1 deletion(-)

-- 
2.7.4

[PATCH 0/2] add 74aup1g157gw 2-input multiplexer as clock driver

[Kuninori Morimoto]

Hi Michael, Stephen, Rob, Mark

These adds 74aup1g157gw 2-input multiplexer as clock driver.

Kuninori Morimoto (2):
  dt-bindings: clock: add description of 74aup1g157gw
  clk: add 74aup1g157gw 2-input multiplexer as clock driver

 Documentation/devicetree/bindings/clock/nxp,74aup1g157gw.txt |  19 ++
 drivers/clk/Kconfig  |   1 +
 drivers/clk/Makefile |   2 +-
 drivers/clk/nxp/Kconfig  |   4 ++
 drivers/clk/nxp/Makefile |   1 +
 drivers/clk/nxp/clk-74aup1g157gw.c   | 213 
++
 6 files changed, 239 insertions(+), 1 deletion(-)

-- 
2.7.4

Re: [PATCH v14 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 10 October 2018 at 02:37, Jacek Anaszewski
 wrote:
> Hi Baolin,
>
> On 10/09/2018 02:01 PM, Baolin Wang wrote:
>> Hi Jacek and Pavel,
>>
>> On 5 October 2018 at 04:00, Jacek Anaszewski  
>> wrote:
>>> Hi Baolin,
>>>
>>> On 10/03/2018 03:21 AM, Baolin Wang wrote:
 Hi Jacek,

 On 3 October 2018 at 04:25, Jacek Anaszewski  
 wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v13:
>>  - Add duration validation for gradual dimming.
>>  - Coding style optimization.
>>
>> Changes from v12:
>>  - Add gradual dimming support for software pattern.
>>
>> Changes from v11:
>>  - Change -1 means repeat indefinitely.
>>
>> Changes from v10:
>>  - Change 'int' to 'u32' for delta_t field.
>>
>> Changes from v9:
>>  - None.
>>
>> Changes from v8:
>>  - None.
>>
>> Changes from v7:
>>  - Move the SC27XX hardware patterns description into its own ABI file.
>>
>> Changes from v6:
>>  - Improve commit message.
>>  - Optimize the description of the hw_pattern file.
>>  - Simplify some logics.
>>
>> Changes from v5:
>>  - Add one 'hw_pattern' file for hardware patterns.
>>
>> Changes from v4:
>>  - Change the repeat file to return the originally written number.
>>  - Improve comments.
>>  - Fix some build warnings.
>>
>> Changes from v3:
>>  - Reset pattern number to 0 if user provides incorrect pattern string.
>>  - Support one pattern.
>>
>> Changes from v2:
>>  - Remove hardware_pattern boolen.
>>  - Chnage the pattern string format.
>>
>> Changes from v1:
>>  - Use ATTRIBUTE_GROUPS() to define attributes.
>>  - Introduce hardware_pattern flag to determine if software pattern
>>  or hardware pattern.
>>  - Re-implement pattern_trig_store_pattern() function.
>>  - Remove pattern_get() interface.
>>  - Improve comments.
>>  - Other small optimization.
>> ---
>>  .../ABI/testing/sysfs-class-led-trigger-pattern|  76 
>>  drivers/leds/trigger/Kconfig   |   7 +
>>  drivers/leds/trigger/Makefile  |   1 +
>>  drivers/leds/trigger/ledtrig-pattern.c | 431 
>> +
>>  include/linux/leds.h   |  15 +
>>  5 files changed, 530 insertions(+)
>>  create mode 100644 
>> Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>>  create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> new file mode 100644
>> index 000..22d7af7
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> @@ -0,0 +1,76 @@
>> +What:/sys/class/leds//pattern
>> +Date:September 2018
>> +KernelVersion:   4.20
>> +Description:
>> + Specify a software pattern for the LED, that supports 
>> altering
>> + the brightness for the specified duration with one software
>> + timer. It can do gradual dimming and constant brightness.
>> +
>> + The pattern is given by a series of tuples, of brightness 
>> and
>> + duration (ms). The LED is expected to traverse the series 
>> and
>> + each brightness value for the specified duration. Duration 
>> of
>> + 0 means brightness should immediately change to new value.
>> +
>> + 1. When doing gradual dimming, the led brightness will be 
>> updated
>> + every 50 milliseconds, so the duration of each step should 
>> not
>> + less than 50 milliseconds.
>
> I'd like to avoid this constraint. Lowest supported delta_t should be 1.
>
> We should only prevent entering dimming mode if current delta_t
> is lower than UPDATE_INTERVAL.

 I do not think so. If the pattern format is used for dimming and the
 

Re: [PATCH v14 1/2] leds: core: Introduce LED pattern trigger

[Baolin Wang]

Hi Jacek,

On 10 October 2018 at 02:37, Jacek Anaszewski
 wrote:
> Hi Baolin,
>
> On 10/09/2018 02:01 PM, Baolin Wang wrote:
>> Hi Jacek and Pavel,
>>
>> On 5 October 2018 at 04:00, Jacek Anaszewski  
>> wrote:
>>> Hi Baolin,
>>>
>>> On 10/03/2018 03:21 AM, Baolin Wang wrote:
 Hi Jacek,

 On 3 October 2018 at 04:25, Jacek Anaszewski  
 wrote:
> Hi Baolin,
>
> Thank you for the v14. We'll probably need v15, though :-)
>
> I added the comments in the code below.
>
> On 10/02/2018 05:43 PM, Baolin Wang wrote:
>> This patch adds one new led trigger that LED device can configure
>> the software or hardware pattern and trigger it.
>>
>> Consumers can write 'pattern' file to enable the software pattern
>> which alters the brightness for the specified duration with one
>> software timer.
>>
>> Moreover consumers can write 'hw_pattern' file to enable the hardware
>> pattern for some LED controllers which can autonomously control
>> brightness over time, according to some preprogrammed hardware
>> patterns.
>>
>> Signed-off-by: Raphael Teysseyre 
>> Signed-off-by: Baolin Wang 
>> ---
>> Changes from v13:
>>  - Add duration validation for gradual dimming.
>>  - Coding style optimization.
>>
>> Changes from v12:
>>  - Add gradual dimming support for software pattern.
>>
>> Changes from v11:
>>  - Change -1 means repeat indefinitely.
>>
>> Changes from v10:
>>  - Change 'int' to 'u32' for delta_t field.
>>
>> Changes from v9:
>>  - None.
>>
>> Changes from v8:
>>  - None.
>>
>> Changes from v7:
>>  - Move the SC27XX hardware patterns description into its own ABI file.
>>
>> Changes from v6:
>>  - Improve commit message.
>>  - Optimize the description of the hw_pattern file.
>>  - Simplify some logics.
>>
>> Changes from v5:
>>  - Add one 'hw_pattern' file for hardware patterns.
>>
>> Changes from v4:
>>  - Change the repeat file to return the originally written number.
>>  - Improve comments.
>>  - Fix some build warnings.
>>
>> Changes from v3:
>>  - Reset pattern number to 0 if user provides incorrect pattern string.
>>  - Support one pattern.
>>
>> Changes from v2:
>>  - Remove hardware_pattern boolen.
>>  - Chnage the pattern string format.
>>
>> Changes from v1:
>>  - Use ATTRIBUTE_GROUPS() to define attributes.
>>  - Introduce hardware_pattern flag to determine if software pattern
>>  or hardware pattern.
>>  - Re-implement pattern_trig_store_pattern() function.
>>  - Remove pattern_get() interface.
>>  - Improve comments.
>>  - Other small optimization.
>> ---
>>  .../ABI/testing/sysfs-class-led-trigger-pattern|  76 
>>  drivers/leds/trigger/Kconfig   |   7 +
>>  drivers/leds/trigger/Makefile  |   1 +
>>  drivers/leds/trigger/ledtrig-pattern.c | 431 
>> +
>>  include/linux/leds.h   |  15 +
>>  5 files changed, 530 insertions(+)
>>  create mode 100644 
>> Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>>  create mode 100644 drivers/leds/trigger/ledtrig-pattern.c
>>
>> diff --git a/Documentation/ABI/testing/sysfs-class-led-trigger-pattern 
>> b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> new file mode 100644
>> index 000..22d7af7
>> --- /dev/null
>> +++ b/Documentation/ABI/testing/sysfs-class-led-trigger-pattern
>> @@ -0,0 +1,76 @@
>> +What:/sys/class/leds//pattern
>> +Date:September 2018
>> +KernelVersion:   4.20
>> +Description:
>> + Specify a software pattern for the LED, that supports 
>> altering
>> + the brightness for the specified duration with one software
>> + timer. It can do gradual dimming and constant brightness.
>> +
>> + The pattern is given by a series of tuples, of brightness 
>> and
>> + duration (ms). The LED is expected to traverse the series 
>> and
>> + each brightness value for the specified duration. Duration 
>> of
>> + 0 means brightness should immediately change to new value.
>> +
>> + 1. When doing gradual dimming, the led brightness will be 
>> updated
>> + every 50 milliseconds, so the duration of each step should 
>> not
>> + less than 50 milliseconds.
>
> I'd like to avoid this constraint. Lowest supported delta_t should be 1.
>
> We should only prevent entering dimming mode if current delta_t
> is lower than UPDATE_INTERVAL.

 I do not think so. If the pattern format is used for dimming and the
 

[PATCH] lib/rbtree.c: fix typo in comment of rb_insert_augmented()

[Wei Yang]

The function name in the comment is not correct.

Signed-off-by: Wei Yang 
---
 include/linux/rbtree_augmented.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index af8a61be2d8d..9510c677ac70 100644
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -51,8 +51,8 @@ extern void __rb_insert_augmented(struct rb_node *node,
  *
  * On insertion, the user must update the augmented information on the path
  * leading to the inserted node, then call rb_link_node() as usual and
- * rb_augment_inserted() instead of the usual rb_insert_color() call.
- * If rb_augment_inserted() rebalances the rbtree, it will callback into
+ * rb_insert_augmented() instead of the usual rb_insert_color() call.
+ * If rb_insert_augmented() rebalances the rbtree, it will callback into
  * a user provided function to update the augmented information on the
  * affected subtrees.
  */
-- 
2.15.1

[PATCH] lib/rbtree.c: fix typo in comment of rb_insert_augmented()

[Wei Yang]

The function name in the comment is not correct.

Signed-off-by: Wei Yang 
---
 include/linux/rbtree_augmented.h | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/include/linux/rbtree_augmented.h b/include/linux/rbtree_augmented.h
index af8a61be2d8d..9510c677ac70 100644
--- a/include/linux/rbtree_augmented.h
+++ b/include/linux/rbtree_augmented.h
@@ -51,8 +51,8 @@ extern void __rb_insert_augmented(struct rb_node *node,
  *
  * On insertion, the user must update the augmented information on the path
  * leading to the inserted node, then call rb_link_node() as usual and
- * rb_augment_inserted() instead of the usual rb_insert_color() call.
- * If rb_augment_inserted() rebalances the rbtree, it will callback into
+ * rb_insert_augmented() instead of the usual rb_insert_color() call.
+ * If rb_insert_augmented() rebalances the rbtree, it will callback into
  * a user provided function to update the augmented information on the
  * affected subtrees.
  */
-- 
2.15.1

Inquiry 09-10-2018

[Daniel Murray]

Hi,friend,

This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in 
your products.
Could you kindly send us your Latest catalog and price list for our trial order.

Best Regards,

Daniel Murray
Purchasing Manager

Inquiry 09-10-2018

[Daniel Murray]

Hi,friend,

This is Daniel Murray and i am from Sinara Group Co.Ltd Group Co.,LTD in Russia.
We are glad to know about your company from the web and we are interested in 
your products.
Could you kindly send us your Latest catalog and price list for our trial order.

Best Regards,

Daniel Murray
Purchasing Manager

Re: [PATCH V5 3/3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Stephen Boyd]

Quoting Doug Anderson (2018-10-09 14:18:26)
> Hi,
> On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd  wrote:
> >
> > Quoting Doug Anderson (2018-10-09 10:48:55)
> > >
> > > Ah, you're suggesting separating the platform_get_irq() and the
> > > request_irq() so that we call platform_get_irq() as the first thing in
> > > the function but don't do the request_irq() until later.  Yeah, that
> > > could be done and I guess if you feel strongly about it I wouldn't
> > > object to the change, but I don't feel it buys us a lot and I kind of
> > > like keeping the two next to each other.  Specifically why I don't
> > > think it buys us a lot:
> > >
> > > 1. You still need the "dev_err" print, right?  platform_get_irq()
> > > doesn't automatically print errors for you I think.
> >
> > I usually leave it out. Who cares? Maybe we should throw a dev_err()
> > into platform_get_irq() on failure so we can keep drivers cleaner and
> > reduce a bunch of "can't find my IRQ" messages throughout the kernel.
> 
> Yeah, all the boilerplate code is annoying.  ...of course by hoisting
> it up then you get a whole bunch of people that have "optional" IRQs
> suddenly getting error messages spewed which is also no good.  IMO the
> convention of Linux drivers I've always reviewed is to print errors
> like this, so unless that changes my vote is to follow convention.
> 
> 
> > > 2. You now need a local variable "irq".  By putting the
> > > platform_get_irq() before the memory allocation you now can't store it
> > > directly in mas->irq.  We could try using "ret" as a temporary
> > > variable but that seems worse in this case since it'd be a bit
> > > fragile.
> > >
> > > 3. You don't get rid of any error labels / error handling so we don't
> > > really save any code
> > >
> > > When I tried this my diffstat says 8 lines added and 7 removed, so a
> > > net increase in LOC FWIW.  I'm relying in gmail so my patch will be
> > > whitespace-damaged (sigh), but you can find a clean one at:
> > >
> > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e0325d618e209c22379e3a4269c14627b19243a8%5E%21/#F0
> > >
> > > ...the basic idea is this though:
> > >
> >
> > Thanks! Here's an updated patch that I haven't compile tested in any way
> > that hoists up the IO mapping part too, which shows that the 'se' local
> > variable is almost entirely useless.
> 
> Yeah, I'd be all for getting rid of "se".  I'm still not really seeing
> the benefit of hoisting all the rest of the stuff up.  Do you feel
> strongly about it?
> 
> In any case I think we've both said that all of our comments so far
> are just nits and could be addressed in a followup patch.  Unless Mark
> Brown wants these nits fixed ahead of time or has other changes he'd
> like, I don't think we're expecting another spin of this patch from
> Alok or Dilip, right?  We'd just expect them to post some follow-up
> patches after Mark lands it?
> 
> 

Yes this is all nits territory. I don't really care too much, but the
patch is already written, so might as well roll it all in and make
things shiny.

Time to get back to real work :P

Re: [PATCH V5 3/3] spi: spi-geni-qcom: Add SPI driver support for GENI based QUP

[Stephen Boyd]

Quoting Doug Anderson (2018-10-09 14:18:26)
> Hi,
> On Tue, Oct 9, 2018 at 12:45 PM Stephen Boyd  wrote:
> >
> > Quoting Doug Anderson (2018-10-09 10:48:55)
> > >
> > > Ah, you're suggesting separating the platform_get_irq() and the
> > > request_irq() so that we call platform_get_irq() as the first thing in
> > > the function but don't do the request_irq() until later.  Yeah, that
> > > could be done and I guess if you feel strongly about it I wouldn't
> > > object to the change, but I don't feel it buys us a lot and I kind of
> > > like keeping the two next to each other.  Specifically why I don't
> > > think it buys us a lot:
> > >
> > > 1. You still need the "dev_err" print, right?  platform_get_irq()
> > > doesn't automatically print errors for you I think.
> >
> > I usually leave it out. Who cares? Maybe we should throw a dev_err()
> > into platform_get_irq() on failure so we can keep drivers cleaner and
> > reduce a bunch of "can't find my IRQ" messages throughout the kernel.
> 
> Yeah, all the boilerplate code is annoying.  ...of course by hoisting
> it up then you get a whole bunch of people that have "optional" IRQs
> suddenly getting error messages spewed which is also no good.  IMO the
> convention of Linux drivers I've always reviewed is to print errors
> like this, so unless that changes my vote is to follow convention.
> 
> 
> > > 2. You now need a local variable "irq".  By putting the
> > > platform_get_irq() before the memory allocation you now can't store it
> > > directly in mas->irq.  We could try using "ret" as a temporary
> > > variable but that seems worse in this case since it'd be a bit
> > > fragile.
> > >
> > > 3. You don't get rid of any error labels / error handling so we don't
> > > really save any code
> > >
> > > When I tried this my diffstat says 8 lines added and 7 removed, so a
> > > net increase in LOC FWIW.  I'm relying in gmail so my patch will be
> > > whitespace-damaged (sigh), but you can find a clean one at:
> > >
> > > https://chromium.googlesource.com/chromiumos/third_party/kernel/+/e0325d618e209c22379e3a4269c14627b19243a8%5E%21/#F0
> > >
> > > ...the basic idea is this though:
> > >
> >
> > Thanks! Here's an updated patch that I haven't compile tested in any way
> > that hoists up the IO mapping part too, which shows that the 'se' local
> > variable is almost entirely useless.
> 
> Yeah, I'd be all for getting rid of "se".  I'm still not really seeing
> the benefit of hoisting all the rest of the stuff up.  Do you feel
> strongly about it?
> 
> In any case I think we've both said that all of our comments so far
> are just nits and could be addressed in a followup patch.  Unless Mark
> Brown wants these nits fixed ahead of time or has other changes he'd
> like, I don't think we're expecting another spin of this patch from
> Alok or Dilip, right?  We'd just expect them to post some follow-up
> patches after Mark lands it?
> 
> 

Yes this is all nits territory. I don't really care too much, but the
patch is already written, so might as well roll it all in and make
things shiny.

Time to get back to real work :P

Re: [PATCH 4/4] mm: zero-seek shrinkers

[Rik van Riel]

On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:

> These workloads also deal with tens of thousands of open files and
> use
> /proc for introspection, which ends up growing the proc_inode_cache
> to
> absurdly large sizes - again at the cost of valuable cache space,
> which isn't a reasonable trade-off, given that proc inodes can be
> re-created without involving the disk.
> 
> This patch implements a "zero-seek" setting for shrinkers that
> results
> in a target ratio of 0:1 between their objects and IO-backed
> caches. This allows such virtual caches to grow when memory is
> available (they do cache/avoid CPU work after all), but effectively
> disables them as soon as IO-backed objects are under pressure.
> 
> It then switches the shrinkers for procfs and sysfs metadata, as well
> as excess page cache shadow nodes, to the new zero-seek setting.

This patch looks like a great step in the right
direction, though I do not know whether it is
aggressive enough.

Given that internal slab fragmentation will
prevent the slab cache from returning a slab to
the VM if just one object in that slab is still
in use, there may well be workloads where we
should just put a hard cap on the number of
freeable items these slabs, and reclaim them
preemptively.

However, I do not know for sure, and this patch
seems like a big improvement over what we had
before, so ...

> Reported-by: Domas Mituzas 
> Signed-off-by: Johannes Weiner 

Reviewed-by: Rik van Riel 

Re: [PATCH 4/4] mm: zero-seek shrinkers

[Rik van Riel]

On Tue, 2018-10-09 at 14:47 -0400, Johannes Weiner wrote:

> These workloads also deal with tens of thousands of open files and
> use
> /proc for introspection, which ends up growing the proc_inode_cache
> to
> absurdly large sizes - again at the cost of valuable cache space,
> which isn't a reasonable trade-off, given that proc inodes can be
> re-created without involving the disk.
> 
> This patch implements a "zero-seek" setting for shrinkers that
> results
> in a target ratio of 0:1 between their objects and IO-backed
> caches. This allows such virtual caches to grow when memory is
> available (they do cache/avoid CPU work after all), but effectively
> disables them as soon as IO-backed objects are under pressure.
> 
> It then switches the shrinkers for procfs and sysfs metadata, as well
> as excess page cache shadow nodes, to the new zero-seek setting.

This patch looks like a great step in the right
direction, though I do not know whether it is
aggressive enough.

Given that internal slab fragmentation will
prevent the slab cache from returning a slab to
the VM if just one object in that slab is still
in use, there may well be workloads where we
should just put a hard cap on the number of
freeable items these slabs, and reclaim them
preemptively.

However, I do not know for sure, and this patch
seems like a big improvement over what we had
before, so ...

> Reported-by: Domas Mituzas 
> Signed-off-by: Johannes Weiner 

Reviewed-by: Rik van Riel 

Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME

[Leonardo Bras]

Thanks Finn, I will take a good look at that and try to use it in my build.

Thank you,
Leonardo Bras

On Wed, Oct 3, 2018 at 11:00 PM Finn Thain  wrote:
>
> On Wed, 3 Oct 2018, Leonardo Bras wrote:
>
> > Both ccache and distcc seem very interesting, I will take my time to
> > study them better as they can solve some situations I face. Thanks for
> > sharing!
> >
>
> You might also want to check out 'gcc -O0', 'gcc -fopt-info' and 'gcc
> --help=optimizers' etc to see if you can reduce the compute cost.
>
> To reduce IO cost, my build tests always use 'make O=/some/path' where
> /some/path is on a tmpfs mountpoint.
>
> HTH.
>
> --

Re: [PATCH v3 0/7] Remove errors building drivers/DRIVERNAME

[Leonardo Bras]

Thanks Finn, I will take a good look at that and try to use it in my build.

Thank you,
Leonardo Bras

On Wed, Oct 3, 2018 at 11:00 PM Finn Thain  wrote:
>
> On Wed, 3 Oct 2018, Leonardo Bras wrote:
>
> > Both ccache and distcc seem very interesting, I will take my time to
> > study them better as they can solve some situations I face. Thanks for
> > sharing!
> >
>
> You might also want to check out 'gcc -O0', 'gcc -fopt-info' and 'gcc
> --help=optimizers' etc to see if you can reduce the compute cost.
>
> To reduce IO cost, my build tests always use 'make O=/some/path' where
> /some/path is on a tmpfs mountpoint.
>
> HTH.
>
> --