On Mon, 25 Apr 2016 21:07:17 +0800 Jonas Ådahl <[email protected]> wrote:
> 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? If it happened only the first time, sure. But I am told Xwayland actually gets into an endless loop with the particular fallocate never returning anything but EINTR all the time. Thanks, pq > > > > > >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
pgpRQpEbMdrLY.pgp
Description: OpenPGP digital signature
_______________________________________________ wayland-devel mailing list [email protected] https://lists.freedesktop.org/mailman/listinfo/wayland-devel
