On 2024-06-06 11:46, Alice Ryhl wrote:
On Thu, Jun 6, 2024 at 5:25 PM Mathieu Desnoyers
wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
This implementation implements support for static keys in Rust so that
the actual static branch will end up in the Rust object file. However,
it would also
On 2024-06-06 12:16, Alice Ryhl wrote:
On Thu, Jun 6, 2024 at 5:29 PM Mathieu Desnoyers
wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header
On 2024-06-06 11:49, Boqun Feng wrote:
On Thu, Jun 06, 2024 at 11:30:03AM -0400, Mathieu Desnoyers wrote:
On 2024-06-06 11:05, Alice Ryhl wrote:
Make it possible to have Rust code call into tracepoints defined by C
code. It is still required that the tracepoint is declared in a C
header
nel/tracepoint.rs | 92 +
scripts/Makefile.build | 2 +-
8 files changed, 315 insertions(+), 1 deletion(-)
---
base-commit: 1613e604df0cd359cf2a7fbd9be7a0bcfacfabd0
change-id: 20240606-tracepoint-31e15b90e471
Best regards,
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
more broadly in userspace as well ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
inlining those helpers in Rust ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-06-04 12:34, Steven Rostedt wrote:
On Tue, 4 Jun 2024 11:02:16 -0400
Mathieu Desnoyers wrote:
I see.
It looks like there are a few things we could improve there:
1) With your approach, modules need to be already loaded before
attaching an fprobe event to them. This effectively
ptor leak has been detected: 1 tracked file
descriptors are still being tracked/
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
lman/listinfo/lttng-dev>
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.o
On 2024-06-03 19:49, Masami Hiramatsu (Google) wrote:
On Mon, 3 Jun 2024 15:50:55 -0400
Mathieu Desnoyers wrote:
On 2024-06-01 04:22, Masami Hiramatsu (Google) wrote:
From: Masami Hiramatsu (Google)
Support raw tracepoint event on module by fprobe events.
Since it only uses
og_set_index(i + 2);
@@ -1155,6 +1183,8 @@ static int __trace_fprobe_create(int argc, const char
*argv[])
}
out:
+ if (tp_mod)
+ module_put(tp_mod);
traceprobe_finish_parse();
trace_probe_log_clear();
kfree(new_argv);
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-05-24 11:35, Mathieu Desnoyers wrote:
[ Adding clang/llvm and KMSAN maintainers/reviewers in CC. ]
On 2024-05-24 11:28, Kent Overstreet wrote:
On Thu, May 23, 2024 at 01:53:42PM -0400, Mathieu Desnoyers wrote:
Hi Kent,
Looking around in the bcachefs code for possible causes
[ Adding clang/llvm and KMSAN maintainers/reviewers in CC. ]
On 2024-05-24 11:28, Kent Overstreet wrote:
On Thu, May 23, 2024 at 01:53:42PM -0400, Mathieu Desnoyers wrote:
Hi Kent,
Looking around in the bcachefs code for possible causes of this KMSAN
bug report:
https://lore.kernel.org/lkml
ngth-array]
int x[0];
So I wonder if the issue reported by KMSAN could be caused by this
pattern ?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
t;>
>> ___
>> lttng-dev mailing list
>> lttng-dev@lists.lttng.org <mailto:lttng-dev@lists.lttng.org>
>> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
<https://lists.lttng.org/cgi-bin/ma
on EL 8.4+
* Fix: support ext4_journal_start on EL 8.4+
* Fix: correct RHEL range for kmem_cache_free define
Project website: https://lttng.org
Documentation: https://lttng.org/docs
Download link: https://lttng.org/download
--
Mathieu Desnoyers
EfficiOS Inc.
https
@
* MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU
* Lesser General Public License for more details.
*/
-
-#define _GNU_SOURCE
#include
#include
#include
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-05-02 10:32, Michael Jeanson wrote:
On 2024-05-02 09:54, Mathieu Desnoyers wrote:
On 2024-05-01 19:42, Benjamin Marzinski via lttng-dev wrote:
If the read() in get_cpu_mask_from_sysfs() fails with EINTR, the code is
supposed to retry, but the while loop condition has (bytes_read >
* Make sure the mask read is a null terminated string.
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
nc, bool lazy_in)
if (unlikely(rcu_rdp_is_offloaded(rdp)))
call_rcu_nocb(rdp, head, func, flags, lazy);
else
- call_rcu_core(rdp, head, func, flags);
+ call_rcu_core(rdp, head, func);
local_irq_restore(flags);
}
--
g/download
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
.
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https
are used for this.
An option to explore suggested by Mathieu Desnoyers is to utilize rseq
for processes to register a value location that can be included when
profiling if desired. This would allow a tighter contract between user
processes and a profiler. It would allow better labeling/categorizing
e_bytes, 0,
new_chunk_size_bytes - old_chunk_size_bytes);
last_chunk->capacity = new_capacity;
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
On 2024-03-25 16:34, Nathan Lynch wrote:
Mathieu Desnoyers writes:
In the powerpc architecture support within the liburcu project [1]
we have a cache line size defined as 256 bytes with the following
comment:
/* Include size of POWER5+ L3 cache lines: 256 bytes */
#define CAA_CACHE_LINE_SIZE
er than CC about 50 additional
people/mailing lists.
Of course, if VIPT aliasing is removed from ARC, removing the
config ARCH_HAS_CPU_CACHE_ALIASING and using the generic
cpu_dcache_is_aliasing() is the way to go. Feel free to add
my:
Acked-by: Mathieu Desnoyers
Thanks,
Mathieu
On 2024-03-26 03:19, Michael Ellerman wrote:
Mathieu Desnoyers writes:
Hi,
Hi Mathieu,
In the powerpc architecture support within the liburcu project [1]
we have a cache line size defined as 256 bytes with the following
comment:
/* Include size of POWER5+ L3 cache lines: 256 bytes
this is why we came up with this
value, but I don't have the detailed specs of that machine.
Any feedback on this matter would be appreciated.
Thanks!
Mathieu
[1] https://liburcu.org
[2] https://github.com/urcu/userspace-rcu/pull/22
[3] https://www.7-cpu.com/
--
Mathieu Desnoyers
EfficiOS Inc.
https
with linux 6.6
* docs: Add supported versions and fix-backport policy
* docs: Add links to project resources
* Fix: Correct minimum version in jbd2 SLE kernel range
* Fix: Handle recent SLE major version codes
* Fix: build on sles15sp4
--
Mathieu Desnoyers
On 2024-03-20 13:58, Steven Rostedt wrote:
On Wed, 20 Mar 2024 13:15:39 -0400
Mathieu Desnoyers wrote:
I would like to introduce restart_critical_timings() and place it in
locations that have this behavior.
Is there any way you could move this to need_resched() rather than
sprinkle those
done here.
*/
if (owner_state != OWNER_WRITER) {
+ restart_critical_timings();
if (need_resched())
break;
if (rt_task(current) &&
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-03-07 14:47, Paul E. McKenney wrote:
On Thu, Mar 07, 2024 at 08:53:05AM -0500, Mathieu Desnoyers wrote:
On 2024-03-06 22:37, Paul E. McKenney wrote:
On Wed, Mar 06, 2024 at 10:06:21PM -0500, Mathieu Desnoyers wrote:
[...]
As far as the WRITE_ONCE(x, READ_ONCE(x) + 1) pattern
On 2024-03-06 22:37, Paul E. McKenney wrote:
On Wed, Mar 06, 2024 at 10:06:21PM -0500, Mathieu Desnoyers wrote:
[...]
As far as the WRITE_ONCE(x, READ_ONCE(x) + 1) pattern
is concerned, the only valid use-case I can think of is
split counters or RCU implementations where there is a
single
that need to snapshot a
consistent value with READ_ONCE().
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
CPU, state,
etc). As trace_seq is made to handle large events (some greater than 4K).
Make the max size of a trace_marker write event be 4K which is guaranteed
to fit in the trace_seq buffer.
Suggested-by: Mathieu Desnoyers
From my perspective I only attempted to clarify the point Linus
lace, and you should then just add a runtime check that
you don't overflow the output buffer before writing the output to it.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-03-04 20:59, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:42:39 -0500
Mathieu Desnoyers wrote:
#define TRACE_OUTPUT_META_DATA_MAX_LEN 80
and a runtime check in the code generating this header.
This would avoid adding an unchecked upper limit.
That would be a lot of complex
ld avoid adding an unchecked upper limit.
Thanks,
Mathieu
-- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-03-04 20:35, Steven Rostedt wrote:
On Mon, 4 Mar 2024 20:15:57 -0500
Mathieu Desnoyers wrote:
On 2024-03-04 19:27, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Since the size of trace_seq's buffer is the max an event can output, have
the trace_marker be half of
if (size > TRACE_SEQ_BUFFER_SIZE) {
- cnt -= size - TRACE_SEQ_BUFFER_SIZE;
- goto again;
- }
-
buffer = tr->array_buffer.buffer;
event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size,
tracing_gen_ctx()
.@gandalf.local.home/
Reported-by: Sachin Sant
Fixes: 60be76eeabb3d ("tracing: Add size check when printing trace_marker
output")
Signed-off-by: Steven Rostedt (Google)
This is a step in the right direction IMHO.
Reviewed-by: Mathieu Desnoyers
Just out of curiosity, is there an
sues, and just obfuscates the code.
Thanks,
Mathieu
In this case, READ_ONCE() is only needed for the commit_page.
But we can at least keep the READ_ONCE() on the commit_page just because it
is used in the next instruction.
-- Steve
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-23 09:26, Steven Rostedt wrote:
On Mon, 19 Feb 2024 13:01:16 -0500
Mathieu Desnoyers wrote:
Between "sched_process_exit" and "sched_process_free", the task can still be
observed by a trace analysis looking at sched and signal events: it's a zombie
at
t
On 2024-02-20 09:19, Steven Rostedt wrote:
On Mon, 19 Feb 2024 18:20:32 -0500
Steven Rostedt wrote:
Instead of using local_add_return() to reserve the ring buffer data,
Mathieu Desnoyers suggested using local_cmpxchg(). This would simplify the
reservation with the time keeping code.
Although
t_dax_nomc(struct dax_device *dax_dev);
-
struct writeback_control;
#if defined(CONFIG_BLOCK) && defined(CONFIG_FS_DAX)
int dax_add_host(struct dax_device *dax_dev, struct gendisk *disk);
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-15 09:43, Mathieu Desnoyers wrote:
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
Hi Andrew,
I notice that you should update the patch you have
"CPU data cache" and "CPU cache" to
eliminate any possible confusion with VFS "dentry cache" and "page
cache".
Link: https://lore.kernel.org/lkml/20030910210416.ga24...@mail.jlokier.co.uk/
Fixes: d92576f1167c ("dax: does not work correctly with virtual alias
iasing data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Be
: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
selects DAX, a return value of -EOPNOTSUPP
from alloc_dax() should make dcssblk_add_store() fail.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Acked-by: Heiko Carstens
Cc: Alasdair Kergon
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russel
. ]
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
ed-by: Dan Williams
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
aliasing at runtime.
Fixes: 4e4ced93794a ("dax: Move mandatory ->zero_page_range() check in
alloc_dax()")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd
: 7ac5360cd4d0 ("dax: remove the copy_from_iter and copy_to_iter methods")
Signed-off-by: Mathieu Desnoyers
Cc: Christoph Hellwig
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-...@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Cc: nvd...@lists.linux.dev
Cc: linux-s...@vger.kernel.org
Mathieu Desnoyers (9):
dax: add empty static inline for CONFIG_DAX=n
dax: alloc_dax() return ERR_PTR(-EOPNOTSUPP) for
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
out_cleanup_dax:
kill_dax(pmem->dax_dev);
put_dax(pmem->dax_dev);
Signed-off-by: Mathieu
On 2024-02-09 15:15, Dan Williams wrote:
Mathieu Desnoyers wrote:
Hi Dan,
In the context of extracting user-space trace data when the kernel crashes,
the LTTng user-space tracer recommends using nvdimm/pmem to reserve an area
of physical (volatile) RAM at boot (memmap=nn[KMG]!ss[KMG]), and use
*, if (!IS_ERR_OR_NULL(_T))
virtio_fs_cleanup_dax(_T))
and define the variable as:
struct dax_device *dax_dev __free(cleanup_dax) = NULL;
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-13 14:07, Dan Williams wrote:
Lukas Wunner wrote:
On Mon, Feb 12, 2024 at 11:30:54AM -0500, Mathieu Desnoyers wrote:
Change the return value from NULL to PTR_ERR(-EOPNOTSUPP) for
CONFIG_DAX=n to be consistent with the fact that CONFIG_DAX=y
never returns NULL.
All the callers
On 2024-02-13 01:25, Lukas Wunner wrote:
On Mon, Feb 12, 2024 at 11:30:58AM -0500, Mathieu Desnoyers wrote:
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of virtio
virtio_fs_setup_dax() to treat alloc_dax() -EOPNOTSUPP
iasing data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Be
"CPU data cache" and "CPU cache" to
eliminate any possible confusion with VFS "dentry cache" and "page
cache".
Link: https://lore.kernel.org/lkml/20030910210416.ga24...@mail.jlokier.co.uk/
Fixes: d92576f1167c ("dax: does not work correctly with virtual alias
: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russel
selects DAX, a return value of -EOPNOTSUPP
from alloc_dax() should make dcssblk_add_store() fail.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas P
ed-by: Dan Williams
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
. ]
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
c: Matthew Wilcox
Cc: Russell King
Cc: linux-a...@vger.kernel.org
Cc: linux-...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-...@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Cc: nvd...@lists.linux.dev
Cc: linux-s...@vger.kernel.org
Mathieu Desnoyers (8):
aliasing at runtime.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Reviewed-by: Dan Williams
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Be
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
out_cleanup_dax:
kill_dax(pmem->dax_dev);
put_dax(pmem->dax_dev);
Signed-off-by: Mathieu
ta present in the cpu data cache
is not invalidated prior to write back in each of those scenarios ?
- reboot with bios explicitly not clearing memory,
- kexec/kdump.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-08 17:37, Dan Williams wrote:
Mathieu Desnoyers wrote:
On 2024-02-08 16:39, Dan Williams wrote:
[...]
So per other feedback on earlier patches, I think this hunk deserves to
be moved to its own patch earlier in the series as a standalone fixup.
Done.
Rest of this patch looks
On 2024-02-08 17:12, Andrew Morton wrote:
On Thu, 8 Feb 2024 17:04:52 -0500 Mathieu Desnoyers
wrote:
[...]
Should I keep this patch 01/12 within the series for v5 or should I
send it separately ?
Doesn't matter much, but perfectionism does say "standalone patch please".
Will
case from the beginning, and then doing
the EOPNOTSUPP fixups.
...repeat this comment for patch 10, 11, 12.
Done.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
if OK with you.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
(-EOPNOTSUPP)?
Done.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-08 16:36, Dan Williams wrote:
[...]
Just another "ditto" on alloc_dax() returning NULL so that the ternary
can be removed, but otherwise this looks good.
Done.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
() in the CONFIG_DAX=n case.
Done.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-02-08 16:32, Dan Williams wrote:
Mathieu Desnoyers wrote:
In preparation for checking whether the architecture has data cache
aliasing within alloc_dax(), modify the error handling of nvdimm/pmem
pmem_attach_disk() to treat alloc_dax() -EOPNOTSUPP failure as non-fatal
On 2024-02-08 16:21, Andrew Morton wrote:
On Thu, 8 Feb 2024 13:49:02 -0500 Mathieu Desnoyers
wrote:
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
ou
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
"CPU data cache" and "CPU cache" to
eliminate any possible confusion with VFS "dentry cache" and "page
cache".
Link: https://lore.kernel.org/lkml/20030910210416.ga24...@mail.jlokier.co.uk/
Fixes: d92576f1167c ("dax: does not work correctly with virtual alias
: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
Cc: linux-a...@vger.kernel.org
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
iasing data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
Cc: l
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
-EOPNOTSUPP.
Co-developed-by: Dan Williams
Signed-off-by: Dan Williams
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvald
.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Suggested-by: Dan Williams
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave
selects DAX, a return value of -EOPNOTSUPP
from alloc_dax() should make dcssblk_add_store() fail.
For the transition, consider that alloc_dax() returning NULL is the
same as returning -EOPNOTSUPP.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-b
l.org
Cc: linux-...@vger.kernel.org
Cc: linux-fsde...@vger.kernel.org
Cc: linux...@kvack.org
Cc: linux-...@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Cc: nvd...@lists.linux.dev
Cc: linux-s...@vger.kernel.org
Mathieu Desnoyers (12):
nvdimm/pmem: Fix leak on dax_add_host() failure
nvdimm/pmem: Treat alloc_
Fix a leak on dax_add_host() error, where "goto out_cleanup_dax" is done
before setting pmem->dax_dev, which therefore issues the two following
calls on NULL pointers:
out_cleanup_dax:
kill_dax(pmem->dax_dev);
put_dax(pmem->dax_dev);
Signed-off-by: Mathieu Desn
-EOPNOTSUPP.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
C
On 2024-02-05 13:34, Vincent Donnefort wrote:
On Mon, Feb 05, 2024 at 11:55:08AM -0500, Mathieu Desnoyers wrote:
[...]
How are the kernel linear mapping and the userspace mapping made coherent
on architectures with virtually aliasing data caches ?
Ref.
https://lore.kernel.org/lkml
ce/trace.h b/kernel/trace/trace.h
index bd312e9afe25..8a96e7a89e6b 100644
--- a/kernel/trace/trace.h
+++ b/kernel/trace/trace.h
@@ -336,6 +336,7 @@ struct trace_array {
boolallocated_snapshot;
spinlock_t snapshot_trigger_lock;
unsigned intsnapshot;
+ unsigned intmapped;
unsigned long max_latency;
#ifdef CONFIG_FSNOTIFY
struct dentry *d_max_latency;
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
Now that alloc_dax() returns ERR_PTR(-EOPNOTSUPP) rather than NULL,
the callers do not have to handle NULL return values anymore.
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: Dan Williams
Cc: Vishal Verma
1 - 100 of 11961 matches
Mail list logo
