Re: [bug report] powerpc/perf: Add nest IMC PMU support

[Anju T Sudhakar]

Hi Dan Carpenter,


On Wednesday 31 January 2018 08:55 PM, Dan Carpenter wrote:

Hello Anju T Sudhakar,

The patch 885dcd709ba9: "powerpc/perf: Add nest IMC PMU support" from
Jul 19, 2017, leads to the following static checker warning:

arch/powerpc/perf/imc-pmu.c:1393 init_imc_pmu()
warn: 'pmu_ptr' was already freed.

arch/powerpc/perf/imc-pmu.c
   1317  int init_imc_pmu(struct device_node *parent, struct imc_pmu *pmu_ptr, 
int pmu_idx)
   1318  {
   1319  int ret;
   1320
   1321  ret = imc_mem_init(pmu_ptr, parent, pmu_idx);
   1322  if (ret) {
   1323  imc_common_mem_free(pmu_ptr);
   1324  return ret;
   1325  }

Change this to:

if (ret)
goto err_free_mpu_ptr;

Or something instead of a direct return.  That's more normal kernel
style.

   1326
   1327  switch (pmu_ptr->domain) {
   1328  case IMC_DOMAIN_NEST:
   1329  /*
   1330  * Nest imc pmu need only one cpu per chip, we 
initialize the
   1331  * cpumask for the first nest imc pmu and use the same 
for the
   1332  * rest. To handle the cpuhotplug callback unregister, 
we track
   1333  * the number of nest pmus in "nest_pmus".
   1334  */
   1335  mutex_lock(_init_lock);
   1336  if (nest_pmus == 0) {
   1337  ret = init_nest_pmu_ref();
   1338  if (ret) {
   1339  mutex_unlock(_init_lock);
   1340  goto err_free;
   1341  }
   1342  /* Register for cpu hotplug notification. */
   1343  ret = nest_pmu_cpumask_init();
   1344  if (ret) {
   1345  mutex_unlock(_init_lock);
   1346  kfree(nest_imc_refc);
   1347  kfree(per_nest_pmu_arr);
   1348  goto err_free;
   1349  }
   1350  }
   1351  nest_pmus++;
   1352  mutex_unlock(_init_lock);
   1353  break;
   1354  case IMC_DOMAIN_CORE:
   1355  ret = core_imc_pmu_cpumask_init();
   1356  if (ret) {
   1357  cleanup_all_core_imc_memory();
   1358  return ret;

These direct returns don't look correct...

   1359  }
   1360
   1361  break;
   1362  case IMC_DOMAIN_THREAD:
   1363  ret = thread_imc_cpu_init();
   1364  if (ret) {
   1365  cleanup_all_thread_imc_memory();
   1366  return ret;
   1367  }
   1368
   1369  break;
   1370  default:
   1371  return  -1; /* Unknown domain */

This one certainly looks like a memory leak.  Plus -1 is -EPERM which is
probably not the correct error code.


   1372  }
   1373
   1374  ret = update_events_in_group(parent, pmu_ptr);
   1375  if (ret)
   1376  goto err_free;
   1377
   1378  ret = update_pmu_ops(pmu_ptr);
   1379  if (ret)
   1380  goto err_free;
   1381
   1382  ret = perf_pmu_register(_ptr->pmu, pmu_ptr->pmu.name, -1);
   1383  if (ret)
   1384  goto err_free;
   1385
   1386  pr_info("%s performance monitor hardware support registered\n",
   1387  
pmu_ptr->pmu.name);
   1388
   1389  return 0;
   1390
   1391  err_free:
   1392  imc_common_mem_free(pmu_ptr);
   1393  imc_common_cpuhp_mem_free(pmu_ptr);
   ^^^
This is a use after free, it should be in the reverse order.

err_free_cpuhp:
imc_common_cpuhp_mem_free(pmu_ptr);
err_free_pmu_ptr:
imc_common_mem_free(pmu_ptr);

   1394  return ret;
   1395  }

regards,
dan carpenter




Apologies for the delayed response, I just got back from vacation.

Thank you for pointing out this, I will rework the code and send.


Regards,
Anju

[PATCH kernel] powerpc/pci: Fix broken INTx configuration via OF

[Alexey Kardashevskiy]

Commit 59f47eff03a0 ("powerpc/pci: Use of_irq_parse_and_map_pci() helper")
correctly states that of_irq_parse_and_map_pci() does the same thing as
of_irq_parse_pci() does as it simply calls
of_irq_parse_pci() and irq_create_of_mapping().

However of_irq_parse_and_map_pci() not only returns 0 for success and
negative value for an error but also a positive virq value from
irq_create_of_mapping() which the mentioned commit ignores and
INTx config fails.

This fixes the of_irq_parse_and_map_pci() return value handling.

Fixes: 59f47eff03a0 "powerpc/pci: Use of_irq_parse_and_map_pci() helper"
Signed-off-by: Alexey Kardashevskiy 
---

Found it on POWER9 + powernv system - almost all devices suddenly lost
INTx support.
---
 arch/powerpc/kernel/pci-common.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/powerpc/kernel/pci-common.c b/arch/powerpc/kernel/pci-common.c
index ae2ede4..acbb44f2 100644
--- a/arch/powerpc/kernel/pci-common.c
+++ b/arch/powerpc/kernel/pci-common.c
@@ -370,7 +370,8 @@ static int pci_read_irq_line(struct pci_dev *pci_dev)
memset(, 0xff, sizeof(oirq));
 #endif
