[PATCH v2 3/3] misc: cxl: flash: Remove unused variable 'drc_index'

[Lee Jones]

Keeping the pointer increment though.

Fixes the following W=1 kernel build warning:

 drivers/misc/cxl/flash.c: In function ‘update_devicetree’:
 drivers/misc/cxl/flash.c:178:16: warning: variable ‘drc_index’ set but not 
used [-Wunused-but-set-variable]
 178 | __be32 *data, drc_index, phandle;
 | ^

Cc: Frederic Barrat 
Cc: Andrew Donnellan 
Cc: linuxppc-...@lists.ozlabs.org
Signed-off-by: Lee Jones 
---
Changelog:

v1 => v2:
 - Fix "flash.c:216:6: error: value computed is not used [-Werror=unused-value]"
   - ... as reported by Intel's Kernel Test Robot

drivers/misc/cxl/flash.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/misc/cxl/flash.c b/drivers/misc/cxl/flash.c
index cb9cca35a2263..5b93ff51d82a5 100644
--- a/drivers/misc/cxl/flash.c
+++ b/drivers/misc/cxl/flash.c
@@ -175,7 +175,7 @@ static int update_devicetree(struct cxl *adapter, s32 scope)
struct update_nodes_workarea *unwa;
u32 action, node_count;
int token, rc, i;
-   __be32 *data, drc_index, phandle;
+   __be32 *data, phandle;
char *buf;
 
token = rtas_token("ibm,update-nodes");
@@ -213,7 +213,7 @@ static int update_devicetree(struct cxl *adapter, s32 scope)
break;
case OPCODE_ADD:
/* nothing to do, just move pointer */
-   drc_index = *data++;
+   data++;
break;
}
}
-- 
2.25.1

