Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755550AbbBFUty (ORCPT ); Fri, 6 Feb 2015 15:49:54 -0500 Received: from mail-ie0-f176.google.com ([209.85.223.176]:44022 "EHLO mail-ie0-f176.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751877AbbBFUtw (ORCPT ); Fri, 6 Feb 2015 15:49:52 -0500 MIME-Version: 1.0 In-Reply-To: <20150206162303.18031.37408.stgit@buzz> References: <20150206162301.18031.32251.stgit@buzz> <20150206162303.18031.37408.stgit@buzz> Date: Fri, 6 Feb 2015 12:49:51 -0800 X-Google-Sender-Auth: BWdJxbXChMyeQ_opr-WpsEbG6TA Message-ID: Subject: Re: [PATCH 2/2] kernel/fork: handle put_user errors for CLONE_PARENT_SETTID From: Linus Torvalds To: Konstantin Khlebnikov Cc: Linux API , Andrew Morton , Linux Kernel Mailing List , Roman Gushchin , Nikita Vetoshkin , Oleg Nesterov , Pavel Emelyanov 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: 1222 Lines: 27 On Fri, Feb 6, 2015 at 8:23 AM, Konstantin Khlebnikov wrote: > Handling of flag CLONE_PARENT_SETTID has the same problem: error returned > from put_user() is ignored. Glibc completely relies on that feature and uses > value returned from syscall only for error checking. I'm not seeing the advantage of the error checking part of the pacth patch. It generates extra code, possibly changing existing interfaces, and it doesn't actually buy us anything. What's the upside? If somebody passes in a bad pointer, it's their problem. For all we know, people used to pass in NULL, even if they had the SETTID bit set. This makes it now return EFAULT. So I don't mind moving things into copy_process(), but I *do* mind the new error return thing. It's actually better in this patch than in 1/2, because 1/2 was just insane with the whole "readable vs writable" thing. That I refuse to even look at, for fear of going blind. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/