On Tue, Feb 12, 2008 at 11:51:19AM -0800, Xin LI wrote:
[..]
>
> Hi,
>
> Is there anyone working on valgrind on newer FreeBSD releases, or some
> work-alikes?
>
> Cheers,
Yes, check out the //depot/projects/valgrind/... perforce project. It
works pretty well.
__
devfs would've been enough, in retrospect).
>
This is not a leak, this is a side effect of how device cloning works in devfs.
IIRC these will be garbaged collected at some point, and faster if the system
requires the resources.
--
Christian S.J. Per
ame.
>
> --
> dc
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Christian S.J. Peron
[EMAIL PROTECTED]
this information, we can get to the bottom of this.
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
On Mon, Oct 08, 2007 at 01:18:28PM -0500, Christian S.J. Peron wrote:
> Please try the attached patch:
>
> cp audit.diff /usr/src/sys
> patch < audit.diff
>
> Recompile your kernel.
>
> If please report success/failure to me.
>
Actually.. ignore this patch.
So
___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
Index: kern/kern_prot.c
2-RELEASE-p7 which is vanilla apart from the
> addition of options MAC, AUDIT and VESA.
>
> --
> dc
> ___
> freebsd-hackers@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "[EMAIL PROTECTED]"
--
tch http://www.freebsd.org/~csjp/mac/mac_chkexec.165827.shar
sh mac_chkexec.165827.shar
cd /usr/src/sys/modules/mac_chkexec
make
make install
make clean
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-hackers@freebsd.org mailing l
ity.mac.chkexec.cache.objmax=1024
Good luck & Thanks!
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
rocess environment to get rid of the procfs requirement.
pjd has some work done on this but it has not been committed yet.
Hope this answers your question.
Regards
Christian S.J. Peron
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.or
*gid = inp_arg->inp_socket->so_cred->cr_groups[0];
> 2416return (1);
> 2417}
> 2418#endif
>
Looks like it could be a bad pointer dereference, have you recompiled
your kernel and the pf/ipfw modules? If not, please try r
ser/group/jail based firewall rules
Remember, these are pretty beta so ... be gentle :)
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscr
oblem, however I have
not had much time to look into it.
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Syntax:
ipfw add count ip from any to any jail 1
"jail" takes a numeric argument, a jail ID.
For those of you who dont know, jail IDs can be retrieved using
the jls(8) utility.
Input would be greatly appriciated.
Thanks!
--
Christian S.J. Peron
[EMAIL PROTECTED]
I understand what you are saying. The only real other choice
would be to copy out the entire cr_groups array. Do you know
if this copy would be more expensive then the mutex lock/unlock
associated with grabbing a reference to the ucred?
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD
make sure there are no return, continues or breaks
etc which could cause the ucred to be leaked.
On 2 Jun 2004 Andre Oppermann wrote:
> Christian S.J. Peron wrote:
> >On 2 Jun 2004 Andre Oppermann wrote:
> >
> >>Christian S.J. Peron wrote:
> >>
> >>>
On 2 Jun 2004 Andre Oppermann wrote:
> Christian S.J. Peron wrote:
> >All,
> >
> >Currently, when you have any rules which contain UID/GID
> >constraints, ipfw will lock the pcb hash and do a lookup
> >to find the pcb associated with that packet --
> >
NOTE:
It also appears that ip_output passes a reference to the PCB.
Perhaps we can hold a reference to the ucred stored in that
entry and do away with lookups on outgoing packets all-together?
--
Christian S.J. Peron
[EMAIL PROTECTED]
FreeBSD Committer
appear to work, however
I ask for people to test and scrutinize these patches.
Feedback/comments are welcome.
Regards
Christian S.J. Peron
> new and improved patch <---
--- sys/kern/kern_jail.c.bakMon Apr 19 16:55:40 2004
+++ sys/kern/kern_jail.cMon Apr 19 17:56:0
create_raw_sockets MIB all together).
Anyway, take a gander at it (testers feedback welcome):
Regards
Christian S.J. Peron
--- sys/netinet/raw_ip.c.b Mon Apr 19 16:23:57 2004
+++ sys/netinet/raw_ip.cTue Apr 20 19:43:30 2004
@@ -40,6 +40,7 @@
#include "opt_random_ip_id.h"
Although RAW sockets can be used when specifying the source
address of packets (defeating one of the aspects of the jail)
some people may find it usefull to use utilities like ping(8)
or traceroute(8) from inside jails.
Enclosed is a patch I have written wh
21 matches
Mail list logo
