FreeBSD_HEAD_i386 - Build #592 - Fixed
FreeBSD_HEAD_i386 - Build #592 - Fixed: Build information: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/ Full change log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/changes Full build log: https://jenkins.FreeBSD.org/job/FreeBSD_HEAD_i386/592/console Change summaries: 285622 by ed: Implement CloudABI's exec() call. Summary: In a runtime that is purely based on capability-based security, there is a strong emphasis on how programs start their execution. We need to make sure that we execute an new program with an exact set of file descriptors, ensuring that credentials are not leaked into the process accidentally. Providing the right file descriptors is just half the problem. There also needs to be a framework in place that gives meaning to these file descriptors. How does a CloudABI mail server know which of the file descriptors corresponds to the socket that receives incoming emails? Furthermore, how will this mail server acquire its configuration parameters, as it cannot open a configuration file from a global path on disk? CloudABI solves this problem by replacing traditional string command line arguments by tree-like data structure consisting of scalars, sequences and mappings (similar to YAML/JSON). In this structure, file descriptors are treated as a first-class citizen. When calling exec(), file descriptors are passed on to the new executable if and only if they are referenced from this tree structure. See the cloudabi-run(1) man page for more details and examples (sysutils/cloudabi-utils). Fortunately, the kernel does not need to care about this tree structure at all. The C library is responsible for serializing and deserializing, but also for extracting the list of referenced file descriptors. The system call only receives a copy of the serialized data and a layout of what the new file descriptor table should look like: int proc_exec(int execfd, const void *data, size_t datalen, const int *fds, size_t fdslen); This change introduces a set of fd*_remapped() functions: - fdcopy_remapped() pulls a copy of a file descriptor table, remapping all of the file descriptors according to the provided mapping table. - fdinstall_remapped() replaces the file descriptor table of the process by the copy created by fdcopy_remapped(). - fdescfree_remapped() frees the table in case we aborted before fdinstall_remapped(). We then add a function exec_copyin_data_fds() that builds on top these functions. It copies in the data and constructs a new remapped file descriptor. This is used by cloudabi_sys_proc_exec(). Test Plan: cloudabi-run(1) is capable of spawning processes successfully, providing it data and file descriptors. procstat -f seems to confirm all is good. Regular FreeBSD processes also work properly. Reviewers: kib, mjg Reviewed By: mjg Subscribers: imp Differential Revision: https://reviews.freebsd.org/D3079 ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
-current broken when src is on NFS
I am seeing the following breakage when building -current and the source is on
NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl -DWITH_INET6
-DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers -Werror -Wall
-Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-enum-conversion -Wno-unused-local-typedef -Wno-switch -Wno-switch-enum
-Wno-knr-promoted-parameter -Qunused-arguments -c
/src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o. Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
Daniel O'Conner wrote:
I am seeing the following breakage when building -current and the source is
on NFS
make -j 4 buildworld
...
--- rescue.all__D ---
--- rescue ---
MAKEOBJDIRPREFIX=/usr/obj/src/FreeBSD-HEAD/rescue/rescue make -f rescue.mk
exe
--- sbin.all__D ---
--- pfctl_qstats.o ---
cc -O2 -pipe -Wall -Wmissing-prototypes -Wno-uninitialized
-Wstrict-prototypes -DENABLE_ALTQ -I/src/FreeBSD-HEAD/sbin/pfctl
-DWITH_INET6 -DWITH_INET -std=gnu99 -fstack-protector -Wsystem-headers
-Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable
-Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality
-Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef
-Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments
-c /src/FreeBSD-HEAD/sbin/pfctl/pfctl_qstats.c -o pfctl_qstats.o
--- rescue.all__D ---
--- cat_stub.c ---
echo int _crunched_cat_stub(int argc, char **argv, char **envp){return
main(argc,argv,envp);} cat_stub.c
make[5]: make[5]: don't know how to make
/usr/obj/src/FreeBSD-HEAD/rescue/rescue//src/FreeBSD-HEAD/bin/cat/cat.o.
Stop
make[5]: stopped in /usr/obj/src/FreeBSD-HEAD/rescue/rescue
*** [rescue] Error code 2
r285066 fixed a POLA violation w.r.t. the old NFS client where the new
client didn't return an EEXIST error return for symlink or mkdir to userland.
The behaviour of not returning this error to userland (which was inherited from
OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default
for the new NFS client) can be enabled via:
vfs.nfs.ignore_eexist=1
You could try setting that sysctl and seeing if it makes any difference?
That is the only recent change to the NFS client that *might* affect this.
To be honest, I have no idea what the correct behaviour for // in a pathname
is?
rick
I copied this source tree to /usr/src (UFS) and it built fine - I guess it's
possible it is barfing on the path name but I figure someone else would have
noticed that.
The NFS server is running 10.0-RELEASE and the NFS client is running -current
r285456, lockd is running and seems to be working (e.g., cat -l works)
--
Daniel O'Connor
The nice thing about standards is that there
are so many of them to choose from.
-- Andrew Tanenbaum
GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: Why shoud we cause panic in scsi_da.c?
Subject: Re: Why shoud we cause panic in scsi_da.c?
Date: Tue, 14 Jul 2015 15:49:29 -0400
On Mon, Jul 13, 2015 at 18:29:36 +0300, Alexander Motin wrote:
Hi.
On 13.07.2015 11:51, Kohji Okuno wrote:
On 07/13/15 10:11, Kohji Okuno wrote:
Could you comment on my quesion?
I found panic() in scsi_da.c. Please find the following.
I think we should return with error without panic().
What do you think about this?
scsi_da.c:
3018} else if (bp != NULL) {
3019 if ((done_ccb-ccb_h.status CAM_DEV_QFRZN) != 0)
3020panic(REQ_CMP with QFRZN);
It looks to me more like an KASSERT() is appropriate here.
As I can see, this panic() call was added by ken@ about 15 years ago.
I've added him to CC in case he has some idea why it was done. From my
personal opinion I don't see much reasons to allow CAM_DEV_QFRZN to be
returned only together with error. While is may have little sense in
case of successful command completion, I don't think it should be
treated as error. Simply removing this panic is probably a bad idea,
since if it happens device will just remain frozen forever, that will be
will be difficult to diagnose, but I would better just dropped device
freeze in that case same as in case of completion with error.
I put it there because it indicates a software error. The queue shouldn't
be frozen if the command is successful. The reason for freezing the queue
is to allow error recovery to happen. The queue will get unfrozen after
error recovery completes.
We could alternately just print a diagnostic message, unfreeze the queue
and move on, but the idea is to allow the driver writer to detect and
correct his error immediately.
As for the original poster's problem, he has uncovered a bug that needs to
be fixed. (And I don't mean in the da(4) driver. The bug is in the
component that left the queue frozen. Most likely in the USB driver, but
it will take a little more investigation.) The panic worked as intended. :)
I don't know the reaseon. When I accessed the specified sector on the
specified HDD, I encounter the panic. But, I can access other sectors
on the same HDD. And, I can access all sectors on the other HDD (same
model).
Even if Ken's logic is correct, I think that we should do panic in
da(4) driver.
Best regards,
Kohji Okuno
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: -current broken when src is on NFS
On 16 Jul 2015, at 21:41, Rick Macklem rmack...@uoguelph.ca wrote: r285066 fixed a POLA violation w.r.t. the old NFS client where the new client didn't return an EEXIST error return for symlink or mkdir to userland. The behaviour of not returning this error to userland (which was inherited from OpenBSD and was not the behaviour of the old FreeBSD NFS client but was default for the new NFS client) can be enabled via: vfs.nfs.ignore_eexist=1 You could try setting that sysctl and seeing if it makes any difference? That is the only recent change to the NFS client that *might* affect this. No dice :( It's pretty weird, it bombs out if either src or obj is on NFS.. But even weirder is that if I build with crochet (a wrapper for cross building to arm) it works. It doesn't work if I cross build manually and I haven't been able to determine why crochet works yet. Relly frustraing :( To be honest, I have no idea what the correct behaviour for // in a pathname is? Nothing, they just get eaten. This isn't AmigaDOS! :) -- Daniel O'Connor The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum GPG Fingerprint - 5596 B766 97C0 0E94 4347 295E E593 DC20 7B3F CE8C ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
