Received: by 10.223.176.46 with SMTP id f43csp960513wra; Fri, 19 Jan 2018 04:56:14 -0800 (PST) X-Google-Smtp-Source: ACJfBotqNH+TW9NjjdVuwwKxbmz2wVsGE++gOmWCd/EwlVexcsltKoIZ75dXXfeLpJYqXaNv3jHD X-Received: by 10.98.207.6 with SMTP id b6mr38490266pfg.187.1516366574087; Fri, 19 Jan 2018 04:56:14 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1516366574; cv=none; d=google.com; s=arc-20160816; b=FqdhQs37o5r07Q+4u19TclW63+iNv1ZQE0PE3kIMC1BDWiXvOUNofpSd8rrOe96o7o 5EBQNfpi44bfh7dvsIKPW+Cf2csCSE7tSFsU67afA/5bJu46vLQlkBNdhpuVezV8AoT3 kl5TT9BDXlfsks+Y373BAJuKm3eAIV9rGZ2xfuuXjR1J7BBZ4Ai9QZtUtroKwVPwIuY+ vbRkl1iiOG05+ELBCUqW++BA52z71MXnsmsiLEx5XCl6L8EpNOueLflicqoYklxkpTPN 6KCkAiCdP55k5Stg6x/kSjPiX8uvubq3pT9pvgTovnSlTUZ1mTYjV/ZQcxLLIlqrW6gG /f4A== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature:arc-authentication-results; bh=k7gtaPFVkUpRgn1Pp+P/YUHeAJF1nLImRSICbmWKyZQ=; b=vcdl85UNU8+H8Jx5XXSn0L3Xa7zwsZrmUcUljRR5tJ52S+NWFnIj+GTZiNLpcBDAny kHcVrXKcJDamXbRLBWR5y4xidqSgMseTrjnDXlLkrMOSxhQIb/UhkJ2HBzMW70GNaPHI X4gshAjOopTq0cz+nHSTqnxpA4lrlyew7PHT2QUPW8XNS5d9psy+SVZ9LF8uCu10cXvA yWe6yY80a9n1OBKIWvoQYyOFNICsgPPpEyM23rqNEMidybMCzKHuw0tXAZdi9f+xVlQI U3hnDYPnfYdRSSpiImxUeWxps8iJQXsSfIn/Z4srZK445aWQaIkCk+p2QUaxKj3aU13b 0dRQ== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=ODmEDs9j; 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 f9-v6si808157plk.94.2018.01.19.04.55.59; Fri, 19 Jan 2018 04:56:14 -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; dkim=fail header.i=@infradead.org header.s=bombadil.20170209 header.b=ODmEDs9j; 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 S1755020AbeASMz2 (ORCPT + 99 others); Fri, 19 Jan 2018 07:55:28 -0500 Received: from bombadil.infradead.org ([65.50.211.133]:38575 "EHLO bombadil.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751200AbeASMzX (ORCPT ); Fri, 19 Jan 2018 07:55:23 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=bombadil.20170209; h=In-Reply-To:Content-Type:MIME-Version :References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=k7gtaPFVkUpRgn1Pp+P/YUHeAJF1nLImRSICbmWKyZQ=; b=ODmEDs9jKEyz4jrufJoQA/VwW 6SkW2TlBSa6IsZd2vSHt4VeTHp9pg7tqtB2dSWhKFZ6YgwVdvjaaab1uYXaieiAxNoh2PTU9JRS45 nCX9RxKNpVz6aW3uh11VsnsUpxBF5FtucLeLU9XQ/gq6FR0xalEhyStjpwGi/B9bWv027D1Lc4zCd PcHS4P/P7evPFB2YBq15ap1P8eWcaUvAQCJAYbJakkaC8jCtHzAwcnsdkKA37Zhqeycu5Y1KgECH6 wWuY14Rk2pg/nDVmmNBTN4+kU4tSwPLMP4WtbMJ49wQbGOBOajARUv0hEuyx2Wq9wr+KjHCW1KKQA L+XD9dq7g==; Received: from willy by bombadil.infradead.org with local (Exim 4.89 #1 (Red Hat Linux)) id 1ecWCF-0004Lf-Qo; Fri, 19 Jan 2018 12:55:03 +0000 Date: Fri, 19 Jan 2018 04:55:03 -0800 From: Matthew Wilcox To: "Kirill A. Shutemov" Cc: Linus Torvalds , Peter Zijlstra , Andrea Arcangeli , Dave Hansen , Tetsuo Handa , "Kirill A. Shutemov" , Andrew Morton , Johannes Weiner , Joonsoo Kim , Mel Gorman , Tony Luck , Vlastimil Babka , Michal Hocko , "hillf.zj" , Hugh Dickins , Oleg Nesterov , Rik van Riel , Srikar Dronamraju , Vladimir Davydov , Ingo Molnar , Linux Kernel Mailing List , linux-mm , the arch/x86 maintainers Subject: Re: [mm 4.15-rc8] Random oopses under memory pressure. Message-ID: <20180119125503.GA2897@bombadil.infradead.org> References: <201801170233.JDG21842.OFOJMQSHtOFFLV@I-love.SAKURA.ne.jp> <201801172008.CHH39543.FFtMHOOVSQJLFO@I-love.SAKURA.ne.jp> <201801181712.BFD13039.LtHOSVMFJQFOFO@I-love.SAKURA.ne.jp> <20180118122550.2lhsjx7hg5drcjo4@node.shutemov.name> <20180118145830.GA6406@redhat.com> <20180118165629.kpdkezarsf4qymnw@node.shutemov.name> <20180118234955.nlo55rw2qsfnavfm@node.shutemov.name> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20180118234955.nlo55rw2qsfnavfm@node.shutemov.name> User-Agent: Mutt/1.9.1 (2017-09-22) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Jan 19, 2018 at 02:49:55AM +0300, Kirill A. Shutemov wrote: > > So that's why you can't do pointer diffs between two arrays. Not > > because you can't subtract the two pointers, but because the > > *division* part of the C pointer diff rules leads to issues. > > Thanks a lot for the explanation! > > I wounder if this may be a problem in other places? > > For instance, perf uses address of a mutex to determinate the lock > ordering. See mutex_lock_double(). The mutex is embedded into struct > perf_event_context, which is allocated with kzalloc() so I don't see how > we can presume that alignment is consistent between them. > > I don't think it's the only example in kernel. Are we just lucky? If you're just *comparing* the addresses of two objects, GCC doesn't care what the size of the object is. ie there's a difference between 'if (b < a)' and 'if ((a - b) < n)'. But yes, if you go by the strict wording of the standard: When two pointers are compared, the result depends on the relative locations in the address space of the objects pointed to. [...] In all other cases, the behavior is undefined http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf So really we should be casting 'b' and 'a' to uintptr_t to be fully compliant with the spec.