/* Try to get a mapping from the device-tree */
-   if (!of_irq_parse_and_map_pci(pci_dev, 0, 0)) {
+   virq = of_irq_parse_and_map_pci(pci_dev, 0, 0);
+   if (virq <= 0) {
u8 line, pin;
 
/* If that fails, lets fallback to what is in the config
-- 
2.11.0

Re: DPAA Ethernet traffice troubles with Linux kernel

[Christian Zigotzky]

Hi Andrew,

How can we fix the buffer problem?

Thanks,
Christian


On 7. Feb 2018, at 22:17, Andrew Lunn  wrote:

On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
Hi,

I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..

——

This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.

Fix the buffer problem, and ARP will likely work properly.

   Andrew

Re: DPAA Ethernet traffice troubles with Linux kernel

[mad skateman]

Hi,

I just found out that something goes wrong within the ARP table (well thats
what i think). I hope someone has a clue..

When i bootup the AmigaOne X5000 with the Ethernet cable connected, it just
never senses the presence of the UTP cable.
I must run the following command as root: mii-tool -R eth0 ... it Resets
the transceiver and the ethernet connection is ready to go.
But then... it randomly dies

After some digging i found that in a working situation the ARP table is
filled with the correct info. Router address, and corresponding MAC, C mask
and Interface.

(Working)
skateman@X5000LNX:~$ arp -n
Address  HWtype  HWaddress   Flags Mask
Iface
192.168.22.66ether   08:5b:0e:fd:db:6a   C
eth0

No more traffic..it just suddenly dies...
skateman@X5000LNX:~$ ping www.google.com
ping: unknown host www.google.com

Rechecked the ARP... and found out it has lost the necessary info.
skateman@X5000LNX:~$ arp -n
Address  HWtype  HWaddress   Flags Mask
Iface
192.168.22.66(incomplete)
eth0

Anyone??? :-)


On Tue, Feb 6, 2018 at 12:20 PM, Christian Zigotzky 
wrote:

> Hello,
>
> I have tried to figure out why there is a problem with the buffer space
> but unfortunately without any success. Any ideas? Could you please watch
> Skateman's video? [1]
>
> Thanks,
> Christian
>
> [1] https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
>
>
> On 03 February 2018 at 12:54PM, mad skateman wrote:
> >
> > For those interested... i have recorded a video of my X5000 DPAA
> Ethernet, and the weird problems..
> > In this Video i am also transfering hundereds of megabytes from my NAS
> to the X5000.
> > You will also see pings die... mostly after the 12th packet and giving
> the no buffer space error..
> > Hopefully someone might have a clue about what is happening.
> >
> > https://drive.google.com/file/d/18RhksfcavRJPr86asQDTzrmsN20D0Xim/view
> >
> > On Wed, Jan 17, 2018 at 3:43 PM, Madalin-cristian Bucur <
> madalin.bu...@nxp.com> wrote:
> >
> > > -Original Message-
> > > From: Madalin-cristian Bucur
> > > Sent: Wednesday, January 17, 2018 4:25 PM
> > > To: David S . Miller 
> > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > madskate...@gmail.com; 'Madalin-cristian Bucur' <
> madalin.bu...@nxp.com>;
> > > Andrew Lunn ; Joakim Tjernlund
> > > 
> > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > >
> > > > -Original Message-
> > > > From: netdev-ow...@vger.kernel.org [mailto:
> netdev-ow...@vger.kernel.org]
> > > > On Behalf Of Madalin-cristian Bucur
> > > > Sent: Wednesday, January 17, 2018 4:16 PM
> > > > To: Andrew Lunn ; Joakim Tjernlund
> > > > 
> > > > Cc: linuxppc-dev@lists.ozlabs.org; net...@vger.kernel.org;
> > > > madskate...@gmail.com; David S . Miller 
> > > > Subject: RE: DPAA Ethernet traffice troubles with Linux kernel
> > > >
> > > > > -Original Message-
> > > > > From: Andrew Lunn [mailto:and...@lunn.ch]
> > > > > Sent: Wednesday, January 17, 2018 3:44 PM
> > > > > To: Joakim Tjernlund 
> > > > > Subject: Re: DPAA Ethernet traffice troubles with Linux kernel
> > > > >
> > > > > > That doesn't work really, having users to hit the bug, debug
> it, fix
> > > > it
> > > > > and then
> > > > > > find it fixed already in upstream, then specifically request
> it to
> > > be
> > > > > backported to stable.
> > > > > > I don't need this fix to be backported, already got it.
> Someone else
> > > > > might though.
> > > > >
> > > > > The "someone else might though" is a big point of asking for
> it to
> > > > > added to stable. The other reason is it means one less patch
> you need
> > > > > to maintain in your build.
> > > >
> > > > I've sent that patch [1] for net but I guess the timing was
> wrong and
> > > > it was merged to net-next.
> > > >
> > > > > > I would be interested in bug fixes upstream which fixes:
> > > > >
> > > > > Did you try upstream? Does it give the same errors?
> > > > >
> > > > > Andrew
> > > >
> > > > [1] https://patchwork.kernel.org/patch/10146119/
> > > >
> > > > Madalin
> > >
> > > Hi Dave,
> > >
> > > Can you please add the fix [1] to stable?
> > >
> > > Thank you,
> > > Madalin
> >
> > Sorry,
> >
> > I've provided the wrong link towards the patch (v1 instead of v3),
> > here's the correct one:
> >
> > https://patchwork.kernel.org/patch/10151969/
> >
> > Madalin
> >
> >
>
>
>

[RFC] powerpc/kernel: Add 'ibm,thread-groups' property for CPU allocation

[Michael Bringmann]

[Withdraw/replace previous version submission.  Awaiting hardware
for further migration tests.  Request comments about current state.]

Add code to parse the new property 'ibm,thread-groups" when it is
present.  The content of this property explicitly defines the number
of threads per core as well as the PowerPC 'threads_core_mask'.
The design provides a common device-tree for both P9 normal core and
P9 fused core systems.  The new property has been observed to be
available on P9 pHyp systems, but it may not be present on OpenPower
BMC systems.

The property updates the kernel to know which CPUs/threads of each
core are actually present, and then use the map when adding cores
to the system at boot, or during hotplug operations.

* Previously, the information about the number of threads per core
  was inferred solely from the "ibm,ppc-interrupt-server#s" property
  in the system device tree.
* Also previous to this property, The mask of threads per CPU was
  inferred to be a strict linear series from 0..(nthreads-1).
* There may be a different thread group mask for each core in the
  system.
* Also after reading the property, we can determine which of the
  possible threads we are allowed to online for each CPU.  It is no
  longer a simple linear sequence, but may be discontinuous e.g.
  activate threads 1,2,3,5,6,7 on a core instead of 0-5 sequentially.

In the event of LPAR migration, we also provide a hook to re-process
the property in the event that it is changed.  Rules about fused-core
and split-core migration are outside the scope of this change, however.
We update the 'ppc_thread_group_mask' for subsequent use by DLPAR
operations.  It is the responsibility of the user to put the source
system into SMT4 mode when moving from a fused-core to split-core
target.

Implementation of the "ibm,thread-groups" property is spread across
a few files in the powerpc specific code:

* prom.c: Parse the property and create 'ppc_thread_group_mask'.
  Use the mask in operation of early_init_dt_scan_cpus().
* setup-common.c: Parse the property, create 'ppc_thread_group_mask',
  and use the value in cpu_init_thread_core_maps(), and
  smp_setup_cpu_maps.
* hotplug-cpu.c: Use 'ppc_thread_group_mask' in several locations
  where the code previously expected to iterate over a
  linear series of active threads (0..nthreads-1).
* mobility.c: Look for and process changes to the thread group mask
  in the context of post migration topology changes

Note that the "ibm,thread-groups" property also includes semantics
of 'thread-group' i.e. define one or more subgroups of the available
threads, each group of threads to be used for a specific class of
task.  Translating thread group semantics into Linux kernel features
is TBD.

Signed-off-by: Michael Bringmann 
---
Changes in V3:
  -- Update patch description regarding latest changes.
  -- Move parsing of new property to 'setup-common.c' in new function
 'process_thread_group_masks'.
  -- Ensure that code is able to handle unique thread group masks
 for different cpus.
  -- Add post migration topology check for 'ibm,thread-groups' using
 new function process_thread_group_mask when appropriate.
  -- Tune use of ppc_thread_group_mask during DLPAR operations.
 Use new function process_thread_group_mask when appropriate.
  -- Add some more description of property semantics/operation in
 the case of LPAR migration.
---
 arch/powerpc/include/asm/cputhreads.h|6 +
 arch/powerpc/kernel/setup-common.c   |  136 --
 arch/powerpc/platforms/pseries/hotplug-cpu.c |   14 ++-
 arch/powerpc/platforms/pseries/mobility.c|6 +
 4 files changed, 150 insertions(+), 12 deletions(-)

diff --git a/arch/powerpc/include/asm/cputhreads.h 
b/arch/powerpc/include/asm/cputhreads.h
index d71a909..df6ade9 100644
--- a/arch/powerpc/include/asm/cputhreads.h
+++ b/arch/powerpc/include/asm/cputhreads.h
@@ -31,6 +31,12 @@
 #define threads_core_mask  (*get_cpu_mask(0))
 #endif
 
+extern cpumask_t ppc_thread_group_mask;
+
+extern int process_thread_group_mask(struct device_node *dn,
+   const __be32 *prop, int prop_len);
+
+
 /* cpu_thread_mask_to_cores - Return a cpumask of one per cores
  *hit by the argument
  *
diff --git a/arch/powerpc/kernel/setup-common.c 
b/arch/powerpc/kernel/setup-common.c
index 8fd3a70..1102d12 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -416,13 +416,18 @@ void __init check_for_initrd(void)
 EXPORT_SYMBOL_GPL(threads_shift);
 EXPORT_SYMBOL_GPL(threads_core_mask);
 
-static void __init cpu_init_thread_core_maps(int tpc)
+cpumask_t ppc_thread_group_mask;
+EXPORT_SYMBOL_GPL(ppc_thread_group_mask);
+
+static void __init cpu_init_thread_core_maps(int tpc,
+   cpumask_t *thread_group_mask)
 {
int i;
 

[RFC] powerpc/hotplug/drcinfo: Fix bugs parsing ibm,drc-info structs

[Michael Bringmann]

[Replace/withdraw previous patch submission to ensure that testing
of related patches on similar hardware progresses together.
Request comments about current state.]

This patch fixes a memory parsing bug when using of_prop_next_u32
calls at the start of a structure.  Depending upon the value of
"cur" memory pointer argument to of_prop_next_u32, it will or it
won't advance the value of the returned memory pointer by the
size of one u32.  This patch corrects the code to deal with that
indexing feature when parsing the ibm,drc-info structs for CPUs.
Also, need to advance the pointer at the end of_read_drc_info_cell
for same reason.

Signed-off-by: Michael Bringmann 
Fixes: 3f38000eda48 ("powerpc/firmware: Add definitions for new drc-info 
firmware feature" -- end of patch series applied to powerpc next)
---
 arch/powerpc/platforms/pseries/of_helpers.c |4 +---
 arch/powerpc/platforms/pseries/pseries_energy.c |2 ++
 drivers/pci/hotplug/rpaphp_core.c   |1 +
 3 files changed, 4 insertions(+), 3 deletions(-)

diff --git a/arch/powerpc/platforms/pseries/of_helpers.c 
b/arch/powerpc/platforms/pseries/of_helpers.c
index 6df192f..17b5938 100644
--- a/arch/powerpc/platforms/pseries/of_helpers.c
+++ b/arch/powerpc/platforms/pseries/of_helpers.c
@@ -65,9 +65,7 @@ int of_read_drc_info_cell(struct property **prop, const 
__be32 **curval,
 
/* Get drc-index-start:encode-int */
p2 = (const __be32 *)p;
-   p2 = of_prop_next_u32(*prop, p2, >drc_index_start);
-   if (!p2)
-   return -EINVAL;
+   data->drc_index_start = of_read_number(p2, 1);
 
/* Get drc-name-suffix-start:encode-int */
p2 = of_prop_next_u32(*prop, p2, >drc_name_suffix_start);
diff --git a/arch/powerpc/platforms/pseries/pseries_energy.c 
b/arch/powerpc/platforms/pseries/pseries_energy.c
index 6ed2212..c7d84aa 100644
--- a/arch/powerpc/platforms/pseries/pseries_energy.c
+++ b/arch/powerpc/platforms/pseries/pseries_energy.c
@@ -64,6 +64,7 @@ static u32 cpu_to_drc_index(int cpu)
value = of_prop_next_u32(info, NULL, _set_entries);
if (!value)
goto err_of_node_put;
+   value++;
 
for (j = 0; j < num_set_entries; j++) {
 
@@ -126,6 +127,7 @@ static int drc_index_to_cpu(u32 drc_index)
value = of_prop_next_u32(info, NULL, _set_entries);
if (!value)
goto err_of_node_put;
+   value++;
 
for (j = 0; j < num_set_entries; j++) {
 
diff --git a/drivers/pci/hotplug/rpaphp_core.c 
b/drivers/pci/hotplug/rpaphp_core.c
index 53902c7..477a21c 100644
--- a/drivers/pci/hotplug/rpaphp_core.c
+++ b/drivers/pci/hotplug/rpaphp_core.c
@@ -253,6 +253,7 @@ static int rpaphp_check_drc_props_v2(struct device_node 
*dn, char *drc_name,
value = of_prop_next_u32(info, NULL, );
if (!value)
return -EINVAL;
+   value++;
 
for (j = 0; j < entries; j++) {
of_read_drc_info_cell(, , );

Re: DPAA Ethernet traffice troubles with Linux kernel

[Andrew Lunn]

On Wed, Feb 07, 2018 at 10:00:45PM +0100, mad skateman wrote:
> Hi,
> 
> I just found out that something goes wrong within the ARP table (well thats
> what i think). I hope someone has a clue..

This looks like 'normal' behaviour. It has been reported that the
device runs out of buffers. That means it will fail to receive ARP
replies. So the ARP entry will time out and be removed, as it should.

Fix the buffer problem, and ARP will likely work properly.

Andrew

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

[Eric W. Biederman]

Khalid Aziz  writes:

> On 02/07/2018 12:38 AM, ebied...@xmission.com wrote:
>> Khalid Aziz  writes:
>>
>>> On 02/01/2018 07:29 PM, ebied...@xmission.com wrote:
 Khalid Aziz  writes:

> V11 changes:
> This series is same as v10 and was simply rebased on 4.15 kernel. Can
> mm maintainers please review patches 2, 7, 8 and 9 which are arch
> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
> and ack these if everything looks good?

 I am a bit puzzled how this differs from the pkey's that other
 architectures are implementing to achieve a similar result.

 I am a bit mystified why you don't store the tag in a vma
 instead of inventing a new way to store data on page out.
>>>
>>> Hello Eric,
>>>
>>> As Steven pointed out, sparc sets tags per cacheline unlike pkey. This 
>>> results
>>> in much finer granularity for tags that pkey and hence requires larger tag
>>> storage than what we can do in a vma.
>>
>> *Nod*   I am a bit mystified where you keep the information in memory.
>> I would think the tags would need to be stored per cacheline or per
>> tlb entry, in some kind of cache that could overflow.  So I would be
>> surprised if swapping is the only time this information needs stored
>> in memory.  Which makes me wonder if you have the proper data
>> structures.
>>
>> I would think an array per vma or something in the page tables would
>> tend to make sense.
>>
>> But perhaps I am missing something.
>
> The ADI tags are stored in spare bits in the RAM. ADI tag storage is
> managed entirely by memory controller which maintains these tags per
> ADI block. An ADI block is the same size as cacheline on M7. Tags for
> each ADI block are associated with the physical ADI block, not the
> virtual address. When a physical page is reused, the physical ADI tag
> storage for that page is overwritten with new ADI tags, hence we need
> to store away the tags when we swap out a page. Kernel updates the ADI
> tags for physical page when it swaps a new page in. Each vma can cover
> variable number of pages so it is best to store a pointer to the tag
> storage in vma as opposed to actual tags in an array. Each 8K page can
> have 128 tags on it. Since each tag is 4 bits, we need 64 bytes per
> page to store the tags. That can add up for a large vma.

If the tags are already stored in RAM I can see why it does not make any
sense to store them except on page out.  Management wise this feels a
lot like the encrypted memory options I have been seeing on x86.

 Can you please use force_sig_fault to send these signals instead
 of force_sig_info.  Emperically I have found that it is very
 error prone to generate siginfo's by hand, especially on code
 paths where several different si_codes may apply.  So it helps
 to go through a helper function to ensure the fiddly bits are
 all correct.  AKA the unused bits all need to be set to zero before
 struct siginfo is copied to userspace.

>>>
>>> What you say makes sense. I followed the same code as other fault handlers 
>>> for
>>> sparc. I could change just the fault handlers for ADI related faults. Would 
>>> it
>>> make more sense to change all the fault handlers in a separate patch and 
>>> keep
>>> the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a
>>> preference?
>>
>> It is my intention post -rc1 to start sending out patches to get the
>> rest of not just sparc but all of the architectures using the new
>> helpers.  I have the code I just ran out of time befor the merge
>> window opened to ensure everything had a good thorough review.
>>
>> So if you can handle the your new changes I expect I will handle the
>> rest.
>>
>
> I can add a patch at the end of my series to update all
> force_sig_info() in my patchset to force_sig_fault(). That will sync
> my patches up with your changes cleanly. Does that work for you? I can
> send an updated series with this change. Can you review and ack the
> patches after this change.

One additional patch would be fine.  I can certainly review and ack that
part.  You probably want to wait until post -rc1 so that you have a
clean base to work off of.

Eric

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

[Khalid Aziz]

On 02/07/2018 12:38 AM, ebied...@xmission.com wrote:

Khalid Aziz  writes:


On 02/01/2018 07:29 PM, ebied...@xmission.com wrote:

Khalid Aziz  writes:


V11 changes:
This series is same as v10 and was simply rebased on 4.15 kernel. Can
mm maintainers please review patches 2, 7, 8 and 9 which are arch
independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
and ack these if everything looks good?


I am a bit puzzled how this differs from the pkey's that other
architectures are implementing to achieve a similar result.

I am a bit mystified why you don't store the tag in a vma
instead of inventing a new way to store data on page out.


Hello Eric,

As Steven pointed out, sparc sets tags per cacheline unlike pkey. This results
in much finer granularity for tags that pkey and hence requires larger tag
storage than what we can do in a vma.


*Nod*   I am a bit mystified where you keep the information in memory.
I would think the tags would need to be stored per cacheline or per
tlb entry, in some kind of cache that could overflow.  So I would be
surprised if swapping is the only time this information needs stored
in memory.  Which makes me wonder if you have the proper data
structures.

I would think an array per vma or something in the page tables would
tend to make sense.

But perhaps I am missing something.


The ADI tags are stored in spare bits in the RAM. ADI tag storage is 
managed entirely by memory controller which maintains these tags per ADI 
block. An ADI block is the same size as cacheline on M7. Tags for each 
ADI block are associated with the physical ADI block, not the virtual 
address. When a physical page is reused, the physical ADI tag storage 
for that page is overwritten with new ADI tags, hence we need to store 
away the tags when we swap out a page. Kernel updates the ADI tags for 
physical page when it swaps a new page in. Each vma can cover variable 
number of pages so it is best to store a pointer to the tag storage in 
vma as opposed to actual tags in an array. Each 8K page can have 128 
tags on it. Since each tag is 4 bits, we need 64 bytes per page to store 
the tags. That can add up for a large vma.





Can you please use force_sig_fault to send these signals instead
of force_sig_info.  Emperically I have found that it is very
error prone to generate siginfo's by hand, especially on code
paths where several different si_codes may apply.  So it helps
to go through a helper function to ensure the fiddly bits are
all correct.  AKA the unused bits all need to be set to zero before
struct siginfo is copied to userspace.



What you say makes sense. I followed the same code as other fault handlers for
sparc. I could change just the fault handlers for ADI related faults. Would it
make more sense to change all the fault handlers in a separate patch and keep
the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a
preference?


It is my intention post -rc1 to start sending out patches to get the
rest of not just sparc but all of the architectures using the new
helpers.  I have the code I just ran out of time befor the merge
window opened to ensure everything had a good thorough review.

So if you can handle the your new changes I expect I will handle the
rest.



I can add a patch at the end of my series to update all force_sig_info() 
in my patchset to force_sig_fault(). That will sync my patches up with 
your changes cleanly. Does that work for you? I can send an updated 
series with this change. Can you review and ack the patches after this 
change.


Thanks,
Khalid

[PATCH] powerpc/via-pmu: Fix section mismatch warning

[Mathieu Malaterre]

Remove the __init annotation from pmu_init() to avoid the
following warning.

WARNING: vmlinux.o(.data+0x4739c): Section mismatch in reference from the 
variable via_pmu_driver to the function .init.text:pmu_init()
The variable via_pmu_driver references
the function __init pmu_init()
If the reference is valid then annotate the
variable with __init* or __refdata (see linux/init.h) or name the variable:
*_template, *_timer, *_sht, *_ops, *_probe, *_probe_one, *_console

Signed-off-by: Mathieu Malaterre 
---
 drivers/macintosh/via-pmu.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/drivers/macintosh/via-pmu.c b/drivers/macintosh/via-pmu.c
index 08849e33c567..5f378272d5b2 100644
--- a/drivers/macintosh/via-pmu.c
+++ b/drivers/macintosh/via-pmu.c
@@ -378,7 +378,7 @@ static int pmu_probe(void)
return vias == NULL? -ENODEV: 0;
 }
 
-static int __init pmu_init(void)
+static int pmu_init(void)
 {
if (vias == NULL)
return -ENODEV;
-- 
2.11.0

Re: [PATCH] char: nvram: disable on ARM

[Alexandre Belloni]

On 07/02/2018 at 16:47:00 +0100, Alexandre Belloni wrote:
> > >> > I really don't think anyone is using that but I don't really know much
> > >> > about x86 and the specification this may be part of.
> > >> >
> > >> > I see the info may be used in drivers/video/fbdev/ and
> > >> > drivers/platform/x86/thinkpad_acpi.c
> > >>
> > >> The thinkpad_acpi driver seems to look at some other bytes
> > >> in the nvram, which have a platform specific meaning.
> > >>
> > >
> > > Yeah, I was more concerned that they need drivers/char/nvram.c for
> > > nvram_read_byte so we can't simply remove the driver.
> > 
> > Ok, so the procfs interface may be obsolete, but we still need an
> > interface into the CMOS NVRAM data.
> > 
> 
> Actually, I just found
> https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to
> 
> So it seems to have real values for some people (even if they are
> wrong).
> 
> That also points to https://sourceforge.net/projects/nvram-wakeup/ but I
> don't think it is necessary. The RTC driver should be able to wakeup an
> x86 platform.
> 
> All the other uses of /dev/nvram I could find with a simple google
> search (i.e. saving and restoring CMOS settings) could just use
> /sys/class/rtc/rtc0/device/nvram
> 

Ok, the chromeos guys are using it for verified boot it seems:
https://chromium.googlesource.com/chromiumos/platform/vboot_reference

I'm wondering whether they really care about the checksum though.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH kernel v2] powerpc/mm: Flush radix process translations when setting MMU type

[Daniel Henrique Barboza]

On 02/07/2018 12:33 PM, Laurent Vivier wrote:

On 01/02/2018 06:09, Alexey Kardashevskiy wrote:

Radix guests do normally invalidate process-scoped translations when
a new pid is allocated but migrated guests do not invalidate these so
migrated guests crash sometime, especially easy to reproduce with
migration happening within first 10 seconds after the guest boot start on
the same machine.

This adds the "Invalidate process-scoped translations" flush to fix
radix guests migration.

Signed-off-by: Alexey Kardashevskiy 
---
Changes:
v2:
* removed PPC_TLBIE_5() from the !(old_HR) case as it is pointless
on hash

---


Not so sure that "process-scoped translations" only require flushing
at pid allocation and migration.

---
  arch/powerpc/mm/pgtable_64.c | 2 ++
  1 file changed, 2 insertions(+)

diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
index c9a623c..d75dd52 100644
--- a/arch/powerpc/mm/pgtable_64.c
+++ b/arch/powerpc/mm/pgtable_64.c
@@ -471,6 +471,8 @@ void mmu_partition_table_set_entry(unsigned int lpid, 
unsigned long dw0,
if (old & PATB_HR) {
asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
 "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
+   asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
+"r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
} else {
asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :


This patch fixes for me a VM migration crash on POWER9.


Same here.

Tested-by: Daniel Henrique Barboza 



Tested-by: Laurent Vivier 

Thanks,
Laurent

Re: [PATCH] char: nvram: disable on ARM

[Alexandre Belloni]

On 07/02/2018 at 15:00:04 +0100, Arnd Bergmann wrote:
> On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni
>  wrote:
> > On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
> >> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
> 
> >> >> $ cat /proc/driver/nvram
> >> >> Checksum status: valid
> >> >> # floppies : 0
> >> >> Floppy 0 type  : none
> >> >> Floppy 1 type  : none
> >> >> HD 0 type  : none
> >> >> HD 1 type  : none
> >> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
> >> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
> >> >> DOS base memory: 635 kB
> >> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
> >> >> Gfx adapter: EGA, VGA, ... (with BIOS)
> >> >> FPU: not installed
> >> >>
> >> >
> >> > I really don't think anyone is using that but I don't really know much
> >> > about x86 and the specification this may be part of.
> >> >
> >> > I see the info may be used in drivers/video/fbdev/ and
> >> > drivers/platform/x86/thinkpad_acpi.c
> >>
> >> The thinkpad_acpi driver seems to look at some other bytes
> >> in the nvram, which have a platform specific meaning.
> >>
> >
> > Yeah, I was more concerned that they need drivers/char/nvram.c for
> > nvram_read_byte so we can't simply remove the driver.
> 
> Ok, so the procfs interface may be obsolete, but we still need an
> interface into the CMOS NVRAM data.
> 

Actually, I just found
https://unix.stackexchange.com/questions/331419/is-dev-nvram-dangerous-to-write-to

So it seems to have real values for some people (even if they are
wrong).

That also points to https://sourceforge.net/projects/nvram-wakeup/ but I
don't think it is necessary. The RTC driver should be able to wakeup an
x86 platform.

All the other uses of /dev/nvram I could find with a simple google
search (i.e. saving and restoring CMOS settings) could just use
/sys/class/rtc/rtc0/device/nvram

> I see that the x86 version of nvram_read_byte is just a wrapper
> around CMOS_READ(14 + addr). We also have some drivers
> that call the low-level function directly:
> 
> arch/x86/include/asm/floppy.h:  val = CMOS_READ(0x10) & 15;
> arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port);
> drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C);
> drivers/input/misc/wistron_btns.c:  qlen = 
> CMOS_READ(cmos_address);
> 
> I suppose we could make the thinkpad driver do the same,
> or provide a 'static inline' version of nvram_read_byte somewhere.
> 

I guess we can do that, provided we take rtc_lock before using
CMOS_READ.

Thinking of it, I think this means we don't need the lock for powerpc as
nvram_read_byte doesn't take it. So I guess it is only needed on x86.

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH kernel v2] powerpc/mm: Flush radix process translations when setting MMU type

[Laurent Vivier]

On 01/02/2018 06:09, Alexey Kardashevskiy wrote:
> Radix guests do normally invalidate process-scoped translations when
> a new pid is allocated but migrated guests do not invalidate these so
> migrated guests crash sometime, especially easy to reproduce with
> migration happening within first 10 seconds after the guest boot start on
> the same machine.
> 
> This adds the "Invalidate process-scoped translations" flush to fix
> radix guests migration.
> 
> Signed-off-by: Alexey Kardashevskiy 
> ---
> Changes:
> v2:
> * removed PPC_TLBIE_5() from the !(old_HR) case as it is pointless
> on hash
> 
> ---
> 
> 
> Not so sure that "process-scoped translations" only require flushing
> at pid allocation and migration.
> 
> ---
>  arch/powerpc/mm/pgtable_64.c | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/arch/powerpc/mm/pgtable_64.c b/arch/powerpc/mm/pgtable_64.c
> index c9a623c..d75dd52 100644
> --- a/arch/powerpc/mm/pgtable_64.c
> +++ b/arch/powerpc/mm/pgtable_64.c
> @@ -471,6 +471,8 @@ void mmu_partition_table_set_entry(unsigned int lpid, 
> unsigned long dw0,
>   if (old & PATB_HR) {
>   asm volatile(PPC_TLBIE_5(%0,%1,2,0,1) : :
>"r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
> + asm volatile(PPC_TLBIE_5(%0,%1,2,1,1) : :
> +  "r" (TLBIEL_INVAL_SET_LPID), "r" (lpid));
>   trace_tlbie(lpid, 0, TLBIEL_INVAL_SET_LPID, lpid, 2, 0, 1);
>   } else {
>   asm volatile(PPC_TLBIE_5(%0,%1,2,0,0) : :
> 

This patch fixes for me a VM migration crash on POWER9.

Tested-by: Laurent Vivier 

Thanks,
Laurent

Re: [PATCH 16/18] crypto: talitos - do hw_context DMA mapping outside the requests

[Horia Geantă]

On 10/6/2017 4:06 PM, Christophe Leroy wrote:
> At every request, we map and unmap the same hash hw_context.
> 
> This patch moves the dma mapping/unmapping in functions ahash_init()
> and ahash_import().
> 
> Signed-off-by: Christophe Leroy 
> ---
>  drivers/crypto/talitos.c | 80 
> ++--
>  1 file changed, 57 insertions(+), 23 deletions(-)
> 
> diff --git a/drivers/crypto/talitos.c b/drivers/crypto/talitos.c
> index ebfd6d982ed6..d495649d5267 100644
> --- a/drivers/crypto/talitos.c
> +++ b/drivers/crypto/talitos.c
> @@ -819,6 +819,7 @@ struct talitos_ctx {
>   unsigned int keylen;
>   unsigned int enckeylen;
>   unsigned int authkeylen;
> + dma_addr_t dma_hw_context;
This doesn't look correct.

talitos_ctx structure is the tfm context.
dma_hw_context is the IOVA of hw_context, located in talitos_ahash_req_ctx
structure (request context).

If there are multiple requests in flight for the same tfm, dma_hw_context will
be overwritten.

dma_hw_context needs to be moved in request context (talitos_ahash_req_ctx 
struct).

Thanks,
Horia

Re: [PATCH] char: nvram: disable on ARM

[Arnd Bergmann]

On Wed, Feb 7, 2018 at 1:48 PM, Alexandre Belloni
 wrote:
> On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
>> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni

>> >> $ cat /proc/driver/nvram
>> >> Checksum status: valid
>> >> # floppies : 0
>> >> Floppy 0 type  : none
>> >> Floppy 1 type  : none
>> >> HD 0 type  : none
>> >> HD 1 type  : none
>> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
>> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
>> >> DOS base memory: 635 kB
>> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
>> >> Gfx adapter: EGA, VGA, ... (with BIOS)
>> >> FPU: not installed
>> >>
>> >
>> > I really don't think anyone is using that but I don't really know much
>> > about x86 and the specification this may be part of.
>> >
>> > I see the info may be used in drivers/video/fbdev/ and
>> > drivers/platform/x86/thinkpad_acpi.c
>>
>> The thinkpad_acpi driver seems to look at some other bytes
>> in the nvram, which have a platform specific meaning.
>>
>
> Yeah, I was more concerned that they need drivers/char/nvram.c for
> nvram_read_byte so we can't simply remove the driver.

Ok, so the procfs interface may be obsolete, but we still need an
interface into the CMOS NVRAM data.

I see that the x86 version of nvram_read_byte is just a wrapper
around CMOS_READ(14 + addr). We also have some drivers
that call the low-level function directly:

arch/x86/include/asm/floppy.h:  val = CMOS_READ(0x10) & 15;
arch/x86/kernel/bootflag.c: v = CMOS_READ(sbf_port);
drivers/char/mwave/smapi.c: usSmapiID = CMOS_READ(0x7C);
drivers/input/misc/wistron_btns.c:  qlen = CMOS_READ(cmos_address);

I suppose we could make the thinkpad driver do the same,
or provide a 'static inline' version of nvram_read_byte somewhere.

  Arnd

Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii

[Jonathan Neuschäfer]

On Wed, Feb 07, 2018 at 01:29:45PM +0100, Linus Walleij wrote:
> On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer
>  wrote:
> 
> > The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> > that supports a configurable number of pins (up to 32), interrupts, and
> > some special mechanisms to share the controller between the system's
> > security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> > not supported.
> >
> > This patch adds a basic driver for this GPIO controller. Interrupt
> > support will come in a later patch.
> >
> > This patch is based on code developed by Albert Herranz and the GameCube
> > Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> > available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> > has grown quite dissimilar.
> >
> > Signed-off-by: Jonathan Neuschäfer 
> > Cc: Albert Herranz 
> > Cc: Segher Boessenkool 
> > ---
> >
> > v2:
> 
> All looks very good to me, Andy had some additional comments,
> once addressed in v3 I will apply this.
> 
> You only need to resend this patch as I already applied the DT
> bindings.

This driver can't be used until the resource mapping problem on PPC32
(see patch 1/6 and the related discussion) is solved or worked around
with out-of-tree patches (such as patch 1/6). Should I send v3 anyway?


Thanks,
Jonathan Neuschäfer


signature.asc
Description: PGP signature

Re: [PATCH] char: nvram: disable on ARM

[Alexandre Belloni]

On 07/02/2018 at 11:33:55 +0100, Arnd Bergmann wrote:
> On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
>  wrote:
> > On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
> >> * arch/arm/kernel/time.c has this code
> >>
> >> #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || 
> >> \
> >> defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
> >> /* this needs a better home */
> >> DEFINE_SPINLOCK(rtc_lock);
> >> EXPORT_SYMBOL(rtc_lock);
> >> #endif  /* pc-style 'CMOS' RTC support */
> >>
> >> That can be adapted now, or maybe we could move all definitions into
> >> a common place (that needs some more planning).
> >>
> >
> > Yes, on arm, the rtc_lock is mostly there to please
> > drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
> > x86 and PPC specific.
> >
> > If we can get rid of arch/powerpc/platforms/chrp/time.c and
> > arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
> > is x86 only.
> 
> What about these:
> 
> arch/alpha/kernel/rtc.c:spin_lock(_lock);
> arch/alpha/kernel/rtc.c:spin_unlock(_lock);
> arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
> arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
> arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock);
> arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock);
> arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
> arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
> arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock);
> arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock);
> arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock);
> 
> Are they all obsolete?
> 

Yes and no. For those architecture, the spinlock is only used to make
the driver compile. It is probably not actually needed or at least it
can be made local to the driver.

For alpha, I just realized I never sent a patch removing the spinlock
usage, I'll do that this cycle:
https://github.com/alexandrebelloni/linux/commit/e79e2a754a3a67f2d7e906bfda0042f9dcf66a0b

> >> $ cat /proc/driver/nvram
> >> Checksum status: valid
> >> # floppies : 0
> >> Floppy 0 type  : none
> >> Floppy 1 type  : none
> >> HD 0 type  : none
> >> HD 1 type  : none
> >> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
> >> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
> >> DOS base memory: 635 kB
> >> Extended memory: 65535 kB (configured), 65535 kB (tested)
> >> Gfx adapter: EGA, VGA, ... (with BIOS)
> >> FPU: not installed
> >>
> >
> > I really don't think anyone is using that but I don't really know much
> > about x86 and the specification this may be part of.
> >
> > I see the info may be used in drivers/video/fbdev/ and
> > drivers/platform/x86/thinkpad_acpi.c
> 
> The thinkpad_acpi driver seems to look at some other bytes
> in the nvram, which have a platform specific meaning.
> 

Yeah, I was more concerned that they need drivers/char/nvram.c for
nvram_read_byte so we can't simply remove the driver.

> For drivers/video/fbdev/, these appear to all be for pre-x86
> Apple Macintosh (m68k or powerpc).
> 

-- 
Alexandre Belloni, Bootlin (formerly Free Electrons)
Embedded Linux and Kernel engineering
http://bootlin.com

Re: [PATCH v2 3/6] gpio: Add GPIO driver for Nintendo Wii

[Linus Walleij]

On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer
 wrote:

> The Nintendo Wii's chipset (called "Hollywood") has a GPIO controller
> that supports a configurable number of pins (up to 32), interrupts, and
> some special mechanisms to share the controller between the system's
> security processor (an ARM926) and the PowerPC CPU. Pin multiplexing is
> not supported.
>
> This patch adds a basic driver for this GPIO controller. Interrupt
> support will come in a later patch.
>
> This patch is based on code developed by Albert Herranz and the GameCube
> Linux Team, file arch/powerpc/platforms/embedded6xx/hlwd-gpio.c,
> available at https://github.com/DeltaResero/GC-Wii-Linux-Kernels, but
> has grown quite dissimilar.
>
> Signed-off-by: Jonathan Neuschäfer 
> Cc: Albert Herranz 
> Cc: Segher Boessenkool 
> ---
>
> v2:

All looks very good to me, Andy had some additional comments,
once addressed in v3 I will apply this.

You only need to resend this patch as I already applied the DT
bindings.

Yours,
Linus Walleij

Re: [PATCH v2 4/6] dt-bindings: gpio: Add binding for Wii GPIO controller

[Linus Walleij]

On Mon, Jan 22, 2018 at 6:04 AM, Jonathan Neuschäfer
 wrote:

> The Nintendo Wii game console has a GPIO controller, which is used for
> the optical disk slot LED, buttons, poweroff, etc. This patch adds a
> binding for this GPIO controller.
>
> Signed-off-by: Jonathan Neuschäfer 
> Reviewed-by: Rob Herring 
> ---
>
> v2:

Patch applied for 4.17.

Yours,
Linus Walleij

Re: [PATCH] char: nvram: disable on ARM

[Arnd Bergmann]

On Wed, Feb 7, 2018 at 2:55 AM, Alexandre Belloni
 wrote:
> On 06/02/2018 at 23:55:02 +0100, Arnd Bergmann wrote:
>> * arch/arm/kernel/time.c has this code
>>
>> #if defined(CONFIG_RTC_DRV_CMOS) || defined(CONFIG_RTC_DRV_CMOS_MODULE) || \
>> defined(CONFIG_NVRAM) || defined(CONFIG_NVRAM_MODULE)
>> /* this needs a better home */
>> DEFINE_SPINLOCK(rtc_lock);
>> EXPORT_SYMBOL(rtc_lock);
>> #endif  /* pc-style 'CMOS' RTC support */
>>
>> That can be adapted now, or maybe we could move all definitions into
>> a common place (that needs some more planning).
>>
>
> Yes, on arm, the rtc_lock is mostly there to please
> drivers/rtc/rtc-cmos.c. Maybe we could make the locking in this driver
> x86 and PPC specific.
>
> If we can get rid of arch/powerpc/platforms/chrp/time.c and
> arch/powerpc/platforms/maple/time.c (so much duplicated code), then it
> is x86 only.

What about these:

arch/alpha/kernel/rtc.c:spin_lock(_lock);
arch/alpha/kernel/rtc.c:spin_unlock(_lock);
arch/alpha/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/alpha/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/arm/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/arm/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m32r/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m32r/kernel/time.c:EXPORT_SYMBOL(rtc_lock);
arch/m68k/atari/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/m68k/atari/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/mn10300/kernel/rtc.c:DEFINE_SPINLOCK(rtc_lock);
arch/mn10300/kernel/rtc.c:EXPORT_SYMBOL(rtc_lock);
arch/powerpc/kernel/time.c:DEFINE_SPINLOCK(rtc_lock);
arch/powerpc/kernel/time.c:EXPORT_SYMBOL_GPL(rtc_lock);
arch/sparc/kernel/time_32.c:DEFINE_SPINLOCK(rtc_lock);
arch/sparc/kernel/time_32.c:EXPORT_SYMBOL(rtc_lock);
arch/sparc/kernel/time_64.c:DEFINE_SPINLOCK(rtc_lock);

Are they all obsolete?

>> * similarly, this line in nvram.c can be simplified:
>> #if defined(CONFIG_ATARI)
>> #  define MACH ATARI
>> #elif defined(__i386__) || defined(__x86_64__) || defined(__arm__)  /* and 
>> ?? */
>> #  define MACH PC
>> #else
>> #  error Cannot build nvram driver for this machine configuration.
>> #endif
>>
>> * GENERIC_NVRAM is not really generic, instead this seems to be the
>>   chardev that is used for 32-bit powerpc (powermac, 85xx, 86xx), while
>>   64-bit powerpc (cell, maple, opal, pseries) use code from
>>   arch/powerpc/kernel/nvram_64.c, with the same underlying arch hooks.
>>   The nvram_64 code appears to be mostly a superset of the 32-bit
>>   generic_nvram one.
>>
>> * The code in drivers/char/nvram is not used at all when
>>GENERIC_NVRAM is set, and half the code in there is different
>>between x86 and atari.
>>
>> * most of the external interface in include/linux/nvram.h is
>>   unused, the rest tends to be architecture specific
>>
>> * The procfs file appears to be completely useless on any 64-bit
>>x86 machine, this is what I see:
>>
>> $ cat /proc/driver/nvram
>> Checksum status: valid
>> # floppies : 0
>> Floppy 0 type  : none
>> Floppy 1 type  : none
>> HD 0 type  : none
>> HD 1 type  : none
>> HD type 48 data: 0/0/0 C/H/S, precomp 0, lz 0
>> HD type 49 data: 156/0/0 C/H/S, precomp 0, lz 0
>> DOS base memory: 635 kB
>> Extended memory: 65535 kB (configured), 65535 kB (tested)
>> Gfx adapter: EGA, VGA, ... (with BIOS)
>> FPU: not installed
>>
>
> I really don't think anyone is using that but I don't really know much
> about x86 and the specification this may be part of.
>
> I see the info may be used in drivers/video/fbdev/ and
> drivers/platform/x86/thinkpad_acpi.c

The thinkpad_acpi driver seems to look at some other bytes
in the nvram, which have a platform specific meaning.

For drivers/video/fbdev/, these appear to all be for pre-x86
Apple Macintosh (m68k or powerpc).

   Arnd

Re: [PATCH v11 00/10] Application Data Integrity feature introduced by SPARC M7

[Eric W. Biederman]

Khalid Aziz  writes:

> On 02/01/2018 07:29 PM, ebied...@xmission.com wrote:
>> Khalid Aziz  writes:
>>
>>> V11 changes:
>>> This series is same as v10 and was simply rebased on 4.15 kernel. Can
>>> mm maintainers please review patches 2, 7, 8 and 9 which are arch
>>> independent, and include/linux/mm.h and mm/ksm.c changes in patch 10
>>> and ack these if everything looks good?
>>
>> I am a bit puzzled how this differs from the pkey's that other
>> architectures are implementing to achieve a similar result.
>>
>> I am a bit mystified why you don't store the tag in a vma
>> instead of inventing a new way to store data on page out.
>
> Hello Eric,
>
> As Steven pointed out, sparc sets tags per cacheline unlike pkey. This results
> in much finer granularity for tags that pkey and hence requires larger tag
> storage than what we can do in a vma.

*Nod*   I am a bit mystified where you keep the information in memory.
I would think the tags would need to be stored per cacheline or per
tlb entry, in some kind of cache that could overflow.  So I would be
surprised if swapping is the only time this information needs stored
in memory.  Which makes me wonder if you have the proper data
structures.

I would think an array per vma or something in the page tables would
tend to make sense.

But perhaps I am missing something.

>> Can you please use force_sig_fault to send these signals instead
>> of force_sig_info.  Emperically I have found that it is very
>> error prone to generate siginfo's by hand, especially on code
>> paths where several different si_codes may apply.  So it helps
>> to go through a helper function to ensure the fiddly bits are
>> all correct.  AKA the unused bits all need to be set to zero before
>> struct siginfo is copied to userspace.
>>
>
> What you say makes sense. I followed the same code as other fault handlers for
> sparc. I could change just the fault handlers for ADI related faults. Would it
> make more sense to change all the fault handlers in a separate patch and keep
> the code in arch/sparc/kernel/traps_64.c consistent? Dave M, do you have a
> preference?

It is my intention post -rc1 to start sending out patches to get the
rest of not just sparc but all of the architectures using the new
helpers.  I have the code I just ran out of time befor the merge
window opened to ensure everything had a good thorough review.

So if you can handle the your new changes I expect I will handle the
rest.

Eric