From owner-freebsd-geom@freebsd.org Mon Oct 9 07:19:15 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1995AE27BC5 for ; Mon, 9 Oct 2017 07:19:15 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from citapm.icyb.net.ua (citapm.icyb.net.ua [212.40.38.140]) by mx1.freebsd.org (Postfix) with ESMTP id 527D06D492 for ; Mon, 9 Oct 2017 07:19:13 +0000 (UTC) (envelope-from avg@FreeBSD.org) Received: from porto.starpoint.kiev.ua (porto-e.starpoint.kiev.ua [212.40.38.100]) by citapm.icyb.net.ua (8.8.8p3/ICyb-2.3exp) with ESMTP id KAA28213 for ; Mon, 09 Oct 2017 10:19:06 +0300 (EEST) (envelope-from avg@FreeBSD.org) Received: from localhost ([127.0.0.1]) by porto.starpoint.kiev.ua with esmtp (Exim 4.34 (FreeBSD)) id 1e1SLC-0000LE-4w for freebsd-geom@FreeBSD.org; Mon, 09 Oct 2017 10:19:06 +0300 To: freebsd-geom@FreeBSD.org From: Andriy Gapon Subject: g_slice_orphan is unsafe? orphanization in general? Message-ID: <02411be8-b5c5-9e0d-c16d-8cdbdf480cf1@FreeBSD.org> Date: Mon, 9 Oct 2017 10:17:44 +0300 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 09 Oct 2017 07:19:15 -0000 void g_slice_orphan(struct g_consumer *cp) { struct g_slicer *gsp; g_trace(G_T_TOPOLOGY, "g_slice_orphan(%p/%s)", cp, cp->provider->name); g_topology_assert(); /* XXX: Not good enough we leak the softc and its suballocations */ gsp = cp->geom->softc; cp->geom->softc = NULL; <--- I think that doing this is unsafe g_slice_free(gsp); <--- and this g_wither_geom(cp->geom, ENXIO); } I do not see how g_slice_orphan() - or, in fact, the whole orphanization process - is synchronized with g_io_request() and g_io_schedule_down(). I think that it is quite possible for a geom to become orphaned after g_io_check() succeeds and before geom->start is executed (or while it's being executed). I see that there is an attempt to prevent orphanization while a geom is in use. The code in one_event() does not call geom->orphan until pp->nstart == pp->nend. But there is no common lock to actually synchronize the check and updates of the variables. Atomic operations are not used either. So, in my opinion, the check is not really safe. It looks like r162200 attempted to fix the general problem but either it was not a complete solution or the I/O code was later changed: https://svnweb.freebsd.org/base?view=revision&revision=162200 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=102766 Back to g_slice, I see that g_slice_start() makes use of the softc. So, this is why I believe that destroying it right in g_slice_orphan is not correct. It seems that other GEOM classes go to greater lengths to ensure that there is no race between orphanization and I/O processing. Typically an internal lock and a flag seems to be used. I wonder if g_slice should follow that technique. Or maybe it's better to use a lock or atomic operations at GEOM infrastructure level to ensure that changes to pp->error, pp->flags, pp->nstart and pp->nend are really seen by other threads and in the correct order. -- Andriy Gapon From owner-freebsd-geom@freebsd.org Tue Oct 10 01:29:37 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id C13AFE42064 for ; Tue, 10 Oct 2017 01:29:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from kenobi.freebsd.org (kenobi.freebsd.org [IPv6:2001:1900:2254:206a::16:76]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id AF4FF6385F for ; Tue, 10 Oct 2017 01:29:37 +0000 (UTC) (envelope-from bugzilla-noreply@freebsd.org) Received: from bugs.freebsd.org ([127.0.1.118]) by kenobi.freebsd.org (8.15.2/8.15.2) with ESMTP id v9A1TbVi067361 for ; Tue, 10 Oct 2017 01:29:37 GMT (envelope-from bugzilla-noreply@freebsd.org) From: bugzilla-noreply@freebsd.org To: freebsd-geom@FreeBSD.org Subject: [Bug 221804] [patch] page fault during shutdown on a server with gjournaled partitions Date: Tue, 10 Oct 2017 01:29:37 +0000 X-Bugzilla-Reason: AssignedTo X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: Base System X-Bugzilla-Component: kern X-Bugzilla-Version: 10.3-STABLE X-Bugzilla-Keywords: patch-ready X-Bugzilla-Severity: Affects Some People X-Bugzilla-Who: linimon@FreeBSD.org X-Bugzilla-Status: Open X-Bugzilla-Resolution: X-Bugzilla-Priority: --- X-Bugzilla-Assigned-To: freebsd-geom@FreeBSD.org X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: assigned_to short_desc Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: https://bugs.freebsd.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Oct 2017 01:29:37 -0000 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D221804 Mark Linimon changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|freebsd-bugs@FreeBSD.org |freebsd-geom@FreeBSD.org Summary|[path] page fault during |[patch] page fault during |shutdown on a server with |shutdown on a server with |gjournaled partitions |gjournaled partitions --=20 You are receiving this mail because: You are the assignee for the bug.= From owner-freebsd-geom@freebsd.org Thu Oct 12 15:18:26 2017 Return-Path: Delivered-To: freebsd-geom@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 8707CE2C832; Thu, 12 Oct 2017 15:18:26 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: from mail-ua0-x236.google.com (mail-ua0-x236.google.com [IPv6:2607:f8b0:400c:c08::236]) (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 3E169803FD; Thu, 12 Oct 2017 15:18:26 +0000 (UTC) (envelope-from woodsb02@gmail.com) Received: by mail-ua0-x236.google.com with SMTP id w45so3276194uac.3; Thu, 12 Oct 2017 08:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=f9wy+PoAqlzCnyuBy3Q43zrR2/G2YUWZQ2E36/PPhcA=; b=HmjTTJx0ddOIINww8apm5xZLMiwsQ5WOJLRATfeWPjCnZpq28EOa+9G1s5gQD6jKxs tiApA4d6MsggFKmTVXkcDoEE0ELeMps5l4zaBpDo5+ibRtVfW0d7ZxceKYY45PS0fTo8 VwDav+nmvk6dyxYdY1dYcQG4R5OOsJE6w+oxlNHPoE+qSx2LXewuJ10nuWHGm16pU+pO e9TY8pcKdr4AmA+NHUimxPnFFL/3tNIl1IFKWJkmF7zmjdZgkUZBiM2W9Cv9U/gy7AOo xz4jzTqOB19j64NBICQqXxs0oLzqkTeE5UsZu451vRGPZDlaUMtNDoERBbjzeEoDhxfO KUHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=f9wy+PoAqlzCnyuBy3Q43zrR2/G2YUWZQ2E36/PPhcA=; b=Zhin1Cpdty4KbtfhNZ/F7vrKIn/t3blE9NSQCyfnWSHYNOAgHBuOEv9W+ml2oe646Q r39Drv5HBkcvRT53kqU3EyrqJ1gsnssJu/8ttVuKqYZnigV5/FuYTtHGk/7yTpfgcQe3 MGi/8tTC6cdBIQvVMjSzY4/kTkVfoW5IU5oCRVxTRReowwbaZf/FYbKcr3ZfR0R0uEPF qkMg0mJeu6MOXYBjj4Ac+w377wc5P7BFrfslWWAmTJCIpBvlOd0dUFk4EMGKanvuQW3l pKT6Dqo4IL7w5wfSJJflnOJLaG/M4A2YPaWLWQR6WgdVpXeyoJ8MTM5ddUHHmCEtc6bq LZRw== X-Gm-Message-State: AMCzsaXViJ9q88FoEpgEn044c4J99XuXhfo6gdAXVr+VoJAGggzl1Prh DeJeOdqfzx58YAuaxOiasjpOCTBZWYzS/qJExF3jXGYW X-Google-Smtp-Source: AOwi7QBSS5/EvTuYblsjDig41ga4uSBe2leeTgkELYmu32Frp1L1pXn2Fnd5ZHPp79lZA3fcQIeuepQMqM8deuoOl8A= X-Received: by 10.176.16.18 with SMTP id f18mr567208uab.108.1507821501773; Thu, 12 Oct 2017 08:18:21 -0700 (PDT) MIME-Version: 1.0 Received: by 10.31.131.80 with HTTP; Thu, 12 Oct 2017 08:18:21 -0700 (PDT) In-Reply-To: References: From: Ben Woods Date: Thu, 12 Oct 2017 23:18:21 +0800 Message-ID: Subject: Re: [RFC] geli - Allow attaching multiple providers To: freebsd-geom@freebsd.org, freebsd-hackers@freebsd.org Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.23 X-BeenThere: freebsd-geom@freebsd.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: GEOM-specific discussions and implementations List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 12 Oct 2017 15:18:26 -0000 On 28 May 2017 at 13:38, Ben Woods wrote: > Hi everyone, > > I would like to propose a patch to geli to allow multiple providers to be > attached in a single command if they use the same passphrase/keyfiles. > > This is helpful when the providers being attached are not used for boot, > and therefore the existing code to first try the cached password when > tasting the providers during boot does not apply. > > Multiple providers with the same passphrase and keyfiles can be attached > at the same time during system start-up by adding the following to > /etc/rc.conf: > > geli_groups="storage backup" > geli_storage_flags="-k /etc/geli/storage.keys" > geli_storage_devices="ada0 ada1" > geli_backup_flags="-j /etc/geli/backup.passfile -k /etc/geli/backup.keys" > geli_backup_devices="ada2 ada3" > > The patch is up for review on phabricator here: > https://reviews.freebsd.org/D9396 > > Regards, > Ben > > -- > From: Benjamin Woods > woodsb02@gmail.com > Hi everyone, I have created a new phabricator review for this work to allow multiple providers to be attached in a single geli command if they use the same passphrase/keyfiles. Unlike D9396, this implementation does not modify the kernel. This is achieved by creating a new child geom request for each provider being attached, and passing each request to the kernel one by one. The new patch can be found here: https://reviews.freebsd.org/D12644 I am hoping people can review and comment on this patch, and that I can get assistance committing this once it is approved (as I am only a ports committer). Regards, Ben -- From: Benjamin Woods woodsb02@gmail.com