Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752291AbcJJUIO (ORCPT ); Mon, 10 Oct 2016 16:08:14 -0400 Received: from mail-oi0-f65.google.com ([209.85.218.65]:34859 "EHLO mail-oi0-f65.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751590AbcJJUIL (ORCPT ); Mon, 10 Oct 2016 16:08:11 -0400 MIME-Version: 1.0 In-Reply-To: References: <20161007222059.GS19539@ZenIV.linux.org.uk> From: Linus Torvalds Date: Mon, 10 Oct 2016 12:56:18 -0700 X-Google-Sender-Auth: PIGC4ECgqtJMVBllBryzbuDBz7c Message-ID: Subject: Re: [git pull] vfs pile 1 (splice) To: Christoph Lameter Cc: Al Viro , Andrew Morton , Jens Axboe , "Ted Ts'o" , Linux Kernel Mailing List , linux-fsdevel Content-Type: text/plain; charset=UTF-8 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1179 Lines: 29 On Mon, Oct 10, 2016 at 7:03 AM, Christoph Lameter wrote: > > Hmm.. Then get_freepointer_safe may not be ok. Should not trigger any > faults. So the reason seems to be that SLUB doesn't actually react well to double-freeing bugs. I'm not sure how to fix that. I think the optimistic load that SLUB does is actually important, since it is what allows the whole lock-free double_cmpxchg() approach. But the fact that it reacts _so_ badly to double-freeing issues when the freelist has become corrupted due to an object being free'd and then modified is clearly very fragile and not great. Doing a google search for "kmalloc", "oops" and "cmpxchg16b" does show that it happens: you can tell by how the trapping instruction is a load just before the cmpxchg16b instruction in the oops disassembly. Maybe we should just make "get_freepointer()" always handle traps. Right now it does that "probe_kernel_read()" conditionally, and it's a fairly costly operation, but we *could* make it cheaper. It's really just a single instruction with an exception entry (kind of like load_unaligned_zeropad() that we wrote for the dcache case). I dunno. Linus