Received: by 2002:a05:6512:3d0e:0:0:0:0 with SMTP id d14csp5489lfv; Tue, 12 Apr 2022 15:00:21 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzfAoWoC5OqKeBDUQjQuG73chYhM+4SqK4p6MrNyUevQjlSFl/sBtYpyZKrr8hl+0RtqamI X-Received: by 2002:a17:902:e74d:b0:156:9d3c:4271 with SMTP id p13-20020a170902e74d00b001569d3c4271mr39152519plf.79.1649800821240; Tue, 12 Apr 2022 15:00:21 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1649800821; cv=none; d=google.com; s=arc-20160816; b=lZtNliz0gWUN9I52GO0VF3P86DaMmXTCp7JqEjr3Gpja8q1A4u+N82SGKpxfA8E22M P8Ia5R++GvGPtYVJSCyZC03bdNwbwn1NNKefeXOI55obHnxD5jn6Mf02361/rYkbPgg4 RdVTQyrBEw/9FtJF40DJgKhApgwsB4gr/TZ+JYa/7zCaTcUiRLMMTCM+fWq/Iz11KHj6 d2ZD0zr0zV1nIRKWVOMwrv9xR/AmMp3A+4q1FiSJVMf7lOUE06iLHtYBGT9M24iNjdtp GRZmnXm0wP54QfQYuAHNgQCe1GS6VjuvQXk4wvwPJRUdTP17zNtJWDG6wh5ywovuZxJK YGLQ== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:content-transfer-encoding:in-reply-to:from :references:cc:to:content-language:subject:user-agent:mime-version :date:message-id:dkim-signature; bh=C2Yny/wdQGOLfSDXssmL5nGEynmk+Ee36fj4fjWkXdI=; b=hSqDGS9t4C8UJaTy8J95lBuittj2iQvIqLzonJX7AHQJ6CpPQq4JA8OTcTgPMuN+Q4 Ou1UrrQ2NYHvSOO949XTXxNGVghb1OeTXOj1lB6nduxxStioriEtxFvYizZa1dHTFoQh RiChxJXWLCnsF3BTVTi0pAU9Bb0nBWSRzV+zgRH9R5Ef+VTdUzHfYaRYs0VEpD3M17/Z IvH9E6Un/pXt5yNfgOqPdBi0edMldiJpvbuOaKfFS+kDdWamxiLHtQNQxTaGMzgU07Qg lcuK3CUZkriTPN6IS1NC1T+5gYYhKMsA/ZKKVNprJbkz7dBXIunlcPXZQOM9FCgEHdau Kxgg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iiTxtzim; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Return-Path: Received: from lindbergh.monkeyblade.net (lindbergh.monkeyblade.net. [2620:137:e000::1:18]) by mx.google.com with ESMTPS id z11-20020a1709028f8b00b00153f163b3c6si11695335plo.552.2022.04.12.15.00.20 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 12 Apr 2022 15:00:21 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) client-ip=2620:137:e000::1:18; Authentication-Results: mx.google.com; dkim=pass header.i=@redhat.com header.s=mimecast20190719 header.b=iiTxtzim; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=redhat.com Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id 37B9E14925C; Tue, 12 Apr 2022 13:52:33 -0700 (PDT) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S236121AbiDKXyO (ORCPT + 99 others); Mon, 11 Apr 2022 19:54:14 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:49270 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S234047AbiDKXyM (ORCPT ); Mon, 11 Apr 2022 19:54:12 -0400 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by lindbergh.monkeyblade.net (Postfix) with ESMTP id EE5F627155 for ; Mon, 11 Apr 2022 16:51:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649721114; 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=iiTxtzimJmPDjddPw/aESV9y2w02D14XUWycgih4Vs6TujoOCfo/s5s29ozn+1E5DnfJCM PDvfv79jCwOGnVUcMx3PRJ6QtxeLTPil0Y213FMO05PbWk981DxXFiqbPXeEjg1hzaeWA1 1uUzMo//LhkUopqDM0cn79AredZi2TQ= Received: from mail-qv1-f71.google.com (mail-qv1-f71.google.com [209.85.219.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-280-M5Ffmg0lNSe2gViVhLa3lg-1; Mon, 11 Apr 2022 19:51:53 -0400 X-MC-Unique: M5Ffmg0lNSe2gViVhLa3lg-1 Received: by mail-qv1-f71.google.com with SMTP id fw9-20020a056214238900b0043522aa5b81so16929893qvb.21 for ; Mon, 11 Apr 2022 16:51:53 -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=E9WyjTedtlshVBKnwtFA2bcj0dFstiRWA66rgR1IgiTE4tSbKD98twC9BLSh8gmOgK wxGjTGjMYZ1HeJ/45r9yb0RuMjFRcNCMI3v5F1IRD7Y0fC3xc+3HJdBYquygOr83UOti 1BA1uaVypqIQlbI2kyWt/f7cB9CQ3Q27u5D/qbvy43UQpRTEVdvnzcg90bf87roTZzoQ 18erm2F0me4nASNwxfTCVlJ3TTkyHCaCeupuaZCEqSho0yojMJ4etWIzAKzwFGF5kqIK L17J/O7mgUeDO2rleDOWQYlK9BjVR+X9Z5Fw57bcCeRQzu41+qvsELQzr7xL5KyHXRgn jH6Q== X-Gm-Message-State: AOAM5301jsd65Z8MM0R/U2Z4pJg99Vt5GfGOfP8FHL+W7rpEb6zq+k3N XmD0lQJUOzjEg0oRSzKSdiDI9tPaxtM/kXP8uVk7Tf/64+bvFKnI4IARuRC8kxf1wE9z0JhIhJQ rwC7X8kYkV6VtmzdW640QL3sl X-Received: by 2002:a05:6214:d87:b0:443:6f15:fe33 with SMTP id e7-20020a0562140d8700b004436f15fe33mr1575454qve.50.1649721112595; Mon, 11 Apr 2022 16:51:52 -0700 (PDT) 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 Content-Language: en-US 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> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,NICE_REPLY_A,RDNS_NONE,SPF_HELO_NONE, T_SCC_BODY_TEXT_LINE autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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; > } >