Date: Fri, 22 Nov 2013 09:42:28 +0200 From: Konstantin Belousov <kostikbel@gmail.com> To: Doug Ambrisko <ambrisko@ambrisko.com> Cc: freebsd-hackers@freebsd.org, Dirk Engling <erdgeist@erdgeist.org>, Jase Thew <jase@freebsd.org>, mdf@freebsd.org Subject: Re: Re: Fix MNAMELEN or reimplement struct statfs Message-ID: <20131122074228.GT59496@kib.kiev.ua> In-Reply-To: <20131121174028.GA80520@ambrisko.com> References: <CAMBSHm8GMWffuuEcSpuNu26Mv4N2yAa2iEdw5koiXx0w30zPRQ@mail.gmail.com> <201306101152.17966.jhb@freebsd.org> <52854161.6080104@FreeBSD.org> <20131115010854.GA76106@ambrisko.com> <20131116183129.GD59496@kib.kiev.ua> <20131118190142.GA28210@ambrisko.com> <20131119074922.GY59496@kib.kiev.ua> <20131119174216.GA80753@ambrisko.com> <20131120075531.GE59496@kib.kiev.ua> <20131121174028.GA80520@ambrisko.com>
next in thread | previous in thread | raw e-mail | index | archive | help
--T+nnW5vHQKf/VlFb Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Nov 21, 2013 at 09:40:28AM -0800, Doug Ambrisko wrote: > On Wed, Nov 20, 2013 at 09:55:31AM +0200, Konstantin Belousov wrote: > | On Tue, Nov 19, 2013 at 09:42:16AM -0800, Doug Ambrisko wrote: > | > I was talking about the more general case since the system tries to k= eep > | > the path in the stat structure. My prior approach which had more iss= ues > | > was to modify the stat structure of which I was pointed to NetBSD and= their > | > change to statvfs which doesn't really solve the problem. They don't > | > have the check to see if the mount is longer then VFS_MNAMELEN (in th= eir case) > | > and just truncate things. > | >=20 > | > If we are just talking about adding it to the mount structure that > | > would be okay since it isn't exposed to user land. I can add that. > | > | Yes, this is exactly what I mean. Add a struct mount field, and use > | it for kernel only. In fact, it only matters for sys_unmount() and > | kern_jail.c, other locations in kernel use the path for warnings, and > | this could be postponed if you prefer to minimize the patch. >=20 > Okay, I went through all of the occurances and compile tested (except > for #DEBUG). I united a few things but should do more once I get > consensus on the approach. I found a few spots that should be updated as > well and made the length check more consistant. Some were doing >=3D and= others > >. So this should be better, however, a lot larger. On the plus side > when we figure out how to return the longer path length to user land > that can be more flexible since the kernel is tracking the longer length. > Probably things to note are changes in: > ZFS to mount snapshot > cd9660 for symlinks > fuse to return full path > jail to check statfs and mount > mount/umount to save and check full path > mountroot to save new field for full path > =09 > Just in case it doesn't make it in email the full patch is at: > http://people.freebsd.org/~ambrisko/mount_bigger.patch >=20 Yes, this is closer to the patch I can agree with :). Two notes, one was already made, about off by one. Second is, I suggest to make the mnt_path member a char *. Usually, the mount point path length is quite short, so 1024 bytes for the buffer is excessive. You can allocate exact needed buffer, which would save in around 10KB of kernel memory even for relatively modest amount of 10 mounts. For additional cleverness, mnt_path could point to f_mntonname when the length is less than MNAMELEN. Since mp deallocation is centralized, code for the trick should be not too hard. --T+nnW5vHQKf/VlFb Content-Type: application/pgp-signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v2.0.22 (FreeBSD) iQIcBAEBAgAGBQJSjwrkAAoJEJDCuSvBvK1BTQYP+gI9yGxHBxVh7pn4NBeZjg7e MEe6URaiyFgSSsQ1HCB5Z6pvyXJGBo2ATZKR5IfD/61e9ZAylsLX8YPR7XBDQxv1 c2JGoBNilVbTZdneqx5eP+AWeTvKVPXt1q6xuBozLZy6xV+E9/P4vk+lBP9/bmVF /xKtvYX6wsoM3AXCGlajppvRmBTuknkFgeOlCRrExeX4M0VHDWinphxnQt1f9v51 BHUAlmhJv77i0zi9UzU2/QlsKQ+n/dXKWkiobdzsu7anthdbPOLBSSEMkmAqf44F yRgiv/MXQVdJpS4QXawnarSwdmH7xFw1YXnZk5lb9ysnS3e7EEiT5jlFK+MjQ7EV JiEnVLm9v26lpBoRatfCHahZ+XGUa8WT1OzRWtCOyc/yCpK10kuRAS3hj5+e4vj8 ZNQtZxpMcJ8T20f5kwthE+cqr/dicja/oPgdoqmfEVODcfGmNWZyb43jSnrQabWp p3CKJN3wJ52DQ2oF5khc9XTuJS72PM0BlsXDnlB0+tC0oRjNf74HXJzOrbf/OCh7 6NDbwxFK1OjaqPwaiT9b1J30mnqL8IqRbInkNYFHKBie/Q30cxEe9IpoNsNyRd2F ou8Gwz8hx6R0E/j8m6cRFBeNKF4bej3EEZOgjqtZzLDpyTieZNZFs8cG3Hh15/+5 Jp7ZG8lCHLI2dJEvSNtT =Hye4 -----END PGP SIGNATURE----- --T+nnW5vHQKf/VlFb--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20131122074228.GT59496>