[DTrace-devel] [PATCH 1/2] dt_link: retry elf_update() without mmaps if writing fails

[Nick Alcock]

On 23 May 2023, Steven Sistare said:

> On 5/23/2023 12:26 PM, Steven Sistare wrote:
>> On 5/22/2023 6:24 PM, Nick Alcock wrote:
>>> But we know that calls in a subsequent process_obj() invocation on the
>>> same file will be identical to the calls that already happened: it's
>>> just that dt_probe_define() doesn't check for existing offsets.  Maybe
>>> it should, but doing so efficiently is quite a lot more work than just
>>> noting that this is a reinvocation of process_obj() and skipping the
>>> define on the grounds that it already happened.
>>>
>>> Orabug: 35416271
>>> Signed-off-by: Nick Alcock <nick.alcock at oracle.com>
>> 
>> Just a heads up, I applied this patch and dlink has munged the file that previously
>> failed with ELF_C_RDWR_MMAP.
>> 
>> /usr/bin/ld: nbd/server.o: attempt to load strings from a non-string section (number 35)
>> nbd/server.o: file not recognized: Bad value
>> 
>> I will debug it.
>
> The problem is that libelf writes to the object before failing, corrupting it.  Using
> the un-patched dtrace:

Oh dammit. I was hoping that elf_update() didn't modify the file before
it failed (I couldn't see any sign of it, but clearly it does).

> To fix, we would need to proactively make a backup copy of the object, to be restored 
> before retrying.  Which defeats the purpose of ELF_C_RDWR_MMAP.

Yeah.

> So, back to supplying an env var or command-line option to disable ELF_C_RDWR_MMAP?

A DTrace option seems best, though fairly horrible. I'll add one. (Of
course, this means that people who actually hit the bug presumably will
have to delete and recreate the input .o file before rerunning...)

Back with another patch soon.

-- 
NULL && (void)