Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp2033093imu; Sat, 5 Jan 2019 12:44:50 -0800 (PST) X-Google-Smtp-Source: ALg8bN4b0IJfpPUw6xiHfLdFVyFEWKdWEPAzh2tepZUUdD7EB6+ysaVwNdVAXByeIbax0++qM8Kz X-Received: by 2002:a17:902:8e8b:: with SMTP id bg11mr56476539plb.332.1546721090252; Sat, 05 Jan 2019 12:44:50 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1546721090; cv=none; d=google.com; s=arc-20160816; b=Uj/QRneozGSzbEo89zVTAoqGB7pLdXdTCdaCYxIYjsyVXBeyoFHCKbt3srR9n2Lljo 3Km6mB9HkFjT+wBK0JzIbUT7KExNMtEju3s89gTKVyeHIV3T7w5c86TfW/9K1J4UHmaL w7lAz6U1W6s8U4Qc32jcZTRWRvEqMY7j3nZkjPqQFDSpthd31wMU8lfQw50fWTa8ddhH WplaL4FVjJuV1i/UK0B7PNNG1wZjhbRpRSHYKNMbY/wvUP9uW5hreZXMtnHEH0yUDElH DOIlaTQ7+hA2Wx/0+BFM/f81pfc9EPHrnATgtxZiXUXFw4i4ZJ3HCp0ol2kdOC7nOnw7 hQCg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:mime-version:user-agent:references :message-id:in-reply-to:subject:cc:to:from:date; bh=NTsGDWwk+E2USt4Or8EEU91aZirfMGT5Vi4b7SBFIlg=; b=MigMYF6ap3mkppkEqvZe62Ek8cl4EhXJm4Y0qQaLrf6RnRql8LjLPTRhzB2JWOXQqt pbmYbRmVxtQjC1E0+ht7yBHKfVNV/5/F+HeppfWaeucziy+UHEoBF71CpX03NnmyBfCh AQ5dj3n3Tkm5NfiE/jFLBzcfSZjbqEmIuCPLAVIm6ySv3VxKIURRPh62YnDhWf41CYqk FD9Wwz20GmgRH90WMGmUFaXOlkUQj4cbSMVoGSKvPgoki2tCybWO/9dc7yV/Xhb3iZuy Dmq2210Qq6j5BQrGn7Au87BEK49ufEI33JuWoQA6hklbSXv6A+xxm1q7KWRQ55iDEEpg +6vA== 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 9si6873525pgm.112.2019.01.05.12.44.35; Sat, 05 Jan 2019 12:44:50 -0800 (PST) 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; dmarc=fail (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726349AbfAEUnF (ORCPT + 99 others); Sat, 5 Jan 2019 15:43:05 -0500 Received: from mx2.suse.de ([195.135.220.15]:39632 "EHLO mx1.suse.de" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1726267AbfAEUnE (ORCPT ); Sat, 5 Jan 2019 15:43:04 -0500 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay1.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 92417AF64; Sat, 5 Jan 2019 20:43:03 +0000 (UTC) Date: Sat, 5 Jan 2019 21:43:02 +0100 (CET) From: Jiri Kosina To: Linus Torvalds cc: Andrew Morton , Greg KH , Peter Zijlstra , Michal Hocko , linux-mm@kvack.org, Linux List Kernel Mailing , linux-api@vger.kernel.org Subject: Re: [PATCH] mm/mincore: allow for making sys_mincore() privileged In-Reply-To: Message-ID: References: User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Sat, 5 Jan 2019, Linus Torvalds wrote: > > I am still not completely sure what to return in such cases though; we can > > either blatantly lie and always pretend that the pages are resident > > That's what my untested patch did. Or maybe just claim they are all > not present? Thinking about it a little bit more, I believe Vlastimil has a good point with 'non present' potentially causing more bogus activity in userspace in response (in an effort to actually make them present, and failing indefinitely). IOW, I think it's a reasonable expectation that the common scenario is "check if it's present, and if not, try to fault it in" instead of "check if it's present, and if it is, try to evict it". > And again, that patch was entirely untested, so it may be garbage and > have some fundamental problem. I will be travelling for next ~24 hours, but I have just asked our QA guys to run it through some basic battery of testing (which will probably happen on monday anyway). > I also don't know exactly what rule might make most sense, but "you can > write to the file" certainly to me implies that you also could know what > parts of it are in-core. I think it's reasonable; I can't really imagine any sidechannel to a global state be possibly mounted on valid R/W mappings. I'd guess that probably the most interesting here are the code segments of shared libraries, allowing to trace victim's execution. > Who actually _uses_ mincore()? That's probably the best guide to what > we should do. Maybe they open the file read-only even if they are the > owner, and we really should look at file ownership instead. Yeah, well https://codesearch.debian.net/search?q=mincore is a bit too much mess to get some idea quickly I am afraid. -- Jiri Kosina SUSE Labs