Re: [PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0

[Ard Biesheuvel]

On Thu, 9 Jul 2020 at 09:50, 彭浩(Richard)  wrote:
>
> On Wed, 8 Jul 2020 at 13:03, 彭浩(Richard)  wrote:
> >>
> >>
> >> On Tue, Jul 07, 2020 at 07:46:08AM -0400, Peng Hao wrote:
> >> >> If plt_max_entries is 0, a warning is triggered.
> >> >> WARNING: CPU: 200 PID: 3000 at arch/arm64/kernel/module-plts.c:97 
> >> >> module_emit_plt_entry+0xa4/0x150
> >> >
> >> > Which kernel are you seeing this with? There is a PLT-related change in
> >> > for-next/core, and I'd like to rule if out if possible.
> >> >
> >> 5.6.0-rc3+
> >> >> Signed-off-by: Peng Hao 
> >> >> ---
> >> >>  arch/arm64/kernel/module-plts.c | 3 ++-
> >> >>  1 file changed, 2 insertions(+), 1 deletion(-)
> >> >>
> >> >> diff --git a/arch/arm64/kernel/module-plts.c 
> >> >> b/arch/arm64/kernel/module-plts.c
> >> >> index 65b08a74aec6..1868c9ac13f2 100644
> >> >> --- a/arch/arm64/kernel/module-plts.c
> >> >> +++ b/arch/arm64/kernel/module-plts.c
> >> >> @@ -79,7 +79,8 @@ u64 module_emit_plt_entry(struct module *mod, 
> >> >> Elf64_Shdr *sechdrs,
> >> >>  int i = pltsec->plt_num_entries;
> >> >>  int j = i - 1;
> >> >>  u64 val = sym->st_value + rela->r_addend;
> >> >> -
> >> >> +if (pltsec->plt_max_entries == 0)
> >> >> +return 0;
> >> >
> >> >Hmm, but if there aren't any PLTs then how do we end up here?
> >> >
> >> We also returned 0 when warning was triggered.
> >
> >That doesn't really answer the question.
> >
> >Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
> >relocation that operates on a b or bl instruction that is more than
> >128 megabytes away from its target.
> >
> My understanding is that a module that calls functions that are not part of 
> the module will use PLT.
> Plt_max_entries =0 May occur if a module does not depend on other module 
> functions.
>

A PLT slot is allocated for each b or bl instruction that refers to a
symbol that lives in a different section, either of the same module
(e.g., bl in .init calling into .text), of another module, or of the
core kernel.

I don't see how you end up with plt_max_entries in this case, though.
Are you sure you have CONFIG_RANDOMIZE_BASE enabled?

> >In module_frob_arch_sections(), we count all such relocations that
> >point to other sections, and allocate a PLT slot for each (and update
> >plt_max_entries) accordingly. So this means that the relocation in
> >question was disregarded, and this could happen for only two reasons:
> >- the branch instruction and its target are both in the same section,
> >in which case this section is *really* large,
> >- CONFIG_RANDOMIZE_BASE is disabled, but you are still ending up in a
> >situation where the modules are really far away from the core kernel
> >or from other modules.
> >
> >Do you have a lot of [large] modules loaded when this happens?
> I don’t think I have [large] modules.  I'll trace which module caused this 
> warning.

Yes please.

[PATCH] arm64: topology: Don't support AMU without cpufreq

[Viresh Kumar]

The commit cd0ed03a8903 ("arm64: use activity monitors for frequency
invariance"), mentions that:

  "if CONFIG_CPU_FREQ is not enabled, the use of counters is
   enabled on all CPUs only if all possible CPUs correctly support
   the necessary counters"

But that's not really true as validate_cpu_freq_invariance_counters()
fails if max_freq_hz is returned as 0 (in case there is no policy for
the CPU). And the AMUs won't be supported in that case.

Make the code reflect this reality.

Signed-off-by: Viresh Kumar 
---
 arch/arm64/kernel/topology.c | 19 +++
 1 file changed, 3 insertions(+), 16 deletions(-)

diff --git a/arch/arm64/kernel/topology.c b/arch/arm64/kernel/topology.c
index 0801a0f3c156..b7da372819fc 100644
--- a/arch/arm64/kernel/topology.c
+++ b/arch/arm64/kernel/topology.c
@@ -187,14 +187,13 @@ static int validate_cpu_freq_invariance_counters(int cpu)
return 0;
 }
 
-static inline bool
-enable_policy_freq_counters(int cpu, cpumask_var_t valid_cpus)
+static inline void update_amu_fie_cpus(int cpu, cpumask_var_t valid_cpus)
 {
struct cpufreq_policy *policy = cpufreq_cpu_get(cpu);
 
if (!policy) {
pr_debug("CPU%d: No cpufreq policy found.\n", cpu);
-   return false;
+   return;
}
 
if (cpumask_subset(policy->related_cpus, valid_cpus))
@@ -202,8 +201,6 @@ enable_policy_freq_counters(int cpu, cpumask_var_t 
valid_cpus)
   amu_fie_cpus);
 
cpufreq_cpu_put(policy);
-
-   return true;
 }
 
 static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
@@ -212,7 +209,6 @@ static DEFINE_STATIC_KEY_FALSE(amu_fie_key);
 static int __init init_amu_fie(void)
 {
cpumask_var_t valid_cpus;
-   bool have_policy = false;
int ret = 0;
int cpu;
 
@@ -228,18 +224,9 @@ static int __init init_amu_fie(void)
if (validate_cpu_freq_invariance_counters(cpu))
continue;
cpumask_set_cpu(cpu, valid_cpus);
-   have_policy |= enable_policy_freq_counters(cpu, valid_cpus);
+   update_amu_fie_cpus(cpu, valid_cpus);
}
 
-   /*
-* If we are not restricted by cpufreq policies, we only enable
-* the use of the AMU feature for FIE if all CPUs support AMU.
-* Otherwise, enable_policy_freq_counters has already enabled
-* policy cpus.
-*/
-   if (!have_policy && cpumask_equal(valid_cpus, cpu_present_mask))
-   cpumask_or(amu_fie_cpus, amu_fie_cpus, valid_cpus);
-
if (!cpumask_empty(amu_fie_cpus)) {
pr_info("CPUs[%*pbl]: counters will be used for FIE.",
cpumask_pr_args(amu_fie_cpus));
-- 
2.25.0.rc1.19.g042ed3e048af

Re: [PATCH 0/2] spi: spi-qcom-qspi: Avoid some per-transfer overhead

[Mukesh, Savaliya]

On 7/8/2020 1:46 AM, Douglas Anderson wrote:

Not to be confused with the similar series I posed for the _other_
Qualcomm SPI controller (spi-geni-qcom) [1], this one avoids the
overhead on the Quad SPI controller.

It's based atop the current Qualcomm tree including Rajendra's ("spi:
spi-qcom-qspi: Use OPP API to set clk/perf state").  As discussed in
individual patches, these could ideally land through the Qualcomm tree
with Mark's Ack.

Measuring:
* Before OPP / Interconnect patches reading all flash takes: ~3.4 seconds
* After OPP / Interconnect patches reading all flash takes: ~4.7 seconds
* After this patch reading all flash takes: ~3.3 seconds

[1] https://lore.kernel.org/r/20200702004509.2333554-1-diand...@chromium.org
[2] 
https://lore.kernel.org/r/1593769293-6354-2-git-send-email-rna...@codeaurora.org


Douglas Anderson (2):
   spi: spi-qcom-qspi: Avoid clock setting if not needed
   spi: spi-qcom-qspi: Set an autosuspend delay of 250 ms

  drivers/spi/spi-qcom-qspi.c | 45 -
  1 file changed, 35 insertions(+), 10 deletions(-)


Reviewed-by: Mukesh Kumar Savaliya 

Re: [PATCH v2 1/2] iommu: iommu_aux_at(de)tach_device() extension

[Lu Baolu]

On 2020/7/7 9:39, Lu Baolu wrote:

The hardware assistant vfio mediated device is a use case of iommu
aux-domain. The interactions between vfio/mdev and iommu during mdev
creation and passthr are:

- Create a group for mdev with iommu_group_alloc();
- Add the device to the group with
 group = iommu_group_alloc();
 if (IS_ERR(group))
 return PTR_ERR(group);

 ret = iommu_group_add_device(group, &mdev->dev);
 if (!ret)
 dev_info(&mdev->dev, "MDEV: group_id = %d\n",
  iommu_group_id(group));
- Allocate an aux-domain
 iommu_domain_alloc()
- Attach the aux-domain to the physical device from which the mdev is
   created.
 iommu_aux_attach_device()

In the whole process, an iommu group was allocated for the mdev and an
iommu domain was attached to the group, but the group->domain leaves
NULL. As the result, iommu_get_domain_for_dev() doesn't work anymore.

The iommu_get_domain_for_dev() is a necessary interface for device
drivers that want to support aux-domain. For example,

 struct iommu_domain *domain;
 struct device *dev = mdev_dev(mdev);
 unsigned long pasid;

 domain = iommu_get_domain_for_dev(dev);
 if (!domain)
 return -ENODEV;

 pasid = iommu_aux_get_pasid(domain, dev->parent);
 if (pasid == IOASID_INVALID)
 return -EINVAL;

  /* Program the device context with the PASID value */
  

This extends iommu_aux_at(de)tach_device() so that the users could pass
in an optional device pointer (struct device for vfio/mdev for example),
and the necessary check and data link could be done.

Fixes: a3a195929d40b ("iommu: Add APIs for multiple domains per device")
Cc: Robin Murphy 
Cc: Alex Williamson 
Signed-off-by: Lu Baolu 
---
  drivers/iommu/iommu.c   | 86 +
  drivers/vfio/vfio_iommu_type1.c |  5 +-
  include/linux/iommu.h   | 12 +++--
  3 files changed, 87 insertions(+), 16 deletions(-)

diff --git a/drivers/iommu/iommu.c b/drivers/iommu/iommu.c
index 1ed1e14a1f0c..435835058209 100644
--- a/drivers/iommu/iommu.c
+++ b/drivers/iommu/iommu.c
@@ -2723,26 +2723,92 @@ EXPORT_SYMBOL_GPL(iommu_dev_feature_enabled);
   * This should make us safe against a device being attached to a guest as a
   * whole while there are still pasid users on it (aux and sva).
   */
-int iommu_aux_attach_device(struct iommu_domain *domain, struct device *dev)
+int iommu_aux_attach_device(struct iommu_domain *domain,
+   struct device *phys_dev, struct device *dev)


I hit a lock issue during internal test. Will fix it in the next
version.

Best regards,
baolu


  {
-   int ret = -ENODEV;
+   struct iommu_group *group;
+   int ret;
  
-	if (domain->ops->aux_attach_dev)

-   ret = domain->ops->aux_attach_dev(domain, dev);
+   if (!domain->ops->aux_attach_dev ||
+   !iommu_dev_feature_enabled(phys_dev, IOMMU_DEV_FEAT_AUX))
+   return -ENODEV;
  
-	if (!ret)

-   trace_attach_device_to_domain(dev);
+   /* Bare use only. */
+   if (!dev) {
+   ret = domain->ops->aux_attach_dev(domain, phys_dev);
+   if (!ret)
+   trace_attach_device_to_domain(phys_dev);
+
+   return ret;
+   }
+
+   /*
+* The caller has created a made-up device (for example, vfio/mdev)
+* and allocated an iommu_group for user level direct assignment.
+* Make sure that the group has only single device and hasn't been
+* attached by any other domain.
+*/
+   group = iommu_group_get(dev);
+   if (!group)
+   return -ENODEV;
+
+   /*
+* Lock the group to make sure the device-count doesn't change while
+* we are attaching.
+*/
+   mutex_lock(&group->mutex);
+   ret = -EINVAL;
+   if ((iommu_group_device_count(group) != 1) || group->domain)
+   goto out_unlock;
+
+   ret = -EBUSY;
+   if (group->default_domain && group->domain != group->default_domain)
+   goto out_unlock;
+
+   ret = domain->ops->aux_attach_dev(domain, phys_dev);
+   if (!ret) {
+   trace_attach_device_to_domain(phys_dev);
+   group->domain = domain;
+   }
+
+out_unlock:
+   mutex_unlock(&group->mutex);
+   iommu_group_put(group);
  
  	return ret;

  }
  EXPORT_SYMBOL_GPL(iommu_aux_attach_device);
  
-void iommu_aux_detach_device(struct iommu_domain *domain, struct device *dev)

+void iommu_aux_detach_device(struct iommu_domain *domain,
+struct device *phys_dev, struct device *dev)
  {
-   if (domain->ops->aux_detach_dev) {
-   domain->ops->aux_detach_dev(domain, dev);
-   trace_detach_device_from_domain(dev);
+   struct iommu_group *group;
+
+   if (WARN_ON_ONCE(!domain

Re: [RFC PATCH v5 2/2] arm64: tlb: Use the TLBI RANGE feature in arm64

[Zhenyu Ye]

On 2020/7/9 2:24, Catalin Marinas wrote:
> On Wed, Jul 08, 2020 at 08:40:31PM +0800, Zhenyu Ye wrote:
>> Add __TLBI_VADDR_RANGE macro and rewrite __flush_tlb_range().
>>
>> In this patch, we only use the TLBI RANGE feature if the stride == PAGE_SIZE,
>> because when stride > PAGE_SIZE, usually only a small number of pages need
>> to be flushed and classic tlbi intructions are more effective.
> 
> Why are they more effective? I guess a range op would work on this as
> well, say unmapping a large THP range. If we ignore this stride ==
> PAGE_SIZE, it could make the code easier to read.
> 

OK, I will remove the stride == PAGE_SIZE here.

>> We can also use 'end - start < threshold number' to decide which way
>> to go, however, different hardware may have different thresholds, so
>> I'm not sure if this is feasible.
>>
>> Signed-off-by: Zhenyu Ye 
>> ---
>>  arch/arm64/include/asm/tlbflush.h | 104 ++
>>  1 file changed, 90 insertions(+), 14 deletions(-)
> 
> Could you please rebase these patches on top of the arm64 for-next/tlbi
> branch:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/arm64/linux.git for-next/tlbi
> 

OK, I will send a formal version patch of this series soon.

>>  
>> -if ((end - start) >= (MAX_TLBI_OPS * stride)) {
>> +if ((!cpus_have_const_cap(ARM64_HAS_TLBI_RANGE) &&
>> +(end - start) >= (MAX_TLBI_OPS * stride)) ||
>> +range_pages >= MAX_TLBI_RANGE_PAGES) {
>>  flush_tlb_mm(vma->vm_mm);
>>  return;
>>  }
> 
> Is there any value in this range_pages check here? What's the value of
> MAX_TLBI_RANGE_PAGES? If we have TLBI range ops, we make a decision here
> but without including the stride. Further down we use the stride to skip
> the TLBI range ops.
> 

MAX_TLBI_RANGE_PAGES is defined as __TLBI_RANGE_PAGES(31, 3), which is
decided by ARMv8.4 spec. The address range is determined by below formula:

[BADDR, BADDR + (NUM + 1) * 2^(5*SCALE + 1) * PAGESIZE)

Which has nothing to do with the stride.  After removing the stride ==
PAGE_SIZE below, there will be more clear.


>>  }
> 
> I think the algorithm is correct, though I need to work it out on a
> piece of paper.
> 
> The code could benefit from some comments (above the loop) on how the
> range is built and the right scale found.
> 

OK.

Thanks,
Zhenyu

Re: [PATCH] drm/aspeed: Call drm_fbdev_generic_setup after drm_dev_register

[Joel Stanley]

On Wed, 1 Jul 2020 at 09:10, Sam Ravnborg  wrote:
>
> Hi Guenter.
>
> On Tue, Jun 30, 2020 at 05:10:02PM -0700, Guenter Roeck wrote:
> > The following backtrace is seen when running aspeed G5 kernels.
> >
> > WARNING: CPU: 0 PID: 1 at drivers/gpu/drm/drm_fb_helper.c:2233 
> > drm_fbdev_generic_setup+0x138/0x198
> > aspeed_gfx 1e6e6000.display: Device has not been registered.
> > CPU: 0 PID: 1 Comm: swapper/0 Not tainted 5.8.0-rc3 #1
> > Hardware name: Generic DT based system
> > Backtrace:
> > [<8010d6d0>] (dump_backtrace) from [<8010d9b8>] (show_stack+0x20/0x24)
> > r7:0009 r6:6153 r5: r4:8119fa94
> > [<8010d998>] (show_stack) from [<80b8cb98>] (dump_stack+0xcc/0xec)
> > [<80b8cacc>] (dump_stack) from [<80123ef0>] (__warn+0xd8/0xfc)
> > r7:0009 r6:80e62ed0 r5: r4:974c3ccc
> > [<80123e18>] (__warn) from [<80123f98>] (warn_slowpath_fmt+0x84/0xc4)
> > r9:0009 r8:806a0140 r7:08b9 r6:80e62ed0 r5:80e631f8 r4:974c2000
> > [<80123f18>] (warn_slowpath_fmt) from [<806a0140>] 
> > (drm_fbdev_generic_setup+0x138/0x198)
> > r9:0001 r8:9758fc10 r7:9758fc00 r6: r5:0020 r4:9768a000
> > [<806a0008>] (drm_fbdev_generic_setup) from [<806d4558>] 
> > (aspeed_gfx_probe+0x204/0x32c)
> > r7:9758fc00 r6: r5: r4:9768a000
> > [<806d4354>] (aspeed_gfx_probe) from [<806dfca0>] 
> > (platform_drv_probe+0x58/0xa8)
> >
> > Since commit 1aed9509b29a6 ("drm/fb-helper: Remove return value from
> > drm_fbdev_generic_setup()"), drm_fbdev_generic_setup() must be called
> > after drm_dev_register() to avoid the warning. Do that.
> >
> > Fixes: 1aed9509b29a6 ("drm/fb-helper: Remove return value from 
> > drm_fbdev_generic_setup()")
> > Signed-off-by: Guenter Roeck 
>
> I thought we had this fixed already - but could not find the patch.
> Must have been another driver then.
>
> Acked-by: Sam Ravnborg 
>
> I assume Joel Stanley will pick up this patch.

I do not have the drm maintainer tools set up at the moment. Could one
of the other maintainers put this in the drm-misc tree?

Acked-by: Joel Stanley 

Cheers,

Joel

>
> Sam
>
> > ---
> >  drivers/gpu/drm/aspeed/aspeed_gfx_drv.c | 3 +--
> >  1 file changed, 1 insertion(+), 2 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c 
> > b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > index 6b27242b9ee3..bca3fcff16ec 100644
> > --- a/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > +++ b/drivers/gpu/drm/aspeed/aspeed_gfx_drv.c
> > @@ -173,8 +173,6 @@ static int aspeed_gfx_load(struct drm_device *drm)
> >
> >   drm_mode_config_reset(drm);
> >
> > - drm_fbdev_generic_setup(drm, 32);
> > -
> >   return 0;
> >  }
> >
> > @@ -225,6 +223,7 @@ static int aspeed_gfx_probe(struct platform_device 
> > *pdev)
> >   if (ret)
> >   goto err_unload;
> >
> > + drm_fbdev_generic_setup(&priv->drm, 32);
> >   return 0;
> >
> >  err_unload:
> > --
> > 2.17.1
> >
> > ___
> > dri-devel mailing list
> > dri-de...@lists.freedesktop.org
> > https://lists.freedesktop.org/mailman/listinfo/dri-devel

Re:[PATCH] arm64/module-plts: Consider the special case where plt_max_entries is 0

[Richard]

On Wed, 8 Jul 2020 at 13:03, 彭浩(Richard)  wrote:
>>
>>
>> On Tue, Jul 07, 2020 at 07:46:08AM -0400, Peng Hao wrote:
>> >> If plt_max_entries is 0, a warning is triggered.
>> >> WARNING: CPU: 200 PID: 3000 at arch/arm64/kernel/module-plts.c:97 
>> >> module_emit_plt_entry+0xa4/0x150
>> >
>> > Which kernel are you seeing this with? There is a PLT-related change in
>> > for-next/core, and I'd like to rule if out if possible.
>> >
>> 5.6.0-rc3+
>> >> Signed-off-by: Peng Hao 
>> >> ---
>> >>  arch/arm64/kernel/module-plts.c | 3 ++-
>> >>  1 file changed, 2 insertions(+), 1 deletion(-)
>> >>
>> >> diff --git a/arch/arm64/kernel/module-plts.c 
>> >> b/arch/arm64/kernel/module-plts.c
>> >> index 65b08a74aec6..1868c9ac13f2 100644
>> >> --- a/arch/arm64/kernel/module-plts.c
>> >> +++ b/arch/arm64/kernel/module-plts.c
>> >> @@ -79,7 +79,8 @@ u64 module_emit_plt_entry(struct module *mod, 
>> >> Elf64_Shdr *sechdrs,
>> >>  int i = pltsec->plt_num_entries;
>> >>  int j = i - 1;
>> >>  u64 val = sym->st_value + rela->r_addend;
>> >> -
>> >> +if (pltsec->plt_max_entries == 0)
>> >> +return 0;
>> >
>> >Hmm, but if there aren't any PLTs then how do we end up here?
>> >
>> We also returned 0 when warning was triggered.
>
>That doesn't really answer the question.
>
>Apparently, you are hitting a R_AARCH64_JUMP26 or R_AARCH64_CALL26
>relocation that operates on a b or bl instruction that is more than
>128 megabytes away from its target.
>
My understanding is that a module that calls functions that are not part of the 
module will use PLT.
Plt_max_entries =0 May occur if a module does not depend on other module 
functions.

>In module_frob_arch_sections(), we count all such relocations that
>point to other sections, and allocate a PLT slot for each (and update
>plt_max_entries) accordingly. So this means that the relocation in
>question was disregarded, and this could happen for only two reasons:
>- the branch instruction and its target are both in the same section,
>in which case this section is *really* large,
>- CONFIG_RANDOMIZE_BASE is disabled, but you are still ending up in a
>situation where the modules are really far away from the core kernel
>or from other modules.
>
>Do you have a lot of [large] modules loaded when this happens?
I don’t think I have [large] modules.  I'll trace which module caused this 
warning.
Thanks.

[PATCH v3] spi: use kthread_create_worker() helper

[Marek Szyprowski]

Use kthread_create_worker() helper to simplify the code. It uses
the kthread worker API the right way. It will eventually allow
to remove the FIXME in kthread_worker_fn() and add more consistency
checks in the future.

Reviewed-by: Petr Mladek 
Signed-off-by: Marek Szyprowski 
---
v3:
- rebased onto latest spi-next branch
---
 drivers/spi/spi.c   | 26 --
 include/linux/spi/spi.h |  6 ++
 2 files changed, 14 insertions(+), 18 deletions(-)

diff --git a/drivers/spi/spi.c b/drivers/spi/spi.c
index d4ba723a30da..1d7bba434225 100644
--- a/drivers/spi/spi.c
+++ b/drivers/spi/spi.c
@@ -1368,7 +1368,7 @@ static void __spi_pump_messages(struct spi_controller 
*ctlr, bool in_kthread)
 
/* If another context is idling the device then defer */
if (ctlr->idling) {
-   kthread_queue_work(&ctlr->kworker, &ctlr->pump_messages);
+   kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
return;
}
@@ -1382,7 +1382,7 @@ static void __spi_pump_messages(struct spi_controller 
*ctlr, bool in_kthread)
 
/* Only do teardown in the thread */
if (!in_kthread) {
-   kthread_queue_work(&ctlr->kworker,
+   kthread_queue_work(ctlr->kworker,
   &ctlr->pump_messages);
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
return;
@@ -1618,7 +1618,7 @@ static void spi_set_thread_rt(struct spi_controller *ctlr)
 
dev_info(&ctlr->dev,
"will run message pump with realtime priority\n");
-   sched_setscheduler(ctlr->kworker_task, SCHED_FIFO, ¶m);
+   sched_setscheduler(ctlr->kworker->task, SCHED_FIFO, ¶m);
 }
 
 static int spi_init_queue(struct spi_controller *ctlr)
@@ -1626,13 +1626,12 @@ static int spi_init_queue(struct spi_controller *ctlr)
ctlr->running = false;
ctlr->busy = false;
 
-   kthread_init_worker(&ctlr->kworker);
-   ctlr->kworker_task = kthread_run(kthread_worker_fn, &ctlr->kworker,
-"%s", dev_name(&ctlr->dev));
-   if (IS_ERR(ctlr->kworker_task)) {
-   dev_err(&ctlr->dev, "failed to create message pump task\n");
-   return PTR_ERR(ctlr->kworker_task);
+   ctlr->kworker = kthread_create_worker(0, dev_name(&ctlr->dev));
+   if (IS_ERR(ctlr->kworker)) {
+   dev_err(&ctlr->dev, "failed to create message pump kworker\n");
+   return PTR_ERR(ctlr->kworker);
}
+
kthread_init_work(&ctlr->pump_messages, spi_pump_messages);
 
/*
@@ -1716,7 +1715,7 @@ void spi_finalize_current_message(struct spi_controller 
*ctlr)
ctlr->cur_msg = NULL;
ctlr->cur_msg_prepared = false;
ctlr->fallback = false;
-   kthread_queue_work(&ctlr->kworker, &ctlr->pump_messages);
+   kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
 
trace_spi_message_done(mesg);
@@ -1742,7 +1741,7 @@ static int spi_start_queue(struct spi_controller *ctlr)
ctlr->cur_msg = NULL;
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
 
-   kthread_queue_work(&ctlr->kworker, &ctlr->pump_messages);
+   kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
 
return 0;
 }
@@ -1798,8 +1797,7 @@ static int spi_destroy_queue(struct spi_controller *ctlr)
return ret;
}
 
-   kthread_flush_worker(&ctlr->kworker);
-   kthread_stop(ctlr->kworker_task);
+   kthread_destroy_worker(ctlr->kworker);
 
return 0;
 }
@@ -1822,7 +1820,7 @@ static int __spi_queued_transfer(struct spi_device *spi,
 
list_add_tail(&msg->queue, &ctlr->queue);
if (!ctlr->busy && need_pump)
-   kthread_queue_work(&ctlr->kworker, &ctlr->pump_messages);
+   kthread_queue_work(ctlr->kworker, &ctlr->pump_messages);
 
spin_unlock_irqrestore(&ctlr->queue_lock, flags);
return 0;
diff --git a/include/linux/spi/spi.h b/include/linux/spi/spi.h
index 0e67a9a3a1d3..5fcf5da13fdb 100644
--- a/include/linux/spi/spi.h
+++ b/include/linux/spi/spi.h
@@ -358,8 +358,7 @@ static inline void spi_unregister_driver(struct spi_driver 
*sdrv)
  * @cleanup: frees controller-specific state
  * @can_dma: determine whether this controller supports DMA
  * @queued: whether this controller is providing an internal message queue
- * @kworker: thread struct for message pump
- * @kworker_task: pointer to task for message pump kworker thread
+ * @kworker: pointer to thread struct for message pump
  * @pump_messages: work struct for scheduling work to the message pump
  * @queue_lock: spinlock to syncronise access to message queue
  * @queue: message queue
@@ -593,8 +592,7 @@ struct spi_controller {
 * Over time we expect SPI drivers t

[PATCH] net: enetc: use eth_broadcast_addr() to assign broadcast

[Xu Wang]

This patch is to use eth_broadcast_addr() to assign broadcast address
insetad of memset().

Signed-off-by: Xu Wang 
---
 drivers/net/ethernet/freescale/enetc/enetc_qos.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/net/ethernet/freescale/enetc/enetc_qos.c 
b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
index fd3df19eaa32..6fc0c275306f 100644
--- a/drivers/net/ethernet/freescale/enetc/enetc_qos.c
+++ b/drivers/net/ethernet/freescale/enetc/enetc_qos.c
@@ -487,7 +487,7 @@ static int enetc_streamid_hw_set(struct enetc_ndev_priv 
*priv,
 
cbd.addr[0] = lower_32_bits(dma);
cbd.addr[1] = upper_32_bits(dma);
-   memset(si_data->dmac, 0xff, ETH_ALEN);
+   eth_broadcast_addr(si_data->dmac);
si_data->vid_vidm_tg =
cpu_to_le16(ENETC_CBDR_SID_VID_MASK
+ ((0x3 << 14) | ENETC_CBDR_SID_VIDM));
-- 
2.17.1

[PATCH] VIRTIO CORE AND NET DRIVERS: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 Documentation/devicetree/bindings/virtio/mmio.txt | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/devicetree/bindings/virtio/mmio.txt 
b/Documentation/devicetree/bindings/virtio/mmio.txt
index 21af30fbb81f..0a575f329f6e 100644
--- a/Documentation/devicetree/bindings/virtio/mmio.txt
+++ b/Documentation/devicetree/bindings/virtio/mmio.txt
@@ -1,6 +1,6 @@
 * virtio memory mapped device
 
-See http://ozlabs.org/~rusty/virtio-spec/ for more details.
+See https://ozlabs.org/~rusty/virtio-spec/ for more details.
 
 Required properties:
 
-- 
2.27.0

Re: [PATCH] Replace HTTP links with HTTPS ones: YAMA SECURITY MODULE

[Alexander A. Klimov]

Am 09.07.20 um 00:54 schrieb Kees Cook:

On Wed, Jul 08, 2020 at 08:22:03PM +0200, Alexander A. Klimov wrote:



Am 08.07.20 um 10:05 schrieb Kees Cook:

On Wed, Jul 08, 2020 at 09:33:46AM +0200, Alexander A. Klimov wrote:

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
If not .svg:
  For each line:
If doesn't contain `\bxmlns\b`:
  For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
  If both the HTTP and HTTPS versions
  return 200 OK and serve the same content:
Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
   Continuing my work started at 93431e0607e5.
   See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
   (Actually letting a shell for loop submit all this stuff for me.)

   If there are any URLs to be removed completely or at least not HTTPSified:
   Just clearly say so and I'll *undo my change*.

As written here...


I interpreted that as "any URLs [changed by this patch]". I wanted no
URLs you changed to be removed nor not HTTPSified.


   See also: https://lkml.org/lkml/2020/6/27/64


(You seem to be saying "any URLs [in the file]".)


   If there are any valid, but yet not changed URLs:
   See: https://lkml.org/lkml/2020/6/26/837


The URL I commented on was not valid and not changed by your patch.



   If you apply the patch, please let me know.


   Documentation/admin-guide/LSM/Yama.rst | 2 +-
   1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/Documentation/admin-guide/LSM/Yama.rst 
b/Documentation/admin-guide/LSM/Yama.rst
index d0a060de3973..64fd62507ae5 100644
--- a/Documentation/admin-guide/LSM/Yama.rst
+++ b/Documentation/admin-guide/LSM/Yama.rst
@@ -21,7 +21,7 @@ of their attack without resorting to user-assisted phishing.
   This is not a theoretical problem. SSH session hijacking
   (http://www.storm.net.nz/projects/7) and arbitrary code injection


This link is dead. It is likely best replaced by:

... I'd undo this change.


You sent me a patch to update URLs, gave me (seemingly) explicit
instructions about which things would cause you to undo individual
changes, none of which seemed to trigger, so I offered an improvement,
that would add another HTTPS URL -- which is entirely within your stated
desires to have "[one] commit ... per one thing [you've]i done" for
a patch where the Subject is literally "Replace HTTP links with HTTPS
ones", for which I suggested an improvement.


But as it's the only one here, just forget this patch.


You seem hostile to accepting feedback on how this patch could be
improved. It's one thing to use automation to help generate patches,
and I understand your apparent desires to keep it automated, but that
is not always how patch development turns out.

Your instructions appear to take a long way to just say "here's a patch,
take it or leave it" which seems pretty anti-collaborative to me.

No, no and no.

If you look up other discussions (especially the very first one) on such 
patches, you'll see that *I react to change requests with improved* 
(shortened) patches.


*I do them manually* and I've no problem with doing things manually, I 
just automate everything that is possible.


*I don't demand to accept my patches as-is.* The only thing I demand is 
letting me focus on one thing at a time.

https://lkml.org/lkml/2020/6/27/64
You requested reanimatig a dead link. That's a legit thing, but it's 
*another* thing. Another than (the yet not done task of mine of) just 
HTTPSifying URLs.


And as it's the only URL here, of course the whole patch makes no sense 
anymore. If I'd replace the URL as you said, I'd make a *new patch* with 
a *new title* and just send it --in-reply-to here. And my statement 
"just forget [the old] patch" would still stand.


Also IMAO in this particular case *I don't deserve* to be the author of 
the new patch as *you did all the work* for it – i.e. figured out the 
replacement URL.

[PATCH] [v3] PCI: rcar: Fix runtime PM imbalance on error

[Dinghao Liu]

pm_runtime_get_sync() increments the runtime PM usage counter even
the call returns an error code. Thus a corresponding decrement is
needed on the error handling path to keep the counter balanced.

Fixes: 0df6150e7ceb ("PCI: rcar: Use runtime PM to control controller
clock")

Signed-off-by: Dinghao Liu 
---

Changelog:

v2: - Remove unnecessary 'err_pm_put' label.
  Refine commit message.

v3: - Add Fixes tag.
  Rebase the patch on top of the latest kernel.
---
 drivers/pci/controller/pcie-rcar-host.c | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/drivers/pci/controller/pcie-rcar-host.c 
b/drivers/pci/controller/pcie-rcar-host.c
index d210a36561be..060c24f5221e 100644
--- a/drivers/pci/controller/pcie-rcar-host.c
+++ b/drivers/pci/controller/pcie-rcar-host.c
@@ -986,7 +986,7 @@ static int rcar_pcie_probe(struct platform_device *pdev)
err = pm_runtime_get_sync(pcie->dev);
if (err < 0) {
dev_err(pcie->dev, "pm_runtime_get_sync failed\n");
-   goto err_pm_disable;
+   goto err_pm_put;
}
 
err = rcar_pcie_get_resources(host);
@@ -1057,8 +1057,6 @@ static int rcar_pcie_probe(struct platform_device *pdev)
 
 err_pm_put:
pm_runtime_put(dev);
-
-err_pm_disable:
pm_runtime_disable(dev);
pci_free_resource_list(&host->resources);
 
-- 
2.17.1

Re: [PATCH] efi/libstub: EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER should not default to yes

[Ard Biesheuvel]

On Thu, 25 Jun 2020 at 19:11, Ard Biesheuvel  wrote:
>
> On Tue, 23 Jun 2020 at 17:09, Geert Uytterhoeven
>  wrote:
> >
> > EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER is deprecated, so it should not
> > be enabled by default.
> >
> > In light of commit 4da0b2b7e67524cc ("efi/libstub: Re-enable command
> > line initrd loading for x86"), keep the default for X86.
> >
> > Fixes: cf6b83664895a5c7 ("efi/libstub: Make initrd file loader 
> > configurable")
> > Signed-off-by: Geert Uytterhoeven 
>
> Queued as a fix, thanks.
>

I am going to have to postpone this one - it appears kernelCI uses
QEMU firmware that does not implement the new initrd loading protocol
yet, so I will need to get that fixed first.


> > ---
> >  drivers/firmware/efi/Kconfig | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/drivers/firmware/efi/Kconfig b/drivers/firmware/efi/Kconfig
> > index e6fc022bc87e03ab..56055c61904e49f4 100644
> > --- a/drivers/firmware/efi/Kconfig
> > +++ b/drivers/firmware/efi/Kconfig
> > @@ -127,7 +127,7 @@ config EFI_ARMSTUB_DTB_LOADER
> >  config EFI_GENERIC_STUB_INITRD_CMDLINE_LOADER
> > bool "Enable the command line initrd loader" if !X86
> > depends on EFI_STUB && (EFI_GENERIC_STUB || X86)
> > -   default y
> > +   default y if X86
> > help
> >   Select this config option to add support for the initrd= command
> >   line parameter, allowing an initrd that resides on the same volume
> > --
> > 2.17.1
> >

Re: [PATCH v4 04/11] mm/hugetlb: make hugetlb migration callback CMA aware

[Michal Hocko]

On Wed 08-07-20 09:41:06, Michal Hocko wrote:
> On Wed 08-07-20 16:16:02, Joonsoo Kim wrote:
> > On Tue, Jul 07, 2020 at 01:22:31PM +0200, Vlastimil Babka wrote:
> > > On 7/7/20 9:44 AM, js1...@gmail.com wrote:
> > > > From: Joonsoo Kim 
> > > > 
> > > > new_non_cma_page() in gup.c which try to allocate migration target page
> > > > requires to allocate the new page that is not on the CMA area.
> > > > new_non_cma_page() implements it by removing __GFP_MOVABLE flag.  This 
> > > > way
> > > > works well for THP page or normal page but not for hugetlb page.
> > > > 
> > > > hugetlb page allocation process consists of two steps.  First is 
> > > > dequeing
> > > > from the pool.  Second is, if there is no available page on the queue,
> > > > allocating from the page allocator.
> > > > 
> > > > new_non_cma_page() can control allocation from the page allocator by
> > > > specifying correct gfp flag.  However, dequeing cannot be controlled 
> > > > until
> > > > now, so, new_non_cma_page() skips dequeing completely.  It is a 
> > > > suboptimal
> > > > since new_non_cma_page() cannot utilize hugetlb pages on the queue so 
> > > > this
> > > > patch tries to fix this situation.
> > > > 
> > > > This patch makes the deque function on hugetlb CMA aware and skip CMA
> > > > pages if newly added skip_cma argument is passed as true.
> > > 
> > > Hmm, can't you instead change dequeue_huge_page_node_exact() to test the 
> > > PF_
> > > flag and avoid adding bool skip_cma everywhere?
> > 
> > Okay! Please check following patch.
> > > 
> > > I think that's what Michal suggested [1] except he said "the code already 
> > > does
> > > by memalloc_nocma_{save,restore} API". It needs extending a bit though, 
> > > AFAICS.
> > > __gup_longterm_locked() indeed does the save/restore, but restore comes 
> > > before
> > > check_and_migrate_cma_pages() and thus new_non_cma_page() is called, so an
> > > adjustment is needed there, but that's all?
> > > 
> > > Hm the adjustment should be also done because save/restore is done around
> > > __get_user_pages_locked(), but check_and_migrate_cma_pages() also calls
> > > __get_user_pages_locked(), and that call not being between nocma save and
> > > restore is thus also a correctness issue?
> > 
> > Simply, I call memalloc_nocma_{save,restore} in new_non_cma_page(). It
> > would not cause any problem.
> 
> I believe a proper fix is the following. The scope is really defined for
> FOLL_LONGTERM pins and pushing it inside check_and_migrate_cma_pages
> will solve the problem as well but it imho makes more sense to do it in
> the caller the same way we do for any others. 
> 
> Fixes: 9a4e9f3b2d73 ("mm: update get_user_pages_longterm to migrate pages 
> allocated from CMA region")
> 
> I am not sure this is worth backporting to stable yet.

Should I post it as a separate patch do you plan to include this into your next 
version?

> 
> diff --git a/mm/gup.c b/mm/gup.c
> index de9e36262ccb..75980dd5a2fc 100644
> --- a/mm/gup.c
> +++ b/mm/gup.c
> @@ -1794,7 +1794,6 @@ static long __gup_longterm_locked(struct task_struct 
> *tsk,
>vmas_tmp, NULL, gup_flags);
>  
>   if (gup_flags & FOLL_LONGTERM) {
> - memalloc_nocma_restore(flags);
>   if (rc < 0)
>   goto out;
>  
> @@ -1802,11 +1801,13 @@ static long __gup_longterm_locked(struct task_struct 
> *tsk,
>   for (i = 0; i < rc; i++)
>   put_page(pages[i]);
>   rc = -EOPNOTSUPP;
> + memalloc_nocma_restore(flags);
>   goto out;
>   }
>  
>   rc = check_and_migrate_cma_pages(tsk, mm, start, rc, pages,
>vmas_tmp, gup_flags);
> + memalloc_nocma_restore(flags);
>   }
>  
>  out:
> -- 
> Michal Hocko
> SUSE Labs

-- 
Michal Hocko
SUSE Labs

general protection fault in khugepaged

[syzbot]

Hello,

syzbot found the following crash on:

HEAD commit:e44f65fd xen-netfront: remove redundant assignment to vari..
git tree:   net-next
console output: https://syzkaller.appspot.com/x/log.txt?x=15de54a710
kernel config:  https://syzkaller.appspot.com/x/.config?x=829871134ca5e230
dashboard link: https://syzkaller.appspot.com/bug?extid=ed318e8b790ca72c5ad0
compiler:   gcc (GCC) 10.1.0-syz 20200507
syz repro:  https://syzkaller.appspot.com/x/repro.syz?x=113406a710
C reproducer:   https://syzkaller.appspot.com/x/repro.c?x=175597d310

IMPORTANT: if you fix the bug, please add the following tag to the commit:
Reported-by: syzbot+ed318e8b790ca72c5...@syzkaller.appspotmail.com

general protection fault, probably for non-canonical address 
0xdc00:  [#1] PREEMPT SMP KASAN
KASAN: null-ptr-deref in range [0x-0x0007]
CPU: 1 PID: 1155 Comm: khugepaged Not tainted 5.8.0-rc2-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
RIP: 0010:anon_vma_lock_write include/linux/rmap.h:120 [inline]
RIP: 0010:collapse_huge_page mm/khugepaged.c:1110 [inline]
RIP: 0010:khugepaged_scan_pmd mm/khugepaged.c:1349 [inline]
RIP: 0010:khugepaged_scan_mm_slot mm/khugepaged.c:2110 [inline]
RIP: 0010:khugepaged_do_scan mm/khugepaged.c:2193 [inline]
RIP: 0010:khugepaged+0x3bba/0x5a10 mm/khugepaged.c:2238
Code: 01 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 
fa 0f 00 00 48 8b 9b 88 00 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 d4 
0f 00 00 48 8b 3b 48 83 c7 08 e8 9f ff 30
RSP: 0018:c90004be7c80 EFLAGS: 00010246
RAX:  RBX:  RCX: 81a72d8b
RDX: 8880a69d8100 RSI: 81b7606b RDI: 88809f0577c0
RBP:  R08:  R09: 8881ff213a7f
R10: 0080 R11:  R12: 8aae6110
R13: c90004be7de0 R14: dc00 R15: 2000
FS:  () GS:8880ae70() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2:  CR3: 0001fe0cf000 CR4: 001406e0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400
Call Trace:
 kthread+0x3b5/0x4a0 kernel/kthread.c:291
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:293
Modules linked in:
---[ end trace f1f03dbd2ea0777e ]---
RIP: 0010:anon_vma_lock_write include/linux/rmap.h:120 [inline]
RIP: 0010:collapse_huge_page mm/khugepaged.c:1110 [inline]
RIP: 0010:khugepaged_scan_pmd mm/khugepaged.c:1349 [inline]
RIP: 0010:khugepaged_scan_mm_slot mm/khugepaged.c:2110 [inline]
RIP: 0010:khugepaged_do_scan mm/khugepaged.c:2193 [inline]
RIP: 0010:khugepaged+0x3bba/0x5a10 mm/khugepaged.c:2238
Code: 01 00 00 48 8d bb 88 00 00 00 48 89 f8 48 c1 e8 03 42 80 3c 30 00 0f 85 
fa 0f 00 00 48 8b 9b 88 00 00 00 48 89 d8 48 c1 e8 03 <42> 80 3c 30 00 0f 85 d4 
0f 00 00 48 8b 3b 48 83 c7 08 e8 9f ff 30
RSP: 0018:c90004be7c80 EFLAGS: 00010246
RAX:  RBX:  RCX: 81a72d8b
RDX: 8880a69d8100 RSI: 81b7606b RDI: 88809f0577c0
RBP:  R08:  R09: 8881ff213a7f
R10: 0080 R11:  R12: 8aae6110
R13: c90004be7de0 R14: dc00 R15: 2000
FS:  () GS:8880ae60() knlGS:
CS:  0010 DS:  ES:  CR0: 80050033
CR2: 004c00c8 CR3: 0001f7ac5000 CR4: 001406f0
DR0:  DR1:  DR2: 
DR3:  DR6: fffe0ff0 DR7: 0400


---
This bug is generated by a bot. It may contain errors.
See https://goo.gl/tpsmEJ for more information about syzbot.
syzbot engineers can be reached at syzkal...@googlegroups.com.

syzbot will keep track of this bug report. See:
https://goo.gl/tpsmEJ#status for how to communicate with syzbot.
syzbot can test patches for this bug, for details see:
https://goo.gl/tpsmEJ#testing-patches

Re: [V2 PATCH] usb: mtu3: fix NULL pointer dereference

[Felipe Balbi]

Hi,

Chunfeng Yun  writes:
>> > @@ -373,8 +380,8 @@ static int mtu3_gadget_dequeue(struct usb_ep *ep, 
>> > struct usb_request *req)
>> >   */
>> >  static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, int value)
>> >  {
>> > -  struct mtu3_ep *mep = to_mtu3_ep(ep);
>> > -  struct mtu3 *mtu = mep->mtu;
>> > +  struct mtu3_ep *mep;
>> > +  struct mtu3 *mtu;
>> >struct mtu3_request *mreq;
>> >unsigned long flags;
>> >int ret = 0;
>> > @@ -382,6 +389,9 @@ static int mtu3_gadget_ep_set_halt(struct usb_ep *ep, 
>> > int value)
>> >if (!ep)
>> >return -EINVAL;
>> 
>> Same here, how can that ever happen?
> Maybe when the class driver has something wrong:)
>
> You mean it's better to remove these unnecessary checks?

if we need those checks, I'd rather have them at a central location,
such as udc/core.c. But, as Greg mentioned, the kernel doesn't call
these with NULL pointers.

-- 
balbi


signature.asc
Description: PGP signature

Re: [V2 PATCH] usb: mtu3: fix NULL pointer dereference

[Felipe Balbi]

Chunfeng Yun  writes:

> Some pointers are dereferenced before successful checks.
>
> Reported-by: Markus Elfring 
> Signed-off-by: Chunfeng Yun 

do you need a Fixes tag here? Perhaps a Cc stable too?

-- 
balbi


signature.asc
Description: PGP signature

Re: [PATCH v6 4/7] pidfd: Replace open-coded partial receive_fd()

[Kees Cook]

On Tue, Jul 07, 2020 at 02:22:20PM +0200, Christian Brauner wrote:
> So while the patch is correct it leaves 5.6 and 5.7 with a bug in the
> pidfd_getfd() implementation and that just doesn't seem right. I'm
> wondering whether we should introduce:
> 
> void sock_update(struct file *file)
> {
>   struct socket *sock;
>   int error;
> 
>   sock = sock_from_file(file, &error);
>   if (sock) {
>   sock_update_netprioidx(&sock->sk->sk_cgrp_data);
>   sock_update_classid(&sock->sk->sk_cgrp_data);
>   }
> }
> 
> and switch pidfd_getfd() over to:
> 
> diff --git a/kernel/pid.c b/kernel/pid.c
> index f1496b757162..c26bba822be3 100644
> --- a/kernel/pid.c
> +++ b/kernel/pid.c
> @@ -642,10 +642,12 @@ static int pidfd_getfd(struct pid *pid, int fd)
> }
> 
> ret = get_unused_fd_flags(O_CLOEXEC);
> -   if (ret < 0)
> +   if (ret < 0) {
> fput(file);
> -   else
> +   } else {
> +   sock_update(file);
> fd_install(ret, file);
> +   }
> 
> return ret;
>  }
> 
> first thing in the series and then all of the other patches on top of it
> so that we can Cc stable for this and that can get it backported to 5.6,
> 5.7, and 5.8.
> 
> Alternatively, I can make this a separate bugfix patch series which I'll
> send upstream soonish. Or we have specific patches just for 5.6, 5.7,
> and 5.8. Thoughts?

Okay, I looked at hch's clean-ups again and I'm reminded why they
don't make great -stable material. :) The compat bug (also missing the
sock_update()) needs a similar fix (going back to 3.6...), so, yeah,
for ease of backport, probably an explicit sock_update() implementation
(with compat and native scm using it), and a second patch for pidfd.

Let me see what I looks best...

-- 
Kees Cook

[PATCH v4] rtc: rtc-ds1374: wdt: Use watchdog core for watchdog part

[陳昭勳]

Let ds1374 watchdog use watchdog core functions. It also includes
improving watchdog timer setting and nowayout, and just uses ioctl()
of watchdog core.

Signed-off-by: Johnson Chen 
---
v3->v4:
- Fix coding styles 
- Remove dev_info() in ds1374_wdt_settimeout()
- Fix missing error check

v2->v3:
- Fix a problem reported by WATCHDOG_CORE if WATCHDOG
- Remove save_client
- Let wdt_margin be 0 for watchdog_init_timeout()
- Use dev_info() rather than pr_info()
- Avoid more strings in this driver

v1->v2:
- Use ds1374_wdt_settimeout() before registering the watchdog
- Remove watchdog_unregister_device() because devm_watchdog_register_device() 
is used
- Remove ds1374_wdt_ping()
- TIMER_MARGIN_MAX to 4095 for 24-bit value
- Keep wdt_margin
- Fix coding styles

 drivers/rtc/Kconfig  |   1 +
 drivers/rtc/rtc-ds1374.c | 258 +--
 2 files changed, 62 insertions(+), 197 deletions(-)

diff --git a/drivers/rtc/Kconfig b/drivers/rtc/Kconfig
index b54d87d45c89..c25d51f35f0c 100644
--- a/drivers/rtc/Kconfig
+++ b/drivers/rtc/Kconfig
@@ -282,6 +282,7 @@ config RTC_DRV_DS1374
 config RTC_DRV_DS1374_WDT
bool "Dallas/Maxim DS1374 watchdog timer"
depends on RTC_DRV_DS1374
+   select WATCHDOG_CORE if WATCHDOG
help
  If you say Y here you will get support for the
  watchdog timer in the Dallas Semiconductor DS1374
diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
index 9c51a12cf70f..c71065d26cd2 100644
--- a/drivers/rtc/rtc-ds1374.c
+++ b/drivers/rtc/rtc-ds1374.c
@@ -46,6 +46,7 @@
 #define DS1374_REG_WDALM2  0x06
 #define DS1374_REG_CR  0x07 /* Control */
 #define DS1374_REG_CR_AIE  0x01 /* Alarm Int. Enable */
+#define DS1374_REG_CR_WDSTR0x08 /* 1=INT, 0=RST */
 #define DS1374_REG_CR_WDALM0x20 /* 1=Watchdog, 0=Alarm */
 #define DS1374_REG_CR_WACE 0x40 /* WD/Alarm counter enable */
 #define DS1374_REG_SR  0x08 /* Status */
@@ -71,7 +72,9 @@ struct ds1374 {
struct i2c_client *client;
struct rtc_device *rtc;
struct work_struct work;
-
+#ifdef CONFIG_RTC_DRV_DS1374_WDT
+   struct watchdog_device wdt;
+#endif
/* The mutex protects alarm operations, and prevents a race
 * between the enable_irq() in the workqueue and the free_irq()
 * in the remove function.
@@ -369,238 +372,98 @@ static const struct rtc_class_ops ds1374_rtc_ops = {
  *
  *
  */
-static struct i2c_client *save_client;
 /* Default margin */
-#define WD_TIMO 131762
+#define TIMER_MARGIN_DEFAULT   32
+#define TIMER_MARGIN_MIN   1
+#define TIMER_MARGIN_MAX   4095 /* 24-bit value */
 
 #define DRV_NAME "DS1374 Watchdog"
 
-static int wdt_margin = WD_TIMO;
-static unsigned long wdt_is_open;
+static int wdt_margin;
 module_param(wdt_margin, int, 0);
 MODULE_PARM_DESC(wdt_margin, "Watchdog timeout in seconds (default 32s)");
 
+static bool nowayout = WATCHDOG_NOWAYOUT;
+module_param(nowayout, bool, 0);
+MODULE_PARM_DESC(nowayout, "Watchdog cannot be stopped once started (default ="
+   __MODULE_STRING(WATCHDOG_NOWAYOUT)")");
+
 static const struct watchdog_info ds1374_wdt_info = {
.identity   = "DS1374 WTD",
.options= WDIOF_SETTIMEOUT | WDIOF_KEEPALIVEPING |
WDIOF_MAGICCLOSE,
 };
 
-static int ds1374_wdt_settimeout(unsigned int timeout)
+static int ds1374_wdt_settimeout(struct watchdog_device *wdt, unsigned int 
timeout)
 {
-   int ret = -ENOIOCTLCMD;
-   int cr;
+   struct ds1374 *ds1374 = watchdog_get_drvdata(wdt);
+   struct i2c_client *client = ds1374->client;
+   int ret, cr;
 
-   ret = cr = i2c_smbus_read_byte_data(save_client, DS1374_REG_CR);
-   if (ret < 0)
-   goto out;
+   wdt->timeout = timeout;
+
+   cr = i2c_smbus_read_byte_data(client, DS1374_REG_CR);
+   if (cr < 0)
+   return cr;
 
/* Disable any existing watchdog/alarm before setting the new one */
cr &= ~DS1374_REG_CR_WACE;
 
-   ret = i2c_smbus_write_byte_data(save_client, DS1374_REG_CR, cr);
+   ret = i2c_smbus_write_byte_data(client, DS1374_REG_CR, cr);
if (ret < 0)
-   goto out;
+   return ret;
 
/* Set new watchdog time */
-   ret = ds1374_write_rtc(save_client, timeout, DS1374_REG_WDALM0, 3);
-   if (ret) {
-   pr_info("couldn't set new watchdog time\n");
-   goto out;
-   }
+   timeout = timeout * 4096;
+   ret = ds1374_write_rtc(client, timeout, DS1374_REG_WDALM0, 3);
+   if (ret)
+   return ret;
 
/* Enable watchdog timer */
cr |= DS1374_REG_CR_WACE | DS1374_REG_CR_WDALM;
+   cr &= ~DS1374_REG_CR_WDSTR;/* for RST PIN */
cr &= ~DS1374_REG_CR_AIE;
 
-   ret = i2c_smbus_write_byte_data(save_client, DS1374_REG_CR, cr);
+   ret =

Re: Re: [PATCH] [v2] PCI: rcar: Fix runtime PM imbalance on error

[dinghao . liu]

> On Sun, Jun 07, 2020 at 05:31:33PM +0800, Dinghao Liu wrote:
> > pm_runtime_get_sync() increments the runtime PM usage counter even
> > the call returns an error code. Thus a corresponding decrement is
> > needed on the error handling path to keep the counter balanced.
> > 
> > Signed-off-by: Dinghao Liu 
> > ---
> > 
> > Changelog:
> > 
> > v2: - Remove unnecessary 'err_pm_put' label.
> >   Refine commit message.
> > ---
> >  drivers/pci/controller/pcie-rcar.c | 6 ++
> >  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> Can you rebase it on top of v5.8-rc1 and resend it with Yoshihiro's tags
> please ?
> 

Sure, I will resend it soon.

Regards,
Dinghao

[PATCH v4 2/2] Add Intel LGM soc DMA support.

[Amireddy Mallikarjuna reddy]

Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.

The main function of the DMA controller is the transfer of data from/to any
DPlus compliant peripheral to/from the memory. A memory to memory copy
capability can also be configured.

This ldma driver is used for configure the device and channnels for data
and control paths.

Signed-off-by: Amireddy Mallikarjuna reddy 
---
v1:
- Initial version.

v2:
- Fix device tree bot issues, correspondign driver changes done.
- Fix kerntel test robot warnings.
  
  >> drivers/dma/lgm/lgm-dma.c:729:5: warning: no previous prototype for 
function 'intel_dma_chan_desc_cfg' [-Wmissing-prototypes]
  int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
  ^
  drivers/dma/lgm/lgm-dma.c:729:1: note: declare 'static' if the function is 
not intended to be used outside of this translation unit
  int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
  ^
  static
  1 warning generated.

  vim +/intel_dma_chan_desc_cfg +729 drivers/dma/lgm/lgm-dma.c

728
  > 729 int intel_dma_chan_desc_cfg(struct dma_chan *chan, dma_addr_t desc_base,
730 int desc_num)
731 {
732 return ldma_chan_desc_cfg(to_ldma_chan(chan), desc_base, 
desc_num);
733 }
734 EXPORT_SYMBOL_GPL(intel_dma_chan_desc_cfg);
735

   Reported-by: kernel test robot 
   ---

v3:
- Fix smatch warning.
  
  smatch warnings:
  drivers/dma/lgm/lgm-dma.c:1306 ldma_cfg_init() error: uninitialized symbol 
'ret'.

  Reported-by: kernel test robot 
  Reported-by: Dan Carpenter 
  

v4:
- Address Thomas Langer comments in dtbinding and corresponding driver side 
changes.
---
 drivers/dma/Kconfig |2 +
 drivers/dma/Makefile|1 +
 drivers/dma/lgm/Kconfig |9 +
 drivers/dma/lgm/Makefile|2 +
 drivers/dma/lgm/lgm-dma.c   | 1941 +++
 include/linux/dma/lgm_dma.h |   27 +
 6 files changed, 1982 insertions(+)
 create mode 100644 drivers/dma/lgm/Kconfig
 create mode 100644 drivers/dma/lgm/Makefile
 create mode 100644 drivers/dma/lgm/lgm-dma.c
 create mode 100644 include/linux/dma/lgm_dma.h

diff --git a/drivers/dma/Kconfig b/drivers/dma/Kconfig
index de41d7928bff..caeaf12fd524 100644
--- a/drivers/dma/Kconfig
+++ b/drivers/dma/Kconfig
@@ -737,6 +737,8 @@ source "drivers/dma/ti/Kconfig"
 
 source "drivers/dma/fsl-dpaa2-qdma/Kconfig"
 
+source "drivers/dma/lgm/Kconfig"
+
 # clients
 comment "DMA Clients"
depends on DMA_ENGINE
diff --git a/drivers/dma/Makefile b/drivers/dma/Makefile
index e60f81331d4c..0b899b076f4e 100644
--- a/drivers/dma/Makefile
+++ b/drivers/dma/Makefile
@@ -83,6 +83,7 @@ obj-$(CONFIG_XGENE_DMA) += xgene-dma.o
 obj-$(CONFIG_ZX_DMA) += zx_dma.o
 obj-$(CONFIG_ST_FDMA) += st_fdma.o
 obj-$(CONFIG_FSL_DPAA2_QDMA) += fsl-dpaa2-qdma/
+obj-$(CONFIG_INTEL_LDMA) += lgm/
 
 obj-y += mediatek/
 obj-y += qcom/
diff --git a/drivers/dma/lgm/Kconfig b/drivers/dma/lgm/Kconfig
new file mode 100644
index ..bdb5b0d91afb
--- /dev/null
+++ b/drivers/dma/lgm/Kconfig
@@ -0,0 +1,9 @@
+# SPDX-License-Identifier: GPL-2.0-only
+config INTEL_LDMA
+   bool "Lightning Mountain centralized low speed DMA and high speed DMA 
controllers"
+   select DMA_ENGINE
+   select DMA_VIRTUAL_CHANNELS
+   help
+ Enable support for intel Lightning Mountain SOC DMA controllers.
+ These controllers provide DMA capabilities for a variety of on-chip
+ devices such as SSC, HSNAND and GSWIP.
diff --git a/drivers/dma/lgm/Makefile b/drivers/dma/lgm/Makefile
new file mode 100644
index ..f318a8eff464
--- /dev/null
+++ b/drivers/dma/lgm/Makefile
@@ -0,0 +1,2 @@
+# SPDX-License-Identifier: GPL-2.0
+obj-$(CONFIG_INTEL_LDMA)   += lgm-dma.o
diff --git a/drivers/dma/lgm/lgm-dma.c b/drivers/dma/lgm/lgm-dma.c
new file mode 100644
index ..91c0a28fe8fb
--- /dev/null
+++ b/drivers/dma/lgm/lgm-dma.c
@@ -0,0 +1,1941 @@
+// SPDX-License-Identifier: GPL-2.0
+/*
+ * Lightning Mountain centralized low speed and high speed DMA controller 
driver
+ *
+ * Copyright (c) 2016 ~ 2020 Intel Corporation.
+ */
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+#include "../dmaengine.h"
+#include "../virt-dma.h"
+
+#define DRIVER_NAME"lgm-ldma"
+
+#define DMA_ID 0x0008
+#define DMA_ID_REV GENMASK(7, 0)
+#define DMA_ID_PNR GENMASK(19, 16)
+#define DMA_ID_CHNRGENMASK(26, 20)
+#define DMA_ID_DW_128B BIT(27)
+#define DMA_ID_AW_36B  BIT(28)
+#define DMA_VE

[PATCH] SONICS SILICON BACKPLANE DRIVER (SSB): Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 Continuing my work started at 93431e0607e5.
 See also: git log --oneline '--author=Alexander A. Klimov 
' v5.7..master
 (Actually letting a shell for loop submit all this stuff for me.)

 If there are any URLs to be removed completely or at least not HTTPSified:
 Just clearly say so and I'll *undo my change*.
 See also: https://lkml.org/lkml/2020/6/27/64

 If there are any valid, but yet not changed URLs:
 See: https://lkml.org/lkml/2020/6/26/837

 If you apply the patch, please let me know.


 drivers/ssb/driver_chipcommon.c | 4 ++--
 drivers/ssb/driver_chipcommon_pmu.c | 2 +-
 drivers/ssb/sprom.c | 2 +-
 3 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/ssb/driver_chipcommon.c b/drivers/ssb/driver_chipcommon.c
index 3861cb659cb9..85542bfd7715 100644
--- a/drivers/ssb/driver_chipcommon.c
+++ b/drivers/ssb/driver_chipcommon.c
@@ -238,7 +238,7 @@ static void chipco_powercontrol_init(struct ssb_chipcommon 
*cc)
}
 }
 
-/* http://bcm-v4.sipsolutions.net/802.11/PmuFastPwrupDelay */
+/* https://bcm-v4.sipsolutions.net/802.11/PmuFastPwrupDelay */
 static u16 pmu_fast_powerup_delay(struct ssb_chipcommon *cc)
 {
struct ssb_bus *bus = cc->dev->bus;
@@ -255,7 +255,7 @@ static u16 pmu_fast_powerup_delay(struct ssb_chipcommon *cc)
}
 }
 
-/* http://bcm-v4.sipsolutions.net/802.11/ClkctlFastPwrupDelay */
+/* https://bcm-v4.sipsolutions.net/802.11/ClkctlFastPwrupDelay */
 static void calc_fast_powerup_delay(struct ssb_chipcommon *cc)
 {
struct ssb_bus *bus = cc->dev->bus;
diff --git a/drivers/ssb/driver_chipcommon_pmu.c 
b/drivers/ssb/driver_chipcommon_pmu.c
index 0f60e90ded26..888069e10659 100644
--- a/drivers/ssb/driver_chipcommon_pmu.c
+++ b/drivers/ssb/driver_chipcommon_pmu.c
@@ -513,7 +513,7 @@ static void ssb_pmu_resources_init(struct ssb_chipcommon 
*cc)
chipco_write32(cc, SSB_CHIPCO_PMU_MAXRES_MSK, max_msk);
 }
 
-/* http://bcm-v4.sipsolutions.net/802.11/SSB/PmuInit */
+/* https://bcm-v4.sipsolutions.net/802.11/SSB/PmuInit */
 void ssb_pmu_init(struct ssb_chipcommon *cc)
 {
u32 pmucap;
diff --git a/drivers/ssb/sprom.c b/drivers/ssb/sprom.c
index 42d620cee8a9..7cd553127861 100644
--- a/drivers/ssb/sprom.c
+++ b/drivers/ssb/sprom.c
@@ -186,7 +186,7 @@ int ssb_fill_sprom_with_fallback(struct ssb_bus *bus, 
struct ssb_sprom *out)
return get_fallback_sprom(bus, out);
 }
 
-/* http://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable */
+/* https://bcm-v4.sipsolutions.net/802.11/IsSpromAvailable */
 bool ssb_is_sprom_available(struct ssb_bus *bus)
 {
/* status register only exists on chipcomon rev >= 11 and we need check
-- 
2.27.0

Re: [RFC PATCH 00/22] Enhance VHOST to enable SoC-to-SoC communication

[Jason Wang]

On 2020/7/8 下午9:13, Kishon Vijay Abraham I wrote:

Hi Jason,

On 7/8/2020 4:52 PM, Jason Wang wrote:

On 2020/7/7 下午10:45, Kishon Vijay Abraham I wrote:

Hi Jason,

On 7/7/2020 3:17 PM, Jason Wang wrote:

On 2020/7/6 下午5:32, Kishon Vijay Abraham I wrote:

Hi Jason,

On 7/3/2020 12:46 PM, Jason Wang wrote:

On 2020/7/2 下午9:35, Kishon Vijay Abraham I wrote:

Hi Jason,

On 7/2/2020 3:40 PM, Jason Wang wrote:

On 2020/7/2 下午5:51, Michael S. Tsirkin wrote:

On Thu, Jul 02, 2020 at 01:51:21PM +0530, Kishon Vijay Abraham I wrote:

This series enhances Linux Vhost support to enable SoC-to-SoC
communication over MMIO. This series enables rpmsg communication between
two SoCs using both PCIe RC<->EP and HOST1-NTB-HOST2

1) Modify vhost to use standard Linux driver model
2) Add support in vring to access virtqueue over MMIO
3) Add vhost client driver for rpmsg
4) Add PCIe RC driver (uses virtio) and PCIe EP driver (uses vhost) for
    rpmsg communication between two SoCs connected to each other
5) Add NTB Virtio driver and NTB Vhost driver for rpmsg communication
    between two SoCs connected via NTB
6) Add configfs to configure the components

UseCase1 :

  VHOST RPMSG VIRTIO RPMSG
   +   +
   |   |
   |   |
   |   |
   |   |
+-v--+ +--v---+
|   Linux    | | Linux    |
|  Endpoint  | | Root Complex |
|    <->  |
|    | |  |
|    SOC1    | | SOC2 |
++ +--+

UseCase 2:

  VHOST RPMSG  VIRTIO RPMSG
   + +
   | |
   | |
   | |
   | |
    +--v--+   +--v--+
    | |   | |
    |    HOST1    |   |    HOST2    |
    | |   | |
    +--^--+   +--^--+
   | |
   | |
+-+
|  +--v--+   +--v--+  |
|  | |   | |  |
|  | EP  |   | EP  |  |
|  | CONTROLLER1 |   | CONTROLLER2 |  |
|  | <---> |  |
|  | |   | |  |
|  | |   | |  |
|  | |  SoC With Multiple EP Instances   | |  |
|  | |  (Configured using NTB Function)  | |  |
|  +-+   +-+  |
+-+

Software Layering:

The high-level SW layering should look something like below. This series
adds support only for RPMSG VHOST, however something similar should be
done for net and scsi. With that any vhost device (PCI, NTB, Platform
device, user) can use any of the vhost client driver.


     ++  +---+  ++  +--+
     |  RPMSG VHOST   |  | NET VHOST |  | SCSI VHOST |  |    X |
     +---^+  +-^-+  +-^--+  +^-+
     | |  |  |
     | |  |  |
     | |  |  |
+---v-v--v--v--+
|    VHOST CORE    |
+^---^^--^-+
  |   |    |  |
  |   |    |  |
  |   |    |  |
+v---+  +v--+  +--v--+  +v-+
|  PCI EPF VHOST |  | NTB VHOST |  |PLATFORM DEVICE VHOST|  |    X |
++  +---+  +-+  +--+

This was initially proposed here [1]

[1] ->
https://lore.

[PATCH 1/2] doc, mm: sync up oom_score_adj documentation

[Michal Hocko]

From: Michal Hocko 

There are at least two notes in the oom section. The 3% discount for
root processes is gone since d46078b28889 ("mm, oom: remove 3% bonus for
CAP_SYS_ADMIN processes").

Likewise children of the selected oom victim are not sacrificed since
bbbe48029720 ("mm, oom: remove 'prefer children over parent' heuristic")

Drop both of them.

Signed-off-by: Michal Hocko 
---
 Documentation/filesystems/proc.rst | 8 
 1 file changed, 8 deletions(-)

diff --git a/Documentation/filesystems/proc.rst 
b/Documentation/filesystems/proc.rst
index 996f3cfe7030..8e3b5dffcfa8 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -1634,9 +1634,6 @@ may allocate from based on an estimation of its current 
memory and swap use.
 For example, if a task is using all allowed memory, its badness score will be
 1000.  If it is using half of its allowed memory, its score will be 500.
 
-There is an additional factor included in the badness score: the current memory
-and swap usage is discounted by 3% for root processes.
-
 The amount of "allowed" memory depends on the context in which the oom killer
 was called.  If it is due to the memory assigned to the allocating task's 
cpuset
 being exhausted, the allowed memory represents the set of mems assigned to that
@@ -1672,11 +1669,6 @@ The value of /proc//oom_score_adj may be reduced no 
lower than the last
 value set by a CAP_SYS_RESOURCE process. To reduce the value any lower
 requires CAP_SYS_RESOURCE.
 
-Caveat: when a parent task is selected, the oom killer will sacrifice any first
-generation children with separate address spaces instead, if possible.  This
-avoids servers and important system daemons from being killed and loses the
-minimal amount of work.
-
 
 3.2 /proc//oom_score - Display current oom-killer score
 -
-- 
2.27.0

[PATCH 2/2] doc, mm: clarify /proc//oom_score value range

[Michal Hocko]

From: Michal Hocko 

The exported value includes oom_score_adj so the range is no [0, 1000]
as described in the previous section but rather [0, 2000]. Mention that
fact explicitly.

Signed-off-by: Michal Hocko 
---
 Documentation/filesystems/proc.rst | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/Documentation/filesystems/proc.rst 
b/Documentation/filesystems/proc.rst
index 8e3b5dffcfa8..78a0dec323a3 100644
--- a/Documentation/filesystems/proc.rst
+++ b/Documentation/filesystems/proc.rst
@@ -1673,6 +1673,9 @@ requires CAP_SYS_RESOURCE.
 3.2 /proc//oom_score - Display current oom-killer score
 -
 
+Please note that the exported value includes oom_score_adj so it is effectively
+in range [0,2000].
+
 This file can be used to check the current score used by the oom-killer is for
 any given . Use it together with /proc//oom_score_adj to tune which
 process should be killed in an out-of-memory situation.
-- 
2.27.0

Re: [PATCH v2 2/2] riscv: Add jump-label implementation

[Björn Töpel]

On Wed, 8 Jul 2020 at 23:10, Emil Renner Berthing  wrote:
>
> Add jump-label implementation based on the ARM64 version
> and add CONFIG_JUMP_LABEL=y to the defconfigs.
>
> Signed-off-by: Emil Renner Berthing 
> Reviewed-by: Björn Töpel 

Tested-by: Björn Töpel 

> ---
>
> Tested on the HiFive Unleashed board.
>
> Changes since v1:
> - WARN and give up gracefully if the jump offset cannot be
>   represented in a JAL instruction.
> - Add missing braces.
> - Add CONFIG_JUMP_LABEL=y to defconfigs.
>
> All suggested by Björn Töpel.
>
> Changes since RFC:
> - Use RISCV_PTR and RISCV_LGPTR macros to match struct jump_table
>   also in 32bit kernels.
> - Remove unneeded branch ? 1 : 0, thanks Björn
> - Fix \n\n instead of \n\t mistake
>
>  .../core/jump-labels/arch-support.txt |  2 +-
>  arch/riscv/Kconfig|  2 +
>  arch/riscv/configs/defconfig  |  1 +
>  arch/riscv/configs/nommu_k210_defconfig   |  1 +
>  arch/riscv/configs/nommu_virt_defconfig   |  1 +
>  arch/riscv/configs/rv32_defconfig |  1 +
>  arch/riscv/include/asm/jump_label.h   | 59 +++
>  arch/riscv/kernel/Makefile|  2 +
>  arch/riscv/kernel/jump_label.c| 49 +++
>  9 files changed, 117 insertions(+), 1 deletion(-)
>  create mode 100644 arch/riscv/include/asm/jump_label.h
>  create mode 100644 arch/riscv/kernel/jump_label.c
>
> diff --git a/Documentation/features/core/jump-labels/arch-support.txt 
> b/Documentation/features/core/jump-labels/arch-support.txt
> index 632a1c7aefa2..760243d18ed7 100644
> --- a/Documentation/features/core/jump-labels/arch-support.txt
> +++ b/Documentation/features/core/jump-labels/arch-support.txt
> @@ -23,7 +23,7 @@
>  |openrisc: | TODO |
>  |  parisc: |  ok  |
>  | powerpc: |  ok  |
> -|   riscv: | TODO |
> +|   riscv: |  ok  |
>  |s390: |  ok  |
>  |  sh: | TODO |
>  |   sparc: |  ok  |
> diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
> index fd639937e251..d2f5c53fdc19 100644
> --- a/arch/riscv/Kconfig
> +++ b/arch/riscv/Kconfig
> @@ -46,6 +46,8 @@ config RISCV
> select GENERIC_TIME_VSYSCALL if MMU && 64BIT
> select HANDLE_DOMAIN_IRQ
> select HAVE_ARCH_AUDITSYSCALL
> +   select HAVE_ARCH_JUMP_LABEL
> +   select HAVE_ARCH_JUMP_LABEL_RELATIVE
> select HAVE_ARCH_KASAN if MMU && 64BIT
> select HAVE_ARCH_KGDB
> select HAVE_ARCH_KGDB_QXFER_PKT
> diff --git a/arch/riscv/configs/defconfig b/arch/riscv/configs/defconfig
> index 4da4886246a4..d58c93efb603 100644
> --- a/arch/riscv/configs/defconfig
> +++ b/arch/riscv/configs/defconfig
> @@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y
>  CONFIG_SOC_SIFIVE=y
>  CONFIG_SOC_VIRT=y
>  CONFIG_SMP=y
> +CONFIG_JUMP_LABEL=y
>  CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
>  CONFIG_NET=y
> diff --git a/arch/riscv/configs/nommu_k210_defconfig 
> b/arch/riscv/configs/nommu_k210_defconfig
> index b48138e329ea..cd1df62b13c7 100644
> --- a/arch/riscv/configs/nommu_k210_defconfig
> +++ b/arch/riscv/configs/nommu_k210_defconfig
> @@ -33,6 +33,7 @@ CONFIG_SMP=y
>  CONFIG_NR_CPUS=2
>  CONFIG_CMDLINE="earlycon console=ttySIF0"
>  CONFIG_CMDLINE_FORCE=y
> +CONFIG_JUMP_LABEL=y
>  # CONFIG_BLOCK is not set
>  CONFIG_BINFMT_FLAT=y
>  # CONFIG_COREDUMP is not set
> diff --git a/arch/riscv/configs/nommu_virt_defconfig 
> b/arch/riscv/configs/nommu_virt_defconfig
> index cf74e179bf90..f27596e9663e 100644
> --- a/arch/riscv/configs/nommu_virt_defconfig
> +++ b/arch/riscv/configs/nommu_virt_defconfig
> @@ -30,6 +30,7 @@ CONFIG_MAXPHYSMEM_2GB=y
>  CONFIG_SMP=y
>  CONFIG_CMDLINE="root=/dev/vda rw earlycon=uart8250,mmio,0x1000,115200n8 
> console=ttyS0"
>  CONFIG_CMDLINE_FORCE=y
> +CONFIG_JUMP_LABEL=y
>  # CONFIG_BLK_DEV_BSG is not set
>  CONFIG_PARTITION_ADVANCED=y
>  # CONFIG_MSDOS_PARTITION is not set
> diff --git a/arch/riscv/configs/rv32_defconfig 
> b/arch/riscv/configs/rv32_defconfig
> index 05bbf5240569..3a55f0e00d6c 100644
> --- a/arch/riscv/configs/rv32_defconfig
> +++ b/arch/riscv/configs/rv32_defconfig
> @@ -17,6 +17,7 @@ CONFIG_BPF_SYSCALL=y
>  CONFIG_SOC_VIRT=y
>  CONFIG_ARCH_RV32I=y
>  CONFIG_SMP=y
> +CONFIG_JUMP_LABEL=y
>  CONFIG_MODULES=y
>  CONFIG_MODULE_UNLOAD=y
>  CONFIG_NET=y
> diff --git a/arch/riscv/include/asm/jump_label.h 
> b/arch/riscv/include/asm/jump_label.h
> new file mode 100644
> index ..d5fb342bfccf
> --- /dev/null
> +++ b/arch/riscv/include/asm/jump_label.h
> @@ -0,0 +1,59 @@
> +/* SPDX-License-Identifier: GPL-2.0-only */
> +/*
> + * Copyright (C) 2020 Emil Renner Berthing
> + *
> + * Based on arch/arm64/include/asm/jump_label.h
> + */
> +#ifndef __ASM_JUMP_LABEL_H
> +#define __ASM_JUMP_LABEL_H
> +
> +#ifndef __ASSEMBLY__
> +
> +#include 
> +
> +#define JUMP_LABEL_NOP_SIZE 4
> +
> +static __always_inline bool arch_static_branch(struct static_key *key,
> +  bool

Re: [PATCH v6.1 6/7] seccomp: Introduce addfd ioctl to seccomp user notifier

[Kees Cook]

On Wed, Jul 08, 2020 at 11:17:27PM -0700, Kees Cook wrote:
> +static long seccomp_notify_addfd(struct seccomp_filter *filter,
> +  struct seccomp_notif_addfd __user *uaddfd,
> +  unsigned int size)
> +{
> + struct seccomp_notif_addfd addfd;
> + struct seccomp_knotif *knotif;
> + struct seccomp_kaddfd kaddfd;
> + int ret;
> +
> + BUILD_BUG_ON(sizeof(struct seccomp_notify_addfd) < 
> SECCOMP_NOTIFY_ADDFD_SIZE_VER0);
> + BUILD_BUG_ON(sizeof(struct seccomp_notify_addfd) != 
> SECCOMP_NOTIFY_ADDFD_SIZE_LATEST);

*brown paper bag* I built the wrong tree! This is a typo:
seccomp_notify_addfd should be seccomp_notif_addfd (no "y").

-- 
Kees Cook

Re: [PATCH v2 1/2] riscv: Support R_RISCV_ADD64 and R_RISCV_SUB64 relocs

[Björn Töpel]

On Wed, 8 Jul 2020 at 23:10, Emil Renner Berthing  wrote:
>
> These are needed for the __jump_table in modules using
> static keys/jump-labels with the layout from
> HAVE_ARCH_JUMP_LABEL_RELATIVE on 64bit kernels.
>
> Signed-off-by: Emil Renner Berthing 

Reviewed-by: Björn Töpel 
Tested-by: Björn Töpel 

> ---
>
> Tested on the HiFive Unleashed board.
>
> This patch is new in v2. It fixes an error loading modules
> containing static keys found by Björn Töpel.
>
>  arch/riscv/kernel/module.c | 16 
>  1 file changed, 16 insertions(+)
>
> diff --git a/arch/riscv/kernel/module.c b/arch/riscv/kernel/module.c
> index 7191342c54da..104fba889cf7 100644
> --- a/arch/riscv/kernel/module.c
> +++ b/arch/riscv/kernel/module.c
> @@ -263,6 +263,13 @@ static int apply_r_riscv_add32_rela(struct module *me, 
> u32 *location,
> return 0;
>  }
>
> +static int apply_r_riscv_add64_rela(struct module *me, u32 *location,
> +   Elf_Addr v)
> +{
> +   *(u64 *)location += (u64)v;
> +   return 0;
> +}
> +
>  static int apply_r_riscv_sub32_rela(struct module *me, u32 *location,
> Elf_Addr v)
>  {
> @@ -270,6 +277,13 @@ static int apply_r_riscv_sub32_rela(struct module *me, 
> u32 *location,
> return 0;
>  }
>
> +static int apply_r_riscv_sub64_rela(struct module *me, u32 *location,
> +   Elf_Addr v)
> +{
> +   *(u64 *)location -= (u64)v;
> +   return 0;
> +}
> +
>  static int (*reloc_handlers_rela[]) (struct module *me, u32 *location,
> Elf_Addr v) = {
> [R_RISCV_32]= apply_r_riscv_32_rela,
> @@ -290,7 +304,9 @@ static int (*reloc_handlers_rela[]) (struct module *me, 
> u32 *location,
> [R_RISCV_RELAX] = apply_r_riscv_relax_rela,
> [R_RISCV_ALIGN] = apply_r_riscv_align_rela,
> [R_RISCV_ADD32] = apply_r_riscv_add32_rela,
> +   [R_RISCV_ADD64] = apply_r_riscv_add64_rela,
> [R_RISCV_SUB32] = apply_r_riscv_sub32_rela,
> +   [R_RISCV_SUB64] = apply_r_riscv_sub64_rela,
>  };
>
>  int apply_relocate_add(Elf_Shdr *sechdrs, const char *strtab,
> --
> 2.27.0
>

[PATCH v3 07/12] ima: Fail rule parsing when appraise_flag=blacklist is unsupportable

[Tyler Hicks]

The "appraise_flag" option is only appropriate for appraise actions
and its "blacklist" value is only appropriate when
CONFIG_IMA_APPRAISE_MODSIG is enabled and "appraise_flag=blacklist" is
only appropriate when "appraise_type=imasig|modsig" is also present.
Make this clear at policy load so that IMA policy authors don't assume
that other uses of "appraise_flag=blacklist" are supported.

Fixes: 273df864cf74 ("ima: Check against blacklisted hashes for files with 
modsig")
Signed-off-by: Tyler Hicks 
Cc: Nayna Jain 
---

* v3
  - New patch

 security/integrity/ima/ima_policy.c | 13 -
 1 file changed, 12 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 81da02071d41..9842e2e0bc6d 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1035,6 +1035,11 @@ static bool ima_validate_rule(struct ima_rule_entry 
*entry)
return false;
}
 
+   /* Ensure that combinations of flags are compatible with each other */
+   if (entry->flags & IMA_CHECK_BLACKLIST &&
+   !(entry->flags & IMA_MODSIG_ALLOWED))
+   return false;
+
return true;
 }
 
@@ -1371,8 +1376,14 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry *entry)
result = -EINVAL;
break;
case Opt_appraise_flag:
+   if (entry->action != APPRAISE) {
+   result = -EINVAL;
+   break;
+   }
+
ima_log_string(ab, "appraise_flag", args[0].from);
-   if (strstr(args[0].from, "blacklist"))
+   if (IS_ENABLED(CONFIG_IMA_APPRAISE_MODSIG) &&
+   strstr(args[0].from, "blacklist"))
entry->flags |= IMA_CHECK_BLACKLIST;
break;
case Opt_permit_directio:
-- 
2.25.1

[PATCH v3 08/12] ima: Shallow copy the args_p member of ima_rule_entry.lsm elements

[Tyler Hicks]

The args_p member is a simple string that is allocated by
ima_rule_init(). Shallow copy it like other non-LSM references in
ima_rule_entry structs.

There are no longer any necessary error path cleanups to do in
ima_lsm_copy_rule().

Signed-off-by: Tyler Hicks 
---

* v3
  - No change
* v2
  - Adjusted context to account for ima_lsm_copy_rule() directly calling
ima_lsm_free_rule() and the lack of explicit reference ownership
transfers
  - Added comment to ima_lsm_copy_rule() to document the args_p
reference ownership transfer

 security/integrity/ima/ima_policy.c | 16 +++-
 1 file changed, 7 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 9842e2e0bc6d..b02e1ffd10c9 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -300,10 +300,13 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct 
ima_rule_entry *entry)
continue;
 
nentry->lsm[i].type = entry->lsm[i].type;
-   nentry->lsm[i].args_p = kstrdup(entry->lsm[i].args_p,
-   GFP_KERNEL);
-   if (!nentry->lsm[i].args_p)
-   goto out_err;
+   nentry->lsm[i].args_p = entry->lsm[i].args_p;
+   /*
+* Remove the reference from entry so that the associated
+* memory will not be freed during a later call to
+* ima_lsm_free_rule(entry).
+*/
+   entry->lsm[i].args_p = NULL;
 
security_filter_rule_init(nentry->lsm[i].type,
  Audit_equal,
@@ -314,11 +317,6 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct 
ima_rule_entry *entry)
(char *)entry->lsm[i].args_p);
}
return nentry;
-
-out_err:
-   ima_lsm_free_rule(nentry);
-   kfree(nentry);
-   return NULL;
 }
 
 static int ima_lsm_update_rule(struct ima_rule_entry *entry)
-- 
2.25.1

[PATCH v3 11/12] ima: Use the common function to detect LSM conditionals in a rule

[Tyler Hicks]

Make broader use of ima_rule_contains_lsm_cond() to check if a given
rule contains an LSM conditional. This is a code cleanup and has no
user-facing change.

Signed-off-by: Tyler Hicks 
Reviewed-by: Mimi Zohar 
---

* v3
  - No change
* v2
  - No change

 security/integrity/ima/ima_policy.c | 11 ++-
 1 file changed, 2 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index c4d0a0c1f896..81ee8fd1d83a 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -360,17 +360,10 @@ static bool ima_rule_contains_lsm_cond(struct 
ima_rule_entry *entry)
 static void ima_lsm_update_rules(void)
 {
struct ima_rule_entry *entry, *e;
-   int i, result, needs_update;
+   int result;
 
list_for_each_entry_safe(entry, e, &ima_policy_rules, list) {
-   needs_update = 0;
-   for (i = 0; i < MAX_LSM_RULES; i++) {
-   if (entry->lsm[i].args_p) {
-   needs_update = 1;
-   break;
-   }
-   }
-   if (!needs_update)
+   if (!ima_rule_contains_lsm_cond(entry))
continue;
 
result = ima_lsm_update_rule(entry);
-- 
2.25.1

[PATCH v3 04/12] ima: Fail rule parsing when buffer hook functions have an invalid action

[Tyler Hicks]

Buffer based hook functions, such as KEXEC_CMDLINE and KEY_CHECK, can
only measure. The process_buffer_measurement() function quietly ignores
all actions except measure so make this behavior clear at the time of
policy load.

The parsing of the keyrings conditional had a check to ensure that it
was only specified with measure actions but the check should be on the
hook function and not the keyrings conditional since
"appraise func=KEY_CHECK" is not a valid rule.

Fixes: b0935123a183 ("IMA: Define a new hook to measure the kexec boot command 
line arguments")
Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Signed-off-by: Tyler Hicks 
---

* v3
  - Add comments to ima_validate_rule() to separate/explain the types of
validation checks (section for action checks, section for hook
function checks, soon to be a section for combination of options
checks, etc.)
  - Removed the "if (entry->flags & IMA_FUNC)" conditional around the
switch statement in ima_validate_rule() which reduced the overall indention
by a tab. This could be removed because entry->func is NONE when the
IMA_FUNC flag is not set. We'll explicitly enforce and then leverage
that property in a later patch when we start validating all hook
functions in ima_validate_rule().
  - Add comment explicitly stating that all hook functions except
KEXEC_CMDLINE and KEY_CHECK are still being validated in
ima_parse_rule().
* v2
  - No change

 security/integrity/ima/ima_policy.c | 40 +++--
 1 file changed, 38 insertions(+), 2 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index e458cd47c099..40c28f1a6a5a 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -973,6 +973,43 @@ static void check_template_modsig(const struct 
ima_template_desc *template)
 #undef MSG
 }
 
+static bool ima_validate_rule(struct ima_rule_entry *entry)
+{
+   /* Ensure that the action is set */
+   if (entry->action == UNKNOWN)
+   return false;
+
+   /*
+* Ensure that the hook function is compatible with the other
+* components of the rule
+*/
+   switch (entry->func) {
+   case NONE:
+   case FILE_CHECK:
+   case MMAP_CHECK:
+   case BPRM_CHECK:
+   case CREDS_CHECK:
+   case POST_SETATTR:
+   case MODULE_CHECK:
+   case FIRMWARE_CHECK:
+   case KEXEC_KERNEL_CHECK:
+   case KEXEC_INITRAMFS_CHECK:
+   case POLICY_CHECK:
+   /* Validation of these hook functions is in ima_parse_rule() */
+   break;
+   case KEXEC_CMDLINE:
+   case KEY_CHECK:
+   if (entry->action & ~(MEASURE | DONT_MEASURE))
+   return false;
+
+   break;
+   default:
+   return false;
+   }
+
+   return true;
+}
+
 static int ima_parse_rule(char *rule, struct ima_rule_entry *entry)
 {
struct audit_buffer *ab;
@@ -1150,7 +1187,6 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry *entry)
keyrings_len = strlen(args[0].from) + 1;
 
if ((entry->keyrings) ||
-   (entry->action != MEASURE) ||
(entry->func != KEY_CHECK) ||
(keyrings_len < 2)) {
result = -EINVAL;
@@ -1356,7 +1392,7 @@ static int ima_parse_rule(char *rule, struct 
ima_rule_entry *entry)
break;
}
}
-   if (!result && (entry->action == UNKNOWN))
+   if (!result && !ima_validate_rule(entry))
result = -EINVAL;
else if (entry->action == APPRAISE)
temp_ima_appraise |= ima_appraise_flag(entry->func);
-- 
2.25.1

[PATCH v3 09/12] ima: Use correct type for the args_p member of ima_rule_entry.lsm elements

[Tyler Hicks]

Make args_p be of the char pointer type rather than have it be a void
pointer that gets casted to char pointer when it is used. It is a simple
NUL-terminated string as returned by match_strdup().

Signed-off-by: Tyler Hicks 
---

* v3
  - No change
* v2
  - No change

 security/integrity/ima/ima_policy.c | 18 +-
 1 file changed, 9 insertions(+), 9 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index b02e1ffd10c9..13a178c70b44 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -74,7 +74,7 @@ struct ima_rule_entry {
int pcr;
struct {
void *rule; /* LSM file metadata specific */
-   void *args_p;   /* audit value */
+   char *args_p;   /* audit value */
int type;   /* audit type */
} lsm[MAX_LSM_RULES];
char *fsname;
@@ -314,7 +314,7 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct 
ima_rule_entry *entry)
  &nentry->lsm[i].rule);
if (!nentry->lsm[i].rule)
pr_warn("rule for LSM \'%s\' is undefined\n",
-   (char *)entry->lsm[i].args_p);
+   entry->lsm[i].args_p);
}
return nentry;
 }
@@ -918,7 +918,7 @@ static int ima_lsm_rule_init(struct ima_rule_entry *entry,
   &entry->lsm[lsm_rule].rule);
if (!entry->lsm[lsm_rule].rule) {
pr_warn("rule for LSM \'%s\' is undefined\n",
-   (char *)entry->lsm[lsm_rule].args_p);
+   entry->lsm[lsm_rule].args_p);
 
if (ima_rules == &ima_default_rules) {
kfree(entry->lsm[lsm_rule].args_p);
@@ -1682,27 +1682,27 @@ int ima_policy_show(struct seq_file *m, void *v)
switch (i) {
case LSM_OBJ_USER:
seq_printf(m, pt(Opt_obj_user),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
case LSM_OBJ_ROLE:
seq_printf(m, pt(Opt_obj_role),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
case LSM_OBJ_TYPE:
seq_printf(m, pt(Opt_obj_type),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
case LSM_SUBJ_USER:
seq_printf(m, pt(Opt_subj_user),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
case LSM_SUBJ_ROLE:
seq_printf(m, pt(Opt_subj_role),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
case LSM_SUBJ_TYPE:
seq_printf(m, pt(Opt_subj_type),
-  (char *)entry->lsm[i].args_p);
+  entry->lsm[i].args_p);
break;
}
seq_puts(m, " ");
-- 
2.25.1

[PATCH v3 06/12] ima: Fail rule parsing when the KEY_CHECK hook is combined with an invalid cond

[Tyler Hicks]

The KEY_CHECK function only supports the uid, pcr, and keyrings
conditionals. Make this clear at policy load so that IMA policy authors
don't assume that other conditionals are supported.

Fixes: 5808611cccb2 ("IMA: Add KEY_CHECK func to measure keys")
Signed-off-by: Tyler Hicks 
Reviewed-by: Lakshmi Ramasubramanian 
---

* v3
  - Added Lakshmi's Reviewed-by
  - Adjust for the indentation change introduced in patch #4
* v2
  - No change

 security/integrity/ima/ima_policy.c | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 1c64bd6f1728..81da02071d41 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -1023,6 +1023,13 @@ static bool ima_validate_rule(struct ima_rule_entry 
*entry)
if (entry->action & ~(MEASURE | DONT_MEASURE))
return false;
 
+   if (entry->flags & ~(IMA_FUNC | IMA_UID | IMA_PCR |
+IMA_KEYRINGS))
+   return false;
+
+   if (ima_rule_contains_lsm_cond(entry))
+   return false;
+
break;
default:
return false;
-- 
2.25.1

[PATCH v3 12/12] ima: Support additional conditionals in the KEXEC_CMDLINE hook function

[Tyler Hicks]

Take the properties of the kexec kernel's inode and the current task
ownership into consideration when matching a KEXEC_CMDLINE operation to
the rules in the IMA policy. This allows for some uniformity when
writing IMA policy rules for KEXEC_KERNEL_CHECK, KEXEC_INITRAMFS_CHECK,
and KEXEC_CMDLINE operations.

Prior to this patch, it was not possible to write a set of rules like
this:

 dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
 dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
 dont_measure func=KEXEC_CMDLINE obj_type=foo_t
 measure func=KEXEC_KERNEL_CHECK
 measure func=KEXEC_INITRAMFS_CHECK
 measure func=KEXEC_CMDLINE

The inode information associated with the kernel being loaded by a
kexec_kernel_load(2) syscall can now be included in the decision to
measure or not

Additonally, the uid, euid, and subj_* conditionals can also now be
used in KEXEC_CMDLINE rules. There was no technical reason as to why
those conditionals weren't being considered previously other than
ima_match_rules() didn't have a valid inode to use so it immediately
bailed out for KEXEC_CMDLINE operations rather than going through the
full list of conditional comparisons.

Signed-off-by: Tyler Hicks 
Cc: Eric Biederman 
Cc: ke...@lists.infradead.org
Reviewed-by: Lakshmi Ramasubramanian 
---

* v3
  - Added Lakshmi's Reviewed-by
  - Adjust for the indentation change introduced in patch #4
* v2
  - Moved the inode parameter of process_buffer_measurement() to be the
first parameter so that it more closely matches process_masurement()

 include/linux/ima.h  |  4 ++--
 kernel/kexec_file.c  |  2 +-
 security/integrity/ima/ima.h |  2 +-
 security/integrity/ima/ima_api.c |  2 +-
 security/integrity/ima/ima_appraise.c|  2 +-
 security/integrity/ima/ima_asymmetric_keys.c |  2 +-
 security/integrity/ima/ima_main.c| 23 +++-
 security/integrity/ima/ima_policy.c  | 17 +--
 security/integrity/ima/ima_queue_keys.c  |  2 +-
 9 files changed, 31 insertions(+), 25 deletions(-)

diff --git a/include/linux/ima.h b/include/linux/ima.h
index 9164e1534ec9..d15100de6cdd 100644
--- a/include/linux/ima.h
+++ b/include/linux/ima.h
@@ -25,7 +25,7 @@ extern int ima_post_read_file(struct file *file, void *buf, 
loff_t size,
  enum kernel_read_file_id id);
 extern void ima_post_path_mknod(struct dentry *dentry);
 extern int ima_file_hash(struct file *file, char *buf, size_t buf_size);
-extern void ima_kexec_cmdline(const void *buf, int size);
+extern void ima_kexec_cmdline(int kernel_fd, const void *buf, int size);
 
 #ifdef CONFIG_IMA_KEXEC
 extern void ima_add_kexec_buffer(struct kimage *image);
@@ -103,7 +103,7 @@ static inline int ima_file_hash(struct file *file, char 
*buf, size_t buf_size)
return -EOPNOTSUPP;
 }
 
-static inline void ima_kexec_cmdline(const void *buf, int size) {}
+static inline void ima_kexec_cmdline(int kernel_fd, const void *buf, int size) 
{}
 #endif /* CONFIG_IMA */
 
 #ifndef CONFIG_IMA_KEXEC
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index bb05fd52de85..07df431c1f21 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -287,7 +287,7 @@ kimage_file_prepare_segments(struct kimage *image, int 
kernel_fd, int initrd_fd,
goto out;
}
 
-   ima_kexec_cmdline(image->cmdline_buf,
+   ima_kexec_cmdline(kernel_fd, image->cmdline_buf,
  image->cmdline_buf_len - 1);
}
 
diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index ea7e77536f3c..576ae2c6d418 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -265,7 +265,7 @@ void ima_store_measurement(struct integrity_iint_cache 
*iint, struct file *file,
   struct evm_ima_xattr_data *xattr_value,
   int xattr_len, const struct modsig *modsig, int pcr,
   struct ima_template_desc *template_desc);
-void process_buffer_measurement(const void *buf, int size,
+void process_buffer_measurement(struct inode *inode, const void *buf, int size,
const char *eventname, enum ima_hooks func,
int pcr, const char *keyring);
 void ima_audit_measurement(struct integrity_iint_cache *iint,
diff --git a/security/integrity/ima/ima_api.c b/security/integrity/ima/ima_api.c
index bf22de8b7ce0..4f39fb93f278 100644
--- a/security/integrity/ima/ima_api.c
+++ b/security/integrity/ima/ima_api.c
@@ -162,7 +162,7 @@ void ima_add_violation(struct file *file, const unsigned 
char *filename,
 
 /**
  * ima_get_action - appraise & measure decision based on policy.
- * @inode: pointer to inode to measure
+ * @inode: pointer to the inode associated with the object being validated
  * @cred: pointer to credentials structure to validate
  * @secid: secid o

[PATCH v3 10/12] ima: Move comprehensive rule validation checks out of the token parser

[Tyler Hicks]

Use ima_validate_rule(), at the end of the token parsing stage, to
verify combinations of actions, hooks, and flags. This is useful to
increase readability by consolidating such checks into a single function
and also because rule conditionals can be specified in arbitrary order
making it difficult to do comprehensive rule validation until the entire
rule has been parsed.

This allows for the check that ties together the "keyrings" conditional
with the KEY_CHECK function hook to be moved into the final rule
validation.

The modsig check no longer needs to compiled conditionally because the
token parser will ensure that modsig support is enabled before accepting
"imasig|modsig" appraise type values. The final rule validation will
ensure that appraise_type and appraise_flag options are only present in
appraise rules.

Finally, this allows for the check that ties together the "pcr"
conditional with the measure action to be moved into the final rule
validation.

Signed-off-by: Tyler Hicks 
---

* v3
  - Significant broadening of the patch's scope along with renaming and
re-describing the patch. ima_validate_rule() is now the consolidated
location for checking combinations of
actions/functions/conditionals and the existing checks are now
removed from the token parsing code.
+ Ensure that the IMA_FUNC flag is only set when a function hook is
  specified, and vice versa, which allows us to use the NONE case in
  the switch statement to enforce that "keyrings=",
  "appraise_type=imasig|modsig", and "appraise_flag=blacklist"
  cannot be specified on a rule without an appropriate hook function
  - Adjust for the indentation change introduced in patch #4
  - Adjust for new fixes introduced in patch #7
* v2
  - Allowed IMA_DIGSIG_REQUIRED, IMA_PERMIT_DIRECTIO,
IMA_MODSIG_ALLOWED, and IMA_CHECK_BLACKLIST conditionals to be
present in the rule entry flags for non-buffer hook functions.

 security/integrity/ima/ima.h|  6 ---
 security/integrity/ima/ima_modsig.c | 20 --
 security/integrity/ima/ima_policy.c | 57 +++--
 3 files changed, 37 insertions(+), 46 deletions(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 59ec28f5c117..ea7e77536f3c 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -372,7 +372,6 @@ static inline int ima_read_xattr(struct dentry *dentry,
 #endif /* CONFIG_IMA_APPRAISE */
 
 #ifdef CONFIG_IMA_APPRAISE_MODSIG
-bool ima_hook_supports_modsig(enum ima_hooks func);
 int ima_read_modsig(enum ima_hooks func, const void *buf, loff_t buf_len,
struct modsig **modsig);
 void ima_collect_modsig(struct modsig *modsig, const void *buf, loff_t size);
@@ -382,11 +381,6 @@ int ima_get_raw_modsig(const struct modsig *modsig, const 
void **data,
   u32 *data_len);
 void ima_free_modsig(struct modsig *modsig);
 #else
-static inline bool ima_hook_supports_modsig(enum ima_hooks func)
-{
-   return false;
-}
-
 static inline int ima_read_modsig(enum ima_hooks func, const void *buf,
  loff_t buf_len, struct modsig **modsig)
 {
diff --git a/security/integrity/ima/ima_modsig.c 
b/security/integrity/ima/ima_modsig.c
index d106885cc495..fb25723c65bc 100644
--- a/security/integrity/ima/ima_modsig.c
+++ b/security/integrity/ima/ima_modsig.c
@@ -32,26 +32,6 @@ struct modsig {
u8 raw_pkcs7[];
 };
 
-/**
- * ima_hook_supports_modsig - can the policy allow modsig for this hook?
- *
- * modsig is only supported by hooks using ima_post_read_file(), because only
- * they preload the contents of the file in a buffer. FILE_CHECK does that in
- * some cases, but not when reached from vfs_open(). POLICY_CHECK can support
- * it, but it's not useful in practice because it's a text file so deny.
- */
-bool ima_hook_supports_modsig(enum ima_hooks func)
-{
-   switch (func) {
-   case KEXEC_KERNEL_CHECK:
-   case KEXEC_INITRAMFS_CHECK:
-   case MODULE_CHECK:
-   return true;
-   default:
-   return false;
-   }
-}
-
 /*
  * ima_read_modsig - Read modsig from buf.
  *
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 13a178c70b44..c4d0a0c1f896 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -984,10 +984,27 @@ static void check_template_modsig(const struct 
ima_template_desc *template)
 
 static bool ima_validate_rule(struct ima_rule_entry *entry)
 {
-   /* Ensure that the action is set */
+   /* Ensure that the action is set and is compatible with the flags */
if (entry->action == UNKNOWN)
return false;
 
+   if (entry->action != MEASURE && entry->flags & IMA_PCR)
+   return false;
+
+   if (entry->action != APPRAISE &&
+   entry->flags & (IMA_DIGSIG_REQUIRED | IMA_MODSIG_ALLOWED | 
IMA_CHECK_BLACKLIST))
+   retu

[PATCH v3 00/12] ima: Fix rule parsing bugs and extend KEXEC_CMDLINE rule support

[Tyler Hicks]

This series ultimately extends the supported IMA rule conditionals for
the KEXEC_CMDLINE hook function. As of today, there's an imbalance in
IMA language conditional support for KEXEC_CMDLINE rules in comparison
to KEXEC_KERNEL_CHECK and KEXEC_INITRAMFS_CHECK rules. The KEXEC_CMDLINE
rules do not support *any* conditionals so you cannot have a sequence of
rules like this:

 dont_measure func=KEXEC_KERNEL_CHECK obj_type=foo_t
 dont_measure func=KEXEC_INITRAMFS_CHECK obj_type=foo_t
 dont_measure func=KEXEC_CMDLINE obj_type=foo_t
 measure func=KEXEC_KERNEL_CHECK
 measure func=KEXEC_INITRAMFS_CHECK
 measure func=KEXEC_CMDLINE

Instead, KEXEC_CMDLINE rules can only be measured or not measured and
there's no additional flexibility in today's implementation of the
KEXEC_CMDLINE hook function.

With this series, the above sequence of rules becomes valid and any
calls to kexec_file_load() with a kernel and initramfs inode type of
foo_t will not be measured (that includes the kernel cmdline buffer)
while all other objects given to a kexec_file_load() syscall will be
measured. There's obviously not an inode directly associated with the
kernel cmdline buffer but this patch series ties the inode based
decision making for KEXEC_CMDLINE to the kernel's inode. I think this
will be intuitive to policy authors.

While reading IMA code and preparing to make this change, I realized
that the buffer based hook functions (KEXEC_CMDLINE and KEY_CHECK) are
quite special in comparison to longer standing hook functions. These
buffer based hook functions can only support measure actions and there
are some restrictions on the conditionals that they support. However,
the rule parser isn't enforcing any of those restrictions and IMA policy
authors wouldn't have any immediate way of knowing that the policy that
they wrote is invalid. For example, the sequence of rules above parses
successfully in today's kernel but the
"dont_measure func=KEXEC_CMDLINE ..." rule is incorrectly handled in
ima_match_rules(). The dont_measure rule is *always* considered to be a
match so, surprisingly, no KEXEC_CMDLINE measurements are made.

While making the rule parser more strict, I realized that the parser
does not correctly free all of the allocated memory associated with an
ima_rule_entry when going down some error paths. Invalid policy loaded
by the policy administrator could result in small memory leaks.

I envision patches 1-7 going to stable. The series is ordered in a way
that has all the fixes up front, followed by cleanups, followed by the
feature patch. The breakdown of patches looks like so:

 Memory leak fixes: 1-3
 Parser strictness fixes: 4-7
 Code cleanups made possible by the fixes: 8-11
 Extend KEXEC_CMDLINE rule support: 12

Perhaps the most logical ordering for code review is:

 1, 2, 3, 8, 9, 4, 5, 6, 7, 10, 11, 12

If you'd like me to re-order or split up the series, just let me know.
Thanks for considering these patches!

* Series-wide v3 changes
  - Indentation changes in patch #4 which caused some churn
  - Added patch #7
  - Significant changes to patch #10 to address Mimi's requests
* Series-wide v2 changes
  - Rebased onto next-integrity-testing
  - Squashed patches 2 and 3 from v1
+ Updated this cover letter to account for changes to patch index
  changes
+ See patch 2 for specific code changes

Tyler

Tyler Hicks (12):
  ima: Have the LSM free its audit rule
  ima: Free the entire rule when deleting a list of rules
  ima: Free the entire rule if it fails to parse
  ima: Fail rule parsing when buffer hook functions have an invalid
action
  ima: Fail rule parsing when the KEXEC_CMDLINE hook is combined with an
invalid cond
  ima: Fail rule parsing when the KEY_CHECK hook is combined with an
invalid cond
  ima: Fail rule parsing when appraise_flag=blacklist is unsupportable
  ima: Shallow copy the args_p member of ima_rule_entry.lsm elements
  ima: Use correct type for the args_p member of ima_rule_entry.lsm
elements
  ima: Move comprehensive rule validation checks out of the token parser
  ima: Use the common function to detect LSM conditionals in a rule
  ima: Support additional conditionals in the KEXEC_CMDLINE hook
function

 include/linux/ima.h  |   4 +-
 kernel/kexec_file.c  |   2 +-
 security/integrity/ima/ima.h |  13 +-
 security/integrity/ima/ima_api.c |   2 +-
 security/integrity/ima/ima_appraise.c|   2 +-
 security/integrity/ima/ima_asymmetric_keys.c |   2 +-
 security/integrity/ima/ima_main.c|  23 ++-
 security/integrity/ima/ima_modsig.c  |  20 --
 security/integrity/ima/ima_policy.c  | 206 ++-
 security/integrity/ima/ima_queue_keys.c  |   2 +-
 10 files changed, 182 insertions(+), 94 deletions(-)

-- 
2.25.1

[PATCH v3 03/12] ima: Free the entire rule if it fails to parse

[Tyler Hicks]

Use ima_free_rule() to fix memory leaks of allocated ima_rule_entry
members, such as .fsname and .keyrings, when an error is encountered
during rule parsing.

Set the args_p pointer to NULL after freeing it in the error path of
ima_lsm_rule_init() so that it isn't freed twice.

This fixes a memory leak seen when loading an rule that contains an
additional piece of allocated memory, such as an fsname, followed by an
invalid conditional:

 # echo "measure fsname=tmpfs bad=cond" > /sys/kernel/security/ima/policy
 -bash: echo: write error: Invalid argument
 # echo scan > /sys/kernel/debug/kmemleak
 # cat /sys/kernel/debug/kmemleak
 unreferenced object 0x98e7e4ece6c0 (size 8):
   comm "bash", pid 672, jiffies 4294791843 (age 21.855s)
   hex dump (first 8 bytes):
 74 6d 70 66 73 00 6b a5  tmpfs.k.
   backtrace:
 [] kstrdup+0x2e/0x60
 [] ima_parse_add_rule+0x7d4/0x1020
 [] ima_write_policy+0xab/0x1d0
 [] vfs_write+0xde/0x1d0
 [] ksys_write+0x68/0xe0
 [] do_syscall_64+0x56/0xa0
 [<89ea7b98>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: f1b08bbcbdaf ("ima: define a new policy condition based on the 
filesystem name")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks 
---

* v3
  - No change
* v2
  - No change

 security/integrity/ima/ima_policy.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index bf00b966e87f..e458cd47c099 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -913,6 +913,7 @@ static int ima_lsm_rule_init(struct ima_rule_entry *entry,
 
if (ima_rules == &ima_default_rules) {
kfree(entry->lsm[lsm_rule].args_p);
+   entry->lsm[lsm_rule].args_p = NULL;
result = -EINVAL;
} else
result = 0;
@@ -1404,7 +1405,7 @@ ssize_t ima_parse_add_rule(char *rule)
 
result = ima_parse_rule(p, entry);
if (result) {
-   kfree(entry);
+   ima_free_rule(entry);
integrity_audit_msg(AUDIT_INTEGRITY_STATUS, NULL,
NULL, op, "invalid-policy", result,
audit_info);
-- 
2.25.1

[PATCH v3 02/12] ima: Free the entire rule when deleting a list of rules

[Tyler Hicks]

Create a function, ima_free_rule(), to free all memory associated with
an ima_rule_entry. Use the new function to fix memory leaks of allocated
ima_rule_entry members, such as .fsname and .keyrings, when deleting a
list of rules.

Make the existing ima_lsm_free_rule() function specific to the LSM
audit rule array of an ima_rule_entry and require that callers make an
additional call to kfree to free the ima_rule_entry itself.

This fixes a memory leak seen when loading by a valid rule that contains
an additional piece of allocated memory, such as an fsname, followed by
an invalid rule that triggers a policy load failure:

 # echo -e "dont_measure fsname=securityfs\nbad syntax" > \
/sys/kernel/security/ima/policy
 -bash: echo: write error: Invalid argument
 # echo scan > /sys/kernel/debug/kmemleak
 # cat /sys/kernel/debug/kmemleak
 unreferenced object 0x9bab67ca12c0 (size 16):
   comm "bash", pid 684, jiffies 4295212803 (age 252.344s)
   hex dump (first 16 bytes):
 73 65 63 75 72 69 74 79 66 73 00 6b 6b 6b 6b a5  securityfs..
   backtrace:
 [] kstrdup+0x2e/0x60
 [] ima_parse_add_rule+0x7d4/0x1020
 [<444825ac>] ima_write_policy+0xab/0x1d0
 [<2b7f0d6c>] vfs_write+0xde/0x1d0
 [<96feedcf>] ksys_write+0x68/0xe0
 [<52b544a2>] do_syscall_64+0x56/0xa0
 [<7ead1ba7>] entry_SYSCALL_64_after_hwframe+0x44/0xa9

Fixes: f1b08bbcbdaf ("ima: define a new policy condition based on the 
filesystem name")
Fixes: 2b60c0ecedf8 ("IMA: Read keyrings= option from the IMA policy")
Signed-off-by: Tyler Hicks 
---

* v3
  - No change
* v2
  - Collapsed patch #2 from v1 of this series, into this patch. This
patch now introduces ima_free_rule().
  - Existing callers of ima_lsm_free_rule() are doing so to free rules
after a successful or failed ima_lsm_copy_rule() and those callers
continue to directly call ima_lsm_copy_rule() rather than doing
explicit reference ownership and calling ima_free_rule().
  - The kfree(entry) of ima_lsm_free_rule() was removed from that
function to make it focused on freeing the LSM references. Direct
callers of ima_lsm_free_rule() must now call kfree(entry) after
ima_lsm_free_rule().
  - A comment was added in ima_lsm_update_rule() to clarify why
ima_free_rule() isn't being used.

 security/integrity/ima/ima_policy.c | 29 -
 1 file changed, 24 insertions(+), 5 deletions(-)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index d7c268c2b0ce..bf00b966e87f 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -261,6 +261,21 @@ static void ima_lsm_free_rule(struct ima_rule_entry *entry)
security_filter_rule_free(entry->lsm[i].rule);
kfree(entry->lsm[i].args_p);
}
+}
+
+static void ima_free_rule(struct ima_rule_entry *entry)
+{
+   if (!entry)
+   return;
+
+   /*
+* entry->template->fields may be allocated in ima_parse_rule() but that
+* reference is owned by the corresponding ima_template_desc element in
+* the defined_templates list and cannot be freed here
+*/
+   kfree(entry->fsname);
+   kfree(entry->keyrings);
+   ima_lsm_free_rule(entry);
kfree(entry);
 }
 
@@ -302,6 +317,7 @@ static struct ima_rule_entry *ima_lsm_copy_rule(struct 
ima_rule_entry *entry)
 
 out_err:
ima_lsm_free_rule(nentry);
+   kfree(nentry);
return NULL;
 }
 
@@ -315,7 +331,14 @@ static int ima_lsm_update_rule(struct ima_rule_entry 
*entry)
 
list_replace_rcu(&entry->list, &nentry->list);
synchronize_rcu();
+   /*
+* ima_lsm_copy_rule() shallow copied all references, except for the
+* LSM references, from entry to nentry so we only want to free the LSM
+* references and the entry itself. All other memory refrences will now
+* be owned by nentry.
+*/
ima_lsm_free_rule(entry);
+   kfree(entry);
 
return 0;
 }
@@ -1402,15 +1425,11 @@ ssize_t ima_parse_add_rule(char *rule)
 void ima_delete_rules(void)
 {
struct ima_rule_entry *entry, *tmp;
-   int i;
 
temp_ima_appraise = 0;
list_for_each_entry_safe(entry, tmp, &ima_temp_rules, list) {
-   for (i = 0; i < MAX_LSM_RULES; i++)
-   kfree(entry->lsm[i].args_p);
-
list_del(&entry->list);
-   kfree(entry);
+   ima_free_rule(entry);
}
 }
 
-- 
2.25.1

[PATCH v2] EDAC-I7300: Replace HTTP links with HTTPS ones

[Alexander A. Klimov]

Rationale:
Reduces attack surface on kernel devs opening the links for MITM
as HTTPS traffic is much harder to manipulate.

Deterministic algorithm:
For each file:
  If not .svg:
For each line:
  If doesn't contain `\bxmlns\b`:
For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
  If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
If both the HTTP and HTTPS versions
return 200 OK and serve the same content:
  Replace HTTP with HTTPS.

Signed-off-by: Alexander A. Klimov 
---
 drivers/edac/i7300_edac.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/edac/i7300_edac.c b/drivers/edac/i7300_edac.c
index 2e9bbe56cde9..4f28b8c8d378 100644
--- a/drivers/edac/i7300_edac.c
+++ b/drivers/edac/i7300_edac.c
@@ -5,7 +5,7 @@
  * Copyright (c) 2010 by:
  *  Mauro Carvalho Chehab
  *
- * Red Hat Inc. http://www.redhat.com
+ * Red Hat Inc. https://www.redhat.com
  *
  * Intel 7300 Chipset Memory Controller Hub (MCH) - Datasheet
  * http://www.intel.com/Assets/PDF/datasheet/318082.pdf
@@ -1206,7 +1206,7 @@ module_exit(i7300_exit);
 
 MODULE_LICENSE("GPL");
 MODULE_AUTHOR("Mauro Carvalho Chehab");
-MODULE_AUTHOR("Red Hat Inc. (http://www.redhat.com)");
+MODULE_AUTHOR("Red Hat Inc. (https://www.redhat.com)");
 MODULE_DESCRIPTION("MC Driver for Intel I7300 memory controllers - "
   I7300_REVISION);
 
-- 
2.27.0

[PATCH v3 05/12] ima: Fail rule parsing when the KEXEC_CMDLINE hook is combined with an invalid cond

[Tyler Hicks]

The KEXEC_CMDLINE hook function only supports the pcr conditional. Make
this clear at policy load so that IMA policy authors don't assume that
other conditionals are supported.

Since KEXEC_CMDLINE's inception, ima_match_rules() has always returned
true on any loaded KEXEC_CMDLINE rule without any consideration for
other conditionals present in the rule. Make it clear that pcr is the
only supported KEXEC_CMDLINE conditional by returning an error during
policy load.

An example of why this is a problem can be explained with the following
rule:

 dont_measure func=KEXEC_CMDLINE obj_type=foo_t

An IMA policy author would have assumed that rule is valid because the
parser accepted it but the result was that measurements for all
KEXEC_CMDLINE operations would be disabled.

Fixes: b0935123a183 ("IMA: Define a new hook to measure the kexec boot command 
line arguments")
Signed-off-by: Tyler Hicks 
Reviewed-by: Mimi Zohar 
Reviewed-by: Lakshmi Ramasubramanian 
---

* v3
  - Adjust for the indentation change introduced in patch #4
  - Added Lakshmi's Reviewed-by
* v2
  - Added Mimi's Reviewed-by

 security/integrity/ima/ima_policy.c | 21 +
 1 file changed, 21 insertions(+)

diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 40c28f1a6a5a..1c64bd6f1728 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -343,6 +343,17 @@ static int ima_lsm_update_rule(struct ima_rule_entry 
*entry)
return 0;
 }
 
+static bool ima_rule_contains_lsm_cond(struct ima_rule_entry *entry)
+{
+   int i;
+
+   for (i = 0; i < MAX_LSM_RULES; i++)
+   if (entry->lsm[i].args_p)
+   return true;
+
+   return false;
+}
+
 /*
  * The LSM policy can be reloaded, leaving the IMA LSM based rules referring
  * to the old, stale LSM policy.  Update the IMA LSM based rules to reflect
@@ -998,6 +1009,16 @@ static bool ima_validate_rule(struct ima_rule_entry 
*entry)
/* Validation of these hook functions is in ima_parse_rule() */
break;
case KEXEC_CMDLINE:
+   if (entry->action & ~(MEASURE | DONT_MEASURE))
+   return false;
+
+   if (entry->flags & ~(IMA_FUNC | IMA_PCR))
+   return false;
+
+   if (ima_rule_contains_lsm_cond(entry))
+   return false;
+
+   break;
case KEY_CHECK:
if (entry->action & ~(MEASURE | DONT_MEASURE))
return false;
-- 
2.25.1

[PATCH v3 01/12] ima: Have the LSM free its audit rule

[Tyler Hicks]

Ask the LSM to free its audit rule rather than directly calling kfree().
Both AppArmor and SELinux do additional work in their audit_rule_free()
hooks. Fix memory leaks by allowing the LSMs to perform necessary work.

Fixes: b16942455193 ("ima: use the lsm policy update notifier")
Signed-off-by: Tyler Hicks 
Cc: Janne Karhunen 
Cc: Casey Schaufler 
Reviewed-by: Mimi Zohar 
---

* v3
  - No change
* v2
  - Fixed build warning by dropping the 'return -EINVAL' from
the stubbed out security_filter_rule_free() since it has a void
return type
  - Added Mimi's Reviewed-by
  - Developed a follow-on patch to rename security_filter_rule_*()
functions, to address Casey's request, but I'll submit it
independently of this patch series since it is somewhat unrelated

 security/integrity/ima/ima.h| 5 +
 security/integrity/ima/ima_policy.c | 2 +-
 2 files changed, 6 insertions(+), 1 deletion(-)

diff --git a/security/integrity/ima/ima.h b/security/integrity/ima/ima.h
index 4515975cc540..59ec28f5c117 100644
--- a/security/integrity/ima/ima.h
+++ b/security/integrity/ima/ima.h
@@ -420,6 +420,7 @@ static inline void ima_free_modsig(struct modsig *modsig)
 #ifdef CONFIG_IMA_LSM_RULES
 
 #define security_filter_rule_init security_audit_rule_init
+#define security_filter_rule_free security_audit_rule_free
 #define security_filter_rule_match security_audit_rule_match
 
 #else
@@ -430,6 +431,10 @@ static inline int security_filter_rule_init(u32 field, u32 
op, char *rulestr,
return -EINVAL;
 }
 
+static inline void security_filter_rule_free(void *lsmrule)
+{
+}
+
 static inline int security_filter_rule_match(u32 secid, u32 field, u32 op,
 void *lsmrule)
 {
diff --git a/security/integrity/ima/ima_policy.c 
b/security/integrity/ima/ima_policy.c
index 66aa3e17a888..d7c268c2b0ce 100644
--- a/security/integrity/ima/ima_policy.c
+++ b/security/integrity/ima/ima_policy.c
@@ -258,7 +258,7 @@ static void ima_lsm_free_rule(struct ima_rule_entry *entry)
int i;
 
for (i = 0; i < MAX_LSM_RULES; i++) {
-   kfree(entry->lsm[i].rule);
+   security_filter_rule_free(entry->lsm[i].rule);
kfree(entry->lsm[i].args_p);
}
kfree(entry);
-- 
2.25.1

[PATCH v6.1 6/7] seccomp: Introduce addfd ioctl to seccomp user notifier

[Kees Cook]

From: Sargun Dhillon 

The current SECCOMP_RET_USER_NOTIF API allows for syscall supervision over
an fd. It is often used in settings where a supervising task emulates
syscalls on behalf of a supervised task in userspace, either to further
restrict the supervisee's syscall abilities or to circumvent kernel
enforced restrictions the supervisor deems safe to lift (e.g. actually
performing a mount(2) for an unprivileged container).

While SECCOMP_RET_USER_NOTIF allows for the interception of any syscall,
only a certain subset of syscalls could be correctly emulated. Over the
last few development cycles, the set of syscalls which can't be emulated
has been reduced due to the addition of pidfd_getfd(2). With this we are
now able to, for example, intercept syscalls that require the supervisor
to operate on file descriptors of the supervisee such as connect(2).

However, syscalls that cause new file descriptors to be installed can not
currently be correctly emulated since there is no way for the supervisor
to inject file descriptors into the supervisee. This patch adds a
new addfd ioctl to remove this restriction by allowing the supervisor to
install file descriptors into the intercepted task. By implementing this
feature via seccomp the supervisor effectively instructs the supervisee
to install a set of file descriptors into its own file descriptor table
during the intercepted syscall. This way it is possible to intercept
syscalls such as open() or accept(), and install (or replace, like
dup2(2)) the supervisor's resulting fd into the supervisee. One
replacement use-case would be to redirect the stdout and stderr of a
supervisee into log file descriptors opened by the supervisor.

The ioctl handling is based on the discussions[1] of how Extensible
Arguments should interact with ioctls. Instead of building size into
the addfd structure, make it a function of the ioctl command (which
is how sizes are normally passed to ioctls). To support forward and
backward compatibility, just mask out the direction and size, and match
everything. The size (and any future direction) checks are done along
with copy_struct_from_user() logic.

As a note, the seccomp_notif_addfd structure is laid out based on 8-byte
alignment without requiring packing as there have been packing issues
with uapi highlighted before[2][3]. Although we could overload the
newfd field and use -1 to indicate that it is not to be used, doing
so requires changing the size of the fd field, and introduces struct
packing complexity.

[1]: https://lore.kernel.org/lkml/87o8w9bcaf@mid.deneb.enyo.de/
[2]: 
https://lore.kernel.org/lkml/a328b91d-fd8f-4f27-b3c2-91a9c45f1...@rasmusvillemoes.dk/
[3]: 
https://lore.kernel.org/lkml/20200612104629.GA15814@ircssh-2.c.rugged-nimbus-611.internal

Cc: Christoph Hellwig 
Cc: Christian Brauner 
Cc: Tycho Andersen 
Cc: Jann Horn 
Cc: Robert Sesek 
Cc: Chris Palmer 
Cc: Al Viro 
Cc: linux-fsde...@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-...@vger.kernel.org
Suggested-by: Matt Denton 
Link: https://lore.kernel.org/r/20200603011044.7972-4-sar...@sargun.me
Signed-off-by: Sargun Dhillon 
Co-developed-by: Kees Cook 
Signed-off-by: Kees Cook 
---
v6.1:
- clarify commit log (christian)
- add ..._SIZE_{VER0,LATEST} and BUILD_BUG_ON()s (christian)
- remove undef (christian)
- fix embedded URL reference numbers
v6: https://lore.kernel.org/lkml/20200707133049.nfxc6vz6vcs26m3b@wittgenstein
---
 include/linux/seccomp.h  |   4 +
 include/uapi/linux/seccomp.h |  22 +
 kernel/seccomp.c | 173 ++-
 3 files changed, 198 insertions(+), 1 deletion(-)

diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h
index babcd6c02d09..881c90b6aa25 100644
--- a/include/linux/seccomp.h
+++ b/include/linux/seccomp.h
@@ -10,6 +10,10 @@
 SECCOMP_FILTER_FLAG_NEW_LISTENER | \
 SECCOMP_FILTER_FLAG_TSYNC_ESRCH)
 
+/* sizeof() the first published struct seccomp_notif_addfd */
+#define SECCOMP_NOTIFY_ADDFD_SIZE_VER0 24
+#define SECCOMP_NOTIFY_ADDFD_SIZE_LATEST SECCOMP_NOTIFY_ADDFD_SIZE_VER0
+
 #ifdef CONFIG_SECCOMP
 
 #include 
diff --git a/include/uapi/linux/seccomp.h b/include/uapi/linux/seccomp.h
index 965290f7dcc2..6ba18b82a02e 100644
--- a/include/uapi/linux/seccomp.h
+++ b/include/uapi/linux/seccomp.h
@@ -113,6 +113,25 @@ struct seccomp_notif_resp {
__u32 flags;
 };
 
+/* valid flags for seccomp_notif_addfd */
+#define SECCOMP_ADDFD_FLAG_SETFD   (1UL << 0) /* Specify remote fd */
+
+/**
+ * struct seccomp_notif_addfd
+ * @id: The ID of the seccomp notification
+ * @flags: SECCOMP_ADDFD_FLAG_*
+ * @srcfd: The local fd number
+ * @newfd: Optional remote FD number if SETFD option is set, otherwise 0.
+ * @newfd_flags: The O_* flags the remote FD should have applied
+ */
+struct seccomp_notif_addfd {
+   __u64 id;
+   __u32 flags;
+   __u32 srcfd;
+   __u32 newfd;
+   __u32 newfd_

Re: [PATCH] Replace HTTP links with HTTPS ones: USB MASS STORAGE DRIVER

[Greg KH]

On Wed, Jul 08, 2020 at 08:41:54PM +0200, Alexander A. Klimov wrote:
> 
> 
> Am 08.07.20 um 12:39 schrieb Greg KH:
> > On Wed, Jul 08, 2020 at 11:55:00AM +0200, Alexander A. Klimov wrote:
> > > Rationale:
> > > Reduces attack surface on kernel devs opening the links for MITM
> > > as HTTPS traffic is much harder to manipulate.
> > > 
> > > Deterministic algorithm:
> > > For each file:
> > >If not .svg:
> > >  For each line:
> > >If doesn't contain `\bxmlns\b`:
> > >  For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> > > If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> > >  If both the HTTP and HTTPS versions
> > >  return 200 OK and serve the same content:
> > >Replace HTTP with HTTPS.
> > > 
> > > Signed-off-by: Alexander A. Klimov 
> > 
> > Your subject lines are very odd compared to all patches for this
> > subsystem, as well as all other kernel subsystems.  Any reason you are
> > doing it this way and not the normal and standard method of:
> > USB: storage: replace http links with https
> > 
> > That would look more uniform as well as not shout at anyone.
> > 
> > thanks,
> > 
> > greg k-h
> > 
> Hi,
> 
> I'm very sorry.
> 
> As Torvalds has merged 93431e0607e5 and many of you devs (including big
> maintainers like David Miller) just applied this stuff, I assumed that's OK.
> 
> And now I've rolled out tens of patches via shell loop... *sigh*
> 
> As this is the third (I think) change request like this, I assume this rule
> applies to all subsystems – right?

Yes, you should try to emulate what the subsystem does, look at other
patches for the same files, but the format I suggested is almost always
the correct one.  If not, I'm sure maintainers will be glad to tell you
otherwise :)

thanks,

greg k-h

[mm/debug_vm_pgtable] a97a171093: BUG:unable_to_handle_page_fault_for_address

[kernel test robot]

Greeting,

FYI, we noticed the following commit (built with gcc-9):

commit: a97a17109332c3a9e361553adfa383c1e5205f3b ("[PATCH V4 2/4] 
mm/debug_vm_pgtable: Add tests validating advanced arch page table helpers")
url: 
https://github.com/0day-ci/linux/commits/Anshuman-Khandual/mm-debug_vm_pgtable-Add-some-more-tests/20200706-085212
base: https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git 
dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258

in testcase: boot

on test machine: qemu-system-x86_64 -enable-kvm -cpu SandyBridge -smp 2 -m 16G

caused below changes (please refer to attached dmesg/kmsg for entire 
log/backtrace):


+-+++
| | 30011bfca7 | a97a171093 |
+-+++
| boot_successes  | 4  | 0  |
| boot_failures   | 0  | 4  |
| BUG:unable_to_handle_page_fault_for_address | 0  | 4  |
| Oops:#[##]  | 0  | 4  |
| RIP:hugetlb_advanced_tests  | 0  | 4  |
| Kernel_panic-not_syncing:Fatal_exception| 0  | 4  |
+-+++


If you fix the issue, kindly add following tag
Reported-by: kernel test robot 


[   94.349598] BUG: unable to handle page fault for address: ed10a7ffddff
[   94.351039] #PF: supervisor read access in kernel mode
[   94.352172] #PF: error_code(0x) - not-present page
[   94.353256] PGD 43ffed067 P4D 43ffed067 PUD 43fdee067 PMD 0 
[   94.354484] Oops:  [#1] SMP KASAN
[   94.355238] CPU: 1 PID: 1 Comm: swapper/0 Not tainted 
5.8.0-rc4-2-ga97a17109332c #1
[   94.360456] Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS 
1.12.0-1 04/01/2014
[   94.361950] RIP: 0010:hugetlb_advanced_tests+0x137/0x699
[   94.363026] Code: 8b 13 4d 85 f6 75 0b 48 ff 05 2c e4 6a 01 31 ed eb 41 bf 
f8 ff ff ff ba ff ff 37 00 4c 01 f7 48 c1 e2 2a 48 89 f9 48 c1 e9 03 <80> 3c 11 
00 74 05 e8 cd c0 67 fa ba f8 ff ff ff 49 8b 2c 16 48 85
[   94.366592] RSP: :c9047d30 EFLAGS: 00010a06
[   94.367693] RAX: 11049b80 RBX: 888380525308 RCX: 1110a7ffddff
[   94.369215] RDX: dc00 RSI: 111087ffdc00 RDI: 88853ffeeff8
[   94.370693] RBP: 0018e510 R08: 0025 R09: 0001
[   94.372165] R10: 888380523c07 R11: ed10700a4780 R12: 88843208e510
[   94.373674] R13: 0025 R14: 88843ffef000 R15: 31e01ae61000
[   94.375147] FS:  () GS:8883a380() 
knlGS:
[   94.376883] CS:  0010 DS:  ES:  CR0: 80050033
[   94.378051] CR2: ed10a7ffddff CR3: 04e15000 CR4: 000406a0
[   94.379522] Call Trace:
[   94.380073]  debug_vm_pgtable+0xd81/0x2029
[   94.380871]  ? pmd_advanced_tests+0x621/0x621
[   94.381819]  do_one_initcall+0x1eb/0xbd0
[   94.382551]  ? trace_event_raw_event_initcall_finish+0x240/0x240
[   94.383634]  ? rcu_read_lock_sched_held+0xb9/0x110
[   94.388727]  ? rcu_read_lock_held+0xd0/0xd0
[   94.389604]  ? __kasan_check_read+0x1d/0x30
[   94.390485]  kernel_init_freeable+0x430/0x4f8
[   94.391416]  ? rest_init+0x3f8/0x3f8
[   94.392185]  kernel_init+0x14/0x1e8
[   94.392918]  ret_from_fork+0x22/0x30
[   94.393662] Modules linked in:
[   94.394289] CR2: ed10a7ffddff
[   94.395000] ---[ end trace 8ca5a1655dfb8c39 ]---


To reproduce:

# build kernel
cd linux
cp config-5.8.0-rc4-2-ga97a17109332c .config
make HOSTCC=gcc-9 CC=gcc-9 ARCH=x86_64 olddefconfig prepare 
modules_prepare bzImage

git clone https://github.com/intel/lkp-tests.git
cd lkp-tests
bin/lkp qemu -k  job-script # job-script is attached in this 
email



Thanks,
lkp

#
# Automatically generated file; DO NOT EDIT.
# Linux/x86_64 5.8.0-rc4 Kernel Configuration
#
CONFIG_CC_VERSION_TEXT="gcc-9 (Debian 9.3.0-14) 9.3.0"
CONFIG_CC_IS_GCC=y
CONFIG_GCC_VERSION=90300
CONFIG_LD_VERSION=23400
CONFIG_CLANG_VERSION=0
CONFIG_CC_CAN_LINK=y
CONFIG_CC_CAN_LINK_STATIC=y
CONFIG_CC_HAS_ASM_GOTO=y
CONFIG_CC_HAS_ASM_INLINE=y
CONFIG_CONSTRUCTORS=y
CONFIG_IRQ_WORK=y
CONFIG_BUILDTIME_TABLE_SORT=y
CONFIG_THREAD_INFO_IN_TASK=y

#
# General setup
#
CONFIG_INIT_ENV_ARG_LIMIT=32
# CONFIG_COMPILE_TEST is not set
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_BUILD_SALT=""
CONFIG_HAVE_KERNEL_GZIP=y
CONFIG_HAVE_KERNEL_BZIP2=y
CONFIG_HAVE_KERNEL_LZMA=y
CONFIG_HAVE_KERNEL_XZ=y
CONFIG_HAVE_KERNEL_LZO=y
CONFIG_HAVE_KERNEL_LZ4=y
# CONFIG_KERNEL_GZIP is not set
# CONFIG_KERNEL_BZIP2 is not set
# CONFIG_KERNEL_LZMA is not set
CONFIG_KERNEL_XZ=y
# CONFIG_KERNEL_LZO is not set
# CONFIG_KERNEL_LZ4 is not set
CONFIG_DEFAULT_INIT=""
CONFIG_DEFAULT_HOSTNAME="(none)"
# CONFIG_SYSVIPC is not set
# CONFIG_P

Re: [PATCH v6 6/7] seccomp: Introduce addfd ioctl to seccomp user notifier

[Kees Cook]

On Tue, Jul 07, 2020 at 03:30:49PM +0200, Christian Brauner wrote:
> Hm, maybe change that description to sm like:
> 
> [...]

Cool, yeah. Thanks! I've tweaked it a little more

> > +   /* 24 is original sizeof(struct seccomp_notif_addfd) */
> > +   if (size < 24 || size >= PAGE_SIZE)
> > +   return -EINVAL;
> 
> Hm, so maybe add the following:
> 
> #define SECCOMP_NOTIFY_ADDFD_VER0 24
> #define SECCOMP_NOTIFY_ADDFD_LATEST SECCOMP_NOTIFY_ADDFD_VER0
> 
> and then place:
> 
> BUILD_BUG_ON(sizeof(struct seccomp_notify_addfd) < SECCOMP_NOTIFY_ADDFD_VER0);
> BUILD_BUG_ON(sizeof(struct open_how) != SECCOMP_NOTIFY_ADDFD_LATEST);

Yes, good idea (BTW, did the EA syscall docs land?)

I've made these SECCOMP_NOTIFY_ADDFD_SIZE_* to match your examples below
(i.e.  I added "SIZE" to what you suggested above).

> somewhere which is what we do for clone3(), openat2() and others to
> catch build-time nonsense.
> 
> include/uapi/linux/perf_event.h:#define PERF_ATTR_SIZE_VER0 64  /* 
> sizeof first published struct */
> include/uapi/linux/sched.h:#define CLONE_ARGS_SIZE_VER0 64 /* sizeof first 
> published struct */
> include/uapi/linux/sched/types.h:#define SCHED_ATTR_SIZE_VER0   48  /* 
> sizeof first published struct */
> include/linux/fcntl.h:#define OPEN_HOW_SIZE_VER024 /* sizeof first 
> published struct */
> include/linux/fcntl.h:#define OPEN_HOW_SIZE_LATEST  OPEN_HOW_SIZE_VER0

The ..._SIZE_VER0 and ...LATEST stuff doesn't seem useful to export via
UAPI. Above, 2 of the 3 export to uapi. Is there a specific rationale
for which should and which shouldn't?

> > +#undef EA_IOCTL
> 
> Why is this undefed? :)

It was defined "in" a function, so I like to mimic function visibility.
But you're right; there's no reason to undef it.

-- 
Kees Cook

Re: [PATCH] Replace HTTP links with HTTPS ones: DISKQUOTA

[Jan Kara]

On Wed 08-07-20 19:19:05, Alexander A. Klimov wrote:
> Rationale:
> Reduces attack surface on kernel devs opening the links for MITM
> as HTTPS traffic is much harder to manipulate.
> 
> Deterministic algorithm:
> For each file:
>   If not .svg:
> For each line:
>   If doesn't contain `\bxmlns\b`:
> For each link, `\bhttp://[^# \t\r\n]*(?:\w|/)`:
> If neither `\bgnu\.org/license`, nor `\bmozilla\.org/MPL\b`:
> If both the HTTP and HTTPS versions
> return 200 OK and serve the same content:
>   Replace HTTP with HTTPS.
> 
> Signed-off-by: Alexander A. Klimov 

Thanks. I've applied the patch. I'll also note that somehow your script
missed converting the sourceforge.net link in quota.rst to https. I did
that myself together with replacing link to libnl doc with a working one...

Honza

> ---
>  Continuing my work started at 93431e0607e5.
>  See also: git log --oneline '--author=Alexander A. Klimov 
> ' v5.7..master
>  (Actually letting a shell for loop submit all this stuff for me.)
> 
>  If there are any URLs to be removed completely or at least not HTTPSified:
>  Just clearly say so and I'll *undo my change*.
>  See also: https://lkml.org/lkml/2020/6/27/64
> 
>  If there are any valid, but yet not changed URLs:
>  See: https://lkml.org/lkml/2020/6/26/837
> 
>  If you apply the patch, please let me know.
> 
> 
>  Documentation/filesystems/quota.rst | 2 +-
>  fs/quota/Kconfig| 2 +-
>  2 files changed, 2 insertions(+), 2 deletions(-)
> 
> diff --git a/Documentation/filesystems/quota.rst 
> b/Documentation/filesystems/quota.rst
> index a30cdd47c652..6508c4520ba5 100644
> --- a/Documentation/filesystems/quota.rst
> +++ b/Documentation/filesystems/quota.rst
> @@ -31,7 +31,7 @@ the above events to userspace. There they can be captured 
> by an application
>  and processed accordingly.
>  
>  The interface uses generic netlink framework (see
> -http://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for 
> more
> +https://lwn.net/Articles/208755/ and http://people.suug.ch/~tgr/libnl/ for 
> more
>  details about this layer). The name of the quota generic netlink interface
>  is "VFS_DQUOT". Definitions of constants below are in .
>  Since the quota netlink protocol is not namespace aware, quota netlink 
> messages
> diff --git a/fs/quota/Kconfig b/fs/quota/Kconfig
> index 7218314ca13f..d1ceb76adb71 100644
> --- a/fs/quota/Kconfig
> +++ b/fs/quota/Kconfig
> @@ -15,7 +15,7 @@ config QUOTA
> Ext3, ext4 and reiserfs also support journaled quotas for which
> you don't need to run quotacheck(8) after an unclean shutdown.
> For further details, read the Quota mini-HOWTO, available from
> -   , or the documentation provided
> +   , or the documentation provided
> with the quota tools. Probably the quota support is only useful for
> multi user systems. If unsure, say N.
>  
> -- 
> 2.27.0
> 
-- 
Jan Kara 
SUSE Labs, CR

Re: [PATCH] omapfb: dss: Fix max fclk divider for omap36xx

[Greg KH]

On Wed, Jul 08, 2020 at 06:37:51PM -0500, Adam Ford wrote:
> On Mon, Jul 6, 2020 at 6:18 AM Adam Ford  wrote:
> >
> > On Mon, Jul 6, 2020 at 1:02 AM Tomi Valkeinen  wrote:
> > >
> > > Hi,
> > >
> > > On 03/07/2020 22:36, Sam Ravnborg wrote:
> > > > Hi Tomi.
> > > >
> > > > On Fri, Jul 03, 2020 at 10:17:29AM +0300, Tomi Valkeinen wrote:
> > > >> On 30/06/2020 21:26, Adam Ford wrote:
> > > >>> The drm/omap driver was fixed to correct an issue where using a
> > > >>> divider of 32 breaks the DSS despite the TRM stating 32 is a valid
> > > >>> number.  Through experimentation, it appears that 31 works, and
> > > >>> it is consistent with the value used by the drm/omap driver.
> > > >>>
> > > >>> This patch fixes the divider for fbdev driver instead of the drm.
> > > >>>
> > > >>> Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> > > >>>
> > > >>> Cc:  #4.9+
> > > >>> Signed-off-by: Adam Ford 
> > > >>> ---
> > > >>> Linux 4.4 will need a similar patch, but it doesn't apply cleanly.
> > > >>>
> > > >>> The DRM version of this same fix is:
> > > >>> e2c4ed148cf3 ("drm/omap: fix max fclk divider for omap36xx")
> > > >>>
> > > >>>
> > > >>> diff --git a/drivers/video/fbdev/omap2/omapfb/dss/dss.c 
> > > >>> b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > > >>> index 7252d22dd117..bfc5c4c5a26a 100644
> > > >>> --- a/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > > >>> +++ b/drivers/video/fbdev/omap2/omapfb/dss/dss.c
> > > >>> @@ -833,7 +833,7 @@ static const struct dss_features 
> > > >>> omap34xx_dss_feats = {
> > > >>>};
> > > >>>static const struct dss_features omap3630_dss_feats = {
> > > >>> -   .fck_div_max=   32,
> > > >>> +   .fck_div_max=   31,
> > > >>> .dss_fck_multiplier =   1,
> > > >>> .parent_clk_name=   "dpll4_ck",
> > > >>> .dpi_select_source  =   
> > > >>> &dss_dpi_select_source_omap2_omap3,
> > > >>>
> > > >>
> > > >> Reviewed-by: Tomi Valkeinen 
> > > > Will you apply to drm-misc?
> > >
> > > This is for fbdev, so I presume Bartlomiej will pick this one.
> > >
> > > > Note  following output from "dim fixes":
> > > > $ dim fixes f76ee892a99e
> > > > Fixes: f76ee892a99e ("omapfb: copy omapdss & displays for omapfb")
> > > > Cc: Tomi Valkeinen 
> > > > Cc: Dave Airlie 
> > > > Cc: Rob Clark 
> > > > Cc: Laurent Pinchart 
> > > > Cc: Sam Ravnborg 
> > > > Cc: Bartlomiej Zolnierkiewicz 
> > > > Cc: Jason Yan 
> > > > Cc: "Andrew F. Davis" 
> > > > Cc: YueHaibing 
> > > > Cc:  # v4.5+
> > > >
> > > > Here it says the fix is valid from v4.5 onwards.
> > >
> > > Hmm... Adam, you marked the fix to apply to v4.9+, and then you said
> > > v4.4 needs a new patch (that's before the big copy/rename). Did you
> > > check the versions between 4.4 and 4.9? I would guess this one applies
> > > to v4.5+.
> >
> > I only tried 4.9 because it's listed as an LTS kernel.  The stuff
> > between 4.4 and 4.9 were EOL, so I didn't go back further.The 4.5+
> > is probably more accurate.  I would like to do the same thing for the
> > 4.4 kernel, but I am not sure the proper way to do that.
> 
> What is the correct protocol for patching 4.4?  I'd like to do that,
> but the patch would be unique to the 4.4.  Should I just submit the
> patch directly to stable and cc Tomi?

Yes, and document the heck out of why this is a 4.4-only patch, and why
we can't take whatever happened in newer kernels instead.

thanks,

greg k-h

Re: [PATCH] bcache: writeback: Remove unneeded variable i

[Coly Li]

On 2020/7/9 13:53, Xu Wang wrote:
> Remove unneeded variable i in bch_dirty_init_thread().
> 
> Signed-off-by: Xu Wang 

Add it into my testing queue. Thanks.

Coly Li

> ---
>  drivers/md/bcache/writeback.c | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
> index 1cf1e5016cb9..71801c086b82 100644
> --- a/drivers/md/bcache/writeback.c
> +++ b/drivers/md/bcache/writeback.c
> @@ -825,10 +825,8 @@ static int bch_dirty_init_thread(void *arg)
>   struct btree_iter iter;
>   struct bkey *k, *p;
>   int cur_idx, prev_idx, skip_nr;
> - int i;
>  
>   k = p = NULL;
> - i = 0;
>   cur_idx = prev_idx = 0;
>  
>   bch_btree_iter_init(&c->root->keys, &iter, NULL);
> 

[PATCH v4 1/2] dt-bindings: dma: Add bindings for intel LGM SOC

[Amireddy Mallikarjuna reddy]

Add DT bindings YAML schema for DMA controller driver
of Lightning Mountain(LGM) SoC.

Signed-off-by: Amireddy Mallikarjuna reddy 
---
v1:
- Initial version.

v2:
- Fix bot errors.

v3:
- No change.

v4:
- Address Thomas langer comments
---
 .../devicetree/bindings/dma/intel,ldma.yaml| 416 +
 1 file changed, 416 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml

diff --git a/Documentation/devicetree/bindings/dma/intel,ldma.yaml 
b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
new file mode 100644
index ..7f666b9812e4
--- /dev/null
+++ b/Documentation/devicetree/bindings/dma/intel,ldma.yaml
@@ -0,0 +1,416 @@
+# SPDX-License-Identifier: (GPL-2.0-only OR BSD-2-Clause)
+%YAML 1.2
+---
+$id: http://devicetree.org/schemas/dma/intel,ldma.yaml#
+$schema: http://devicetree.org/meta-schemas/core.yaml#
+
+title: Lightning Mountain centralized low speed DMA and high speed DMA 
controllers.
+
+maintainers:
+  - chuanhua@intel.com
+  - mallikarjunax.re...@intel.com
+
+properties:
+ $nodename:
+   pattern: "^dma(@.*)?$"
+
+ "#dma-cells":
+   const: 1
+
+ compatible:
+  anyOf:
+   - const: intel,lgm-cdma
+   - const: intel,lgm-dma2tx
+   - const: intel,lgm-dma1rx
+   - const: intel,lgm-dma1tx
+   - const: intel,lgm-dma0tx
+   - const: intel,lgm-dma3
+   - const: intel,lgm-toe-dma30
+   - const: intel,lgm-toe-dma31
+
+ reg:
+  maxItems: 1
+
+ clocks:
+  maxItems: 1
+
+ resets:
+  maxItems: 1
+
+ interrupts:
+  maxItems: 1
+
+ intel,dma-poll-cnt:
+   $ref: /schemas/types.yaml#definitions/uint32
+   description:
+ DMA descriptor polling counter. It may need fine tune according
+ to the system application scenario.
+
+ intel,dma-byte-en:
+   type: boolean
+   description:
+ DMA byte enable is only valid for DMA write(RX).
+ Byte enable(1) means DMA write will be based on the number of dwords
+ instead of the whole burst.
+
+ intel,dma-drb:
+type: boolean
+description:
+  DMA descriptor read back to make sure data and desc synchronization.
+
+ intel,dma-burst:
+$ref: /schemas/types.yaml#definitions/uint32
+description:
+   Specifiy the DMA burst size(in dwords), the valid value will be 8, 16, 
32.
+   Default is 16 for data path dma, 32 is for memcopy DMA.
+
+ intel,dma-polling-cnt:
+$ref: /schemas/types.yaml#definitions/uint32
+description:
+   DMA descriptor polling counter. It may need fine tune according to
+   the system application scenario.
+
+ intel,dma-desc-in-sram:
+type: boolean
+description:
+   DMA descritpors in SRAM or not. Some old controllers descriptors
+   can be in DRAM or SRAM. The new ones are all in SRAM.
+
+ intel,dma-orrc:
+$ref: /schemas/types.yaml#definitions/uint32
+description:
+   DMA outstanding read counter. The maximum value is 16, and it may
+   need fine tune according to the system application scenarios.
+
+ intel,dma-dburst-wr:
+type: boolean
+description:
+   Enable RX dynamic burst write. It only applies to RX DMA and memcopy 
DMA.
+
+
+ dma-ports:
+type: object
+description:
+   This sub-node must contain a sub-node for each DMA port.
+properties:
+  '#address-cells':
+const: 1
+  '#size-cells':
+const: 0
+
+patternProperties:
+  "^dma-ports@[0-9]+$":
+  type: object
+
+  properties:
+reg:
+  items:
+- enum: [0, 1, 2, 3, 4, 5]
+  description:
+ Which port this node refers to.
+
+intel,name:
+  $ref: /schemas/types.yaml#definitions/string-array
+  description:
+ Port name of each DMA port.
+
+intel,chans:
+  $ref: /schemas/types.yaml#/definitions/uint32-array
+  description:
+ The channels included on this port. Format is channel start
+ number and how many channels on this port.
+
+intel,burst:
+  $ref: /schemas/types.yaml#/definitions/uint32
+  description:
+ Specify the DMA port burst size, the valid value will be
+ 2, 4, 8. Default is 2 for data path dma.
+
+intel,txwgt:
+  $ref: /schemas/types.yaml#/definitions/uint32
+  description:
+ Specify the port transmit weight for QoS purpose. The valid
+ value is 1~7. Default value is 1.
+
+intel,endian:
+  $ref: /schemas/types.yaml#/definitions/uint32
+  description:
+ Specify the DMA port endiannes conversion due to SoC 
endianness difference.
+
+  required:
+- reg
+- intel,name
+- intel,chans
+
+
+ dma-channels:
+type: object
+description:
+   This sub-node must contain a sub-node for each DMA channel.
+properties:
+  '#address-cells':
+const

[PATCH v4 0/2] Add Intel LGM soc DMA support

[Amireddy Mallikarjuna reddy]

Add DMA controller driver for Lightning Mountain(LGM) family of SoCs.

The main function of the DMA controller is the transfer of data from/to any
DPlus compliant peripheral to/from the memory. A memory to memory copy
capability can also be configured.
This ldma driver is used for configure the device and channnels for data
and control paths.

These controllers provide DMA capabilities for a variety of on-chip
devices such as SSC, HSNAND and GSWIP.

-
Future Plans:
-
LGM SOC also supports Hardware Memory Copy engine.
The role of the HW Memory copy engine is to offload memory copy operations
from the CPU.

Amireddy Mallikarjuna reddy (2):
  dt-bindings: dma: Add bindings for intel LGM SOC
  Add Intel LGM soc DMA support.

 .../devicetree/bindings/dma/intel,ldma.yaml|  416 +
 drivers/dma/Kconfig|2 +
 drivers/dma/Makefile   |1 +
 drivers/dma/lgm/Kconfig|9 +
 drivers/dma/lgm/Makefile   |2 +
 drivers/dma/lgm/lgm-dma.c  | 1941 
 include/linux/dma/lgm_dma.h|   27 +
 7 files changed, 2398 insertions(+)
 create mode 100644 Documentation/devicetree/bindings/dma/intel,ldma.yaml
 create mode 100644 drivers/dma/lgm/Kconfig
 create mode 100644 drivers/dma/lgm/Makefile
 create mode 100644 drivers/dma/lgm/lgm-dma.c
 create mode 100644 include/linux/dma/lgm_dma.h

-- 
2.11.0

Re: [f2fs-dev] [PATCH] f2fs: ignore when len of range in f2fs_sec_trim_file is zero

[Daeho Jeong]

I can add it~

2020년 7월 9일 (목) 오후 2:39, Jaegeuk Kim 님이 작성:
>
> On 07/09, Chao Yu wrote:
> > On 2020/7/9 9:57, Daeho Jeong wrote:
> > > From: Daeho Jeong 
> > >
> > > When end_addr comes to zero, it'll trigger different behaviour.
> > > To prevent this, we need to ignore the case of that range.len is
> > > zero in the function.
> > >
> > > Signed-off-by: Daeho Jeong 
> > > ---
> > >  fs/f2fs/file.c | 7 +++
> > >  1 file changed, 3 insertions(+), 4 deletions(-)
> > >
> > > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > > index 368c80f8e2a1..98b0a8dbf669 100644
> > > --- a/fs/f2fs/file.c
> > > +++ b/fs/f2fs/file.c
> > > @@ -3813,15 +3813,14 @@ static int f2fs_sec_trim_file(struct file *filp, 
> > > unsigned long arg)
> > > file_start_write(filp);
> > > inode_lock(inode);
> > >
> > > -   if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode)) {
> > > +   if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode) ||
> > > +   range.start >= inode->i_size) {
> > > ret = -EINVAL;
> > > goto err;
> > > }
> > >
> > > -   if (range.start >= inode->i_size) {
> > > -   ret = -EINVAL;
> > > +   if (range.len == 0)
> > > goto err;
> > > -   }
> > >
> > > if (inode->i_size - range.start < range.len) {
> > > ret = -E2BIG;
> >
> > How about the case trimming last partial written block?
> >
> > i_size = 8000
> > range.start = 4096
> > range.len = 4096
> >
> > Do we need to roundup(isize, PAGE_SIZE) before comparison?
>
> If we want to trim whole file, do we need to give the exact i_size?
> Wouldn't it be better to give trim(0, -1)?
>
> >
> > Thanks,
> >
> > >
> >
> >
> > ___
> > Linux-f2fs-devel mailing list
> > linux-f2fs-de...@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

[PATCH v2] net: ethernet: mtk_eth_soc: fix mtu warning

[Frank Wunderlich]

From: René van Dorst 

in recent Kernel-Versions there are warnings about incorrect MTU-Size
like these:

mt7530 mdio-bus:00: nonfatal error -95 setting MTU on port x
eth0: mtu greater than device maximum
mtk_soc_eth 1b10.ethernet eth0: error -22 setting MTU to include DSA 
overhead

Fixes: bfcb813203e6 ("net: dsa: configure the MTU for switch ports")
Fixes: 72579e14a1d3 ("net: dsa: don't fail to probe if we couldn't set the MTU")
Fixes: 7a4c53bee332 ("net: report invalid mtu value via netlink extack")
Signed-off-by: René van Dorst 
Signed-off-by: Frank Wunderlich 
---
changes in v2:
  Fixes: tag show 12-chars of sha1 and moved above other tags
---
 drivers/net/ethernet/mediatek/mtk_eth_soc.c | 4 
 1 file changed, 4 insertions(+)

diff --git a/drivers/net/ethernet/mediatek/mtk_eth_soc.c 
b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
index 85735d32ecb0..00e3d70f7d07 100644
--- a/drivers/net/ethernet/mediatek/mtk_eth_soc.c
+++ b/drivers/net/ethernet/mediatek/mtk_eth_soc.c
@@ -2891,6 +2891,10 @@ static int mtk_add_mac(struct mtk_eth *eth, struct 
device_node *np)
eth->netdev[id]->irq = eth->irq[0];
eth->netdev[id]->dev.of_node = np;

+   eth->netdev[id]->mtu = 1536;
+   eth->netdev[id]->min_mtu = ETH_MIN_MTU;
+   eth->netdev[id]->max_mtu = 1536;
+
return 0;

 free_netdev:
--
2.25.1

[PATCH] bcache: writeback: Remove unneeded variable i

[Xu Wang]

Remove unneeded variable i in bch_dirty_init_thread().

Signed-off-by: Xu Wang 
---
 drivers/md/bcache/writeback.c | 2 --
 1 file changed, 2 deletions(-)

diff --git a/drivers/md/bcache/writeback.c b/drivers/md/bcache/writeback.c
index 1cf1e5016cb9..71801c086b82 100644
--- a/drivers/md/bcache/writeback.c
+++ b/drivers/md/bcache/writeback.c
@@ -825,10 +825,8 @@ static int bch_dirty_init_thread(void *arg)
struct btree_iter iter;
struct bkey *k, *p;
int cur_idx, prev_idx, skip_nr;
-   int i;
 
k = p = NULL;
-   i = 0;
cur_idx = prev_idx = 0;
 
bch_btree_iter_init(&c->root->keys, &iter, NULL);
-- 
2.17.1

Re: [PATCH v3] HID: i2c-hid: Enable touchpad wakeup from Suspend-to-Idle

[Kai-Heng Feng]

Hi,

> On Jul 3, 2020, at 20:27, Hans de Goede  wrote:
> 
> Hi,
> 
> On 7/1/20 8:46 AM, Kai-Heng Feng wrote:
>>> On Jun 19, 2020, at 17:56, Hans de Goede  wrote:
>>> 
>>> Hi,
>>> 
>>> On 6/19/20 6:16 AM, Kai-Heng Feng wrote:
 Hi,
> On Jun 18, 2020, at 23:28, Hans de Goede  wrote:
> 
> Hi,
> 
> On 6/18/20 4:55 PM, Kai-Heng Feng wrote:
>> Many laptops can be woken up from Suspend-to-Idle by touchpad. This is
>> also the default behavior on other OSes.
>> So let's enable the wakeup support if the system defaults to
>> Suspend-to-Idle.
> 
> I have been debugging a spurious wakeup issue on an Asus T101HA,
> where the system would not stay suspended when the lid was closed.
> 
> The issue turns out to be that the touchpad is generating touch
> events when the lid/display gets close to the touchpad. In this case
> wakeup is already enabled by default because it is an USB device.
 Sounds like a mechanical/hardware issue to me.
>>> 
>>> Nope, the laptop is pretty much in new state.
>> Ack.
>>> 
 I've seen some old laptops have the same issue.
 Swollen battery can push up the touchpad, makes it contact to touchscreen, 
 and wakes up the system.
>>> 
>>> This is a 2-in-1 with a detachable keyboard, which is why the
>>> kbd/touchpad is a USB device rather then i2c-hid. Even if the
>>> battery were swollen this would push up the back cover of the
>>> tablet.
>> What's the behavior on Windows?
>> I wonder if Windows has a different wakeup policy?
>> Like disable remote wakeup for USB touchpad and touchscreen?
> 
> I'm afraid I no longer have Windows on the device, so I cannot
> test this. I guess that Windows disables the builtin touchpad and
> touchscreenn when the lid is closed. That is sensible to do from
> a power-management pov even when not suspending, but just closing
> the lid and using an external monitor + kbd.

Ok. This seems worth further investigation.

> 
> So I do not believe that this is a good idea, most current devices
> with a HID multi-touch touchpad use i2c-hid and also use S2idle,
> so this will basically enable wakeup by touchpad on almost all
> current devices.
 However, it's really handy to wake up the system from touchpad.
>>> 
>>> I agree this is somewhat handy, but the keyboard (space-bar) is
>>> usually sitting right next to it. So we can live without it,
>>> we really need to fix the spurious wakeup issue first, once
>>> that is fixed I'm fine with enabling wakeup by touchpad.
>> That's true. Spacebar is a good enough alternative.
>>> 
> There will likely be other devices with the same issue as the T101HA,
> but currently we are not seeing this issue because by default i2c-hid
> devices do not have wakeup enabled. This change will thus likely cause
> new spurious wakeup issues on more devices. So this seems like a
> bad idea.
 But only under lid is closed?
>>> 
>>> Right.
>>> 
 I wonder if it's okay to handle the case in s2idle_loop() or in userspace?
 Lid close -> Wakeup event from touchpad -> Found the lid is closed
 -> Turn off touchpad wakeup -> continue suspend.
>>> 
>>> I've discussed doing something about the spurious wakeup issue in
>>> the kernel with the the kernel input maintainer (Dmitry) here:
>>> 
>>> https://lore.kernel.org/linux-acpi/964ca07a-3da5-101f-7edf-64bdeec98...@redhat.com/
>>> 
>>> He was quite clear that this must be fixed in userspace. We did
>>> come up with a plan for fixing this in userspace:
>>> 
>>> 1) Have udev-rules setting using hwdb for quirks which tags
>>> some input devices as "input-disable-wake-on-closed-lid".
>>> A simple udev rule could tag all i2c-hid touchpads with this and
>>> for the detachable USB keyboards with builtin touchpad some
>>> 2-in-1s have we can then use quirks in hwdb to set the tag
>>> on those.
>> Maybe we can avoid using quirks in hwdb, external USB devices should have 
>> "Removable" bit set (i.e. it's external).
> 
> At the USB level there only is a somewhat reliable "removal" bit
> for storage devices, defined at the storage protocol level.
> 
> For other devices there is:
> 
> cat /sys/bus/usb/devices/1-8/removable
> 
> This comes from the ACPI tables parsed by:
> drivers/usb/core/usb-acpi.c
> 
> Which set the port's connect_type variable.

Actually most laptops I've used correctly marked internally connected USB 2 
device with Removable bit.
And that's the reason why USB2 LPM, which only enables when Removable == 1, 
caused many issues for us.

> 
> I've tested this on a bunch of 2-in-1s with detachable USB
> keyboards and it is almost completely random and not at
> all related to the reality (both for the kbd-dock connector
> and for other USB ports) this info is so unreliable it is
> pretty much useless.

Ok, that means USB2 LPM will be inadvertently enabled for those devices...
Doesn't sound right.

> 
> And the kbd-dock is special anyways, the dock is removable,
> but when docked /

Re: [PATCH v2] vmlinux.lds: add PGO and AutoFDO input sections

[Kees Cook]

On Wed, Jul 08, 2020 at 04:13:54PM -0700, Nick Desaulniers wrote:
> On Thu, Jul 2, 2020 at 8:57 AM Kees Cook  wrote:
> >
> > This looks good to me. Do you want me to carry it as part of the orphan
> > series? (It doesn't look like it'll collide, so that's not needed, but I
> > can if that makes things easier.)
> >
> > Acked-by: Kees Cook 
> 
> If you would be so kind, I'd owe you yet another beer!

Yup! It's on my list; I've been clearing other stuff so I can do another
revision. (I want to move some things out of discard and into 0-size
asserts, and possibly collect Arvind's runtime relocations series too
(since it seems basically done but no x86 maintainers have snagged it).

-- 
Kees Cook

drm: BUG: unable to handle page fault for address: 17ec6000

[Paul Menzel]

Dear Linux folks,


Building Linux v5.8-rc4-25-gbfe91da29bfad with Clang/LLD 
1:11~++20200701093119+ffee8040534-1~exp1 from Debian experimental for 
32-bit (`ARCH=i386`), starting Weston (Wayland) or X.Org Server results 
in non-working screen, and Linux shows the trace below [1].



[  502.044997] BUG: unable to handle page fault for address: 17ec6000
[  502.045650] #PF: supervisor write access in kernel mode
[  502.046301] #PF: error_code(0x0002) - not-present page
[  502.046956] *pde =  
[  502.047612] Oops: 0002 [#1] SMP

[  502.048269] CPU: 0 PID: 2125 Comm: Xorg.wrap Not tainted 
5.8.0-rc4-00105-g4da71f1ee6263 #141
[  502.048967] Hardware name: System manufacturer System Product Name/F2A85-M 
PRO, BIOS 6601 11/25/2014
[  502.049686] EIP: __srcu_read_lock+0x11/0x20
[  502.050413] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 
c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 
83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
[  502.052027] EAX:  EBX: f36671b8 ECX:  EDX: 0286
[  502.052856] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c
[  502.053695] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[  502.054543] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0
[  502.055402] Call Trace:
[  502.056275]  drm_minor_acquire+0x6f/0x140 [drm]
[  502.057162]  drm_stub_open+0x2e/0x110 [drm]
[  502.058049]  chrdev_open+0xdd/0x1e0
[  502.058937]  do_dentry_open+0x21d/0x330
[  502.059828]  vfs_open+0x23/0x30
[  502.060718]  path_openat+0x947/0xd60
[  502.061610]  ? unlink_anon_vmas+0x53/0x120
[  502.062504]  do_filp_open+0x6d/0x100
[  502.063404]  ? __alloc_fd+0x73/0x140
[  502.064305]  do_sys_openat2+0x1b3/0x2a0
[  502.065217]  __ia32_sys_openat+0x90/0xb0
[  502.066128]  ? prepare_exit_to_usermode+0xa/0x20
[  502.067046]  do_fast_syscall_32+0x68/0xd0
[  502.067970]  do_SYSENTER_32+0x12/0x20
[  502.068902]  entry_SYSENTER_32+0x9f/0xf2
[  502.069839] EIP: 0xb7ef14f9
[  502.070764] Code: Bad RIP value.
[  502.071689] EAX: ffda EBX: ff9c ECX: bfa6a2ac EDX: 8002
[  502.072654] ESI:  EDI: b7ed1000 EBP: bfa6b2c8 ESP: bfa6a1c0
[  502.073630] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0246
[  502.074615] Modules linked in: af_packet k10temp r8169 realtek i2c_piix4 
snd_hda_codec_realtek snd_hda_codec_generic ohci_pci ohci_hcd ehci_pci 
snd_hda_codec_hdmi ehci_hcd radeon i2c_algo_bit snd_hda_intel ttm 
snd_intel_dspcfg snd_hda_codec drm_kms_helper snd_hda_core snd_pcm cfbimgblt 
cfbcopyarea cfbfillrect snd_timer sysimgblt syscopyarea sysfillrect snd 
fb_sys_fops xhci_pci xhci_hcd soundcore acpi_cpufreq drm 
drm_panel_orientation_quirks agpgart ipv6 nf_defrag_ipv6
[  502.077895] CR2: 17ec6000
[  502.079050] ---[ end trace ced4517b63a6db26 ]---
[  502.080214] EIP: __srcu_read_lock+0x11/0x20
[  502.081392] Code: 83 e0 03 50 56 68 72 c6 99 dd 68 46 c6 99 dd e8 3a c8 fe ff 83 
c4 10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 
83 44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
[  502.083891] EAX:  EBX: f36671b8 ECX:  EDX: 0286
[  502.085148] ESI: f3f94eb8 EDI: f3e51c00 EBP: f303dd9c ESP: f303dd9c
[  502.086406] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010246
[  502.087675] CR0: 80050033 CR2: 17ec6000 CR3: 2eea2000 CR4: 000406d0



$ dmesg | ./scripts/decodecode
[ 55.784870] Code: 83 e0 03 50 56 68 ca c6 99 cf 68 9e c6 99 cf e8 3a c8 fe ff 83 c4 
10 eb ce 0f 1f 44 00 00 55 89 e5 8b 48 68 8b 40 7c 83 e1 01 <64> ff 04 88 f0 83 
44 24 fc 00 89 c8 5d c3 90 0f 1f 44 00 00 55 89
All code

   0:   83 e0 03and$0x3,%eax
   3:   50  push   %eax
   4:   56  push   %esi
   5:   68 ca c6 99 cf  push   $0xcf99c6ca
   a:   68 9e c6 99 cf  push   $0xcf99c69e
   f:   e8 3a c8 fe ff  call   0xfffec84e
  14:   83 c4 10add$0x10,%esp
  17:   eb ce   jmp0xffe7
  19:   0f 1f 44 00 00  nopl   0x0(%eax,%eax,1)
  1e:   55  push   %ebp
  1f:   89 e5   mov%esp,%ebp
  21:   8b 48 68mov0x68(%eax),%ecx
  24:   8b 40 7cmov0x7c(%eax),%eax
  27:   83 e1 01and$0x1,%ecx
  2a:*  64 ff 04 88 incl   %fs:(%eax,%ecx,4)<-- 
trapping instruction
  2e:   f0 83 44 24 fc 00   lock addl $0x0,-0x4(%esp)
  34:   89 c8   mov%ecx,%eax
  36:   5d  pop%ebp
  37:	c3   	ret
  38:	90   	nop

  39:   0f 1f 44 00 00  nopl   0x0(%eax,%eax,1)
  3e:   55  push   %ebp
  3f:   89  .byte 0x89

Code starting with the faulting instruction
===
   0:   64 ff 04 88 incl   %fs:(%eax,%ecx,4)
   4:   f0 83 44 24 fc 00   lock addl $

[PATCH] debugfs: file: Remove unnecessary cast in kfree()

[Xu Wang]

Remove unnecassary casts in the argument to kfree.

Signed-off-by: Xu Wang 
---
 fs/debugfs/file.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/debugfs/file.c b/fs/debugfs/file.c
index ae49a55bda00..3753c4c484fc 100644
--- a/fs/debugfs/file.c
+++ b/fs/debugfs/file.c
@@ -273,7 +273,7 @@ static int full_proxy_release(struct inode *inode, struct 
file *filp)
r = real_fops->release(inode, filp);
 
replace_fops(filp, d_inode(dentry)->i_fop);
-   kfree((void *)proxy_fops);
+   kfree(proxy_fops);
fops_put(real_fops);
return r;
 }
-- 
2.17.1

Re: [f2fs-dev] [PATCH] f2fs: ignore when len of range in f2fs_sec_trim_file is zero

[Jaegeuk Kim]

On 07/09, Chao Yu wrote:
> On 2020/7/9 9:57, Daeho Jeong wrote:
> > From: Daeho Jeong 
> > 
> > When end_addr comes to zero, it'll trigger different behaviour.
> > To prevent this, we need to ignore the case of that range.len is
> > zero in the function.
> > 
> > Signed-off-by: Daeho Jeong 
> > ---
> >  fs/f2fs/file.c | 7 +++
> >  1 file changed, 3 insertions(+), 4 deletions(-)
> > 
> > diff --git a/fs/f2fs/file.c b/fs/f2fs/file.c
> > index 368c80f8e2a1..98b0a8dbf669 100644
> > --- a/fs/f2fs/file.c
> > +++ b/fs/f2fs/file.c
> > @@ -3813,15 +3813,14 @@ static int f2fs_sec_trim_file(struct file *filp, 
> > unsigned long arg)
> > file_start_write(filp);
> > inode_lock(inode);
> >  
> > -   if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode)) {
> > +   if (f2fs_is_atomic_file(inode) || f2fs_compressed_file(inode) ||
> > +   range.start >= inode->i_size) {
> > ret = -EINVAL;
> > goto err;
> > }
> >  
> > -   if (range.start >= inode->i_size) {
> > -   ret = -EINVAL;
> > +   if (range.len == 0)
> > goto err;
> > -   }
> >  
> > if (inode->i_size - range.start < range.len) {
> > ret = -E2BIG;
> 
> How about the case trimming last partial written block?
> 
> i_size = 8000
> range.start = 4096
> range.len = 4096
> 
> Do we need to roundup(isize, PAGE_SIZE) before comparison?

If we want to trim whole file, do we need to give the exact i_size?
Wouldn't it be better to give trim(0, -1)?

> 
> Thanks,
> 
> > 
> 
> 
> ___
> Linux-f2fs-devel mailing list
> linux-f2fs-de...@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/linux-f2fs-devel

Re: [PATCH v2] dmaengine: check device and channel list for empty

[Jiri Slaby]

On 07. 07. 20, 17:42, Dave Jiang wrote:
> On 7/6/2020 11:05 PM, Jiri Slaby wrote:
>> On 26. 06. 20, 20:09, Dave Jiang wrote:
>>> Check dma device list and channel list for empty before iterate as the
>>> iteration function assume the list to be not empty. With devices and
>>> channels now being hot pluggable this is a condition that needs to be
>>> checked. Otherwise it can cause the iterator to spin forever.
>>
>> Could you be a little bit more specific how this can spin forever? I.e.
>> can you attach a stacktrace of such a behaviour?
> 
> I can't seem to find the original splat that lead me to the conclusion
> of it's spinning forever. As I recall, the issue seems to produce
> different splats and not always consistent in being reproduced. Here's a
> partial splat that was tracked by the internal bug database. Since with
> the dma device and channel list being are hot added and removed, the
> device and channel lists can be empty. The list_entry() and friends
> expect the list to not be empty (according to header comment), I added
> the check to ensure that isn't the case before using them in dmaengine.

Yes, the comment states that as it is true: you receive a
wild/non-checkable pointer if you do list_entry on an empty list. BUT
have you actually read what I wrote:

>> As in the empty case, "&pos->member" is "head" (look into
>> list_for_each_entry) and the for loop should loop exactly zero times.

HERE 

> With the fix, we can no longer produce any of the splats. So maybe the
> above was a bad description of the issue.

No, not only the description, worse, the patch proper looks wrong.

> [ 4216.048375]  ? dma_channel_rebalance+0x7b/0x250
> [ 4216.056360]  dma_async_device_register+0x349/0x3a0
> [ 4216.064604]  idxd_register_dma_device+0x90/0xc0 [idxd]
> [ 4216.073175]  idxd_config_bus_probe.cold+0x7d/0x1fc [idxd]

So, the good part in the patch is the fixed locking in
dma_async_device_register. Otherwise it adds nonsense checks. So you
fixed the issue only by a chance, by a side effect as Peter pointed out.
Leaving aside that you broke dma_request_chan -- that could happen to
anybody.

Vinod, please drop/revert this patch. Then start over only with
dma_async_device_register fixed locking.

thanks,
-- 
js

[PATCH v2 2/2] memory: samsung: exynos5422-dmc: Use delayed timer as default

[Chanwoo Choi]

Use delayed timer as default instead of deferrable timer
in order to monitor the DMC status regardless of CPU idle.

Reviewed-by: Krzysztof Kozlowski 
Reviewed-by: Lukasz Luba 
Signed-off-by: Chanwoo Choi 
---
 drivers/memory/samsung/exynos5422-dmc.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/drivers/memory/samsung/exynos5422-dmc.c 
b/drivers/memory/samsung/exynos5422-dmc.c
index 25196d6268e2..93e9c2429c0d 100644
--- a/drivers/memory/samsung/exynos5422-dmc.c
+++ b/drivers/memory/samsung/exynos5422-dmc.c
@@ -945,6 +945,7 @@ static int exynos5_dmc_get_cur_freq(struct device *dev, 
unsigned long *freq)
  * It provides to the devfreq framework needed functions and polling period.
  */
 static struct devfreq_dev_profile exynos5_dmc_df_profile = {
+   .timer = DEVFREQ_TIMER_DELAYED,
.target = exynos5_dmc_target,
.get_dev_status = exynos5_dmc_get_status,
.get_cur_freq = exynos5_dmc_get_cur_freq,
-- 
2.17.1

[PATCH v2 1/2] PM / devfreq: Add support delayed timer for polling mode

[Chanwoo Choi]

Until now, the devfreq driver using polling mode like simple_ondemand
governor have used only deferrable timer for reducing the redundant
power consumption. It reduces the CPU wake-up from idle due to polling mode
which check the status of Non-CPU device.

But, it has a problem for Non-CPU device like DMC device with DMA operation.
Some Non-CPU device need to do monitor continuously regardless of CPU state
in order to decide the proper next status of Non-CPU device.

So, add support the delayed timer for polling mode to support
the repetitive monitoring. The devfreq driver and user can select
the kind of timer on either deferrable and delayed timer.

For example, change the timer type of DMC device
based on Exynos5422-based Odroid-XU3 as following:

- If want to use deferrable timer as following:
echo deferrable > /sys/class/devfreq/10c2.memory-controller/timer

- If want to use delayed timer as following:
echo delayed > /sys/class/devfreq/10c2.memory-controller/timer

Reviewed-by: Bartlomiej Zolnierkiewicz 
Reviewed-by: Lukasz Luba 
Signed-off-by: Chanwoo Choi 
---
 Documentation/ABI/testing/sysfs-class-devfreq | 12 +++
 drivers/devfreq/devfreq.c | 86 ++-
 include/linux/devfreq.h   |  9 ++
 3 files changed, 106 insertions(+), 1 deletion(-)

diff --git a/Documentation/ABI/testing/sysfs-class-devfreq 
b/Documentation/ABI/testing/sysfs-class-devfreq
index 9758eb85ade3..deefffb3bbe4 100644
--- a/Documentation/ABI/testing/sysfs-class-devfreq
+++ b/Documentation/ABI/testing/sysfs-class-devfreq
@@ -108,3 +108,15 @@ Description:
frequency requested by governors and min_freq.
The max_freq overrides min_freq because max_freq may be
used to throttle devices to avoid overheating.
+
+What:  /sys/class/devfreq/.../timer
+Date:  July 2020
+Contact:   Chanwoo Choi 
+Description:
+   This ABI shows and stores the kind of work timer by users.
+   This work timer is used by devfreq workqueue in order to
+   monitor the device status such as utilization. The user
+   can change the work timer on runtime according to their demand
+   as following:
+   echo deferrable > /sys/class/devfreq/.../timer
+   echo delayed > /sys/class/devfreq/.../timer
diff --git a/drivers/devfreq/devfreq.c b/drivers/devfreq/devfreq.c
index 52b9c3e141f3..10f1543df84b 100644
--- a/drivers/devfreq/devfreq.c
+++ b/drivers/devfreq/devfreq.c
@@ -49,6 +49,11 @@ static LIST_HEAD(devfreq_governor_list);
 static LIST_HEAD(devfreq_list);
 static DEFINE_MUTEX(devfreq_list_lock);
 
+static const char timer_name[][DEVFREQ_NAME_LEN] = {
+   [DEVFREQ_TIMER_DEFERRABLE] = { "deferrable" },
+   [DEVFREQ_TIMER_DELAYED] = { "delayed" },
+};
+
 /**
  * find_device_devfreq() - find devfreq struct using device pointer
  * @dev:   device pointer used to lookup device devfreq.
@@ -454,7 +459,17 @@ void devfreq_monitor_start(struct devfreq *devfreq)
if (devfreq->governor->interrupt_driven)
return;
 
-   INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
+   switch (devfreq->profile->timer) {
+   case DEVFREQ_TIMER_DEFERRABLE:
+   INIT_DEFERRABLE_WORK(&devfreq->work, devfreq_monitor);
+   break;
+   case DEVFREQ_TIMER_DELAYED:
+   INIT_DELAYED_WORK(&devfreq->work, devfreq_monitor);
+   break;
+   default:
+   return;
+   }
+
if (devfreq->profile->polling_ms)
queue_delayed_work(devfreq_wq, &devfreq->work,
msecs_to_jiffies(devfreq->profile->polling_ms));
@@ -771,6 +786,11 @@ struct devfreq *devfreq_add_device(struct device *dev,
devfreq->data = data;
devfreq->nb.notifier_call = devfreq_notifier_call;
 
+   if (devfreq->profile->timer < 0
+   || devfreq->profile->timer >= DEVFREQ_TIMER_NUM) {
+   goto err_out;
+   }
+
if (!devfreq->profile->max_state && !devfreq->profile->freq_table) {
mutex_unlock(&devfreq->lock);
err = set_freq_table(devfreq);
@@ -1625,6 +1645,69 @@ static ssize_t trans_stat_store(struct device *dev,
 }
 static DEVICE_ATTR_RW(trans_stat);
 
+static ssize_t timer_show(struct device *dev,
+struct device_attribute *attr, char *buf)
+{
+   struct devfreq *df = to_devfreq(dev);
+
+   if (!df->governor)
+   return -EINVAL;
+
+   return sprintf(buf, "%s\n", timer_name[df->profile->timer]);
+}
+
+static ssize_t timer_store(struct device *dev, struct device_attribute *attr,
+ const char *buf, size_t count)
+{
+   struct devfreq *df = to_devfreq(dev);
+   char str_timer[DEVFREQ_NAME_LEN + 1];
+   int timer = -1;
+   int ret = 0, i;
+
+   if (!df->governor)
+   return -EINVAL;
+

[PATCH v2 0/2] PM / devfreq: Add delayed timer for polling

[Chanwoo Choi]

Add the delayed timer to devfreq framework in order to support
the periodical polling mode without stop caused by CPU idle state.
Some Non-CPU device must need to monitor the device status like
utilization regardless of CPU state.

- patch1 explains the detailed reason why the delayed timer is required.
- patch2 initializes that exynos5422-dmc device use delayed timer as default
instead of deferrable timer.

Changes from v2:
- Add reviewed-by tag
- Fix typo on patch description
- Remove 'RFC' work from patch title
- Check whether 'df->governor' is NULL or not on timer_store()

Chanwoo Choi (2):
  PM / devfreq: Add support delayed timer for polling mode
  memory: samsung: exynos5422-dmc: Use delayed timer as default

 Documentation/ABI/testing/sysfs-class-devfreq | 12 +++
 drivers/devfreq/devfreq.c | 86 ++-
 drivers/memory/samsung/exynos5422-dmc.c   |  1 +
 include/linux/devfreq.h   |  9 ++
 4 files changed, 107 insertions(+), 1 deletion(-)

-- 
2.17.1

Re: [RFC PATCH 2/2] memory: samsung: exynos5422-dmc: Use delayed timer as default

[Chanwoo Choi]

Hi Krzysztof,

On 7/8/20 9:33 PM, Krzysztof Kozlowski wrote:
> On Fri, Jul 03, 2020 at 03:26:22PM +0900, Chanwoo Choi wrote:
>> Use delayed timer as default instead of deferrable timer
>> in order to monitor the DMC status regardless of CPU idle.
>>
>> Signed-off-by: Chanwoo Choi 
>> ---
>>  drivers/memory/samsung/exynos5422-dmc.c | 1 +
>>  1 file changed, 1 insertion(+)
> 
> If you want to take this through devfreq tree, I'm fine:
> Reviewed-by: Krzysztof Kozlowski 

OK. I'll take it to devfreq-next for v5.9-rc1. Thanks.

> 
> Otherwise I could grab it through samsung-soc after devfreq change ends
> in mainline.
> 
> Best regards,
> Krzysztof
> 
> 


-- 
Best Regards,
Chanwoo Choi
Samsung Electronics

Re: [PATCH] riscv: Enable ELF-ASLR for riscv

[Alex Ghiti]

Hi Guo,

Le 7/9/20 à 12:38 AM, guo...@kernel.org a écrit :

From: Guo Ren 

Let riscv enable randomizes the stack, heap and binary images of
ELF binaries. Seems it's ok at all after qemu & chip test and
there is no founded side effect.

So just simply select ARCH_HAS_ELF_RANDOMIZE :)

Signed-off-by: Guo Ren 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Zong Li 
Cc: Greentime Hu 
---
  arch/riscv/Kconfig | 1 +
  1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 91bfc6c..eed6647 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -20,6 +20,7 @@ config RISCV
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_MMIOWB
select ARCH_HAS_PTE_SPECIAL
+   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU



Actually it is already the case: ARCH_HAS_ELF_RANDOMIZE is already 
selected by ARCH_WANT_DEFAULT_TOPDOWN_MMAP_LAYOUT.


Thanks,

Alex

Re: remove dead bdi congestion leftovers

[Christoph Hellwig]

On Wed, Jul 08, 2020 at 05:14:29PM -0600, Jens Axboe wrote:
> On 7/1/20 3:06 AM, Christoph Hellwig wrote:
> > Hi Jens,
> > 
> > we have a lot of bdi congestion related code that is left around without
> > any use.  This series removes it in preparation of sorting out the bdi
> > lifetime rules properly.
> 
> Please run series like this through a full compilation, for both this one
> and the previous series I had to fix up issues like this:
> 
> drivers/md/bcache/request.c: In function ‘bch_cached_dev_request_init’:
> drivers/md/bcache/request.c:1233:18: warning: unused variable ‘g’ 
> [-Wunused-variable]
>  1233 |  struct gendisk *g = dc->disk.disk;
>   |  ^
> drivers/md/bcache/request.c: In function ‘bch_flash_dev_request_init’:
> drivers/md/bcache/request.c:1320:18: warning: unused variable ‘g’ 
> [-Wunused-variable]
>  1320 |  struct gendisk *g = d->disk;
>   |  ^
> 
> Did the same here, applied it.

And just like the previous one I did, and the compiler did not complain.
There must be something about certain gcc versions not warning about
variables that are initialized but not otherwise used.

Re: [PATCH bpf-next v3 2/4] bpf: Implement bpf_local_storage for inodes

[kernel test robot]

Hi KP,

I love your patch! Perhaps something to improve:

[auto build test WARNING on bpf-next/master]

url:
https://github.com/0day-ci/linux/commits/KP-Singh/Generalizing-bpf_local_storage/20200709-085810
base:   https://git.kernel.org/pub/scm/linux/kernel/git/bpf/bpf-next.git master
config: mips-allyesconfig (attached as .config)
compiler: mips-linux-gcc (GCC) 9.3.0
reproduce (this is a W=1 build):
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
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=mips 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

>> kernel/bpf/bpf_inode_storage.c:274:17: warning: no previous prototype for 
>> 'inode_storage_map_alloc' [-Wmissing-prototypes]
 274 | struct bpf_map *inode_storage_map_alloc(union bpf_attr *attr)
 | ^~~
>> kernel/bpf/bpf_inode_storage.c:286:6: warning: no previous prototype for 
>> 'inode_storage_map_free' [-Wmissing-prototypes]
 286 | void inode_storage_map_free(struct bpf_map *map)
 |  ^~

vim +/inode_storage_map_alloc +274 kernel/bpf/bpf_inode_storage.c

   273  
 > 274  struct bpf_map *inode_storage_map_alloc(union bpf_attr *attr)
   275  {
   276  struct bpf_local_storage_map *smap;
   277  
   278  smap = bpf_local_storage_map_alloc(attr);
   279  if (IS_ERR(smap))
   280  return ERR_CAST(smap);
   281  
   282  smap->cache_idx = cache_idx_get_inode();
   283  return &smap->map;
   284  }
   285  
 > 286  void inode_storage_map_free(struct bpf_map *map)
   287  {
   288  struct bpf_local_storage_map *smap;
   289  
   290  smap = (struct bpf_local_storage_map *)map;
   291  cache_idx_free_inode(smap->cache_idx);
   292  bpf_local_storage_map_free(smap);
   293  }
   294  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

[PATCH] f2fs: don't skip writeback of quota data

[Jaegeuk Kim]

It doesn't need to bypass flushing quota data in background.

Signed-off-by: Jaegeuk Kim 
---
 fs/f2fs/data.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/fs/f2fs/data.c b/fs/f2fs/data.c
index 44645f4f914b6..72e8b50e588c1 100644
--- a/fs/f2fs/data.c
+++ b/fs/f2fs/data.c
@@ -3148,7 +3148,7 @@ static int __f2fs_write_data_pages(struct address_space 
*mapping,
if (unlikely(is_sbi_flag_set(sbi, SBI_POR_DOING)))
goto skip_write;
 
-   if ((S_ISDIR(inode->i_mode) || IS_NOQUOTA(inode)) &&
+   if (S_ISDIR(inode->i_mode) &&
wbc->sync_mode == WB_SYNC_NONE &&
get_dirty_pages(inode) < nr_pages_to_skip(sbi, DATA) &&
f2fs_available_free_memory(sbi, DIRTY_DENTS))
-- 
2.27.0.383.g050319c2ae-goog

Re: [PATCH] Input: elan_i2c - Add more hardware ID for Lenovo laptop

['Dmitry Torokhov']

On Mon, Dec 02, 2019 at 11:07:26AM +0800, Dave.Wang wrote:
> Hi Dmitry,
> 
> List device with its corresponding hardware ID as below patch,
> Please check , thanks!
> 
> Add more hardware ID for Lenovo laptop.
> 
> Signed-off-by: Dave Wang 

Applied, thank you.

-- 
Dmitry

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

[Peng Fan]

Very sorry for that, I will re-send v2 later.

"Stephen Rothwell" wrote:
> Hi all,
> 
> After merging the spi tree, today's linux-next build (arm
> multi_v7_defconfig) produced this warning:
> 
> drivers/spi/spi-atmel.c: In function 'atmel_spi_probe':
> drivers/spi/spi-atmel.c:1680:1: warning: label 'out_free' defined but not 
> used [-Wunused-label]
>  1680 | out_free:
>   | ^~~~
> 
> Introduced by commit
> 
>   2d9a744685bc ("spi: atmel: No need to call spi_master_put() if 
> spi_alloc_master() failed")
> 
> -- 
> Cheers,
> Stephen Rothwell

WARNING: at mm/mremap.c:211 move_page_tables in i386

[Naresh Kamboju]

While running LTP mm test suite on i386 or qemu_i386 this kernel warning
has been noticed from stable 5.4 to stable 5.7 branches and mainline 5.8.0-rc4
and linux next.

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  git commit: dcb7fd82c75ee2d6e6f9d8cc71c52519ed52e258
  kernel-config:
https://builds.tuxbuild.com/zFkvGKyEbfYdZOMzwrbl-w/kernel.config
  vmlinux: https://builds.tuxbuild.com/zFkvGKyEbfYdZOMzwrbl-w/vmlinux.xz
  system.map: https://builds.tuxbuild.com/zFkvGKyEbfYdZOMzwrbl-w/System.map

steps to reproduce:
- boot i386 kernel or qemu_i386 device
- cd /opt/ltp
- ./runltp -f mm

code snippet:
file: mm/mremap.c
#ifdef CONFIG_HAVE_MOVE_PMD
static bool move_normal_pmd(struct vm_area_struct *vma, unsigned long old_addr,
...
/*
* The destination pmd shouldn't be established, free_pgtables()
* should have release it.
*/
if (WARN_ON(!pmd_none(*new_pmd)))
return false;


[ cut here ]
[  720.642524] WARNING: CPU: 3 PID: 27091 at mm/mremap.c:211
move_page_tables+0x6ef/0x720
[  720.650437] Modules linked in: x86_pkg_temp_thermal
[  720.655314] CPU: 3 PID: 27091 Comm: true Not tainted 5.8.0-rc4 #1
[  720.661408] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[  720.668886] EIP: move_page_tables+0x6ef/0x720
[  720.673245] Code: 85 0c ff ff ff 8b 45 08 8b 4d d4 05 00 00 40 00
25 00 00 c0 ff 2b 45 08 39 c1 0f 46 c1 89 45 d4 01 f0 89 45 cc e9 d6
fa ff ff <0f> 0b 80 7d be 00 0f 84 80 fd ff ff e9 02 fe ff ff a8 80 0f
84 4d
[  720.691990] EAX: f3250bf8 EBX: f3250bfc ECX: 8c46a067 EDX: 02fe
[  720.698249] ESI: bfc0 EDI: f3250bf8 EBP: eea31dd4 ESP: eea31d74
[  720.704514] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282
[  720.711353] CR0: 80050033 CR2: b7d9e3b0 CR3: 3325 CR4: 003406d0
[  720.717634] DR0:  DR1:  DR2:  DR3: 
[  720.723952] DR6: fffe0ff0 DR7: 0400
[  720.727843] Call Trace:
[  720.730325]  setup_arg_pages+0x22b/0x310
[  720.734277]  ? get_random_u32+0x49/0x70
[  720.738167]  ? get_random_u32+0x49/0x70
[  720.742006]  load_elf_binary+0x30e/0x10e0
[  720.746019]  __do_execve_file+0x4c3/0x9f0
[  720.750031]  __ia32_sys_execve+0x25/0x30
[  720.753959]  do_syscall_32_irqs_on+0x3d/0x250
[  720.758317]  ? do_user_addr_fault+0x1a0/0x3c0
[  720.762701]  ? __prepare_exit_to_usermode+0x50/0x1a0
[  720.767703]  ? prepare_exit_to_usermode+0x8/0x20
[  720.772349]  do_fast_syscall_32+0x39/0xb0
[  720.776361]  do_SYSENTER_32+0x15/0x20
[  720.780028]  entry_SYSENTER_32+0x9f/0xf2
[  720.783951] EIP: 0xb7f1d549
[  720.786741] Code: Bad RIP value.
[  720.789965] EAX: ffda EBX: bfbbc7c0 ECX: 08067420 EDX: bfbbc9f4
[  720.796225] ESI: 08058a14 EDI: bfbbc7c9 EBP: bfbbc868 ESP: bfbbc798
[  720.802489] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0292
[  720.809276] ---[ end trace bc662e76cba2d081 ]---
[  724.934902] [ cut here ]
[ cut here ]
[  738.03] WARNING: CPU: 1 PID: 29339 at mm/mremap.c:211
move_page_tables+0x6ef/0x720
[  738.107928] Modules linked in: x86_pkg_temp_thermal
[  738.112860] CPU: 1 PID: 29339 Comm: true Tainted: GW
 5.8.0-rc4 #1
[  738.120374] Hardware name: Supermicro SYS-5019S-ML/X11SSH-F, BIOS
2.0b 07/27/2017
[  738.127904] EIP: move_page_tables+0x6ef/0x720
[  738.132316] Code: 85 0c ff ff ff 8b 45 08 8b 4d d4 05 00 00 40 00
25 00 00 c0 ff 2b 45 08 39 c1 0f 46 c1 89 45 d4 01 f0 89 45 cc e9 d6
fa ff ff <0f> 0b 80 7d be 00 0f 84 80 fd ff ff e9 02 fe ff ff a8 80 0f
84 4d
[  738.151112] EAX: e0f3bbf8 EBX: e0f3bbfc ECX: 8c4b8067 EDX: 02fe
[  738.157422] ESI: bfc0 EDI: e0f3bbf8 EBP: f3809dd4 ESP: f3809d74
[  738.163756] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068 EFLAGS: 00010282
[  738.170587] CR0: 80050033 CR2: b7d9e3b0 CR3: 20f3b000 CR4: 003406d0
[  738.176895] DR0:  DR1:  DR2:  DR3: 
[  738.183179] DR6: fffe0ff0 DR7: 0400
[  738.187019] Call Trace:
[  738.189489]  setup_arg_pages+0x22b/0x310
[  738.193423]  ? get_random_u32+0x49/0x70
[  738.197280]  ? get_random_u32+0x49/0x70
[  738.201119]  load_elf_binary+0x30e/0x10e0
[  738.205159]  __do_execve_file+0x4c3/0x9f0
[  738.209198]  __ia32_sys_execve+0x25/0x30
[  738.213122]  do_syscall_32_irqs_on+0x3d/0x250
[  738.217484]  ? do_user_addr_fault+0x1a0/0x3c0
[  738.221841]  ? __prepare_exit_to_usermode+0x50/0x1a0
[  738.226808]  ? prepare_exit_to_usermode+0x8/0x20
[  738.231427]  do_fast_syscall_32+0x39/0xb0
[  738.235438]  do_SYSENTER_32+0x15/0x20
[  738.239107]  entry_SYSENTER_32+0x9f/0xf2
[  738.243030] EIP: 0xb7f1d549
[  738.245830] Code: Bad RIP value.
[  738.249067] EAX: ffda EBX: bfbbc7c0 ECX: 08067420 EDX: bfbbc9f4
[  738.255331] ESI: 08058a14 EDI: bfbbc7c9 EBP: bfbbc868 ESP: bfbbc798
[  738.261595] DS: 007b ES: 007b FS:  GS: 0033 SS: 007b EFLAGS: 0292
[  738.268382] ---[ end trace bc662e76cba2d083 ]---
[  770.832465] true (1218) used greatest stack depth:

Re: [PATCH 2/2] fs: Remove kiocb->ki_complete

[kernel test robot]

Hi "Matthew,

Thank you for the patch! Perhaps something to improve:

[auto build test WARNING on block/for-next]
[cannot apply to balbi-usb/testing/next cifs/for-next miklos-vfs/overlayfs-next 
linus/master v5.8-rc4 next-20200708]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use  as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Matthew-Wilcox-Oracle/Remove-kiocb-ki_complete/20200709-062758
base:   https://git.kernel.org/pub/scm/linux/kernel/git/axboe/linux-block.git 
for-next
config: s390-randconfig-r013-20200708 (attached as .config)
compiler: clang version 11.0.0 (https://github.com/llvm/llvm-project 
02946de3802d3bc65bc9f2eb9b8d4969b5a7add8)
reproduce (this is a W=1 build):
wget 
https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O 
~/bin/make.cross
chmod +x ~/bin/make.cross
# install s390 cross compiling tool for clang build
# apt-get install binutils-s390x-linux-gnu
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=s390 

If you fix the issue, kindly add following tag as appropriate
Reported-by: kernel test robot 

All warnings (new ones prefixed by >>):

   In file included from arch/s390/purgatory/purgatory.c:10:
   In file included from include/linux/kexec.h:18:
   In file included from include/linux/crash_core.h:6:
   In file included from include/linux/elfcore.h:9:
   In file included from arch/s390/include/asm/elf.h:132:
   In file included from include/linux/compat.h:17:
>> include/linux/fs.h:353:41: warning: shifting a negative signed value is 
>> undefined [-Wshift-negative-value]
   kiocb->ki_flags = (kiocb->ki_flags & (~IOCB_COMPLETION_FNS)) |
  ^~~
   include/linux/fs.h:325:33: note: expanded from macro 'IOCB_COMPLETION_FNS'
   #define IOCB_COMPLETION_FNS (~0 << _IOCB_COMPLETION_SHIFT)
~~ ^
   1 warning generated.

vim +353 include/linux/fs.h

   350  
   351  static inline void kiocb_set_completion(struct kiocb *kiocb, int id)
   352  {
 > 353  kiocb->ki_flags = (kiocb->ki_flags & (~IOCB_COMPLETION_FNS)) |
   354  (id << _IOCB_COMPLETION_SHIFT);
   355  }
   356  

---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-...@lists.01.org


.config.gz
Description: application/gzip

Re: [PATCH] arm64: Add missing sentinel to erratum_1463225

[Sai Prakash Ranjan]

Hi Florian,

On 2020-07-09 10:43, Florian Fainelli wrote:

When the erratum_1463225 array was introduced a sentinel at the end was
missing thus causing a KASAN: global-out-of-bounds in
is_affected_midr_range_list on arm64 error.

Link:
https://lore.kernel.org/linux-arm-kernel/ca+g9fys3eavpu89-rtqfqq9ggxamgmak7jiivrfp0yxj5s+...@mail.gmail.com/
Fixes: a9e821b89daa ("arm64: Add KRYO4XX gold CPU cores to erratum
list 1463225 and 1418040")
Signed-off-by: Florian Fainelli 
---
 arch/arm64/kernel/cpu_errata.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/cpu_errata.c 
b/arch/arm64/kernel/cpu_errata.c

index 8e302dc093d0..79728bfb5351 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -782,6 +782,7 @@ static const struct midr_range erratum_1463225[] = 
{

MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 1),
/* Kryo4xx Gold (rcpe to rfpf) => (r0p0 to r3p1) */
MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xf),
+   {},
 };
 #endif


My bad missing this, thanks for the fix.

Reviewed-by: Sai Prakash Ranjan 

--
QUALCOMM INDIA, on behalf of Qualcomm Innovation Center, Inc. is a 
member

of Code Aurora Forum, hosted by The Linux Foundation

[Linux-kernel-mentees] [PATCH] net/bluetooth: Fix slab-out-of-bounds read in hci_extended_inquiry_result_evt()

[Peilin Ye]

Check upon `num_rsp` is insufficient. A malformed event packet with a
large `num_rsp` number makes hci_extended_inquiry_result_evt() go out
of bounds. Fix it. Also, make `num_rsp` unsigned.

This patch fixes the following syzbot bug:


https://syzkaller.appspot.com/bug?id=4bf11aa05c4ca51ce0df86e500fce486552dc8d2

Reported-by: syzbot+d8489a79b781849b9...@syzkaller.appspotmail.com
Signed-off-by: Peilin Ye 
---
 net/bluetooth/hci_event.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/net/bluetooth/hci_event.c b/net/bluetooth/hci_event.c
index 03a0759f2fc2..29aff5e7dec2 100644
--- a/net/bluetooth/hci_event.c
+++ b/net/bluetooth/hci_event.c
@@ -4369,13 +4369,13 @@ static void hci_extended_inquiry_result_evt(struct 
hci_dev *hdev,
struct sk_buff *skb)
 {
struct inquiry_data data;
-   struct extended_inquiry_info *info = (void *) (skb->data + 1);
-   int num_rsp = *((__u8 *) skb->data);
+   struct extended_inquiry_info *info = (void *)(skb->data + 1);
+   __u8 num_rsp = *((__u8 *)skb->data);
size_t eir_len;
 
BT_DBG("%s num_rsp %d", hdev->name, num_rsp);
 
-   if (!num_rsp)
+   if (!num_rsp || num_rsp * sizeof(*info) > skb->truesize)
return;
 
if (hci_dev_test_flag(hdev, HCI_PERIODIC_INQ))
-- 
2.25.1

[PATCH 1/1] riscv: Enable ARCH_HAS_FAST_MULTIPLIER for RV64I

[Chenxi Mao]

Enable ARCH_HAS_FAST_MULTIPLIER on RV64I
which works fine on GCC-9.3 and GCC-10.1

PS2: remove ARCH_SUPPORTS_INT128 because of RV64I already enabled.

Signed-off-by: Chenxi Mao 
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 128192e14ff2..84e6777fecad 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -202,6 +202,7 @@ config ARCH_RV64I
bool "RV64I"
select 64BIT
select ARCH_SUPPORTS_INT128 if CC_HAS_INT128 && GCC_VERSION >= 5
+   select ARCH_HAS_FAST_MULTIPLIER
select HAVE_DYNAMIC_FTRACE if MMU
select HAVE_DYNAMIC_FTRACE_WITH_REGS if HAVE_DYNAMIC_FTRACE
select HAVE_FTRACE_MCOUNT_RECORD
-- 
2.25.1

RE: [PATCH v5 0/5] scsi: ufs: Add Host Performance Booster Support

[Avri Altman]

> Hello,
> 
> Just a gentle reminder that I'd like some feedback.
> Any suggestions here?
If no-one objects, I think you can submit your patches for review as non-RFC.

Thanks,
Avri

> 
> Thanks,
> Daejun

Re: BUG: KASAN: global-out-of-bounds in is_affected_midr_range_list on arm64

[Florian Fainelli]

On 7/8/2020 9:36 PM, Naresh Kamboju wrote:
> While running LTP cpuhotplug test on mainline 5.8.0-rc4 the kernel BUG noticed
> on arm64 Juno-r2 KASAN config enabled kernel.
> 
> steps to reproduce:
> - boot KASAN enabled Juno-r2 device
> - cd /opt/ltp
> - ./runltp -f cpuhotplug
> 
> metadata:
>   git branch: master
>   git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
>   git commit: 63e1968a2c87e9461e9694a96991935116e0cec7
>   kernel-config:
> https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/kernel.config
>   vmlinux: https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/vmlinux.xz
>   system.map: https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/System.map
> 
> Test log:
> Name:   cpuhotplug02
> Date:   Thu Jul  9 00:09:24 UTC 2020
> Desc:   What happens to a process when its CPU is offlined?
> 

Just sent a tentative fix:

https://lore.kernel.org/linux-arm-kernel/20200709051345.14544-1-f.faine...@gmail.com/
-- 
Florian

[PATCH] arm64: Add missing sentinel to erratum_1463225

[Florian Fainelli]

When the erratum_1463225 array was introduced a sentinel at the end was
missing thus causing a KASAN: global-out-of-bounds in
is_affected_midr_range_list on arm64 error.

Link: 
https://lore.kernel.org/linux-arm-kernel/ca+g9fys3eavpu89-rtqfqq9ggxamgmak7jiivrfp0yxj5s+...@mail.gmail.com/
Fixes: a9e821b89daa ("arm64: Add KRYO4XX gold CPU cores to erratum list 1463225 
and 1418040")
Signed-off-by: Florian Fainelli 
---
 arch/arm64/kernel/cpu_errata.c | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/arm64/kernel/cpu_errata.c b/arch/arm64/kernel/cpu_errata.c
index 8e302dc093d0..79728bfb5351 100644
--- a/arch/arm64/kernel/cpu_errata.c
+++ b/arch/arm64/kernel/cpu_errata.c
@@ -782,6 +782,7 @@ static const struct midr_range erratum_1463225[] = {
MIDR_RANGE(MIDR_CORTEX_A76, 0, 0, 3, 1),
/* Kryo4xx Gold (rcpe to rfpf) => (r0p0 to r3p1) */
MIDR_RANGE(MIDR_QCOM_KRYO_4XX_GOLD, 0xc, 0xe, 0xf, 0xf),
+   {},
 };
 #endif
 
-- 
2.17.1

RE: [PATCH v3 5/6] device-dax: use fallback nid when numa_node is invalid

[Justin He]

Hi Dan

> -Original Message-
> From: Dan Williams 
> Sent: Thursday, July 9, 2020 11:39 AM
> To: Justin He 
> Cc: Catalin Marinas ; Will Deacon
> ; Tony Luck ; Fenghua Yu
> ; Yoshinori Sato ; Rich
> Felker ; Dave Hansen ; Andy
> Lutomirski ; Peter Zijlstra ;
> Thomas Gleixner ; Ingo Molnar ;
> Borislav Petkov ; David Hildenbrand ; X86
> ML ; H. Peter Anvin ; Vishal Verma
> ; Dave Jiang ; Andrew
> Morton ; Baoquan He ; Chuhong
> Yuan ; Mike Rapoport ; Logan
> Gunthorpe ; Masahiro Yamada ;
> Michal Hocko ; Linux ARM  ker...@lists.infradead.org>; Linux Kernel Mailing List  ker...@vger.kernel.org>; linux-i...@vger.kernel.org; Linux-sh  s...@vger.kernel.org>; linux-nvdimm ; Linux MM
> ; Jonathan Cameron ; Kaly
> Xin 
> Subject: Re: [PATCH v3 5/6] device-dax: use fallback nid when numa_node is
> invalid
> 
> On Wed, Jul 8, 2020 at 7:07 PM Jia He  wrote:
> >
> > numa_off is set unconditionally at the end of dummy_numa_init(),
> > even with a fake numa node. ACPI detects node id as NUMA_NO_NODE(-1) in
> > acpi_map_pxm_to_node() because it regards numa_off as turning off the
> numa
> > node. Hence dev_dax->target_node is NUMA_NO_NODE on arm64 with fake numa.
> >
> > Without this patch, pmem can't be probed as a RAM device on arm64 if
> SRAT table
> > isn't present:
> > $ndctl create-namespace -fe namespace0.0 --mode=devdax --map=dev -s 1g -
> a 64K
> > kmem dax0.0: rejecting DAX region [mem 0x24040-0x2bfff] with
> invalid node: -1
> > kmem: probe of dax0.0 failed with error -22
> >
> > This fixes it by using fallback memory_add_physaddr_to_nid() as nid.
> >
> > Suggested-by: David Hildenbrand 
> > Signed-off-by: Jia He 
> > ---
> >  drivers/dax/kmem.c | 21 +
> >  1 file changed, 13 insertions(+), 8 deletions(-)
> >
> > diff --git a/drivers/dax/kmem.c b/drivers/dax/kmem.c
> > index 275aa5f87399..218f66057994 100644
> > --- a/drivers/dax/kmem.c
> > +++ b/drivers/dax/kmem.c
> > @@ -31,22 +31,23 @@ int dev_dax_kmem_probe(struct device *dev)
> > int numa_node;
> > int rc;
> >
> > +   /* Hotplug starting at the beginning of the next block: */
> > +   kmem_start = ALIGN(res->start, memory_block_size_bytes());
> > +
> > /*
> >  * Ensure good NUMA information for the persistent memory.
> >  * Without this check, there is a risk that slow memory
> >  * could be mixed in a node with faster memory, causing
> > -* unavoidable performance issues.
> > +* unavoidable performance issues. Furthermore, fallback node
> > +* id can be used when numa_node is invalid.
> >  */
> > numa_node = dev_dax->target_node;
> > if (numa_node < 0) {
> > -   dev_warn(dev, "rejecting DAX region %pR with invalid
> node: %d\n",
> > -res, numa_node);
> > -   return -EINVAL;
> > +   numa_node = memory_add_physaddr_to_nid(kmem_start);
> 
> I think this fixup belongs to the core to set a fallback value for
> dev_dax->target_node.
> 
> I'm close to having patches to provide a functional
> phys_addr_to_target_node() for arm64.

Should My this patch(5/6) wait on your new phys_addr_to_target_node() patch?
Thanks for the clarification.

--
Cheers,
Justin (Jia He)

Re: [PATCH] tty/sysrq: Add alternative SysRq key

[Dmitry Torokhov]

Hi Andrzej,

On Fri, Jun 19, 2020 at 06:28:19PM +0200, Andrzej Pietrasiewicz wrote:
> There exist machines which don't have SysRq key at all, e.g. chromebooks.
> 
> This patch allows configuring an alternative key to act as SysRq. Devices
> which declare KEY_SYSRQ in their 'keybit' bitmap continue using KEY_SYSRQ,
> but other devices use the alternative SysRq key instead, by default F10.
> Which key is actually used can be modified with sysrq's module parameter.

I guess you will be removing KEY_SYSRQ form all Chrome OS internal AT
keyboards and external USB keyboard with Chrome OS layouts as well? Via
udev keymap? I suppose this could work... Or have a per device setting
as we allocate a separate handle for each input device attached to the
SysRq handler.

> 
> Signed-off-by: Andrzej Pietrasiewicz 
> ---
>  drivers/tty/sysrq.c | 28 +---
>  1 file changed, 25 insertions(+), 3 deletions(-)
> 
> diff --git a/drivers/tty/sysrq.c b/drivers/tty/sysrq.c
> index 0dc3878794fd..e1d271c84746 100644
> --- a/drivers/tty/sysrq.c
> +++ b/drivers/tty/sysrq.c
> @@ -604,6 +604,7 @@ EXPORT_SYMBOL(handle_sysrq);
>  
>  #ifdef CONFIG_INPUT
>  static int sysrq_reset_downtime_ms;
> +static unsigned short alternative_sysrq_key = KEY_F10;
>  
>  /* Simple translation table for the SysRq keys */
>  static const unsigned char sysrq_xlate[KEY_CNT] =
> @@ -621,6 +622,7 @@ struct sysrq_state {
>   unsigned long key_down[BITS_TO_LONGS(KEY_CNT)];
>   unsigned int alt;
>   unsigned int alt_use;
> + unsigned short sysrq_key;
>   bool active;
>   bool need_reinject;
>   bool reinjecting;
> @@ -770,10 +772,10 @@ static void sysrq_reinject_alt_sysrq(struct work_struct 
> *work)
>  
>   /* Simulate press and release of Alt + SysRq */
>   input_inject_event(handle, EV_KEY, alt_code, 1);
> - input_inject_event(handle, EV_KEY, KEY_SYSRQ, 1);
> + input_inject_event(handle, EV_KEY, sysrq->sysrq_key, 1);
>   input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
>  
> - input_inject_event(handle, EV_KEY, KEY_SYSRQ, 0);
> + input_inject_event(handle, EV_KEY, sysrq->sysrq_key, 0);
>   input_inject_event(handle, EV_KEY, alt_code, 0);
>   input_inject_event(handle, EV_SYN, SYN_REPORT, 1);
>  
> @@ -805,6 +807,7 @@ static bool sysrq_handle_keypress(struct sysrq_state 
> *sysrq,
>   }
>   break;
>  
> +key_sysrq:
>   case KEY_SYSRQ:
>   if (value == 1 && sysrq->alt != KEY_RESERVED) {
>   sysrq->active = true;
> @@ -825,11 +828,15 @@ static bool sysrq_handle_keypress(struct sysrq_state 
> *sysrq,
>* triggering print screen function.
>*/
>   if (sysrq->active)
> - clear_bit(KEY_SYSRQ, sysrq->handle.dev->key);
> + clear_bit(sysrq->sysrq_key, sysrq->handle.dev->key);
>  
>   break;
>  
>   default:
> + /* handle non-default sysrq key */
> + if (code == sysrq->sysrq_key)
> + goto key_sysrq;
> +
>   if (sysrq->active && value && value != 2) {
>   sysrq->need_reinject = false;
>   __handle_sysrq(sysrq_xlate[code], true);
> @@ -924,6 +931,14 @@ static int sysrq_connect(struct input_handler *handler,
>   sysrq->handle.private = sysrq;
>   timer_setup(&sysrq->keyreset_timer, sysrq_do_reset, 0);
>  
> + if (test_bit(KEY_SYSRQ, dev->keybit)) {
> + sysrq->sysrq_key = KEY_SYSRQ;
> + pr_info("%s: using default sysrq key [%x]\n", dev->name, 
> KEY_SYSRQ);
> + } else {
> + sysrq->sysrq_key = alternative_sysrq_key;
> + pr_info("%s: Using alternative sysrq key: [%x]\n", dev->name, 
> sysrq->sysrq_key);
> + }

This is way too noisy IMO.

> +
>   error = input_register_handle(&sysrq->handle);
>   if (error) {
>   pr_err("Failed to register input sysrq handler, error %d\n",
> @@ -1032,6 +1047,13 @@ module_param_array_named(reset_seq, sysrq_reset_seq, 
> sysrq_reset_seq,
>  
>  module_param_named(sysrq_downtime_ms, sysrq_reset_downtime_ms, int, 0644);
>  
> +module_param(alternative_sysrq_key, ushort, 0644);
> +MODULE_PARM_DESC(alternative_sysrq_key,
> + "Alternative SysRq key for input devices that don't have SysRq key. F10 
> by default.\n"
> + "Example\n"
> + "Using F9 as SysRq:\n"
> + "sysrq.alternative_sysrq_key=0x43\n");
> +
>  #else
>  
>  static inline void sysrq_register_handler(void)
> 
> base-commit: 3d77e6a8804abcc0504c904bd6e5cdf3a5cf8162
> -- 
> 2.17.1
> 

-- 
Dmitry

Re: [PATCH v5 1/4] riscv: Move kernel mapping to vmalloc zone

[Palmer Dabbelt]

On Sun, 07 Jun 2020 00:59:46 PDT (-0700), a...@ghiti.fr wrote:

This is a preparatory patch for relocatable kernel.

The kernel used to be linked at PAGE_OFFSET address and used to be loaded
physically at the beginning of the main memory. Therefore, we could use
the linear mapping for the kernel mapping.

But the relocated kernel base address will be different from PAGE_OFFSET
and since in the linear mapping, two different virtual addresses cannot
point to the same physical address, the kernel mapping needs to lie outside
the linear mapping.


I know it's been a while, but I keep opening this up to review it and just
can't get over how ugly it is to put the kernel's linear map in the vmalloc
region.

I guess I don't understand why this is necessary at all.  Specifically: why
can't we just relocate the kernel within the linear map?  That would let the
bootloader put the kernel wherever it wants, modulo the physical memory size we
support.  We'd need to handle the regions that are coupled to the kernel's
execution address, but we could just put them in an explicit memory region
which is what we should probably be doing anyway.


In addition, because modules and BPF must be close to the kernel (inside
+-2GB window), the kernel is placed at the end of the vmalloc zone minus
2GB, which leaves room for modules and BPF. The kernel could not be
placed at the beginning of the vmalloc zone since other vmalloc
allocations from the kernel could get all the +-2GB window around the
kernel which would prevent new modules and BPF programs to be loaded.


Well, that's not enough to make sure this doesn't happen -- it's just enough to
make sure it doesn't happen very quickily.  That's the same boat we're already
in, though, so it's not like it's worse.


Signed-off-by: Alexandre Ghiti 
Reviewed-by: Zong Li 
---
 arch/riscv/boot/loader.lds.S |  3 +-
 arch/riscv/include/asm/page.h| 10 +-
 arch/riscv/include/asm/pgtable.h | 38 ++---
 arch/riscv/kernel/head.S |  3 +-
 arch/riscv/kernel/module.c   |  4 +--
 arch/riscv/kernel/vmlinux.lds.S  |  3 +-
 arch/riscv/mm/init.c | 58 +---
 arch/riscv/mm/physaddr.c |  2 +-
 8 files changed, 88 insertions(+), 33 deletions(-)

diff --git a/arch/riscv/boot/loader.lds.S b/arch/riscv/boot/loader.lds.S
index 47a5003c2e28..62d94696a19c 100644
--- a/arch/riscv/boot/loader.lds.S
+++ b/arch/riscv/boot/loader.lds.S
@@ -1,13 +1,14 @@
 /* SPDX-License-Identifier: GPL-2.0 */

 #include 
+#include 

 OUTPUT_ARCH(riscv)
 ENTRY(_start)

 SECTIONS
 {
-   . = PAGE_OFFSET;
+   . = KERNEL_LINK_ADDR;

.payload : {
*(.payload)
diff --git a/arch/riscv/include/asm/page.h b/arch/riscv/include/asm/page.h
index 2d50f76efe48..48bb09b6a9b7 100644
--- a/arch/riscv/include/asm/page.h
+++ b/arch/riscv/include/asm/page.h
@@ -90,18 +90,26 @@ typedef struct page *pgtable_t;

 #ifdef CONFIG_MMU
 extern unsigned long va_pa_offset;
+extern unsigned long va_kernel_pa_offset;
 extern unsigned long pfn_base;
 #define ARCH_PFN_OFFSET(pfn_base)
 #else
 #define va_pa_offset   0
+#define va_kernel_pa_offset0
 #define ARCH_PFN_OFFSET(PAGE_OFFSET >> PAGE_SHIFT)
 #endif /* CONFIG_MMU */

 extern unsigned long max_low_pfn;
 extern unsigned long min_low_pfn;
+extern unsigned long kernel_virt_addr;

 #define __pa_to_va_nodebug(x)  ((void *)((unsigned long) (x) + va_pa_offset))
-#define __va_to_pa_nodebug(x)  ((unsigned long)(x) - va_pa_offset)
+#define linear_mapping_va_to_pa(x) ((unsigned long)(x) - va_pa_offset)
+#define kernel_mapping_va_to_pa(x) \
+   ((unsigned long)(x) - va_kernel_pa_offset)
+#define __va_to_pa_nodebug(x)  \
+   (((x) >= PAGE_OFFSET) ?  \
+   linear_mapping_va_to_pa(x) : kernel_mapping_va_to_pa(x))

 #ifdef CONFIG_DEBUG_VIRTUAL
 extern phys_addr_t __virt_to_phys(unsigned long x);
diff --git a/arch/riscv/include/asm/pgtable.h b/arch/riscv/include/asm/pgtable.h
index 35b60035b6b0..94ef3b49dfb6 100644
--- a/arch/riscv/include/asm/pgtable.h
+++ b/arch/riscv/include/asm/pgtable.h
@@ -11,23 +11,29 @@

 #include 

-#ifndef __ASSEMBLY__
-
-/* Page Upper Directory not used in RISC-V */
-#include 
-#include 
-#include 
-#include 
-
-#ifdef CONFIG_MMU
+#ifndef CONFIG_MMU
+#define KERNEL_VIRT_ADDR   PAGE_OFFSET
+#define KERNEL_LINK_ADDR   PAGE_OFFSET
+#else
+/*
+ * Leave 2GB for modules and BPF that must lie within a 2GB range around
+ * the kernel.
+ */
+#define KERNEL_VIRT_ADDR   (VMALLOC_END - SZ_2G + 1)
+#define KERNEL_LINK_ADDR   KERNEL_VIRT_ADDR


At a bare minimum this is going to make a mess of the 32-bit port, as
non-relocatable kernels are now going to get linked at 1GiB which is where user
code is supposed to live.  That's an easy fix, though, as the 32-bit stuff
doesn't need any module address restrictions.


 #define VMALLOC_SIZE (KERN_VIRT_SIZE >> 1)
 #define VMALLOC_END  (PAGE_OFFSE

[PATCH 3/5] iommu/arm-smmu: Move SMR and S2CR definitions to header file

[Bjorn Andersson]

Expose the SMR and S2CR structs in the header file, to allow platform
specific implementations to populate/initialize the smrs and s2cr
arrays.

Signed-off-by: Bjorn Andersson 
---
 drivers/iommu/arm-smmu.c | 14 --
 drivers/iommu/arm-smmu.h | 15 +++
 2 files changed, 15 insertions(+), 14 deletions(-)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index f33eda3117fa..e2d6c0aaf1ea 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -68,24 +68,10 @@ module_param(disable_bypass, bool, S_IRUGO);
 MODULE_PARM_DESC(disable_bypass,
"Disable bypass streams such that incoming transactions from devices 
that are not attached to an iommu domain will report an abort back to the 
device and will not be allowed to pass through the SMMU.");
 
-struct arm_smmu_s2cr {
-   struct iommu_group  *group;
-   int count;
-   enum arm_smmu_s2cr_type type;
-   enum arm_smmu_s2cr_privcfg  privcfg;
-   u8  cbndx;
-};
-
 #define s2cr_init_val (struct arm_smmu_s2cr){  \
.type = disable_bypass ? S2CR_TYPE_FAULT : S2CR_TYPE_BYPASS,\
 }
 
-struct arm_smmu_smr {
-   u16 mask;
-   u16 id;
-   boolvalid;
-};
-
 struct arm_smmu_cb {
u64 ttbr[2];
u32 tcr[2];
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index a71d193073e4..bcd160d01c53 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -251,6 +251,21 @@ enum arm_smmu_implementation {
QCOM_SMMUV2,
 };
 
+struct arm_smmu_s2cr {
+   struct iommu_group  *group;
+   int count;
+   enum arm_smmu_s2cr_type type;
+   enum arm_smmu_s2cr_privcfg  privcfg;
+   u8  cbndx;
+};
+
+struct arm_smmu_smr {
+   u16 mask;
+   u16 id;
+   boolvalid;
+   boolpinned;
+};
+
 struct arm_smmu_device {
struct device   *dev;
 
-- 
2.26.2

[PATCH 0/5] iommu/arm-smmu: Support maintaining bootloader mappings

[Bjorn Andersson]

Based on previous attempts and discussions this is the latest attempt at
inheriting stream mappings set up by the bootloader, for e.g. boot splash or
efifb.

The first patch is an implementation of Robin's suggestion that we should just
mark the relevant stream mappings as BYPASS. Relying on something else to set
up the stream mappings wanted - e.g. by reading it back in platform specific
implementation code.

The series then tackles the problem seen in most versions of Qualcomm firmware,
that the hypervisor intercepts BYPASS writes and turn them into FAULTs. It does
this by allocating context banks for identity domains as well, with translation
disabled.

Lastly it amends the stream mapping initialization code to allocate a specific
identity domain that is used for any mappings inherited from the bootloader, if
above Qualcomm quirk is required.


The series has been tested and shown to allow booting SDM845, SDM850, SM8150,
SM8250 with boot splash screen setup by the bootloader. Specifically it also
allows the Lenovo Yoga C630 to boot with SMMU and efifb enabled.

Bjorn Andersson (5):
  iommu/arm-smmu: Make all valid stream mappings BYPASS
  iommu/arm-smmu: Emulate bypass by using context banks
  iommu/arm-smmu: Move SMR and S2CR definitions to header file
  iommu/arm-smmu-qcom: Consstently initialize stream mappings
  iommu/arm-smmu: Setup identity domain for boot mappings

 drivers/iommu/arm-smmu-qcom.c |  48 +
 drivers/iommu/arm-smmu.c  | 124 +-
 drivers/iommu/arm-smmu.h  |  21 ++
 3 files changed, 175 insertions(+), 18 deletions(-)

-- 
2.26.2

[PATCH 4/5] iommu/arm-smmu-qcom: Consstently initialize stream mappings

[Bjorn Andersson]

Firmware that traps writes to S2CR to translate BYPASS into FAULT also
ignores writes of type FAULT. As such booting with "disable_bypass" set
will result in all S2CR registers left as configured by the bootloader.

This has been seen to result in indeterministic results, as these
mappings might linger and reference context banks that Linux is
reconfiguring.

Use the fact that BYPASS writes result in FAULT type to force all stream
mappings to FAULT.

Signed-off-by: Bjorn Andersson 
---
 drivers/iommu/arm-smmu-qcom.c | 18 +-
 1 file changed, 17 insertions(+), 1 deletion(-)

diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index e8a36054e912..86b1917459a4 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -27,6 +27,7 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
 {
unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 
1);
u32 reg;
+   int i;
 
/*
 * With some firmware writes to S2CR of type FAULT are ignored, and
@@ -37,9 +38,24 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
FIELD_PREP(ARM_SMMU_S2CR_CBNDX, 
0xff) |
FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, 
S2CR_PRIVCFG_DEFAULT));
reg = arm_smmu_gr0_read(smmu, last_s2cr);
-   if (FIELD_GET(ARM_SMMU_S2CR_TYPE, reg) != S2CR_TYPE_BYPASS)
+   if (FIELD_GET(ARM_SMMU_S2CR_TYPE, reg) != S2CR_TYPE_BYPASS) {
smmu->qcom_bypass_quirk = true;
 
+   /*
+* With firmware ignoring writes of type FAULT, booting the
+* Linux kernel with disable_bypass disabled (i.e. "enable
+* bypass") the initialization during probe will leave mappings
+* in an inconsistent state. Avoid this by configuring all
+* S2CRs to BYPASS.
+*/
+   for (i = 0; i < smmu->num_mapping_groups; i++) {
+   smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+   smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+   smmu->s2crs[i].cbndx = 0xff;
+   smmu->s2crs[i].count = 0;
+   }
+   }
+
return 0;
 }
 
-- 
2.26.2

[PATCH 5/5] iommu/arm-smmu: Setup identity domain for boot mappings

[Bjorn Andersson]

With many Qualcomm platforms not having functional S2CR BYPASS a
temporary IOMMU domain, without translation, needs to be allocated in
order to allow these memory transactions.

Unfortunately the boot loader uses the first few context banks, so
rather than overwriting a active bank the last context bank is used and
streams are diverted here during initialization.

This also performs the readback of SMR registers for the Qualcomm
platform, to trigger the mechanism.

This is based on prior work by Thierry Reding and Laurentiu Tudor.

Signed-off-by: Bjorn Andersson 
---
 drivers/iommu/arm-smmu-qcom.c | 11 +
 drivers/iommu/arm-smmu.c  | 80 +--
 drivers/iommu/arm-smmu.h  |  3 ++
 3 files changed, 90 insertions(+), 4 deletions(-)

diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index 86b1917459a4..397df27c1d69 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -26,6 +26,7 @@ static const struct of_device_id qcom_smmu_client_of_match[] 
= {
 static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
 {
unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 
1);
+   u32 smr;
u32 reg;
int i;
 
@@ -56,6 +57,16 @@ static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
}
}
 
+   for (i = 0; i < smmu->num_mapping_groups; i++) {
+   smr = arm_smmu_gr0_read(smmu, ARM_SMMU_GR0_SMR(i));
+
+   if (FIELD_GET(ARM_SMMU_SMR_VALID, smr)) {
+   smmu->smrs[i].id = FIELD_GET(ARM_SMMU_SMR_ID, smr);
+   smmu->smrs[i].mask = FIELD_GET(ARM_SMMU_SMR_MASK, smr);
+   smmu->smrs[i].valid = true;
+   }
+   }
+
return 0;
 }
 
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index e2d6c0aaf1ea..a7cb27c1a49e 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -652,7 +652,8 @@ static void arm_smmu_write_context_bank(struct 
arm_smmu_device *smmu, int idx)
 }
 
 static int arm_smmu_init_domain_context(struct iommu_domain *domain,
-   struct arm_smmu_device *smmu)
+   struct arm_smmu_device *smmu,
+   bool boot_domain)
 {
int irq, start, ret = 0;
unsigned long ias, oas;
@@ -770,6 +771,15 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,
ret = -EINVAL;
goto out_unlock;
}
+
+   /*
+* Use the last context bank for identity mappings during boot, to
+* avoid overwriting in-use bank configuration while we're setting up
+* the new mappings.
+*/
+   if (boot_domain)
+   start = smmu->num_context_banks - 1;
+
ret = __arm_smmu_alloc_bitmap(smmu->context_map, start,
  smmu->num_context_banks);
if (ret < 0)
@@ -1149,7 +1159,10 @@ static int arm_smmu_attach_dev(struct iommu_domain 
*domain, struct device *dev)
struct iommu_fwspec *fwspec = dev_iommu_fwspec_get(dev);
struct arm_smmu_master_cfg *cfg;
struct arm_smmu_device *smmu;
+   bool free_identity_domain = false;
+   int idx;
int ret;
+   int i;
 
if (!fwspec || fwspec->ops != &arm_smmu_ops) {
dev_err(dev, "cannot attach to SMMU, is it on the same bus?\n");
@@ -1174,7 +1187,7 @@ static int arm_smmu_attach_dev(struct iommu_domain 
*domain, struct device *dev)
return ret;
 
/* Ensure that the domain is finalised */
-   ret = arm_smmu_init_domain_context(domain, smmu);
+   ret = arm_smmu_init_domain_context(domain, smmu, false);
if (ret < 0)
goto rpm_put;
 
@@ -1190,9 +1203,34 @@ static int arm_smmu_attach_dev(struct iommu_domain 
*domain, struct device *dev)
goto rpm_put;
}
 
+   /* Decrement use counter for any references to the identity domain */
+   mutex_lock(&smmu->stream_map_mutex);
+   if (smmu->identity) {
+   struct arm_smmu_domain *identity = 
to_smmu_domain(smmu->identity);
+
+   for_each_cfg_sme(cfg, fwspec, i, idx) {
+   dev_err(smmu->dev, "%s() %#x\n", __func__, 
smmu->smrs[idx].id);
+   if (smmu->s2crs[idx].cbndx == identity->cfg.cbndx) {
+   smmu->num_identity_masters--;
+   if (smmu->num_identity_masters == 0)
+   free_identity_domain = true;
+   }
+   }
+   }
+   mutex_unlock(&smmu->stream_map_mutex);
+
/* Looks ok, so add the device to the domain */
ret = arm_smmu_domain_add_master(smmu_domain, cfg, fwspec);
 
+   /*
+* The last stream map to reference the identity domain has been
+* overwritten, so i

[PATCH 1/5] iommu/arm-smmu: Make all valid stream mappings BYPASS

[Bjorn Andersson]

Turn all stream mappings marked as valid into BYPASS. This allows the
platform specific implementation to configure stream mappings to match
the boot loader's configuration for e.g. display to continue to function
through the reset of the SMMU.

Suggested-by: Robin Murphy 
Signed-off-by: Bjorn Andersson 
---
 drivers/iommu/arm-smmu.c | 20 
 1 file changed, 20 insertions(+)

diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 243bc4cb2705..2e27cf9815ab 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -1924,6 +1924,22 @@ static int arm_smmu_device_cfg_probe(struct 
arm_smmu_device *smmu)
return 0;
 }
 
+int arm_smmu_setup_identity(struct arm_smmu_device *smmu)
+{
+   int i;
+
+   for (i = 0; i < smmu->num_mapping_groups; i++) {
+   if (smmu->smrs[i].valid) {
+   smmu->s2crs[i].type = S2CR_TYPE_BYPASS;
+   smmu->s2crs[i].privcfg = S2CR_PRIVCFG_DEFAULT;
+   smmu->s2crs[i].cbndx = 0xff;
+   smmu->s2crs[i].count++;
+   }
+   }
+
+   return 0;
+}
+
 struct arm_smmu_match_data {
enum arm_smmu_arch_version version;
enum arm_smmu_implementation model;
@@ -2181,6 +2197,10 @@ static int arm_smmu_device_probe(struct platform_device 
*pdev)
if (err)
return err;
 
+   err = arm_smmu_setup_identity(smmu);
+   if (err)
+   return err;
+
if (smmu->version == ARM_SMMU_V2) {
if (smmu->num_context_banks > smmu->num_context_irqs) {
dev_err(dev,
-- 
2.26.2

[PATCH 2/5] iommu/arm-smmu: Emulate bypass by using context banks

[Bjorn Andersson]

Some firmware found on various Qualcomm platforms traps writes to S2CR
of type BYPASS and writes FAULT into the register. This prevents us from
marking the streams for the display controller as BYPASS to allow
continued scanout of the screen through the initialization of the ARM
SMMU.

This adds a Qualcomm specific cfg_probe function, which probes the
behavior of the S2CR registers and if found faulty enables the related
quirk. Based on this quirk context banks are allocated for IDENTITY
domains as well, but with ARM_SMMU_SCTLR_M omitted.

The result is valid stream mappings, without translation.

Signed-off-by: Bjorn Andersson 
---
 drivers/iommu/arm-smmu-qcom.c | 21 +
 drivers/iommu/arm-smmu.c  | 14 --
 drivers/iommu/arm-smmu.h  |  3 +++
 3 files changed, 36 insertions(+), 2 deletions(-)

diff --git a/drivers/iommu/arm-smmu-qcom.c b/drivers/iommu/arm-smmu-qcom.c
index cf01d0215a39..e8a36054e912 100644
--- a/drivers/iommu/arm-smmu-qcom.c
+++ b/drivers/iommu/arm-smmu-qcom.c
@@ -23,6 +23,26 @@ static const struct of_device_id qcom_smmu_client_of_match[] 
= {
{ }
 };
 
+static int qcom_smmu_cfg_probe(struct arm_smmu_device *smmu)
+{
+   unsigned int last_s2cr = ARM_SMMU_GR0_S2CR(smmu->num_mapping_groups - 
1);
+   u32 reg;
+
+   /*
+* With some firmware writes to S2CR of type FAULT are ignored, and
+* writing BYPASS will end up as FAULT in the register. Perform a write
+* to S2CR to detect if this is the case with the current firmware.
+*/
+   arm_smmu_gr0_write(smmu, last_s2cr, FIELD_PREP(ARM_SMMU_S2CR_TYPE, 
S2CR_TYPE_BYPASS) |
+   FIELD_PREP(ARM_SMMU_S2CR_CBNDX, 
0xff) |
+   FIELD_PREP(ARM_SMMU_S2CR_PRIVCFG, 
S2CR_PRIVCFG_DEFAULT));
+   reg = arm_smmu_gr0_read(smmu, last_s2cr);
+   if (FIELD_GET(ARM_SMMU_S2CR_TYPE, reg) != S2CR_TYPE_BYPASS)
+   smmu->qcom_bypass_quirk = true;
+
+   return 0;
+}
+
 static int qcom_smmu_def_domain_type(struct device *dev)
 {
const struct of_device_id *match =
@@ -61,6 +81,7 @@ static int qcom_smmu500_reset(struct arm_smmu_device *smmu)
 }
 
 static const struct arm_smmu_impl qcom_smmu_impl = {
+   .cfg_probe = qcom_smmu_cfg_probe,
.def_domain_type = qcom_smmu_def_domain_type,
.reset = qcom_smmu500_reset,
 };
diff --git a/drivers/iommu/arm-smmu.c b/drivers/iommu/arm-smmu.c
index 2e27cf9815ab..f33eda3117fa 100644
--- a/drivers/iommu/arm-smmu.c
+++ b/drivers/iommu/arm-smmu.c
@@ -654,7 +654,9 @@ static void arm_smmu_write_context_bank(struct 
arm_smmu_device *smmu, int idx)
 
/* SCTLR */
reg = ARM_SMMU_SCTLR_CFIE | ARM_SMMU_SCTLR_CFRE | ARM_SMMU_SCTLR_AFE |
- ARM_SMMU_SCTLR_TRE | ARM_SMMU_SCTLR_M;
+ ARM_SMMU_SCTLR_TRE;
+   if (cfg->m)
+   reg |= ARM_SMMU_SCTLR_M;
if (stage1)
reg |= ARM_SMMU_SCTLR_S1_ASIDPNE;
if (IS_ENABLED(CONFIG_CPU_BIG_ENDIAN))
@@ -678,7 +680,11 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,
if (smmu_domain->smmu)
goto out_unlock;
 
-   if (domain->type == IOMMU_DOMAIN_IDENTITY) {
+   /*
+* Nothing to do for IDENTITY domains,unless disabled context banks are
+* used to emulate bypass mappings on Qualcomm platforms.
+*/
+   if (domain->type == IOMMU_DOMAIN_IDENTITY && !smmu->qcom_bypass_quirk) {
smmu_domain->stage = ARM_SMMU_DOMAIN_BYPASS;
smmu_domain->smmu = smmu;
goto out_unlock;
@@ -826,6 +832,10 @@ static int arm_smmu_init_domain_context(struct 
iommu_domain *domain,
domain->geometry.aperture_end = (1UL << ias) - 1;
domain->geometry.force_aperture = true;
 
+   /* Enable translation for non-identity context banks */
+   if (domain->type != IOMMU_DOMAIN_IDENTITY)
+   cfg->m = true;
+
/* Initialise the context bank with our page table cfg */
arm_smmu_init_context_bank(smmu_domain, &pgtbl_cfg);
arm_smmu_write_context_bank(smmu, cfg->cbndx);
diff --git a/drivers/iommu/arm-smmu.h b/drivers/iommu/arm-smmu.h
index d172c024be61..a71d193073e4 100644
--- a/drivers/iommu/arm-smmu.h
+++ b/drivers/iommu/arm-smmu.h
@@ -305,6 +305,8 @@ struct arm_smmu_device {
 
/* IOMMU core code handle */
struct iommu_device iommu;
+
+   boolqcom_bypass_quirk;
 };
 
 enum arm_smmu_context_fmt {
@@ -323,6 +325,7 @@ struct arm_smmu_cfg {
};
enum arm_smmu_cbar_type cbar;
enum arm_smmu_context_fmt   fmt;
+   boolm;
 };
 #define ARM_SMMU_INVALID_IRPTNDX   0xff
 
-- 
2.26.2

WARNING: kernel stack regs at 00000000de0bac5a in cpuacct.sh:5923 has bad 'bp' value

[Naresh Kamboju]

While running LTP controllers on mainline 5.8.0-rc4 the kernel warning was
noticed on x86_64 KASAN enabled kernel.

steps to reproduce:
- boot KASAN enabled x86_64 device
- cd /opt/ltp
- ./runltp -f controllers

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  git commit: 63e1968a2c87e9461e9694a96991935116e0cec7
  kernel-config:
https://builds.tuxbuild.com/Vo6kJCXrQFAecvpDYbsNfA/kernel.config
  vmlinux: https://builds.tuxbuild.com/Vo6kJCXrQFAecvpDYbsNfA/vmlinux.xz
  system.map: https://builds.tuxbuild.com/Vo6kJCXrQFAecvpDYbsNfA/System.map

test log:
cpuacct 1 TINFO: cpuacct: /sys/fs/cgroup/cpu,cpuacct
cpuacct 1 TINFO: Creating 100 subgroups each with 100 processes
[ 2065.217708] WARNING: kernel stack regs at de0bac5a in
cpuacct.sh:5923 has bad 'bp' value 
[ 2065.217710] unwind stack type:0 next_sp: mask:0x6 graph_idx:0
[ 2065.217713] dccf3e29: 8882308899d0 (0x8882308899d0)
[ 2065.217718] 0ced5e7d: 88520337 (arch_stack_walk+0x87/0xf0)
[ 2065.217719] c3b8b4a3:  ...
[ 2065.217720] a5100dde: 8881dd30 (0x8881dd30)
[ 2065.217722] d26471bd: 8881dd308000 (0x8881dd308000)
[ 2065.217723] c0fb7603:  ...
[ 2065.217724] 0a0685f8: 0006 (0x6)
[ 2065.217725] c4e89127: 8881e09cbd00 (0x8881e09cbd00)
[ 2065.217727] 47505be5: 0101 (0x101)
[ 2065.217727] 806a2e76:  ...
[ 2065.217729] f07cebbf: 888230889938 (0x888230889938)
[ 2065.217731] 4fc275e8: 88402b4d (ret_from_fork+0xd/0x30)
[ 2065.217732] 90ee713c:  ...
[ 2065.217734] fbfdc4ef: 8881dd307ea8 (0x8881dd307ea8)
[ 2065.217735] 8475d463: 19bfbd057188fd00 (0x19bfbd057188fd00)
[ 2065.217737] ad790ad9: ed104611133c (0xed104611133c)
[ 2065.217738] fb59349d: 0a20 (0xa20)
[ 2065.217739] 19732c4b: 8881dd2b1b80 (0x8881dd2b1b80)
[ 2065.217740] 236b0212:  ...
[ 2065.217742] b4714969: 888230889a68 (0x888230889a68)
[ 2065.217745] 101a1272: 8870efcf (stack_trace_save+0x8f/0xc0)
[ 2065.217746] 822328ce: 41b58ab3 (0x41b58ab3)
[ 2065.217748] 78676158: 8a6340cc (0x8a6340cc)
[ 2065.217750] 245fa723: 8870ef40
(stack_trace_consume_entry+0x90/0x90)
[ 2065.217751] 9a7b06c9:  ...
[ 2065.217752] 686e9812: 888230889a78 (0x888230889a78)
[ 2065.217754] 0eb43e1c: 0040 (0x40)
[ 2065.217755] 0c034512: 000f (0xf)
[ 2065.217758] 8dc113ec: 88671a53
(kernel_text_address+0xe3/0xf0)
[ 2065.217759] c5bfdc59: 8881dd2f7f58 (0x8881dd2f7f58)
[ 2065.217761] 076a9187: 888230889ac0 (0x888230889ac0)
[ 2065.217762] 20020bf7: 888230889a48 (0x888230889a48)
[ 2065.217765] b602adf1: 88671a6d
(__kernel_text_address+0xd/0x40)
[ 2065.217767] fd3561b8: 888230889a78 (0x888230889a78)
[ 2065.217768] 1fbe04e1: 888230889a68 (0x888230889a68)
[ 2065.217771] 8333f971: 8855b581
(unwind_get_return_address+0x31/0x50)
[ 2065.217773] 4c0dbeef: 19bfbd057188fd00 (0x19bfbd057188fd00)
[ 2065.217774] bbb9110b: 8881dd2b1c60 (0x8881dd2b1c60)
[ 2065.217776] cc8b0486: 888230889c80 (0x888230889c80)
[ 2065.217778] 8b439a46: 888dcae3 (save_stack+0x23/0x50)
[ 2065.217780] a66b6692: 888dcae3 (save_stack+0x23/0x50)
[ 2065.217782] 75588e36: 888dcf3f
(__kasan_kmalloc.constprop.0+0xcf/0xe0)
[ 2065.217784] a050be3e: 888dd2ce (kasan_slab_alloc+0xe/0x10)
[ 2065.217787] 029235b1: 888d8200 (kmem_cache_alloc+0xc0/0x240)
[ 2065.217791] 5e6a28dd: 896567cf (__build_skb+0x1f/0x50)
[ 2065.217793] fb80faf7: 89656814 (build_skb+0x14/0xd0)
[ 2065.217796] 8e683902: 892ddc92 (igb_poll+0x15d2/0x1e20)
[ 2065.217799] 6a844143: 89687297 (net_rx_action+0x2a7/0x690)
[ 2065.217802] bd9d4055: 89e00107 (__do_softirq+0x107/0x3a9)
[ 2065.217804] 83f57728: 89c00f82 (asm_call_on_stack+0x12/0x20)
[ 2065.217807] 411a40b2: 8850a3aa
(do_softirq_own_stack+0x3a/0x50)
[ 2065.217809] e88ca3a4: 88640d75 (irq_exit_rcu+0xd5/0xe0)
[ 2065.217812] 851e0f2c: 89af256b (common_interrupt+0x7b/0x130)
[ 2065.217814] 684bd52e: 89c00b9e
(asm_common_interrupt+0x1e/0x40)
[ 2065.217816] 64414bca: 88402b4d (ret_from_fork+0xd/0x30)
[ 2065.217818] 073e925d: 88820a919000 (0x88820a919000)
[ 2065.217819] f122296d: 88822f8af200 (0x88822f8af200)
[ 20

Re: [mm] 4e2c82a409: ltp.overcommit_memory01.fail

[Feng Tang]

On Tue, Jul 07, 2020 at 01:41:20PM +0800, Feng Tang wrote:
> On Tue, Jul 07, 2020 at 12:00:09PM +0800, Huang, Ying wrote:
> > Feng Tang  writes:
> > 
> > > On Mon, Jul 06, 2020 at 06:34:34AM -0700, Andi Kleen wrote:
> > >> >ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
> > >> > -  if (ret == 0 && write)
> > >> > +  if (ret == 0 && write) {
> > >> > +  if (sysctl_overcommit_memory == OVERCOMMIT_NEVER)
> > >> > +  schedule_on_each_cpu(sync_overcommit_as);
> > >> 
> > >> The schedule_on_each_cpu is not atomic, so the problem could still happen
> > >> in that window.
> > >> 
> > >> I think it may be ok if it eventually resolves, but certainly needs
> > >> a comment explaining it. Can you do some stress testing toggling the
> > >> policy all the time on different CPUs and running the test on
> > >> other CPUs and see if the test fails?
> > >
> > > For the raw test case reported by 0day, this patch passed in 200 times
> > > run. And I will read the ltp code and try stress testing it as you
> > > suggested.
> > >
> > >
> > >> The other alternative would be to define some intermediate state
> > >> for the sysctl variable and only switch to never once the 
> > >> schedule_on_each_cpu
> > >> returned. But that's more complexity.
> > >
> > > One thought I had is to put this schedule_on_each_cpu() before
> > > the proc_dointvec_minmax() to do the sync before sysctl_overcommit_memory
> > > is really changed. But the window still exists, as the batch is
> > > still the larger one. 
> > 
> > Can we change the batch firstly, then sync the global counter, finally
> > change the overcommit policy?
> 
> These reorderings are really head scratching :)
> 
> I've thought about this before when Qian Cai first reported the warning
> message, as kernel had a check: 
> 
>   VM_WARN_ONCE(percpu_counter_read(&vm_committed_as) <
>   -(s64)vm_committed_as_batch * num_online_cpus(),
>   "memory commitment underflow");
> 
> If the batch is decreased first, the warning will be easier/earlier to be
> triggered, so I didn't brought this up when handling the warning message.
> 
> But it might work now, as the warning has been removed.

I tested the reorder way, and the test could pass in 100 times run. The
new order when changing policy to OVERCOMMIT_NEVER:
  1. re-compute the batch ( to the smaller one)
  2. do the on_each_cpu sync
  3. really change the policy to NEVER.

It solves one of previous concern, that after the sync is done on cpuX,
but before the whole sync on all cpus are done, there is a window that
the percpu-counter could be enlarged again.

IIRC Andi had concern about read side cost when doing the sync, my
understanding is most of the readers (malloc/free/map/unmap) are using
percpu_counter_read_positive, which is a fast path without involving lock.

As for the problem itself, I agree with Michal's point, that usually there
is no normal case that will change the overcommit_policy too frequently.

The code logic is mainly in overcommit_policy_handler(), based on the
previous sync fix. please help to review, thanks!

int overcommit_policy_handler(struct ctl_table *table, int write, void *buffer,
size_t *lenp, loff_t *ppos)
{
int ret;

if (write) {
int new_policy;
struct ctl_table t;

t = *table;
t.data = &new_policy;
ret = proc_dointvec_minmax(&t, write, buffer, lenp, ppos);
if (ret)
return ret;

mm_compute_batch(new_policy);
if (new_policy == OVERCOMMIT_NEVER)
schedule_on_each_cpu(sync_overcommit_as);
sysctl_overcommit_memory = new_policy;
} else {
ret = proc_dointvec_minmax(table, write, buffer, lenp, ppos);
}

return ret;
}

- Feng

Re: [PATCH v2 0/8] arm64: dts: qcom: smmu/USB nodes and HDK855/HDK865 dts

[Bjorn Andersson]

On Fri 03 Jul 05:31 PDT 2020, Will Deacon wrote:

> On Tue, Jun 09, 2020 at 03:40:18PM -0400, Jonathan Marek wrote:
> > Add dts nodes for apps_smmu and USB for both sm8150 and sm8250.
> > 
> > Also add initial dts files for HDK855 and HDK865, based on mtp dts, with a
> > few changes. Notably, the HDK865 dts has regulator config changed a bit 
> > based
> > on downstream (I think sm8250-mtp.dts is wrong and copied too much from 
> > sm8150).
> > 
> > V2 changes:
> > * Added two patches for sm8150 and sm8250 iommu compatibles
> > * Changed apps_smmu node patches to use new compatibles
> > * Updated commit messages for apps_smmu patches to be more correct
> > * Updated HDK dts patches based on Bjorn's comments
> > 
> > Jonathan Marek (8):
> >   dt-bindings: arm-smmu: Add sm8150 and sm8250 compatible strings
> >   iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatibles
> >   arm64: dts: qcom: sm8150: add apps_smmu node
> >   arm64: dts: qcom: sm8250: add apps_smmu node
> >   arm64: dts: qcom: sm8150: Add secondary USB and PHY nodes
> >   arm64: dts: qcom: sm8250: Add USB and PHY device nodes
> >   arm64: dts: qcom: add sm8150 hdk dts
> >   arm64: dts: qcom: add sm8250 hdk dts
> 
> What's your plan for merging this? I can take the first two patches
> via arm-smmu, if you like. Please just let me know.
> 

Please pick up the binding and driver patch through your tree.

Regards,
Bjorn

Re: [PATCH v2 2/8] iommu: arm-smmu-impl: Use qcom impl for sm8150 and sm8250 compatibles

[Bjorn Andersson]

On Tue 09 Jun 12:40 PDT 2020, Jonathan Marek wrote:

> Use the qcom implementation for IOMMU hardware on sm8150 and sm8250 SoCs.
> 
> Signed-off-by: Jonathan Marek 

Reviewed-by: Bjorn Andersson 

Regards,
Bjorn

> ---
>  drivers/iommu/arm-smmu-impl.c | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/drivers/iommu/arm-smmu-impl.c b/drivers/iommu/arm-smmu-impl.c
> index c75b9d957b70..f5f6cab626be 100644
> --- a/drivers/iommu/arm-smmu-impl.c
> +++ b/drivers/iommu/arm-smmu-impl.c
> @@ -172,7 +172,9 @@ struct arm_smmu_device *arm_smmu_impl_init(struct 
> arm_smmu_device *smmu)
>   smmu->impl = &calxeda_impl;
>  
>   if (of_device_is_compatible(np, "qcom,sdm845-smmu-500") ||
> - of_device_is_compatible(np, "qcom,sc7180-smmu-500"))
> + of_device_is_compatible(np, "qcom,sc7180-smmu-500") ||
> + of_device_is_compatible(np, "qcom,sm8150-smmu-500") ||
> + of_device_is_compatible(np, "qcom,sm8250-smmu-500"))
>   return qcom_smmu_impl_init(smmu);
>  
>   return smmu;
> -- 
> 2.26.1
> 
> 
> ___
> linux-arm-kernel mailing list
> linux-arm-ker...@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

[PATCH] riscv: Enable ELF-ASLR for riscv

[guoren]

From: Guo Ren 

Let riscv enable randomizes the stack, heap and binary images of
ELF binaries. Seems it's ok at all after qemu & chip test and
there is no founded side effect.

So just simply select ARCH_HAS_ELF_RANDOMIZE :)

Signed-off-by: Guo Ren 
Cc: Palmer Dabbelt 
Cc: Paul Walmsley 
Cc: Zong Li 
Cc: Greentime Hu 
---
 arch/riscv/Kconfig | 1 +
 1 file changed, 1 insertion(+)

diff --git a/arch/riscv/Kconfig b/arch/riscv/Kconfig
index 91bfc6c..eed6647 100644
--- a/arch/riscv/Kconfig
+++ b/arch/riscv/Kconfig
@@ -20,6 +20,7 @@ config RISCV
select ARCH_HAS_GIGANTIC_PAGE
select ARCH_HAS_MMIOWB
select ARCH_HAS_PTE_SPECIAL
+   select ARCH_HAS_ELF_RANDOMIZE
select ARCH_HAS_SET_DIRECT_MAP
select ARCH_HAS_SET_MEMORY
select ARCH_HAS_STRICT_KERNEL_RWX if MMU
-- 
2.7.4

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

[yangerkun]

在 2020/7/9 11:26, Stephen Rothwell 写道:

Hi all,

After merging the device-mapper tree, today's linux-next build (x86_64
allmodconfig) produced this warning:

In file included from drivers/md/dm-dust.c:11:
drivers/md/dm-dust.c: In function 'dust_list_badblocks':
drivers/md/dm-dust.c:307:10: warning: zero-length gnu_printf format string 
[-Wformat-zero-length]
   307 |   DMEMIT("");

Mike and Bryan,

Should we just use "DMEMIT("\n")"? Maybe it's bad since this lead a
blank line...



   |  ^~
include/linux/device-mapper.h:555:46: note: in definition of macro 'DMEMIT'
   555 |  0 : scnprintf(result + sz, maxlen - sz, x))
   |  ^

Introduced by commit

   20f93ea74f9c ("dm dust: add interface to list all badblocks")

[PATCH v2] kernel: Implement selective syscall userspace redirection

[Gabriel Krisman Bertazi]

Introduce a mechanism to quickly disable/enable syscall handling for a
specific process and redirect to userspace via SIGSYS.  This is useful
for processes with parts that require syscall redirection and parts that
don't, but who need to perform this boundary crossing really fast,
without paying the cost of a system call to reconfigure syscall handling
on each boundary transition.  This is particularly important for Windows
games running over Wine.

The proposed interface looks like this:

  prctl(PR_SET_SYSCALL_USER_DISPATCH, , , [selector])

Dispatcher is the address of a syscall instruction that is allowed to
by-pass the blockage, such that in fast paths you don't need to disable
the trap nor check the selector.  This is essential to return from
SIGSYS to a blocked area without triggering another SIGSYS from the
rt_sigreturn.

selector is an optional pointer to an aligned int-sized userspace memory
region that has a key switch for the mechanism. This key switch can be
PR_SYSCALL_DISPATCH_ENABLE, PR_SYSCALL_DISPATCH_DISABLE.

The feature is meant to be set per-thread and it is disabled on
fork/clone/execv.

Internally, this doesn't add overhead to the syscall hot path, and it
requires very little per-architecture support.  I avoided using seccomp,
even though it duplicates some functionality, due to previous feedback
that maybe it shouldn't mix with seccomp since it is not a security
mechanism.  And obviously, this should never be considered a security
mechanism, since any part of the program can by-pass it by using the
syscall dispatcher.

For the sysinfo benchmark, which measures the overhead added to
executing a native syscall that doesn't require interception, the
overhead using only dispatcher to issue syscalls is pretty much
irrelevant.  The overhead of selector goes around 40ns for a
native (untrapped) syscall in my system, and it is (as expected)
dominated by the supervisor-mode user-address access.  In fact, with
SMAP off, the overhead is consistently less than 5ns on my test box.

Right now, it is only supported by x86_64 and x86, but it should be
easily enabled for other architectures.

An example code using this interface can be found at:
  https://gitlab.collabora.com/krisman/syscall-disable-personality

Cc: Matthew Wilcox 
Cc: Andy Lutomirski 
Cc: Paul Gofman 
Cc: Kees Cook 
Signed-off-by: Gabriel Krisman Bertazi 
---
Changes since RFC:
  (Kees Cook suggestions)
  - Don't mention personality while explaining the feature
  - Use syscall_get_nr
  - Remove header guard on several places
  - Convert WARN_ON to WARN_ON_ONCE
  - Explicit check for state values
  - Rename to syscall user dispatcher

RFC/v1: https://lkml.org/lkml/2020/7/8/96

 arch/Kconfig  | 20 ++
 arch/x86/Kconfig  |  1 +
 arch/x86/entry/common.c   |  5 ++
 arch/x86/include/asm/thread_info.h|  4 +-
 fs/exec.c |  2 +
 include/linux/sched.h |  3 +
 include/linux/syscall_user_dispatch.h | 45 ++
 include/uapi/asm-generic/siginfo.h|  1 +
 include/uapi/linux/prctl.h|  4 ++
 kernel/Makefile   |  1 +
 kernel/fork.c |  1 +
 kernel/sys.c  |  8 +++
 kernel/syscall_user_dispatch.c| 90 +++
 13 files changed, 184 insertions(+), 1 deletion(-)
 create mode 100644 include/linux/syscall_user_dispatch.h
 create mode 100644 kernel/syscall_user_dispatch.c

diff --git a/arch/Kconfig b/arch/Kconfig
index 8cc35dc556c7..c182344374a1 100644
--- a/arch/Kconfig
+++ b/arch/Kconfig
@@ -465,6 +465,26 @@ config SECCOMP_FILTER
 
  See Documentation/userspace-api/seccomp_filter.rst for details.
 
+config HAVE_ARCH_SYSCALL_USER_DISPATCH
+   bool
+   help
+ An arch should select this symbol if it provides all of these things:
+ - TIF_SYSCALL_USER_DISPATCH
+ - syscall_get_arch
+ - syscall_rollback
+ - syscall_get_nr
+ - SIGSYS siginfo_t support
+
+config SYSCALL_USER_DISPATCH
+   bool "Support rejecting syscalls not coming from a dispatcher"
+   depends on HAVE_ARCH_SYSCALL_USER_DISPATCH
+   help
+ Enable tasks to ask the kernel to redirect syscalls not
+ issued from a predefined dispatcher back to userspace,
+ depending on a userspace selector.
+
+ This option is useful to optimize games running over Wine.
+
 config HAVE_ARCH_STACKLEAK
bool
help
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 883da0abf779..466a3a9c0708 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -149,6 +149,7 @@ config X86
select HAVE_ARCH_COMPAT_MMAP_BASES  if MMU && COMPAT
select HAVE_ARCH_PREL32_RELOCATIONS
select HAVE_ARCH_SECCOMP_FILTER
+   select HAVE_ARCH_SYSCALL_USER_DISPATCH
select HAVE_ARCH_THREAD_STRUCT_WHITELIST
select HAVE_ARCH_STACKLEAK
select HAVE_ARCH_TRAC

BUG: KASAN: global-out-of-bounds in is_affected_midr_range_list on arm64

[Naresh Kamboju]

While running LTP cpuhotplug test on mainline 5.8.0-rc4 the kernel BUG noticed
on arm64 Juno-r2 KASAN config enabled kernel.

steps to reproduce:
- boot KASAN enabled Juno-r2 device
- cd /opt/ltp
- ./runltp -f cpuhotplug

metadata:
  git branch: master
  git repo: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
  git commit: 63e1968a2c87e9461e9694a96991935116e0cec7
  kernel-config:
https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/kernel.config
  vmlinux: https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/vmlinux.xz
  system.map: https://builds.tuxbuild.com/wc75HkrGrWgQCdI-l_1jUw/System.map

Test log:
Name:   cpuhotplug02
Date:   Thu Jul  9 00:09:24 UTC 2020
Desc:   What happens to a process when its CPU is offlined?

CPU is 1
[  123.400330] process 722 (cpuhotplug_do_s) no longer affine to cpu1
[  123.400428] CPU1: shutdown
[  123.409425] psci: CPU1 killed (polled 0 ms)
[  123.752216] 
==
[  123.759476] BUG: KASAN: global-out-of-bounds in
is_affected_midr_range_list+0x50/0xe8
[  123.767327] Read of size 4 at addr a0001159bf78 by task swapper/1/0
[  123.773953]
[  123.775453] CPU: 1 PID: 0 Comm: swapper/1 Not tainted 5.8.0-rc4 #1
[  123.781648] Hardware name: ARM Juno development board (r2) (DT)
[  123.787579] Call trace:
[  123.790041]  dump_backtrace+0x0/0x2b8
[  123.793716]  show_stack+0x18/0x28
[  123.797043]  dump_stack+0xec/0x158
[  123.800456]  print_address_description.isra.0+0x6c/0x448
[  123.805785]  kasan_report+0x134/0x200
[  123.809457]  __asan_load4+0x9c/0xd8
[  123.812957]  is_affected_midr_range_list+0x50/0xe8
[  123.817763]  has_cortex_a76_erratum_1463225+0x10/0x30
[  123.822830]  verify_local_cpu_caps+0xbc/0x1a0
[  123.827202]  check_local_cpu_capabilities+0x24/0x128
[  123.832183]  secondary_start_kernel+0x1b8/0x2b0
[  123.836719]
[  123.838211] The buggy address belongs to the variable:
[  123.843364]  erratum_1463225+0x18/0x40
[  123.847117]
[  123.848607] Memory state around the buggy address:
[  123.853413]  a0001159be00: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[  123.860654]  a0001159be80: 00 00 00 00 00 00 00 00 00 00 00 00
00 00 00 00
[  123.867895] >a0001159bf00: 00 00 00 00 00 00 00 00 fa fa fa fa
00 00 00 fa
[  123.875131] ^
[  123.882286]  a0001159bf80: fa fa fa fa 00 00 00 00 00 00 00 00
00 fa fa fa
[  123.889526]  a0001159c000: fa fa fa fa 00 00 00 00 00 00 00 00
00 00 00 00
[  123.896762] 
==
[  123.903997] Disabling lock debugging due to kernel taint
[  123.909333] Detected PIPT I-cache on CPU1
[  123.913420] CPU1: Booted secondary processor 0x00 [0x410fd080]

Full test log link,
https://qa-reports.linaro.org/lkft/linux-mainline-oe/build/v5.8-rc4-81-g63e1968a2c87/testrun/299/suite/linux-log-parser/test/check-kernel-bug-1548361/log

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

[PATCH v4 0/5] Refactor handling flow of KVM_SET_CPUID*

[Xiaoyao Li]

4 Patches of v3 has been queued into kvm/queue branch. This v4 contains
the rest to refactor the flow of KVM_SET_CPUID* as:

1. cpuid check: check if userspace provides legal CPUID settings;

2. cpuid update: Update userspace provided CPUID settings. It currently
   only contains kvm_update_cpuid_runtime, which updates special CPUID
   bits based on the vcpu state, e.g., OSXSAVE, OSPKE. In the future, we
   can re-introduce kvm_update_cpuid() if KVM needs to force on/off some
   bits.

3. update vcpu states: Update vcpu states/settings based on the final updated
   CPUID settings. 

v4:
 - remove 4 queued patches
 - rebased to kvm/queue: c16ced9cc67a "x86/kvm/vmx: Use native read/write_cr2()"
 - fix one bug in v3 to call kvfree(cpuid_entries) in kvm_vcpu_ioctl_set_cpuid()
 - rename "update_vcpu_model" to "vcpu_after_set_cpuid" [Paolo] 
 - Add a new patch to extrace kvm_update_cpuid_runtime()

v3:
https://lkml.kernel.org/r/20200708065054.19713-1-xiaoyao...@intel.com
 - Add a note in KVM api doc to state the previous CPUID configuration
   is not reliable if current KVM_SET_CPUID* fails [Jim]
 - Adjust Patch 2 to reduce code churn [Sean]
 - Commit message refine to add more justification [Sean]
 - Add a new patch 7

v2:
https://lkml.kernel.org/r/20200623115816.24132-1-xiaoyao...@intel.com
 - rebase to kvm/queue: a037ff353ba6 ("Merge branch 'kvm-master' into HEAD")
 - change the name of kvm_update_state_based_on_cpuid() to
   kvm_update_vcpu_model() [Sean]
 - Add patch 5 to rename kvm_x86_ops.cpuid_date() to
   kvm_x86_ops.update_vcpu_model()

v1:
https://lkml.kernel.org/r/20200529085545.29242-1-xiaoyao...@intel.com

Xiaoyao Li (5):
  KVM: x86: Introduce kvm_check_cpuid()
  KVM: x86: Extract kvm_update_cpuid_runtime() from kvm_update_cpuid()
  KVM: x86: Rename kvm_update_cpuid() to kvm_vcpu_after_set_cpuid()
  KVM: x86: Rename cpuid_update() callback to vcpu_after_set_cpuid()
  KVM: x86: Move kvm_x86_ops.vcpu_after_set_cpuid() into
kvm_vcpu_after_set_cpuid()

 arch/x86/include/asm/kvm_host.h |  2 +-
 arch/x86/kvm/cpuid.c| 99 +
 arch/x86/kvm/cpuid.h|  2 +-
 arch/x86/kvm/lapic.c|  2 +-
 arch/x86/kvm/svm/svm.c  |  4 +-
 arch/x86/kvm/vmx/nested.c   |  3 +-
 arch/x86/kvm/vmx/vmx.c  |  4 +-
 arch/x86/kvm/x86.c  | 10 ++--
 8 files changed, 76 insertions(+), 50 deletions(-)

-- 
2.18.4

[PATCH v4 1/5] KVM: x86: Introduce kvm_check_cpuid()

[Xiaoyao Li]

Use kvm_check_cpuid() to validate if userspace provides legal cpuid
settings and call it before KVM take any action to update CPUID or
update vcpu states based on given CPUID settings.

Signed-off-by: Xiaoyao Li 
---
 arch/x86/kvm/cpuid.c | 55 
 arch/x86/kvm/cpuid.h |  2 +-
 2 files changed, 36 insertions(+), 21 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index eebd66f86abe..1a053022a961 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -54,7 +54,26 @@ static u32 xstate_required_size(u64 xstate_bv, bool 
compacted)
 
 #define F feature_bit
 
-int kvm_update_cpuid(struct kvm_vcpu *vcpu)
+static int kvm_check_cpuid(struct kvm_vcpu *vcpu)
+{
+   struct kvm_cpuid_entry2 *best;
+
+   /*
+* The existing code assumes virtual address is 48-bit or 57-bit in the
+* canonical address checks; exit if it is ever changed.
+*/
+   best = kvm_find_cpuid_entry(vcpu, 0x8008, 0);
+   if (best) {
+   int vaddr_bits = (best->eax & 0xff00) >> 8;
+
+   if (vaddr_bits != 48 && vaddr_bits != 57 && vaddr_bits != 0)
+   return -EINVAL;
+   }
+
+   return 0;
+}
+
+void kvm_update_cpuid(struct kvm_vcpu *vcpu)
 {
struct kvm_cpuid_entry2 *best;
struct kvm_lapic *apic = vcpu->arch.apic;
@@ -98,18 +117,6 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
 cpuid_entry_has(best, X86_FEATURE_XSAVEC)))
best->ebx = xstate_required_size(vcpu->arch.xcr0, true);
 
-   /*
-* The existing code assumes virtual address is 48-bit or 57-bit in the
-* canonical address checks; exit if it is ever changed.
-*/
-   best = kvm_find_cpuid_entry(vcpu, 0x8008, 0);
-   if (best) {
-   int vaddr_bits = (best->eax & 0xff00) >> 8;
-
-   if (vaddr_bits != 48 && vaddr_bits != 57 && vaddr_bits != 0)
-   return -EINVAL;
-   }
-
best = kvm_find_cpuid_entry(vcpu, KVM_CPUID_FEATURES, 0);
if (kvm_hlt_in_guest(vcpu->kvm) && best &&
(best->eax & (1 << KVM_FEATURE_PV_UNHALT)))
@@ -131,7 +138,6 @@ int kvm_update_cpuid(struct kvm_vcpu *vcpu)
kvm_pmu_refresh(vcpu);
vcpu->arch.cr4_guest_rsvd_bits =
__cr4_reserved_bits(guest_cpuid_has, vcpu);
-   return 0;
 }
 
 static int is_efer_nx(void)
@@ -206,11 +212,16 @@ int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
vcpu->arch.cpuid_entries[i].padding[2] = 0;
}
vcpu->arch.cpuid_nent = cpuid->nent;
+   r = kvm_check_cpuid(vcpu);
+   if (r) {
+   vcpu->arch.cpuid_nent = 0;
+   kvfree(cpuid_entries);
+   goto out;
+   }
+
cpuid_fix_nx_cap(vcpu);
kvm_x86_ops.cpuid_update(vcpu);
-   r = kvm_update_cpuid(vcpu);
-   if (r)
-   vcpu->arch.cpuid_nent = 0;
+   kvm_update_cpuid(vcpu);
 
kvfree(cpuid_entries);
 out:
@@ -231,10 +242,14 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,
   cpuid->nent * sizeof(struct kvm_cpuid_entry2)))
goto out;
vcpu->arch.cpuid_nent = cpuid->nent;
-   kvm_x86_ops.cpuid_update(vcpu);
-   r = kvm_update_cpuid(vcpu);
-   if (r)
+   r = kvm_check_cpuid(vcpu);
+   if (r) {
vcpu->arch.cpuid_nent = 0;
+   goto out;
+   }
+
+   kvm_x86_ops.cpuid_update(vcpu);
+   kvm_update_cpuid(vcpu);
 out:
return r;
 }
diff --git a/arch/x86/kvm/cpuid.h b/arch/x86/kvm/cpuid.h
index 05434cd9342f..f136de1debad 100644
--- a/arch/x86/kvm/cpuid.h
+++ b/arch/x86/kvm/cpuid.h
@@ -9,7 +9,7 @@
 extern u32 kvm_cpu_caps[NCAPINTS] __read_mostly;
 void kvm_set_cpu_caps(void);
 
-int kvm_update_cpuid(struct kvm_vcpu *vcpu);
+void kvm_update_cpuid(struct kvm_vcpu *vcpu);
 struct kvm_cpuid_entry2 *kvm_find_cpuid_entry(struct kvm_vcpu *vcpu,
  u32 function, u32 index);
 int kvm_dev_ioctl_get_cpuid(struct kvm_cpuid2 *cpuid,
-- 
2.18.4

[PATCH v4 4/5] KVM: x86: Rename cpuid_update() callback to vcpu_after_set_cpuid()

[Xiaoyao Li]

The name of callback cpuid_update() is misleading that it's not about
updating CPUID settings of vcpu but updating the configurations of vcpu
based on the CPUIDs. So rename it to vcpu_after_set_cpuid().

Signed-off-by: Xiaoyao Li 
---
 arch/x86/include/asm/kvm_host.h | 2 +-
 arch/x86/kvm/cpuid.c| 4 ++--
 arch/x86/kvm/svm/svm.c  | 4 ++--
 arch/x86/kvm/vmx/nested.c   | 3 ++-
 arch/x86/kvm/vmx/vmx.c  | 4 ++--
 5 files changed, 9 insertions(+), 8 deletions(-)

diff --git a/arch/x86/include/asm/kvm_host.h b/arch/x86/include/asm/kvm_host.h
index 16461a674406..3d7d818a282c 100644
--- a/arch/x86/include/asm/kvm_host.h
+++ b/arch/x86/include/asm/kvm_host.h
@@ -1052,7 +1052,7 @@ struct kvm_x86_ops {
void (*hardware_unsetup)(void);
bool (*cpu_has_accelerated_tpr)(void);
bool (*has_emulated_msr)(u32 index);
-   void (*cpuid_update)(struct kvm_vcpu *vcpu);
+   void (*vcpu_after_set_cpuid)(struct kvm_vcpu *vcpu);
 
unsigned int vm_size;
int (*vm_init)(struct kvm *kvm);
diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index b602c0c9078e..832a24c1334e 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -228,7 +228,7 @@ int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
}
 
cpuid_fix_nx_cap(vcpu);
-   kvm_x86_ops.cpuid_update(vcpu);
+   kvm_x86_ops.vcpu_after_set_cpuid(vcpu);
kvm_update_cpuid_runtime(vcpu);
kvm_vcpu_after_set_cpuid(vcpu);
 
@@ -257,7 +257,7 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,
goto out;
}
 
-   kvm_x86_ops.cpuid_update(vcpu);
+   kvm_x86_ops.vcpu_after_set_cpuid(vcpu);
kvm_update_cpuid_runtime(vcpu);
kvm_vcpu_after_set_cpuid(vcpu);
 out:
diff --git a/arch/x86/kvm/svm/svm.c b/arch/x86/kvm/svm/svm.c
index 6d49afa3063f..535ad311ad02 100644
--- a/arch/x86/kvm/svm/svm.c
+++ b/arch/x86/kvm/svm/svm.c
@@ -3595,7 +3595,7 @@ static u64 svm_get_mt_mask(struct kvm_vcpu *vcpu, gfn_t 
gfn, bool is_mmio)
return 0;
 }
 
-static void svm_cpuid_update(struct kvm_vcpu *vcpu)
+static void svm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 {
struct vcpu_svm *svm = to_svm(vcpu);
 
@@ -4095,7 +4095,7 @@ static struct kvm_x86_ops svm_x86_ops __initdata = {
 
.get_exit_info = svm_get_exit_info,
 
-   .cpuid_update = svm_cpuid_update,
+   .vcpu_after_set_cpuid = svm_vcpu_after_set_cpuid,
 
.has_wbinvd_exit = svm_has_wbinvd_exit,
 
diff --git a/arch/x86/kvm/vmx/nested.c b/arch/x86/kvm/vmx/nested.c
index 7693d41a2446..e4080ab2df21 100644
--- a/arch/x86/kvm/vmx/nested.c
+++ b/arch/x86/kvm/vmx/nested.c
@@ -6354,7 +6354,8 @@ void nested_vmx_setup_ctls_msrs(struct nested_vmx_msrs 
*msrs, u32 ept_caps)
 
/*
 * secondary cpu-based controls.  Do not include those that
-* depend on CPUID bits, they are added later by vmx_cpuid_update.
+* depend on CPUID bits, they are added later by
+* vmx_vcpu_after_set_cpuid.
 */
if (msrs->procbased_ctls_high & CPU_BASED_ACTIVATE_SECONDARY_CONTROLS)
rdmsr(MSR_IA32_VMX_PROCBASED_CTLS2,
diff --git a/arch/x86/kvm/vmx/vmx.c b/arch/x86/kvm/vmx/vmx.c
index 0cdc78f2f2f4..2b41d987b101 100644
--- a/arch/x86/kvm/vmx/vmx.c
+++ b/arch/x86/kvm/vmx/vmx.c
@@ -7282,7 +7282,7 @@ static void update_intel_pt_cfg(struct kvm_vcpu *vcpu)
vmx->pt_desc.ctl_bitmask &= ~(0xfULL << (32 + i * 4));
 }
 
-static void vmx_cpuid_update(struct kvm_vcpu *vcpu)
+static void vmx_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 {
struct vcpu_vmx *vmx = to_vmx(vcpu);
 
@@ -7940,7 +7940,7 @@ static struct kvm_x86_ops vmx_x86_ops __initdata = {
 
.get_exit_info = vmx_get_exit_info,
 
-   .cpuid_update = vmx_cpuid_update,
+   .vcpu_after_set_cpuid = vmx_vcpu_after_set_cpuid,
 
.has_wbinvd_exit = cpu_has_vmx_wbinvd_exit,
 
-- 
2.18.4

[PATCH v4 3/5] KVM: x86: Rename kvm_update_cpuid() to kvm_vcpu_after_set_cpuid()

[Xiaoyao Li]

Now there is no updating CPUID bits behavior in kvm_update_cpuid(),
rename it to kvm_vcpu_after_set_cpuid().

Signed-off-by: Xiaoyao Li 
---
 arch/x86/kvm/cpuid.c | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
index 0ed3b343c44e..b602c0c9078e 100644
--- a/arch/x86/kvm/cpuid.c
+++ b/arch/x86/kvm/cpuid.c
@@ -116,7 +116,7 @@ void kvm_update_cpuid_runtime(struct kvm_vcpu *vcpu)
}
 }
 
-static void kvm_update_cpuid(struct kvm_vcpu *vcpu)
+static void kvm_vcpu_after_set_cpuid(struct kvm_vcpu *vcpu)
 {
struct kvm_lapic *apic = vcpu->arch.apic;
struct kvm_cpuid_entry2 *best;
@@ -230,7 +230,7 @@ int kvm_vcpu_ioctl_set_cpuid(struct kvm_vcpu *vcpu,
cpuid_fix_nx_cap(vcpu);
kvm_x86_ops.cpuid_update(vcpu);
kvm_update_cpuid_runtime(vcpu);
-   kvm_update_cpuid(vcpu);
+   kvm_vcpu_after_set_cpuid(vcpu);
 
kvfree(cpuid_entries);
 out:
@@ -259,7 +259,7 @@ int kvm_vcpu_ioctl_set_cpuid2(struct kvm_vcpu *vcpu,
 
kvm_x86_ops.cpuid_update(vcpu);
kvm_update_cpuid_runtime(vcpu);
-   kvm_update_cpuid(vcpu);
+   kvm_vcpu_after_set_cpuid(vcpu);
 out:
return r;
 }
-- 
2.18.4