* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Marc Zyngier @ 2018-03-29 17:53 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Geert Uytterhoeven, Oliver, Rob Landley, Shea Levy, linux-riscv,
Linux Kernel Mailing List, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Catalin Marinas,
Will Deacon, Mark Salter, Aurelien Jacquiot, Mikael Starvik,
Jesper Nilsson, Yoshinori Sato, Richard Kuo, Tony Luck,
Fenghua Yu, James Hogan, Michal Simek, Ralf Baechle,
David Howells, Ley Foon Tan, Jonas Bonn, Stefan Kristiansson,
Stafford Horne, James E.J. Bottomley, Helge Deller,
Benjamin Herrenschmidt, Paul Mackerras, Michael Ellerman,
Palmer Dabbelt, Albert Ou, Martin Schwidefsky, Heiko Carstens,
Chen Liqin, Lennox Wu, Rich Felker, David S. Miller, Jeff Dike,
Richard Weinberger, Guan Xuetao, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, the arch/x86 maintainers, Chris Zankel,
Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Rob Herring, Kees Cook, Vlastimil Babka, Balbir Singh,
Christophe Leroy, Joe Perches, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Florian Fainelli, alpha, arcml, Linux ARM,
adi-buildroot-devel, linux-c6x-dev, Cris,
moderated list:H8/300 ARCHITECTURE, open list:QUALCOMM HEXAGON...,
linux-ia64, linux-m68k, open list:METAG ARCHITECTURE,
Linux MIPS Mailing List, moderated list:PANASONIC MN10300...,
nios2-dev, Openrisc, Parisc List, linuxppc-dev, linux-s390,
Linux-sh list, sparclinux, uml-devel, uml-user, linux-xtensa,
Nicholas Piggin
In-Reply-To: <20180329173247.GF16141@n2100.armlinux.org.uk>
On Thu, 29 Mar 2018 18:32:47 +0100,
Russell King - ARM Linux wrote:
>
> On Thu, Mar 29, 2018 at 05:53:14PM +0100, Marc Zyngier wrote:
> > On Thu, 29 Mar 2018 16:58:27 +0100,
> > Russell King - ARM Linux wrote:
[...]
> > > I'm not aware of there being an emulated UART in the guest's address
> > > space, so serial based stuff doesn't work.
> >
> > "earlycon=uart,mmio,0x3f8" is what you're looking for:
>
> Does that also mean that we have a RTC at the standard PC IO addresses
> as well, but in mmio space?
There is one, together with an i8042. Not exposed in the DT though.
M.
--
Jazz is not dead, it just smell funny.
^ permalink raw reply
* [PATCH] powerpc/pseries: Fix to clear security feature flags
From: Mauricio Faria de Oliveira @ 2018-03-29 18:32 UTC (permalink / raw)
To: mpe, linuxppc-dev
The H_CPU_BEHAV_* flags should be checked for in the 'behaviour' field
of 'struct h_cpu_char_result' -- 'character' is for H_CPU_CHAR_* flags.
Found it by playing around with QEMU's implementation of the hypercall:
Example:
H_CPU_CHAR=0xf000000000000000
H_CPU_BEHAV=0x0000000000000000
This clears H_CPU_BEHAV_FAVOUR_SECURITY and H_CPU_BEHAV_L1D_FLUSH_PR
so pseries_setup_rfi_flush() disables 'rfi_flush'; and it also clears
H_CPU_CHAR_L1D_THREAD_PRIV flag. So there is no RFI flush mitigation
at all for cpu_show_meltdown() to report; but currently it does:
Original kernel:
# cat /sys/devices/system/cpu/vulnerabilities/meltdown
Mitigation: RFI Flush
Patched kernel:
# cat /sys/devices/system/cpu/vulnerabilities/meltdown
Not affected
Example:
H_CPU_CHAR=0x0000000000000000
H_CPU_BEHAV=0xf000000000000000
This sets H_CPU_BEHAV_BNDS_CHK_SPEC_BAR so cpu_show_spectre_v1() should
report vulnerable; but currently it doesn't:
Original kernel:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Not affected
Patched kernel:
# cat /sys/devices/system/cpu/vulnerabilities/spectre_v1
Vulnerable
Fixes: f636c14790ea ("powerpc/pseries: Set or clear security feature flags")
Signed-off-by: Mauricio Faria de Oliveira <mauricfo@linux.vnet.ibm.com>
---
arch/powerpc/platforms/pseries/setup.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/arch/powerpc/platforms/pseries/setup.c b/arch/powerpc/platforms/pseries/setup.c
index 1f12235..b11564f 100644
--- a/arch/powerpc/platforms/pseries/setup.c
+++ b/arch/powerpc/platforms/pseries/setup.c
@@ -484,13 +484,13 @@ static void init_cpu_char_feature_flags(struct h_cpu_char_result *result)
* The features below are enabled by default, so we instead look to see
* if firmware has *disabled* them, and clear them if so.
*/
- if (!(result->character & H_CPU_BEHAV_FAVOUR_SECURITY))
+ if (!(result->behaviour & H_CPU_BEHAV_FAVOUR_SECURITY))
security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
- if (!(result->character & H_CPU_BEHAV_L1D_FLUSH_PR))
+ if (!(result->behaviour & H_CPU_BEHAV_L1D_FLUSH_PR))
security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
- if (!(result->character & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
+ if (!(result->behaviour & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
}
--
1.8.3.1
^ permalink raw reply related
* Re: [PATCH v2 03/10] powerpc/pseries: Set or clear security feature flags
From: Mauricio Faria de Oliveira @ 2018-03-29 18:35 UTC (permalink / raw)
To: Michael Ellerman, linuxppc-dev
In-Reply-To: <20180327120153.31612-3-mpe@ellerman.id.au>
Hi Michael,
On 03/27/2018 09:01 AM, Michael Ellerman wrote:
> + if (!(result->character & H_CPU_BEHAV_FAVOUR_SECURITY))
> + security_ftr_clear(SEC_FTR_FAVOUR_SECURITY);
> +
> + if (!(result->character & H_CPU_BEHAV_L1D_FLUSH_PR))
> + security_ftr_clear(SEC_FTR_L1D_FLUSH_PR);
> +
> + if (!(result->character & H_CPU_BEHAV_BNDS_CHK_SPEC_BAR))
> + security_ftr_clear(SEC_FTR_BNDS_CHK_SPEC_BAR);
Oops, I missed this..
The H_CPU_BEHAV flags should be checked for in 'result->behaviour'.
Just sent '[PATCH] powerpc/pseries: Fix to clear security feature flags'
cheers,
Mauricio
^ permalink raw reply
* Re: [PATCH v3 00/41] cxlflash: OCXL transport support and miscellaneous fixes
From: Uma Krishnan @ 2018-03-29 18:35 UTC (permalink / raw)
To: Martin K. Petersen
Cc: James Bottomley, linux-scsi, Matthew R. Ochs, Frederic Barrat,
Manoj N. Kumar, Andrew Donnellan, linuxppc-dev,
Christophe Lombard
In-Reply-To: <yq1o9j7j34o.fsf@oracle.com>
> On Mar 28, 2018, at 4:34 PM, Martin K. Petersen =
<martin.petersen@oracle.com> wrote:
>=20
>=20
> Uma,
>=20
>> This patch series adds OCXL support to the cxlflash driver. With this
>> support, new devices using the OCXL transport will be supported by =
the
>> cxlflash driver along with the existing CXL devices. An effort is =
made
>> to keep this transport specific function independent of the existing
>> core driver that communicates with the AFU.
>>=20
>> The first three patches contain a minor fix and staging improvements.
>>=20
>> This series is intended for 4.17 and is bisectable.
>=20
> Something this big really needs to be submitted around rc2/rc3. It's =
way
> too late in the cycle to ensure proper zeroday coverage for all these
> commits.
>=20
> I have started a 4.18/scsi-queue branch to hold this series for now.
> The 4.18 branch will be rebased once 4.17rc1 is out in a few weeks. =
Your
> changes won't show up in for-next until then either.
I did send the first version of this series just after 4.16rc2 but the =
reviews took a while and the V3 is cutting close unless we do have an =
rc8 for 4.16 :)
I understand what you are saying and agree with you. Thanks for keeping =
me posted.=
^ permalink raw reply
* [PATCH] powerpc: kexec_file: Fix error code when trying to load kdump kernel
From: Thiago Jung Bauermann @ 2018-03-29 19:05 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Ellerman, Dave Young, Michal Suchánek, kexec,
linux-kernel, Thiago Jung Bauermann
kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
returns -ENOTSUPP in that case.
I've recently learned that this errno is internal to the kernel and isn't
supposed to be exposed to userspace. Therefore, change to -EOPNOTSUPP which
is defined in an uapi header.
This does indeed make kexec-tools happier. Before the patch, on ppc64le:
# ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
kexec_file_load failed: Unknown error 524
After the patch:
# ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
kexec_file_load failed: Operation not supported
Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()")
Reported-by: Dave Young <dyoung@redhat.com>
Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
---
arch/powerpc/kernel/machine_kexec_file_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
This is a minor issue, but since it's a simple patch it might be worth
applying it to stable branches.
This is the kexec-tools thread where this problem was brought up:
https://lists.infradead.org/pipermail/kexec/2018-March/020346.html
And this is an instance of a similar fix being applied elsewhere in the
kernel, for the same reasons:
https://patchwork.kernel.org/patch/8490791/
The test shown in the commit log was made using Hari Bathini's patch
adding kexec_file_load() support to kexec-tools in ppc64.
diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c b/arch/powerpc/kernel/machine_kexec_file_64.c
index e4395f937d63..45e0b7d5f200 100644
--- a/arch/powerpc/kernel/machine_kexec_file_64.c
+++ b/arch/powerpc/kernel/machine_kexec_file_64.c
@@ -43,7 +43,7 @@ int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
/* We don't support crash kernels yet. */
if (image->type == KEXEC_TYPE_CRASH)
- return -ENOTSUPP;
+ return -EOPNOTSUPP;
for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
fops = kexec_file_loaders[i];
^ permalink raw reply related
* Re: [PATCH 00/32] docs/vm: convert to ReST format
From: Jonathan Corbet @ 2018-03-29 21:46 UTC (permalink / raw)
To: Mike Rapoport
Cc: Andrey Ryabinin, Richard Henderson, Ivan Kokshaysky, Matt Turner,
Tony Luck, Fenghua Yu, Ralf Baechle, James Hogan,
Michael Ellerman, Alexander Viro, linux-kernel, linux-doc,
kasan-dev, linux-alpha, linux-ia64, linux-mips, linuxppc-dev,
linux-fsdevel, linux-mm
In-Reply-To: <1521660168-14372-1-git-send-email-rppt@linux.vnet.ibm.com>
On Wed, 21 Mar 2018 21:22:16 +0200
Mike Rapoport <rppt@linux.vnet.ibm.com> wrote:
> These patches convert files in Documentation/vm to ReST format, add an
> initial index and link it to the top level documentation.
>
> There are no contents changes in the documentation, except few spelling
> fixes. The relatively large diffstat stems from the indentation and
> paragraph wrapping changes.
>
> I've tried to keep the formatting as consistent as possible, but I could
> miss some places that needed markup and add some markup where it was not
> necessary.
So I've been pondering on these for a bit. It looks like a reasonable and
straightforward RST conversion, no real complaints there. But I do have a
couple of concerns...
One is that, as we move documentation into RST, I'm really trying to
organize it a bit so that it is better tuned to the various audiences we
have. For example, ksm.txt is going to be of interest to sysadmin types,
who might want to tune it. mmu_notifier.txt is of interest to ...
somebody, but probably nobody who is thinking in user space. And so on.
So I would really like to see this material split up and put into the
appropriate places in the RST hierarchy - admin-guide for administrative
stuff, core-api for kernel development topics, etc. That, of course,
could be done separately from the RST conversion, but I suspect I know
what will (or will not) happen if we agree to defer that for now :)
The other is the inevitable merge conflicts that changing that many doc
files will create. Sending the patches through Andrew could minimize
that, I guess, or at least make it his problem. Alternatively, we could
try to do it as an end-of-merge-window sort of thing. I can try to manage
that, but an ack or two from the mm crowd would be nice to have.
Thanks,
jon
^ permalink raw reply
* [RFC PATCH] powerpc/64/kexec: fix race in kexec when XIVE is shutdown
From: Cédric Le Goater @ 2018-03-29 14:49 UTC (permalink / raw)
To: linuxppc-dev
Cc: Michael Ellerman, Benjamin Herrenschmidt, Cédric Le Goater
The kexec_state KEXEC_STATE_IRQS_OFF barrier is reached by all
secondary CPUs before the kexec_cpu_down() operation is called on
secondaries. This can raise conflicts and provoque errors in the XIVE
hcalls when XIVE is shutdowned with H_INT_RESET on the primary CPU.
To synchronize the kexec_cpu_down() operations and make sure the
secondaries have completed their task before the primary starts doing
the same, let's move the primary kexec_cpu_down() after the
KEXEC_STATE_REAL_MODE barrier.
Signed-off-by: Cédric Le Goater <clg@kaod.org>
---
If this is a bad idea, there are alternate solutions :
- introduce a new kexec_state and barrier
- test for such error in all possible XIVE hcalls.
But I tend to prefer the proposed one.
Thanks,
C.
arch/powerpc/kernel/machine_kexec_64.c | 8 ++++----
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/machine_kexec_64.c b/arch/powerpc/kernel/machine_kexec_64.c
index 49d34d7271e7..212ecb8e829c 100644
--- a/arch/powerpc/kernel/machine_kexec_64.c
+++ b/arch/powerpc/kernel/machine_kexec_64.c
@@ -230,16 +230,16 @@ static void kexec_prepare_cpus(void)
/* we are sure every CPU has IRQs off at this point */
kexec_all_irq_disabled = 1;
- /* after we tell the others to go down */
- if (ppc_md.kexec_cpu_down)
- ppc_md.kexec_cpu_down(0, 0);
-
/*
* Before removing MMU mappings make sure all CPUs have entered real
* mode:
*/
kexec_prepare_cpus_wait(KEXEC_STATE_REAL_MODE);
+ /* after we tell the others to go down */
+ if (ppc_md.kexec_cpu_down)
+ ppc_md.kexec_cpu_down(0, 0);
+
put_cpu();
}
--
2.13.6
^ permalink raw reply related
* [PATCH 1/2] powerpc/cpu: raise DEVICE_ADD/REMOVE msg to usrspace
From: Pingfan Liu @ 2018-03-30 1:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, mpe, benh, hbathini
Some user space tools such as kexec-tools resort to the event
add/remove to decide whether rebuilding dtb or not.
So if a new core added and a crash happens on one of its thread,
then kexec fails to bring up the 2nd kernel since lacking the info
of boot-cpu-hwid in dtb. This patch uses the interface
register_/unregister_cpu to fix the problem
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
Reported-by: Hari Bathini <hbathini@linux.vnet.ibm.com>
---
arch/powerpc/include/asm/smp.h | 1 +
arch/powerpc/kernel/sysfs.c | 26 ++++++++++++++------------
arch/powerpc/platforms/pseries/hotplug-cpu.c | 3 ++-
3 files changed, 17 insertions(+), 13 deletions(-)
diff --git a/arch/powerpc/include/asm/smp.h b/arch/powerpc/include/asm/smp.h
index fac963e..3ef730d 100644
--- a/arch/powerpc/include/asm/smp.h
+++ b/arch/powerpc/include/asm/smp.h
@@ -35,6 +35,7 @@ extern int spinning_secondaries;
extern void cpu_die(void);
extern int cpu_to_chip_id(int cpu);
+DECLARE_PER_CPU(struct cpu, cpu_devices);
#ifdef CONFIG_SMP
struct smp_ops_t {
diff --git a/arch/powerpc/kernel/sysfs.c b/arch/powerpc/kernel/sysfs.c
index 04d0bbd..dbbcc96 100644
--- a/arch/powerpc/kernel/sysfs.c
+++ b/arch/powerpc/kernel/sysfs.c
@@ -26,7 +26,7 @@
#include <asm/lppaca.h>
#endif
-static DEFINE_PER_CPU(struct cpu, cpu_devices);
+DEFINE_PER_CPU(struct cpu, cpu_devices);
/*
* SMT snooze delay stuff, 64-bit only for now
@@ -716,6 +716,16 @@ static struct device_attribute pa6t_attrs[] = {
#endif /* HAS_PPC_PMC_PA6T */
#endif /* HAS_PPC_PMC_CLASSIC */
+/* Only valid if CPU is present. */
+static ssize_t show_physical_id(struct device *dev,
+ struct device_attribute *attr, char *buf)
+{
+ struct cpu *cpu = container_of(dev, struct cpu, dev);
+
+ return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
+}
+static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
+
static int register_cpu_online(unsigned int cpu)
{
struct cpu *c = &per_cpu(cpu_devices, cpu);
@@ -723,6 +733,8 @@ static int register_cpu_online(unsigned int cpu)
struct device_attribute *attrs, *pmc_attrs;
int i, nattrs;
+ device_create_file(&c->dev, &dev_attr_physical_id);
+
/* For cpus present at boot a reference was already grabbed in register_cpu() */
if (!s->of_node)
s->of_node = of_get_cpu_node(cpu, NULL);
@@ -816,6 +828,7 @@ static int unregister_cpu_online(unsigned int cpu)
BUG_ON(!c->hotpluggable);
+ device_remove_file(s, &dev_attr_physical_id);
#ifdef CONFIG_PPC64
if (cpu_has_feature(CPU_FTR_SMT))
device_remove_file(s, &dev_attr_smt_snooze_delay);
@@ -1017,16 +1030,6 @@ static void register_nodes(void)
#endif
-/* Only valid if CPU is present. */
-static ssize_t show_physical_id(struct device *dev,
- struct device_attribute *attr, char *buf)
-{
- struct cpu *cpu = container_of(dev, struct cpu, dev);
-
- return sprintf(buf, "%d\n", get_hard_smp_processor_id(cpu->dev.id));
-}
-static DEVICE_ATTR(physical_id, 0444, show_physical_id, NULL);
-
static int __init topology_init(void)
{
int cpu, r;
@@ -1049,7 +1052,6 @@ static int __init topology_init(void)
if (cpu_online(cpu) || c->hotpluggable) {
register_cpu(c, cpu);
- device_create_file(&c->dev, &dev_attr_physical_id);
}
}
r = cpuhp_setup_state(CPUHP_AP_ONLINE_DYN, "powerpc/topology:online",
diff --git a/arch/powerpc/platforms/pseries/hotplug-cpu.c b/arch/powerpc/platforms/pseries/hotplug-cpu.c
index 652d3e96..697dfb7 100644
--- a/arch/powerpc/platforms/pseries/hotplug-cpu.c
+++ b/arch/powerpc/platforms/pseries/hotplug-cpu.c
@@ -367,6 +367,7 @@ static int dlpar_online_cpu(struct device_node *dn)
cpu_maps_update_done();
timed_topology_update(1);
find_and_online_cpu_nid(cpu);
+ register_cpu(&per_cpu(cpu_devices, cpu), cpu);
rc = device_online(get_cpu_device(cpu));
if (rc)
goto out;
@@ -541,6 +542,7 @@ static int dlpar_offline_cpu(struct device_node *dn)
rc = device_offline(get_cpu_device(cpu));
if (rc)
goto out;
+ unregister_cpu(container_of(get_cpu_device(cpu), struct cpu, dev));
cpu_maps_update_begin();
break;
@@ -599,7 +601,6 @@ static ssize_t dlpar_cpu_remove(struct device_node *dn, u32 drc_index)
return saved_rc;
}
-
pr_debug("Successfully removed CPU, drc index: %x\n", drc_index);
return 0;
}
--
2.7.4
^ permalink raw reply related
* [PATCH 2/2] powerpc/cpuidle: dynamically register/unregister cpuidle_device during hotplug
From: Pingfan Liu @ 2018-03-30 1:17 UTC (permalink / raw)
To: linuxppc-dev; +Cc: paulus, mpe, benh, hbathini
In-Reply-To: <1522372657-27490-1-git-send-email-kernelfans@gmail.com>
Now for pseries, ../cpu/cpuX is created and deleted dynamically.
Hence cpuX/cpuidle should be created and deleted dynamically.
For powernv, it is harmless to use the same method.
Signed-off-by: Pingfan Liu <kernelfans@gmail.com>
---
drivers/cpuidle/cpuidle-powernv.c | 2 ++
drivers/cpuidle/cpuidle-pseries.c | 2 ++
2 files changed, 4 insertions(+)
diff --git a/drivers/cpuidle/cpuidle-powernv.c b/drivers/cpuidle/cpuidle-powernv.c
index 1a8234e..962c944 100644
--- a/drivers/cpuidle/cpuidle-powernv.c
+++ b/drivers/cpuidle/cpuidle-powernv.c
@@ -144,6 +144,7 @@ static int powernv_cpuidle_cpu_online(unsigned int cpu)
struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
if (dev && cpuidle_get_driver()) {
+ cpuidle_register_device(dev);
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
@@ -159,6 +160,7 @@ static int powernv_cpuidle_cpu_dead(unsigned int cpu)
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
+ cpuidle_unregister_device(dev);
}
return 0;
}
diff --git a/drivers/cpuidle/cpuidle-pseries.c b/drivers/cpuidle/cpuidle-pseries.c
index 9e56bc4..a53be8a 100644
--- a/drivers/cpuidle/cpuidle-pseries.c
+++ b/drivers/cpuidle/cpuidle-pseries.c
@@ -193,6 +193,7 @@ static int pseries_cpuidle_cpu_online(unsigned int cpu)
struct cpuidle_device *dev = per_cpu(cpuidle_devices, cpu);
if (dev && cpuidle_get_driver()) {
+ cpuidle_register_device(dev);
cpuidle_pause_and_lock();
cpuidle_enable_device(dev);
cpuidle_resume_and_unlock();
@@ -208,6 +209,7 @@ static int pseries_cpuidle_cpu_dead(unsigned int cpu)
cpuidle_pause_and_lock();
cpuidle_disable_device(dev);
cpuidle_resume_and_unlock();
+ cpuidle_unregister_device(dev);
}
return 0;
}
--
2.7.4
^ permalink raw reply related
* Re: RFC on writel and writel_relaxed
From: Benjamin Herrenschmidt @ 2018-03-30 1:40 UTC (permalink / raw)
To: Sinan Kaya, David Miller
Cc: torvalds, alexander.duyck, will.deacon, arnd, jgg, David.Laight,
oohall, linuxppc-dev, linux-rdma, alexander.h.duyck, paulmck,
netdev, linus971
In-Reply-To: <29fe17e0-9978-dc43-d02c-de8fabdc66c2@codeaurora.org>
On Thu, 2018-03-29 at 09:56 -0400, Sinan Kaya wrote:
> On 3/28/2018 11:55 AM, David Miller wrote:
> > From: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> > Date: Thu, 29 Mar 2018 02:13:16 +1100
> >
> > > Let's fix all archs, it's way easier than fixing all drivers. Half of
> > > the archs are unused or dead anyway.
> >
> > Agreed.
> >
>
> I pinged most of the maintainers yesterday.
> Which arches do we care about these days?
> I have not been paying attention any other architecture besides arm64.
Thanks for going through that exercise !
Once sparc, s390, microblaze and mips reply, I think we'll have a good
coverage, maybe riscv is to put in that lot too.
Cheers,
Ben.
>
> arch status detail
> ------ ------------- ------------------------------------
> alpha question sent
> arc question sent ysato@users.sourceforge.jp will fix it.
> arm no issues
> arm64 no issues
> blackfin question sent about to be removed
> c6x question sent
> cris question sent
> frv
> h8300 question sent
> hexagon question sent
> ia64 no issues confirmed by Tony Luck
> m32r
> m68k question sent
> metag
> microblaze question sent
> mips question sent
> mn10300 question sent
> nios2 question sent
> openrisc no issues shorne@gmail.com says should no issues
> parisc no issues grantgrundler@gmail.com says most probably no problem but still looking
> powerpc no issues
> riscv question sent
> s390 question sent
> score question sent
> sh question sent
> sparc question sent
> tile question sent
> unicore32 question sent
> x86 no issues
> xtensa question sent
>
>
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: kbuild test robot @ 2018-03-30 1:43 UTC (permalink / raw)
To: Shea Levy
Cc: kbuild-all, linux-riscv, linux-kernel, linux-mips, linux-sh,
Linus Walleij, Will Deacon, Paul Mackerras, James E.J. Bottomley,
Christoph Hellwig, Geert Uytterhoeven, Catalin Marinas,
Matt Turner, Eugeniy Paltsev, uclinux-h8-devel, Vladimir Murzin,
Marc Zyngier, adi-buildroot-devel, Al Viro, Thomas Gleixner,
Richard Henderson, linux-cris-kernel, Greg Kroah-Hartman,
Ralf Baechle, Richard Kuo, Joe Perches, Andrew Morton, linux-ia64,
James Hogan, Palmer Dabbelt, Max Filippov, Oliver O'Halloran,
Deepa Dinamani, Chen Liqin, Jesper Nilsson, linux-c6x-dev,
Yoshinori Sato, David S. Miller, linux-hexagon, Helge Deller,
linux-xtensa, Albert Ou, Philippe Ombredanne, Aurelien Jacquiot,
linux-m68k, Stafford Horne, linux-metag, linux-arm-kernel,
Chris Zankel, Tony Luck, Sudip Mukherjee, Martin Schwidefsky,
Kate Stewart, Heiko Carstens, Michal Hocko, Guan Xuetao,
Lennox Wu, Rob Herring, Daniel Thompson, Florian Fainelli,
linux-snps-arc, Fenghua Yu, Kees Cook, Arnd Bergmann, Jeff Dike,
Ivan Kokshaysky, Dan Williams, linux-parisc, Rob Landley,
linux-alpha, Ley Foon Tan, Christian König, Rich Felker,
Wei Yang, David Howells, H. Peter Anvin, sparclinux, Jonas Bonn,
linux-am33-list, Richard Weinberger, x86, Russell King, Shea Levy,
Ingo Molnar, Mark Salter, user-mode-linux-devel, linux-s390,
Stefan Kristiansson, Mikael Starvik, openrisc,
user-mode-linux-user, Vlastimil Babka, Michal Simek, Vineet Gupta,
nios2-dev, linuxppc-dev
In-Reply-To: <20180328152714.6103-1-shea@shealevy.com>
[-- Attachment #1: Type: text/plain, Size: 1031 bytes --]
Hi Shea,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc7]
[cannot apply to next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shea-Levy/Extract-initrd-free-logic-from-arch-specific-code/20180330-085507
config: ia64-allnoconfig (attached as .config)
compiler: ia64-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=ia64
All warnings (new ones prefixed by >>):
warning: (IA64) selects HAVE_ARCH_FREE_INITRD_MEM which has unmet direct dependencies (BLK_DEV_INITRD)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 5949 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: Mark Greer @ 2018-03-30 2:22 UTC (permalink / raw)
To: Oliver
Cc: Mark Greer, Christophe LEROY, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, linuxppc-dev, David Gibson
In-Reply-To: <CAOSf1CFVH+OEkZCN+AYOxb863akkuw44uOENVEi=zf=QVc-UmQ@mail.gmail.com>
On Tue, Mar 20, 2018 at 10:55:07AM +1100, Oliver wrote:
> On Tue, Mar 20, 2018 at 3:02 AM, Mark Greer <mgreer@animalcreek.com> wrote:
> > On Mon, Mar 19, 2018 at 09:53:09AM +0100, Christophe LEROY wrote:
> >>
> >>
> >> Le 16/03/2018 à 22:54, Mark Greer a écrit :
> >> >When building a uImage or zImage using ppc6xx_defconfig and some other
> >> >defconfigs, the following error occurs:
> >> >
> >> > BOOTCC arch/powerpc/boot/fdt.o
> >> > In file included from arch/powerpc/boot/fdt.c:51:0:
> >> > ../arch/powerpc/boot/libfdt_env.h:10:13: error: redefinition of typedef 'uint32_t'
> >> > ../arch/powerpc/boot/types.h:21:13: note: previous declaration of 'uint32_t' was here
> >> > ../arch/powerpc/boot/libfdt_env.h:11:13: error: redefinition of typedef 'uint64_t'
> >> > ../arch/powerpc/boot/types.h:22:13: note: previous declaration of 'uint64_t' was here
> >> > ../arch/powerpc/boot/Makefile:210: recipe for target 'arch/powerpc/boot/fdt.o' failed
> >> > make[2]: *** [arch/powerpc/boot/fdt.o] Error 1
> >> >
> >> >The problem is that commit 656ad58ef19e (powerpc/boot: Add OPAL console
> >> >to epapr wrappers) adds typedefs for uint32_t and uint64_t to type.h but
> >> >doesn't remove the pre-existing (and now duplicate) typedefs from
> >> >libfdt_env.h. Fix the error by removing the duplicat typedefs from
> >> >libfdt_env.h
> >> >
> >> >CC: David Gibson <david@gibson.dropbear.id.au>
> >> >CC: Oliver O'Halloran <oohall@gmail.com>
> >> >Signed-off-by: Mark Greer <mgreer@animalcreek.com>
> >> >---
> >> >Having said all of that, commit 656ad58ef19e (powerpc/boot: Add OPAL
> >> >console to epapr wrappers) went into mainline back in 2016 so, AFAICT,
> >> >this has been broken since then. That seems unlikely so I must be
> >> >missing something... Any ideas what that is?
> >>
> >> I just compiled uImage for ppc6xx_defconfig, and I don't get such error.
> >> I looked at what gcc -E outputs, u32 is defined twice but it doesn't seems
> >> to bother GCC.
> >>
> >> What version of GCC do you use ?
> >> I tried with 5.4.0 and 4.6.3, both seems to work.
> >>
> >> Christophe
> >
> > Hi Christophe.
> >
> > That's interesting. I would expect an error regardless of version.
> >
> > I used an old 4.5.1 gcc that I had laying around (from denx, iirc).
> > I'll find a newer one and try it.
>
> Yeah that's pretty odd. It might be a bug in your specific version of
> GCC since I can't replicate it with this dumb test case:
>
> #include <stdio.h>
> typedef unsigned int u32;
>
> typedef u32 uint32_t;
> typedef u32 uint32_t;
>
> int main(void) {
> uint32_t test = 0;
> printf("%u\n", test);
> return 0;
> }
>
> Does that result in an error?
Hi Oliver. I'm very sorry for the long delay in responding.
This fail to compile too:
$ cat test.c
#include <stdio.h>
typedef unsigned int u32;
typedef u32 uint32_t;
typedef u32 uint32_t;
int main(void) {
uint32_t test = 0;
printf("%u\n", test);
return 0;
}
$
$ powerpc-linux-gnu-gcc -o test test.c
test.c:5:13: error: redefinition of typedef 'uint32_t'
test.c:4:13: note: previous declaration of 'uint32_t' was here
> > Either way, it seems to me that we should remove the duplicate definitions.
> > Do you agree?
>
> It wouldn't hurt to remove those definitions from libfdt_env.h. That
> file includes types.h directly anyway so there's not much point in
> them being there.
+1
Mark
--
^ permalink raw reply
* Re: [PATCH] powerpc/boot: Remove duplicate typedefs from libfdt_env.h
From: Mark Greer @ 2018-03-30 2:26 UTC (permalink / raw)
To: Oliver
Cc: Mark Greer, Christophe LEROY, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, linuxppc-dev, David Gibson
In-Reply-To: <20180330022250.GA20304@animalcreek.com>
On Thu, Mar 29, 2018 at 07:22:50PM -0700, Mark Greer wrote:
> On Tue, Mar 20, 2018 at 10:55:07AM +1100, Oliver wrote:
> > Yeah that's pretty odd. It might be a bug in your specific version of
> > GCC since I can't replicate it with this dumb test case:
> >
> > #include <stdio.h>
> > typedef unsigned int u32;
> >
> > typedef u32 uint32_t;
> > typedef u32 uint32_t;
> >
> > int main(void) {
> > uint32_t test = 0;
> > printf("%u\n", test);
> > return 0;
> > }
> >
> > Does that result in an error?
>
> Hi Oliver. I'm very sorry for the long delay in responding.
>
> This fail to compile too:
>
> $ cat test.c
> #include <stdio.h>
> typedef unsigned int u32;
>
> typedef u32 uint32_t;
> typedef u32 uint32_t;
>
> int main(void) {
> uint32_t test = 0;
> printf("%u\n", test);
> return 0;
> }
> $
> $ powerpc-linux-gnu-gcc -o test test.c
> test.c:5:13: error: redefinition of typedef 'uint32_t'
> test.c:4:13: note: previous declaration of 'uint32_t' was here
And I meant to add:
$ powerpc-linux-gnu-gcc --version
powerpc-linux-gnu-gcc (Sourcery G++ Lite 2010.09-55) 4.5.1
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So, yeah, its really old.
I'll get a newer one and test it.
Mark
--
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: kbuild test robot @ 2018-03-30 3:16 UTC (permalink / raw)
To: Shea Levy
Cc: kbuild-all, linux-riscv, linux-kernel, linux-mips, linux-sh,
Linus Walleij, Will Deacon, Paul Mackerras, James E.J. Bottomley,
Christoph Hellwig, Geert Uytterhoeven, Catalin Marinas,
Matt Turner, Eugeniy Paltsev, uclinux-h8-devel, Vladimir Murzin,
Marc Zyngier, adi-buildroot-devel, Al Viro, Thomas Gleixner,
Richard Henderson, linux-cris-kernel, Greg Kroah-Hartman,
Ralf Baechle, Richard Kuo, Joe Perches, Andrew Morton, linux-ia64,
James Hogan, Palmer Dabbelt, Max Filippov, Oliver O'Halloran,
Deepa Dinamani, Chen Liqin, Jesper Nilsson, linux-c6x-dev,
Yoshinori Sato, David S. Miller, linux-hexagon, Helge Deller,
linux-xtensa, Albert Ou, Philippe Ombredanne, Aurelien Jacquiot,
linux-m68k, Stafford Horne, linux-metag, linux-arm-kernel,
Chris Zankel, Tony Luck, Sudip Mukherjee, Martin Schwidefsky,
Kate Stewart, Heiko Carstens, Michal Hocko, Guan Xuetao,
Lennox Wu, Rob Herring, Daniel Thompson, Florian Fainelli,
linux-snps-arc, Fenghua Yu, Kees Cook, Arnd Bergmann, Jeff Dike,
Ivan Kokshaysky, Dan Williams, linux-parisc, Rob Landley,
linux-alpha, Ley Foon Tan, Christian König, Rich Felker,
Wei Yang, David Howells, H. Peter Anvin, sparclinux, Jonas Bonn,
linux-am33-list, Richard Weinberger, x86, Russell King, Shea Levy,
Ingo Molnar, Mark Salter, user-mode-linux-devel, linux-s390,
Stefan Kristiansson, Mikael Starvik, openrisc,
user-mode-linux-user, Vlastimil Babka, Michal Simek, Vineet Gupta,
nios2-dev, linuxppc-dev
In-Reply-To: <20180328152714.6103-1-shea@shealevy.com>
[-- Attachment #1: Type: text/plain, Size: 1038 bytes --]
Hi Shea,
Thank you for the patch! Perhaps something to improve:
[auto build test WARNING on linus/master]
[also build test WARNING on v4.16-rc7]
[cannot apply to next-20180329]
[if your patch is applied to the wrong git tree, please drop us a note to help improve the system]
url: https://github.com/0day-ci/linux/commits/Shea-Levy/Extract-initrd-free-logic-from-arch-specific-code/20180330-085507
config: m32r-m32104ut_defconfig (attached as .config)
compiler: m32r-linux-gcc (GCC) 7.2.0
reproduce:
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross
chmod +x ~/bin/make.cross
# save the attached .config to linux build tree
make.cross ARCH=m32r
All warnings (new ones prefixed by >>):
warning: (M32R) selects HAVE_ARCH_FREE_INITRD_MEM which has unmet direct dependencies (BLK_DEV_INITRD)
---
0-DAY kernel test infrastructure Open Source Technology Center
https://lists.01.org/pipermail/kbuild-all Intel Corporation
[-- Attachment #2: .config.gz --]
[-- Type: application/gzip, Size: 11473 bytes --]
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Pavel Machek @ 2018-03-30 7:55 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, mhocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <1521736598-12812-1-git-send-email-blackzert@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 657 bytes --]
Hi!
> Current implementation doesn't randomize address returned by mmap.
> All the entropy ends with choosing mmap_base_addr at the process
> creation. After that mmap build very predictable layout of address
> space. It allows to bypass ASLR in many cases. This patch make
> randomization of address on any mmap call.
How will this interact with people debugging their application, and
getting different behaviours based on memory layout?
strace, strace again, get different results?
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: kexec_file: Fix error code when trying to load kdump kernel
From: Dave Young @ 2018-03-30 8:02 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linuxppc-dev, Michael Ellerman, kexec, linux-kernel,
Michal Suchánek
In-Reply-To: <20180329190543.25118-1-bauerman@linux.vnet.ibm.com>
On 03/29/18 at 04:05pm, Thiago Jung Bauermann wrote:
> kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
> returns -ENOTSUPP in that case.
>
> I've recently learned that this errno is internal to the kernel and isn't
> supposed to be exposed to userspace. Therefore, change to -EOPNOTSUPP which
> is defined in an uapi header.
>
> This does indeed make kexec-tools happier. Before the patch, on ppc64le:
>
> # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
> kexec_file_load failed: Unknown error 524
>
> After the patch:
>
> # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
> kexec_file_load failed: Operation not supported
>
> Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()")
> Reported-by: Dave Young <dyoung@redhat.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
> ---
> arch/powerpc/kernel/machine_kexec_file_64.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> This is a minor issue, but since it's a simple patch it might be worth
> applying it to stable branches.
>
> This is the kexec-tools thread where this problem was brought up:
>
> https://lists.infradead.org/pipermail/kexec/2018-March/020346.html
>
> And this is an instance of a similar fix being applied elsewhere in the
> kernel, for the same reasons:
>
> https://patchwork.kernel.org/patch/8490791/
>
> The test shown in the commit log was made using Hari Bathini's patch
> adding kexec_file_load() support to kexec-tools in ppc64.
>
> diff --git a/arch/powerpc/kernel/machine_kexec_file_64.c b/arch/powerpc/kernel/machine_kexec_file_64.c
> index e4395f937d63..45e0b7d5f200 100644
> --- a/arch/powerpc/kernel/machine_kexec_file_64.c
> +++ b/arch/powerpc/kernel/machine_kexec_file_64.c
> @@ -43,7 +43,7 @@ int arch_kexec_kernel_image_probe(struct kimage *image, void *buf,
>
> /* We don't support crash kernels yet. */
> if (image->type == KEXEC_TYPE_CRASH)
> - return -ENOTSUPP;
> + return -EOPNOTSUPP;
>
> for (i = 0; i < ARRAY_SIZE(kexec_file_loaders); i++) {
> fops = kexec_file_loaders[i];
>
>
> _______________________________________________
> kexec mailing list
> kexec@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/kexec
Reviewed-by: Dave Young <dyoung@redhat.com>
Thanks
Dave
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Ilya Smith @ 2018-03-30 9:07 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <20180330075508.GA21798@amd>
Hi
> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> Hi!
>=20
>> Current implementation doesn't randomize address returned by mmap.
>> All the entropy ends with choosing mmap_base_addr at the process
>> creation. After that mmap build very predictable layout of address
>> space. It allows to bypass ASLR in many cases. This patch make
>> randomization of address on any mmap call.
>=20
> How will this interact with people debugging their application, and
> getting different behaviours based on memory layout?
>=20
> strace, strace again, get different results?
>=20
Honestly I=E2=80=99m confused about your question. If the only one way =
for debugging=20
application is to use predictable mmap behaviour, then something went =
wrong in=20
this live and we should stop using computers at all.
Thanks,
Ilya
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Pavel Machek @ 2018-03-30 9:57 UTC (permalink / raw)
To: Ilya Smith
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <95EECC28-7349-4FB4-88BF-26E4CF087A0B@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 1199 bytes --]
On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
> Hi
>
> > On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
> >
> > Hi!
> >
> >> Current implementation doesn't randomize address returned by mmap.
> >> All the entropy ends with choosing mmap_base_addr at the process
> >> creation. After that mmap build very predictable layout of address
> >> space. It allows to bypass ASLR in many cases. This patch make
> >> randomization of address on any mmap call.
> >
> > How will this interact with people debugging their application, and
> > getting different behaviours based on memory layout?
> >
> > strace, strace again, get different results?
> >
>
> Honestly I’m confused about your question. If the only one way for debugging
> application is to use predictable mmap behaviour, then something went wrong in
> this live and we should stop using computers at all.
I'm not saying "only way". I'm saying one way, and you are breaking
that. There's advanced stuff like debuggers going "back in time".
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 181 bytes --]
^ permalink raw reply
* Re: [RFC] new SYSCALL_DEFINE/COMPAT_SYSCALL_DEFINE wrappers
From: Ingo Molnar @ 2018-03-30 10:58 UTC (permalink / raw)
To: John Paul Adrian Glaubitz
Cc: Linus Torvalds, Al Viro, Dominik Brodowski,
Linux Kernel Mailing List, Arnd Bergmann, linux-arch,
Ralf Baechle, James Hogan, linux-mips, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, ppc-dev, Martin Schwidefsky,
Heiko Carstens, linux-s390, David S . Miller, sparclinux,
Ingo Molnar, Jiri Slaby, the arch/x86 maintainers
In-Reply-To: <7753539f-c72d-9e5a-eb2d-939e5514404b@physik.fu-berlin.de>
* John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> On 03/27/2018 12:40 PM, Linus Torvalds wrote:
> > On Mon, Mar 26, 2018 at 4:37 PM, John Paul Adrian Glaubitz
> > <glaubitz@physik.fu-berlin.de> wrote:
> >>
> >> What about a tarball with a minimal Debian x32 chroot? Then you can
> >> install interesting packages you would like to test yourself.
> >
> > That probably works fine.
>
> I just created a fresh Debian x32 unstable chroot using this command:
>
> $ debootstrap --no-check-gpg --variant=minbase --arch=x32 unstable debian-x32-unstable http://ftp.ports.debian.org/debian-ports
>
> It can be downloaded from my Debian webspace along checksum files for
> verification:
>
> > https://people.debian.org/~glaubitz/chroots/
>
> Let me know if you run into any issues.
Here's the direct download link:
$ wget https://people.debian.org/~glaubitz/chroots/debian-x32-unstable.tar.gz
Checksum should be:
$ sha256sum debian-x32-unstable.tar.gz
010844bcc76bd1a3b7a20fe47f7067ed8e429a84fa60030a2868626e8fa7ec3b debian-x32-unstable.tar.gz
Seems to work fine here (on a distro kernel) even if I extract all the files as a
non-root user and do:
~/s/debian-x32-unstable> fakechroot /usr/sbin/chroot . /usr/bin/dpkg -l | tail -2
ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
ii util-linux:x32 2.31.1-0.5 x32 miscellaneous system utilities
ii zlib1g:x32 1:1.2.8.dfsg-5 x32 compression library - runtime
So that 'dpkg' instance appears to be running inside the chroot environment and is
listing x32 installed packages.
Although I did get this warning:
ERROR: ld.so: object 'libfakechroot.so' from LD_PRELOAD cannot be preloaded (cannot open shared object file): ignored.
Even with that warning, is still still a sufficiently complex test of x32 syscall
code paths?
BTW., "fakechroot /usr/sbin/chroot ." crashes instead of giving me a bash shell.
Thanks,
Ingo
^ permalink raw reply
* Re: [RFC PATCH v2 0/2] Randomization of address chosen by mmap.
From: Ilya Smith @ 2018-03-30 11:10 UTC (permalink / raw)
To: Pavel Machek
Cc: rth, ink, mattst88, vgupta, linux, tony.luck, fenghua.yu, jhogan,
ralf, jejb, Helge Deller, benh, paulus, mpe, schwidefsky,
heiko.carstens, ysato, dalias, davem, tglx, mingo, hpa, x86, nyc,
viro, arnd, gregkh, deepa.kernel, Michal Hocko, hughd, kstewart,
pombredanne, akpm, steve.capper, punit.agrawal, paul.burton,
aneesh.kumar, npiggin, keescook, bhsharma, riel, nitin.m.gupta,
kirill.shutemov, dan.j.williams, jack, ross.zwisler, jglisse,
willy, aarcange, oleg, linux-alpha, linux-kernel, linux-snps-arc,
linux-arm-kernel, linux-ia64, linux-metag, linux-mips,
linux-parisc, linuxppc-dev, linux-s390, linux-sh, sparclinux,
linux-mm
In-Reply-To: <20180330095735.GA15641@amd>
> On 30 Mar 2018, at 12:57, Pavel Machek <pavel@ucw.cz> wrote:
>=20
> On Fri 2018-03-30 12:07:58, Ilya Smith wrote:
>> Hi
>>=20
>>> On 30 Mar 2018, at 10:55, Pavel Machek <pavel@ucw.cz> wrote:
>>>=20
>>> Hi!
>>>=20
>>>> Current implementation doesn't randomize address returned by mmap.
>>>> All the entropy ends with choosing mmap_base_addr at the process
>>>> creation. After that mmap build very predictable layout of address
>>>> space. It allows to bypass ASLR in many cases. This patch make
>>>> randomization of address on any mmap call.
>>>=20
>>> How will this interact with people debugging their application, and
>>> getting different behaviours based on memory layout?
>>>=20
>>> strace, strace again, get different results?
>>>=20
>>=20
>> Honestly I=E2=80=99m confused about your question. If the only one =
way for debugging=20
>> application is to use predictable mmap behaviour, then something went =
wrong in=20
>> this live and we should stop using computers at all.
>=20
> I'm not saying "only way". I'm saying one way, and you are breaking
> that. There's advanced stuff like debuggers going "back in time".
>=20
Correct me if I wrong, when you run gdb for instance and try to debug =
some=20
application, gdb will disable randomization. This behaviour works with =
gdb=20
command: set disable-randomization on. As I know, gdb remove flag =
PF_RANDOMIZE=20
from current personality thats how it disables ASLR for debugging =
process.=20
According to my patch, flag PF_RANDOMIZE is checked before calling=20
unmapped_area_random. So I don=E2=80=99t breaking debugging. If you =
talking about the=20
case, when your application crashes under customer environment and you =
want to
debug it; in this case layout of memory is what you don=E2=80=99t =
control at all and=20
you have to understand what is where. So for debugging memory process =
layout is
not what you should care of.
Thanks,
Ilya
^ permalink raw reply
* Re: [PATCH] Extract initrd free logic from arch-specific code.
From: Ingo Molnar @ 2018-03-30 11:15 UTC (permalink / raw)
To: Shea Levy
Cc: linux-riscv, linux-kernel, Christoph Hellwig, Richard Henderson,
Ivan Kokshaysky, Matt Turner, Vineet Gupta, Russell King,
Catalin Marinas, Will Deacon, Mark Salter, Aurelien Jacquiot,
Mikael Starvik, Jesper Nilsson, Yoshinori Sato, Richard Kuo,
Tony Luck, Fenghua Yu, Geert Uytterhoeven, James Hogan,
Michal Simek, Ralf Baechle, David Howells, Ley Foon Tan,
Jonas Bonn, Stefan Kristiansson, Stafford Horne,
James E.J. Bottomley, Helge Deller, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Palmer Dabbelt, Albert Ou,
Martin Schwidefsky, Heiko Carstens, Chen Liqin, Lennox Wu,
Rich Felker, David S. Miller, Jeff Dike, Richard Weinberger,
Guan Xuetao, Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Chris Zankel, Max Filippov, Kate Stewart, Greg Kroah-Hartman,
Philippe Ombredanne, Eugeniy Paltsev, Al Viro, Vladimir Murzin,
Linus Walleij, Michal Hocko, Andrew Morton, Sudip Mukherjee,
Marc Zyngier, Rob Herring, Kees Cook, Vlastimil Babka,
Balbir Singh, Christophe Leroy, Joe Perches,
Oliver O'Halloran, Dan Williams, Wei Yang,
Christian König, Arnd Bergmann, Deepa Dinamani,
Daniel Thompson, Rob Landley, Florian Fainelli, linux-alpha,
linux-snps-arc, linux-arm-kernel, adi-buildroot-devel,
linux-c6x-dev, linux-cris-kernel, uclinux-h8-devel, linux-hexagon,
linux-ia64, linux-m68k, linux-metag, linux-mips, linux-am33-list,
nios2-dev, openrisc, linux-parisc, linuxppc-dev, linux-s390,
linux-sh, sparclinux, user-mode-linux-devel, user-mode-linux-user,
linux-xtensa
In-Reply-To: <20180328152714.6103-1-shea@shealevy.com>
* Shea Levy <shea@shealevy.com> wrote:
> Now only those architectures that have custom initrd free requirements
> need to define free_initrd_mem.
>
> Signed-off-by: Shea Levy <shea@shealevy.com>
Please put the Kconfig symbol name this patch introduces both into the title, so
that people know what to grep for.
> ---
> arch/alpha/mm/init.c | 8 --------
> arch/arc/mm/init.c | 7 -------
> arch/arm/Kconfig | 1 +
> arch/arm64/Kconfig | 1 +
> arch/blackfin/Kconfig | 1 +
> arch/c6x/mm/init.c | 7 -------
> arch/cris/Kconfig | 1 +
> arch/frv/mm/init.c | 11 -----------
> arch/h8300/mm/init.c | 7 -------
> arch/hexagon/Kconfig | 1 +
> arch/ia64/Kconfig | 1 +
> arch/m32r/Kconfig | 1 +
> arch/m32r/mm/init.c | 11 -----------
> arch/m68k/mm/init.c | 7 -------
> arch/metag/Kconfig | 1 +
> arch/microblaze/mm/init.c | 7 -------
> arch/mips/Kconfig | 1 +
> arch/mn10300/Kconfig | 1 +
> arch/nios2/mm/init.c | 7 -------
> arch/openrisc/mm/init.c | 7 -------
> arch/parisc/mm/init.c | 7 -------
> arch/powerpc/mm/mem.c | 7 -------
> arch/riscv/mm/init.c | 6 ------
> arch/s390/Kconfig | 1 +
> arch/score/Kconfig | 1 +
> arch/sh/mm/init.c | 7 -------
> arch/sparc/Kconfig | 1 +
> arch/tile/Kconfig | 1 +
> arch/um/kernel/mem.c | 7 -------
> arch/unicore32/Kconfig | 1 +
> arch/x86/Kconfig | 1 +
> arch/xtensa/Kconfig | 1 +
> init/initramfs.c | 7 +++++++
> usr/Kconfig | 4 ++++
> 34 files changed, 28 insertions(+), 113 deletions(-)
Please also put it into Documentation/features/.
> diff --git a/usr/Kconfig b/usr/Kconfig
> index 43658b8a975e..7a94f6df39bf 100644
> --- a/usr/Kconfig
> +++ b/usr/Kconfig
> @@ -233,3 +233,7 @@ config INITRAMFS_COMPRESSION
> default ".lzma" if RD_LZMA
> default ".bz2" if RD_BZIP2
> default ""
> +
> +config HAVE_ARCH_FREE_INITRD_MEM
> + bool
> + default n
Help text would be nice, to tell arch maintainers what the purpose of this switch
is.
Also, a nit, I think this should be named "ARCH_HAS_FREE_INITRD_MEM", which is the
dominant pattern:
triton:~/tip> git grep 'select.*ARCH' arch/x86/Kconfig* | cut -f2 | cut -d_ -f1-2 | sort | uniq -c | sort -n
...
2 select ARCH_USES
2 select ARCH_WANTS
3 select ARCH_MIGHT
3 select ARCH_WANT
4 select ARCH_SUPPORTS
4 select ARCH_USE
16 select HAVE_ARCH
23 select ARCH_HAS
It also reads nicely in English:
"arch has free_initrd_mem()"
While the other makes little sense:
"have arch free_initrd_mem()"
?
Thanks,
Ingo
^ permalink raw reply
* Re: [PATCH] powerpc: kexec_file: Fix error code when trying to load kdump kernel
From: Simon Horman @ 2018-03-30 6:27 UTC (permalink / raw)
To: Thiago Jung Bauermann
Cc: linuxppc-dev, Michael Ellerman, kexec, linux-kernel,
Michal Suchánek, Dave Young
In-Reply-To: <20180329190543.25118-1-bauerman@linux.vnet.ibm.com>
On Thu, Mar 29, 2018 at 04:05:43PM -0300, Thiago Jung Bauermann wrote:
> kexec_file_load() on powerpc doesn't support kdump kernels yet, so it
> returns -ENOTSUPP in that case.
>
> I've recently learned that this errno is internal to the kernel and isn't
> supposed to be exposed to userspace. Therefore, change to -EOPNOTSUPP which
> is defined in an uapi header.
>
> This does indeed make kexec-tools happier. Before the patch, on ppc64le:
>
> # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
> kexec_file_load failed: Unknown error 524
>
> After the patch:
>
> # ~bauermann/src/kexec-tools/build/sbin/kexec -s -p /boot/vmlinuz
> kexec_file_load failed: Operation not supported
>
> Fixes: a0458284f062 ("powerpc: Add support code for kexec_file_load()")
> Reported-by: Dave Young <dyoung@redhat.com>
> Signed-off-by: Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>
Reviewed-by: Simon Horman <horms@verge.net.au>
^ permalink raw reply
* [PATCH] powerpc/kvm: Fix guest boot issue DAWR cpu feature
From: Aneesh Kumar K.V @ 2018-03-30 11:57 UTC (permalink / raw)
To: benh, paulus, mpe, Michael Neuling; +Cc: linuxppc-dev, Aneesh Kumar K.V
SLOF check the 'sc 1' support by issuing a hcall with H_SET_DABR. With
recent patch to make the hcall return H_UNSUPPORTED, we get guest boot
failures. SLOF can work with the hcall failure H_HARDWARE for the above
hcall. Switch the return value to H_HARDWARE instead of H_UNSUPPORTED so that
we don't break the guest boot.
Fixes: e8ebedbf ("KVM: PPC: Book3S HV: Return error from h_set_dabr() on POWER9")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.ibm.com>
---
arch/powerpc/kvm/book3s_hv_rmhandlers.S | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kvm/book3s_hv_rmhandlers.S b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
index c4c1b169826a..fdd7350d6c87 100644
--- a/arch/powerpc/kvm/book3s_hv_rmhandlers.S
+++ b/arch/powerpc/kvm/book3s_hv_rmhandlers.S
@@ -2576,7 +2576,7 @@ END_FTR_SECTION_IFSET(CPU_FTR_ARCH_207S)
2:
BEGIN_FTR_SECTION
/* POWER9 with disabled DAWR */
- li r3, H_UNSUPPORTED
+ li r3, H_HARDWARE
blr
END_FTR_SECTION_IFCLR(CPU_FTR_DAWR)
/* Emulate H_SET_DABR/X on P8 for the sake of compat mode guests */
--
2.14.3
^ permalink raw reply related
* [PATCH V3] powerpc/mm/hugetlb: initialize the pagetable cache correctly for hugetlb
From: Aneesh Kumar K.V @ 2018-03-30 12:04 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
With 64k page size, we have hugetlb pte entries at the pmd and pud level for
book3s64. We don't need to create a separate page table cache for that. With 4k
we need to make sure hugepd page table cache for 16M is placed at PUD level
and 16G at the PGD level.
Simplify all these by not using HUGEPD_PD_SHIFT which is confusing for book3s64.
Without this patch, with 64k page size we create pagetable caches with shift
value 10 and 7 which are not used at all.
Fixes: 419df06eea5b ("powerpc: Reduce the PTE_INDEX_SIZE")
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/hugetlbpage.c | 18 +++++++++++++-----
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/mm/hugetlbpage.c b/arch/powerpc/mm/hugetlbpage.c
index f4153f21d214..99cf86096970 100644
--- a/arch/powerpc/mm/hugetlbpage.c
+++ b/arch/powerpc/mm/hugetlbpage.c
@@ -122,9 +122,6 @@ static int __hugepte_alloc(struct mm_struct *mm, hugepd_t *hpdp,
#if defined(CONFIG_PPC_FSL_BOOK3E) || defined(CONFIG_PPC_8xx)
#define HUGEPD_PGD_SHIFT PGDIR_SHIFT
#define HUGEPD_PUD_SHIFT PUD_SHIFT
-#else
-#define HUGEPD_PGD_SHIFT PUD_SHIFT
-#define HUGEPD_PUD_SHIFT PMD_SHIFT
#endif
/*
@@ -670,15 +667,26 @@ static int __init hugetlbpage_init(void)
shift = mmu_psize_to_shift(psize);
- if (add_huge_page_size(1ULL << shift) < 0)
+#ifdef CONFIG_PPC_BOOK3S_64
+ if (shift > PGDIR_SHIFT)
continue;
-
+ else if (shift > PUD_SHIFT)
+ pdshift = PGDIR_SHIFT;
+ else if (shift > PMD_SHIFT)
+ pdshift = PUD_SHIFT;
+ else
+ pdshift = PMD_SHIFT;
+#else
if (shift < HUGEPD_PUD_SHIFT)
pdshift = PMD_SHIFT;
else if (shift < HUGEPD_PGD_SHIFT)
pdshift = PUD_SHIFT;
else
pdshift = PGDIR_SHIFT;
+#endif
+
+ if (add_huge_page_size(1ULL << shift) < 0)
+ continue;
/*
* if we have pdshift and shift value same, we don't
* use pgt cache for hugepd.
--
2.14.3
^ permalink raw reply related
* [PATCH 1/2] powerpc/mm/radix: Parse disable_radix commandline correctly.
From: Aneesh Kumar K.V @ 2018-03-30 12:09 UTC (permalink / raw)
To: benh, paulus, mpe; +Cc: linuxppc-dev, Aneesh Kumar K.V
From: "Aneesh Kumar K.V" <aneesh.kumar@linux.vnet.ibm.com>
kernel parameter disable_radix takes different options
disable_radix=yes|no|1|0 or just disable_radix. When using the later format
we get below error.
`Malformed early option 'disable_radix'`
Signed-off-by: Aneesh Kumar K.V <aneesh.kumar@linux.vnet.ibm.com>
---
arch/powerpc/mm/init_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/mm/init_64.c b/arch/powerpc/mm/init_64.c
index fdb424a29f03..9c9f8dde31c3 100644
--- a/arch/powerpc/mm/init_64.c
+++ b/arch/powerpc/mm/init_64.c
@@ -372,7 +372,7 @@ static int __init parse_disable_radix(char *p)
{
bool val;
- if (strlen(p) == 0)
+ if (!p)
val = true;
else if (kstrtobool(p, &val))
return -EINVAL;
--
2.14.3
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox