linux-kernel - Re: loop device auto release patch

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 15 Jul 2011 12:19:03 -0700
From:	Andrew Morton <akpm@...ux-foundation.org>
To:	Phillip Susi <psusi@....rr.com>
Cc:	Ayan George <ayan@...n.net>, linux-kernel@...r.kernel.org
Subject: Re: loop device auto release patch

On Fri, 15 Jul 2011 15:12:50 -0400
Phillip Susi <psusi@....rr.com> wrote:

> On 7/14/2011 2:56 PM, Ayan George wrote:
> >
> > Hi Philip,
> >
> > This is the patch I'd like to submit for the loop device. I'm in the
> > process of testing it now. I'm pretty confident it will work.
>
> Looks good to me.  Forwarding to Andrew Morton.  Andrew, please 
> disregard my previous patch as I think this one is better.

Would prefer to wait until Ayan has completed testing it.  It would be
good if you were to test it too please.
 
> 
> [0001-Always-invalidate-cleared-loop-block-devices.patch  text/x-patch (2.9KB)]
> >From c783ba6a26eff42d3cb0061e4fcb8ee8a16b3e67 Mon Sep 17 00:00:00 2001
> From: Ayan George <ayan.george@...onical.com>
> Date: Thu, 14 Jul 2011 14:16:58 -0400
> Subject: [PATCH] Always invalidate cleared loop block devices
> 
> The API for loop_clr_fd() is confusing -- the second argument (bdev)
> isn't necessesary as struct loop_device contains a pointer to the block
> device it is assocated with.
> 
> There is a cases where loop_clr_fd() is called with NULL for bdev
> which prevents the block device from ever being invalidated with
> invalidate_bdev() and prevents a uevent from being emitted.
> 
> This patch removes the bdev argument from loop_clr_fd(), unconditionally
> invalidates lo->lo_device when cleared, and unconditionally emits a
> uevent for removed loops.

The patch appears to do two unrelated things.  That's generally frowned
upon, but doesn't bother me much if the patch is small.

Still, splitting it into two patches (in which the bugfix is staged
first) would be advantageous for people who might wish to backport the
fix into earlier kernels.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/