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: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:   Fri, 19 Jul 2019 11:20:34 -0400
From:   Jeff Layton <jlayton@...nel.org>
To:     Luis Henriques <lhenriques@...e.com>,
        Ilya Dryomov <idryomov@...il.com>, Sage Weil <sage@...hat.com>
Cc:     ceph-devel@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH 0/4] Sleeping functions in invalid context bug fixes

On Fri, 2019-07-19 at 15:32 +0100, Luis Henriques wrote:
> Hi,
> 
> I'm sending three "sleeping function called from invalid context" bug
> fixes that I had on my TODO for a while.  All of them are ceph_buffer_put
> related, and all the fixes follow the same pattern: delay the operation
> until the ci->i_ceph_lock is released.
> 
> The first patch simply allows ceph_buffer_put to receive a NULL buffer so
> that the NULL check doesn't need to be performed in all the other patches.
> IOW, it's not really required, just convenient.
> 
> (Note: maybe these patches should all be tagged for stable.)
> 
> Luis Henriques (4):
>   libceph: allow ceph_buffer_put() to receive a NULL ceph_buffer
>   ceph: fix buffer free while holding i_ceph_lock in __ceph_setxattr()
>   ceph: fix buffer free while holding i_ceph_lock in
>     __ceph_build_xattrs_blob()
>   ceph: fix buffer free while holding i_ceph_lock in fill_inode()
> 
>  fs/ceph/caps.c              |  5 ++++-
>  fs/ceph/inode.c             |  7 ++++---
>  fs/ceph/snap.c              |  4 +++-
>  fs/ceph/super.h             |  2 +-
>  fs/ceph/xattr.c             | 19 ++++++++++++++-----
>  include/linux/ceph/buffer.h |  3 ++-
>  6 files changed, 28 insertions(+), 12 deletions(-)

This all looks good to me. I'll plan to merge these into the testing
branch soon, and tag them for stable.

PS: On a related note (and more of a question for Ilya)...

I'm wondering if we get any benefit from having our own ceph_kvmalloc
routine. Why are we not better off using the stock kvmalloc routine
instead? Forcing a vmalloc just because we've gone above 32k allocation
doesn't seem like the right thing to do.

PPS: I also wonder if we ought to put a might_sleep() in kvfree(). I
think that kfree generally doesn't, and I wonder how many uses of this
end up using kfree until memory ends up fragmented.
-- 
Jeff Layton <jlayton@...nel.org>

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