Received: by 2002:a05:6a11:4021:0:0:0:0 with SMTP id ky33csp1442924pxb; Fri, 24 Sep 2021 04:48:41 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyE883awRiHX3LysINOFrdvTyfDtgtrmvDSINRVfpSYXB4JjduYE0p4D0ijs6ukTRUEmb9A X-Received: by 2002:a17:906:50e:: with SMTP id j14mr165688eja.87.1632484121271; Fri, 24 Sep 2021 04:48:41 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1632484121; cv=none; d=google.com; s=arc-20160816; b=RB6eN6jOjpSZJamFZleqD4sF0lnxVv9dNyFFWV61I3eVszpZJFg9ECd4yjwjAJBNOQ wXXrqLkkB+DMbMFM0Dun98CAZliTMCji9LCG6ozxKxJ3RGfFIywAwf5h6UN5ECDxut5x fPD/FJUlSBbT8X/zFXeEf1xMfYOBLldqdUkP0SKfDRIpVaEvNVo7PXDqAYLdb3v0LxDo xPv6ED4oWCB7AlF4erxshiFfTd0Ovd+ZQwGZOqSQKJR1etXxory4XC1peRtw8JcVRkj5 oC7WYR05As8upXxDjy1zF13RhSMJScOMCo0RwP898V/AJaOloT09c+PsfX/hVy9KCSwo cvsw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:mime-version:message-id:date:references :in-reply-to:subject:cc:to:dkim-signature:dkim-signature:from; bh=/7ACTzCKCJ8fwwf3NKIamkJEmGqQfZ3neuf/bUWLhh4=; b=AHSu7rW/Q8VeyXdkeOD5paOAhaa5MKTbMU0p2/o9GVoQcMsOvs9YG+Pbo3sPBbPp+G e56t8C2xjw2U4sfOtiT21EC5lWocYos1TDt7HRXqqR6MfnNUEqP68zsOD52RxeH7oiE4 QFIPsRF/Oy0dW40crGhcT6td6OWIRAtQWWtvPgrrqgVOt4IBEMoYXIM7UVMArR1hQ/v7 b8lHUfmU09Dr9/l3NqQvnpqQ++Vow3uYuc5czah8pnyOvr5VqEQJ5R5juvAJ/CuvIDS8 yzbRqd57WkIIwi1ICIbmvoKF/D08orOUyh7NXLPFsk4ssjdZHSTrsiNgVDYwCUWqsnkJ vZOA== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=WxF8rGiw; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id p12si11845142ejy.596.2021.09.24.04.48.13; Fri, 24 Sep 2021 04:48:41 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@linutronix.de header.s=2020 header.b=WxF8rGiw; dkim=neutral (no key) header.i=@linutronix.de; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=QUARANTINE dis=NONE) header.from=linutronix.de Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S245664AbhIXK4K (ORCPT + 99 others); Fri, 24 Sep 2021 06:56:10 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:45166 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S245662AbhIXKzs (ORCPT ); Fri, 24 Sep 2021 06:55:48 -0400 Received: from galois.linutronix.de (Galois.linutronix.de [IPv6:2a0a:51c0:0:12e:550::1]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id D8023C061756; Fri, 24 Sep 2021 03:54:15 -0700 (PDT) From: Thomas Gleixner DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020; t=1632480853; 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=/7ACTzCKCJ8fwwf3NKIamkJEmGqQfZ3neuf/bUWLhh4=; b=WxF8rGiwvf1wvxuvzyKyMSchqrD0yZKbzEfkzG0wI6AOaPBxJ/jeiXwxvJ94Eg/E9cYxmf 3FgatXPU71L+df75qc2V1eebCNqphQZjW+VTS855o3tzG/ah0wQWrwYxpQ1/ldSqvvcIwm YoN5DPycOsKS/UZ5LtkI4FXY3DhVDUrQSn+uUfEMF2LpfBVeJPgsyw53T9qMi9vUn51Dz4 9eOBavCSJ5NDNpLsgy2O2/1kT+oewcOf0EXmCJlb9hOuchF7+BwfM314xtIawEv7XOR/Aj +f4DgFZTTVrf2LrcEEpgykcudT1UhjmHVgzkjW6VL/lbZxJ9wYf8yH2nVFYjFg== DKIM-Signature: v=1; a=ed25519-sha256; c=relaxed/relaxed; d=linutronix.de; s=2020e; t=1632480853; 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=/7ACTzCKCJ8fwwf3NKIamkJEmGqQfZ3neuf/bUWLhh4=; b=F3HUGypPhoXARUuEk506nAxHNIZzPBZIIK5AavJ/nhx9YV+Pe2P8r2P1/l/9fazJhebx0u l4ESm1OK9zEbocDQ== To: Sohil Mehta , x86@kernel.org Cc: Sohil Mehta , Tony Luck , Dave Hansen , Ingo Molnar , Borislav Petkov , "H . Peter Anvin" , Andy Lutomirski , Jens Axboe , Christian Brauner , Peter Zijlstra , Shuah Khan , Arnd Bergmann , Jonathan Corbet , Ashok Raj , Jacob Pan , Gayatri Kammela , Zeng Guang , Dan Williams , Randy E Witt , Ravi V Shankar , Ramesh Thomas , linux-api@vger.kernel.org, linux-arch@vger.kernel.org, linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org Subject: Re: [RFC PATCH 10/13] x86/uintr: Introduce user IPI sender syscalls In-Reply-To: <20210913200132.3396598-11-sohil.mehta@intel.com> References: <20210913200132.3396598-1-sohil.mehta@intel.com> <20210913200132.3396598-11-sohil.mehta@intel.com> Date: Fri, 24 Sep 2021 12:54:12 +0200 Message-ID: <87tuiadz1n.ffs@tglx> MIME-Version: 1.0 Content-Type: text/plain Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Mon, Sep 13 2021 at 13:01, Sohil Mehta wrote: > +/* > + * No lock is needed to read the active flag. Writes only happen from > + * r_info->task that owns the UPID. Everyone else would just read this flag. > + * > + * This only provides a static check. The receiver may become inactive right > + * after this check. The primary reason to have this check is to prevent future > + * senders from connecting with this UPID, since the receiver task has already > + * made this UPID inactive. How is that not racy? > +static void free_uitt(struct uintr_uitt_ctx *uitt_ctx) > +{ > + unsigned long flags; > + > + spin_lock_irqsave(&uitt_ctx->uitt_lock, flags); > + kfree(uitt_ctx->uitt); Again. Please move kfree() outside of the lock held region. But aside of that what is this lock protecting here? > + uitt_ctx->uitt = NULL; > + spin_unlock_irqrestore(&uitt_ctx->uitt_lock, flags); If there is concurrency then the other task which is blocked on uitt_lock will operate on uitt_ctx while the same is freed. Again, this lacks any life time and serialization rules. Just sprinkling locks all over the place does not make it magically correct. > + kfree(uitt_ctx); > +} > +static void put_uitt_ref(struct uintr_uitt_ctx *uitt_ctx) > +{ > + if (refcount_dec_and_test(&uitt_ctx->refs)) > + free_uitt(uitt_ctx); > +} > +static struct uintr_uitt_ctx *get_uitt_ref(struct uintr_uitt_ctx *uitt_ctx) > +{ > + refcount_inc(&uitt_ctx->refs); > + return uitt_ctx; > +} > + > +static inline void mark_uitte_invalid(struct uintr_sender_info *s_info) > +{ > + struct uintr_uitt_entry *uitte; > + unsigned long flags; > + > + spin_lock_irqsave(&s_info->uitt_ctx->uitt_lock, flags); > + uitte = &s_info->uitt_ctx->uitt[s_info->uitt_index]; > + uitte->valid = 0; > + spin_unlock_irqrestore(&s_info->uitt_ctx->uitt_lock, flags); > +} > + > static void __clear_vector_from_upid(u64 uvec, struct uintr_upid *upid) > { > clear_bit(uvec, (unsigned long *)&upid->puir); > @@ -175,6 +290,210 @@ static void receiver_clear_uvec(struct callback_head *head) > kfree(r_info); > } > > +static void teardown_uitt(void) > +{ > + struct task_struct *t = current; > + struct fpu *fpu = &t->thread.fpu; > + u64 msr64; > + > + put_uitt_ref(t->thread.ui_send->uitt_ctx); > + kfree(t->thread.ui_send); > + t->thread.ui_send = NULL; > + > + fpregs_lock(); > + > + if (fpregs_state_valid(fpu, smp_processor_id())) { > + /* Modify only the relevant bits of the MISC MSR */ > + rdmsrl(MSR_IA32_UINTR_MISC, msr64); > + msr64 &= GENMASK_ULL(63, 32); More magic numbers. > + wrmsrl(MSR_IA32_UINTR_MISC, msr64); > + wrmsrl(MSR_IA32_UINTR_TT, 0ULL); > +static void __free_uitt_entry(unsigned int entry) > +{ > + struct task_struct *t = current; > + unsigned long flags; > + > + if (entry >= UINTR_MAX_UITT_NR) > + return; > + > + if (!is_uintr_sender(t)) > + return; > + > + pr_debug("send: Freeing UITTE entry %d for task=%d\n", entry, t->pid); > + > + spin_lock_irqsave(&t->thread.ui_send->uitt_ctx->uitt_lock, flags); > + memset(&t->thread.ui_send->uitt_ctx->uitt[entry], 0, > + sizeof(struct uintr_uitt_entry)); > + spin_unlock_irqrestore(&t->thread.ui_send->uitt_ctx->uitt_lock, > flags); What's the spinlock protecting here? > + clear_bit(entry, (unsigned long *)t->thread.ui_send->uitt_mask); > + > + if (is_uitt_empty(t)) { > + pr_debug("send: UITT mask is empty. Dereference and teardown UITT\n"); > + teardown_uitt(); > + } > +} > +void do_uintr_unregister_sender(struct uintr_receiver_info *r_info, > + struct uintr_sender_info *s_info) > +{ > + int ret; > + > + /* > + * To make sure any new senduipi result in a #GP fault. > + * The task work might take non-zero time to kick the process out. -ENOPARSE > + */ > + mark_uitte_invalid(s_info); > + > + pr_debug("send: Adding Free UITTE %d task work for task=%d\n", > + s_info->uitt_index, s_info->task->pid); > + > + init_task_work(&s_info->twork, sender_free_uitte); > + ret = task_work_add(s_info->task, &s_info->twork, true); > + if (ret) { > + /* > + * Dereferencing the UITT and UPID here since the task has > + * exited. > + */ > + pr_debug("send: Free UITTE %d task=%d has already exited\n", > + s_info->uitt_index, s_info->task->pid); > + put_upid_ref(s_info->r_upid_ctx); > + put_uitt_ref(s_info->uitt_ctx); > + put_task_struct(s_info->task); > + kfree(s_info); > + return; > + } > +} > + > +int do_uintr_register_sender(struct uintr_receiver_info *r_info, > + struct uintr_sender_info *s_info) > +{ > + struct uintr_uitt_entry *uitte = NULL; > + struct uintr_sender *ui_send; > + struct task_struct *t = current; > + unsigned long flags; > + int entry; > + int ret; > + > + /* > + * Only a static check. Receiver could exit anytime after this check. > + * This check only prevents connections using uintr_fd after the > + * receiver has already exited/unregistered. > + */ > + if (!uintr_is_receiver_active(r_info)) > + return -ESHUTDOWN; How is this safe against a concurrent unregister/exit operation? Thanks, tglx