From patchwork Tue Dec 11 11:16:53 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Michael McMaster X-Patchwork-Id: 1861831 Return-Path: X-Original-To: patchwork-linux-btrfs@patchwork.kernel.org Delivered-To: patchwork-process-083081@patchwork1.kernel.org Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by patchwork1.kernel.org (Postfix) with ESMTP id A6E313FCA5 for ; Tue, 11 Dec 2012 11:17:09 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752559Ab2LKLRF (ORCPT ); Tue, 11 Dec 2012 06:17:05 -0500 Received: from mail-pa0-f46.google.com ([209.85.220.46]:56279 "EHLO mail-pa0-f46.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751223Ab2LKLRE (ORCPT ); Tue, 11 Dec 2012 06:17:04 -0500 Received: by mail-pa0-f46.google.com with SMTP id bh2so2810129pad.19 for ; Tue, 11 Dec 2012 03:17:04 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:message-id:date:from:user-agent:mime-version:to:subject :x-enigmail-version:content-type; bh=CxylPZoMf1BZyr5DgbQ55Vpy/C1+35i0kohAN+afDoE=; b=TLEClfVtzk7ENzRFmaIq1mUOTuD/nCF3L+9JhFzcPFqLAx/y6nmPZ7vT5n4qUEBcDJ I6rAQ21x204dF//TPGmSopavzJbGSqj9aJrkpD5TX7YNg8PFLn568USrvSqYPoF7Q/Qq 8uQ4CX5fPaYq129azWgr+KeFBj+j1UoU2283xI5OGuQBM5uyURMqE1Bfe7WJOo0hX6io qhf2Jt6RTUy65iO/D5VkPnrWy8Ld2nA0ygs50KHgUwOkUE34TywNbk3y1EOxw+VvyC3x DEAtK+4K7m0Ok8rggN2vYobMNKm2NyooWCTMYS7X8TY/7LHkRZkG50aBTe7jlj1nYHW+ horA== Received: by 10.68.192.97 with SMTP id hf1mr47262401pbc.106.1355224624137; Tue, 11 Dec 2012 03:17:04 -0800 (PST) Received: from [60.241.109.145] ([60.241.109.145]) by mx.google.com with ESMTPS id pv8sm13609916pbc.26.2012.12.11.03.17.02 (version=SSLv3 cipher=OTHER); Tue, 11 Dec 2012 03:17:03 -0800 (PST) Message-ID: <50C71625.1010003@codesrc.com> Date: Tue, 11 Dec 2012 21:16:53 +1000 From: Michael McMaster User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.10) Gecko/20121027 Icedove/10.0.10 MIME-Version: 1.0 To: linux-btrfs@vger.kernel.org Subject: Patch for resolving loop devices X-Enigmail-Version: 1.4.1 Sender: linux-btrfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-btrfs@vger.kernel.org I experienced an error where mkfs.btrfs failed when an unrelated cryptoloop device was mounted. $ sudo /tmp/btrfs-progs/mkfs.btrfs /dev/mapper/mydisk WARNING! - Btrfs v0.20-rc1-37-g91d9eec-dirty IS EXPERIMENTAL WARNING! - see http://btrfs.wiki.kernel.org before using error checking /dev/mapper/mydisk mount status $ sudo losetup -a /dev/loop0: [0014]:71314 (/home/michael/loopfile), encryption aes (type 18) I found that resolve_loop_device() method in utils.c was returning "aes" as the associated file, instead of /home/michael/loopfile. This eventually causes the realpath() call in is_same_blk_file() to fail. The attached patch fixes this problem. Regards, Michael McMaster --- utils.c.orig 2012-12-11 21:00:07.000000000 +1000 +++ utils.c 2012-12-11 21:00:26.000000000 +1000 @@ -653,16 +653,16 @@ { int loop_fd; int ret_ioctl; - struct loop_info loopinfo; + struct loop_info64 loopinfo; if ((loop_fd = open(loop_dev, O_RDONLY)) < 0) return -errno; - ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS, &loopinfo); + ret_ioctl = ioctl(loop_fd, LOOP_GET_STATUS64, &loopinfo); close(loop_fd); if (ret_ioctl == 0) { - strncpy(loop_file, loopinfo.lo_name, max_len); + strncpy(loop_file, loopinfo.lo_file_name, max_len); if (max_len > 0) loop_file[max_len-1] = 0; } else