<feed xmlns='http://www.w3.org/2005/Atom'>
<title>user/sven/linux.git/arch, branch v5.4.62</title>
<subtitle>Linux Kernel
</subtitle>
<id>https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.62</id>
<link rel='self' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v5.4.62'/>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/'/>
<updated>2020-09-03T09:27:10Z</updated>
<entry>
<title>kbuild: fix broken builds because of GZIP,BZIP2,LZOP variables</title>
<updated>2020-09-03T09:27:10Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-08T09:59:44Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=c98b6ebd9b555db3ddc7751d31e5e424c1c81245'/>
<id>urn:sha1:c98b6ebd9b555db3ddc7751d31e5e424c1c81245</id>
<content type='text'>
commit e4a42c82e943b97ce124539fcd7a47445b43fa0d upstream.

Redefine GZIP, BZIP2, LZOP variables as KGZIP, KBZIP2, KLZOP resp.
GZIP, BZIP2, LZOP env variables are reserved by the tools. The original
attempt to redefine them internally doesn't work in makefiles/scripts
intercall scenarios, e.g., "make GZIP=gzip bindeb-pkg" and results in
broken builds. There can be other broken build commands because of this,
so the universal solution is to use non-reserved env variables for the
compression tools.

Fixes: 8dfb61dcbace ("kbuild: add variables for compression tools")
Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Tested-by: Guenter Roeck &lt;linux@roeck-us.net&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Cc: Matthias Maennich &lt;maennich@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>kbuild: add variables for compression tools</title>
<updated>2020-09-03T09:27:10Z</updated>
<author>
<name>Denis Efremov</name>
<email>efremov@linux.com</email>
</author>
<published>2020-06-05T07:39:55Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=37432a83faab68c0bc89d6a4395ff063eaa14f3b'/>
<id>urn:sha1:37432a83faab68c0bc89d6a4395ff063eaa14f3b</id>
<content type='text'>
commit 8dfb61dcbaceb19a5ded5e9c9dcf8d05acc32294 upstream.

Allow user to use alternative implementations of compression tools,
such as pigz, pbzip2, pxz. For example, multi-threaded tools to
speed up the build:
$ make GZIP=pigz BZIP2=pbzip2

Variables _GZIP, _BZIP2, _LZOP are used internally because original env
vars are reserved by the tools. The use of GZIP in gzip tool is obsolete
since 2015. However, alternative implementations (e.g., pigz) still rely
on it. BZIP2, BZIP, LZOP vars are not obsolescent.

The credit goes to @grsecurity.

As a sidenote, for multi-threaded lzma, xz compression one can use:
$ export XZ_OPT="--threads=0"

Signed-off-by: Denis Efremov &lt;efremov@linux.com&gt;
Signed-off-by: Masahiro Yamada &lt;masahiroy@kernel.org&gt;
Signed-off-by: Matthias Maennich &lt;maennich@google.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>x86/hotplug: Silence APIC only after all interrupts are migrated</title>
<updated>2020-09-03T09:27:06Z</updated>
<author>
<name>Ashok Raj</name>
<email>ashok.raj@intel.com</email>
</author>
<published>2020-08-27T04:12:10Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=1adf8c19f974b210c243f96cb4d694497f96506d'/>
<id>urn:sha1:1adf8c19f974b210c243f96cb4d694497f96506d</id>
<content type='text'>
commit 52d6b926aabc47643cd910c85edb262b7f44c168 upstream.

There is a race when taking a CPU offline. Current code looks like this:

native_cpu_disable()
{
	...
	apic_soft_disable();
	/*
	 * Any existing set bits for pending interrupt to
	 * this CPU are preserved and will be sent via IPI
	 * to another CPU by fixup_irqs().
	 */
	cpu_disable_common();
	{
		....
		/*
		 * Race window happens here. Once local APIC has been
		 * disabled any new interrupts from the device to
		 * the old CPU are lost
		 */
		fixup_irqs(); // Too late to capture anything in IRR.
		...
	}
}

The fix is to disable the APIC *after* cpu_disable_common().

Testing was done with a USB NIC that provided a source of frequent
interrupts. A script migrated interrupts to a specific CPU and
then took that CPU offline.

