tocol);
^~~
Fix them by using the proper types.
Fixes: 6413139dfc64 ("skbuff: increase verbosity when dumping skb data")
Signed-off-by: Qian Cai
---
v2: Drop the checkpatch fix as it seems a bit more involved that it does not
even like passing a variable
tocol);
^~~
Fix them by using the proper types, and also fix some checkpatch
warnings by using pr_info().
WARNING: printk() should include KERN_ facility level
+ printk("%ssk family=%hu type=%u proto=%u\n",
Fixes: 6413139dfc64 ("skbuff: increase verbosity
> On Jul 15, 2019, at 8:22 PM, Yang Shi wrote:
>
>
>
> On 7/15/19 2:23 PM, Qian Cai wrote:
>> On Fri, 2019-07-12 at 12:12 -0700, Yang Shi wrote:
>>>> Another possible lead is that without reverting the those commits below,
>>>> kdump
>>>
On Fri, 2019-07-12 at 12:12 -0700, Yang Shi wrote:
> > Another possible lead is that without reverting the those commits below,
> > kdump
> > kernel would always also crash in shrink_slab_memcg() at this line,
> >
> > map = rcu_dereference_protected(memcg->nodeinfo[nid]->shrinker_map, true);
>
>
_printf() unconditionally and get rid of the DBG macro
entirely."
Suggested-by: Michael Ellerman
Signed-off-by: Qian Cai
---
v4: Use the suggestions from Michael and __func__ per checkpatch.
v3: Use no_printk() macro, and make sure that format and argument are always
verified by the comp
On Mon, 2019-07-15 at 10:01 -0500, Catalin Marinas wrote:
> On 15 Jul 2019, at 08:17, Michal Hocko wrote:
> > On Sat 13-07-19 04:49:04, Yang Shi wrote:
> > > When running ltp's oom test with kmemleak enabled, the below warning was
> > > triggerred since kernel detects __GFP_NOFAIL &
> On Jul 12, 2019, at 6:46 PM, David Miller wrote:
>
> From: Qian Cai
> Date: Fri, 12 Jul 2019 15:23:21 -0400
>
>> The commit d66acc39c7ce ("bitops: Optimise get_order()") introduced a
>> problem for the be2net driver as "rx_frag_size" cou
_page_size = (1 << get_order(rx_frag_size)) * PAGE_SIZE;
^
Fix it by using __get_order() instead which will calculate in runtime.
Fixes: d66acc39c7ce ("bitops: Optimise get_order()")
Signed-off-by: Qian Cai
---
drivers/net/ethernet/emulex/benet/be_main.c | 2 +-
1 file changed,
ixes: b48c104d2211 ("writeback: trace event bdi_dirty_ratelimit")
Fixes: cc1676d917f3 ("writeback: Move requeueing when I_SYNC set to
writeback_sb_inodes()")
Fixes: 9fb0a7da0c52 ("writeback: add more tracepoints")
Signed-off-by: Qian Cai
---
include/trace/events/writebac
Ping.
On Fri, 2019-06-28 at 10:03 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warning
Ping.
On Wed, 2019-05-22 at 12:09 -0400, Qian Cai wrote:
> The commit b575c731fe58 ("powerpc/powernv/npu: Add set/unset window
> helpers") called pnv_npu_set_window() in a void function
> pnv_npu_dma_set_32(), but the return code from pnv_npu_set_window() has
> no use
Actually, this patch is slightly off. There is one delta need to apply (ignore
the part in pgtable.h which has already in mainline via the commit 615c48ad8f42
"arm64/mm: don't initialize pgd_cache twice") in.
https://lore.kernel.org/linux-mm/20190617151252.GF16810@rapoport-lnx/
On Thu,
>
>
> Regards,
>
> Yang
>
>
>
> On 7/10/19 2:43 PM, Qian Cai wrote:
> > Running LTP oom01 test case with swap triggers a crash below. Revert the
> > series
> > "Make deferred split shrinker memcg aware" [1] seems fix the issue.
a_dim_prof[RDMA_DIM_PARAMS_NUM_PROFILES] = {
^
Since only ib_cq_rdma_dim_work() in drivers/infiniband/core/cq.c uses
it, just move the definition over there.
[1] https://patchwork.kernel.org/patch/11031455/
Signed-off-by: Qian Cai
---
drivers/infiniband/core/cq.c | 13 +
include/l
Running LTP oom01 test case with swap triggers a crash below. Revert the series
"Make deferred split shrinker memcg aware" [1] seems fix the issue.
aefde94195ca mm: thp: make deferred split shrinker memcg aware
cf402211cacc mm-shrinker-make-shrinker-not-depend-on-memcg-kmem-fix-2-fix
ca37e9e5f18d
/0x5b0
kthread+0x1d2/0x1f0
ret_from_fork+0x22/0x40
Fix it by validating the return from the 2nd alloc_iova_fast() in
dma_ops_alloc_iova(), so map_sg() could handle the error condition
immediately.
Signed-off-by: Qian Cai
---
drivers/iommu/amd_iommu.c | 2 ++
1 file changed, 2 insertions(+)
On Mon, 2019-07-08 at 23:35 +0200, Christoph Hellwig wrote:
> We actually have a discussion on that in another thread, but if you
> can easily reproduce the issue, can you test the patch below?
>
> diff --git a/fs/xfs/xfs_bio_io.c b/fs/xfs/xfs_bio_io.c
> index 757c1d9293eb..e2148f2d5d6b 100644
>
Instruction dump:
[ 8872.728161] 419ef3b0 3d220003 392974fc 8129 2f89 409ef39c 3c82ff33
3c62ff33
[ 8872.728194] 38841af8 386308e8 4bf708c1 6000 <0fe0> 4bfff37c 6000
3920
[ 8872.728251] ---[ end trace 42d16c13415f9f32 ]---
>
> Thanks,
> Yuyang
>
> O
"apic_verbosity" an "int"
which is a simpler fix than adding more checks in apic_printk().
Signed-off-by: Qian Cai
---
arch/x86/include/asm/apic.h | 2 +-
arch/x86/kernel/apic/apic.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/x86/include/asm/api
Booting today's linux-next starts to have several memory leaks. Looks like the
new xfs_rw_bdev() was introduced in the commit "xfs: use bios directly to read
and write the log recovery buffers".
https://patchwork.kernel.org/patch/10977673/
unreferenced object 0x888f595487c0 (size 184):
g Du wrote:
> The commit:
>
> 091806515124b20 ("locking/lockdep: Consolidate lock usage bit
> initialization")
>
> misses marking LOCK_USED flag at IRQ usage initialization when
> CONFIG_TRACE_IRQFLAGS
> or CONFIG_PROVE_LOCKING is not defined. Fix it.
>
>
Ping. Per discussion, sounds like this is the best thing to do in order to avoid
compilation warnings.
On Tue, 2019-06-25 at 08:44 -0400, Qian Cai wrote:
> Compiling a kernel with both FAIR_GROUP_SCHED=n and RT_GROUP_SCHED=n
> will generate a warning using W=1,
>
> kernel/
similar functions to inline for
consistency.
Signed-off-by: Qian Cai
---
include/asm-generic/cacheflush.h | 74
1 file changed, 60 insertions(+), 14 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index
empty-body]
DBG("Argh, can't find icache properties !\n");
Fix it by using the no_printk() macro, and make sure that format and
argument are always verified by the compiler.
Suggested-by: Tyrel Datwyler
Suggested-by: Joe Perches
Signed-off-by: Qian Cai
---
v3: Use no_printk()
On Fri, 2019-06-28 at 17:19 +0530, Anju T Sudhakar wrote:
> On 6/28/19 9:04 AM, Qian Cai wrote:
> >
> > > On Jun 27, 2019, at 11:12 PM, Michael Ellerman
> > > wrote:
> > >
> > > Qian Cai writes:
> > > > Read of debugfs imc_cmd file
> On Jun 27, 2019, at 11:12 PM, Michael Ellerman wrote:
>
> Qian Cai writes:
>> Read of debugfs imc_cmd file for a memory-less node will trigger a crash
>> below
>> on this power9 machine which has the following NUMA layout.
>
> What type of machine is
Read of debugfs imc_cmd file for a memory-less node will trigger a crash below
on this power9 machine which has the following NUMA layout. I don't understand
why I only saw it recently on linux-next where it was tested everyday. I can
reproduce it back to 4.20 where 4.18 seems work fine.
# cat
Ping.
On Wed, 2019-06-05 at 16:46 -0400, Qian Cai wrote:
> The opening comment mark "/**" is reserved for kernel-doc comments, so
> it will generate a warning with "make W=1".
>
> arch/powerpc/kernel/eeh_cache.c:37: warning: cannot understand function
> p
Ping.
On Thu, 2019-06-06 at 09:58 -0400, Qian Cai wrote:
> The powerpc's flush_cache_vmap() is defined as a macro and never use
> both of its arguments, so it will generate a compilation warning,
>
> lib/ioremap.c: In function 'ioremap_page_range':
> lib/ioremap.c:203:16: wa
Ping.
On Wed, 2019-06-05 at 16:53 -0400, Qian Cai wrote:
> At the beginning of setup_64.c, it has,
>
> #ifdef DEBUG
> #define DBG(fmt...) udbg_printf(fmt)
> #else
> #define DBG(fmt...)
> #endif
>
> where DBG() could be compiled away, and generate warning
On Thu, 2019-06-27 at 11:09 -0700, Mike Kravetz wrote:
> On 6/24/19 2:53 PM, Mike Kravetz wrote:
> > On 6/24/19 2:30 PM, Qian Cai wrote:
> > > So the problem is that ipcget_public() has held the semaphore
> > > "ids->rwsem"
> > > for
> >
On Thu, 2019-05-16 at 00:29 +, Verma, Vishal L wrote:
> On Wed, 2019-05-15 at 17:26 -0700, Dan Williams wrote:
> > On Wed, May 15, 2019 at 5:25 PM Verma, Vishal L
> > wrote:
> > > On Wed, 2019-05-15 at 16:25 -0700, Dan Williams wrote:
> > > > > diff --git a/drivers/nvdimm/btt.c
similar functions to inline for
consistency.
Signed-off-by: Qian Cai
---
include/asm-generic/cacheflush.h | 74
1 file changed, 60 insertions(+), 14 deletions(-)
diff --git a/include/asm-generic/cacheflush.h b/include/asm-generic/cacheflush.h
index
On Tue, 2019-06-25 at 18:00 +0100, Vincenzo Frascino wrote:
> Hi Nick,
>
> On 25/06/2019 17:26, Nick Desaulniers wrote:
> > On Tue, Jun 25, 2019 at 7:54 AM Vincenzo Frascino
> > wrote:
> > >
> > > Hi Qian,
> > >
> > > ...
> > >
> > > >
> > > > but clang 7.0 is still use in many distros by
On Tue, 2019-06-25 at 15:54 +0100, Vincenzo Frascino wrote:
> Hi Qian,
>
> ...
>
> >
> > but clang 7.0 is still use in many distros by default, so maybe this commit
> > can
> > be fixed by adding a conditional check to use "small" if clang version <
> > 8.0.
> >
>
> Could you please verify
On Tue, 2019-06-25 at 16:25 +0200, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 10:04:19AM -0400, Qian Cai wrote:
> > On Tue, 2019-06-25 at 15:52 +0200, Peter Zijlstra wrote:
> > Yes, -Wmissing-prototype makes no sense, but "-Wunused-but-set-variable" is
> >
On Tue, 2019-06-25 at 15:11 +0100, Vincenzo Frascino wrote:
> Hi Qian,
>
> On 25/06/2019 14:51, Qian Cai wrote:
> > On Tue, 2019-06-25 at 14:40 +0100, Vincenzo Frascino wrote:
> > > On 25/06/2019 13:56, Qian Cai wrote:
> > > > On Tue, 2019-06-25 at
On Tue, 2019-06-25 at 15:52 +0200, Peter Zijlstra wrote:
> On Tue, Jun 25, 2019 at 08:44:22AM -0400, Qian Cai wrote:
> > Compiling a kernel with both FAIR_GROUP_SCHED=n and RT_GROUP_SCHED=n
> > will generate a warning using W=1,
> >
> > kernel/sched/core.c: In functi
On Tue, 2019-06-25 at 14:40 +0100, Vincenzo Frascino wrote:
> On 25/06/2019 13:56, Qian Cai wrote:
> > On Tue, 2019-06-25 at 13:47 +0100, Vincenzo Frascino wrote:
> > > Hi Qian,
> > >
> > > On 25/06/2019 13:16, Qian Cai wrote:
> > > > The linux-n
On Tue, 2019-06-25 at 13:47 +0100, Vincenzo Frascino wrote:
> Hi Qian,
>
> On 25/06/2019 13:16, Qian Cai wrote:
> > The linux-next commit "arm64: vdso: Substitute gettimeofday() with C
> > implementation" [1] breaks clang build.
> >
> > error: invalid v
Signed-off-by: Qian Cai
---
v2: Incorporate the feedback from Valentin.
kernel/sched/core.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/kernel/sched/core.c b/kernel/sched/core.c
index 874c427742a9..12b9b69c8a66 100644
--- a/kernel/sched/core.c
+++ b/kernel/sched/core.c
The linux-next commit "arm64: vdso: Substitute gettimeofday() with C
implementation" [1] breaks clang build.
error: invalid value 'tiny' in '-mcode-model tiny'
make[1]: *** [scripts/Makefile.build:279:
arch/arm64/kernel/vdso/vgettimeofday.o] Error 1
make[1]: *** Waiting for unfinished jobs
So the problem is that ipcget_public() has held the semaphore "ids->rwsem" for
too long seems unnecessarily and then goes to sleep sometimes due to direct
reclaim (other times LTP hugemmap05 [1] has hugetlb_file_setup() returns
-ENOMEM),
[ 788.765739][ T1315] INFO: task hugemmap05:5001 can't die
;
^~~
It apparently the maintainers don't like the proper fix [1] which
contains ugly idefs, so silence it by appending the __maybe_unused
attribute for it instead.
[1] https://lore.kernel.org/lkml/1559681162-5385-1-git-send-email-...@lca.pw/
Signed-off-by: Qian Cai
On Mon, 2019-06-24 at 10:35 +0100, Will Deacon wrote:
> Hi Qian Cai,
>
> On Sun, Jun 16, 2019 at 09:41:09PM -0400, Qian Cai wrote:
> > > On Jun 16, 2019, at 9:32 PM, Anshuman Khandual
> > > wrote:
> > > On 06/14/2019 05:45 PM, Qian Cai wrote:
>
On Fri, 2019-06-21 at 20:24 +0200, David Hildenbrand wrote:
> On 21.06.19 17:15, Qian Cai wrote:
> > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> > > @Andrew: Only patch 1, 4 and 6 changed compared to v1.
> > >
> > > Some further cleanups aro
On Fri, 2019-06-21 at 20:56 +0200, David Hildenbrand wrote:
> On 21.06.19 20:24, David Hildenbrand wrote:
> > On 21.06.19 17:15, Qian Cai wrote:
> > > On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> > > > @Andrew: Only patch 1, 4 and 6 changed compare
On Thu, 2019-06-20 at 20:31 +0200, David Hildenbrand wrote:
> @Andrew: Only patch 1, 4 and 6 changed compared to v1.
>
> Some further cleanups around memory block devices. Especially, clean up
> and simplify walk_memory_range(). Including some other minor cleanups.
>
> Compiled + tested on x86
On Fri, 2019-06-21 at 16:37 +0200, Alexander Potapenko wrote:
> On Fri, Jun 21, 2019 at 2:26 PM Qian Cai wrote:
> >
> > On Fri, 2019-06-21 at 12:39 +0200, Alexander Potapenko wrote:
> > > On Fri, Jun 21, 2019 at 3:01 AM Kees Cook wrote:
> > > >
> > &g
ime to fix
it properly.
On Mon, 2019-05-13 at 14:41 +0200, Michal Hocko wrote:
> On Sun 12-05-19 01:48:29, Qian Cai wrote:
> > The linux-next commit ("x86, numa: always initialize all possible
> > nodes") introduced a crash below during boot for systems with a
> > memor
On Thu, 2019-06-20 at 18:19 -0700, Kees Cook wrote:
> On Thu, Jun 20, 2019 at 06:14:33PM -0700, Kees Cook wrote:
> > On Thu, Jun 20, 2019 at 03:28:01PM -0400, Qian Cai wrote:
> > > diff --git a/mm/slub.c b/mm/slub.c
> > > index a384228ff6d3..787971d4fa36 100644
> >
On Fri, 2019-06-21 at 12:39 +0200, Alexander Potapenko wrote:
> On Fri, Jun 21, 2019 at 3:01 AM Kees Cook wrote:
> >
> > On Thu, Jun 20, 2019 at 04:46:06PM -0400, Qian Cai wrote:
> > > The linux-next commit "mm: security: introduce init_on_alloc=1 and
> >
th 0.
Fix it by switching the order between kernel_init_free_pages() and
kernel_poison_pages() in free_pages_prepare().
[1] https://patchwork.kernel.org/patch/10999465/
Signed-off-by: Qian Cai
---
v2: After further debugging, the issue after switching order is likely a
separate issue as clear_pag
ptrval)=0xcc
FIX kmalloc-64: Object at 0x(ptrval) not freed
Signed-off-by: Qian Cai
---
mm/slub.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/mm/slub.c b/mm/slub.c
index a384228ff6d3..787971d4fa36 100644
--- a/mm/slub.c
+++ b/mm/slub.c
@@ -1437,7 +1437,7 @@ sta
y treating init_on_free=1 the same as
CONFIG_PAGE_POISONING_ZERO=y.
[1] https://patchwork.kernel.org/patch/10999465/
Signed-off-by: Qian Cai
---
mm/page_poison.c | 10 +++---
1 file changed, 7 insertions(+), 3 deletions(-)
diff --git a/mm/page_poison.c b/mm/page_poison.c
index 21d4f97cb49b..27
00.88939-3-eduma...@google.com/
Signed-off-by: Qian Cai
---
include/net/inet_frag.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/include/net/inet_frag.h b/include/net/inet_frag.h
index 46574d996f1d..010f26b31c89 100644
--- a/include/net/inet_frag.h
+++ b/include/net/i
al)-0x(ptrval)=0x6b
FIX kmem_cache: Marking all objects used
Signed-off-by: Qian Cai
---
mm/slab_common.c | 5 -
1 file changed, 5 deletions(-)
diff --git a/mm/slab_common.c b/mm/slab_common.c
index 91e8c739dc97..bb8aec6d8744 100644
--- a/mm/slab_common.c
+++ b/mm/slab_common.c
Compiling a kernel with W=1 generates this warning,
arch/x86/platform/efi/quirks.c:731:16: warning: comparison of unsigned
expression >= 0 is always true [-Wtype-limits]
Fixes: 3425d934fc03 ("efi/x86: Handle page faults occurring while running EFI
runtime services")
Signed-off
Commit-ID: 1b7aebf0487613033aff26420e32fa2076d52846
Gitweb: https://git.kernel.org/tip/1b7aebf0487613033aff26420e32fa2076d52846
Author: Qian Cai
AuthorDate: Wed, 19 Jun 2019 10:32:53 -0400
Committer: Borislav Petkov
CommitDate: Wed, 19 Jun 2019 19:21:32 +0200
x86/cacheinfo: Fix
Ping.
On Tue, 2019-06-04 at 16:46 -0400, Qian Cai wrote:
> Compiling a kernel with both FAIR_GROUP_SCHED=n and RT_GROUP_SCHED=n
> will generate a warning using W=1:
>
> kernel/sched/core.c: In function 'sched_init':
> kernel/sched/core.c:5906:32: warning: variable 'ptr' s
[-Wtype-limits]
"c->x86 == 0x17" is true if and only if c->x86_model was explicitly set
by cpu_detect(), so just remove the unnecessary checking.
Fixes: 68091ee7ac3c ("x86/CPU/AMD: Calculate last level cache ID from number of
sharing threads")
Reviewed-by: Sean Christopherso
On Wed, 2019-06-19 at 03:09 +, Roman Gushchin wrote:
> On Tue, Jun 18, 2019 at 05:43:04PM -0400, Qian Cai wrote:
> > Booting linux-next on both arm64 and powerpc triggers SLUB_DEBUG errors
> > below. Reverted the whole series “mm: reparent slab memory on cgroup
> > removal
Booting linux-next on both arm64 and powerpc triggers SLUB_DEBUG errors below.
Reverted the whole series “mm: reparent slab memory on cgroup removal” [1]
fixed the issue.
[1] https://lore.kernel.org/lkml/20190611231813.3148843-1-g...@fb.com/
[ 151.773224][ T1650] BUG kmem_cache (Tainted: G
Commit-ID: 509466b7d480bc5d22e90b9fbe6122ae0e2fbe39
Gitweb: https://git.kernel.org/tip/509466b7d480bc5d22e90b9fbe6122ae0e2fbe39
Author: Qian Cai
AuthorDate: Mon, 3 Jun 2019 17:11:44 -0400
Committer: Ingo Molnar
CommitDate: Mon, 17 Jun 2019 12:15:58 +0200
sched/fair: Fix
> On Jun 16, 2019, at 11:42 AM, Dan Williams wrote:
>
> On Fri, Jun 14, 2019 at 1:43 PM Qian Cai wrote:
>>
>> On Fri, 2019-06-14 at 12:48 -0700, Dan Williams wrote:
>>> On Fri, Jun 14, 2019 at 12:40 PM Qian Cai wrote:
>>>>
>>>>
> On Jun 16, 2019, at 9:32 PM, Anshuman Khandual
> wrote:
>
> Hello Qian,
>
> On 06/14/2019 05:45 PM, Qian Cai wrote:
>> On Fri, 2019-06-14 at 11:20 +0100, Will Deacon wrote:
>>> Hi Qian,
>>>
>>> On Thu, Jun 13, 2019 at 05:34:01PM -040
On Fri, 2019-06-14 at 12:48 -0700, Dan Williams wrote:
> On Fri, Jun 14, 2019 at 12:40 PM Qian Cai wrote:
> >
> > On Fri, 2019-06-14 at 11:57 -0700, Dan Williams wrote:
> > > On Fri, Jun 14, 2019 at 11:03 AM Dan Williams
> > > wrote:
> > > >
>
On Fri, 2019-06-14 at 11:57 -0700, Dan Williams wrote:
> On Fri, Jun 14, 2019 at 11:03 AM Dan Williams
> wrote:
> >
> > On Fri, Jun 14, 2019 at 7:59 AM Qian Cai wrote:
> > >
> > > On Fri, 2019-06-14 at 14:28 +0530, Aneesh Kumar K.V wrote:
> > > >
On Fri, 2019-06-14 at 14:28 +0530, Aneesh Kumar K.V wrote:
> Qian Cai writes:
>
>
> > 1) offline is busted [1]. It looks like test_pages_in_a_zone() missed the
> > same
> > pfn_section_valid() check.
> >
> > 2) powerpc booting is generating endless
On Fri, 2019-06-14 at 11:20 +0100, Will Deacon wrote:
> Hi Qian,
>
> On Thu, Jun 13, 2019 at 05:34:01PM -0400, Qian Cai wrote:
> > LTP hugemmap05 test case [1] could not exit itself properly and then degrade
> > the
> > system performance on arm64 with linux-next (ne
> On Jun 13, 2019, at 9:17 PM, Dan Williams wrote:
>
> On Thu, Jun 13, 2019 at 11:42 AM Qian Cai wrote:
>>
>> On Wed, 2019-06-12 at 12:37 -0700, Dan Williams wrote:
>>> On Wed, Jun 12, 2019 at 12:16 PM Qian Cai wrote:
>>>>
>>>> The lin
LTP hugemmap05 test case [1] could not exit itself properly and then degrade the
system performance on arm64 with linux-next (next-20190613). The bisection so
far indicates,
BAD: 30bafbc357f1 Merge remote-tracking branch 'arm64/for-next/core'
GOOD: 0c3d124a3043 Merge remote-tracking branch
On Wed, 2019-06-12 at 12:37 -0700, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 12:16 PM Qian Cai wrote:
> >
> > The linux-next commit "mm/sparsemem: Add helpers track active portions
> > of a section at boot" [1] causes a crash below when the first
On Wed, 2019-06-12 at 12:38 -0700, Dan Williams wrote:
> On Wed, Jun 12, 2019 at 12:37 PM Dan Williams
> wrote:
> >
> > On Wed, Jun 12, 2019 at 12:16 PM Qian Cai wrote:
> > >
> > > The linux-next commit "mm/sparsemem: Add helpers track active portio
On Thu, 2019-06-13 at 15:11 +0300, Mike Rapoport wrote:
> The log Qian Cai posted at [1] and partially cited below confirms that the
> failure happens when *user* PGDs are allocated and the addition of
> __GFP_ACCOUNT to gfp flags used by pgd_alloc() only uncovered another
> issue.
&g
Signed-off-by: Qian Cai
---
include/linux/memory_hotplug.h | 1 +
1 file changed, 1 insertion(+)
diff --git a/include/linux/memory_hotplug.h b/include/linux/memory_hotplug.h
index 0b8a5e5ef2da..f02be86077e3 100644
--- a/include/linux/memory_hotplug.h
+++ b/include/linux/memory_hotplug.h
@@ -
On Wed, 2019-06-12 at 09:57 +0300, Mike Rapoport wrote:
> Hi,
>
> On Tue, Jun 11, 2019 at 08:46:45AM -0400, Qian Cai wrote:
> >
> > > On Jun 11, 2019, at 8:41 AM, Mike Rapoport wrote:
> > >
> > > Sorry for the delay, I'm mostly offline these days.
>
> On Jun 11, 2019, at 8:41 AM, Mike Rapoport wrote:
>
> On Tue, Jun 11, 2019 at 11:03:49AM +0100, Mark Rutland wrote:
>> On Mon, Jun 10, 2019 at 01:26:15PM -0400, Qian Cai wrote:
>>> On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
>>>> On Tue, Ju
=]
Silence it by appending the __maybe_unused attribute for it, so all
generated variables and macros can still be kept in the same file.
Signed-off-by: Qian Cai
---
v2: add a comment for __maybe_unused.
Documentation/scheduler/sched-pelt.c | 3 ++-
kernel/sched/sched-pelt.h| 2 +-
2
It appears that kernel-doc does not understand the return type *__ref,
drivers/acpi/osl.c:306: warning: cannot understand function prototype:
'void __iomem *__ref acpi_os_map_iomem(acpi_physical_address phys,
acpi_size size)
Signed-off-by: Qian Cai
---
drivers/acpi/osl.c | 4 ++--
include
On Mon, 2019-06-10 at 12:43 +0100, Will Deacon wrote:
> On Tue, Jun 04, 2019 at 03:23:38PM +0100, Mark Rutland wrote:
> > On Tue, Jun 04, 2019 at 10:00:36AM -0400, Qian Cai wrote:
> > > The commit "arm64: switch to generic version of pte allocation"
> > > in
_PROVE_LOCKING is not defined. Fix it.
>
> Reported-by: Qian Cai
> Signed-off-by: Yuyang Du
It works fine.
On Sun, 2019-06-09 at 10:43 +0800, Lu Baolu wrote:
> Hi Qian,
>
> I just posted some fix patches. I cc'ed them in your email inbox as
> well. Can you please check whether they happen to fix your issue?
> If not, do you mind posting more debug messages?
Unfortunately, it does not work. Here is
On Fri, 2019-06-07 at 11:21 +0800, Yuyang Du wrote:
> Thanks for the report, but
>
> On Fri, 7 Jun 2019 at 05:14, Qian Cai wrote:
> >
> > The linux-next commit "locking/lockdep: Consolidate lock usage bit
> > initialization" [1] will always gener
The linux-next commit "locking/lockdep: Consolidate lock usage bit
initialization" [1] will always generate a warning below. Looking through the
commit that when mark_irqflags() returns 1 and check = 1, it will do one less
mark_lock() call than it used to.
[1]
On Wed, 2019-06-05 at 08:01 +, Yuri Norov wrote:
> (Sorry for top-posting)
>
> I can reproduce this on next-20190604. Is it new trace, or like one you've
> posted before?
Same thing, "nbits" causes an invalid access.
# ./scripts/faddr2line vmlinux bitmap_parse+0x20c/0x2d8
it an inline function.
Signed-off-by: Qian Cai
---
arch/powerpc/include/asm/cacheflush.h | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/include/asm/cacheflush.h
b/arch/powerpc/include/asm/cacheflush.h
index 74d60cfe8ce5..fd318f7c3eed 100644
--- a/arch
empty-body]
DBG("Argh, can't find icache properties !\n");
Suggested-by: Tyrel Datwyler
Signed-off-by: Qian Cai
---
v2: fix it by using a NOP while loop.
arch/powerpc/kernel/setup_64.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/arch/powerpc/kernel/setup
ct below, but rather an
overview of this source eeh_cache.c, just use the free-form comments
kernel-doc syntax instead.
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/eeh_cache.c | 3 +++
1 file changed, 3 insertions(+)
diff --git a/arch/powerpc/kernel/eeh_cache.c b/arch/powerpc/kernel/eeh_cache.
empty-body]
DBG("Argh, can't find icache properties !\n");
Signed-off-by: Qian Cai
---
arch/powerpc/kernel/setup_64.c | 9 +
1 file changed, 5 insertions(+), 4 deletions(-)
diff --git a/arch/powerpc/kernel/setup_64.c b/arch/powerpc/kernel/setup_64.c
index 44b4c432a273.
[-Wtype-limits]
Signed-off-by: Qian Cai
---
arch/x86/kernel/cpu/cacheinfo.c | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
diff --git a/arch/x86/kernel/cpu/cacheinfo.c b/arch/x86/kernel/cpu/cacheinfo.c
index 395d46f78582..c7503be92f35 100644
--- a/arch/x86/kernel/cpu/cacheinfo.c
+++ b/arch
indentations, #endif comments and lines.
Signed-off-by: Qian Cai
---
v2: Fix an oversight when both FAIR_GROUP_SCHED and RT_GROUP_SCHED
selected which was found by the 0day kernel testing robot.
kernel/sched/core.c | 50 +++---
1 file changed, 23
om/
On Thu, 2019-05-30 at 15:01 -0400, Qian Cai wrote:
> The linux-next commit "lib: rework bitmap_parse" triggers errors below during
> boot on both arm64 and powerpc with KASAN_SW_TAGS or SLUB_DEBUG enabled.
>
> Reverted the commit and its dependency (lib: opencode in_st
emcg finds out those don't belong to any cgroup.
backtrace:
kobject_add_internal
kobject_init_and_add
sysfs_slab_add+0x1a8
__kmem_cache_create
create_cache
memcg_create_kmem_cache
memcg_kmem_cache_create_func
process_one_work
worker_thread
kthread
Signed-off-by: Qian Cai
---
=]
Silence it by appending the __maybe_unused attribute for it, so all
generated variables and macros can still be kept in the same file.
Signed-off-by: Qian Cai
---
v2: add a comment for __maybe_unused.
Documentation/scheduler/sched-pelt.c | 3 ++-
kernel/sched/sched-pelt.h| 2 +-
2
It appears that kernel-doc does not understand the return type *__ref,
drivers/acpi/osl.c:306: warning: cannot understand function prototype:
'void __iomem *__ref acpi_os_map_iomem(acpi_physical_address phys,
acpi_size size)
Signed-off-by: Qian Cai
---
drivers/acpi/osl.c | 4 ++--
include
used-variable]
Also, change to use IS_ENABLED() instead.
Signed-off-by: Qian Cai
---
arch/x86/mm/fault.c | 8 +++-
1 file changed, 3 insertions(+), 5 deletions(-)
diff --git a/arch/x86/mm/fault.c b/arch/x86/mm/fault.c
index 46ac96aa7c81..40d70bd3fa84 100644
--- a/arch/x86/mm/fault.c
+++ b
"tsk" is only used when MEMORY_FAILURE=y.
arch/x86/mm/fault.c: In function 'do_sigbus':
arch/x86/mm/fault.c:1017:22: warning: unused variable 'tsk'
[-Wunused-variable]
Signed-off-by: Qian Cai
---
arch/x86/mm/fault.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/arch/x86/mm
On Fri, 2019-05-31 at 11:27 -0700, Dexuan-Linux Cui wrote:
> Hi,
> Did you know about the panic reported here:
> https://marc.info/?t=15593077303=1=2
>
> "Kernel panic - not syncing: stack-protector: Kernel stack is
> corrupted in: write_irq_affinity.isra"
>
> This panic is reported on
ble]
Also, rework the code logic a bit.
Signed-off-by: Qian Cai
---
drivers/base/memory.c | 12
1 file changed, 4 insertions(+), 8 deletions(-)
diff --git a/drivers/base/memory.c b/drivers/base/memory.c
index f28efb0bf5c7..826dd76f662e 100644
--- a/drivers/base/memory.c
+++ b/drivers/bas
701 - 800 of 1200 matches
Mail list logo
