From owner-freebsd-xen@freebsd.org Mon Jul 30 10:36:49 2018 Return-Path: Delivered-To: freebsd-xen@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id EE58F1051D5F for ; Mon, 30 Jul 2018 10:36:48 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: from mail-it0-f54.google.com (mail-it0-f54.google.com [209.85.214.54]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 78501927F2; Mon, 30 Jul 2018 10:36:48 +0000 (UTC) (envelope-from pratiy0100@gmail.com) Received: by mail-it0-f54.google.com with SMTP id g191-v6so5481299ita.0; Mon, 30 Jul 2018 03:36:48 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=XvPtrARKHwUeZA6eZ9WBWv9uVfhEt64+mgVfA525ySQ=; b=c/MuVH+O+R3InNKdG0m6cdxFhBDPbwEUf9V+EfD00jR3T8ZqwfIYuE6mcajQctMjxK QhiLZDs6p8h2noivSzaoxy4hDaomVnW+Z/G3gjf9p0TpScRtcMS4dQUdMLgjqjgCJ5p9 jcpgSO44eOgXmVS9LDCTGmSEtlXfdacrPJ7Q/8Q/fyxddd78Yk1iJ59jxPKBb6tSJstn dwFy0ctGwriPK/IEFWzbN6U0lvnuRGt+mS+voTbQZ2M9wcz30y/gCZ1AKo/a2hoieJAV QGbYM/daF23lHeU+tt89CE8IZM+lyRNw5MZuePhRt/heSl7qxAvWM7QpujuxJSI4R4tY 4LyQ== X-Gm-Message-State: AOUpUlFe+2u709lRa4cT9soctQJqw9/AKJ2H0LXJ0CUJLBBdGUX6gO82 jrl4rId1We23YQXheeJ+Ozix6QH438GfeQ== X-Google-Smtp-Source: AAOMgpegQ3zvg/MgrtSFGKZk4/kQz4Bub1j7nvJpJkJECQOQhZemswXgQqWtMqJ1w+0ai7fvj+L6oA== X-Received: by 2002:a02:380c:: with SMTP id b12-v6mr15986033jaa.125.1532946596399; Mon, 30 Jul 2018 03:29:56 -0700 (PDT) Received: from mail-it0-f41.google.com (mail-it0-f41.google.com. [209.85.214.41]) by smtp.gmail.com with ESMTPSA id j11-v6sm6448849itj.6.2018.07.30.03.29.56 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 30 Jul 2018 03:29:56 -0700 (PDT) Received: by mail-it0-f41.google.com with SMTP id d16-v6so8923782itj.0; Mon, 30 Jul 2018 03:29:56 -0700 (PDT) X-Received: by 2002:a24:5f92:: with SMTP id r140-v6mr14227746itb.95.1532946595871; Mon, 30 Jul 2018 03:29:55 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: Pratyush Yadav Date: Mon, 30 Jul 2018 15:59:19 +0530 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: Recursion in non-recursive mutex when using the grant table free callbacks To: Akshay Jaggi Cc: =?UTF-8?Q?Roger_Pau_Monn=C3=A9?= , Edward Napierala , FreeBSD-Xen Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-BeenThere: freebsd-xen@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussion of the freebsd port to xen - implementation and usage List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 30 Jul 2018 10:36:49 -0000 On Mon, Jul 30, 2018 at 4:00 AM Akshay Jaggi wrote: > > Roger would be a better person to answer this and I would wait for him to= respond, but here are my 2 cents. > > First let's finalize and record the semantics of the callbacks. What guar= antee do we want to provide callbacks about locks held (no locks held OR x,= y,z locks held)? This is mostly a product decision. Usually callbacks are c= alled with no locks held. > Post this problem is simple. If the list_lock would be held during callba= cks, we need to provide a lock-free function (which assumes lock would be h= eld before function is called and use that) and if the lock would not be he= ld we should fix the locking to ensure the case you mentioned should not ha= ppen. > > WDYT? The guarantee we want to provide the callback is that the allocation of grant references can not fail inside the callback (unless they try to allocate more refs than initially specified). This means that we can't call the callback without the lock held otherwise during the execution of the callback it is possible for some other thread to get the grant references, and the grant refs the callbacks needs would not be available. So a change in the locking has to be done. On Mon, Jul 30, 2018 at 3:02 PM Roger Pau Monn=C3=A9 w= rote: > I agree in the analysis, however I think the proper solution is to use > a recursive lock. All right. I'll send in the patch. -- Regards, Pratyush Yadav