date:20201115

Hi Meng,

Thank you for the patch! Yet something to improve:

[auto build test ERROR on cryptodev/master]
[also build test ERROR on crypto/master v5.10-rc3 next-20201113]
[cannot apply to sparc-next/master]
[If your patch is applied to the wrong git tree, kindly drop us a note.
And when submitting patch, we suggest to use '--base' as documented in
https://git-scm.com/docs/git-format-patch]

url:
https://github.com/0day-ci/linux/commits/Meng-Yu/crypto-hisilicon-hpre-add-something-for-Kunpeng-930/20201102-103450
base:   
https://git.kernel.org/pub/scm/linux/kernel/git/herbert/cryptodev-2.6.git master
config: arm64-defconfig (attached as .config)
compiler: aarch64-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
# 
https://github.com/0day-ci/linux/commit/c6ca2d701fee193538b8aeac13909c5e7f5bc3f9
git remote add linux-review https://github.com/0day-ci/linux
git fetch --no-tags linux-review 
Meng-Yu/crypto-hisilicon-hpre-add-something-for-Kunpeng-930/20201102-103450
git checkout c6ca2d701fee193538b8aeac13909c5e7f5bc3f9
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=arm64 

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

All errors (new ones prefixed by >>, old ones prefixed by <<):

>> ERROR: modpost: "curve25519_null_point" 
>> [drivers/crypto/hisilicon/hpre/hisi_hpre.ko] undefined!

---
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] perf stat: Take cgroups into account for shadow stats

2020-11-15 Thread Andi Kleen

Actually thinking about it more you should probably pass around ctx/cgroup
in a single abstract argument. Otherwise have to change all the metrics
functions for the next filter too.

Re: [PATCH] perf stat: Take cgroups into account for shadow stats

2020-11-15 Thread Andi Kleen

> @@ -57,6 +59,9 @@ static int saved_value_cmp(struct rb_node *rb_node, const 
> void *entry)
>   if (a->ctx != b->ctx)
>   return a->ctx - b->ctx;
>  
> + if (a->cgrp != b->cgrp)
> + return (char *)a->cgrp < (char *)b->cgrp ? -1 : +1;

This means the sort order will depend on heap randomization, 
which will make it harder to debug.

Better use something stable like the inode number of the cgroup.

Do we have the same problem with other filters?

The rest of the patch looks good to me.

-Andi

[GIT pull] sched/urgent for v5.10-rc4

Linus,

please pull the latest sched/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
sched-urgent-2020-11-15

up to:  8d4d9c7b4333: sched/debug: Fix memory corruption caused by multiple 
small reads of flags


A set of scheduler fixes:

 - Address a load balancer regression by making the load balancer use the
   same logic as the wakeup path to spread tasks in the LLC domain.

 - Prefer the CPU on which a task run last over the local CPU in the fast
   wakeup path for asymmetric CPU capacity systems to align with the
   symmetric case. This ensures more locality and prevents massive
   migration overhead on those asymetric systems

 - Fix a memory corruption bug in the scheduler debug code caused by
   handing a modified buffer pointer to kfree().

Thanks,

tglx

-->
Colin Ian King (1):
  sched/debug: Fix memory corruption caused by multiple small reads of flags

Vincent Guittot (2):
  sched/fair: Ensure tasks spreading in LLC during LB
  sched/fair: Prefer prev cpu in asymmetric wakeup path


 kernel/sched/debug.c | 12 -
 kernel/sched/fair.c  | 70 +---
 2 files changed, 51 insertions(+), 31 deletions(-)

