Hi Heather,
On Sat, 2023-10-14 at 13:29 -0500, Heather McIntyre wrote:
> I have a quick query regarding how you'd prefer to handle these changes.
> Would you like me to implement some of the recommended modifications and
> commit them (if possible), or would you prefer that I simply leave
> comm
John and I discussed that atomic_compare_exchange_strong could have been
used here. I see that this has been pushed to the main branch, but I can
make the change to the atomic operation if you think that is a better
option.
Best,
Heather
On Tue, Oct 10, 2023 at 9:00 AM Mark Wielaard wrote:
> Hi
You are right that if elf->map_address != NULL then the acquired wrlock is
not unlocked. The rwlock_unlock that was there initially was removed due to
deadlocking when returning from inside the if statement, but this was not
correct. However, adding ‘else rwlock_unlock (elf->lock)’ at the end of th
You are right. I changed the code to just rely on if (__libelf_readall
(elf) == NULL) and this seems to work just fine.
On Tue, Oct 10, 2023 at 10:23 AM Mark Wielaard wrote:
> Hi Heather,
>
> On Tue, 2023-10-10 at 15:42 +0200, Mark Wielaard wrote:
> > From: Heather McIntyre
> >
> > * libe
https://sourceware.org/bugzilla/show_bug.cgi?id=30978
Bug ID: 30978
Summary: debuginfod-client security: optionally(?) verify
downloaded binaries
Product: elfutils
Version: unspecified
Status: UNCONFIRMED
Severi
Thank you for pointing out that changes to these two files are not needed
due to them being single threaded utilities. I reverted the changes and ran
some tests. Works just fine with the original search.h, tsearch, and tfind.
On Tue, Oct 10, 2023 at 4:26 PM Mark Wielaard wrote:
> Hi Heather,
>
>
Since it wasn't too complicated to do, I implemented a dwarf object lock
(per struct dwarf lock) instead of having the static global lock. As per
your suggestion, I placed the lock over the whole dwarf_getalt function, so
now find_debug_altlink is called with the lock already acquired. In
addition,
https://sourceware.org/bugzilla/show_bug.cgi?id=30978
--- Comment #1 from Dominique Martinet ---
Relevant part of the fedora-devel thread at the time, justifying there'd be
interest in distros:
https://www.mail-archive.com/devel@lists.fedoraproject.org/msg166474.html
(sorry for double-update, to
Hi Mark,
I see now that this is incomplete considering the other places that also
call this function. I do agree that global locking may be heavy if 1)
implemented in all of these locations, or 2) implemented directly in
__libdw_dieabbrev. We could use atomics here directly in __libdw_dieabbrev.
I
Hi Mark,
As per your suggestion, I have placed the lock around the entire
__libdw_find_split_unit function call.
On Wed, Oct 11, 2023 at 12:17 PM Mark Wielaard wrote:
> Hi Heather,
>
> On Tue, Oct 10, 2023 at 03:42:56PM +0200, Mark Wielaard wrote:
> > From: Heather McIntyre
> >
> > * (tr
Hi Mark,
For the call to __libdw_intern_next_unit in __libdw_findcu, I have updated
the locking to the per struct drawf lock. Although I have not encountered a
data race report regarding the call to __libdw_intern_next_unit in
dwarf_formref_die, I have also placed the updated locking there as well
Hi Mark,
I think having unique per-root locks might be a good idea. From a brief
test, I saw around 70 roots created when parsing the test file I have been
using. I have an initial idea for this that I don't think will be too
complicated. I will go over my idea with John to get his input and then
https://sourceware.org/bugzilla/show_bug.cgi?id=30978
Frank Ch. Eigler changed:
What|Removed |Added
CC||fche at redhat dot com
--- Comment
https://sourceware.org/bugzilla/show_bug.cgi?id=30978
--- Comment #3 from Dominique Martinet ---
Interesting, thanks for the link!
The implementation hurdle is a bit higher than updating the already-used
objcopy command I was suggesting (won't be available for distros like debian
that don't ship
14 matches
Mail list logo
