[EMAIL PROTECTED] (Nick Sayer) writes:
> What we _really_ need is some mechanism to recognize the difference
> between a user program and a system library, with an eye towards
> granting privileges to trusted libraries without letting those privileges
> leak past the library in question.
>
> I d
[EMAIL PROTECTED] (FengYue) writes:
> I've 3 small programs. First one writes 4K of data contains 'A's into a
> file /tmp/pagetest and then lseek() to the begin of the file.
> Second one writes 4K of 'Z' into the same file /tmp/pagetest and
> then lseek() to the begin of the file. They both do
> IPSec isn't well documented, but once I figured out the config
> file it didn't seem too bad. I am guessing that replay prevention
Reading the RFCs might be more helpful than most of the KAME
documentation. There's also a lot of undocumented stuff for which the
sources seem to be the
[EMAIL PROTECTED] (Matthew Dillon) writes:
> The question is: What am I forgetting to do? Or is this a bug in our
> IPSEC implementation?
AFAIK this is more or less how it's supposed to work. IPsec is a
mess. Security associations are not stateless, ESP provides replay
protection us
[EMAIL PROTECTED] (Olaf Hoyer) writes:
> Well, thats reality.
> Sometimes the mobile telco hotlines are so overloaded, you cannot even tell
> them that your phone was stolen. (Talk about service-but you get what you
> pay for)
> In germany, there is some list, where every cell phone can be enter
[EMAIL PROTECTED] (Kris Kennaway) writes:
> Can you say "gimmick"? :-) gcc often produces demonstrably broken code for
> optimisation levels higher than -O.
That -O is safe seems to be a persistent myth. GCC also produces
broken code for -O and no optimization in some cases, sometimes while
pr
[EMAIL PROTECTED] (Warner Losh) writes:
> I have a system that has one file system on it (eg everything is on
> /). I'm finding that a lot of space is wasted on the multiple static
> copies of libc in /sbin and /bin. I was thinking about building, for
> this system only, /bin and /sbin dynamic
[EMAIL PROTECTED] (Arun Sharma) writes:
> 2. For cases where you've entered the kernel synchronously - through syscalls
>for example, you need to check for the validity of data. You could
>potentially skip the step and validate the data where it is used, rather
>than doing it upfron
[EMAIL PROTECTED] (Jonas Bulow) writes:
> How does the UVM system compare to the VM system in FreeBSD? Are there
> any benchmark tests or research results in this area?
The dissertation paper on UVM describes the differences (and is
reasonably objective). It can be found on the UVM pages
(htt
[EMAIL PROTECTED] (Ronald F. Guilmette) writes:
> The original libelf code was/is owned by, and developed by AT&T's Unix
> Systems Group (USG) which AT&T sold to (I think) Novell and which Novell
> then sold to SCO.
> Bottom line is that the _real_ libelf is proprietary code.
There is a free (
[EMAIL PROTECTED] (Vladimir N. Silyaev) writes:
> are need to have steal nerves. I fill that, at the time when I was porting
> vmware. I have too much hours of very interested work - load driver, launch
> vmware and then looking into the DDB double fault screen. Reload box,
> and then again.
I
[EMAIL PROTECTED] (Don) writes:
> > and the next question: now that LFS starts to get usable in NetBSD
> > - has anybody started to look at getting it working again in
> > FreeBSD too (maybe matt ?) or has it on the TODO list
> LFS is being considered as a starting point for this project. The g
[EMAIL PROTECTED] (Chuck Robey) writes:
> Boy, I sure wish Java compiled and ran natively. I'd stop using C++
> forever.
gcc-2.95.1 + libgcj already works, at least for simple programs. On
FreeBSD 3.x programs seem to work as long as you use statically linked
libraries (shared libraries cause
[EMAIL PROTECTED] (W Gerald Hicks) writes:
> I don't have a shiny new K7 yet, where I might expect the haifa
> build to make more of a difference than my crusty old Pentium...
Processors with out-of-order execution benefit *less* from scheduling
than non-OOO superscalar processors.
To Unsubsc
[EMAIL PROTECTED] (Zhihui Zhang) writes:
> As said by the 4.4 BSD book (page 423), 4.4 BSD does not support multiple
> routes to the same destination (identical key and mask). Does the radix
> tree code in FreeBSD - 4.0 has the same limitation? I am wondering if
> there is already a solution fo
[EMAIL PROTECTED] (Jayson Nordwick) writes:
> While reading through (at least trying to... I wish there was some sort of
> kernel documentation available, the entry fee is very high) the aio_* calls,
> I had a few questions to clear up my understanding:
> 1) Do they only work on files? The on
nordw...@scam.xcf.berkeley.edu (Jayson Nordwick) writes:
> While reading through (at least trying to... I wish there was some sort of
> kernel documentation available, the entry fee is very high) the aio_* calls,
> I had a few questions to clear up my understanding:
> 1) Do they only work on fi
sheld...@uunet.co.za (Sheldon Hearn) writes:
> Actually, not. The postfix and exim ports, at least, would be taught to
> use the new UID when it became available in STABLE. I'm pretty sure
> smail and others would follow suit. Remember, _we_ control the ports and
> can have packages install for w
[EMAIL PROTECTED] (Sheldon Hearn) writes:
> Actually, not. The postfix and exim ports, at least, would be taught to
> use the new UID when it became available in STABLE. I'm pretty sure
> smail and others would follow suit. Remember, _we_ control the ports and
> can have packages install for wha
bri...@wintelcom.net (Alfred Perlstein) writes:
> 1) file descriptor passing (described in Unix Network Programming Vol I)
Or just read recv(2), search for SCM_RIGHTS.
> 2) shared address fork (should be on http://lt.tar.com)
Or just read rfork(2), and you don't need to share the address space
[EMAIL PROTECTED] (Alfred Perlstein) writes:
> 1) file descriptor passing (described in Unix Network Programming Vol I)
Or just read recv(2), search for SCM_RIGHTS.
> 2) shared address fork (should be on http://lt.tar.com)
Or just read rfork(2), and you don't need to share the address space.
g...@lemis.com (Greg Lehey) writes:
> All systems which do more than one thing at a time need file locking
> at some time or another. Since it involves cooperation between
> potentially unrelated processes, it's an obvious kernel function. Any
> "solution" requiring cooperation between processe
[EMAIL PROTECTED] (Greg Lehey) writes:
> All systems which do more than one thing at a time need file locking
> at some time or another. Since it involves cooperation between
> potentially unrelated processes, it's an obvious kernel function. Any
> "solution" requiring cooperation between proc
tlamb...@primenet.com (Terry Lambert) writes:
> I think this has been the basis of your objection so far. If so,
> it's a fundamental misunderstanding of "mandatory". In this context
What I was objecting to were some of the arguments made by Greg Lehey
and Wes Peters, both of whom explicitly s
[EMAIL PROTECTED] (Terry Lambert) writes:
> I think this has been the basis of your objection so far. If so,
> it's a fundamental misunderstanding of "mandatory". In this context
What I was objecting to were some of the arguments made by Greg Lehey
and Wes Peters, both of whom explicitly stat
> Not to jump down your throat, or anything, but you seem to be
> perpetuating some incorrct assumptions about both effect and
> proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean automatic, forc
> Not to jump down your throat, or anything, but you seem to be
> perpetuating some incorrct assumptions about both effect and
> proposed implementation details, and they must be stomped. 8-).
I was assuming that mandatory locking, in the context of this
discussion, does not mean automatic, for
w...@softweyr.com (Wes Peters) writes:
> And how many programmers with nearly (or more than) two decades of UNIX
> experience it takes to convince someone it really is useful.
It should only take one, as long as the arguments made are not bogus.
IMHO Greg made some very silly arguments (or at l
[EMAIL PROTECTED] (Wes Peters) writes:
> And how many programmers with nearly (or more than) two decades of UNIX
> experience it takes to convince someone it really is useful.
It should only take one, as long as the arguments made are not bogus.
IMHO Greg made some very silly arguments (or at
gurne...@efn.org (John-Mark Gurney) writes:
> Ville-Pertti Keinonen scribbled this message on Aug 24:
> > cat writes part of oldmail to /var/mail/grog
> > sendmail locks /var/mail/grog
> > (cat may try to write more to /var/mail/grog but blocks)
> >
[EMAIL PROTECTED] (John-Mark Gurney) writes:
> Ville-Pertti Keinonen scribbled this message on Aug 24:
> > cat writes part of oldmail to /var/mail/grog
> > sendmail locks /var/mail/grog
> > (cat may try to write more to /var/mail/grog but blocks)
> >
g...@lemis.com (Greg Lehey) writes:
> an agreement of some kind. But what if I want to merge the contents
> of another mail folder:
> cat oldmail >>/var/mail/grog
> That works, but it's playing with fire: if sendmail is delivering a
> message at the same time, it won't see me, and my cat doe
chu...@picnic.mat.net (Chuck Robey) writes:
> On 23 Aug 1999, Ville-Pertti Keinonen wrote:
> > And even without otherwise incorrect behavior, if you have a program
> > that doesn't use any locking and another one that uses mandatory
> > locking to prevent races with th
[EMAIL PROTECTED] (Greg Lehey) writes:
> an agreement of some kind. But what if I want to merge the contents
> of another mail folder:
> cat oldmail >>/var/mail/grog
> That works, but it's playing with fire: if sendmail is delivering a
> message at the same time, it won't see me, and my cat
[EMAIL PROTECTED] (Chuck Robey) writes:
> On 23 Aug 1999, Ville-Pertti Keinonen wrote:
> > And even without otherwise incorrect behavior, if you have a program
> > that doesn't use any locking and another one that uses mandatory
> > locking to prevent races with th
g...@lemis.com (Greg Lehey) writes:
> Again, if we have two concurrent transactions, we stand to gain money:
> the updated balance is likely not to know about the other transaction,
> and will thus "forget" one of the deductions.
> Now I suppose you're going to come and say that this is bad
> pr
gurne...@efn.org (John-Mark Gurney) writes:
> Christopher Seiwald scribbled this message on Aug 18:
> > It's a pretty straightforward change to bypass the insertion sort for
> > large subsets of the data. If no one has a strong love for qsort, I'll
> > educate myself on how to make and contribut
[EMAIL PROTECTED] (Greg Lehey) writes:
> Again, if we have two concurrent transactions, we stand to gain money:
> the updated balance is likely not to know about the other transaction,
> and will thus "forget" one of the deductions.
> Now I suppose you're going to come and say that this is bad
[EMAIL PROTECTED] (John-Mark Gurney) writes:
> Christopher Seiwald scribbled this message on Aug 18:
> > It's a pretty straightforward change to bypass the insertion sort for
> > large subsets of the data. If no one has a strong love for qsort, I'll
> > educate myself on how to make and contrib
ch...@calldei.com (Chris Costello) writes:
>I'm in favor of a libgnucompat rather than gnu functions in
> libcompat.
And how would a libgnucompat be different from libiberty? Except of
course that it would be maintained by the FreeBSD folks... Or that it
would be maintained at all. ;--)
matthew.al...@anheuser-busch.com (Alton, Matthew) writes:
> I am currently researching methods for implementing the 64-bit
> syscalls stat64(), fstat64(), lseek64() &etc. delineated in the
> SGI design doc _64 Bit File Access_ by Adam Sweeney.
Do the design docs indicate how inode numbers shou
[EMAIL PROTECTED] (Chris Costello) writes:
>I'm in favor of a libgnucompat rather than gnu functions in
> libcompat.
And how would a libgnucompat be different from libiberty? Except of
course that it would be maintained by the FreeBSD folks... Or that it
would be maintained at all. ;--)
[EMAIL PROTECTED] (Alton, Matthew) writes:
> I am currently researching methods for implementing the 64-bit
> syscalls stat64(), fstat64(), lseek64() &etc. delineated in the
> SGI design doc _64 Bit File Access_ by Adam Sweeney.
Do the design docs indicate how inode numbers should interact wi
d...@flood.ping.uio.no (Dag-Erling Smorgrav) writes:
> Ville-Pertti Keinonen writes:
> > I certainly don't expect any of the available voices to be able to
> > pronounce Finnish names correctly, even with phonetic specifications.
> If the software were *designed* to sp
[EMAIL PROTECTED] (Dag-Erling Smorgrav) writes:
> Ville-Pertti Keinonen <[EMAIL PROTECTED]> writes:
> > I certainly don't expect any of the available voices to be able to
> > pronounce Finnish names correctly, even with phonetic specifications.
> If the soft
w...@softweyr.com (Wes Peters) writes:
> available for "home" computers decades ago. (Anyone else here ever use
> SAM "the Software Automated Mouth" for the Atari 800 or Commodore 64?)
Yes.
It's almost surprising how little speech synthesis has improved, at
least judging from the festival demo
[EMAIL PROTECTED] (Wes Peters) writes:
> available for "home" computers decades ago. (Anyone else here ever use
> SAM "the Software Automated Mouth" for the Atari 800 or Commodore 64?)
Yes.
It's almost surprising how little speech synthesis has improved, at
least judging from the festival dem
> > > :> [ENOBUFS] Insufficient system buffer space exists to complete
> > > the op-
> > > :>eration.
> > > :
> > > :Do you know what kind of circumstances that error *really* occurs
> > > :under?
> >
> > So you can get ENOBUFS not related to mbufs for UDP/local data
> > > :> [ENOBUFS] Insufficient system buffer space exists to complete the op-
> > > :>eration.
> > > :
> > > :Do you know what kind of circumstances that error *really* occurs
> > > :under?
> >
> > So you can get ENOBUFS not related to mbufs for UDP/local datagram
>
> :w...@softweyr.com (Wes Peters) writes:
> :
> :> [ENOBUFS] Insufficient system buffer space exists to complete the
> op-
> :>eration.
> :
> :Do you know what kind of circumstances that error *really* occurs
> :under?
> :
> :If it happened with files, that would be a
> :[EMAIL PROTECTED] (Wes Peters) writes:
> :
> :> [ENOBUFS] Insufficient system buffer space exists to complete the op-
> :>eration.
> :
> :Do you know what kind of circumstances that error *really* occurs
> :under?
> :
> :If it happened with files, that would be a b
w...@softweyr.com (Wes Peters) writes:
> [ENOBUFS] Insufficient system buffer space exists to complete the op-
>eration.
Do you know what kind of circumstances that error *really* occurs
under?
If it happened with files, that would be a bug and should be fixed.
The
[EMAIL PROTECTED] (Wes Peters) writes:
> [ENOBUFS] Insufficient system buffer space exists to complete the op-
>eration.
Do you know what kind of circumstances that error *really* occurs
under?
If it happened with files, that would be a bug and should be fixed.
The
jere...@gsmx07.alcatel.com.au (Peter Jeremy) writes:
> "Leif Neland" wrote:
> >My 60MHz Pentium, FreeBSD
> >
> >time file /usr/home/leif/vnc-3.3.2r
> >/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated,
> >original filename, last modified: Thu Jan 21 19:23:21 1999
> >
> >real
[EMAIL PROTECTED] (Peter Jeremy) writes:
> "Leif Neland" <[EMAIL PROTECTED]> wrote:
> >My 60MHz Pentium, FreeBSD
> >
> >time file /usr/home/leif/vnc-3.3.2r
> >/usr/home/leif/vnc-3.3.2r3_unixsrc.tgz: gzip compressed data, deflated,
> >original filename, last modified: Thu Jan 21 19:23:21 1999
> >
d...@flood.ping.uio.no (Dag-Erling Smorgrav) writes:
> "Kelly Yancey" writes:
> > Ahh...but wouldn't the bzero() touch all of the memory just allocated
> > functionally making it non-overcommit?
>
> No. If it were an "non-overcomitting malloc", it would return NULL and
> set errno to ENOMEM,
[EMAIL PROTECTED] (Dag-Erling Smorgrav) writes:
> "Kelly Yancey" <[EMAIL PROTECTED]> writes:
> > Ahh...but wouldn't the bzero() touch all of the memory just allocated
> > functionally making it non-overcommit?
>
> No. If it were an "non-overcomitting malloc", it would return NULL and
> set er
c...@netbsd.org (Chris G. Demetriou) writes:
> Matthew Dillon writes:
> > The text size of a program is irrelevant, because swap is never
> > allocated for it. The data and BSS are only relevant when they
No, you can mprotect read-only vnode mappings to writable. Most
things wouldn't
jul...@whistle.com (Julian Elischer) writes:
> If you wanted to fix this, you could add a patch to malloc that touched
> every page that it handed to the application. (and trapped sig11s)
How would you expect that to work?
Several misunderstandings seem to be common regarding this issue (most
n
[EMAIL PROTECTED] (Chris G. Demetriou) writes:
> Matthew Dillon <[EMAIL PROTECTED]> writes:
> > The text size of a program is irrelevant, because swap is never
> > allocated for it. The data and BSS are only relevant when they
No, you can mprotect read-only vnode mappings to writable.
[EMAIL PROTECTED] (Julian Elischer) writes:
> If you wanted to fix this, you could add a patch to malloc that touched
> every page that it handed to the application. (and trapped sig11s)
How would you expect that to work?
Several misunderstandings seem to be common regarding this issue (most
n
gr...@freebsd.org (Brian F. Feldman) writes:
> It's "out with the bad, in with the good." Pidentd code is pretty terrible.
> The only security concerns with my code were wrt FAKEID, and those were
> mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't
> be read.) If anyone wa
[EMAIL PROTECTED] (Brian F. Feldman) writes:
> It's "out with the bad, in with the good." Pidentd code is pretty terrible.
> The only security concerns with my code were wrt FAKEID, and those were
> mostly fixed (mostly meaning that a symlink _may_ be opened, but it won't
> be read.) If anyone w
p...@critter.freebsd.dk (Poul-Henning Kamp) writes:
> But shouldn't you still be able to use the timer in the local apic ?
Did you read the last paragraph in my message?
Here it is again:
> >It's been a while since I looked at the documentation, but it *might*
> >be possible that the local API
zzh...@cs.binghamton.edu (Zhihui Zhang) writes:
> At the beginning of the file vm_object.c, we have the following comment:
>
> The only items within the object structure which are modified after time
> of creation are:
>
> reference count locked by object's lock
> pager routine
p...@critter.freebsd.dk (Poul-Henning Kamp) writes:
> Somebody should study the abilities of the on-cpu APIC for this
> for pentium ff. machines.
The local APIC would work very nicely, but I'm not sure that you can
enable it reliably in a non-SMP configuration. AFAIK most BIOSes
don't provide a
[EMAIL PROTECTED] (Poul-Henning Kamp) writes:
> But shouldn't you still be able to use the timer in the local apic ?
Did you read the last paragraph in my message?
Here it is again:
> >It's been a while since I looked at the documentation, but it *might*
> >be possible that the local APIC tim
[EMAIL PROTECTED] (Zhihui Zhang) writes:
> At the beginning of the file vm_object.c, we have the following comment:
>
> The only items within the object structure which are modified after time
> of creation are:
>
> reference count locked by object's lock
> pager routine locke
[EMAIL PROTECTED] (Poul-Henning Kamp) writes:
> Somebody should study the abilities of the on-cpu APIC for this
> for pentium ff. machines.
The local APIC would work very nicely, but I'm not sure that you can
enable it reliably in a non-SMP configuration. AFAIK most BIOSes
don't provide an MP
patr...@mycenae.ilion.eu.org (Patryk Zadarnowski) writes:
> > You can't extend the address space that way, segments are all parts of
> > the single 4GB address space described by the page mapping.
> True, but you can reserve a part of the 4GB address space (say 128MB of it)
> for partitioning in
dil...@apollo.backplane.com (Matthew Dillon) writes:
> pair-down the fields in both structures. For example, the vnode structure
> contains a lot of temporary clustering fields that could be removed
> entirely if clustering operations are done at the time of the actual I/O
> rath
jul...@whistle.com (Julian Elischer) writes:
> we already use the gs register for SMP now..
> what about the fs register?
> I vaguely remember that the different segments could be used to achieve
> this (%fs points to user space or something)
You can't extend the address space that way, segm
[EMAIL PROTECTED] (Patryk Zadarnowski) writes:
> > You can't extend the address space that way, segments are all parts of
> > the single 4GB address space described by the page mapping.
> True, but you can reserve a part of the 4GB address space (say 128MB of it)
> for partitioning into tiny (s
[EMAIL PROTECTED] (Matthew Dillon) writes:
> pair-down the fields in both structures. For example, the vnode structure
> contains a lot of temporary clustering fields that could be removed
> entirely if clustering operations are done at the time of the actual I/O
> rather then b
[EMAIL PROTECTED] (Julian Elischer) writes:
> we already use the gs register for SMP now..
> what about the fs register?
> I vaguely remember that the different segments could be used to achieve
> this (%fs points to user space or something)
You can't extend the address space that way, segm
zzh...@cs.binghamton.edu (Zhihui Zhang) writes:
> For a big executable file that is being run by the OS, all its contents
> may not be loaded into the memory. At the same time, the developer gets
> impatient and wants to create a new version of the same file. He could
> modify the makefile to o
[EMAIL PROTECTED] (Zhihui Zhang) writes:
> For a big executable file that is being run by the OS, all its contents
> may not be loaded into the memory. At the same time, the developer gets
> impatient and wants to create a new version of the same file. He could
> modify the makefile to output
I think I've located a problem in TCP input processing...and it has
been there for quite a while. It breaks half-open connection
discovery for many cases since version 1.15 of netinet/tcp_input.c
(committed by Garrett Wollman, which is why this is Cc'd to him),
although that isn't where the (pres
g...@lemis.com (Greg Lehey) writes:
> > You've accidentally striped subdisks on the same drive? ;--)
> >
> > Like Greg Lehey said, you haven't really provided enough details.
>
> He did provide one detail, though; this is a concatenated plex, not a
> striped one.
Or he at least *thinks* it's c
cro...@cs.rpi.edu (David E. Cross) writes:
> I have a drive that is rated at ~16 Meg/second, and indeed it delivers on the
> order of 15+ Meg/second. If I use Vinum to create a concatinated device
> of 2 such units performance drops to 2.5 Meg/sec. This seems like a
> drastic drop in performan
dil...@apollo.backplane.com (Matthew Dillon) writes:
> However, if the inside of the first conditional generates an error, the vp
> may be vput twice. What I recommend is this for the last bit:
That can't happen (the attributes are straight from VATTR_NULL along
that path) - if it could
dsche...@enteract.com (David Scheidt) writes:
> First try: Suppose foo depends on /usr/local/etc/foo.conf.
> /usr/local/etc is a link to /usr/local/${ARCH}/etc. User does
> export $ARCH=../../home/user, so /usr/local/etc/foo.conf is now in
> their home directory. Depending on how poorly writte
m...@servo.ccr.org (Mike O'Dell) writes:
> very fine-grain-locked systems often display convoying and
> are prone to priority inversion problems. coarse-grained
Priority inversion problems are design flaws. Depending on the type
of locks, they may not even be possible. Spin locks held for shor
zzh...@cs.binghamton.edu (Zhihui Zhang) writes:
> It seems to me that we can lock at the vnode layer AND at the inode layer.
No, the inode lock is, in most cases, the vnode layer lock. It isn't
obvious because the code assumes that any filesystem using vop_stdlock
has a 'struct lock' as the fi
jo...@gnu.org (Joel Ray Holveck) writes:
> As we all know, tunefs -o space will hurt write performance. Will it
> hurt read performance? If I don't care about install-time speed, but
> do care about run-time speed and free space, should I populate my
> filesystems at install time with space tun
> Suppose, you have a directory hierarchy a -> b -> c. In each of a, b, and
> c, we have the following files:
>
> a: ., .., a1, a2, a3, b (a1, a2, a3 are not directory files)
> b: ., .., b1, b2, b3, c (b1, b2, b3 are not directory files)
>
> If I do a "mv a a_new", then cache entrie
zzh...@cs.binghamton.edu (Zhihui Zhang) writes:
> Suppose you want to mv a directory file (with subdirectories) to another
> name (it is like grafting a subtree to another point), the namecache
> associated with the source directory file will be purged by calling
> cache_purge() (done in ufs_renam
cro...@cs.rpi.edu (David E. Cross) writes:
> One of our users way able to reliably crash an NFS server 3 times today.
> I have since copied his program and have reliably crashed a seperate and
> unloaded machine with the exact same panic, "lockmgr: locking against
> myself". I check the recent DG
88 matches
Mail list logo
