From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.6 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM, HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 9CA12C2D0EA for ; Wed, 8 Apr 2020 16:12:45 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 6E1F320730 for ; Wed, 8 Apr 2020 16:12:45 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=gmail.com header.i=@gmail.com header.b="PlMdjefx" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729684AbgDHQMo (ORCPT ); Wed, 8 Apr 2020 12:12:44 -0400 Received: from mail-io1-f68.google.com ([209.85.166.68]:44218 "EHLO mail-io1-f68.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1727933AbgDHQMo (ORCPT ); Wed, 8 Apr 2020 12:12:44 -0400 Received: by mail-io1-f68.google.com with SMTP id h6so601324iok.11 for ; Wed, 08 Apr 2020 09:12:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=5UeHvRZgHUoaBNGTkCp7AEmXDKHN9fduNv5LerfvrBk=; b=PlMdjefxxfmPTbYFmpyeI+ogOFyw83wJRhhIte5JXC2T80en4MujXn9u8lDoSOESfA B1Jtx6W6ze6J7gm/WF6mwbkHYrPQq7GOGy++s6+3YBdncBU8yqb28OBNgtRCvzQr8rhe BCWkhY+XeU94pPU+sEgotN1tw79sBbaOUvVM0G+tb2iZr5nJsNdpiAL1wKAqqS6gJD2q RZGA0YMXvQYAu+WWcdJ/dw/OwITrNJhpnzbmVnA9v4Y5IhLvYWK0WKTeP47XjOuZ36sF pgp4ny+R6ZUTMBRfoBZcSyd4X7i7Ni1qx+80LW2R620pnx2IarOJb/31gLF6xJjcu7lk /UUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=5UeHvRZgHUoaBNGTkCp7AEmXDKHN9fduNv5LerfvrBk=; b=A09gMNfex2PTfWZwzYUEcVyWwWabYlka8+APujDqzgpU0jJucx/bvNJJpQWeDcxBbw 2DZlubmHzHuqXukryY2VTeDbwcEBJzmWGYxefgzUFBrvl9mIeGDhcv2Rex37J7yCL089 jWvqijPF1AmamYrMLyuM9XGcbtZC4XQh8zhvrCR1pplv/0ryrgqnqC1wfNX+XQBQe8PA U/eYLpacakjDdsa6W4b0rBJrbXsgf/bEThzqI+RUH0up8NVhHjE5YcajnUS1R0o/BYCU YO/yB2BIk3bySC817t/uy8f675V6pSyL4ZdZxxyAABgrXXWKZWSFiwUGes5RVPWBMwQD 6Nkg== X-Gm-Message-State: AGi0PuYf9J8ckKNbLzYuD+bQcDIjQ+wuve+TVfDRZkeUYUWqcblAhpjT rfjFNaihYRXl6rC1M9LDszrP1mdbFt+f6+c2lAqTCPM4 X-Google-Smtp-Source: APiQypKdohiD0VDVA8iFJDOkRQy0zmDYk4Djkiqat+HEvXhx8g00Q3p/EZ5P1ha1SqGhXu6vZ8D4cSErzl/nyz0aPnI= X-Received: by 2002:a02:a49a:: with SMTP id d26mr7487591jam.117.1586362363736; Wed, 08 Apr 2020 09:12:43 -0700 (PDT) MIME-Version: 1.0 References: <3a70c47f-d017-9f11-a41b-fa351e3906dc@kernel.dk> <47ce7e4b-42d9-326d-f15e-8273a7edda7a@kernel.dk> In-Reply-To: <47ce7e4b-42d9-326d-f15e-8273a7edda7a@kernel.dk> From: Dmitry Kadashev Date: Wed, 8 Apr 2020 23:12:31 +0700 Message-ID: Subject: Re: io_uring's openat doesn't work with large (2G+) files To: Jens Axboe Cc: io-uring@vger.kernel.org Content-Type: text/plain; charset="UTF-8" Sender: io-uring-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: io-uring@vger.kernel.org On Wed, Apr 8, 2020 at 10:49 PM Jens Axboe wrote: > > On 4/8/20 8:41 AM, Dmitry Kadashev wrote: > > On Wed, Apr 8, 2020 at 10:36 PM Jens Axboe wrote: > >> > >> On 4/8/20 8:30 AM, Dmitry Kadashev wrote: > >>> On Wed, Apr 8, 2020 at 10:19 PM Jens Axboe wrote: > >>>> > >>>> On 4/8/20 7:51 AM, Dmitry Kadashev wrote: > >>>>> Hi, > >>>>> > >>>>> io_uring's openat seems to produce FDs that are incompatible with > >>>>> large files (>2GB). If a file (smaller than 2GB) is opened using > >>>>> io_uring's openat then writes -- both using io_uring and just sync > >>>>> pwrite() -- past that threshold fail with EFBIG. If such a file is > >>>>> opened with sync openat, then both io_uring's writes and sync writes > >>>>> succeed. And if the file is larger than 2GB then io_uring's openat > >>>>> fails right away, while the sync one works. > >>>>> > >>>>> Kernel versions: 5.6.0-rc2, 5.6.0. > >>>>> > >>>>> A couple of reproducers attached, one demos successful open with > >>>>> failed writes afterwards, and another failing open (in comparison with > >>>>> sync calls). > >>>>> > >>>>> The output of the former one for example: > >>>>> > >>>>> *** sync openat > >>>>> openat succeeded > >>>>> sync write at offset 0 > >>>>> write succeeded > >>>>> sync write at offset 4294967296 > >>>>> write succeeded > >>>>> > >>>>> *** sync openat > >>>>> openat succeeded > >>>>> io_uring write at offset 0 > >>>>> write succeeded > >>>>> io_uring write at offset 4294967296 > >>>>> write succeeded > >>>>> > >>>>> *** io_uring openat > >>>>> openat succeeded > >>>>> sync write at offset 0 > >>>>> write succeeded > >>>>> sync write at offset 4294967296 > >>>>> write failed: File too large > >>>>> > >>>>> *** io_uring openat > >>>>> openat succeeded > >>>>> io_uring write at offset 0 > >>>>> write succeeded > >>>>> io_uring write at offset 4294967296 > >>>>> write failed: File too large > >>>> > >>>> Can you try with this one? Seems like only openat2 gets it set, > >>>> not openat... > >>> > >>> I've tried specifying O_LARGEFILE explicitly, that did not change the > >>> behavior. Is this good enough? Much faster for me to check this way > >>> that rebuilding the kernel. But if necessary I can do that. > >> > >> Not sure O_LARGEFILE settings is going to do it for x86-64, the patch > >> should fix it though. Might have worked on 32-bit, though. > > > > OK, will test. > > Great, thanks. FWIW, tested here, and it works for me. Great, will post results tomorrow. > > Any objection to adding your test cases to the liburing regression > suite? Feel free to! > > -- > Jens Axboe > -- Dmitry