Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
No worries. Thanks for the correction!
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Sun, Apr 07, 2019 at 06:11:58PM +0200, Mariusz Zaborski wrote:
> In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to
> bump
> __FreeBSD_version. I confirmed that with Warner. So this was my mistake.
>
> Thanks Shawn.
> --
> Mariusz Zaborski
> oshogbo//vx | http://oshogbo.vexillium.org
> FreeBSD committer | https://freebsd.org
> Software developer| http://wheelsystems.com
> If it's not broken, let's fix it till it is!!1
>
> On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > > wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > > > >> version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > > > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
> >
> > --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX: Web: http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> >
signature.asc
Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On April 7, 2019 7:11:52 AM PDT, Shawn Webb wrote: >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: >> Author: oshogbo >> Date: Sat Apr 6 09:34:26 2019 >> New Revision: 345982 >> URL: https://svnweb.freebsd.org/changeset/base/345982 >> >> Log: >> Introduce funlinkat syscall that always us to check if we are >removing >> the file associated with the given file descriptor. >> >> Reviewed by: kib, asomers >> Reviewed by: cem, jilles, brooks (they reviewed previous version) >> Discussed with:pjd, and many others >> Differential Revision: https://reviews.freebsd.org/D14567 > >Hey Mariusz, > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? >I can't remember off-hand. > >Thanks, I don't think so. Why force the rebuild of all ports through poudriere over something that would never affect any of them? -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert
wrote:
> In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb <
> shawn.w...@hardenedbsd.org> wr
> > ote:
> > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > >> Author: oshogbo
> > > >> Date: Sat Apr 6 09:34:26 2019
> > > >> New Revision: 345982
> > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > >>
> > > >> Log:
> > > >> Introduce funlinkat syscall that always us to check if we are
> > > >removing
> > > >> the file associated with the given file descriptor.
> > > >>
> > > >> Reviewed by: kib, asomers
> > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> version)
> > > >> Discussed with:pjd, and many others
> > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > >
> > > >Hey Mariusz,
> > > >
> > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > >I can't remember off-hand.
> > > >
> > > >Thanks,
> > >
> > > I don't think so. Why force the rebuild of all ports through poudriere
> over
> > something that would never affect any of them?
> >
> > So that you can if version >= foo to know it is safe to use the new
> syscal?
> > Or if version < foo you must use the old way.
>
> Granted. However we do need something to avoid gratuitous rebuilds of
> ports.
>
> Personally, my poudriere script adjusts the pkg version
> ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> that of the jail version (reported by poudriere jail -i -j $JAIL),
> rebuilding all ports when I (the human) determines when the machine
> should rebuild all ports with -c.
>
> In that regard FreeBSD version bumps occasionally seem a little
> gratuitous. Using the same indicator to tell whether software should be
> able to use a new feature and when ports build infrastructure should
> summarily delete all packages forcing a rebuild of absolutely
> everything is probably not the best.
>
> Just throwing out an idea, what if poudriere considers the first N
> bytes of __FreeBSD_version significant? Having said that, looking at
> __FreeBSD_version, I don't think we have enough digits to do what I was
> planning on suggesting. But, you get the idea of what I'm driving at.
> Maybe a new macro such as __FreeBSD_ports that is incremented every
> time a change that affects ports?
>
> Anyhow, I'm not too terribly concerned as what I have (selfishly
> speaking) works. But we may as a group might want to consider this at
> some point to build some efficiency into the ports part of the equation.
>
We generally bump the version around the time we add a syscall. This allows
any wrappers to call it or not based on the kernel version and avoid a
SIGSYS when we're doing forward compatibility hacks for whatever reason.
The current overloading of __FreeBSD_version is unfortunate. We've been
quite liberal over the past 2 decades at bumping it because it's free to do
so. Or so the thinking has been. I personally think we should continue to
do so, but maybe look at piggy-backing those changes we can if someone else
bumped it in the last few days. To give some perspective, in the ~120 days
since we branched, we've bumped it 17 times. This is more or less weekly,
which suggests we don't have a problem that we need to optimize too much
here.
If Poudriere wants to optimize building, I'd suggest that you have a
command line argument / config file thing that sets the maximum skew.
Normally, you could set it up to be pretty tolerant, but if you knew
something was a big deal, you could then crank down to intolerant. The
current setting of '1' for this skew should be the default.
I'm not sure a FreeBSD_ports would scale. How do you know a port won't need
to know about the new syscall? It's from Linux, and there may be some ports
that use it if available. As a src committer, I've not easy way to know
(and no hard way to know that's not a full exprun).
Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
> On April 7, 2019 7:11:52 AM PDT, Shawn Webb > wrote: > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > >> Author: oshogbo > >> Date: Sat Apr 6 09:34:26 2019 > >> New Revision: 345982 > >> URL: https://svnweb.freebsd.org/changeset/base/345982 > >> > >> Log: > >> Introduce funlinkat syscall that always us to check if we are > >removing > >> the file associated with the given file descriptor. > >> > >> Reviewed by: kib, asomers > >> Reviewed by: cem, jilles, brooks (they reviewed previous version) > >> Discussed with: pjd, and many others > >> Differential Revision: https://reviews.freebsd.org/D14567 > > > >Hey Mariusz, > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? > >I can't remember off-hand. > > > >Thanks, > > I don't think so. Why force the rebuild of all ports through poudriere over > something that would never affect any of them? So that you can if version >= foo to know it is safe to use the new syscal? Or if version < foo you must use the old way. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to bump
__FreeBSD_version. I confirmed that with Warner. So this was my mistake.
Thanks Shawn.
--
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer | https://freebsd.org
Software developer | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1
On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > wr
> > ote:
> > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > >> Author: oshogbo
> > > >> Date: Sat Apr 6 09:34:26 2019
> > > >> New Revision: 345982
> > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > >>
> > > >> Log:
> > > >> Introduce funlinkat syscall that always us to check if we are
> > > >removing
> > > >> the file associated with the given file descriptor.
> > > >>
> > > >> Reviewed by: kib, asomers
> > > >> Reviewed by: cem, jilles, brooks (they reviewed previous version)
> > > >> Discussed with: pjd, and many others
> > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > >
> > > >Hey Mariusz,
> > > >
> > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > >I can't remember off-hand.
> > > >
> > > >Thanks,
> > >
> > > I don't think so. Why force the rebuild of all ports through poudriere
> > > over
> > something that would never affect any of them?
> >
> > So that you can if version >= foo to know it is safe to use the new syscal?
> > Or if version < foo you must use the old way.
>
> Granted. However we do need something to avoid gratuitous rebuilds of
> ports.
>
> Personally, my poudriere script adjusts the pkg version
> ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> that of the jail version (reported by poudriere jail -i -j $JAIL),
> rebuilding all ports when I (the human) determines when the machine
> should rebuild all ports with -c.
>
> In that regard FreeBSD version bumps occasionally seem a little
> gratuitous. Using the same indicator to tell whether software should be
> able to use a new feature and when ports build infrastructure should
> summarily delete all packages forcing a rebuild of absolutely
> everything is probably not the best.
>
> Just throwing out an idea, what if poudriere considers the first N
> bytes of __FreeBSD_version significant? Having said that, looking at
> __FreeBSD_version, I don't think we have enough digits to do what I was
> planning on suggesting. But, you get the idea of what I'm driving at.
> Maybe a new macro such as __FreeBSD_ports that is incremented every
> time a change that affects ports?
>
> Anyhow, I'm not too terribly concerned as what I have (selfishly
> speaking) works. But we may as a group might want to consider this at
> some point to build some efficiency into the ports part of the equation.
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
>
signature.asc
Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Sat Apr 6 09:34:26 2019 > New Revision: 345982 > URL: https://svnweb.freebsd.org/changeset/base/345982 > > Log: > Introduce funlinkat syscall that always us to check if we are removing > the file associated with the given file descriptor. > > Reviewed by:kib, asomers > Reviewed by:cem, jilles, brooks (they reviewed previous version) > Discussed with: pjd, and many others > Differential Revision: https://reviews.freebsd.org/D14567 Hey Mariusz, Is __FreeBSD_version supposed to be bumped after adding new syscalls? I can't remember off-hand. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
Grimes"
writes:
> > On April 7, 2019 7:11:52 AM PDT, Shawn Webb wr
> ote:
> > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > >> Author: oshogbo
> > >> Date: Sat Apr 6 09:34:26 2019
> > >> New Revision: 345982
> > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > >>
> > >> Log:
> > >> Introduce funlinkat syscall that always us to check if we are
> > >removing
> > >> the file associated with the given file descriptor.
> > >>
> > >> Reviewed by: kib, asomers
> > >> Reviewed by: cem, jilles, brooks (they reviewed previous version)
> > >> Discussed with:pjd, and many others
> > >> Differential Revision: https://reviews.freebsd.org/D14567
> > >
> > >Hey Mariusz,
> > >
> > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > >I can't remember off-hand.
> > >
> > >Thanks,
> >
> > I don't think so. Why force the rebuild of all ports through poudriere over
> something that would never affect any of them?
>
> So that you can if version >= foo to know it is safe to use the new syscal?
> Or if version < foo you must use the old way.
Granted. However we do need something to avoid gratuitous rebuilds of
ports.
Personally, my poudriere script adjusts the pkg version
($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
that of the jail version (reported by poudriere jail -i -j $JAIL),
rebuilding all ports when I (the human) determines when the machine
should rebuild all ports with -c.
In that regard FreeBSD version bumps occasionally seem a little
gratuitous. Using the same indicator to tell whether software should be
able to use a new feature and when ports build infrastructure should
summarily delete all packages forcing a rebuild of absolutely
everything is probably not the best.
Just throwing out an idea, what if poudriere considers the first N
bytes of __FreeBSD_version significant? Having said that, looking at
__FreeBSD_version, I don't think we have enough digits to do what I was
planning on suggesting. But, you get the idea of what I'm driving at.
Maybe a new macro such as __FreeBSD_ports that is incremented every
time a change that affects ports?
Anyhow, I'm not too terribly concerned as what I have (selfishly
speaking) works. But we may as a group might want to consider this at
some point to build some efficiency into the ports part of the equation.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In message
, Warner Losh writes:
> --5c05ef0585f2f684
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert
> wrote:
>
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb <
> > shawn.w...@hardenedbsd.org> wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
>
> We generally bump the version around the time we add a syscall. This allows
> any wrappers to call it or not based on the kernel version and avoid a
> SIGSYS when we're doing forward compatibility hacks for whatever reason.
>
> The current overloading of __FreeBSD_version is unfortunate. We've been
> quite liberal over the past 2 decades at bumping it because it's free to do
> so. Or so the thinking has been. I personally think we should continue to
> do so, but maybe look at piggy-backing those changes we can if someone else
> bumped it in the last few days. To give some perspective, in the ~120 days
> since we branched, we've bumped it 17 times. This is more or less weekly,
> which suggests we don't have a problem that we need to optimize too much
> here.
>
> If Poudriere wants to optimize building, I'd suggest that you have a
> command line argument / config file thing that sets the maximum skew.
> Normally, you could set it up to be pretty tolerant, but if you knew
> something was a big deal, you could then crank down to intolerant. The
> current setting of '1' for this skew should be the default.
It's not that simple. A skew may miss an important change to base that
will affect ports. Having resulting packages that segfault could be
unacceptable outcome. An argument to ignore the jail/pkg version
comparison or arbitrarily update it (like my script does) would solve
this.
However someone not monitoring base commit log commits, an arbitrary
argument to poudriere could result in unnecessary mailing list noise or
bugzilla tickets, both of which are time wasters.
>
> I'm not sure a FreeBSD_ports would scale. How do you know a port won't need
> to know about the new syscall? It's from Linux, and there may be some ports
> that use it if available. As a src committer, I've not easy way to know
> (and no hard way to know that's not a full exprun).
That's the other problem. Not everyone will know how a change may
affect applications. I suppose the best might be a poudriere flag or
config option to ignore jail and pkg version differences
svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
Author: oshogbo
Date: Sat Apr 6 09:34:26 2019
New Revision: 345982
URL: https://svnweb.freebsd.org/changeset/base/345982
Log:
Introduce funlinkat syscall that always us to check if we are removing
the file associated with the given file descriptor.
Reviewed by: kib, asomers
Reviewed by: cem, jilles, brooks (they reviewed previous version)
Discussed with: pjd, and many others
Differential Revision:https://reviews.freebsd.org/D14567
Modified:
head/include/unistd.h
head/lib/libc/sys/Makefile.inc
head/lib/libc/sys/Symbol.map
head/lib/libc/sys/unlink.2
head/sys/cddl/compat/opensolaris/sys/vnode.h
head/sys/compat/cloudabi/cloudabi_file.c
head/sys/compat/freebsd32/syscalls.master
head/sys/compat/linux/linux_file.c
head/sys/kern/capabilities.conf
head/sys/kern/syscalls.master
head/sys/kern/vfs_mountroot.c
head/sys/kern/vfs_syscalls.c
head/sys/sys/fcntl.h
head/sys/sys/syscallsubr.h
head/sys/ufs/ffs/ffs_alloc.c
Modified: head/include/unistd.h
==
--- head/include/unistd.h Sat Apr 6 09:00:06 2019(r345981)
+++ head/include/unistd.h Sat Apr 6 09:34:26 2019(r345982)
@@ -585,6 +585,7 @@ off_t__syscall(quad_t, ...);
int undelete(const char *);
int unwhiteout(const char *);
void *valloc(size_t);/* obsoleted by malloc() */
+int funlinkat(int, const char *, int, int);
#ifndef _OPTRESET_DECLARED
#define_OPTRESET_DECLARED
Modified: head/lib/libc/sys/Makefile.inc
==
--- head/lib/libc/sys/Makefile.inc Sat Apr 6 09:00:06 2019
(r345981)
+++ head/lib/libc/sys/Makefile.inc Sat Apr 6 09:34:26 2019
(r345982)
@@ -485,6 +485,7 @@ MLINKS+=timer_settime.2 timer_getoverrun.2 \
MLINKS+=thr_kill.2 thr_kill2.2
MLINKS+=truncate.2 ftruncate.2
MLINKS+=unlink.2 unlinkat.2
+MLINKS+=unlink.2 funlinkat.2
MLINKS+=utimensat.2 futimens.2
MLINKS+=utimes.2 futimes.2 \
utimes.2 futimesat.2 \
Modified: head/lib/libc/sys/Symbol.map
==
--- head/lib/libc/sys/Symbol.mapSat Apr 6 09:00:06 2019
(r345981)
+++ head/lib/libc/sys/Symbol.mapSat Apr 6 09:34:26 2019
(r345982)
@@ -406,6 +406,7 @@ FBSD_1.6 {
fhlinkat;
fhreadlink;
getfhat;
+ funlinkat;
};
FBSDprivate_1.0 {
Modified: head/lib/libc/sys/unlink.2
==
--- head/lib/libc/sys/unlink.2 Sat Apr 6 09:00:06 2019(r345981)
+++ head/lib/libc/sys/unlink.2 Sat Apr 6 09:34:26 2019(r345982)
@@ -28,7 +28,7 @@
.\" @(#)unlink.2 8.1 (Berkeley) 6/4/93
.\" $FreeBSD$
.\"
-.Dd November 11, 2018
+.Dd April 6, 2019
.Dt UNLINK 2
.Os
.Sh NAME
@@ -42,7 +42,9 @@
.Ft int
.Fn unlink "const char *path"
.Ft int
-.Fn unlinkat "int fd" "const char *path" "int flag"
+.Fn unlinkat "int dfd" "const char *path" "int flag"
+.Ft int
+.Fn funlinkat "int dfd" "const char *path" "int fd" "int flag"
.Sh DESCRIPTION
The
.Fn unlink
@@ -74,7 +76,7 @@ except in the case where
specifies a relative path.
In this case the directory entry to be removed is determined
relative to the directory associated with the file descriptor
-.Fa fd
+.Fa dfd
instead of the current working directory.
.Pp
The values for
@@ -113,6 +115,26 @@ or
respectively, depending on whether or not the
.Dv AT_REMOVEDIR
bit is set in flag.
+.Pp
+The
+.Fn funlinkat
+system call can be used to unlink an already-opened file, unless that
+file has been replaced since it was opened.
+It is equivalent to
+.Fn unlinkat
+in the case where
+.Fa path
+is already open as the file descriptor
+.Fa fd .
+Otherwise, the path will not be removed and an error will be returned.
+The
+.Fa fd
+can be set the
+.Dv FD_NONE .
+In that case
+.Fn funlinkat
+behaves exactly like
+.Fn unlinkat .
.Sh RETURN VALUES
.Rv -std unlink
.Sh ERRORS
@@ -227,6 +249,15 @@ or the relative
.Fa path
escapes it.
.El
+.Pp
+In addition to the errors returned by
+.Fn unlinkat ,
+.Fn funlinkat
+may fail if:
+.Bl -tag -width Er
+.It Bq Er EDEADLK
+The file descriptor is not associated with the path.
+.El
.Sh SEE ALSO
.Xr chflags 2 ,
.Xr close 2 ,
@@ -246,6 +277,10 @@ The
.Fn unlinkat
system call appeared in
.Fx 8.0 .
+The
+.Fn funlinkat
+system call appeared in
+.Fx 13.0 .
.Pp
The
.Fn unlink
Modified: head/sys/cddl/compat/opensolaris/sys/vnode.h
==
--- head/sys/cddl/compat/opensolaris/sys/vnode.hSat Apr 6 09:00:06
2019(r345981)
+++ head/sys/cddl/compat/opensolaris/sys/vnode.hSat Apr 6 09:34:26
2019(r345982)
@@ -278,7 +278,8 @@ vn_remove(char *fnamep, enum uio_seg seg, enum rm dirf
ASSERT(seg ==
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
No worries. Thanks for the correction!
--
Shawn Webb
Cofounder / Security Engineer
HardenedBSD
Tor-ified Signal:+1 443-546-8752
Tor+XMPP+OTR:latt...@is.a.hacker.sx
GPG Key ID: 0x6A84658F52456EEE
GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2
On Sun, Apr 07, 2019 at 06:11:58PM +0200, Mariusz Zaborski wrote:
> In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to
> bump
> __FreeBSD_version. I confirmed that with Warner. So this was my mistake.
>
> Thanks Shawn.
> --
> Mariusz Zaborski
> oshogbo//vx | http://oshogbo.vexillium.org
> FreeBSD committer | https://freebsd.org
> Software developer| http://wheelsystems.com
> If it's not broken, let's fix it till it is!!1
>
> On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > > wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > > > >> version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > > > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
> >
> > --
> > Cheers,
> > Cy Schubert
> > FreeBSD UNIX: Web: http://www.FreeBSD.org
> >
> > The need of the many outweighs the greed of the few.
> >
> >
signature.asc
Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In message
, Warner Losh writes:
> --5c05ef0585f2f684
> Content-Type: text/plain; charset="UTF-8"
>
> On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert
> wrote:
>
> > In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> > Grimes"
> > writes:
> > > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb <
> > shawn.w...@hardenedbsd.org> wr
> > > ote:
> > > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > > >> Author: oshogbo
> > > > >> Date: Sat Apr 6 09:34:26 2019
> > > > >> New Revision: 345982
> > > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > > >>
> > > > >> Log:
> > > > >> Introduce funlinkat syscall that always us to check if we are
> > > > >removing
> > > > >> the file associated with the given file descriptor.
> > > > >>
> > > > >> Reviewed by: kib, asomers
> > > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> > version)
> > > > >> Discussed with:pjd, and many others
> > > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > > >
> > > > >Hey Mariusz,
> > > > >
> > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > > >I can't remember off-hand.
> > > > >
> > > > >Thanks,
> > > >
> > > > I don't think so. Why force the rebuild of all ports through poudriere
> > over
> > > something that would never affect any of them?
> > >
> > > So that you can if version >= foo to know it is safe to use the new
> > syscal?
> > > Or if version < foo you must use the old way.
> >
> > Granted. However we do need something to avoid gratuitous rebuilds of
> > ports.
> >
> > Personally, my poudriere script adjusts the pkg version
> > ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> > that of the jail version (reported by poudriere jail -i -j $JAIL),
> > rebuilding all ports when I (the human) determines when the machine
> > should rebuild all ports with -c.
> >
> > In that regard FreeBSD version bumps occasionally seem a little
> > gratuitous. Using the same indicator to tell whether software should be
> > able to use a new feature and when ports build infrastructure should
> > summarily delete all packages forcing a rebuild of absolutely
> > everything is probably not the best.
> >
> > Just throwing out an idea, what if poudriere considers the first N
> > bytes of __FreeBSD_version significant? Having said that, looking at
> > __FreeBSD_version, I don't think we have enough digits to do what I was
> > planning on suggesting. But, you get the idea of what I'm driving at.
> > Maybe a new macro such as __FreeBSD_ports that is incremented every
> > time a change that affects ports?
> >
> > Anyhow, I'm not too terribly concerned as what I have (selfishly
> > speaking) works. But we may as a group might want to consider this at
> > some point to build some efficiency into the ports part of the equation.
> >
>
> We generally bump the version around the time we add a syscall. This allows
> any wrappers to call it or not based on the kernel version and avoid a
> SIGSYS when we're doing forward compatibility hacks for whatever reason.
>
> The current overloading of __FreeBSD_version is unfortunate. We've been
> quite liberal over the past 2 decades at bumping it because it's free to do
> so. Or so the thinking has been. I personally think we should continue to
> do so, but maybe look at piggy-backing those changes we can if someone else
> bumped it in the last few days. To give some perspective, in the ~120 days
> since we branched, we've bumped it 17 times. This is more or less weekly,
> which suggests we don't have a problem that we need to optimize too much
> here.
>
> If Poudriere wants to optimize building, I'd suggest that you have a
> command line argument / config file thing that sets the maximum skew.
> Normally, you could set it up to be pretty tolerant, but if you knew
> something was a big deal, you could then crank down to intolerant. The
> current setting of '1' for this skew should be the default.
It's not that simple. A skew may miss an important change to base that
will affect ports. Having resulting packages that segfault could be
unacceptable outcome. An argument to ignore the jail/pkg version
comparison or arbitrarily update it (like my script does) would solve
this.
However someone not monitoring base commit log commits, an arbitrary
argument to poudriere could result in unnecessary mailing list noise or
bugzilla tickets, both of which are time wasters.
>
> I'm not sure a FreeBSD_ports would scale. How do you know a port won't need
> to know about the new syscall? It's from Linux, and there may be some ports
> that use it if available. As a src committer, I've not easy way to know
> (and no hard way to know that's not a full exprun).
That's the other problem. Not everyone will know how a change may
affect applications. I suppose the best might be a poudriere flag or
config option to ignore jail and pkg version differences
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In the https://wiki.freebsd.org/AddingSyscalls we mentions that we need to bump
__FreeBSD_version. I confirmed that with Warner. So this was my mistake.
Thanks Shawn.
--
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer | https://freebsd.org
Software developer | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1
On Sun, Apr 07, 2019 at 08:35:07AM -0700, Cy Schubert wrote:
> In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb
> > > wr
> > ote:
> > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > >> Author: oshogbo
> > > >> Date: Sat Apr 6 09:34:26 2019
> > > >> New Revision: 345982
> > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > >>
> > > >> Log:
> > > >> Introduce funlinkat syscall that always us to check if we are
> > > >removing
> > > >> the file associated with the given file descriptor.
> > > >>
> > > >> Reviewed by: kib, asomers
> > > >> Reviewed by: cem, jilles, brooks (they reviewed previous version)
> > > >> Discussed with: pjd, and many others
> > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > >
> > > >Hey Mariusz,
> > > >
> > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > >I can't remember off-hand.
> > > >
> > > >Thanks,
> > >
> > > I don't think so. Why force the rebuild of all ports through poudriere
> > > over
> > something that would never affect any of them?
> >
> > So that you can if version >= foo to know it is safe to use the new syscal?
> > Or if version < foo you must use the old way.
>
> Granted. However we do need something to avoid gratuitous rebuilds of
> ports.
>
> Personally, my poudriere script adjusts the pkg version
> ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> that of the jail version (reported by poudriere jail -i -j $JAIL),
> rebuilding all ports when I (the human) determines when the machine
> should rebuild all ports with -c.
>
> In that regard FreeBSD version bumps occasionally seem a little
> gratuitous. Using the same indicator to tell whether software should be
> able to use a new feature and when ports build infrastructure should
> summarily delete all packages forcing a rebuild of absolutely
> everything is probably not the best.
>
> Just throwing out an idea, what if poudriere considers the first N
> bytes of __FreeBSD_version significant? Having said that, looking at
> __FreeBSD_version, I don't think we have enough digits to do what I was
> planning on suggesting. But, you get the idea of what I'm driving at.
> Maybe a new macro such as __FreeBSD_ports that is incremented every
> time a change that affects ports?
>
> Anyhow, I'm not too terribly concerned as what I have (selfishly
> speaking) works. But we may as a group might want to consider this at
> some point to build some efficiency into the ports part of the equation.
>
>
> --
> Cheers,
> Cy Schubert
> FreeBSD UNIX: Web: http://www.FreeBSD.org
>
> The need of the many outweighs the greed of the few.
>
>
signature.asc
Description: PGP signature
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sun, Apr 7, 2019 at 9:35 AM Cy Schubert
wrote:
> In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
> Grimes"
> writes:
> > > On April 7, 2019 7:11:52 AM PDT, Shawn Webb <
> shawn.w...@hardenedbsd.org> wr
> > ote:
> > > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > > >> Author: oshogbo
> > > >> Date: Sat Apr 6 09:34:26 2019
> > > >> New Revision: 345982
> > > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > > >>
> > > >> Log:
> > > >> Introduce funlinkat syscall that always us to check if we are
> > > >removing
> > > >> the file associated with the given file descriptor.
> > > >>
> > > >> Reviewed by: kib, asomers
> > > >> Reviewed by: cem, jilles, brooks (they reviewed previous
> version)
> > > >> Discussed with:pjd, and many others
> > > >> Differential Revision: https://reviews.freebsd.org/D14567
> > > >
> > > >Hey Mariusz,
> > > >
> > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > > >I can't remember off-hand.
> > > >
> > > >Thanks,
> > >
> > > I don't think so. Why force the rebuild of all ports through poudriere
> over
> > something that would never affect any of them?
> >
> > So that you can if version >= foo to know it is safe to use the new
> syscal?
> > Or if version < foo you must use the old way.
>
> Granted. However we do need something to avoid gratuitous rebuilds of
> ports.
>
> Personally, my poudriere script adjusts the pkg version
> ($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
> that of the jail version (reported by poudriere jail -i -j $JAIL),
> rebuilding all ports when I (the human) determines when the machine
> should rebuild all ports with -c.
>
> In that regard FreeBSD version bumps occasionally seem a little
> gratuitous. Using the same indicator to tell whether software should be
> able to use a new feature and when ports build infrastructure should
> summarily delete all packages forcing a rebuild of absolutely
> everything is probably not the best.
>
> Just throwing out an idea, what if poudriere considers the first N
> bytes of __FreeBSD_version significant? Having said that, looking at
> __FreeBSD_version, I don't think we have enough digits to do what I was
> planning on suggesting. But, you get the idea of what I'm driving at.
> Maybe a new macro such as __FreeBSD_ports that is incremented every
> time a change that affects ports?
>
> Anyhow, I'm not too terribly concerned as what I have (selfishly
> speaking) works. But we may as a group might want to consider this at
> some point to build some efficiency into the ports part of the equation.
>
We generally bump the version around the time we add a syscall. This allows
any wrappers to call it or not based on the kernel version and avoid a
SIGSYS when we're doing forward compatibility hacks for whatever reason.
The current overloading of __FreeBSD_version is unfortunate. We've been
quite liberal over the past 2 decades at bumping it because it's free to do
so. Or so the thinking has been. I personally think we should continue to
do so, but maybe look at piggy-backing those changes we can if someone else
bumped it in the last few days. To give some perspective, in the ~120 days
since we branched, we've bumped it 17 times. This is more or less weekly,
which suggests we don't have a problem that we need to optimize too much
here.
If Poudriere wants to optimize building, I'd suggest that you have a
command line argument / config file thing that sets the maximum skew.
Normally, you could set it up to be pretty tolerant, but if you knew
something was a big deal, you could then crank down to intolerant. The
current setting of '1' for this skew should be the default.
I'm not sure a FreeBSD_ports would scale. How do you know a port won't need
to know about the new syscall? It's from Linux, and there may be some ports
that use it if available. As a src committer, I've not easy way to know
(and no hard way to know that's not a full exprun).
Warner
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
In message <201904071510.x37fa7tm050...@gndrsh.dnsmgr.net>, "Rodney W.
Grimes"
writes:
> > On April 7, 2019 7:11:52 AM PDT, Shawn Webb wr
> ote:
> > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote:
> > >> Author: oshogbo
> > >> Date: Sat Apr 6 09:34:26 2019
> > >> New Revision: 345982
> > >> URL: https://svnweb.freebsd.org/changeset/base/345982
> > >>
> > >> Log:
> > >> Introduce funlinkat syscall that always us to check if we are
> > >removing
> > >> the file associated with the given file descriptor.
> > >>
> > >> Reviewed by: kib, asomers
> > >> Reviewed by: cem, jilles, brooks (they reviewed previous version)
> > >> Discussed with:pjd, and many others
> > >> Differential Revision: https://reviews.freebsd.org/D14567
> > >
> > >Hey Mariusz,
> > >
> > >Is __FreeBSD_version supposed to be bumped after adding new syscalls?
> > >I can't remember off-hand.
> > >
> > >Thanks,
> >
> > I don't think so. Why force the rebuild of all ports through poudriere over
> something that would never affect any of them?
>
> So that you can if version >= foo to know it is safe to use the new syscal?
> Or if version < foo you must use the old way.
Granted. However we do need something to avoid gratuitous rebuilds of
ports.
Personally, my poudriere script adjusts the pkg version
($JAILPATH/data/packages/${JAIL}-${PORTS}/.building/.jailversion) with
that of the jail version (reported by poudriere jail -i -j $JAIL),
rebuilding all ports when I (the human) determines when the machine
should rebuild all ports with -c.
In that regard FreeBSD version bumps occasionally seem a little
gratuitous. Using the same indicator to tell whether software should be
able to use a new feature and when ports build infrastructure should
summarily delete all packages forcing a rebuild of absolutely
everything is probably not the best.
Just throwing out an idea, what if poudriere considers the first N
bytes of __FreeBSD_version significant? Having said that, looking at
__FreeBSD_version, I don't think we have enough digits to do what I was
planning on suggesting. But, you get the idea of what I'm driving at.
Maybe a new macro such as __FreeBSD_ports that is incremented every
time a change that affects ports?
Anyhow, I'm not too terribly concerned as what I have (selfishly
speaking) works. But we may as a group might want to consider this at
some point to build some efficiency into the ports part of the equation.
--
Cheers,
Cy Schubert
FreeBSD UNIX: Web: http://www.FreeBSD.org
The need of the many outweighs the greed of the few.
___
svn-src-all@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-all
To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
> On April 7, 2019 7:11:52 AM PDT, Shawn Webb > wrote: > >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > >> Author: oshogbo > >> Date: Sat Apr 6 09:34:26 2019 > >> New Revision: 345982 > >> URL: https://svnweb.freebsd.org/changeset/base/345982 > >> > >> Log: > >> Introduce funlinkat syscall that always us to check if we are > >removing > >> the file associated with the given file descriptor. > >> > >> Reviewed by: kib, asomers > >> Reviewed by: cem, jilles, brooks (they reviewed previous version) > >> Discussed with: pjd, and many others > >> Differential Revision: https://reviews.freebsd.org/D14567 > > > >Hey Mariusz, > > > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? > >I can't remember off-hand. > > > >Thanks, > > I don't think so. Why force the rebuild of all ports through poudriere over > something that would never affect any of them? So that you can if version >= foo to know it is safe to use the new syscal? Or if version < foo you must use the old way. -- Rod Grimes rgri...@freebsd.org ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On April 7, 2019 7:11:52 AM PDT, Shawn Webb wrote: >On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: >> Author: oshogbo >> Date: Sat Apr 6 09:34:26 2019 >> New Revision: 345982 >> URL: https://svnweb.freebsd.org/changeset/base/345982 >> >> Log: >> Introduce funlinkat syscall that always us to check if we are >removing >> the file associated with the given file descriptor. >> >> Reviewed by: kib, asomers >> Reviewed by: cem, jilles, brooks (they reviewed previous version) >> Discussed with:pjd, and many others >> Differential Revision: https://reviews.freebsd.org/D14567 > >Hey Mariusz, > >Is __FreeBSD_version supposed to be bumped after adding new syscalls? >I can't remember off-hand. > >Thanks, I don't think so. Why force the rebuild of all ports through poudriere over something that would never affect any of them? -- Pardon the typos and autocorrect, small keyboard in use. Cheers, Cy Schubert FreeBSD UNIX: Web: http://www.FreeBSD.org The need of the many outweighs the greed of the few. ___ svn-src-all@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-all To unsubscribe, send any mail to "svn-src-all-unsubscr...@freebsd.org"
Re: svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
On Sat, Apr 06, 2019 at 09:34:26AM +, Mariusz Zaborski wrote: > Author: oshogbo > Date: Sat Apr 6 09:34:26 2019 > New Revision: 345982 > URL: https://svnweb.freebsd.org/changeset/base/345982 > > Log: > Introduce funlinkat syscall that always us to check if we are removing > the file associated with the given file descriptor. > > Reviewed by:kib, asomers > Reviewed by:cem, jilles, brooks (they reviewed previous version) > Discussed with: pjd, and many others > Differential Revision: https://reviews.freebsd.org/D14567 Hey Mariusz, Is __FreeBSD_version supposed to be bumped after adding new syscalls? I can't remember off-hand. Thanks, -- Shawn Webb Cofounder / Security Engineer HardenedBSD Tor-ified Signal:+1 443-546-8752 Tor+XMPP+OTR:latt...@is.a.hacker.sx GPG Key ID: 0x6A84658F52456EEE GPG Key Fingerprint: D206 BB45 15E0 9C49 0CF9 3633 C85B 0AF8 AB23 0FB2 signature.asc Description: PGP signature
svn commit: r345982 - in head: include lib/libc/sys sys/cddl/compat/opensolaris/sys sys/compat/cloudabi sys/compat/freebsd32 sys/compat/linux sys/kern sys/sys sys/ufs/ffs
Author: oshogbo
Date: Sat Apr 6 09:34:26 2019
New Revision: 345982
URL: https://svnweb.freebsd.org/changeset/base/345982
Log:
Introduce funlinkat syscall that always us to check if we are removing
the file associated with the given file descriptor.
Reviewed by: kib, asomers
Reviewed by: cem, jilles, brooks (they reviewed previous version)
Discussed with: pjd, and many others
Differential Revision:https://reviews.freebsd.org/D14567
Modified:
head/include/unistd.h
head/lib/libc/sys/Makefile.inc
head/lib/libc/sys/Symbol.map
head/lib/libc/sys/unlink.2
head/sys/cddl/compat/opensolaris/sys/vnode.h
head/sys/compat/cloudabi/cloudabi_file.c
head/sys/compat/freebsd32/syscalls.master
head/sys/compat/linux/linux_file.c
head/sys/kern/capabilities.conf
head/sys/kern/syscalls.master
head/sys/kern/vfs_mountroot.c
head/sys/kern/vfs_syscalls.c
head/sys/sys/fcntl.h
head/sys/sys/syscallsubr.h
head/sys/ufs/ffs/ffs_alloc.c
Modified: head/include/unistd.h
==
--- head/include/unistd.h Sat Apr 6 09:00:06 2019(r345981)
+++ head/include/unistd.h Sat Apr 6 09:34:26 2019(r345982)
@@ -585,6 +585,7 @@ off_t__syscall(quad_t, ...);
int undelete(const char *);
int unwhiteout(const char *);
void *valloc(size_t);/* obsoleted by malloc() */
+int funlinkat(int, const char *, int, int);
#ifndef _OPTRESET_DECLARED
#define_OPTRESET_DECLARED
Modified: head/lib/libc/sys/Makefile.inc
==
--- head/lib/libc/sys/Makefile.inc Sat Apr 6 09:00:06 2019
(r345981)
+++ head/lib/libc/sys/Makefile.inc Sat Apr 6 09:34:26 2019
(r345982)
@@ -485,6 +485,7 @@ MLINKS+=timer_settime.2 timer_getoverrun.2 \
MLINKS+=thr_kill.2 thr_kill2.2
MLINKS+=truncate.2 ftruncate.2
MLINKS+=unlink.2 unlinkat.2
+MLINKS+=unlink.2 funlinkat.2
MLINKS+=utimensat.2 futimens.2
MLINKS+=utimes.2 futimes.2 \
utimes.2 futimesat.2 \
Modified: head/lib/libc/sys/Symbol.map
==
--- head/lib/libc/sys/Symbol.mapSat Apr 6 09:00:06 2019
(r345981)
+++ head/lib/libc/sys/Symbol.mapSat Apr 6 09:34:26 2019
(r345982)
@@ -406,6 +406,7 @@ FBSD_1.6 {
fhlinkat;
fhreadlink;
getfhat;
+ funlinkat;
};
FBSDprivate_1.0 {
Modified: head/lib/libc/sys/unlink.2
==
--- head/lib/libc/sys/unlink.2 Sat Apr 6 09:00:06 2019(r345981)
+++ head/lib/libc/sys/unlink.2 Sat Apr 6 09:34:26 2019(r345982)
@@ -28,7 +28,7 @@
.\" @(#)unlink.2 8.1 (Berkeley) 6/4/93
.\" $FreeBSD$
.\"
-.Dd November 11, 2018
+.Dd April 6, 2019
.Dt UNLINK 2
.Os
.Sh NAME
@@ -42,7 +42,9 @@
.Ft int
.Fn unlink "const char *path"
.Ft int
-.Fn unlinkat "int fd" "const char *path" "int flag"
+.Fn unlinkat "int dfd" "const char *path" "int flag"
+.Ft int
+.Fn funlinkat "int dfd" "const char *path" "int fd" "int flag"
.Sh DESCRIPTION
The
.Fn unlink
@@ -74,7 +76,7 @@ except in the case where
specifies a relative path.
In this case the directory entry to be removed is determined
relative to the directory associated with the file descriptor
-.Fa fd
+.Fa dfd
instead of the current working directory.
.Pp
The values for
@@ -113,6 +115,26 @@ or
respectively, depending on whether or not the
.Dv AT_REMOVEDIR
bit is set in flag.
+.Pp
+The
+.Fn funlinkat
+system call can be used to unlink an already-opened file, unless that
+file has been replaced since it was opened.
+It is equivalent to
+.Fn unlinkat
+in the case where
+.Fa path
+is already open as the file descriptor
+.Fa fd .
+Otherwise, the path will not be removed and an error will be returned.
+The
+.Fa fd
+can be set the
+.Dv FD_NONE .
+In that case
+.Fn funlinkat
+behaves exactly like
+.Fn unlinkat .
.Sh RETURN VALUES
.Rv -std unlink
.Sh ERRORS
@@ -227,6 +249,15 @@ or the relative
.Fa path
escapes it.
.El
+.Pp
+In addition to the errors returned by
+.Fn unlinkat ,
+.Fn funlinkat
+may fail if:
+.Bl -tag -width Er
+.It Bq Er EDEADLK
+The file descriptor is not associated with the path.
+.El
.Sh SEE ALSO
.Xr chflags 2 ,
.Xr close 2 ,
@@ -246,6 +277,10 @@ The
.Fn unlinkat
system call appeared in
.Fx 8.0 .
+The
+.Fn funlinkat
+system call appeared in
+.Fx 13.0 .
.Pp
The
.Fn unlink
Modified: head/sys/cddl/compat/opensolaris/sys/vnode.h
==
--- head/sys/cddl/compat/opensolaris/sys/vnode.hSat Apr 6 09:00:06
2019(r345981)
+++ head/sys/cddl/compat/opensolaris/sys/vnode.hSat Apr 6 09:34:26
2019(r345982)
@@ -278,7 +278,8 @@ vn_remove(char *fnamep, enum uio_seg seg, enum rm dirf
ASSERT(seg ==
