Received: by 10.213.65.68 with SMTP id h4csp6741imn; Fri, 16 Mar 2018 15:23:41 -0700 (PDT) X-Google-Smtp-Source: AG47ELvBLGsXZVJWoadNsaULCVkpSbpUq+HELR9XvdlfXjYQb12JlFwAQVah+gdxEv5zjnKcjSnt X-Received: by 10.98.112.6 with SMTP id l6mr2962205pfc.61.1521239021479; Fri, 16 Mar 2018 15:23:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1521239021; cv=none; d=google.com; s=arc-20160816; b=JlroKDyZbHhuNQ4yffbK8cj7esokxcvqv0LXZXMJLBIroe6YycUuB6AWU6n3E6UynJ uFDPwNC12s5cz4eoWTgRxJpT3oax537s+93V7U7Uszot4p9Xy2TlfkO6Mqe4jICPSrzK HXFq4kBf/Ej1+OWxvVV9G+16KYhzTrB6Rr4Oh+smxbn0O/ZN86YQT7g3A2gqTltRCj0G 2aTjrkuYLijQBz0DWaFQtUzKVCAy+4CZAyTnH4Or2Eh/iObp9YaPb479fX8XlFC45Y67 ZVThjpP9g8ce15l8XRH6fcyTKld/Cbo66AvmDRkoMlc23+USic9OeeeGkkFkwItVrsGl kp8g== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding :content-language:in-reply-to:mime-version:user-agent:date :message-id:from:cc:references:to:subject:arc-authentication-results; bh=JJkZhwnpQWWbq4pYy4BJBd/v4StvC+JXUG4a4HMloWA=; b=yACW5Hr0Ia3t3uvsTEm23YVrjen3WN9NobAELyWmrM3uLO63Wfc6/cK9TI5yzYVM9P GOmPm2LuaDfpoju35A0flrBwpnHFCkZqXmFJ+DbmDl4sww7dZW1Gq0qztTcd8x8ilvua B4HsIxqZWeFCsGVUTTMcxxgmWyRa3rhAHnej1sLOOkp2IB8E3UBYtv6nNbqbt4Uf7LG4 9kKqt1X7+S0m8O9DBDHDNYX7yQxb8ekZSk64b3vE0ZFhpNxMf4EPJJacEmPc4uihxgd+ fDnkE2z7pbT1Iofh8gSXVu/2+ZfUhd8UmlR9tANKUhDsiIknr+T6+zuDFxeLwFKr58wl CNpA== ARC-Authentication-Results: i=1; mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id t9-v6si6878852plq.321.2018.03.16.15.23.26; Fri, 16 Mar 2018 15:23:41 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752579AbeCPWWZ (ORCPT + 99 others); Fri, 16 Mar 2018 18:22:25 -0400 Received: from mga14.intel.com ([192.55.52.115]:51091 "EHLO mga14.intel.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751982AbeCPWWX (ORCPT ); Fri, 16 Mar 2018 18:22:23 -0400 X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga007.jf.intel.com ([10.7.209.58]) by fmsmga103.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 16 Mar 2018 15:22:22 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,317,1517904000"; d="scan'208";a="25371741" Received: from ray.jf.intel.com (HELO [10.7.201.16]) ([10.7.201.16]) by orsmga007.jf.intel.com with ESMTP; 16 Mar 2018 15:22:22 -0700 Subject: Re: [PATCH v12 12/22] selftests/vm: generic cleanup To: Ram Pai , shuahkh@osg.samsung.com, linux-kselftest@vger.kernel.org References: <1519264541-7621-1-git-send-email-linuxram@us.ibm.com> <1519264541-7621-13-git-send-email-linuxram@us.ibm.com> Cc: mpe@ellerman.id.au, linuxppc-dev@lists.ozlabs.org, linux-mm@kvack.org, x86@kernel.org, linux-arch@vger.kernel.org, linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, mingo@redhat.com, akpm@linux-foundation.org, benh@kernel.crashing.org, paulus@samba.org, khandual@linux.vnet.ibm.com, aneesh.kumar@linux.vnet.ibm.com, bsingharora@gmail.com, hbabu@us.ibm.com, mhocko@kernel.org, bauerman@linux.vnet.ibm.com, ebiederm@xmission.com, arnd@arndb.de From: Dave Hansen Message-ID: <920ff5c4-153a-488c-e502-82ea43adbd79@intel.com> Date: Fri, 16 Mar 2018 15:22:14 -0700 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <1519264541-7621-13-git-send-email-linuxram@us.ibm.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On 02/21/2018 05:55 PM, Ram Pai wrote: > cleanup the code to satisfy coding styles. > > cc: Dave Hansen > cc: Florian Weimer > Signed-off-by: Ram Pai > --- > tools/testing/selftests/vm/protection_keys.c | 81 ++++++++++++++------------ > 1 files changed, 43 insertions(+), 38 deletions(-) > > diff --git a/tools/testing/selftests/vm/protection_keys.c b/tools/testing/selftests/vm/protection_keys.c > index 6054093..6fdd8f5 100644 > --- a/tools/testing/selftests/vm/protection_keys.c > +++ b/tools/testing/selftests/vm/protection_keys.c > @@ -4,7 +4,7 @@ > * > * There are examples in here of: > * * how to set protection keys on memory > - * * how to set/clear bits in pkey registers (the rights register) > + * * how to set/clear bits in Protection Key registers (the rights register) I don't think CodingStyle says to do this. :) > * * how to handle SEGV_PKUERR signals and extract pkey-relevant > * information from the siginfo > * > @@ -13,13 +13,18 @@ > * prefault pages in at malloc, or not > * protect MPX bounds tables with protection keys? > * make sure VMA splitting/merging is working correctly > - * OOMs can destroy mm->mmap (see exit_mmap()), so make sure it is immune to pkeys > - * look for pkey "leaks" where it is still set on a VMA but "freed" back to the kernel > - * do a plain mprotect() to a mprotect_pkey() area and make sure the pkey sticks > + * OOMs can destroy mm->mmap (see exit_mmap()), > + * so make sure it is immune to pkeys > + * look for pkey "leaks" where it is still set on a VMA > + * but "freed" back to the kernel > + * do a plain mprotect() to a mprotect_pkey() area and make > + * sure the pkey sticks Ram, I'm not sure where this came from, but this looks horrid. Please don't do this to the file > * Compile like this: > - * gcc -o protection_keys -O2 -g -std=gnu99 -pthread -Wall protection_keys.c -lrt -ldl -lm > - * gcc -m32 -o protection_keys_32 -O2 -g -std=gnu99 -pthread -Wall protection_keys.c -lrt -ldl -lm > + * gcc -o protection_keys -O2 -g -std=gnu99 > + * -pthread -Wall protection_keys.c -lrt -ldl -lm > + * gcc -m32 -o protection_keys_32 -O2 -g -std=gnu99 > + * -pthread -Wall protection_keys.c -lrt -ldl -lm > */ Please just leave this, or remove it from the file. It was a long line so it could be copied and pasted, this ruins that. > #define _GNU_SOURCE > #include > @@ -251,26 +256,11 @@ void signal_handler(int signum, siginfo_t *si, void *vucontext) > dprintf1("signal pkey_reg from pkey_reg: %016lx\n", __rdpkey_reg()); > dprintf1("pkey from siginfo: %jx\n", siginfo_pkey); > *(u64 *)pkey_reg_ptr = 0x00000000; > - dprintf1("WARNING: set PRKU=0 to allow faulting instruction to continue\n"); > + dprintf1("WARNING: set PKEY_REG=0 to allow faulting instruction " > + "to continue\n"); > pkey_faults++; > dprintf1("<<<<==================================================\n"); > return; > - if (trapno == 14) { > - fprintf(stderr, > - "ERROR: In signal handler, page fault, trapno = %d, ip = %016lx\n", > - trapno, ip); > - fprintf(stderr, "si_addr %p\n", si->si_addr); > - fprintf(stderr, "REG_ERR: %lx\n", > - (unsigned long)uctxt->uc_mcontext.gregs[REG_ERR]); > - exit(1); > - } else { > - fprintf(stderr, "unexpected trap %d! at 0x%lx\n", trapno, ip); > - fprintf(stderr, "si_addr %p\n", si->si_addr); > - fprintf(stderr, "REG_ERR: %lx\n", > - (unsigned long)uctxt->uc_mcontext.gregs[REG_ERR]); > - exit(2); > - } > - dprint_in_signal = 0; > } I think this is just randomly removing code now. I think you should probably just drop this patch. It's not really brining anything useful.