to start
committing things in a week or two, after some additional testing, if
there is no objections or other suggestions.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
and n_descsz do
* not include the padding.
*/
--
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
On Fri, Mar 29, 2013 at 11:22:45AM +0200, Konstantin Belousov wrote:
On Thu, Mar 28, 2013 at 11:18:21PM +0200, Mikolaj Golub wrote:
On Thu, Mar 28, 2013 at 12:51:34PM +0200, Konstantin Belousov wrote:
In the generic Elf 64bit draft specification I have, the notes sections
are specified
care if I
want to MFC the code to stable/9 and may be 8?
Version of what ? MFC does not require any additional actions, FBSD_1.3
is the valid version namespace in 9 and 8.
Ok. Now I see it was rather silly question :-). Thanks. For this and
your other notes.
--
Mikolaj Golub
bump the version? Won't I need any additional care if I
want to MFC the code to stable/9 and may be 8?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
On Sun, Mar 17, 2013 at 08:30:33AM +0200, Konstantin Belousov wrote:
On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote:
A KPI that would be natural for my case:
/* start a section that is going to be aligned to sizeof(Elf_Size),
using byte '0' for padding
On Wed, Feb 20, 2013 at 09:58:02PM +0200, Mikolaj Golub wrote:
On Wed, Feb 20, 2013 at 09:04:14AM -0500, John Baldwin wrote:
The process should be stopped by the time we dump a core, so running it
multiple times should be ok in that the sizes should not change. I would
say that you
, things like umask, resources and osrel might be
of the interest for post-morted analysis.
This is in my TODO list.
I did not looked at the usermode changes.
Thanks for your suggestions! Will do them.
--
Mikolaj Golub
___
freebsd-hackers
On Sun, Mar 17, 2013 at 12:35:20AM +0200, Mikolaj Golub wrote:
Ah, this is a thing I wanted to discuss but forgot! As I understand
the idea of the 'ABI hack' is: if the output buffer is less than the
size of data we have, truncate our data to the last successfully
written kinfo_file structure
you for all your comments and suggestions.
--
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
.
Stop
--
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
On Wed, Jan 23, 2013 at 11:31:43AM -0500, John Baldwin wrote:
On Wednesday, January 23, 2013 2:25:00 am Mikolaj Golub wrote:
IMHO, after adding procstat_getargv and procstat_getargv, the usage of
kvm_getargv() and kvm_getenvv() (at least in the new code) may be
deprecated. As this is stated
sysctl) she would have to do procstat_open_kvm() for
args and procstat_open_sysctl() for files.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
do not belong in the kvm interface. I suppose they are part
of libkvm because there was no a better place for them. procstat(1)
prefers direct sysctl to them (so, again, code duplication, which I am
going to remove adding procstat_getargv/envv).
--
Mikolaj Golub
this second patch, if there are no objections
or suggestions how to improve the things.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd
this?
--
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
Not sure it is useful enough to be committed.
--
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
On Sat, 9 Jun 2012 11:38:22 +0300 Konstantin Belousov wrote:
KB On Sat, Jun 09, 2012 at 10:31:17AM +0300, Mikolaj Golub wrote:
On Fri, 1 Jun 2012 14:54:48 +0200 Ivan Voras wrote:
IV On 1 June 2012 14:35, Wojciech Puchar woj...@wojtek.tensor.gdynia.pl
wrote:
http
just to divide the result obtained counting normal-sized pages by
(2M/4k) factor?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers
On Sat, Mar 17, 2012 at 9:30 PM, Mikolaj Golub troc...@freebsd.org wrote:
Hi,
Currently we can check and change binary osreldate of another process via
procfs(5).
Kostik suggested to add a new sysctl for the same purpose and also extend
procstat to show osrel.
Here are patches I am going
On Thu, 22 Mar 2012 22:38:15 +0200 Mikolaj Golub wrote:
MG Actually I don't see reasons why this may not be p_cansee, so I
MG updated the patch and going to commit it if there is no objections.
The updated patch:
http://people.freebsd.org/~trociny/kern_proc_osrel.2.patch
--
Mikolaj Golub
On Sat, 17 Mar 2012 22:29:01 +0100 Jilles Tjoelker wrote:
JT On Sat, Mar 17, 2012 at 09:30:05PM +0200, Mikolaj Golub wrote:
I added osrel output to procstat -b option:
kopusha:~% procstat -b 2975
PID COMMOSREL PATH
2975 emacs 101 /usr/local/bin/emacs
:~% procstat -b 2975
PID COMMOSREL PATH
2975 emacs 101 /usr/local/bin/emacs-23.3
Would this be ok or someone see a better way?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
JH Would this be a planned MFC to stable/N as well specifcially 8 ?
I plan to MFC to stable/9 if there is no objections.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
On Sat, 17 Mar 2012 23:26:53 +0200 Konstantin Belousov wrote:
KB On Sat, Mar 17, 2012 at 11:07:24PM +0200, Mikolaj Golub wrote:
On Sat, 17 Mar 2012 16:37:02 -0400 Jason Hellenthal wrote:
JH Would this be a planned MFC to stable/N as well specifcially 8 ?
I plan to MFC to stable
On Sun, 4 Dec 2011 15:57:06 + Robert N. M. Watson wrote:
RNMW On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote:
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells
On Sun, 4 Dec 2011 15:57:06 + Robert N. M. Watson wrote:
RNMW On 4 Dec 2011, at 14:31, Jilles Tjoelker wrote:
On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
[KERN_PROC_AUXV requires just p_cansee()]
If we are ever going to do ASLR, the AUXV information tells
after the check. I believe you already tried
KB to do this with P_WEXIT.
Ok, eventually I decided not to check for P_INEXEC (as the simplest :-).
The updated patch:
http://people.freebsd.org/~trociny/env.sys.5.patch
--
Mikolaj Golub
___
freebsd-hackers
On Wed, 09 Nov 2011 15:31:26 +0200 Mikolaj Golub wrote:
MG On Wed, 9 Nov 2011 14:53:29 +0200 Kostik Belousov wrote:
And now you return success and nothing gets copied out for the process
in P_INEXEC state. Either you should return an error like EAGAIN, or
consider the P_INEXEC state
On Wed, 9 Nov 2011 14:44:55 +0200 Kostik Belousov wrote:
KB On Tue, Nov 08, 2011 at 11:47:54PM +0200, Mikolaj Golub wrote:
http://people.freebsd.org/~trociny/env.sys.4.patch
Investigating cases when EFAULT was returned and if the fallback was
successful I noticed that most
for me to check for P_INEXEC and return EAGAIN, and
add the comment why we do this and that it still racy. But if you still think
that ignoring the state is the best option no problems for me to return it
back.
--
Mikolaj Golub
___
freebsd-hackers
On Sun, 6 Nov 2011 20:10:41 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 10:37:46PM +0200, Mikolaj Golub wrote:
http://people.freebsd.org/~trociny/env.sys.3.patch
KB Oops, I missed this in the previous review. You cannot use fubyte in
KB proc_read_mem(). fubyte reads a byte
On Sat, 5 Nov 2011 15:58:01 +0200 Kostik Belousov wrote:
KB procfs_doproccmdline() can benefit from your work.
Patch for procfs:
http://people.freebsd.org/~trociny/procfs.patch
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
are observed:
procstat: sysctl: kern.proc.args: 58002: 8: Exec format error
And for kern.proc.env:
procstat: sysctl: kern.proc.env: 81352: 16: Device busy
But I have not investigated these cases yet.
The update version:
http://people.freebsd.org/~trociny/env.sys.2.patch
--
Mikolaj Golub
() and
proc_getenvv().
Ah, sure.
KB Note that using cached pargs is somewhat inconsistent with the digging
KB into ps_strings.
KB procfs_doproccmdline() can benefit from your work.
Thanks, I will look at it :-).
--
Mikolaj Golub
___
freebsd-hackers
)
Looking at exec_copyout_strings() from kern_exec.c, how destp is calculated, I
think they are sizeof(char *) aligned.
Do you think it is worth adding the check for sizeof(char *) alignment?
if (vptr % (sizeof(char *) != 0)
return (ENOEXEC);
--
Mikolaj Golub
On Sat, 5 Nov 2011 21:45:53 +0200 Kostik Belousov wrote:
KB On Sat, Nov 05, 2011 at 08:59:21PM +0200, Mikolaj Golub wrote:
On Sat, 5 Nov 2011 17:44:43 +0200 Kostik Belousov wrote:
KB I think that the aux vector must be naturally aligned. You can
return
KB ENOEXEC early
vectors.
Also I decided not to play with exec_alloc_args :-).
--
Mikolaj Golub
diff --git a/sys/sys/proc.h b/sys/sys/proc.h
index fb97913..4949f98 100644
--- a/sys/sys/proc.h
+++ b/sys/sys/proc.h
@@ -168,6 +168,7 @@ struct p_sched;
struct proc;
struct procdesc;
struct racct;
+struct sbuf
think
it is worth doing?
--
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
On Mon, 31 Oct 2011 11:49:48 +0200 Kostik Belousov wrote:
KB On Sat, Oct 29, 2011 at 01:32:39PM +0300, Mikolaj Golub wrote:
What do you think about the attached patch? This is a kernel
part. COMPAT_FREEBSD32 has not been tested after the last update (just
checked
that it compiles
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
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
the size? Or do you
propose to extend struct ps_strings to store location and size of auxv? I
could do this way...
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe
currently only ps uses kvm_getenvv(3) (and thus
kvm_uread()).
Note, when reading from its own user space it just does bcopy(3), so if a
wrong address range is passed to kvm_uread() the program will segfault. Do we
need some protection here and what? Masking SIGSEGV?
--
Mikolaj Golub
On Tue, 22 Mar 2011 00:15:06 +0300 Andrey Zonov wrote:
AZ Hi,
AZ This sysctl contains a binary data. You can see it using -o or -x
AZ sysctl's key.
AZ Additional information is at devstat(3) manpage.
Or try sysutils/devstat :-)
--
Mikolaj Golub
? flowtable? Or
jail/epair, which should not allow simultaneous entering of flowtable_flush?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd
On Sat, 20 Nov 2010 17:03:13 + (UTC) Bjoern A. Zeeb wrote:
BAZ On Sat, 20 Nov 2010, Mikolaj Golub wrote:
BAZ Hi,
Running something like below under VirtualBox (CURRENT, VIMAGE)
BAZ ...
So the question is who is guilty in this situation? ULE? flowtable? Or
jail/epair, which should
it to freebsd-virtualization unless I find that this is
a known issue.
--
Mikolaj Golub
Index: sys/net/flowtable.c
===
--- sys/net/flowtable.c (revision 215574)
+++ sys/net/flowtable.c (working copy)
@@ -195,7 +195,8
= (struct ifnet *) 0xdeadc0de
Doesn't this need some lock protection? I tried the attached patch, but still
observed crashes in ifioctl I posted earlier.
--
Mikolaj Golub
Index: sys/net/vnet.c
===
--- sys/net/vnet.c (revision 215576
returned by close(2) after shutdown()/close() on our side and simultaneous
close() on the other side (and in this case this is wrong).
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
/sysctl.conf
debug.ddb.capture.bufsize=5242880).
--
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
On Thu, 18 Feb 2010 11:59:40 + (GMT) Robert Watson wrote:
On Thu, 18 Feb 2010, Mikolaj Golub wrote:
Below is a simple test code with unix sockets: the client does
connect()/close() in loop and the server -- accept()/close().
Sometimes close() fails with 'Socket is not connected' error
) above
to avoid the race
if (close(connfd) != 0)
errx(1, child: close error: %d, errno);
usleep(USLEEP);
}
}
return 0;
}
--
Mikolaj Golub
://www.freebsd.org/cgi/query-pr.cgi?pr=139721
BTW, many things in the script have been improved since I posted it here, and
user friendly error output is among them :-).
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman
, it says that we have
some problems with accessing crash dump files, so permissions should be
checked.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
On Fri, 9 Oct 2009 11:28:11 -0400 John Baldwin wrote:
JB On Monday 05 October 2009 1:48:06 am Mikolaj Golub wrote:
Hi,
It would be nice if crashinfo(8) were also trying to output the content of
ddb
capture buffer. Something like in this patch:
--- crashinfo.sh.orig2009
unpacked archive
will give kgdb(1) session with crash core loaded in it. The script should be
run with root privileges because it does chroot(8) before starting kgdb(1).
I think I don't have to warn here that a crashdump may be sent only to person
you trust :-).
--
Mikolaj Golub
capture buffer
+ echo
+ cat $file |
+ sed -e 's/p\{10\}p*//' # XXX: this removes the unfilled part of
a capture buffer
+ echo
+ fi
+ rm -f $file
+fi
+
--
Mikolaj Golub
___
freebsd-hackers
',
nc_nlen = 0 '\0', nc_name = 0xcc33785e }
--
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
which
traverse kernel structures extracting all necessary data. But SNMP has its
own limitations, statistics provided via SNMP are rather limited and currently
I don't see how I could use it effectively to echieve my goal, althogh I
haven't think much in this direction yet...
--
Mikolaj Golub
.
WP using rcp works. most probably ftpd uses sendfile, while rcp does not
Yes, this is sendfile problem. It has been reported.
http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/127213
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
On Tue, 02 Jun 2009 23:24:54 +0300 Mikolaj Golub wrote:
Actually some output from crashinfo looks suspicious. zero values for fork()
calls, negative values in vmstat -m output... Does the userland where you were
running crashinfo matched the crushed kernel?
It looks like the strange figures
symbols from... and the command line itself)?
Also you can try in kgdb session:
fr 9
list
p *cmd
p cmd-arg1
p a
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any
remember that debugging symbols for modules are needed
too?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail
be able to provide bt (from the next crash :-)
with all necessary info available. Do the bt output for other crashes looks
the same?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
On Tue, 12 May 2009 09:27:30 +0300 Mikolaj Golub wrote:
MG Hi,
MG The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386,
amd64):
MG #include omp.h
MG #include unistd.h
MG int n = 4, m = 2;
MG int main () {
MG for (;;) {
MG int i;
MG
traced this bug.
MN Thanks, I'll take a look at it.
Today I submitted lmdbg port.
http://www.freebsd.org/cgi/query-pr.cgi?pr=134617
At present it is waiting to be committed in ports tree, but you can use shar
from the PR to build the port yourself.
--
Mikolaj Golub
On Fri, 15 May 2009 13:48:51 +0200 Marius Nünnerich wrote:
MN On Tue, May 12, 2009 at 08:27, Mikolaj Golub to.my.troc...@gmail.com
wrote:
Hi,
The code below is compiled with -fopenmp and run on FreeBSD6/7 (i386,
amd64):
#include omp.h
#include unistd.h
int n = 4, m = 2
with uncommented
sleep() and observing the number of threads with 'top -H' I see in turn 2 or 4
threads. So it looks like memory leak when thread is removed. Should I fill
PR?
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
You need to increase the value of debug.ddb.capture.bufsize sysctl variable to
make sure all ddb output will be captured.
You can read more about this in ddb(4), ddb(8), textdump(4).
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
eater.
--
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
help to restart daemons
one by one and see if sockets are freed.
You can surely increase kern.ipc.maxsockets as workaround until you identify
what causes the problem.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org
done
Look for sockets with 0 count. These are suspicious ones. Observe these
sockets by netstat and try to figure out what application they could belong
and dig in that direction.
--
Mikolaj Golub
___
freebsd-hackers@freebsd.org mailing list
http
73 matches
Mail list logo
