Messages in this thread | | | From | Jue Wang <> | Date | Thu, 22 Jul 2021 21:16:40 -0700 | Subject | Re: [PATCH 2/3] x86/mce: Avoid infinite loop for copy from user recovery |
| |
On Thu, Jul 22, 2021 at 9:01 PM Luck, Tony <tony.luck@intel.com> wrote: > > >> I'm not aware of, nor expecting to find, places where the kernel > >> tries to access user address A and hits poison, and then tries to > >> access user address B (without returrning to user between access > >> A and access B). > >This seems a reasonablely easy scenario. > > > > A user space app allocates a buffer of xyz KB/MB/GB. > > > > Unfortunately the dimms are bad and multiple cache lines have > > uncorrectable errors in them on different pages. > > > > Then the user space app tries to write the content of the buffer into some > > file via write(2) from the entire buffer in one go. > > Before this patch Linux gets into an infinite loop taking machine > checks on the first of the poison addresses in the buffer. > > With this patch (and also patch 3/3 in this series). There are > a few machine checks on the first poison address (I think the number > depends on the alignment of the poison within a page ... but I'm > not sure). My test code shows 4 machine checks at the same > address. Then Linux returns a short byte count to the user > showing how many bytes were actually written to the file. > > The fast that there are many more poison lines in the buffer > beyond the place where the write stopped on the first one is > irrelevant. In our test, the application memory was anon. With 1 UC error injected, the test always passes with the error recovered and a SIGBUS delivered to user space.
When there are >1 UC errors in buffer, then indefinite mce loop. > > [Well, if the second poisoned line is immediately after the first > you may hit h/w prefetch issues and h/w may signal a fatal > machine check ... but that's a different problem that s/w could > only solve with painful LFENCE operations between each 64-bytes > of the copy] > > -Tony
| |