From patchwork Tue May 9 08:18:15 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: =?utf-8?b?UmFmYcWCIE1pxYJlY2tp?= X-Patchwork-Id: 759957 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from bombadil.infradead.org (bombadil.infradead.org [65.50.211.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 3wMXMM2FD0z9s3T for ; Tue, 9 May 2017 18:18:55 +1000 (AEST) Authentication-Results: ozlabs.org; dkim=pass (2048-bit key; unprotected) header.d=lists.infradead.org header.i=@lists.infradead.org header.b="QiLFJZAS"; dkim=fail reason="signature verification failed" (2048-bit key; unprotected) header.d=gmail.com header.i=@gmail.com header.b="kmWzkhCk"; dkim-atps=neutral DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=lists.infradead.org; s=bombadil.20170209; h=Sender: Content-Transfer-Encoding:Content-Type:Cc:List-Subscribe:List-Help:List-Post: List-Archive:List-Unsubscribe:List-Id:Subject:MIME-Version:Message-Id:Date:To :From:Reply-To:Content-ID:Content-Description:Resent-Date:Resent-From: Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:In-Reply-To:References: List-Owner; bh=TfDP3ZA5ubvK6uKSwnAtEgaz79Sj2d2cZFK1RwcBkUI=; b=QiLFJZASZ+jC/8 1eFSZYdHwAx2HjeMJbD4Xe9veXHtODAf1+1WEgtvrPt62IzMI+CXerm7VUCFRbGstwqt0z/b0VYOx XcBS9VqnVZKloxvklUVQawsRJpPFCINEmR1z4DhU1w09qNbCbtuv7A1pU2PtENPI2vIBC44paqerU GRIDVD6oemDnHZnG1UqPtFjmAYhfaRAJ3AYEaBsGm0sEAIGFFnlrrYWNG5iSoBKytQ0f4uOAvOwU9 TlN6unzDmBifumZPN8EQwF8r6wwsRW52/6TA2BiAJ5cYYE0cyfOA8N31EQAYzyZ3SHTdky0uTUsRA MycbWQTFK+3VBmwpVp3A==; Received: from localhost ([127.0.0.1] helo=bombadil.infradead.org) by bombadil.infradead.org with esmtp (Exim 4.87 #1 (Red Hat Linux)) id 1d80M6-0002k0-54; Tue, 09 May 2017 08:18:50 +0000 Received: from mail-wr0-x243.google.com ([2a00:1450:400c:c0c::243]) by bombadil.infradead.org with esmtps (Exim 4.87 #1 (Red Hat Linux)) id 1d80M2-0002jB-O4 for lede-dev@lists.infradead.org; Tue, 09 May 2017 08:18:48 +0000 Received: by mail-wr0-x243.google.com with SMTP id w50so11836599wrc.0 for ; Tue, 09 May 2017 01:18:26 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=I/5ZC0i3+9984wS1MkTA0i2hIz69Xh3DhgY5XX6UKXg=; b=kmWzkhCkKSo6P6oOqEXbP6fVfY/OQlXhM+39jzhOArkNOd8+CIH5NLWo22iTh+01cb SGB6B/nPSEaCUNeYv3EaI4xEKvPUR0iWdR+sJH36xPb5ckGR1JJ4vOk8AywrxeFfpCQs jN3Ih597WdjRd+LJi4Rzuuz0sEsnScPHobJ5X+ZNElDD3ByN8VyYB4N2rdwfrIC7FxSO c4uj9V//+H3ZrkKbp1tcoKN+MmBoVDoBQAoktH9USYUB+hdYSo+RU51WgW6+NKX8xZRX h1ODf/UFAWsw1RJV/VJ8zy2nNkz7pU/j+CBn1/HMKPsUQZnHFX7f1lXwExE6ECrGJNGr Srtg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:date:message-id:mime-version :content-transfer-encoding; bh=I/5ZC0i3+9984wS1MkTA0i2hIz69Xh3DhgY5XX6UKXg=; b=HgmbPycPeRBmn5dlfMQYYURNTrCHT9yVRcC2qBVWQj/2dtmPiaWQH1ZDlTTBtXgevV O2cGAFCLXclRvwOaL8glT2mLSD+ZGbs16Vv/lLmAJkhjdrWYuI4P84/rHUx30wCwOzEy Vq7RS6H+iysKdW5EVhwjBbpeIaSpickJGro+XAhFmF01vnfv0ml+wXihQKEOdWQW05Hz AOQucZftz/HfQ6RccNDKbqGcbhiQLhHObzO7vkCcH4QF3I/coMkOjkuq6JR8soxupCig aT9esVkrz562lXvzOvn3xwTn+6CUwI+xJOfenSpMVZX3gGBHZ+dBdfyevLYqq9qRmSiq WXBg== X-Gm-Message-State: AODbwcApVfvFaEc94K4IEXfaA3d7HuA6D2d8wPmQ78cvFjnfRSyNuPwA /5Wn/5Qh1srbEg== X-Received: by 10.46.32.203 with SMTP id g72mr2927526lji.32.1494317905005; Tue, 09 May 2017 01:18:25 -0700 (PDT) Received: from linux-samsung.lan (ip-194-187-74-233.konfederacka.maverick.com.pl. [194.187.74.233]) by smtp.gmail.com with ESMTPSA id l136sm3145468lfg.18.2017.05.09.01.18.24 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 09 May 2017 01:18:24 -0700 (PDT) From: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= To: lede-dev@lists.infradead.org Date: Tue, 9 May 2017 10:18:15 +0200 Message-Id: <20170509081815.2629-1-zajec5@gmail.com> X-Mailer: git-send-email 2.11.0 MIME-Version: 1.0 X-CRM114-Version: 20100106-BlameMichelson ( TRE 0.8.0 (BSD) ) MR-646709E3 X-CRM114-CacheID: sfid-20170509_011846_960066_2BCDC29A X-CRM114-Status: GOOD ( 17.38 ) X-Spam-Score: -1.8 (-) X-Spam-Report: SpamAssassin version 3.4.1 on bombadil.infradead.org summary: Content analysis details: (-1.8 points) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [2a00:1450:400c:c0c:0:0:0:243 listed in] [list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (zajec5[at]gmail.com) 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (zajec5[at]gmail.com) -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's domain 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily valid -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Subject: [LEDE-DEV] [PATCH 17.01] fstools: backport regression fix for volume_identify X-BeenThere: lede-dev@lists.infradead.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: =?UTF-8?q?Rafa=C5=82=20Mi=C5=82ecki?= , Pieter Smith Sender: "Lede-dev" Errors-To: lede-dev-bounces+incoming=patchwork.ozlabs.org@lists.infradead.org From: Rafał Miłecki This fixes regression when volume_identify didn't identify volume on subsequent calls. Signed-off-by: Rafał Miłecki --- package/system/fstools/Makefile | 1 + ...fix-multiple-volume_identify-usages-with-.patch | 56 ++++++++++++++++++++++ 2 files changed, 57 insertions(+) create mode 100644 package/system/fstools/patches/0001-libfstools-fix-multiple-volume_identify-usages-with-.patch diff --git a/package/system/fstools/Makefile b/package/system/fstools/Makefile index cf9bd2119d..28f68b57d6 100644 --- a/package/system/fstools/Makefile +++ b/package/system/fstools/Makefile @@ -15,6 +15,7 @@ PKG_SOURCE_URL=$(LEDE_GIT)/project/fstools.git PKG_SOURCE_DATE:=2016-12-04 PKG_SOURCE_VERSION:=84b530a732b12cca1cd5ee9ba163b7ead7a83de3 PKG_MIRROR_HASH:=b607138de1adbb7f49e53daebe28ac1352910fa2b29278365edeabafc5b46a91 +PKG_RELEASE:=2 CMAKE_INSTALL:=1 PKG_LICENSE:=GPL-2.0 diff --git a/package/system/fstools/patches/0001-libfstools-fix-multiple-volume_identify-usages-with-.patch b/package/system/fstools/patches/0001-libfstools-fix-multiple-volume_identify-usages-with-.patch new file mode 100644 index 0000000000..4a3809a276 --- /dev/null +++ b/package/system/fstools/patches/0001-libfstools-fix-multiple-volume_identify-usages-with-.patch @@ -0,0 +1,56 @@ +From 633a8d0981fed0c90f6d16ee2257858b04514dc8 Mon Sep 17 00:00:00 2001 +From: Pieter Smith +Date: Wed, 29 Mar 2017 18:21:56 +0200 +Subject: [PATCH] libfstools: fix multiple volume_identify usages with the same + volume +MIME-Version: 1.0 +Content-Type: text/plain; charset=UTF-8 +Content-Transfer-Encoding: 8bit + +This fixes e.g. factory-flashed startup issue with jffs2 on ubi overlay + +Commit ba019965 ("libfstools: accept volume as argument in most calls") +broke startup for factory-flashed jffs2 on ubi systems, causing substantial +slowdown in factory environments. + +When starting up with a factory-flashed jffs2 on ubi system, the "rootfs_data" +volume contains a deadcode marker. In the start phase, mount_root then mounts a +tmpfs overlay, and postpones remounting of the jffs2 overlay until the done +phase of the startup. + +The refactoring in ba019965 eliminated an unneeded call to volume_find() when +done() called jffs2_switch(). Unfortunately the refactoring did not take into +account that volume_identify() does not function correctly when called twice in +a row on the same struct volume when using an mtd driver. + +mtd_volume_identify() uses mtd_volume_load() to open an fd to the mtd device +and reads a potential deadcode marker from the fd. The first time this works, +and FS_DEADCODE is returned. + +When volume_identify() is called a second time however, mtd_volume_load() +notices that we already have an open fd, does nothing further and returns 0 +without resetting the file offset to 0. mtd_volume_identify() now reads past +the deadcode marker and now returns FS_JFFS2 if the mtd device is a UBIVOLUME. + +jffs2_switch() then handles the wrong case, either pulling the root out from +under user-space in Chaos Calmer, or indefinitely sticking to a tmpfs overlay +in later OpenWRT builds. + +Signed-off-by: Pieter Smith +Signed-off-by: Rafał Miłecki +--- + +--- a/libfstools/mtd.c ++++ b/libfstools/mtd.c +@@ -76,8 +76,10 @@ static int mtd_volume_load(struct mtd_vo + struct mtd_info_user mtdInfo; + struct erase_info_user mtdLockInfo; + +- if (p->fd) ++ if (p->fd) { ++ lseek(p->fd, 0, SEEK_SET); + return 0; ++ } + + if (!p->chr) + return -1;