Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
On 6/7/23 7:55 pm, J. R. Okajima wrote: > > My current development base version is v5.10. > I tried aufs5.10, and failed compiling tools/lib/subcmd/subcmd-util.h. > There is a commit in v5.17-rc5, > > > commit 52a9dab6d892763b2a8334a568bd4e2c1a6fde66 > Author: Kees Cook > Date: Sun Feb 13 10:24:43 2022 -0800 > > libsubcmd: Fix use-after-free for realloc(..., 0) > > GCC 12 correctly reports a potential use-after-free condition in the > xrealloc helper. Fix the warning by avoiding an implicit "free(ptr)" > when size == 0: > > In file included from help.c:12: > In function 'xrealloc', > inlined from 'add_cmdname' at help.c:24:2: subcmd-util.h:56:23: > error: p > ointer may be used after 'realloc' [-Werror=use-after-free] >56 | ret = realloc(ptr, size); > | ^~ > ::: > > > J. R. Okajima Thank you for pointing this out, Junjiro-san. My kernel is 5.19 and was built with gcc 7.3.0, and it compiled okay (with aufs) back then. I'm going to update to one of the stable 6.x releases soon with gcc 12, so this is something that I really have to watch out. cheers!
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
James B: > That's strange. > Which kernel version did you try to compile? > I have just upgraded to gcc 12.2.0 as well and if this gcc has problems > building kernels (new and old), I'll be stuck as well ... My current development base version is v5.10. I tried aufs5.10, and failed compiling tools/lib/subcmd/subcmd-util.h. There is a commit in v5.17-rc5, commit 52a9dab6d892763b2a8334a568bd4e2c1a6fde66 Author: Kees Cook Date: Sun Feb 13 10:24:43 2022 -0800 libsubcmd: Fix use-after-free for realloc(..., 0) GCC 12 correctly reports a potential use-after-free condition in the xrealloc helper. Fix the warning by avoiding an implicit "free(ptr)" when size == 0: In file included from help.c:12: In function 'xrealloc', inlined from 'add_cmdname' at help.c:24:2: subcmd-util.h:56:23: error: p ointer may be used after 'realloc' [-Werror=use-after-free] 56 | ret = realloc(ptr, size); | ^~ ::: J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
On 6/7/23 7:27 pm, hooanon...@gmail.com wrote: > "J. R. Okajima": >> Now I am thinking about changing mount.aufs(8) helper. >> - users specify "br:path1:path2" as usual. >> - mount.aufs helper (in aufs-util.git) translate it into >> "br=path1:path2" and executes /bin/mount with -i option, which stops >> calling mount.aufs again. >> >> I'm still considering... > I was going to try this approach, but failed. > Technically speaking, I could not start my aufs work. > Currently my main pc is debian v12 (bookworm) and it has gcc-11 and > gcc-12. And my current aufs development version is v5.10. > Unfortunately this version of linux kernel cannot be compiled by > gcc-12!! > I'm stucked again... That's strange. Which kernel version did you try to compile? I have just upgraded to gcc 12.2.0 as well and if this gcc has problems building kernels (new and old), I'll be stuck as well ...
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
"J. R. Okajima": > Now I am thinking about changing mount.aufs(8) helper. > - users specify "br:path1:path2" as usual. > - mount.aufs helper (in aufs-util.git) translate it into > "br=path1:path2" and executes /bin/mount with -i option, which stops > calling mount.aufs again. > > I'm still considering... I was going to try this approach, but failed. Technically speaking, I could not start my aufs work. Currently my main pc is debian v12 (bookworm) and it has gcc-11 and gcc-12. And my current aufs development version is v5.10. Unfortunately this version of linux kernel cannot be compiled by gcc-12!! I'm stucked again... J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
James B: > It's important to keep backward compatibility, as not every people will > suddenly update to the latest util-linux. > While it is important to plan for the future, it's important not to > break existing applications. > We don't want people updating the kernel (+aufs) and find that all their > systems suddenly stopped working because the format has changed. Agreed. But also I don't want to force util-linux/libmount to handle aufs differently. Now I am thinking about changing mount.aufs(8) helper. - users specify "br:path1:path2" as usual. - mount.aufs helper (in aufs-util.git) translate it into "br=path1:path2" and executes /bin/mount with -i option, which stops calling mount.aufs again. I'm still considering... J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
On 3/7/23 4:00 pm, hooanon...@gmail.com wrote: > I don't want introducing unnecessary confusing and incompatibility. Thank you very mmuch for this consideration. It's important to keep backward compatibility, as not every people will suddenly update to the latest util-linux. While it is important to plan for the future, it's important not to break existing applications. We don't want people updating the kernel (+aufs) and find that all their systems suddenly stopped working because the format has changed. cheers, James
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Hi,
Guan Xin:
> Does this look ok? --
> mount -t aufs -o br=3D${BR1_ATTR}:${PATH_TO_BR1} -o
> br=3D${BR2_ATTR}:${PATH_TO_BR2}
> which is equivalent to
> mount -t aufs -o br=3D${BR1_ATTR}:${PATH_TO_BR1},br=3D${BR2_ATTR}:${PATH_=
> TO_BR2}
> (Special characters need to be escaped in the latter form.)
Thanx for the suggestion, but I'm afraid it makes users (including me)
confused about the processing order.
Actually aufs has a mount option "append:path[=attr]". Your suggestion
is equivalent to current 'append' option.
Currently two "br" options never mean appending. I don't want
introducing unnecessary confusing and incompatibility.
J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Dear Okajima,
On Mon, Jul 3, 2023 at 6:19 AM wrote:
>
//snip
> > For example overlayfs uses lowerdir=/lower1:/lower2:/lower3, so the usage
> > of colon as separator within an option value is not unique.
>
> I know about that.
> But overlayfs doesn't have the layer attribute such as "=rw" and "=rr".
Does this look ok? --
mount -t aufs -o br=${BR1_ATTR}:${PATH_TO_BR1} -o
br=${BR2_ATTR}:${PATH_TO_BR2}
which is equivalent to
mount -t aufs -o br=${BR1_ATTR}:${PATH_TO_BR1},br=${BR2_ATTR}:${PATH_TO_BR2}
(Special characters need to be escaped in the latter form.)
Regards,
Guan
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Thomas Wei schuh: > > "br=/upper=rw:/lower=ro" is not bad but I feel weird. > > This feels ok for me. For me, "A = B = C" looks strange because B is a path and C is its attribute. But I start making myself feel "there is no problem here." > For example overlayfs uses lowerdir=/lower1:/lower2:/lower3, so the usage > of colon as separator within an option value is not unique. I know about that. But overlayfs doesn't have the layer attribute such as "=rw" and "=rr". J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Hi! On 2023-07-01 09:08:46+0900, J. R. Okajima wrote: > Hello Thomas, > > Thomas Wei schuh: > > recently util-linux 2.39 was released. > > In this release the mount(8) command and libmount where changed to use > > the new fd-based mount API found in newer kernels. > ::: > > Would it make sense from aufs side to update the docs to use the > > equality sign based syntax? > > It seems to be supported as well as the colon-based one. > > Thanx for the report. > Aufs is using colon in several options where an eaual sign specifies the > branch attribute such as RW and ROs. > Now I need to consider about all of them. > > Currently > > br:/upper=rw:/lower=ro > > is the only option to take multiple branch specifiers. > Also this branch syntax appears in /sys/fs/aufs/si_XXX/br0, br1, ... > > br0: /upper=rw > br1: /lower=ro > > I believe they should be same to the mount option syntax. > "br=/upper=rw:/lower=ro" is not bad but I feel weird. This feels ok for me. For example overlayfs uses lowerdir=/lower1:/lower2:/lower3, so the usage of colon as separator within an option value is not unique. Also having more equality signs within an option does not seem too weird to me, but I don't know about a precedent of the top of my head. > If I change "/upper:rw' syntax, that is not bad. But what is good to > delimit the branches? > > Additionally there are other options using colon, > > add:1:/middle=rw > mod:/upper=ro > append:/bottom=rr+wh > prepend:/new_top=rw+icex > > Hmm, these options take only one branch specifier. It may be rather > easier than 'br' option. But I need to consider. > > The option to remove a branch from the union is easy to replace. > > del:dir > > Other options using colon are not required to replace > > create=tdmfs:low[:second] > create=mfs[:second] > create=mfsrr:low[:second] > create=pmfs[:second] > create=pmfsrr:low[:second] > > I am still thinking... Users in the linked issue reported that at least for br: and add: it is already possible to use the equality sign instead of the colon. (At least with the new mount API) And for "br" it is already documented this way on aufs.sourceforge.net. This made me think that the equality sign would already be fully supported by aufs, hoping it would only be necessary to update and align the documentation. Thomas
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Hello Thomas, Thomas Wei schuh: > recently util-linux 2.39 was released. > In this release the mount(8) command and libmount where changed to use > the new fd-based mount API found in newer kernels. ::: > Would it make sense from aufs side to update the docs to use the > equality sign based syntax? > It seems to be supported as well as the colon-based one. Thanx for the report. Aufs is using colon in several options where an eaual sign specifies the branch attribute such as RW and ROs. Now I need to consider about all of them. Currently br:/upper=rw:/lower=ro is the only option to take multiple branch specifiers. Also this branch syntax appears in /sys/fs/aufs/si_XXX/br0, br1, ... br0: /upper=rw br1: /lower=ro I believe they should be same to the mount option syntax. "br=/upper=rw:/lower=ro" is not bad but I feel weird. If I change "/upper:rw' syntax, that is not bad. But what is good to delimit the branches? Additionally there are other options using colon, add:1:/middle=rw mod:/upper=ro append:/bottom=rr+wh prepend:/new_top=rw+icex Hmm, these options take only one branch specifier. It may be rather easier than 'br' option. But I need to consider. The option to remove a branch from the union is easy to replace. del:dir Other options using colon are not required to replace create=tdmfs:low[:second] create=mfs[:second] create=mfsrr:low[:second] create=pmfs[:second] create=pmfsrr:low[:second] I am still thinking... J. R. Okajima
Re: mount option incompatibility with (lib)mount 2.39 and new kernel mount API
Hi everyone, recently util-linux 2.39 was released. In this release the mount(8) command and libmount where changed to use the new fd-based mount API found in newer kernels. Unfortunately the old(?) option syntax in aufs using colons, instead of equality signs, does not work anymore with the new mount(8) using the new kernel API. This does not work: mount -t aufs -o br:/tmp/rw none /tmp/aufs This does work: mount -t aufs -o br=/tmp/rw none /tmp/aufs Would it make sense from aufs side to update the docs to use the equality sign based syntax? It seems to be supported as well as the colon-based one. See also https://github.com/util-linux/util-linux/issues/2309 Thanks, Thomas
