Re: Bug 29863 - Segmentation fault in memcmp-sse2.S if memory contents can concurrently change

[Florian Weimer <fweimer@redhat.com>]

* Noah Goldstein:

> On Tue, Dec 13, 2022 at 1:20 PM Florian Weimer <fweimer@redhat.com> wrote:
>>
>> * Noah Goldstein via Libc-alpha:
>>
>> > Is this something we have to support? I believe other functions /
>> > implementations of memcmp will suffer from a similar bug.
>>
>> Of course the crash is by no means deterministic, so I'm not sure how
>> useful it is to detect application bugs.  Maybe papering over the
>> application bug is the right approach here.
>>
>> On the other hand, I really don't see how such a racing memcmp call
>> could deliver any useful information whatsoever.  The result will always
>> be arbitrary in practice.  So I hope such application bugs are really
>> rare.
>
> The usecase in the bugzilla is optimistic reads in concurrent
> databases.

So what happens is that whatever the result is, it is still validated
with some separate mechanism (e.g., a seqlock or some other form of TM)?
That does not seem unreasonable at all, so I'd be in favor of supporting
this, given that the cost is so low.

Thanks,
Florian