Fixes: 60dcaad5736f ("x86/hotplug: Silence APIC and NMI when CPU is dead")
Reported-by: Evan Green &lt;evgreen@chromium.org&gt;
Signed-off-by: Ashok Raj &lt;ashok.raj@intel.com&gt;
Signed-off-by: Thomas Gleixner &lt;tglx@linutronix.de&gt;
Tested-by: Mathias Nyman &lt;mathias.nyman@linux.intel.com&gt;
Tested-by: Evan Green &lt;evgreen@chromium.org&gt;
Reviewed-by: Evan Green &lt;evgreen@chromium.org&gt;
Cc: stable@vger.kernel.org
Link: https://lore.kernel.org/lkml/875zdarr4h.fsf@nanos.tec.linutronix.de/
Link: https://lore.kernel.org/r/1598501530-45821-1-git-send-email-ashok.raj@intel.com
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>powerpc/perf: Fix crashes with generic_compat_pmu &amp; BHRB</title>
<updated>2020-09-03T09:27:05Z</updated>
<author>
<name>Alexey Kardashevskiy</name>
<email>aik@ozlabs.ru</email>
</author>
<published>2020-06-02T02:56:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=df2a6a4a9d688e29ee4847871451d48248b4c89f'/>
<id>urn:sha1:df2a6a4a9d688e29ee4847871451d48248b4c89f</id>
<content type='text'>
commit b460b512417ae9c8b51a3bdcc09020cd6c60ff69 upstream.

The bhrb_filter_map ("The Branch History Rolling Buffer") callback is
only defined in raw CPUs' power_pmu structs. The "architected" CPUs
use generic_compat_pmu, which does not have this callback, and crashes
occur if a user tries to enable branch stack for an event.

This add a NULL pointer check for bhrb_filter_map() which behaves as
if the callback returned an error.

This does not add the same check for config_bhrb() as the only caller
checks for cpuhw-&gt;bhrb_users which remains zero if bhrb_filter_map==0.

Fixes: be80e758d0c2 ("powerpc/perf: Add generic compat mode pmu driver")
Cc: stable@vger.kernel.org # v5.2+
Signed-off-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Reviewed-by: Madhavan Srinivasan &lt;maddy@linux.ibm.com&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/20200602025612.62707-1-aik@ozlabs.ru
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: vdso32: make vdso32 install conditional</title>
<updated>2020-09-03T09:27:05Z</updated>
<author>
<name>Frank van der Linden</name>
<email>fllinden@amazon.com</email>
</author>
<published>2020-08-27T23:40:12Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7ded78a8c89ecd69de8b57d420f71e524df0c17e'/>
<id>urn:sha1:7ded78a8c89ecd69de8b57d420f71e524df0c17e</id>
<content type='text'>
commit 5d28ba5f8a0cfa3a874fa96c33731b8fcd141b3a upstream.

vdso32 should only be installed if CONFIG_COMPAT_VDSO is enabled,
since it's not even supposed to be compiled otherwise, and arm64
builds without a 32bit crosscompiler will fail.

Fixes: 8d75785a8142 ("ARM64: vdso32: Install vdso32 from vdso_install")
Signed-off-by: Frank van der Linden &lt;fllinden@amazon.com&gt;
Cc: stable@vger.kernel.org [5.4+]
Link: https://lore.kernel.org/r/20200827234012.19757-1-fllinden@amazon.com
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Greg Kroah-Hartman &lt;gregkh@linuxfoundation.org&gt;

</content>
</entry>
<entry>
<title>arm64: Allow booting of late CPUs affected by erratum 1418040</title>
<updated>2020-09-03T09:27:01Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-07-31T17:38:24Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=2f4b202eb1b127300859f03fdb5afbe9c3cab7e8'/>
<id>urn:sha1:2f4b202eb1b127300859f03fdb5afbe9c3cab7e8</id>
<content type='text'>
[ Upstream commit bf87bb0881d0f59181fe3bbcf29c609f36483ff8 ]

As we can now switch from a system that isn't affected by 1418040
to a system that globally is affected, let's allow affected CPUs
to come in at a later time.

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Tested-by: Sai Prakash Ranjan &lt;saiprakash.ranjan@codeaurora.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Reviewed-by: Suzuki K Poulose &lt;suzuki.poulose@arm.com&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Link: https://lore.kernel.org/r/20200731173824.107480-3-maz@kernel.org
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: Move handling of erratum 1418040 into C code</title>
<updated>2020-09-03T09:27:01Z</updated>
<author>
<name>Marc Zyngier</name>
<email>maz@kernel.org</email>
</author>
<published>2020-07-31T17:38:23Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=82b05f0838aa43281782cac2fb58c29144c66643'/>
<id>urn:sha1:82b05f0838aa43281782cac2fb58c29144c66643</id>
<content type='text'>
[ Upstream commit d49f7d7376d0c0daf8680984a37bd07581ac7d38 ]

Instead of dealing with erratum 1418040 on each entry and exit,
let's move the handling to __switch_to() instead, which has
several advantages:

- It can be applied when it matters (switching between 32 and 64
  bit tasks).
- It is written in C (yay!)
- It can rely on static keys rather than alternatives

