Received: by 2002:a05:6a10:a0d1:0:0:0:0 with SMTP id j17csp2746880pxa; Tue, 25 Aug 2020 02:00:12 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxAjIY+6aVpf2MjEAL6qZmveaV5fNZrDjJX8wXXbf7j+YX+gu3mMMM5eMiLNZS109UXewDm X-Received: by 2002:a50:9fe9:: with SMTP id c96mr4152361edf.327.1598346012511; Tue, 25 Aug 2020 02:00:12 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1598346012; cv=none; d=google.com; s=arc-20160816; b=IqULW5I5HRabCI0Clpf+v+k6UPDCyWnGbO+BYJMQhhXsumytIadYtoGRpFmUy6L1xg o91L3Yqjpo+AFJKZTll2ItOVJLE9/9OMCsPQRQMpjsCL2Htjb9SVQ4xcjF+1J7CUrhA3 u8I555uHrLllYrBip3TLswYj9OIlfCOJ0S6oMZmzedMCssWwOrKw6BeblwNrNwamm9dW 5SOsRsFYp7NvfRly6ld688EAT0UmUJDBDwBx1i1LRtv48yJKRDnPgjk7gSMjL6cnhlwE lCIei9RXPFjfnto9EGfiDL8/46Ar1RQOfYY18LeOCnhw6rryTe/caCKFhky+39MspLTI SUow== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=LWvQJmkrnmEIXZZ3m3NQCmqtplrJpyZpyg/o+bfnJmk=; b=qLjuT5yI6JlB5sBNvB4rluxdG0TVG1YYyjMAS6+rPebej1NyuZn1Xr1vmWrqYnOyIv +fOQRPjGqLdeni+aj1W4++glV6EWCIWUipCJvIEhV74cT13sdebtbs5EvGcUt2fwh6DK QDSmmCu/zNDdXYZe1HNNEZYtfE3D6xAmUJueb8Bg/YTKy91csAoq48GweExqjz1/Yxn/ 9dHzjZNUAMx+56r9ce5iD4T6BrkR/sRdl///daHrvjCwPXSndAwmNDZJJ46HKL5aMycE mLsPGEtf5j1iRntnzWVoBlys405UrrLzy/2nhiqZyD1HORVxt4iNKsw8ZbP1h6uNhjLD hUZA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=MInaNUgn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id d90si7057476edd.489.2020.08.25.01.59.49; Tue, 25 Aug 2020 02:00:12 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@android.com header.s=20161025 header.b=MInaNUgn; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=android.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729381AbgHYHUl (ORCPT + 99 others); Tue, 25 Aug 2020 03:20:41 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:50252 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729277AbgHYHUl (ORCPT ); Tue, 25 Aug 2020 03:20:41 -0400 Received: from mail-lf1-x143.google.com (mail-lf1-x143.google.com [IPv6:2a00:1450:4864:20::143]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id AF832C061574 for ; Tue, 25 Aug 2020 00:20:40 -0700 (PDT) Received: by mail-lf1-x143.google.com with SMTP id j15so5847988lfg.7 for ; Tue, 25 Aug 2020 00:20:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=android.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=LWvQJmkrnmEIXZZ3m3NQCmqtplrJpyZpyg/o+bfnJmk=; b=MInaNUgnNlhGKEt7t59LrOLAkQfHi07yS38zUrGAb31g5p/yELmauj4uOqNWLb6upQ b2qdgKwN4nz31yW2hNDWVD1nIFK/ItIaHEkA2+9oScyT27YwivO+8RjC4nNikXGov4dp l/lB0aXorQ2lMUV6N2UzILuL1d9x1N0itJEIs0qZQzxL/aUF2jpKrgbHKFfSIJQ+jHd0 BCLNefg3RRim+GdWCfwaT1rSo/QqHWs1QIBGRKuCWJZyR51YCsINfRpk8+msMXT5iOiA W7hUUwqghSUGOzWTJCgkKdwTx1rRh2A61TARMB5FTdSH0q+wE6BN+tudmqNy4b1FpFqM Oxww== 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=LWvQJmkrnmEIXZZ3m3NQCmqtplrJpyZpyg/o+bfnJmk=; b=jjWMqCX6yPH2MgtEJAVw87U0wUGXTkB0gWKB6HF5Guh5cVKOU0f8nWnIeDgIy6fupW HPFsAvK2Lt2NHduoB67imEeqH6X5Tg6fcxSmyIsXYkVYXl4cUO6ZCLh7QrhNr9waYNM4 OcPMLHBGp/y7YlVgjjE0U4/FJvXarl86XJfTJyahQn2H8vYLnD1hqwHDwLlSes8aAQzk aii0KeQzK4AUav7mP7+zIJcL4jaAepyUJdun8/Ja3PcZl3DqbH0DHgN+W6DH7l9MAVfC BhetvLqlth5V7hc+Iy9w8Gbl7JwOA4rxi8hZbFVD8abL8i1ABr40W3rJOXYI8U/tTaQU SyQg== X-Gm-Message-State: AOAM533Irg3WZt/hhvv4xsCBck7E/S/cFag8kFmd9jg0wavbIbKXsQIw +B2ehjpM5n1+8GWmUrBq3yBQiLOBTkTUihK8Jnb8POS7AkvUgw== X-Received: by 2002:a19:cb45:: with SMTP id b66mr4279527lfg.179.1598340039088; Tue, 25 Aug 2020 00:20:39 -0700 (PDT) MIME-Version: 1.0 References: <20200824154436.GA255257@gardel-login> In-Reply-To: From: Martijn Coenen Date: Tue, 25 Aug 2020 09:20:28 +0200 Message-ID: Subject: Re: LOOP_CONFIGURE ioctl doesn't work if lo_offset/lo_sizelimit are set To: Lennart Poettering Cc: linux-block , LKML , Jens Axboe , Christoph Hellwig , Yang Xu Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Hi, I just sent a patch to fix the issue. The loop device would have respected the configuration, but indeed the size of the underlying block device was not set correctly, so reading back the size would give the wrong result. Thanks, Martijn On Mon, Aug 24, 2020 at 8:24 PM Martijn Coenen wrote: > > Hi Lennart, > > Thanks for the report, I'll look into it. FWIW, we've been using > LOOP_CONFIGURE on Android with lo_offset/lo_sizelimit without issues, > but it may be a particular configuration that's causing issues. > > Thanks, > Martijn > > On Mon, Aug 24, 2020 at 5:44 PM Lennart Poettering wrote: > > > > Hi! > > > > Even with fe6a8fc5ed2f0081f17375ae2005718522c392c6 the LOOP_CONFIGURE > > ioctl doesn't work correctly. It gets confused if the > > lo_offset/lo_sizelimit fields are set to non-zero. > > > > In a quick test I ran (on Linux 5.8.3) I call LOOP_CONFIGURE with > > .lo_offset=3221204992 and .lo_sizelimit=50331648 and immediately > > verify the size of the block device with BLKGETSIZE64. It should of > > course return 50331648, but actually returns 3271557120. (the precise > > values have no particular relevance, it's just what I happened to use > > in my test.) If I instead use LOOP_SET_STATUS64 with the exact same > > parameters, everything works correctly. In either case, if I use > > LOOP_GET_STATUS64 insted of BLKGETSIZE64 to verify things, everything > > looks great. > > > > My guess is that the new ioctl simply doesn't properly propagate the > > size limit into the underlying block device like it should. I didn't > > have the time to investigate further though. > > > > Lennart