Re: File name.
* Pawel Jakub Dawidek <[EMAIL PROTECTED]> [020203 23:49] wrote: > On Sun, Feb 03, 2002 at 10:11:37PM +0100, Pawel Jakub Dawidek wrote: > +> But how can i get file name? > +> > [...] > +> I got file name, but how can I get full path name for this file? > +> > Answer that there is no way to get that will be nice too. There is, and there isn't. :) Since UFS allows for hardlinks a single file may have multiple valid names. For instance: # cd /tmp # echo foo > f1 # ln f1 f2 484 -rw-r--r-- 2 root wheel 4 Feb 4 01:39 f1 484 -rw-r--r-- 2 root wheel 4 Feb 4 01:39 f2 However there's a dirty way to get at it via the vfs lookup cache entries hung off the vnode. Paul Saab showed me a delta that did something nasty like this, but I've got no clue as to where it is now. -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductable donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to count number of user process?
On 10:11+0300, Feb 4, 2002, Magdalinin Kirill wrote: > Hello, > > can anyone give an idea of C code on how to quickly count > the number of processes for a given user? I want to patch > Apache in order to prevent it from forking new process > over user's maxproc limit (while running suexec). > > Should I look at ps(1) source code or there are some > other examples? take a look at src/usr.bin/killall/killall.c > thanks, > > Kirill Magdalinin > [EMAIL PROTECTED] > > _ > Join the worlds largest e-mail service with MSN Hotmail. > http://www.hotmail.com > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > > -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto: [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: File name.
On Sun, Feb 03, 2002 at 10:11:37PM +0100, Paweł Jakub Dawidek wrote: +> But how can i get file name? +> [...] +> I got file name, but how can I get full path name for this file? +> Answer that there is no way to get that will be nice too. -- Paweł Jakub Dawidek Network Administrator. Am I Evil? Yes, I Am. msg31379/pgp0.pgp Description: PGP signature
Re: fork rate limit
On Sun, 3 Feb 2002 18:02:13 -0500 Mike Barcroft <[EMAIL PROTECTED]> wrote: > He should be able to pick his own administrative policy. And what I pointed out was simply another choice. Whether he implements the solution in software or takes the administrative route is obviously his choice. And if other people are interested in the work and want it commited that's fine too. cheers, mike makonnen To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: how to count number of user process?
On Mon, 4 Feb 2002, Magdalinin Kirill wrote: > can anyone give an idea of C code on how to quickly count > the number of processes for a given user? I want to patch You could try kvm_getprocs with an argument of KERN_PROC_UID. Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
how to count number of user process?
Hello, can anyone give an idea of C code on how to quickly count the number of processes for a given user? I want to patch Apache in order to prevent it from forking new process over user's maxproc limit (while running suexec). Should I look at ps(1) source code or there are some other examples? thanks, Kirill Magdalinin [EMAIL PROTECTED] _ Join the worlds largest e-mail service with MSN Hotmail. http://www.hotmail.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clock Granularity (kernel option HZ)
On Fri, 1 Feb 2002, Terry Lambert wrote: > I guess you are talking the LRP stuff. > > I was just talking about the processing at NETISR as a > result of a higher HZ causing a higher softintr run > frequency. Interesting; I hadn't considered that scheduling could have an effect on performance, but that does make sense on a heavily loaded system. > Really, the timer code that TCP uses is all bogus for a > large number of connections, and upping the clock wheel > size doesn't gain you nearly as much as interval specific > lists which only have to process until the intended time > to fire is later than "now". The clock stuff as it is > has to traverse the entire chain, because it can't know > that the firing of the timer after the current one is later > than the current one (i.e. intervals of 1 second and one > hour can end up in the same wheel bucket, because it is, in > effect, an unsorted modular timer, and inserting sorted for > more than one or two intervals is an O(N) problem). > > -- Terry I was looking at the timer implementation a few weeks ago and pondering if it could be improved as well. I think it's quite clever if you're dealing with a quantity of timers < 1000 or so, but it looks like it could be more optimal when used with the quantity of timers we have these days. Did you attempt to combine the various tcp timers so that there would be one callout per socket? I think it would be a pretty easy task; just store the various timers inside each socket, and only set a callout for the soonest to wake one. Upon wakeup, quickly check them all. That would reduce the total number of events in the callout wheel for one, and might help with the hash function aliasing long-term events such as keepalives into the current time. (I'm assuming that the retransmission and other short-term timers do a good job of keeping themselves just ahead of the clockhand that they aren't falsely checked.) Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Clock Granularity (kernel option HZ)
On Fri, 1 Feb 2002, Luigi Rizzo wrote: > HZ also has an impact on select() behaviour when timeouts are > used (and device drivers using timeouts as well). > A lot of software uses select() with a very short timeout which > is usually rounded up to the next tick. If the author of the software > is unaware of what goes on (likely) there might be negative effects > on performance because such programs stay idle longer than they should. > > cheers > luigi True, I had forgotten about that effect. Ironic, since I was quite annoyed by the limitations of 10ms accuracy last semester. Increasing the resolution of select/usleep is a good argument for increasing the HZ default, but I'm not sure how great the impact would be on slower machines. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fork rate limit
On Sun, 3 Feb 2002, Robert Watson wrote: > BTW, many sites find the per-uid process limits helpful in preventing fork > bombs from crippling the site. The default configuration may not be > sufficiently agressive, and while it's not the same as a rate limit, it > does have the effect of topping them. If there is a strong desire for > rate-limiting, slotting it into the current resource handling code > shouldn't be hard at all -- the state can be stored in uidinfo. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > [EMAIL PROTECTED] NAI Labs, Safeport Network Services Yeah, I threw in the maxprocperuid auto-capping thinking that it would help reduce the nastiness of forkbombs. However, as PR kern/23740 points out, one of the problems we're encountering now is that the proc structures are large enough that all kernel memory can be exhausted. We're going to have to cap maxproc so that proc structures can't use more than 50% of system memory in order to make sure that forkbombs can't seriously hurt a box. Mike "Silby" Silbersack To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fork rate limit
On Sun, 3 Feb 2002, Mike Barcroft wrote: > > This means less work for you, and no need to continuously maintain diffs > > against the kernel sources. IMO it's a *very,very* bad thing to > > introduce changes into the kernel that might introduce unintended side > > effects when the problem can be solved administratively. > > Obviously he is intending his changes to be committed; hence, the > patches will be applicable to -CURRENT. This is an area where FreeBSD > is lacking. I can't understand why you wish to stifle his work. BTW, many sites find the per-uid process limits helpful in preventing fork bombs from crippling the site. The default configuration may not be sufficiently agressive, and while it's not the same as a rate limit, it does have the effect of topping them. If there is a strong desire for rate-limiting, slotting it into the current resource handling code shouldn't be hard at all -- the state can be stored in uidinfo. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: fork rate limit
Mike Makonnen <[EMAIL PROTECTED]> writes: > On Sun, 3 Feb 2002 02:35:46 +0400 > Gaspar Chilingarov <[EMAIL PROTECTED]> wrote: > > > I've got such situation on our free shellbox set up in the > > university - some newbies were kidding with old while(1) fork(); > > attack. Finnaly they got hit by memory limits set up for each > > user, but anyway they were taking a lot of processor time. I > > prefer to limit some uid's ability to do many forks in some > > short period - like 'no more than 200 forks in 10 seconds' or > > smthng like this. > > Lock them out of the box for a while. If they do it again ban them > forever. The students will learn pretty quickly not to do such things. He should be able to pick his own administrative policy. > This means less work for you, and no need to continuously maintain diffs > against the kernel sources. IMO it's a *very,very* bad thing to > introduce changes into the kernel that might introduce unintended side > effects when the problem can be solved administratively. Obviously he is intending his changes to be committed; hence, the patches will be applicable to -CURRENT. This is an area where FreeBSD is lacking. I can't understand why you wish to stifle his work. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
File name.
Hey.
For example i cantrol fchflags syscall via my kernel module.
I got:
int
n_fchflags(register struct proc *p, register struct fchflags_args)
{
...
}
struct fchflags_args {
int fd;
int flags;
};
I can get vnode of changed file.
I can get inode number of changed file.
But how can i get file name?
There is a way to get inode when i have file name and p (struct proc), so
maybe there is a way to get file name from inode number and p.
And another thing for chflags syscall.
I got file name, but how can I get full path name for this file?
--
Paweł Jakub Dawidek
Network Administrator.
Am I Evil? Yes, I Am.
msg31370/pgp0.pgp
Description: PGP signature
Re: stack alignment issues (was: unbelievable benchmark output)
In message <[EMAIL PROTECTED]>, Dan Nelson cleopede: >In the last episode (Feb 03), Alfred Perlstein said: >> * Michal Mertl <[EMAIL PROTECTED]> [020203 08:17] wrote: >> Not really sure what to make of this, anyone else know how we ought >> to fix this? > >This has actually been an issue for ages, most commonly seen with >doubles. take a look at the thread at Has any "real world" program ever been significantly affected by this "problem"? Greg Shenaut To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stack alignment issues (was: unbelievable benchmark output)
In the last episode (Feb 03), Alfred Perlstein said: > * Michal Mertl <[EMAIL PROTECTED]> [020203 08:17] wrote: > > Several runs of the program take about the same time but the time > > changes wildly when the executable is called differently. > > > > The only thing which I can think of that can be causing this is > > some memory alignment issue. > > It sure looks like an alignment issue. If you print the address of > 'i' and 'j' in the attached program you can see for the fast case > they are aligned to 8 byte boundries, but when it's slow they are at > an address that is a multiple of 4 but not 8. > > Not really sure what to make of this, anyone else know how we ought > to fix this? This has actually been an issue for ages, most commonly seen with doubles. take a look at the thread at http://www.freebsd.org/cgi/getmsg.cgi?fetch=393691+0+/usr/local/www/db/text/2000/freebsd-current/2507.freebsd-current or, easier to read the entire thread: http://groups.yahoo.com/group/freebsd-current/messages/39583?threaded=1 -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: stack alignment issues (was: unbelievable benchmark output)
On Sun, 3 Feb 2002 08:59:41 -0800 Alfred Perlstein <[EMAIL PROTECTED]> wrote: Hi, > It sure looks like an alignment issue. If you print the address > of 'i' and 'j' in the attached program you can see for the fast > case they are aligned to 8 byte boundries, but when it's slow they > are at an address that is a multiple of 4 but not 8. Agreed, my bet is on data alignment. > > Not really sure what to make of this, anyone else know how we ought > to fix this? Well, you could always malloc() some memory and make sure your data is in an address that is multiple of 8. You'll waste some mem but will gain performance. I actually haven't tried it on FreeBSD but it's a trick I used to do on the Amiga some years ago. Cheers, -- Miguel Mendez - [EMAIL PROTECTED] Public Key :: http://energyhq.homeip.net/files/pubkey.txt EnergyHQ :: http://energyhq.homeip.net FreeBSD - The power to serve! To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Patch to remove MFREE() macro entirely
On Sat, Feb 02, 2002 at 11:54:17PM -0800, David Greenman wrote: > >Oh what a tangled web we weave. This should be really easy for people > >to take a quick look at to see if I made any mistakes. I'm basically > >untangling the (small) mess that people made of the code while trying to > >use the MFREE() macro over the last N years. > > > >If nobody sees any problems it will go into -current next week some > >time and then be MFC'd to stable. > >Looks good to me. I'm definately very much in favor of killing MFREE(). Absolutely! Especially in light of the fact that in -CURRENT now-a-days, MFREE() will has no benefits and pretty much ALL the mbuf macros are deprecated (they just wrap calls to the appropriate functions). They were really big for macros and actually used to make things slower by busting the cache. > -DG > > David Greenman > Co-founder, The FreeBSD Project - http://www.freebsd.org > President, TeraSolutions, Inc. - http://www.terasolutions.com > President, Download Technologies, Inc. - http://www.downloadtech.com > Pave the road of life with opportunities. -- Bosko Milekic [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: unbelievable benchmark output
> > Several runs of the program take about the same time but the time > changes wildly when the executable is called differently. > > --- > ./xx/xxx > 5 s > xx/xxx > 9 s > > The only thing which I can think of that can be causing this is some > memory alignment issue. > it could also be the shell taking time to look up the names? > Compile the code below with gcc -O -march=pentiumpro and save the > program to /tmp/x (1x) and /tmp/xxx (11x). cd /tmp; ./x shows me > 0.490495 (with slight variations amongst runs) and ./xxx 1.016591. > The real results depend on hw but they occur always with different > differences in speed and the length of name of fast/slow programs. > here're my numbers athlon 850, iwill k266 (via686b southbridge), 384m ram, 5400rpm fujitsu 20G FreeBSD fenris 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Fri Feb 1 23:57:28 CST 2002 root@fenris:/usr/src/sys/i386/compile/FENRIS i386 ./x bounces between .6 and .7 ./xxx...xx bounces between .65 and .75 with 100 x's in the name, .67 to .76 /tmp/x.55 .60 /tmp/x(11) .62 /tmp/x(100) .62 .72 > > > -- > Michal Mertl > [EMAIL PROTECTED] > -Erik <[EMAIL PROTECTED]> [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: rtadvd bugfix?
Hi,
> On Sat, 2 Feb 2002 02:49:49 +0100
> Marco Wertejuk <[EMAIL PROTECTED]> said:
wertejuk> I was really nerved when I noticed that rtadvd is exiting
wertejuk> without any notice if the host is not an ipv6 gateway.
wertejuk> Since it took me a lot of time to find this problem
wertejuk> I wrote a patch for rtadvd to show a message and
wertejuk> noticed something strange:
wertejuk> rtadvd won't exit even if ipv6 forwarding is not
wertejuk> enabled, take a look at this patch. (attachement)
wertejuk> Watch out for the changed if-condition.
wertejuk> Is that really a bug ?
No, I don't think it is a bug. The value of `forwarding' is checked
later. From config.c:
/*
* Basically, hosts MUST NOT send Router Advertisement messages at any
* time (RFC 2461, Section 6.2.3). However, it would sometimes be
* useful to allow hosts to advertise some parameters such as prefix
* information and link MTU. Thus, we allow hosts to invoke rtadvd
* only when router lifetime (on every advertising interface) is
* explicitly set zero. (see also the above section)
*/
if (val && forwarding == 0) {
syslog(LOG_WARNING,
"<%s> non zero router lifetime is specified for %s, "
"which must not be allowed for hosts.",
__FUNCTION__, intface);
exit(1);
}
And, I believe the message goes to syslog in this case.
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
[EMAIL PROTECTED] [EMAIL PROTECTED] ume@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
stack alignment issues (was: unbelievable benchmark output)
* Michal Mertl <[EMAIL PROTECTED]> [020203 08:17] wrote: > I wrote a simple program which does this: > > gettimeofday > something (takes several seconds) > gettimeofday > print time elapsed > > Several runs of the program take about the same time but the time > changes wildly when the executable is called differently. > > --- > ./xx/xxx > 5 s > xx/xxx > 9 s > > and similar. It holds true on vastly different machines with current and > stable. > > The only thing which I can think of that can be causing this is some > memory alignment issue. It sure looks like an alignment issue. If you print the address of 'i' and 'j' in the attached program you can see for the fast case they are aligned to 8 byte boundries, but when it's slow they are at an address that is a multiple of 4 but not 8. Not really sure what to make of this, anyone else know how we ought to fix this? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
unbelievable benchmark output
I wrote a simple program which does this:
gettimeofday
something (takes several seconds)
gettimeofday
print time elapsed
Several runs of the program take about the same time but the time
changes wildly when the executable is called differently.
---
./xx/xxx
5 s
xx/xxx
9 s
and similar. It holds true on vastly different machines with current and
stable.
The only thing which I can think of that can be causing this is some
memory alignment issue.
It makes me a bit scared - if the filename or argv[0] make program load
to different address than it can probaly mean that even normal programs
can suffer significatnly from this. Alignment, which does gcc would
probably be mostly useless than. Does the system care where is loads the
program image at all?
Compile the code below with gcc -O -march=pentiumpro and save the
program to /tmp/x (1x) and /tmp/xxx (11x). cd /tmp; ./x shows me
0.490495 (with slight variations amongst runs) and ./xxx 1.016591.
The real results depend on hw but they occur always with different
differences in speed and the length of name of fast/slow programs.
BTW: The program doesn't have to contain assembly it seems but with the
program below the results are most visible.
-- 8<
#include
#include
#include
#include
#define NUMTESTS 1000
static inline void
atomic_add_64(volatile u_int64_t *p, u_int64_t v)
{
__asm __volatile (
" movl (%0),%%eax ; "
" movl 4(%0),%%edx ; "
" 1:movl (%1),%%ebx ; "
" movl 4(%1),%%ecx ; "
" addl %%eax,%%ebx ; "
" adcl %%edx,%%ecx ; "
" cmpxchg8b (%0) ;"
" jnz 1b ;"
"#atomic_add_64"
:
: "S" (p), /* 0 */
"D" (&v) /* 1 */
: "eax", "ebx", "ecx", "edx", "memory" );
}
void
difftimeval(struct timeval start, struct timeval *end)
{
if (end->tv_usec < start.tv_usec) {
end->tv_usec += (100 - start.tv_usec);
end->tv_sec--;
} else
end->tv_usec -= start.tv_usec;
end->tv_sec -= start.tv_sec;
}
int
main()
{
u_int64_t i, j;
int k;
struct timeval st, en;
i = 0;
j = 10;
gettimeofday(&st, NULL);
for (k = 0; k < NUMTESTS; k++) {
atomic_add_64(&i, j);
}
gettimeofday(&en, NULL);
difftimeval(st, &en);
printf("%lu.%06lu\n", en.tv_sec, en.tv_usec);
return (EXIT_SUCCESS);
}
- 8<
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
