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 X-Spam-Level: X-Spam-Status: No, score=-5.8 required=3.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, SPF_HELO_NONE,SPF_PASS autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 7E4E4C433DB for ; Wed, 10 Mar 2021 08:58:29 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [23.128.96.18]) by mail.kernel.org (Postfix) with ESMTP id 1DB5464FEE for ; Wed, 10 Mar 2021 08:58:29 +0000 (UTC) Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S232338AbhCJI5z (ORCPT ); Wed, 10 Mar 2021 03:57:55 -0500 Received: from Galois.linutronix.de ([193.142.43.55]:58628 "EHLO galois.linutronix.de" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S231492AbhCJI5b (ORCPT ); Wed, 10 Mar 2021 03:57:31 -0500 From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1615366650; 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=7Prcn4FBWkHEBWzQEVl+zK5TjWq1HiyVjVL+CC+4j9Y=; b=jy0h0pKixcREetU90jQ8vU2+IzUoXRINA6fqjcZJSIFT/uNy4y9VP5fA170ln1VhLtfcjX jq2uDZGbRbTuZ3vXW4RP44CW5/cvDuy49hB7nJGxjSsovfqgDDKEO68inqUqHL5+hu+U57 F0S5M0+smxWd5lnieFc7ChDtCscJxtwNsoXid4q4oIf9mIZkUkluKR+V4+wdw9NNoqymOZ DsKgZdunabnxB7by6omPDBVFhA1GkEOY9BzpZDBbGYfAb/iO9CtJnuNjQ6cwW+yGZ+iyQ3 FkKfp/groD4gm1EJG7nM5HYNwFsyD6G3Y69dfZFgGrZroAkPcTvEDYtqQcYjVQ== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1615366650; 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=7Prcn4FBWkHEBWzQEVl+zK5TjWq1HiyVjVL+CC+4j9Y=; b=SUIj8OjAPQmktIrPdGPWGmuXNbBC3kR8vvKcymTyQtvgW4NnhY2wHdp/Jn2NwpDZHube9F J0C80ZFxyLW0q9BQ== To: Oleg Nesterov Cc: Sebastian Andrzej Siewior , linux-kernel@vger.kernel.org, Ingo Molnar , Peter Zijlstra , Juri Lelli , Vincent Guittot , Dietmar Eggemann , Steven Rostedt , Ben Segall , Mel Gorman , Daniel Bristot de Oliveira , Matt Fleming Subject: Re: [PATCH] signal: Allow RT tasks to cache one sigqueue struct In-Reply-To: References: Date: Wed, 10 Mar 2021 09:57:30 +0100 Message-ID: <87v99z4c91.fsf@nanos.tec.linutronix.de> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Mar 09 2021 at 13:01, Thomas Gleixner wrote: > On Fri, Mar 05 2021 at 11:57, Oleg Nesterov wrote: >> On 03/04, Thomas Gleixner wrote: >>> On Wed, Mar 03 2021 at 16:37, Oleg Nesterov wrote: >>> >> +static bool sigqueue_add_cache(struct task_struct *t, struct sigqueue *q) >>> >> +{ >>> >> + if (!t->sigqueue_cache && cmpxchg(&t->sigqueue_cache, NULL, q) == NULL) >>> >> + return true; >>> >> + return false; >>> >> +} >>> > >>> > Do we really need cmpxchg? It seems they are always called with >>> > spinlock held. >>> >>> With which spinlock held? >>> >>> __send_signal() <- sighand::siglock held >>> __sigqueue_alloc() >>> >>> alloc_posix_timer() >>> sigqueue_alloc() <- No lock held >>> __sigqueue_alloc() >> >> In the last case "fromslab" is true, sigqueue_from_cache() won't be called. >> >>> and on the free side we have a bunch of callers which do not hold >>> sighand::siglock either. >> >> Where? Bah. I confused myself. Let me start over with that. Thanks, tglx