Signed-off-by: Marc Zyngier &lt;maz@kernel.org&gt;
Tested-by: Sai Prakash Ranjan &lt;saiprakash.ranjan@codeaurora.org&gt;
Reviewed-by: Stephen Boyd &lt;swboyd@chromium.org&gt;
Acked-by: Will Deacon &lt;will@kernel.org&gt;
Link: https://lore.kernel.org/r/20200731173824.107480-2-maz@kernel.org
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>powerpc/perf: Fix soft lockups due to missed interrupt accounting</title>
<updated>2020-09-03T09:27:01Z</updated>
<author>
<name>Athira Rajeev</name>
<email>atrajeev@linux.vnet.ibm.com</email>
</author>
<published>2020-08-06T12:46:32Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=7d44b707aaff05630bc6b5c5b497e696730a15e3'/>
<id>urn:sha1:7d44b707aaff05630bc6b5c5b497e696730a15e3</id>
<content type='text'>
[ Upstream commit 17899eaf88d689529b866371344c8f269ba79b5f ]

Performance monitor interrupt handler checks if any counter has
overflown and calls record_and_restart() in core-book3s which invokes
perf_event_overflow() to record the sample information. Apart from
creating sample, perf_event_overflow() also does the interrupt and
period checks via perf_event_account_interrupt().

Currently we record information only if the SIAR (Sampled Instruction
Address Register) valid bit is set (using siar_valid() check) and
hence the interrupt check.

But it is possible that we do sampling for some events that are not
generating valid SIAR, and hence there is no chance to disable the
event if interrupts are more than max_samples_per_tick. This leads to
soft lockup.

Fix this by adding perf_event_account_interrupt() in the invalid SIAR
code path for a sampling event. ie if SIAR is invalid, just do
interrupt check and don't record the sample information.

Reported-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Signed-off-by: Athira Rajeev &lt;atrajeev@linux.vnet.ibm.com&gt;
Tested-by: Alexey Kardashevskiy &lt;aik@ozlabs.ru&gt;
Signed-off-by: Michael Ellerman &lt;mpe@ellerman.id.au&gt;
Link: https://lore.kernel.org/r/1596717992-7321-1-git-send-email-atrajeev@linux.vnet.ibm.com
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>s390/numa: set node distance to LOCAL_DISTANCE</title>
<updated>2020-09-03T09:26:50Z</updated>
<author>
<name>Sasha Levin</name>
<email>sashal@kernel.org</email>
</author>
<published>2020-08-28T18:20:57Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=a0cfda9cb3a135d78cdda63b390adfa9d86b7dfa'/>
<id>urn:sha1:a0cfda9cb3a135d78cdda63b390adfa9d86b7dfa</id>
<content type='text'>
[ Upstream commit 535e4fc623fab2e09a0653fc3a3e17f382ad0251 ]

The node distance is hardcoded to 0, which causes a trouble
for some user-level applications. In particular, "libnuma"
expects the distance of a node to itself as LOCAL_DISTANCE.
This update removes the offending node distance override.

Cc: &lt;stable@vger.kernel.org&gt; # 4.4
Fixes: 3a368f742da1 ("s390/numa: add core infrastructure")
Signed-off-by: Alexander Gordeev &lt;agordeev@linux.ibm.com&gt;
Signed-off-by: Heiko Carstens &lt;hca@linux.ibm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
<entry>
<title>arm64: Fix __cpu_logical_map undefined issue</title>
<updated>2020-09-03T09:26:49Z</updated>
<author>
<name>Kefeng Wang</name>
<email>wangkefeng.wang@huawei.com</email>
</author>
<published>2020-07-27T15:29:38Z</published>
<link rel='alternate' type='text/html' href='https://git.stealer.net/cgit.cgi/user/sven/linux.git/commit/?id=da56eb03ea94fe6236be8ea68be06e78077d3a65'/>
<id>urn:sha1:da56eb03ea94fe6236be8ea68be06e78077d3a65</id>
<content type='text'>
[ Upstream commit eaecca9e7710281be7c31d892c9f447eafd7ddd9 ]

The __cpu_logical_map undefined issue occued when the new
tegra194-cpufreq drvier building as a module.

ERROR: modpost: "__cpu_logical_map" [drivers/cpufreq/tegra194-cpufreq.ko] undefined!

The driver using cpu_logical_map() macro which will expand to
__cpu_logical_map, we can't access it in a drvier. Let's turn
cpu_logical_map() into a C wrapper and export it to fix the
build issue.

Also create a function set_cpu_logical_map(cpu, hwid) when assign
a value to cpu_logical_map(cpu).

Reported-by: Hulk Robot &lt;hulkci@huawei.com&gt;
Signed-off-by: Kefeng Wang &lt;wangkefeng.wang@huawei.com&gt;
Signed-off-by: Catalin Marinas &lt;catalin.marinas@arm.com&gt;
Signed-off-by: Sasha Levin &lt;sashal@kernel.org&gt;
</content>
</entry>
</feed>
