From mboxrd@z Thu Jan  1 00:00:00 1970
From: Su Yue <Damenly_Su@gmx.com>
Date: Wed, 22 Apr 2020 22:17:53 +0800
Subject: [PATCH U-BOOT 18/26] fs: btrfs: Implement btrfs_lookup_path()
In-Reply-To: <20200422120451.5864d812@nic.cz>
References: <20200422065009.69392-1-wqu@suse.com>
 <20200422065009.69392-19-wqu@suse.com> <368vvoni.fsf@gmx.com>
 <20200422120451.5864d812@nic.cz>
Message-ID: <h7xbob8u.fsf@gmx.com>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de


On Wed 22 Apr 2020 at 18:04, Marek Behun <marek.behun@nic.cz>
wrote:

> On Wed, 22 Apr 2020 17:46:25 +0800 Su Yue <Damenly_Su@gmx.com>
> wrote:
>
>> > +	while (*cur != '\0') { + +		cur =
>> > skip_current_directories(cur); +		len =
>> > next_length(cur); +		if (len > BTRFS_NAME_LEN) {
>>  next_length() promises @len <= BTRFS_NAME_LEN, so the check is
>> trivial.
>

Okay.
> Hmm. This is a bug in next_length. I meant for next_length to
> return len > BTRFS_NAME_LEN in case of too long name. Thanks for
> noticing.
>
>> > +			ret = btrfs_readlink(root, ino, target); +
>> > if (ret < 0) { +				free(target); +
>> > return ret; +			} +			target[ret] = '\0';
>>  It was done in btrfs_readlink() already.
>
> It is in old btrfs_readlink, but is it even after this patches?
> I don't see it in the new implementation.
>

You are right. The thing changed in the 17th patch.
btrfs_readlink()
doesn't set the null byte now.

--
Su
>> > +
>> > +			ret = btrfs_lookup_path(root, ino, target, &next_root,
>> > +						&next_ino, &next_type,
>> > +						symlink_limit);
>>
>> Just notify gentlely this is a recursive call here. I don't know
>> whether uboot cares about stack things. But, recursion makes coding simpler :).
>
> It is limited by symlink_limit. Until somebody complains about stack
> issues I would like to keep it simple.