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 1F0EEC433EF for ; Fri, 8 Apr 2022 16:13:38 +0000 (UTC) Received: by kanga.kvack.org (Postfix) id 806E56B0072; Fri, 8 Apr 2022 12:13:38 -0400 (EDT) Received: by kanga.kvack.org (Postfix, from userid 40) id 7B5DD6B0073; Fri, 8 Apr 2022 12:13:38 -0400 (EDT) X-Delivered-To: int-list-linux-mm@kvack.org Received: by kanga.kvack.org (Postfix, from userid 63042) id 67E6D6B0074; Fri, 8 Apr 2022 12:13:38 -0400 (EDT) X-Delivered-To: linux-mm@kvack.org Received: from forelay.hostedemail.com (smtprelay0150.hostedemail.com [216.40.44.150]) by kanga.kvack.org (Postfix) with ESMTP id 581F06B0072 for ; Fri, 8 Apr 2022 12:13:38 -0400 (EDT) Received: from smtpin21.hostedemail.com (10.5.19.251.rfc1918.com [10.5.19.251]) by forelay04.hostedemail.com (Postfix) with ESMTP id 1CFC2A75B0 for ; Fri, 8 Apr 2022 16:13:38 +0000 (UTC) X-FDA: 79334207316.21.0D53D21 Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by imf02.hostedemail.com (Postfix) with ESMTP id 30DC18000B for ; Fri, 8 Apr 2022 16:13:36 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1649434416; 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: in-reply-to:in-reply-to:references:references; bh=RABOyYo670sPAWQ+PEuN77+r1YMjgpRyhVZuUCYWh68=; b=GJ97/JEu/pOCuPe+LF8BCyEMdihHWtCOHYgKB1xKbxvM6VxjMTYRZJewYH6ElPh+tnnZAL u/ze2cR0lq6QcXyTb9BaiJrSp+WigUrv0RJB1wx8mzj4g9OYwqQG0+zlEKTREkXK/Xh7/i QzZUu+uM0vh8izVNmMBiDeYtwf8GLYA= Received: from mail-yw1-f199.google.com (mail-yw1-f199.google.com [209.85.128.199]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-607-aca6zNwkOBaOnZh5mdCuYA-1; Fri, 08 Apr 2022 12:13:33 -0400 X-MC-Unique: aca6zNwkOBaOnZh5mdCuYA-1 Received: by mail-yw1-f199.google.com with SMTP id 00721157ae682-2ebd532c5a9so33540017b3.5 for ; Fri, 08 Apr 2022 09:13:33 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=RABOyYo670sPAWQ+PEuN77+r1YMjgpRyhVZuUCYWh68=; b=dXFF65BumD4gkQYN6avNL8CB2A8ShPWYXiflHzI7UFlFI2wVQrUG7j7retvG8IvIrm GJUsUogtb2mx008rXW502LcoJ/Py5SfYPgt4NrlAHg3escxceDsItPin7mQD3bdssBYx 73+pOLlVEhmO47TF7b8ig/NLw/jZjy60VCYbO8FcsxqKI44bPnNLa2yBQSLRZ26nMm03 10S8FaXtJ7C9o/ZPQSrvX2Rmab0lg62ALDgXMMZIkCTGuG4mJ8jPRMOtmYLYz/sXTTwO 49LHRtSCt9Hs6CrTicsnnY+14bldeB8yAYsYiliMPaYXRWvclfpOSXfHFT/5x1P0NicF hJ/Q== X-Gm-Message-State: AOAM533mJeno1t3nVH5dCl4EgrQvTi5ITb2zMLgwuKpk7z3X1pdjcSjh hDvInhqfmj2mrztyNXJ48nzXyOPmfve58rdLMPGfSsTQ38pDZwaprsKPYT8F2D2gKz9+PrZqUGE Mbr9r57nKRASYnYtywe28UuBYdMU= X-Received: by 2002:a25:adc8:0:b0:633:b79d:92ee with SMTP id d8-20020a25adc8000000b00633b79d92eemr14066202ybe.457.1649434412956; Fri, 08 Apr 2022 09:13:32 -0700 (PDT) X-Google-Smtp-Source: ABdhPJxRgvqC+MnDBFtFpOj0kzf4fzJqLCJ33Or5sPWhBYgE8Lr6rPUPkktLh7gmkeG3+q2BSQNdr/IZiHbdDYQjY1w= X-Received: by 2002:a25:adc8:0:b0:633:b79d:92ee with SMTP id d8-20020a25adc8000000b00633b79d92eemr14066179ybe.457.1649434412748; Fri, 08 Apr 2022 09:13:32 -0700 (PDT) MIME-Version: 1.0 References: <20220408032809.3696798-1-npache@redhat.com> <20220408081549.GM2731@worktop.programming.kicks-ass.net> <87k0bzk7e5.ffs@tglx> In-Reply-To: <87k0bzk7e5.ffs@tglx> From: Joel Savitz Date: Fri, 8 Apr 2022 12:13:16 -0400 Message-ID: Subject: Re: [PATCH v8] oom_kill.c: futex: Don't OOM reap the VMA containing the robust_list_head To: Thomas Gleixner Cc: Nico Pache , Peter Zijlstra , linux-mm@kvack.org, linux-kernel , 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 , Darren Hart , stable@kernel.org X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset="UTF-8" X-Rspamd-Server: rspam05 X-Rspamd-Queue-Id: 30DC18000B X-Stat-Signature: 6qkt7fj67rt1435roc9sodfty636aqfo X-Rspam-User: Authentication-Results: imf02.hostedemail.com; dkim=pass header.d=redhat.com header.s=mimecast20190719 header.b="GJ97/JEu"; dmarc=pass (policy=none) header.from=redhat.com; spf=none (imf02.hostedemail.com: domain of jsavitz@redhat.com has no SPF policy when checking 170.10.129.124) smtp.mailfrom=jsavitz@redhat.com X-HE-Tag: 1649434416-807517 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: > --- > #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); One thing I don't understand is what kind of sane use case relies on robust futex for a process-private lock? Is there a purpose to a lock being on the robust list if there are no other processes that must be woken in case the holder process is killed? If this usage serves no purpose besides causing races during oom, we should discourage this use, perhaps by adding a note on the manpage. > 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; > } >