On Fri, Jun 04, 2021 at 06:24:07PM +0300, Kirill A. Shutemov wrote: > On Fri, Jun 04, 2021 at 12:43:22AM -0700, Ming Lin wrote: > > Adds new flag MAP_NOSIGBUS of mmap() to specify the behavior of > > "don't SIGBUS on fault". Right now, this flag is only allowed > > for private mapping. > > That's not what your use case asks for. Simon explained the use case here: https://bit.ly/3wR85Lc FYI, I copied here too. ------begin------------------------------------------------------------------- Regarding the requirements for Wayland: - The baseline requirement is being able to avoid SIGBUS for read-only mappings of shm files. - Wayland clients can expand their shm files. However the compositor doesn't need to immediately access the new expanded region. The client will tell the compositor what the new shm file size is, and the compositor will re-map it. - Ideally, MAP_NOSIGBUS would work on PROT_WRITE + MAP_SHARED mappings (of course, the no-SIGBUS behavior would be restricted to that mapping). The use-case is writing back to client buffers e.g. for screen capture. From the earlier discussions it seems like this would be complicated to implement. This means we'll need to come up with a new libwayland API to allow compositors to opt-in to the read-only mappings. This is sub-optimal but seems doable. - Ideally, MAP_SIGBUS wouldn't be restricted to shm. There are use-cases for using it on ordinary files too, e.g. for sharing ICC profiles. But from the earlier replies it seems very unlikely that this will become possible, and making it work only on shm files would already be fantastic. ------end------------------------------------------------------------------- > > SIGBUS can be generated for a number of reasons, not only on fault beyond > end-of-file. vmf_error() would convert any errno, except ENOMEM to > VM_FAULT_SIGBUS. > > Do you want to ignore -EIO or -ENOSPC? I don't think so. > > > For MAP_NOSIGBUS mapping, map in the zero page on read fault > > or fill a freshly allocated page with zeroes on write fault. > > I don't like the resulting semantics: if you had a read fault beyond EOF > and got zero page, you will still see zero page even if the file grows. > Yes, it's allowed by POSIX for MAP_PRIVATE to get out-of-sync with the > file, but it's not what users used to. Actually old version did support file grows. https://github.com/minggr/linux/commit/77f3722b94ff33cafe0a72c1bf1b8fa374adb29f We can support this if there is real use case. > > It might be enough for the use case, but I would rather avoid one-user > features.
