Re: ps -e without procfs(5)
On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
KB argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as
KB procfs and linprocfs inside the kernel.
Thanks! I am testing a patch (without auxv vector so far) and have some
questions.
Original ps -e returns environment only for user owned processes (the access
is
restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl
does not have such a restriction. I suppose I should add it? What function I
could use for this?
BTW, linprocfs allows to read other user's environment.
linprocfs uses p_cansee() to check the permissions. There are sysctls
security.bsd.see_other_{ug}ids that control the behaviour.
I believe that the new sysctl shall use the same check.
KB While you are at the code, it would be useful to also export the auxv
vector,
KB which is immediately before env.
It looks I can find the location of auxv but what about the size? Or do you
propose to extend struct ps_strings to store location and size of auxv? I
could do this way...
No, extending ps_strings is not needed and it is too radical change.
The auxv vector must end by the AT_NULL aux entry. You can also artificially
limit the amount of read aux vectors to, say, 256, which is much more then
it is currently defined.
pgpHLn9etVmXO.pgp
Description: PGP signature
Re: ps -e without procfs(5)
On 25 Oct 2011, at 09:24, Kostik Belousov wrote:
On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
KB argv and env vectors. Then, ps(1) and procstat(1) can use it, as well as
KB procfs and linprocfs inside the kernel.
Thanks! I am testing a patch (without auxv vector so far) and have some
questions.
Original ps -e returns environment only for user owned processes (the access
is
restricted by the permissions of /proc/pid/mem file). My kern.proc.env sysctl
does not have such a restriction. I suppose I should add it? What function I
could use for this?
BTW, linprocfs allows to read other user's environment.
linprocfs uses p_cansee() to check the permissions. There are sysctls
security.bsd.see_other_{ug}ids that control the behaviour.
I believe that the new sysctl shall use the same check.
To be honest, I'd be far more comfortable if the environment check used
p_candebug(). Environmental variables sometimes contain passwords, etc, that
shouldn't be visible to other users on the system. Even showing command lines
is a bit dubious, but widely accepted, whereas seeing the contents of
environmental variables is not widely known in user communities.
Robert___
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: ps -e without procfs(5)
On Tue, 25 Oct 2011 11:24:51 +0300 Kostik Belousov wrote:
KB On Tue, Oct 25, 2011 at 12:13:10AM +0300, Mikolaj Golub wrote:
On Sun, 16 Oct 2011 20:10:05 +0300 Kostik Belousov wrote:
KB In my opinion, the way to implement the feature is to (re)use
KB linprocfs_doargv() and provide another kern.proc sysctl to retrieve the
KB argv and env vectors. Then, ps(1) and procstat(1) can use it, as well
as
KB procfs and linprocfs inside the kernel.
Thanks! I am testing a patch (without auxv vector so far) and have some
questions.
Original ps -e returns environment only for user owned processes (the
access is
restricted by the permissions of /proc/pid/mem file). My kern.proc.env
sysctl
does not have such a restriction. I suppose I should add it? What function I
could use for this?
BTW, linprocfs allows to read other user's environment.
KB linprocfs uses p_cansee() to check the permissions. There are sysctls
KB security.bsd.see_other_{ug}ids that control the behaviour.
KB I believe that the new sysctl shall use the same check.
This looks reasonable for me. But I just wanted to be sure that this would be
ok for other people, as my patch changes the system behavior: currently with
security.bsd.see_other_{ug}ids and procfs (not linprocfs) mounted a user can
see other users args but not env; after the change a user will see both args
and env (until security.bsd.see_other_{ug}ids is off).
KB While you are at the code, it would be useful to also export the auxv
vector,
KB which is immediately before env.
It looks I can find the location of auxv but what about the size? Or do you
propose to extend struct ps_strings to store location and size of auxv? I
could do this way...
KB No, extending ps_strings is not needed and it is too radical change.
KB The auxv vector must end by the AT_NULL aux entry. You can also
artificially
KB limit the amount of read aux vectors to, say, 256, which is much more then
KB it is currently defined.
Thanks.
--
Mikolaj Golub
___
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: Apache Corefile issues
On Mon, Oct 24, 2011 at 5:26 PM, Bernd Walter ti...@cicely7.cicely.de wrote: On Mon, Oct 24, 2011 at 04:52:15PM -0400, Mark Saad wrote: Hackers I have a strange apache issue , and I wonder if anyone has seen this before. I am running Apache 1.3.34 on freeBSD 7.3-RELEASE amd64 . At some point in the day apache's children segfault and die. No core files are generated. I am not running mod_php either. Apache 1.x isn't really advised since many many years, but I assume you have very special reasons to stay with it? we are moving away from this to nginx 1. I have setup the following sysctls #Debug options kern.sugid_coredump=1 kern.corefile=/var/coredumps/%U-%N-%P.core Don't use quotes here. Stupid me , why is this sysctl using no quotes as its convention ? 2. The httpd.conf is set with CoreDumpDirectory /var/coredumps/ 3. The dir /var/coredumps/ is set 1777 4. A ktrace of the parrent apache process shows the core file tries to create 84954 libhttpd.ep RET kill 0 84954 libhttpd.ep CALL sigreturn(0x7ffeb030) 84954 libhttpd.ep RET sigreturn JUSTRETURN 84954 libhttpd.ep PSIG SIGSEGV SIG_DFL 84954 libhttpd.ep NAMI /var/coredumps/65534-libhttpd.ep-84954.core It's double quoted here - one to frame the filename and one as part of the filename itself. I guess your / directory don't contain a subdirectory named . This worked with out the quotes on the sysctl 34924 libhttpd.ep RET select 0 34924 libhttpd.ep CALL gettimeofday(0x7fffe890,0) 34924 libhttpd.ep RET gettimeofday 0 34924 libhttpd.ep CALL fork 5. I have proc mounted and I can't gcore -s $PID either I have no cores and I am stumped . -- mark saad | nones...@longcount.org ___ 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 -- B.Walter be...@bwct.de http://www.bwct.de Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm. -- mark saad | nones...@longcount.org ___ 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: determining bus_dma memory usage by driver
On Mon, Oct 24, 2011 at 8:38 PM, Matthew Jacob m...@feral.com wrote: On 10/24/2011 5:21 PM, Chuck Tuffli wrote: Is there an easy way to determine the amount of bus_dma memory allocated by a driver? Something similar to vmstat -m bus_dma memory allocations are platform specific. Looking at least amd64 you can see that the memory is carved out M_DEVBUF. OK, so do a diff of vmstat -m | grep devbuf before and after driver load would get me the right number? Does this double count any memory reported by the MALLOC_DEFINE()? ---chuck ___ 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: Shrinking 4 parititions on a new HP laptop
Julian H. Stacey wrote: A new purchased HP laptop (pavilion entertainment PC dm3 ... As no answer so far, I reformulated posting, added info reposted to sysinstall@ Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultants Munich http://berklix.com Reply below, not above; Indent with ; Cumulative like a play script. Format: Plain text. Not HTML, multipart/alternative, base64, quoted-printable. ___ 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: Shrinking 4 parititions on a new HP laptop
When Win comes with machine, you don't use it at all. YOU install Win, set it up and THEN use it. You must have bootable USB stick, which you have already setup-ed (Must be able to compile/install BSD itself and in it, you have your BSD confs). Stick it and enter boot menu on laptop and choose USB. When BSD boots, at this step, you will ONLY SLICE HDD: # dd if=/dev/zero of=/dev/ada0 bs=8m Nuke HDD and pRe-installed $oft Win # gpart create -s MBR ada0 You wana dual boot right? # gpart bootcode -b /boot/mbr ada0 You said 1 slice, but I say 2 slices (which will preserve ntfs data, if win is nuked) Use max 35 Gb for win install slice and choose yourself how much Gb you wana for slice 2 # gpart add -s 30g -t ntfs ada0 # gpart add -s 50g -t \!15 ada0 Append slice 2, of type 'Extended DOS (LBA)' - holds all oher added letters (D:, E:, ...) ... Here you can add max 2 slices for FreeBSD and something else ... Reboot, as we ONLY SLICED HDD. Now install Win7 (it reads MBR and replaces it with it's own MBR) and set it up. After Win7 has been installed: Boot USB stick and: # boot0cfg -B ada0 # boot0cfg -m 0x5 ada0 # In boot options, show only slices 1 (Win7) and 3 (FreeBSD) Here you would mount slice 3 and install FreeBSD into it ... (about which I'll not chatter ...) Domagoj Smolčić ___ 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: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value?
On Mon, 24 Oct 2011 15:42:10 -0500
Dan Nelson dnel...@allantgroup.com wrote:
In the last episode (Oct 24), Christopher J. Ruwe said:
On Sun, 23 Oct 2011 19:10:34 -0500
Dan Nelson dnel...@allantgroup.com wrote:
In the last episode (Oct 23), Christopher J. Ruwe said:
I need to get the maximum size of an pwd-entry to determine the
correct buffersize for calling getpwnam_r(uname,pwd, buf,
bufsize, pwdp). I would like to use
sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which
unfornutately fails (returns -1). Currently, I used 16384,
which seems to be too much, bit works for the time being.
[..]
From looking at the libc/gen/getpwent.c file, it looks like a
maximum size might be 1MB. The wrapper functions that convert
getpw*_r functions into ones that simply return a pointer to
malloced data all use the getpw() helper function, which starts
with a 1k buffer and keeps doubling its size until the data fits
or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked
within that getpw() function, though, so it's possible that an
nss library might return an even longer string to a get*_r call.
It's up to you to decide what your own limit is :)
Uh ... it's just that I hoped I had not to decide ;-)
However, 1M seems to be rather large to me. Let's see (pwd.h):
116 struct passwd {
117 char*pw_name; /* user name */
118 char*pw_passwd; /* encrypted
password */ 119 uid_t pw_uid; /* user
uid */ 120 gid_t pw_gid; /* user gid
*/ 121 time_t pw_change; /* password change
time */ 122 char*pw_class; /* user access
class */ 123char*pw_gecos; /* Honeywell
login info */ 124 char*pw_dir;/* home
directory */ 125char*pw_shell; /* default
shell */ 126time_t pw_expire; /* account
expiration */ 127 int pw_fields; /* internal:
fields filled in */ 128 };
So pw_name - MAXLOGNAME (from param.h) = 17. pw_passwd -
http://www.freebsd.org/doc/handbook/one-time-passwords.html = 129.
pw_uid pw_gid each sizeof(__uint32_t) ?= 32b. time_t -
sizeof(__int64_t) ?= 64b.
At some point, I would just sum it up and reach some size which
might be machine dependant, but should be somewhere
(guessing/estimating now) between 4k and 16k. I am short on time
just now, am I on the right track or am I missing something which
should be obvious to someone with experience, but is not to me
(lacking experience)?
The getpwnam_r function needs enough space to store the struct
passwd itself (which has a constant size) plus the strings pointed
to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have
enough control over your environment that you can guarantee that the
sum of those strings won't be larger than 4k, then you can just used
a fixed buffer of that size. Even 1k is probably large enough for
99.999% of all systems. That's a really long home directory or shell
path :) On the other hand, the GECOS field is theoretially free-form
and could contain a lot of data. I've never see it hold more than an
office number myself, though.
Thanks for your help so far. Just assuming (I am not sufficiently clear about
myself and my own intents) I want to be precise and am afraid of guessing: Can
I assume that the gecos field is an entry in /etc/passwd and can therefore
never exceed LINE_MAX, i.e., 2048B (limits.h, line 72)? Or, more precisely, (
2048B - sum( lenght(all fields except passwd) ) )? Would that be an acceptable
limit to set the getpwnam_r( ... ) buffer to and/or would that be an acceptable
value to replace the following bit from sysconf.c?
372#if _POSIX_THREAD_SAFE_FUNCTIONS -1
373 case _SC_GETGR_R_SIZE_MAX:
374 case _SC_GETPW_R_SIZE_MAX:
375 #error somebody needs to implement this
376#endif
Thanks again, cheers,
--
Christopher J. Ruwe
TZ GMT + 2
___
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
iotop (dtrace?)
I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Thanks, Stefan Solaris dtrace-based iotop: http://prefetch.net/articles/solaris.dtracetopten.html Linux /proc-based Python script: http://guichaz.free.fr/iotop/ -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: iotop (dtrace?)
On Tue, Oct 25, 2011 at 10:34:39PM +0200, Stefan Bethke wrote: I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Can't 'top -mio' do the job? regards, Bapt pgpDBtL848D9o.pgp Description: PGP signature
Re: iotop (dtrace?)
Am 25.10.2011 um 22:50 schrieb Baptiste Daroussin: On Tue, Oct 25, 2011 at 10:34:39PM +0200, Stefan Bethke wrote: I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Can't 'top -mio' do the job? D'oh! Thanks! Stefan -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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: iotop (dtrace?)
top and then use the IO mode, will give you an idea where the issue is. Regards Steve - Original Message - From: Stefan Bethke s...@lassitu.de To: freebsd-hackers@freebsd.org Sent: Tuesday, October 25, 2011 9:34 PM Subject: iotop (dtrace?) I've got two systems with a constantly high rate of disk I/O that sometimes seems to be overwhelmed from it. Before trying to decide if a hardware upgrade will help, I'd like to figure out which processes generate the load. I've found a couple scripts named iotop which appear to produce what I would be interested in, but they appear to require Solaris or Linux. Has someone ported over one of them, or would have a suggestion how to go about writing a custom dtrace script to gather this kind of information? I can successfully run a couple of sample dtrace scripts on these 8-stable amd64 boxes. Thanks, Stefan Solaris dtrace-based iotop: http://prefetch.net/articles/solaris.dtracetopten.html Linux /proc-based Python script: http://guichaz.free.fr/iotop/ -- Stefan Bethke s...@lassitu.de Fon +49 151 14070811 ___ 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 This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmas...@multiplay.co.uk. ___ 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: _SC_GETPW_R_SIZE_MAX undefined in sysconf.c, what is correct value?
In the last episode (Oct 25), Christopher J. Ruwe said: On Mon, 24 Oct 2011 15:42:10 -0500 Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Oct 24), Christopher J. Ruwe said: On Sun, 23 Oct 2011 19:10:34 -0500 Dan Nelson dnel...@allantgroup.com wrote: In the last episode (Oct 23), Christopher J. Ruwe said: I need to get the maximum size of an pwd-entry to determine the correct buffersize for calling getpwnam_r(uname,pwd, buf, bufsize, pwdp). I would like to use sysconf(_SC_GETPW_R_SIZE_MAX) to determine bufsize, which unfornutately fails (returns -1). Currently, I used 16384, which seems to be too much, bit works for the time being. [..] From looking at the libc/gen/getpwent.c file, it looks like a maximum size might be 1MB. The wrapper functions that convert getpw*_r functions into ones that simply return a pointer to malloced data all use the getpw() helper function, which starts with a 1k buffer and keeps doubling its size until the data fits or it hits PWD_STORAGE_MAX (1MB). PWD_STORAGE_MAX is only checked within that getpw() function, though, so it's possible that an nss library might return an even longer string to a get*_r call. It's up to you to decide what your own limit is :) Uh ... it's just that I hoped I had not to decide ;-) The getpwnam_r function needs enough space to store the struct passwd itself (which has a constant size) plus the strings pointed to by pw_name, pw_class, pw_gecos, pw_dir, and pw_shell. If you have enough control over your environment that you can guarantee that the sum of those strings won't be larger than 4k, then you can just used a fixed buffer of that size. Even 1k is probably large enough for 99.999% of all systems. That's a really long home directory or shell path :) On the other hand, the GECOS field is theoretially free-form and could contain a lot of data. I've never see it hold more than an office number myself, though. Thanks for your help so far. Just assuming (I am not sufficiently clear about myself and my own intents) I want to be precise and am afraid of guessing: Can I assume that the gecos field is an entry in /etc/passwd and can therefore never exceed LINE_MAX, i.e., 2048B (limits.h, line 72)? Or, more precisely, ( 2048B - sum( lenght(all fields except passwd) ) )? Would that be an acceptable limit to set the getpwnam_r( ... ) buffer to and/or would that be an acceptable value to replace the following bit from sysconf.c? 372 #if _POSIX_THREAD_SAFE_FUNCTIONS -1 373 case _SC_GETGR_R_SIZE_MAX: 374 case _SC_GETPW_R_SIZE_MAX: 375 #error somebody needs to implement this 376#endif If your nsswitch.conf has passwd: files in it, then yes, you can assume that the 2048-byte limit applies. However, if you are using nss_ldap, nss_mysql, nss_winbind, or some other nsswitch module that provides user info, that backend user system may be capable of returning longer strings. If you want to be able to handle any struct passwd that might be thrown at you, you should implement a retry with doubling loop similar to the one in libc/gen/getpwent.c:getpw() . -- Dan Nelson dnel...@allantgroup.com ___ 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: mmap performance and memory use
On 10/10/2011 4:28 PM, Wojciech Puchar wrote: Notice that vm.pmap.pde.promotions increased by 31. This means that 31 superpage mappings were created by promotion from small page mappings. thank you. i looked at .mappings as it seemed logical for me that is shows total. In contrast, vm.pmap.pde.mappings counts superpage mappings that are created directly and not by promotion from small page mappings. For example, if a large executable, such as gcc, is resident in memory, the text segment will be pre-mapped using superpage mappings, avoiding soft fault and promotion overhead. Similarly, mmap(..., MAP_PREFAULT_READ) on a large, memory resident file may pre-map the file using superpage mappings. your options are not described in mmap manpage nor madvise (MAP_PREFAULT_READ). when can i find the up to date manpage or description? A few minutes ago, I merged the changes to support and document MAP_PREFAULT_READ into 8-STABLE. So, now it exists in HEAD, 9.0, and 8-STABLE. Alan ___ 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
