Re: kernel modules into static kernel
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/07/19 20:50, Tim Judd wrote: > Hellos, > > > Of interest, I can get GEOM_UZIP kernel module as part of the kernel, > but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build > a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the > kernel? Yes. Cheers, - -- Xin LI http://www.delphij.net/ FreeBSD - The Power to Serve! Live free or die -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.15 (FreeBSD) iQEcBAEBCAAGBQJMRd0KAAoJEATO+BI/yjfB9EEH/38i8b0LdphAnpKEmKO0u1eU tCqM0LiSd8iJM3ZxilBvrIVofDXEqQW6PoDZ3m3KTRu39muZRqhRB1aVt3vbTCev xhDFEAgVrC0G16/JI9OE3h4Qtg0WT85Oyt/pZOTpzlaSXySByYyLHL2WbcC2FAMg t1R3ej35jqdmo2heSq3TnuRHQ6ykeqWqtHN18SMFrs+ywC6FYvgpR7rA2gsSa194 tiHEleR0IiBeklksHX38GPwWytYhgVwOAEdy+6JlFqcHAulFON47jjhq/9YAa6sq xAYBoJStnIVqIf4pjvzMzUrn07DUVbs9P4xbgJkTU0NXuuFvyaiH0VgzuU/zHt8= =Q7Yq -END PGP SIGNATURE- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: Missing files device_if.h and bus_if.h
On Sunday, July 18, 2010 1:40:58 am Christopher Bowman wrote: > Can a pci/pcie dirver be loaded and unloaded like a kld? Yes. Typically Makefiles for driver modules list 'driver_if.h' and 'bus_if.h' in their SRCS line and bsd.kmod.mk generates them during the build. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel modules into static kernel
On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: > Hellos, > > > Of interest, I can get GEOM_UZIP kernel module as part of the kernel, > but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build > a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the > kernel? Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for 'uzip' to see what GEOM_UZIP includes in the build). -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Chasing down bugs with access(2)
Hi Hackers, I ran into an issue last night where apparently several apps make faulty assumptions w.r.t. whether or not access(2) returns functional data when running as a superuser. POSIX says: In early proposals, some inadequacies in the access() function led to the creation of an eaccess() function because: 1. Historical implementations of access() do not test file access correctly when the process' real user ID is superuser. In particular, they always return zero when testing execute permissions without regard to whether the file is executable. 2. The superuser has complete access to all files on a system. As a consequence, programs started by the superuser and switched to the effective user ID with lesser privileges cannot use access() to test their file access permissions. However, the historical model of eaccess() does not resolve problem (1), so this volume of IEEE Std 1003.1-2001 now allows access() to behave in the desired way because several implementations have corrected the problem. It was also argued that problem (2) is more easily solved by using open(), chdir(), or one of the exec functions as appropriate and responding to the error, rather than creating a new function that would not be as reliable. Therefore, eaccess() is not included in this volume of IEEE Std 1003.1-2001. The sentence concerning appropriate privileges and execute permission bits reflects the two possibilities implemented by historical implementations when checking superuser access for X_OK. New implementations are discouraged from returning X_OK unless at least one execution permission bit is set. FreeBSD says: Even if a process's real or effective user has appropriate privileges and indicates success for X_OK, the file may not actually have execute per- mission bits set. Likewise for R_OK and W_OK. This results in: sh/test - ok-ish (a guy on bash-bugs challenged the fact that the syscall was buggy based on the details returned). bash - broken (builtin test(1) always returns true) csh - not really ok (uses whacky stat-like detection; doesn't check for ACLs, or MAC info) perl - ok (uses eaccess(2) for our OS). python - broken (uses straight access(2), so os.access is broken). So now the question is how to fix this? Linux reports the correct mode for the file (when operating as superuser or not), and there's a lot of code outside of *BSD that builds upon that assumption because stat(2) doesn't test for permissions via POSIX ACLs, MAC, etc. I tried munging through the code to determine where VOP_ACCESS was coming from but I got lost. Where should I look for this? Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: [PATCH] Catch errors with sigaddset(3) in sigaddset (sighold)
On Mon, Jul 19, 2010 at 5:09 AM, Kostik Belousov wrote:
> On Sun, Jul 18, 2010 at 10:46:25PM -0700, Garrett Cooper wrote:
>> sighold(3) doesn't determine whether or not the signal added is
>> valid today (and sigprocmask doesn't verify that either). This fixes
>> that.
>> Thanks,
>> -Garrett
>>
>> Index: sigcompat.c
>> ===
>> --- sigcompat.c (revision 210226)
>> +++ sigcompat.c (working copy)
>> @@ -131,7 +131,8 @@
>> sigset_t set;
>>
>> sigemptyset(&set);
>> - sigaddset(&set, sig);
>> + if (sigaddset(&set, sig) == -1)
>> + return (-1);
>> return (_sigprocmask(SIG_BLOCK, &set, NULL));
>> }
>
> I added checks for failures of sig{add,del}set to the sigcompat.c,
> and unified style to not assign intermediate error to local variable.
>
> This is what I am going to commit shortly.
>
> diff --git a/lib/libc/compat-43/sigcompat.c b/lib/libc/compat-43/sigcompat.c
> index 6841eeb..199846f 100644
> --- a/lib/libc/compat-43/sigcompat.c
> +++ b/lib/libc/compat-43/sigcompat.c
> @@ -112,16 +112,11 @@ int
> xsi_sigpause(int sig)
> {
> sigset_t set;
> - int error;
>
> - if (!_SIG_VALID(sig)) {
> - errno = EINVAL;
> + if (_sigprocmask(SIG_BLOCK, NULL, &set) == -1)
> + return (-1);
> + if (sigdelset(&set, sig) == -1)
> return (-1);
> - }
> - error = _sigprocmask(SIG_BLOCK, NULL, &set);
> - if (error != 0)
> - return (error);
> - sigdelset(&set, sig);
> return (_sigsuspend(&set));
> }
>
> @@ -131,7 +126,8 @@ sighold(int sig)
> sigset_t set;
>
> sigemptyset(&set);
> - sigaddset(&set, sig);
> + if (sigaddset(&set, sig) == -1)
> + return (-1);
> return (_sigprocmask(SIG_BLOCK, &set, NULL));
> }
>
> @@ -151,7 +147,8 @@ sigrelse(int sig)
> sigset_t set;
>
> sigemptyset(&set);
> - sigaddset(&set, sig);
> + if (sigaddset(&set, sig) == -1)
> + return (-1);
> return (_sigprocmask(SIG_UNBLOCK, &set, NULL));
> }
>
> @@ -160,35 +157,30 @@ void
> {
> sigset_t set, pset;
> struct sigaction sa, psa;
> - int error;
>
> sigemptyset(&set);
> - sigaddset(&set, sig);
> - error = _sigprocmask(SIG_BLOCK, NULL, &pset);
> - if (error == -1)
> + if (sigaddset(&set, sig) == -1)
> + return (SIG_ERR);
> + if (_sigprocmask(SIG_BLOCK, NULL, &pset) == -1)
> return (SIG_ERR);
> if ((__sighandler_t *)disp == SIG_HOLD) {
> - error = _sigprocmask(SIG_BLOCK, &set, &pset);
> - if (error == -1)
> + if (_sigprocmask(SIG_BLOCK, &set, &pset) == -1)
> return (SIG_ERR);
> if (sigismember(&pset, sig))
> return (SIG_HOLD);
> else {
> - error = _sigaction(sig, NULL, &psa);
> - if (error == -1)
> + if (_sigaction(sig, NULL, &psa) == -1)
> return (SIG_ERR);
> return (psa.sa_handler);
> }
> } else {
> - error = _sigprocmask(SIG_UNBLOCK, &set, &pset);
> - if (error == -1)
> + if (_sigprocmask(SIG_UNBLOCK, &set, &pset) == -1)
> return (SIG_ERR);
> }
>
> bzero(&sa, sizeof(sa));
> sa.sa_handler = disp;
> - error = _sigaction(sig, &sa, &psa);
> - if (error == -1)
> + if (_sigaction(sig, &sa, &psa) == -1)
> return (SIG_ERR);
> if (sigismember(&pset, sig))
> return (SIG_HOLD);
The results when I ran the tests manually outside of the shell
script were ok. I need to track down why they're failing in the script
itself.
Thanks,
-Garrett
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
Re: kernel modules into static kernel
On 7/20/10, John Baldwin wrote: > On Monday, July 19, 2010 11:50:37 pm Tim Judd wrote: >> Hellos, >> >> >> Of interest, I can get GEOM_UZIP kernel module as part of the kernel, >> but the GEOM_UZIP kernel module has a dependency on ZLIB. If I build >> a kernel with GEOM_UZIP, will the relavant ZLIB pieces also be in the >> kernel? > > Yes. GEOM_UZIP sucks in net/zlib.c (look at sys/conf/files and search for > 'uzip' to see what GEOM_UZIP includes in the build). > > -- > John Baldwin > Extremely appreciated. Thanks John ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
