On 13.10.21 13:55, Jan Kiszka via Xenomai wrote: > From: Jan Kiszka <jan.kis...@siemens.com> > > VM_DENYWRITE was removed in 5.15, so we need a different criteria. > Absence of a file-backing seems to be a good one.
Bringing this one up, because we recently had a "report" on the ML regarding VM_DENYWRITE. I scanned the ld (dynamic loader) sources today. I was interested if there is any magic involved when mapping DSOs to the vma of the process. AFAICT there is none. I would expect the vma to be file-backed (=vma->vm_file =! NULL), so not sure if that is going to work. Btw: Subject talks about vDSO, which is not what we are looking at here. Just to make sure I got all that right: We need a way to figure out if the reason for the thread relax was caused by the executable itself, or any of it's dependencies, right? > > Signed-off-by: Jan Kiszka <jan.kis...@siemens.com> > --- > kernel/cobalt/debug.c | 12 +++++------- > 1 file changed, 5 insertions(+), 7 deletions(-) > > diff --git a/kernel/cobalt/debug.c b/kernel/cobalt/debug.c > index a6e2cc42d3..0521fca45d 100644 > --- a/kernel/cobalt/debug.c > +++ b/kernel/cobalt/debug.c > @@ -249,13 +249,12 @@ void xndebug_trace_relax(int nr, unsigned long > *backtrace, > continue; > > /* > - * Hack. Unlike DSOs, executables and interpreters > - * (e.g. dynamic linkers) are protected against write > - * attempts. Use this to determine when $pc should be > - * fixed up by subtracting the mapping base address in > - * the DSO case. > + * DSOs are not file-backed. Use this to determine when $pc > + * should be fixed up by subtracting the mapping base address > + * in the DSO case. > */ > - if (!(vma->vm_flags & VM_DENYWRITE)) > + file = vma->vm_file; > + if (file == NULL) > pc -= vma->vm_start; > > spot.backtrace[depth].pc = pc; > @@ -265,7 +264,6 @@ void xndebug_trace_relax(int nr, unsigned long *backtrace, > * record the PC value, which may still give some hint > * downstream. > */ > - file = vma->vm_file; > if (file == NULL) > goto next_frame; >
