From mboxrd@z Thu Jan 1 00:00:00 1970 From: Lothar =?UTF-8?B?V2HDn21hbm4=?= Date: Tue, 27 Jun 2017 09:05:14 +0200 Subject: [U-Boot] [PATCH v6 3/3] GPT: provide commands to selectively rename partitions In-Reply-To: References: <20170610065138.2410A120BB0@gemini.denx.de> <1497137617-772-1-git-send-email-alison@peloton-tech.com> <20170612074557.E32A3120432@gemini.denx.de> <20170618110357.103A8120607@gemini.denx.de> Message-ID: <20170627090514.60272dd1@karo-electronics.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="windows-1252" Content-Transfer-Encoding: quoted-printable To: u-boot@lists.denx.de Hi, On Sun, 25 Jun 2017 14:54:56 -0700 Alison Chaiken wrote: > On Sun, Jun 18, 2017 at 4:03 AM, Wolfgang Denk wrote: >=20 > > Dear Alison, > > > > In message > gmail.com> you wrote: > > > > > > The idea behind the 'swap' mode is that a storage device can have two > > sets > > > of partitions, one set all named 'primary' and one set all named > > 'backup'. > > > The software updater in userspace can then simply rename the partit= ions > > > with sgdisk in order to pick the new image. The swap mode changes t= he > > > whole set of labels at once, so there's little chance of being > > interrupted. > > > > It's still a sequential, non-atomic operation, and "little chance" > > is exactly the places where Murphy likes to hit you. > > > > > One additional note: the last version I posted worked fine for the > > sandbox, > > > but wouldn't link for an ARM target with the Linaro toolchain, as the > > > linker couldn't find atoi(). I guess the libc for the x86 compiler > > > includes it. To test on ARM, I copied in simple_atoi() from > > > lib/vsprintf.c, but assuredly that is an ugly solution. Does anyone > > have > > > a better idea to solve this problem? > > > > U-Boot should always be self-contained and not link regular library > > code from the tool chain. > > > > Best regards, > > > > Wolfgang Denk > > >=20 > I'm about to submit a new version of the patches that adopts Wolfgang's a= nd > Tom's suggestions about replacing atoi(). >=20 > Regarding the atomicity of 'gpt swap, the point is that 'gpt swap' first > modifies the names in an in-memory > data structure, and then uses the existing 'gpt write' functionality to > change the actual partition table stored on the device. Thus, > interruption of the new command is low-risk, as interruption of the > modification of the new data structure has no persistent effect, and > the risk associated with 'gpt write' is the same as always. >=20 > By the way, in the course of testing an earlier version of this patch > series, I noticed that 'gpt write' and 'gpt verify' segv if presented with > a non-null-terminated partitions string. It's the strlen function in lib > that actually generates an error. I haven't yet quite figured out what the > best solution to the problem is: should strlen() itself be modified, or is > it enough to test in gpt.c? The right solution is not to present the > commands with poorly formed strings, but it's easy to do so. >=20 You can use strnlen() if you know the maximum allowed length of the string. NB: A quick glance at set_gpt_info() revealed this potential crash cause: | str =3D strdup(str_part); | | /* extract disk guid */ | s =3D str; | val =3D extract_val(str, "uuid_disk"); strdup() may fail (especially if the input string is not zero terminated) and return a NULL pointer which then will happily be used by extract_val(). Lothar Wa=C3=9Fmann