> On Mar 8, 2021, at 1:49 AM, Aili Yao <yaoa...@kingsoft.com> wrote: > > On Sun, 7 Mar 2021 11:16:24 -0800 > Andy Lutomirski <l...@amacapital.net> wrote: > >>>>>>> Some programs may use read(2), write(2), etc as ways to check if >>>>>>> memory is valid without getting a signal. They might not want >>>>>>> signals, which means that this feature might need to be configurable. >>>>>> >>>>>> That sounds like an appalling hack. If users need such a mechanism >>>>>> we should create some better way to do that. >>>>>> >>>>> >>>>> Appalling hack or not, it works. So, if we’re going to send a signal to >>>>> user code that looks like it originated from a bina fide architectural >>>>> recoverable fault, it needs to be recoverable. A load from a failed >>>>> NVDIMM page is such a fault. A *kernel* load is not. So we need to >>>>> distinguish it somehow. >>>> >>>> Sorry for my previous mis-understanding, and i have some questions: >>>> if programs use read,write to check if if memory is valid, does it really >>>> want to cover the poison case? >> >> I don't know. >> >>>> When for such a case, an error is returned, can the program realize it's >>>> hwposion issue not other software error and process correctly? >> >> Again, I don't know. But changing the API like this seems potentialy >> dangerous and needs to be done with care. >> >>>> >>>> if this is the proper action, the original posion flow in current code >>>> from read and write need to change too. >>>> >>> >>> Sorry, another question: >>> When programs use read(2), write(2) as ways to check if memory is valid, >>> does it really want to check if the user page the program provided is >>> valid, not the destination or disk space valid? >> >> They may well be trying to see if their memory is valid. > > Thanks for your reply, and I don't know what to do. > For current code, if user program write to a block device(maybe a test try) > and if its user copy page corrupt when in kernel copy, the process is killed > with a SIGBUS. > And for the page fault case in this thread, the process is error returned.
Can you point me at that SIGBUS code in a current kernel? > > -- > Thanks! > Aili Yao
