On Fri, Apr 01, 2022 at 11:44:16AM +0800, Muchun Song wrote:
> Thanks for your report. Would you mind providing the .config?
$ make ARCH=arm64 defconfig debug.config
On Fri, Mar 18, 2022 at 03:45:23PM +0800, Muchun Song wrote:
> This series is based on next-20220225.
>
> Patch 1-2 fix a cache flush bug, because subsequent patches depend on
> those on those changes, there are placed in this series. Patch 3-4
> are preparation for fixing a dax bug in patch 5.
On Sun, 2021-01-10 at 17:39 +0200, Mike Rapoport wrote:
> On Wed, Jan 06, 2021 at 04:04:21PM -0500, Qian Cai wrote:
> > On Wed, 2021-01-06 at 10:05 +0200, Mike Rapoport wrote:
> > > I think we trigger PF_POISONED_CHECK() in PageSlab(), then
> > > ff
On Wed, 2021-01-06 at 10:05 +0200, Mike Rapoport wrote:
> I think we trigger PF_POISONED_CHECK() in PageSlab(), then fffe
> is "accessed" from VM_BUG_ON_PAGE().
>
> It seems to me that we are not initializing struct pages for holes at the node
> boundaries because zones are already
.config:
https://cailca.coding.net/public/linux/mm/git/files/master/powerpc.config
Today's linux-next starts to generate random process hang quite easily.
Yesterday's build seems work fine. Sometimes, the process stack seems corrupt
while the process is running 100% CPU with gdb shows it just
On Tue, 2021-01-05 at 13:35 -0800, Hugh Dickins wrote:
> This patchset went into mmotm 2020-11-16-16-23, so probably linux-next
> on 2020-11-17: you'll have had three trouble-free weeks testing with it
> in, so it's not a likely suspect. I haven't looked yet at your report,
> to think of a more
On Tue, 2021-01-05 at 11:42 -0800, Shakeel Butt wrote:
> On Tue, Jan 5, 2021 at 11:30 AM Qian Cai wrote:
> > On Thu, 2020-11-05 at 16:55 +0800, Alex Shi wrote:
> > > This version rebase on next/master 20201104, with much of Johannes's
> > > Acks and some changes acc
On Thu, 2020-11-05 at 16:55 +0800, Alex Shi wrote:
> This version rebase on next/master 20201104, with much of Johannes's
> Acks and some changes according to Johannes comments. And add a new patch
> v21-0006-mm-rmap-stop-store-reordering-issue-on-page-mapp.patch to support
> v21-0007.
>
> This
On Tue, 2021-01-05 at 10:24 +0200, Mike Rapoport wrote:
> Hi,
>
> On Mon, Jan 04, 2021 at 02:03:00PM -0500, Qian Cai wrote:
> > On Wed, 2020-12-09 at 23:43 +0200, Mike Rapoport wrote:
> > > From: Mike Rapoport
> > >
> > > Interleave initia
On Wed, 2020-12-09 at 23:43 +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> There could be struct pages that are not backed by actual physical memory.
> This can happen when the actual memory bank is not a multiple of
> SECTION_SIZE or when an architecture does not register memory holes
>
On Thu, 2020-11-19 at 13:46 +0100, Uwe Kleine-König wrote:
> This works towards the goal mentioned in 2006 in commit 594c8281f905
> ("[PATCH] Add bus_type probe, remove, shutdown methods.").
>
> The functions are moved to where the other bus_type functions are
> defined and renamed to match the
On Fri, 2020-11-06 at 13:20 +, Christophe Leroy wrote:
> All hugetlb range freeing functions have a verification like the following,
> which only differs by the mask used, depending on the page table level.
>
> start &= MASK;
> if (start < floor)
> return;
> if
On Fri, 2020-11-20 at 18:02 -0800, Saravana Kannan wrote:
> The current implementation of fw_devlink is very inefficient because it
> tries to get away without creating fwnode links in the name of saving
> memory usage. Past attempts to optimize runtime at the cost of memory
> usage were blocked
On Thu, 2020-12-10 at 15:42 +0100, Peter Zijlstra wrote:
[]
> /*
> @@ -2706,6 +2666,55 @@ static inline int check_irq_usage(struct
> }
> #endif /* CONFIG_TRACE_IRQFLAGS */
>
> +#ifdef CONFIG_LOCKDEP_SMALL
> +/*
> + * Check that the dependency graph starting at can lead to
> + * or not. If
On Mon, 2020-12-07 at 19:27 +, Valentin Schneider wrote:
> Ok, can reproduce this on a TX2 on next-20201207. I didn't use your config,
> I oldconfig'd my distro config and only modified it to CONFIG_PREEMPT_NONE.
> Interestingly the BUG happens on CPU127 here too...
I think that number is
On Wed, 2020-12-02 at 18:41 +, David Brazdil wrote:
> Add a host-initialized constant to KVM nVHE hyp code for converting
> between EL2 linear map virtual addresses and physical addresses.
> Also add `__hyp_pa` macro that performs the conversion.
>
> Signed-off-by: David Brazdil
> ---
>
On Thu, 2020-12-03 at 08:29 +0200, Mike Rapoport wrote:
> From: Mike Rapoport
>
> Wire up memfd_secret system call on architectures that define
> ARCH_HAS_SET_DIRECT_MAP, namely arm64, risc-v and x86.
>
> Signed-off-by: Mike Rapoport
> Acked-by: Palmer Dabbelt
> Acked-by: Arnd Bergmann
> ---
On Sat, 2020-12-05 at 18:37 +, Valentin Schneider wrote:
> From there I see:
>
> [20798.166987][ T650] CPU127 nr_running=2
> [20798.171185][ T650] p=migration/127
> [20798.175161][ T650] p=kworker/127:1
>
> so this might be another workqueue hurdle. This should be prevented by:
>
>
On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
> We did have some breakage in that area, but all the holes I was aware of
> have been plugged. What would help here is to see which tasks are still
> queued on that outgoing CPU, and their recent activity.
>
> Something like
> -
On Thu, 2020-12-03 at 23:23 +0800, carver4...@163.com wrote:
> From: Hailong Liu
>
> When system in the booting stage, pages span from [start, end] of a memblock
> are freed to buddy in a order as large as possible (less than MAX_ORDER) at
> first, then decrease gradually to a proper order(less
FYI, it did crash on arm64 (Thunder X2) as well, so I'll re-run to gather more
information too.
.config: https://cailca.coding.net/public/linux/mm/git/files/master/arm64.config
[20370.682747][T77637] psci: CPU123 killed (polled 0 ms)
[20370.823651][ T635] IRQ 43: no longer affine to CPU124
On Thu, 2020-12-03 at 18:27 +0100, Marek Szyprowski wrote:
> Hi
>
> On 03.12.2020 16:46, Marek Szyprowski wrote:
> > On 25.11.2020 03:32, Matthew Wilcox wrote:
> > > On Tue, Nov 17, 2020 at 11:43:02PM +, Matthew Wilcox wrote:
> > > > On Tue, Nov 17, 2020 at 07:15:13PM +, Matthew Wilcox
On Wed, 2020-12-02 at 15:53 +0800, Kuan-Ying Lee wrote:
> We hit this issue in our internal test.
> When enabling generic kasan, a kfree()'d object is put into per-cpu
> quarantine first. If the cpu goes offline, object still remains in
> the per-cpu quarantine. If we call kmem_cache_destroy()
On Thu, 2020-11-26 at 10:13 +0530, vji...@codeaurora.org wrote:
> From: Yogesh Lal
>
> Add a kernel parameter stack_hash_order to configure STACK_HASH_SIZE.
>
> Aim is to have configurable value for STACK_HASH_SIZE, so that one
> can configure it depending on usecase there by reducing the
On Mon, 2020-11-23 at 19:13 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-18 09:44:34 [-0500], Qian Cai wrote:
> > On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
> > > We did have some breakage in that area, but all the holes I was aware of
> > > ha
On Wed, 2020-12-02 at 15:15 -0800, Andrew Morton wrote:
> On Wed, 2 Dec 2020 10:15:49 -0500 Qian Cai wrote:
>
> > We can't call kvfree() with a spin lock held, so defer it.
> >
>
> Fixes: 873d7bcfd066 ("mm/swapfile.c: use kvzalloc for swap_info_struct
> alloca
On Mon, 2020-11-23 at 19:13 +0100, Sebastian Andrzej Siewior wrote:
> On 2020-11-18 09:44:34 [-0500], Qian Cai wrote:
> > On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
> > > We did have some breakage in that area, but all the holes I was aware of
> > > ha
We can't call kvfree() with a spin lock held, so defer it.
Signed-off-by: Qian Cai
---
mm/swapfile.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/mm/swapfile.c b/mm/swapfile.c
index c4a613688a17..d58361109066 100644
--- a/mm/swapfile.c
+++ b/mm/swapfile.c
@@ -2867,6
On Thu, 2020-11-19 at 11:57 +0100, Oscar Salvador wrote:
> Hi,
>
> following up on previous fix-ups an refactors, this patchset simplifies
> the get page interface and removes the MF_COUNT_INCREASED trick we have
> for soft offline.
Well, the madvise() EIO is back. I don't understand why we
On Tue, 2020-11-17 at 19:28 +, Valentin Schneider wrote:
> We did have some breakage in that area, but all the holes I was aware of
> have been plugged. What would help here is to see which tasks are still
> queued on that outgoing CPU, and their recent activity.
>
> Something like
> -
On Fri, 2020-10-23 at 12:12 +0200, Peter Zijlstra wrote:
> From: Thomas Gleixner
>
> On CPU unplug tasks which are in a migrate disabled region cannot be pushed
> to a different CPU until they returned to migrateable state.
>
> Account the number of tasks on a runqueue which are in a migrate
On Thu, 2020-11-12 at 19:31 +, Valentin Schneider wrote:
> a) Do you also get this on CONFIG_PREEMPT=y?
This also happens with:
CONFIG_PREEMPT=y
CONFIG_PREEMPTION=y
CONFIG_PREEMPT_RCU=y
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_DEBUG_PREEMPT=y
CONFIG_PREEMPTIRQ_TRACEPOINTS=y
[ 1235.044945][ T330]
On Thu, 2020-11-12 at 19:31 +, Valentin Schneider wrote:
> One thing I don't get: that trace shows refcount_dec_and_test()
> (kernel/sched/core.c:2263) happening before the wait_for_completion(). It's
> not the case in the below trace.
Yes, that is normal. Sometimes, the decoding is a bit off
On Thu, 2020-11-12 at 17:26 +, Valentin Schneider wrote:
> On 12/11/20 16:38, Qian Cai wrote:
> > Some syscall fuzzing from an unprivileged user starts to trigger this below
> > since this commit first appeared in the linux-next today. Does it ring any
> > bells?
X86 i
On Thu, 2020-11-12 at 17:26 +, Valentin Schneider wrote:
> On 12/11/20 16:38, Qian Cai wrote:
> > Some syscall fuzzing from an unprivileged user starts to trigger this below
> > since this commit first appeared in the linux-next today. Does it ring any
> > bells?
> &g
On Fri, 2020-10-23 at 12:12 +0200, Peter Zijlstra wrote:
> Concurrent migrate_disable() and set_cpus_allowed_ptr() has
> interesting features. We rely on set_cpus_allowed_ptr() to not return
> until the task runs inside the provided mask. This expectation is
> exported to userspace.
>
> This
It looks to me the code paths below had recently been modified heavily by this
patchset. If this is reproducible, it can be confirmed by reverting it.
https://lore.kernel.org/linux-arm-kernel/cover.1605046662.git.andreyk...@google.com/
On Tue, 2020-11-10 at 23:45 -0800, syzbot wrote:
> Hello,
>
On Wed, 2020-11-11 at 17:27 +0800, Ming Lei wrote:
> Can this issue disappear by applying the following change?
This makes the system boot again as well.
>
> diff --git a/block/blk-flush.c b/block/blk-flush.c
> index e32958f0b687..b1fe6176d77f 100644
> --- a/block/blk-flush.c
> +++
On Wed, 2020-11-11 at 12:01 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the bpf-next tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> kernel/bpf/btf.c:4481:20: warning: 'btf_parse_module' defined but not used [-
> Wunused-function]
> 4481 |
On Sat, 2020-10-24 at 22:35 +0100, David Woodhouse wrote:
> From: Thomas Gleixner
>
> 'trigger' and 'polarity' are used throughout the I/O-APIC code for handling
> the trigger type (edge/level) and the active low/high configuration. While
> there are defines for initializing these variables and
On Mon, 2020-11-09 at 13:04 +, Colin King wrote:
> From: Colin Ian King
>
> Currently the allocation of cpulist is based on the length of buf but does
> not include the addition end of string '\0' terminator. Static analysis is
> reporting this as a potential out-of-bounds access on cpulist.
On Mon, 2020-11-02 at 11:18 +, tip-bot2 for Tony Luck wrote:
> The following commit has been merged into the ras/core branch of tip:
>
> Commit-ID: 68299a42f84288537ee3420c431ac0115ccb90b1
> Gitweb:
> https://git.kernel.org/tip/68299a42f84288537ee3420c431ac0115ccb90b1
> Author:
On Mon, 2020-11-09 at 08:49 +, John Garry wrote:
> On 07/11/2020 00:17, Qian Cai wrote:
> > On Sat, 2020-11-07 at 00:55 +0530, Sumit Saxena wrote:
> > > I am able to hit the boot hang and similar kind of stack traces as
> > > reported by Qian with shared .config
On Sat, 2020-11-07 at 00:55 +0530, Sumit Saxena wrote:
> I am able to hit the boot hang and similar kind of stack traces as
> reported by Qian with shared .config on x86 machine.
> In my case the system boots after a hang of 40-45 mins. Qian, is it
> true for you as well ?
I don't know. I had
On Fri, 2020-11-06 at 10:37 +, Will Deacon wrote:
> > diff --git a/arch/arm64/kernel/smp.c b/arch/arm64/kernel/smp.c
> > index 09c96f57818c..10729d2d6084 100644
> > --- a/arch/arm64/kernel/smp.c
> > +++ b/arch/arm64/kernel/smp.c
> > @@ -421,6 +421,8 @@ void cpu_die_early(void)
> >
> >
On Thu, 2020-11-05 at 15:28 -0800, Paul E. McKenney wrote:
> On Thu, Nov 05, 2020 at 06:02:49PM -0500, Qian Cai wrote:
> > On Thu, 2020-11-05 at 22:22 +, Will Deacon wrote:
> > > On Fri, Oct 30, 2020 at 04:33:25PM +, Will Deacon wrote:
> > > > On Wed, 28 Oct
On Thu, 2020-11-05 at 22:22 +, Will Deacon wrote:
> On Fri, Oct 30, 2020 at 04:33:25PM +, Will Deacon wrote:
> > On Wed, 28 Oct 2020 14:26:14 -0400, Qian Cai wrote:
> > > The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> > > enough
VM_MSR_RET_FILTERED error code for the
> userspace filtered msrs.
>
> Fixes: 291f35fb2c1d1 ("KVM: x86: report negative values from wrmsr emulation
> to userspace")
> Reported-by: Qian Cai
> Signed-off-by: Maxim Levitsky
Apparently, it does not apply cleanly on today's linu
On Wed, 2020-11-04 at 16:16 +0100, Jan Kara wrote:
> On Mon 26-10-20 10:26:26, Qian Cai wrote:
> > On Mon, 2020-10-26 at 07:55 -0600, Jens Axboe wrote:
> > > I've tried to reproduce this as well, to no avail. Qian, could you perhaps
> > > detail the setup? What kin
On Tue, 2020-11-03 at 08:04 -0500, Qian Cai wrote:
> On Tue, 2020-11-03 at 10:54 +, John Garry wrote:
> > I have no x86 system to test that x86 config, though. How about
> > v5.10-rc2 for this issue?
>
> v5.10-rc2 is also broken here.
John, Kashyap, any update on t
On Tue, 2020-11-03 at 10:54 +, John Garry wrote:
> I have no x86 system to test that x86 config, though. How about
> v5.10-rc2 for this issue?
v5.10-rc2 is also broken here.
[ 251.941451][ T330] INFO: task systemd-udevd:551 blocked for more than 122
seconds.
[ 251.949176][ T330]
On Mon, 2020-11-02 at 12:50 -0700, Jens Axboe wrote:
> Ah, but that's because later patches assume that TIF_NOTIFY_SIGNAL is
> always there once all archs have been converted. If you just want to back
> out that patch, you'll need to just revert this one:
>
> commit
On Mon, 2020-11-02 at 10:07 -0700, Jens Axboe wrote:
> On 11/2/20 9:59 AM, Qian Cai wrote:
> > On Sun, 2020-11-01 at 17:31 +, Heiko Carstens wrote:
> > > On Thu, Oct 29, 2020 at 10:21:11AM -0600, Jens Axboe wrote:
> > > > Wire up TIF_NOTIFY_SIGNAL handling for s3
On Sun, 2020-11-01 at 17:31 +, Heiko Carstens wrote:
> On Thu, Oct 29, 2020 at 10:21:11AM -0600, Jens Axboe wrote:
> > Wire up TIF_NOTIFY_SIGNAL handling for s390.
> >
> > Cc: linux-s...@vger.kernel.org
> > Signed-off-by: Jens Axboe
Even though I did confirm that today's linux-next contains
On Mon, 2020-11-02 at 20:01 +0530, Kashyap Desai wrote:
> > On Wed, 2020-08-19 at 23:20 +0800, John Garry wrote:
> > > From: Kashyap Desai
> > >
> > > Fusion adapters can steer completions to individual queues, and we now
> > > have support for shared host-wide tags.
> > > So we can enable
On Mon, 2020-11-02 at 14:51 +, John Garry wrote:
> On 02/11/2020 14:17, Qian Cai wrote:
> > [ 251.961152][ T330] INFO: task systemd-udevd:567 blocked for more than
> > 122 seconds.
> > [ 251.968876][ T330] Not tainted 5.10.0-rc1-next-20201102 #1
> > [
On Thu, 2020-10-29 at 16:20 +0100, Miklos Szeredi wrote:
> On Thu, Oct 29, 2020 at 4:02 PM Qian Cai wrote:
> > On Wed, 2020-10-07 at 16:08 -0400, Qian Cai wrote:
> > > Running some fuzzing by a unprivileged user on virtiofs could trigger the
> > > warning below.
On Wed, 2020-08-19 at 23:20 +0800, John Garry wrote:
> From: Kashyap Desai
>
> Fusion adapters can steer completions to individual queues, and
> we now have support for shared host-wide tags.
> So we can enable multiqueue support for fusion adapters.
>
> Once driver enable shared host-wide
On Sat, 2020-10-31 at 19:37 +0100, Heiko Carstens wrote:
> On Wed, Oct 28, 2020 at 02:27:42PM -0400, Qian Cai wrote:
> > The call to rcu_cpu_starting() in smp_init_secondary() is not early
> > enough in the CPU-hotplug onlining process, which results in lockdep
> &
On Fri, 2020-10-30 at 09:27 -0600, Jens Axboe wrote:
> On 10/30/20 9:24 AM, Qian Cai wrote:
> > We will need to call putname() before do_renameat2() returning -EINVAL
> > to avoid memory leaks.
>
> Thanks, should mention that this isn't final by any stretch (which is
> w
We will need to call putname() before do_renameat2() returning -EINVAL
to avoid memory leaks.
Fixes: 3c5499fa56f5 ("fs: make do_renameat2() take struct filename")
Signed-off-by: Qian Cai
---
fs/namei.c | 12 ++--
1 file changed, 10 insertions(+), 2 deletions(-)
diff --git a/
On Thu, 2020-10-22 at 18:12 +0100, Matthew Wilcox wrote:
> On Thu, Oct 22, 2020 at 11:35:26AM -0400, Qian Cai wrote:
> > On Thu, 2020-10-22 at 01:49 +0100, Matthew Wilcox wrote:
> > > On Wed, Oct 21, 2020 at 08:30:18PM -0400, Qian Cai wrote:
> > > > Today'
On Thu, 2020-10-29 at 16:20 +0100, Miklos Szeredi wrote:
> On Thu, Oct 29, 2020 at 4:02 PM Qian Cai wrote:
> > On Wed, 2020-10-07 at 16:08 -0400, Qian Cai wrote:
> > > Running some fuzzing by a unprivileged user on virtiofs could trigger the
> > > warning below.
On Wed, 2020-10-07 at 16:08 -0400, Qian Cai wrote:
> Running some fuzzing by a unprivileged user on virtiofs could trigger the
> warning below. The warning was introduced not long ago by the commit
> c146024ec44c ("fuse: fix warning in tree_insert() and clean up writepage
> inser
On Wed, 2020-10-28 at 17:31 -0700, Paul E. McKenney wrote:
> On Thu, Oct 29, 2020 at 11:09:07AM +1100, Michael Ellerman wrote:
> > Qian Cai writes:
> > > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > > in the CPU-hotplug onlining proces
On Thu, 2020-10-29 at 09:10 +, Will Deacon wrote:
> On Wed, Oct 28, 2020 at 02:26:14PM -0400, Qian Cai wrote:
> > The call to rcu_cpu_starting() in secondary_start_kernel() is not early
> > enough in the CPU-hotplug onlining process, which results in lockdep
> &
On Thu, 2020-10-29 at 11:09 +1100, Michael Ellerman wrote:
> Qian Cai writes:
> > The call to rcu_cpu_starting() in start_secondary() is not early enough
> > in the CPU-hotplug onlining process, which results in lockdep splats as
> > follows:
>
> Since when?
For
the call to rcu_cpu_starting up near the
beginning of the secondary_start_kernel() function.
Link:
https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
Signed-off-by: Qian Cai
---
arch/arm64/kernel/smp.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64
/0x130
system_call_exception+0xf8/0x1d0
system_call_common+0xe8/0x218
Fixes: 5ca85ae6318d ("powerpc/eeh_cache: Add a way to dump the EEH address
cache")
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/eeh_cache.c | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/arc
in order to avoid calling into
lockdep before RCU has declared the CPU to be watched for readers.
Link:
https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
Signed-off-by: Qian Cai
---
arch/s390/kernel/smp.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion
that the
raw_smp_processor_id() is required in order to avoid calling into
lockdep before RCU has declared the CPU to be watched for readers.
Link:
https://lore.kernel.org/lkml/160223032121.7002.1269740091547117869.tip-bot2@tip-bot2/
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/smp.c | 3 ++-
1 file
On Wed, 2020-10-28 at 08:53 -0700, Paul E. McKenney wrote:
> On Wed, Oct 28, 2020 at 10:39:47AM -0400, Qian Cai wrote:
> > On Tue, 2020-10-27 at 20:01 -0700, Paul E. McKenney wrote:
> > > If I have the right email thread associated with the right fixes, these
> > > com
On Tue, 2020-10-27 at 20:01 -0700, Paul E. McKenney wrote:
> If I have the right email thread associated with the right fixes, these
> commits in -rcu should be what you are looking for:
>
> 73b658b6b7d5 ("rcu: Prevent lockdep-RCU splats on lock acquisition/release")
> 626b79aa935a ("x86/smpboot:
On Mon, 2020-10-26 at 15:40 -0400, Qian Cai wrote:
> On Wed, 2020-09-23 at 00:10 +0300, Maxim Levitsky wrote:
> > This will allow the KVM to report such errors (e.g -ENOMEM)
> > to the userspace.
> >
> > Signed-off-by: Maxim Levitsky
>
> Reverting this and its
On Mon, 2020-10-12 at 11:11 +0800, Boqun Feng wrote:
> Hi,
>
> On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > > The following commit has been merged into the locking/core branch of tip
On Mon, 2020-10-12 at 10:10 -0400, Qian Cai wrote:
> The linux-next commit c870baeede75 ("asm-generic: add generic MMU
> versions of mmu context functions") missed a case in the arm64/for-next
> branch.
>
> Signed-off-by: Qian Cai
Arnd, Stephen, can you apply this patc
On Wed, 2020-09-23 at 00:10 +0300, Maxim Levitsky wrote:
> This will allow the KVM to report such errors (e.g -ENOMEM)
> to the userspace.
>
> Signed-off-by: Maxim Levitsky
Reverting this and its dependency:
72f211ecaa80 KVM: x86: allow kvm_x86_ops.set_efer to return an error value
on the top
On Mon, 2020-10-26 at 07:55 -0600, Jens Axboe wrote:
> I've tried to reproduce this as well, to no avail. Qian, could you perhaps
> detail the setup? What kind of storage, kernel config, compiler, etc.
This should work:
https://gitlab.com/cailca/linux-mm/-/blob/master/x86.config
On Mon, 2020-10-26 at 07:55 -0600, Jens Axboe wrote:
> I've tried to reproduce this as well, to no avail. Qian, could you perhaps
> detail the setup? What kind of storage, kernel config, compiler, etc.
>
So far I have only been able to reproduce on this Intel platform:
HPE DL560 gen10
Intel(R)
On Thu, 2020-10-22 at 01:49 +0100, Matthew Wilcox wrote:
> On Wed, Oct 21, 2020 at 08:30:18PM -0400, Qian Cai wrote:
> > Today's linux-next starts to trigger this wondering if anyone has any clue.
>
> I've seen that occasionally too. I changed that BUG_ON to VM_BUG_ON_PAGE
> to
Today's linux-next starts to trigger this wondering if anyone has any clue.
[ 9765.086947][T48578] LTP: starting iogen01 (export LTPROOT; rwtest -N iogen01
-i 120s -s read,write -Da -Dv -n 2 500b:$TMPDIR/doio.f1.$$
1000b:$TMPDIR/doio.f2.$$)
[ 9839.423703][T97227] [ cut here
On Fri, 2020-10-16 at 01:12 -0700, syzbot wrote:
> Hello,
>
> syzbot found the following issue on:
>
> HEAD commit:b2926c10 Add linux-next specific files for 20201016
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=12fc877f90
> kernel config:
On Tue, 2020-10-13 at 14:40 -0400, Vivek Goyal wrote:
> > == the thread is stuck in the loop ==
> > [10813.290694] task:trinity-c33 state:D stack:25888 pid:254219 ppid:
> > 87180
> > flags:0x4004
> > [10813.292671] Call Trace:
> > [10813.293379] __schedule+0x71d/0x1b50
> > [10813.294182]
This reverts commit 3a3181e16fbde752007759f8759d25e0ff1fc425 which
causes memory corruptions on POWER9 NV.
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/pci-bridge.h | 6 --
arch/powerpc/kernel/pci-common.c | 114 --
2 files changed, 120 deletions(-)
diff
On Tue, 2020-10-13 at 15:57 -0400, Vivek Goyal wrote:
> Hmm..., So how do I reproduce it. Just run trinity as root and it will
> reproduce after some time?
Only need to run it as unprivileged user after mounting virtiofs on /tmp
(trinity will need to create and use files there) as many as CPUs as
On Tue, 2020-10-13 at 14:58 -0400, Vivek Goyal wrote:
> I am wondering if virtiofsd still alive and responding to requests? I
> see another task which is blocked on getdents() for more than 120s.
>
> [10580.142571][ T348] INFO: task trinity-c36:254165 blocked for more than 123
> +seconds.
>
On Wed, 2020-09-23 at 09:06 +0200, Cédric Le Goater wrote:
> On 9/23/20 2:33 AM, Qian Cai wrote:
> > On Fri, 2020-08-07 at 12:18 +0200, Cédric Le Goater wrote:
> > > When a passthrough IO adapter is removed from a pseries machine using
> > > hash MMU and the XIV
On Tue, 2020-10-13 at 14:58 -0400, Vivek Goyal wrote:
> I am wondering if virtiofsd still alive and responding to requests? I
> see another task which is blocked on getdents() for more than 120s.
>
> [10580.142571][ T348] INFO: task trinity-c36:254165 blocked for more than 123
> +seconds.
>
Running some fuzzing on virtiofs with an unprivileged user on today's
linux-next
could trigger soft-lockups below.
# virtiofsd --socket-path=/tmp/vhostqemu -o source=$TESTDIR -o cache=always -o
no_posix_lock
Basically, everything was blocking on inode_lock(inode) because one thread
On Mon, 2020-10-12 at 11:11 +0800, Boqun Feng wrote:
> Hi,
>
> On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > > The following commit has been merged into the locking/core branch of tip
The linux-next commit c870baeede75 ("asm-generic: add generic MMU
versions of mmu context functions") missed a case in the arm64/for-next
branch.
Signed-off-by: Qian Cai
---
arch/arm64/include/asm/mmu_context.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/i
On Fri, 2020-10-09 at 13:36 -0400, Qian Cai wrote:
> Back to x86, we have:
>
> start_secondary()
> smp_callin()
> apic_ap_setup()
> setup_local_APIC()
> printk() in certain conditions.
>
> which is before smp_store_cpu_info().
>
>
On Fri, 2020-10-09 at 18:23 +0200, Peter Zijlstra wrote:
> On Fri, Oct 09, 2020 at 06:58:37AM -0700, Paul E. McKenney wrote:
> > On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > >
On Fri, 2020-10-09 at 06:58 -0700, Paul E. McKenney wrote:
> On Fri, Oct 09, 2020 at 09:41:24AM -0400, Qian Cai wrote:
> > On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> > > The following commit has been merged into the locking/core branch of tip:
>
On Fri, 2020-10-09 at 07:58 +, tip-bot2 for Peter Zijlstra wrote:
> The following commit has been merged into the locking/core branch of tip:
>
> Commit-ID: 4d004099a668c41522242aa146a38cc4eb59cb1e
> Gitweb:
> https://git.kernel.org/tip/4d004099a668c41522242aa146a38cc4eb59cb1e
>
On Mon, 2020-10-05 at 17:43 +0100, Mark Rutland wrote:
> The current initialization of the per-cpu offset register is difficult
> to follow and this initialization is not always early enough for
> upcoming instrumentation with KCSAN, where the instrumentation callbacks
> use the per-cpu offset.
>
On Mon, 2020-10-05 at 10:41 +0200, Christoph Hellwig wrote:
> Hi Martin,
>
> this series tidies up various loose ends in the SCSI I/O submission path.
Reverting this patchset on the top of today's linux-next fixed the boot failures
below with libata, i.e.,
git revert --no-edit
On Sun, 2020-10-04 at 21:10 -0700, syzbot wrote:
> syzbot has found a reproducer for the following issue on:
>
> HEAD commit:2172e358 Add linux-next specific files for 20201002
> git tree: linux-next
> console output: https://syzkaller.appspot.com/x/log.txt?x=1596c7a390
> kernel
Running some fuzzing by a unprivileged user on virtiofs could trigger the
warning below. The warning was introduced not long ago by the commit
c146024ec44c ("fuse: fix warning in tree_insert() and clean up writepage
insertion").
>From the logs, the last piece of the fuzzing code is:
On Wed, 2020-10-07 at 19:47 +0530, Srikar Dronamraju wrote:
> Can you confirm if CONFIG_CPUMASK_OFFSTACK is enabled in your config?
Yes, https://gitlab.com/cailca/linux-mm/-/blob/master/powerpc.config
We tested here almost daily on linux-next.
1 - 100 of 1200 matches
Mail list logo
