On Mon, Apr 25, 2016 at 02:38:21PM +0200, Marek Chalupa wrote: > > On 04/25/16 12:20, Pekka Paalanen wrote: > >On Mon, 25 Apr 2016 11:33:00 +0200 > >Marek Chalupa <[email protected]> wrote: > > > >>If posix_fallocate or ftruncate is interrupted by signal > >>while working, we return -1 as fd and the allocation process > >>returns BadAlloc error. That causes xwayland clients to abort > >>with 'BadAlloc (insufficient resources for operation)' > >>even when there's a lot of resources available. > >> > >>Fix it by trying again when we get EINTR. > >> > >>Signed-off-by: Marek Chalupa <[email protected]> > >>--- > >> hw/xwayland/xwayland-shm.c | 10 ++++++++-- > >> 1 file changed, 8 insertions(+), 2 deletions(-) > >> > >>diff --git a/hw/xwayland/xwayland-shm.c b/hw/xwayland/xwayland-shm.c > >>index e8545b3..c199e5e 100644 > >>--- a/hw/xwayland/xwayland-shm.c > >>+++ b/hw/xwayland/xwayland-shm.c > >>@@ -140,14 +140,20 @@ os_create_anonymous_file(off_t size) > >> return -1; > >> > >> #ifdef HAVE_POSIX_FALLOCATE > >>- ret = posix_fallocate(fd, 0, size); > >>+ do { > >>+ ret = posix_fallocate(fd, 0, size); > >>+ } while (ret == EINTR); > >>+ > >> if (ret != 0) { > >> close(fd); > >> errno = ret; > >> return -1; > >> } > >> #else > >>- ret = ftruncate(fd, size); > >>+ do { > >>+ ret = ftruncate(fd, size); > >>+ } while (ret == -1 && errno == EINTR); > >>+ > >> if (ret < 0) { > >> close(fd); > >> return -1; > > > >Hi Marek, > > > >curious, how did you hit this case? And is the signal that intercept > >these usually the smart scheduler's SIGALRM? > > Hi Pekka, > > under gnome-shell it's enough to open terminator and resize it very > quickly. Under Weston (and also gnome-shell) I hit this with Firefox. > Just start it and in a moment it goes down with this error. > > Yes, it looks like SIGALRM (I put assert on change of SmartScheduleTime > when fallocate fails) > > >I am asking, because I have someone suffering from the EINTR issue, but > >a simple restart like what you implemented here results in an endless > >loop. A new signal arrives before fallocate completes every time. It is > >like fallocate is not making any progress. > > > >What is more curious is that the file is supposedly on a tmpfs, yet in > >our case the 5 ms is not enough to fallocate a full-HD frame (8 MB). It > >is a "Low powered NXP arm platform" I am told, I do not have access to > >it myself.
Couldn't it just as well be that the allocation started 0.01 ms before the SIGALRM that interrupted it? > > > >It may be the platform's fault that fallocate takes such a long time. > >Another thing is whether fallocate should make gradual progress or not; > >if not, simple restart will not work against a regular timer signal. > > Here the platform is x86_64. Actually, this started happening some time > ago, but it was fine before. I don't know what made the change. Not too long ago the posix_fallocate() support was fixed in Xwayland. Some configure.ac rules were missing and we were simply never ever building those lines behind the #ifdef. I assume this is what made this issue suddenly show up. Jonas _______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
