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
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
-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
: 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
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_
.
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
-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
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
On 2024-02-02 15:14, Dan Williams wrote:
Mathieu Desnoyers wrote:
[..]
Thanks for that. All of those need to be done before the fs goes live
later in virtio_device_ready(), but before that point nothing should be
calling into virtio_fs_dax_ops, so as far as I can see it is safe to
change
On 2024-02-02 14:41, Dan Williams wrote:
Mathieu Desnoyers wrote:
On 2024-02-02 12:37, Dan Williams wrote:
Mathieu Desnoyers wrote:
[...]
The alternative route I intend to take is to audit all callers
of alloc_dax() and make sure they all save the alloc_dax() return
value in a struct
On 2024-02-02 12:37, Dan Williams wrote:
Mathieu Desnoyers wrote:
[...]
The alternative route I intend to take is to audit all callers
of alloc_dax() and make sure they all save the alloc_dax() return
value in a struct dax_device * local variable first for the sake
of checking for IS_ERR
On 2024-02-01 10:44, Mathieu Desnoyers wrote:
On 2024-01-31 17:18, Dan Williams wrote:
[...]
diff --git a/fs/fuse/virtio_fs.c b/fs/fuse/virtio_fs.c
index 5f1be1da92ce..11053a70f5ab 100644
--- a/fs/fuse/virtio_fs.c
+++ b/fs/fuse/virtio_fs.c
@@ -16,6 +16,7 @@
#include
#include
On 2024-02-01 10:44, Mathieu Desnoyers wrote:
[...]
diff --git a/drivers/nvdimm/pmem.c b/drivers/nvdimm/pmem.c
index 4e8fdcb3f1c8..b69c9e442cf4 100644
--- a/drivers/nvdimm/pmem.c
+++ b/drivers/nvdimm/pmem.c
@@ -560,17 +560,19 @@ static int pmem_attach_disk(struct device *dev,
dax_dev
On 2024-01-31 17:18, Dan Williams wrote:
Mathieu Desnoyers wrote:
On 2024-01-31 16:02, Dan Williams wrote:
Mathieu Desnoyers wrote:
Replace the following fs/Kconfig:FS_DAX dependency:
depends on !(ARM || MIPS || SPARC)
By a runtime check within alloc_dax().
This is done in preparation
On 2024-01-31 16:02, Dan Williams wrote:
Mathieu Desnoyers wrote:
Replace the following fs/Kconfig:FS_DAX dependency:
depends on !(ARM || MIPS || SPARC)
By a runtime check within alloc_dax().
This is done in preparation for its use by each filesystem supporting
the "dax" mo
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
es.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
C
"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
n Williams
Signed-off-by: Mathieu Desnoyers
Cc: Alasdair Kergon
Cc: Mike Snitzer
Cc: Mikulas Patocka
Cc: dm-devel@lists.linux.dev
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
er.kernel.org
Cc: nvd...@lists.linux.dev
Cc: linux-fsde...@vger.kernel.org
Cc: dm-devel@lists.linux.dev
Mathieu Desnoyers (4):
dm: Treat alloc_dax failure as non-fatal
dax: Check for data cache aliasing at runtime
Introduce cpu_dcache_is_aliasing() across all architectures
dax: Fix incorrec
reparation for using cpu_dcache_is_aliasing() in a
following change which will properly support architectures which detect
data cache aliasing at runtime.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
On 2024-01-30 22:13, Dan Williams wrote:
Dave Chinner wrote:
On Tue, Jan 30, 2024 at 11:52:55AM -0500, Mathieu Desnoyers wrote:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
prevents DAX from building on architectures with virtually alia
On 2024-01-30 21:48, Dave Chinner wrote:
On Tue, Jan 30, 2024 at 11:52:54AM -0500, Mathieu Desnoyers wrote:
Introduce a generic way to query whether the dcache is virtually aliased
on all architectures. Its purpose is to ensure that subsystems which
are incompatible with virtually aliased data
ful to gate features like XIP on architectures
which have aliasing dcache-icache but not dcache-dcache.
Link: https://lore.kernel.org/lkml/20030910210416.ga24...@mail.jlokier.co.uk/
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathi
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc:
to validate whether they have virtually aliased data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Chandan Babu R
Cc: Darrick J. Wong
Cc: linux-...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
to validate whether they have virtually aliased data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Miklos Szeredi
Cc: linux-fsde...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
they have virtually aliased data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: "Theodore Ts'o"
Cc: Andreas Dilger
Cc: linux-e...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: l
to validate whether they have virtually aliased data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Gao Xiang
Cc: Chao Yu
Cc: Yue Hu
Cc: Jeffle Xu
Cc: linux-erofs@lists.ozlabs.org
Cc: Andrew Morton
to validate whether they have virtually aliased data caches.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Jan Kara
Cc: linux-e...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
rvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
Cc: linux-...@vger.kernel.org
Cc: nvd...@lists.linux.dev
Cc: linux-fsde...@vger.kernel.org
Mathieu Desnoyers (8):
dax:
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: Arnd Bergmann
Cc: Russell King
Cc: nvd...@lists.linux.dev
Cc: linux-...@vger.kernel.org
Cc:
On 2024-01-30 06:33, Jan Kara wrote:
On Mon 29-01-24 16:06:28, Mathieu Desnoyers wrote:
Use dax_is_supported() to validate whether the architecture has
virtually aliased caches at mount time.
This is relevant for architectures which require a dynamic check
to validate whether they have
On 2024-01-29 21:38, Dave Chinner wrote:
On Mon, Jan 29, 2024 at 04:06:31PM -0500, Mathieu Desnoyers wrote:
Use dax_is_supported() to validate whether the architecture has
virtually aliased caches at mount time.
This is relevant for architectures which require a dynamic check
to validate
On 2024-01-29 16:22, Dan Williams wrote:
Mathieu Desnoyers wrote:
This commit introduced in v5.13 prevents building FS_DAX on 32-bit ARM,
even on ARMv7 which does not have virtually aliased dcaches:
commit d92576f1167c ("dax: does not work correctly with virtual aliasing
caches"
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: "Theodore Ts'o"
Cc: Andreas Dilger
Cc: linux-e...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vi
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Chandan Babu R
Cc: Darrick J. Wong
Cc: linux-...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
caches
(ARCH_HAS_CACHE_ALIASING_DYNAMIC=y).
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Miklos Szeredi
Cc: linux-fsde...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
ed in each filesystem
supporting the dax mount option to validate whether dax is indeed
supported.
Fixes: d92576f1167c ("dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a..
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Gao Xiang
Cc: Chao Yu
Cc: Yue Hu
Cc: Jeffle Xu
Cc: linux-erofs@lists.ozlabs.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Wi
t;dax: does not work correctly with virtual aliasing
caches")
Signed-off-by: Mathieu Desnoyers
Cc: Jan Kara
Cc: linux-e...@vger.kernel.org
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew
HMLBA from SZ_64K to
PAGE_SIZE"))
* microblaze
* openrisc
* powerpc
* riscv
* s390
* um
* x86
Link: https://lore.kernel.org/lkml/20030910210416.ga24...@mail.jlokier.co.uk/
Signed-off-by: Mathieu Desnoyers
Cc: Andrew Morton
Cc: Linus Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.or
Torvalds
Cc: linux...@kvack.org
Cc: linux-a...@vger.kernel.org
Cc: Dan Williams
Cc: Vishal Verma
Cc: Dave Jiang
Cc: Matthew Wilcox
Cc: linux-...@vger.kernel.org
Cc: nvd...@lists.linux.dev
Mathieu Desnoyers (7):
Introduce cache_is_aliasing() across all architectures
dax: Fix incorrect li
e a 0 inode number */
+ if (unlikely(!res))
+ res++;
I suspect that bumping this res++ in the 0 case can cause inode range
reservation issues at (files+1 == LAST_INO_BATCH-1).
Thanks,
Mathieu
+ *p = res + files;
+ put_cpu_var(last_ino);
+ return res;
+}
ughts on how to best move forward with this issue are welcome.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2024-01-20 08:47, Steven Rostedt wrote:
On Fri, 19 Jan 2024 20:49:36 -0500
Mathieu Desnoyers wrote:
Let's say we have the following ktime_get() values (monotonic timestamp value)
for
a sequence of events:
Timestamp (Hex)Encoding in the trace
On 2024-01-19 16:42, Steven Rostedt wrote:
On Fri, 19 Jan 2024 15:56:21 -0500
Mathieu Desnoyers wrote:
So when an overflow happens, you just insert a timestamp, and then events
after that is based on that?
No. Let's use an example to show how it works.
For reference, LTTng uses 5-bit
On 2024-01-19 10:37, Steven Rostedt wrote:
On Fri, 19 Jan 2024 09:40:27 -0500
Mathieu Desnoyers wrote:
On 2024-01-18 18:12, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
[...]
Although, it does not get rid of the double time stamps (before_stamp and
write_stamp), usi
On 2024-01-18 18:12, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
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.
I admire the effort
On 2024-01-15 14:42, Florian Weimer wrote:
* Mathieu Desnoyers:
[...]
General use of lttng should be fine, I think, only the malloc wrapper
has this problem.
The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS
On 2024-01-15 14:42, Florian Weimer wrote:
* Mathieu Desnoyers:
[...]
General use of lttng should be fine, I think, only the malloc wrapper
has this problem.
The purpose of the nesting counter TLS variable in the malloc wrapper
is to catch situations like this where a global-dynamic TLS
th glibc could avoid this issue,
and also help with the longjmp problem, and fix setcontext/swapcontext,
too.
Thanks,
Florian
___
lttng-dev mailing list
lttng-...@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
th glibc could avoid this issue,
and also help with the longjmp problem, and fix setcontext/swapcontext,
too.
Thanks,
Florian
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
s, it's good to make sure
that all bases are covered, because those choices will have lasting impacts.
Thanks,
Mathieu
[1]
https://git.lttng.org/?p=lttng-modules.git;a=blob;f=src/lib/ringbuffer/ring_buffer_mmap.c
[2]
https://git.lttng.org/?p=lttng-modules.git;a=blob;f=src/lib/ringbuffer/ring_buffer_
Import VFS namespace for android common kernel
* Fix build for RHEL 8.8 with linux 4.18.0-477.10.1+
* Fix: bytecode validator: oops during validation of immediate string
* fix: ubuntu kinetic kernel range for jdb2
--
Mathieu De
x: python agent: install on Debian python >= 3.10
* fix: python agent: Add a dependency on generated files
* python: use setuptools with python >= 3.12
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lt
)
EXPORT_SYMBOL_GPL(wrapper_kallsyms_lookup_name);
#endif
+
+#ifdef CONFIG_ANDROID
+MODULE_IMPORT_NS(VFS_internal_I_am_really_a_filesystem_and_am_NOT_a_driver);
+#endif
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing
On 2023-12-15 13:43, Steven Rostedt wrote:
On Fri, 15 Dec 2023 13:25:07 -0500
Mathieu Desnoyers wrote:
I am not against exposing an ABI that allows userspace to alter the
filter behavior. I disagree on the way you plan to expose the ABI.
These are no different than the knobs for sched_debug
On 2023-12-15 12:34, Steven Rostedt wrote:
On Fri, 15 Dec 2023 12:24:14 -0500
Mathieu Desnoyers wrote:
On 2023-12-15 12:04, Steven Rostedt wrote:
On Fri, 15 Dec 2023 10:53:39 -0500
Mathieu Desnoyers wrote:
[...]
So rather than stacking tons of "on/off" switches for filter
fea
On 2023-12-15 12:04, Steven Rostedt wrote:
On Fri, 15 Dec 2023 10:53:39 -0500
Mathieu Desnoyers wrote:
[...]
So rather than stacking tons of "on/off" switches for filter
features, how about you let users express the mechanism they
want to use for filtering with a string ins
switches for filter
features, how about you let users express the mechanism they
want to use for filtering with a string instead ? e.g.
filter-method="temp-buffer"
filter-method="ring-buffer"
filter-method="input-arguments"
?
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
ally had to dust off my old Eee PC for this :)
This means that this complex code is not only complex but also not even
faster than just using 64-bit cmpxchg.
Nuke it!
Acked-by: Mathieu Desnoyers
@@ -3720,6 +3517,7 @@ rb_reserve_next_event(struct trace_buffer *buffer,
struc
On 2023-12-12 11:53, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Mathieu Desnoyers pointed out an issue in the rb_time_cmpxchg() for 32 bit
architectures. That is:
static bool rb_time_cmpxchg(rb_time_t *t, u64 expect, u64 set)
{
unsigned long cnt, top, b
ed by nested rb_time_set().
Link:
https://lore.kernel.org/lkml/20231211201324.652870-1-mathieu.desnoy...@efficios.com/
Fixes: f458a1453424e ("ring-buffer: Test last update in 32bit version of
__rb_time_read()")
Signed-off-by: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: l
On 2023-12-11 23:38, Steven Rostedt wrote:
On Mon, 11 Dec 2023 22:51:04 -0500
Mathieu Desnoyers wrote:
[...]
For this first issue, here is the race:
rb_time_cmpxchg()
[...]
if (!rb_time_read_cmpxchg(>msb, msb, msb2))
return fa
tr->array_buffer.buffer;
event = __trace_buffer_lock_reserve(buffer, TRACE_PRINT, size,
tracing_gen_ctx());
- if (unlikely(!event))
+ if (unlikely(!event)) {
+ /*
+* If the size was greated than what was allowed, then
greater
uf);
trace_assign_type(field, iter->ent);
- trace_seq_printf(>seq, "# %lx %s", field->ip, field->buf);
+ trace_seq_printf(>seq, "# %lx %*s", field->ip, max, field->buf);
return trace_handle_return(>seq);
}
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 2023-12-11 17:59, Steven Rostedt wrote:
On Mon, 11 Dec 2023 15:13:24 -0500
Mathieu Desnoyers wrote:
Going through a review of the ring buffer rb_time functions for 32-bit
architectures, I updated the comments to match the code, and identified
the following issues:
Thanks Mathieu
sure the rest of the ring buffer handles this correctly.
Signed-off-by: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: linux-trace-ker...@vger.kernel.org
---
kernel/trace/ring_buffer.c | 64 +++---
1 file changed, 46 insertions(+), 18 deletions
On 2023-12-10 11:38, Steven Rostedt wrote:
On Sun, 10 Dec 2023 11:07:22 -0500
Mathieu Desnoyers wrote:
It just allows more to be written in one go.
I don't see why the tests need to cover this or detect this change.
If the purpose of this change is to ensure that the entire
trace marker
On 2023-12-10 10:30, Steven Rostedt wrote:
On Sun, 10 Dec 2023 09:09:06 -0500
Mathieu Desnoyers wrote:
On 2023-12-09 17:50, Steven Rostedt wrote:
From: "Steven Rostedt (Google)"
Allow a trace write to be as big as the ring buffer tracing data will
allow. Currently, it only all
ing buffer and the snapshot buffer will be discarded.
+
free_buffer:
If a process is performing tracing, and the ring buffer should be
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
uot;1234567890" pattern only.
The test should be extended to validate whether the trace marker
payload was truncated or not, otherwise it is of limited value.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
Specifying the "order" of subbuffer size as a power of two of
number of pages is a poor UX choice for a user-facing ABI.
I would recommend allowing the user to specify the size in bytes, and
internally bump to size to the next power of 2, with a minimum of
PAGE_SIZE.
Thanks,
Mathieu
n the
buffer size is rather inconvenient.
It would be better to print the partial line, and end the line with
a tag.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
uld expect the tests under tools/testing/selftests/ftrace/* to
be affected by those changes. If they are not, then it's a hole in
the test coverage and should be taken care of as this behavior is
modified.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
lld] delta:%lld TIME EXTEND\n",
Please prefix hex values with "0x", as in:
pr_warn(" 0x%x: [%lld] delta:%lld TIME EXTEND\n"
Otherwise it can be confusing.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
se because they were now unused internally, without
expecting this impact for external users. The gradual deprecation plan
seems better indeed.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
Grub-devel mailing list
resource is causing more problems than it solves.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
In order to make sure I get CC'd on tracing changes for which my input
would be relevant, add my name as reviewer of the TRACING subsystem.
Signed-off-by: Mathieu Desnoyers
Cc: Steven Rostedt
Cc: Masami Hiramatsu
Cc: linux-trace-ker...@vger.kernel.org
---
MAINTAINERS | 1 +
1 file changed, 1
le process is going away anyway. It's like
tidying up your house right before it is scheduled to be bulldozed
away to make room for a new highway. :-)
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
in the
definition of "trivial", so I would advise to perhaps send those
patches to kernel-janit...@vger.kernel.org ?
[...]
+
+ close(fd);
These added calls to close(2) miss handling of possible close errors
(check return value and use errno to print an error).
Thanks,
Mathieu
tps://github.com/ClangBuiltLinux/linux/issues/1698
Link: https://github.com/ClangBuiltLinux/continuous-integration2/issues/61
Suggested-by: Mathieu Desnoyers
Signed-off-by: Justin Stitt
Reviewed-by: Mathieu Desnoyers
Peter, should this go through tip ?
Shuah, should to go through selftests ?
Tha
rcu/+/10911/1>. That ought to fix
the issue until we merge the patch.
Fix merged into liburcu master, thanks!
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
On 9/11/23 12:53, Justin Stitt wrote:
On Sat, Sep 9, 2023 at 5:37 AM Mathieu Desnoyers
wrote:
On 9/8/23 19:03, Justin Stitt wrote:
Hi,
I am experiencing many warnings when trying to build tools/testing/selftests.
Here's one such example from rseq tree:
| param_test.c:1234:10: error
up on our customer's
feature requirement radar yet.
Also, are there any recent docs to share regarding tracepoint latency?
There is a Polytechnique student who extensively analyzed this recently.
Michel, do you have a pointer to his work ?
Thanks,
Mathieu
--
Mathieu Desnoyers
sizeof(struct percpu_list_entry) * cpu, 1, cpu);
} while (rseq_unlikely(ret));
}
---
base-commit: 2dde18cd1d8fac735875f2e4987f11817cc0bc2c
change-id: 20230908-kselftest-param_test-c-1763b62e762f
Best regards,
--
Justin Stitt
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
On 8/23/23 10:47, Paul E. McKenney wrote:
On Mon, Aug 21, 2023 at 11:43:32AM -0400, Mathieu Desnoyers wrote:
On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases
On 8/15/23 08:38, Mathieu Desnoyers via lttng-dev wrote:
On 8/14/23 17:05, Olivier Dion via lttng-dev wrote:
After discussing it with Mathieu, we agree on the following 3 phases for
deprecating the signal flavor:
1) liburcu-signal will be implemented in term of liburcu-mb. The only
een various loads/stores to memory which
are typically not relevant to track from a TSAN perspective. Therefore
I suspect the working set of loads/stores that would need to be
tracked by TSAN would become impractically large.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
an existing shared object, therefore I'm not even sure we need to
bump the soname for all the other remaining shared objects.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev
file"
+
+if awk "BEGIN {exit !(${kernel_version} >= 6.1)}"; then
+ echo 'obj-y += lttng/' >> "${KERNEL_DIR}/Kbuild"
+else
+ sed -i 's#+= kernel/#+= kernel/ lttng/#' "${KERNEL_DIR}/Makefile"
+fi
echo >&2
echo "$0: done."
-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
prototype! Please
don't hesitate to reach out to EfficiOS if HPE would like to explore
supporting this project.
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https
all copies of this message. KPIT Technologies Ltd. does not
accept any liability for virus infected mails.
___
lttng-dev mailing list
lttng-dev@lists.lttng.org
https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev
--
Mathieu Desnoyers
EfficiOS Inc.
h
] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68622
[6] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86072
[7] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63273
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
s that can creep up.
Thanks,
Mathieu
--
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com
a versioned kernel ABI without different semantics
across kernel flavors, but considering the current situation we will
need to deal with this with scripts as we have done for other distributions.
Thanks,
Mathieu
All the best, Roxana
On 04/07/2023 20:07, Mathieu Desnoyers wrote:
On 7/4/23 11
101 - 200 of 11961 matches
Mail list logo
