From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752945Ab2HOOac (ORCPT ); Wed, 15 Aug 2012 10:30:32 -0400 Received: from casper.infradead.org ([85.118.1.10]:38233 "EHLO casper.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750854Ab2HOOab convert rfc822-to-8bit (ORCPT ); Wed, 15 Aug 2012 10:30:31 -0400 Message-ID: <1345041021.31459.88.camel@twins> Subject: Re: yama_ptrace_access_check(): possible recursive locking detected From: Peter Zijlstra To: Oleg Nesterov Cc: Kees Cook , Fengguang Wu , LKML Date: Wed, 15 Aug 2012 16:30:21 +0200 In-Reply-To: <20120815130159.GA3221@redhat.com> References: <20120726134748.GA20605@localhost> <20120810015222.GA19286@localhost> <20120815030110.GA24836@localhost> <20120815130159.GA3221@redhat.com> Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7BIT X-Mailer: Evolution 3.2.2- Mime-Version: 1.0 Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 2012-08-15 at 15:01 +0200, Oleg Nesterov wrote: > BTW, set_task_comm()->wmb() and memset() should die. There are > not needed afaics, and the comment is misleading. As long as we guarantee there's always a terminating '\0', now strlcpy() doesn't pad the result, however if we initialize the ->comm to all 0s in fork() or thereabouts, we should get this guarantee from the strlcpy() since that will never replace the last byte with anything but 0. That barrier is indeed completely pointless as there's no pairing barrier anywhere.