https://bugzilla.kernel.org/show_bug.cgi?id=214913
Michal Suchanek (hramr...@gmail.com) changed:
What|Removed |Added
CC||hramr...@gmail.com
This is a note to let you know that I've just added the patch titled
arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
This is a note to let you know that I've just added the patch titled
mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
to the 4.9-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-zs
This is a note to let you know that I've just added the patch titled
arch: pgtable: define MAX_POSSIBLE_PHYSMEM_BITS where needed
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is
This is a note to let you know that I've just added the patch titled
mm/zsmalloc: Prepare to variable MAX_PHYSMEM_BITS
to the 4.14-stable tree which can be found at:
http://www.kernel.org/git/?p=linux/kernel/git/stable/stable-queue.git;a=summary
The filename of the patch is:
mm-z
On Wed, Nov 03, 2021 at 01:56:56PM -0700, Florian Fainelli wrote:
> From: Arnd Bergmann
>
> [ Upstream commit cef397038167ac15d085914493d6c86385773709 ]
>
> Stefan Agner reported a bug when using zsram on 32-bit Arm machines
> with RAM above the 4GB address boundary:
>
> Unable to handle kern
I don't use debian.
Andreas.
--
Andreas Schwab, sch...@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510 2552 DF73 E780 A9DA AEC1
"And now for something completely different."
Hi,
On Thu, 4 Nov 2021 14:17:09 +0800 davidcomponent...@gmail.com wrote:
>
> From: Yang Guang
>
> Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
> opencoding it.
So if swap() is in the above include file, then you should include it.
--
Cheers,
Stephen Rothwell
pgpRINbe
On Thu, Nov 04, 2021 at 09:06:56PM +1100, Stephen Rothwell wrote:
> On Thu, 4 Nov 2021 14:17:09 +0800 davidcomponent...@gmail.com wrote:
> > From: Yang Guang
> >
> > Use the macro 'swap()' defined in 'include/linux/minmax.h' to avoid
> > opencoding it.
>
> So if swap() is in the above include f
From: Jing Yao
coccicheck complains about the use of snprintf() in sysfs show
functions:
WARNING use scnprintf or sprintf
Use sysfs_emit instead of scnprintf or sprintf makes more sense.
Reported-by: Zeal Robot
Signed-off-by: Jing Yao
---
drivers/scsi/ibmvscsi/ibmvfc.c | 16
在 2021/11/2 下午2:33, Jiri Slaby 写道:
On 28. 10. 21, 17:09, Xianting Tian wrote:
As well known, hvc backend can register its opertions to hvc backend.
the operations contain put_chars(), get_chars() and so on.
Some hvc backend may do dma in its operations. eg, put_chars() of
virtio-console. But
On Thu, Nov 4, 2021 at 2:20 AM Michael Ellerman wrote:
> Konstantin Ryabitsev writes:
> > On Wed, Nov 03, 2021 at 10:18:57AM +1100, Michael Ellerman wrote:
> >> It's not in next, that notification is from the b4 thanks script, which
> >> didn't notice that the commit has since been reverted.
> >
These are some watchdog fixes and improvements.
This has taken a while to post out because upstream printk code seems
to have a problem with indefinitely delaying NMI context printk while
the CPU remains stuck, so that confounded testing a bit. That might
require another watchdog change after I di
Most updates to wd_smp_cpus_pending are under lock except the watchdog
interrupt bit clear.
This can race with non-atomic RMW updates to the mask under lock, which
can happen in two instances:
Firstly, if another CPU detects this one is stuck, removes it from the
mask, mask becomes empty and is r
There is a deadlock with the console_owner lock and the wd_smp_lock:
CPU x takes the console_owner lock
CPU y takes a watchdog timer interrupt and takes __wd_smp_lock
CPU x takes a soft-NMI interrupt, detects deadlock, spins on __wd_smp_lock
CPU y detects deadlock, tries to print something and spi
It is possible for all CPUs to miss the pending cpumask becoming clear,
and then nobody resetting it, which will cause the lockup detector to
stop working. It will eventually expire, but watchdog_smp_panic will
avoid doing anything if the pending mask is clear and it will never be
reset.
Order the
When taking watchdog actions, printing messages, comparing and
re-setting wd_smp_last_reset_tb, etc., read TB close to the point of use
and under wd_smp_lock or printing lock (if applicable).
This should keep timebase mostly monotonic with kernel log messages, and
could prevent (in theory) a laggy
The watchdog unstuck message can't be serialised with other watchdog
messages because that might prevent watchdog reporting. This removes
the big backtrace from the unstuck message, which can get mixed with
other messages and confuse logs, and just prints a single line.
Signed-of-by: Nicholas Pigg
Le 02/11/2021 à 03:20, Finn Thain a écrit :
Hi Christopher,
After many builds and tests, Stan and I were able to determine that this
regression only affects builds with CONFIG_USER_NS=y. That is,
d3ccc9781560 + CONFIG_USER_NS=y --> fail
d3ccc9781560 + CONFIG_USER_NS=n --> okay
d3ccc978
Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
The watchdog unstuck message can't be serialised with other watchdog
messages because that might prevent watchdog reporting. This removes
the big backtrace from the unstuck message, which can get mixed with
other messages and confuse logs, and just
Hi Segher,
On Thu, 4 Nov 2021 06:33:51 -0500 Segher Boessenkool
wrote:
>
> On Thu, Nov 04, 2021 at 09:06:56PM +1100, Stephen Rothwell wrote:
> > On Thu, 4 Nov 2021 14:17:09 +0800 davidcomponent...@gmail.com wrote:
> > > From: Yang Guang
> > >
> > > Use the macro 'swap()' defined in 'include
On Fri, 01 Oct 2021 17:14:41 +1000 Daniel Axtens wrote:
> > #ifdef __KERNEL__
> > +/*
> > + * Check if an address is part of freed initmem. After initmem is freed,
> > + * memory can be allocated from it, and such allocations would then have
> > + * addresses within the range [_stext, _end].
> >
On Thu, 4 Nov 2021, Christophe Leroy wrote:
> Le 02/11/2021 à 03:20, Finn Thain a écrit :
> > Hi Christopher,
> >
> > After many builds and tests, Stan and I were able to determine that this
> > regression only affects builds with CONFIG_USER_NS=y. That is,
> >
> > d3ccc9781560 + CONFIG_USER_NS
Excerpts from Laurent Dufour's message of November 5, 2021 2:48 am:
> Le 04/11/2021 à 17:10, Nicholas Piggin a écrit :
>> The watchdog unstuck message can't be serialised with other watchdog
>> messages because that might prevent watchdog reporting. This removes
>> the big backtrace from the unstuc
Excerpts from Nathan Lynch's message of November 4, 2021 7:11 am:
> Nicholas Piggin writes:
>> Excerpts from Michael Ellerman's message of October 29, 2021 11:15 pm:
>>> Nicholas Piggin writes:
Excerpts from Athira Rajeev's message of October 29, 2021 1:05 pm:
> @@ -631,12 +632,18 @@ sta
Excerpts from Michal Suchánek's message of November 3, 2021 1:48 am:
> On Thu, Jan 14, 2021 at 11:08:03PM +1000, Nicholas Piggin wrote:
>> Excerpts from Michal Suchánek's message of January 14, 2021 10:40 pm:
>> > On Mon, Oct 19, 2020 at 02:50:51PM +1000, Nicholas Piggin wrote:
>> >> Excerpts from
From: Ye Guojin
The operands of the bitwise OR operator are duplicated, remove one of
them.
Reported-by: Zeal Robot
Signed-off-by: Ye Guojin
---
arch/powerpc/xmon/ppc-opc.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/xmon/ppc-opc.c b/arch/powerpc/xmon/
This function builds the cores online map with on-stack cpumasks which
can cause high stack usage with large NR_CPUS.
It is not used in any performance sensitive paths, so instead just check
for first thread sibling.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/include/asm/cputhreads.h |
Some core kernel code starts to go beyond the 2048 byte stack size
warning at NR_CPUS=8192, so select CPUMASK_OFFSTACK in that case.
x86 does similarly for very large NR_CPUS.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/powerpc
Similarly to x86, add MAXSMP that should help flush out problems with
vary large SMP and other values associated with very big systems.
Signed-off-by: Nicholas Piggin
---
arch/powerpc/Kconfig | 8
arch/powerpc/platforms/Kconfig.cputype | 5 +++--
2 files changed, 11 in
cgel@gmail.com writes:
> From: Ye Guojin
>
> The operands of the bitwise OR operator are duplicated, remove one of
> them.
>
> Reported-by: Zeal Robot
> Signed-off-by: Ye Guojin
> ---
> arch/powerpc/xmon/ppc-opc.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
Thanks, but this
31 matches
Mail list logo
