From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794657833; b=Jx+KkHKoE+5ZiKWmUv1uiBnNJDyASgMdF954ILF7H2Ape6dq7OomLX7izyLga6K4uofX pD/JsJwdQuu2/qmLmPzK0PqDqp1gTesojYxRCGYqRmCuxCXBb+Zx+fzyolr8xfkRD+hHm tgAhem3N4nbpzBpuosJWKHm4TtljrtOnCIswHCJL0/cWdmAZ+b55YSrd3v+W3Uy+dZ9bo zOt+bup0nBni+29Bs3hiA6x/ZySzkRrRoqDnVQjDHlJc2q4EwSfzKFG6SXIVeGsmJotwO SthJVM6iuMDJpYq5y2RnmktQqWqn4IknhFrzD1jV1GyCUbkznvxJLsUMQc+Skd70HSg== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794657833; h=Received:DKIM-Signature:Message-ID:From:Subject:Reply-To:To:Cc: In-Reply-To:References:Content-Type:Content-Transfer-Encoding:Date; bh=h9QvBLMsaftQkNF5XqflyzTjEcAymvR21sTq1hGFR9U=; b=xB5qSGxrMXgAXlE7nh8mENt4nv5VlI81GjWg/BB5k01J1mKLA+/OADIpyB3+yWe+Ufjv 4ikWSx6bhK1G0FAZyUBdChUknGWq6HVVjkC1QfbopQsPW6buQPotJKV8iZPEQnGVhfj/P UPOXIM//R9X39fuq2ZRfUnQWUMDk+J1m7/08tgcZNApM+amhSRdV6k58erEYnm4R1DEKG JylMXx73zSd8X/9fzw7qg6TteaKTeecxl1gWj4qFvhaPFUYWDJBhjyG5jfuV2wHsDyumL gVyq9AOk1rjxvznp+lU4gkV9N689iMnWjFRJn8k/8OT9RvqQ3Ojya0QGp0mntfJ3gjg== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=acRLK16T; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 98D23606A330; Sat, 14 Nov 2026 12:03:53 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=acRLK16T Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7DA11F000C5; Sat, 14 Nov 2026 12:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794657833; bh=h9QvBLMsaftQkNF5XqflyzTjEcAymvR21sTq1hGFR9U=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=acRLK16Tv5rVfr5zfeXkCS81IwZynV0Iu0o5OGc2HpX3/05hrjbueaWKLxLlYqLmO z3W+PPmaM3U0hqso0XI+Ooq0RQyvBrwDBT11n9g9KSgX8ZhGVcIxnOI9fIOtTrhxxK HjE1FgbCj1dbiTCHVsQhDOFs56nIgMByBpuhawWcso3hlxTf//5jcUYgwAaZ04rwjz BdkAHdeW3WWvKJw7xI6KV+jY+dZQrvNHw7VEagMRPiDHtBYiWi45s6JmOMZp7SE9XB WqfiGf81GveG6tD+O2sIN9n3nXaeikmtUkJNFdgDSm4yOjub0sItWiIhIB1G/G4u+I 3yjoHedFGAoMA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 30/33] ubifs: don't set SB_RDONLY after errors Reply-To: sashiko-reviews@lists.linux.dev To: "Christian Brauner" , "Jan Kara" Cc: "Al Viro" , linux-ext4@vger.kernel.org, linux-mm@kvack.org, linux-efi@vger.kernel.org, linux-mtd@lists.infradead.org, dsterba@suse.cz, tytso@mit.edu, "Mark Fasheh" , "Joel Becker" , "Joseph Qi" In-Reply-To: <20261113-work-fs-sb_rdonly-v3-30-0be92bb73709@kernel.org> References: <20261113-work-fs-sb_rdonly-v3-0-0be92bb73709@kernel.org> <20261113-work-fs-sb_rdonly-v3-30-0be92bb73709@kernel.org> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Date: Sat, 14 Nov 2026 12:03:52 +0000 X-Mailing-List: linux-efi@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list Thank you for your contribution! Sashiko AI review found 3 potential issues to consider: - [Medium] ubifs: false space accounting error in ubifs_remount_ro() after error - [Medium] ubifs: ubifs_fsync() trips !c->ro_mount assert after error remount - [Medium] ubifs: race between in-flight writeback and ubifs_remount_ro() after error -- commit fda6fbd307537dfd99ef75b3610022c5af4a9353 Author: Christian Brauner ubifs: don't set SB_RDONLY after errors This commit switches ubifs_ro_mode() from setting SB_RDONLY directly on s_flags to calling sb_set_emergency_ro(), allows remounting read-only after an error, and drops dirty folios and inodes during writeback once c->ro_error is set. > diff --git a/fs/ubifs/super.c b/fs/ubifs/super.c > index 38972786817e7..2d71274e89ad0 100644 > --- a/fs/ubifs/super.c > +++ b/fs/ubifs/super.c [ ... ] > @@ -1839,19 +1846,26 @@ static void ubifs_remount_ro(struct ubifs_info *c) > =20 > dbg_save_space_info(c); > =20 > - for (i =3D 0; i < c->jhead_cnt; i++) { > - err =3D ubifs_wbuf_sync(&c->jheads[i].wbuf); > + /* Like ubifs_put_super(), don't write anything after an error. */ > + if (!c->ro_error) { > + for (i =3D 0; i < c->jhead_cnt; i++) { > + err =3D ubifs_wbuf_sync(&c->jheads[i].wbuf); > + if (err) > + ubifs_ro_mode(c, err); > + } > + > + c->mst_node->flags &=3D ~cpu_to_le32(UBIFS_MST_DIRTY); > + c->mst_node->flags |=3D cpu_to_le32(UBIFS_MST_NO_ORPHS); > + c->mst_node->gc_lnum =3D cpu_to_le32(c->gc_lnum); > + err =3D ubifs_write_master(c); > if (err) > ubifs_ro_mode(c, err); > + } else { > + /* Syncing the write-buffers would have canceled them. */ > + for (i =3D 0; i < c->jhead_cnt; i++) > + hrtimer_cancel(&c->jheads[i].wbuf.timer); > } [Severity: Medium] Can an in-flight ubifs_fsync() trip the !c->ro_mount assertion in ubifs_wbuf_sync_nolock() when racing with a read-only remount after an error? When c->ro_error is set, skipping ubifs_wbuf_sync() leaves wbuf->used and wbuf->inodes[] populated while ubifs_remount_ro() sets c->ro_mount =3D 1. Because vfs_fsync_range() does not hold s_umount or mnt_want_write(), an fsync() on an inode whose node is already buffered in a wbuf (with no dirty folios and ui->dirty =3D=3D 0) can interleave with ubifs_remount_ro(): CPU0 CPU1 ubifs_fsync() if (c->ro_mount) return 0; file_write_and_wait_range() ubifs_write_inode() -> 0 ubifs_remount_ro() hrtimer_cancel(&wbuf->timer) c->ro_mount =3D 1 ubifs_sync_wbufs_by_inode() ubifs_wbuf_sync_nolock(wbuf) ubifs_assert(c, !c->ro_media && !c->ro_mount) <-- assertion failure In ubifs_wbuf_sync_nolock(), the !c->ro_mount assertion runs before the if (c->ro_error) return -EROFS check, causing a warning and stack dump (or a panic when mounted with assert=3Dpanic). > - > - c->mst_node->flags &=3D ~cpu_to_le32(UBIFS_MST_DIRTY); > - c->mst_node->flags |=3D cpu_to_le32(UBIFS_MST_NO_ORPHS); > - c->mst_node->gc_lnum =3D cpu_to_le32(c->gc_lnum); > - err =3D ubifs_write_master(c); > - if (err) > - ubifs_ro_mode(c, err); > - > vfree(c->orph_buf); > c->orph_buf =3D NULL; > kfree(c->write_reserve_buf); [Severity: Medium] Can ubifs_remount_ro() free c->write_reserve_buf and set c->ro_mount =3D 1 while an in-flight do_writepage() is still running? Once ubifs_ro_mode() calls sb_set_emergency_ro(), sync_filesystem(sb) in ubifs_reconfigure() returns immediately at sb_rdonly_any(sb) without calling sync_inodes_sb() or waiting for in-flight writeback. A writeback caller that does not take mnt_want_write() or s_umount (such as sync_file_range()) can pass the unlocked c->ro_error check in do_writepage() just before an error occurs and then race with ubifs_remount_ro(): CPU0 CPU1 do_writepage() if (unlikely(c->ro_error)) ubifs_jnl_write_data() ubifs_ro_mode() c->ro_error =3D 1 sb_set_emergency_ro(sb) ubifs_reconfigure() sync_filesystem(sb) -> 0 ubifs_remount_ro() kfree(c->write_reserve_buf) c->write_reserve_buf =3D NULL c->ro_mount =3D 1 mutex_lock(&c->write_reserve_mutex) data =3D c->write_reserve_buf data->ch.node_type =3D ... <-- NULL dereference or use-after-free Even when kmalloc() succeeds in ubifs_jnl_write_data(), make_reservation() subsequently calls reserve_space(), tripping ubifs_assert(c, !c->ro_media && !c->ro_mount). > @@ -1977,10 +1991,7 @@ static int ubifs_reconfigure(struct fs_context *fc) > if (err) > return err; > } else if (!c->ro_mount && (fc->sb_flags & SB_RDONLY)) { > - if (c->ro_error) { > - ubifs_msg(c, "cannot re-mount R/O due to prior errors"); > - return -EROFS; > - } > + /* After an error ubifs_remount_ro() can't write but still works. */ > ubifs_remount_ro(c); > } [Severity: Medium] Should ubifs_remount_ro() skip dbg_save_space_info() and dbg_check_space_info() when c->ro_error is set, as ubifs_put_super() and the taken_empty_lebs check in ubifs_reconfigure() do? Because sync_filesystem() is a no-op once sb_set_emergency_ro() is set, dirty folios and dirty inodes remain pending during ubifs_remount_ro(). dbg_save_space_info() snapshots ubifs_get_free_space_nolock(), which includes c->bi.data_growth and c->bi.dd_growth. If a concurrent writeback or folio release drops a dirty folio via do_writepage() or a dirty inode via ubifs_write_inode() before dbg_check_space_info() runs at the end of ubifs_remount_ro(), releasing that page or inode budget changes the reported free space and causes dbg_check_space_info() to log a false "free space changed" error and call dump_stack(). --=20 Sashiko AI review =C2=B7 https://sashiko.dev/#/patchset/20261113-work-fs-sb= _rdonly-v3-0-0be92bb73709@kernel.org?part=3D30 From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from bombadil.infradead.org (bombadil.infradead.org [198.137.202.133]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 2EF2A606A334 for ; Sat, 14 Nov 2026 12:03:56 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=lists.infradead.org header.i=@lists.infradead.org header.a=rsa-sha256 header.s=bombadil.20210309 header.b=sVU+lptL; dkim=fail reason="signature verification failed" (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=acRLK16T DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20210309; h=Sender: Content-Transfer-Encoding:Content-Type:MIME-Version:Reply-To:List-Subscribe: List-Help:List-Post:List-Archive:List-Unsubscribe:List-Id:Date:References: In-Reply-To:Cc:To:Subject:From:Message-ID:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: List-Unsubscribe-Post:List-Owner; bh=x1G+sfnsQw5RW1GWuLAD4l7IGlTiRg+BDcT+5tJ9O5U=; b=sVU+lptLSpPnzYtjmVLnGZ+x46 gzYzDx8YMROVBlQyruFSYxf/teo2m7hsRsKX8xb0vWp3StFC7Hh00DtnqGlgsH0nNjmcJ53wCYDyF +osGYoRkWVQ2r0Z6wr33b8JfkRA3xDu1yvcGY2NMbtGqBgTJ82ykSTnVb5S4FonHRvta1/NXL9kc9 1TmrEUcprAgK9bbilfqal0ZuP1sIyM8OxElk1U82jTG0Ncyx54mOPUhdtKtDsShgV8uvPMn3/Omm1 7Sde8rjCsQA5iHnl2pthnVJISKMg+nt7BLGU3UaQ3n66ucM29uHBerofcIl5rq01A4EbnutXsmIC+ aO6twnUA==; Received: from localhost ([::1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSCU7-0000000FzGe-3jLH; Sat, 14 Nov 2026 12:03:55 +0000 Received: from tor.source.kernel.org ([172.105.4.254]) by bombadil.infradead.org with esmtps (Exim 4.100.1 #2 (Red Hat Linux)) id 1xSCU6-0000000FzEM-1N66 for linux-mtd@lists.infradead.org; Sat, 14 Nov 2026 12:03:54 +0000 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) by tor.source.kernel.org (Postfix) with ESMTP id BCDF46232A; Sat, 14 Nov 2026 12:03:53 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id E7DA11F000C5; Sat, 14 Nov 2026 12:03:52 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794657833; bh=h9QvBLMsaftQkNF5XqflyzTjEcAymvR21sTq1hGFR9U=; h=From:Subject:Reply-To:To:Cc:In-Reply-To:References:Date; b=acRLK16Tv5rVfr5zfeXkCS81IwZynV0Iu0o5OGc2HpX3/05hrjbueaWKLxLlYqLmO z3W+PPmaM3U0hqso0XI+Ooq0RQyvBrwDBT11n9g9KSgX8ZhGVcIxnOI9fIOtTrhxxK HjE1FgbCj1dbiTCHVsQhDOFs56nIgMByBpuhawWcso3hlxTf//5jcUYgwAaZ04rwjz BdkAHdeW3WWvKJw7xI6KV+jY+dZQrvNHw7VEagMRPiDHtBYiWi45s6JmOMZp7SE9XB WqfiGf81GveG6tD+O2sIN9n3nXaeikmtUkJNFdgDSm4yOjub0sItWiIhIB1G/G4u+I 3yjoHedFGAoMA== Message-ID: From: sashiko-bot@kernel.org Subject: Re: [PATCH v3 30/33] ubifs: don't set SB_RDONLY after errors To: "Christian Brauner" , "Jan Kara" Cc: "Al Viro" , linux-ext4@vger.kernel.org, linux-mm@kvack.org, linux-efi@vger.kernel.org, linux-mtd@lists.infradead.org, dsterba@suse.cz, tytso@mit.edu, "Mark Fasheh" , "Joel Becker" , "Joseph Qi" In-Reply-To: <20261113-work-fs-sb_rdonly-v3-30-0be92bb73709@kernel.org> References: <20261113-work-fs-sb_rdonly-v3-0-0be92bb73709@kernel.org> <20261113-work-fs-sb_rdonly-v3-30-0be92bb73709@kernel.org> Date: Sat, 14 Nov 2026 12:03:52 +0000 X-BeenThere: linux-mtd@lists.infradead.org X-Mailman-Version: 2.1.34 Precedence: list List-Id: Linux MTD discussion mailing list List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: sashiko-reviews@lists.linux.dev X-Archived-By: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 Sender: "linux-mtd" X-Spam-Status: No, score=-8.9 required=3.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_EF,HEADER_FROM_DIFFERENT_DOMAINS, INCLUDES_PATCH,MAILING_LIST_MULTI,SPF_HELO_NONE,SPF_PASS autolearn=ham autolearn_force=no version=4.0.1 X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-26) on aws-us-west-2-korg-listserv-alma10-1 VGhhbmsgeW91IGZvciB5b3VyIGNvbnRyaWJ1dGlvbiEgU2FzaGlrbyBBSSByZXZpZXcgZm91bmQg MyBwb3RlbnRpYWwKaXNzdWVzIHRvIGNvbnNpZGVyOgotIFtNZWRpdW1dIHViaWZzOiBmYWxzZSBz cGFjZSBhY2NvdW50aW5nIGVycm9yIGluIHViaWZzX3JlbW91bnRfcm8oKQogIGFmdGVyIGVycm9y Ci0gW01lZGl1bV0gdWJpZnM6IHViaWZzX2ZzeW5jKCkgdHJpcHMgIWMtPnJvX21vdW50IGFzc2Vy dCBhZnRlciBlcnJvcgogIHJlbW91bnQKLSBbTWVkaXVtXSB1YmlmczogcmFjZSBiZXR3ZWVuIGlu LWZsaWdodCB3cml0ZWJhY2sgYW5kCiAgdWJpZnNfcmVtb3VudF9ybygpIGFmdGVyIGVycm9yCi0t Cgpjb21taXQgZmRhNmZiZDMwNzUzN2RmZDk5ZWY3NWIzNjEwMDIyYzVhZjRhOTM1MwpBdXRob3I6 IENocmlzdGlhbiBCcmF1bmVyIDxicmF1bmVyQGtlcm5lbC5vcmc+Cgp1YmlmczogZG9uJ3Qgc2V0 IFNCX1JET05MWSBhZnRlciBlcnJvcnMKClRoaXMgY29tbWl0IHN3aXRjaGVzIHViaWZzX3JvX21v ZGUoKSBmcm9tIHNldHRpbmcgU0JfUkRPTkxZIGRpcmVjdGx5IG9uCnNfZmxhZ3MgdG8gY2FsbGlu ZyBzYl9zZXRfZW1lcmdlbmN5X3JvKCksIGFsbG93cyByZW1vdW50aW5nIHJlYWQtb25seSBhZnRl cgphbiBlcnJvciwgYW5kIGRyb3BzIGRpcnR5IGZvbGlvcyBhbmQgaW5vZGVzIGR1cmluZyB3cml0 ZWJhY2sgb25jZQpjLT5yb19lcnJvciBpcyBzZXQuCgo+IGRpZmYgLS1naXQgYS9mcy91Ymlmcy9z dXBlci5jIGIvZnMvdWJpZnMvc3VwZXIuYwo+IGluZGV4IDM4OTcyNzg2ODE3ZTcuLjJkNzEyNzRl ODlhZDAgMTAwNjQ0Cj4gLS0tIGEvZnMvdWJpZnMvc3VwZXIuYwo+ICsrKyBiL2ZzL3ViaWZzL3N1 cGVyLmMKWyAuLi4gXQo+IEBAIC0xODM5LDE5ICsxODQ2LDI2IEBAIHN0YXRpYyB2b2lkIHViaWZz X3JlbW91bnRfcm8oc3RydWN0IHViaWZzX2luZm8gKmMpCj4gIAo+ICAJZGJnX3NhdmVfc3BhY2Vf aW5mbyhjKTsKPiAgCj4gLQlmb3IgKGkgPSAwOyBpIDwgYy0+amhlYWRfY250OyBpKyspIHsKPiAt CQllcnIgPSB1Ymlmc193YnVmX3N5bmMoJmMtPmpoZWFkc1tpXS53YnVmKTsKPiArCS8qIExpa2Ug dWJpZnNfcHV0X3N1cGVyKCksIGRvbid0IHdyaXRlIGFueXRoaW5nIGFmdGVyIGFuIGVycm9yLiAq Lwo+ICsJaWYgKCFjLT5yb19lcnJvcikgewo+ICsJCWZvciAoaSA9IDA7IGkgPCBjLT5qaGVhZF9j bnQ7IGkrKykgewo+ICsJCQllcnIgPSB1Ymlmc193YnVmX3N5bmMoJmMtPmpoZWFkc1tpXS53YnVm KTsKPiArCQkJaWYgKGVycikKPiArCQkJCXViaWZzX3JvX21vZGUoYywgZXJyKTsKPiArCQl9Cj4g Kwo+ICsJCWMtPm1zdF9ub2RlLT5mbGFncyAmPSB+Y3B1X3RvX2xlMzIoVUJJRlNfTVNUX0RJUlRZ KTsKPiArCQljLT5tc3Rfbm9kZS0+ZmxhZ3MgfD0gY3B1X3RvX2xlMzIoVUJJRlNfTVNUX05PX09S UEhTKTsKPiArCQljLT5tc3Rfbm9kZS0+Z2NfbG51bSA9IGNwdV90b19sZTMyKGMtPmdjX2xudW0p Owo+ICsJCWVyciA9IHViaWZzX3dyaXRlX21hc3RlcihjKTsKPiAgCQlpZiAoZXJyKQo+ICAJCQl1 Ymlmc19yb19tb2RlKGMsIGVycik7Cj4gKwl9IGVsc2Ugewo+ICsJCS8qIFN5bmNpbmcgdGhlIHdy aXRlLWJ1ZmZlcnMgd291bGQgaGF2ZSBjYW5jZWxlZCB0aGVtLiAqLwo+ICsJCWZvciAoaSA9IDA7 IGkgPCBjLT5qaGVhZF9jbnQ7IGkrKykKPiArCQkJaHJ0aW1lcl9jYW5jZWwoJmMtPmpoZWFkc1tp XS53YnVmLnRpbWVyKTsKPiAgCX0KCltTZXZlcml0eTogTWVkaXVtXQpDYW4gYW4gaW4tZmxpZ2h0 IHViaWZzX2ZzeW5jKCkgdHJpcCB0aGUgIWMtPnJvX21vdW50IGFzc2VydGlvbiBpbgp1Ymlmc193 YnVmX3N5bmNfbm9sb2NrKCkgd2hlbiByYWNpbmcgd2l0aCBhIHJlYWQtb25seSByZW1vdW50IGFm dGVyIGFuCmVycm9yPwoKV2hlbiBjLT5yb19lcnJvciBpcyBzZXQsIHNraXBwaW5nIHViaWZzX3di dWZfc3luYygpIGxlYXZlcyB3YnVmLT51c2VkIGFuZAp3YnVmLT5pbm9kZXNbXSBwb3B1bGF0ZWQg d2hpbGUgdWJpZnNfcmVtb3VudF9ybygpIHNldHMgYy0+cm9fbW91bnQgPSAxLgpCZWNhdXNlIHZm c19mc3luY19yYW5nZSgpIGRvZXMgbm90IGhvbGQgc191bW91bnQgb3IgbW50X3dhbnRfd3JpdGUo KSwgYW4KZnN5bmMoKSBvbiBhbiBpbm9kZSB3aG9zZSBub2RlIGlzIGFscmVhZHkgYnVmZmVyZWQg aW4gYSB3YnVmICh3aXRoIG5vIGRpcnR5CmZvbGlvcyBhbmQgdWktPmRpcnR5ID09IDApIGNhbiBp bnRlcmxlYXZlIHdpdGggdWJpZnNfcmVtb3VudF9ybygpOgoKQ1BVMCAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIENQVTEKdWJpZnNfZnN5bmMoKQogIGlmIChjLT5yb19tb3VudCkKICAgIHJl dHVybiAwOwogIGZpbGVfd3JpdGVfYW5kX3dhaXRfcmFuZ2UoKQogIHViaWZzX3dyaXRlX2lub2Rl KCkgLT4gMAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgdWJpZnNfcmVtb3VudF9y bygpCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGhydGltZXJfY2FuY2VsKCZ3 YnVmLT50aW1lcikKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYy0+cm9fbW91 bnQgPSAxCiAgdWJpZnNfc3luY193YnVmc19ieV9pbm9kZSgpCiAgICB1Ymlmc193YnVmX3N5bmNf bm9sb2NrKHdidWYpCiAgICAgIHViaWZzX2Fzc2VydChjLCAhYy0+cm9fbWVkaWEgJiYgIWMtPnJv X21vdW50KQogICAgICAgIDwtLSBhc3NlcnRpb24gZmFpbHVyZQoKSW4gdWJpZnNfd2J1Zl9zeW5j X25vbG9jaygpLCB0aGUgIWMtPnJvX21vdW50IGFzc2VydGlvbiBydW5zIGJlZm9yZSB0aGUKaWYg KGMtPnJvX2Vycm9yKSByZXR1cm4gLUVST0ZTIGNoZWNrLCBjYXVzaW5nIGEgd2FybmluZyBhbmQg c3RhY2sgZHVtcCAob3IKYSBwYW5pYyB3aGVuIG1vdW50ZWQgd2l0aCBhc3NlcnQ9cGFuaWMpLgoK PiAtCj4gLQljLT5tc3Rfbm9kZS0+ZmxhZ3MgJj0gfmNwdV90b19sZTMyKFVCSUZTX01TVF9ESVJU WSk7Cj4gLQljLT5tc3Rfbm9kZS0+ZmxhZ3MgfD0gY3B1X3RvX2xlMzIoVUJJRlNfTVNUX05PX09S UEhTKTsKPiAtCWMtPm1zdF9ub2RlLT5nY19sbnVtID0gY3B1X3RvX2xlMzIoYy0+Z2NfbG51bSk7 Cj4gLQllcnIgPSB1Ymlmc193cml0ZV9tYXN0ZXIoYyk7Cj4gLQlpZiAoZXJyKQo+IC0JCXViaWZz X3JvX21vZGUoYywgZXJyKTsKPiAtCj4gIAl2ZnJlZShjLT5vcnBoX2J1Zik7Cj4gIAljLT5vcnBo X2J1ZiA9IE5VTEw7Cj4gIAlrZnJlZShjLT53cml0ZV9yZXNlcnZlX2J1Zik7CgpbU2V2ZXJpdHk6 IE1lZGl1bV0KQ2FuIHViaWZzX3JlbW91bnRfcm8oKSBmcmVlIGMtPndyaXRlX3Jlc2VydmVfYnVm IGFuZCBzZXQgYy0+cm9fbW91bnQgPSAxCndoaWxlIGFuIGluLWZsaWdodCBkb193cml0ZXBhZ2Uo KSBpcyBzdGlsbCBydW5uaW5nPwoKT25jZSB1Ymlmc19yb19tb2RlKCkgY2FsbHMgc2Jfc2V0X2Vt ZXJnZW5jeV9ybygpLCBzeW5jX2ZpbGVzeXN0ZW0oc2IpIGluCnViaWZzX3JlY29uZmlndXJlKCkg cmV0dXJucyBpbW1lZGlhdGVseSBhdCBzYl9yZG9ubHlfYW55KHNiKSB3aXRob3V0CmNhbGxpbmcg c3luY19pbm9kZXNfc2IoKSBvciB3YWl0aW5nIGZvciBpbi1mbGlnaHQgd3JpdGViYWNrLiAgQSB3 cml0ZWJhY2sKY2FsbGVyIHRoYXQgZG9lcyBub3QgdGFrZSBtbnRfd2FudF93cml0ZSgpIG9yIHNf dW1vdW50IChzdWNoIGFzCnN5bmNfZmlsZV9yYW5nZSgpKSBjYW4gcGFzcyB0aGUgdW5sb2NrZWQg Yy0+cm9fZXJyb3IgY2hlY2sgaW4KZG9fd3JpdGVwYWdlKCkganVzdCBiZWZvcmUgYW4gZXJyb3Ig b2NjdXJzIGFuZCB0aGVuIHJhY2Ugd2l0aAp1Ymlmc19yZW1vdW50X3JvKCk6CgpDUFUwICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgQ1BVMQpkb193cml0ZXBhZ2UoKQogIGlmICh1bmxpa2Vs eShjLT5yb19lcnJvcikpCiAgdWJpZnNfam5sX3dyaXRlX2RhdGEoKQogICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgdWJpZnNfcm9fbW9kZSgpCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgIGMtPnJvX2Vycm9yID0gMQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzYl9zZXRfZW1lcmdlbmN5X3JvKHNiKQogICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgdWJpZnNfcmVjb25maWd1cmUoKQogICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBzeW5jX2ZpbGVzeXN0ZW0oc2IpIC0+IDAKICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgdWJpZnNfcmVtb3VudF9ybygpCiAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAga2ZyZWUoYy0+d3JpdGVfcmVzZXJ2ZV9idWYpCiAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgYy0+d3JpdGVfcmVzZXJ2ZV9idWYgPSBOVUxMCiAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgYy0+cm9fbW91bnQgPSAxCiAgICBtdXRleF9s b2NrKCZjLT53cml0ZV9yZXNlcnZlX211dGV4KQogICAgZGF0YSA9IGMtPndyaXRlX3Jlc2VydmVf YnVmCiAgICBkYXRhLT5jaC5ub2RlX3R5cGUgPSAuLi4KICAgICAgPC0tIE5VTEwgZGVyZWZlcmVu Y2Ugb3IgdXNlLWFmdGVyLWZyZWUKCkV2ZW4gd2hlbiBrbWFsbG9jKCkgc3VjY2VlZHMgaW4gdWJp ZnNfam5sX3dyaXRlX2RhdGEoKSwgbWFrZV9yZXNlcnZhdGlvbigpCnN1YnNlcXVlbnRseSBjYWxs cyByZXNlcnZlX3NwYWNlKCksIHRyaXBwaW5nCnViaWZzX2Fzc2VydChjLCAhYy0+cm9fbWVkaWEg JiYgIWMtPnJvX21vdW50KS4KCj4gQEAgLTE5NzcsMTAgKzE5OTEsNyBAQCBzdGF0aWMgaW50IHVi aWZzX3JlY29uZmlndXJlKHN0cnVjdCBmc19jb250ZXh0ICpmYykKPiAgCQlpZiAoZXJyKQo+ICAJ CQlyZXR1cm4gZXJyOwo+ICAJfSBlbHNlIGlmICghYy0+cm9fbW91bnQgJiYgKGZjLT5zYl9mbGFn cyAmIFNCX1JET05MWSkpIHsKPiAtCQlpZiAoYy0+cm9fZXJyb3IpIHsKPiAtCQkJdWJpZnNfbXNn KGMsICJjYW5ub3QgcmUtbW91bnQgUi9PIGR1ZSB0byBwcmlvciBlcnJvcnMiKTsKPiAtCQkJcmV0 dXJuIC1FUk9GUzsKPiAtCQl9Cj4gKwkJLyogQWZ0ZXIgYW4gZXJyb3IgdWJpZnNfcmVtb3VudF9y bygpIGNhbid0IHdyaXRlIGJ1dCBzdGlsbCB3b3Jrcy4gKi8KPiAgCQl1Ymlmc19yZW1vdW50X3Jv KGMpOwo+ICAJfQoKW1NldmVyaXR5OiBNZWRpdW1dClNob3VsZCB1Ymlmc19yZW1vdW50X3JvKCkg c2tpcCBkYmdfc2F2ZV9zcGFjZV9pbmZvKCkgYW5kCmRiZ19jaGVja19zcGFjZV9pbmZvKCkgd2hl biBjLT5yb19lcnJvciBpcyBzZXQsIGFzIHViaWZzX3B1dF9zdXBlcigpIGFuZAp0aGUgdGFrZW5f ZW1wdHlfbGVicyBjaGVjayBpbiB1Ymlmc19yZWNvbmZpZ3VyZSgpIGRvPwoKQmVjYXVzZSBzeW5j X2ZpbGVzeXN0ZW0oKSBpcyBhIG5vLW9wIG9uY2Ugc2Jfc2V0X2VtZXJnZW5jeV9ybygpIGlzIHNl dCwKZGlydHkgZm9saW9zIGFuZCBkaXJ0eSBpbm9kZXMgcmVtYWluIHBlbmRpbmcgZHVyaW5nIHVi aWZzX3JlbW91bnRfcm8oKS4KZGJnX3NhdmVfc3BhY2VfaW5mbygpIHNuYXBzaG90cyB1Ymlmc19n ZXRfZnJlZV9zcGFjZV9ub2xvY2soKSwgd2hpY2gKaW5jbHVkZXMgYy0+YmkuZGF0YV9ncm93dGgg YW5kIGMtPmJpLmRkX2dyb3d0aC4gIElmIGEgY29uY3VycmVudCB3cml0ZWJhY2sKb3IgZm9saW8g cmVsZWFzZSBkcm9wcyBhIGRpcnR5IGZvbGlvIHZpYSBkb193cml0ZXBhZ2UoKSBvciBhIGRpcnR5 IGlub2RlCnZpYSB1Ymlmc193cml0ZV9pbm9kZSgpIGJlZm9yZSBkYmdfY2hlY2tfc3BhY2VfaW5m bygpIHJ1bnMgYXQgdGhlIGVuZCBvZgp1Ymlmc19yZW1vdW50X3JvKCksIHJlbGVhc2luZyB0aGF0 IHBhZ2Ugb3IgaW5vZGUgYnVkZ2V0IGNoYW5nZXMgdGhlCnJlcG9ydGVkIGZyZWUgc3BhY2UgYW5k IGNhdXNlcyBkYmdfY2hlY2tfc3BhY2VfaW5mbygpIHRvIGxvZyBhIGZhbHNlICJmcmVlCnNwYWNl IGNoYW5nZWQiIGVycm9yIGFuZCBjYWxsIGR1bXBfc3RhY2soKS4KCi0tIApTYXNoaWtvIEFJIHJl dmlldyDCtyBodHRwczovL3Nhc2hpa28uZGV2LyMvcGF0Y2hzZXQvMjAyNjExMTMtd29yay1mcy1z Yl9yZG9ubHktdjMtMC0wYmU5MmJiNzM3MDlAa2VybmVsLm9yZz9wYXJ0PTMwCgpfX19fX19fX19f X19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX19fX18KTGludXggTVREIGRp c2N1c3Npb24gbWFpbGluZyBsaXN0Cmh0dHA6Ly9saXN0cy5pbmZyYWRlYWQub3JnL21haWxtYW4v bGlzdGluZm8vbGludXgtbXRkLwo=