On Wed, Feb 7, 2024 at 10:28 AM richard clark
wrote:
>
> On Tue, Feb 6, 2024 at 5:39 PM Valentin Schneider wrote:
> >
> > You should have access to the generic fields which include the CPU from
> > which the event happens. Any of "CPU", "cpu" or "common_cpu" would match
> > this.
> >
> > So if yo
On Tue, Feb 6, 2024 at 5:39 PM Valentin Schneider wrote:
>
> You should have access to the generic fields which include the CPU from
> which the event happens. Any of "CPU", "cpu" or "common_cpu" would match
> this.
>
> So if you're on a recent enough kernel (v6.6 or above AFAICT), you should
> be
On 06/02/24 16:42, richard clark wrote:
> On Tue, Feb 6, 2024 at 12:05 AM Valentin Schneider
> wrote:
>>
>> The CPUS{} thingie only works with an event field that is either declared as
>> a
>> cpumask (__cpumask) or a scalar. That's not the case for ipi_raise, the
>> target_cpus event field is s
On Tue, Feb 6, 2024 at 12:05 AM Valentin Schneider wrote:
>
> On 05/02/24 14:39, Mark Rutland wrote:
> > [adding Valentin]
> >
>
> Thanks!
>
> > On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote:
> >> On Mon, 5 Feb 2024 10:28:57 +
> >> Mark Rutland wrote:
> >>
> >> > > I try to w
Hi Steve,
On Mon, Feb 5, 2024 at 6:38 PM Steven Rostedt wrote:
>
> On Mon, 5 Feb 2024 17:57:29 +0800
> richard clark wrote:
>
> > I try to write below:
> > echo 'target_cpus == 11 && reason == "Function call interrupts"' >
> > events/ipi/ipi_raise/filter
>
> You mean when it is sent only to CPU
On 05/02/24 14:39, Mark Rutland wrote:
> [adding Valentin]
>
Thanks!
> On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote:
>> On Mon, 5 Feb 2024 10:28:57 +
>> Mark Rutland wrote:
>>
>> > > I try to write below:
>> > > echo 'target_cpus == 11 && reason == "Function call interrupts
[adding Valentin]
On Mon, Feb 05, 2024 at 08:06:09AM -0500, Steven Rostedt wrote:
> On Mon, 5 Feb 2024 10:28:57 +
> Mark Rutland wrote:
>
> > > I try to write below:
> > > echo 'target_cpus == 11 && reason == "Function call interrupts"' >
> > > events/ipi/ipi_raise/filter
> >
> > The '='
On Mon, 5 Feb 2024 10:28:57 +
Mark Rutland wrote:
> > I try to write below:
> > echo 'target_cpus == 11 && reason == "Function call interrupts"' >
> > events/ipi/ipi_raise/filter
>
> The '=' checks if the target_cpus bitmap *only* contains CPU 11. If the
> cpumask
> contains other CPUs, t
the ',0bff' mean?
> ~~
It's the CPU mask. bff is bits 1011 or CPUs = 0-9,11.
>
> Another question is for the filter, I'd like to catch the IPI only
> happening on cpu#11 *AND* a remote function call, so how to write the
> '
0 is not set.
I suspect your kernel module has generated the bitmap incorrectly; it looks
like you have a mask for CPUs 0-11 minus a mask for CPU 10?
For CPUs 10 and 11, that should be 0xc00 / 0b1100__.
> ~~
>
> Another question is for the filter, I'd lik
terrupts)
...
The above output is triggered by my kernel module where it will smp
cross call a remote function from cpu#10 to cpu#11, for the
'target_mask' value, what does the '0000,0bff' mean?
~~
Another question is for the filter, I'd like to catc
On Wed, Nov 01, 2023 at 01:45:56PM -0400, Steven Rostedt wrote:
> On Wed, 1 Nov 2023 18:32:14 +0100
> Jiri Olsa wrote:
>
> > hi,
> > I'm doing some testing on top of fprobes and noticed that the
> > ftrace_test_recursion_trylock allows caller from the same context
> > going through twice.
> >
>
On Wed, 1 Nov 2023 18:32:14 +0100
Jiri Olsa wrote:
> hi,
> I'm doing some testing on top of fprobes and noticed that the
> ftrace_test_recursion_trylock allows caller from the same context
> going through twice.
>
> The change below adds extra fprobe on stack_trace_print, which is
> called withi
hi,
I'm doing some testing on top of fprobes and noticed that the
ftrace_test_recursion_trylock allows caller from the same context
going through twice.
The change below adds extra fprobe on stack_trace_print, which is
called within the sample_entry_handler and I can see it being executed
with fol
Em Thu, Apr 15, 2021 at 12:01:23PM +0800, Tiezhu Yang escreveu:
> (1) tools/bpf/bpftool build failed due to the following reason:
>
> Error: failed to load BTF from /boot/vmlinux-5.12.0-rc2: No such
> file or directory
> make: *** [Makefile:158: vmlinux.h] Error 2
>
> (2) When set CONFIG_DEBUG_IN
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
>
> > [ 15.428008]
> > ==
> > [ 15.428011] BUG: KASAN: vmalloc-out-of-bounds in
> > crash_setup_memmap_entries+0x17e/0x3a0
>
> This looks like a genuine kernel bug on first
(1) tools/bpf/bpftool build failed due to the following reason:
Error: failed to load BTF from /boot/vmlinux-5.12.0-rc2: No such file or
directory
make: *** [Makefile:158: vmlinux.h] Error 2
(2) When set CONFIG_DEBUG_INFO_BTF=y, failed to generate BTF for vmlinux
due to pahole is not available
发件人: Mike Galbraith
发送时间: 2021年4月14日 15:56
收件人: Zhang, Qiang; Dmitry Vyukov
抄送: Andrew Halaney; andreyk...@gmail.com; ryabinin@gmail.com;
a...@linux-foundation.org; linux-kernel@vger.kernel.org;
kasan-...@googlegroups.com
主题: Re: 回复: Question on
On Wed, 2021-04-14 at 07:29 +, Zhang, Qiang wrote:
>
> if CONFIG_PREEMPT_RT is enabled and but not in preemptible, the prealloc
> should be allowed
No, you can't take an rtmutex when not preemptible.
-Mike
发件人: Mike Galbraith
发送时间: 2021年4月14日 12:00
收件人: Dmitry Vyukov; Zhang, Qiang
抄送: Andrew Halaney; andreyk...@gmail.com; ryabinin@gmail.com;
a...@linux-foundation.org; linux-kernel@vger.kernel.org;
kasan-...@googlegroups.com
主题: Re: Question on KASAN
el@vger.kernel.org;
> kasan-...@googlegroups.com
> 主题: Re: Question on KASAN calltrace record in RT
>
> [Please note: This e-mail is from an EXTERNAL e-mail address]
>
> On Tue, Apr 6, 2021 at 10:26 AM Zhang, Qiang
> wrote:
> >
> > Hello everyone
> >
> > In R
发件人: Dmitry Vyukov
发送时间: 2021年4月13日 23:29
收件人: Zhang, Qiang
抄送: Andrew Halaney; andreyk...@gmail.com; ryabinin@gmail.com;
a...@linux-foundation.org; linux-kernel@vger.kernel.org;
kasan-...@googlegroups.com
主题: Re: Question on KASAN calltrace record
On Wed, 2021-04-14 at 07:26 +0200, Dmitry Vyukov wrote:
> On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith wrote:
>
> > [0.692437] BUG: sleeping function called from invalid context at
> > kernel/locking/rtmutex.c:943
> > [0.692439] in_atomic(): 1, irqs_disabled(): 1, non_block: 0, pid: 1,
On Wed, Apr 14, 2021 at 6:00 AM Mike Galbraith wrote:
>
> On Tue, 2021-04-13 at 17:29 +0200, Dmitry Vyukov wrote:
> > On Tue, Apr 6, 2021 at 10:26 AM Zhang, Qiang
> > wrote:
> > >
> > > Hello everyone
> > >
> > > In RT system, after Andrew test, found the following calltrace ,
> > > in KASA
On Tue, 2021-04-13 at 17:29 +0200, Dmitry Vyukov wrote:
> On Tue, Apr 6, 2021 at 10:26 AM Zhang, Qiang
> wrote:
> >
> > Hello everyone
> >
> > In RT system, after Andrew test, found the following calltrace ,
> > in KASAN, we record callstack through stack_depot_save(), in this function,
> >
On Tue, Apr 6, 2021 at 10:26 AM Zhang, Qiang wrote:
>
> Hello everyone
>
> In RT system, after Andrew test, found the following calltrace ,
> in KASAN, we record callstack through stack_depot_save(), in this function,
> may be call alloc_pages, but in RT, the spin_lock replace with
> rt_mut
On 2021/3/30 15:27, Yu Zhao wrote:
> On Tue, Mar 30, 2021 at 12:57 AM Huang, Ying wrote:
>>
>> Yu Zhao writes:
>>
>>> On Mon, Mar 29, 2021 at 9:44 PM Huang, Ying wrote:
Miaohe Lin writes:
> On 2021/3/30 9:57, Huang, Ying wrote:
>> Hi, Miaohe,
>>
>> Miaohe Lin wri
I was working on some checkpatch fixes for ddk750_dvi.h and ddk750_dvi.c
when I noticed that dviInit function does not seem to be invoked in any
of the files that belong to this driver and can be removed. Am I missing
something?
Thank you,
Pavle
Hello everyone
In RT system, after Andrew test, found the following calltrace ,
in KASAN, we record callstack through stack_depot_save(), in this function, may
be call alloc_pages, but in RT, the spin_lock replace with
rt_mutex in alloc_pages(), if before call this function, the irq is dis
On 2021/3/30 11:44, Huang, Ying wrote:
> Miaohe Lin writes:
>
>> On 2021/3/30 9:57, Huang, Ying wrote:
>>> Hi, Miaohe,
>>>
>>> Miaohe Lin writes:
>>>
Hi all,
I am investigating the swap code, and I found the below possible race
window:
CPU 1
Yu Zhao writes:
> On Mon, Mar 29, 2021 at 9:44 PM Huang, Ying wrote:
>>
>> Miaohe Lin writes:
>>
>> > On 2021/3/30 9:57, Huang, Ying wrote:
>> >> Hi, Miaohe,
>> >>
>> >> Miaohe Lin writes:
>> >>
>> >>> Hi all,
>> >>> I am investigating the swap code, and I found the below possible race
>> >>>
On Mon, Mar 29, 2021 at 9:44 PM Huang, Ying wrote:
>
> Miaohe Lin writes:
>
> > On 2021/3/30 9:57, Huang, Ying wrote:
> >> Hi, Miaohe,
> >>
> >> Miaohe Lin writes:
> >>
> >>> Hi all,
> >>> I am investigating the swap code, and I found the below possible race
> >>> window:
> >>>
> >>> CPU 1
Miaohe Lin writes:
> On 2021/3/30 9:57, Huang, Ying wrote:
>> Hi, Miaohe,
>>
>> Miaohe Lin writes:
>>
>>> Hi all,
>>> I am investigating the swap code, and I found the below possible race
>>> window:
>>>
>>> CPU 1 CPU 2
>>> -
On 2021/3/30 9:57, Huang, Ying wrote:
> Hi, Miaohe,
>
> Miaohe Lin writes:
>
>> Hi all,
>> I am investigating the swap code, and I found the below possible race window:
>>
>> CPU 1CPU 2
>> -
Hi, Miaohe,
Miaohe Lin writes:
> Hi all,
> I am investigating the swap code, and I found the below possible race window:
>
> CPU 1 CPU 2
> - -
> do_swap_page
> skip swapcache case (synchrono
Hi all,
I am investigating the swap code, and I found the below possible race window:
CPU 1 CPU 2
- -
do_swap_page
skip swapcache case (synchronous swap_readpage)
alloc_page_vma
On Mon 22-03-21 17:49:48, Ira Weiny wrote:
> Jan,
>
> Why does ext2_set_link() need to call ext2_put_page()?
>
> I don't see any reason that we could not match up the ext2_put_page() calls
> with the ext2_find_entry().
>
> Similarly am I missing something by moving the ext2_put_page() out of
> e
e,
> > and check whether they are more than 128 MB apart.
> >
>
> Thanks Ard
>
> I will check it.
>
> One more question, why is CONFIG_ARM64_MODULE_PLTS depended on
> CONFIG_RANDOMIZE_BASE?
>
Because modules should never go out of branching range if the
placement is not randomized and the total size of all modules does not
exceed 128 MB.
ready? The module region is
> only 128 MB, so if your modules are huge, you may run out of space.
>
> Please check the kernel VA address and the load address of the module,
> and check whether they are more than 128 MB apart.
>
Thanks Ard
I will check it.
One more question, why is
On the x86 platform, we encountered the following problems. The kernel version
we are using is 3.10. The following is our analysis process, hoping to get your
help.
kernel panic at timerqueue_add+32.The stack information is as follows.
crash> bt -c 3
PID: 27797 TASK: 9f9e28805f40 CPU: 3
On Wed, 24 Mar 2021 at 08:27, chenjun (AM) wrote:
>
> Hi
>
> I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
> can not be inserted.
>
How many large modules have you loaded already? The module region is
only 128 MB, so if your modules are huge, you may run out of space.
Hi
I make a Image for arm64 (without CONFIG_RANDOMIZE_BASE). And a ko (13M)
can not be inserted.
WARNING: CPU: 2 PID: 1998 at arch/arm64/kernel/module-plts.c:39
module_emit_plt_entry+0x100/0x118
..
Call trace:
module_emit_plt_entry+0x100/0x118
apply_relocate_add+0x34c/0x570
..
I think the probl
Jan,
Why does ext2_set_link() need to call ext2_put_page()?
I don't see any reason that we could not match up the ext2_put_page() calls
with the ext2_find_entry().
Similarly am I missing something by moving the ext2_put_page() out of
ext2_delete_entry()?
See below patch.
I'm in the process of
On 3/18/21 8:56 AM, Vivek Goyal wrote:
I think all the in args are being mapped into a single scatter gather
element and that's why it does not matter whether in_numargs is 3, 2 or 1.
They will be mapped in a single element.
sg_init_fuse_args()
{
len = fuse_len_args(numargs - argpages,
On Wed, Mar 17, 2021 at 01:12:01PM -0500, Connor Kuehl wrote:
> Hi,
>
> I've been familiarizing myself with the virtiofs guest kernel module and I'm
> trying to better understand how virtiofs maps a FUSE request into
> scattergather lists.
>
> sg_count_fuse_req() starts knowing that there will be
Hi,
I've been familiarizing myself with the virtiofs guest kernel module and
I'm trying to better understand how virtiofs maps a FUSE request into
scattergather lists.
sg_count_fuse_req() starts knowing that there will be at least one in
header, as shown here (which makes sense):
u
s simply to
>>>> replace page_address(pfn_to_page(pfn)) with pfn_to_virt(pfn). I don't
>>>> know why Dan decided to do this in the more complicated way.
>>>
>>> pfn_to_virt() only works for the direct-map. If pages are not mapped I
>>> don't see how p
to do this in the more complicated way.
> >
> > pfn_to_virt() only works for the direct-map. If pages are not mapped I
> > don't see how pfn_to_virt() is expected to work.
> >
> > The real question Chenjun is why are you writing a new simulator of
> > memory as a
't involved, but I think the right solution here is simply to
>> replace page_address(pfn_to_page(pfn)) with pfn_to_virt(pfn). I don't
>> know why Dan decided to do this in the more complicated way.
>
> pfn_to_virt() only works for the direct-map. If pages are not mapped I
> d
在 2021/3/11 20:20, Matthew Wilcox 写道:
> On Thu, Mar 11, 2021 at 07:48:25AM +, chenjun (AM) wrote:
>> static int dax_writeback_one(struct xa_state *xas, struct dax_device
>> *dax_dev, struct address_space *mapping, void *entry)
>> dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PA
age_address(pfn_to_page(pfn)) with pfn_to_virt(pfn). I don't
> know why Dan decided to do this in the more complicated way.
pfn_to_virt() only works for the direct-map. If pages are not mapped I
don't see how pfn_to_virt() is expected to work.
The real question Chenjun is why are you
On Thu, Mar 11, 2021 at 07:48:25AM +, chenjun (AM) wrote:
> static int dax_writeback_one(struct xa_state *xas, struct dax_device
> *dax_dev, struct address_space *mapping, void *entry)
> dax_flush(dax_dev, page_address(pfn_to_page(pfn)), count * PAGE_SIZE);
> The pfn is returned by the dri
Hi
I write a driver to simulate memory as a block device (like a ramdisk).
and I hope the memory used would not be observed by kernel, becasue of
the struct page will take many memory.
When I mount ext2 with dax on my ramdisk. Panic will happen when fsync.
Call trace：
dax_writeback_one+0x330/
space has directly mapped into the cache, and the cache
> > storage goes away, the userspace app has to be killed because we
> > have no idea if the device going away has caused data loss or not.
> > IOWs, if userspace writes direct to the cache device and it hasn't
> >
On Mon, Mar 1, 2021 at 11:57 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > > I really don't see you seem to be telling us that invalidation is an
> > > > > either/or choice. There's more w
On Mon, Mar 01, 2021 at 09:41:02PM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
> > > > I really don't see you seem to be telling us that invalidation is an
> > > > either/or choice. There's more ways to convert physical block
> > > > address -> inode file off
On Mon, Mar 1, 2021 at 9:38 PM Dave Chinner wrote:
>
> On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> > On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> > [..]
> > > We do not need a DAX specific mechanism to tell us "DAX device
> > > gone", we need a generic block device int
On Mon, Mar 1, 2021 at 7:28 PM Darrick J. Wong wrote:
>
> On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> > On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> > >
> > > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > > On Sat, Feb 27, 2021 at 2:36 PM Dave Ch
On Mon, Mar 01, 2021 at 07:33:28PM -0800, Dan Williams wrote:
> On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
> [..]
> > We do not need a DAX specific mechanism to tell us "DAX device
> > gone", we need a generic block device interface that tells us "range
> > of block device is gone".
>
> T
On Mon, Mar 1, 2021 at 6:42 PM Dave Chinner wrote:
[..]
> We do not need a DAX specific mechanism to tell us "DAX device
> gone", we need a generic block device interface that tells us "range
> of block device is gone".
This is the crux of the disagreement. The block_device is going away
*and* th
On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> >
> > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan
e have tens to hundreds of millions of cache inodes to
walk and invalidate mappings on.
Closing this gap requires brute force purging the CPU ptes the
moment an unexpected DAX device unplug occurs. There is no other way
to do it quickly, and just waiting until the filesystem can unmap it
only increas
oes the
filesystem want to do about device removal" perspective.
> > Going forward, for buses like CXL, there will be a managed physical
> > remove operation via PCIE native hotplug. The flow there is that the
> > PCIE hotplug driver will notify the OS of a pending removal,
On Mon, Mar 01, 2021 at 12:55:53PM -0800, Dan Williams wrote:
> On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
> >
> > On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan
ead through the two patchsets...
> >
> > I've been meaning to circle back here as well.
> >
> > My immediate concern is the issue Jason recently highlighted [1] with
> > respect to invalidating all dax mappings when / if the device is
> > ripped out from u
On Sun, Feb 28, 2021 at 2:39 PM Dave Chinner wrote:
>
> On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> > On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > > > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner
uan's implementation, but it does need new communication from
driver to fs about removal events.
[1]:
http://lore.kernel.org/r/capcyv4i+pzhyziepf2pah0dt5jdfkmkdx-3usqy1fahf6lp...@mail.gmail.com
I'm not sure why there is a race condition between unbinding operation
and accessing mmaped
On Sat, Feb 27, 2021 at 03:40:24PM -0800, Dan Williams wrote:
> On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
> > On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
> > > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Wil
On Sat, Feb 27, 2021 at 2:36 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
> > > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > > > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner
On Fri, Feb 26, 2021 at 02:41:34PM -0800, Dan Williams wrote:
> On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
> > On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> > > > > My immediate concern is the issue Jason recent
On Fri, Feb 26, 2021 at 1:28 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> > >
> > > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > > > On Fri, Feb 26, 2021 at 11:05 AM Darrick
On Fri, Feb 26, 2021 at 12:59:53PM -0800, Dan Williams wrote:
> On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
> >
> > On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong
> > > wrote:
> > > >
> > > > On Fri, Feb 26, 2021 at 0
On Fri, Feb 26, 2021 at 12:51 PM Dave Chinner wrote:
>
> On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> > On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> > >
> > > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > > > Hi, guys
> > > >
> > > >
On Fri, Feb 26, 2021 at 11:24:53AM -0800, Dan Williams wrote:
> On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
> >
> > On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > > Hi, guys
> > >
> > > Beside this patchset, I'd like to confirm something about the
> > > "E
On Fri, Feb 26, 2021 at 11:05 AM Darrick J. Wong wrote:
>
> On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> > Hi, guys
> >
> > Beside this patchset, I'd like to confirm something about the
> > "EXPERIMENTAL" tag for dax in XFS.
> >
> > In XFS, the "EXPERIMENTAL" tag, whi
On Fri, Feb 26, 2021 at 09:45:45AM +, ruansy.f...@fujitsu.com wrote:
> Hi, guys
>
> Beside this patchset, I'd like to confirm something about the
> "EXPERIMENTAL" tag for dax in XFS.
>
> In XFS, the "EXPERIMENTAL" tag, which is reported in waring message
> when we mount a pmem device with dax
Hi, guys
Beside this patchset, I'd like to confirm something about the "EXPERIMENTAL"
tag for dax in XFS.
In XFS, the "EXPERIMENTAL" tag, which is reported in waring message when we
mount a pmem device with dax option, has been existed for a while. It's a bit
annoying when using fsdax feature
On Thu, Feb 25, 2021 at 11:23:18PM +0100, Peter Zijlstra wrote:
> On Thu, Feb 25, 2021 at 10:33:21AM -0800, Paul E. McKenney wrote:
> > One question for Peter... Does each and every context switch imply a
> > full barrier?
>
> Yes, also see the smp_mb__after_spinlock() in _
On Thu, Feb 25, 2021 at 10:33:21AM -0800, Paul E. McKenney wrote:
> One question for Peter... Does each and every context switch imply a
> full barrier?
Yes, also see the smp_mb__after_spinlock() in __schedule() :-)
On Thu, Feb 25, 2021 at 03:20:34PM -0500, Mathieu Desnoyers wrote:
> - On Feb 25, 2021, at 1:33 PM, paulmck paul...@kernel.org wrote:
> [...]
> > commit 581f79546b6be406a9c7280b2d3511b60821efe0
> > Author: Paul E. McKenney
> > Date: Thu Feb 25 10:26:00 2021 -0800
> >
> >rcu-tasks: Add b
- On Feb 25, 2021, at 1:33 PM, paulmck paul...@kernel.org wrote:
[...]
> commit 581f79546b6be406a9c7280b2d3511b60821efe0
> Author: Paul E. McKenney
> Date: Thu Feb 25 10:26:00 2021 -0800
>
>rcu-tasks: Add block comment laying out RCU Tasks Trace design
>
>This commit adds a bloc
On Thu, Feb 25, 2021 at 10:47:32AM -0500, Mathieu Desnoyers wrote:
> - On Feb 25, 2021, at 10:36 AM, paulmck paul...@kernel.org wrote:
>
> > On Thu, Feb 25, 2021 at 09:22:48AM -0500, Mathieu Desnoyers wrote:
> >> Hi Paul,
> >>
> >> Answering a quest
- On Feb 25, 2021, at 10:36 AM, paulmck paul...@kernel.org wrote:
> On Thu, Feb 25, 2021 at 09:22:48AM -0500, Mathieu Desnoyers wrote:
>> Hi Paul,
>>
>> Answering a question from Peter on IRC got me to look at
>> rcu_read_lock_trace(),
>> and I se
On Thu, Feb 25, 2021 at 09:22:48AM -0500, Mathieu Desnoyers wrote:
> Hi Paul,
>
> Answering a question from Peter on IRC got me to look at
> rcu_read_lock_trace(), and I see this:
>
> static inline void rcu_read_lock_trace(void)
> {
> struct
Hi Paul,
Answering a question from Peter on IRC got me to look at rcu_read_lock_trace(),
and I see this:
static inline void rcu_read_lock_trace(void)
{
struct task_struct *t = current;
WRITE_ONCE(t->trc_reader_nesting, READ_ONCE(t->trc_reader_nesting) + 1);
b
On 2021/1/30 3:11, Jay Vosburgh wrote:
> moyufeng wrote:
>
>> Ping...
>> Any comments? Thanks!
>>
>> On 2021/1/15 10:02, moyufeng wrote:
>>> Hi Team,
>>>
>>> I have a question about bonding. During testing bonding mode 4
>>> s
moyufeng wrote:
>Ping...
>Any comments? Thanks!
>
>On 2021/1/15 10:02, moyufeng wrote:
>> Hi Team,
>>
>> I have a question about bonding. During testing bonding mode 4
>> scenarios, I find that there is a very low probability that
>> the pointer is nu
On Tue, Jan 26, 2021 at 02:12:45AM +, Zhang, Qiang wrote:
> Hello Peterz, tglx
>
> I have some questions about migrate_disabe/enable(), in the past
> migrate_disabe/enable() is replaced by preempt_disable/enable() in no
> RT system.
>
> And now migrate_disabe/enable() has its own implementat
Hello Peterz, tglx
I have some questions about migrate_disabe/enable(), in the past
migrate_disabe/enable() is replaced by preempt_disable/enable() in no RT system.
And now migrate_disabe/enable() has its own implementation, I want to know in
migrate_disabe/enable() critical area is blocking a
Ping...
Any comments? Thanks!
On 2021/1/15 10:02, moyufeng wrote:
> Hi Team,
>
> I have a question about bonding. During testing bonding mode 4
> scenarios, I find that there is a very low probability that
> the pointer is null. The following information is displayed:
>
>
Hi Sam,
I have a question about CONFIG_DEBUG_SECTION_MISMATCH's use of
-fno-inline-functions-called-once.
- Add the option -fno-inline-functions-called-once to gcc commands.
When inlining a function annotated with __init in a non-init
function, we would los
runq, when wake up, other online
CPUs will also be selected to run.
what I want to ask is why we take the initiative to set it up?
Thanks
Qiang
发件人: Peter Zijlstra
发送时间: 2021年1月14日 17:11
收件人: Zhang, Qiang
抄送: linux-kernel@vger.kernel.org
主题: Re: Q
Sorry.. I see spin_lock is running after preempt_disable.
Sorry to make a noise.
On Fri, Jan 15, 2021 at 11:03 AM Yun Levi wrote:
>
> Hi Peter, Ingo, Will and linux-kernel.
>
> While I read the code of queued_spin_lock_slowpath function,
> I have some questions about an unrelated nesting case whe
Hi Peter, Ingo, Will and linux-kernel.
While I read the code of queued_spin_lock_slowpath function,
I have some questions about an unrelated nesting case when qspinlock is waiting.
Suppose there are CPU1 to CPU8.
There are two locks named lock1 and lock2 which are not related to each other.
At f
Hi Team,
I have a question about bonding. During testing bonding mode 4
scenarios, I find that there is a very low probability that
the pointer is null. The following information is displayed:
[99359.795934] bond0: (slave eth13.2001): Port 2 did not find a suitable
aggregator
[99359.796960
On Thu, Jan 14, 2021 at 08:03:23AM +, Zhang, Qiang wrote:
> Hello Peter
>
> Excuse me, I have some questions for you, about a description of this change:
>
> ''Don't rely on the scheduler to force break affinity for us -- it will
> stop doing that for per-cpu-kthreads."
>
> this mean when cp
Hello Peter
Excuse me, I have some questions for you, about a description of this change:
''Don't rely on the scheduler to force break affinity for us -- it will
stop doing that for per-cpu-kthreads."
this mean when cpuhotplug, scheduler do not change affinity for
per-cpu-kthread's task, if w
On Fri, Jan 08, 2021 at 11:37:04PM +, Asmaa Mnebhi wrote:
> Hi Corey,
>
> I have a question for you related to the following function in
> ipmi_msghandler.c
>
> static void __get_guid(struct ipmi_smi *intf)
> {
> int rv;
> struct bmc_device *bmc
Hi Corey,
I have a question for you related to the following function in ipmi_msghandler.c
static void __get_guid(struct ipmi_smi *intf)
{
int rv;
struct bmc_device *bmc = intf->bmc;
bmc->dyn_guid_set = 2;
intf->null_user_handler = guid_handler;
On 12/17/2020 08:48 PM, Tiezhu Yang wrote:
On 12/16/2020 11:16 PM, Arnaldo Carvalho de Melo wrote:
Em Wed, Dec 16, 2020 at 11:30:47AM -0300, Arnaldo Carvalho de Melo
escreveu:
Em Wed, Dec 16, 2020 at 07:14:02PM +0800, Jiaxun Yang escreveu:
在 2020/12/16 下午6:05, Tiezhu Yang 写道:
Hi,
In the cur
1 - 100 of 3303 matches
Mail list logo
