Bosko Milekic wrote:
I plan to commit the new bits within the next week.
However, as is usually the case with commits of this magnitude,
I'd like a few more tests to be run by a few more people.
I've been testing the allocator myself (in several different
ways, mainly resource
Hi Terry,
On Thu, Jun 14, 2001 at 01:03:13AM -0700, Terry Lambert wrote:
A general comment, and then a comment on the patch:
I would like to see this code be optional, until such time
as benchmarks have proven it to be better than the existing
code, or have proben it to be worse.
FWIW- your patches appear to work fine for top of tree alpha.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
The reason I said in the next week is actually because on Sat. June 23rd
(not this upcoming one, but the one after), I should be flying off to
Yugoslavia (actually to London, and only then to Yugoslavia). I will be
gone for 3 weeks and seeing as how maintaining this huge diff is a real
On Wed, Jun 13, 2001 at 12:48:14AM -0700, Mike Smith wrote:
The reason I said in the next week is actually because on Sat. June 23rd
(not this upcoming one, but the one after), I should be flying off to
Yugoslavia (actually to London, and only then to Yugoslavia). I will be
gone for 3
Folks,
I have a new version of the patch for you to test. It's up:
http://people.freebsd.org/~bmilekic/code/mb_slab/mb_alloc-LATEST.diff
(same place as before).
The difference is that I have removed the HUGE src/sys sweep for #include's
and have removed the need to include
Hi -current -alpha,
If you run -CURRENT on multiprocessor alpha, please
please please read this! :-)
The final version (or next to final, depending on how
this final testing stage goes) of the new mbuf allocator which
I have been working on for the past 1.5 months and which
Right, will do some testing, thanks.. can you give us a bit more than a week
tho?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote:
Right, will do some testing, thanks.. can you give us a bit more than a week
tho?
Your prompt reply is extremely encouraging. Thanks! :-
The reason I said in the next week is actually because on Sat. June 23rd
(not this
On Wed, 13 Jun 2001, Bosko Milekic wrote:
On Tue, Jun 12, 2001 at 10:13:12PM -0700, Matthew Jacob wrote:
Right, will do some testing, thanks.. can you give us a bit more than a week
tho?
Your prompt reply is extremely encouraging. Thanks! :-
The reason I said in the next
x I like the -e option when I'm root and trying to debug things. I
x think that peter's fix seems to be ideal. You can find out about your
x own uid, but no one else's unless you are root.
I agree, but anything that runs suid has to be excluded as well.
-Adam Wight
To Unsubscribe: send
Adam Wight wrote in list.freebsd-current:
x I like the -e option when I'm root and trying to debug things. I
x think that peter's fix seems to be ideal. You can find out about your
x own uid, but no one else's unless you are root.
I agree, but anything that runs suid has to be
since the environment is supposed to be part of the address space
it is ssupposed to be private..
On Wed, 17 Nov 1999, Oliver Fromme wrote:
Adam Wight wrote in list.freebsd-current:
x I like the -e option when I'm root and trying to debug things. I
x think that peter's fix seems to be
Julian Elischer wrote in list.freebsd-current:
On Wed, 17 Nov 1999, Oliver Fromme wrote:
Adam Wight wrote in list.freebsd-current:
x I like the -e option when I'm root and trying to debug things. I
x think that peter's fix seems to be ideal. You can find out about your
x
And, also, we need to get rid of the 'e' option to ps entirely. It's a
major security hole.
I agree that we need to get rid of 'e' and any other options that allow
reading another process's environment.
How about protecting the -e option by a test for setuid() == 0 instead
of
On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote:
Why don't we get rid of the 'e' option to ps while we are at it
considering how much of a security hole it is.
Hmm, well, I like to have it around for root at least...
Exactly.
In a perfect world, the -e option will
In message [EMAIL PROTECTED], Sheldon Hearn writes:
On Tue, 16 Nov 1999 07:19:52 +0100, Poul-Henning Kamp wrote:
Why don't we get rid of the 'e' option to ps while we are at it
considering how much of a security hole it is.
Hmm, well, I like to have it around for root at least...
On Mon, Nov 15, 1999 at 02:18:24PM -0800, Matthew Dillon wrote:
Why don't we get rid of the 'e' option to ps while we are at it
considering how much of a security hole it is. I've never liked the
'e' option.
If we get rid of the 'e' option we should also get rid of showing
the
http://phk.freebsd.dk/misc/p_args.patch
The p_args.patch patch implements a cache of the commandline arguments
in the process structure and makes ps(1) pick it up from there with
sysctl rather than by groping around in the target process memory.
This patch:
Speeds up ps(1).
In article [EMAIL PROTECTED] you write:
The p_args.patch patch implements a cache of the commandline arguments
in the process structure and makes ps(1) pick it up from there with
sysctl rather than by groping around in the target process memory.
I don't think this should go in at all.
It
:http://phk.freebsd.dk/misc/p_args.patch
:
:The p_args.patch patch implements a cache of the commandline arguments
:in the process structure and makes ps(1) pick it up from there with
:sysctl rather than by groping around in the target process memory.
:
:This patch:
:Speeds up ps(1).
:I don't think this should go in at all.
:
:It increases the size of the proc structure (thereby affecting _all_
:processes) gratuitously. While I'm generally in favour of having the process
:arguments kept around, the "BSD way" has been to only examine them in user
:memory, despite that being
On Mon, Nov 15, 1999 at 02:27:10PM -0800, Matthew Dillon wrote:
And, also, we need to get rid of the 'e' option to ps entirely. It's a
major security hole.
Not more so than option 'u', or even 'a', if you ask me.
It's common knowledge under Unix that you shouldn't put anything
Pierre Beyssac wrote in list.freebsd-current:
On Mon, Nov 15, 1999 at 02:27:10PM -0800, Matthew Dillon wrote:
And, also, we need to get rid of the 'e' option to ps entirely. It's a
major security hole.
Not more so than option 'u', or even 'a', if you ask me.
It's common
:I don't think this should go in at all.
:
:It increases the size of the proc structure (thereby affecting _all_
:processes) gratuitously. While I'm generally in favour of having the process
:arguments kept around, the "BSD way" has been to only examine them in user
:memory, despite that being
:In my opinion, doing so majorly bloats the proc struct for no good reason and
:also introduces gratuitous incompatibilities for utilities that want to modify
:their argv[*] and expect the modifications to show up in ps(1).
:
:-DG
:
:David Greenman
Well, I think there is an issue in the proc
At 6:22 PM -0800 11/15/99, Matthew Dillon wrote:
Well, I think there is an issue in the proc struct bloat but I disagree
strongly about modifying argv - any worthwhile code uses setproctitle()
now simply because the argv space is highly dependant on the number of
arguments passed
In message [EMAIL PROTECTED], Sean Eric Fagan writes:
In article [EMAIL PROTECTED] you write:
The p_args.patch patch implements a cache of the commandline arguments
in the process structure and makes ps(1) pick it up from there with
sysctl rather than by groping around in the target process
In message [EMAIL PROTECTED], Matthew Dillon writes:
:http://phk.freebsd.dk/misc/p_args.patch
:
:The p_args.patch patch implements a cache of the commandline arguments
:in the process structure and makes ps(1) pick it up from there with
:sysctl rather than by groping around in the target process
In message [EMAIL PROTECTED], David Greenman writes:
I agree that we need to get rid of 'e' and any other options that allow
reading another process's environment. I don't agree with putting the command
args in the proc struct, however, for the reason that Sean mentioned above.
In my opinion,
Alex Zepeda wrote:
On Fri, 19 Nov 1999, Warner Losh wrote:
In message Pine.BSF.4.10.9911182311590.338-10@localhost Alex Zepeda w
rites:
: ps -e w/out -U only shows variables for processes owned by that user, no?
ps -ea.
Then perhaps -a and -U should be disabled? *grin*
I
In message Pine.BSF.4.10.9911172341110.397-10@localhost Alex Zepeda writes:
: Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful,
: no?
-e w/o -U is still harmful.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of
:
:In message Pine.BSF.4.10.9911172341110.397-10@localhost Alex Zepeda writes:
:: Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful,
:: no?
:
:-e w/o -U is still harmful.
:
:Warner
I am all for removing -e, but I don't really like the idea of making
it optional
In message [EMAIL PROTECTED] Matthew Dillon writes:
: I am all for removing -e, but I don't really like the idea of making
: it optional nor do I like the idea of trying to maintain the capability
: for the user's own processes - that simply makes the code even more
: complex then
In article [EMAIL PROTECTED] you
write:
I am all for removing -e, but I don't really like the idea of making
it optional nor do I like the idea of trying to maintain the capability
for the user's own processes - that simply makes the code even more
complex then it already is.
Sean Eric Fagan wrote:
In article [EMAIL PROTECTED]
m you write:
I am all for removing -e, but I don't really like the idea of making
it optional nor do I like the idea of trying to maintain the capability
for the user's own processes - that simply makes the code even more
On Thu, 18 Nov 1999, Warner Losh wrote:
In message Pine.BSF.4.10.9911172341110.397-10@localhost Alex Zepeda writes:
: Or perhaps restricting -U to root only? Since -e w/out -U isn't harmful,
: no?
-e w/o -U is still harmful.
ps -e w/out -U only shows variables for processes owned by
On Thu, Nov 18, 1999 at 05:04:20PM -0800, Matthew Dillon wrote:
I am all for removing -e, but I don't really like the idea of making
it optional nor do I like the idea of trying to maintain the capability
for the user's own processes - that simply makes the code even more
In message Pine.BSF.4.10.9911182311590.338-10@localhost Alex Zepeda writes:
: ps -e w/out -U only shows variables for processes owned by that user, no?
ps -ea.
Warner
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
In message [EMAIL PROTECTED] Andreas Klemm writes:
: By simply removing it (without thinking about alternatives) I
: think FreeBSD looses some points ... I thought we were the team
: that doesn't do radical changes without a good reason ;-)
That's why I'm not in favor of removing it. That's far
On Fri, 19 Nov 1999, Warner Losh wrote:
In message Pine.BSF.4.10.9911182311590.338-10@localhost Alex Zepeda writes:
: ps -e w/out -U only shows variables for processes owned by that user, no?
ps -ea.
Then perhaps -a and -U should be disabled? *grin*
- alex
To Unsubscribe: send
In message Pine.BSF.4.10.9911182331120.338-10@localhost Alex Zepeda writes:
: Then perhaps -a and -U should be disabled? *grin*
No. -e, -a, -U are all use for the sysadmin. They can provide
sensitive information, so should have sensible access policies placed
upon their use. While the
On Fri, 19 Nov 1999, Warner Losh wrote:
In message Pine.BSF.4.10.9911182331120.338-10@localhost Alex Zepeda writes:
: Then perhaps -a and -U should be disabled? *grin*
No. -e, -a, -U are all use for the sysadmin. They can provide
sensitive information, so should have sensible access
In message Pine.BSF.4.10.9911182338520.338-10@localhost Alex Zepeda writes:
: Erk. That came out wrong. I meant removal for non root or
: perhaps non gid wheel? or somesuch.
Actually, you wanna do access control like procfs does (will do?) for
its cmdline file.
Warner
To Unsubscribe:
On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote:
I agree that we need to get rid of 'e' and any other options that allow
reading another process's environment.
I think it would be sufficient, to allow only root to use the 'e' option.
There is no need to get rid of it
On Thu, 18 Nov 1999, Andreas Klemm wrote:
On Mon, Nov 15, 1999 at 05:44:12PM -0800, David Greenman wrote:
I agree that we need to get rid of 'e' and any other options that allow
reading another process's environment.
I think it would be sufficient, to allow only root to use the 'e'
46 matches
Mail list logo