diff --git a/kernel/sched/debug.c b/kernel/sched/debug.c
index 0655524700d2..2357921580f9 100644
--- a/kernel/sched/debug.c
+++ b/kernel/sched/debug.c
@@ -251,7 +251,7 @@ static int sd_ctl_doflags(struct ctl_table *table, int 
write,
unsigned long flags = *(unsigned long *)table->data;
size_t data_size = 0;
size_t len = 0;
-   char *tmp;
+   char *tmp, *buf;
int idx;
 
if (write)
@@ -269,17 +269,17 @@ static int sd_ctl_doflags(struct ctl_table *table, int 
write,
return 0;
}
 
-   tmp = kcalloc(data_size + 1, sizeof(*tmp), GFP_KERNEL);
-   if (!tmp)
+   buf = kcalloc(data_size + 1, sizeof(*buf), GFP_KERNEL);
+   if (!buf)
return -ENOMEM;
 
for_each_set_bit(idx, , __SD_FLAG_CNT) {
char *name = sd_flag_debug[idx].name;
 
-   len += snprintf(tmp + len, strlen(name) + 2, "%s ", name);
+   len += snprintf(buf + len, strlen(name) + 2, "%s ", name);
}
 
-   tmp += *ppos;
+   tmp = buf + *ppos;
len -= *ppos;
 
if (len > *lenp)
@@ -294,7 +294,7 @@ static int sd_ctl_doflags(struct ctl_table *table, int 
write,
*lenp = len;
*ppos += len;
 
-   kfree(tmp);
+   kfree(buf);
 
return 0;
 }
diff --git a/kernel/sched/fair.c b/kernel/sched/fair.c
index aa4c6227cd6d..8e563cf2b5e7 100644
--- a/kernel/sched/fair.c
+++ b/kernel/sched/fair.c
@@ -6172,21 +6172,21 @@ static int select_idle_cpu(struct task_struct *p, 
struct sched_domain *sd, int t
 static int
 select_idle_capacity(struct task_struct *p, struct sched_domain *sd, int 
target)
 {
-   unsigned long best_cap = 0;
+   unsigned long task_util, best_cap = 0;
int cpu, best_cpu = -1;
struct cpumask *cpus;
 
-   sync_entity_load_avg(>se);
-
cpus = this_cpu_cpumask_var_ptr(select_idle_mask);
cpumask_and(cpus, sched_domain_span(sd), p->cpus_ptr);
 
+   task_util = uclamp_task_util(p);
+
for_each_cpu_wrap(cpu, cpus, target) {
unsigned long cpu_cap = capacity_of(cpu);
 
if (!available_idle_cpu(cpu) && !sched_idle_cpu(cpu))
continue;
-   if (task_fits_capacity(p, cpu_cap))
+   if (fits_capacity(task_util, cpu_cap))
return cpu;
 
if (cpu_cap > best_cap) {
@@ -6198,44 +6198,42 @@ select_idle_capacity(struct task_struct *p, struct 
sched_domain *sd, int target)
return best_cpu;
 }
 
+static inline bool asym_fits_capacity(int task_util, int cpu)
+{
+   if (static_branch_unlikely(_asym_cpucapacity))
+   return fits_capacity(task_util, capacity_of(cpu));
+
+   return true;
+}
+
 /*
  * Try and locate an idle core/thread in the LLC cache domain.
  */
 static int select_idle_sibling(struct task_struct *p, int prev, int target)
 {
struct sched_domain *sd;
+   unsigned long task_util;
int i, recent_used_cpu;
 
/*
-* For asymmetric CPU capacity systems, our domain of interest is
-* sd_asym_cpucapacity rather than sd_llc.
+* On asymmetric system, update task utilization because we will check
+* that the task fits with cpu's capacity.
 */
if (static_branch_unlikely(_asym_cpucapacity)) {
-   sd = rcu_dereference(per_cpu(sd_asym_cpucapacity, target));
-   /*
-* On an asymmetric CPU capacity system where an exclusive
-* cpuset defines a symmetric island (i.e. one unique
-* capacity_orig value through the cpuset), the key will be set
-* but the CPUs within that cpuset will not have a domain with
-

[GIT pull] perf/urgent for v5.10-rc4

Linus,

please pull the latest perf/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
perf-urgent-2020-11-15

up to:  1a8cfa24e21c: perf/x86/intel/uncore: Fix Add BW copypasta

A set of fixes for perf:

 - A set of commits which reduce the stack usage of various perf event
   handling functions which allocated large data structs on stack causing
   stack overflows in the worst case.

 - Use the proper mechanism for detecting soft interrupts in the recursion
   protection.

 - Make the resursion protection simpler and more robust.

 - Simplify the scheduling of event groups to make the code more robust and
   prepare for fixing the issues vs. scheduling of exclusive event groups.

 - Prevent event multiplexing and rotation for exclusive event groups

 - Correct the perf event attribute exclusive semantics to take pinned
   events, e.g. the PMU watchdog, into account

 - Make the anythread filtering conditional for Intel's generic PMU
   counters as it is not longer guaranteed to be supported on newer
   CPUs. Check the corresponding CPUID leaf to make sure.

 - Fixup a duplicate initialization in an array which was probably cause by
   the usual copy & paste - forgot to edit mishap.

Thanks,

tglx

-->
Arnd Bergmann (1):
  perf/x86/intel/uncore: Fix Add BW copypasta

Peter Zijlstra (10):
  perf: Reduce stack usage of perf_output_begin()
  perf/x86: Reduce stack usage for x86_pmu::drain_pebs()
  perf: Fix get_recursion_context()
  perf: Optimize get_recursion_context()
  perf/arch: Remove perf_sample_data::regs_user_copy
  perf/x86: Make dummy_iregs static
  perf: Simplify group_sched_out()
  perf: Simplify group_sched_in()
  perf: Fix event multiplexing for exclusive groups
  perf: Tweak perf_event_attr::exclusive semantics

Stephane Eranian (1):
  perf/x86/intel: Make anythread filter support conditional


 arch/arm/kernel/perf_regs.c|  3 +-
 arch/arm64/kernel/perf_regs.c  |  3 +-
 arch/csky/kernel/perf_regs.c   |  3 +-
 arch/powerpc/perf/imc-pmu.c|  2 +-
 arch/powerpc/perf/perf_regs.c  |  3 +-
 arch/riscv/kernel/perf_regs.c  |  3 +-
 arch/s390/kernel/perf_cpum_sf.c|  2 +-
 arch/s390/kernel/perf_regs.c   |  3 +-
 arch/x86/events/intel/core.c   | 12 +++-
 arch/x86/events/intel/ds.c | 53 ++-
 arch/x86/events/intel/uncore_snb.c |  2 +-
 arch/x86/events/perf_event.h   |  3 +-
 arch/x86/include/asm/perf_event.h  |  4 ++-
 arch/x86/kernel/perf_regs.c| 15 +++---
 arch/x86/kvm/cpuid.c   |  4 ++-
 include/linux/perf_event.h | 13 -
 include/linux/perf_regs.h  |  6 ++--
 kernel/events/core.c   | 57 +-
 kernel/events/internal.h   | 16 ---
 kernel/events/ring_buffer.c| 20 +++--
 20 files changed, 116 insertions(+), 111 deletions(-)

diff --git a/arch/arm/kernel/perf_regs.c b/arch/arm/kernel/perf_regs.c
index 05fe92aa7d98..0529f90395c9 100644
--- a/arch/arm/kernel/perf_regs.c
+++ b/arch/arm/kernel/perf_regs.c
@@ -32,8 +32,7 @@ u64 perf_reg_abi(struct task_struct *task)
 }
 
 void perf_get_regs_user(struct perf_regs *regs_user,
-   struct pt_regs *regs,
-   struct pt_regs *regs_user_copy)
+   struct pt_regs *regs)
 {
regs_user->regs = task_pt_regs(current);
regs_user->abi = perf_reg_abi(current);
diff --git a/arch/arm64/kernel/perf_regs.c b/arch/arm64/kernel/perf_regs.c
index 94e8718e7229..f6f58e6265df 100644
--- a/arch/arm64/kernel/perf_regs.c
+++ b/arch/arm64/kernel/perf_regs.c
@@ -73,8 +73,7 @@ u64 perf_reg_abi(struct task_struct *task)
 }
 
 void perf_get_regs_user(struct perf_regs *regs_user,
-   struct pt_regs *regs,
-   struct pt_regs *regs_user_copy)
+   struct pt_regs *regs)
 {
regs_user->regs = task_pt_regs(current);
regs_user->abi = perf_reg_abi(current);
diff --git a/arch/csky/kernel/perf_regs.c b/arch/csky/kernel/perf_regs.c
index eb32838b8210..09b7f88a2d6a 100644
--- a/arch/csky/kernel/perf_regs.c
+++ b/arch/csky/kernel/perf_regs.c
@@ -32,8 +32,7 @@ u64 perf_reg_abi(struct task_struct *task)
 }
 
 void perf_get_regs_user(struct perf_regs *regs_user,
-   struct pt_regs *regs,
-   struct pt_regs *regs_user_copy)
+   struct pt_regs *regs)
 {
regs_user->regs = task_pt_regs(current);
regs_user->abi = perf_reg_abi(current);
diff --git a/arch/powerpc/perf/imc-pmu.c b/arch/powerpc/perf/imc-pmu.c
index 9ed4fcccf8a9..7b25548ec42b 100644
--- a/arch/powerpc/perf/imc-pmu.c
+++ b/arch/powerpc/perf/imc-pmu.c
@@ -1336,7 +1336,7 @@ static void dump_trace_imc_data(struct perf_event *event)
/* If this is a valid record, create the sample */

[GIT pull] x86/urgent for v5.10-rc4

Linus,

please pull the latest x86/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
x86-urgent-2020-11-15

up to:  ff828729be44: iommu/vt-d: Cure VF irqdomain hickup


A small set of fixes for x86:

 - Cure the fallout from the MSI irqdomain overhaul which missed that the
   Intel IOMMU does not register virtual function devices and therefore
   never reaches the point where the MSI interrupt domain is assigned. This
   makes the VF devices use the non-remapped MSI domain which is trapped by
   the IOMMU/remap unit.

 - Remove an extra space in the SGI_UV architecture type procfs output for
   UV5.

 - Remove a unused function which was missed when removing the UV BAU TLB
   shootdown handler.

Thanks,

tglx

-->
Jiri Slaby (1):
  x86/platform/uv: Drop last traces of uv_flush_tlb_others

Mike Travis (1):
  x86/platform/uv: Fix copied UV5 output archtype

Thomas Gleixner (1):
  iommu/vt-d: Cure VF irqdomain hickup


 arch/x86/include/asm/uv/uv.h   | 10 --
 arch/x86/kernel/apic/x2apic_uv_x.c |  6 +++---
 drivers/iommu/intel/dmar.c | 19 ++-
 3 files changed, 21 insertions(+), 14 deletions(-)

diff --git a/arch/x86/include/asm/uv/uv.h b/arch/x86/include/asm/uv/uv.h
index 172d3e4a9e4b..648eb23fe7f0 100644
--- a/arch/x86/include/asm/uv/uv.h
+++ b/arch/x86/include/asm/uv/uv.h
@@ -2,14 +2,8 @@
 #ifndef _ASM_X86_UV_UV_H
 #define _ASM_X86_UV_UV_H
 
-#include 
-
 enum uv_system_type {UV_NONE, UV_LEGACY_APIC, UV_X2APIC};
 
-struct cpumask;
-struct mm_struct;
-struct flush_tlb_info;
-
 #ifdef CONFIG_X86_UV
 #include 
 
@@ -44,10 +38,6 @@ static inline int is_uv_system(void) { return 0; }
 static inline int is_uv_hubbed(int uv) { return 0; }
 static inline void uv_cpu_init(void)   { }
 static inline void uv_system_init(void){ }
-static inline const struct cpumask *
-uv_flush_tlb_others(const struct cpumask *cpumask,
-   const struct flush_tlb_info *info)
-{ return cpumask; }
 
 #endif /* X86_UV */
 
diff --git a/arch/x86/kernel/apic/x2apic_uv_x.c 
b/arch/x86/kernel/apic/x2apic_uv_x.c
index 3115caa7d7d0..1b98f8c12b96 100644
--- a/arch/x86/kernel/apic/x2apic_uv_x.c
+++ b/arch/x86/kernel/apic/x2apic_uv_x.c
@@ -33,7 +33,7 @@ static union uvh_apicid   uvh_apicid;
 static int uv_node_id;
 
 /* Unpack AT/OEM/TABLE ID's to be NULL terminated strings */
-static u8 uv_archtype[UV_AT_SIZE];
+static u8 uv_archtype[UV_AT_SIZE + 1];
 static u8 oem_id[ACPI_OEM_ID_SIZE + 1];
 static u8 oem_table_id[ACPI_OEM_TABLE_ID_SIZE + 1];
 
@@ -320,7 +320,7 @@ static int __init decode_arch_type(unsigned long ptr)
 
if (n > 0 && n < sizeof(uv_ate->archtype)) {
pr_info("UV: UVarchtype received from BIOS\n");
-   uv_stringify(UV_AT_SIZE, uv_archtype, uv_ate->archtype);
+   uv_stringify(sizeof(uv_archtype), uv_archtype, 
uv_ate->archtype);
return 1;
}
return 0;
@@ -378,7 +378,7 @@ static int __init uv_set_system_type(char *_oem_id, char 
*_oem_table_id)
if (!early_get_arch_type())
 
/* If not use OEM ID for UVarchtype */
-   uv_stringify(UV_AT_SIZE, uv_archtype, _oem_id);
+   uv_stringify(sizeof(uv_archtype), uv_archtype, oem_id);
 
/* Check if not hubbed */
if (strncmp(uv_archtype, "SGI", 3) != 0) {
diff --git a/drivers/iommu/intel/dmar.c b/drivers/iommu/intel/dmar.c
index 404b40af31cb..b2e804473209 100644
--- a/drivers/iommu/intel/dmar.c
+++ b/drivers/iommu/intel/dmar.c
@@ -333,6 +333,11 @@ static void  dmar_pci_bus_del_dev(struct 
dmar_pci_notify_info *info)
dmar_iommu_notify_scope_dev(info);
 }
 
+static inline void vf_inherit_msi_domain(struct pci_dev *pdev)
+{
+   dev_set_msi_domain(>dev, dev_get_msi_domain(>physfn->dev));
+}
+
 static int dmar_pci_bus_notifier(struct notifier_block *nb,
 unsigned long action, void *data)
 {
@@ -342,8 +347,20 @@ static int dmar_pci_bus_notifier(struct notifier_block *nb,
/* Only care about add/remove events for physical functions.
 * For VFs we actually do the lookup based on the corresponding
 * PF in device_to_iommu() anyway. */
-   if (pdev->is_virtfn)
+   if (pdev->is_virtfn) {
+   /*
+* Ensure that the VF device inherits the irq domain of the
+* PF device. Ideally the device would inherit the domain
+* from the bus, but DMAR can have multiple units per bus
+* which makes this impossible. The VF 'bus' could inherit
+* from the PF device, but that's yet another x86'sism to
+* inflict on everybody else.
+*/
+   if (action == BUS_NOTIFY_ADD_DEVICE)
+   vf_inherit_msi_domain(pdev);
return NOTIFY_DONE;
+   }
+
if (action != BUS_NOTIFY_ADD_DEVICE &&

[GIT pull] locking/urgent for v5.10-rc4

Linus,

please pull the latest locking/urgent branch from:

   git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git 
locking-urgent-2020-11-15

up to:  d61fc96a3760: lockdep: Avoid to modify chain keys in validate_chain()


Two fixes for the locking subsystem:

  - Prevent an unconditional interrupt enable in a futex helper function
which can be called from contexts which expect interrupts to stay
disabled across the call.

  - Don't modify lockdep chain keys in the validation process as that
causes chain inconsistency.

Thanks,

tglx

-->
Boqun Feng (1):
  lockdep: Avoid to modify chain keys in validate_chain()

Dan Carpenter (1):
  futex: Don't enable IRQs unconditionally in put_pi_state()


 kernel/futex.c   |  5 +++--
 kernel/locking/lockdep.c | 19 +--
 2 files changed, 12 insertions(+), 12 deletions(-)

diff --git a/kernel/futex.c b/kernel/futex.c
index ac328874f6e5..00259c7e288e 100644
--- a/kernel/futex.c
+++ b/kernel/futex.c
@@ -788,8 +788,9 @@ static void put_pi_state(struct futex_pi_state *pi_state)
 */
if (pi_state->owner) {
struct task_struct *owner;
+   unsigned long flags;
 
-   raw_spin_lock_irq(_state->pi_mutex.wait_lock);
+   raw_spin_lock_irqsave(_state->pi_mutex.wait_lock, flags);
owner = pi_state->owner;
if (owner) {
raw_spin_lock(>pi_lock);
@@ -797,7 +798,7 @@ static void put_pi_state(struct futex_pi_state *pi_state)
raw_spin_unlock(>pi_lock);
}
rt_mutex_proxy_unlock(_state->pi_mutex, owner);
-   raw_spin_unlock_irq(_state->pi_mutex.wait_lock);
+   raw_spin_unlock_irqrestore(_state->pi_mutex.wait_lock, 
flags);
}
 
if (current->pi_state_cache) {
diff --git a/kernel/locking/lockdep.c b/kernel/locking/lockdep.c
index b71ad8d9f1c9..d9fb9e19d2ed 100644
--- a/kernel/locking/lockdep.c
+++ b/kernel/locking/lockdep.c
@@ -2765,7 +2765,9 @@ print_deadlock_bug(struct task_struct *curr, struct 
held_lock *prev,
  * (Note that this has to be done separately, because the graph cannot
  * detect such classes of deadlocks.)
  *
- * Returns: 0 on deadlock detected, 1 on OK, 2 on recursive read
+ * Returns: 0 on deadlock detected, 1 on OK, 2 if another lock with the same
+ * lock class is held but nest_lock is also held, i.e. we rely on the
+ * nest_lock to avoid the deadlock.
  */
 static int
 check_deadlock(struct task_struct *curr, struct held_lock *next)
@@ -2788,7 +2790,7 @@ check_deadlock(struct task_struct *curr, struct held_lock 
*next)
 * lock class (i.e. read_lock(lock)+read_lock(lock)):
 */
if ((next->read == 2) && prev->read)
-   return 2;
+   continue;
 
/*
 * We're holding the nest_lock, which serializes this lock's
@@ -3592,16 +3594,13 @@ static int validate_chain(struct task_struct *curr,
 
if (!ret)
return 0;
-   /*
-* Mark recursive read, as we jump over it when
-* building dependencies (just like we jump over
-* trylock entries):
-*/
-   if (ret == 2)
-   hlock->read = 2;
/*
 * Add dependency only if this lock is not the head
-* of the chain, and if it's not a secondary read-lock:
+* of the chain, and if the new lock introduces no more
+* lock dependency (because we already hold a lock with the
+* same lock class) nor deadlock (because the nest_lock
+* serializes nesting locks), see the comments for
+* check_deadlock().
 */
if (!chain_head && ret != 2) {
if (!check_prevs_add(curr, hlock))

Re: [PATCH RFC v3] ipvs: add genetlink cmd to dump all services and destinations

2020-11-15 Thread Julian Anastasov



Hello,

On Tue, 10 Nov 2020, Cezar Sa Espinola wrote:

> A common operation for userspace applications managing ipvs is to dump all
> services and all destinations and then sort out what needs to be done.
> Previously this could only be accomplished by issuing 1 netlink
> IPVS_CMD_GET_SERVICE dump command followed by N IPVS_CMD_GET_DEST dump
> commands. For a dynamic system with a very large number of services this
> could be cause a performance impact.
> 
> This patch introduces a new way of dumping all services and destinations
> with the new IPVS_CMD_GET_SERVICE_DEST command. A dump call for this
> command will send the services as IPVS_CMD_NEW_SERVICE messages each
> containing a nested array of destinations with the new IPVS_SVC_ATTR_DESTS
> and IPVS_DESTS_ATTR_DEST attributes. Services may be repeated if their
> destinations do not fit in a single packet, user space should be
> responsible for merging the destinations from each repeated service.
> 
> It's also possible to dump a single service and its destinations by sending
> a IPVS_CMD_ATTR_SERVICE argument to the dump command.
> 
> Signed-off-by: Cezar Sa Espinola 

Thanks! Overall, I don't see problems with the logic
in the kernel patch and also in the ipvsadm patch. Below
you will see only comments about styling. In the above
patch description you can include some benchmark info
that specify speedup in what range was observed depending
on used services/dests, so that it can go to the commit log.

> ---
> Changes in v2:
> - Send destinations nested in a service.
> Changes in v3:
> - Avoid tab lookups at EOF and other requested changes.
> 
>  include/uapi/linux/ip_vs.h |  17 ++-
>  net/netfilter/ipvs/ip_vs_ctl.c | 200 ++---
>  2 files changed, 201 insertions(+), 16 deletions(-)
> 
> diff --git a/include/uapi/linux/ip_vs.h b/include/uapi/linux/ip_vs.h
> index 4102ddcb4e14..ce9bfa03b61b 100644
> --- a/include/uapi/linux/ip_vs.h
> +++ b/include/uapi/linux/ip_vs.h
> @@ -331,6 +331,8 @@ enum {
>   IPVS_CMD_ZERO,  /* zero all counters and stats */
>   IPVS_CMD_FLUSH, /* flush services and dests */
>  
> + IPVS_CMD_GET_SERVICE_DEST,  /* get service and destination info */
> +
>   __IPVS_CMD_MAX,
>  };
>  
> @@ -374,15 +376,28 @@ enum {
>  
>   IPVS_SVC_ATTR_STATS64,  /* nested attribute for service stats */
>  
> + IPVS_SVC_ATTR_DESTS,/* nested destinations */
> +
>   __IPVS_SVC_ATTR_MAX,
>  };
>  
>  #define IPVS_SVC_ATTR_MAX (__IPVS_SVC_ATTR_MAX - 1)
>  
> +enum {
> + IPVS_DESTS_ATTR_UNSPEC = 0,
> +
> + IPVS_DESTS_ATTR_DEST,   /* nested destination */
> +
> + __IPVS_DESTS_ATTR_MAX,
> +};
> +
> +#define IPVS_DESTS_ATTR_MAX (__IPVS_DESTS_ATTR_MAX - 1)
> +
>  /*
>   * Attributes used to describe a destination (real server)
>   *
> - * Used inside nested attribute IPVS_CMD_ATTR_DEST
> + * Used inside nested attribute IPVS_CMD_ATTR_DEST and
> + * IPVS_DESTS_ATTR_DEST
>   */
>  enum {
>   IPVS_DEST_ATTR_UNSPEC = 0,
> diff --git a/net/netfilter/ipvs/ip_vs_ctl.c b/net/netfilter/ipvs/ip_vs_ctl.c
> index e279ded4e306..65456eaaf11f 100644
> --- a/net/netfilter/ipvs/ip_vs_ctl.c
> +++ b/net/netfilter/ipvs/ip_vs_ctl.c
> @@ -2981,6 +2981,7 @@ static const struct nla_policy 
> ip_vs_svc_policy[IPVS_SVC_ATTR_MAX + 1] = {
>   [IPVS_SVC_ATTR_TIMEOUT] = { .type = NLA_U32 },
>   [IPVS_SVC_ATTR_NETMASK] = { .type = NLA_U32 },
>   [IPVS_SVC_ATTR_STATS]   = { .type = NLA_NESTED },
> + [IPVS_SVC_ATTR_DESTS]   = { .type = NLA_NESTED },
>  };
>  
>  /* Policy used for attributes in nested attribute IPVS_CMD_ATTR_DEST */
> @@ -3070,31 +3071,26 @@ static int ip_vs_genl_fill_stats64(struct sk_buff 
> *skb, int container_type,
>   return -EMSGSIZE;
>  }
>  
> -static int ip_vs_genl_fill_service(struct sk_buff *skb,
> -struct ip_vs_service *svc)
> +static int ip_vs_genl_put_service_attrs(struct sk_buff *skb,
> + struct ip_vs_service *svc)
>  {
>   struct ip_vs_scheduler *sched;
>   struct ip_vs_pe *pe;
> - struct nlattr *nl_service;
>   struct ip_vs_flags flags = { .flags = svc->flags,
>.mask = ~0 };
>   struct ip_vs_kstats kstats;
>   char *sched_name;
>  
> - nl_service = nla_nest_start_noflag(skb, IPVS_CMD_ATTR_SERVICE);
> - if (!nl_service)
> - return -EMSGSIZE;
> -
>   if (nla_put_u16(skb, IPVS_SVC_ATTR_AF, svc->af))
> - goto nla_put_failure;
> + return -EMSGSIZE;
>   if (svc->fwmark) {
>   if (nla_put_u32(skb, IPVS_SVC_ATTR_FWMARK, svc->fwmark))
> - goto nla_put_failure;
> + return -EMSGSIZE;
>   } else {
>   if (nla_put_u16(skb, IPVS_SVC_ATTR_PROTOCOL, svc->protocol) ||
>   nla_put(skb, IPVS_SVC_ATTR_ADDR,

Re: [PATCH] PCI: Add sysfs attribute for PCI device power state

2020-11-15 Thread Maximilian Luz


On 11/15/20 7:08 AM, Krzysztof Wilczyński wrote:

Hi Maximilian,

On 20-11-02 15:15:20, Maximilian Luz wrote:

While most PCI power-states can be queried from user-space via lspci,
this has some limits. Specifically, lspci fails to provide an accurate
value when the device is in D3cold as it has to resume the device before
it can access its power state via the configuration space, leading to it
reporting D0 or another on-state. Thus lspci can, for example, not be
used to diagnose power-consumption issues for devices that can enter
D3cold or to ensure that devices properly enter D3cold at all.

To alleviate this issue, introduce a new sysfs device attribute for the
PCI power state, showing the current power state as seen by the kernel.


Very nice!  Thank you for adding this.

[...]

+/* PCI power state */
+static ssize_t power_state_show(struct device *dev,
+   struct device_attribute *attr, char *buf)
+{
+   struct pci_dev *pci_dev = to_pci_dev(dev);
+   pci_power_t state = READ_ONCE(pci_dev->current_state);
+
+   return sprintf(buf, "%s\n", pci_power_name(state));
+}
+static DEVICE_ATTR_RO(power_state);

[...]

Curious, why did you decide to use the READ_ONCE() macro here?  Some
other drivers exposing data through sysfs use, but certainly not all.


As far as I can tell current_state is normally guarded by the device
lock, but here we don't hold that lock. I generally prefer to be
explicit about those kinds of access, if only to document that the value
can change here.

In this case it should work fine without it, but this also has the
benefit that if someone were to add a change like

  if (state > x)
  state = y;

later on (here or even in pci_power_name() due to inlining), things
wouldn't break as we explicitly forbid the compiler to load
current_state more than once. Without the READ_ONCE, the compiler would
be theoretically allowed to do two separate reads then (although
arguably unlikely it would end up doing that).

Also there's no downside of marking it as READ_ONCE here as far as I can
tell, as in that context the value will always have to be loaded from
memory.

So in short, mostly personal preference rooted in documentation and
avoiding potential (unlikely) future mishaps.

Regards,
Max

Re: [Fonts] 9522750c66: fio.read_iops 7.5% improvement

2020-11-15 Thread Feng Tang

On Sat, Nov 14, 2020 at 01:25:44PM +0100, Greg Kroah-Hartman wrote:
> On Sat, Nov 14, 2020 at 03:19:17PM +0800, Feng Tang wrote:
> > Hi Greg,
> > 
> > On Fri, Nov 13, 2020 at 07:46:57AM +0100, Greg Kroah-Hartman wrote:
> > > On Thu, Nov 12, 2020 at 10:06:25PM +0800, kernel test robot wrote:
> > > > 
> > > > Greeting,
> > > > 
> > > > FYI, we noticed a 7.5% improvement of fio.read_iops due to commit:
> > > > 
> > > > 
> > > > commit: 9522750c66c689b739e151fcdf895420dc81efc0 ("Fonts: Replace 
> > > > discarded const qualifier")
> > > > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git master
> > > 
> > > I strongly doubt this :)
> > 
> > We just double checked, the test was run 4 times and the result are
> > very stable.
> > 
> > The commit does looks irrelevant to fio test, and we just further
> > checked the System map of the 2 kernels, and many data's alignment
> > have been changed (systemmaps attached).
> > 
> > We have a hack debug patch to make data sections of each .o file to
> > be aligned, with that the fio result gap could be reduced from +7.5%
> > to +3.8%, so there is still some other factor affecting the benchmark,
> > which need more checking. And with the same debug method of forcing
> > data sections aligned, 2 other strange performance bumps[1][2] reported
> > by 0day could be recovered.
> > 
> > [1]. https://lore.kernel.org/lkml/20200205123216.GO12867@shao2-debian/
> > [2]. https://lore.kernel.org/lkml/20200305062138.GI5972@shao2-debian/
> 
> That's really odd.  Why wouldn't .o sections be aligned already and how
> does that affect the real .ko files that are created from that?  What
> alignment are you forcing?

Our debug patch is hacky which enforce 16K aligned (to adapt other rules
in the linker script to make kernel boot), as below:

diff --git a/arch/x86/kernel/vmlinux.lds.S b/arch/x86/kernel/vmlinux.lds.S
index 1bf7e31..de5ddc8 100644
--- a/arch/x86/kernel/vmlinux.lds.S
+++ b/arch/x86/kernel/vmlinux.lds.S
@@ -156,7 +156,9 @@ SECTIONS
X86_ALIGN_RODATA_END
 
/* Data */
-   .data : AT(ADDR(.data) - LOAD_OFFSET) {
+   .data : AT(ADDR(.data) - LOAD_OFFSET)
+   SUBALIGN(16384)
+   {
/* Start of data section */
_sdata = .;

And to make it boot, for our kernel config, we have to disable
CONFIG_DYNAMIC_DEBUG to avoid kernel panic.

> And also, what hardware is seeing this performance gains?  Something is
> fitting into a cache now that previously wasn't, and tracking that down
> seems like it would be very worthwhile as that is a non-trivial speedup
> that some developers take years to achieve with code changes.

It's a x86 server with 2S/48C/96T, and the fio parameters are:

[global]
bs=2M
ioengine=mmap
iodepth=32
size=4473924266
nr_files=1
filesize=4473924266
direct=0
runtime=240
invalidate=1
fallocate=posix
io_size=4473924266
file_service_type=roundrobin
random_distribution=random
group_reporting
pre_read=0

time_based

[task_0]
rw=read
directory=/fs/pmem0
numjobs=24

[task_1]
rw=read
directory=/fs/pmem1
numjobs=24

And yes, we also think it's cacheline related, and we are further   
checking it. Actually we have 2 other similar strange performance
change checking ongoing:

https://lore.kernel.org/lkml/20201102091543.GM31092@shao2-debian/
https://lore.kernel.org/lkml/20201004132838.GU393@shao2-debian/

So it may take some time. And to be frank, there have been quite
some old similar cases that we couldn't figure out the exact cause.

Thanks,
Feng

> thanks,
> 
> greg k-h

[PATCH v3 4/4] ASoC: pcm512x: Add support for more data formats

Currently, pcm512x driver supports only I2S data format.
This commit adds RJ, LJ, DSP_A and DSP_B as well.

I don't expect regression WRT existing sound cards, because:

* default value in corresponding register of pcm512x codec is 0 ==  I2S
* existing in-tree sound cards with pcm512x codec are configured for I2S
* i don't see how existing off-tree sound cards with pcm512x codec could be
  configured differently - it would not work
* tested explicitly, that there is no regression with Raspberry Pi +
  sound card `sound/soc/bcm/hifiberry_dacplus.c`

Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Takashi Iwai 
Cc: Liam Girdwood 
Cc: Matthias Reichl 
Cc: Kuninori Morimoto 
Cc: Peter Ujfalusi 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/codecs/pcm512x.c | 38 ++
 1 file changed, 38 insertions(+)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index 22ef77955a28..4dc844f3c1fc 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -1335,6 +1335,8 @@ static int pcm512x_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
 {
struct snd_soc_component *component = dai->component;
struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
+   int afmt;
+   int offset = 0;
int clock_output;
int master_mode;
int ret;
@@ -1372,6 +1374,42 @@ static int pcm512x_set_fmt(struct snd_soc_dai *dai, 
unsigned int fmt)
return ret;
}
 
+   switch (fmt & SND_SOC_DAIFMT_FORMAT_MASK) {
+   case SND_SOC_DAIFMT_I2S:
+   afmt = PCM512x_AFMT_I2S;
+   break;
+   case SND_SOC_DAIFMT_RIGHT_J:
+   afmt = PCM512x_AFMT_RTJ;
+   break;
+   case SND_SOC_DAIFMT_LEFT_J:
+   afmt = PCM512x_AFMT_LTJ;
+   break;
+   case SND_SOC_DAIFMT_DSP_A:
+   offset = 1;
+   fallthrough;
+   case SND_SOC_DAIFMT_DSP_B:
+   afmt = PCM512x_AFMT_DSP;
+   break;
+   default:
+   dev_err(component->dev, "unsupported DAI format: 0x%x\n",
+   pcm512x->fmt);
+   return -EINVAL;
+   }
+
+   ret = regmap_update_bits(pcm512x->regmap, PCM512x_I2S_1,
+PCM512x_AFMT, afmt);
+   if (ret != 0) {
+   dev_err(component->dev, "Failed to set data format: %d\n", ret);
+   return ret;
+   }
+
+   ret = regmap_update_bits(pcm512x->regmap, PCM512x_I2S_2,
+0xFF, offset);
+   if (ret != 0) {
+   dev_err(component->dev, "Failed to set data offset: %d\n", ret);
+   return ret;
+   }
+
pcm512x->fmt = fmt;
 
return 0;
-- 
2.13.6

[PATCH v3 0/4] ASoC: pcm512x: Patch series to set fmt from `set_fmt()`

Set format from `set_fmt()` func instead of `hw_params()`, plus supportive
commits

Kirill Marinushkin (4):
  ASoC: pcm512x: Fix not setting word length if DAIFMT_CBS_CFS
  ASoC: pcm512x: Rearrange operations in `hw_params()`
  ASoC: pcm512x: Move format check into `set_fmt()`
  ASoC: pcm512x: Add support for more data formats

 sound/soc/codecs/pcm512x.c | 134 -
 1 file changed, 84 insertions(+), 50 deletions(-)

-- 
2.13.6

[PATCH v3 1/4] ASoC: pcm512x: Fix not setting word length if DAIFMT_CBS_CFS

In `pcm512x_hw_params()`, the following switch-case:


switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:


returns 0, which was preventing word length from being written into codecs
register.

Fixed by writing it into register before checking
`SND_SOC_DAIFMT_MASTER_MASK`.
Tested with Raspberry Pi + sound card `hifiberry_dacplus` in CBS_CFS format

Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Takashi Iwai 
Cc: Liam Girdwood 
Cc: Matthias Reichl 
Cc: Kuninori Morimoto 
Cc: Peter Ujfalusi 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/codecs/pcm512x.c | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index 8153d3d01654..db3dc6a40feb 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -1195,6 +1195,13 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return -EINVAL;
}
 
+   ret = regmap_update_bits(pcm512x->regmap, PCM512x_I2S_1,
+PCM512x_ALEN, alen);
+   if (ret != 0) {
+   dev_err(component->dev, "Failed to set frame size: %d\n", ret);
+   return ret;
+   }
+
switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
ret = regmap_update_bits(pcm512x->regmap,
@@ -1229,13 +1236,6 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return -EINVAL;
}
 
-   ret = regmap_update_bits(pcm512x->regmap, PCM512x_I2S_1,
-PCM512x_ALEN, alen);
-   if (ret != 0) {
-   dev_err(component->dev, "Failed to set frame size: %d\n", ret);
-   return ret;
-   }
-
if (pcm512x->pll_out) {
ret = regmap_write(pcm512x->regmap, PCM512x_FLEX_A, 0x11);
if (ret != 0) {
-- 
2.13.6

Re: [PATCH v2 1/1] page_frag: Recover from memory pressure

2020-11-15 Thread Matthew Wilcox

On Sat, Nov 14, 2020 at 10:51:06PM -0800, Dongli Zhang wrote:
> + if (nc->pfmemalloc) {

You missed the unlikely() change that Eric recommended.

[PATCH v3 3/4] ASoC: pcm512x: Move format check into `set_fmt()`

I would like to describe the reasoning by quoting Peter Ujfalusi
 from his review of this patch series v1 [1]:

> When you bind a link you will use set_fmt for the two sides to see if
> they can agree, that both can support what has been asked.
>
> The pcm512x driver just saves the fmt and say back to that card:
> whatever, I'm fine with it. But runtime during hw_params it can fail due
> to unsupported bus format, which it actually acked to be ok.
>
> This is the difference.
>
> Sure, some device have constraint based on the fmt towards the hw_params
> and it is perfectly OK to do such a checks and rejections or build
> rules/constraints based on fmt, but failing hw_params just because
> set_fmt did not checked that the bus format is not even supported is not
> a nice thing to do.

[1] https://patchwork.kernel.org/project/alsa-devel/patch/
20201109212133.25869-1-kmarinush...@birdec.com/

Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Takashi Iwai 
Cc: Liam Girdwood 
Cc: Matthias Reichl 
Cc: Kuninori Morimoto 
Cc: Peter Ujfalusi 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/codecs/pcm512x.c | 55 +-
 1 file changed, 30 insertions(+), 25 deletions(-)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index aa55a477a28f..22ef77955a28 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -1168,8 +1168,6 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
int alen;
int gpio;
-   int clock_output;
-   int master_mode;
int ret;
 
dev_dbg(component->dev, "hw_params %u Hz, %u channels\n",
@@ -1202,11 +1200,8 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return ret;
}
 
-   switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
-   case SND_SOC_DAIFMT_CBS_CFS:
-   clock_output = 0;
-   master_mode = 0;
-
+   if ((pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) ==
+   SND_SOC_DAIFMT_CBS_CFS) {
ret = regmap_update_bits(pcm512x->regmap, PCM512x_ERROR_DETECT,
 PCM512x_DCAS, 0);
if (ret != 0) {
@@ -1216,16 +1211,6 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return ret;
}
goto skip_pll;
-   case SND_SOC_DAIFMT_CBM_CFM:
-   clock_output = PCM512x_BCKO | PCM512x_LRKO;
-   master_mode = PCM512x_RLRK | PCM512x_RBCK;
-   break;
-   case SND_SOC_DAIFMT_CBM_CFS:
-   clock_output = PCM512x_BCKO;
-   master_mode = PCM512x_RBCK;
-   break;
-   default:
-   return -EINVAL;
}
 
if (pcm512x->pll_out) {
@@ -1343,6 +1328,34 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
}
 
 skip_pll:
+   return 0;
+}
+
+static int pcm512x_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
+{
+   struct snd_soc_component *component = dai->component;
+   struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
+   int clock_output;
+   int master_mode;
+   int ret;
+
+   switch (fmt & SND_SOC_DAIFMT_MASTER_MASK) {
+   case SND_SOC_DAIFMT_CBS_CFS:
+   clock_output = 0;
+   master_mode = 0;
+   break;
+   case SND_SOC_DAIFMT_CBM_CFM:
+   clock_output = PCM512x_BCKO | PCM512x_LRKO;
+   master_mode = PCM512x_RLRK | PCM512x_RBCK;
+   break;
+   case SND_SOC_DAIFMT_CBM_CFS:
+   clock_output = PCM512x_BCKO;
+   master_mode = PCM512x_RBCK;
+   break;
+   default:
+   return -EINVAL;
+   }
+
ret = regmap_update_bits(pcm512x->regmap, PCM512x_BCLK_LRCLK_CFG,
 PCM512x_BCKP | PCM512x_BCKO | PCM512x_LRKO,
 clock_output);
@@ -1359,14 +1372,6 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return ret;
}
 
-   return 0;
-}
-
-static int pcm512x_set_fmt(struct snd_soc_dai *dai, unsigned int fmt)
-{
-   struct snd_soc_component *component = dai->component;
-   struct pcm512x_priv *pcm512x = snd_soc_component_get_drvdata(component);
-
pcm512x->fmt = fmt;
 
return 0;
-- 
2.13.6

Re: [PATCH v7 1/2] kunit: Support for Parameterized Testing

2020-11-15 Thread Arpitha Raghunandan

On 15/11/20 2:28 pm, Marco Elver wrote:
> On Sat, 14 Nov 2020 at 13:38, Arpitha Raghunandan <98.a...@gmail.com> wrote:
>> Implementation of support for parameterized testing in KUnit. This
>> approach requires the creation of a test case using the
>> KUNIT_CASE_PARAM() macro that accepts a generator function as input.
>>
>> This generator function should return the next parameter given the
>> previous parameter in parameterized tests. It also provides a macro to
>> generate common-case generators based on arrays. Generators may also
>> optionally provide a human-readable description of parameters, which is
>> displayed where available.
>>
>> Note, currently the result of each parameter run is displayed in
>> diagnostic lines, and only the overall test case output summarizes
>> TAP-compliant success or failure of all parameter runs. In future, when
>> supported by kunit-tool, these can be turned into subsubtest outputs.
>>
>> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
>> Co-developed-by: Marco Elver 
>> Signed-off-by: Marco Elver 
>> ---
>> Changes v6->v7:
>> - Clarify commit message.
>> - Introduce ability to optionally generate descriptions for parameters;
>>   if no description is provided, we'll still print 'param-N'.
>> - Change diagnostic line format to:
>> # :  N - []
>>
>> Changes v5->v6:
>> - Fix alignment to maintain consistency
>>
>> Changes v4->v5:
>> - Update kernel-doc comments.
>> - Use const void* for generator return and prev value types.
>> - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
>> - Rework parameterized test case execution strategy: each parameter is 
>> executed
>>   as if it was its own test case, with its own test initialization and 
>> cleanup
>>   (init and exit are called, etc.). However, we cannot add new test cases 
>> per TAP
>>   protocol once we have already started execution. Instead, log the result of
>>   each parameter run as a diagnostic comment.
>>
>> Changes v3->v4:
>> - Rename kunit variables
>> - Rename generator function helper macro
>> - Add documentation for generator approach
>> - Display test case name in case of failure along with param index
>>
>> Changes v2->v3:
>> - Modifictaion of generator macro and method
>>
>> Changes v1->v2:
>> - Use of a generator method to access test case parameters
>> Changes v6->v7:
>> - Clarify commit message.
>> - Introduce ability to optionally generate descriptions for parameters;
>>   if no description is provided, we'll still print 'param-N'.
>> - Change diagnostic line format to:
>> # :  N - []
>> - Before execution of parameterized test case, count number of
>>   parameters and display number of parameters. Currently also as a
>>   diagnostic line, but this may be used in future to generate a subsubtest
>>   plan. A requirement of this change is that generators must generate a
>>   deterministic number of parameters.
>>
>> Changes v5->v6:
>> - Fix alignment to maintain consistency
>>
>> Changes v4->v5:
>> - Update kernel-doc comments.
>> - Use const void* for generator return and prev value types.
>> - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
>> - Rework parameterized test case execution strategy: each parameter is 
>> executed
>>   as if it was its own test case, with its own test initialization and 
>> cleanup
>>   (init and exit are called, etc.). However, we cannot add new test cases 
>> per TAP
>>   protocol once we have already started execution. Instead, log the result of
>>   each parameter run as a diagnostic comment.
>>
>> Changes v3->v4:
>> - Rename kunit variables
>> - Rename generator function helper macro
>> - Add documentation for generator approach
>> - Display test case name in case of failure along with param index
>>
>> Changes v2->v3:
>> - Modifictaion of generator macro and method
>>
>> Changes v1->v2:
>> - Use of a generator method to access test case parameters
>>
>>  include/kunit/test.h | 51 ++
>>  lib/kunit/test.c | 59 ++--
>>  2 files changed, 97 insertions(+), 13 deletions(-)
>>
>> diff --git a/include/kunit/test.h b/include/kunit/test.h
>> index db1b0ae666c4..cf5f33b1c890 100644
>> --- a/include/kunit/test.h
>> +++ b/include/kunit/test.h
>> @@ -94,6 +94,9 @@ struct kunit;
>>  /* Size of log associated with test. */
>>  #define KUNIT_LOG_SIZE 512
>>
>> +/* Maximum size of parameter description string. */
>> +#define KUNIT_PARAM_DESC_SIZE 64
> 
> I think we need to make this larger, perhaps 128. I just noticed a few
> of the inode-test strings are >64 chars (and it should probably also
> use strncpy() to copy to description, which is my bad).
>

Okay, I will make the description size larger and use strncpy().
 
>>  /*
>>   * TAP specifies subtest stream indentation of 4 spaces, 8 spaces for a
>>   * sub-subtest.  See the "Subtests" section in
>> @@ -107,6 +110,7 @@ struct kunit;
> [...]
>> +/**
>> + * KUNIT_ARRAY_PARAM() - Define test parameter generator from an array.
>> + *

[PATCH v3 2/4] ASoC: pcm512x: Rearrange operations in `hw_params()`

This commit is a preparation for the next patch in the series.
It's goal is to make format check easy-to-move-out. Theoretically, more
butifications are possile in `hw_params()` func, but my intention in this
commit is to keep behaviour unchanged.

Signed-off-by: Kirill Marinushkin 
Cc: Mark Brown 
Cc: Takashi Iwai 
Cc: Liam Girdwood 
Cc: Matthias Reichl 
Cc: Kuninori Morimoto 
Cc: Peter Ujfalusi 
Cc: alsa-de...@alsa-project.org
Cc: linux-kernel@vger.kernel.org
---
 sound/soc/codecs/pcm512x.c | 49 +++---
 1 file changed, 20 insertions(+), 29 deletions(-)

diff --git a/sound/soc/codecs/pcm512x.c b/sound/soc/codecs/pcm512x.c
index db3dc6a40feb..aa55a477a28f 100644
--- a/sound/soc/codecs/pcm512x.c
+++ b/sound/soc/codecs/pcm512x.c
@@ -1204,16 +1204,8 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
 
switch (pcm512x->fmt & SND_SOC_DAIFMT_MASTER_MASK) {
case SND_SOC_DAIFMT_CBS_CFS:
-   ret = regmap_update_bits(pcm512x->regmap,
-PCM512x_BCLK_LRCLK_CFG,
-PCM512x_BCKP
-| PCM512x_BCKO | PCM512x_LRKO,
-0);
-   if (ret != 0) {
-   dev_err(component->dev,
-   "Failed to enable slave mode: %d\n", ret);
-   return ret;
-   }
+   clock_output = 0;
+   master_mode = 0;
 
ret = regmap_update_bits(pcm512x->regmap, PCM512x_ERROR_DETECT,
 PCM512x_DCAS, 0);
@@ -1223,7 +1215,7 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
ret);
return ret;
}
-   return 0;
+   goto skip_pll;
case SND_SOC_DAIFMT_CBM_CFM:
clock_output = PCM512x_BCKO | PCM512x_LRKO;
master_mode = PCM512x_RLRK | PCM512x_RBCK;
@@ -1316,25 +1308,7 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
dev_err(component->dev, "Failed to enable pll: %d\n", 
ret);
return ret;
}
-   }
-
-   ret = regmap_update_bits(pcm512x->regmap, PCM512x_BCLK_LRCLK_CFG,
-PCM512x_BCKP | PCM512x_BCKO | PCM512x_LRKO,
-clock_output);
-   if (ret != 0) {
-   dev_err(component->dev, "Failed to enable clock output: %d\n", 
ret);
-   return ret;
-   }
 
-   ret = regmap_update_bits(pcm512x->regmap, PCM512x_MASTER_MODE,
-PCM512x_RLRK | PCM512x_RBCK,
-master_mode);
-   if (ret != 0) {
-   dev_err(component->dev, "Failed to enable master mode: %d\n", 
ret);
-   return ret;
-   }
-
-   if (pcm512x->pll_out) {
gpio = PCM512x_G1OE << (pcm512x->pll_out - 1);
ret = regmap_update_bits(pcm512x->regmap, PCM512x_GPIO_EN,
 gpio, gpio);
@@ -1368,6 +1342,23 @@ static int pcm512x_hw_params(struct snd_pcm_substream 
*substream,
return ret;
}
 
+skip_pll:
+   ret = regmap_update_bits(pcm512x->regmap, PCM512x_BCLK_LRCLK_CFG,
+PCM512x_BCKP | PCM512x_BCKO | PCM512x_LRKO,
+clock_output);
+   if (ret != 0) {
+   dev_err(component->dev, "Failed to enable clock output: %d\n", 
ret);
+   return ret;
+   }
+
+   ret = regmap_update_bits(pcm512x->regmap, PCM512x_MASTER_MODE,
+PCM512x_RLRK | PCM512x_RBCK,
+master_mode);
+   if (ret != 0) {
+   dev_err(component->dev, "Failed to enable master mode: %d\n", 
ret);
+   return ret;
+   }
+
return 0;
 }
 
-- 
2.13.6

Re: [PATCH] phy: phylink: Fix CuSFP issue in phylink

2020-11-15 Thread Russell King - ARM Linux admin

On Wed, Nov 11, 2020 at 09:52:18AM +0100, Bjarni Jonasson wrote:
> 
> Russell King - ARM Linux admin writes:
> 
> > On Tue, Nov 10, 2020 at 03:16:34PM +0100, Bjarni Jonasson wrote:
> >>
> >> Russell King - ARM Linux admin writes:
> >>
> >> > On Tue, Nov 10, 2020 at 11:06:42AM +0100, Bjarni Jonasson wrote:
> >> >> There is an issue with the current phylink driver and CuSFPs which
> >> >> results in a callback to the phylink validate function without any
> >> >> advertisement capabilities.  The workaround (in this changeset)
> >> >> is to assign capabilities if a 1000baseT SFP is identified.
> >> >
> >> > How does this happen?  Which PHY is being used?
> >>
> >> This occurs just by plugging in the CuSFP.
> >> None of the CuSFPs we have tested are working.
> >> This is a dump from 3 different CuSFPs, phy regs 0-3:
> >> FS SFP: 01:40:79:49
> >> HP SFP: 01:40:01:49
> >> Marvel SFP: 01:40:01:49
> >> This was working before the delayed mac config was implemented (in dec
> >> 2019).
> >
> > You're dumping PHY registers 0 and 1 there, not 0 through 3, which
> > the values confirm. I don't recognise the format either. PHY registers
> > are always 16-bit.
> Sorry about that. Here is it again:
> Marvell SFP : 0x0140 0x0149 0x0141 0x0cc1
> FS SFP  : 0x1140 0x7949 0x0141 0x0cc2
> Cisco SFP   : 0x0140 0x0149 0x0141 0x0cc1
> I.e. its seems to be a Marvell phy (0x0141) in all cases.
> And this occurs when phylink_start() is called.

So they're all 88E devices, which is the most common PHY for
CuSFPs.

Do you have the Marvell PHY driver either built-in or available as a
module? I suspect the problem is you don't. You will need the Marvell
PHY driver to correctly drive the PHY, you can't rely on the fallback
driver for SFPs.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps down 10Mbps up. Decent connectivity at last!

[PATCH rdma-next 0/2] Enable querying AH for XRC QP types

2020-11-15 Thread Leon Romanovsky

From: Leon Romanovsky 

Update mlx4 and mlx5 drivers to support querying AH for XRC QP types.

Thanks

Avihai Horon (2):
  RDMA/mlx5: Enable querying AH for XRC QP types
  RDMA/mlx4: Enable querying AH for XRC QP types

 drivers/infiniband/hw/mlx4/qp.c | 4 +++-
 drivers/infiniband/hw/mlx5/qp.c | 4 +++-
 2 files changed, 6 insertions(+), 2 deletions(-)

--
2.28.0

[PATCH] staging: rtl8188eu: clean up the useless code

2020-11-15 Thread xiakaixu1987

From: Kaixu Xia 

The two bool variables singletone and carrier_sup are always false
and the following if statement can't be true, these code are useless,
so remove them.

Reported-by: Tosk Robot 
Signed-off-by: Kaixu Xia 
---
 drivers/staging/rtl8188eu/hal/phy.c | 7 ---
 1 file changed, 7 deletions(-)

diff --git a/drivers/staging/rtl8188eu/hal/phy.c 
b/drivers/staging/rtl8188eu/hal/phy.c
index a970189ba8c6..a664bff370bb 100644
--- a/drivers/staging/rtl8188eu/hal/phy.c
+++ b/drivers/staging/rtl8188eu/hal/phy.c
@@ -1200,7 +1200,6 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, bool 
recovery)
bool pathaok, pathbok;
s32 reg_e94, reg_e9c, reg_ea4, reg_eb4, reg_ebc, reg_ec4;
bool is12simular, is13simular, is23simular;
-   bool singletone = false, carrier_sup = false;
u32 iqk_bb_reg_92c[IQK_BB_REG_NUM] = {
rOFDM0_XARxIQImbalance, rOFDM0_XBRxIQImbalance,
rOFDM0_ECCAThreshold, rOFDM0_AGCRSSITable,
@@ -1214,9 +1213,6 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, bool 
recovery)
if (!(dm_odm->SupportAbility & ODM_RF_CALIBRATION))
return;
 
-   if (singletone || carrier_sup)
-   return;
-
if (recovery) {
ODM_RT_TRACE(dm_odm, ODM_COMP_INIT, ODM_DBG_LOUD,
 ("phy_iq_calibrate: Return due to recovery!\n"));
@@ -1312,14 +1308,11 @@ void rtl88eu_phy_iq_calibrate(struct adapter *adapt, 
bool recovery)
 
 void rtl88eu_phy_lc_calibrate(struct adapter *adapt)
 {
-   bool singletone = false, carrier_sup = false;
u32 timeout = 2000, timecount = 0;
struct odm_dm_struct *dm_odm = >HalData->odmpriv;
 
if (!(dm_odm->SupportAbility & ODM_RF_CALIBRATION))
return;
-   if (singletone || carrier_sup)
-   return;
 
while (*dm_odm->pbScanInProcess && timecount < timeout) {
mdelay(50);
-- 
2.20.0

Re: PCI: Race condition in pci_create_sysfs_dev_files

2020-11-15 Thread Pali Rohár

On Sunday 15 November 2020 07:19:36 Krzysztof Wilczyński wrote:
> Hello Pali!
> 
> Sincere apologies for taking a long time to get back to you.
> 
> On 20-11-04 17:29:31, Pali Rohár wrote:
> 
> [...]
> > 
> > Krzysztof, as Bjorn wrote, do you want to take this issue?
> > 
> [...]
> 
> Yes.  I already talked to Bjorn about this briefly, and thus I am more
> than happy to take care about this.  Most definitely.
> 
> Krzysztof

Hello Krzysztof!

Thank you very much. I have there some patches for pci aardvard driver
which decrease boot time but trigger this race condition more often. So
they are not suitable for upstreaming yet.

Once you you have a fix for it, let me know and I could test it with my
aardvark patches.

Re: [PATCH] sched/core: Add missing completion for affine_move_task() waiters

2020-11-15 Thread Tao Zhou

Hi,

On Fri, Nov 13, 2020 at 11:24:14AM +, Valentin Schneider wrote:

> Qian reported that some fuzzer issuing sched_setaffinity() ends up stuck on
> a wait_for_completion(). The problematic pattern seems to be:
>   affine_move_task()
>   // task_running() case
>   stop_one_cpu();
>   wait_for_completion(>done);
> 
> Combined with, on the stopper side:
> 
>   migration_cpu_stop()
> // Task moved between unlocks and scheduling the stopper
> task_rq(p) != rq &&
> // task_running() case
> dest_cpu >= 0
> 
> => no complete_all()
> 
> This can happen with both PREEMPT and !PREEMPT, although !PREEMPT should
> be more likely to see this given the targeted task has a much bigger window
> to block and be woken up elsewhere before the stopper runs.
> 
> Make migration_cpu_stop() always look at pending affinity requests; signal
> their completion if the stopper hits a rq mismatch but the task is
> still within its allowed mask. When Migrate-Disable isn't involved, this
> matches the previous set_cpus_allowed_ptr() vs migration_cpu_stop()
> behaviour.
> 
> Link: 
> https://lore.kernel.org/lkml/8b62fd1ad1b18def27f18e2ee2df3ff5b36d0762.ca...@redhat.com
> Fixes: 6d337eab041d ("sched: Fix migrate_disable() vs set_cpus_allowed_ptr()")
> Reported-by: Qian Cai 
> Signed-off-by: Valentin Schneider 
> ---
>  kernel/sched/core.c | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/kernel/sched/core.c b/kernel/sched/core.c
> index 02076e6d3792..fad0a8e62aca 100644
> --- a/kernel/sched/core.c
> +++ b/kernel/sched/core.c
> @@ -1923,7 +1923,7 @@ static int migration_cpu_stop(void *data)
>   else
>   p->wake_cpu = dest_cpu;
>  
> - } else if (dest_cpu < 0) {
> + } else if (dest_cpu < 0 || pending) {
>   /*
>* This happens when we get migrated between migrate_enable()'s
>* preempt_enable() and scheduling the stopper task. At that
> @@ -1933,6 +1933,17 @@ static int migration_cpu_stop(void *data)
>* more likely.
>*/
>  
> + /*
> +  * The task moved before the stopper got to run. We're holding
> +  * ->pi_lock, so the allowed mask is stable - if it got
> +  * somewhere allowed, we're done.
> +  */
> + if (pending && cpumask_test_cpu(task_cpu(p), p->cpus_ptr)) {
> + p->migration_pending = NULL;
> + complete = true;
> + goto out;
> + }
> +
>   /*
>* When this was migrate_enable() but we no longer have an
>* @pending, a concurrent SCA 'fixed' things and we should be
> -- 
> 2.27.0

Oh, I did not receive this patch from 'ouwen...@hotmail.com'
account. Checked that you sent the patch to that mail address
from web. If 'ouwen210' is not a good mail account name(I have
used this name since 2002), I will change to use this one(Now
is smooth enough and can go to lkml).

Thanks,
Tao

Re: [PATCH] perf test: Fix dwarf unwind for optimized builds.

2020-11-15 Thread Miguel Ojeda

On Sat, Nov 14, 2020 at 9:14 PM Ian Rogers  wrote:
>
> Unfortunately no GCC version actually has this fixed.

Then we can say GCC <= 11 does not support it yet or something like that.

> This seems overly complex and unnecessary.

How is 1 condition more complex than 3 different ones?

Cheers,
Miguel

j721e-evm.c:undefined reference to `clk_set_parent'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   e28c0d7c92c89016c12a677616668957351e7542
commit: 6748d05590594837e42dfa975879fb275099f0b2 ASoC: ti: Add custom machine 
driver for j721e EVM (CPB and IVI)
date:   5 months ago
config: mips-randconfig-c003-20201104 (attached as .config)
compiler: mipsel-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
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=6748d05590594837e42dfa975879fb275099f0b2
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout 6748d05590594837e42dfa975879fb275099f0b2
# 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 errors (new ones prefixed by >>):

   mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_mixer.o: in function 
`mixer_bind':
   exynos_mixer.c:(.text+0x988): undefined reference to `clk_set_parent'
   mipsel-linux-ld: drivers/gpu/drm/exynos/exynos_hdmi.o: in function 
`hdmi_clk_set_parents':
   exynos_hdmi.c:(.text+0x2d0): undefined reference to `clk_set_parent'
   mipsel-linux-ld: drivers/gpu/drm/ingenic/ingenic-drm.o: in function 
`ingenic_drm_probe':
   ingenic-drm.c:(.text+0xe8c): undefined reference to `clk_get_parent'
   mipsel-linux-ld: drivers/usb/phy/phy-tegra-usb.o: in function 
`tegra_usb_phy_init':
   phy-tegra-usb.c:(.text+0x1dd4): undefined reference to `clk_get_parent'
   mipsel-linux-ld: sound/soc/meson/aiu-encoder-spdif.o: in function 
`aiu_encoder_spdif_startup':
   aiu-encoder-spdif.c:(.text+0x3a0): undefined reference to `clk_set_parent'
   mipsel-linux-ld: sound/soc/meson/axg-tdm-formatter.o: in function 
`axg_tdm_formatter_event':
   (.text+0x7ec): undefined reference to `clk_set_parent'
   mipsel-linux-ld: (.text+0x940): undefined reference to `clk_set_parent'
   mipsel-linux-ld: sound/soc/sh/fsi.o: in function `fsi_clk_set_rate_external':
   fsi.c:(.text+0x26f0): undefined reference to `clk_set_parent'
   mipsel-linux-ld: sound/soc/stm/stm32_i2s.o: in function 
`stm32_i2s_hw_params':
   stm32_i2s.c:(.text+0x1870): undefined reference to `clk_set_parent'
   mipsel-linux-ld: sound/soc/stm/stm32_i2s.o:stm32_i2s.c:(.text+0x19dc): more 
undefined references to `clk_set_parent' follow
   mipsel-linux-ld: sound/soc/ti/omap-dmic.o: in function 
`omap_dmic_set_dai_sysclk':
   omap-dmic.c:(.text+0xa5c): undefined reference to `clk_get_parent'
   mipsel-linux-ld: omap-dmic.c:(.text+0xaa0): undefined reference to 
`clk_set_parent'
   mipsel-linux-ld: omap-dmic.c:(.text+0xb7c): undefined reference to 
`clk_set_parent'
   mipsel-linux-ld: sound/soc/ti/omap-mcbsp.o: in function 
`omap2_mcbsp_set_clks_src':
   omap-mcbsp.c:(.text+0x650): undefined reference to `clk_set_parent'
   mipsel-linux-ld: sound/soc/ti/j721e-evm.o: in function 
`j721e_configure_refclk':
>> j721e-evm.c:(.text+0x27c): undefined reference to `clk_set_parent'
>> mipsel-linux-ld: j721e-evm.c:(.text+0x298): undefined reference to 
>> `clk_set_parent'
   mipsel-linux-ld: sound/soc/ti/j721e-evm.o: in function `j721e_soc_probe':
>> j721e-evm.c:(.text+0x2030): undefined reference to `clk_get_parent'
>> mipsel-linux-ld: j721e-evm.c:(.text+0x2078): undefined reference to 
>> `clk_get_parent'

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


.config.gz
Description: application/gzip

[PATCH] remoteproc: Add module parameter 'auto_boot'

2020-11-15 Thread Paul Cercueil

Until now the remoteproc core would always default to trying to boot the
remote processor at startup. The various remoteproc drivers could
however override that setting.

Whether or not we want the remote processor to boot, really depends on
the nature of the processor itself - a processor built into a WiFi chip
will need to be booted for the WiFi hardware to be usable, for instance,
but a general-purpose co-processor does not have any predeterminated
function, and as such we cannot assume that the OS will want the
processor to be booted - yet alone that we have a single do-it-all
firmware to load.

Add a 'auto_boot' module parameter that instructs the remoteproc whether
or not it should auto-boot the remote processor, which will default to
"true" to respect the previous behaviour.

Signed-off-by: Paul Cercueil 
---
 drivers/remoteproc/remoteproc_core.c | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/drivers/remoteproc/remoteproc_core.c 
b/drivers/remoteproc/remoteproc_core.c
index dab2c0f5caf0..687b1bfd49db 100644
--- a/drivers/remoteproc/remoteproc_core.c
+++ b/drivers/remoteproc/remoteproc_core.c
@@ -44,6 +44,11 @@
 
 #define HIGH_BITS_MASK 0xULL
 
+static bool auto_boot = true;
+module_param(auto_boot, bool, 0400);
+MODULE_PARM_DESC(auto_boot,
+"Auto-boot the remote processor [default=true]");
+
 static DEFINE_MUTEX(rproc_list_mutex);
 static LIST_HEAD(rproc_list);
 static struct notifier_block rproc_panic_nb;
@@ -2176,7 +2181,7 @@ struct rproc *rproc_alloc(struct device *dev, const char 
*name,
return NULL;
 
rproc->priv = [1];
-   rproc->auto_boot = true;
+   rproc->auto_boot = auto_boot;
rproc->elf_class = ELFCLASSNONE;
rproc->elf_machine = EM_NONE;
 
-- 
2.29.2

Re: [Linux-kernel-mentees] [PATCH v4 net] rose: Fix Null pointer dereference in rose_send_frame()

2020-11-15 Thread Anmol Karn

On Sat, Nov 14, 2020 at 11:18:38AM -0800, Jakub Kicinski wrote:
> On Wed, 11 Nov 2020 22:29:54 +0530 Anmol Karn wrote:
> > rose_send_frame() dereferences `neigh->dev` when called from
> > rose_transmit_clear_request(), and the first occurrence of the
> > `neigh` is in rose_loopback_timer() as `rose_loopback_neigh`,
> > and it is initialized in rose_add_loopback_neigh() as NULL.
> > i.e when `rose_loopback_neigh` used in rose_loopback_timer()
> > its `->dev` was still NULL and rose_loopback_timer() was calling
> > rose_rx_call_request() without checking for NULL.
> > 
> > - net/rose/rose_link.c
> > This bug seems to get triggered in this line:
> > 
> > rose_call = (ax25_address *)neigh->dev->dev_addr;
> > 
> > Fix it by adding NULL checking for `rose_loopback_neigh->dev`
> > in rose_loopback_timer().
> > 
> > Fixes: 1da177e4c3f4 ("Linux-2.6.12-rc2")
> > Reported-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> > Tested-by: syzbot+a1c743815982d9496...@syzkaller.appspotmail.com
> > Link: 
> > https://syzkaller.appspot.com/bug?id=9d2a7ca8c7f2e4b682c97578dfa3f236258300b3
> > Signed-off-by: Anmol Karn 
> 
> > diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> > index 7b094275ea8b..6a71b6947d92 100644
> > --- a/net/rose/rose_loopback.c
> > +++ b/net/rose/rose_loopback.c
> > @@ -96,10 +96,12 @@ static void rose_loopback_timer(struct timer_list 
> > *unused)
> > }
> > 
> > if (frametype == ROSE_CALL_REQUEST) {
> > -   if ((dev = rose_dev_get(dest)) != NULL) {
> > +   dev = rose_dev_get(dest);
> > +   if (rose_loopback_neigh->dev && dev) {
> > if (rose_rx_call_request(skb, dev, 
> > rose_loopback_neigh, lci_o) == 0)
> > kfree_skb(skb);
> > } else {
> > +   dev_put(dev);
> > kfree_skb(skb);
> > }
> > } else {
> 
> This is still not correct. With this code dev_put() could be called with
> NULL, which would cause a crash.
> 
> There is also a dev_put() missing if rose_rx_call_request() returns 0.
> 
> I think that this is the correct code:
> 
> diff --git a/net/rose/rose_loopback.c b/net/rose/rose_loopback.c
> index 7b094275ea8b..ff252ef73592 100644
> --- a/net/rose/rose_loopback.c
> +++ b/net/rose/rose_loopback.c
> @@ -96,11 +96,22 @@ static void rose_loopback_timer(struct timer_list *unused)
>   }
>  
>   if (frametype == ROSE_CALL_REQUEST) {
> - if ((dev = rose_dev_get(dest)) != NULL) {
> - if (rose_rx_call_request(skb, dev, 
> rose_loopback_neigh, lci_o) == 0)
> - kfree_skb(skb);
> - } else {
> + if (!rose_loopback_neigh->dev) {
>   kfree_skb(skb);
> + continue;
> + }
> +
> + dev = rose_dev_get(dest);
> + if (!dev) {
> + kfree_skb(skb);
> + continue;
> + }
> +
> + if (rose_rx_call_request(skb, dev, rose_loopback_neigh,
> +  lci_o) == 0) {
> + dev_put(dev);
> + kfree_skb(skb);
>   }
>   } else {
>   kfree_skb(skb);
> 
> Please test this and resubmit it if it works.

Sure sir, I will test it and resend, if it works.


Thanks,
Anmol

[PATCH rdma-next v1 0/7] Use ib_umem_find_best_pgsz() for all umems

2020-11-15 Thread Leon Romanovsky

From: Leon Romanovsky 

Changelog:
v1:
 * Added patch for raw QP
 * Fixed commit messages
v0: https://lore.kernel.org/lkml/20201026132635.1337663-1-l...@kernel.org

-
>From Jason:

Move the remaining cases working with umems to use versions of
ib_umem_find_best_pgsz() tailored to the calculations the devices
requires.

Unlike a MR there is no IOVA, instead a page offset from the starting page
is possible, with various restrictions.

Compute the best page size to meet the page_offset restrictions.

Thanks

Jason Gunthorpe (7):
  RDMA/mlx5: Use ib_umem_find_best_pgoff() for SRQ
  RDMA/mlx5: Use mlx5_umem_find_best_quantized_pgoff() for WQ
  RDMA/mlx5: Directly compute the PAS list for raw QP RQ's
  RDMA/mlx5: Use mlx5_umem_find_best_quantized_pgoff() for QP
  RDMA/mlx5: mlx5_umem_find_best_quantized_pgoff() for CQ
  RDMA/mlx5: Use ib_umem_find_best_pgsz() for devx
  RDMA/mlx5: Lower setting the umem's PAS for SRQ

 drivers/infiniband/hw/mlx5/cq.c  |  48 +---
 drivers/infiniband/hw/mlx5/devx.c|  66 ++-
 drivers/infiniband/hw/mlx5/mem.c | 115 +++
 drivers/infiniband/hw/mlx5/mlx5_ib.h |  47 +++-
 drivers/infiniband/hw/mlx5/qp.c  | 165 ---
 drivers/infiniband/hw/mlx5/srq.c |  27 +
 drivers/infiniband/hw/mlx5/srq.h |   1 +
 drivers/infiniband/hw/mlx5/srq_cmd.c |  80 -
 include/rdma/ib_umem.h   |  42 +++
 9 files changed, 343 insertions(+), 248 deletions(-)

--
2.28.0

Re: [PATCH v6] can: usb: etas_es58X: add support for ETAS ES58X CAN USB interfaces

2020-11-15 Thread Vincent MAILHOL

The report from Intel's test robot is a false positive.

On Sun. 15 Nov. 2020 at 03:12, kernel test robot wrote:
> Hi Vincent,
>
> Thank you for the patch! Yet something to improve:
>
> [auto build test ERROR on linus/master]
> [also build test ERROR on bff6f1db91e330d7fba56f815cdbc412c75fe163 v5.10-rc3 
> next-20201113]
> [If your patch is applied to the wrong git tree, kindly drop us a note.

Patch is applied to the wrong git tree. It is based on the testing
branch of linux-can-next:
https://git.kernel.org/pub/scm/linux/kernel/git/mkl/linux-can-next.git/log/?h=testing

> And when submitting patch, we suggest to use '--base' as documented in
> https://git-scm.com/docs/git-format-patch]

I did so (c.f. the base-commit and prerequisite-patch-id tags at the
bottom of the patch). While the base-commit was taken into account,
the prerequisite-patch-id tags seem to have been ignored.

FYI, I used the below command to generate the patch.
git format-patch --base=bff6f1db91e330d7fba56f815cdbc412c75fe163 -v6
-o patch/v6 HEAD~1


Yours sincerely,
Vincent Mailhol

> url:
> https://github.com/0day-ci/linux/commits/Vincent-Mailhol/can-usb-etas_es58X-add-support-for-ETAS-ES58X-CAN-USB-interfaces/20201114-232854
> base:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
> config: x86_64-randconfig-a005-20201115 (attached as .config)
> compiler: clang version 12.0.0 (https://github.com/llvm/llvm-project 
> 9a85643cd357e412cff69067bb5c4840e228c2ab)
> 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 x86_64 cross compiling tool for clang build
> # apt-get install binutils-x86-64-linux-gnu
> # 
> https://github.com/0day-ci/linux/commit/80a9b72580bad04e879752fa5c54d278b486e2bb
> git remote add linux-review https://github.com/0day-ci/linux
> git fetch --no-tags linux-review 
> Vincent-Mailhol/can-usb-etas_es58X-add-support-for-ETAS-ES58X-CAN-USB-interfaces/20201114-232854
> git checkout 80a9b72580bad04e879752fa5c54d278b486e2bb
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=clang make.cross ARCH=x86_64
>
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
>
> All errors (new ones prefixed by >>):
>
> >> drivers/net/can/usb/etas_es58x/es58x_core.c:745:12: error: use of 
> >> undeclared identifier 'CAN_MAX_RAW_DLC'
>if (dlc > CAN_MAX_RAW_DLC) {
>  ^
>drivers/net/can/usb/etas_es58x/es58x_core.c:748:22: error: use of 
> undeclared identifier 'CAN_MAX_RAW_DLC'
>   __func__, dlc, CAN_MAX_RAW_DLC);
>  ^
> >> drivers/net/can/usb/etas_es58x/es58x_core.c:753:9: error: implicit 
> >> declaration of function 'can_fd_dlc2len' 
> >> [-Werror,-Wimplicit-function-declaration]
>len = can_fd_dlc2len(dlc);
>  ^
>drivers/net/can/usb/etas_es58x/es58x_core.c:753:9: note: did you mean 
> 'can_dlc2len'?
>include/linux/can/dev.h:190:4: note: 'can_dlc2len' declared here
>u8 can_dlc2len(u8 can_dlc);
>   ^
> >> drivers/net/can/usb/etas_es58x/es58x_core.c:756:9: error: implicit 
> >> declaration of function 'can_cc_dlc2len' 
> >> [-Werror,-Wimplicit-function-declaration]
>len = can_cc_dlc2len(dlc);
>  ^
>drivers/net/can/usb/etas_es58x/es58x_core.c:756:9: note: did you mean 
> 'can_dlc2len'?
>include/linux/can/dev.h:190:4: note: 'can_dlc2len' declared here
>u8 can_dlc2len(u8 can_dlc);
>   ^
> >> drivers/net/can/usb/etas_es58x/es58x_core.c:775:3: error: implicit 
> >> declaration of function 'can_frame_set_cc_len' 
> >> [-Werror,-Wimplicit-function-declaration]
>can_frame_set_cc_len(ccf, dlc, 
> es58x_priv(netdev)->can.ctrlmode);
>^
>5 errors generated.
> --
> >> drivers/net/can/usb/etas_es58x/es581_4.c:385:20: error: implicit 
> >> declaration of function 'can_get_cc_dlc' 
> >> [-Werror,-Wimplicit-function-declaration]
>tx_can_msg->dlc = can_get_cc_dlc(cf, priv->can.ctrlmode);
>  ^
> >> drivers/net/can/usb/etas_es58x/es581_4.c:387:41: error: no member named 
> >> 'len' in 'struct can_frame'
>memcpy(tx_can_msg->data, cf->data, cf->len);
>   ~~  ^
> >> drivers/n

Re: [PATCH v4 06/17] PCI: add SIOV and IMS capability detection

On Sat, Nov 14 2020 at 13:18, Ashok Raj wrote:
> On Sat, Nov 14, 2020 at 10:34:30AM +, Christoph Hellwig wrote:
>> On Thu, Nov 12, 2020 at 11:42:46PM +0100, Thomas Gleixner wrote:
>> Which is why I really think we need explicit opt-ins for "native"
>> SIOV handling and for paravirtualized SIOV handling, with the kernel
>> not offering support at all without either or a manual override on
>> the command line.
>
> opt-in by device or kernel? The way we are planning to support this is:
>
> Device support for IMS - Can discover in device specific means
> Kernel support for IMS. - Supported by IOMMU driver.

And why exactly do we have to enforce IOMMU support? Please stop looking
at IMS purely from the IDXD perspective. We are talking about the
general concept here and not about the restricted Intel universe.

> each driver can check 
>
> if (dev_supports_ims() && iommu_supports_ims()) {
>   /* Then IMS is supported in the platform.*/
> }

Please forget this 'each driver can check'. That's just wrong.

The only thing the driver has to check is whether the device supports
IMS or not. Everything else has to be handled by the underlying
infrastructure.

That's pretty much the same thing like PCI/MSI[X]. The driver does not
have to check 'device_has_msix() && platform_supports_msix()'. Enabling
MSI[X] will simply fail if it's not supported.

So for IMS creating the underlying irqdomain has to fail when the
platform does not support it and the driver can act upon the fail and
fallback to MSI[X] or just refuse to load when IMS is required for the
device to be functional.

Thanks,

tglx

Re: [PATCH] MAINTAINERS: rectify file patterns for NETFILTER

2020-11-15 Thread Pablo Neira Ayuso

On Mon, Nov 09, 2020 at 10:19:42AM +0100, Lukas Bulwahn wrote:
> The two file patterns in the NETFILTER section:
> 
>   F:  include/linux/netfilter*
>   F:  include/uapi/linux/netfilter*
> 
> intended to match the directories:
> 
>   ./include{/uapi}/linux/netfilter_{arp,bridge,ipv4,ipv6}
> 
> A quick check with ./scripts/get_maintainer.pl --letters -f will show that
> they are not matched, though, because this pattern only matches files, but
> not directories.
> 
> Rectify the patterns to match the intended directories.

Applied, thanks.

[tip: irq/core] genirq/irqdomain: Make irq_domain_disassociate() static

2020-11-15 Thread tip-bot2 for Thomas Gleixner

The following commit has been merged into the irq/core branch of tip:

Commit-ID: e906a546bd8653ed2e7a14cb300fd17952d7f862
Gitweb:
https://git.kernel.org/tip/e906a546bd8653ed2e7a14cb300fd17952d7f862
Author:Thomas Gleixner 
AuthorDate:Sat, 14 Nov 2020 23:36:28 +01:00
Committer: Thomas Gleixner 
CommitterDate: Sun, 15 Nov 2020 12:01:11 +01:00

genirq/irqdomain: Make irq_domain_disassociate() static

No users outside of the core code.

Signed-off-by: Thomas Gleixner 
Link: https://lore.kernel.org/r/87a6vja7mb@nanos.tec.linutronix.de

---
 include/linux/irqdomain.h | 2 --
 kernel/irq/irqdomain.c| 2 +-
 2 files changed, 1 insertion(+), 3 deletions(-)

diff --git a/include/linux/irqdomain.h b/include/linux/irqdomain.h
index 77bf7d8..5701a8b 100644
--- a/include/linux/irqdomain.h
+++ b/include/linux/irqdomain.h
@@ -387,8 +387,6 @@ extern int irq_domain_associate(struct irq_domain *domain, 
unsigned int irq,
 extern void irq_domain_associate_many(struct irq_domain *domain,
  unsigned int irq_base,
  irq_hw_number_t hwirq_base, int count);
-extern void irq_domain_disassociate(struct irq_domain *domain,
-   unsigned int irq);
 
 extern unsigned int irq_create_mapping(struct irq_domain *host,
   irq_hw_number_t hwirq);
diff --git a/kernel/irq/irqdomain.c b/kernel/irq/irqdomain.c
index 9c9cb88..3d7463f 100644
--- a/kernel/irq/irqdomain.c
+++ b/kernel/irq/irqdomain.c
@@ -496,7 +496,7 @@ static void irq_domain_set_mapping(struct irq_domain 
*domain,
}
 }
 
-void irq_domain_disassociate(struct irq_domain *domain, unsigned int irq)
+static void irq_domain_disassociate(struct irq_domain *domain, unsigned int 
irq)
 {
struct irq_data *irq_data = irq_get_irq_data(irq);
irq_hw_number_t hwirq;

[tip:irq/core] BUILD SUCCESS f296dcd629aa412a80a53215e46087f53af87f08

tree/branch: https://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git  
irq/core
branch HEAD: f296dcd629aa412a80a53215e46087f53af87f08  genirq: Remove 
GENERIC_IRQ_LEGACY_ALLOC_HWIRQ

elapsed time: 721m

configs tested: 119
configs skipped: 2

The following configs have been built successfully.
More configs may be tested in the coming days.

gcc tested configs:
arm defconfig
arm64allyesconfig
arm64   defconfig
arm  allyesconfig
arm  allmodconfig
riscvnommu_k210_defconfig
ia64defconfig
arm  tango4_defconfig
powerpc  ppc40x_defconfig
mipsgpr_defconfig
c6x  alldefconfig
xtensa   allyesconfig
nios2 3c120_defconfig
sh  r7780mp_defconfig
mips   ci20_defconfig
sh  r7785rp_defconfig
powerpc wii_defconfig
arm   h5000_defconfig
mips  loongson3_defconfig
mipsar7_defconfig
m68k   m5249evb_defconfig
archsdk_defconfig
shapsh4ad0a_defconfig
powerpc ksi8560_defconfig
powerpc mpc834x_itx_defconfig
sh  sdk7780_defconfig
arc nsimosci_hs_smp_defconfig
sh  sdk7786_defconfig
ia64generic_defconfig
powerpc ep8248e_defconfig
sparc64  alldefconfig
powerpc mpc837x_mds_defconfig
armspear3xx_defconfig
powerpc mpc8540_ads_defconfig
mips db1xxx_defconfig
sh espt_defconfig
mipsjmr3927_defconfig
mipsbcm47xx_defconfig
arm orion5x_defconfig
mips  cavium_octeon_defconfig
nds32 allnoconfig
sparc   sparc64_defconfig
alphaallyesconfig
mips   rbtx49xx_defconfig
sh   se7750_defconfig
csky alldefconfig
sparc64 defconfig
powerpc  storcenter_defconfig
powerpc stx_gp3_defconfig
c6xevmc6474_defconfig
arm axm55xx_defconfig
sh  landisk_defconfig
m68k apollo_defconfig
sh   se7712_defconfig
mipsnlm_xlr_defconfig
ia64 allmodconfig
ia64 allyesconfig
m68k allmodconfig
m68kdefconfig
m68k allyesconfig
nds32   defconfig
nios2allyesconfig
cskydefconfig
alpha   defconfig
h8300allyesconfig
arc defconfig
sh   allmodconfig
parisc  defconfig
s390 allyesconfig
parisc   allyesconfig
s390defconfig
i386 allyesconfig
sparcallyesconfig
sparc   defconfig
i386defconfig
nios2   defconfig
arc  allyesconfig
c6x  allyesconfig
mips allyesconfig
mips allmodconfig
powerpc  allyesconfig
powerpc  allmodconfig
powerpc   allnoconfig
i386 randconfig-a006-20201115
i386 randconfig-a005-20201115
i386 randconfig-a001-20201115
i386 randconfig-a002-20201115
i386 randconfig-a004-20201115
i386 randconfig-a003-20201115
x86_64   randconfig-a015-20201115
x86_64   randconfig-a011-20201115
x86_64   randconfig-a014-20201115
x86_64   randconfig-a013-20201115
x86_64   randconfig-a016-20201115
x86_64   randconfig-a012-20201115
i386 randconfig-a012-20201115
i386 randconfig-a014-20201115
i386 randconfig-a016-20201115
i386 randconfig-a011-20201115
i386 randconfig-a015-20201115
i386 randconfig

Re: [RFC bpf-next 1/3] bpf: add module support to btf display helpers

2020-11-15 Thread Alan Maguire

On Sat, 14 Nov 2020, Yonghong Song wrote:

> 
> 
> On 11/14/20 8:04 AM, Alexei Starovoitov wrote:
> > On Fri, Nov 13, 2020 at 10:59 PM Andrii Nakryiko
> >  wrote:
> >>
> >> On Fri, Nov 13, 2020 at 10:11 AM Alan Maguire 
> >> wrote:
> >>>
> >>> bpf_snprintf_btf and bpf_seq_printf_btf use a "struct btf_ptr *"
> >>> argument that specifies type information about the type to
> >>> be displayed.  Augment this information to include a module
> >>> name, allowing such display to support module types.
> >>>
> >>> Signed-off-by: Alan Maguire 
> >>> ---
> >>>   include/linux/btf.h|  8 
> >>>   include/uapi/linux/bpf.h   |  5 -
> >>>   kernel/bpf/btf.c   | 18 ++
> >>>   kernel/trace/bpf_trace.c   | 42
> >>>   --
> >>>   tools/include/uapi/linux/bpf.h |  5 -
> >>>   5 files changed, 66 insertions(+), 12 deletions(-)
> >>>
> >>> diff --git a/include/linux/btf.h b/include/linux/btf.h
> >>> index 2bf6418..d55ca00 100644
> >>> --- a/include/linux/btf.h
> >>> +++ b/include/linux/btf.h
> >>> @@ -209,6 +209,14 @@ static inline const struct btf_var_secinfo
> >>> *btf_type_var_secinfo(
> >>>   const struct btf_type *btf_type_by_id(const struct btf *btf, u32
> >>>   type_id);
> >>>   const char *btf_name_by_offset(const struct btf *btf, u32 offset);
> >>>   struct btf *btf_parse_vmlinux(void);
> >>> +#ifdef CONFIG_DEBUG_INFO_BTF_MODULES
> >>> +struct btf *bpf_get_btf_module(const char *name);
> >>> +#else
> >>> +static inline struct btf *bpf_get_btf_module(const char *name)
> >>> +{
> >>> +   return ERR_PTR(-ENOTSUPP);
> >>> +}
> >>> +#endif
> >>>   struct btf *bpf_prog_get_target_btf(const struct bpf_prog *prog);
> >>>   #else
> >>>   static inline const struct btf_type *btf_type_by_id(const struct btf
> >>>   *btf,
> >>> diff --git a/include/uapi/linux/bpf.h b/include/uapi/linux/bpf.h
> >>> index 162999b..26978be 100644
> >>> --- a/include/uapi/linux/bpf.h
> >>> +++ b/include/uapi/linux/bpf.h
> >>> @@ -3636,7 +3636,8 @@ struct bpf_stack_build_id {
> >>>* the pointer data is carried out to avoid kernel crashes
> >>>during
> >>>* operation.  Smaller types can use string space on the
> >>>stack;
> >>>* larger programs can use map data to store the string
> >>> - * representation.
> >>> + * representation.  Module-specific data structures can be
> >>> + * displayed if the module name is supplied.
> >>>*
> >>>* The string can be subsequently shared with userspace via
> >>>* bpf_perf_event_output() or ring buffer interfaces.
> >>> @@ -5076,11 +5077,13 @@ struct bpf_sk_lookup {
> >>>* potentially to specify additional details about the BTF pointer
> >>>* (rather than its mode of display) - is included for future use.
> >>>* Display flags - BTF_F_* - are passed to bpf_snprintf_btf separately.
> >>> + * A module name can be specified for module-specific data.
> >>>   */
> >>>   struct btf_ptr {
> >>>  void *ptr;
> >>>  __u32 type_id;
> >>>  __u32 flags;/* BTF ptr flags; unused at present. */
> >>> +   const char *module; /* optional module name. */
> >>
> >> I think module name is a wrong API here, similarly how type name was
> >> wrong API for specifying the type (and thus we use type_id here).
> >> Using the module's BTF ID seems like a more suitable interface. That's
> >> what I'm going to use for all kinds of existing BPF APIs that expect
> >> BTF type to attach BPF programs.
> >>
> >> Right now, we use only type_id and implicitly know that it's in
> >> vmlinux BTF. With module BTFs, we now need a pair of BTF object ID +
> >> BTF type ID to uniquely identify the type. vmlinux BTF now can be
> >> specified in two different ways: either leaving BTF object ID as zero
> >> (for simplicity and backwards compatibility) or specifying it's actual
> >> BTF obj ID (which pretty much always should be 1, btw). This feels
> >> like a natural extension, WDYT?
> >>
> >> And similar to type_id, no one should expect users to specify these
> >> IDs by hand, Clang built-in and libbpf should work together to figure
> >> this out for the kernel to use.
> >>
> >> BTW, with module names there is an extra problem for end users. Some
> >> types could be either built-in or built as a module (e.g., XFS data
> >> structures). Why would we require BPF users to care which is the case
> >> on any given host?
> > 
> > +1.
> > As much as possible libbpf should try to hide the difference between
> > type in a module vs type in the vmlinux, since that difference most of the
> > time is irrelevant from bpf prog pov.
>

All sounds good to me - I've split out the libbpf fix and 
put together an updated patchset for the helpers/test which
converts the currently unused __u32 "flags" field in
struct btf_ptr to an "obj_id" field.  If obj_id is > 1 it
is presumed to be a module ID.

[PATCH bpf-next] libbpf: bpf__find_by_name[_kind] should use btf__get_nr_types()

2020-11-15 Thread Alan Maguire

When operating on split BTF, btf__find_by_name[_kind] will not
iterate over all types since they use btf->nr_types to show
the number of types to iterate over.  For split BTF this is
the number of types _on top of base BTF_, so it will
underestimate the number of types to iterate over, especially
for vmlinux + module BTF, where the latter is much smaller.

Use btf__get_nr_types() instead.

Fixes: ba451366bf44 ("libbpf: Implement basic split BTF support")
Signed-off-by: Alan Maguire 
---
 tools/lib/bpf/btf.c | 8 
 1 file changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/lib/bpf/btf.c b/tools/lib/bpf/btf.c
index 2d0d064..8ff46cd 100644
--- a/tools/lib/bpf/btf.c
+++ b/tools/lib/bpf/btf.c
@@ -674,12 +674,12 @@ int btf__resolve_type(const struct btf *btf, __u32 
type_id)
 
 __s32 btf__find_by_name(const struct btf *btf, const char *type_name)
 {
-   __u32 i;
+   __u32 i, nr_types = btf__get_nr_types(btf);
 
if (!strcmp(type_name, "void"))
return 0;
 
-   for (i = 1; i <= btf->nr_types; i++) {
+   for (i = 1; i <= nr_types; i++) {
const struct btf_type *t = btf__type_by_id(btf, i);
const char *name = btf__name_by_offset(btf, t->name_off);
 
@@ -693,12 +693,12 @@ __s32 btf__find_by_name(const struct btf *btf, const char 
*type_name)
 __s32 btf__find_by_name_kind(const struct btf *btf, const char *type_name,
 __u32 kind)
 {
-   __u32 i;
+   __u32 i, nr_types = btf__get_nr_types(btf);
 
if (kind == BTF_KIND_UNKN || !strcmp(type_name, "void"))
return 0;
 
-   for (i = 1; i <= btf->nr_types; i++) {
+   for (i = 1; i <= nr_types; i++) {
const struct btf_type *t = btf__type_by_id(btf, i);
const char *name;
 
-- 
1.8.3.1

Re: [PATCH v2 1/6] ARM: dts: exynos: Fix Ethernet interface description for Odroid XU3

2020-11-15 Thread Krzysztof Kozlowski

On Tue, Nov 03, 2020 at 07:44:07PM +0100, Łukasz Stelmach wrote:
> Assign appropriate compatible properties.
> 
> Signed-off-by: Łukasz Stelmach 
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)
> 

Thanks, applied.

Best regards,
Krzysztof

Re: [PATCH v2 2/6] ARM: dts: exynos: Add an alias for the Ethernet interface on Odroid XU3

2020-11-15 Thread Krzysztof Kozlowski

On Tue, Nov 03, 2020 at 07:44:08PM +0100, Łukasz Stelmach wrote:
> Add an alias to enable bootloaders to find the Ethernet
> interface and assign a MAC address.
> 
> Signed-off-by: Łukasz Stelmach 
> ---
>  arch/arm/boot/dts/exynos5422-odroidxu3.dts | 4 
>  1 file changed, 4 insertions(+)
> 

Thanks, applied.

Best regards,
Krzysztof

[PATCH] USB: apple-mfi-fastcharge: Fix kfree after failed kzalloc

2020-11-15 Thread Lucas Tanure

kfree don't need to be called after a failed kzalloc

Signed-off-by: Lucas Tanure 
---
Follow up patch from "USB: apple-mfi-fastcharge: Use devm_kzalloc and
simplify the code"

 drivers/usb/misc/apple-mfi-fastcharge.c | 15 ---
 1 file changed, 4 insertions(+), 11 deletions(-)

diff --git a/drivers/usb/misc/apple-mfi-fastcharge.c 
b/drivers/usb/misc/apple-mfi-fastcharge.c
index 9de0171b5177..6dedd5498e8a 100644
--- a/drivers/usb/misc/apple-mfi-fastcharge.c
+++ b/drivers/usb/misc/apple-mfi-fastcharge.c
@@ -178,16 +178,13 @@ static int mfi_fc_probe(struct usb_device *udev)
 {
struct power_supply_config battery_cfg = {};
struct mfi_device *mfi = NULL;
-   int err;
 
if (!mfi_fc_match(udev))
return -ENODEV;
 
mfi = kzalloc(sizeof(struct mfi_device), GFP_KERNEL);
-   if (!mfi) {
-   err = -ENOMEM;
-   goto error;
-   }
+   if (!mfi)
+   return -ENOMEM;
 
battery_cfg.drv_data = mfi;
 
@@ -197,18 +194,14 @@ static int mfi_fc_probe(struct usb_device *udev)
_cfg);
if (IS_ERR(mfi->battery)) {
dev_err(>dev, "Can't register battery\n");
-   err = PTR_ERR(mfi->battery);
-   goto error;
+   kfree(mfi);
+   return PTR_ERR(mfi->battery);
}
 
mfi->udev = usb_get_dev(udev);
dev_set_drvdata(>dev, mfi);
 
return 0;
-
-error:
-   kfree(mfi);
-   return err;
 }
 
 static void mfi_fc_disconnect(struct usb_device *udev)
-- 
2.29.2

Re: pl353-smc.c:undefined reference to `amba_driver_register'

2020-11-15 Thread Krzysztof Kozlowski

On Sun, Nov 15, 2020 at 06:17:53AM +0800, kernel test robot wrote:
> tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
> master
> head:   f01c30de86f1047e9bae1b1b1417b0ce8dcd15b1
> commit: ea0c0ad6b6eb36726088991d97a55b99cae456d0 memory: Enable compile 
> testing for most of the drivers
> date:   3 months ago
> config: arm-randconfig-p002-20201115 (attached as .config)
> compiler: arm-linux-gnueabi-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
> # 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=ea0c0ad6b6eb36726088991d97a55b99cae456d0
> git remote add linus 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
> git fetch --no-tags linus master
> git checkout ea0c0ad6b6eb36726088991d97a55b99cae456d0
> # save the attached .config to linux build tree
> COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
> ARCH=arm 
> 
> If you fix the issue, kindly add following tag as appropriate
> Reported-by: kernel test robot 
> 
> All errors (new ones prefixed by >>):
> 
>arm-linux-gnueabi-ld: drivers/memory/pl353-smc.o: in function 
> `pl353_smc_driver_init':
> >> pl353-smc.c:(.init.text+0x10): undefined reference to 
> >> `amba_driver_register'
>arm-linux-gnueabi-ld: drivers/memory/pl353-smc.o: in function 
> `pl353_smc_driver_exit':
> >> pl353-smc.c:(.exit.text+0x10): undefined reference to 
> >> `amba_driver_unregister'

Fix is ready:
https://git.kernel.org/pub/scm/linux/kernel/git/krzk/linux-mem-ctrl.git/commit/?h=fixes=275374b46da2baea437a2e9456e52a04c2049780

Best regards,
Krzysztof

Re: Has the linux-kernel already implemented the functions in apollo-kernel?

2020-11-15 Thread Greg KH

On Sat, Oct 31, 2020 at 02:44:07PM +0800, Hongyi Zhao wrote:
> Hi,
> 
> The apollo-kernel (https://github.com/ApolloAuto/apollo-kernel) is a
> patched Linux Kernel based on official Linux Kernel 4.4.32 with some
> modifications on the kernel level, especially for the scenario
> necessary to run the Apollo (https://github.com/ApolloAuto/apollo)
> open autonomous driving platform software stack.
> 
> According to the official description as shown
> ,
> the major difference from the original Linux kernel is as follows:
> 
> 
> - Realtime patch (https://rt.wiki.kernel.org/index.php/RT_PREEMPT_HOWTO)
> - Latest e1000e intel ethernet driver
> - Bugfix for Nvidia driver under realtime patch
> - Double free in the inet_csk_clone_lock function patch
> (https://bugzilla.redhat.com/show_bug.cgi?id=1450972)
> - Other cve security patches
> 
> 
> However, considering that Linux Kernel 4.4.32 is a fairly old version,
> so I want to know whether the modifications/fixes applied/added have
> been already available in the current Linux kernel.
> 
> Any hints will be highly appreciated.

As you have the source to both trees, why not compare them and see if
all of this is true or not?  That's the best way to be sure.

good luck!

greg k-h

[PATCH v5] zram: break the strict dependency from lzo

2020-11-15 Thread Rui Salvaterra

>From the beginning, the zram block device always enabled CRYPTO_LZO, since
lzo-rle is hardcoded as the fallback compression algorithm. As a consequence, on
systems where another compression algorithm is chosen (e.g. CRYPTO_ZSTD), the
lzo kernel module becomes unused, while still having to be built/loaded.

This patch removes the hardcoded lzo-rle dependency and allows the user to
select the default compression algorithm for zram at build time. The previous
behaviour is kept, as the default algorithm is still lzo-rle.

Suggested-by: Sergey Senozhatsky 
Suggested-by: Minchan Kim 
Signed-off-by: Rui Salvaterra 
---
v5: incorporate Minchan's feedback. Allow the user to choose a default 
algorithm.
v4: incorporate Sergey's feedback and fix a small typo.
v3: fix the default selection when lzo isn't present. Rebase against 5.10-rc1.
v2: fix the dependency on CRYPTO.

I believe this is the final version, but it does deserve some comment. Given the
choice of having more preprocessor #if/#endif directives in C files or making
the kconfig a bit more complex, I went for the latter. However, since kconfig
choices can only be boolean, I had to devise a way to make a string selection
based on the boolean choice, hence the ZRAM_DEF_COMP symbol.
I also tried to make the ZRAM_AUTOSEL_ALGO definition a bit less painful to the
eye, while still allowing for the compression algorithms to be selected as
modules, as per Sergey's suggestion.

 drivers/block/zram/Kconfig| 49 ++-
 drivers/block/zram/zcomp.c|  2 ++
 drivers/block/zram/zram_drv.c |  2 +-
 3 files changed, 51 insertions(+), 2 deletions(-)

diff --git a/drivers/block/zram/Kconfig b/drivers/block/zram/Kconfig
index fe7a4b7d30cf..cde089c30ffb 100644
--- a/drivers/block/zram/Kconfig
+++ b/drivers/block/zram/Kconfig
@@ -2,7 +2,6 @@
 config ZRAM
tristate "Compressed RAM block device support"
depends on BLOCK && SYSFS && ZSMALLOC && CRYPTO
-   select CRYPTO_LZO
help
  Creates virtual block devices called /dev/zramX (X = 0, 1, ...).
  Pages written to these disks are compressed and stored in memory
@@ -14,6 +13,54 @@ config ZRAM
 
  See Documentation/admin-guide/blockdev/zram.rst for more information.
 
+choice
+   prompt "Default zram compression algorithm"
+   depends on ZRAM
+
+config ZRAM_DEF_COMP_LZORLE
+   bool "lzo-rle"
+   depends on CRYPTO_LZO
+
+config ZRAM_DEF_COMP_ZSTD
+   bool "zstd"
+   depends on CRYPTO_ZSTD
+
+config ZRAM_DEF_COMP_LZ4
+   bool "lz4"
+   depends on CRYPTO_LZ4
+
+config ZRAM_DEF_COMP_LZO
+   bool "lzo"
+   depends on CRYPTO_LZO
+
+config ZRAM_DEF_COMP_LZ4HC
+   bool "lz4hc"
+   depends on CRYPTO_LZ4HC
+
+config ZRAM_DEF_COMP_842
+   bool "842"
+   depends on CRYPTO_842
+
+endchoice
+
+config ZRAM_DEF_COMP
+   string
+   default "lzo-rle" if ZRAM_DEF_COMP_LZORLE
+   default "zstd" if ZRAM_DEF_COMP_ZSTD
+   default "lz4" if ZRAM_DEF_COMP_LZ4
+   default "lzo" if ZRAM_DEF_COMP_LZO
+   default "lz4hc" if ZRAM_DEF_COMP_LZ4HC
+   default "842" if ZRAM_DEF_COMP_842
+
+config ZRAM_AUTOSEL_ALGO
+   def_bool y
+   depends on ZRAM && \
+   !(CRYPTO_LZ4=m   || CRYPTO_LZ4=y   || \
+ CRYPTO_LZ4HC=m || CRYPTO_LZ4HC=y || \
+ CRYPTO_842=m   || CRYPTO_842=y   || \
+ CRYPTO_ZSTD=m  || CRYPTO_ZSTD=y)
+   select CRYPTO_LZO
+
 config ZRAM_WRITEBACK
bool "Write back incompressible or idle page to backing device"
depends on ZRAM
diff --git a/drivers/block/zram/zcomp.c b/drivers/block/zram/zcomp.c
index 33e3b76c4fa9..052aa3f65514 100644
--- a/drivers/block/zram/zcomp.c
+++ b/drivers/block/zram/zcomp.c
@@ -15,8 +15,10 @@
 #include "zcomp.h"
 
 static const char * const backends[] = {
+#if IS_ENABLED(CONFIG_CRYPTO_LZO)
"lzo",
"lzo-rle",
+#endif
 #if IS_ENABLED(CONFIG_CRYPTO_LZ4)
"lz4",
 #endif
diff --git a/drivers/block/zram/zram_drv.c b/drivers/block/zram/zram_drv.c
index 1b697208d661..9ddccb968c68 100644
--- a/drivers/block/zram/zram_drv.c
+++ b/drivers/block/zram/zram_drv.c
@@ -42,7 +42,7 @@ static DEFINE_IDR(zram_index_idr);
 static DEFINE_MUTEX(zram_index_mutex);
 
 static int zram_major;
-static const char *default_compressor = "lzo-rle";
+static const char *default_compressor = CONFIG_ZRAM_DEF_COMP;
 
 /* Module params (documentation at end) */
 static unsigned int num_devices = 1;
-- 
2.29.2

Re: [RFC PATCH v2 00/26] Make reporting-bugs easier to grasp and yet more detailed & helpful

2020-11-15 Thread Thorsten Leemhuis

Am 13.11.20 um 23:33 schrieb Jonathan Corbet:

On Thu, 12 Nov 2020 18:58:37 +0100
Thorsten Leemhuis wrote:

This series rewrites the "how to report bugs to the Linux kernel
maintainers" document to make it more straight forward and its essence
easier to grasp. At the same time make the text provide a lot more details
about the process in form of a reference section, so users that want or
need to know them have them at hand.

The goal of this rewrite: improve the quality of the bug reports and
reduce the number of reports that get ignored. This was motivated by many
reports of poor quality the submitter noticed while looking after Linux
kernel regression tracking many moons ago.

So I've not had a chance to try to read through the whole thing again,
will try to do so in the near future.

Great, thx, looking forward to it.

As for how to proceed...getting others to review this is going to be a bit
of a challenge.

Yeah :-/

Perhaps the right approach is to just merge the new
document under a new name - reporting-bugs-the-novel.txt

drivers/staging/Documentation/ (no, just kidding [I think…])

or something -
then try to get a few people to look at specific parts of it? Once all
seems well we can rename it over the old document and call it done.

Make sense?

Totally fine for me. Putting it some place that makes it easier to
collaborate and to see who writes what is better for everyone – and get
control out of my hands and burden off my shoulders. ;-)

There is just one thing on I'm wondering: should we start with the
version of the text start users very long lines/is unwrapped and use it
for the reviewing and polishing phase? Together with tools like meld of
kdiff3 that afaics makes it lot easier to see what actually changes.
That'd why I uploaded the text in such a format:

https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v1.rst
https://gitlab.com/knurd42/linux/-/raw/reporting-bugs/Documentation/admin-guide/reporting-bugs-v2.rst

These for example would have allowed an easier rereview from Randy (but
I think he's right not doing one right now [see the other reply]!), as
these tools are quite well at highlighting what changed and what did
not. Yer, these tools are not as bad as a classic diff once you change
something in a wrapped paragraph, but in my experience work quite a bit
better with long lines. That's why I wonder if we should stick to them
before we call the main work done. Another reasons: with long lines
everyone can temporarily put the text in LibreOffice, Google Docs, ...
and use their spelling and grammar checkers.

Another aspect on my mind: the split up makes it easy to just CC certain
people on parts we want them to review. I for example planned to CC the
members of the stable-team only on four patches (TLDR, the two patches
with the step by step parts, the reference section for stable and
logterm), as those are the main ones that are relevant for them:

https://lore.kernel.org/lkml/b80b1387cf09fb897f4a527bc487fff3012d1181.1605203187.git.li...@leemhuis.info/
https://lore.kernel.org/lkml/b439c3d74c541d4d7631203a52f9d697ea8c283d.1605203187.git.li...@leemhuis.info/
https://lore.kernel.org/lkml/2d840fb91b7c5d481284275dea1d4f75fd755af6.1605203187.git.li...@leemhuis.info/
https://lore.kernel.org/lkml/0bb6bf554ac1f0c2a75631e6969a50dcd34c6b51.1605203187.git.li...@leemhuis.info/

Without a split split we'd have to tell people something like "please
took at the document and the sections starting with , ,
and ". Or would we at some point just simply sent those parts as
regular text (not as diff) my mail to the people & lists that need to
review them?

And a few more thoughts, just for completeness.

* I guess we should discuss the dual-license approach I chose soon
before it gets complicate to change it

* Some of the reviewer might want to compare the approaches the old and
the new text take. The current patch-series tries to makes that easy by
removing parts from the old text when adding new text about that topic.
That would be mostly lost afaics, but I guess it's not that much of a
problem.

* I wonder if putting the text in some real collaborative text editor
(google docs, a wiki, Etherpad, …) for a while would be even better. But
even with restricted write access that might pose some problems for
signing the changes off later. :-/ Guess finding the solution for those
might not be worth the trouble.

Ciao, Thorsten

[PATCH] net: lantiq: Wait for the GPHY firmware to be ready

2020-11-15 Thread Martin Blumenstingl

A user reports (slightly shortened from the original message):
  libphy: lantiq,xrx200-mdio: probed
  mdio_bus 1e108000.switch-mii: MDIO device at address 17 is missing.
  gswip 1e108000.switch lan: no phy at 2
  gswip 1e108000.switch lan: failed to connect to port 2: -19
  lantiq,xrx200-net 1e10b308.eth eth0: error -19 setting up slave phy

This is a single-port board using the internal Fast Ethernet PHY. The
user reports that switching to PHY scanning instead of configuring the
PHY within device-tree works around this issue.

The documentation for the standalone variant of the PHY11G (which is
probably very similar to what is used inside the xRX200 SoCs but having
the firmware burnt onto that standalone chip in the factory) states that
the PHY needs 300ms to be ready for MDIO communication after releasing
the reset.

Add a 300ms delay after initializing all GPHYs to ensure that the GPHY
firmware had enough time to initialize and to appear on the MDIO bus.
Unfortunately there is no (known) documentation on what the minimum time
to wait after releasing the reset on an internal PHY so play safe and
take the one for the external variant. Only wait after the last GPHY
firmware is loaded to not slow down the initialization too much (
xRX200 has two GPHYs but newer SoCs have at least three GPHYs).

Fixes: 14fceff4771e51 ("net: dsa: Add Lantiq / Intel DSA driver for vrx200")
Signed-off-by: Martin Blumenstingl 
---
 drivers/net/dsa/lantiq_gswip.c | 11 +++
 1 file changed, 11 insertions(+)

diff --git a/drivers/net/dsa/lantiq_gswip.c b/drivers/net/dsa/lantiq_gswip.c
index 74db81dafee3..0a25283bdd13 100644
--- a/drivers/net/dsa/lantiq_gswip.c
+++ b/drivers/net/dsa/lantiq_gswip.c
@@ -26,6 +26,7 @@
  */
 
 #include 
+#include 
 #include 
 #include 
 #include 
@@ -1894,6 +1895,16 @@ static int gswip_probe(struct platform_device *pdev)
dev_err(dev, "gphy fw probe failed\n");
return err;
}
+
+   /* The standalone PHY11G requires 300ms to be fully
+* initialized and ready for any MDIO communication after being
+* taken out of reset. For the SoC-internal GPHY variant there
+* is no (known) documentation for the minimum time after a
+* reset. Use the same value as for the standalone variant as
+* some users have reported internal PHYs not being detected
+* without any delay.
+*/
+   msleep(300);
}
 
/* bring up the mdio bus */
-- 
2.29.2

Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy

2020-11-15 Thread Russell King - ARM Linux admin

On Sun, Nov 15, 2020 at 03:26:01AM +0100, Andreas Färber wrote:
> Hi Russell,
> 
> On 15.11.20 02:02, Russell King - ARM Linux admin wrote:
> > On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote:
> >> Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta:
> >> Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX.
> >>
> >> In case a comphy is not provided, mvneta_validate()'s check
> >>   state->interface == PHY_INTERFACE_MODE_2500BASEX
> >> could never be true (it would've returned with empty bitmask before),
> >> so that 2500baseT_Full and 2500baseX_Full do net get added to the mask.
> > 
> > This makes me nervous. It was intentional that if there is no comphy
> > configured in DT for SoCs such as Armada 388, then there is no support
> > to switch between 1G and 2.5G speed. Unfortunately, the configuration
> > of the comphy is up to the board to do, not the SoC .dtsi, so we can't
> > rely on there being a comphy on Armada 388 systems.
> 
> Please note that the if clause at the beginning of the validate function
> does not check for comphy at all. So even with comphy, if there is a
> code path that attempts to validate state 2500BASEX, it is broken, too.

I'm afraid you are mistaken.  phy_interface_mode_is_8023z() covers
both 1000BASEX and 2500BASEX.

> Do you consider the modification of both ifs (validate and power_up) as
> correct? Should they be split off from my main _NA change you discuss?

Sorry, don't understand this comment.

> > So, one of the side effects of this patch is it incorrectly opens up
> > the possibility of allowing 2.5G support on Armada 388 without a comphy
> > configured.
> > 
> > We really need a better way to solve this; just relying on the lack of
> > comphy and poking at a register that has no effect on Armada 388 to
> > select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen
> > doesn't sound like a good idea to me.
> [snip]
> 
> May I add that the comphy needs better documentation?
> 
> As a DT contributor I would need the binding to tell me that it's an
> enum with 2 meaning SGMII2. Not even the max of 2 is documented. The
> Linux driver talks of ports, but I don't see that term used in U-Boot,
> and U-Boot APIs appeared to pass very different args in the board code.

It would be nice if the comphy documentation described this parameter
in detail for all comphys, but alas it hasn't been.

This is described in the binding for Armada 38x
Documentation/devicetree/bindings/phy/phy-armada38x-comphy.txt:

- #phy-cells : from the generic phy bindings, must be 1. Defines the
   input port to use for a given comphy lane.

This came from the phy-mvebu-comphy.txt, which was maintained by
bootlin/free-electrons, and uses the same wording.

For the Armada 38x comphy, it is the internal port number for the
ethernet controller when the comphy is connected to ethernet. So,
0 is ethernet@7, 1 is ethernet@3, 2 is ethernet@34000. It
actually defines an index into a table in the comphy driver which is
used to look up the "Common PHYs Selectors Register" setting for each
comphy, and also describes the bit index in an undocumented
configuration register for the ethernet port. Look at Table 1479
in the public Armada-38x-Functional-Spec-U0A document (which can be
found via google.) You'll see it talks about XXX PortN. This is the
"N" value.

The Armada 38x comphy Linux driver does not support non-ethernet
interfaces (since this was all I needed it for) but the hardware does
support SATA and USB. The driver can be regarded as incomplete, but it
is not necessary for it to be complete. These are not described in the
DT for the SoC since historically they have not needed to be, since
u-boot does all the setup there - and to add them would require a lot
of effort to ensure that they were correct for every board. That's
dangerous to do when we don't have a driver making use of that
information; there would be no validation that it is correct.

> The binding also still needs to be converted to YAML before we can
> extend it with any better explanations. (And before you suggest it:
> Since I obviously don't fully understand that hardware, I'm the wrong
> person to attempt documenting it. The 38x comphy seems not mentioned in
> MAINTAINERS, only the 3700 one.)

I'm not sure how we'd better describe it TBH. It is the input port
number as described by the SoC documentation.

I suppose we could say:

0 for ethernet@7
1 for ethernet@3
2 for ethernet@34000
0 for usb@...
1 for usb@...
0 for pci@...
1 for pci@...
... etc ...

But then what if we have that IP re-used on a different SoC where the
devices are at different addresses in the SoC. So that would mean we
would need to list out the devices for every SoC in the comphy
documentation, which is hardly practical.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTP is here! 40Mbps

Re: [PATCH] IB/hfi1: Fix error return code in hfi1_init_dd()

2020-11-15 Thread Leon Romanovsky

On Sun, Nov 15, 2020 at 04:25:48PM +0800, Wang ShaoBo wrote:
> Fix to return the error code from hfi1_netdev_alloc() instaed of 0
> in hfi1_init_dd(), as done elsewhere in this function.
>
> Fixes: 4730f4a6c6b2 ("IB/hfi1: Activate the dummy netdev")
> Signed-off-by: Wang ShaoBo 
> ---
>  drivers/infiniband/hw/hfi1/chip.c | 3 ++-
>  1 file changed, 2 insertions(+), 1 deletion(-)

It was already handled, thanks
https://lore.kernel.org/lkml/1605249747-17942-1-git-send-email-zhangchangzh...@huawei.com

Re: [PATCH v8 08/26] memory: tegra30-emc: Continue probing if timings are missing in device-tree

2020-11-15 Thread Dmitry Osipenko

14.11.2020 18:42, Krzysztof Kozlowski пишет:
> On Wed, Nov 11, 2020 at 04:14:38AM +0300, Dmitry Osipenko wrote:
>> EMC driver will become mandatory after turning it into interconnect
>> provider because interconnect users, like display controller driver, will
>> fail to probe using newer device-trees that have interconnect properties.
>> Thus make EMC driver to probe even if timings are missing in device-tree.
>>
>> Signed-off-by: Dmitry Osipenko 
>> ---
>>  drivers/memory/tegra/tegra30-emc.c | 29 +++--
>>  1 file changed, 15 insertions(+), 14 deletions(-)
> 
> Thanks, applied 1-8.  For the rest I see discussion on going, so I guess
> there will be a v9.

The v9 will be ready soon, thank you.

Re: [PATCH RFC v1 1/4] dt-bindings: net: dwmac-meson: use picoseconds for the RGMII RX delay

2020-11-15 Thread Martin Blumenstingl

Hi Andrew,

On Sat, Nov 14, 2020 at 11:32 PM Andrew Lunn  wrote:
[...]
> > +amlogic,rgmii-rx-delay-ps:
> > +  default: 0
> >description:
> >  The internal RGMII RX clock delay (provided by this IP block) 
> > in
> > -nanoseconds. When phy-mode is set to "rgmii" then the RX delay
> > +picoseconds. When phy-mode is set to "rgmii" then the RX delay
> >  should be explicitly configured. When the phy-mode is set to
> >  either "rgmii-id" or "rgmii-rxid" the RX clock delay is already
> >  provided by the PHY. Any configuration is ignored when the
> >  phy-mode is set to "rmii".
>
> Hi Martin
>
> I don't think the wording matches what the driver is actually doing:
>
> if (dwmac->rx_delay_ns == 2)
> rx_dly_config = PRG_ETH0_ADJ_ENABLE | PRG_ETH0_ADJ_SETUP;
> else
> rx_dly_config = 0;
>
> switch (dwmac->phy_mode) {
> case PHY_INTERFACE_MODE_RGMII:
> delay_config = tx_dly_config | rx_dly_config;
> break;
> case PHY_INTERFACE_MODE_RGMII_RXID:
> delay_config = tx_dly_config;
> break;
> case PHY_INTERFACE_MODE_RGMII_TXID:
> delay_config = rx_dly_config;
> break;
> case PHY_INTERFACE_MODE_RGMII_ID:
> case PHY_INTERFACE_MODE_RMII:
> delay_config = 0;
> break;
>
> So rx_delay is used for both rgmii and rgmii-txid. The binding says
> nothing about rgmii-txid.
interesting point here. it's been like this before this patch. still I
would like to understand what the proper way to fix it is so I can
also include a fix for it:
1. should rgmii-txid not add any RX delay on the MAC side? that would
mean for my board I will switch to phy-mode rgmii so the MAC applies
both the RX and TX delays
2. update the documentation to clarify that rgmii-txid would also add
the RX delay on the MAC side

> And while i'm looking at the code, i wonder about this:
>
>if (rx_dly_config & PRG_ETH0_ADJ_ENABLE) {
> if (!dwmac->timing_adj_clk) {
> dev_err(dwmac->dev,
> "The timing-adjustment clock is mandatory for 
> the RX delay re-timing\n");
> return -EINVAL;
> }
>
> /* The timing adjustment logic is driven by a separate clock 
> */
> ret = meson8b_devm_clk_prepare_enable(dwmac,
>   dwmac->timing_adj_clk);
> if (ret) {
> dev_err(dwmac->dev,
> "Failed to enable the timing-adjustment 
> clock\n");
> return ret;
> }
> }
>
> It looks like it can be that rx_dly_config & PRG_ETH0_ADJ_ENABLE is
> true, so the clock is enabled, but delay_config does not contain
> rx_delay_config, so it is pointless turning it on.
that is a good point and also a bug with one of the previous patches
I'll include a patch fixing this in v2


Best regards,
Martin

Re: [PATCH v8 6/9] secretmem: add memcg accounting

On Fri, Nov 13, 2020 at 03:42:25PM -0800, Roman Gushchin wrote:
> вт, 10 нояб. 2020 г. в 07:16, Mike Rapoport :
> >
> > From: Mike Rapoport 
> >
> > Account memory consumed by secretmem to memcg. The accounting is updated
> > when the memory is actually allocated and freed.
> >
> > Signed-off-by: Mike Rapoport 
> > ---
> >  mm/filemap.c   |  2 +-
> >  mm/secretmem.c | 42 +-
> >  2 files changed, 42 insertions(+), 2 deletions(-)
> >
> > diff --git a/mm/filemap.c b/mm/filemap.c
> > index 249cf489f5df..11387a077373 100644
> > --- a/mm/filemap.c
> > +++ b/mm/filemap.c
> > @@ -844,7 +844,7 @@ static noinline int __add_to_page_cache_locked(struct 
> > page *page,
> > page->mapping = mapping;
> > page->index = offset;
> >
> > -   if (!huge) {
> > +   if (!huge && !page->memcg_data) {
> > error = mem_cgroup_charge(page, current->mm, gfp);
> > if (error)
> > goto error;
> > diff --git a/mm/secretmem.c b/mm/secretmem.c
> > index 1aa2b7cffe0d..1eb7667016fa 100644
> > --- a/mm/secretmem.c
> > +++ b/mm/secretmem.c
> > @@ -17,6 +17,7 @@
> >  #include 
> >  #include 
> >  #include 
> > +#include 
> >  #include 
> >  #include 
> >
> > @@ -49,6 +50,38 @@ struct secretmem_ctx {
> >
> >  static struct cma *secretmem_cma;
> >
> 
> Hi Mike!
> 
> > +static int secretmem_memcg_charge(struct page *page, gfp_t gfp, int order)
> > +{
> > +   unsigned long nr_pages = (1 << order);
> > +   int i, err;
> > +
> > +   err = memcg_kmem_charge_page(page, gfp, order);
> > +   if (err)
> > +   return err;
> > +
> > +   for (i = 1; i < nr_pages; i++) {
> > +   struct page *p = page + i;
> > +
> > +   p->memcg_data = page->memcg_data;
> > +   }
> 
> Hm, it looks very strange to me. Why do we need to copy memcg_data?
> What about css reference counting?

I need to copy memcg_data to mark a page as being accounted so it won't
be charged again when it is added to page cache.

What happens here is that I allocate a large page and then use it as a
local cache for allocations in secretmem_fault(). I charge the large
page as kmem. 

During secretmem_fault() a small sub-page from that large page goes into
page cache and there I skip its memcg accounting.

In the end, when the large page is freed, the memcg_data for all its
sub-pages is cleared and I uncharge memcg with the order of large page.

An alternative would be to uncharge a small page from kmem in
secretmem_fault() and make this page charged in add_to_page_cache(), but
that would complicate the release path as I would need to re-charge the
small page back to kmem at secretmem_freepage() and track all the
participating memcgs till the large page is freed.

> And what about statistics?

Hmm, that's probably won't be accurate :-/

> I'm sorry for being late.
> 
> Thank you!
> 
> > +
> > +   return 0;
> > +}
> > +
> > +static void secretmem_memcg_uncharge(struct page *page, int order)
> > +{
> > +   unsigned long nr_pages = (1 << order);
> > +   int i;
> > +
> > +   for (i = 1; i < nr_pages; i++) {
> > +   struct page *p = page + i;
> > +
> > +   p->memcg_data = 0;
> > +   }
> > +
> > +   memcg_kmem_uncharge_page(page, PMD_PAGE_ORDER);
> > +}
> > +
> >  static int secretmem_pool_increase(struct secretmem_ctx *ctx, gfp_t gfp)
> >  {
> > unsigned long nr_pages = (1 << PMD_PAGE_ORDER);
> > @@ -61,10 +94,14 @@ static int secretmem_pool_increase(struct secretmem_ctx 
> > *ctx, gfp_t gfp)
> > if (!page)
> > return -ENOMEM;
> >
> > -   err = set_direct_map_invalid_noflush(page, nr_pages);
> > +   err = secretmem_memcg_charge(page, gfp, PMD_PAGE_ORDER);
> > if (err)
> > goto err_cma_release;
> >
> > +   err = set_direct_map_invalid_noflush(page, nr_pages);
> > +   if (err)
> > +   goto err_memcg_uncharge;
> > +
> > addr = (unsigned long)page_address(page);
> > err = gen_pool_add(pool, addr, PMD_SIZE, NUMA_NO_NODE);
> > if (err)
> > @@ -81,6 +118,8 @@ static int secretmem_pool_increase(struct secretmem_ctx 
> > *ctx, gfp_t gfp)
> >  * won't fail
> >  */
> > set_direct_map_default_noflush(page, nr_pages);
> > +err_memcg_uncharge:
> > +   secretmem_memcg_uncharge(page, PMD_PAGE_ORDER);
> >  err_cma_release:
> > cma_release(secretmem_cma, page, nr_pages);
> > return err;
> > @@ -310,6 +349,7 @@ static void secretmem_cleanup_chunk(struct gen_pool 
> > *pool,
> > int i;
> >
> > set_direct_map_default_noflush(page, nr_pages);
> > +   secretmem_memcg_uncharge(page, PMD_PAGE_ORDER);
> >
> > for (i = 0; i < nr_pages; i++)
> > clear_highpage(page + i);
> > --
> > 2.28.0
> >
> >

-- 
Sincerely yours,
Mike.

[PATCH] soc/tegra: fuse: Fix build with Tegra234 configuration

2020-11-15 Thread Wang ShaoBo

If only Tegra234 support is enabled, the tegra30_fuse_read() and
tegra30_fuse_init() function are not declared and cause a build failure.

drivers/soc/tegra/fuse/fuse-tegra30.c:376:10: error: ‘tegra30_fuse_read’
 undeclared here (not in a function); did you mean ‘tegra_fuse_readl’?
  .read = tegra30_fuse_read,
  ^
  tegra_fuse_readl
drivers/soc/tegra/fuse/fuse-tegra30.c:382:10: error: ‘tegra30_fuse_init’
 undeclared here (not in a function); did you mean ‘tegra30_fuse_read’?
  .init = tegra30_fuse_init,
  ^
  tegra30_fuse_read

Fixes: 1f44febf71ba ("soc/tegra: fuse: Add Tegra234 support")
Signed-off-by: Wang ShaoBo 
---
 drivers/soc/tegra/fuse/fuse-tegra30.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/drivers/soc/tegra/fuse/fuse-tegra30.c 
b/drivers/soc/tegra/fuse/fuse-tegra30.c
index 9ea7f0168457..c1aa7815bd6e 100644
--- a/drivers/soc/tegra/fuse/fuse-tegra30.c
+++ b/drivers/soc/tegra/fuse/fuse-tegra30.c
@@ -37,7 +37,8 @@
 defined(CONFIG_ARCH_TEGRA_132_SOC) || \
 defined(CONFIG_ARCH_TEGRA_210_SOC) || \
 defined(CONFIG_ARCH_TEGRA_186_SOC) || \
-defined(CONFIG_ARCH_TEGRA_194_SOC)
+defined(CONFIG_ARCH_TEGRA_194_SOC) || \
+defined(CONFIG_ARCH_TEGRA_234_SOC)
 static u32 tegra30_fuse_read_early(struct tegra_fuse *fuse, unsigned int 
offset)
 {
if (WARN_ON(!fuse->base))
-- 
2.17.1

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

On Fri, Nov 13, 2020 at 05:14:52PM -0800, Andrew Morton wrote:
> On Fri, 13 Nov 2020 18:02:39 +1100 Stephen Rothwell  
> wrote:
> 
> > Hi all,
> > 
> > After merging the akpm tree, today's linux-next build (i386 defconfig)
> > failed like this:
> > 
> > mm/secretmem.c: In function 'secretmem_memcg_charge':
> > mm/secretmem.c:72:4: error: 'struct page' has no member named 'memcg_data'
> >72 |   p->memcg_data = page->memcg_data;
> >   |^~
> > mm/secretmem.c:72:23: error: 'struct page' has no member named 'memcg_data'
> >72 |   p->memcg_data = page->memcg_data;
> >   |   ^~
> > mm/secretmem.c: In function 'secretmem_memcg_uncharge':
> > mm/secretmem.c:86:4: error: 'struct page' has no member named 'memcg_data'
> >86 |   p->memcg_data = 0;
> >   |^~
> > 
> > ...
> >
> > --- a/mm/secretmem.c
> > +++ b/mm/secretmem.c
> > @@ -69,7 +69,9 @@ static int secretmem_memcg_charge(struct page *page, 
> > gfp_t gfp, int order)
> > for (i = 1; i < nr_pages; i++) {
> > struct page *p = page + i;
> >  
> > +#ifdef CONFIG_MEMCG
> > p->memcg_data = page->memcg_data;
> > +#endif
> > }
> >  
> > return 0;
> 
> Thanks, that'll work for now.
> 
> I guess we're looking at adding a set_page_memcg() (I'd prefer
> page_memcg_set()).
> 
> But probably these functions shouldn't be compiled at all if
> CONFIG_MEMCG=n.

My preference would be to put the entire function body in '#ifdef
CONFIG_MEMCG' here.

-- 
Sincerely yours,
Mike.

Re: [PATCH v7 1/2] kunit: Support for Parameterized Testing

2020-11-15 Thread Marco Elver

On Sat, 14 Nov 2020 at 13:38, Arpitha Raghunandan <98.a...@gmail.com> wrote:
> Implementation of support for parameterized testing in KUnit. This
> approach requires the creation of a test case using the
> KUNIT_CASE_PARAM() macro that accepts a generator function as input.
>
> This generator function should return the next parameter given the
> previous parameter in parameterized tests. It also provides a macro to
> generate common-case generators based on arrays. Generators may also
> optionally provide a human-readable description of parameters, which is
> displayed where available.
>
> Note, currently the result of each parameter run is displayed in
> diagnostic lines, and only the overall test case output summarizes
> TAP-compliant success or failure of all parameter runs. In future, when
> supported by kunit-tool, these can be turned into subsubtest outputs.
>
> Signed-off-by: Arpitha Raghunandan <98.a...@gmail.com>
> Co-developed-by: Marco Elver 
> Signed-off-by: Marco Elver 
> ---
> Changes v6->v7:
> - Clarify commit message.
> - Introduce ability to optionally generate descriptions for parameters;
>   if no description is provided, we'll still print 'param-N'.
> - Change diagnostic line format to:
> # :  N - []
>
> Changes v5->v6:
> - Fix alignment to maintain consistency
>
> Changes v4->v5:
> - Update kernel-doc comments.
> - Use const void* for generator return and prev value types.
> - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
> - Rework parameterized test case execution strategy: each parameter is 
> executed
>   as if it was its own test case, with its own test initialization and cleanup
>   (init and exit are called, etc.). However, we cannot add new test cases per 
> TAP
>   protocol once we have already started execution. Instead, log the result of
>   each parameter run as a diagnostic comment.
>
> Changes v3->v4:
> - Rename kunit variables
> - Rename generator function helper macro
> - Add documentation for generator approach
> - Display test case name in case of failure along with param index
>
> Changes v2->v3:
> - Modifictaion of generator macro and method
>
> Changes v1->v2:
> - Use of a generator method to access test case parameters
> Changes v6->v7:
> - Clarify commit message.
> - Introduce ability to optionally generate descriptions for parameters;
>   if no description is provided, we'll still print 'param-N'.
> - Change diagnostic line format to:
> # :  N - []
> - Before execution of parameterized test case, count number of
>   parameters and display number of parameters. Currently also as a
>   diagnostic line, but this may be used in future to generate a subsubtest
>   plan. A requirement of this change is that generators must generate a
>   deterministic number of parameters.
>
> Changes v5->v6:
> - Fix alignment to maintain consistency
>
> Changes v4->v5:
> - Update kernel-doc comments.
> - Use const void* for generator return and prev value types.
> - Add kernel-doc comment for KUNIT_ARRAY_PARAM.
> - Rework parameterized test case execution strategy: each parameter is 
> executed
>   as if it was its own test case, with its own test initialization and cleanup
>   (init and exit are called, etc.). However, we cannot add new test cases per 
> TAP
>   protocol once we have already started execution. Instead, log the result of
>   each parameter run as a diagnostic comment.
>
> Changes v3->v4:
> - Rename kunit variables
> - Rename generator function helper macro
> - Add documentation for generator approach
> - Display test case name in case of failure along with param index
>
> Changes v2->v3:
> - Modifictaion of generator macro and method
>
> Changes v1->v2:
> - Use of a generator method to access test case parameters
>
>  include/kunit/test.h | 51 ++
>  lib/kunit/test.c | 59 ++--
>  2 files changed, 97 insertions(+), 13 deletions(-)
>
> diff --git a/include/kunit/test.h b/include/kunit/test.h
> index db1b0ae666c4..cf5f33b1c890 100644
> --- a/include/kunit/test.h
> +++ b/include/kunit/test.h
> @@ -94,6 +94,9 @@ struct kunit;
>  /* Size of log associated with test. */
>  #define KUNIT_LOG_SIZE 512
>
> +/* Maximum size of parameter description string. */
> +#define KUNIT_PARAM_DESC_SIZE 64

I think we need to make this larger, perhaps 128. I just noticed a few
of the inode-test strings are >64 chars (and it should probably also
use strncpy() to copy to description, which is my bad).

>  /*
>   * TAP specifies subtest stream indentation of 4 spaces, 8 spaces for a
>   * sub-subtest.  See the "Subtests" section in
> @@ -107,6 +110,7 @@ struct kunit;
[...]
> +/**
> + * KUNIT_ARRAY_PARAM() - Define test parameter generator from an array.
> + * @name:  prefix for the test parameter generator function.
> + * @array: array of test parameters.
> + * @get_desc: function to convert param to description; NULL to use default
> + *
> + * Define function @name_gen_params which uses @array to

Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy

2020-11-15 Thread Marek Behún

On Sun, 15 Nov 2020 03:26:01 +0100
Andreas Färber  wrote:

> Hi Russell,
> 
> On 15.11.20 02:02, Russell King - ARM Linux admin wrote:
> > On Sun, Nov 15, 2020 at 01:41:51AM +0100, Andreas Färber wrote:  
> >> Commit 1a642ca7f38992b086101fe204a1ae3c90ed8016 (net: ethernet: mvneta:
> >> Add 2500BaseX support for SoCs without comphy) added support for 2500BaseX.
> >>
> >> In case a comphy is not provided, mvneta_validate()'s check
> >>   state->interface == PHY_INTERFACE_MODE_2500BASEX
> >> could never be true (it would've returned with empty bitmask before),
> >> so that 2500baseT_Full and 2500baseX_Full do net get added to the mask.  
> > 
> > This makes me nervous. It was intentional that if there is no comphy
> > configured in DT for SoCs such as Armada 388, then there is no support
> > to switch between 1G and 2.5G speed. Unfortunately, the configuration
> > of the comphy is up to the board to do, not the SoC .dtsi, so we can't
> > rely on there being a comphy on Armada 388 systems.  
> 
> Please note that the if clause at the beginning of the validate function
> does not check for comphy at all. So even with comphy, if there is a
> code path that attempts to validate state 2500BASEX, it is broken, too.
> 
> Do you consider the modification of both ifs (validate and power_up) as
> correct? Should they be split off from my main _NA change you discuss?
> 
> > So, one of the side effects of this patch is it incorrectly opens up
> > the possibility of allowing 2.5G support on Armada 388 without a comphy
> > configured.
> > 
> > We really need a better way to solve this; just relying on the lack of
> > comphy and poking at a register that has no effect on Armada 388 to
> > select 2.5G speed while allowing 1G and 2.5G to be arbitarily chosen
> > doesn't sound like a good idea to me.  
> [snip]
> 
> May I add that the comphy needs better documentation?
> 
> Marek and I independently came up with < 2> in the end, but the
> DT binding doesn't explain what the index is supposed to be and how I
> might figure it out. It cost me days of reading U-Boot and kernel
> sources and playing around with values until I had the working one.
> 
> Might be helpful to have a symbolic dt-bindings #define for this 2.
> 

The gbe mux number is described in Armada 385 documentation. Yes, maybe
we should add these defines somewhere, but certainly we should not
declare ability of 2500baseX if comphy is not present and the interface
is not configured to 2500baseX by default.

I propose putting this just into the dt binding documentation. No need
for macros IMO, especially since these muxes may be different on each
SOC.

Marek

Re: [PATCH v8 8/9] arch, mm: wire up memfd_secret system call were relevant

On Fri, Nov 13, 2020 at 12:25:08PM +, Catalin Marinas wrote:
> Hi Mike,
> 
> On Tue, Nov 10, 2020 at 05:14:43PM +0200, Mike Rapoport wrote:
> > diff --git a/arch/arm64/include/asm/unistd32.h 
> > b/arch/arm64/include/asm/unistd32.h
> > index 6c1dcca067e0..c71c3fe0b6cd 100644
> > --- a/arch/arm64/include/asm/unistd32.h
> > +++ b/arch/arm64/include/asm/unistd32.h
> > @@ -891,6 +891,8 @@ __SYSCALL(__NR_faccessat2, sys_faccessat2)
> >  __SYSCALL(__NR_process_madvise, sys_process_madvise)
> >  #define __NR_watch_mount 441
> >  __SYSCALL(__NR_watch_mount, sys_watch_mount)
> > +#define __NR_memfd_secret 442
> > +__SYSCALL(__NR_memfd_secret, sys_memfd_secret)
> 
> arch/arm doesn't select ARCH_HAS_SET_DIRECT_MAP and doesn't support
> memfd_secret(), so I wouldn't add it to the compat layer.

Ok, I'll drop it.

> -- 
> Catalin

-- 
Sincerely yours,
Mike.

Re: [PATCH net-next] net: mvneta: Fix validation of 2.5G HSGMII without comphy

2020-11-15 Thread Marek Behún

On Sun, 15 Nov 2020 01:41:51 +0100
Andreas Färber  wrote:

> - if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX) {
> + if (pp->comphy || state->interface == PHY_INTERFACE_MODE_2500BASEX
> +|| state->interface == PHY_INTERFACE_MODE_NA) {
>   phylink_set(mask, 2500baseT_Full);
>   phylink_set(mask, 2500baseX_Full);
>   }

No, this will cause, on systems without comphy described, phylink to
think that 2500baseX/T is possible. But without comphy how can it be
configured?

Marek

Re: [PATCH v8 4/9] mm: introduce memfd_secret system call to create "secret" memory areas

On Fri, Nov 13, 2020 at 02:06:56PM +, Matthew Wilcox wrote:
> On Tue, Nov 10, 2020 at 05:14:39PM +0200, Mike Rapoport wrote:
> > diff --git a/mm/Kconfig b/mm/Kconfig
> > index c89c5444924b..d8d170fa5210 100644
> > --- a/mm/Kconfig
> > +++ b/mm/Kconfig
> > @@ -884,4 +884,7 @@ config ARCH_HAS_HUGEPD
> >  config MAPPING_DIRTY_HELPERS
> >  bool
> >  
> > +config SECRETMEM
> > +   def_bool ARCH_HAS_SET_DIRECT_MAP && !EMBEDDED
> 
> So I now have to build this in, whether I want it or not?

Why wouldn't anybody want this nice feature? ;-)

Now, seriously, I hesitated a lot about having a prompt here, but in the
end I've decided to go without it.

The added footprint is not so big, with x86 defconfig it's less than 8K
and with distro (I've checked with Fedora) config the difference is less
than 1k because they anyway have CMA=y.

As this is "security" feature, disros most probably would have this
enabled anyway, and I believe users that will see something like "Allow
hiding memory from the kernel" will hit Y there.

-- 
Sincerely yours,
Mike.

Re: [PATCH v8 4/9] mm: introduce memfd_secret system call to create "secret" memory areas

On Fri, Nov 13, 2020 at 01:58:48PM +, Matthew Wilcox wrote:
> On Tue, Nov 10, 2020 at 05:14:39PM +0200, Mike Rapoport wrote:
> > +static vm_fault_t secretmem_fault(struct vm_fault *vmf)
> > +{
> > +   struct address_space *mapping = vmf->vma->vm_file->f_mapping;
> > +   struct inode *inode = file_inode(vmf->vma->vm_file);
> > +   pgoff_t offset = vmf->pgoff;
> > +   unsigned long addr;
> > +   struct page *page;
> > +   int ret = 0;
> > +
> > +   if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode))
> > +   return vmf_error(-EINVAL);
> > +
> > +   page = find_get_entry(mapping, offset);
> 
> Why did you decide to use find_get_entry() here?  You don't handle
> swap or shadow entries.

Right, I've missed that. 

> > +   if (!page) {
> > +   page = secretmem_alloc_page(vmf->gfp_mask);
> > +   if (!page)
> > +   return vmf_error(-EINVAL);
> 
> Why is this EINVAL and not ENOMEM?

Ah, I was annoyed by OOMs I got when I simulated various allocation
failures, so I changed it to get SIGBUS instead and than forgot to restore.
Will fix.

> > +   ret = add_to_page_cache(page, mapping, offset, vmf->gfp_mask);
> > +   if (unlikely(ret))
> > +   goto err_put_page;
> > +
> > +   ret = set_direct_map_invalid_noflush(page, 1);
> > +   if (ret)
> > +   goto err_del_page_cache;
> > +
> > +   addr = (unsigned long)page_address(page);
> > +   flush_tlb_kernel_range(addr, addr + PAGE_SIZE);
> > +
> > +   __SetPageUptodate(page);
> > +
> > +   ret = VM_FAULT_LOCKED;
> > +   }
> > +
> > +   vmf->page = page;
> > +   return ret;
> 
> Does sparse not warn you about this abuse of vm_fault_t?  Separate out
> 'ret' and 'err'.
 
Will fix.

> Andrew, please fold in this fix.  I suspect Mike will want to fix
> the other things I mention above.
> 
> diff --git a/mm/secretmem.c b/mm/secretmem.c
> index 3dfdbd85ba00..09ca27f21661 100644
> --- a/mm/secretmem.c
> +++ b/mm/secretmem.c
> @@ -172,7 +172,7 @@ static vm_fault_t secretmem_fault(struct vm_fault *vmf)
>   if (((loff_t)vmf->pgoff << PAGE_SHIFT) >= i_size_read(inode))
>   return vmf_error(-EINVAL);
>  
> - page = find_get_entry(mapping, offset);
> + page = find_get_page(mapping, offset);
>   if (!page) {
>   page = secretmem_alloc_page(ctx, vmf->gfp_mask);
>   if (!page)

-- 
Sincerely yours,
Mike.

Re: [RFC PATCH v3 9/9] ipu3-cio2: Add functionality allowing software_node connections to sensors on platforms designed for Windows

2020-11-15 Thread Daniel Scally

On 13/11/2020 19:45, Andy Shevchenko wrote:
> On Fri, Nov 13, 2020 at 6:22 PM Laurent Pinchart
>  wrote:
>> On Fri, Nov 13, 2020 at 10:02:30AM +, Dan Scally wrote:
>>> On 29/10/2020 22:51, Laurent Pinchart wrote:
 On Fri, Oct 30, 2020 at 12:22:15AM +0200, Andy Shevchenko wrote:
> On Thu, Oct 29, 2020 at 11:29:30PM +0200, Laurent Pinchart wrote:
> ...
>
> In this case we probably need something like
>
> struct acpi_device *
> acpi_dev_get_next_match_dev(struct acpi_device *adev,
>const char *hid, const char *uid, s64 hrv)
> {
>struct device *start = adev ? >dev : NULL;
>...
>dev = bus_find_device(_bus_type, start, , 
> acpi_dev_match_cb);
>...
> }
>
> in drivers/acpi/utils.c and
>
> static inline struct acpi_device *
> acpi_dev_get_first_match_dev(const char *hid, const char *uid, s64 hrv)
> {
>return acpi_dev_get_next_match_dev(NULL, hid, uid, hrv);
> }
>
> in include/linux/acpi.h.
>
> Then we may add
>
> #define for_each_acpi_dev_match(adev, hid, uid, hrv)  
>  \
>for (adev = acpi_dev_get_first_match_dev(hid, uid, hrv);\
> adev;  \
> adev = acpi_dev_get_next_match_dev(adev, hid, uid, hrv))
 What the cio2-bridge code needs is indeed

 for each hid in supported hids:
 for each acpi device that is compatible with hid:
 ...

 which could also be expressed as

 for each acpi device:
 if acpi device hid is in supported hids:
 ...

 I don't mind either option, I'll happily follow the preference of the
 ACPI maintainers.
>>> Does this need raising elsewhere then? The original idea of just
>>> bus_for_each_dev(_bus_type...) I have now tested and it works fine,
>>> but it does mean that I need to export acpi_bus_type (currently that
>>> symbol's not available)...that seems much simpler to me but I'm not sure
>>> whether that's something to avoid, and if so whether Andy's approach is
>>> better.
>>>
>>> Thoughts?
>> I like simple options :-) A patch to export acpi_bus_type, with enough
>> context in the commit message (and in the cover latter of the series),
>> should be enough to provide all the information the ACPI maintainers
>> need to decide which option is best. With a bit of luck that patch will
>> be considered the best option and no extra work will be needed.
> The problem with ACPI bus is that it is not as simple as other buses,
> i.e. it may have purely ACPI devices along with *companion* devices,
> which are usually represented by platform bus. On top of that for
> several ACPI devices there can be one physical node and it will be not
> so clear what you are exactly looking for by traversing acpi_bus_type.
> I believe it's hidden on purpose.
Alright - I followed your suggestion to implement the iterator instead
then and left acpi_bus_type hidden, thanks.

mtk_scp_ipi.c:undefined reference to `__iowrite32_copy'

tree:   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git 
master
head:   e28c0d7c92c89016c12a677616668957351e7542
commit: cbd2dca74926c0e4610c40923cc786b732c9e8ef remoteproc: scp: add 
COMPILE_TEST dependency
date:   7 weeks ago
config: s390-randconfig-p002-20201115 (attached as .config)
compiler: s390-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
# 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=cbd2dca74926c0e4610c40923cc786b732c9e8ef
git remote add linus 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git
git fetch --no-tags linus master
git checkout cbd2dca74926c0e4610c40923cc786b732c9e8ef
# save the attached .config to linux build tree
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-9.3.0 make.cross 
ARCH=s390 

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

All errors (new ones prefixed by >>):

   s390-linux-ld: drivers/reset/reset-axs10x.o: in function 
`axs10x_reset_probe':
   reset-axs10x.c:(.text+0x54): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-lpc18xx.o: in function 
`lpc18xx_rgu_probe':
   reset-lpc18xx.c:(.text+0x3aa): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-meson.o: in function `meson_reset_probe':
   reset-meson.c:(.text+0xcc): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-meson-audio-arb.o: in function 
`meson_audio_arb_probe':
   reset-meson-audio-arb.c:(.text+0x204): undefined reference to 
`devm_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-npcm.o: in function `npcm_rc_probe':
   reset-npcm.c:(.text+0x41a): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-simple.o: in function 
`reset_simple_probe':
   reset-simple.c:(.text+0xf6): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/reset/reset-sunxi.o: in function `sun6i_reset_init':
   reset-sunxi.c:(.init.text+0xe0): undefined reference to 
`of_address_to_resource'
   s390-linux-ld: reset-sunxi.c:(.init.text+0x13a): undefined reference to 
`ioremap'
   s390-linux-ld: drivers/reset/reset-uniphier-glue.o: in function 
`uniphier_glue_reset_probe':
   reset-uniphier-glue.c:(.text+0x1e0): undefined reference to 
`devm_ioremap_resource'
   s390-linux-ld: drivers/char/hw_random/exynos-trng.o: in function 
`exynos_trng_probe':
   exynos-trng.c:(.text+0x390): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/char/hw_random/meson-rng.o: in function 
`meson_rng_probe':
   meson-rng.c:(.text+0xea): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/mfd/syscon.o: in function `syscon_probe':
   syscon.c:(.text+0x11e): undefined reference to `devm_ioremap'
   s390-linux-ld: drivers/mfd/syscon.o: in function `of_syscon_register':
   syscon.c:(.text+0x364): undefined reference to `of_address_to_resource'
   s390-linux-ld: syscon.c:(.text+0x3c6): undefined reference to `ioremap'
   s390-linux-ld: syscon.c:(.text+0x5d2): undefined reference to `iounmap'
   s390-linux-ld: drivers/input/serio/olpc_apsp.o: in function 
`olpc_apsp_probe':
   olpc_apsp.c:(.text+0x550): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/media/cec/platform/meson/ao-cec.o: in function 
`meson_ao_cec_probe':
   ao-cec.c:(.text+0x1fc): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/media/cec/platform/sti/stih-cec.o: in function 
`stih_cec_probe':
   stih-cec.c:(.text+0x4e0): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/power/reset/ocelot-reset.o: in function 
`ocelot_reset_probe':
   ocelot-reset.c:(.text+0x12c): undefined reference to `devm_ioremap_resource'
   s390-linux-ld: drivers/thermal/broadcom/brcmstb_thermal.o: in function 
`brcmstb_thermal_probe':
   brcmstb_thermal.c:(.text+0x1da): undefined reference to 
`devm_ioremap_resource'
   s390-linux-ld: drivers/watchdog/asm9260_wdt.o: in function 
`asm9260_wdt_probe':
   asm9260_wdt.c:(.text+0x5ac): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/watchdog/at91sam9_wdt.o: in function `at91wdt_probe':
   at91sam9_wdt.c:(.init.text+0x1a8): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/watchdog/sama5d4_wdt.o: in function 
`sama5d4_wdt_probe':
   sama5d4_wdt.c:(.text+0x734): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/watchdog/ep93xx_wdt.o: in function `ep93xx_wdt_probe':
   ep93xx_wdt.c:(.text+0x17a): undefined reference to 
`devm_platform_ioremap_resource'
   s390-linux-ld: drivers/watchdog/npcm_wdt.o: in function `npcm_wdt_probe':
   npcm_wdt.c:(.text+0x3ea): und

Re: [PATCH] mfd: cpcap: Fix interrupt regression with regmap clear_ack

2020-11-15 Thread Tony Lindgren

* Tim Harvey  [201113 22:07]:
> 3a6f0fb7b8eb ("regmap: irq: Add support to clear ack registers")
> appears to not only add the new clear_ack case it also attempts to
> resolve the long standing ack_invert issue with this change:
> 
> - ret = regmap_write(map, reg, data->status_buf[i]);
> + if (chip->ack_invert)
> +  ret = regmap_write(map, reg,
> +  ~data->status_buf[i]);
> + else
> + ret = regmap_write(map, reg,
> + data->status_buf[i]);

Yes that's what I noticed too. And that's why cpcap was working for
me with ack_invert and without it earlier.

> However, this still doesn't resolve the issue I have with my
> device/driver because it ends up writing 1's to all the other bits in
> the ack register which keeps my device's interrupt from de-asserting.
> Perhaps that's a strange behavior of my device that it allows you to
> 'set' interrupt source bits which causes the interrupt to stay
> asserted? I'm also wondering if my issue is that I currently have the
> interrupt registered as such:
> 
> ret = devm_regmap_add_irq_chip(dev, gsc->regmap, client->irq,
> IRQF_ONESHOT | IRQF_SHARED | IRQF_TRIGGER_FALLING, 0, _irq_chip,
> _data);
> 
> Perhaps this should be IRQF_TRIGGER_LOW as the device will not
> de-assert its IRQ# until all source bits are cleared.

Yes could be. For cpcap, we have IRQ_TYPE_LEVEL_HIGH configured in the
motorola-cpcap-mapphone.dtsi file.

> Tony, I thought that your pcap issue was that it truly did not have an
> inverted ack and the fact that ack_invert did not work was why you
> never noticed any issue. If this is true I would think you would want
> to disable ack_invert but not necessarily enable clear_ack. Did your
> testing show it needed to toggle the ack to clear it?

Well I looked at the v3.0.8 Motorola Linux Android kernel, it actually
does clear_ack. So I'd rather keep the same logic as we have no proper
documentation for cpcap. I also confirmed still works without ack_invert
too while ack_invert now is broken. But using clear_ack now that we
have it working seems safer.

Regards,

Tony

INFO: task can't die in io_sq_thread_stop

2020-11-15 Thread syzbot

Hello,

syzbot found the following issue on:

HEAD commit:6dd65e60 Add linux-next specific files for 20201110
git tree:   linux-next
console output: https://syzkaller.appspot.com/x/log.txt?x=14727d4250
kernel config:  https://syzkaller.appspot.com/x/.config?x=4fab43daf5c54712
dashboard link: https://syzkaller.appspot.com/bug?extid=03beeb595f074db9cfd1
compiler:   gcc (GCC) 10.1.0-syz 20200507

Unfortunately, I don't have any reproducer for this issue yet.

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

INFO: task syz-executor.2:12399 can't die for more than 143 seconds.
task:syz-executor.2  state:D stack:28744 pid:12399 ppid:  8504 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3773 [inline]
 __schedule+0x893/0x2170 kernel/sched/core.c:4522
 schedule+0xcf/0x270 kernel/sched/core.c:4600
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1847
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
 kthread_stop+0x17a/0x720 kernel/kthread.c:596
 io_put_sq_data fs/io_uring.c:7193 [inline]
 io_sq_thread_stop+0x452/0x570 fs/io_uring.c:7290
 io_finish_async fs/io_uring.c:7297 [inline]
 io_sq_offload_create fs/io_uring.c:8015 [inline]
 io_uring_create fs/io_uring.c:9433 [inline]
 io_uring_setup+0x19b7/0x3730 fs/io_uring.c:9507
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45deb9
Code: Unable to access opcode bytes at RIP 0x45de8f.
RSP: 002b:7f174e51ac78 EFLAGS: 0246 ORIG_RAX: 01a9
RAX: ffda RBX: 8640 RCX: 0045deb9
RDX:  RSI: 2140 RDI: 50e5
RBP: 0118bf58 R08:  R09: 
R10:  R11: 0246 R12: 0118bf2c
R13: 7ffed9ca723f R14: 7f174e51b9c0 R15: 0118bf2c
INFO: task syz-executor.2:12399 blocked for more than 143 seconds.
  Not tainted 5.10.0-rc3-next-20201110-syzkaller #0
"echo 0 > /proc/sys/kernel/hung_task_timeout_secs" disables this message.
task:syz-executor.2  state:D stack:28744 pid:12399 ppid:  8504 flags:0x4004
Call Trace:
 context_switch kernel/sched/core.c:3773 [inline]
 __schedule+0x893/0x2170 kernel/sched/core.c:4522
 schedule+0xcf/0x270 kernel/sched/core.c:4600
 schedule_timeout+0x1d8/0x250 kernel/time/timer.c:1847
 do_wait_for_common kernel/sched/completion.c:85 [inline]
 __wait_for_common kernel/sched/completion.c:106 [inline]
 wait_for_common kernel/sched/completion.c:117 [inline]
 wait_for_completion+0x163/0x260 kernel/sched/completion.c:138
 kthread_stop+0x17a/0x720 kernel/kthread.c:596
 io_put_sq_data fs/io_uring.c:7193 [inline]
 io_sq_thread_stop+0x452/0x570 fs/io_uring.c:7290
 io_finish_async fs/io_uring.c:7297 [inline]
 io_sq_offload_create fs/io_uring.c:8015 [inline]
 io_uring_create fs/io_uring.c:9433 [inline]
 io_uring_setup+0x19b7/0x3730 fs/io_uring.c:9507
 do_syscall_64+0x2d/0x70 arch/x86/entry/common.c:46
 entry_SYSCALL_64_after_hwframe+0x44/0xa9
RIP: 0033:0x45deb9
Code: Unable to access opcode bytes at RIP 0x45de8f.
RSP: 002b:7f174e51ac78 EFLAGS: 0246 ORIG_RAX: 01a9
RAX: ffda RBX: 8640 RCX: 0045deb9
RDX:  RSI: 2140 RDI: 50e5
RBP: 0118bf58 R08:  R09: 
R10:  R11: 0246 R12: 0118bf2c
R13: 7ffed9ca723f R14: 7f174e51b9c0 R15: 0118bf2c

Showing all locks held in the system:
1 lock held by khungtaskd/1653:
 #0: 8b3386a0 (rcu_read_lock){}-{1:2}, at: 
debug_show_all_locks+0x53/0x260 kernel/locking/lockdep.c:6253
1 lock held by systemd-journal/4873:
1 lock held by in:imklog/8167:
 #0: 88801c86e0f0 (>f_pos_lock){+.+.}-{3:3}, at: __fdget_pos+0xe9/0x100 
fs/file.c:932

=

NMI backtrace for cpu 1
CPU: 1 PID: 1653 Comm: khungtaskd Not tainted 
5.10.0-rc3-next-20201110-syzkaller #0
Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 
01/01/2011
Call Trace:
 __dump_stack lib/dump_stack.c:77 [inline]
 dump_stack+0x107/0x163 lib/dump_stack.c:118
 nmi_cpu_backtrace.cold+0x44/0xd7 lib/nmi_backtrace.c:105
 nmi_trigger_cpumask_backtrace+0x1b3/0x230 lib/nmi_backtrace.c:62
 trigger_all_cpu_backtrace include/linux/nmi.h:147 [inline]
 check_hung_uninterruptible_tasks kernel/hung_task.c:253 [inline]
 watchdog+0xd89/0xf30 kernel/hung_task.c:338
 kthread+0x3af/0x4a0 kernel/kthread.c:292
 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:296
Sending NMI from CPU 1 to CPUs 0:
NMI backtrace for cpu 0
CPU: 0 PID: 5 Comm: kworker/0:0 Not tainted 5.10.0-rc3-next-20201110-syzkaller 
#0
Hardware name: Google Google

Re: v5.10-rc3 vs. Droid 4

2020-11-15 Thread Tony Lindgren

* Pavel Machek  [201114 20:59]:
> Hi!
> 
> Does anyone have Droid 4 working with 5.10-rc3?
> 
> I tried it with the original config; I got message about culomb
> counter calibration done scrolling (and boot progressing very slowly
> or not at all) . So ... I disabled cpcap battery & charger
> support. But init still drops me to emergency shell.
> 
> I may try some more, but if someone know what is going on, let me
> know.

I ran into this too, sorry I thought I added you to Cc but looks like not.
See the fix here:

https://lore.kernel.org/lkml/2020170613.46057-1-t...@atomide.com/

Regards,

Tony

Re: [PATCH v8 2/9] mmap: make mlock_future_check() global