From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from kanga.kvack.org (kanga.kvack.org [205.233.56.17]) by smtp.lore.kernel.org (Postfix) with ESMTP id 05D97C433EF for ; Mon, 11 Apr 2022 23:51:55 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 752C66B0071; Mon, 11 Apr 2022 19:51:55 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 6DB446B0073; Mon, 11 Apr 2022 19:51:55 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 52D7D6B0074; Mon, 11 Apr 2022 19:51:55 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from relay.hostedemail.com (relay.hostedemail.com [64.99.140.28]) by kanga.kvack.org (Postfix) with ESMTP id 3E39F6B0071 for ; Mon, 11 Apr 2022 19:51:55 -0400 (EDT) Received: from smtpin10.hostedemail.com (a10.router.float.18 [10.200.18.1]) by unirelay11.hostedemail.com (Postfix) with ESMTP id 0E5F181DAB for ; Mon, 11 Apr 2022 23:51:55 +0000 (UTC) X-FDA: 79346248590.10.FF761B4 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by imf22.hostedemail.com (Postfix) with ESMTP id 65DE5C0003 for ; Mon, 11 Apr 2022 23:51:54 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649721113; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=C2Yny/wdQGOLfSDXssmL5nGEynmk+Ee36fj4fjWkXdI=; b=COPt7v1MkZoIDsSsRkqBTFElFIDc9pwhPWY9AgPvX60YJGbSsxarhlq3B8FsAhxlQQeC1u CN1lL2mdauVEdKCeetyhhcyocMJpMKyvWnFAWyMkcHQdjRud1yhOSawxuKuHDkDdzWI7H/ nRGpiBpHergHHk3ZCw2duNjyPk90sws= Received: from mail-qv1-f69.google.com (mail-qv1-f69.google.com [209.85.219.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-642-zSKuNK-KPb2QG95st50uDw-1; Mon, 11 Apr 2022 19:51:53 -0400 X-MC-Unique: zSKuNK-KPb2QG95st50uDw-1 Received: by mail-qv1-f69.google.com with SMTP id kj4-20020a056214528400b0044399a9bb4cso16967255qvb.15 for ; Mon, 11 Apr 2022 16:51:52 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=C2Yny/wdQGOLfSDXssmL5nGEynmk+Ee36fj4fjWkXdI=; b=zFFdqAoOyZ5lWOACszygMS+86fXsjEVf/e3hvmeqPI4FWqV/EqL3ZiV8+LCAbJaIba sCrOoqGNH3dpCdBimeqta+/wqq7xUk087ORJ03HNa7ud4gFlM2QZSc4D7uG5PYb9ndF6 770HG3f0CKwwKq2ZWOobXGn1k1VuR+V9M7ykdHAcpxD54R0Vm1m1PMTd4a79/7qJ8PR0 GH0hmB8BGCBL9EO+yyQyIxBT9vAxL9P4sJjFFaQAh8pniDB3LYuIb+sJ7frMdgJrCvuB 7siOlWCufYe5e3Q9vSep7EPuqqpn20xHBx5PAYKf/6MdUXt0IFUBkRr0dmsun5t1Og5j 3R0g== X-Gm-Message-State: AOAM533W9LYK2cv/Zubmc+YaCRfj8Ch5QoUnZ9I8d7uqNSVmgLH0fFL3 Af/gpGDYO2PZWewBz1iUcTSX9R/le1mvDIecc8BamDu6qb3nxvjOVtNtB8XGrMC8mO1cFSrU9u6 j15+02WCT2i4= X-Received: by 2002:a05:6214:d87:b0:443:6f15:fe33 with SMTP id e7-20020a0562140d8700b004436f15fe33mr1575450qve.50.1649721112594; Mon, 11 Apr 2022 16:51:52 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyrQG8u7aJ35wAwhhAtjuu9u/vtd70iPUCdYOEsCb2dpEct5qorprasylOONObrCtnpj/xA5w== X-Received: by 2002:a05:6214:d87:b0:443:6f15:fe33 with SMTP id e7-20020a0562140d8700b004436f15fe33mr1575435qve.50.1649721112407; Mon, 11 Apr 2022 16:51:52 -0700 (PDT) Received: from [192.168.0.188] ([24.48.139.231]) by smtp.gmail.com with ESMTPSA id f15-20020a379c0f000000b0069bf3430cc4sm6119872qke.100.2022.04.11.16.51.51 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Apr 2022 16:51:51 -0700 (PDT) Message-ID: <1a7944c7-d717-d5af-f71d-92326f7bb7f6@redhat.com> Date: Mon, 11 Apr 2022 19:51:50 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.5.0 Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head To: Thomas Gleixner , Peter Zijlstra Cc: linux-mm@kvack.org, linux-kernel@vger.kernel.org, Rafael Aquini , Waiman Long , Baoquan He , Christoph von Recklinghausen , Don Dutile , "Herton R . Krzesinski" , David Rientjes , Michal Hocko , Andrea Arcangeli , Andrew Morton , Davidlohr Bueso , Ingo Molnar , Joel Savitz , Darren Hart , stable@kernel.org References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87k0bzk7e5.ffs@tglx> From: Nico Pache In-Reply-To: <87k0bzk7e5.ffs@tglx> X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Authentication-Results: imf22.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b=COPt7v1M; spf=none (imf22.hostedemail.com: domain of npache@redhat.com has no SPF policy when checking 170.10.133.124) smtp.mailfrom=npache@redhat.com; dmarc=pass (policy=none) header.from=redhat.com X-Rspam-User: X-Rspamd-Server: rspam10 X-Rspamd-Queue-Id: 65DE5C0003 X-Stat-Signature: dofoi8cp3s6rtyc7kqhf59eabd5s5yr6 X-HE-Tag: 1649721114-111097 X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 Sender: owner-linux-mm@kvack.org Precedence: bulk X-Loop: owner-majordomo@kvack.org List-ID: On 4/8/22 09:54, Thomas Gleixner wrote: > On Fri, Apr 08 2022 at 04:41, Nico Pache wrote: >> On 4/8/22 04:15, Peter Zijlstra wrote: >>>> >>>> The following case can still fail: >>>> robust head (skipped) -> private lock (reaped) -> shared lock (skipped) >>> >>> This is still all sorts of confused.. it's a list head, the entries can >>> be in any random other VMA. You must not remove *any* user memory before >>> doing the robust thing. Not removing the VMA that contains the head is >>> pointless in the extreme. >> Not sure how its pointless if it fixes all the different reproducers we've >> written for it. As for the private lock case we stated here, we havent been able >> to reproduce it, but I could see how it can be a potential issue (which is why >> its noted). > > The below reproduces the problem nicely, i.e. the lock() in the parent > times out. So why would the OOM killer fail to cause the same problem > when it reaps the private anon mapping where the private futex sits? > > If you revert the lock order in the child the robust muck works. Thanks for the reproducer Thomas :) I think I need to re-up my knowledge around COW and how it effects that stack. There are increased oddities when you add the pthread library that I cant fully wrap my head around at the moment. My confusion lies in how the parent/child share a robust list here, but they obviously do. In my mind the mut_s would be different in the child/parent after the fork and pthread_mutex_init (and friends) are done in the child. Thanks! -- Nico > > Thanks, > > tglx > --- > #include > #include > #include > #include > #include > #include > #include > > #include > #include > > static char n[4096]; > > int main(void) > { > pthread_mutexattr_t mat_s, mat_p; > pthread_mutex_t *mut_s, *mut_p; > pthread_barrierattr_t ba; > pthread_barrier_t *b; > struct timespec to; > void *pri, *shr; > int r; > > shr = mmap(NULL, sizeof(n), PROT_READ | PROT_WRITE, > MAP_SHARED | MAP_ANONYMOUS, -1, 0); > > pthread_mutexattr_init(&mat_s); > pthread_mutexattr_setrobust(&mat_s, PTHREAD_MUTEX_ROBUST); > mut_s = shr; > pthread_mutex_init(mut_s, &mat_s); > > pthread_barrierattr_init(&ba); > pthread_barrierattr_setpshared(&ba, PTHREAD_PROCESS_SHARED); > b = shr + 1024; > pthread_barrier_init(b, &ba, 2); > > if (!fork()) { > pri = mmap(NULL, 1<<20, PROT_READ | PROT_WRITE, > MAP_PRIVATE | MAP_ANONYMOUS, -1, 0); > pthread_mutexattr_init(&mat_p); > pthread_mutexattr_setpshared(&mat_p, PTHREAD_PROCESS_PRIVATE); > pthread_mutexattr_setrobust(&mat_p, PTHREAD_MUTEX_ROBUST); > mut_p = pri; > pthread_mutex_init(mut_p, &mat_p); > > // With lock order s, p parent gets timeout > // With lock order p, s parent gets owner died > pthread_mutex_lock(mut_s); > pthread_mutex_lock(mut_p); > // Remove unmap and lock order does not matter > munmap(pri, sizeof(n)); > pthread_barrier_wait(b); > printf("child gone\n"); > } else { > pthread_barrier_wait(b); > printf("parent lock\n"); > clock_gettime(CLOCK_REALTIME, &to); > to.tv_sec += 1; > r = pthread_mutex_timedlock(mut_s, &to); > printf("parent lock returned: %s\n", strerror(r)); > } > return 0; > } >